1 介紹

藍牙Mesh Profile規(guī)范定義了實現(xiàn)藍牙低功耗無線技術的可互操作Mesh網(wǎng)絡解決方案的基本要求。

1.1 一致性

如果聲明符合本規(guī)范，則應以指定的方式（過程強制性）支持本規(guī)范強制規(guī)定的所有功能。這也適用于支持被指示的所有可選和有條件的功能。

1.2 藍牙規(guī)范版本兼容性

本規(guī)范應與以下內容一起使用：

? 核心規(guī)格附錄6結合允許的藍牙核心規(guī)范（參見第1卷，D部分可训，第1.2節(jié)，表1.3）捶枢，或

? 任何v5.0版本之后的藍牙核心規(guī)格握截。

如果 支持 第 5.2.2 節(jié)定義的GATT Provisioning Bearer 或第 3.3.2 節(jié)定義的GATT Bearer， 則需要通用屬性配置文件（GATT） 被支持烂叔。

1.3 語言

1.3.1 語言約定

在規(guī)范的開發(fā)過程中谨胞，藍牙SIG設立了以下約定使用的詞語 ， 應當蒜鸡，必須胯努， 將要， 應該术瓮， 可以康聂， 可能， 是胞四，以及注意恬汁。

• 應當（shall）， 需要 - 用于定義需求辜伟。
• 必須（must）氓侧，是一種自然的后果 - 僅用于描述不可避免的情況。
• 將要（will）导狡， 確實如此 - 僅用于事實陳述约巷。
• 應該（should），建議 - 用于表示在幾種可能性中有一種推薦為特別合適旱捧，但不是必需的独郎。
• 可以（may）踩麦，被允許 - 用于允許選項。
• 可能（can）氓癌，能夠 - 以因果方式將陳述關聯(lián)起來谓谦。
• 是（is），被定義為 - 用于進一步解釋以前需要的元素或允許 贪婉。
• 注意（note）反粥，用于指示僅用于提供信息的文本，而不是為實現(xiàn)該規(guī)范所需的疲迂。一份說明中的信息性文字延續(xù)到段落的末尾才顿。

為了清楚說明這些術語的定義，請參閱核心規(guī)范第1卷E部分第1節(jié)尤蒿。

1.3.1.1 保留供將來使用

在數(shù)據(jù)包郑气，協(xié)議數(shù)據(jù)單元（PDU）或其他數(shù)據(jù)結構中的字段被描述為“保留供將來使用（Reserved for Future Use）”（不管是大寫還是小寫），創(chuàng)建結構的設備應將其值設置為零腰池，除非特別指定竣贪。任何接收或解釋結構的設備都應忽略該字段;特別是它不應該由于該字段的值而拒絕該結構。

在字段巩螃，參數(shù)或其他變量對象可以在一個范圍內取值并且某些值被描述為“保留供將來使用”的情況下，發(fā)送該對象的設備不應將該對象設置為這些值匕争。接收具有這種值的對象的設備應該拒絕它避乏，并且包含它的任何數(shù)據(jù)結構都是錯誤的;但是，這不適用于將對象描述為可被忽略或指定可忽略無法識別的值的上下文中甘桑。

當字段值是一個位字段時拍皮，未分配的位可以被標記為保留以備將來使用，并且應該被設置為0跑杭。接收包含未使用的保留位的消息設置為1的實現(xiàn)將像該位設置為0一樣理處該消息铆帽，除非另有規(guī)定。

首字母縮略詞RFU相當于“保留供將來使用”德谅。

1.3.1.2 禁止

當字段值是枚舉時爹橱，未分配的值可以標記為“禁止（Prohibited）”。這些值永遠不會被實現(xiàn)使用窄做，并且任何收到的包含禁止值的消息都應該被忽略愧驱，并且不會被處理，也不會被回應椭盏。

如果字段组砚，參數(shù)或其他變量對象可以取一個范圍內的值，并且某些值被描述為“禁止”掏颊，則設備不得將該對象設置為任何被禁止的值糟红。接收具有這種值的對象的設備應該拒絕它艾帐，并且包含它的任何數(shù)據(jù)結構都是錯誤的。

“禁止”永遠不會縮寫盆偿。

1.3.2 縮略語

表1.1：縮寫和首字母縮略詞

1.3.3 術語

表1.2：術語

2 Mesh系統(tǒng)架構

本節(jié)概述了Mesh網(wǎng)絡操作和分層系統(tǒng)體系結構矛纹。

2.1 分層架構

Mesh Profile 規(guī)范被定義為 如圖2.1 所示的分層體系結構 。

圖2.1：Mesh系統(tǒng)架構

2.1.1 模型層

模型層定義了用于標準化典型用戶場景操作的模型光稼，并在藍牙Mesh模型規(guī)范 [11] 或其他更高層規(guī)格中定義或南。較高層模型規(guī)格的例子包括照明和傳感器模型。

2.1.2 基礎模型層

基礎模型層定義配置和管理Mesh網(wǎng)所需的狀態(tài)艾君，消息和模型采够。

2.1.3 接入層（Access layer）

接入層定義了高層應用如何使用高層傳輸層（upper transport layer）。它定義了應用程序數(shù)據(jù)的格式;它定義和控制在上層傳輸層中執(zhí)行的應用數(shù)據(jù)加密和解密;它會檢查傳入的應用程序數(shù)據(jù)是否在正確的網(wǎng)絡和應用程序密鑰的上下文中被接收冰垄，然后再將其轉發(fā)到更高層蹬癌。

2.1.4 上層傳輸層（Upper transport layer）

上層傳輸層對應用數(shù)據(jù)進行加密，解密和認證虹茶，并被設計為提供接入消息的機密性（confidentiality of access messages）冀瓦。它還定義了如何使用傳輸控制消息來管理節(jié)點之間的上層傳輸層，包括由Friend功能使用時的情形写烤。

2.1.5 低層傳輸層（Lower transport layer）

低層傳輸層定義如何將高層傳輸層消息分段并重新組裝成多個較低傳輸PDU以將較大的較高傳輸層消息傳遞到其他節(jié)點翼闽。它還定義了一個控制消息來管理分段和重組。

2.1.6 網(wǎng)絡層（Network layer）

網(wǎng)絡層定義了傳輸消息如何尋址一個或多個元件洲炊。它定義了允許傳輸PDU由Bearer layer傳輸?shù)木W(wǎng)絡消息格式感局。網(wǎng)絡層決定是否中繼/轉發(fā)消息尼啡，接受它們以供進一步處理，或拒絕它們询微。它還定義了網(wǎng)絡消息如何加密和認證崖瞭。

2.1.7 Bearer layer

Bearer層定義了網(wǎng)絡消息如何在節(jié)點之間傳輸。定義了兩個Bearer撑毛，廣告Bearer和GATT Bearer书聚。未來可能會定義其他Bearer。

2.2 Mesh操作概述

本規(guī)范定義的Mesh網(wǎng)絡操作旨在：

? 使消息能夠從一個元件發(fā)送到一個或多個元件;

? 允許通過其他節(jié)點中繼消息來擴展通信范圍;

? 安全的消息以抵御已知的安全攻擊藻雌，包括竊聽攻擊雌续，中間人攻擊，重放（replay）攻擊胯杭，垃圾桶（trash-can）攻擊驯杜，暴力（brute-force key）攻擊以及可能出現(xiàn)的其他安全攻擊。

? 在當今市場上的現(xiàn)有設備上工作;

? 及時發(fā)送消息;

? 當一個或多個設備移動或停止運行時可以繼續(xù)工作;以及

? 具有內置的前向兼容性做个，以支持未來版本的Mesh Profile規(guī)范鸽心。

該規(guī)范定義了基于泛洪管理（managed-flood-based）的Mesh網(wǎng)絡，該網(wǎng)絡使用廣播信道傳輸消息居暖，以便其他節(jié)點可以接收消息并轉發(fā)這些消息;從而擴大原始消息的范圍顽频。只要有足夠密度的設備監(jiān)聽和中繼消息，受管理的泛洪（managed-flood）Mesh網(wǎng)絡中的任何設備都可以隨時發(fā)送消息太闺。增加路由功能和定義基于路由的（routing-based）Mesh網(wǎng)絡的增強可以考慮用于本規(guī)范的未來版本冲九。

本規(guī)范使用多種方法來限制受管泛洪Mesh網(wǎng)絡中消息的無限中繼。使用的兩種主要方法是網(wǎng)絡消息緩存（network message cache）方法和生存時間（time to live）方法跟束。

網(wǎng)絡消息緩存（network message cache）旨在通過將所有消息添加到緩存列表來防止設備中繼先前收到的消息。收到消息時丑孩，會根據(jù)列表進行檢查冀宴，如果已經(jīng)存在則忽略。如果尚未收到温学，則將其添加到緩存中略贮，以便將來可以忽略它。為了防止這個列表變得太長仗岖，緩存的消息數(shù)量受到實現(xiàn)的限制逃延。

每條消息都包含一個生存時間（TTL）值，用于限制消息中繼的次數(shù)轧拄。每次收到一條消息揽祥，然后由設備中繼（最多126次），TTL值就會減1檩电。

2.2.1 網(wǎng)絡和子網(wǎng)

Mesh網(wǎng)絡由共享四種公共資源的節(jié)點組成：

? 用于識別消息來源和目的地的網(wǎng)絡地址（見第 3.4.2 節(jié) ）;

? 用于在網(wǎng)絡層保護和認證消息的網(wǎng)絡密鑰（見第 3.8.6.3 節(jié) ）;

? 用于在接入層保護和認證消息的應用密鑰（見第 3.8.6.2 節(jié) ）; 和

? 用于延長網(wǎng)絡壽命的IV索引（見第 3.8.4 節(jié) ） 拄丰。

網(wǎng)絡可以有一個或多個便于“區(qū)域”隔離的子網(wǎng)（例如府树，酒店網(wǎng)絡內的隔離的酒店房間子網(wǎng)）。子網(wǎng)是一組可以在網(wǎng)絡層互相通信的節(jié)點料按，因為它們共享一個網(wǎng)絡密鑰奄侠。通過知道一個或多個網(wǎng)絡密鑰，節(jié)點可能屬于一個或多個子網(wǎng)载矿。在配置（provisioning）時垄潮，設備被配置到一個子網(wǎng)，并且可以使用配置模型（Configuration Model）添加到更多的子網(wǎng)闷盔。

有一個稱為主子網(wǎng)（primary subnet）的特殊子網(wǎng)弯洗，它基于主NetKey（見第 3.8.6.4 節(jié) ）。主子網(wǎng)上的節(jié)點參與IV更新過程（請參見第

3.10.5節(jié)）馁筐， 并將IV更新（IV updates）傳播到其他子網(wǎng)涂召，而其他子網(wǎng)上的節(jié)點只傳播IV 索引更新（IV Index updates）到這些子網(wǎng)。

網(wǎng)絡資源由實現(xiàn)配置客戶端（Configuration Client）模型（稱為配置客戶端敏沉，通常為智能電話或其他移動計算設備）的節(jié)點管理果正，并在配置時分配給節(jié)點（參見第 5 節(jié) ）， 盟迟，配置時使用配置服務器（Configuration Server）模型（參見第 4.4.1 節(jié) ） 秋泳。特別是，Provisioner管理地址分配以確保沒有重復的單播 地址分配攒菠，而配置客戶端（Configuration Client）生成并分配網(wǎng)絡和應用密鑰迫皱，并確保需要相互通信的設備為網(wǎng)絡層和接入層共享適當?shù)拿荑€。配置客戶端也知道設備密鑰（device keys）（參見第 3.8.6.1 節(jié) ）辖众， 用于保護與每個單獨節(jié)點的通信卓起，包括分發(fā) 更新的網(wǎng)絡和應用程序密鑰。

2.2.2 設備和節(jié)點

不是Mesh網(wǎng)絡成員的設備稱為未配置設備凹炸。作為Mesh網(wǎng)絡成員的設備稱為節(jié)點戏阅。Provisioner用于管理未配置設備和節(jié)點之間的轉換。

未配置的設備不能發(fā)送或接收Mesh消息;然而啤它，它將它的存在告知Provisioner奕筐。Provisioner會在未經(jīng)過驗證的設備通過驗證后邀請其進入Mesh網(wǎng)絡，并將該未經(jīng)過驗證的設備轉換為節(jié)點变骡。

節(jié)點可以發(fā)送或接收Mesh消息离赫，并由配置客戶端管理，該配置客戶端也可以是與配置器（Provisioner）相同的設備塌碌，通過Mesh網(wǎng)絡來配置節(jié)點與其他節(jié)點的通信方式渊胸。配置客戶端可以從Mesh網(wǎng)絡中刪除一個節(jié)點，這將該節(jié)點恢復為未配置的設備台妆。

設備可以通過在已經(jīng)配置到Mesh網(wǎng)絡之后將其自身提供給另一個Mesh網(wǎng)絡來支持節(jié)點的多個實例蹬刷。Mesh網(wǎng)絡的每個實例都由設備在配置期間獲取的地址和設備密鑰確定瓢捉。

2.2.3 將設備添加到Mesh網(wǎng)絡

設備被配置器（Provisioner）添加到Mesh網(wǎng)絡中，此時它們成為節(jié)點办成。將設備配置到Mesh網(wǎng)絡中不同于藍牙無線技術中通常使用的點對點綁定和配對泡态。通過使用簡單的廣告Bearer（Advertising Bearer）或基于點對點的GATT Bearer（GATT-based Bearer）來啟用設備配置。兩個Bearer使用同一個配置協(xié)議（provisioning protocol）迂卢。通過基于廣告的Bearer進行配置是由所有設備實現(xiàn)的某弦。通過基于GATT的Bearer來配置，允許諸如傳統(tǒng)電話的設備（即而克，不支持通過原生廣告Bearer配置的設備）成為配置器（Provisioners）靶壮。

為了協(xié)助配置多個設備，設備具有可由配置器設置的關注計時器（attention timer）员萍。當設置為非零值時腾降，設備使用任何可能的方式識別自己。例如碎绎，該設備可以閃燈螃壤，發(fā)出聲音或振動。當關注計時器到期時筋帖，設備停止識別自身奸晴。這允許配置器向設備發(fā)送單個消息以使其自身識別，并且設備在給定時間后自動停止識別自身日麸。

在這兩個Bearer上運行的協(xié)議是藍牙核心規(guī)范v4.2的安全管理器協(xié)議的衍生寄啼，用于引入驗證具有非常有限的用戶界面的設備（如燈泡或交換機）的能力。安全管理器協(xié)議需要可靠的Bearer代箭，這是廣告配置Bearer（advertising provisioning Bearer）不能保證的;因此本規(guī)范中使用的協(xié)議旨在實現(xiàn)與Bearer無關的可靠消息傳遞墩划。與安全管理器協(xié)議的相似性可以在已實現(xiàn)此功能的設備上大量重用現(xiàn)有代碼。

2.2.4 通信支持

許多當前設備不能在未更新的情況下發(fā)廣告或理解Mesh消息嗡综。為了使這些設備能夠與Mesh網(wǎng)絡中的節(jié)點進行通信乙帮，而無需進行操作系統(tǒng)更新或類似的硬件/軟件更新，該規(guī)范支持對所有現(xiàn)有設備使用GATT連接蛤高。

2.2.5 低功耗支持

本規(guī)范中的特性使Mesh網(wǎng)絡中的許多設備可以使用電池供電，或使用諸如能量采集等技術碑幅。這些設備可能受限于它們如何用作Mesh網(wǎng)絡的一部分（例如戴陡，與之交互時僅發(fā)送數(shù)據(jù)的設備）。本規(guī)范不要求設備協(xié)調傳輸沟涨，建立連接或在每個連接上重新啟動安全性;從而促進低功耗操作恤批。需要低功耗支持的設備可以使用稱為Friendship的概念（參見第 3.6.6 節(jié) ） 將自己與始終在線的設備相關聯(lián)，該設備代表它們存儲和中繼消息 裹赴。然而喜庞，中繼消息的設備大多數(shù)時間都會接收消息并轉發(fā)消息诀浪，并且可能使用的功耗要比典型的小電池或電容器提供的功耗大得多。

2.3 架構概念

Mesh網(wǎng)絡體系結構使用幾種不同的概念：狀態(tài)（states）延都，消息（messages）雷猪，綁定（bindings），元件（elements）晰房，尋址（addressing）求摇，模型（models），發(fā)布 - 訂閱（publish-subscribe）殊者，Mesh密鑰（mesh keys）以及關聯(lián)（associations）与境。

2.3.1 狀態(tài)（States）

狀態(tài)是表示元件狀態(tài)的值。

暴露狀態(tài)的元件（element）被稱為服務器（server）猖吴。例如摔刁，最簡單的服務器是一個通用開關服務器（Generic OnOff Server），表示它要么是打開的海蔽，要么是關閉的共屈。

訪問狀態(tài)的元件被稱為客戶端（client）。例如准潭，最簡單的客戶端是通用開關客戶端（Generic OnOff Client）（二進制開關）趁俊，它能夠通過通用開關模型（Generic OnOff Model）定義的消息來控制通用開關服務器（Generic OnOff Server）。

由兩個或更多值組成的狀態(tài)稱為組合狀態(tài)（composite states）刑然。例如寺擂，變色燈可以通過色彩飽和度（color saturation）和亮度（brightness）分開控制色調（color hue）。

2.3.2 綁定狀態(tài)（Bound states）

當一個狀態(tài)被綁定到另一個狀態(tài)時泼掠，一個狀態(tài)的變化會導致另一個狀態(tài)的變化怔软。綁定狀態(tài)（Bound states）可能來自一個或多個元件中的不同模型。例如择镇，一個常見類型的綁定位于Level級別和OnOff狀態(tài)之間：將Level更改為0會將綁定的OnOff狀態(tài)更改為Off挡逼，并將Level更改為非零值會將綁定的OnOff狀態(tài)更改為On。

2.3.3 消息（Messages）

Mesh網(wǎng)絡內的所有通信都通過發(fā)送消息來完成腻豌。消息按狀態(tài)進行操作家坎。對于每個狀態(tài)，都有一組定義的消息吝梅，服務器支持并且客戶端可以使用該消息請求狀態(tài)值或更改狀態(tài)虱疏。服務器也可以傳輸攜帶關于狀態(tài)和/或改變狀態(tài)的信息的未經(jīng)請求（unsolicited messages）的消息。

消息被定義為具有操作碼苏携，相關參數(shù)和行為做瞪。一個操作碼可以是一個八位字節(jié)（對于需要最大可能的有效負載的特殊消息），2個八位字節(jié)（對于標準消息）或3個八位字節(jié)（對于供應商特定的消息）。

包括操作碼的總消息大小由下面的傳輸層確定装蓬，其可以使用分段和重組（Segmentation and ReassemblySAR）機制著拭。為了最大限度地提高性能并避免SAR的開銷，設計目標是將消息放入單個段中牍帚。傳輸層為非分段消息提供多達11個八位位組儡遮，當使用1個八位字節(jié)操作碼時最多可以提供10個八位位組參數(shù)，在使用2個八位位組操作碼時最多可以提供9個八位位組參數(shù)履羞，當使用供應商專用的3字節(jié)操作碼時峦萎，可以使用8個八位字節(jié)作為參數(shù)。

傳輸層提供了一個能夠傳輸多達32個段的SAR機制忆首。使用SAR時的最大消息大小是384個八位字節(jié)爱榔。這意味著（排除一個應用MIC），當使用1字節(jié)操作碼時糙及，最多379個八位字節(jié)可用于參數(shù)详幽，當使用2個八位字節(jié)操作碼時，最多378個八位字節(jié)可用于參數(shù)浸锨，而當使用3個八位字節(jié)的供應商特定操作碼時唇聘，最多可以有377個八位字節(jié)用于參數(shù)。

SAR不會在每個分段的接入層有效載荷上施加任何額外的開銷：一個10字節(jié)的消息作為未分段的消息傳輸柱搜，而20個八位字節(jié)的消息作為使用兩個分段的分段消息傳輸迟郎。

消息定義包含參數(shù)表。在消息有效載荷中聪蘸，參數(shù)跟隨操作碼宪肖，除非另有說明，參數(shù)偏移量以八位字節(jié)為單位健爬。

消息被定義為有確認（acknowledged）或無確認（unacknowledged）兩種控乾。有確認的消息（例如Get消息）需要響應，而無確認的消息（例如狀態(tài)消息）不需要響應娜遵。

Set蜕衡，Clear，Recall和Store消息定義為兩種變體：有確認和無確認设拟。

消息變體在語義上是相同的慨仿，但使用單獨的操作碼。

2.3.4 元件（Elements）

元件是節(jié)點內的可尋址實體纳胧。每個節(jié)點至少有一個元件镰吆，主要元件（primary element），并可能有一個或多個附加的次要元件（secondary elements）躲雅。元件的數(shù)量和結構是靜態(tài)的鼎姊，并且在節(jié)點的整個生命周期中都不會改變（即只要該節(jié)點是網(wǎng)絡的一部分期間）骡和。

使用在配置期間分配給節(jié)點的第一個單播地址（unicast address）來尋址主要元件相赁。使用隨后的地址尋址每個附加的次要元件相寇。這些單播元件地址允許節(jié)點識別節(jié)點內的哪個元件正在傳輸或接收消息。

如果元件的數(shù)量和結構發(fā)生變化（例如由于固件更新）钮科，則必須重新配置節(jié)點唤衫。當執(zhí)行更改元件數(shù)量或結構的固件更新時，將使用 “節(jié)點移除”過程（請參閱第 3.10.7 節(jié) ）绵脯。

消息在基于操作碼和元件地址的模型內分派佳励。

一個元件不允許包含多個使用相同消息的模型實例（例如，“On”消息）蛆挫。當同一元件中的多個模型使用相同的消息時赃承，這些模型被稱為“重疊”。為了在單個節(jié)點內實現(xiàn)重疊模型的多個實例（例如悴侵，控制可以打開和關閉的多個燈具）瞧剖，該節(jié)點需要包含多個元件。

例如壶辜，燈具可能有兩個燈泡廓鞠，每個燈泡實現(xiàn)Light Lightness Server模型的實例和Generic Power OnOff Server模型的實例尽爆。這要求節(jié)點包含兩個元件，每個燈泡一個捉撮。當它收到“開啟”消息時，該節(jié)點使用該元件的單播地址來標識該消息尋址到哪個通用開關服務器（Generic Power OnOff Server）模型的實例妇垢。

在另一個示例中巾遭，雙插槽電源板包含兩個獨立的能量測量傳感器，可以測量連接到插座的設備消耗的功耗修己。這將要求節(jié)點具有兩個傳感器數(shù)據(jù)狀態(tài)恢总，每個狀態(tài)都在一個單獨的元件中。第一個元件即主要元件將使用該節(jié)點的單播地址進行標識睬愤，并且將包含第一個能量傳感器的狀態(tài)以及表示節(jié)點配置的狀態(tài)片仿。第二個元件（次要元件）將使用單播元件地址進行識別，并將包含第二個能量傳感器的狀態(tài)尤辱。

每個元件都有一個GATT藍牙命名空間描述符（GATT Bluetooth Namespace Descriptor） 5 值砂豌，有助于識別此元件所代表的是節(jié)點的哪一部分。這些名稱空間描述符值使用與GATT相同的定義光督。例如阳距，溫度傳感器的元件將使用“內部（inside）”和“外部（outside）”的值。

2.3.5 地址（Addresses）

地址可以是單播地址（unicast address）结借，虛擬地址（virtual address）或組地址（group address）筐摘。還有一個特殊的值來表示未被分配的地址，在消息中不使用該地址。

單播地址被分配給一個元件咖熟，并且總是表示一個節(jié)點的單個元件圃酵。每個Mesh網(wǎng)絡有32767個單播地址。

虛擬地址是多播地址（multicast address）馍管，可以表示一個或多個節(jié)點上的多個元件郭赐。每個虛擬地址在邏輯上代表一個標簽UUID，它是一個128位的值确沸，不需要集中管理捌锭。發(fā)送到標簽UUID的每條完整標簽UUID消息，都包含用于驗證該消息的消息完整性檢查值（message integrity check value）罗捎。為了減少檢查每個已知標簽UUID的開銷观谦，使用標簽UUID的哈希值。有16384個哈希值桨菜，每個哈希值編碼一組虛擬地址坎匿。雖然在虛擬地址中僅使用16384個哈希值，但每個哈希值可能代表數(shù)百萬個可能的標簽UUID;因此雷激，虛擬地址的數(shù)量被認為是非常大的替蔬。

組地址是多播地址（multicast address），可以表示一個或多個節(jié)點上的多個元件屎暇。每個Mesh網(wǎng)絡有16384個組地址承桥。有一組固定組地址（fixed group addresses）用于根據(jù)這些節(jié)點的功能來定位節(jié)點的所有主要元件的子集。所有其他組地址都稱為動態(tài)分配的組地址（dynamically assigned group addresses）根悼。有256個固定組地址和16128個動態(tài)分配的組地址凶异。

2.3.6 模型（Models）

模型定義了節(jié)點的基本功能。一個節(jié)點可能包含多個模型挤巡。模型定義了所需的狀態(tài)（如 2.3.1 節(jié)所述 ）剩彬，作用于這些狀態(tài)的消息（如 2.3.3 節(jié)所述 ）以及任何相關的行為。

一個Mesh應用程序使用以發(fā)布 - 訂閱范式進行通信的客戶端 - 服務器體系結構指定矿卑。由于Mesh網(wǎng)絡的特性以及對配置客戶端執(zhí)行的行為配置的認識喉恋，因此應用程序未在單個端到端規(guī)范（如配置文件）中定義。相反母廷，應用程序是在客戶端模型（client model）轻黑，服務器模型（server model）和控制模型（control model）中定義的。

本規(guī)范定義了三種類型的模型：服務器模型琴昆，客戶端模型和控制模型：

? 服務器模型： 服務器模型由跨越一個或多個元件的一個或多個狀態(tài)組成氓鄙。 服務器模型定義了它可以發(fā)送或接收的一組強制性消息，元件在發(fā)送和接收此類消息時所需的行為业舍，以及在發(fā)送或接收消息之后發(fā)生的任何其他行為抖拦。

? 客戶端模型： 客戶端模型定義了一組客戶端的消息（包括必需的和可選的） 用于請求升酣，更改或使用由服務器模型定義的相應服務器狀態(tài)√铮客戶端模型沒有狀態(tài)拗踢。

? 控制模型： 控制模型可能包含客戶端模型功能與其他服務器模型通信 ，以及服務器模型功能與其他客戶端模型進行通信向臀。控制模型也可以包含 控制邏輯 诸狭， 控制邏輯 是協(xié)調控制模型連接的其他模型之間的交互作用的一組規(guī)則和行為券膀。

單個設備可能包括服務器，客戶端和控制模型驯遇。

例如芹彬， 圖2.2 顯示了一個設備的元件模型結構，實現(xiàn)具有狀態(tài)并支持消息R叉庐，S舒帮，T，X陡叠，Y玩郊，Z的服務器模型（設備C）;以及兩個實現(xiàn)客戶端模型的設備，設備A支持消息X枉阵，Y和Z译红，設備B支持消息R，S兴溜，T和Z侦厚。

圖2.2：客戶端 - 服務器模型通信

在另一個例子中， 圖2.3 顯示了實現(xiàn)控制模型的設備的元件模型結構拙徽。設備C可以作為客戶端與服務器模型進行通信（分別支持消息X刨沦，Y和Z以及消息R，S和T）膘怕，并且可以作為服務器（支持消息A想诅，B和C）與客戶端模型進行通信。

圖2.3：控制模型通信

照明控制器是控制模型實施的一個例子岛心。照明控制器需要作為傳感器（用于測量占用率（occupancy）和/或環(huán)境光（ambient light））和光源（如燈泡或其他照明設備）的客戶端侧蘸。照明控制器還可以作為設置客戶端的服務器（例如配置其參數(shù)的智能手機應用程序）。這樣的照明控制器可以被包括在傳感器或光源內鹉梨，或它可以是單獨的設備讳癌。

模型可以定義做為網(wǎng)絡節(jié)點的設備的功能，如密鑰管理存皂，地址分配和消息中繼晌坤。模型還定義了圍繞網(wǎng)絡節(jié)點構建的設備的物理行為逢艘，如功耗控制，照明控制和傳感器數(shù)據(jù)收集骤菠∷模可能有節(jié)點僅實現(xiàn)與網(wǎng)絡相關的功能，例如中繼節(jié)點或代理節(jié)點商乎，而大多數(shù)節(jié)點能夠通過控制電力央拖，控制光發(fā)射或感測環(huán)境數(shù)據(jù)來與物理世界交互。

一條消息可以被多個不同的模型使用鹉戚。消息行為在每個模型中都是相同的鲜戒，因此可以在客戶端，服務器和控制模型之間達成共識抹凳，因為無論發(fā)送和處理消息的模型如何遏餐，其行為都是一致的。

模型規(guī)格設計得非常小巧且獨立赢底。在規(guī)范定義的時候失都，模型可能需要其他模型，這些模型也必須在同一個節(jié)點中實例化幸冻。這稱為 擴展 粹庞，這意味著模型可以擴展其他模型。

不擴展其他模型的模型被稱為 根模型 洽损。

模型規(guī)范是不可變的：不可能刪除或向模型添加行為信粮，無論期望的行為是可選行為還是強制行為。模型沒有版本并且沒有特征位趁啸。

如果模型中需要額外的行為强缘，就定義一個新的擴展模型，公開所需的行為不傅，并可以與原始模型一起實施旅掂。

因此，知道元件所支持的模型访娶，就知道了該元件所暴露的確切行為商虐。

模型可能由Bluetooth SIG定義并采用，也可能由供應商定義崖疤。Bluetooth SIG定義的模型被稱為SIG采用的模型秘车，供應商定義的模型被稱為供應商模型。模型由唯一的標識符標識劫哼，對于SIG采用的模型叮趴，可以是16位，對于供應商模型可以是32位权烧。

例如眯亦， 圖2.4 顯示了一個設備的元件模型結構伤溉，該設備實現(xiàn)了具有兩個綁定狀態(tài)的根模型和一組在每個狀態(tài)下運行的消息。根模型位于主要元件內妻率，并由擴展模型進行擴展乱顾，在次要元件上添加另一個狀態(tài)。消息不能區(qū)分同一元件上同一狀態(tài)的多個實例宫静。因此走净，當設備上存在多于一個給定狀態(tài)的實例時，每個實例都需要位于一個單獨的元件中孤里。在這個例子中伏伯，狀態(tài)X的第二個實例需要位于第二個元件上，因為它是一個相同類型的狀態(tài)扭粱，因此具有相同類型的消息。

圖2.4：設備的元件模型結構

此示例結構可能會在復合設備中被倍乘震檩。例如琢蛤，復合設備可能有多個相同根模型（或擴展模型）的實例，每個實例都在一個單獨的元件（或一組元件）上抛虏。另外博其，如果一個模型（根或擴展）需要一個特定狀態(tài)的多個實例，該狀態(tài)必須分布在多個元件上迂猴，以至于任何給定狀態(tài)的單個實例至多在一個元件上慕淡。

圖2.5說明圖2.4設備的元件模型結構如何可能被執(zhí)行在一個復合設備中。該裝置的元件模型結構是由組合數(shù)據(jù)（Composition Data）（見描述 4.2.1） 沸毁， 其由配置客戶端部署后讀（見第5節(jié) ）峰髓，使用配置服務器模型和配置客戶端模型（參見第 4.4 0.1 和 4.4.2 ） 。

圖2.5：復合設備的元件模型結構

2.3.7 示例設備

為了幫助解釋元件內部模型的排列方式如何確定設備的狀態(tài)和行為息尺，我們將使用雙插槽智能電源板設備（如圖 2.6 所示 ） 作為示例携兵。該設備具有藍牙低功耗的單一無線電和兩個獨立的電源插座，每個電源插座均可控制功耗輸出搂誉。這個例子包括Mesh Model規(guī)范 [11]中 定義的狀態(tài)徐紧，消息和模型 。

圖2.6：雙插槽智能電源板

該設備具有兩個 代表兩個電源插座的 元件（見第 2.3.4 節(jié) ） 炭懊。每個元件都有一個分配給它的單播地址并级。

每個元件的功能由通用功耗級別服務器（Generic Power Level Server）模型定義。該模型定義了服務器上的一組狀態(tài)侮腹，以及一組對這些狀態(tài)進行操作的消息嘲碧。

通用功耗級別設置（Generic Power Level Set）消息可以被發(fā)送到設備以控制輸出功耗。該消息被發(fā)送到一個元件并在目標地址（DST）字段中攜帶該元件的地址（見第 2.3.8 節(jié) ）父阻。

插槽也可以通過實現(xiàn)通用級別客戶機（Generic Level Client）模型的通用設備（如調光器）進行控制（并且不知道任何有關功耗控制的內容）呀潭。該模型簡單地將期望水平設置為零钉迷，最大值或兩之間的值。通過狀態(tài)綁定來控制插座的電源钠署。在每個電源插座中糠聪，通用電源實際狀態(tài)都綁定到通用電平狀態(tài)。通用級客戶端將通用級消息發(fā)送到通用級服務器谐鼎。通用級別狀態(tài)發(fā)生改變舰蟆，反過來（通過已定義的綁定）改變控制功耗輸出的通用功耗實際狀態(tài)。

元件可以報告狀態(tài)狸棍。在我們的例子中身害，每個插座可以報告功耗水平以及插入插座的設備的能量消耗。使用Sensor Server模型定義的消息報告能耗草戈。每個消息的SRC字段中都有元件的地址塌鸯，用于標識套接字（請參見第 3.4.4.6 節(jié) ） 。

圖2.7 說明 雙插槽設備的單元模型結構唐片。功能上丙猬，這兩個要素 的設備具有相同的特征。唯一的區(qū)別是除了其他模型之外费韭，主要元件還處理用于網(wǎng)絡管理的配置服務器模型茧球。每個元件可以定義其他模型，如Health Server模型（參見第 4.4.4 節(jié) ）或Mesh Model規(guī)范 [11]中 定義的模型 星持。

圖2.7：示例設備的元件模型結構

2.3.8 發(fā)布 - 訂閱和消息交換

Mesh網(wǎng)絡內數(shù)據(jù)的發(fā)布和訂閱被使用使用發(fā)布 - 訂閱范例來描述抢埋。生成消息的節(jié)點將消息發(fā)布到單播地址，組地址或虛擬地址督暂。有興趣接收消息的節(jié)點將訂閱這些地址揪垄。

生成的消息被發(fā)送到的目標Mesh地址可以是單播，預先配置的組地址或虛擬地址逻翁。消息可以作為對其他消息的回復發(fā)送福侈，也可以是未經(jīng)請求的消息。當模型的實例發(fā)送回復消息時卢未，它將傳入消息始發(fā)的源地址用作目標地址肪凛。當模型的實例發(fā)送未經(jīng)請求的消息時，它將使用模型發(fā)布地址（model publish address）作為目標地址辽社。節(jié)點中的每個模型實例都有一個發(fā)布地址伟墙。

在接收端，節(jié)點內模型的每個實例可以訂閱一個或多個組地址或虛擬地址滴铅。無論何時發(fā)送到模型預訂列表中的某個組地址或虛擬地址的消息到達時戳葵，該消息都將由該節(jié)點處理。

當目的地址是接收元件的單播地址汉匙，或目的地址是該設備所屬的固定組地址時拱烁，也會處理該消息生蚁。如果一個節(jié)點有多個元件，那么該消息在被尋址的每個元件上處理一次戏自。

由更高層規(guī)范定義的模型的發(fā)布地址和預訂列表（Publish addresses and subscription lists）使用由配置服務器模型（Configuration Server Model）管理的模型發(fā)布和預訂列表狀態(tài)（Model Publication and Subscription List states）邦投。

節(jié)點可以為模型元件的每個實例擁有任意數(shù)量的訂閱，盡管節(jié)點可能會限制支持的訂閱數(shù)量擅笔。使用多個訂閱地址允許節(jié)點響應發(fā)布到不同組的消息志衣。例如，燈可以訂閱發(fā)送到床頭燈組猛们，臥室組念脯，樓上組和家庭組的消息。

每條消息都從一個單播地址（一個元件地址）發(fā)送弯淘，并使用唯一的序列號進行排序绿店，以便檢測和防止重放攻擊。

消息可以被確認或無確認（見第 3.7.5 節(jié) ）庐橙。有確認的消息（例如Get消息）會產(chǎn)生響應消息;無確認的消息（例如假勿，狀態(tài)消息）不會引起響應。

2.3.9 安全

所有消息都使用兩種密鑰進行加密和驗證怕午。一種密鑰類型用于網(wǎng)絡層通信废登，使得Mesh網(wǎng)絡內的所有通信都將使用相同的網(wǎng)絡密鑰淹魄。另一種密鑰類型用于應用程序數(shù)據(jù)郁惜。分離網(wǎng)絡和應用的密鑰允許將敏感訪問消息（例如，用于建筑物的訪問控制）與非敏感訪問消息（例如甲锡，用于照明）分開兆蕉。Mesh網(wǎng)絡中沒有未加密或未認證的消息。

2.3.9.1 應用程序和網(wǎng)絡安全

在上層傳輸層和網(wǎng)絡層對消息進行加密和認證的目的是保護Mesh網(wǎng)絡內的通信缤沦，防止竊聽和惡意攻擊虎韵。每層保持不同的密鑰以允許應用程序和網(wǎng)絡實體之間的分離。

從網(wǎng)絡密鑰中分割應用密鑰可實現(xiàn)應用消息的安全中繼傳輸：中繼節(jié)點可以在網(wǎng)絡級別對消息進行身份驗證缸废，而無需訪問應用程序數(shù)據(jù)包蓝。例如，充當中繼節(jié)點的燈泡應該無法打開門企量。

這意味著節(jié)點可以使用從網(wǎng)絡密鑰導出的密鑰中繼訪問消息测萎，而無需知道應用密鑰;因此他們將無法更改或理解應用程序數(shù)據(jù)。預計網(wǎng)絡密鑰將被網(wǎng)絡中的許多節(jié)點廣泛知曉届巩，從而增加中繼節(jié)點的密度硅瞧，同時保護不同的應用區(qū)域。這需要為每個應用程序分配密鑰恕汇。例如腕唧，敏感的門安全應用將與非敏感的門鈴和照明應用分開或辖。

應用程序密鑰（application key）直接與相關的應用程序密鑰標識符（application key identifier）一起使用，該標識符在特定上下文中用于標識所使用的應用程序枣接。但是颂暇，網(wǎng)絡密鑰始終通過密鑰派生函數(shù)（key derivation function）使用，以生成直接使用的其他密鑰月腋。這種密鑰的例子包括加密和保密密鑰（encryption and privacy keys）蟀架。這允許更改單個網(wǎng)絡密鑰，且所有從此密鑰導出的相關值都能被快速導出榆骚。

與應用密鑰一樣片拍，網(wǎng)絡密鑰也用于派生網(wǎng)絡密鑰標識符（見第 3.8.6 節(jié) ） 。

安全模型定義了三個單獨的密鑰（設備密鑰（DevKey）妓肢，應用密鑰（AppKey）和網(wǎng)絡密鑰（NetKey））來保護消息捌省。當一個節(jié)點被給予一個密鑰時，它被授權使用該密鑰碉钠。在多個節(jié)點之間共享的密鑰使任何具有該密鑰的節(jié)點能夠使用該密鑰發(fā)送和接收消息纲缓。

設備密鑰（device key）便于配置客戶端和單個節(jié)點之間的密鑰材料的機密性和身份驗證（confidentiality and authentication）。應用程序密鑰便于在預定節(jié)點之間發(fā)送的應用程序數(shù)據(jù)的機密性和身份驗證喊废。網(wǎng)絡密鑰便于網(wǎng)絡消息的隱私性祝高，機密性和真實性。節(jié)點可能具有單個設備密鑰污筷，多個應用密鑰和多個網(wǎng)絡密鑰的知識工闺。

設備密鑰類似于應用密鑰，因為其設計用于保護上層傳輸層中的應用發(fā)送的信息瓣蛀。但是陆蟆，設備密鑰僅由配置客戶端和單個節(jié)點知道。Configuration Client知道所有節(jié)點的設備密鑰惋增，這允許Configuration Client通過發(fā)送這些用每個單獨節(jié)點的設備密鑰保護的密鑰來安全地將密鑰分發(fā)給一組節(jié)點叠殷，從而允許密鑰分發(fā)僅針對那些需要知道的節(jié)點。設備密鑰的使用旨在防止“垃圾桶（trash-can）”攻擊（一種從丟棄的設備中檢索信息的技術诈皿，可用于對網(wǎng)絡執(zhí)行攻擊）林束，方法是允許僅限選定的設備分發(fā)新的網(wǎng)絡和應用程序密鑰。

應用程序密鑰只能與單個網(wǎng)絡密鑰一起使用稽亏。這意味著網(wǎng)絡密鑰有一個或多個與之相關的應用密鑰壶冒。這種關聯(lián)（association）被稱為密鑰綁定（key binding）。

訪問層安全的粒度基于每個模型措左。每個服務器模型（server model）都有一組綁定的應用程序密鑰依痊，用于定義應該用于加密和驗證要由模型處理的消息的可能密鑰。這允許多個實體操作某些節(jié)點功能。最多可以將251個應用程序密鑰綁定到模型胸嘁。例如瓶摆，Light Lightness服務器模型有三個密鑰綁定到它，因為管理員性宏，用戶和來賓都可以打開燈光群井。但是，只有管理員可以配置指示燈毫胜，因此配置服務器模型（Configuration Server Model）只有管理應用程序密鑰綁定到它书斜。

2.3.9.2 混淆

網(wǎng)絡安全模型利用稱為混淆（obfuscation）的隱私機制，該機制利用AES使用私鑰對源地址酵使，序列號和其他頭信息進行加密荐吉。混淆的目的是使跟蹤節(jié)點更加困難口渔。

2.3.9.3 網(wǎng)絡和應用程序密鑰標識

一個節(jié)點可能有多個網(wǎng)絡或應用程序密鑰样屠。

通過使用密鑰標識符，可以識別哪個密鑰子集（subset of keys）用于保護消息缺脉。例如痪欲，節(jié)點可能只需要檢查密鑰標識符具有相同最低有效位的兩個密鑰，而無需檢查20個密鑰攻礼。如果收到的消息中有一個未知的密鑰標識符业踢，則該節(jié)點可以立即丟棄該消息。

密鑰標識符是使用密鑰派生函數(shù)從網(wǎng)絡或應用密鑰生成的礁扮。

該規(guī)范為網(wǎng)絡密鑰和應用密鑰定義了一個單獨的標識符知举。網(wǎng)絡密鑰標識符使用7位值在每個網(wǎng)絡PDU中傳送，而應用密鑰標識符使用6位值在每個低層傳輸層（Lower Transport）PDU中傳送深员。

2.3.9.4 初始化向量索引

一個網(wǎng)絡PDU包含一個24位序列號负蠕，允許一個元件發(fā)送16,777,216個網(wǎng)絡PDU蛙埂。序列號用于安全隨機數(shù)（security nonce）以提供唯一性;因此序號不能換行倦畅。如果某個元件以2 Hz發(fā)送新消息，那么這些序列號將在97天后耗盡绣的。為了使Mesh網(wǎng)絡能夠運行比序號空間允許的更長時間段叠赐，定義了一個附加的4字節(jié)值，稱為IV索引（IV Index）屡江，該值包含在安全隨機數(shù)（security nonce）中芭概。例如，使用相同的2Hz消息頻率將在數(shù)十億年內使用IV索引來測量網(wǎng)絡的生命周期惩嘉。

為了實現(xiàn)從一個IV索引到下一個索引的逐步過渡罢洲，每個網(wǎng)絡PDU包括用于傳輸該消息的IV索引的最低有效位。節(jié)點還可以使用IV更新過程（IV Update procedure）向對等節(jié)點發(fā)信號通知它正在更新IV索引。此過程至少需要八天時間才能從舊IV索引轉換到新IV索引惹苗，從而將節(jié)點發(fā)送消息的頻率限制在24 Hz內殿较。但是，節(jié)點不應在任何10秒的窗口內發(fā)送超過100個網(wǎng)絡PDU桩蓉，因此通常需要耗費大約19天的時間淋纲。

2.3.10 Friendship

低功耗節(jié)點使用Friendship來限制他們需要收聽的時間。如果一個節(jié)點不能連續(xù)接收院究，那么它可能不會收到它應該處理的Mesh消息洽瞬。這包括維護網(wǎng)絡安全所需的安全更新以及正常的Mesh消息。

如果低功耗節(jié)點沒有收到這樣的消息业汰，那么它可能無法按預期運行伙窃，并且它也可能無法保持最新的網(wǎng)絡安全狀態(tài)，并且如果在它不知道的情況下更改了此安全性样漆，它最終會退出網(wǎng)絡对供。

Friendship是一個低功耗節(jié)點和一個鄰居Friend節(jié)點（Friend node）之間的特殊關系。這些節(jié)點必須位于彼此的單跳內并處于同一子網(wǎng)內氛濒。

Friendship首先由低功耗節(jié)點建立和發(fā)起;一旦建立产场，F(xiàn)riend節(jié)點將執(zhí)行一些操作，以幫助降低低功耗節(jié)點上的功耗舞竿。Friend節(jié)點為低功耗節(jié)點維護一個Friend Queue京景，該節(jié)點存儲發(fā)往低功耗節(jié)點的所有傳入消息。當?shù)凸墓?jié)點請求時骗奖，F(xiàn)riend節(jié)點將這些消息傳遞給低功耗節(jié)點确徙。另外，F(xiàn)riend節(jié)點將安全更新傳遞給低功耗節(jié)點执桌。

當在低功耗節(jié)點和一個Friend節(jié)點之間建立Friendship時鄙皇，這兩個節(jié)點被認為是“Friend”。

Friend節(jié)點可以是多個低功耗節(jié)點的Friend仰挣。低功耗節(jié)點只能是單個Friend節(jié)點的Friend伴逸。

圖 2.3.12中 顯示并描述了一個說明Friend節(jié)點和低功耗節(jié)點的Mesh網(wǎng)絡的示例拓撲 。

2.3.11 特性

節(jié)點的功能取決于它們支持的特性膘壶。所有節(jié)點都有能力發(fā)送和接收Mesh消息错蝴。節(jié)點還可以選擇支持一個或多個附加特性：

• 中繼（Relay）特性 - 通過廣告Bearer接收和轉發(fā)Mesh消息以啟用大型網(wǎng)絡的能力。
• 代理（Proxy）特性 - 在GATT和廣告Bearer之間接收和轉發(fā)Mesh消息的能力颓芭。
• 低功耗特性 - 只在支持Friend功能的節(jié)點支持下就能在Mesh網(wǎng)絡中運行并大幅降低接收器占空比的能力顷锰。
• Friend特性 - 通過存儲指向這些節(jié)點的消息來幫助支持低功耗功能的節(jié)點進行操作的能力。

支持某個特性的節(jié)點可能啟用或禁用該特性亡问，并且特性啟用時官紫，可能正在使用或未使用。

支持中繼（Relay）特性的節(jié)點可能禁用了此功能，但它仍然可以支持中繼功能束世，只是它沒有執(zhí)行該特性所需的功能悼吱。支持中繼特性并啟用中繼特性的節(jié)點稱為中繼節(jié)點。

支持代理特性的節(jié)點可能禁用了此特性良狈，但它仍然可支持代理特性后添，只是它沒有執(zhí)行該特性所需的功能。支持代理特性并啟用代理特性的節(jié)點稱為代理節(jié)點薪丁。

支持低功耗特性的節(jié)點不能禁用此特性遇西，并且必須與支持Friend特性的其他節(jié)點建立Friendship，然后才能使用低功耗特性來減少接收器占空比严嗜。支持低功耗特性并與支持Friend特性的節(jié)點建立Friendship的節(jié)點稱為低功耗節(jié)點粱檀。

支持Friend特性的節(jié)點可能禁用了此特性，但它仍然可以支持Friend特性漫玄，只是它沒有執(zhí)行該特性所需的功能茄蚯。支持Friend特性的節(jié)點啟用了Friend特性，并且與支持Low Power特性的節(jié)點之間具有Friendship的節(jié)點被稱為Friend節(jié)點睦优。

2.3.12 拓撲

支持上述各種特性的節(jié)點可以形成Mesh網(wǎng)絡渗常。圖2.8 顯示了Mesh網(wǎng)絡的圖示

圖 2.8 ：Mesh網(wǎng)絡的拓撲示例

如圖2.8 所示 三個中繼節(jié)點：Q，R和S.支持Friend功能的三個節(jié)點分別是N汗盘， O和P皱碘，但是N沒有任何Friendship;因此只有O和P是Friend節(jié)點。有五個低功耗節(jié)點：I隐孽，J癌椿，K，L和M.節(jié)點I菱阵，J和K以P為Friend踢俄，而L和M以O為Friend体谒。節(jié)點T僅使用GATTBearer連接到Mesh網(wǎng)絡;因此S必須將所有消息中繼給T.

例如琴儿，如果消息要從T發(fā)送到L鞭呕，則T將使用GATTBearer將消息發(fā)送到節(jié)點S.節(jié)點S將使用廣告Bearer重傳此消息贩挣。節(jié)點H，R巩踏，N和O在節(jié)點S的無線電范圍內;因此他們會收到此消息音榜。作為節(jié)點L的Friend的節(jié)點O將存儲該消息，并且如果該消息是分段消息动雹，則節(jié)點O將在下層傳輸層處用確認進行響應。稍后跟压，L將輪詢節(jié)點O以檢查新消息胰蝠，使得O將T最初發(fā)送的消息轉發(fā)給L.

2.4 Mesh網(wǎng)關

Mesh網(wǎng)關是能夠在Mesh網(wǎng)絡和非藍牙技術之間轉換消息的節(jié)點。節(jié)點可能能夠通過Mesh網(wǎng)關發(fā)送和接收Mesh消息，而不在任何中繼節(jié)點的范圍內茸塞。該轉換超出了本規(guī)范的范圍躲庄。

2.5 并發(fā)極限和限制（Concurrency limitations and restrictions）

受本規(guī)范約束的節(jié)點沒有做并發(fā)極限或限制。

2.6 拓撲極限和限制（Topology limitations and restrictions）

與藍牙低功耗傳輸一起使用時钾虐，本規(guī)范沒有做拓撲極限或限制噪窘。