关于IoT的协议选择

对于使用传感器和保持连接性的IoT系统而言，如何使用这些元素和多种互联网技术相结合呢？

互联网协议并不陌生，但是IoT相关的互联网协议可能是有不同，有些协议被用来辅助塑造系统。TCP/IP协议栈上有多个应用层协议， 每种协议都有自己的优势和限制，了解这些可以帮助开发者为产品做出最好的设计选择。 在选择物联网协议时， 带宽要求、实时性能和内存占用是主要的约束条件。

鉴于IoT 的多样性和复杂性，应用场景上有着诸多的类型：

Consumer versus industrial 消费者 vs 工业

Web services 网络服务

IoT services 物联网服务

Publish/subscribe 发布/订阅

Request/response 请求/响应

。。。。。。

在设计IoT系统时， 必须考虑这些类别， 清晰的需求和边界确定，几乎是成败的关键。一般地，一个IoT系统大致如此：

图1 IoT（M2M）的一般系统架构

面向接口的设计，被业界广泛的接受，引申到系统的层面，大约是面向协议的设计， 对协议的认知是设计的基础。

互联网协议栈

互联网是所有网络设备的总和， 用来将 IP 包从源路由到目的地。 相比之下， Web只是一个在互联网上运行的应用系统。 网络是一个交流信息工具， 在过去的几十年里， 网络得到了普及和发展， 普通人也能够轻松有效地使用互联网。 例如， 电子邮件，搜索引擎，浏览器，移动应用，以及其他流行的社交媒体。

相对而言， 物联网是让电子设备通过互联网交换信息。 但是这些设备还不能像浏览器和社交媒体那样来促进交流。 物联网也不同于网络，因为物联网设备为了协同工作所需要的速度、规模和功能不同于互联网， 需求千姿百态，这也是物联网定义难以明确的原因之一。

协议栈是互联网和网络的核心，离不开OSI七层开放系统互连的表示，具体可以参见老曹眼中的网络编程基础。 在这里，上三层被分组在一起以简化模型。

图2 OSI 模型简要

我们需要从IoT的角度来快速理解一下OSI层。

下三层：物理层、数据链路层 和网络层

互联网中常用的物理层和数据链路层协议有：

Ethernet （10 Mbps， 100 Mbps， 1 Gbps）

Wi-Fi （802.11b/g/n）

点对点协议（PPP）

GSM， 3G， 4G， LTE 3G， 4G， LTE

但是对IoT而言，采用的无线协议更加丰富，例如 802.15.*等，甚至城域网乃至其他广域网的相关协议也纷纷被引入， 后面单独进行理解。

网络层是互联网生存的地方。 互联网之所以被命名， 是因为它提供了网络之间、物理层之间的连接。 这就是我们找到无处不在 IP 地址的地方。

传输层

在 IP 之上， 互联网有两个传输协议——TCP和UDP。 TCP 用于网络中的交互（电子邮件、网页浏览等） ， 甚至被认为 是传输层中唯一的协议。 TCP 提供了逻辑连接的概念， 传输包的确认， 丢失数据包的重传， 以及流量控制。 但是对于IoT系统而言， TCP 可能有点重。 因此， 尽管 UDP 长期以来一直被降级到DNS和 DHCP等网络服务， 现在已经在传感器采集和远程控制领域占据了一席之地。 如果需要对数据进行某种类型的管理， 甚至可以在 UDP 之上编写自己的轻量级协议， 以避免 TCP的开销。

对于语音和视频等实时数据应用， UDP 比 TCP 可能更适合。 TCP 的数据包确认和重传功能对于这些应用可能是无用的开销。 如果一段数据（比如一段口语音频）没有及时到达目的地， 那么重新传输数据包可能意义不大。有时选择TCP是因为它提供了一个持久的连接。 为了实现类似的功能， 必须在 UDP 上面的协议层中实现该特性。

当决定如何将数据从“事物”本地网络转移到一个 IP 网络时， 可以通过网关将两个网络连接起来， 或者可以把这个功能构建在“事物”本身上。 许多微控制器（MCUs）现在都有一个以太网控制器， 这使得这个任务更加容易。

用于物联网的无线协议

虽然大部分物联网依赖于传统的嵌入式开发技术， 但是对始终拥有对连接性的需求，这要求我们不仅对无线方法做出选择， 还要选择相应的通信协议。 因此， 不同的协议都在试图建立为从边缘节点向云服务提供数据通信的基础。 每种协议都希望被看作是对某些类型的数据或数据交换方法的最佳选择。

从计算机网络演进的IoT无线协议

Nest Labs 在智能恒温器和烟雾探测器产品中使用了Thread Group 协议， 在2015年被谷歌收购并获得了迅速的发展。 随着合作伙伴和用户群体的不断增长， Thread Group的潜力使其成为 ZigBee、 Z-Wave 和低耗电蓝牙（BLE）等技术的可行替代品。 其成功的主要原因是谷歌没有开发一个全新的协议， 而是把它建立在 IEEE 802.15.4无线标准的基础上。

图3 Thread 协议的主要组件

Thread Group的目标是家用电器、接入和气候控制、能源管理、照明、安全等。

BLE 可能是Thread Group 的最大竞争对手， 但是 BLE 尚不能形成一个自我修复的网络， 而这个网络正逐渐成为物联网应用的先决条件。 可靠性是基于传感器任何形式通信的关键， 如恒温器、安全警报器， 当然也适用于安全第一的工业应用。尽管如此， BLE 当然还没有退出物联网的协议竞争。受益于多年来不断增强的功能， 现在一些蓝牙技术联盟（蓝牙 SIG）的参与者， 如 Broadcom、 Qualcomm 和其他行业领导者， 正在努力提高 BLE 的能力， 使其适用于物联网应用。

蓝牙 SIG 也为连接互联网铺平了道路，推出了蓝牙智能网络工作组（目前已有80多家公司支持该工作组） ， 目标是建立标准化蓝牙网络网络的架构。

IPv6， IEEE 802.15.4， 以及一个叫做 IPv6的个人区域网络相对于Thread Group、 ZigBee 和 Z-Wave 所使用的低功耗无线个人区域网（6LoWPAN）的是互补的， 因为后两种网络是明确为处理能力有限、数据率低、射频输出功率极低、电源或电池耗电量极低的设备。 这将使设备和网络设计相对简单， 成本效益较高。

由于 Thread 的低延迟（通常为100毫秒， 一般比 Wi-Fi 要少得一些）特性 ， 它可以在一个网络上容纳300个设备， 提供 AES 128位的安全性， 以及一个网状网络方法将其定位为适合在物联网应用中使用的协议。 但是， 没有证据表明 Thread 将成为物联网连接的主导者。 随着物联网的增长 ， 很多协议显然要建立自己的空间， 也许在特定的应用程序中找准自己的位置。

远距离的IoT无线协议

LPWAN技术是为了满足物联网需求应运而生的远距离无线通信技术。

对于电信运营商而言，车联网、智慧医疗、智能家居等物联网应用将产生海量连接，远远超过人与人之间的通信需求。基于蜂窝的窄带物联网（Narrow Band Internet of Things， NB-IoT）成为万物互联网络的一个重要分支。NB-IoT构建于蜂窝网络，只消耗大约180KHz的带宽，可直接部署于GSM网络、UMTS网络或LTE网络，以降低部署成本、实现平滑升级。

NB-IOT聚焦于低功耗广覆盖（LPWA）物联网（IOT）市场，是一种可在全球范围内广泛应用的新兴技术。其具有覆盖广、连接多、速率低、成本低、功耗低、架构优等特点。NB-IOT使用授权频段，可采取带内、保护带或独立载波三种部署方式，与现有网络共存。

国内的华为在NB-IoT上是比较有作为的，该公司给出的端到端解决方案示意如下：

图4 NB-IoT E2E soluTIon　

在非授权频段，也有应用于IoT的相关无线协议。对应于NB-IoT，LP-WAN在非授权频谱中的协议主要有LoRa、SigFox等技术。网络部署拓扑布局可以根据具体应用和和场景设计部署方案。 例如，LoRa适合于通信频次低，数据量不大的应用。

图5 LPWAN 的解决方案

其他的那些常见协议

那么 zigbee / zigbee Pro， Z-Wave， AllJoyn， CSR Mesh， 和 IoTIvity 那些协议是怎样的呢？

Zigbee 3.0在2.4 GHz 的频率运行， 最大数据速率为250千兆比特， 已经获得了大约400个供应商的广泛支持， 并且可以使用一个完善的网络协议支持数以千计的节点。 它的链接距离约为100英尺， 支持 IPv6， 并提供128位的 AES 加密安全。 这个最新版本包含了多年来所有过往的ZigBee 应用配置， ZigBee 联盟因此受到了批评。

和 ZigBee 一样， ZigBee Pro 是一个相对较新的规范。 这种网格网络协议显然对物联网进行了优化， 它不仅可以在2.4 GHz 频谱上运行， 而且可以在800-900 MHz 无需授权的频谱中运行。 使用扩频调制方法， 可以超过16个通道， 除广播传输选项外， 还支持星状拓扑。 和大多数物联网节点应用一样， 节约能源是首要考虑因素， 因此协议满足通过各种机电、光或运动方法获取能量的无电池的设备。

与此同时， Z-Wave 只在800-900 MHz 频带上运行，仍然得到了超过375个组织的支持。

在 Linux 基金会内部， 有 AllJoyn 框架的 AllSeen 联盟。 Alljoyn 是一个开源、协作软件框架， 允许开发者为物联网编写应用程序， 无论品牌、类别、传输媒介和操作系统， 都可以为物联网编写应用程序， 而无需使用云计算， 甚至不需要互联网（但这两者都得到了支持）。 它支持 Wi-Fi、以太网、串口乃至电力线传输媒体。 支持的操作系统包括 RTOS， Arduino， Linux， Android， iOS， Windows 和 Mac。 该框架同样使用128位 AES 加密， 目前有120多家公司支持。

另一个在 Linux 基金会内部运行的协议是 IoTIvity， 它专注于提高互操作性和定义物联网的连接需求。 它使用一个通用的通信框架， 管理个人计算机和新兴物联网设备之间的信息流， 而不考虑形式因素、操作系统或服务提供者。

可应用在物联网中的互联网高层协议

尽管不像新的协议那样有效，但使用web 技术建立物联网系统仍然是可能的。 http/https和 websocket 是常用的标准， 以及负载中的 XML或 JSON。

HTTP

Http 是 Web 客户端-服务器模型的基础。 在物联网设备中实现 HTTP 的最安全且简单的方法是只包含一个客户端， 而不是服务器。 换句话说， 当物联网设备能够启动与网络服务器的连接， 但无法接收连接请求时， 它会更安全; 一般不希望外部机器访问装有物联网设备的本地网络。

WebSocket

Websocket 是一个协议， 通过一个单一的 TCP 连接提供全双工通信， 通过这种连接可以在客户端和服务器之间发送消息。 它是HTML5规范的一部分。 Websocket 标准简化了双向网络通信和连接管理的大部分复杂性。

XMPP

XMPP 是现有 Web 技术在物联网领域中应用的一个好例子。Xmpp 的根源在于即时通讯和存储信息， 并且已经扩展到语音和视频通话、协作、轻量级中间件、内容聚合和 XML 数据的广义路由。 它能够大规模管理消费者产品，如洗衣机、烘干机、冰箱等等。

XMPP 的优势在于地址、安全性和可伸缩性，成为面向消费者物联网应用的良好选择之一。

HTTP， WebSocket， 和XMPP 只是其中的一些例子，很多组织也在努力寻找解决物联网新挑战的解决方案。

面向物联网的高层协议

许多物联网专家把物联网设备称为受限系统， 因为物联网设备应该尽可能的便宜， 并且运行协议栈的同时使用最小能力的MCU。

如果系统不需要 TCP 的特性， 并且可以使用更有限的 UDP 功能， 那么删除 TCP 模块将大大减少产品的总代码量， 这就是 6LoWPAN 和 CoAP 在物联网领域的应用。

CoAP

虽然网络基础设施对物联网设备来说是可用的， 但是对于大多数物联网应用来说还是太重了。 2013年7月， IETF 发布了 CoAP， 用于低功耗节点网络。 与 HTTP 一样， CoAP 也具有 RESTful操作资源和资源标识符的能力。

CoAP 与 HTTP 语义对齐， 甚至有一对一的 HTTP 映射。 网络设备受到较小的MCU约束， 只有少量的闪存和 RAM， 而对局部网络的限制是高数据包错误率和低吞吐量（几十kb/秒）。 对于在电池或能量采集元件上运行的设备来说， CoAP 是一个很好的协议。

CoAP 的特点：

由于 CoAP 使用 UDP， 一些 TCP 功能在 CoAP 中被直接复制。 例如， CoAP 区分了可确认（需要确认）和非确认消息

请求和响应在 CoAP 消息上异步交换（与使用现有 TCP 连接的 HTTP 不同）

所有的标题、方法和状态代码都是二进制编码， 可以减少协定开销。 然而， 这需要使用协议分析器来debug网络问题。

充分考虑到这是一种极其轻微的协议， 其行为类似于永久连接。 它对 HTTP 语义很类似， 并且是 RESTful 的。 如果有网络编程背景， 使用 CoAP 是相对容易的。

MQTT

MQTT是针对受限设备和低带宽、高延迟或不可靠网络开发和优化的开源协议。 它是一种发布/订阅传输模型， 非常轻便， 非常适合将小型设备与带宽小的网络连接起来。 MQTT 是带宽效率高、数据不可知的， 并且在使用 TCP 时具有连续的会话意图。 其目的是尽量减少设备所需资源， 同时努力确保服务等级的可靠性和某种程度上的保证。

MQTT的目标是小型设备的大型网络， 这些设备需要在互联网的后端服务器上进行监控。 它不是为设备间传输设计的， 也不是为许多接收机“多播”数据而设计的。 使用MQTT的应用程序有时是缓慢的， 因为在这种情况下，“实时”的定义通常以秒计量。

MQTT 与 CoAP 的简要对比

MQTT 的发布/订阅模型很好， 这种体系结构的优点已经得到证明。 在 IETF 最新的RFC中， CoAP 引入了对发布/订阅的支持。CoAP 的轻型有效负载非常适合无线传感器网络。传感器MQTT网络已经采纳并复制了这个想法。

两个主要的物联网专用协议互相借鉴。 但这两个协议是否是主流？ 尚需时间检验。

物联网协议的选择

连接传感器和事物对象打开了一个全新的世界， 这些应用场景将决定何时为应用使用怎样的协议。

这些协议的层位置都是相似的。 除了 HTTP 之外， 所有这些协议都被定位为实时发布/订阅的物联网协议， 支持数百万的设备。 根据如何定义“实时”（秒、毫秒或微秒）和“事物”（WSN 节点、多媒体设备、个人可穿戴设备、医疗扫描仪、引擎控制等） ， 对产品的协议选择至关重要。 从根本上讲， 这些协议是非常不同的。

在设计系统时， 需要做的是非常精确地定义系统需求， 并选择正确的协议来解决问题。 网络协议是一个载体，可以像Web 一样封装物联网的许多协议。

一旦协议或协议集被认为满足应用的部署、管理和支持， 就应该理解每个协议的最佳实现。 鉴于此， 设计需要为系统选择每个协议的最佳实现， 然后从这些协议中选择系统的最佳协议实现。

协议选择问题与协议的实现密切相关， 而支持协议的组件在最终设计中往往是必不可少的。 这使得这个决定非常复杂。 部署、操作、管理和安全的所有方面都必须被视为包括实现环境在内的协议选择因素。

为了满足具有少内存、低带宽、高延迟的物联网设备的需求，面向互联网的物联网协议已有很多。 图6 提供了这些协议给物联网带来的性能效益的另一个总结。

此外， 对于特定的应用程序没有任何统一的标准， 这些标准通常是由市场选择的。 作为一个开发者， 利用环境的特定特性， 满足系统的要求， 这反过来又依赖于协议的细节， 应对未来的变化会变得非常困难。

协议栈的选择与供应商的关系

物联网的高级协议具有多种特点， 提供了不同的功能。 大多数协议是由特定的供应商开发的， 这些供应商通常会推广自己的协议选择， 没有明确地定义他们的假设， 而且忽略了其他的替代方案。 由于这个原因， 依靠供应商信息来选择物联网协议是有问题的， 而且大多数已经产生的比较都不足以理解权衡。

物联网协议常常绑定到业务模型。 有时这些协议是不完整的和 / 或用于支持现有的业务模式和方法。 有些时候， 它们提供了一个更完整的解决方案， 但是对于较小的传感器来说， 资源需求是不可接受的。 此外， 没有明确说明使用议定书背后的关键假设， 因此难以进行比较。

物联网应用的基本假设如下：

将使用各种无线连接

设备从微型单片机到高性能系统都有， 重点是小型的 MCU

安全是核心要求

数据将存储在云中， 并可能在云中处理

需要将连接到云存储

需要通过无线和有线连接将信息传送到云存储中

其他假设需要更深入的调查， 并将对他们的选择需要深入了解。 通过查看这些协议的主要特点， 并审视关键的实现要求， 设计者可以更清楚地了解在协议领域和支持特性领域需要什么， 以改进其设计。

协议选择中的关键特性

物联网通信是基于 Internet tcp / udp 协议和相关的互联网协议。 对于基本的通信， 这意味着要么 UDP 数据包的 TCP 流套接字。 小型设备的开发者声称 UDP 在性能和尺寸方面有很大的优势， 这反过来会减少成本。 虽然这是真的， 但在很多情况下它并不重要。

尽管Stream Socket 受到性能的影响， 但它们确实保证了所有数据的有序传输。 在167mhz 的 STM32F4上传输传感器数据的性能受到影响， 不到16.7% （用2kb 的数据包测量）。 通过采用流套接字的方法， 也可以使用标准安全协议来简化环境（尽管如果可用的话， DTLS 可以与 UDP 一起使用）。

类似地， 增加20 KB 的闪存和8kb 内存升级到 TCP 的内存成本差异通常很小。 对于大量的微型应用和传感器来说， 这可能是有意义的， 但通常不会影响 ARM Cortex-M3的设计， 也不会影响其他架构， 如 RX， PIC32和 ARM Cortex-Ax。

消息模型

信息传递通用物联网的方法非常重要， 许多协议已经迁移到一个发布/订阅模型。 由于许多节点连接和断开， 而且这些节点需要连接到云中的各种应用程序， 因此， 发布/订阅请求 / 响应模型具有优势。 它对随机的开/关操作作出动态响应， 并能支持多节点。

CoAP 和 HTTP都是基于请求响应的，而没采用发布/订阅方法（CoAP在新的RFC中已引入）。 在 CoAP 的情况下， 使用6LoWPAN 和IPv6的自动地址被用来唯一地识别节点。 在HTTP的例子中， 这种方法是不同的， 因为请求可以是任何东西， 包括发布请求或者订阅请求， 所以事实上，这种方式的设计是一般情况。 今天， 这些协议被合并以提供一个完整的发布/订阅请求 / 响应模型。

拓扑架构

系统架构是多种多样的， 包括CS、树或星、总线和 P2P。 大多数人使用CS， 但也有人使用总线和 P2P 方法。 星状结构是一种树的方法。 对于这些拓扑架构， 性能问题通常存在于 P2P 和总线体系结构中。 模拟或原型方法在设计的早期需被采纳， 以防止意外发生。

可伸缩性

可伸缩性取决于在字段中添加多个节点， 并增加云资源以服务这些新的节点。 不同的架构有不同的特性，对于客户端服务器架构来说， 增加可用服务器的池是容易的。 对于总线和 P2P 架构， 规模在架构中是固有的， 但是没有云服务。 对于与树或星相连接的架构来说， 可能存在与在树上增加额外的叶子有关的问题， 这会加重通信节点的负担。

可伸缩性的另一个方面是处理大量不断变化的节点， 并将这些节点与云应用程序联系起来。 正如所讨论的， 发布/订阅请求 / 响应系统是为了可伸缩性， 因为需要处理出于各种原因离线的节点， 这些节点允许应用在决定订阅和请求数据时接收特定数据， 从而实现精细的数据流量控制。 不健壮的方法也不能很好地扩展。

自修复性

低功耗和无损网络是有节点层级移动的。 这种动态行为可能会影响网络的整体， 所以协议是为多路径动态重构设计的。 在 ZigBee、 ZigBee IP （使用6LoWPAN）和 6LoWPAN 中发现的动态路由协议确保了网络的适应性。 如果没有这些特性， 处理这些节点就会变成一个不连续的操作， 使得节点的资源需求更高。

资源需求

随着应用数量的增加， 资源需求是关键。 微控制器以非常低的成本处理上面列出的问题。 有些协议过于资源密集， 不适用于小的节点。 除非包括大量的闪存或其他存储介质， 否则不连续操作和大数据存储将受到限制。 随着资源的增加， 为了减少整个系统的成本， 可能需要添加聚合节点，来提供额外的共享存储资源。

互操作性

互操作性对于未来的大多数设备来说是必不可少的。 迄今为止， 已经看到了一系列的点解决方案， 但最终用户希望传感器和设备能够协同工作。 通过使用一套标准化的协议和标准化的消息， 设备可以与支持它们的云服务分开。 这种方法可以提供完整的设备互操作性。 此外， 使用智能发布/订阅选项， 不同的设备甚至可以使用相同的云服务， 并提供不同的功能。 使用开放的方法， 应用标准将会出现， 但目前还没有。

安全性

使用标准信息安全解决方案是大多数提供安全性的协议核心安全机制。 这些安全办法的基础是：

TLS

PSec/VPN

SSH

SFTP

SecurebootloaderandautomaTIcfallback

Filtering

HTTPS

SNMPv3

Encryptionanddecryption

DTLS（forUDP-onlysecurity）

由于这些技术已使用多年， 因此将安全作为一揽子计划的一部分至关重要。

协议选择时的实施考量

隐私是一个必不可少的实现要求，几乎所有系统都需要对云进行安全通信， 以确保个人数据无法被访问或修改。 此外， 云中显示的设备和数据的管理需要单独管理。 如果没有这个功能， 用户的关键个人信息就不能得到适当的保护， 任何有管理权限的人都可以获得。

管理平台一般还包括：

系统初始化

远程字段服务选项（如字段升级、重置为默认参数和远程测试）

控制帐户用途（例如帐户禁用、帐户启用及帐单功能）

为防盗目的而进行控制（相当于把设备弄坏）

考虑到这种类型的体系结构， 还有一些附加的协议和程序需要考虑：

自定义开发的云系统管理应用程序

Snmp 管理的传感器节点集合

云计算集成程序

运行的 SQLite 来存储和有选择地更新数据到云

计费是商业系统的一个重要方面。 电信运营商已经证明， 包月模式是最佳的收入选择。 此外， 自动化服务的选择和集成对于无缝计费也很重要。 此外， 信用卡依赖性也会产生问题， 包括超过限额的问题， 过期的信用卡和被删除的账户。

用户自服务也是实现成功的关键。 这包括远程现场服务， 这样设备就不会返回工厂， 智能或自动配置， 在线帮助， 社区帮助和非常直观的产品都是关键。

应用集成也很重要。 如今， 点系统占据了主导地位， 但是未来的关键将是使传感器可以用于用户选择的广泛应用。 准确性和可靠性可以对结果应用结果产生重大影响， 一旦出现标准接口， 预计将在这一领域开展竞争。 通过服务器的间接访问可以确保安全性、没有应用程序更改的进化和计费控制。

不连续的操作和大数据是紧密相连的。 随着设备的随机连接和断开， 需要为传感器保存数据并在稍后更新云计算。 由于电力和成本的原因， 存储限制是存在的。 如果某些数据是关键的， 它可以在其他数据被丢弃的时候被保存。 所有的数据都可以保存下来， 并选择性地更新以后执行的云。 处理数据的算法可以运行在云或传感器或任何中间节点。 所有这些选项都给传感器、云、通信和外部应用带来了特殊的挑战。

多连接传感器访问也是一个需求， 使传感器真正可用于一系列广泛的应用程序。 这种连接最有可能通过服务器进行， 以简化传感器并消除重复消息的功率需求。

综上所述，许多协议都被吹捧为物联网（IoT）的理想解决方案。 通常正确的协议选择会被那些在他们的产品中有既得利益的供应商所掩盖。 用户必须了解他们的具体要求和限制， 并有一个精确的系统规范， 以确保为各种管理、应用程序和通信功能选择正确的协议， 并确保所有的实现规范都得到满足。