kaiyun官方注册
您所在的位置: 首页> 电源技术> 业界动态> 探索Zigbee网状网络性能

探索Zigbee网状网络性能

2019-09-05
关键词: ZigBee 网状网络性能

640.webp.jpg

  本应用指南详细介绍了测试Zigbee网状网络性能的方法。随着当今无线市场上可用的网状网络数量不断增加,设计人员必须了解这些网络的使用情况及其预期性能。选择网络或设备时,设计人员需要了解网络的性能和行为特征,如电池寿命、网络吞吐量和延迟,以及网络规模对可扩展性和可靠性的影响。

  本应用指南介绍了 Zigbee 网状网络在性能和行为方面与其他网状网络的不同。使用能够运行 Zigbee Mesh 和专有协议的 Silicon Labs Zigbee Mesh 软件堆栈和Silicon Labs Wireless Gecko SoC 平台进行了测试。测试环境是一个商业办公大楼,范围内有 Wi-Fi 和 Zigbee 网络。在走廊、会议室、办公室和开放区域部署了无线测试集群。定义了执行基准测试的方法,以便其他人可以运行相同的测试。这些结果主要用于为设计实践和原则以及预期的现场性能结果提供指导。

  内容要点

  说明了 Silicon Labs 研发 (R&D) 中的无线测试网络。

  评估了无线条件和环境。

  介绍了网状网络性能,包括吞吐量、延迟和大型网络可扩展性。

  阅读完整的Zigbee网状网络性能测试报告:https://www.silabs.com/documents/login/application-notes/an1138-zigbee-mesh-network-performance-cn.pdf

  有关其他技术的性能基准测试信息,请参阅http://www.silabs.com/mesh-performance

  介绍和背景

  在开发人员会议和行业白皮书中,Silicon Labs 提供了嵌入式网状网络的性能测试结果。系统设计人员可以使用吞吐量、延迟和安全影响等基本性能数据来定义预期行为。测试是通过我们的各种网状网络技术完成的 – Zigbee、Thread 和 Bluetooth,每种都单独做了介绍。本应用指南介绍了Zigbee 网络的性能。

  基础物理层和数据包结构

  网络性能取决于有效荷载的大小,这是因为数据包开销中不包含应用的使用。

  Zigbee 使用 IEEE 802.15.4 2006,127 字节数据包和250 kbps 的基础数据速率。Zigbee 数据包格式显示如下,结果为 68 字节有效荷载。对于 68 字节以上的有效荷载,Zigbee 会分成多个数据包。我们的性能数据取决于有效荷载大小,因为这是构建应用时需要考虑的设计参数。

640.webp (3).jpg

  Zigbee数据包格式

  网络路由差异

  Zigbee 专为家庭和建筑自动化设计。Zigbee 支持多种路由技术,包括用于路由发现或组消息的网状网络泛洪、用于网状网络中受控消息的下一跳路由、以及到网关后再使用源路由发送到设备的多对一路由。Zigbee 网络通常会同时使用这些方法。

  网络将较大的消息分成较小的消息。对于 Zigbee,分段是在应用层完成的,并且从源到目标是端到端。

  对于这些网络中的单播转发,只要设备准备好发送,就会转发该消息。对于多播转发,通常有关于如何转发消息的网络要求。对于 Zigbee 设备,只有在抖动达到 64 毫秒后才能通过设备转发多播消息。但是,在重发初始消息之前,发起设备有 500 毫秒的时间差。

  Note: 此性能数据适用于 Silicon Labs 实现这些网状网络堆栈。正如为此测试提供的测试网络和基础设施所显示的那样,未使用其他堆栈或系统执行测试。

  目标和方法

  本应用指南定义了一系列用于评估网状网络性能、可扩展性和可靠性的测试。描述了测试条件和基础设施,以及消息延迟和可靠性。该测试是通过测试网络中的实际无线设备进行的,而不是模拟。

  此测试主要为了提供不同网格技术之间的对比,以更好地理解和推荐其用途。不同的网络和系统设计对设备和网络有不同的要求。因此,没有一个网络能够满足所有的网络要求。但是,我们要对比的三种网状网络技术都是针对家庭和商业建筑中用于安防监控的低功耗和电池供电网状网络。

  通常,分析网络性能数据时,我们会考虑可以对网络进行哪些改进以提高性能。因为目前关于大型网络的网状网络性能的公开数据有限,所以很难就可能的改进或变化进行行业讨论。例如,在商业建筑中,人们担心:

  其他网络流量,因为可能有许多子网互相干扰。

  正常建筑 Wi-Fi 基础设施的 Wi-Fi 干扰,因为这些技术通常在 2.4 GHz ISM 频段中运行。

  网络吞吐量和延迟以及大型网络多播延迟和可靠性,这是因为多播常被用于密集办公环境中的照明控制,并且系统用户预期照明控制会有响应性。

  Note: 这里的测试结果仅限于在正常运行条件下比较系统性能,或者在特定测试中指出的压力下进行比较。本应用指南不提供系统干扰或其他此类影响的解决方案,这可参考其他已公布的结果。不过,测试是在我们的SiliconLabs R&D 设施进行的,其RF范围内有超过100个Wi-Fi接入点。该设施还有一个 300 节点的Zigbee照明网络,该网络不属于本测试的一部分,而是用于普通照明控制。

  其他性能测试回顾

  没有用于评估和报告大型网络可靠性、可扩展性或延迟的具体、已定义方法。过去,Silicon Labs 发表了多篇论文,根据网络测试对比网络性能。测试主要关注设备行为以及对电池寿命、网络吞吐量和延迟的影响。大规模多播测试还需要从大型分布式网络中采集准确的时间和可靠性信息。所有测试均使用能够运行 Zigbee、Thread、Bluetooth Mesh、和专有 RF 协议的 Silicon Labs Wireless Gecko SoC 平台执行,以避免测试中设备本身造成的差异。先前公布的结果有收发器、网络协处理器和片上系统设计之间的差异。这些设备全部使用片上系统设计。

  其他关于性能的论文有 Kui Liu 编写的关于 Zigbee 网络性能的硕士毕业论文“嵌入式电表的 Zigbee 网络性能评估”,由瑞典皇家理工学院电气工程系出版。对于单跳内的露天往返时间,他们测试了不同的范围,结果如下:

640.webp (2).jpg

  距离和平均往返行程的数据包丢失

  该测试使用100毫秒间隔的50字节有效荷载单播,安全关闭。请注意,Zigbee 不允许关闭安全。结果显示1跳测试一直需要约18毫秒的往返时间。在室内使用各种干扰条件重复进行该测试,发现1跳的往返时间与18毫秒相差不大。未提供多跳测试结果。

  测试网络和条件

  为了最大限度地减少差异,设备测试也可以在固定拓扑结构中执行,其中 RF 路径通过分路器和衰减器连接在一起,以确保拓扑结构不会随时间和测试而发生变化。此方法在 7 跳测试中用以保证网络拓扑。MAC 过滤也可用于实现网络拓扑。

  大型网络测试最好在露天环境中进行,其中设备行为取决于现有的和变化的 RF 条件。Silicon Labs R&D 设施即被用于此露天测试。

  设施和测试网络条件

  Silicon Labs R&D 设施包含一个带电梯井的中央核心,其他服务在大楼西端并有开放式平面图,办公室和会议室位于东端。整个设施占地约 120 英尺乘 200 英尺。下图显示了设施布局。较深的线代表坚硬的墙壁,其他所有部分都使用立方体分隔。

  测试设备安装在设施周围的不同位置。这些设备都有以太网反向信道连接,以允许:

  固件更新

  命令行接口

  脚本处理

  定时分析

  数据包采集

  能量测量

640.webp (1).jpg

  典型测试集群

  测试集群分布在整个设施中,包括高低位置、开放区域以及封闭的会议室和办公室。

  该测试网络会定期添加或移除设备,但在进行此测试时,它包含以下设备:

  EM35xx 设备

  EFR32 Mighty Gecko 设备

  这个网络代表了网络和软件质量保证团队用于露天测试的设备。所有设备均由中央测试服务器和基础设施控制,可进行脚本式的回归测试或由工程师手动测试。

  测试和结果

  吞吐量和延迟

  在受控网络(有线配置)中测试了吞吐量和延迟,以测试各种数据包有效荷载下的跳频。正常配置是测试 6 个跳频。

  测试是使用一个源节点和一系列路由节点完成的,以便更改跳频数量。

  测试使用以下配置:

  Zigbee 应用层消息

  延迟测试使用的数据包有效荷载为 50 字节到 300 字节,50 字节为增量

  测试时开启安全

  从 1 到 6 跳

  飞行模式下使用 2 个数据包(第 3 个在收到第 1 个确认时发送…)

  在给定确认时间的情况下尽可能快地发送

  测量往返延迟(源到目的地到源),以毫秒为单位

  对于各个网状网络,当我们如上所述增加有效荷载大小时,数据包分段行为不同。使用较大的数据包大小取决于应用层,但我们在此提供比较数据,以说明发生分段时的相对性能。

  Zigbee 多跳延迟

  在这个多跳延迟测试中有多个值得注意的地方:

  对于高达 250 字节的 1 跳有效荷载,我们看到延迟非常低 (60 毫秒)。

  对于 50 字节的有效荷载(包含在 1 个数据包内),Zigbee 在 6 跳内保持了 140 毫秒以下的延迟。

  在载荷超过 150 字节且跳数超过 5 之前,延迟保持在 200 毫秒以下。

  Zigbee 大型网络测试结果

  Zigbee 测试是使用最新版本的 Zigbee 堆栈完成的。Zigbee 网络测试使用 5、25 和 50 字节的载荷完成,正常广播传输间隔为 3 秒。

  测试时有以下值得注意的地方:

  随着数据包有效荷载的增加,设备的延迟也增加。这是预料中的正常的行为,因为传输较大的数据包需要更多时间。

  我们看到所有测试的可靠性都是 100%。注意这些是 100 个广播测试。对于低于 100 广播的测试,可以使用较大的测试以更好地测量可靠性。

  随着网络规模的增长,我们看到延迟也会增加和扩散,这是因为它需要多跳才能发送完所有消息。在较大的网络中,因为所有设备都在尝试重复消息,所以广播中竞争也更多。

  该测试使用 3 秒的广播间隔,即在发送下一条消息之前,给网络一些恢复时间。下面分别显示了各个测试中当广播间隔减少时发生的情况。

  缩短间隔的 Zigbee 网络测试

  众所周知,应该尽量避免在 15.4 网络中使用广播,因为它们会导致网络暂时泛洪。Zigbee 网络有广播交易记录,可以防止重复处理设备转发的广播。该广播表必须包含至少 9 个条目,并且它们会在 9 秒后失效,这意味着平均每秒只支持 1 个广播。因为上述测试使用的是 3 秒的广播间隔,所以又使用 2 秒和 1 秒的间隔进行了其他测试,以分析相对网络规模的影响。

  小结

  Zigbee 表现出优异的可靠性且延迟低于通常人类与设备互动所需的 200 毫秒时间。Zigbee 网络在我们测试的 192 节点的网络中表现良好,但如果广播频率太高,Zigbee 也会显示延迟增加。

  随着网络规模的增加,增加的跳数和广播拥塞会导致延迟有一定程度的增加。随着数据包有效荷载的增加,网络中的延迟也会增加,但这在测试 5、25 和50字节的有效荷载时影响较小。广播间隔降低到 1 秒时,最大延迟会增加,这对于某些应用可能会不太理想。

  后续测试注意事项

  本应用指南中描述的测试需要进行后续测试,以进一步定义设备行为和网络运行。为后续测试记录了以下具体项目:

  这些测试中可以添加故障测试以评估恢复时间和对可靠性的影响,方法是将节点从网络中删除。

  测试应使用在片上系统和网络协处理器 (NCP) 模式下运行的不同设备类型执行。先前的测试发现这些运行模式之间的一些差异,因此应进一步表征。


本站内容除特别声明的原创文章之外,转载内容只为传递更多信息,并不代表本网站赞同其观点。转载的所有的文章、图片、音/视频文件等资料的版权归版权所有权人所有。本站采用的非本站原创文章及图片等内容无法一一联系确认版权者。如涉及作品内容、版权和其它问题,请及时通过电子邮件或电话通知我们,以便迅速采取适当措施,避免给双方造成不必要的经济损失。联系电话:010-82306116;邮箱:aet@chinaaet.com。
Baidu
map