【p2p、分布式，区块链笔记 MESH】论文阅读 Thread/OpenThread Low-Power Wireless Multihop Net

关注

原创 2025-06-04 19:52:42 2.5k 阅读 AI 写同款· GEO 优化 ›

已知文件名取文件所在目录何志丹已知文件名,如何取文件所在目录?最简单的方法是从后向前找"//".但有时,文件名中没有"//",这时要先转化一下.具体代码如下:CString GetPathName(const CString strPathFileName){ //取阅读详情

paper	author
Thread/OpenThread: A Compromise in Low-Power Wireless Multihop Network Architecture for the Internet of Things	Hyung-Sin Kim, Sam Kumar, and David E. Culler

Thread 是一种近期标准化的低功耗物联网网络协议，由以 Google/Nest 为首的行业联盟 Thread Group 推动。本文作者基于 RPL 和 Thread 的技术规范，对其技术特点进行了对比分析，并解释了为何在未来的互联网中，相较于使用 RPL，采用 Thread 可能更具合理性。

摘要

为了支持未来的物联网（IoT），有必要通过多跳无线连接将资源受限的节点（如嵌入式传感器和执行器）扩展到互联网子网中。RPL 是为低功耗、易丢包网络设计的 IPv6 路由标准，旨在实现这一目标，但在实际中并未被广泛采用。作为替代方案，Thread 是一种近期标准化的低功耗物联网网络协议，由以 Google/Nest 为首的行业联盟 Thread Group 推动。
本文基于 RPL 和 Thread 的技术规范，对其技术特性进行了对比分析，解释了为何在未来的互联网中，相较于 RPL，采用 Thread 更具合理性。具体而言，RPL 和 Thread 在应用范围和多跳网络架构方面存在根本性差异，这些差异促成了 Thread 独特的设计以及相较于 RPL 的优势。
最后，我们在一个室内多跳无线测试平台上，使用官方开源实现 OpenThread 对 Thread 协议进行了评估。本研究是学术界对 Thread 协议的首次分析。

引言

互联网的应用范围正在不断扩展。如今，使用可穿戴设备、智能音箱等智能设备组建子网已变得司空见惯，物联网（IoT）正在逐步实现。然而，目前的物联网主要集中在无线连接功能强大的设备，这些设备通常靠近边界路由器（例如智能手机或 WiFi 接入点）。而未来物联网发展的自然下一步，是进一步扩展无线子网，纳入各种嵌入式或电池供电的传感器与执行器，使其能够灵活部署在远离边界路由器的位置。
实现这一愿景需要跨学科的协作，结合两个领域的力量：低功耗/易丢包网络（LLNs，或称无线传感器网络 WSNs）与互联网。这项工作实际上早在十多年前就已启动，并在 2008 年通过 6LoWPAN 实现了在 IEEE 802.15.4 低功耗无线链路上传输 IPv6，从而将互联网连接扩展到了资源受限的嵌入式设备 [1]。进一步地，RPL 作为 LLNs 的 IPv6 路由协议，于 2012 年被标准化 [2]。RPL 旨在通过多跳无线连接，将数千个资源受限、电池供电的设备构建为一个 IPv6 子网。尽管 RPL 在过去六年中受到广泛关注，并催生了大量研究工作，但它仍存在许多未解决的问题，阻碍了其在实际中的广泛应用（除 Cisco 的 Connected-Grid Mesh 外）[3, 4]。目前，实际的物联网应用大多仍采用高功耗的单跳 WiFi 来连接“物”，或者干脆用其他低功耗的单跳无线技术（如蓝牙低功耗）取代了互联网连接。
相比之下，早在二十年前低功耗无线网络（LLN）刚兴起时 [5]，研究人员就预期不久后会出现实用且可扩展的多跳无线系统。然而，构建一个由无人值守、周期性工作的节点组成的可靠多跳网络一直被认为极具挑战性。随着物联网的兴起，低功耗无线网络再次受到关注，但业界普遍仍认为多跳低功耗无线网络不够可靠，且电池寿命难以满足实际需求 [6]。要实现这一领域的突破，唯一的办法就是拿出切实可行的实证，证明它确实能够稳定运行。
为此，一个名为 Thread Group 的工业联盟近期对 Thread 协议进行了标准化 [7]。Thread 是一种基于 IPv6 的新型低功耗网状网络，其设计理念包括以下几点：
1. 鉴于互联网核心本身已经具备全球可扩展性，试图再构建一个由数千个嵌入式设备组成的低功耗子网不仅困难重重，而且并非必要，甚至有些过度设计。
2. 在嵌入式网络中，将多个协议层协同设计比让每一层独立工作更为合理。
因此，与 RPL 不同，Thread 从物理层到网络层都有明确规范，并将扩展规模限定在几百个嵌入式设备以内（Thread 使用网状网络拓扑，这意味着每个设备（节点）都可以作为数据传输的中继点（路由器）。这种设计有助于扩展网络覆盖范围并提高可靠性。然而，随着网络规模的增大，路由表和邻接表等信息也会增长，这可能会增加内存使用量并对性能产生影响。）。Thread 在依赖其他现有标准完成部分协议栈的同时，也设计了自己的路由协议，并设置了明确的架构限制：一个网络分区最多只能有 32 个路由器，这些路由器必须始终保持开启（即无线电不可进行休眠周期）。分区内的其他节点被称为叶子节点，可以进行周期性休眠，但它们始终与至少一个常开的路由器保持一跳距离。这一架构限制将路由功能与低功耗操作解耦，使 Thread 能在路由器之间构建可靠的网状网络，同时为电池供电的叶子节点提供低功耗运行能力。为了避免因不同实现方式带来的兼容性问题，Thread Group 的主要成员 Google/Nest 发布了一个官方的 Thread 开源实现，称为 OpenThread。
借助其开源实现、对实际应用的关注以及来自业界的强大推动力，Thread 值得深入研究，并具有实际应用的潜力。然而，作为一项新近标准，Thread 的技术细节尚未在学术界得到充分探讨。作为一个起点，本文通过与 RPL 的对比分析，探讨了 Thread 在路由方面的设计，以展示它为何可能成为未来物联网的合理选择。我们还讨论了将“互联网”真正引入“物联网”的未来发展方向。我们的目标并非评判哪个协议更优，而是介绍 Thread 作为一种新兴的低功耗物联网协议，表明它具有足够的研究价值，值得在未来物联网的发展中加以深入探讨。

RPL 标准

本节简要概述了 RPL 的设计目标与主要特性。

设计目标与架构

RPL 路由协议的设计旨在同时实现三个高度挑战性的目标：可扩展性、可靠性以及资源/能效效率。具体而言，RPL 旨在构建一个 IPv6 子网，该子网由数千个资源受限的节点组成，通过多跳低功耗无线链路进行连接，既能实现可靠的数据传输，又能支持多年的电池续航。
此外，RPL 明确定位为纯粹的路由协议，不对节点的其他特性设限；任何节点都可以作为路由器，也可以是电池供电的设备，从而简化部署过程。然而，这种高远的目标加上灵活的架构，也对协议设计提出了极高要求：RPL 的路由机制必须在所有节点都既是路由器又是电池供电设备的情况下（这是无线传感器网络研究中的典型设定），依然能够同时保障可靠性和能效性。

设计选择与特性

为了满足上述需求，RPL 在借鉴以往无线传感器网络（WSN）研究成果的基础上 [8]，做出了两个重要的假设与设计选择：
面向上行的路由（Upward-Focused Routing）：
“多点到一点（MP2P）的流量模式在许多低功耗和易丢包网络（LLN）应用中占主导地位。”——IETF RFC 6550 [2]。
注：这是 RPL 的核心设计假设之一。RPL 认为，在大多数 LLN 应用中，网络中的多个传感器节点需要将数据上报给一个中心节点（例如边界路由器或数据汇聚节点）。因此，RPL 的路由机制以上行为主（即从多个节点到一个中心节点的数据流），优先优化这种 “多点到一点” 的通信模式。这一设计方向决定了 RPL 在路径构建、维护和路由选择策略上对上行数据传输进行了重点优化。
第一个假设是：LLN 中的流量主要是上行的，例如从嵌入式传感器向边界路由器收集数据。因此，尽管 RPL 支持双向通信（即上行和下行路由），但它的重点是构建可靠的上行路径。为此，RPL 构建了一种类森林的路由拓扑结构，称为面向目的地的有向无环图（DODAG），其根节点是边界路由器。每个节点根据与边界路由器的距离向量选择一个父节点，作为其上行路径的下一跳；而下行路径则通常被简单地设定为上行路径的反向。这种基于距离向量的上行路径代价称为 RANK，它通过广播 DODAG 信息对象（DIO，DODAG Information Object）消息在网络中传播。RANK 值越小表示越靠近 DODAG 根节点，从而帮助节点构建向上的数据传输路径。
Data-Reactive Route Update 基于数据的路由更新机制：
“数据流量可能并不频繁”，以及“典型的 LLN 存在物理连接变化，但这些变化通常是短暂且对通信影响较小的。”——IETF RFC 6550 [2]
注：这是 RPL 的第二个关键设计假设。RPL 认为在低功耗网络中，数据通信通常不是持续高频的，而且网络中的连接波动（如无线信号衰减或短暂干扰）大多数情况下不会严重影响数据传输。
基于这一假设，让控制平面持续维护一个与实际物理拓扑完全同步的路由结构，反而可能造成不必要的能量浪费。因此，RPL 采用了一种被动响应机制：它假设物理连接的变化是短暂且不频繁的，通过对数据传输结果的反馈来检测连接状态的变化，同时使用 Trickle 定时器机制 [9] 尽量减少控制包的发送频率。虽然路径代价（Path Cost）的具体设计并不被 RPL 标准强制规定，但“基于数据流量进行响应性路由更新”的设计理念，自然推动了 ETX（期望传输次数） 被广泛用作路径代价（即 RANK）指标。
- ETX（Expected Transmission Count）：衡量一个数据包成功传输所需的平均传输次数。
- 当无线链路变差，导致链路层需要多次重传数据包时，ETX 值会上升，表明该路径不再稳定。
附加特性与未涵盖方面：
除了前述设计选择外，RPL 还引入了多实例（multi-instance）功能以支持异构流量。在 RPL 中，每个实例都可以根据自身的服务质量（QoS）需求和路由度量标准，构建独立的路由拓扑结构。借助该功能，不同类型的数据流可以通过不同的路由路径到达同一个目的地。结果是，对于同一个节点，路由表中可能会存在多个条目，具体取决于该节点参与了多少个实例。这一设计提升了网络对多种应用需求的支持能力。

shortcomIngs of RPL

自六年前 RPL 推出以来，尽管它受到了广泛关注并催生了大量研究论文，但其实际应用却很有限，除了思科的 CGmesh 之外几乎未见大规模采用。这其中存在什么问题？我们将结合规范文档和相关文献揭示其背后的原因。欲了解更多详情，强烈推荐阅读近期关于 RPL 的综述文章，如文献 [3, 4]。

设计选择的反面影响

首先，RPL 的两个基本设计选择在实际物联网应用场景中被证明并不合适。
面向上行的路由：虽然上行流量在低功耗和易丢包网络（LLN）中占主导地位，但物联网应用中对下行流量的需求同样不可忽视。下行流量在执行控制命令、固件更新、基于确认的传输层协议（如 TCP）以及应用层确认（ACK）等场景中必不可少。此外，某些应用（例如电子货架标签）产生的下行流量甚至超过上行流量 [10]。
然而，RPL 面向上行的设计导致下行路由既不可靠也难以扩展 [4]。具体来说，当无线物理连接发生变化时，下行路由的更新非常缓慢：需要先经历上行数据传输失败（ETX 值增加）、上行路由更新，以及成功发送指向新上行路由的控制消息（目的地通告对象，DAO）。在此过程中，许多下行数据包可能会丢失。此外，RPL 的下行路由需要选择两种操作模式中的一种（MOP）：存储模式（基于路由表的路由）或非存储模式（源路由），这两种模式分别面临内存开销和路由头开销的问题。这些开销限制了 RPL 在拥有成千上万个资源受限节点的网络中构建大规模下行路由的能力。
基于数据的路由更新：虽然利用数据流量进行路由更新显著减少了控制开销，但也带来了稳定性和可靠性的问题。需要注意的是，数据包的主要作用是将重要信息传递到目的地，而不是用于辅助网络维护。然而，当网络连接发生变化时，RPL 无法在牺牲一定数量的数据包之前及时检测到这种变化，从而导致可靠性下降。
此外，RPL 代表性的路由度量指标 ETX 在无线链路状况恶劣时表现出诸多问题。与标准假设不同，低功耗网络中的数据流量不一定是稀疏的。一些应用，如结构监测和风速测量 [11]，需要频繁的数据上报以进行有效分析。在拥有成千上万个节点的大型网络中，靠近边界路由器的节点需要转发大量流量。大量流量会导致拥塞和隐藏终端问题，进而引发数据包丢失。此外，WiFi 等无线干扰也会导致显著的数据包丢失。在这种情况下，RPL 的路由拓扑会频繁剧烈变动 [12]。原因在于，当 ETX 变差时，RPL 会尝试更换路由，但路由更换无法解决由无线干扰和流量负载引起的链路质量问题，导致网络状态不断波动，影响整体稳定性。
尽管上述设计选择存在明显缺陷，但迄今尚未出现能够在灵活的网络架构中，同时满足可扩展性、可靠性和能源效率的优秀替代方案——这种架构要求所有节点既可以作为路由器，也可以是电池供电的设备。

sImultaneous complexIty and ambIguIty

制定协议标准的关键理念在于，所有遵循该标准的实现应能相互兼容，并且提供合理的性能。标准应为所有必要功能制定细致的指导方针，同时排除任何冗余的功能。
然而，RPL 标准包含一些不必要的功能，例如多实例/服务质量（QoS）度量（在嵌入式设备上几乎未被研究）以及与 IPv6 邻居发现（ND）功能重叠的路由消息。这些设计不仅增加了实现的复杂性和内存开销，却没有带来明显的益处。针对资源受限的嵌入式设备，协议应避免此类过度设计的特性。
与此同时，RPL 对许多必要功能的规范又不够充分。具体来说，尽管嵌入式网络实现应当实现纵向集成，RPL 却很少提供跨层操作的指导。虽然将邻居发现（ND）功能排除在路由标准之外是合理的，但遗憾的是，RPL 并未对外部 ND 机制或与 IPv6 ND 的互操作性提出完整的建议。
RPL 的复杂性和模糊性导致了多种不同的实现版本，这些版本在实现方式和功能上存在差异，从而降低了协议的互操作性和整体性能。

Thread标准

本节介绍 Thread，它是 RPL 的一种替代方案，作为低功耗多跳物联网网络协议。Thread 并不追求与 RPL 相同的设计目标和架构。相反，与 RPL 相比，Thread 放宽了设计目标，并提出了一种折中的网络架构，具体如下。
能源效率：“路由器不设计为休眠模式”，“睡眠终端设备（SED）是主设备，它们仅通过其父路由器通信，且不能为其他设备转发消息。”——摘自 Thread 1.1.1 规范 [7]
可扩展性：“Thread 专为智能家居应用设计”，“家庭网络规模从几个设备到数百个设备无缝通信”，“Thread 网络分区中最多可包含 32 个路由器。”——摘自 Thread 1.1.1 规范
与 RPL 相比，Thread 目标子网规模从成千上万个节点缩减到数百个节点（包括叶子节点），并且对路由器数量有明确的限制。适度的可扩展性不仅是一个折中选择，更避免了子网规模过大的问题。此外，路由器应具备持续供电能力，始终保持在线；而低功耗节点（通过周期性休眠实现节能）则被明确地与路由功能分离，专注于能源效率。这种设计使路由器能够专注于保证网络的可靠性，而电池供电的叶子节点则专注于低功耗操作。对于室内环境（电源插座充足）以及利用太阳能等方式供电的室外环境，这种“始终在线的路由器”限制是合理且可行的。
此外，考虑到嵌入式网络作为一个垂直封闭系统的特性，Thread 对多个层级（从物理层到网络层）进行了规范。除了提出自身的路由设计外，Thread 还规范了其他网络方面内容，如周期性休眠的介质访问控制（MAC，第二层）、地址分配以及设备配置管理。这种设计有效解决了复杂性和模糊性的问题。具体来说，Thread 的设计选择与 RPL 存在显著差异，如表 1 所示。

路由拓扑: two-tIer, AsymmetrIc, FuLL mesh

与 RPL 不同，Thread 提供了一个两层路由拓扑结构，考虑到了节点电源能力的异质性。由于路由器始终保持在线，路由器之间的拓扑不是森林结构，而是一个全网状结构。也就是说，每个路由器不仅拥有到边界路由器的路径成本（距离向量），还拥有到所有其他路由器的路径成本。每个路由器可以自主选择多个候选下一跳中的一个，以到达任何目的地。与 RPL 中下行路由被动地作为上行路由的反向路径确定不同，Thread 独立设置每条路径，这可能导致双向路由在某些情况下不对称。通过这种方式，Thread 不仅为上行流量提供了可靠的路由，还支持任意节点之间的通信。

路由更新：回归控制平面

RPL 使用 Trickle 算法[9]控制 DIO 消息的发送，既保证控制开销最小化，又实现快速路由恢复，其稳定状态下的 DIO 发送间隔长达几分钟。Thread 同样使用 Trickle 来设置通告消息的发送间隔，但由于 Thread 中的路由器并非低功耗设备，稳定状态下该间隔设置为 32 秒，远比 RPL 频繁。通过如此频繁的通告，Thread 可以依靠控制报文定期刷新整个网状路由，而不必依赖（不频繁的）数据传输。利用控制报文检测物理连接变化，使 Thread 更接近传统路由协议，而非 RPL 的反应式机制。
每个（低功耗）叶子节点则周期性唤醒，发送数据请求（保活）消息以检测与其父节点的连接状态。

路径代价：累积信噪比（SNR）

虽然 ETX（预期传输次数），即数据包接收率（PRR）的倒数，是一种非常直观且无需额外开销即可从数据传输经验中获得的度量，但它存在前面提到的问题，并且在低功耗无线网络（LLNs）中表现不够可靠。原因在于，PRR 与接收信号强度指示（RSSI）并非线性下降，而是在某个 RSSI 阈值（例如 –87 dBm）附近会突然从超过 90% 降至低于 10% [13]。ETX 可以在该阈值附近细致区分链路质量，但无法区分非常稳定的链路与可能较脆弱的链路。
例如，在选择上行路由时，两个候选链路的当前 ETX 都为 1（表示最佳质量），但一个链路的 RSSI 是 –50 dBm，另一个是 –80 dBm。虽然 –80 dBm 链路当前有良好的 PRR，但由于链路质量波动，未来很可能会跌破 –87 dBm 阈值变差。而 –50 dBm 的链路则更加稳定可靠，但 ETX 指标无法反映出这一差异。

吓一跳选择: tAbLe- And Address-drIven

RPL 对于向下流量的下一跳选择提供了非存储模式和存储模式，但这两种模式都存在可扩展性问题：分别是数据包开销和内存开销。

相比之下，Thread 仅在路由器之间利用路由表查找路由，这将内存开销限制在最多 32 条目。为了向叶节点提供路由，Thread 结合路由表和地址编码技术。由于叶节点只能通过其父路由器与其他节点通信，Thread 的目标是找到从源节点到父路由器的路径。

为此，Thread 在叶节点的地址中编码了父路由器的地址：在 16 位 IEEE 802.15.4 短地址字段中，前 6 位用于表示父路由器地址，后 10 位用于叶节点标识符。这样，当节点需要发送数据包给叶节点时，可以从叶节点地址中提取父路由器信息，并基于路由表找到通往父路由器的路由。

duty-cycLIng: LIsten-AFter-send

作为一个多层标准，Thread 规范了一个基于 IEEE 802.15.4 标准的 duty-cycling MAC 协议，即“发送后监听”机制。借助于始终在线的路由器，这种 duty-cycling 协议主要针对低功耗（周期性唤醒）叶节点与始终在线路由器之间的通信设计；叶节点之间没有直接通信。与大多数假设所有节点都周期唤醒的协议不同，Thread 的叶节点无需检测父路由器是否在线，使操作更加简单。具体来说，当叶节点有数据包发送给父路由器时，它只需唤醒、发送，然后进入休眠。目的地为叶节点的下行数据包则缓存在父路由器处。为了接收数据，叶节点会周期性地唤醒，向父路由器发送数据请求包，并在短时间内监听。父路由器收到请求后，会将缓存的数据包发送给叶节点。这个数据请求包同时也用于检测与父节点的连接状态。通过调节休眠间隔，duty-cycling 机制能够有效控制叶节点的能耗。
鉴于 RPL 可以与任何链路层协议（如 IEEE 802.15.4e 标准中的时间同步信道跳频 TSCH）结合使用，仍需研究 Thread 所采用的链路层协议在实际环境中的表现是否足够优越。

muLtIPLe border routers

实际应用中，任何节点都可能因各种原因失效，因此低功耗网络（LLNs）应避免过度依赖单一节点。即使单个边界路由器能连接所有节点，部署多个边界路由器仍然是必要的，以防止单点故障。
然而，RPL 的目的地导向无环图（DODAG）是以单一边界路由器为根节点构建的，因此要支持多个边界路由器，必须形成多个独立的 DODAG。此外，RPL 允许节点在每个实例中只能加入一个 DODAG，导致网络中出现两个或多个不相连的 DODAG，而无法构建一个充分利用所有潜在连接的整体拓扑。虽然 RPL 标准允许多个边界路由器协调形成一个以“虚拟”根为中心的单一 DODAG，但标准未提供实现该功能的具体指导，因此实际上没有 RPL 实现支持这一特性。
相比之下，Thread 采用全网状（full mesh）拓扑结构，而非 DODAG，因此能够将所有节点和多个边界路由器包含在同一条路由拓扑中，大大降低了实际管理的复杂度和负担。

OpenThread: A comPLete, oFFIcIAL, And oPen ImPLementAtIon oF threAd

OpenThread：Thread 的完整、官方且开源实现

从设计上看，Thread 解决了 RPL 的许多问题。然而，在低功耗网络（LLN）中，问题常常出在实现细节上。尤其是 RPL，一直受到实现不完整的困扰 [4]。为了解决这个问题，Thread Group 的主导成员 Google/Nest 开源了一个官方且完整的 Thread 实现，称为 OpenThread（https://openthread.io）。

OpenThread 是一个涵盖所有网络层的完整网络协议实现。它自带事件驱动内核，可以独立运行，也可以移植到嵌入式操作系统中。

为评估 OpenThread 的性能，我们将其移植到了开源嵌入式操作系统 RIOT-OS 上，并使用 Hamilton 嵌入式平台 [15] 进行测试。我们首先在以下两种场景下评估了叶节点的能耗：

周期性传感并向父节点发送数据
周期性接收来自父节点的数据
（每种情况每 10 秒一次，信道质量良好）

测试结果显示：作为叶节点的 Hamilton 设备分别消耗 30 mA 和 21 mA，配备 1400 mAh 电池时，预计使用寿命分别为 5.3 年和 7.6 年。

为评估路由性能，我们在办公室环境中使用 15 个 Hamilton 节点（包括边界路由器）构建了一个多跳测试平台。每个 Hamilton 节点作为路由器，使用 IEEE 802.15.4 无线电（250 kb/s 数据速率）定期向边界路由器发送数据包。

图 2 展示了 OpenThread 在不同总输入流量下的性能表现：

图 2a 显示随着负载增加，确实出现了更多的丢包；
但图 2b 表明，即使在严重丢包的情况下，OpenThread 仍然能维护网络拓扑，而不会使问题进一步恶化。

OpenThread 的开放性为我们系统性研究 Thread 的各个方面提供了可能，例如：链路/路径成本评估、负载均衡、设备接入配置、以及网络信息的及时传播等。

what else is missing?

Thread 和 RPL 都没有明确规定在 IPv6 之上的传输层或应用层协议。

RPL 由于专注于向上路由（从节点到网关），更适合需要单向流量的协议，如基于 UDP 的传感器上报协议。
而 Thread 同时支持向上和向下路由，因而更适合双向通信的协议。

例如，Thread 可以使用 TCP 来采集传感器数据，其中数据包沿一个方向传输，而 TCP 的确认包（ACK）则沿相反方向传输。
在 LLN 中使用 TCP 很有意义，因为它能提升与现有互联网服务（主要基于 TCP/IP）之间的互操作性 [11]。

实验验证

为了验证这一点，研究人员在相同的测试平台（图 1）中同时运行了 TCP 和 UDP，持续了 40 小时：

节点 11、12、13 和 14 每 10 秒生成一条消息；
节点 11 和 14 使用 UDP 发送；
节点 12 和 13 使用 TCP 发送。

值得注意的是：在实验环境中，白天有人活动及各种无线设备引起了明显的无线干扰。

图 3 显示了两种协议的可靠性（分别为两个使用该协议的节点的平均值）：
- UDP 在多跳、易丢包的无线网络中无法提供可靠的传输；
- 而 TCP 的可靠性接近 100%；
- 唯一一次下降发生在第 35 小时，Node 13 失去了连接，可能是由于 OpenThread 的路由失败造成的 —— 当前实现在恶劣环境下偶尔会发生这种断链现象。