微信的信令风暴解决途径

readhere

  微信的信令风暴是微信收费的一个主要原因，而频密的心跳包是造成微信的信令风暴的直接因素。从技术上看，心跳包还是由于移动通信网络与互联网的寻址方式不同，不匹配。

   移动通信网络用电话号码，简称MSISDN，这是固定的；互联网通常采用动态的IP地址，每次业务过程都需要分配。微信等互联网应用为了摆脱移动通信网络，从而实现免费的目的，直接使用IP地址，而不是采用电话号码。互联网应用为了避免IP地址被释放，造成无法寻址，只好引入了心跳机制。   其实，移动终端在移动网络中的状态是明确的，可以被移动网络掌握的。互联网应用如果能与移动网络建立联系，通过电话号码寻址，心跳包就大可不必了。

具体操作方式是：
   终端发出的数据包对IP包头做一下修正，源地址改为MSISDN的低9位，而不是终端获得的IP地址。
   GGSN在发出数据包时，将源地址改为自己的地址池的IP地址，并建立MSISDN与IP地址的连接关系。
   GGSN在收到数据包后，根据MSISDN与IP地址的连接关系，将目的地址翻译为MSISDN的低9位，再寻址到终端。
   优点：
   无需为终端分配IP地址，简化建立过程，解决心跳包问题。
   缺点：
   需要翻译设备；有可能MSISDDN的低9位重复。

由于对核心网不是很了解，以上的想法是否只是空想，希望得到大家的指点。

  [4.23 修正]
    压缩MSISDN引起了一些争议，其实不用压缩MSISDN，也可以取消心跳机制，具体方法：
     1. 终端的APP激活后，把MSISDN发给微信服务器；
     2. 微信服务器遇到有消息要推送，直接向终端发送特殊格式的SMS，含推送消息的获取地址；
     3. APP收到特殊格式的SMS后，从后台向微信服务器取推送消息；
     4. APP显示推送消息。
   

kinghighland

终端耗电：
试想如果所有的APP都自己发状态/心跳，那手机得多费电，用不了几个小时就没电了。手机本身需要提供一个统一的SDK给所有的APP，集中发送心跳报文，据说iOS和android都提供了这个API，不确定这些APP是否采用了这个方案。

信道浪费：
QQ/微信等IM应用可不止是心跳，它们本来就其他应用不一样，而是所谓E2E业务，网络需要在发给你消息的时候能找到你，否则就得寻呼你。你要保持在线就得发心跳，发的频繁了浪费信道资源，发的不频繁可能带来大量TBF重建、浪费控制信道，发得再慢些可能网络又找不到你了就带来大量寻呼浪费寻呼信道。

现在普及了小包检测，把小报文集中到一个信道中来处理，这样可以解决业务信道的浪费。
长连接减少了心跳包，也就减少了TBF重建的开销，节约了控制信道。
而目前3分钟或N分钟的心跳，并不能保持网络随时能找到终端，因此IM下发消息尤其是群聊消息还是会带来可观的寻呼。这应该是小包检测加长连接之后的遗留问题吧。

zgx-07988

版主，微信的心跳和QQ的心跳是类似的吗？信令风暴中提到的信令负荷过大主要只的是无线空口信令资源吗(AGCH信道)?

enjoying007

微信 QQ的心跳包除了消耗空口信令资源，核心网资源是否也会频繁占用呢？每次心跳包都要PDP激活吗？

readhere

    压缩MSISDN引起了一些争议，其实不用压缩MSISDN，也可以取消心跳机制，具体方法：
     1. 终端的APP激活后，把MSISDN发给微信服务器；
     2. 微信服务器遇到有消息要推送，直接向终端发送特殊格式的SMS，含推送消息的获取地址；
     3. APP收到特殊格式的SMS后，从后台向微信服务器取推送消息；
     4. APP显示推送消息。
   

readhere

fordesign 发表于 2013-4-19 12:44
通过短信来激活PS的行为，短信也要寻呼和分配TCH，这也要占用CCCH吧？如果这个量太大，那么造成的冲击比维持 ...

  看得出对信令很了解，的确与主叫相比，被叫的信令消耗是要大一些的。不过，对于绝大多数微信用户而言，其实每天收到的推送信息量是非常有限的，比如我是不上10的。在这种情况下，发送频密的心跳包就显得极其浪费了。

cmcc_demon

很好的讨论帖，微信业务的普及对传统电信业务收入肯定会带来了影响。据统计分析表明，平时微信业务对##省(沿海)话音、短信、彩信的收入影响为损失30万元/日，针对微信等小流量业务频繁占用宝贵的无线资源，香港运营商与腾讯合作已推出针对微信的数据包服务的资费套餐^^

delperio

绝对好文！！！！！

wenliu

的确如果采用类似微信的半通话方式，这个获取的次数会很频繁。还是不实用啊。。

fordesign

通过短信来激活PS的行为，短信也要寻呼和分配TCH，这也要占用CCCH吧？如果这个量太大，那么造成的冲击比维持心跳对CCCH的冲击更大，那不是得不偿失？
具体分析：假设MS每次心跳的时候都在MM的STANDBY状态。
心跳模式:
   MS通过RACH申请上行TBF，通过AGCH得到TBI信息。剩下的信令和数据交互都在PDCH，不占用CCCH。服务器回心跳ACK建立下行TBF因为MS处于READY状态且已有上行TBF，将在PDCH上进行信令交互建立TBF，所以也不占用CCCH。心跳完成之后上行和下行TBF都在PDCH上进行信令交互。一次心跳消耗CCCH俩条信令。

SMS通知机制：
  首先MS因为不需要维持心跳，所以会主动断tcp，需要消耗俩条CCCH信令申请TBF完成四路挥手。
  SMS下行，需要消耗PCH一次，然后通过RACH和AGCH完成信道申请，取得短信。
  SMS通知应用，应用触发tcp连接，需要再通过RACH和AGCH再完成PS域的tcp连接和拉取消息。
  整个过程消耗CCCH7条。

所以如果通过sms通知应用的次数超过心跳次数的3.5倍，这么计算信令的消耗反而更多。
不知道这么计算是否正确。

wenliu

彩信还是比较落后的。虽然前面几天，彩信有个爆发量，因为当时即时通信软件还不够发达。用户分享图片，分享内容的需求还不像如今这样。但是这几年，QQ，微博，Facebook，twitter之类的推动，普通人习惯了去内容分享。因此以前的彩信业务模式已经落后了。或者来讲，大家已经不满足彩信这种点对点的内容分享方式了。

另外还是运营商自己，抱着语音通话和sms，完全满足利益收入，也没什么动力去推新的东西。好好一个飞信，要是能够整合好也不错。毕竟有先天的优势。可惜。

国外语音邮件用的比较多，电话留言什么的经常可以从电视，电影中看见，大家也习惯于这种模式。但是国内很少用语音邮件吧。

readhere

NMW 发表于 2013-4-18 15:49
这样就有点类似彩信的机制了，改push为pull方式，这样心跳消息都可以省了。另外，增加的sms消息可以为 ...

  没错，我想到SMS通知时，马上就联想到了彩信，只是我一直疑惑，为什么彩信这种方式没有发展起来？

fordesign

心跳的目的主要应该是为了防止tcp沉默太久被防火墙强行关闭。

wenliu

NMW 发表于 2013-4-18 15:49
这样就有点类似彩信的机制了，改push为pull方式，这样心跳消息都可以省了。另外，增加的sms消息可以为 ...

这个方式倒不错。。。不用sms来通知用户状态改变，而用sms来通知用户有网络侧的语音邮件。当然这个语音邮件可以被模糊成push talk。运营商可以在这个基础上推出新业务来和微信竞争。

NMW

readhere 发表于 2013-4-18 09:03
谢谢爱总转的文章，目前基本明确旧版QQ的心跳周期为30s，新版QQ为180s，微信为300s，Google原生应用为168 ...

相反地，我倒是建议腾讯把MSISDN以及微信用户间建立连接，通过SMS来通知微信用户的状态改变，这样可以节省心跳包。

这样就有点类似彩信的机制了，改push为pull方式，这样心跳消息都可以省了。另外，增加的sms消息可以为运营商带来一定的收入，是个比较接近双赢的办法。：）

wenliu

readhere 发表于 2013-4-18 09:03
谢谢爱总转的文章，目前基本明确旧版QQ的心跳周期为30s，新版QQ为180s，微信为300s，Google原生应用为168 ...

目前iphone 上的微信客户端上并没有出现用户即时状态。我觉得这是一个很好的用户体验，而且也是腾讯故意这么来做的，这个设计真是不错。腾讯设计的微信目的应该不是为了再推出一个和QQ类似的即时通信软件，而是瞄准了用户电话薄。
和QQ,MSN类似的即时通信软件不同，微信模糊了在线状态这个概念。没有让用户在使用微信的时候感觉到他们开了一个额外的客户端软件。自然而然的像以以前的手机call和短信来接收微信方面的push call 和 sms，所以它不引入即时状态的改变。就像一个用户电话薄体现给用户，用户可以使用微信这个电话薄来收取语音邮件和sms。这样用户的体验就无缝的从运营商手中转移到了微信手中。这也是运营商不待见微信的方面。

而且通过SMS来通知客户端来改变用户状态是不可行的。要知道你用户列表好友里有很多用户，而且状态迁移可能很频繁，如果每个都来改变一次或者集中来改变一次，对用户来说，体验只有变差。用户收到这种SMS并没有什么用。除非是后台微信和SMS之间绑定，而不展示在前台给用户获知。不过这还是要运营商，终端，来进行配合。但是这个一样不可行。

readhere

  谢谢爱总转的文章，目前基本明确旧版QQ的心跳周期为30s，新版QQ为180s，微信为300s，Google原生应用为1680s左右。

  心跳的目的我想也基本明确了，就是为了服务器可以及时Push信息。

  心跳的结果是服务器可以得到用户当前的IP地址，从而可以寻址到用户。当然，用户的IP地址并不需要维持不变，只需要有当前的IP地址。

  因此，前面的提法“互联网应用为了避免IP地址被释放，造成无法寻址，只好引入了心跳机制。”应该修改为   “互联网应用为了避免取不到用户的当前IP地址，造成无法寻址，只好引入了心跳机制。”

  关于MSISDN的寻址我再介绍一下，我的方案中并没有提供给腾讯，而是给GGSN。其实，微信的APP中已经采集了很多MSISDN了，运营商即使不想给，也控制不了。

  相反地，我倒是建议腾讯把MSISDN以及微信用户间建立连接，通过SMS来通知微信用户的状态改变，这样可以节省心跳包。

admin

fordesign 发表于 2013-4-17 11:36
微信引起的信令问题，我的理解主要是俩个，一个是MM状态切换造成的，一个是分配TBF造成的。
想请教一下版主 ...

发篇期刊论文的一部分供参考哈。摘自《QQ短数据业务对无线资源的需求及影响》，张柘宏、(河北移动通信有限公司唐山分公司）

（本文以上传到论坛城通网盘，下载地址：http://www.400gb.com/file/19313974。

2.1 CCCH资源分析

CCCH信道中主要有AGCH和PCH，AGCH用于手机的接入，而PCH是用于寻呼手机。所有PS的接入及寻呼均与CS共享信道。Immediate assignment（CS和PS），Immediate assignment eject（CS和PS）都是在AGCH上发射，而所有的CS和PS的paging group都是在PCH上发射。而且手机接入比寻呼优先级高，也即在AGCH不够的情况下，会占用更多的CCCH（相对而言PCH信道就少了）。

对CCCH资源的评估，主要是看是否出现immediate assignment（immediate assignment eject）信息丢失，以及是否出现寻呼丢失等。

2.3 AGCH丢失率

像手机QQ这样的短数据业务以及像WAP浏览等业务需要不断地发起channel request，使得网络需要不断地下发immediate assignment或者immediate eject信息，两类占据了大部分CCCH信道，因而导致寻呼信息的丢失。

2.4 PDCH资源分析

网络分配多少PDCH信道给发起申请的MS，主要取决于两个方面：

1）手机能力

当前大部分的手机支持下行4时隙的。手机的能力决定了手机上下行同时可拥有多少信道，也即影响数据业务的质量等。

2）PDCH资源

上表中（略）每个小时平均分配的PDCH大概在2300左右，则大概有288个载波在用作数据业务，占整个BSC的载波数的30%。

PDCH共享因子是指同一个PDCH同时可以承载多少个TBF，这个指标也是与小区信道资源以及参数设置有很大关系的。共享因子越大则肯定导致每个用户的速率要小。从BSC整体来看，EDGE下行信道的共享因子比较大，其他PDCH还是不高的。晚忙时比早忙时共享因子要大些。

CS抢占PS资源的情况表（略）：

上表中REEMPTPDCH为一个小时中PDCH被清空抢占的次数，而PREEMPTTBF则为一个小时中TBF由于essential PDCH被清空抢占而释放的次数。TSBS38的CS业务很高，较多小区存在CS拥塞，导致大量的PDCH被抢占，严重影响了PS的业务。

从短数据业务模型看，像手机QQ，虽然每次申请传输的数据量很小需要PDCH的时间也比较短，但由于用户的绝对数量很大而且信道申请的频率比较高，这就导致大量的PDCH的信道申请。

3 短数据业务对资源的占用分析

手机QQ业务是典型的短数据业务，每次发送或者接收的信息一般为0.2KB左右，但是每一次的发起或者接收信息都是一次完成的信道申请以及分配过程。而且手机QQ还有一个很重要的方面，这就是QQ的“心跳”（系统自动刷新），目前版本的QQ心跳时间为3m，而以前版本的QQ心跳时间则为30s。TSBS38区域使用手机QQ的用户就占到了总户的40%左右，这个用户群体对数据业务网络是至关重要的。

从Gb口的数据分析我们得到一个小时内手机QQ用户平均上线时间约为8分钟。我们可以估计出一个手机QQ用户申请数据业务信道的量。因而我们这里只能得出一个大概的手机QQ用户模型，根据手机QQ的模拟测试情况，我们假设一下的手机QQ使用模型如下：

每分钟发送/接收两条消息；

每次登陆手机QQ，平均接收8条系统消息（包括登陆QQ后的信息更新，QQ广告，QQ通知等等）；系统主动刷新周期：新版QQ 3m，旧版30s，其他一些消息如群消息，好友上线消息等等。

以手机QQ使用模型来分析对CCCH以及PDCH资源的需求。

1）CCCH

一个小时内一个MS占用immediate assignment（或者immediate assignment eject）数量为：

新版QQ：2*8+2*8+8+8/3 =43条

旧版QQ：2*8+2*8+8+8*60/30=56条

我们假设新版QQ和旧版QQ用户比例各占50%：

那么BSC38的手机QQ用户（平均每小时为13146个用户）占用的immediate assignment（或者immediate assignment eject）为：13146*50%*43+13146*50%*56=650727条，占总立即分配信息（CS和PS）的39.6%，而占PS立即分配信息的51.8%。

而像手机QQ用户最多的TSG011B小区晚忙时用户为660左右，此小区的手机QQ的立即分配信息量为：660*50%*39+660*50%*52=32670条，占总立即分配消息（CS+PS）的36.1%，而占PS理解分配消息的49.6%。

手机QQ业务带来的大量立即指派信息占据了大量的CCCH资源，导致了一些小区出现寻呼丢失以及AGCH的丢失。

2）PDCH

当前大部分的手机按下行3时隙来计算，当前网络的时隙满足率约为72%。下面我们就按照上面提出的手机QQ模型计算对PDCH的占用。

新版QQ：2*8*3+2*8*2.5+8*2.5+8/3*3=118s。

旧版QQ：2*8*3+2*8*2.5+8*2.5+8*60/30*3=158s。

一小时内手机QQ平均上线时间为8分钟，而其中每一个手机QQ用户在8分钟的上线时间中，占用3个下行时隙的时间：新版QQ为108s，旧版QQ为148s。

按TSBS38的平均PDCH共享因子2.85来计算的话，BSC区域的总手机QQ用户（13146）就需要很大量的PDCH资源。一些小区（如TSG011B）数据业务用户很多以及加上本身资源的不足，使得PDCH的共享因子达到7、8甚至超过10。

4 总结：

从上面的分析，可以得出下面几个观点:
    1)由于现在数据业务中，类似手机QQ的短数据业务占大部分，这种短数据业务因不断地发起信道申请而大量增加了CCCH的负荷，在一些高校周边小区CCCH出现过载，并导致寻呼以及立即分配的丢失;根据用户的数量以及基本的用户行为模型可以计算出立即分配消息的需求量，再加上CS业务的立即分配消息，就能算出各个小区的立即分配信息量，并结合寻
呼信息量，就可以估算出CCCH的负荷。
    2)对于高校周边的小区，规划上应考虑到CCCH的负荷，可以通过调整小区搜盖范围合理化idle mode用户的驻留:当然也评估寻呼信息量(如LAC里话务过高则需考虑LAC的重新评估规划)以及寻呼策略(LAC寻呼和Global寻呼方式).
    对于PDCH的需求规划，可以从现网络的各项统计(PDCH共享因子，PDCH分配数It, TBF建立成功率，IP层数率以及CS抢占PS资源等)来分析资源现状，并结合区域内各种类型的用户分布以及发展情况，给信道资源给出一定的余量来满足对PDCH信道的需求。