藍牙Mesh 1.1版本中引入了遠端配置和無線裝置韌體更新（OTA DFU）的功能。本文將透過廣泛部署基於Silicon Labs（芯科科技）的xG24和xG21無線SoC開發板的節點並組成網路，來分析在多個測試節點上進行的一系列實驗結果，進一步探索藍牙Mesh 1.1網路的性能，包括網路延遲、遠端配置和OTA、DFU性能的詳細測試設置和結果等實用資料。

測試網路及條件

隨著網路中節點數量的增加或資料包負載的增加，延遲也會相應增加。相比於有效負載，網路對延遲的影響較小，但後者可能導致延遲大幅增加。

測試環境是位於布達佩斯的Silicon Labs商業辦公樓，其範圍內有Wi-Fi和低功耗藍牙網路，本實驗相關的無線測試功能集（wireless test clusters）分別部署在走廊、會議室、辦公室和開放區域。由於測試是在真實環境中進行的，背景噪訊聲一直存在。這些噪聲來自員工在辦公室使用的藍牙與Wi-Fi裝置，以及辦公室的其他測試台。不過，測試過程還是採取了一些降噪措施。這些測試是在工作日的晚上和週末進行的，目的是消除辦公室的一些噪聲來源。

在位於辦公室的大型網路測試裝置上，進行了多播延遲（multicast latency）和OTA DFU測試。總共有43個盒子分散在地板上，每個盒子包含4～6個設備，在網路中自然發生跳躍的大面積上創建一個256個節點的網路。每個盒子包含6個Silicon Labs的無線入門套件（WSTK），除了其中的一個盒子僅包含四個WSTK。

前27個盒子有4個EFR32xG24和2個無線電板（Wireless Gecko Starter Kit）。盒子28～42號則有3個EFR32xG24和3個EFR32xG21無線電板。43號箱有4塊EFR32xG24射頻板和1塊EFR32xG21射頻板。辦公室呈矩形，邊長分別為38公尺和19公尺。由於樓梯、電梯、浴室和不同的空間設置，有18.5m x 7.5m的區域沒有放置設備。

圖一 : 網路測試環境的設置佈局

圖二 : 本實驗在辦公樓裡測試所設置的網路盒子

延遲測試和遠端發送測試都是在一個射頻遮罩多跳測試網路上進行的。8個射頻隔離箱通過SMA和衰減桶（attenuation barrels）連接在一起，每個隔離箱至少包含一個EFR32xG24射頻板，用於藍牙Mesh測試用例。我們進行了以下幾項主要測試和分析，以實際掌握藍牙Mesh 1.1網路的性能。

延遲測試（Latency Test）

在露天和射頻遮罩環境中測試了延遲，其中包括了單播測試（Unicast Test）與多播測試（Multicast Test）。

單播測試（Unicast Test）

在這個測試中，以定義的速率發送單播一對一有效負載訊息並測量資料包往返時間，方法是讓客戶端模型以兩種方式之一確認伺服器模式發送的資料包：包括分段PDU（Packet Data Unit）的較低傳輸層確認，以及未分段PDU的客戶端模型層確認。

多播測試（Multicast Test）

對於此測試，有一個伺服器節點和多個客戶端節點訂閱了一個網路位址。伺服器將資料封包傳送到該位址，並分別測量每個客戶端在給定客戶端上發送和接收之間的時間。該測試在大型露天網路上運行。

單播和多播延遲測試的推理

隨著有效負載大小從 8 位元組增加到 32 位元組，由於網路需要傳輸更多的封包，所以延遲時間也隨之增加。我們可以發現，透過向網路添加更多封包，延遲會線性增加。單一網格資料封包只能傳輸 12 位元組的有效負載。隨著節點數量從10增加到256，我們也可以觀察到，更高比例的高負載大小的訊息（16位元和32位元）被接收節點成功接收。

在所有情況下，大多數 8 位元組有效負載都會在發送後 10 毫秒內收到。即使有 6 跳數，大多數 8 位元組有效負載也會在 120 毫秒內發送。這表明資料封包通常必須較小，才能更快地發送並成功接收。分段會增加一些延遲，但在 8 位元PDU大小下，即使我們強制分段，這種延遲也幾乎無法測量。

廣告擴展測試結果

廣告擴展（Advertising Extension）是一種非標準藍牙功能，可透過廣告「資料封包」忠實傳輸更大的資料有效負載，其大小比沒有AE傳輸的資料大得多。AE使網格訊息大小從 29 位元增加到最大 236 位元。

從上圖可以看出，對於給定的節點網路規模（256 個節點），與不使用 AE 時相比，使用廣告擴展功能可以成功傳輸和接收更大比例的各種大小資料封包。還可以觀察到延遲顯著改善，因為在所有測量的 PDU 大小中，大多數資料包在 40 毫秒內到達，因為不需要分段和重組。

遠端配置測試

對於遠端配置效能測試（Remote Provisioning Test），使用多跳設置，根據網路中的跳數測量效能。建立了射頻屏蔽環境，以濾除辦公區域持續存在的干擾。現有且不斷變化的射頻條件使該環境接近現實生活場景。這種設定確保沒有射頻干擾影響測試，最大限度地減少變異性，同時還在網路中創建六跳。隨著跳數的增加，配置時間也會增加，這是可以預料的，因為訊息封包會出現更多的來回衝突，特別是當訊息封包被接收方確認時的節點上。

無線裝置韌體更新測試

對於無線裝置韌體更新（OTA DFU Test）效能測試，由於節點數量較多，無法形成屏蔽環境，因此測試是在辦公室無人存在的時段進行的，整個樓層的測試台都處於關閉狀態。這使得測試能夠在稍微更規範的環境中進行。OTA DFU 的效能方面在未分配中繼的 60 節點設定中進行了測試。在啟用廣告擴充（AE）功能的情況下也測量了分發時間。

測試設定

在這次的大規模網路設置中，使用了GSDK中現成的範例應用程式來配置分發器和啟動器節點，並只更改了一些參數。分發器運行的是Bluetooth Mesh - SoC DFU分發器範例應用程式，而啟動器則在EFR32xG24板上運行Bluetooth Mesh NCP Empty v1.1範例應用程式。目標節點運行在ER32xG21和EFR32xG24板上，運行的是Bluetooth Mesh - SoC Sensor Server範例應用程式。分發器和啟動器的選擇方式是使它們靠近網路的中心，並且彼此相近。測試是在網路PDU大小增加（廣告擴展）的情況下或不增加的情況下運行的。

過程中使用了兩個GBL文件作為更新目標。一個是節點無法驗證的虛擬圖像，另一個是節點在分發後成功應用的真實SOC sensor server GBL文件。在虛擬影像的情況下，預期的測試結果是節點會在最後報告一個『驗證失敗』的狀態。

在圖三中，橙色圓圈表示啟動器和分發器節點的位置。淡藍色區域是用來形成網路的群集（每個包含六個設備），並用實心藍色框表示。這種設置方式提供了一個有效的測試環境，能夠準確地評估和優化網路性能。

圖三 : 60節點網路平面圖

結語

藍牙Mesh的性能測試結果顯示，當有效負載能夠包含在單個資料封包中時，其延遲表現極佳。如果有效負載小於16位元，即使在6跳的情況下，延遲也可以保持在200毫秒以下。

然而，對於較大的網路，隨著網路中節點數量的增加或資料包負載的增加，延遲也會相應增加。相比於有效負載大小，網路大小對延遲的影響較小，但後者可能導致延遲的大幅增加。

在進行這些測試時，這些網路的可靠性均超過99%。因此，為了在藍牙Mesh應用中實現低延遲和高可靠性，我們建議應用程式的有效負載應適合單個資料封包，並且需要多播消息傳遞的應用程式應避免使用分段消息。

此外，我們還需要進行更多的測試來進一步定義裝置行為和網路操作。例如，我們可以進行長時間的穩定性測試，以觀察網路性能是否會隨著時間的推移而下降。在進行測試時，我們應該注意，在測試期間刪除網路中的節點，以進行故障測試，並評估其對恢復時間和可靠性的影響。

當然，還應該在不同類型的設備上進行測試，包括在系統單晶片和網路輔助處理器（NCP）模式下運行的設備。以前的測試已經揭示了這些操作模式之間的一些差異，因此應該進一步描述這些差異。這些都是在進行後續測試時需要注意的事項。透過這些測試，就可以更深入地理解藍牙Mesh的性能，並找出優化其性能的方法。