循序打造智慧建築/照明　藍牙Mesh設計開發不NG

採納最新的藍牙Mesh 1.0規範(Bluetooth Mesh 1.0)允許低功耗藍牙(Bluetooth Low Energy/Bluetooth LE)網路中的裝置(或稱「節點」)互相通訊而無需使用網路中的中樞裝置(Hub)，從而實現了更大的通訊範圍、靈活性和擴充性，並且是實現區域網路(LAN)物聯網(IoT)無線技術之先決條件。藍牙Mesh網路的主要應用包括企業照明設施、托管式信標的後端，以及工業監控。然而，該規範同時帶來了新的設計挑戰，例如開通(Provisioning)及配置網路，以及使用藍牙Mesh的模型。

藍牙Mesh介紹

藍牙Mesh網路建立於標準低功耗藍牙實體層(PHY)之上(圖1)，具有七層架構，包含承載層、網路層、底層傳輸層、上層傳輸層、存取層、基礎模型和模型。當一個節點接收訊息時，會將該訊息從下層的PHY向上傳播，經由承載層送達至網路層。

圖1 藍牙Mesh疊構位於低功耗藍牙物理層之上。

藍牙Mesh採用一種稱為「擴散式」(Flooding)的通訊方式，將每個資料封包向網路中的每個節點廣播。有三種類型定址可配合擴散式網路：「單一廣播」(Unicast)(在節點初始設置期間使用)、「群組」以及「虛擬」(主要由裝置製造商用來「標記」產品)。其中，群組定址最適用於日常操作。群組位址代表著網路中一個或多個裝置的群播位址。藍牙技術聯盟(SIG)定義了四種「固定群組位址」，稱作「全代理」(All-proxies)、「全朋友」(All-friends)、「全中繼」(All-relays)，以及「全節點」(All-nodes)，專門配合下述的各個節點類型。

主要的智慧家居應用(例如照明)適合採用擴散網路方式的Mesh網路和群組定址。採用擴散網路方式的Mesh網路允許交換器向智慧照明群組發送「開啟」指令，透過網路進行快速傳播，然後每個節點(燈光)都接收到指令，幾乎瞬時全部點亮。

Mesh網路的另一個優勢是簡單，把通訊限制到低功耗藍牙技術的三種廣播頻道，而非37個全頻寬資料通道。然而，這樣做的代價是頻寬減小了，原因在於需要管理流量以防止資料封包完全霸占這個有限的頻率子集。

Mesh網路技術內建多個機制以緩減廣播和掃描通道阻塞，包括了TTL(Time-To-Live)計數器，它定義一個資料封包能夠被中繼傳輸的次數，在達到指定次數之後，就不會繼續進行中繼操作。第二個防止阻塞機制就是資料封包的資訊暫存，一旦資料封包流傳整個Mesh網路之後，最後只可以到達暫存，在這一點上，設計者可以安心假設它不必再進行傳輸。還有一個「選擇性中繼」功能可以限制Mesh網路擁塞。只要關閉中繼，節點便可以僅接收資料封包而不會向外傳送。

藍牙Mesh網路的規範詳細描述了四種類型「節點」，包含中繼節點(Relay Nodes)、低功耗節點(Low Power Nodes, LPN)、朋友節點(Friend Nodes)和代理節點(Proxy Nodes)。中繼節點能夠重新發送所接收到的資料封包，並且利用這個機制，讓資料封包可以在整個網路上快速傳播。中繼的缺點是耗電量增加，這是由於這種節點一直「醒著」。雖然在Mesh網路配置中低功耗藍牙的功耗遠低於其他競爭技術，但如果時常醒著，也無法單單依靠電池供電來持久運作。

LPN透過與朋友節點協同工作，從而能夠使用電池來運作。朋友節點通常是由主電源供電，因而能夠永遠保持醒著，並且暫存任何發往LPN的訊息；LPN根據預先設定的排程表切換至「接收」模式來接收朋友節點所暫存的訊息，並根據指令進行運作，接著便快速返回節能的「睡眠」狀態。

「代理節點」允許運行低功耗藍牙疊構但不支援藍牙Mesh網路的裝置(例如現在的智慧手機)連接至藍牙網路。它利用節點和裝置的通用型屬性設定檔(GATT)介面實現互動(圖2)。

圖2 代理節點(P)允許不支援藍牙Mesh的低功耗藍牙設備(例如智慧手機)連接到藍牙Mesh網路。

藍牙Mesh網路沿用藍牙技術的架構，其中GATT的「設定檔」允許眾多使範例分享共同的資訊結構。然而，由於Mesh網路的分散式特性，所以這兩類設定檔的設計是不同的。為了避免GATT設定檔被錯誤認為是網路設定檔，因此Mesh的設定檔稱作「模型」(Models)。

藍牙Mesh 1.0包括「設定」、「心跳」和「健康」基礎模型，這些基礎模型與「Mesh模型」相輔相成，用於「通用」、「照明」、「感測器」和「場景」等使用範例。有了鏡像GATT設定檔，還可以建立客製化的基礎和Mesh模型。

對於新開發藍牙Mesh的設計人員來說，範例和學習指南是最佳的起步點。這個學習指南中一個重要的區別是，儘管藍牙Mesh節點具有前面所述的四種通用類型，但每個類型的功能都由其「模型」決定。

模型方法

藍牙Mesh網路在建構Mesh應用時提供了靈活性，因為開發人員可以建構許多擁有不同客製化行為裝置的「模型」。模型定義了所需Mesh網路的「狀態」，作用於這些狀態的「訊息」以及這些狀態的相關行為。所有通過Mesh網路的通訊都經由訊息來促進(圖3)。

圖3 模型架構實現控制模型的藍牙Mesh設備的元素。裝置C可以做為和伺服器模型(裝置A和B內)進行通訊的客戶端(分別是訊息X、Y和Z，以及訊息R、S和T)，以及作為伺服器(支援訊息A、B和C)的客戶端模型(裝置D內)。

狀態是表示「元素」狀態的值。元素代表裝置或節點的網路可尋址實體。每個裝置由至少一個(主要)元素組成，並可能有一個或多個次要元素。在初始配置後的整個節點生命週期內，所有的元素都保持不變。「揭露」狀態的元素稱為「伺服器」。「存取」狀態的元素則稱為「客戶端」。

伺服器、客戶端和「控制」是規範中定義的三種類型的模型。伺服器模型由跨越一個或更多的元素組成的一個或多個狀態，並定義一組可以發送或接收的強制訊息，在處理訊息時的元素行為，以及訊息得到處理後所發生的任何其他行為。

客戶端模型定義了一組客戶端用來請求、改變或「消耗」相應伺服器狀態的訊息，就如伺服器模型所定義的。客戶端模型本身沒有狀態。控制模型可以結合客戶端模型功能(與其他伺服器模型進行通訊)，和伺服器模型功能(與其他客戶端模型進行通訊)。控制模型還可以包括一組規則和行為，以協調控制模型與控制模型連接的其他模型之間的互動通訊。

藍牙SIG以電源插座為例來說明模型的工作原理[1]。在這個範例中，電源插座包含兩個獨立的電源插口，每個插口連接到藍牙Mesh網路。該電源插座裝置由兩個元件(個別的電源插座)組成。這些元素的每一個功能由通用功率水平伺服器模型定義，該模型定義伺服器上的一組狀態，以及在這些狀態下操作的一組訊息。發送到其中一個插座元件的通用功率水平設置訊息，可以發送到裝置以控制其輸出功率。 插座也可以由調光器控制。在這種情況下，調光器必須實施通用級的客戶端模型。該模型將期望水平設為零，最大值或兩者之間的某個值。利用稱為「狀態綁定」(State Binding)的功能來控制插座的電源，使得在每個電源插座中，通用電源實際狀態均會通往通用級狀態。通用級客戶端將通用級訊息發送到通用級伺服器，更改通用級狀態，然後利用定義的綁定，更改控制功率輸出的通用電源實際狀態。 由於元素可以報告狀態，因此每個插座均可以報告功率級別，以及插入到插座的裝置能源消耗。能源消耗使用感測器伺服器模型(Sensor Server Model)定義的消息進行報告。

藍牙Mesh開發工具

開發人員現在可以利用藍牙Mesh，因為該規範並未要求低功耗藍牙供應商更新其支援該功能的PHY或軟體堆疊。除此之外，藍牙Mesh不限制PHY須相容最新版本藍牙5，因此Mesh可採納藍牙4.0、4.1和4.2晶片的舊版產品。

然而，藍牙Mesh確實需要引進供應商的相容Mesh疊構。該疊構包含了一個全新的主機層，與低功耗藍牙主機層的概念有點相似，但兩者並不相容。

由於藍牙Mesh不需要更改現有的PHY或疊構，因此可以利用包含目標裝置的現有DK，例如Nordic的nRF52 DK來進行藍牙Mesh開發工作。

Mesh的開發需求至少要有三個(最好是更多)裝置來進行通訊和模擬Mesh環境。理想情況下，可以使用幾個DK來表示Mesh的節點，但此舉的缺點是硬體開發成本顯著增加。另一種方法是使用一套DK，並向第三方供應商購買經測試和驗證過的低功耗藍牙模組。如果使用nRF52832 SoC所建構的模組，可以有許多選擇。

開通配置Mesh網路

整合藍牙Mesh堆疊需要多少熟悉跟目標裝置有關的硬體、軟體和開發工具。假設開發人員有這樣的經驗，並配備SDK、DK和模組(或更多的DK)形成一個小型網路，便可以相對容易地將其初步的藍牙Mesh應用整合起來。

第一步是建構Mesh疊構。以Nordic的方案為例，疊構是使用選定的IDE來建構的。例如，SEGGER Embedded Studio，是使用藍牙Mesh SDK附帶的一個範例，並以IDE編譯後來建構疊構。接著DK上的PHY將被清除，並利用經編譯的藍牙Mesh和通訊疊構(Nordic的低功耗藍牙疊構)重新編程。一旦該疊構經編程和驗證後，SDK就可以用來設置和建立藍牙Mesh網路。

其開發工具包括為Mesh網路增添新裝置的應用程式介面(API)，這稱為「開通」。開通由先前已配置作開通用途，並且已是網路的一部份的裝置處理，稱作「開通者」(圖4)。開通者可為新裝置提供加入網路的資訊。最初，未開通的裝置會接收到一組網路金鑰、位址和裝置金鑰(在開通之後，可建立用於配置的安全頻道)。

圖4 Nordic用於Mesh的nRF5 SDK所產生的開通與配置流程圖。「nrf_mesh⋯」標註是API函數。

API允許開發人員開始偵聽等待加入網路的未開通裝置。這些裝置將以低功耗藍牙的三個廣播頻道之一所發送的廣播信標進行通訊，頻道上的導入連接(Incoming Link)請求將被開通者自動接受。 建立連接後，它會被認證(使用頻外配對OOB方法增強安全性)，以確保加入網路的裝置是預期的目標裝置。之後會進行API事件，為裝置提供開通資料和裝置金鑰。

用於Mesh的nRF5 SDK包括一個燈光開關範例，展示如何開發同時具有開通者和被開通者兩種角色的應用程式。在該展示中，一個燈光開關「客戶端模型」(Client Model，開關)是開通者，而燈光開關「伺服器模型」(Server Model，燈泡)是被開通者。

Nordic的範例突顯了藍牙Mesh規範中最簡單的伺服器就是「通用OnOff伺服器」(Generic OnOff Server)，它表示伺服器可以「開」或「關」。最簡單的客戶端是「通用OnOff客戶端」，它能夠利用通用OnOff模型定義的訊息，來控制通用OnOff伺服器。

當此伺服器模型從客戶端模型接收到GET或(可靠)SET訊息，它將發送OnOff狀態的當前值作為回應。這可以使客戶端了解伺服器的最新狀態(表1)。

表1 通用開/關模型(Generic OnOff Model)支援的訊息和ATT。

「配置伺服器」(Configuration Server)是藍牙Mesh節點的強制性要求，用於表示裝置的Mesh網路配置。配置伺服器可處理與配置客戶端的通訊，和來自配置客戶端的指示(由開通者控制)。

開通完成後開始配置。開通者讀取被開通者的組成資料以辨識裝置的後設資料(Metadata)，以及哪些模型會配合哪些元素。然後應用程式或網路密鑰被添加並配合到不同的模型。

要在網路上增添更多節點，可以重複為每個新裝置進行開通和配置。

發布和訂閱

在添加和配置網路裝置後，藍牙Mesh需要開發人員配置模型的「發布狀態」，並設定「訂閱」。發布狀態包括用於發布狀態事件的位址，以及使用了什麼金鑰和什麼TTL值。

訊息在每個模型的發布位址「發布」時被送出。例如，由感測器節點報告資料時發布。訊息能夠只發布一次，或重複發送到單播位址、群組位址或虛擬位。客戶端模型也使用發布消息將訊息發送到伺服器模型。發布狀態的配置通常由開通者利用配置模型來控制。

使用Nordic nRF5 SDK時，訊息以「access_model_publish()」API函數發布，該函數根據發布模型的發布設定(間隔、目的地)來發布訊息。

訂閱用於接收來自節點的未經請求訊息。Nordic SDK的「access_model_subscription_list_alloc()」API函數分配一個預定表，讓模型能夠訂閱一個位址。該訂閱功能允許模型偵聽發布的訊息，例如包含感測器節點資料的訊息。

將不支援藍牙Mesh網路功能的裝置(例如智慧手機)連接至藍牙網路裝置以配置智慧照明，將有許多好處。可以利用節點和裝置的通用型屬性設定檔(GATT)介面，將智慧手機設為代理節點。

熟悉低功耗藍牙設計的開發人員在開始使用藍牙Mesh時，將十分有利。但是，實施藍牙Mesh的確需要學習新的架構，並了解當中的細微差異，例如狀態、元素和模型，以及如何增添和配置新的網路裝置。

(本文作者為Nordic產品行銷經理)