Hello China被定位为物联网操作系统，是以前关于物联网操作系统的一系列文章中，物联网操作系统区别于其他操作系统的两个主要物联网特征支持是指对嵌入操作系统的NFC、GPS、Zigbee等物联网通信机制的支持，以及自恢复能力、低功耗等非功能机制。 这些机制简单易懂，也是目前其他几种物联网操作系统的主要开发方向。 但是，关于后者-运营商网络协作机制，在前一个说明中很少涉及，现在在本文中作为补充。 实际上并不是说明不足，而是因为运营商网络协作机制是新提出的概念，大众并不陌生。 在前面的物联网操作系统系列文章中，运营商网络的协同机制反而被描述得更多。
运营商网络协同机制体系构建所谓的协同(英文称为Collaboration )，至少有两个以上的人或系统互相发现对方的不足，发挥自己的特长，齐头并进，弥补对方的不足，“1”12 因此，物联网操作系统与运营商网络的协同，本质上是这两个系统—物联网操作系统与运营商网络之间的一种有效协调、取长补短的机制。 只存在某一方而不存在另一方，是不能合作的，双方必须存在并且有效合作。 以下是Hello China操作系统与运营商网络协作的技术架构。
其中，HCNserver(HelloChina服务器)是与运营商网络有效协作的重要组件，它是在运营商机房服务器上运行的软件模块。 运行Hello China操作系统的终端可经由运营商的无线电或有线网络接受HCN服务器的管理和调整并同时可能需要向HCN服务器报告一些终端状态数据。 这种管理和被管理的关系是可选择的布置。 如果Hello China终端的所有权不是运营商，则终端所有者可以选择不与HCNServer进行任何交互。 这可以通过自定义选项或动态配置来完成。 请不要误以为物联网终端受HCN服务器的严格控制。
HCN Server与运营商的网络系统有相应的接口。 例如，Policy Server (术语可能称为PCRF )。 )和之间具有Rx接口，通过该接口可以为特定终端定制特定服务。 例如，网络带宽和流量限制。 与运营商的消息接发中心也可以存在接口，例如对于中国移动来说，HCN Server通过CMPP接口与消息接发中心的网关连接，完成消息的发送接收功能。 当然，最重要的接口是HCN Server与物联网服务商或企业的接口。 企业可以通过HCN服务器实时获取终端的状态、终端收集的数据等信息，而无需与终端直接交换。 毕竟，通过一个固定的接口获取所有终端的信息，比一个一个地轮换终端要高效得多。 当然，如果企业不想在自己的终端上接受HCN服务器的管理，完全可以自己控制终端，从终端收集数据。
上图中有一些通信行业的术语，包括SMSC、BSS/OSS和Rx。 如果不理解这些词和系统的含义，也不影响对以下内容的理解： 以上述结构为基础，列举了运营商和物联网运营商能够真正受益的一些协同机制。 这里的前提是物联网终端，即Hello China终端归物联网运营商所有，物联网运营商与运营商签订合同，使用运营商的基础网络，同时使用HCN Server提供的服务
协同机制之一：通过SHBC机制执行黄金管路服务最直接的协同机制之一是共享心率中心机制(SHBC，详见以前的物联网操作系统系列文章)。 连接： http://blog.csdn.net/hello China 15/article/details/8798342目前，很多运营商都在为物联网APP提供管路服务，但实际上与个人通信不同，运营商的网络部件(如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，著有《操作系统实现之路》、《嵌入式操作系统设计与实现》等书籍，十多年通信行业从业经验。
版权所有，转载请注明出处及作者。