物联网操作系统再思考-共享心跳中心机制（SHBC）

 

刚才发了该blog，不知为什么无影无踪了，难道包含敏感词？唉，重发一次看看。

最近微信很火，不是因为其强劲的约炮能力，也不是因为其简单易用的人性化界面，而是因为其强大的网络信令产生能力。中国移动、电信等运营商本来就对微信虎视眈眈，恨不得一巴掌拍死，正是因为微信的存在，使得运营商一个中秋节就能够收入几个亿的短信业务几乎灭绝。信令冲击这件事刚好给了运营商把柄，让运营商抓住了小辫子，此山是我开，此树是我载，既然占用了这么多信令流量，那么只好向你收买路钱了。

在这里我们不关注最终的博弈结果，只关注信令风暴这个技术问题，以及如何通过物联网操作系统来解决这个技术问题。实际上，所谓信令风暴，是对移动通信网络来说的。如果读者对移动通信网络的分组域不了解，则这个问题解释起来还真有点难度。实际上微信这个应用本身是不会直接产生移动通信网络的信令流量的，微信产生的是一些心跳（Heart Beat）报文。所谓心跳报文，是微信客户端跟服务器之间周期性的数据交互，目的在于维持微信状态信息的一致性，同时也确保消息能够及时的传达到接收方。微信的发送过程应该（之所以使用“应该”，是因为这是作者的猜测，并未经过实证）是这样的，微信发送方客户端把信息（文字、图片、录音等）发送给位于腾讯的微信服务器，信息中携带了接收方的微信ID。服务器则把信息暂存在缓冲区中，等待接收方主动过来取。如果接收方不主动来取信息，信息是不会发送到接收方的。因此为了确保信息能够实时收到，微信客户端软件必须周期性的，而且间隔非常短的去跟服务器交互信息，很重要的一个目的就是查看有没有自己的信息，即使没有消息到来也是这样。这个过程很容易理解，但有过软件系统设计经验的读者可能会提问，为什么不取消这种主动联系机制，而是改由服务器实时的推送消息呢？一旦服务器收到消息，只要根据微信ID，把消息推送给接收方的客户端就可以了，这样客户端只要被动等待，无需产生过多的心跳。但实现这个机制的前提是，服务器能够联系到客户端。而由于IPv4地址的缺乏，导致运营商网络中大量使用网络地址转换（NAT，一般部署在移动网络的GGSN等网元上）技术，使得服务器无法“看到”客户端的真实IP地址，因此无法把数据主动推送给客户端。这种情况下客户端定期主动轮询服务器就不可避免了，于是心跳产生了。

实际上客户端与服务器通过心跳保持联系，是很正常的机制，在固定网络里面大量应用，但为什么直到现在才产生问题呢？这是由于移动网络的工作机制引起的。为了节约无线频谱资源，手机终端在没有数据传输的时候，会自动把频谱资源释放掉，这就断开了手机跟无线网络之间的数据链接。这时候一旦上层应用（比如微信）请求发送数据（即心跳报文），手机的基带芯片会重新向网络发起请求，重新建立跟移动网络（基站/基站控制器、核心网等）之间的数据链接，然后再发送数据。显然，心跳机制和移动网络的频谱按需使用机制，综合导致了信令风暴的产生。因为手机终端请求建立网络链接，是一个复杂的过程，这个过程至少需要十条左右的信息交互（手机与网络之间，如果考虑移动网络中不同设备之间的消息交互，则加起来甚至可能超过百条），这种信息交互就是运营商所谓的网络信令。显然，一个心跳报文，会导致这么多的信令流量，那么积累下来，大量的心跳报文必然会产生数倍的信令流量，对网络造成的冲击是不言而喻的。在固定网络下是不存在这个问题的，因为一旦网线被接入就不会断开，这个过程无任何网络信令产生。但需要说明的是，这种信令机制在GPRS网络，即所谓的2.5G网络里才显得突出，到了3G时代，网络标准做了更改，这种由于心跳而导致的信令大大减少了。到了4G（LTE）时代，则基本上彻底消失了。

在固定网络中工作得很好的机制，到了移动网络，就成了“逗你玩”了。而且是小白羊逗大灰狼，本来就看你不顺眼，现在抓住把柄，刚好可以趁机把你收拾了。

但这跟物联网操作系统有什么关系呢？下面慢慢说来。

实际上这个心跳问题，微信表现出来的还仅仅是冰山一角。因为只有一个应用。设想如果手机上有十个与微信类似的应用，同时用户数量扩大100倍，那么运营商的网络早就奔溃了。但这种情况在未来的物联网时代是完全可能的。通过运营商的无线网络接进来的物联网智能终端，其数量会是现在移动用户的100倍以上。如果每个智能终端上都有这样一个或几个基于心跳的应用，则这些心跳机制对运营商网络将是巨大的挑战。即使网络完全基于LTE，数据链接（LTE中叫做缺省承载，default bearer）始终存在，但是由于心跳机制产生的数据流量（即纯粹的IP报文）也是一个天文数字。不但对运营商网络，对物联网应用的服务器来说也是一项巨大挑战。服务器要跟数以亿计的物联网终端联系，实时维系其状态，硬件和软件开销是巨大的。这有点大数据的味道，但这个大数据，大在终端的数量，而不是信息的数量。

基于物联网操作系统的共享心跳中心（Shared Heart Beat Center，后面简写为SHBC，希望读者不要理解为上海银行）解决方案，可以解决这个问题，而且可能会给不争气的运营商带来咸鱼翻身的机会。虽然作者对运营商动辄祭起收费大棒来耍垄断威风而心存不屑，但还是希望运营商能够重整旗鼓，再啸山林。毕竟作者从业在电信行业，一旦运营商蔫了，我们也就没有过冬的衣服了。

共享心跳中心大概是由两个核心模块组成：内嵌入物联网操作系统的SHBC代理和位于运营商核心网络的SHBC服务器，大概如下图所示：

SHBC代理是物联网操作系统的一部分，通过API的形式，提供给应用程序统一的接口，凡是希望通过心跳跟服务器保持联系的应用程序，都同一向SHBC代理注册，并向SHBC代理报告自身的状态就可以了。SHBC代理汇总整个操作系统上的所有应用程序的心跳需求，通过一份心跳报文，跟SHBC服务器进行联系。所有应用程序的状态信息，都通过这一份心跳报文，传达到SHBC服务器，并统一保存和维持。具体ISP或物联网服务商的应用服务器，则通过定义好的API接口，向SHBC服务器索取特定终端的状态信息。显然，这种机制解决了两个本质问题：

1、        在一台终端上有多个应用程序的情况下，这些应用程序共用一条心跳通道，无需每个应用程序都占用独立的心跳通道。这样就大大节约了网络资源，同时也降低了终端的资源消耗。据统计，软件心跳机制是影响智能手机的电池续航能力的重要因素之一；

2、        在超大量物联网终端的情况下，服务器端也无需亲自维护每个终端的状态信息，而只在需要时，向HSBC服务器索取即可。这样可大大节约ISP服务器的软硬件成本和软件复杂度。

对运营商来说，也有巨大的好处，甚至可以通过这个机制来改变行业格局，重新夺回行业桂冠的宝座。有了SHBC机制，运营商可以出台标准的SHBC代理和SHBC服务器API，供ISP和物联网服务提供商使用。这样运营商提供的服务就不仅仅是管道了，而是在管道基础上，又进一步提供了软件服务，而且这种软件服务又是最核心的软件机制，使得运营商对整个产业链的把控力度突然增加。不仅于此，通过开放HSBC服务器的API，运营商可向ISP或物联网服务商收费，来增加自身收入，这无形中又增加了一份额外的业务收入。

从经济学的角度讲，这样的结果也是一种优化的资源分配结果，属帕累托改进，利己但又不损人。在每个应用独立维护心跳的情况下，实际上ISP或物联网应用厂商的软件成本有两部分组成：功能软件部分和心跳机制部分。如果心跳机制由每个企业独立创建，整个社会付出的总成本是巨大的，且投资是重复的。但是若由运营商统一构筑，企业只需要给运营商缴纳少于独立构筑心跳机制成本的费用，就可得到相同或更高级别的服务，对企业显然是有利的。这对运营商来说也是有利的，毕竟产生的收入会远大于投入的成本，因为这种模式消除了重复建设。

构筑HSBC的关键还是物联网操作系统。毕竟SHBC的代理要植入操作系统中才能被应用程序调用，因此通过推出物联网操作系统，在此基础上进一步推出SHBC，是一种可行的方法。

结合以前的论述，运营商部署物联网操作系统的优势是很多的，SHBC为物联网操作系统的商业模式的成功又增加了一层砝码。