實測藍(lán)牙Mesh 1.1性能更新 深入理解并徹底優(yōu)化
藍(lán)牙Mesh 1.1版本中引入了遠(yuǎn)程配置和無線裝置韌體更新(OTA DFU)的功能。本文將透過廣泛部署基于Silicon Labs(芯科科技)的xG24和xG21無線SoC開發(fā)板的節(jié)點并組成網(wǎng)絡(luò),來分析在多個測試節(jié)點上進行的一系列實驗結(jié)果,進一步探索藍(lán)牙Mesh 1.1網(wǎng)絡(luò)的性能,包括網(wǎng)絡(luò)等待時間、遠(yuǎn)程配置和OTA、DFU性能的詳細(xì)測試設(shè)置和結(jié)果等實用資料。
測試網(wǎng)絡(luò)及條件
隨著網(wǎng)絡(luò)中節(jié)點數(shù)量的增加或數(shù)據(jù)報負(fù)載的增加,延遲也會相應(yīng)增加。相比于有效負(fù)載,網(wǎng)絡(luò)對延遲的影響較小,但后者可能導(dǎo)致延遲大幅增加。
測試環(huán)境是位于布達(dá)佩斯的Silicon Labs商業(yè)辦公樓,其范圍內(nèi)有Wi-Fi和低功耗藍(lán)牙網(wǎng)絡(luò),本實驗相關(guān)的無線測試功能集(wireless test clusters)分別部署在走廊、會議室、辦公室和開放區(qū)域。由于測試是在真實環(huán)境中進行的,背景噪訊聲一直存在。這些噪聲來自員工在辦公室使用的藍(lán)牙與Wi-Fi裝置,以及辦公室的其他測試臺。不過,測試過程還是采取了一些降噪措施。這些測試是在工作日的晚上和周末進行的,目的是消除辦公室的一些噪聲來源。
在位于辦公室的大型網(wǎng)絡(luò)測試裝置上,進行了多播延遲(multicast latency)和OTA DFU測試??偣灿?3個盒子分散在地板上,每個盒子包含4~6個設(shè)備,在網(wǎng)絡(luò)中自然發(fā)生跳躍的大面積上創(chuàng)建一個256個節(jié)點的網(wǎng)絡(luò)。每個盒子包含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公尺。由于樓梯、電梯、浴室和不同的空間設(shè)置,有18.5m x 7.5m的區(qū)域沒有放置設(shè)備。
圖一 : 網(wǎng)絡(luò)測試環(huán)境的設(shè)置布局
圖二 : 本實驗在辦公樓里測試所設(shè)置的網(wǎng)絡(luò)盒子
延遲測試和遠(yuǎn)程發(fā)送測試都是在一個射頻屏蔽多跳測試網(wǎng)絡(luò)上進行的。8個射頻隔離箱通過SMA和衰減桶(attenuation barrels)連接在一起,每個隔離箱至少包含一個EFR32xG24射頻板,用于藍(lán)牙Mesh測試用例。我們進行了以下幾項主要測試和分析,以實際掌握藍(lán)牙Mesh 1.1網(wǎng)絡(luò)的性能。
延遲測試(Latency Test)
在露天和射頻屏蔽環(huán)境中測試了延遲,其中包括了單播測試(Unicast Test)與多播測試(Multicast Test)。
單播測試(Unicast Test)
在這個測試中,以定義的速率發(fā)送單播一對一有效負(fù)載訊息并測量數(shù)據(jù)報往返時間,方法是讓客戶端模型以兩種方式之一確認(rèn)服務(wù)器模式發(fā)送的數(shù)據(jù)報:包括分段PDU(Packet Data Unit)的較低傳輸層確認(rèn),以及未分段PDU的客戶端模型層確認(rèn)。
多播測試(Multicast Test)
對于此測試,有一個服務(wù)器節(jié)點和多個客戶端節(jié)點訂閱了一個網(wǎng)絡(luò)地址。服務(wù)器將數(shù)據(jù)封包傳送到該地址,并分別測量每個客戶端在給定客戶端上發(fā)送和接收之間的時間。該測試在大型露天網(wǎng)絡(luò)上運行。
單播和多播延遲測試的推理
隨著有效負(fù)載大小從 8 字節(jié)增加到 32 字節(jié),由于網(wǎng)絡(luò)需要傳輸更多的封包,所以延遲時間也隨之增加。我們可以發(fā)現(xiàn),透過向網(wǎng)絡(luò)添加更多封包,延遲會線性增加。單一網(wǎng)格數(shù)據(jù)封包只能傳輸 12 字節(jié)的有效負(fù)載。隨著節(jié)點數(shù)量從10增加到256,我們也可以觀察到,更高比例的高負(fù)載大小的訊息(16位和32位)被接收節(jié)點成功接收。
在所有情況下,大多數(shù) 8 字節(jié)有效負(fù)載都會在發(fā)送后 10 毫秒內(nèi)收到。即使有 6 跳數(shù),大多數(shù) 8 字節(jié)有效負(fù)載也會在 120 毫秒內(nèi)發(fā)送。這表明數(shù)據(jù)封包通常必須較小,才能更快地發(fā)送并成功接收。分段會增加一些延遲,但在 8 位PDU大小下,即使我們強制分段,這種延遲也幾乎無法測量。
廣告擴展測試結(jié)果
廣告擴展(Advertising Extension)是一種非標(biāo)準(zhǔn)藍(lán)牙功能,可透過廣告「數(shù)據(jù)封包」忠實傳輸更大的數(shù)據(jù)有效負(fù)載,其大小比沒有AE傳輸?shù)臄?shù)據(jù)大得多。AE使網(wǎng)格訊息大小從 29 位增加到最大 236 位。
從上圖可以看出,對于給定的節(jié)點網(wǎng)絡(luò)規(guī)模(256 個節(jié)點),與不使用 AE 時相比,使用廣告擴展功能可以成功傳輸和接收更大比例的各種大小數(shù)據(jù)封包。還可以觀察到延遲顯著改善,因為在所有測量的 PDU 大小中,大多數(shù)數(shù)據(jù)報在 40 毫秒內(nèi)到達(dá),因為不需要分段和重組。
遠(yuǎn)程配置測試
對于遠(yuǎn)程配置效能測試(Remote Provisioning Test),使用多跳設(shè)置,根據(jù)網(wǎng)絡(luò)中的跳數(shù)測量效能。建立了射頻屏蔽環(huán)境,以濾除辦公區(qū)域持續(xù)存在的干擾?,F(xiàn)有且不斷變化的射頻條件使該環(huán)境接近現(xiàn)實生活場景。這種設(shè)定確保沒有射頻干擾影響測試,最大限度地減少變異性,同時還在網(wǎng)絡(luò)中創(chuàng)建六跳。隨著跳數(shù)的增加,配置時間也會增加,這是可以預(yù)料的,因為訊息封包會出現(xiàn)更多的來回沖突,特別是當(dāng)訊息封包被接收方確認(rèn)時的節(jié)點上。
無線裝置韌體更新測試
對于無線裝置韌體更新(OTA DFU Test)效能測試,由于節(jié)點數(shù)量較多,無法形成屏蔽環(huán)境,因此測試是在辦公室無人存在的時段進行的,整個樓層的測試臺都處于關(guān)閉狀態(tài)。這使得測試能夠在稍微更規(guī)范的環(huán)境中進行。OTA DFU 的效能方面在未分配中繼的 60 節(jié)點設(shè)定中進行了測試。在啟用廣告擴充(AE)功能的情況下也測量了分發(fā)時間。
測試設(shè)定
在這次的大規(guī)模網(wǎng)絡(luò)設(shè)置中,使用了GSDK中現(xiàn)成的范例應(yīng)用程序來配置分發(fā)器和啟動器節(jié)點,并只更改了一些參數(shù)。分發(fā)器運行的是Bluetooth Mesh - SoC DFU分發(fā)器范例應(yīng)用程序,而啟動器則在EFR32xG24板上運行Bluetooth Mesh NCP Empty v1.1范例應(yīng)用程序。目標(biāo)節(jié)點運行在ER32xG21和EFR32xG24板上,運行的是Bluetooth Mesh - SoC Sensor Server范例應(yīng)用程序。分發(fā)器和啟動器的選擇方式是使它們靠近網(wǎng)絡(luò)的中心,并且彼此相近。測試是在網(wǎng)絡(luò)PDU大小增加(廣告擴展)的情況下或不增加的情況下運行的。
過程中使用了兩個GBL文件作為更新目標(biāo)。一個是節(jié)點無法驗證的虛擬圖像,另一個是節(jié)點在分發(fā)后成功應(yīng)用的真實SOC sensor server GBL文件。在虛擬圖像的情況下,預(yù)期的測試結(jié)果是節(jié)點會在最后報告一個『驗證失敗』的狀態(tài)。
在圖三中,橙色圓圈表示啟動器和分發(fā)器節(jié)點的位置。淡藍(lán)色區(qū)域是用來形成網(wǎng)絡(luò)的群集(每個包含六個設(shè)備),并用實心藍(lán)色框表示。這種設(shè)置方式提供了一個有效的測試環(huán)境,能夠準(zhǔn)確地評估和優(yōu)化網(wǎng)絡(luò)性能。
圖三 : 60節(jié)點網(wǎng)絡(luò)平面圖
結(jié)語
藍(lán)牙Mesh的性能測試結(jié)果顯示,當(dāng)有效負(fù)載能夠包含在單個資料封包中時,其延遲表現(xiàn)極佳。如果有效負(fù)載小于16位,即使在6跳的情況下,延遲也可以保持在200毫秒以下。
然而,對于較大的網(wǎng)絡(luò),隨著網(wǎng)絡(luò)中節(jié)點數(shù)量的增加或數(shù)據(jù)報負(fù)載的增加,延遲也會相應(yīng)增加。相比于有效負(fù)載大小,網(wǎng)絡(luò)大小對延遲的影響較小,但后者可能導(dǎo)致延遲的大幅增加。
在進行這些測試時,這些網(wǎng)絡(luò)的可靠性均超過99%。因此,為了在藍(lán)牙Mesh應(yīng)用中實現(xiàn)低延遲和高可靠性,我們建議應(yīng)用程序的有效負(fù)載應(yīng)適合單個數(shù)據(jù)封包,并且需要多播消息傳遞的應(yīng)用程序應(yīng)避免使用分段消息。
此外,我們還需要進行更多的測試來進一步定義裝置行為和網(wǎng)絡(luò)操作。例如,我們可以進行長時間的穩(wěn)定性測試,以觀察網(wǎng)絡(luò)性能是否會隨著時間的推移而下降。在進行測試時,我們應(yīng)該注意,在測試期間刪除網(wǎng)絡(luò)中的節(jié)點,以進行故障測試,并評估其對恢復(fù)時間和可靠性的影響。
當(dāng)然,還應(yīng)該在不同類型的設(shè)備上進行測試,包括在系統(tǒng)單芯片和網(wǎng)絡(luò)協(xié)處理器(NCP)模式下運行的設(shè)備。以前的測試已經(jīng)揭示了這些操作模式之間的一些差異,因此應(yīng)該進一步描述這些差異。這些都是在進行后續(xù)測試時需要注意的事項。透過這些測試,就可以更深入地理解藍(lán)牙Mesh的性能,并找出優(yōu)化其性能的方法。
評論