目錄
1：BLE SIG Mesh初始化
2：未配網裝置的unprovisioned 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過程
6：天貓精靈對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：未配網裝置的unprovisioned dev beacon
未配網的裝置會向外部廣播自身的資訊，BLE SIG Mesh支援兩種配網方式：PB-GATT與PB-ADV：
<1>PB-GATT是通過BLE與裝置直連進行配網的方式，裝置為了支援PB-GATT配網會向外廣播ADV_IND類型的unprovisioned dev beacon，可以參考我的另一篇博文：
《Telink BLE SIG Mesh GATT 配網功能》https://blog.csdn.net/abc517789065/article/details/95066020
<2>PB-ADV是通過廣播包對裝置進行配網的方式，天貓精靈采用該種方式對裝置配網。裝置處于未配網狀态下會廣播ADV_NONCONN_IND類型的unprovisioned mesh beacon，beacon包含有裝置的UUID資訊；當使用者指令天貓精靈“發現裝置”時，天貓精靈會進行一段時間的mesh beacon接收，搜尋周圍未配網的裝置的UUID。
Airoha AB1611裝置未配網時的unprovisioned 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。天貓精靈應該需要聯網從伺服器端拿到某個UUID(如前所述，mesh beacon内附帶)對應的static 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過程
配網成功的裝置已成為BLE SIG Mesh網絡内的節點。
然而通常實際使用情況下，根據SIG Mesh規範，為了能夠使用節點的具體功能，配網成功後還需要為節點的models綁定AppKey：
“BLE SIG Mesh規範規定了兩種類型的密鑰：NetKey與AppKey。NetKey用于網絡層消息認證，AppKey用于傳輸層應用程式的資料加密。NetKey與AppKey在BLE SIG Mesh網絡的節點之間是存在共享的；是以還有另外一種DevKey，每個節點的DevKey可以不同，用于配置端與節點之間的加密。關于BLE SIG Mesh的密鑰與加密詳見《Mesh_v1.0.pdf》3.8 Mesh security”。
實際使用中，需要将AppKey依次綁定某個節點上需要互動的models。以AB1611 SDK ali_mesh_device這個工程的固件為例，節點上element與model的關系大緻是(初步看了下，不一定正确)：
從AB1611配網期間的log看，天貓精靈bind了綠色部分的models，也就是說天貓精靈bind成功這些models之後才可以控制AB1611燈的開關、亮度、色溫。
PS：按照個人的了解，天貓部分應該還使用了不少vendor model的自定義指令，但是AB1611 SDK上并沒有相關的部分。
6：天貓精靈對AB1611配網問題總結
本文的目的即是為了在實際産品開發過程中遇到配網失敗的問題時進行分析，相關問題随着項目進展再進行整理總結。