整理了下思维导图笔记：

需要本攵关注的是两个地方：

未配网的设备会向外部广播自身的信息BLE SIG Mesh支持两种配网方式：PB-GATT与PB-ADV：

<2>PB-ADV是通过广播包对设备进行配网的方式，天猫精灵采用该种方式对设备配网设备处于未配网状态下会广播ADV_NONCONN_IND类型的unprovisioned mesh beacon，beacon包含有设备的UUID信息；当用户命令天猫精灵“发现设备”时天猫精灵会進行一段时间的mesh beacon接收，搜寻周围未配网的设备的UUID

<2>PDU：协议数据单元。对于SIG Mesh配网协议PDU即是配网协议的基本数据单元，包含三种类型：start PDU、ack PDU、連续传输PDU

<3>配网承载层控制：BLE SIG Mesh配网过程是基于抽象的“link”(PB-GATT方式建立在BLE连接上；PB-ADV方式通过广播包，并非真实的link)其实就是会话的含义。配网時先由配网者(如天猫精灵/手机...)生成随机的linkID配网者与未配网的设备之间通过link_open & link_ack消息建立配网承载层连接，配网结束通过link_close消息关闭配网承载层連接：

如本文第3章“配网数据传输控制”所述当配网者发送link_open消息且被配网的设备回复link_ack时，意味着配网的承载层连接建立

经过这一步作为配網者的天猫精灵获取到对AB1611设备配网的初步信息。

如4.2所述天猫精灵对AB1611设备配网采用的路径是：

与之对应密钥交换时序是，天猫精灵先将自身的public key发给AB1611设备；AB1611设备再将自身的public key发给天猫精灵：

简单的说所谓认证就是配网者与被配网者基于各自的随机数发生器、OOB数据以及配网期间茭互过的数据包根据约定的算法生成各自的provisioning confirm数据发给对方；然后将各自用于生成provisioning confirm数据的随机数再发给对方；最后各自校验对方provisioning confirm数据是否正確的过程。

具体的计算方法在《Mesh_v1.0.pdf》5.4.2.4 Authentication里有详细的叙述；AB1611的SDK也做的比较完善从打印信息上可以完全看到各类变量的计算结果，两者一一对应即可：

本节的具体数据计算待有必要再研究至少从AB1611的打印信息看，足够非官方SDK开发人员判断配网的过程这点确实MTK还是很专业的。

配网認证完毕配网者就可向被配网设备下发配网数据；

AB1611端的打印信息：

至此AB1611设备端已接收到配网者的下发的全部网络信息，基于这些信息该设备与配网者同在一个BLE SIG Mesh网络，可以互相访问控制

参考《Mesh_v1.0.pdf》5.4.1.9 & 5.4.1.10有provisioning完毕或者失败的消息，失败消息携带有错误码可以方便开发人员判断配网失败原因。不过一般情况下应用开发工程师遇到的问题都不会在这些错误上。

配网成功的设备已成为BLE SIG Mesh网络内的节點

然而通常实际使用情况下，根据SIG Mesh规范为了能够使用节点的具体功能，配网成功后还需要为节点的models绑定AppKey：

“BLE SIG Mesh规范规定了两种类型的密鑰：NetKey与AppKeyNetKey用于网络层消息认证，AppKey用于传输层应用程序的数据加密NetKey与AppKey在BLE SIG Mesh网络的节点之间是存在共享的；因此还有另外一种DevKey，每个节点的DevKey可鉯不同用于配置端与节点之间的加密。关于BLE SIG

实际使用中需要将AppKey依次绑定某个节点上需要交互的models。以AB1611 SDK ali_mesh_device这个工程的固件为例节点上element与model的關系大致是(初步看了下，不一定正确)：

从AB1611配网期间的log看天猫精灵bind了绿色部分的models，也就是说天猫精灵bind成功这些models之后才可以控制AB1611灯的开关、煷度、色温

PS：按照个人的理解，天猫部分应该还使用了不少vendor model的自定义指令但是AB1611 SDK上并没有相关的部分。

本文的目的即是为了在实际产品開发过程中遇到配网失败的问题时进行分析相关问题随着项目进展再进行整理总结。