Airoha BLE SIG Mesh AB1611 & 天貓精靈配網過程整理

目錄

1：BLE SIG Mesh初始化

2：配網前Mesh Beacon

3：配網數據傳輸控制

4：天貓精靈PB-ADV配網過程

4.1 provisioning invite與provisioning capabilities

4.2 provisioning start

4.3 provisioning public key exchange

4.4 authentication

4.5 Distribution of provisioning data

4.6 provisioning complete & provisioning fail

5：綁定AppKey過程

---

最近在瞭解Airoha AB1611 BLE SIG Mesh相關的代碼，隨便整理了下通過天貓對AB1611進行配網的過程

整理了下思維導圖筆記：

關於環境搭建，參考《基於Airoha AB1611的mesh智能燈方案》https://www.wpgholdings.com/news/detail/zhcn/program/project_code_5226 

---

1：BLE SIG Mesh初始化

關於BLE SIG Mesh的初始化過程詳見《AB16xx_Mesh_Developers_Guide.pdf》

需要本文關注的是兩個地方：

<1> BT_MISC_EVENT_INITED藍牙初始化完畢後，通過mesh_three_tuples_get_uuid獲取了阿里發佈的三元組數據，並將前16字節數據寫入deviceUuid。deviceUuid是每個與天貓精靈配網的設備的唯一標識，其內包括設備MAC地址。

<2>bt_mesh_init調用前對BLE SIG Mesh網絡的初始化相關設置。

---

2：配網前Mesh Beacon

未配網的設備會向外部廣播自身的信息，BLE SIG Mesh支持兩種配網方式：PB-GATT與PB-ADV：

<1>PB-GATT是通過BLE與設備直連進行配網的方式，設備爲了支持PB-GATT配網會向外廣播ADV_IND類型的Unprovisioned Beacon，可以參考我的另一篇博文：

《Telink BLE SIG Mesh GATT 配網功能》https://blog.csdn.net/abc517789065/article/details/95066020

<2>PB-ADV是通過廣播包對設備進行配網的方式，天貓精靈採用該種方式對設備配網。設備處於未配網狀態下會廣播ADV_NONCONN_IND類型的Mesh Beacon，Mesh Beacon內包含有設備的UUID信息；當用戶命令天貓精靈“發現設備”時，天貓精靈會進行一段時間的Mesh Beacon接收，搜尋周圍未配網的設備的UUID。

Airoha AB1611設備未配網時的Mesh Beacon抓包數據：

---

3：配網數據傳輸控制

<1>本節主要參見《Mesh_v1.0.pdf》 5.3 Generic Provisioning layer

<2>PDU：協議數據單元。對於SIG Mesh配網協議，PDU即是配網協議的基本數據單元，包含三種類型：start PDU、ack PDU、連續傳輸PDU。

詳見《Mesh_v1.0.pdf》5.3.1 Generic Provisioning PDU Types。

<3>配網承載層控制：BLE SIG Mesh配網過程是基於抽象的“link”(PB-GATT方式建立在BLE連接上；PB-ADV方式通過廣播包，並非真實的link)，其實就是會話的含義。配網時先由配網者(如天貓精靈/手機...)生成隨機的linkID，配網者與未配網的設備之間通過link_open & link_ack消息建立配網承載層連接，配網結束通過link_close消息關閉配網承載層連接：

詳見《Mesh_v1.0.pdf》5.3.1.4 Provisioning Bearer Control

<4>Airoha AB1611被天貓精靈配網時天貓精靈發送的link_open消息，關鍵是linkID：

 

---

4：天貓精靈PB-ADV配網過程

 

本節內容參考《Mesh_v1.0.pdf》5.4 Provisioning protocol與AB161X SDK代碼，思維導圖部分：

 

4.1 provisioning invite與provisioning capabilities

如本文第3章“配網數據傳輸控制”所述，當配網者發送link_open消息且被配網的設備回覆link_ack時，意味着配網的承載層連接建立。

此時，配網者需要向未配網的設備發出配網邀請provisioning invite，未配網的設備需要回復自身的provisioning capabilities給配網者。

AB1611接收到的天貓精靈provisioning invite與回覆的provisioning capabilities：

<1>provisoning invite

provisoning invite
參考文檔	《Mesh_v1.0.pdf》5.4.1.1
AB1611 SDK代碼	bt_mesh_evt_prov_invite_t
關鍵數據	Attention Duration	天貓精靈設置attention duration爲0(OFF)，但是從AB1611 log看，啓動一個provision的超時定時器60s

<2>provisoning capabilities

provisoning capabilities
參考文檔	《Mesh_v1.0.pdf》5.4.1.2
AB1611 SDK代碼	bt_mesh_evt_prov_capabilities_t
關鍵數據	Number of Elements	<1>當前設備元素數，AB1611返回2個 <2>BLE SIG Mesh每個設備必須有一個主元素，另外還可以有多個附加元素。每個主元素對應配網時唯一的unicast addr，附加元素在主元素的地址上子序列尋址 <3>AB1611 SDK代碼返回的2個元素： 主元素，包含Light CTL Server model及其它 附加元素，包含Light CTL Temperature Server model
	Algorithms	AB1611返回0，FIPS P-256 Elliptic Curve
	Public Key Type	AB1611返回0，密鑰OOB數據有效
	Static OOB Type	AB1611返回1，static OOB信息無效
	Output OOB Size	AB1611返回0，表示不支持輸出OOB
	Output OOB Action	AB1611返回0，Output OOB Action blink；但Output OOB Size爲0，該數據無效
	Input OOB Size	AB1611返回0，表示不支持輸入OOB
	Input OOB Action	AB1611返回0，Iutput OOB Action push; 但Input OOB Size爲0，該數據無效

經過這一步，作爲配網者的天貓精靈獲取到對AB1611設備配網的初步信息。

 

4.2 provisioning start

當作爲配網者的設備獲取到未配網設備的provisioning capabilities並決定對此設備進行配網，會向該設備發送provisioning start消息。

AB1611接收到的天貓精靈provisioning start消息數據：

provisoning start
參考文檔	《Mesh_v1.0.pdf》5.4.1.3
AB1611 SDK代碼	bt_mesh_prov_start_t
關鍵數據	Algorithm	AB1611接收0 採用FIPS P-256 Elliptic Curve算法
	Public Key	AB1611接收0 使用No OOB的public key
	Authentication Method	AB1611接收1 認證方式使用static OOB認證
	Authentication Action	AB1611接收0 注：當Authentication Method == 1 Authentication Action必須設爲0
	Authentication Size	AB1611接收0 注：當Authentication Method == 1 Authentication Size 必須設爲0

        AB1611設備端接收到provisioning start消息後，知道天貓精靈對其進行配網使用的public key不包含OOB，認證使用static OOB數據。這一步決定了接下來配網者天貓精靈與被配網的AB1611設備間的密鑰交換流程。

 

4.3 provisioning public key exchange

本節主要參考《Mesh_v1.0.pdf》5.4.2.3 exchange public keys

public keys用於FIPS P-256 Elliptic Curve算法加密使用，該算法可以參見《Mesh_v1.0.pdf》5.4.3  Provisioning security；

根據配網是否採用帶OOB的public key以及認證的方式，provisioning public exchange的過程是不同的(具體參見《Mesh_v1.0.pdf》5.4.2.3)；

如4.2所述，天貓精靈對AB1611設備配網採用的路徑是：

① No OOB的public key

② static OOB方式的auth method

與之對應密鑰交換時序是，天貓精靈先將自身的public key發給AB1611設備；AB1611設備再將自身的public key發給天貓精靈：

<1> 天貓精靈向AB1611發送己方public key

<2>AB1611向天貓精靈返回己方public key

配網者與被配網設備間的密鑰交換都是按照provisioning PDUs的格式多包傳輸的，可對照《Mesh_v1.0.pdf》5.3.1 Generic Provisioning PDU types。

至此，public key exchange過程完成，天貓精靈與AB1611設備各自拿到對方的public key，將開始認證過程。

 

4.4 authentication

與4.3密鑰交換流程一樣，認證過程根據public key以及認證是否帶OOB分爲幾種時序，具體參考《Mesh_v1.0.pdf》5.4.2.4 Authentication；

No OOB的public key 與 static OOB authentication對應的認證時序是：

簡單的說，所謂認證就是配網者與被配網者基於各自的隨機數發生器、OOB數據以及配網期間交互過的數據包根據約定的算法生成各自的provisioning confirm數據發給對方；然後將各自用於生成provisioning confirm數據的隨機數再發給對方；最後各自校驗對方provisioning confirm數據是否正確的過程。

具體的計算方法在《Mesh_v1.0.pdf》5.4.2.4 Authentication裏有詳細的敘述；AB1611的SDK也做的比較完善，從打印信息上可以完全看到各類變量的計算結果，兩者一一對應即可：

從AB1611 SDK 源碼的BT_MESH_EVT_PROV_REQUEST_OOB_AUTH_VALUE事件下，可以看出天貓精靈與AB1611配網所使用的static OOB其實就是從阿里發放的三元組獲取的：mesh_three_tuples_get_authentication_value。畢竟每個設備的三元組不同，也算是動態OOB了。

本節的具體數據計算待有必要再研究，至少從AB1611的打印信息看，足夠非官方SDK開發人員判斷配網的過程，這點確實MTK還是很專業的。

 

4.5 Distribution of provisioning data

本節參考《Mesh_v1.0.pdf》5.4.2.5 Distribution of provisioning data。

配網認證完畢，配網者就可向被配網設備下發配網數據；

配網數據的下發是加密的，包括兩個部分：provisioning data與 provisioning data MIC，最終在AB1611設備端被解密：

 

provisoning data
參考文檔	《Mesh_v1.0.pdf》5.4.2.5
AB1611 SDK代碼	bt_mesh_prov_data_t
關鍵數據	Network Key	網絡密鑰，具有相同網絡密鑰的設備才位於同一個網絡
	Key Index	網絡密鑰序號
	Flags	標誌位，指示是否網絡密鑰刷新的階段、是否IV index正在刷新
	IV Index	IV index是32位數據，位於相同網絡的設備共享相同的IV index，並在網絡運作過程中通過secure network beacon更新共享
	Unicast Address	設備主元素地址，網絡內通過該地址尋址設備

AB1611端的打印信息：

至此，AB1611設備端已接收到配網者的下發的全部網絡信息，基於這些信息，該設備與配網者同在一個BLE SIG Mesh網絡，可以互相訪問控制。

 

4.6 provisioning complete & provisioning fail

參考《Mesh_v1.0.pdf》5.4.1.9 & 5.4.1.10有provisioning完畢或者失敗的消息，失敗消息攜帶有錯誤碼，可以方便開發人員判斷配網失敗原因。不過一般情況下，應用開發工程師遇到的問題都不會在這些錯誤上。

 

---

5：綁定AppKey過程

TBD