心跳、信令负载问题根源是在于手机终端的设计还是APP应用？

进行支持，管理资源消耗太高，而收他过路费又不能按照汽车收，因为他确实没多重，确实没那么大载客量，如果按照汽车比例收的话，他的费用就过低了，而他又不是一直在公路上，是一会一次的上来，每次上来都要浪费大量管理资源的支持，公路巡警也招架不住了:lol

这个比方虽然很不适当，也有漏洞，但是基本上就这么回事了

大家在使用业务的时候，实际交的费用不只是为了占用纯业务信道的资源费用，还有建立业务信道而消耗的其他资源的费用，当然了还有设备损耗等。而这里说的就是为了建立业务信道而消耗的其他资源受到了大量冲击，而实际流量收费（占用业务信道的时间流量）又很少。

再打个比方，某高原乡村没有水，为了解决这个问题，搭建了一条1000公里的输水管道，而这个小乡村只是每户隔三差五的使用，每天也就2吨水的使用量。发散开来想，微信就是每次用0.5立方的水就要建立1000公里的输水管道（映射到移动业务是虚拟的信道，而非实际物理管道），而全村隔一会就有个人来打水或者这个人隔会就换个桶来接水，这样成天无数次的打水，无数次的管道建立，带来的就是一天几十块的水费，而建立的管道上百万公里了，性价比来说就不值得了。而普通的业务建立一次连接，占用时长较长，使用流量适当，这样就有建立管道的性价比可言了。
现在就是为了达成业务而浪费的建立资源过大，已经达到网络负荷风险，而实际使用的业务根本无法和消耗的资源相提并论，所以需要收费，以收费来适当抑制这种情况。

信令上的负荷，应只涉及到RNC、SGSN和GGSN。
但这是USIM卡通过认证后，假如是刚开机的话，还会涉及HLR，而终端上的信令交互，只跟RNC和SGSN有关。

核心侧网络涉及：SGSN/GGSN/HRL/VLR。主要是移动性管理GMM相关的信息，以及用户SM PDP CONTEXT维护跟踪。HLR/VLR主要是涉及MAP协议，用户标识、位置跟踪、鉴权认证。另外还有计费相关的单元参与。

“如果是不同运营商的手机微信用户进行语音业务,中间是否由腾讯公司负责接续?如果是,是否也象普通语音业务一样,从远端落地过网?”

这个部分倒是和IM公司没有任何关系，网络对于IT公司来讲都是透明的。IM软件只要注意自己的业务接续不出问题，网络的接续那是OP的事情。

我觉着本质上是通信协议栈不能适应移动互联网的需求， 以前有接触过一个 cross layer设计的思路，当时还只是paper， 不知道现状如何了。

先马克