Design patterns of iot platform communication protocol

1. 物联网终端与平台
通讯协议设计模式概览
钟玮军
2019-12

2. 作者介绍
• 领域驱动设计实践者、传播者
• 资深SOA系统架构师
• 企业敏捷转型咨询师
• 从零到百打造优秀创业技术团队的经历
• 从业多个业务领域的系统分析与架构设计
– 电信设备制造
– 移动飞信即时通讯
– 物联网/车联网
– O2O汽车后服务
– 露天矿无人驾驶运输

3. 目的
如何根据应用场景的不同，恰当地进行物联网终端与平台之间通讯协议的设计？是很
多初涉物联网领域研发工程师的常见问题。
设计良好的通讯协议，能提升物联网运行的安全性和可靠性，少走弯路。
作者从不同应用场景的需求出发，总结物联网终端与平台通信协议几类常见问题和设
计模式，便于大家在实际工作中甄别使用。

4. (一) 终端连接管理(TCP)
需求场景：物联网终端与平台以TCP作为底层传输协议(传输更可靠)
(1)通常由物联网终端主动向平台发起连接建立请求，平台需要对终端的连接建立请求进行鉴权；
(2)终端与平台之间应当具备网络异常识别和断网重连的能力；
设计模式：
(1)应用层协议设计需要考虑TCP粘包分包问题，以及数据报文完整性校验问题，大块数据分包传输问题；
(2)终端TCP连接后应立即进行鉴权，未通过鉴权的连接平台不接收除鉴权外的任何报文，鉴权失败立即断开连接；
(2)可以采用TLS作为终端鉴权和加密传输的安全认证机制，也可以自己实现设备口令认证机制；
(3)为维持连接，在没有正常数据包传输的情况下，终端和平台之间通过心跳包维持连接；
(4)平台在收到终端主动断开、终端新连接建立或一定时间内未收到终端发出的消息，则判断原TCP连接断开；
(5)终端在收到平台主动断开、数据通信链路断开或重传数次未收到平台应答后，则判断TCP连接断开；
终端 平台
HeartBeat
AuthenticateAck
Data
Transmit
Authenticate(DeviceToken)
HeartBeatAct
Data
Transmit
TCP
Connect
TCP
Disconnect
AuthenticateAck
Authenticate(DeviceToken)
TCP
Connect
粘包分包 完整性校验
分包传输
建
立
连
接
维
持
连
接
断
网
重
连

5. (二) 终端连接管理(UDP)
需求场景：物联网终端与平台以UDP作为底层传输协议(传输更快)
(1)无连接传输协议，不需要连接建立、维持和断网重连过程，仍需要有安全认证机制；
(2)优点是没有发送缓冲区速度更快、缺点是传输的可靠性完全由应用层协议负责；
设计模式：
(1)没有粘包分包问题，需要验证报文数据完整性，以及大块数据分包传输问题；
(2)终端非固定IP模式下，平台/NAT穿透需要从终端数据报文中获取IP/端口以回传数据；
(3)按照应用场景可以分为允许丢包和不允许丢包两类，不允许丢包需要靠消息ID和消息ACK支持丢包重传；
(4)可以采用DTLS作为终端鉴权和加密传输的安全认证机制；
(5)终端和平台之间可以增加心跳机制，平台一段时间没有接收终端数据判断为终端离线，产生离线报警；
终端 平台
MsgAck(id = 1)
Msg(id = 1)
MsgAck(id = 2)
Msg(id = 2)
x
MsgAck(id = 3) x
Msg(id = 3)
MsgAck(id = 4)
Msg(id = 4)
补传MsgAck(id = 2,3,…)
补传Msg(id = 2,3,…)
终端 平台
MsgAck(id = 1)
Msg(id = 1)
MsgAck(id = 2)
Msg(id = 2)
x
MsgAck(id = 2) x
Msg(id = 2)
MsgAck(id = 2)
Msg(id = 2)
MsgAck(id = 3)
Msg(id = 3)
阻塞式丢包重传 非阻塞式丢包重传 DTLS握手协议

6. (三) NAT穿透问题
需求场景：节约IP资源，物联网终端部署在独立的专网内，通过公网和平台互通
设计模式：
(1)节点路由器需要开启NAT转换功能，一般地，平台端采用静态NAT，设备端采用动态NAT；
(2)终端与平台通信需要考虑NAT过期问题，必要时需要增加心跳包以便NAT Session不过期(如终端休眠唤醒)；
(3)除非设备侧有固定IP和静态NAT，设备与设备间直连通信需要借助平台进行UDP或TCP打洞；

7. (四) 有序消息发送
需求场景：终端到平台或者平台到终端的消息，需要以有序、可靠的方式到达对端
设计模式：
(1)可以采用传统阻塞式丢包重传机制，或者采用类似微信的Sync有序消息同步机制实现；
(2)发端需要设计有缓存消息队列机制，Sync机制需要SyncKey递增生成机制；
(3)终端->平台消息，更适合采用传统阻塞丢包重传机制，平台->终端消息，若终端不稳定阻塞重传平台开销较大；
(4)当累计有多条未发消息时，可以考虑多条消息一起打包传送，直至传送完毕；
(5)Sync同步机制能够完美解决单用户在多终端登录的消息发送场景。
终端 平台
MsgAck(id = 1)
Msg(id = 1)
MsgAck(id = 2)
Msg(id = 2)
x
MsgAck(id = 2) x
Msg(id = 2)
MsgAck(id = 2)
Msg(id = 2)
MsgAck(id = 3)
Msg(id = 3)
传统阻塞式丢包重传机制(终端->平台)
平台 终端
Msg(id = 5)
Msg(id = n)
TCP
Connect
Notif
ySync(SyncKe
y)SyncResponse(New
SyncKey)Sync(SyncKe
y)SyncResponse(New
SyncKey)Msg(id = n+1)
Notif
y
x
Periodicity
SyncCheck(SyncKey)
Sync(SyncKe
y)SyncResponse(New
SyncKey)
Notif
y
以微信为代表的Sync有序消息同步机制(平台->终端)
平台 终端
MsgAck(id = 1)
Msg(id = 1)
MsgAck(id = 2)
Msg(id = 2)
x
MsgAck(id = 2) x
Msg(id = 2)
MsgAck(id = 2)
Msg(id = 2)
MsgAck(id = 3)
Msg(id = 3)
传统阻塞式丢包重传机制(平台->终端)

8. (五) 非阻塞式丢包重传机制
需求场景：希望新数据实时发送，丢失数据允许延时发送(以环境数据实时监测为例)
设计模式：
(1)可以采用非阻塞式丢包重传机制，最新消息即时发送，未得到响应的消息延时打包发送；
(2)发送端需要设计消息缓存队列机制，未发送成功消息保存在消息缓存队列中 ，成功后从缓存中消除；
(3)补传消息可以选择相对空闲的时机进行补传。
终端 平台
MsgAck(id = 1)
Msg(id = 1)
MsgAck(id = 2)
Msg(id = 2)
x
MsgAck(id = 3) x
Msg(id = 3)
MsgAck(id = 4)
Msg(id = 4)
补传MsgAck(id = 2,3,…)
补传Msg(id = 2,3,…)
非阻塞式丢包重传

9. (六) 终端参数配置
需求场景：平台操作人员对终端参数进行远程设置
设计模式：
(1)参数的最后一次设置值才有意义，终端断网重连时重发过期配置指令没有意义甚至可能发生问题；
(2)以亚马逊为代表的物联网平台有DeviceShadow概念，提供了基于MQTT的状态同步机制，用于终端参数设置；
(3)Sync有序消息同步机制其实也是状态同步机制的一种变体，它把消息收件箱的SyncKey作为状态与终端同步；
(4)参数变多的话Report的参数表会很长，此时可以考虑将参数表的最后版本(修改时间)作为Report和Notify同步
的状体，当Report的参数表版本与平台的参数表版本不一致时，终端全量同步参数表并进行更新；
平台 终端
消息丢包重传机制进行参数配置命令下发（差）
Set(A=1)
Set(A=2)
Set(A=3)
connected
Msg(Set(A=1))
Msg(Set(A=2))
Msg(Set(A=3))
Set(A=4)
MsgAck
MsgAck
MsgAck
Set(A=5)
Msg(Set(A=4))
MsgAck x
Msg(Set(A=4))
MsgAck
Msg(Set(A=5))
MsgAck
平台 终端
状态同步机制进行终端参数配置（好）
Set(A=2)
Set(A=3)
Set(B=1)
connected
Report(A=1, B=5)
Notify(new A=3, new B=1)
Report(A=3, B=1)
Set(B=2)
Set(B=3)
Notify(new B=2)
Report(A=3, B=2)
Notify(new B=3)
Report(A=3, B=2)
x
Notify(new B=3)
Report(A=3, B=3)
Amazon的DeviceShadow工作原理

10. Product Package V2.0.0
(七) OTA升级
需求场景：平台提供对终端软件的在线升级能力
设计模式：
(1)基本思路仍然可以借鉴终端参数配置(即状态同步机制)实现；
(2)将Product Package版本和Component版本概念上分离，可以实现增量更新的效果；
(3)终端侧可能需要考虑在接收到版本更新的Notify之后，选择安全的时机进行软件版本更新(尤其是机械设备)；
(4)终端侧需要考虑OTA升级失败处理机制(升级程序本身在升级失败后仍然能重新启动升级过程)；
Component A
V1.2.1
Component B
V1.5.1
Component C
V2.2.1
Component C
V2.5.1
Product Package V2.1.0
Component A
V1.2.1
Component B
V1.5.1
Component C
V2.2.1
Component C
V2.6.1
平台 终端
状态同步机制进行终端参数配置（好）
Set(Product Package V=2.1.0)
connected
Report(Product Package V=2.0.0)
Notify(Product Package V=2.1.0)
Get Sub Components Version of Pakage V2.1.0
Download upgrade file
VerifyFile
Upgrade
Notify(Product Package V=2.1.0)
Notify(Product Package V=2.1.0)
x

11. (八) 人工远程遥控驾驶
需求场景：远程遥控驾驶飞机/车辆
(1)操作员观测被遥控对象的运动姿态并随之调整远程遥控器/设备的档位数值；
(2)远程遥控器/设备将档位控制信息实时发送给被遥控对象，被遥控对象根据遥控指令做出相应动作；
设计模式：
(1)档位控制信息的播发要求通信网络具有高频率、低时延、低丢包的特性；
(2)常见的数据通信协议有PWM/PPM，或者基于IP网络的UDP协议；
(3) 飞机/车辆可以设计SafeGuard机制，当远程指令存在安全风险时，可以安全刹停并返回报警；
视频回传
PWM/PPM通讯
UDP通讯
观测
操作
观测
操作

12. (九) 实时智能反馈控制
需求场景：平台根据终端状态进行实时智能反馈控制（以轨道CBTC移动闭塞空间为
例）
(1)列车实时将自己的最新状态信息(位置、车速等)发送给行控中心 ；
(2)行控中心根据最新状态信息重新计算列车的移动闭塞区间；
(3)行控中心将新的移动闭塞区间参数下发给列车；
(4)列车根据新的移动闭塞区间参数进行行驶控制；
设计模式：在考虑到行车安全的情况下，还需要考虑到行车连续性和网络异常状况
(1)本套系统的特点是响应要快，通讯数据包内容应简洁短小，尽量不包含无关内容；
(2)列车实时状态上报可以采用TCP或UDP，因过时数据对移动闭塞计算没有意义，考虑高频同步，丢包不重传；
(3)保证列车端计算的移动闭塞区间范围永远小于平台端计算的移动闭塞区间范围，丢包时也可保证绝对安全；
(4)行控中心向列车下发的移动闭塞区间参数有助连续运行，虽然丢包没大影响，还是可以考虑周期播发的方式；
x
列车实时状态同步报文丢失 闭塞区间参数同步报文丢失
平台端计算的移动闭塞区间参数 列车端计算的移动闭塞区间参数
x x x
x x
x x
x xx x