智能家居和智能建筑等产品的开发者可以使用大量的无线协议。 Zigbee，Z-Wave，以及专有的无线协议，在这些市场中占据了主导地位，新的进入者还包括Thread 和蓝牙网格。 虽然传统的BLE和 Wi-Fi 在这些市场上也很流行，但它们不支持网状网络。 无论底层协议如何，物联网的部署网络必须是健壮的，这种稳健性可以通过测量吞吐量、延迟和可靠性来量化。 这些测量取决于部署规模的大小和其他系统级别的需求。
在Mesh协议方面,"没有一种协议可以适合任意情况"。 每个无线协议都有独特的特性和优点，这取决于应用场景和最终应用。 理解Mesh技术的内部机制要优于具体技术的一系列关键特征。 更重要的是，开发人员需要了解这些网络协议在功耗、吞吐量、延迟、可伸缩性、安全性以及互联网连接等关键领域的表现。 Zigbee，Thread 和蓝牙mesh的设计有着本质的不同，每种Mesh的实现方式都会对系统性能和健壮性产生影响。
无线连接的Mesh技术
无线芯片上的SoC已经具备了成本效益，足以被添加到物联网中，为我们的日常生活提供了方便、安全和舒适的体验。 当添加了无线连接时，一个个的物就变成了物联网设备。 许多物联网设备以前都没有无线互联网连接。 不断变化的规则和消费者的期望迫使产品制造商在无数产品和系统中添加无线连接，以保持竞争力或为新的收入流提供可能。 当开发者选择构建物联网设备时，必须考虑如何使用最终产品以及这些产品将在何种生态系统中运行。
无线网络的种类
在众多物联网无线技术中存在两种基本拓扑: Mesh（网格） 和 Star （星形）(图1)。 由于能够扩展到无数的节点并且覆盖很长的距离，因此它Mesh在家庭和智能建筑中通常比星型网络更受欢迎。 星际网络依赖于端节点和中央设备之间的点对点连接。 如果在安装了网络之后环境发生了变化，那么一个星型网络可能就会发生故障。
图1 两种基本拓扑结构
在点对点或星网中，信号范围是输出功率的函数。 为了确保设备可以在电池上运行足够长的时间或提高能源效率，理想的方案是减少功率消耗和输出功率。 然而，尽管功耗减少，设备仍然需要能够与其他设备进行通信和互动。 Mesh网络中的每个设备都传输较短的距离，以减少其功耗。 当通信在Mesh网络上的设备之间传输时，系统的总通信范围可以得到改进。
Mesh网络也提供了额外的通信优势，例如它们具有动态自愈能力。 例如，如果一个网格网络中的一个节点失败，则可以通过重新路由以提高可靠性。 网格网络的另一个重要好处是设备可以直接相互通信。
哪个网络最适合家庭和智能建筑？
Mesh网络提供了一种理想的技术来实现和加强一些应用，如上所述的建筑和家庭自动化，照明系统和零售beacon系统。 Mesh网络允许系统减少电力消耗，提高电池寿命，扩大通信范围，提高整个系统的可靠性。
每个网格网络标准为不同的设备类型和应用提供基于标准的支持。 有一个成熟的应用层支持家庭自动化，照明和计量，而***个蓝牙Mesh规范主要关注照明和一些家庭自动化支持。 Thread是三种Mesh技术中唯一基于 IPv6的网格技术。 这提供了一些独特的好处，例如在同一个网络或跨网络上的端到端路由和地址，而不需要实现额外的翻译层。
Zigbee 通常用于建筑和家用设备的自动化。 最近，针对这些应用也在考虑Thread 和蓝牙Mesh。 Z-wave 是另一种Mesh技术，在智能家居的安全应用中也很流行。
表1 3种协议的对比
大多数连接设备受益于连接到云端的使用场景，例如数据聚合。 支持低耗电蓝牙的蓝牙网格设备可以通过智能手机或平板电脑为云提供连接。 当然，这是一个暂时的连接，因为如果手机或平板电脑不存在，这些设备将无法连接到云端来发送或接收信息。 需要一个云连接的网关，而基于 IP 连接的 Thread 并不需要在网状网络之间建立一个完整的网关。 通过Thread，路由器能够以较轻的权重方式促进在 IP 上直接进行设备对云的通信。
智能家居和智能建筑包括能量采集设备、电池供电设备和有线设备的组合。 照明和恒温器通常是有线的，因为它们是基础设施的一部分，但这并不意味着功耗可以被忽略。 因此，必须谨慎管理作为基础设施的设备组成以及交流电的设备。电池通常为远程传感器和控制元件提供动力。 这意味着Mesh必须从功率角度理解两个根本不同的应用场景。
应用场景
在智能家居和智能建筑中有许多潜在的Mesh网络应用场景。利用Mesh网络，整个系统性能和终端用户体验可以得到显著的改善。 通过建筑和家庭自动化，设备可以直接相互沟通。 在光开关上的一个动作可以立即发送到本地网格网络的灯光，而不需要通过通向云端的网关进行通信。这种类型的即时反应可以提高消费者的体验。 此外，对于一些使用情况，例如在火灾报警时关闭空调的 HVAC 系统，网状网络上的局部通信可以确保系统正确运行而不依赖云连接。
舒适
对于照明系统，可以简化部署和管理。 Mesh网络提供的扩展连接范围意味着可以在更远的地方部署连接灯。 一个集线器或网关可以放置在一个位置，和连接的灯光共同部署。 随着每一个节点的部署，通信的范围增加，允许一个单一的网关有效地覆盖更大的区域。
例如，考虑一下剧院或博物馆的照明和环境控制。 这些装置通常有成百上千个节点。 灯光、窗帘的马达和百叶窗需要精确和精心设计的控制。 所有的灯光都要同时调暗，控制窗帘的马达应该一致工作。 细微的差异是显而易见的，并且会减少观众的体验。
家里也有类似的需求。 如果在一个有灯光和窗帘的场景，用户期望一个无缝的且精心设计的体验，可能是所有的灯光同时暗淡，所有的窗帘都会同时移动。
安全
像仓库这样的工业环境可能比剧院有不同的照明需求。 通常，一个区域的灯光是同时打开的。 然而，如果这些灯光一起亮起来，或者只需要几秒钟就能照亮所有的灯，这并不重要。 用户体验和期望是不同的。 另一方面，如果由于停电，某些灯需要快速打开，时间突然又变得重要起来。
方便
在部署过程中，如果每盏灯都一致亮着，这也许并不重要。 然而，如果开发者想要添加额外的服务，那么网络的强大程度就有可能成为问题。
在部署Mesh的过程中越来越受欢迎的服务是资产跟踪。 在这种情况下，设计者依赖于控制网络来传输关于被安装的设备，进而追踪资产的数据。 在这个例子中，吞吐量和延迟问题取决于资产信息在网络中传播的速度。
图2 网络连接带来的增值服务
另外，用于零售营销或资产追踪的Beacon可以不要求每一个都在手机的范围内来管理。 还可以将这些领域和设备类型的功能结合起来。 例如，灯不仅可以自动化，还可以充当Beacon。 这种方法可以通过增加位置服务和广告等功能来增加灯的功能和价值。
应用层的协议支持
协议的全部功能也取决于相应的应用层。 虽然Thread协议不包括应用层，但可以使用任何基于 ip 的应用层，如 dotdot 或 OCF。 蓝牙包括一个名为 Mesh 模型的本地应用层，这是一个全新的应用层，支持不同的设备类型，但相比 Zigbee 或 Thread 更加有限。 蓝牙Mesh对于照明和通用控制的支持都有很好的支持，比如 on / off，传感器，滑块，电源和电池状态，但对许多家庭配件缺乏专门的模型，如门锁，HVAC，或窗口覆盖特定的功能定义的互操作性。
表2 协议对应用层的原生支持
哪种Mesh协议***？
不能一概而论。 在 Zigbee，Thread 和蓝牙Mesh之间存在着基本的架构差异。 ZigBee和 Thread 可以在使用时可能会用到flooding，但通常使用路由网格来最小化网络开销，从而干扰信息传递。 蓝牙Mesh则允许设备的配置作为路由器来减少flooding的影响。 蓝牙技术联盟(SIG)将此称为"托管式洪峰处理"。
ZigBee和 Thread 网络包括路由节点和终端节点。 路由节点通常是线路供电的，可以作为Mesh的骨干。 端节点通常由电池驱动，在网格的外围运行，并使用路由器传递信息。 在创建网格时，将建立路由表。 路由表是一个分类目录，它告诉每个设备如何与网格中的其他设备进行通信。 通过这种方式，一个节点可以通过网格以精确的路径发送消息，有效地与另一个节点进行通信。 这对网格的吞吐量有积极的影响，并且可以随着网格的增长而减少延迟。
在历史上，路由网格更受欢迎，因为它提供了更高效的通信和可预测的性能。 另一方面，对于协议栈的开发人员来说，路由更难实现。
已经部署的系统，一个产品必须可以交互操作是一个重要的因素考虑。 以住宅为例，其中一些设备可能使用 Zigbee 或 Thread 形成一个Mesh网络。 一个网关或者一个集线器和网关的组合很可能已经将这些设备连接到云端以获得额外的服务。 手机可能也会与云沟通，然后再回到设备上。
为了支持电话到设备的直接通信，或者支持一个生态系统，如苹果 HomeKit，蓝牙连接是必需的。 如果所有的设备都支持该协议，蓝牙就可以与另一个Mesh网络结合起来，或者单独作为一个Mesh网络使用。 在设备中增加对多个协议的支持也可以提供好处，比如使用手机在没有Zigbee 或 Thread 网络的情况下安装或使用设备。
连接需求应该考虑整个生态系统，从终端设备，到任何网关或中心，到应用程序层和服务提供者。 网络技术，如 Zigbee 和蓝牙网格，不能本地支持 IP 必须首先适应网关的 IP。 这个过程涉及到将网络级有效载荷映射到 IP 数据报上，并将网络级有效载荷重新打包。 相比之下，本地网络本身支持 IP，如 Thread，可以在不干预的情况下提前和路由应用程序有效载荷。 在本地网络中加密的数据包可以保持端到端的安全。
ZigBee 和 Thread 的包结构
Zigbee 和 Thread 都使用 IEEE 802.15.4中127字节的数据包，基础数据速率为250 kbps。 虽然相同，但数据包结构不同，导致有效负载的大小略有不同。 图2显示了 Zigbee 数据包格式，结果是一个68字节的有效负载。 对于68字节以上的有效载荷，Zigbee 将碎片分成多个数据包。 Thread数据包格式如图3所示，结果是一个63字节的有效负载。 对于63字节以上的有效载荷，thread协议栈使用6LoWPAN。这些都是构建应用程序时需要关注的设计参数。
图3 ZigBee 的数据包格式
图4 Thread 的数据包格式
它们都会将较大的信息分解成更小的信息。 对于 Zigbee 来说，应用层会发生分段处理，并且从源到目的地进行端到端的执行。 对于线程来说，分割是在6LoWPAN 层完成的。
- 对于这些网络中的单播转发，一旦设备准备好发送，消息就会被转发。 对于多播转发，有一些网络需求:
- 对于 Zigbee 设备来说，只在64毫秒抖动之后，设备才会发送多播消息。 然而，在重新传输初始消息之前，启动装置有500毫秒的间隔。
Thread设备使用 RFC7731 MPL 转发多播消息。涓流计时器被设置为64毫秒，这样设备在重新发送之前可以随机返回。
BLE 的包结构
BLE有如下的数据包结构，以减少无线传输时间和功耗。 蓝牙Mesh进一步完善了这个数据包结构，增加了网格和安全性能。
图5 蓝牙Mesh 的数据包结构
这意味着蓝牙Mesh只有12或16个字节可用于有效负载，除此之外，数据包被分割成单独的数据包，然后在目的地重新组装。 这个分段包携带一个header，标识应用中有效负载的分段和12字节，但***一段除外，它们可以更短。 然而，蓝牙网格规范空间中需要额外的处理这些分段包，从而增加了延迟并减少吞吐量。 由于所有的吞吐量和延迟分析都是基于应用的有效负载，可以看到，蓝牙网格将需要比 Zigbee 或 Thread 更多的数据包。
路由与flooding的对比
Zigbee，Thread 和蓝牙网络是为智能家居和智能建筑设计的。 Zigbee 支持几种路由技术，包括用于路由发现的flooding或群组消息; 网格中控制消息的下一跳路由; 以及通向网关的多对一路由，然后使用到设备的源路由。 Zigbee 网络同时使用所有这些方法也是正常的。
Thread也支持下一跳路由和flooding。 然而，Thread网络将下一跳路由维护到所有路由器，作为正常网络维护的一部分，而不是一个执行路由发现的设备。 Thread还将处理可伸缩性的活跃路由器数量降到***。 以前，这被视为嵌入式802.15.4网络的限制，因为网络在大量路由器的存在下flooding限制了组播通信的频率和可靠性。 需要注意的是，Thread网络管理了活跃路由器的数目和间隔，不需要用户干预或管理。
蓝牙网支持管理flooding。 这是Mesh上的一个微调，用户可以指定哪些设备参与了flooding。 这将减少flooding的影响，但需要用户确定其网络中路由器的适当密度和拓扑结构，这可能变得很困难。 随着网络条件的变化，哪些设备参与了flooding也可能需要改变，这也将需要用户干预。
蓝牙还有类似于 Zigbee 或 Thread 的终端设备，称为"友邻"设备。 一个友邻装置与一个相邻的有线节点耦合在一起，而友邻的数据包则由有线节点存储。 友邻设备会定期醒来询问邻居是否有任何数据包。 有线节点只在一定的时间段内保存数据包，所以"友邻"需要使用其配对的中继节点进行签入。
图6 蓝牙Mesh 示例
对网格拓扑的研究可以分析网络规模。 这些网络表现得差异很大，在考虑10节点网络或200节点网络时，路由和管理技术往往需要改变。
通常情况下，在一个小网络中，设备可以通过一两跳和非常简单的路由或flooding就可以适合。 随着网络规模的扩大，增加了复杂性，例如设备间的更多的跳跃; 设备的密度，这可能干扰彼此发送消息; 更多的关注延迟和可靠性。 如果使用flooding类型的信息来打开100盏灯，通常不能接受只打开了98或99个开关。 这种类型的问题在10节点网络中很少见，但在100节点网络中可能变得普遍。
硅实验室的测试结论
为了最小化设备测试的可变性，测试可以在固定拓扑中进行，在这些拓扑结构中，射频路径通过分路器和衰减器连接在一起，以确保该拓扑不会随着时间和测试而改变。 硅实验室采用了七跳测试，以确保网络拓扑。 当然，MAC地址过滤也可以用来实现网络拓扑。
关注的度量指标
在以前应用场景中，设计者希望为应用建立一个健壮的网络。 在评估网络的健壮性时，需要关注的测量指标包括吞吐量、延迟和可靠性。 这三种测量方法可以准确地预测给定网络的健壮性。
- 吞吐量： 定义了网络的可伸缩性(有多少设备可以发送正常的流量) ，以及高级数据操作的行为，如向设备推送固件更新
- 时延： 描述了行动的发生需要多长时间。 它是涉及最终用户交互的关键参数(而不是机器对机器的通信) ，因为很多人能够体会到超过100毫秒的操作。 对于需要同时进行操作的过程，例如打开多盏灯，时间必须低于100毫秒，以便最终用户不会抱怨灯光连续亮起时产生"爆米花"效应。
- 可靠性： 但是当用户与诸如灯光和开关等日常设备互动时，用户期望100% 的可靠性。 实际上，硅谷实验室测试的可靠性达到99.999% 。
无论使用什么样的无线技术，这些都是Mesh网络测量的关键因素，并且与设备和无线系统的设计目标密切相关。
基准测试
硅实验室使用了无线 Gecko SoC 平台进行了测试，该平台可以运行蓝牙网、线程、 Zigbee 和专有协议， 同时使用了硅实验室的蓝牙、线程和 Zigbee 软件协议栈。 测试环境是一个商业办公大楼，有活跃的 Wi-Fi 和 Zigbee 网络。 无线测试集群被部署在走廊、会议室、办公室和空旷地区。
100字节有效负载的吞吐量
图7 吞吐量与多跳的对比
典型的网络包括两到三跳，吞吐量根据跳数不同而变化，协议性能随着跳数的增加而变得相似，蓝牙Mesh的小数据包有效负载导致吞吐量减少。
四跳的时延
图8 4跳网络的时延
- 所有的协议都在较小的有效负载时提供了类似的延迟
- 当有效负载大小增加时，Thread(6LowPAN)实现了***的效率和延迟性能。
- Zigbee 有很好的效率，但是一些应用层分段处理，
- 蓝牙Mesh 的延迟随着由于数据包大小和由此产生的分段蠢了，有效负载大小降低较多。
小载荷小型网络
图9 多播时延
- 三种协议的峰值都低于50毫秒，
- 它们网络膨胀后均已扩大至90毫秒，远低于200毫秒的市场目标。
- 另外，所有协议的多播都提供了非常高的可靠性。
具有中等载荷的小型网络
图10 中载荷小网络的多播时延
- 在延迟高达100毫秒(ms)的情况下，Thread表现***。
- Zigbee 执行的数据包大多数具有80ms 的延迟，逐渐扩展到130 ms。
- 蓝牙网格延迟在60毫秒，扩展到250毫秒。
- 所有192个节点均为蓝牙Nesh中继节点，没有进行中继节点进行优化。
带有小载荷的大型网络
图11 小载荷大网络的多播时延
- 在延迟扩展到100毫秒的情况下，线程表现***。
- Zigbee 执行的数据包大多数具有80ms 的延迟，逐渐扩展到130 ms。
- 蓝牙网格延迟在60毫秒，扩展到250毫秒
- 所有192个节点均为蓝牙网格继电器，没有进行继电器优化
测试结果
- Thread、 Zigbee 和蓝牙Mesh在小型网络中的较小有效载荷下能进行类似的操作
- 当有效负载和吞吐量需求增加时，Thread 和 Zigbee 的性能比蓝牙Mesh要好
- 随着网络规模的增长，这三种方式的延迟都会增加，但是蓝牙Mesh的增长***
- 选择物联网无线连接解决方案应该包括额外的标准，如预期的生态系统和功耗需求
- 对于大型蓝牙Mesh，可以利用中继节点优化来优化性能
- 当短消息(11B)特别用于多播消息时，蓝牙Mesh效果***
结论
基于所使用解决方案的理论网络大小不能准确反映网络在实际实现中所需节点的数目。 实际的限制是基于一些因素，包括网络拓扑、数据包大小以及吞吐量和延迟等性能要求。 例如，一个 Zigbee 的设备子网在100个设备中有一个实际的限制，尽管可以部署极大的商业系统，比如在拉斯维加斯的 Aria 酒店，拥有超过80000个有多个子网的 Zigbee 网络设备。 1.1协议针对每个网络约250个节点进行了优化，但是由于线程是基于 IP 的，边界路由器使得网络更容易扩展和分布。
Mesh网络的选择取决于终端应用程序或生态系统。 有许多已经建立了的生态系统，如飞利浦 Hue，亚马逊 Echo Plus 和 Comcast Xfinity。 如果一个设备制造商想与这些生态系统进行交互操作，Zigbee 是***选择。 如果没有为应用程序指定生态系统，那么还有许多其他的协议选择。
Thread和蓝牙Mesh都是可行的选择，也是除了 Zigbee 之外最常见的选择。 集成电路供应商提供的开发工具在Mesh网络开发的速度上有很大的影响。 数据包跟踪和多节点能量分析等工具可以确保所选择的Mesh网络得到有力的支撑。 最终，网络的大小，所需的延迟，预期的吞吐量和整体的可靠性将驱动网格协议的选择。
本文编译自以下3篇文章：
http://www.embedded-computing.com/iot/how-zigbee-thread-and-bluetooth-mesh-stack-up-in-performance-benchmarking
https://www.silabs.com/products/wireless/learning-center/mesh-performance
https://www.silabs.com/whitepapers/selecting-the-appropriate-wireless-mesh-network-technology
【本文来自51CTO专栏作者“老曹”的原创文章，作者微信公众号：喔家ArchiSelf,id:wrieless-com】
