微信的信令风暴解决途径

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显示推送消息。
   

admin

tom老师太谦虚了。很好的主意啊。我也结合个人理解，说下实施起来的难度吧。

1 修改IP包头为MSISDN地址，牵扯太大。毕竟IP包头中只有源IP和目的IP，分别是32bit，和MSISDN不兼容。如果要修改则需要修改IP规范，阻力太大。

2 手机中没有MSISDN地址，MSISDN是存放在HLR并下发到SGSN中的，手机上只有IMSI。

3 手机如果没有网络侧分配的IP地址，则网络侧（GGSN以及Gi网络后面的路由器）无法为手机提供路由。那手机都没有办法访问腾讯服务器了。

4 手机侧的IP地址，只要手机不发起PDP去激活流程，一般网络侧是不会主动发起PDP激活然后释放的（有超时时间，但timer很长，比如30分钟，远比心跳间隔要短）。所以，微信服务器发心跳包主要不是为了保持IP地址不变，主要的作用应该是让服务器了解到用户当前的状态是什么（比如在线、隐身、离开），从而决定是否要继续点亮你的头像，让其他用户也能知道你的状态。（因为如果手机如果不发任何消息，那微信服务器肯定不知道手机现在是什么情况的，所以要心跳）。

另外，从技术手段上来讲，为了减少微信的信令风暴问题，一方面运营商可能会和腾讯商谈，延长心跳的间隔时间。另外，在SGSN上将ready timer时间从默认44秒调大一些（很多地方都调大了），这样可以防止手机MM状态特别快地切换到Standby从而带来大量的寻呼。

另一方面，运营商如果要打压微信，技术上是完全可行的（根本用不着收费），只需要在分配无线信道资源的时候将微信这种业务监测出来少分配一点，将下行速率限制到1k以下，那肯定就没人愿意用微信了。技术上实现这一点完全没问题，但有社会问题，会引起公愤。运营商应该还不敢。

个人理解哈。

fordesign

微信引起的信令问题，我的理解主要是俩个，一个是MM状态切换造成的，一个是分配TBF造成的。
想请教一下版主
1.有没有办法知道这俩个切换造成的信令消耗的量？
2. 这俩个切换的信令是否都走的CCCH? 我的理解是CCCH拥堵才会影响CS域，才会引起运营商的不满。

readhere

  现在“微信”事件是热点，众说纷纭，正是发出技术人声音的时候。在核心网的领域，的确还是要向大伙多请教。

1. 关于MSISDN，在SIM卡里有，手机应该可以读到。

2. 我已经考虑了一种方法，将MSISDN压缩到32比特，这样就可以借用IPV4的地址了。

3. 我最近才用微信，还不是很熟。微信中能设状态是什么（比如在线、隐身、离开）吗？我认为微信中的心跳包主要是告诉腾讯自己的IP地址，这样一旦微信服务器有最新的信息，可以推送下来。http://tech.sina.com.cn/i/csj/2013-04-16/09368244003.shtml提到了5分钟的周期。

wenliu

手机终端上的微信版本还暂时未引入即时状态的表述。
但是也并不认为微信心跳包目的是为了告诉腾讯自己的IP地址。虽然UE 的IP地址在心跳过程中，可以被腾讯服务器获知，但是对于腾讯来讲，这个目的是主要借此向腾讯服务器通知了当前UE 对于微信的可接受状态。

但是通过MSISDN来实现IP的方式，这不大可能实现。
1. 毕竟MSISDN目前还是运营商和终端用户的资源，运营商已经开始反感微信在业务层面上抢夺用户，怎么可能在IP接入层再去配合腾讯。除非腾讯分钱。（不过即使这样，估计运营商也不干)
2. 另外也要考虑终端用户，可能部分人比较反感腾讯通过手机薄里的电话号码来搜寻好友，这对个人隐私是个泄露。
3. 通过MSISDN来压缩32比特，这个方式也需要终端的支持，除非腾讯出自己的自定机。


这个问题还是归结在移动网络中的用户移动管理状态如何传递给互联网侧的应用服务器。或者，也可以通过HLR or HSS or SGSN 通过接口消息来通知应用服务器，这样用户的接入情况直接和应用服务器进行了同步。。。这个移动性管理状态的更新应该比采用IP心跳方式更好吧。。不过按照目前的情况，运营商不会开放这块。

NMW

我觉得关键点还是要先弄清楚以下问题：

1. 微信为何要发心跳信息？能否取消心跳？
2. 如果必须发的话，间隔是多少？能否延长？

如果发心跳信息只是告知微信服务器UE的地址，问题还是好解决的。

readhere

  to wenliu:
   MSISDN寻址是移动网络原生的方式，如果微信等互联网应用能采用，无疑是多赢的结果，运营商不应该反对，难道他们希望自己的网络拥塞？

  to NMW：
    心跳是为了能及时push消息，取消心跳后，微信服务器无法push消息。新浪微博等也是这样设计的。
    据称目前心跳为5分钟一次，如果延长，终端进入idle后，反复激活可能开销更大。

wenliu

readhere 发表于 2013-4-17 20:40
to wenliu:
   MSISDN寻址是移动网络原生的方式，如果微信等互联网应用能采用，无疑是多赢的结果，运营商 ...

不过目前并没有达到多赢的结果。毕竟微信的出现，对于运营商语音和短信的冲击太大。原本这两块是旱涝保收的业务收费，现在却被微信抢走，运营商只在当中收取当业务出现时候才占用的流量费。心跳这点流量收不到太多的费用。
运营商为互联网铺好了路，只能收高速公路的费用，上层应用已经和运营商们无关。

这对于从依靠语音和短信转变从数据流量的收费，运营商肯定不乐意。毕竟它只能充当了高速公路的收费站，而用户被互联网应用培养出来的数据需求，逼迫运营商们花费巨资去提升网络的质量，却找不回以前语音和SMS时候那种唯我独尊的地位。

并且对于运营商来讲，手中掌握的MSISDN资源其实应该比QQ号码这种更为值钱，因为一个活跃的MSISDN号码，必定标示一个活跃的用户，必然会带来稳定的收益。但是微信或者QQ号码不行，微信和QQ还是基于免费的模式。 运营商当然不愿意将这块号码资源无偿的分享给互联网应用，让互联网再去挖掘它们的价值。。。（要弄，它也想能自己来挖掘这块资源。虽然事实证明，运营商没这个能力来丰富电信网中的应用。。）

admin

readhere 发表于 2013-4-17 20:40
to wenliu:
   MSISDN寻址是移动网络原生的方式，如果微信等互联网应用能采用，无疑是多赢的结果，运营商 ...

Tom老师，首先我更正下，手机里确实是有MSISDN的，只不过附着的时候是用IMSI通常。感谢指出问题。另外，针对MSISDN寻址感觉技术上应该还是可行的，最大的阻力应该还是产业链从business的角度。因为这个需要终端厂家的支持。不是移动运营商说了算的。比如中国移动绞尽脑汁都无法说动几家终端厂商生产支持TD-SCDMA的手机，而要说服这些厂家做一个目前没有规范支撑的使用MSISDN寻址的手机出来，无疑难度更大。

你提到的5分钟超时时间，这个应该不是指无线空口资源释放的时间，因为肯定没那么长，不会是分钟级的。那就只有可能是pdp上下文的idle timer了。这个设置一般在GGSN中设置，默认值都是30分钟或以上。如果超时后，GGSN将发起PDP上下文去激活流程，手机的IP地址就会被回收了。所以应该不是用心跳解决IP地址回收的问题。后面有一个QQ登陆的流程供参考。（微信实际上是QQ的升级版，心跳原理和QQ差不多，只不过是多了个通讯录添加好友的功能。但这个是最要运营商命的功能。所以这是为什么QQ其实也有视频还有语音通话功能，但运营商只说向微信收费，而没听说向QQ收费的原因之一）

另外，我找了一些资料，这里做一个汇总吧，不过找的资料比较多，这里只好粘贴一些重要的文字，等抽空我再发全文帖出来。

1 摘自《小流量长在线业务对Ev-DO网络的影响及优化》中国电信股份有限公司广东研究院，何晓明、贾曼、刘志华：

小流量长在线业务大体分为两类：人与人通信及机器与机器通信（M2M）。目前国内人与人通信的小流量长在线应用软件主要以QQ、微信、微博为代表。根据统计，校园学生中手机QQ和微信的渗透率达到70%以上，而普通用户中参与QQ应用的用户占比也达到30%左右。特点是：

1）在线时间长

对于M2M应用,因不同业务的应用场景不同,业务在线时间也不尽相同,但总体在线时间较长。如在电力抄表
应用中，电力公司为了实时了解电力抄表系统的工作状态，要求抄表终端24h在线，环境监测系统也要求全天候上报监测点的温度和湿度情况，公交或出租车的车载终端GPS定位业务每天在线时长至少为10h。在手机IM应用中虽然不同个体间存在使用习惯的差异性，但运营商普遍采用的按流量计费方式使得大多数用户的平均在线时间超过8h。

2）流量小

不同于上网下载这类大流量突发业务，大多数小流量长在线业务具有小流量突发特点，即每次连接传输的数据量都很小。根据现场测试数据，车载终端GPS定位业务每次连接的前、反向数据量为800~860 byte，前、反向速率均小于4.8kbps，手机QQ每次连接的前、反向数据量为500~600字节，前、反向速率大部分接近3kbps。

3）连接次数高

对于车载终端GPS定位业务，需要实时了解车辆的轨迹和行踪，可根据车速情况调整GPRS数据发送频度，若按平均每分钟上报一次数据计算，每小时建立的空口连接数约为60次；对于手机QQ业务，消息的发送频次取决于应用场景，根据华为公司智能终端实验室得到的长期测试数据可以得出，QQ用户每小时建立的空口连接数平均约为80次。在主流的IM软件中，由于国内使用QQ应用的用户渗透率最高，如此频繁的空口连接和释放对无线网络是一个挑战。

4）心跳周期短

为保持业务长时在线，大多数客户端软件都具有心跳机制，如较早版本的QQ客户端心跳周期为30s。

5）前、反向链路的占空比低

由于小流量长在线业务具有较强的间隙性传输数据的特点，一个小的突发数据过后，要经过一个较长的时间间隔才传送下一个突发数据。因此，根据现场测试数据可以得出，车载终端及手机IM应用大部分连接的占空比都低于20%。也就是说，终端在提供小流量在线业务的时候，大部分时间处在休眠状态，只有小部分时间在发送或接收数据。

下面以QQ业务流程为例，说明消息在QQ客户端和QQ应用服务器之间的交互过程。QQ业务流程包括：客户端登陆/退出、心跳消息的周期性发送、聊天消息和系统消息传递，如图1所示。QQ业务客户端在QQ服务器成功登陆后，才能进行聊天消息和系统消息的传递。聊天消息由客户端发送到服务器，再由QQ服务器下发到目标客户端；系统消息包括好友的上/下线通知和系统推送通知如广告等，由QQ服务器端发起，发送到QQ客户端。

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信道的需求。

readhere

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

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

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

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

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

  相反地，我倒是建议腾讯把MSISDN以及微信用户间建立连接，通过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之间绑定，而不展示在前台给用户获知。不过这还是要运营商，终端，来进行配合。但是这个一样不可行。

NMW

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

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

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

wenliu

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

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

fordesign

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

readhere

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

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

wenliu

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

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

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

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倍，这么计算信令的消耗反而更多。
不知道这么计算是否正确。