Thread使用經過實踐驗證的標準和IPv6技術，以6LoWPAN為基礎，為產品開發人員提供了優于現有無線協議的許多技術優勢。Internet運行在 IP 之上。IP 技術使手機、路由器以及全球各地的設備相互通信，與具體的接入鏈路無關。 Thread為智能家居中的低功耗無線設備提供IP接入，使其更容易與家庭中的其它IP設備（如智能手機，平板電腦和計算機等）進行通信，以創建和控制Thread網絡。

在此過程中，Thread設備不需要專有網關或轉換器，就可以直接連接到與其互操作的其它設備。這減少了對基礎設施的需求和投資，潛在的故障點和維護負擔。它還使依賴任何額外的Thread產品更容易連接到手機和平板電腦等個人設備。 因為在同一個IP網絡中，Thread設備間不需要借助手機即可相互通信。使用其它技術的設備可以通過集線器或網關與Thread設備進行交互。

Thread與其它IP網絡技術結合，可以無縫連接眾多供應商的各種基于IP協議的物聯網終端設備，與各種云服務通信，可以同時運行多個應用層，如Matter，LWM2M，OCF或Weave。

測試目標與方法

本文對用于評估Thread網狀網絡的性能、可擴展性和可靠性的一系列測試進行了介紹。除對Thread消息延遲和可靠性進行介紹外，還對測試條件和基礎設施進行了介紹。本測試是在測試網絡中真實的無線設備上進行的，并非模擬環境。

進行本測試是為了對不同的網絡技術進行對比，以便更好地理解其用法并推而廣之。不同的網絡和系統設計對設備和網絡的要求不同。因此，沒有哪個網絡能夠滿足所有的網絡要求。然而，本文對比了三種網狀網絡技術，人們熱衷于將這些技術應用于低功耗和電池供電的網狀網絡，以對家庭和商業建筑進行監控。

在分析網絡性能數據時，通常會考慮可以對網絡進行哪些改進，從而提高性能。由于有關當今大型網絡中網狀網絡性能的公開數據有限，因此很難在行業層面上就可能的改進或變化進行討論。舉例來說，在商業建筑中，以下問題令人關切：

其他網絡流量，因為可能有許多相互干擾的子網。

來自常規建筑的Wi-Fi 基礎設施的無線干擾，因為這些技術通常在2.4GHz ISM頻段運行。

網絡吞吐量和延遲以及大型網絡多播延遲和可靠性，因為多播通常用于密集辦公環境中的照明控制，并且系統用戶期望照明控制可以快速響應。

注：本文測試結果僅限于在正常運行條件下或在特定測試中注明的壓力條件下對系統性能進行比較。本文并未明確解決系統干擾或其他類似的干擾的最終方案，盡管這些干擾已在其他已公布的測試結果中得以解決。但是，測試是在Silicon Labs的研發辦公場所中完成的，其RF 范圍內有100多個Wi-Fi接入點。此外，該場所還配置了300節點的Zigbee照明網絡，用于正常照明控制。

Thread測試網絡及環境

為了最大限度地降低不確定性，設備測試也會在固定拓撲中進行，射頻路徑通過分路器和衰減器連接在一起，以確保拓撲不會隨著時間和測試而改變。此方法用于7跳測試以確保網絡拓撲。MAC地址過濾也可以用于實現網絡拓撲。

典型的有線測試配置如下圖所示：

圖1. 抽屜內有線RF設備（帶有分路器和同軸電纜連接）

大型網絡測試最好在開放環境中進行，因為在這樣的環境中，設備行為基于現有的RF條件和不斷變化的RF條件。Silicon Labs的研發場所被用作這種開放環境的測試，Silicon Labs的研發場所包括：帶電梯井的中央核心區、大樓西端帶有開放樓層的其他服務區、以及東端的辦公室和會議室。整個研發場所寬約120英尺，長約200英尺。研發場所布局請見下圖。較暗的線條為實墻，其余則為隔間分區。

圖2. 用于無線測試的Silicon Labs研發場所布局測試設備安裝在研發場所周圍的不同位置。這些設備都具有以太網通道連接，以實現以下功能：

固件更新

命令行接口

腳本運行

時序分析

數據包捕獲

能耗測量

下圖中的測試簇包括以下內容：

六個EFR32MGxx設備

多頻段支持，以測試2.4 GHz（PCB天線）和私有sub-GHz協議（外部天線）

USB電源和以太網連接

圖3. 典型的測試簇測試簇分布在整個場所的不同位置、開放區域以及封閉的會議室和辦公室。

圖4. Silicon Labs研發場所中的測試簇此測試網絡可定期添加或刪除設備，但在開展本測試時，該網絡包含以下設備：

EM35xx設備

EFR32MGxx 設備

這些用于開放環境下測試的網絡設備也同樣被網絡和軟件質量保證團隊使用。所有設備都由中央測試服務器和基礎設施控制，允許工程師進行腳本回歸測試或手動測試。

吞吐量及延遲測試

吞吐量和延遲的測試在受控網絡（有線配置）內進行，以測試不同包負載下的每一跳。

配置通常能測試到7跳。測試是通過一個源節點和一系列目的節點來完成的，并允許改變跳數。

本測試通過以下配置完成：

帶有確認的CoAP可確認型消息

包負載從10字節到最多300字節不等，以10字節為增量進行延遲測試

使用Leader作為源節點，從1到7跳

僅傳輸1個包

考慮ack時序后，應盡可能快的發送

以毫秒為單位測量往返延遲（源節點到目的節點再返回到源節點）

對于每一個不同的網狀網絡而言，隨著包負載的不斷增大（如前所述），會產生不同的包分片。能否使用更大的包負載長度取決于應用層，但這里提供了比較數據以說明產生包分片時的相對性能。

Thread多跳延遲

Thread延遲測量采用給定負載大小的CoAP消息的往返時間。

圖5. Thread EFR32–CoAp平均往返延遲時間在該多跳延遲測試中，以下幾點值得注意。

在1跳、包負載最大300字節條件下，Thread的往返延遲維持在50毫秒以下，表現出色。

即便在最大7跳、負載為300字節條件下，EFR32的往返延遲也小于200毫秒。

對于負載在單個包（50-60字節）內的大多數應用來說，Thread可以維持在最大7跳的100毫秒以內往返延遲。

Thread網絡測試和網絡規模

為了在盡可能少的受控條件下驗證協議棧性能，需要采用更大的開放網絡測試環境。這些網絡被部署在Silicon Labs的普通辦公場所內，這些辦公場所有常見的Wi-Fi干擾、其他運行的網絡、樓宇控制系統。測試不會嘗試屏蔽這些網絡RF干擾。

用于測試每個協議棧的網絡如下：

小型網絡：24臺設備

中型網絡：1–48臺設備

中型網絡：2–96臺設備

大型網絡：1–144臺設備

大型網絡：2–192臺設備

注：對于以上任意一種測試來說，針對某組指定的測試，測試網絡中具體的設備數量可接受的浮動范圍為+/-10%。大型網絡中的測試是在設備的SoC模式下完成的。

這些網絡中的設備都是墻電供電設備，特別針對休眠終端設備的測試除外。

對于這些網絡，測試將驗證一組通信條件下的可靠性和延遲。測試的目的是對100多條消息進行測試，但為了可靠性，也會使用10，000條消息進行更長時間的測試。測試中會使用相同的設備，以保持不同測試下的網絡拓撲和密度是相似的。實際的空中條件會有所不同，這在這些測試中無法控制。

Thread大網絡測試結果

Thread測試是使用最新版本的Silicon Labs Thread協議棧完成的。

下圖說明了Thread網絡的多播行為。Thread網絡將路由器的數量限制在32個（含）以內，而且隨著網絡增長或條件變化，作為活動路由器的設備也會隨著時間而發生變化。非活動路由器的設備也被稱為具有路由器資格的終端設備（REED），這些設備作為RF常開子設備。初始設備發送廣播，RF范圍內的所有路由器以及以該初始設備作為父設備的任何REED設備都可以聽到該廣播。Thread規范要求REED與單個主要父設備同步，但同時也要至少與三個其他父設備同步以提高多播可靠性。

Thread設備采用32-64毫秒的多播退避機制，之后設備才會中繼多播。

圖6. Thread多播時序-EFR32 5字節負載和網絡規模

圖7. Thread多播時序-EFR32 25字節負載和網絡規模

圖8. Thread多播時序-EFR32 50字節負載和網絡規模測試結果如下：

不同網絡規模的Thread網絡行為是非常一致的，延遲隨著包大小的增加而增加。

Thread延遲不會隨著網絡規模的增大而延長，這是因為路由器較少，因而網絡中較少出現擁堵現象。

Thread在多播性能方面通常比Zigbee快一些，當網絡規模增大時速度更快。

這些測試均證明了100%的可靠性，但以下更大規模的測試則說明了網絡的可靠性。

以3秒的間隔進行測試，以與上面的Zigbee結果一致。Thread上較短的時間間隔不能顯示出性能差異，因此有必要運行下文提及的可靠性擴展測試，采用0.5秒廣播間隔，以顯示測試結果。

總結

Thread具有出色的可靠性和延遲，比通常200毫米的人機交互時間還短。即使在多播、大型網絡條件下，Thread網絡也能在0.5秒內完成流量處理并確保延遲和可靠性。即使網絡規模增大，Thread的網絡行為也幾乎沒有什么變化，這歸功于網絡層對于路由器的靈活配置。在某種程度上這是預期的，這是因為Thread設備采用了更新的架構，可以以更高的時鐘速度運行，而且有更多的RAM用于包處理。隨著包負載的增長，網絡延遲也會增加，但在5、25和50字節的負載測試中這種影響卻很小。