物联网操作系统再思考-Hello China操作系统的运营商网络协同机制
Hello China定位为物联网操作系统，在我们以前关于物联网操作系统的系列描述文章中，已经总结出物联网操作系统区别于其它操作系统的两大核心机制：物联网相关的特性支持和运营商网络的紧密协同。所谓物联网相关的特性支持，指的是操作系统内嵌诸如NFC、GPS、Zigbee等物联网通信机制的支持，以及自愈能力、低功耗等非功能性机制。这些机制很容易理解，也是当前其它一些物联网操作系统的主要开发方向。但对于后者-运营商网络协同机制，在前面的描述中涉及得不多，现通过这篇文章进行补全。实际上并不是描述不足，而是因为运营商网络协同机制是新提出的一个概念，尚不为大众所熟悉。在前面的物联网操作系统系列文章中，运营商网络协同机制反而描述得更多一些。
运营商网络协同机制体系架构
所谓协同（英文叫做Collaboration），我个人认为，至少是两个以上的人或者系统能够相互发现对方的不足，并能够发挥自身特长，步调一致的进行工作，弥补对方不足，达到“1+1>2”的效果。因此，物联网操作系统与运营商网络的协同，本质上是这两个系统-物联网操作系统和运营商网络-之间的有效协调、取长补短的机制。只有任意一方而另一方不存在，是无法协同的，必须双方都存在，且有效配合。下面是Hello China操作系统与运营商网络协同的技术架构：
其中，HCN Server（Hello China服务器）是与运营商网络有效协同的关键组件，这是一个软件模块，运行在运营商机房的服务器上。运行Hello China操作系统的终端，通过运营商的无线或有线网络，接受HCNServer的管理和协调，同时可以根据需要，把终端的一些状态数据上报给HCN Server。需要说明的是，这种管理和被管理的关系，是可选择的配置。如果Hello China终端的所有权不是运营商，那么终端所有者可以选择不跟HCNServer有任何互动。这是通过定制选项或动态配置做到的，千万不要产生物联网终端受HCN Server严格控制的错觉。
HCN Server跟运营商的网络系统有相应接口，比如跟Policy Server（专业名词可能叫做PCRF）之间有Rx接口，通过这个接口，可以为特定终端定制特定的服务，比如限制网络带宽和流量等。跟运营商的短信中心也可以存在接口，比如对中国移动来说，HCN Server通过CMPP接口跟短信中心的Gateway连接，完成短信发送和接收功能。当然，最重要的接口，还是HCN Server与物联网服务商或者企业的接口。企业可以通过HCN Server，实时的获取终端状态、终端收集的数据等信息，而无需直接跟终端打交道。毕竟通过一个固定的接口获取所有终端信息，比一个一个的轮训终端，效率要高得多。当然，如果企业不愿意自己的终端接受HCN Server的管理，完全可以自己控制终端，从终端上收集数据等。
上述图中有一些通信行业的专业名词，比如SMSC，BSS/OSS，Rx等。如果您不了解这些词汇或系统的含义，也不影响对下面的内容的理解。下面就以上述结构为基础，列举一些协同机制，这些机制能够让运营商和物联网服务商真正受益。这里的前提是，物联网终端（即Hello China终端）归物联网服务商所有，物联网服务商与运营商签订协议，使用运营商的基础网络，同时使用HCN Server提供的服务。
协同机制之一：通过SHBC机制落实金管道服务
最直接的一个协同机制，就是通过共享心跳中心机制（SHBC，详细请参考以前的物联网操作系统系列文章，连接：http://blog.csdn.net/hellochina15/article/details/8798342），实现真正的物联网金管道服务。当前很多运营商推出了面向物联网应用的金管道服务，其实就是给物联网企业的终端安装一个体积更小的SIM卡，使物联网终端可以通过2G/3G等无线网络跟企业通信。与个人通信不同的是，运营商的网络部件（比如MSC/HLR/xGSN等）会监控这些特定用途的SIM卡，记录其网络访问情况。这样在发生问题的时候，比如数据报不上来，就可以查阅相关记录数据，判断故障是由运营商网络导致，还是终端自身的问题。显然，这种做法的逻辑是，把整个通信路径隔离成几段，比如终端系统本身一段，终端到基站这一段无线连接，基站到企业这一段有线连接等。当前运营商提供的机制，从理论上说，只能监控到基站到企业这一段有线连接，其它两段是无法顾及的，而且这也只是从理论上说，实际上就连这一段，也是无法监控的。这种做法根本无法解决问题，是一种“伪金管道”。从哲学意义上说，把整体进行割裂、非此即彼的逻辑也是有问题的。但是通过引入物联网操作系统和对应的服务器，就可以从根本上解决这个问题。很简单，物联网操作系统内置SHBC线程，这个线程周期性的跟HCN Server进行交互，一旦HCN Server在一段既定的时间内没有收到某个终端的心跳报文，就认为这个终端出了问题，从而通过上图中的SOP接口向企业发起告警。得到告警后，物联网企业就可以有针对性的处理了。同时，在Hello China终端上，SHBC线程也会记录这种异常事件，供以后追溯。这种解决方案把整个网络连接统一对待，没有做任何区分。对于问题定界（确认问题是由于运营商网络导致，还是终端硬件导致），可以通过分析Hello China记录的本地日志来确认，相信在大多数情况下，都是能够分清的。
这只是SHBC机制的一部分功能，另外的功能，比如应用程序保活功能、心跳合并功能等，都可在Hello China和HCN Server上实现，从而降低运营商网络的负担。
这些机制的好处是显而易见的，对运营商来说，做到了真正的金管道服务，会取得物联网应用企业的信任，会吸引更多的终端接入网络。要知道每个终端就是一个用户，用户渗透率（运营商用户数占总电信用户数的比率）是运营商追求的核心经营指标之一。对企业来说，通过金管道服务，可以实时准确的了解终端工作情况，必要时做出紧急响应，避免问题发生。同时这种机制也便于企业和运营商之间的责任澄清。
协同机制之二：通过Policy Agent和延迟传输服务提升网络使用效率，降低企业成本
据行业忽悠，未来物联网对运营商开放的市场空间，是当前运营商市场空间的500倍。保守起见，我们把这个数字降低100倍，即物联网市场空间是当前运营商市场空间的5倍。这就意味着运营商的用户数要翻五翻。当前一个微信业务，就把运营商网络搞得鸡飞狗跳的情况下，可以想象5倍现网用户的情况下，运营商的网络将是多么不堪一击。举例来说，假设一个千万人口的大城市（这在中国很正常），全部实现了远程用电抄表功能，在月底的时候，数百万电表同时连接网络，向电力公司汇总数据。这时候运营商的网络，必定像飓风中的小木屋，瘫痪得七零八落。根据我个人的经验，这种原因导致的网络瘫痪，基本上不可能恢复。因为终端的行为是不受控的，会努力地一次又一次的尝试。网络刚刚进入稳定状态，又会被下一波尝试冲垮。
这个问题的根本原因就在于网络终端的行为不受控。通过物联网操作系统的PolicyAgent（策略代理）机制和延迟传输机制，可以很好的解决这个问题。Policy Agent和延迟传输是Hello China操作系统内嵌的两个核心线程，其中第一个线程接受来自HCNServer的策略，比如什么时候可以传输数据，传输多少，什么时候传输速度最快，什么时候传输数据最便宜等。PolicyAgent可以根据这些策略，灵活的安排传输时间和传输的数据数量，以最大可能的降低传输成本。毕竟在白天上传数据，比凌晨传输数据的成本要高很多，因为凌晨很少有人使用网络。Policy Agent确定了传输策略之后，即可把这个传输任务下达给延迟传输线程。延迟传输线程本质上就是一个任务管理器，有自身的定时机制，一旦时间到了，就启动其它线程注册的任务，比如开始传输数据。
有了这些机制，运营商和企业就可以大做文章了。比如运营商可以通过历史数据分析，判断出哪些时间段是网络的空闲时间段，在空闲时间段内，最大能够容忍多少终端同时并发传送数据等等。然后生成针对每个终端的传输策略，下发给Hello China的Policy Agent线程。这样就可以把突发的网络请求，平均分散到各个网络空闲的时间段，避免了网络风暴问题。这就类似于武术中的以柔克刚，四两拨千斤等思想。
当然，这样做的前提是，物联网业务允许数据可以延迟传送，远程电力抄表就是一个很好的例子。对于一些不能容忍延迟传送的业务，比如视频监控等，就不适用了。但是这种情况下，Policy Agent反而能产生更大的作用。举视频监控这个实例来说，现在大多数监控终端都能够做到事件识别功能，即能够识别出异常事件。这样对于监控到的数据就可以分为两类：敏感事件监控录像和普通监控录像。现在的实现方式是，不论敏感事件录像还是普通录像，都统一通过无线网络，实时传输到后台服务器。但在引入Policy Agent和延迟传输机制的情况下，就可以实现敏感事件的实时传输，以及普通录像的低成本传输了。比如HCN Server可以把运营商推出的一些优惠策略（比如非节假日打折等）传递给PolicyAgent，终端就可以选择在成本最低的时段完成普通录像的传输。
当然，延迟传输并不是无限延迟的，而是可以定义一个最大延迟时间。如果在这个时间超时前没有任何优惠策略，则终端不得不启用正常传输了。
显然，Policy Agent和延迟传输策略不论对运营商还是企业，都具有莫大收益。对运营商来说，可以提升网络使用效率，避免恶性事故的发生。而对企业来说，则可以选择最低的成本完成数据传输工作，会节约很大成本。最重要的是，运营商会通过更低的价格，鼓励企业使用这项服务，这样企业的开通成本又会大大降低。
协同策略之三：运营商运营策略的落地点
号码资源一直是运营商的关键资产之一。典型的号码资源有IP地址、电话号码等。这些资源都是有限的，目前大多数运营商都面临号码资源耗尽的问题。对IP地址耗尽的问题非常紧迫，尤其是在中国。解决方案也很简单，就是升级到IPv6（当前IP协议的版本是IPv4）。对号码资源，虽然不如IP地址耗尽问题紧迫，但在看得见的将来，这也是个严重问题，尤其是在终端数量是现在的500倍的情况下。即时目前，从众多的号码前缀（比如130,131,132,133,134…）来看，用户也似乎越来越感受到电话号码资源的紧张。
虽然运营商的创新能力不如互联网厂商，但是我认为，在未雨绸缪方面，运营商却似乎比互联网厂商强得多。互联网厂商大多是走一步看一步，跟着用户的口味不断变化，推陈出新，但是基本不看未来十年，甚至五年之后的趋势。而运营商就不同了，IPv4地址实际上还是能够支撑几年的，但几乎没有一个运营商不在考虑部署IPv6。3G还没怎么用起来，已经有运营商在研究5G了。IP网络的DiffServ服务质量框架和流量工程（TE）还没有真正用起来，大多数运营商已经在考虑怎么上SDN了。这可能是由于行业特征导致的，毕竟互联网企业的产品或服务变化太大，不像运营商这么固定。互联网企业好比是天空中的鸟儿，面对一望无际的蓝天，管好自己的一对翅膀就足够了，从不考虑蓝天以外是什么样子。
有点扯远了，通信行业的同仁千万别拍砖，回到正题。由于运营商的未雨绸缪本性，在号码资源还未耗尽的情况下，如何尽快推出应对策略，是大多数运营商在研究的课题。对IP地址来说，目前最好的办法就是赶紧切换到IPv6。对电话号码耗尽问题，现在的解决方案是面向物联网应用，推出不带电话号码（MSISDN）的SIM卡，通过IMSI识别用户（后续称这种解决方案为MSISDN free）。如果您对MSISDN、IMSI等这些名词不熟悉也不要紧，这里简单介绍一下，在通信网络里，用好几套用户标识机制，电话号码是一种，IMSI是另一种。IMSI的长度可以达到15位（十进制），目前资源非常充足，而MSISDN就是电话号码，是资源瓶颈。
但是这两项策略在真正落地的时候，却不是很顺利。对IPv6推行来说，只有运营商在不遗余力的推动，ISP和终端厂商是非常消极的态度。因为IPv6除了带来充足的IP地址外，没有带来任何实际的东西。而演进到IPv6，对ISP和终端厂商来说是出力不讨好的事情，投入巨大，毕竟应用系统的源代码都要逐行检查，看是否需要针对IPv6最修改。这个巨大的投入却带不来任何经济收益。对MSISDN free特性来说，也需要终端操作系统的支持，毕竟需要修改通信软件的处理流程，而这种修改只是配合运营商，对终端本身来说无任何意义。
显然，如果引入与运营商网络紧密协同的物联网操作系统，这两项运营策略就可以很容易的推行了。只需要在物联网操作系统中增加对IPv6和MSISDN free的支持即可，这项工作是轻而易举的事。
这里列举了IPv6推行和MSISDNfree两项运营策略的推行为例，解释了物联网操作系统可以帮助运营商完成运营策略的快速落地。除此之外，物联网操作系统还可以通过软件升级的方式，配合运营商的任何运营策略的落地。
协同机制之四：信息收集机制帮助运营商完成网络质量分析和优化
思路很简单，不细说了，篇幅超标了。就是在Hello China上实现Info Collector核心线程，收集网络相关的事件或者数据。比如终端attach到网络上的成功率，终端连接到网络上的成功率，网络连接失败的原因，网络传输数据的速率等等数据，把这些数据统一汇总到HCN Server上。这些数据是运营商优化网络、提升客户体验的第一手资料，能够对网络质量产生最直接的掌握。现在运营商对自己的网络的掌握情况，个人认为是盲人摸象，无法掌握全貌。因为网络质量的好坏，是最终用户感受到的。只有最终用户能够评价网络的质量好坏，而物联网终端就是典型的网络用户。有了这些第一手的材料，运营商就可以有目的的优化自己的网络了。
总结
本文通过几个典型的应用场景，说明了物联网操作系统与运营商网络的紧密协同机制。实际上真正有效的协同机制，肯定不止这些。随着物联网操作系统开发和应用的深入，更有价值的协同机制和商业模式会被挖掘出来。协同之所以能够产生，就是随着网络的成熟和应用的增多，网络与终端之间的界面越来越模糊，关系越来越紧密。一旦协同起来，就会产生事半功倍的效果。相反，一旦不能协同，则可能会产生网络瘫痪等恶性事故。
作为物联网操作系统，Hello China从内核设计开始，就充分考虑了运营商网络协同机制和物联网相关机制的支持，在后续版本的开发中，将继续秉承这种理念，打造出一个高效稳定的物联网操作系统。
本文作者：辛庆祥，物联网操作系统概念提出者和倡导者，Hello China操作系统设计者，MBA，著有《操作系统实现之路》、《嵌入式操作系统设计与实现》等书籍，十多年通信行业从业经验。
版权所有，转载请注明出处及作者。
