文章目錄
- 前言：
- 一、SIG MESH Bearer Layer
-
- 1.1 Advertising Bearer Layer
- 1.2 GATT Bearer Layer
- 二、SIG MESH Provisioning
-
- 2.1 Unprovisioned Device Beacon
- 2.2 MESH Provisioning Process
-
- 2.2.1 Link Establishment Procedure
- 2.2.2 Provisioning Protocol
- 三、MESH Beacon and Security state
-
- 3.1 Key Refresh procedures
- 3.2 IV Update procedure
- 四、SIG MESH Network Layer
-
- 4.1 Publish/Subscribe Addresses
- 4.2 Encrypted/Obfuscated Network PDU
- 4.3 Receiving/Transmitting Network PDU
- 五、SIG MESH Transport Control messages
-
- 5.1 Unsegmented Control Message
-
- 5.1.1 Heartbeat message
- 5.1.2 Friendship messages
- 5.1.3 Segment Acknowledgment message
- 5.2 Segmented Control message
- 更多文章：
前言：
前篇博文BLE MESH 是如何設計的 介紹了SIG MESH 為解決大規模物聯網裝置之間安全可靠高效通信的問題，采用了哪些設計來傳遞消息并應對各種網絡攻擊的、如何支援低功耗節點和大量現有BLE GATT 節點的入網通信等。前篇博文從解決問題的角度介紹了SIG MESH 協定的設計方案，本篇博文從MESH 消息封包在各協定層的傳遞過程，介紹SIG 是如何設計MESH 封包結構的、又是如何處理MESH 封包消息的。
- Bearer Layer：定義了如何使用底層BLE 協定棧傳輸MESH 消息封包PDU，目前定義了Advertising Bearer 和GATT Bearer 兩種承載層。其中GATT Bearer 是為了讓現有無法更新MESH 協定的BLE 裝置接入MESH 網絡，Advertising Bearer 是MESH 協定主要的承載層，Advertising Bearer 又可分為Mesh Beacon Advertising Bearer 和Mesh Advertising Bearer，前者主要用來啟動配網和更新安全密鑰，後者主要用來傳輸消息；
- Network Layer：定義了MESH 消息封包如何安全尋址到一個或一組元素，啟動配網後分發的NetKey 就是用于網絡層消息封包加解密認證和完整性校驗的（實際使用的是NetKey 派生的EncryptionKey 和PrivacyKey）。網絡層為不同的承載層定義了不同的網絡接口（包括用于本節點内不同元素間通信的本地網絡接口），可通過配置 input / output filter 對經網絡接口輸入或輸出的消息進行過濾，從網絡接口接收到的封包根據其目的位址字段判斷是需要中繼/代理轉發還是遞交上層處理；
- Lower Transport Layer：定義了如何将上層傳輸層消息分段為多個網絡層協定可以處理的大小，如何将來自網絡層協定的分段資料重新組合為完整消息遞交給上層傳輸層處理，還定義了用于确認重傳的分段消息應答封包。如果是Friend 節點接收到了要發送給與其建立友誼關系的低功耗節點的封包，則在該層将消息封包放入對應的Friend Queue，待收到來自LPN 的Friend Poll 封包後将緩存封包發送給LPN；
- Upper Transport Layer：定義了如何對應用消息（也即來自通路層的Access PDU）進行加解密認證和完整性校驗（應用消息使用與模型綁定的AppKey 加密認證，配置消息使用為目标節點配置設定的DevKey 加密認證）。上層傳輸層也會為每個消息配置設定一個序列号SEQ 用于防護中繼/重播攻擊，該層還定義了用于管理Friendship 和Heartbeat 相關的控制封包（用于管理LPN 與FN 之間友誼建立/終止、訂閱位址添加/移除、消息輪詢與發送，心跳封包釋出/接收、節點距離或跳數Hop count 計算等過程）；
- Access Layer：定義更高層應用程式如何使用上層傳輸層，比如定義應用程式資料的格式（通常指各種 Model）、定義和控制上層傳輸層執行的應用資料加密和解密過程（AppKey 通常是綁定到特定Model 的）、驗證從上層傳輸層接收的資料是否适用于正确的網絡和應用程式（封包中的NetKeyIndex 和AppKeyIndex 等資訊）等，通過驗證的消息根據目的位址和模型識别碼遞交給目标元素和目标模型處理；
- Foundation Model Layer：定義了配置和管理MESH 網絡及其節點裝置所需的狀态、消息和模型。基礎模型層主要定義了兩組模型：一組是配置服務端模型和配置用戶端模型，MESH 網絡所有裝置節點都需要實作配置服務端模型（包含一系列與配置相關的狀态和消息），為該裝置節點提供各種配置能力（比如配置釋出消息時的目的位址和TTL、元素或模型的訂閱位址、裝置節點可能扮演的Relay/Friend/Low Power/Proxy 角色等），使用者可以使用實作了配置用戶端模型的裝置（比如智能手機APP）憑對應的DevKey 來擷取或改變裝置節點的配置狀态；另一組是健康服務端模型和健康用戶端模型，MESH 網絡所有裝置節點的主元素都需要實作健康服務端模型（包含一系列與故障相關的狀态和消息），為該裝置節點提供各種故障報告和診斷能力（比如目前故障、注冊故障等），使用者可以使用實作了健康用戶端模型的裝置（比如智能手機APP）憑對應的AppKey 來擷取或接收裝置節點的健康狀态；
- Model Layer：定義了用于标準化典型使用者場景操作的模型，目前SIG MESH Model Specification 中定義了Generics、Sensors、Time and Scenes、Lighting 等四組模型，每組模型都包含一系列具體的模型，每個模型都定義了一組狀态、狀态間的綁定關系、作用于狀态的消息、響應消息的行為等。除了上述SIG 定義的Bluetooth SIG models，供應商也可以在SIG 模型無法滿足需求的情況下定義Vendor models；
- Application Layer：應用開發服務于使用者場景、依托于各種标準化模型，通過業務邏輯把不同功能的Model 組合起來，實作一個特定功能或者服務，比如樓宇照明網絡中的複雜燈控功能、工廠工廠中的房間或農業大棚傳感網絡中的複雜監測功能、智能家居各種MESH 裝置間的複雜關聯功能等。
一、SIG MESH Bearer Layer
SIG MESH 作為網絡協定，是承載在BLE 實體層和資料鍊路層之上的，為了使用BLE 協定棧傳輸MESH 消息封包PDU，引入了MESH Bearer Layer。
目前MESH Bearer Layer 定義了Advertising Bearer 和GATT Bearer 兩種承載層：GATT Bearer 是為了讓無法更新MESH 協定的BLE 裝置能夠接入MESH 網絡；Advertising Bearer 則是SIG MESH 網絡主要的消息封包傳輸承載層。
1.1 Advertising Bearer Layer
雖然BLE 5.x 協定為了提高傳輸速率和擴大傳輸距離，新增支援LE 2M PHY 和LE Coded PHY 兩種空口封包；為了提高廣播能力，新增支援Extended Advertising Channel（可以将資料信道作為廣播信道使用，且單個擴充廣播包可承載更多載荷資料）。
但是，目前的SIG MESH 1.0.1 協定并不支援BLE 5.x 協定的新特性，仍然使用傳統的 3 個固定廣播信道（channel 37、38、39）和LE 1M PHY 空口封包來傳輸MESH 消息封包（或許後續的MESH 2.x 協定支援BLE 5.x 協定新特性吧）。
SIG MESH 廣播包并不需要對方連接配接，也不會響應對方的掃描請求，是以MESH Advertising Bearer Layer 使用ADV_NONCONN_IND 廣播封包來承載MESH 消息封包。不可連接配接不可掃描非定向的廣播封包payload 支援的AdvData 最大長度為 31 octets，是以MESH Advertising Bearer 封包的最大長度也隻有 31 位元組。
AdvData 被劃分為一系列AD structures，每個AD structure 包含AD Length、AD Type、Content 三個字段。每個MESH 廣播封包隻包含一個AD structure，MESH 協定僅支援如下三種廣播封包（參閱：Assigned Numbers – GAP）：
| AD Type | Type Name | Content |
|---|---|---|
| 0x29 | «PB-ADV» | PB-ADV PDU，包含 Link ID (4 octets)、Transaction Number (1 octets)和Generic Provisioning PDU (1 - 24 octets) 三部分 |
| 0x2A | «Mesh Message» | Network PDU (1 - 29 octets) |
| 0x2B | «Mesh Beacon» | Mesh Beacon PDU，包含Beacon Type (1 octets) 和Beacon Data 兩部分，其中Beacon Type 目前隻定義了Unprovisioned Device beacon 和Secure Network beacon 兩種類型 |
- «PB-ADV»：主要用于啟動配網過程中邀請入網–>建立安全通道–>身份認證–>安全密鑰分發等過程必要資訊的傳輸，可以承載的Generic Provisioning PDU 最大為24 個位元組。Link ID 用于辨別Provisioner 與New Device之間建立的通信鍊路，Transaction Number 則用于辨別每個單獨的Generic Provisioning PDU（分段或重傳封包的Transaction Number 相同，新的單獨PDU 封包則Transaction Number 自增 1）；
- «Mesh Message»：主要用于承載MESH 網絡層的消息封包，可承載的Network PDU 最大為29 個位元組；
- «Mesh Beacon»：目前定義了Unprovisioned Device beacon 和Secure Network beacon 兩種類型：Unprovisioned Device beacon 主要用于未配網裝置對外廣播，以便Provisioner 能發現自己，并向自己發出入網邀請；Secure Network beacon 主要用于識别并通知子網内的裝置節點進行 IV Index 更新或密鑰重新整理過程。
MESH 網絡節點之間通過ADV_NONCONN_IND 廣播封包進行通信時，需要裝置同時支援GAP Observer role 和GAP Broadcaster role。由于MESH 網絡節點裝置随時都有可能接收到消息封包，為了避免丢失傳入的廣播資料包，MESH 裝置應以盡可能接近 100% 的占空比執行被動掃描過程（也即scanWindow 盡可能等于scanInterval）。為了盡量降低多個MESH 裝置節點同時廣播導緻廣播信道上資料包沖突的機率，廣播間隔advInterval 應盡可能設定為随機值。
1.2 GATT Bearer Layer
MESH GATT Bearer Layer 是為了讓無法更新MESH 協定的BLE 裝置能夠接入到MESH 網絡中而設計的，GATT Bearer Layer 使用Proxy protocol 通過GATT 連接配接在兩個裝置之間發送或接收Proxy PDU。
使用BLE GATT 連接配接傳輸資料需要在GATT Server 實作相應的GATT Service 和Characteristic，GATT Client 則通過發現Service、讀寫Characteristic 實作服務資料的傳輸。
MESH GATT Bearer 定義了兩個角色：GATT Bearer Server 和GATT Bearer Client，由于二者使用Proxy protocol 通信，是以也可稱為MESH Proxy Server 和MESH Proxy Client。
MESH GATT Bearer 也提供了兩個GATT 服務：Mesh Provisioning Service 和Mesh Proxy Service，每個Service 都提供了兩個Characteristic（參閱：Assigned Numbers – 16-bit UUIDs）：
| GATT Services UUID | GATT Services Name | GATT Characteristic |
|---|---|---|
| 0x1827 | Mesh Provisioning Service | Mesh Provisioning Data In (0x2ADB) Mesh Provisioning Data Out (0X2ADC) |
| 0x1828 | Mesh Proxy Service | Mesh Proxy Data In (0X2ADD) Mesh Proxy Data Out (0X2ADE) |
GATT Bearer Client 發現GATT Bearer Server 提供的Service 和Characteristic 後（可參閱：GATT Profile 和Service Discovery），通過Mesh Provisioning/Proxy Data In Characteristic 的Write Without Response 方法向GATT Bearer Server 發送資料，通過Mesh Provisioning/Proxy Data Out Characteristic 的Notify 方法從GATT Bearer Server 接收資料，實作在GATT 連接配接上發送或接收Proxy PDU 的功能。
MESH GATT Bearer 通過Mesh Provisioning Service 或Mesh Proxy Service 傳輸的Proxy PDU 格式如下：
MESH Proxy PDU 目前支援的消息類型有四種：
- Network PDU：MESH 網絡層的消息封包，同MESH Advertising Bearer 中的«Mesh Message»，是否需要分段傳輸取決于ATT_MTU 的配置值；
- Mesh Beacon：同MESH Advertising Bearer 中的«Mesh Beacon»，目前定義了Unprovisioned Device beacon 和Secure Network beacon 兩種類型；
- Proxy Configuration：主要用于Proxy Client 向Proxy Server 配置過濾條件，Data 部分由Opcode(1 octets) 和Parameters(variable) 兩部分構成（相當于配置Proxy Client 的訂閱位址清單），比如向Proxy Server 維護的白名單或黑名單中新增或删除位址；
- Provisioning PDU：用于Provisioner 與New Device之間啟動配網過程中必要資訊的交換，MESH Advertising Bearer 中的Generic Provisioning PDU 由«PB-ADV» 承載，MESH GATT Bearer 中Provisioning PDU 則是由«PB-GATT» 承載。
由此可知，MESH Advertising Bearer 和MESH GATT Bearer 封裝的有效載荷Network PDU、Mesh Beacon、Provisioning PDU 都是相同的，隻是MESH Bearer Layer 封裝的外殼有差別。
二、SIG MESH Provisioning
一個BLE 新裝置要想加入到一個MESH 網絡中并與其它MESH 節點通信，需要通過執行啟動配網過程Provisioning。啟動配網過程是 Provisioner 向對外廣播Unprovisioned Device beacon 封包的裝置發起入網邀請–>建立安全通信鍊路–>驗證入網者身份–>分發網絡安全密鑰等一系列過程的組合（參閱博文：啟動配網與密鑰分發）。
2.1 Unprovisioned Device Beacon
一個BLE 裝置上電啟動後，要想讓附近的Provisioner 發現該裝置，并向自己發起配網邀請，自己需要周期性向外廣播Unprovisioned Device Beacon 封包。Provisioner 裝置掃描到Unprovisioned Device Beacon 封包後，才知道附近有想要入網的裝置，可以向其發送入網邀請封包。
Unprovisioned Device Beacon 封包是«Mesh Beacon» 的其中一種類型，該封包的格式如下：
| Field | Size (octets) | Description |
|---|---|---|
| Beacon Type | 1 | Unprovisioned Device beacon type (0x00) |
| Device UUID | 16 | 這個裝置的全局唯一辨別符，128 位UUID |
| OOB Information | 2 | 通知Provisioner 本裝置OOB 資料的可用性，比如是否支援通過二維碼或者NFC傳輸裝置公鑰 |
| URI Hash | 4 | 指向OOB 資訊（比如裝置公鑰）的統一資源定位符哈希值，該字段是可選的 |
Provisioner 掃描到附近廣播Unprovisioned Device Beacon 封包的裝置，就可以向該裝置發起配網邀請封包，開始啟動配網過程了。
2.2 MESH Provisioning Process
MESH 啟動配網過程是Provisioner 将Unprovisioned Device 加入到MESH 網絡中的過程。Provisioner 可以是手機、平闆電腦或其它智能裝置，每個MESH 網絡隻需要一個Provisioner 裝置，當然也支援多個Provisioner 裝置，但同一MESH 網絡中的多個Provisioner 裝置資料要共享且同步。
啟動配置裝置Provisioner 與Unprovisioned Device 在進行啟動配網過程中，需要交換很多資料封包，啟動配網過程的封包可統稱為Provisioning PDU。對于支援MESH 協定的裝置，使用Advertising Bearer Layer 承載資料封包，Provisioning PDU 便封裝在PB-ADV 廣播封包中。對于不支援MESH 協定的BLE 裝置，使用GATT Bearer Layer 承載資料封包，Provisioning PDU 便封裝在PB-GATT 資料封包中，且Provisioner 需要提供Mesh Provisioning Service 來傳輸PB-GATT 資料封包。
2.2.1 Link Establishment Procedure
Provisioner 與Unprovisioned Device 之間交換Provisioning PDUs，雙方需要建立可靠的通信鍊路，甚至應該支援資料包的分片重組功能。
對于PB-GATT 承載的Provisioning PDUs，Provisioner 與Unprovisioned Device 之間的通信鍊路由BLE GATT 管理，借助GATT Mesh Provisioning Service 在雙方之間傳遞資料封包還是比較可靠的。如果ATT_MTU 設定長度不足以容納完整的Provisioning PDUs 封包，則Proxy PDU 中的SAR(Segmentation And Reassembly) 字段可用于同一Provisioning PDU 被分割為多個 Attribute PDU（包括反向重組過程）。
對于PB-ADV 承載的Provisioning PDUs，Provisioner 與Unprovisioned Device 之間的通信封包在Advertising 信道傳輸，單向廣播通信屬于不可靠通信，MESH 協定需要在進行廣播通信的裝置間建立并維護可靠的通信鍊路，該如何基于單向廣播信道建立可靠的通信鍊路呢？
基于單向廣播通信建立可靠的通信鍊路，可以參考連接配接通信建立的過程。BLE 連接配接建立過程是Initiator 向特定Advertiser 發送包含Device Address 的連接配接請求封包，Provisioning 鍊路建立過程則是Provisioner 向特定Unprovisioned Device 發起鍊路建立封包：
由于廣播通信是單向的，要保證通信的可靠性，需要通信對端裝置回複Ack 應答封包，上圖中Unprovisioned Device 向Provisioner 回複的Link Ack 封包就是響應Link Open 封包的，前面介紹的«PB-ADV»封包中的Link ID 則可以辨別這裡建立的通信鍊路。
Provisioner 與Unprovisioned Device 之間建立通信鍊路後，如何保證通信的可靠性呢？首先就是為了解決單向通信的不可靠性，引入Ack 确認應答封包，可以讓通信對端及時知道前一個資料包是否被正确接收。
除了确認應答封包設計，還需要考慮單個PB-ADV 無法承載完整的Provisioning PDU 封包，需要支援封包的分片重組功能。前面介紹的«PB-ADV»封包中的Transaction Number 字段可以辨別每個單獨的Generic Provisioning PDU，但如何區分這個單獨的Provisioning PDU 分割出的起始封包和後續封包呢？
參考Proxy PDU 中SAR 字段的作用，«PB-ADV»封包中的Generic Provisioning PDU 除了承載Generic Provisioning PDU 外，還可以設計控制通信鍊路建立、封包确認應答、區分每個單獨的Generic Provisioning PDU 分割出的起始封包和後續封包的Generic Provisioning Control 部分。于是，«PB-ADV»封包的格式設計成如下的樣子（圖檔取自博文：Mesh Provisioning）：
從上圖各字段的名字也可以看出其作用，比如Provisioning Bearer Control PDU 設計了通信鍊路建立、應答、關閉等三種封包，Transaction Start PDU 和Transaction Continuation PDU 則辨別每個單獨的Generic Provisioning PDU 分割出的起始封包和後續封包，Transaction Acknowledgment PDU 則是确認應答封包。也即，«PB-ADV»封包中的Generic Provisioning Control 部分用于Provisioner 與Unprovisioned Device 之間基于廣播信道建立可靠的通信鍊路，保證Provisioning Process 的順利進行。
2.2.2 Provisioning Protocol
Provisioner 與Unprovisioned Device 之間建立了可靠的通信鍊路後，就可以使用Provisioning Protocol 執行啟動配網過程了。Provisioning Process 的四個階段（邀請Unprovisioned Device 入網–>建立安全通信鍊路–>驗證Unprovisioned Device 的身份–>向Unprovisioned Device 分發安全密鑰）已經在前篇博文中介紹過了，這裡列出四個階段使用到的Provisioning PDU 格式及類型說明（每種類型Provisioning PDU 的格式設計可參閱Mesh Profile Section 5.4）：
Provisioner 與Unprovisioned Device 之間的啟動配網過程，可以對比BLE Central/Master 與BLE Peripheral/Slave 之間的LE 安全配對過程來了解。整個啟動配對過程的流程如下：
- Scan for Unprovisioned Device Beacons：Provisioner 掃描周圍Unprovisioned Device 廣播的Unprovisioned Device Beacon，并根據該封包中的OOB Information 字段資訊判斷OOB 資訊是否可用；
- Invitation & Capabilities：Provisioner 根據Unprovisioned Device Beacon 封包中的Device UUID 資訊選擇邀請入網的裝置，并向其發送Provisioning Invite 入網邀請封包，收到該封包的Unprovisioned Device 則回複Provisioning Capabilities 封包，告知Provisioner 自己支援的元素數量、安全算法、是否支援OOB 公鑰、Input/Output/Static OOB 能力等資訊；
- Start without / using OOB Public Key：Provisioner 收到Provisioning Capabilities 封包後，向Unprovisioned Device 發送Provisioning Start 封包，告訴對方自己選擇的安全算法（目前MESH 僅支援FIPS P-256 Elliptic Curve）、是否使用OOB 公鑰、身份認證方法等資訊，并使用Provisioning Public Key 封包向其發送公鑰資訊。若使用OOB 公鑰，則Provisioner 通過OOB 鍊路（比如二維碼或者NFC鍊路）從Unprovisioned Device 讀取公鑰資訊，若不使用OOB 公鑰 則Unprovisioned Device 通過Provisioning Public Key 封包向Provisioner 發送公鑰資訊。雙方交換公鑰後，通過ECDH 密鑰協商算法計算出共享密鑰，并通過共享密鑰加密建立安全通信鍊路；
- Use Output / Input / Static / No OOB：Provisioner 為了保證MESH 網絡安全，需要使用者參與驗證入網者的身份，防止攻擊者的裝置入網擷取安全密鑰。Provisioner 根據標明的身份認證方法對Unprovisioned Device 進行身份認證：若選擇Output OOB 認證方法，使用者可以将Unprovisioned Device 閃爍/蜂鳴次數或者顯示的數字字母資訊輸入到Provisioner 中；若選擇Input OOB 認證方法，使用者可以向Unprovisioned Device 按壓/扭轉/輸入 Provisioner 顯示的數字，完成輸入後Unprovisioned Device 向Provisioner 發送Provisioning Input Complete 封包；若選擇Static OOB，使用者可以向Provisioner 輸入與Unprovisioned Device 綁定的特定資訊；若選擇No OOB 則不需要使用者參與認證，是以是不安全的。使用者輸入認證資訊後，雙方還需要計算出Confirmation value，并通過Provisioning Confirmation 和Provisioning Random 封包完成Confirmation value 的校驗；
- Distribution of Provisioning Data：Provisioner 完成對Unprovisioned Device 的身份校驗後，使用建立的安全通信鍊路向Unprovisioned Device 發送Provisioning Data 封包，該封包包括Network Key、Key Index、IV Index、Unicast Address、Key Refresh Flag / IV Update Flag等MESH 安全密鑰資訊，Unprovisioned Device 成功接收并處理這些安全密鑰資訊後向Provisioner 回複Provisioning Complete 封包，整個啟動配網過程完成，先前的Unprovisioned Device 變成了MESH Node，其它MESH 節點通過配置設定的Unicast Address 尋址該裝置。
MESH 裝置經過啟動配網後，也會生成一個DevKey，該密鑰是隻有本裝置節點和Configuration Client 才知道的接入層密鑰。Configuration Client 如果需要對某個節點裝置進行配置，需要使用該節點裝置的DevKey 加密認證配置消息，目标節點裝置使用同樣的DevKey 成功解密并通過完整性校驗後才會處理該配置消息。
DevKey = k1(ECDHSecret, ProvisioningSalt, “prdk”)
三、MESH Beacon and Security state
我們使用某些對資訊安全比較敏感的應用時（比如郵箱、網銀等），通常需要定期更新密鑰，當我們決定目前密鑰不再安全時，也會主動去更改密碼。MESH 網絡對通信安全尤其看重，是以也會有密鑰參數更新過程。
MESH 網絡中裝置節點較多，沒法做到所有裝置統一更新密鑰，是以通常有一個新舊密鑰共存的過渡階段，比如為了應對垃圾桶攻擊，從MESH 網絡移除節點時需要執行的密鑰重新整理程式，或者為了應對重播攻擊，在SEQ 将要遞增到最大值時執行的 IV Index 更新過程等。
在MESH 網絡安全參數更新過程中，Secure Network Beacon 封包可以通知裝置節點目前使用新密鑰參數還是舊密鑰參數，在MESH 節點間同步協調新舊安全參數的切換過程。Secure Network Beacon 封包格式如下：
| Field | Size (octets) | Description |
|---|---|---|
| Beacon Type | 1 | Secure Network beacon (0x01) |
| Flags | 1 | Bit-0 (Key Refresh Flag)：0->未處于更新階段；1->處于更新階段 Bit-1 (IV Update Flag)：0->正常狀态；1-> IV更新狀态 Bit 2~7：Reserved for Future Use |
| Network ID | 8 | 目前的Network ID 值 |
| IV Index | 4 | 目前的 IV Index 值 |
| Authentication Value | 8 | 目前 security network beacon 的認證或鑒權值，采用AES-CMAC 算法生成 |
Authentication Value = AES-CMACBeaconKey(Flags || Network ID || IV Index) [0–7]
BeaconKey = k1 (NetKey, salt, P)
由于Secure Network Beacon 封包并沒有經過加密，為了防止攻擊者僞造該封包影響安全參數更新過程，裝置節點接收到該封包後需要校驗Authentication Value，該值是通過BeaconKey 認證加密的，BeaconKey 是通過入網時被分發的NetKey 計算出來的，也即隻有知道NetKey 的裝置節點發出的Secure Network Beacon 封包才會被持有相同NetKey 的裝置節點校驗通過并接受。
從Secure Network Beacon 封包格式可以看出，其主要服務于Key Refresh procedure 和IV Update procedure，當MESH 網絡節點或使用者感覺網絡不安全時，廣播到MESH 網絡中通知Network ID 辨別網絡中裝置節點何時啟用新的安全密鑰或 IV Index 通信，協調MESH 網絡中所有節點順利從舊安全參數切換到新安全參數。
由于Secure Network Beacon 封包是向全網廣播的，為了減少對網絡資源的占用，需要對Secure Network Beacon 封包的數量或者發送間隔進行限制，通常兩個Beacon 封包之間的間隔時間Beacon Interval 應設定在10 秒到600 秒之間，計算公式如下：
Beacon Interval = Observation Period * (Observed Number of Beacons + 1) / Expected Number of Beacons
比如假設Observation Period 為 50 秒，在此期間實際掃描到Beacon 封包的數量Observed Number of Beacons 為2 個，每個節點在子網中期望平均每 10 秒接收到一個Beacon 封包，在掃描周期内期望掃描到的Beacon 封包數量為 5 個（= 50 / 10），按照上述公式實際計算出的信标間隔Beacon Interval 為 30 秒（= 50 * 3 / 5）。
3.1 Key Refresh procedures
當一個或多個NetKey 或AppKey 可能不再安全時，由Configuration Client（比如智能手機或平闆電腦等）啟動密鑰重新整理過程，比如從MESH 網絡中移除某個節點裝置時，為應對垃圾桶攻擊，通常需要先将其加入黑名單、再執行密鑰重新整理過程。
密鑰重新整理過程管理NetKey、AppKey 和所有派生安全憑證從一個密鑰更改為另一個密鑰的過程，在新舊密鑰切換過程中要求對MESH 網絡運作的影響盡可能小。密鑰重新整理過程大緻可分為如下三個階段（以更新NetKey 為例）：
- Phase 1 – 分發新密鑰：Configuration Client 通過Foundation Configuration Client model 中的Config NetKey Update 消息（該消息使用Device Key 加密）向該子網内未列入黑名單的所有節點分發新的密鑰New Key，節點裝置收到分發的New Key 後會向Configuration Client 回複Config NetKey Status 消息。此階段使用Old Key 加密發送封包，使用Old Key 或New Key 接收解密封包；
- Phase 2 – 啟用新密鑰：待Configuration Client 收到所有未列入黑名單的節點裝置回複的Config NetKey Status 消息後，開始發送Key Refresh Flag 設定為 1 的Secure Network Beacon 封包（使用New NetKey 生成的BeaconKey 認證保護），或者發送Transition 參數設定為0x02 的Config Key Refresh Phase Set 消息到未列入黑名單的節點，節點收到上述消息後進入密鑰重新整理過程的第二階段，并向Configuration Client 回複Config Beacon Status 或Config Key Refresh Phase Status 消息。此階段使用New Key 加密發送封包，使用Old Key 或New Key 接收解密封包，但僅接收使用New Key 認證保護的Secure Network Beacon 封包；
- Phase 3 – 廢棄舊密鑰：待Configuration Client 确定所有未列入黑名單的節點都處于第二階段後，開始發送Key Refresh Flag 設定為 0 的Secure Network Beacon 封包（使用New NetKey 認證保護），或者發送Transition 參數設定為0x03 的Config Key Refresh Phase Set 消息到未列入黑名單的節點，節點收到上述消息後廢棄Old Key（處于第一階段的節點收到上述消息後将跳過第二階段，直接進入第三階段），後續都使用New Key 來加密發送或者接收解密封包。
密鑰重新整理過程是由Configuration Client 發起的，MESH 網絡中的節點裝置Foundation models 都需要提供 Configuration Server model 和Health Server model，密鑰重新整理過程是Configuration Client 通過向MESH 網絡或子網内未列入黑名單的所有裝置的Configuration Server model 發送相應的配置消息實作的。
在啟用新密鑰和廢棄舊密鑰階段，需要通過Secure Network Beacon 封包通知該網絡内的節點何時進入密鑰重新整理過程的哪個階段，起到協調各節點順暢同步切換密鑰的作用。
與密鑰重新整理過程相關的，還有一個Node Removal procedure，該過程是通過将某節點從密鑰重新整理過程中排除，實作将該節點從MESH 網絡中移除的目的。在一個節點從MESH 網絡中移除後，它的單點傳播位址 unicast addresses 可以被Provisioner 重新使用。
3.2 IV Update procedure
IV Index 是MESH 網絡所有節點共享的一個32 位值，它為網絡層或應用層中用于AES-CCM 認證加密的随機數提供種子，同時配合MESH 封包序列号SEQ 唯一辨別一個MESH 網絡層中傳輸的封包，為了避免出現重複的SEQ 而被重播攻擊者有機可乘，IV Index 需要時常更新，IV Index 更新後SEQ 值重置為0x000000。
IV Update procedure 可以由MESH 主網（也即NetKey Index = 0x000）中的任何節點發起，當節點判斷它自己或者另一節點在 96 小時後即将用盡其SEQ 時，可以發起 IV Index 更新過程，是以發送消息越多的節點發起 IV Update procedure 的機率越大些。
IV Update procedure 是為了應對重播攻擊保證SEQ 不會重複而設計的機制，通常在更新 IV Index 時在其目前值基礎上遞增 1，理論上隻要更新值比目前值大就可以，但 IV Index 更新過程也不是随時都能進行的。由于SEQ 用 24 位二進制表示，兩個廣播封包之間的最小間隔 advInterval 為20 ms（還需要再加個0 ~ 10 ms 的随機延時），可以計算出理論上SEQ 從0x000000 到0xFFFFFF 至少需要 96 小時（取随機延時約 1 ms）。
IV Update procedure 就取 96 h 作為 IV Index 更新周期的限制時間了，由于MESH 網絡中節點數量可能非常多（理論單點傳播位址最大數量為215 - 1 = 32767 個），為了盡可能照顧到每個節點的 IV Index 更新，MESH 所有節點 IV Update procedure 總持續時間至少為 96 小時，這就要求MESH 主網節點判斷SEQ 在即将用盡前的 96 小時就要發起 IV Update procedure。
由于 IV Update procedure 在SEQ 即将用盡的前96 小時就開始了，更新 IV Index 後重置SEQ，至少又可以使用 96 小時，是以MESH 網絡中的某個節點在 192 小時内至多執行一次 IV Update procedure。
Low Power Node 的 IV Update procedure 由Friend Node 代勞，一個 IV Index 至少可以使用96 小時，是以Low Power Node 為了不錯過 IV Update procedure，向Friend 輪詢的逾時時間PollTimeout 不能超過96 小時。
IV Update procedure 與前面的密鑰重新整理過程類似（IV 更新是針對MESH 全網的，密鑰重新整理可能隻針對某個子網），都包含更新New IV Index、通過Secure Network Beacon 封包通知其它節點進入 IV 更新狀态、節點完成 IV 更新後傳回正常狀态三個階段，這三個階段 IV Index 的使用情況如下：
- Phase 1 – Normal：MESH 主網中的某個節點判斷自己或者另一節點在96小時後即将用盡SEQ，則其更新自己的 IV Index 為m（通常為目前值n 遞增 1），并向其它節點發送 IV Update Flag 為 1 的Secure Network Beacon 封包通知其開始 IV Index 更新過程。其它處于正常狀态的節點在接收并驗證該封包後，比對自己目前的 IV Index（簡稱為 c）和封包中的 IV Index（簡稱為 b），如果b < c 或b > c + 42（節點離網超過48 周後需要重新啟動配網，假如每192 小時 IV Index 遞增 1，則48 周遞增 42）則忽略該Beacon 封包，如果 c + 1 < b <= c + 42 則該節點可以啟動 IV Index Recovery procedure，如果 b = c + 1 則該節點進入 IV 更新狀态。此階段節點還處于正常狀态，使用目前 IV Index（目前值 n）發送封包，使用 n 或 n - 1 處理接收到的封包（n - 1 該節點的Old IV Index）；
- Phase 2 – In Progress：MESH 網絡中某個節點接收到 IV Update Flag 為 1 的Secure Network Beacon 封包，且該封包中的 IV Index 值（簡稱為m）等于該節點目前 IV Index（簡稱為n）+ 1，則該節點進入 IV Update in Progress State，自己目前的 IV Index 更新為 m，并将該節點使用的SEQ 重置為0x000000。此階段節點繼續使用更新前的 IV Index（也即m - 1 或 n）發送封包，使用更新前後的 IV Index（也即m - 1 或 m）處理接收到的封包，相當于廢除了前一個 IV Index 更新過程中的Old IV Index（也即 n - 1）；
- Phase 3 – Normal：MESH 網絡中處于 IV Update procedure State 超過96 小時的節點向其它節點發送 IV Update Flag 為 0 的Secure Network Beacon 封包，其它節點接收并驗證該封包後（通常已完成 IV Index 更新和SEQ 重置過程），切換回Normal Operation state（處于 IV Update procedure State 達到144 小時後也會切換回正常狀态），并且使用更新後的 IV Index（也即 m）發送封包，依然使用 m - 1 或 m 處理接收到的封包。
IV Index Recovery procedure 是為某個節點可能長時間遠離網絡而錯過 IV Update procedure 導緻不能再與其它節點通信而設計的，為了恢複與其它節點的通信需要先獲得其它節點使用的 IV Index，這個過程就是 IV Index 恢複過程。為了恢複 IV Index，節點需要偵聽Secure Network Beacon（其中包含 Network ID 和 IV Index），該節點接收并驗證Beacon 封包後，根據該封包中的 IV Index 更新自己的 IV Index，并将 IV Update Procedure State 設定為In Progress。IV Index Recovery procedure 同樣在192 小時内至多執行一次。
IV Update procedure 和 IV Index Recovery procedure 都需要 Secure Network Beacon 來通知 IV Index 值和 IV Update Procedure State，協調MESH 網絡所有節點在保證SEQ 不重複的情況下順利從Old IV Index 更新到New IV Index。即便某個節點暫時離開MESH 網絡（比如距離太遠或者斷電等原因），錯過了 IV Update procedure 而無法與其它節點進行通信，隻要離網時間不超過48 周（離網超過48 周需要重新啟動配網），都可以通過 IV Index Recovery procedure 更新到MESH 網絡目前使用的 IV Index，進而恢複與其它節點的正常通信。
四、SIG MESH Network Layer
前面已經介紹了MESH Advertising Bearer 和GATT Bearer Layer 支援的封包類型，也介紹了與MESH Provisioning 相關的Unprovisioned Device beacon、«PB-ADV»、«PB-GATT» 封包，以及與MESH 密鑰重新整理和 IV Index 更新過程相關的Secure Network beacon 封包，剩下的就是«Mesh Message» 或Proxy PDU 承載的Network PDU 封包了，網絡層是MESH 消息安全尋址的關鍵。
MESH Advertising Bearer 承載的 Network PDU 最大為 29 位元組，GATT Bearer Layer 通過Mesh Proxy Service 傳輸的Network PDU 格式定義跟MESH Advertising Bearer 一緻，Network PDU 的格式定義如下：
| Field Name | Bits | Description |
|---|---|---|
| IVI | 1 | IV Index 的最低有效位，可以在 IV Update procedure 中辨別該封包使用的是Old IV 還是New IV |
| NID | 7 | 用來辨別一個網絡或子網的網絡辨別符，NID、EncryptionKey、PrivacyKey 都是由NetKey 一同生成的，NID 字段有助于更快的找到該封包加解密使用的EncryptionKey 和模糊化使用的PrivacyKey |
| CTL | 1 | CTL = 0：該封包承載的消息類型是Access Message，且NetMIC Size 為32 位； CTL = 1：該封包承載的消息類型是Control Message，且NetMIC Size 為64 位 |
| TTL | 7 | 訓示該封包剩餘的生存跳數Time To Live，若 TTL < 2 則該封包不會被中繼轉發，若 2 <= TTL <= 127 則該封包可能會被中繼轉發，該字段由上層協定設定 |
| SEQ | 24 | 封包序列号，配合 IV Index、SRC 唯一辨別MESH 網絡中的一個封包 |
| SRC | 16 | 用于辨別發送該封包的元素位址，該位址是元素的單點傳播位址 |
| DST | 16 | 用來辨別接收該封包的一個或一組元素位址，該位址可以是單點傳播位址、多點傳播位址或虛拟位址 |
| TransportPDU | 8 to 128 | 網絡層封包的資料載荷，承載傳輸層封包。若CTL 值為 0 則該字段最長為128 位，若CTL 值為 1 則該字段最長為96 位 |
| NetMIC | 32 or 64 | Message Integrity Check for Network（也即消息認證碼MAC），用于對DST 和TransportPDU 字段資訊進行完整性校驗。若CTL 值為 0 則該字段長度為32 位，若CTL 值為 1 則該字段長度為64 位 |
Network PDU 中TransportPDU 字段（也即Lower Transport Layer 封包）承載的消息分兩種：Access Message 的最大長度為 16 位元組，Control Message 的最大長度是 12 位元組。
4.1 Publish/Subscribe Addresses
Network PDU 中的SRC 和DST 字段分别辨別該資料包的發送位址和接收位址（類似于 IP 協定中的源位址和目标位址），這裡的位址隻有 16 位，又不像 IP 位址那樣是分層設計的，該如何尋址呢？
在介紹MESH 網絡如何尋址之前，先看看MESH 網絡都支援哪些位址類型：
| Address Type | Address Value | Description |
|---|---|---|
| Unassigned Address | 0x0000 | 節點元素尚未配置設定的位址，未配置設定位址不能用于消息的源位址或目的位址字段（若将該位址設為某模型的釋出位址，則相當于禁用該模型的消息釋出功能）。 |
| Unicast Address | 0x0001 ~ 0x7FFF | 在啟動配網過程中配置設定給每個元素的唯一位址，消息的源位址都是單點傳播位址，目的位址可以是單點傳播、多點傳播、虛拟位址，發送到單點傳播位址的消息最多由一個元素處理。 |
| Virtual Address | 0x8000 ~ 0xBFFF | 代表在邏輯上與特定Label UUID 相關聯的一組元素位址，Label UUID 實際上是使用者在邏輯上定義的一個128 位的标簽類别，虛拟位址的低14 位是從Label UUID派生的散列值。若Configuration Client 配置設定的訂閱或釋出位址為虛拟位址，則需要在配置過程中将Label UUID 發送到訂閱或釋出節點；若消息的目的位址是虛拟位址，則需要使用Label UUID 作為認證加密的附加資料。Control Message 不能使用虛拟位址。 |
| Group Address | 0xC000 ~ 0xFFFF | 主要用于消息的目的位址，發送到組位址的消息應傳遞給訂閱該組位址的所有元素。多點傳播位址分為兩種： 1. 固定組位址（0xFF00 ~ 0xFFFF）：All-proxies -> 0xFFFC，All-friends -> 0xFFFD，All-relays -> 0xFFFE，All-nodes -> 0xFFFF，其餘的供将來使用； 2. 動态配置設定組位址（0xC000 ~ 0xFEFF）：使用者通過Configuration Client 配置設定，作為訂閱或釋出位址供MESH 元素使用。 |
MESH 裝置啟動配網後，該裝置的每個元素都會被Provisioner 配置設定一個單點傳播位址，該元素向其它節點發送消息時，源位址就是自己的元素位址。如果MESH 消息的目的位址是單點傳播位址，這個單點傳播位址代表該MESH 網絡中的某個特定元素，該消息封包隻會被該目标元素處理。
虛拟位址或多點傳播位址代表一組元素，通常由使用者在配置MESH 網絡節點訂閱-釋出關系時配置設定的。使用者通過Configuration Client 配置設定多點傳播位址或虛拟位址，在配置MESH 元素訂閱位址和釋出位址時選擇，Configuration Client 配置設定的多點傳播位址或虛拟位址也會發送到訂閱或釋出該位址的節點（若是虛拟位址還需要發送對應的Label UUID，若多點傳播位址夠用一般就不用虛拟位址了），也即某個多點傳播位址或虛拟位址的訂閱節點和釋出節點都儲存有該多點傳播或虛拟位址。
某個元素想向MESH 網絡中的多個元素釋出消息，就可以将該消息的目的位址設定為這多個元素的多點傳播位址。MESH 網絡是通過受控泛洪廣播方式尋址目的節點的，這條消息會被廣播到MESH 全網或某個子網的幾乎所有節點（低功耗節點和GATT 節點有相應的朋友節點或代理節點幫忙接收轉發），當節點收到該消息後，會取出該消息中的目的位址并與自己的訂閱位址清單相比較，若該消息的目的位址屬于自己的訂閱位址則接收并處理，否則丢棄忽略或中繼轉發該消息，這就實作了消息的尋址功能。
4.2 Encrypted/Obfuscated Network PDU
MESH 網絡中節點之間的通信安全主要是由網絡層實作的，比如前篇博文BLE MESH 如何保證通信安全 介紹的子網隔離、加密認證、重播攻擊防護、模糊化處理等都靠MESH 網絡層實作，MESH 網絡從是如何保證消息封包的安全發送接收的呢？
首先看下MESH 網絡層封包的認證加密和模糊化處理過程，前面Network PDU 格式已經展示了哪些字段Encrypted、哪些字段Obfuscated？認證加密使用的是EncryptionKey，模糊混淆使用的是PrivacyKey，這兩個密鑰是如何獲得的呢？
Network PDU 中的網絡辨別符NID，加密認證DST 和TransportPDU 字段的加密密鑰EncryptionKey，模糊混淆CTL、TTL、SEQ、SRC 等字段的隐私密鑰PrivacyKey 都是使用k2 函數由NetKey 計算出來的，NetKey 又是Provisioner（啟動配網過程）或Configuration Client（密鑰重新整理過程）分發的。
Network PDU 中的DST 和TransportPDU 字段使用AES-CCM 認證加密算法獲得Encrypted Data 和Network MIC，使用的密鑰是EncryptionKey 和Network Nonce，其中EncryptionKey 是由NetKey 生成的，Network Nonce 則是由 IV Index、CTL、TTL、SEQ、SRC 等字段構成的。
Network PDU 中的CTL、TTL、SEQ、SRC 等字段通過與PrivacyKey 和Privacy Plaintext 進行AES-128 加密後的密文異或運算後獲得ObfuscatedData，Privacy Plaintext 則是由padding、IV Index、Encrypted Data、Network MIC 等字段構成的。
通過對Network PDU 進行認證加密和模糊混淆處理，攻擊者假如沒有網絡密鑰NetKey，将隻能看到 IVI 和 NID 兩個字段的資訊，其它資訊都無法檢視到，自然起到防止嗅探或篡改的目的。配合SEQ 遞增、IV Index 更新、緩存SEQ 和SRC 等設計，也可以起到防止重播攻擊的目的。
4.3 Receiving/Transmitting Network PDU
MESH 網絡層支援通過Advertising Bearer 或GATT Bearer 發送和接收消息，面向廣播的Advertising Bearer 是一個網絡接口，面向連接配接的GATT Bearer 每個GATT 連接配接都是一個網絡接口。比如本文開頭的MESH 消息流向圖，此節點就具有三個網絡接口，一個通過Advertising Bearer 發送接收消息，兩個通過GATT Bearer 分别和兩個連接配接的GATT Client 發送接收消息。此外，MESH 協定為了允許在同一節點的不同元素間傳遞消息，還定義了本地接口 Local Network Interface。
Network interfaces 提供了 input filter 和output filter，過濾器可以使用 bearer-specific PDUs 進行配置（可以類比Proxy Configuration 配置White list filter 和Black list filter）。接收的MESH 消息通過網絡接口從承載層傳遞到網絡層，接口使用其 input filter 定義的過濾規則先對消息進行過濾處理，決定是将該消息傳遞到網絡層進一步處理還是直接丢棄。發送的MESH 消息則是通過網絡接口從網絡層傳遞到承載層，接口使用其 output filter 定義的過濾規則對消息進行過濾處理，決定是将該消息傳遞到承載層還是直接丢棄。
MESH 網絡層接收到通過網絡接口傳遞來的MESH 消息後，處理流程如下：
- Check NID：節點從網絡接口接收到來自承載層的Network PDU 後，首先檢查該封包的NID 字段值是否能比對上本節點存儲的NID 清單（每個NID 辨別一個MESH 網絡或子網和相應的 NetKey，本節點存儲的NID 清單記錄該節點都處于哪些MESH 網絡中）。若該節點并沒有存儲接收封包中的NID，則說明該節點不在接收封包NID 辨別的網絡中（也即沒有解密該封包的NetKey），直接丢棄該封包，這實際上就是MESH 消息傳遞中子網間的區域隔離機制。若該節點已經存儲接收封包中的NID，則繼續進行下一步處理；
- Verify NetMIC：該節點根據Network PDU 中的NID 字段，查找相應的EncryptionKey 和PrivacyKey，然後使用這兩個密鑰和目前使用的 IV Index 解密反模糊接收封包，并通過比對NetMIC 字段值驗證接收封包的完整性。若NetMIC 驗證失敗則直接丢棄該封包（可能是接收封包被破壞，或者本節點使用的NetKey 不正确），若接收封包通過完整性校驗則繼續下一步處理；
- Check SRC and DST：檢查Network PDU 中的SRC 字段是否是有效的單點傳播位址，DST 字段是否是有效的單點傳播、多點傳播、虛拟位址，若SRC 或DST 是無效位址則直接丢棄該封包。若SRC 和DST 都是有效的，則檢查DST 是否在本節點的訂閱位址清單中（包括Friend Subscription List 和Proxy white / black list），若DST 是本節點的訂閱位址則後續将其遞交給傳輸層繼續處理（或者Proxy 節點将其轉發給對應的GATT 節點），若DST 不是本節點的訂閱位址則不向上傳遞了（看是否需要将其中繼轉發給其它節點）；
- Check SEQ and SRC Cache：檢查Network PDU 中的SEQ 和SRC 字段，這兩個字段配合目前使用的 IV Index 可以唯一辨別該MESH 網絡中的一個封包，節點會将接收封包的SEQ 和SRC 字段緩存起來，以避免重複處理相同的封包。若接收封包中的SEQ 和SRC 字段組合值已在該節點的接收消息緩存中，則直接丢棄該封包。若SEQ 和SRC 組合值不在該節點接收消息緩存中，則将這兩個字段值添加到該節點的消息緩存中，繼續下一步處理；
- Check TTL and Relay / Proxy feature：如果本節點啟用了Relay 特性且DST 不是本節點上元素的單點傳播位址，若TTL < 2 則将其丢棄，若TTL >= 2 則TTL 值減 1 後将其重新加密認證并通過承載層中繼轉發出去。如果本節點啟用了Proxy 特性且DST 在Proxy white list 中則将其重新加密認證并通過Mesh Proxy Service 發送給Proxy / GATT Client 節點。如果DST 是本節點上元素的訂閱位址，或者與本節點建立友誼關系的低功耗節點上元素的訂閱位址，則将接收封包向上傳遞到Lower Transport Layer 繼續處理。
如果該節點上的元素想要向其它節點發送MESH 消息，來自Lower Transport Layer 的封包作為MESH 網絡層的TransportPDU 字段，CTL、TTL、DST 字段都是由上層協定設定的，使用該元素所在MESH 網絡的 NID 、LSB of IV Index 填充NID 和 IVI 字段，使用發送該消息的元素的單點傳播位址填充SRC 字段，将發送前一個封包的SEQ 值加 1 填充SEQ 字段。使用 NID 辨別的EncryptionKey、PrivacyKey 和目前的 IV Index 對Network PDU 特定字段進行加密認證和模糊化處理，最後将生成的Network PDU 經網絡接口傳遞給承載層發送出去。
五、SIG MESH Transport Control messages
在介紹MESH Network Layer 時我們知道，TransportPDU 分為Access Message 和Control Message，前者是來自Access Layer 的消息，後者則是來自Transport Layer 的消息。
Access Message 承載的主要是Foundation Model 的配置或健康消息、以及SIG / Vendor Model 的應用消息封包。為了保證釋出者模型釋出的消息封包，隻能被相應的訂閱者模型處理或響應，除了使用NetKey 對網絡資料封包進行認證加密外，還需要使用AppKey 對模型或應用消息封包進行認證加密，且釋出者模型與訂閱者模型都綁定到相同的AppKey。限于篇幅，Access Message 在談Model 時再介紹。
Control Message 承載的主要是跟Friend node 如何幫助Low Power node 管理訂閱清單 / 緩存并轉發消息相關的友誼消息封包，以及監測MESH 網絡中其它節點活動狀态和拓撲距離相關的心跳消息封包。Friendship 相關的消息主要在FN 與LPN 之間傳輸，Heartbeat 相關的消息則在MESH 網絡或子網中傳輸，這兩種Control Message 發送對象都比較确定，不屬于應用業務的範疇，沒必要再使用類似AppKey 之類的密鑰進行二次認證加密，是以Control Message 在傳輸層不需要進行認證加密（隻在網絡層進行認證加密）。
5.1 Unsegmented Control Message
Control Message 主要由Opcode 和Parameters 兩部分構成（可以類比Attribute PDU，MESH Access Layer 的Access Message 也主要由Opcode 和Parameters 這兩部分構成），考慮到MESH 網絡層封包承載的Transport PDU 隻有 12 位元組，為了支援更大的消息封包長度，傳輸層需要支援消息封包的分片重組功能（TCP/IP 協定和BLE L2CAP 協定都支援封包的分片重組功能），為此新增了一個訓示該封包是否分片的辨別位SEG，Unsegmented Control Message 的格式如下：
| Field | Size (bits) | Description |
|---|---|---|
| SEG | 1 | 0 = Unsegmented Message |
| Opcode | 7 | 0x00 = Segment Acknowledgment 0x01 to 0x7F = Opcode of the Transport Control message |
| Parameters | 0 to 88 | Parameters for the Transport Control message |
Control Message 的Opcode 字段隻有 7 位，0x00 是分片封包的确認應答封包（消息發送者可通過該封包得知哪個分片未送達需重新發送，保證分片封包傳輸的完整性），剩餘的 127 個操作碼可用來辨別每個Control Message。目前SIG MESH 定義的Control Message 如下：
5.1.1 Heartbeat message
Transport Control messages 最後一種Opcode 為0x0A 的控制消息是Heartbeat message，主要用來監測MESH 網絡上其它節點的活動狀态及其拓撲距離。
MESH 網絡節點間通信采用訂閱 – 釋出消息傳遞模型，該消息傳遞模型通常需要各節點周期性發送心跳封包，以通知其可能的訂閱者自己是否還在網并處于活動狀态，這是MESH Heartbeat message 的第一個作用。
MESH Heartbeat message 的第二個作用就是幫助接收該消息的節點計算到該消息釋出者的拓撲距離也即跳數，該消息封包會包含 InitTTL 字段，接收者在Network PDU 中會獲知接收到該封包時的 RxTTL 值，就可以計算得到該消息發送者與接收者之間的拓撲距離如下：
hops = InitTTL - RxTTL +1
MESH 節點通過Heartbeat message 知道了到其它節點的拓撲距離hops，也就可以在釋出消息時設定合适的TTL 值，盡可能以較小的網絡資源占用将消息發送到其它所有訂閱者，這也是MESH 網絡受控泛洪廣播提高通信效率的一個設計。
MESH Heartbeat message 中除了包含 InitTTL 字段，還包含Features 字段，該字段主要是用來通知其它節點，自己是否支援Relay、Proxy、Friend、Low Power 等Feature，不僅讓MESH 節點知道到其它節點的拓撲距離hops，也讓MESH 節點知道其它節點支援的功能Feature。當MESH 節點的某個功能Feature（比如Relay、Proxy、Friend、Low Power 等）發生變化時，應該向其它節點釋出Heartbeat message，及時通知其它節點自己功能角色的變化。
5.1.2 Friendship messages
Transport Control messages 中間的 9 種都屬于Friendship 相關的消息，Friend node 與Low Power node 之間友誼的建立、訂閱清單維護、消息傳遞等過程都已經在博文BLE MESH 如何支援低功耗裝置 中介紹過了，每種封包的參數格式可以參閱Mesh Profile Section 3.6.5，這裡就不贅述了。
跟Friendship 相關的Transport Control messages 封包，由于僅在Friend 節點和Low Power 節點間傳輸，網絡層封包的TTL 字段設定為 0（也即不中繼轉發）。FN 與LPN 雙方建立Friendship 後，通信封包改為friendship security material 認證加密，這個安全密鑰是由NetKey 和FriendAddress、LPNAddress 等參數計算出來的（用于網絡層封包對TransportPDU 字段的認證加密），生成過程如下：
The master security material using:
NID || EncryptionKey || PrivacyKey = k2(NetKey, 0x00)
The friendship security material using:
NID || EncryptionKey || PrivacyKey = k2(NetKey, 0x01 || LPNAddress || FriendAddress || LPNCounter || FriendCounter)
在建立Friendship 之前FN 與LPN 之間發送的Friend Request、Friend Offer 控制消息封包，以及建立New Friendship 後New Friend 節點與Old Friend 節點之間發送的取消Old Friendship 關系的Friend Clear 和Friend Clear Confirm 控制消息封包都是采用master security material 認證加密的（實際上就是前面介紹Network Layer 時使用的EncryptionKey 和PrivacyKey）。建立Friendship 之後FN 與LPN 之間互動的封包，比如Friend Poll、Friend Update、Friend Subscription List Add / Remove / Confirm 等控制消息封包都是采用friendship security material 認證加密的，由于包含FN 與LPN 之間的私有資訊（比如LPNAddress、FriendAddress、LPNCounter、FriendCounter 等），這些封包隻能被建立Friendship 關系的另一方正确解密并處理。
前面也介紹了，當從MESH 網絡中移除節點時Configuration Client 會啟動Key Refresh procedures，當某個節點判斷自己或者另一節點在 96 小時後即将用盡其SEQ 時會啟動 IV Update procedure，這兩個過程用于MESH 網絡中未列在黑名單中的所有結點更新密鑰或 IV Index，Low Power 節點怎麼從Friend 節點獲得這些更新值呢？
Friend Update 控制消息封包Opcode 為0x02，參數包含Key Refresh / IV Update Flags、IV Index、MD 等字段，前兩個字段就可以将MESH 網絡或子網更新的 NetKey 或 IV Index 發送給Low Power 節點（由于Key Refresh 和 IV Update 過程都是有時限的，LPN 輪詢FN 的最長時間間隔PollTimeout 不能超過這個時限 96 小時），若NetKey 更新則friendship security material 也需要更新。Friend Update 封包中的MD 字段 則告訴Low Power 節點是否還有後續更多消息封包待傳輸，LPN 節點根據MD 字段的值決定是否繼續向FN 發送Friend Poll 封包以請求後續更多的消息（MD = 1 則還有後續更多消息待發送，MD = 0 則本次緩存的消息已發送完畢）。
5.1.3 Segment Acknowledgment message
由于單個Network 封包承載的Transport PDU 長度有限（Access Message 最大長度為 16 位元組，Control Message 最大長度是 12 位元組），對于長度超過單個Network 封包承載極限的消息，我們很自然想到分片重組。
分段傳輸有可能導緻某個封包未成功送達，如果此時重傳整個消息封包就降低了網絡使用率，是以接收者有必要通過Segment Acknowledgment message 告訴消息發送者，自己都接收到了哪些分段封包，消息發送者隻需要重傳對方未收到的分段封包就可以了，進而提高了網絡使用率。
Segment Acknowledgment message 不僅用于Segmented Control message 的确認應答，還用于Segmented Access message 的确認應答，該封包的格式如下：
| Field | Size (bits) | Description |
|---|---|---|
| SEG | 1 | 0 = Unsegmented Message |
| Opcode | 7 | 0x00 = Segment Acknowledgment |
| OBO | 1 | Friend on behalf of a Low Power node，OBO = 1 代表一個低功耗節點的朋友節點确認此消息，OBO = 0 直接尋址的消息接收者确認此消息 |
| SeqZero | 13 | Least significant 13 bits of SeqAuth（由32 位 IV Index 和24 位第一個分段的SEQ 構成的一個56 位消息認證碼，用來辨別該元素發出的每一個封包），相當于消息第一個分段的SEQ 的低 13 位，同一個消息不同分段的SeqZero 值相同，用來辨別某個特定的消息 |
| RFU | 2 | Reserved for Future Use |
| BlockAck | 32 | Block acknowledgment for segments，每一位置為 1 代表确認已接收到對應的一個分段消息，比如 LSB - 0 置為 1 辨別分段 0 消息被确認接收到、LSB - 31 置為 1 辨別分段 31 消息被确認已接收到，一條消息最多被分成32 個分段 |
發送給LPN 的消息封包是由與其建立Friendship 關系的FN 代為緩存轉發的（FN 為每個與其建立友誼關系的 LPN 都設定了一個 Friend Queue，用于緩存即将發送給LPN 的消息），當FN 接收到發送給LPN 的消息時（也即消息封包的目的位址是LPN 的單點傳播位址或者訂閱位址），如果封包的TTL 字段值大于等于2 則将其減 1 後存入Friend Queue（如果封包的TTL 值小于2 則将其丢棄）。
如果發送給LPN 的消息是分段消息，則由與其建立友誼關系的FN 代為回複Segment Acknowledgment message，該消息的OBO 字段應設定為 1。FN 接收到發送給LPN 的分段消息後，待所有分段封包重組為完整的消息後，才放入到Friend Queue 中（如果該好友隊列已滿，則會丢棄除Friend Update 消息外的最舊的消息）。
5.2 Segmented Control message
通常Access Messages 長度可能超過單個Network 封包承載極限，需要分段傳輸，Control messages 中的Friend Subscription List Add 和Friend Subscription List Remove 消息也可能超過單個Network 封包承載極限，是以也為Control message 定義了Segmented Control message，該封包的格式如下（）：
| Field | Size(bits) | Description |
|---|---|---|
| SEG | 1 | 1 = Segmented Message |
| Opcode | 7 | 0x00 = Reserved 0x01 to 0x7F = Opcode of the Transport Control message |
| RFU | 1 | Reserved for Future Use |
| SeqZero | 13 | Least significant 13 bits of SeqAuth，相當于消息第一個分段的SEQ 的低 13 位，同一個消息不同分段的SeqZero 值相同，用來辨別某個特定的消息 |
| SegO | 5 | Segment Offset number，表示目前封包的分段号（可以了解為目前封包是該消息的第幾個分段，需要從0 開始計） |
| SegN | 5 | Last Segment number，該消息的最後一個分段号，同一個消息不同分段的SegN 值相同，用來表示該消息被分成了多少段 |
| Segment m | 8 to 64 | Segment m of the Upper Transport Control PDU，承載控制消息的每個分段内容 |
從SegN 字段隻有 5 位可以得知，一條MESH 消息最多隻能分成 32 個片段，每個片段最多隻能承載 8 位元組有效載荷，Segmented Control message 最多可以承載256 位元組有效載荷。
分段封包相比未分段封包，多了SeqZero、SegO、SegN 三個字段，這三個字段資訊也是分段重組的關鍵。這三個字段控制封包分段的圖示如下（同一消息的不同分段使用相同的Opcode，下圖就不單獨給出Opcode 字段了）：
SeqZero 是SeqAuth 的低13 位，可以唯一辨別213 = 8192 個封包中的一條消息（若在該範圍内未完成分段重組，則該消息傳遞失敗），在分段封包重組時通過該字段判斷是否屬于同一條消息的不同分段。
SegO / SegN 可以唯一辨別某個消息（由 SeqZero 辨別）的每個分段，比如 0 / 5 表示目前封包是消息SeqZero 總共六個分段中的第一個分段。在分段封包重組時通過這兩個字段判斷同一條消息不同分段的組合順序。
前面介紹的Segment Acknowledgment message 中的BlockAck 字段每一位表示已經接收到分段封包的SegO 字段值，BlockAck 字段中超過SegN 字段值的位應該置 0（也即不需要确認不存在的分段）。比如已經接收到SegO / SegN 值為 0 / 5、1 / 5、3 / 5、5 / 5 則BlockAck 字段應設定為0x0000002B，發送者收到該封包後就知道對方未收到 2 / 5、4 / 5 分段封包，便會重新發送這兩個分段封包給對方。
值得一提的是，對于分段封包，在傳輸層有Segment Acknowledgment message 用于确認應答。但對于未分段封包，在傳輸層并沒有相應的确認應答機制，Unsegmented Access message 可以由應用層确認應答，Unsegmented Control Message 針對重要的控制消息提供了專門的确認應答消息，比如Friend Clear Confirm、Friend Subscription List Confirm。其它的Unsegmented Control Message 會多次發生（比如Heartbeat 是周期性多次發送的，LPN 發送Friend Poll 後若一段時間内未收到Friend Update 響應則會繼續重發Friend Poll ），即便有一兩個控制消息未送達也影響不大。若想使用傳輸層的确認應答機制，如果Control Message Parameters 字段不超過8 個位元組，可以使用單分段封包發送（也即SegN 值為 0 的分段封包）。
Transport Access messages、Foundation Model Layer 和Models Layer 的詳細介紹見下篇博文：BLE 技術（九）— SIG MESH Models 是如何設計的(下)?
更多文章：
- 《BLE 技術（九）— SIG MESH Models 是如何設計的(下)?》
- 《BLE 技術（七）— BLE MESH 是如何設計的？》
- 《Bluetooth 技術（一）— 協定棧設計與演進(Core_v5.2 + 6LoWPAN + Mesh)》
- 《Mesh Profile 1.0.1》
- 《Mesh Model 1.0.1》