NB-IoT 设备实时反向控制方案分析

2020年，电信、移动、联通三大运营商 NB-IoT 设备突破1亿大关，NB-IoT在水、电、煤表计场景应用广泛。NB-IoT终端可以通过域名轻松找到业务服务器，定时上报业务数据， 但IoT终端没有域名，业务服务器如何主动找NB-IoT设备，实现反向控制指令及时下达，让很多IoT 开发者头疼不已。

  NB-IoT 三大模式  

在解决如何实时下行前，我们首先需要了解 NB-IoT 支持三种省电模式：DRX（不连续接收模式）、eDRX（扩展不连续接收模式）、PSM (省电模式)。

DRX虽然叫做“不连续接收”，但是对硬件产品来讲，是“连续接收”。随时都可以收到数据。相当于随时在监听，所以功耗最高。

eDRX，就是把网络先开一会、再停一会。 开的时候能收到数据，停的时候收不到数据。停的时间从几十秒到几个小时，可以配置。

PSM，相当于把eDRX开关网络的频率放的更低，低至几天打开一次网络。同样，打开网络的时候能收到数据，不打开网络的时候收不到数据。

  NB-IoT 反向控制  

业务服务器要想随时随地找到IoT设备，就需要建立一个长连接通道。这个“长连接”，实际上是个虚拟的TCP/IP网络连接，中间经过了无数网络节点，每个节点都可能把这个长连接断掉。因此 IoT 设备需要定期(Keepalive)给服务器发送心跳包，告诉服务器“我还活着、我在这里，不要把我踢掉！”。

但是，心跳包非常耗电。NB-IoT设备不能断开和基站之间的信号连接，信号一断，连接就断了。同时每次发送心跳包需要大功率发射信号，对于电池供电的IoT设备来说是不能承受之重。

在DRX模式下NB-IoT网络不需要通过心跳包来维持长连接，运营商会负责反向控制。这样业务系统无需再设计心跳包！提供运营商API来发送反向控制指令，下发到NB-IoT基站，基站能够随时向终端发数据。

  运营商 GRE 隧道  

NB-IoT终端数据最终经过在P-GW后汇入公网并传输到上层应用服务器；由于IPv4资源限制，所有终端在通常情况下都不可能使用单独的公网IP。

IPv4的NAT映射存在端口老化问题，对此我们可以通过专用网络的方式解决资源受限的问题，也就是传说中的GRE隧道方案。

通过向运营商申请开通GRE隧道，将NB-IoT终端接入到了私网中进行传输，由于私网资源宽裕，所以在P-GW中可以绕过NAT映射，将一个IP+Port资源固定给一个业务上下行使用，从而规避心跳机制实现无需心跳维NB-IoT网络长连接功能。

往期推荐

1、39张传感器工作原理GIF图汇总

2、智能手持测温枪开发实践

3、IoT+TSDB+Quick BI 搭建楼宇环境监控

4、JS全栈开发，构建智能家居小程序