藍牙Mesh, ZIGBEE, THREAD網(wǎng)絡性能對比?
novaa 智聯(lián)網(wǎng)事 智聯(lián)網(wǎng)事
微信號iotthings
功能介紹讓思緒, 漂一會;
昨天
本文測試數(shù)據(jù)主要基于SILABS的應用文檔"AN1142 - 網(wǎng)狀網(wǎng)絡性能對比"。針對藍牙Mesh性能及特點，可參考
藍牙Mesh網(wǎng)絡性能及網(wǎng)絡特點總結(一)
藍牙Mesh網(wǎng)絡性能及網(wǎng)絡特點總結(二)
目錄
三種Mesh網(wǎng)絡概述
吞吐率和延時性能對比
網(wǎng)絡性能對比
總結
] 1 [ 三種Mesh網(wǎng)絡概述
首先，我們看下三種Mesh技術的概覽及網(wǎng)絡模型，如圖1，2，3，4。
圖1 - Mesh網(wǎng)絡概覽
圖2 - Thread網(wǎng)絡模型
圖3 - Zigbee網(wǎng)絡模型
圖4 - BLE Mesh網(wǎng)絡模型
本文的測試，均是Silabs在研發(fā)中心實際環(huán)境測試，具體可參考上篇文章。
] 1 [ 吞吐率和延遲測試比拼
吞吐率及傳輸延時的測試在一個穩(wěn)定的6Hop拓撲下進行(通過衰減器搭建的穩(wěn)定的6跳網(wǎng)絡)，測試節(jié)點拓撲如下圖。本測試結果主要取決于協(xié)議棧本身的PHY及MAC的特性;
圖 - 6跳網(wǎng)絡示意圖
本測試針對未分段8bytes小數(shù)據(jù)傳輸下的性能及100Bytes的大數(shù)據(jù)傳輸下的數(shù)據(jù)吞吐率性能進行了驗證。分別如圖5和圖6;我查了下Thread和Zigbee的MAC層結構，都是按照802.15.4的MAC和PHY;由于文檔中沒有針對具體的數(shù)據(jù)收發(fā)情景做出說明，圖5與圖6顯示Thread能夠有更好的結果，大概率與Thread的最終PHY數(shù)據(jù)包結構有關系;有深入看過協(xié)議的朋友可以分享下~
而藍牙由于分包機制，在大數(shù)據(jù)包情況下，數(shù)據(jù)吞吐率，嗯，非常穩(wěn)定;
圖 5 - 8 Bytes吞吐率對比
圖 6 - 100 Bytes吞吐率對比
同時，針對小數(shù)據(jù)包的數(shù)據(jù)通信延時如圖7，這里不得不說，憑什么拿20Bytes的Thread和50Bytes的ZIGBEE對比? 這點不理解?
圖 7 - 8 Bytes通信延時對比
接著， SILABS針對4HOP的拓撲下的不同數(shù)據(jù)長度做了延時的對比，結果如下，簡單而言，由于Payload的增大，不同拓撲的分包機制帶來的傳輸延時會成比例增加。當然，我也不理解為什么結果中，ZIGBEE與藍牙Mesh均是 點狀結果+ 預估趨勢線而 Thread則是實線? 且Thread分包帶來的影響如此之小??
圖 8 - 4 Hops下不同數(shù)據(jù)包延時對比
] 2 [ 網(wǎng)絡性能測試
針對Mesh網(wǎng)絡實際應用，實際環(huán)境下的不同大小網(wǎng)絡的性能，也是驗證協(xié)議棧性能及穩(wěn)定性，實用性的重要方面;Silabs的網(wǎng)絡性能測試，基于如下不同大小的網(wǎng)絡，測試100包不同大小數(shù)據(jù)的傳輸延時及數(shù)據(jù)包成功接收比例;
小型網(wǎng)絡： 24節(jié)點
中型網(wǎng)絡：1~48節(jié)點
中型網(wǎng)絡：2~96節(jié)點
大型網(wǎng)絡：1~144節(jié)點
大型網(wǎng)絡：2~192節(jié)點
> 24節(jié)點網(wǎng)絡性能測試
測試結果如下圖10，三種網(wǎng)絡在約100ms內完成100個數(shù)據(jù)包的傳輸，而可以看到的是Thread總體完成時間更快更高效;
圖 10- 24節(jié)點100Bytes數(shù)據(jù)包網(wǎng)絡性能對比
而如果增大數(shù)據(jù)包大小，Thread和Zigbee采用50Bytes，藍牙Mesh 32 Bytes情況下，測試結果如下圖11。可以看到Thread還能夠在穩(wěn)定的100ms內完成，而Zigbee時間明顯的增加，藍牙Mesh則呈現(xiàn)出了按時間平均分布的傳包率，延時大大增加;從這個結果，結合藍牙基于Flooding的技術，基因決定藍牙Mesh適合小數(shù)據(jù)包?
圖 11 - 24節(jié)點100Bytes數(shù)據(jù)包網(wǎng)絡性能對比
> 192節(jié)點網(wǎng)絡性能測試
隨著網(wǎng)絡增大，存在的沖突會增加，跳數(shù)會增加，對應會導致傳輸延時的增加;192節(jié)點小數(shù)據(jù)包的傳輸延時如下圖12，這里需要注意的是，藍牙Mesh有~3%的數(shù)據(jù)包超過250ms才完成傳輸(有多少傳輸最終失敗就不清楚了，也不明白為什么藍牙不能是5Bytes)
圖 12 - 192節(jié)點5 Bytes數(shù)據(jù)包網(wǎng)絡性能對比
隨著數(shù)據(jù)包的增大，分包導致的沖突阻塞，25Bytes下(藍牙16Bytes)的測試結果如下圖13
圖 13 - 192節(jié)點25 Bytes數(shù)據(jù)包網(wǎng)絡性能對比
] 3 [ 總結
總體來說，本篇應用文檔的測試合理性，數(shù)據(jù)測試及統(tǒng)計具體方法，分析，信息都不夠;應用文檔里面也有說明，ZIGBEE 他們從2006年開始，Thread從2015，而BLE Mesh從2017，他們針對不同協(xié)議的優(yōu)化程度都不一致;
但是從協(xié)議角度看， Thread與Zigbee基于同PHY和MAC，其特性類似;但是藍牙Mesh由于采用了Flooding技術，其在大網(wǎng)絡及大數(shù)據(jù)包情況下，顯得更力不從心;
Mesh網(wǎng)絡的性能，穩(wěn)定性，實用性，不是簡單的通過數(shù)據(jù)吞吐及數(shù)據(jù)通信延時能夠衡量，綜上...
下載文檔
