心跳、信令负载问题根源是在于手机终端的设计还是APP应用？
这个问题本质上不是终端的问题，还是和App应用工作机制以及用户行为有关。如果非要说终端，只不过智能终端释放了App的活力。至于说心跳之类的交互则是App工作机制设计的问题。当前讨论最多的IM类应用对信令的大量使用。看来看去也都是在云里雾里的一通忽悠，根本没有理解何谓当前主题涉及的“信令”。这个问题包括以下几个方面的因素：1 - 寻呼PCH资源、AGCH接入允许信道资源消耗。不难理解，为了发送数据到休眠的用户，必然先要找到他
2 - 心跳包对RACH/PRACH/AGCH信道资源的占用，重要的还有PDCH（TBF建立）业务信道资源的占用，这个是收费信道
3 - 频繁的状态转换对核心网交换机设备的负荷压力
另外，说明一点这个问题和2G/3G网络无关，只不过目前3G用户量实在太毛线。所以，电信和联通才在那里借机营销，自己太穷还不忘时机黑移动啊，呵呵。
以上三个方面如果不加控制，到了一定的引爆点，自然就可以把一个网络拿下趴窝了。你说移动会不捉鸡么？TENCENT的IT研发有几个人清楚这个，你懂么？心跳的过于频繁等于过度消费运营商的大量宝贵资源。提出对TENCENT收费的想法也是完全可以理解的，一旦收费，这个费用不会很低。收了你的流量费不代表你就可以在我的网络里面撒野了。
科普下。
微信降低PDCH承载效率的问题其实更严重，小包业务分配的资源一样，但是产生的流量少的可怜
楼主提及智能机的意思是否是说智能机的省电机制，会主动释放资源，导致微信类APP需要用心跳包keep？实际上即使不是智能机，无线侧也会在空闲一段时间后主动释放资源的。
正常的非IM类应用，比如在浏览网页的过程中，你停留在一个页面看内容的间隙，空口TBF资源已经释放了，也就是说PDCH信道释放了，这个是共享使用的概念。并且这个时间很短，但是你不再浏览的时候，那么就不再使用空口大量资源，仅仅做必要的移动性管理。但是这类行为是正常的，也是网络可以承受的。
而IM类应用，他是频繁的主动发起心跳包的，比如60s甚至更短时间。那么，大量的用户周期性的不停做keep-alive操作，产生仅仅几个字节的流量，但一次行为带来的信令事件却是几十个，涉及的网络设备从接入到核心侧都需要参与为你这么一次小小的跳跳辛勤工作，几乎免费！！！还面临风暴的极大风险。可想而知，这种经济效益是十分低下的，并且安全风险极度上升扩大。OP的付出和收入严重失衡。
这就是我说的这个事情，这种心跳包与使用什么终端无关，无线网的特性在于共享信道，空口释放是正常的，IM类应用通过心跳包长期占用信道，这与终端特性无关。
我的看法是，还是跟终端有关，空口释放由网络侧释放或者由终端侧释放还是有关系的，假如终端侧空口释放的时间比网络侧，也比心跳更新的时间更少的话，那说明终端侧的空口释放时间太短，导致信令负荷的进一步增加。
智能手机为了省电，是否是每一次已发送完消息就转换为空闲模式？
其实不管无线侧还是终端侧，释放的间隔都小于心跳包间隔~我印象中某款IM客户商的心跳包是30S。QQ的心跳包间隔也改动过好几次。
说到底，应该还是每次心跳包发送的数据量太小，假如每次都有几百KB的流量，运营商也乐意
2g时代QQ不也一样用么，大家都在手机上挂QQ，一天24小时，不要说那个时候的手机QQ没有微信这么多，也没见有什么问题，运营商还鼓励大家用QQ呢，定制手机上都绑定QQ。
正解
关键是很多人不懂技术，所以腾讯得逞
感谢解答，学习了！
也不是完全和终端类型无关，Nokia当年为了终端省电搞了个fast dormancy，加快终端进入dormant状态的速度，结果加大了信令风暴发生的可能性和严重程度
没错，所谓fast dormancy就是终端完成一次session后迅速由连接态释放，似乎是前两年日本NTT DOCOMO网络中信令风暴的罪魁祸首之一
我估计跟安卓和IOS也有关系～～还在看相关的资料ing
追问一下前辈几个小问题,
关于第3点:对核心网设备的负荷,是否只涉及到RNC和SGSN-GGSN?
如果是不同运营商的手机微信用户进行语音业务,中间是否由腾讯公司负责接续?如果是,是否也象普通语音业务一样,从远端落地过网?
一条高速公路车道只给一辆自行车使用，如果自行车在车道上，汽车是无法走的，而这辆自行车带来的管理费用远超过其实际价值，占用了大量资源，而整段时间内，他又是几十秒到高速公路上来一次，他一来整体的管理资源都要注意到他，然后对其