谈谈信令风暴

因为近期移动和腾讯就微信收费的问题争吵,夹杂大量“不明真相”的big mouth。将电信运营商就基础设施向互联网运营商收费的问题,无厘头地作为电信运营商向用户收费而破口大骂。信令风暴的问题在去年開始有接触,影响不是一般的大,对于扩容,有60%是因为信令过载引起的,全部也想整理一下各方材料。信令风暴与空口有关,而有人在微博上却以为是承载在IP上的互联网消息,而迫不及待地开骂。

终端在休眠时,触发向发送数据(如心跳消息发送,有如微博消息提醒的定期向server查询),须要主叫连接建立。分组控制功能块(Packet Control Function,PCF)主要作为射频部分与分组网络(IP网络)间的接口。

终端在休眠时,假设服务器向它推送数据(如push,即业务在IP上的建立TCP长连接实施server à client推送消息,注意IP层是PSDN后面的事情了),须要被叫连接建立。

由此可见:

1、 假设连接处于休眠,不管是终端主动发送,还收被动接收,应须要进行进行空口信令的协商以进行激活;

2、 被动接收比主动发送须要的交换的空口信令多。寻呼过程中的容量表现为寻呼容量,接入过程中的前向信令容量容量表征为控制信道容量,接入过程中的发现信令容量有反向接入容量表征。而眼下的载扇的首要瓶颈在寻呼容量(寻呼容量小于控制信令容量和反向接容量)。假设容量不足必须进行扩容,否则会出现寻呼受阻。

微博业务是查询类业务,为主叫连接。微信类业务是双向业务,为主叫连接和被叫连接。手机上有不同应用,不同业务之间的心跳/轮询的发送时间不一致,push时间也不一致,假设同一时候Andriod后台执行若干应用,则累加的信令很可观。而微信触发激活的频率特别高,特别消耗空口信令。

问题的关键在于:为什么终端会出现休眠,而导致不断进行空口连接激活?

导致休眠有两个方面:

一、 智能终端系统通过高速休眠(Fast Dormancy)的方式实施节能省电,提高电池续航能力。以下资料来自未经验证的网络资料:Android智能手机频繁休眠所带来的信令是普通手机是否频率的7.5倍[1]。也有某些资料说是10倍。详细的Android和iOS系统进入休眠的时间查不到,能查到的仅仅是主进程堵塞的时间,大致是5秒,不清楚两者是否关联?

当智能手机在短期内不使用时,它们将进入空暇状态。当用户须要使用时,须要和网络进行信令交换来唤醒手机。为了省电,高速休眠支持智能手机高速回到省电空暇状态。详细时间多长,没有查到,可是程序须要对应用户的操作,最要能在200ms(0.2s)之内,假设超过5秒没有反应,ActivityManager会没有提示就kill了activity进程,激活须要又一次onCreate(),因此对于长时间操作,须要採用后台程序。

写过程序的都知道,要让程序对用户输入响应及时,避免程序在某个操作时僵死的情况,那就要把耗时操作放到后台去做,然后通过异步的通知或者回调来接着流程往下走。否则的话耗时操作会把主线程堵塞,导致程序非常长时间不回到主事件循环。这 在移动平台上尤其重要,一般移动平台上系统都会有一个专门的检查机制,看程序有没有非常长时间被堵塞住,没有回来检查主消息队列。发现这样的情况一般都是把程 序作为“无响应”干掉。iOS普通情况下是10秒为上限。10秒内程序没有回到主消息循环就被干掉。在前台后台切换时更严格,大概是5秒左右。[2]

二、运营商基站,假设连接长时间不用,也会将资源释放出来。依据资料[3]:中移动的 2.5G 网络为例,经过粗略測试,大约 5 分钟左右的基带空暇,连接就会被释放,这就是为什么微信 Android 版本号选择以“5 分钟”为周期发送连接心跳。

导致不断激活也有两个方面:

一、 应用是怎样实施心跳/轮询机制。依据资料[4],微信具有:1)单次传输的数据量较小; 2)接入和释放频次较高;;3)在线时间长但传送数据的时间非常短;;4)上下行传输的数据量较为对称。具有典型的信令风暴业务的特点。

二、 有没有可能多个应用同步实时心跳,这样空口信令就可大量节省。

中国移动和腾讯的矛盾在于用户为移动流量进行的支付,可是业务的空口信令资源,也即微信所依赖的基础建设所有由运营商支付,而作为微信业务的主要盈利者腾讯公司没有提供一分钱的基础建设费用。中移动方面提供的统计数据显示,微信已经占用了中移动60%的信令资源,但只带来了10%的移动数据流量[5]。正如电信行业的资深专家韦乐平所说:产业链关系失衡,建网者赔钱(利润非常低),应用商赚钱(利润高速增长),利益相上层互联网应用上转移,底层电信运营商边缘化、低值化。韦总还说:基于IP承载层设计的移动互联网业务应用与基于集中调度的移动网是天然不匹配的,基于IP层平等理念的业务应用开发导致了大量网络容量和信令资源的浪费,但互联网和移动网这两边谁也动不了。这话非常精彩,移动基站要集中调度,反复地利用频谱资源,而平铺的互联网并不考虑这些。而在电信基础建设运营商向互联网运营商收费补贴基础建设的博弈中,有一拨人有意无意地误导为向用户收费进行煽动,而一些自觉得懂点IT就是,会点编程,就觉得懂电信通信的人在起哄,只能说明运营商在已经沦为弱势群体。

为何公布这种感叹,有些以学富五车自居的如 @李开复 就发出了如此不懂技术并极具误导的微博,我分几条微博评论道:实际刚好和不学无术的 @李开复 所说相反,为了避免QQ和微信造成基站的信令风暴,应该避免要使用这类互联网服务,以保障基站有足够容量可以为真正有须要的服务,尽量使用短信,少使用语音,不要使用QQ/微信。@李开复 将这条删了,虽信口开河,但知错能改。但我仍极不喜欢他。他的big mouth常常不负责任,被称人生误导师,是有道理的。



[1] http://www.gsta.com/news/15006.html

[2] http://www.cnblogs.com/linyawen/archive/2012/07/24/2606709.html

[3] http://www.alibuybuy.com/posts/81071.html

[4] http://www.weste.net/2013/4-7/90227.html

[5] http://jingji.cntv.cn/2013/04/05/VIDE1365097318724308.shtml

时间: 2024-12-15 07:09:31

谈谈信令风暴的相关文章

我的产业生态链和杂谈文章

3G通信技术篇 随笔:关于AT命令 2014.8.26 CDMA学习笔记(一):历史和基本概况 谈谈信令风暴 2013.4.25 系统平台篇 VisionMobile:VisionMobile:iOS8–Apple隐藏的议程 2014.6.13 VisionMobile:应用从4到4000:汽车行业是曾相识的颠覆 2014.4.15 [笔记]Google对Android的控制 2014.4.4 Android应用生态系统的控制 2014.4.1 VisionMobile:剥光Android 20

12.切换分类-实际信令-切换带优化定义

切换分类 实际信令 站内UE跟踪 X2和S1在基站跟踪 以上都是从基站侧跟踪的 切换带 过大(乒乓切换),过小(掉话),信令风暴 路损模型算出来的距离 过渡区:都满足切换的条件,如大于2db余量 切换执行区:保证切换时延 保护区域:切换后,一定db内防止再切换,如2db 实际:与门限配置一起.通过实际测量感受,切换带与时延. 原文地址:https://www.cnblogs.com/sec875/p/11802881.html

【netty】Netty系列之Netty百万级推送服务设计要点

1. 背景 1.1. 话题来源 最近很多从事移动互联网和物联网开发的同学给我发邮件或者微博私信我,咨询推送服务相关的问题.问题五花八门,在帮助大家答疑解惑的过程中,我也对问题进行了总结,大概可以归纳为如下几类: Netty是否可以做推送服务器? 如果使用Netty开发推送服务,一个服务器最多可以支撑多少个客户端? 使用Netty开发推送服务遇到的各种技术问题. 由于咨询者众多,关注点也比较集中,我希望通过本文的案例分析和对推送服务设计要点的总结,帮助大家在实际工作中少走弯路. 1.2. 推送服务

创业者谨记:与这五个部门打交道要小心(要知错就改,或积极解释,或示弱,或求被监管,或变通,就是千万别对着干)

创业者谨记:与这五个部门打交道要小心 2015年01月29日11:43  <创业家>杂志     收藏本文 刚出来的消息,淘宝因为抽查一事要投诉国家工商总局,乱了乱了. 1月23日,国家工商总局发布网络交易商品定向监测报告,结果显示淘宝正品率最低,为37.25%.4天后,淘宝发文表示不满,称相关司司长刘红亮“吹黑哨”,有着“神一样的逻辑”.昨日下午,工商局召开新闻发布会,网络商品交易监管司副司长杨洪丰对此作出回应,称委托第三方抽检目的是找问题,而不是为了反应网购领域质量有多差,不能过度解读.

Netty系列之Netty百万级推送服务设计要点

原文:http://www.infoq.com/cn/articles/netty-million-level-push-service-design-points 1. 背景 1.1. 话题来源 最近很多从事移动互联网和物联网开发的同学给我发邮件或者微博私信我,咨询推送服务相关的问题.问题五花八门,在帮助大家答疑解惑的过程中,我也对问题进行了总结,大概可以归纳为如下几类: Netty是否可以做推送服务器? 如果使用Netty开发推送服务,一个服务器最多可以支撑多少个客户端? 使用Netty开发

互联网推送服务原理:长连接+心跳机制(MQTT协议)

互联网推送消息的方式很常见,特别是移动互联网上,手机每天都能收到好多推送消息,经过研究发现,这些推送服务的原理都是维护一个长连接(要不不可能达到实时效果),但普通的socket连接对服务器的消耗太大了,所以才会出现像MQTT这种轻量级低消耗的协议来维护长连接,那么要如何维护长连接呢: 在写之前,我们首先了解一下为什么Android维护长连接需要心跳机制,首先我们知道,维护任何一个长连接都需要心跳机制,客户端发送一个心跳给 服务器,服务器给客户端一个心跳应答,这样就形成客户端服务器的一次完整的握手

移动互联网消息推送原理:长连接+心跳机制(MQTT协议)

互联网推送消息的方式很常见,特别是移动互联网上,手机每天都能收到好多推送消息,经过研究发现,这些推送服务的原理都是维护一个长连接(要不不可能达到实时效果),但普通的socket连接对服务器的消耗太大了,所以才会出现像MQTT这种轻量级低消耗的协议来维护长连接,那么要如何维护长连接呢: 在写之前,我们首先了解一下为什么Android维护长连接需要心跳机制,首先我们知道,维护任何一个长连接都需要心跳机制,客户端发送一个心跳给 服务器,服务器给客户端一个心跳应答,这样就形成客户端服务器的一次完整的握手

微信收费事件背后被广泛忽略的技术细节

作为一个横跨通信与互联网两大行业的从业者,前四年的核心网经验和后五年的互联网经验让我不得不感慨一个非常遗憾的现实:通信与互联网两大行业本来可以有珠联璧合的技术协同,为移动互联网提供近乎零耗电零流量的PUSH机制,但由于两个行业之间长期以来的价值观隔阂和互防心态,导致如今的手机PUSH技术不仅为用户增加了显著的电量消耗,还对移动运营商的基础设施造成了完全不必要的信令压力.微信与运营商的纷争正是这种冲突集中爆发的结果. 看到不少来自两个行业的专业分析,通信行业的专家谴责微信过于频繁的心跳和短包导致"

Netty系列之Netty百万级推送服务设计要点(转)

1. 背景 1.1. 话题来源 最近很多从事移动互联网和物联网开发的同学给我发邮件或者微博私信我,咨询推送服务相关的问题.问题五花八门,在帮助大家答疑解惑的过程中,我也对问题进行了总结,大概可以归纳为如下几类: Netty是否可以做推送服务器? 如果使用Netty开发推送服务,一个服务器最多可以支撑多少个客户端? 使用Netty开发推送服务遇到的各种技术问题. 由于咨询者众多,关注点也比较集中,我希望通过本文的案例分析和对推送服务设计要点的总结,帮助大家在实际工作中少走弯路. 1.2. 推送服务