多協(xié)議連接提供了一種獨特的方法來添加消費者和企業(yè)所要求的功能。為了在家庭或樓宇自動化場景中提供必要的可擴展性和穩(wěn)定性，通過網(wǎng)狀網(wǎng)絡(luò)進行設(shè)備間通信是一種理想的實現(xiàn)方式。同時，能夠直接從智能手機設(shè)置、控制或監(jiān)視單個設(shè)備或一組設(shè)備的功能也是一種簡化消費者體驗并向技術(shù)人員提供更多即時診斷信息以輔助安裝的特性需求。

增值服務(wù)可以通過連接的設(shè)備(例如燈)進行交付，例如在零售環(huán)境中提供基于接近感知的廣告，為技術(shù)人員傳輸系統(tǒng)健康信息以及跟蹤倉庫中的資產(chǎn)。同時，人們希望參與多個生態(tài)系統(tǒng)，無論是Alexa、Apple HomeKit還是Google Home，每個生態(tài)系統(tǒng)都有各自的協(xié)議或集成要求。通過在單個設(shè)備上支持多協(xié)議，我們可以滿足我們剛剛討論過的許多需求。

目錄

通過多種無線方式提供新體驗

尋找一種經(jīng)濟有效的方式來支持多協(xié)議

在單個無線電上同時執(zhí)行多協(xié)議

在單個無線電進行Zigbee和藍(lán)牙操作的調(diào)度要求

評估動態(tài)多協(xié)議性能

設(shè)計具有多協(xié)議連接的系統(tǒng)

通過多種無線協(xié)議提供新體驗

讓我們研究一下如何使用支持多協(xié)議的設(shè)備來改善家庭自動化場景中的體驗。Zigbee通過其網(wǎng)狀網(wǎng)絡(luò)功能提供整個家庭的覆蓋范圍，并且可以通過網(wǎng)關(guān)從家庭外部進行控制。但是，有了多協(xié)議支持，我們可以進一步擴展使用場景，用具有低功耗藍(lán)牙的電話進行本地控制和位置感知。

通過同時支持藍(lán)牙和Zigbee連接，門鎖在接收到藍(lán)牙通信后便會解鎖，同時能夠發(fā)送Zigbee消息以打開客廳燈。當(dāng)將智能手機帶入臥室時，使用接近感應(yīng)服務(wù)(例如藍(lán)牙信標(biāo))，燈可以發(fā)送藍(lán)牙信標(biāo)消息，允許消費者打開房間中的全部或部分燈。

在零售或商業(yè)環(huán)境中，希望利用諸如藍(lán)牙信標(biāo)之類的技術(shù)來提供基于位置的廣告、跟蹤資產(chǎn)，以及去開發(fā)人流的熱圖(heat map)。大規(guī)模采用的挑戰(zhàn)之一是需要專用的信標(biāo)設(shè)備。對于設(shè)備生命周期管理，連接范圍也會影響更新設(shè)備的統(tǒng)籌安排。

通過將藍(lán)牙信標(biāo)集成到其他連接的基礎(chǔ)設(shè)施(例如照明)中，我們可以建立大規(guī)模且密集的信標(biāo)覆蓋區(qū)域。不必同時部署連接燈和信標(biāo)，連接的燈或燈具也可以用作藍(lán)牙信標(biāo)。與部署單獨的專用信標(biāo)設(shè)備相比，這可以提供一種更具成本效益的方式來提高信標(biāo)密度，并且具有無需監(jiān)視和維護必須由電池供電的信標(biāo)設(shè)備的額外優(yōu)勢。

用多功能燈提高信標(biāo)密度

多協(xié)議還使其他使用案例成為可能。例如，無線更新可能會在網(wǎng)狀網(wǎng)絡(luò)上花費很長時間，但是藍(lán)牙的更高吞吐量可以在不消耗網(wǎng)狀網(wǎng)絡(luò)帶寬的情況下提供更新固件映像的更快傳輸。

用多功能燈提高信標(biāo)密度

尋找一種經(jīng)濟有效的方式來支持多協(xié)議

在支持多協(xié)議的情況下提供這些改進的體驗所面臨的挑戰(zhàn)之一是要求擁有多個芯片或SoC，每種協(xié)議一個。然而，使用多協(xié)議芯片，設(shè)備現(xiàn)在可以靈活地運行不同的協(xié)議。下表描述了多協(xié)議設(shè)備的一些常見示例。

無線多協(xié)議方案

來自像Silicon Labs這樣的公司的單芯片解決方案結(jié)合了軟件和硬件方面的先進技術(shù)，使設(shè)備既支持Zigbee也支持藍(lán)牙，從而滿足目前為止討論的使用案例需求。相對于兩個無線電，通過使用一個SoC無線子系統(tǒng)，可以將BoM成本降低40%，并且通過消除設(shè)計中兩個無線電之間可能存在的干擾，還可以簡化PCB設(shè)計。

在單個無線電上同時執(zhí)行多協(xié)議

讓我們更詳細(xì)地研究動態(tài)多協(xié)議調(diào)度如何通過單個無線電支持多協(xié)議。當(dāng)不發(fā)送信號時，Zigbee路由器始終將其無線電設(shè)為接收模式。這樣一來，網(wǎng)絡(luò)中的其他設(shè)備就可以始終向其發(fā)送數(shù)據(jù)包或通過它路由。由于Zigbee流量的低占空比和Zigbee網(wǎng)絡(luò)協(xié)議棧中的重傳機制，Zigbee路由器可以在短時間內(nèi)將其無線電更改為另一個協(xié)議，而不會在應(yīng)用層級上丟棄任何消息。這使得我們可以在同一芯片上對Zigbee和藍(lán)牙通信進行時間切片。除Zigbee路由外，Silicon Labs動態(tài)多協(xié)議技術(shù)還支持藍(lán)牙連接和藍(lán)牙信標(biāo)。

協(xié)議連接間隔可以基于應(yīng)用需求而配置。對于藍(lán)牙信標(biāo)，無線電只需要大約1ms即可發(fā)送信標(biāo)，并且信標(biāo)之間的連接間隔通常不小于100ms。對于高速OTA固件更新，可能需要將設(shè)備配置為支持更長的藍(lán)牙連接時間。這些例子面對的應(yīng)用場景相反。但是，通過可配置的連接間隔，Silicon Labs多協(xié)議解決方案提供了靈活的框架，可以滿足不同應(yīng)用的獨特需求。

為了實現(xiàn)有效的多協(xié)議通信，Silicon Labs已經(jīng)在軟件和硬件上進行了大量投資。Silicon Labs無線協(xié)議棧經(jīng)過專門設(shè)計，可以共享相同的低級別的無線電驅(qū)動程序和庫(RAIL)。利用RAIL可確保使用一致的API和接口來共享無線電。

另外，無線電調(diào)度器管理來自協(xié)議的請求以訪問無線電，而Micrium OS內(nèi)核管理協(xié)議棧之間的資源共享。

Silicon Labs多協(xié)議調(diào)度考慮了要調(diào)度的協(xié)議，并使用基于優(yōu)先級的調(diào)度方法。藍(lán)牙需要固定的連接間隔才能有效運行，而采用MAC重傳方法的Zigbee更加寬容。因此，對于Zigbee和藍(lán)牙多協(xié)議操作，藍(lán)牙以更高的優(yōu)先級運行。由于使用RAIL、無線電調(diào)度器和Micrium OS的無線協(xié)議棧具有統(tǒng)一的體系結(jié)構(gòu)，該系統(tǒng)能夠使用基于優(yōu)先級的調(diào)度方法來平衡Zigbee和藍(lán)牙操作。

在單個無線電上進行Zigbee和藍(lán)牙操作的調(diào)度要求

許多調(diào)度方案可能都要求使用單個無線電實現(xiàn)Zigbee和藍(lán)牙的正確操作。調(diào)度器可以配置成使得任一協(xié)議在無線訪問方面具有更高的優(yōu)先級。但是，最可能的配置是使藍(lán)牙連接和信標(biāo)具有更高的優(yōu)先級，并且在不執(zhí)行其他任何操作時將無線電保持在Zigbee接收模式。

具有優(yōu)先權(quán)的Bluetooth LE和Zigbee后臺接收

在上圖中，我們可以看到低優(yōu)先級的Zigbee接收是默認(rèn)的，但是當(dāng)需要Zigbee傳輸時，它將中斷該過程。這是Zigbee設(shè)備的正常行為。當(dāng)Bluetooth LE連接被調(diào)度時，采用先例，調(diào)度器要及時退出Zigbee接收模式，以用于藍(lán)牙連接。如果調(diào)度器要求進行Zigbee傳輸?shù)恼埱蟪^下一個藍(lán)牙連接或信標(biāo)發(fā)出之前無線電上可用的時間，則調(diào)度器將重新安排Zigbee傳輸以在藍(lán)牙活動完成之后進行。

如果Zigbee數(shù)據(jù)包的傳輸時間超出了預(yù)期，可能是由于退避或清除信道評估所致，調(diào)度器可以中斷該傳輸并切換到藍(lán)牙。如圖2所示，對于Zigbee協(xié)議棧來說，這看起來像是一次失敗的嘗試，因此它進行了重傳，這次成功了。

藍(lán)牙連接中斷Zigbee傳輸

同樣，如果遠(yuǎn)程Zigbee節(jié)點在處于藍(lán)牙連接或信標(biāo)中間時嘗試將數(shù)據(jù)包發(fā)送到設(shè)備，則該設(shè)備將無法接收該數(shù)據(jù)包，但是發(fā)送設(shè)備將重傳(IEEE 802.15.4 MAC重傳)，數(shù)據(jù)包將在第二次嘗試時被接收。另外，如果在建立藍(lán)牙連接或信標(biāo)時設(shè)備正處于接收Zigbee數(shù)據(jù)包的中間，調(diào)度器可能會中斷數(shù)據(jù)包的接收，并且發(fā)送設(shè)備將不會收到確認(rèn)。因此，它將重傳并在第二次嘗試時被成功接收。圖3顯示了這兩種情況。

無線電調(diào)度器必須處理各種情況，以管理無線協(xié)議之間的沖突，但是各個協(xié)議棧彼此并不會有任何察覺，只是他們必須請求訪問無線電并且判斷它們的發(fā)送或接收是否成功。

評估動態(tài)多協(xié)議性能

為了了解運行多協(xié)議時的設(shè)備行為，重要的是測量和比較多種配置下的性能。對于在同一SoC和單個無線電上運行Zigbee和藍(lán)牙的情況，方案可能包括：

Zigbee吞吐量對比藍(lán)牙連接和/或廣播間隔

Zigbee延遲對比藍(lán)牙連接和/或廣播間隔

Zigbee吞吐量或延遲對比變化的藍(lán)牙數(shù)據(jù)包類型和大小

Zigbee重試和網(wǎng)絡(luò)行為對比變化的藍(lán)牙連接和/或廣播

動態(tài)多協(xié)議測試設(shè)置

使用圖4中概述的測試設(shè)置，在Silicon Labs Wireless Gecko STK板上使用輻射測試設(shè)置執(zhí)行的示例測試給出以下結(jié)果：

對于顯示結(jié)果，我們使能了802.15.4 MAC和Zigbee NWK層重傳，但未使能Zigbee APS層重傳。該設(shè)備配置為在單個跳躍點上傳輸70個字節(jié)的有效負(fù)載，同時在指定的連接間隔內(nèi)保持藍(lán)牙連接并保持活動狀態(tài)。隨著藍(lán)牙連接間隔的減小，由于Zigbee網(wǎng)絡(luò)上無線電時間的減少，藍(lán)牙連接事件的數(shù)量增加，Zigbee吞吐量降低。需要注意的是，這里獲得了100%的端到端消息可靠性，并且雖然由于較長的數(shù)據(jù)傳輸時間導(dǎo)致吞吐量降低，但沒有丟失Zigbee應(yīng)用消息。

為了驗證廣播間隔的影響，設(shè)備配置為以變化的間隔傳輸藍(lán)牙廣播，而不是保持藍(lán)牙連接。由于藍(lán)牙廣播數(shù)據(jù)包比藍(lán)牙連接保持活動的數(shù)據(jù)包更長，因此在相同時間間隔內(nèi)，它們對Zigbee吞吐量的影響略高。短至0.5s的廣播間隔對Zigbee吞吐量幾乎沒有影響，應(yīng)該可以滿足大多數(shù)用例的需求。

設(shè)計具有多協(xié)議連接的系統(tǒng)

借助動態(tài)多協(xié)議硬件和軟件，現(xiàn)在可以在一個SoC上以經(jīng)濟高效的方式去整合多協(xié)議的優(yōu)勢。通過在設(shè)備上結(jié)合Zigbee和藍(lán)牙連接，家庭自動化、資產(chǎn)跟蹤和零售廣告可從中受益。

每個設(shè)備和應(yīng)用都有獨特的需求，這些需求要求對軟件進行可配置性設(shè)置，例如藍(lán)牙連接間隔。在著手開發(fā)之前，重要的是要確?；A(chǔ)軟件和硬件體系結(jié)構(gòu)被設(shè)計用于無線電的有效資源共享，并支持高級調(diào)度方案。此外，應(yīng)根據(jù)特定的應(yīng)用和系統(tǒng)用例來定義測試和性能基準(zhǔn)，以確保在現(xiàn)場正確運行。