 |
问答管理员：
待解决问题
心跳、信令负载问题根源是在于手机终端的设计还是APP应用？ (进入论坛模式)
离问题结束还有0天0小时 |
提问者：uestcvv
|
提问时间：2013-4-10 10:01
看到一篇文章的编辑说运营商为何只让微信解决心跳过频问题而对智能终端厂商视而不见，楼主就有点不解了，智能终端莫非躺着也中枪？心跳、APP应用、智能终端三者到底是怎样一种关系？
问题答案 ( 21 条 )
这个问题本质上不是终端的问题，还是和App应用工作机制以及用户行为有关。如果非要说终端，只不过智能终端释放了App的活力。至于说心跳之类的交互则是App工作机制设计的问题。当前讨论最多的IM类应用对信令的大量使用。看来看去也都是在云里雾里的一通忽悠，根本没有理解何谓当前主题涉及的“信令”。这个问题包括以下几个方面的因素：1 - 寻呼PCH资源、AGCH接入允许信道资源消耗。不难理解，为了发送数据到休眠的用户，必然先要找到他
2 - 心跳包对RACH/PRACH/AGCH信道资源的占用，重要的还有PDCH（TBF建立）业务信道资源的占用，这个是收费信道
3 - 频繁的状态转换对核心网交换机设备的负荷压力
另外，说明一点这个问题和2G/3G网络无关，只不过目前3G用户量实在太毛线。所以，电信和联通才在那里借机营销，自己太穷还不忘时机黑移动啊，呵呵。
以上三个方面如果不加控制，到了一定的引爆点，自然就可以把一个网络拿下趴窝了。你说移动会不捉鸡么？TENCENT的IT研发有几个人清楚这个，你懂么？心跳的过于频繁等于过度消费运营商的大量宝贵资源。提出对TENCENT收费的想法也是完全可以理解的，一旦收费，这个费用不会很低。收了你的流量费不代表你就可以在我的网络里面撒野了。
科普下。
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。
正解
关键是很多人不懂技术，所以Tencent得逞
感谢解答，学习了！
也不是完全和终端类型无关，Nokia当年为了终端省电搞了个fast dormancy，加快终端进入dormant状态的速度，结果加大了信令风暴发生的可能性和严重程度
没错，所谓fast dormancy就是终端完成一次session后迅速由连接态释放，似乎是前两年日本NTT DOCOMO网络中信令风暴的罪魁祸首之一
我估计跟安卓和IOS也有关系～～还在看相关的资料ing
追问一下前辈几个小问题,
关于第3点:对核心网设备的负荷,是否只涉及到RNC和SGSN-GGSN?
如果是不同运营商的手机微信用户进行语音业务,中间是否由Tencent企业负责接续?如果是,是否也象普通语音业务一样,从远端落地过网?
一条高速公路车道只给一辆自行车使用，如果自行车在车道上，汽车是无法走的，而这辆自行车带来的管理费用远超过其实际价值，占用了大量资源，而整段时间内，他又是几十秒到高速公路上来一次，他一来整体的管理资源都要注意到他，然后对其进行支撑，管理资源消耗太高，而收他过路费又不能按照汽车收，因为他确实没多重，确实没那么大载客量，如果按照汽车比例收的话，他的费用就过低了，而他又不是一直在公路上，是一会一次的上来，每次上来都要浪费大量管理资源的支撑，公路巡警也招架不住了:lol
这个比方虽然很不适当，也有漏洞，但是基本上就这么回事了
大家在使用业务的时候，实际交的费用不只是为了占用纯业务信道的资源费用，还有建立业务信道而消耗的其他资源的费用，当然了还有设备损耗等。而这里说的就是为了建立业务信道而消耗的其他资源受到了大量冲击，而实际流量收费（占用业务信道的时间流量）又很少。
再打个比方，某高原乡村没有水，为了解决这个问题，搭建了一条1000公里的输水管道，而这个小乡村只是每户隔三差五的使用，每天也就2吨水的使用量。发散开来想，微信就是每次用0.5立方的水就要建立1000公里的输水管道（映射到移动业务是虚拟的信道，而非实际物理管道），而全村隔一会就有个人来打水或者这个人隔会就换个桶来接水，这样成天无数次的打水，无数次的管道建立，带来的就是一天几十块的水费，而建立的管道上百万公里了，性价比来说就不值得了。而普通的业务建立一次连接，占用时长较长，使用流量适当，这样就有建立管道的性价比可言了。
现在就是为了达成业务而浪费的建立资源过大，已经达到网络负荷风险，而实际使用的业务根本无法和消耗的资源相提并论，所以需要收费，以收费来适当抑制这种情况。
这个比方虽然很不适当，也有漏洞，但是基本上就这么回事了
大家在使用业务的时候，实际交的费用不只是为了占用纯业务信道的资源费用，还有建立业务信道而消耗的其他资源的费用，当然了还有设备损耗等。而这里说的就是为了建立业务信道而消耗的其他资源受到了大量冲击，而实际流量收费（占用业务信道的时间流量）又很少。
再打个比方，某高原乡村没有水，为了解决这个问题，搭建了一条1000公里的输水管道，而这个小乡村只是每户隔三差五的使用，每天也就2吨水的使用量。发散开来想，微信就是每次用0.5立方的水就要建立1000公里的输水管道（映射到移动业务是虚拟的信道，而非实际物理管道），而全村隔一会就有个人来打水或者这个人隔会就换个桶来接水，这样成天无数次的打水，无数次的管道建立，带来的就是一天几十块的水费，而建立的管道上百万公里了，性价比来说就不值得了。而普通的业务建立一次连接，占用时长较长，使用流量适当，这样就有建立管道的性价比可言了。
现在就是为了达成业务而浪费的建立资源过大，已经达到网络负荷风险，而实际使用的业务根本无法和消耗的资源相提并论，所以需要收费，以收费来适当抑制这种情况。
信令上的负荷，应只涉及到RNC、SGSN和GGSN。
但这是USIM卡通过认证后，假如是刚开机的话，还会涉及HLR，而终端上的信令交互，只跟RNC和SGSN有关。
核心侧网络涉及：SGSN/GGSN/HRL/VLR。主要是移动性管理GMM相关的信息，以及用户SM PDP CONTEXT维护跟踪。HLR/VLR主要是涉及MAP协议，用户标识、位置跟踪、鉴权认证。另外还有计费相关的单元参与。
“如果是不同运营商的手机微信用户进行语音业务,中间是否由Tencent企业负责接续?如果是,是否也象普通语音业务一样,从远端落地过网?”
这个部分倒是和IM企业没有任何关系，网络对于IT企业来讲都是透明的。IMApp只要注意自己的业务接续不出问题，网络的接续那是OP的事情。
这个部分倒是和IM企业没有任何关系，网络对于IT企业来讲都是透明的。IMApp只要注意自己的业务接续不出问题，网络的接续那是OP的事情。
我觉着本质上是通信协议栈不能适应移动互联网的需求， 以前有接触过一个 cross layer设计的思路，当时还只是paper， 不知道现状如何了。
先马克
Copyright © 1999-2024 C114 All Rights Reserved | 联系大家 | 沪ICP备12002291号 |
