智能家居和智能建筑等產(chǎn)品的開(kāi)發(fā)者可以使用大量的無(wú)線協(xié)議。 Zigbee，Z-Wave，以及專(zhuān)有的無(wú)線協(xié)議，在這些市場(chǎng)中占據(jù)了主導(dǎo)地位，新的進(jìn)入者還包括Thread 和藍(lán)牙網(wǎng)格。 雖然傳統(tǒng)的BLE和 Wi-Fi 在這些市場(chǎng)上也很流行，但它們不支持網(wǎng)狀網(wǎng)絡(luò)。 無(wú)論底層協(xié)議如何，物聯(lián)網(wǎng)的部署網(wǎng)絡(luò)必須是健壯的，這種穩(wěn)健性可以通過(guò)測(cè)量吞吐量、延遲和可靠性來(lái)量化。 這些測(cè)量取決于部署規(guī)模的大小和其他系統(tǒng)級(jí)別的需求。

在Mesh協(xié)議方面,"沒(méi)有一種協(xié)議可以適合任意情況"。 每個(gè)無(wú)線協(xié)議都有獨(dú)特的特性和優(yōu)點(diǎn)，這取決于應(yīng)用場(chǎng)景和最終應(yīng)用。 理解Mesh技術(shù)的內(nèi)部機(jī)制要優(yōu)于具體技術(shù)的一系列關(guān)鍵特征。 更重要的是，開(kāi)發(fā)人員需要了解這些網(wǎng)絡(luò)協(xié)議在功耗、吞吐量、延遲、可伸縮性、安全性以及互聯(lián)網(wǎng)連接等關(guān)鍵領(lǐng)域的表現(xiàn)。 Zigbee，Thread 和藍(lán)牙m(xù)esh的設(shè)計(jì)有著本質(zhì)的不同，每種Mesh的實(shí)現(xiàn)方式都會(huì)對(duì)系統(tǒng)性能和健壯性產(chǎn)生影響。

無(wú)線連接的Mesh技術(shù)

無(wú)線芯片上的SoC已經(jīng)具備了成本效益，足以被添加到物聯(lián)網(wǎng)中，為我們的日常生活提供了方便、安全和舒適的體驗(yàn)。 當(dāng)添加了無(wú)線連接時(shí)，一個(gè)個(gè)的物就變成了物聯(lián)網(wǎng)設(shè)備。 許多物聯(lián)網(wǎng)設(shè)備以前都沒(méi)有無(wú)線互聯(lián)網(wǎng)連接。 不斷變化的規(guī)則和消費(fèi)者的期望迫使產(chǎn)品制造商在無(wú)數(shù)產(chǎn)品和系統(tǒng)中添加無(wú)線連接，以保持競(jìng)爭(zhēng)力或?yàn)樾碌氖杖肓魈峁┛赡堋?當(dāng)開(kāi)發(fā)者選擇構(gòu)建物聯(lián)網(wǎng)設(shè)備時(shí)，必須考慮如何使用最終產(chǎn)品以及這些產(chǎn)品將在何種生態(tài)系統(tǒng)中運(yùn)行。

無(wú)線網(wǎng)絡(luò)的種類(lèi)

在眾多物聯(lián)網(wǎng)無(wú)線技術(shù)中存在兩種基本拓?fù)? Mesh（網(wǎng)格） 和 Star （星形）(圖1)。 由于能夠擴(kuò)展到無(wú)數(shù)的節(jié)點(diǎn)并且覆蓋很長(zhǎng)的距離，因此它Mesh在家庭和智能建筑中通常比星型網(wǎng)絡(luò)更受歡迎。 星際網(wǎng)絡(luò)依賴(lài)于端節(jié)點(diǎn)和中央設(shè)備之間的點(diǎn)對(duì)點(diǎn)連接。 如果在安裝了網(wǎng)絡(luò)之后環(huán)境發(fā)生了變化，那么一個(gè)星型網(wǎng)絡(luò)可能就會(huì)發(fā)生故障。

圖1 兩種基本拓?fù)浣Y(jié)構(gòu)

在點(diǎn)對(duì)點(diǎn)或星網(wǎng)中，信號(hào)范圍是輸出功率的函數(shù)。 為了確保設(shè)備可以在電池上運(yùn)行足夠長(zhǎng)的時(shí)間或提高能源效率，理想的方案是減少功率消耗和輸出功率。 然而，盡管功耗減少，設(shè)備仍然需要能夠與其他設(shè)備進(jìn)行通信和互動(dòng)。 Mesh網(wǎng)絡(luò)中的每個(gè)設(shè)備都傳輸較短的距離，以減少其功耗。 當(dāng)通信在Mesh網(wǎng)絡(luò)上的設(shè)備之間傳輸時(shí)，系統(tǒng)的總通信范圍可以得到改進(jìn)。

Mesh網(wǎng)絡(luò)也提供了額外的通信優(yōu)勢(shì)，例如它們具有動(dòng)態(tài)自愈能力。 例如，如果一個(gè)網(wǎng)格網(wǎng)絡(luò)中的一個(gè)節(jié)點(diǎn)失敗，則可以通過(guò)重新路由以提高可靠性。 網(wǎng)格網(wǎng)絡(luò)的另一個(gè)重要好處是設(shè)備可以直接相互通信。 

哪個(gè)網(wǎng)絡(luò)最適合家庭和智能建筑？

Mesh網(wǎng)絡(luò)提供了一種理想的技術(shù)來(lái)實(shí)現(xiàn)和加強(qiáng)一些應(yīng)用，如上所述的建筑和家庭自動(dòng)化，照明系統(tǒng)和零售beacon系統(tǒng)。 Mesh網(wǎng)絡(luò)允許系統(tǒng)減少電力消耗，提高電池壽命，擴(kuò)大通信范圍，提高整個(gè)系統(tǒng)的可靠性。

每個(gè)網(wǎng)格網(wǎng)絡(luò)標(biāo)準(zhǔn)為不同的設(shè)備類(lèi)型和應(yīng)用提供基于標(biāo)準(zhǔn)的支持。 有一個(gè)成熟的應(yīng)用層支持家庭自動(dòng)化，照明和計(jì)量，而***個(gè)藍(lán)牙Mesh規(guī)范主要關(guān)注照明和一些家庭自動(dòng)化支持。 Thread是三種Mesh技術(shù)中唯一基于 IPv6的網(wǎng)格技術(shù)。 這提供了一些獨(dú)特的好處，例如在同一個(gè)網(wǎng)絡(luò)或跨網(wǎng)絡(luò)上的端到端路由和地址，而不需要實(shí)現(xiàn)額外的翻譯層。

Zigbee 通常用于建筑和家用設(shè)備的自動(dòng)化。 最近，針對(duì)這些應(yīng)用也在考慮Thread 和藍(lán)牙Mesh。 Z-wave 是另一種Mesh技術(shù)，在智能家居的安全應(yīng)用中也很流行。 

表1  3種協(xié)議的對(duì)比

大多數(shù)連接設(shè)備受益于連接到云端的使用場(chǎng)景，例如數(shù)據(jù)聚合。 支持低耗電藍(lán)牙的藍(lán)牙網(wǎng)格設(shè)備可以通過(guò)智能手機(jī)或平板電腦為云提供連接。 當(dāng)然，這是一個(gè)暫時(shí)的連接，因?yàn)槿绻謾C(jī)或平板電腦不存在，這些設(shè)備將無(wú)法連接到云端來(lái)發(fā)送或接收信息。 需要一個(gè)云連接的網(wǎng)關(guān)，而基于 IP 連接的 Thread 并不需要在網(wǎng)狀網(wǎng)絡(luò)之間建立一個(gè)完整的網(wǎng)關(guān)。 通過(guò)Thread，路由器能夠以較輕的權(quán)重方式促進(jìn)在 IP 上直接進(jìn)行設(shè)備對(duì)云的通信。

智能家居和智能建筑包括能量采集設(shè)備、電池供電設(shè)備和有線設(shè)備的組合。 照明和恒溫器通常是有線的，因?yàn)樗鼈兪腔A(chǔ)設(shè)施的一部分，但這并不意味著功耗可以被忽略。 因此，必須謹(jǐn)慎管理作為基礎(chǔ)設(shè)施的設(shè)備組成以及交流電的設(shè)備。電池通常為遠(yuǎn)程傳感器和控制元件提供動(dòng)力。 這意味著Mesh必須從功率角度理解兩個(gè)根本不同的應(yīng)用場(chǎng)景。

應(yīng)用場(chǎng)景

在智能家居和智能建筑中有許多潛在的Mesh網(wǎng)絡(luò)應(yīng)用場(chǎng)景。利用Mesh網(wǎng)絡(luò)，整個(gè)系統(tǒng)性能和終端用戶(hù)體驗(yàn)可以得到顯著的改善。 通過(guò)建筑和家庭自動(dòng)化，設(shè)備可以直接相互溝通。 在光開(kāi)關(guān)上的一個(gè)動(dòng)作可以立即發(fā)送到本地網(wǎng)格網(wǎng)絡(luò)的燈光，而不需要通過(guò)通向云端的網(wǎng)關(guān)進(jìn)行通信。這種類(lèi)型的即時(shí)反應(yīng)可以提高消費(fèi)者的體驗(yàn)。 此外，對(duì)于一些使用情況，例如在火災(zāi)報(bào)警時(shí)關(guān)閉空調(diào)的 HVAC 系統(tǒng)，網(wǎng)狀網(wǎng)絡(luò)上的局部通信可以確保系統(tǒng)正確運(yùn)行而不依賴(lài)云連接。

舒適

對(duì)于照明系統(tǒng)，可以簡(jiǎn)化部署和管理。 Mesh網(wǎng)絡(luò)提供的擴(kuò)展連接范圍意味著可以在更遠(yuǎn)的地方部署連接燈。 一個(gè)集線器或網(wǎng)關(guān)可以放置在一個(gè)位置，和連接的燈光共同部署。 隨著每一個(gè)節(jié)點(diǎn)的部署，通信的范圍增加，允許一個(gè)單一的網(wǎng)關(guān)有效地覆蓋更大的區(qū)域。

例如，考慮一下劇院或博物館的照明和環(huán)境控制。 這些裝置通常有成百上千個(gè)節(jié)點(diǎn)。 燈光、窗簾的馬達(dá)和百葉窗需要精確和精心設(shè)計(jì)的控制。 所有的燈光都要同時(shí)調(diào)暗，控制窗簾的馬達(dá)應(yīng)該一致工作。 細(xì)微的差異是顯而易見(jiàn)的，并且會(huì)減少觀眾的體驗(yàn)。

家里也有類(lèi)似的需求。 如果在一個(gè)有燈光和窗簾的場(chǎng)景，用戶(hù)期望一個(gè)無(wú)縫的且精心設(shè)計(jì)的體驗(yàn)，可能是所有的燈光同時(shí)暗淡，所有的窗簾都會(huì)同時(shí)移動(dòng)。

安全

像倉(cāng)庫(kù)這樣的工業(yè)環(huán)境可能比劇院有不同的照明需求。 通常，一個(gè)區(qū)域的燈光是同時(shí)打開(kāi)的。 然而，如果這些燈光一起亮起來(lái)，或者只需要幾秒鐘就能照亮所有的燈，這并不重要。 用戶(hù)體驗(yàn)和期望是不同的。 另一方面，如果由于停電，某些燈需要快速打開(kāi)，時(shí)間突然又變得重要起來(lái)。

方便

在部署過(guò)程中，如果每盞燈都一致亮著，這也許并不重要。 然而，如果開(kāi)發(fā)者想要添加額外的服務(wù)，那么網(wǎng)絡(luò)的強(qiáng)大程度就有可能成為問(wèn)題。

在部署Mesh的過(guò)程中越來(lái)越受歡迎的服務(wù)是資產(chǎn)跟蹤。 在這種情況下，設(shè)計(jì)者依賴(lài)于控制網(wǎng)絡(luò)來(lái)傳輸關(guān)于被安裝的設(shè)備，進(jìn)而追蹤資產(chǎn)的數(shù)據(jù)。 在這個(gè)例子中，吞吐量和延遲問(wèn)題取決于資產(chǎn)信息在網(wǎng)絡(luò)中傳播的速度。

圖2 網(wǎng)絡(luò)連接帶來(lái)的增值服務(wù)

另外，用于零售營(yíng)銷(xiāo)或資產(chǎn)追蹤的Beacon可以不要求每一個(gè)都在手機(jī)的范圍內(nèi)來(lái)管理。 還可以將這些領(lǐng)域和設(shè)備類(lèi)型的功能結(jié)合起來(lái)。 例如，燈不僅可以自動(dòng)化，還可以充當(dāng)Beacon。 這種方法可以通過(guò)增加位置服務(wù)和廣告等功能來(lái)增加燈的功能和價(jià)值。

應(yīng)用層的協(xié)議支持

協(xié)議的全部功能也取決于相應(yīng)的應(yīng)用層。 雖然Thread協(xié)議不包括應(yīng)用層，但可以使用任何基于 ip 的應(yīng)用層，如 dotdot 或 OCF。 藍(lán)牙包括一個(gè)名為 Mesh 模型的本地應(yīng)用層，這是一個(gè)全新的應(yīng)用層，支持不同的設(shè)備類(lèi)型，但相比 Zigbee 或 Thread 更加有限。 藍(lán)牙Mesh對(duì)于照明和通用控制的支持都有很好的支持，比如 on / off，傳感器，滑塊，電源和電池狀態(tài)，但對(duì)許多家庭配件缺乏專(zhuān)門(mén)的模型，如門(mén)鎖，HVAC，或窗口覆蓋特定的功能定義的互操作性。

表2  協(xié)議對(duì)應(yīng)用層的原生支持

哪種Mesh協(xié)議***？

不能一概而論。 在 Zigbee，Thread 和藍(lán)牙Mesh之間存在著基本的架構(gòu)差異。 ZigBee和 Thread 可以在使用時(shí)可能會(huì)用到flooding，但通常使用路由網(wǎng)格來(lái)最小化網(wǎng)絡(luò)開(kāi)銷(xiāo)，從而干擾信息傳遞。 藍(lán)牙Mesh則允許設(shè)備的配置作為路由器來(lái)減少flooding的影響。 藍(lán)牙技術(shù)聯(lián)盟(SIG)將此稱(chēng)為"托管式洪峰處理"。

ZigBee和 Thread 網(wǎng)絡(luò)包括路由節(jié)點(diǎn)和終端節(jié)點(diǎn)。 路由節(jié)點(diǎn)通常是線路供電的，可以作為Mesh的骨干。 端節(jié)點(diǎn)通常由電池驅(qū)動(dòng)，在網(wǎng)格的外圍運(yùn)行，并使用路由器傳遞信息。 在創(chuàng)建網(wǎng)格時(shí)，將建立路由表。 路由表是一個(gè)分類(lèi)目錄，它告訴每個(gè)設(shè)備如何與網(wǎng)格中的其他設(shè)備進(jìn)行通信。 通過(guò)這種方式，一個(gè)節(jié)點(diǎn)可以通過(guò)網(wǎng)格以精確的路徑發(fā)送消息，有效地與另一個(gè)節(jié)點(diǎn)進(jìn)行通信。 這對(duì)網(wǎng)格的吞吐量有積極的影響，并且可以隨著網(wǎng)格的增長(zhǎng)而減少延遲。

在歷史上，路由網(wǎng)格更受歡迎，因?yàn)樗峁┝烁咝У耐ㄐ藕涂深A(yù)測(cè)的性能。 另一方面，對(duì)于協(xié)議棧的開(kāi)發(fā)人員來(lái)說(shuō)，路由更難實(shí)現(xiàn)。

已經(jīng)部署的系統(tǒng)，一個(gè)產(chǎn)品必須可以交互操作是一個(gè)重要的因素考慮。 以住宅為例，其中一些設(shè)備可能使用 Zigbee 或 Thread 形成一個(gè)Mesh網(wǎng)絡(luò)。 一個(gè)網(wǎng)關(guān)或者一個(gè)集線器和網(wǎng)關(guān)的組合很可能已經(jīng)將這些設(shè)備連接到云端以獲得額外的服務(wù)。 手機(jī)可能也會(huì)與云溝通，然后再回到設(shè)備上。

為了支持電話(huà)到設(shè)備的直接通信，或者支持一個(gè)生態(tài)系統(tǒng)，如蘋(píng)果 HomeKit，藍(lán)牙連接是必需的。 如果所有的設(shè)備都支持該協(xié)議，藍(lán)牙就可以與另一個(gè)Mesh網(wǎng)絡(luò)結(jié)合起來(lái)，或者單獨(dú)作為一個(gè)Mesh網(wǎng)絡(luò)使用。 在設(shè)備中增加對(duì)多個(gè)協(xié)議的支持也可以提供好處，比如使用手機(jī)在沒(méi)有Zigbee 或 Thread 網(wǎng)絡(luò)的情況下安裝或使用設(shè)備。

連接需求應(yīng)該考慮整個(gè)生態(tài)系統(tǒng)，從終端設(shè)備，到任何網(wǎng)關(guān)或中心，到應(yīng)用程序?qū)雍头?wù)提供者。 網(wǎng)絡(luò)技術(shù)，如 Zigbee 和藍(lán)牙網(wǎng)格，不能本地支持 IP 必須首先適應(yīng)網(wǎng)關(guān)的 IP。 這個(gè)過(guò)程涉及到將網(wǎng)絡(luò)級(jí)有效載荷映射到 IP 數(shù)據(jù)報(bào)上，并將網(wǎng)絡(luò)級(jí)有效載荷重新打包。 相比之下，本地網(wǎng)絡(luò)本身支持 IP，如 Thread，可以在不干預(yù)的情況下提前和路由應(yīng)用程序有效載荷。 在本地網(wǎng)絡(luò)中加密的數(shù)據(jù)包可以保持端到端的安全。

ZigBee 和 Thread 的包結(jié)構(gòu)

Zigbee 和 Thread 都使用 IEEE 802.15.4中127字節(jié)的數(shù)據(jù)包，基礎(chǔ)數(shù)據(jù)速率為250 kbps。 雖然相同，但數(shù)據(jù)包結(jié)構(gòu)不同，導(dǎo)致有效負(fù)載的大小略有不同。 圖2顯示了 Zigbee 數(shù)據(jù)包格式，結(jié)果是一個(gè)68字節(jié)的有效負(fù)載。 對(duì)于68字節(jié)以上的有效載荷，Zigbee 將碎片分成多個(gè)數(shù)據(jù)包。 Thread數(shù)據(jù)包格式如圖3所示，結(jié)果是一個(gè)63字節(jié)的有效負(fù)載。 對(duì)于63字節(jié)以上的有效載荷，thread協(xié)議棧使用6LoWPAN。這些都是構(gòu)建應(yīng)用程序時(shí)需要關(guān)注的設(shè)計(jì)參數(shù)。

圖3 ZigBee 的數(shù)據(jù)包格式

圖4 Thread 的數(shù)據(jù)包格式

它們都會(huì)將較大的信息分解成更小的信息。 對(duì)于 Zigbee 來(lái)說(shuō)，應(yīng)用層會(huì)發(fā)生分段處理，并且從源到目的地進(jìn)行端到端的執(zhí)行。 對(duì)于線程來(lái)說(shuō)，分割是在6LoWPAN 層完成的。

• 對(duì)于這些網(wǎng)絡(luò)中的單播轉(zhuǎn)發(fā)，一旦設(shè)備準(zhǔn)備好發(fā)送，消息就會(huì)被轉(zhuǎn)發(fā)。 對(duì)于多播轉(zhuǎn)發(fā)，有一些網(wǎng)絡(luò)需求:
• 對(duì)于 Zigbee 設(shè)備來(lái)說(shuō)，只在64毫秒抖動(dòng)之后，設(shè)備才會(huì)發(fā)送多播消息。 然而，在重新傳輸初始消息之前，啟動(dòng)裝置有500毫秒的間隔。

Thread設(shè)備使用 RFC7731 MPL 轉(zhuǎn)發(fā)多播消息。涓流計(jì)時(shí)器被設(shè)置為64毫秒，這樣設(shè)備在重新發(fā)送之前可以隨機(jī)返回。

BLE 的包結(jié)構(gòu)

BLE有如下的數(shù)據(jù)包結(jié)構(gòu)，以減少無(wú)線傳輸時(shí)間和功耗。 藍(lán)牙Mesh進(jìn)一步完善了這個(gè)數(shù)據(jù)包結(jié)構(gòu)，增加了網(wǎng)格和安全性能。

圖5 藍(lán)牙Mesh 的數(shù)據(jù)包結(jié)構(gòu)

這意味著藍(lán)牙Mesh只有12或16個(gè)字節(jié)可用于有效負(fù)載，除此之外，數(shù)據(jù)包被分割成單獨(dú)的數(shù)據(jù)包，然后在目的地重新組裝。 這個(gè)分段包攜帶一個(gè)header，標(biāo)識(shí)應(yīng)用中有效負(fù)載的分段和12字節(jié)，但***一段除外，它們可以更短。 然而，藍(lán)牙網(wǎng)格規(guī)范空間中需要額外的處理這些分段包，從而增加了延遲并減少吞吐量。 由于所有的吞吐量和延遲分析都是基于應(yīng)用的有效負(fù)載，可以看到，藍(lán)牙網(wǎng)格將需要比 Zigbee 或 Thread 更多的數(shù)據(jù)包。

路由與flooding的對(duì)比

Zigbee，Thread 和藍(lán)牙網(wǎng)絡(luò)是為智能家居和智能建筑設(shè)計(jì)的。 Zigbee 支持幾種路由技術(shù)，包括用于路由發(fā)現(xiàn)的flooding或群組消息; 網(wǎng)格中控制消息的下一跳路由; 以及通向網(wǎng)關(guān)的多對(duì)一路由，然后使用到設(shè)備的源路由。 Zigbee 網(wǎng)絡(luò)同時(shí)使用所有這些方法也是正常的。

Thread也支持下一跳路由和flooding。 然而，Thread網(wǎng)絡(luò)將下一跳路由維護(hù)到所有路由器，作為正常網(wǎng)絡(luò)維護(hù)的一部分，而不是一個(gè)執(zhí)行路由發(fā)現(xiàn)的設(shè)備。 Thread還將處理可伸縮性的活躍路由器數(shù)量降到***。 以前，這被視為嵌入式802.15.4網(wǎng)絡(luò)的限制，因?yàn)榫W(wǎng)絡(luò)在大量路由器的存在下flooding限制了組播通信的頻率和可靠性。 需要注意的是，Thread網(wǎng)絡(luò)管理了活躍路由器的數(shù)目和間隔，不需要用戶(hù)干預(yù)或管理。

藍(lán)牙網(wǎng)支持管理flooding。 這是Mesh上的一個(gè)微調(diào)，用戶(hù)可以指定哪些設(shè)備參與了flooding。 這將減少flooding的影響，但需要用戶(hù)確定其網(wǎng)絡(luò)中路由器的適當(dāng)密度和拓?fù)浣Y(jié)構(gòu)，這可能變得很困難。 隨著網(wǎng)絡(luò)條件的變化，哪些設(shè)備參與了flooding也可能需要改變，這也將需要用戶(hù)干預(yù)。

藍(lán)牙還有類(lèi)似于 Zigbee 或 Thread 的終端設(shè)備，稱(chēng)為"友鄰"設(shè)備。 一個(gè)友鄰裝置與一個(gè)相鄰的有線節(jié)點(diǎn)耦合在一起，而友鄰的數(shù)據(jù)包則由有線節(jié)點(diǎn)存儲(chǔ)。 友鄰設(shè)備會(huì)定期醒來(lái)詢(xún)問(wèn)鄰居是否有任何數(shù)據(jù)包。 有線節(jié)點(diǎn)只在一定的時(shí)間段內(nèi)保存數(shù)據(jù)包，所以"友鄰"需要使用其配對(duì)的中繼節(jié)點(diǎn)進(jìn)行簽入。

圖6 藍(lán)牙Mesh 示例

對(duì)網(wǎng)格拓?fù)涞难芯靠梢苑治鼍W(wǎng)絡(luò)規(guī)模。 這些網(wǎng)絡(luò)表現(xiàn)得差異很大，在考慮10節(jié)點(diǎn)網(wǎng)絡(luò)或200節(jié)點(diǎn)網(wǎng)絡(luò)時(shí)，路由和管理技術(shù)往往需要改變。

通常情況下，在一個(gè)小網(wǎng)絡(luò)中，設(shè)備可以通過(guò)一兩跳和非常簡(jiǎn)單的路由或flooding就可以適合。 隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)大，增加了復(fù)雜性，例如設(shè)備間的更多的跳躍; 設(shè)備的密度，這可能干擾彼此發(fā)送消息; 更多的關(guān)注延遲和可靠性。 如果使用flooding類(lèi)型的信息來(lái)打開(kāi)100盞燈，通常不能接受只打開(kāi)了98或99個(gè)開(kāi)關(guān)。 這種類(lèi)型的問(wèn)題在10節(jié)點(diǎn)網(wǎng)絡(luò)中很少見(jiàn)，但在100節(jié)點(diǎn)網(wǎng)絡(luò)中可能變得普遍。

硅實(shí)驗(yàn)室的測(cè)試結(jié)論

為了最小化設(shè)備測(cè)試的可變性，測(cè)試可以在固定拓?fù)渲羞M(jìn)行，在這些拓?fù)浣Y(jié)構(gòu)中，射頻路徑通過(guò)分路器和衰減器連接在一起，以確保該拓?fù)洳粫?huì)隨著時(shí)間和測(cè)試而改變。 硅實(shí)驗(yàn)室采用了七跳測(cè)試，以確保網(wǎng)絡(luò)拓?fù)洹?當(dāng)然，MAC地址過(guò)濾也可以用來(lái)實(shí)現(xiàn)網(wǎng)絡(luò)拓?fù)洹?/p>

關(guān)注的度量指標(biāo)

在以前應(yīng)用場(chǎng)景中，設(shè)計(jì)者希望為應(yīng)用建立一個(gè)健壯的網(wǎng)絡(luò)。 在評(píng)估網(wǎng)絡(luò)的健壯性時(shí)，需要關(guān)注的測(cè)量指標(biāo)包括吞吐量、延遲和可靠性。 這三種測(cè)量方法可以準(zhǔn)確地預(yù)測(cè)給定網(wǎng)絡(luò)的健壯性。

• 吞吐量： 定義了網(wǎng)絡(luò)的可伸縮性(有多少設(shè)備可以發(fā)送正常的流量) ，以及高級(jí)數(shù)據(jù)操作的行為，如向設(shè)備推送固件更新
• 時(shí)延： 描述了行動(dòng)的發(fā)生需要多長(zhǎng)時(shí)間。 它是涉及最終用戶(hù)交互的關(guān)鍵參數(shù)(而不是機(jī)器對(duì)機(jī)器的通信) ，因?yàn)楹芏嗳四軌蝮w會(huì)到超過(guò)100毫秒的操作。 對(duì)于需要同時(shí)進(jìn)行操作的過(guò)程，例如打開(kāi)多盞燈，時(shí)間必須低于100毫秒，以便最終用戶(hù)不會(huì)抱怨燈光連續(xù)亮起時(shí)產(chǎn)生"爆米花"效應(yīng)。
• 可靠性： 但是當(dāng)用戶(hù)與諸如燈光和開(kāi)關(guān)等日常設(shè)備互動(dòng)時(shí)，用戶(hù)期望100% 的可靠性。 實(shí)際上，硅谷實(shí)驗(yàn)室測(cè)試的可靠性達(dá)到99.999% 。 

無(wú)論使用什么樣的無(wú)線技術(shù)，這些都是Mesh網(wǎng)絡(luò)測(cè)量的關(guān)鍵因素，并且與設(shè)備和無(wú)線系統(tǒng)的設(shè)計(jì)目標(biāo)密切相關(guān)。

基準(zhǔn)測(cè)試

硅實(shí)驗(yàn)室使用了無(wú)線 Gecko SoC 平臺(tái)進(jìn)行了測(cè)試，該平臺(tái)可以運(yùn)行藍(lán)牙網(wǎng)、線程、 Zigbee 和專(zhuān)有協(xié)議， 同時(shí)使用了硅實(shí)驗(yàn)室的藍(lán)牙、線程和 Zigbee 軟件協(xié)議棧。 測(cè)試環(huán)境是一個(gè)商業(yè)辦公大樓，有活躍的 Wi-Fi 和 Zigbee 網(wǎng)絡(luò)。 無(wú)線測(cè)試集群被部署在走廊、會(huì)議室、辦公室和空曠地區(qū)。

100字節(jié)有效負(fù)載的吞吐量

圖7 吞吐量與多跳的對(duì)比

典型的網(wǎng)絡(luò)包括兩到三跳，吞吐量根據(jù)跳數(shù)不同而變化，協(xié)議性能隨著跳數(shù)的增加而變得相似，藍(lán)牙Mesh的小數(shù)據(jù)包有效負(fù)載導(dǎo)致吞吐量減少。

四跳的時(shí)延

圖8 4跳網(wǎng)絡(luò)的時(shí)延

• 所有的協(xié)議都在較小的有效負(fù)載時(shí)提供了類(lèi)似的延遲
• 當(dāng)有效負(fù)載大小增加時(shí)，Thread(6LowPAN)實(shí)現(xiàn)了***的效率和延遲性能。
• Zigbee 有很好的效率，但是一些應(yīng)用層分段處理，
• 藍(lán)牙Mesh 的延遲隨著由于數(shù)據(jù)包大小和由此產(chǎn)生的分段蠢了，有效負(fù)載大小降低較多。

小載荷小型網(wǎng)絡(luò)

圖9 多播時(shí)延

• 三種協(xié)議的峰值都低于50毫秒，
• 它們網(wǎng)絡(luò)膨脹后均已擴(kuò)大至90毫秒，遠(yuǎn)低于200毫秒的市場(chǎng)目標(biāo)。
• 另外，所有協(xié)議的多播都提供了非常高的可靠性。

具有中等載荷的小型網(wǎng)絡(luò)

圖10 中載荷小網(wǎng)絡(luò)的多播時(shí)延

• 在延遲高達(dá)100毫秒(ms)的情況下，Thread表現(xiàn)***。
• Zigbee 執(zhí)行的數(shù)據(jù)包大多數(shù)具有80ms 的延遲，逐漸擴(kuò)展到130 ms。 
• 藍(lán)牙網(wǎng)格延遲在60毫秒，擴(kuò)展到250毫秒。
• 所有192個(gè)節(jié)點(diǎn)均為藍(lán)牙Nesh中繼節(jié)點(diǎn)，沒(méi)有進(jìn)行中繼節(jié)點(diǎn)進(jìn)行優(yōu)化。

帶有小載荷的大型網(wǎng)絡(luò)

圖11 小載荷大網(wǎng)絡(luò)的多播時(shí)延

• 在延遲擴(kuò)展到100毫秒的情況下，線程表現(xiàn)***。
• Zigbee 執(zhí)行的數(shù)據(jù)包大多數(shù)具有80ms 的延遲，逐漸擴(kuò)展到130 ms。
• 藍(lán)牙網(wǎng)格延遲在60毫秒，擴(kuò)展到250毫秒
• 所有192個(gè)節(jié)點(diǎn)均為藍(lán)牙網(wǎng)格繼電器，沒(méi)有進(jìn)行繼電器優(yōu)化

測(cè)試結(jié)果

1. Thread、 Zigbee 和藍(lán)牙Mesh在小型網(wǎng)絡(luò)中的較小有效載荷下能進(jìn)行類(lèi)似的操作
2. 當(dāng)有效負(fù)載和吞吐量需求增加時(shí)，Thread 和 Zigbee 的性能比藍(lán)牙Mesh要好
3. 隨著網(wǎng)絡(luò)規(guī)模的增長(zhǎng)，這三種方式的延遲都會(huì)增加，但是藍(lán)牙Mesh的增長(zhǎng)***
4. 選擇物聯(lián)網(wǎng)無(wú)線連接解決方案應(yīng)該包括額外的標(biāo)準(zhǔn)，如預(yù)期的生態(tài)系統(tǒng)和功耗需求
5. 對(duì)于大型藍(lán)牙Mesh，可以利用中繼節(jié)點(diǎn)優(yōu)化來(lái)優(yōu)化性能
6. 當(dāng)短消息(11B)特別用于多播消息時(shí)，藍(lán)牙Mesh效果***

結(jié)論

基于所使用解決方案的理論網(wǎng)絡(luò)大小不能準(zhǔn)確反映網(wǎng)絡(luò)在實(shí)際實(shí)現(xiàn)中所需節(jié)點(diǎn)的數(shù)目。 實(shí)際的限制是基于一些因素，包括網(wǎng)絡(luò)拓?fù)洹?shù)據(jù)包大小以及吞吐量和延遲等性能要求。 例如，一個(gè) Zigbee 的設(shè)備子網(wǎng)在100個(gè)設(shè)備中有一個(gè)實(shí)際的限制，盡管可以部署極大的商業(yè)系統(tǒng)，比如在拉斯維加斯的 Aria 酒店，擁有超過(guò)80000個(gè)有多個(gè)子網(wǎng)的 Zigbee 網(wǎng)絡(luò)設(shè)備。 1.1協(xié)議針對(duì)每個(gè)網(wǎng)絡(luò)約250個(gè)節(jié)點(diǎn)進(jìn)行了優(yōu)化，但是由于線程是基于 IP 的，邊界路由器使得網(wǎng)絡(luò)更容易擴(kuò)展和分布。

Mesh網(wǎng)絡(luò)的選擇取決于終端應(yīng)用程序或生態(tài)系統(tǒng)。 有許多已經(jīng)建立了的生態(tài)系統(tǒng)，如飛利浦 Hue，亞馬遜 Echo Plus 和 Comcast Xfinity。 如果一個(gè)設(shè)備制造商想與這些生態(tài)系統(tǒng)進(jìn)行交互操作，Zigbee 是***選擇。 如果沒(méi)有為應(yīng)用程序指定生態(tài)系統(tǒng)，那么還有許多其他的協(xié)議選擇。

Thread和藍(lán)牙Mesh都是可行的選擇，也是除了 Zigbee 之外最常見(jiàn)的選擇。 集成電路供應(yīng)商提供的開(kāi)發(fā)工具在Mesh網(wǎng)絡(luò)開(kāi)發(fā)的速度上有很大的影響。 數(shù)據(jù)包跟蹤和多節(jié)點(diǎn)能量分析等工具可以確保所選擇的Mesh網(wǎng)絡(luò)得到有力的支撐。 最終，網(wǎng)絡(luò)的大小，所需的延遲，預(yù)期的吞吐量和整體的可靠性將驅(qū)動(dòng)網(wǎng)格協(xié)議的選擇。

本文編譯自以下3篇文章：

http://www.embedded-computing.com/iot/how-zigbee-thread-and-bluetooth-mesh-stack-up-in-performance-benchmarking

https://www.silabs.com/products/wireless/learning-center/mesh-performance

https://www.silabs.com/whitepapers/selecting-the-appropriate-wireless-mesh-network-technology 

【本文來(lái)自51CTO專(zhuān)欄作者“老曹”的原創(chuàng)文章，作者微信公眾號(hào)：喔家ArchiSelf,id:wrieless-com】

戳這里，看該作者更多好文