文章目录
一、Access Layer
op code 有三种类型，1byte，2byte 和 3byte。1byte，2byte 是 SIG 定义的命令。3byte
是 vendor 自定义的命令，其中 2 个 byte 是 vendor ID（CID）,整个 mesh 网络中，一个 vendor
id 最多支持 64 个 vendor opcode。
Access layer 包含 op code 和 parameter，最大支持 380 byte。
二、Transport layer
目前为了兼容 BLE4.2 等不支持长广播包的设备，所以都统一设定 adv 的最大 payload 为
31byte。去掉一些数据包的通讯协议需要占用的部分，单包的有效 payload 是 11byte，所以当
Access layer 超过 11byte 后，就需要分包，所以对于 vendor op code 来说，当 parameters 大
于 8 个 byte(8=11-3)，mesh 协议栈就会自动执行分包发送。用户不需要介入。
三、Network layer
3.1 Address
| Values | Address Type | Description |
|---|---|---|
| 0b0000 0000 0000 0000 | Unassigned Address | 0，未分配地址 |
| 0b0xxx xxxx xxxx xxxx | Unicast Address | element address |
| 0b11xx xxxx xxxx xxxx | Group Address | 分组地址，用于组控，以及publish/subcribe |
| 0b10xx xxxx xxxx xxxx | Virtual Address | 暂时用不到 |
3.2 Network PDU
- IVI: iv index(即 SDK 的 iv_idx_st.tx[3]这个 byte 的最低 bit, 目前 SDK 的 iv index 按 big endian 存储)。
- NID:和 network key 相关
- CTL:标记是否是 control message
3.3 Network transmit count/ / interval ( ( 重传 次数 和 重传间隔的定义) )
network transmit count 是指发送一个命令，需要重传的次数，这些重传的 rf packet 是一模一样的，包括 sno 等。重传的目的是为了提升接收成功率。假如当网络中只有两个 mesh 节点，只发送一次的成功率是 80%，即丢包率是 20%，那么，理论上，发送 6 次的丢包率是 20%的 6 次方，即 0.0064%，即收包成功率是 99.993%，当然这个是理论分析。和 RF 环境等还有一定的关系。
我们的 SDK 协议栈默认重发 5 次，即 TRANSMIT_CNT_DEF(5)，总共发发送次数是 n+1 =6 个。
network transmit interval 是指重传的两个包之间的发送间隔，我们 SDK 默认在 30-40ms之间，由 TRANSMIT_INVL_STEPS_DEF(2) 决定，计算方式是 ((TRANSMIT_INVL_STEPS_DEF +1)*10 + (0----10))ms。”
network transmit count、transmit interval 还可以通过 SIG 定义的标准 config 命令CFG_NW_TRANSMIT_SET 来配置。
综上所述，我们 SDK 默认发送一个 network packet，比如 generic ONOFF no ack 命令(该命令不需要分包)，需要的时间大概是 40 * 6 = 240ms。
3.4 Reliable retry( 发包 重试次数) )
Reliable retry 是指应用层的重试，用于有 status 回复的命令，比如 generic ONOFF。当发送一个 network packet 后(包含 network transmit)，会判断是否收到 status，如果没有收到，我们会进行 retry，retry 的时候，network packet 里面的 sequence number 会变化。我们默认最多重试两次。
四、mesh beacon
下图是 unprovisioned device beacon 的 PDU。
Device UUID 可以唯一识别 node。因为有些手机，比如 IOS 不能获取 mac，以及在未来的remote provision 中无法获得 mac，所以在 SIG mesh 中是通过 Device UUID 来唯一识别 node，而不是通过 mac。unprovisioned beacon 通过 non-connectable ADV 的 packet 来发送，用于 PB-ADV
provision 模式。
Oob info 及 URI Hash 请参考 spec 《3.9.2 Unprovisioned Device beacon》在未组网时，会发送 unprovision beacon，通过 unprov_beacon_send()来发送。发送周期由”beacon_send.inter = MAX_BEACON_SEND_INTERVAL”来定义，默认是 2 秒。在组网后，会发送 security beacon，通过 mesh_tx_sec_nw_beacon()来发送。另外还可以通过 CFG_BEACON_SET 命令打开或者关闭这个发送使能开关。请参考本文章节《4.4 控制对应的节点》““SecNwBc”按钮”的操作。发送周期由 SEC_NW_BC_INV_DEF_100MS 来定义，默认是 10 秒。
五、IV Update procedure
即iv index的update flow。network layer和access layer的加解密过程都需要用到iv index。
前面提到，mesh网络要求network PDU的sequence number要一直累加，而sequence number
是 3byte 表示。当使用很长一段时间后，sequence number 接近最大值的时候，就需要考虑更
新 iv index，否则 sequence number 就会归 0，导致接收端认为是一个无效的 message。从某
种程度上，可以理解 iv index 为 sequence number 的扩展位。
iv index update flow 是节点自行发起，自行 update 的过程。目前 SDK，当节点检测自己
的sequence number超过了IV_UPDATE_START_SNO (0xC00000) 后，会主动发起 iv update
folw。每次 Iv update 后，iv index 会加 1.
详细的 iv update flow 请查阅 spe 相关章节: SPEC V1.0 《3.10.5 IV Update procedure》。
六、heartbeat
mesh 的心跳包，可以配置周期发送，所以可以用于做在线离线检测(周期 publish 机制也可
以做在线离线检测)，以及 hops 的计算，即计算 heartbeat message 经过多少跳之后，才被接
收到。
经过统计一定时间内收到的 heartbeat 的个数(count)，并计算得到每个 heartbeat 的 hops
的 值，得到 min hops 和 max hops，进而了解整个网络的布局，以及每一个节点的 message
传输的可靠程度。不过每次配置 heartbeat subscription 只能监听和统计一个节点的状态。
hops 计算方式是 :hops = InitTTL - RxTTL +1。
- InitTTL:是 heartbeat publish set 里面的 TTL 参数。
- RxTTL:是收到的 message 的 network PDU 里面的 TTL。
节点默认不发送 heartbeat，具体配置方式，详见“5.6 Heartbeat 的演示”章节
七、Health
Health model 相关的 message 是用来反映节点的 warning 或者 error 状态。
| Value | Description |
|---|---|
| 0x00 | No Fault |
| 0x01 | Battery Low Warning |
| 0x02 | Bettery Low Error |
| 0x03 | Supply Voltage Too Low Warning |
| 0x04 | Supply Voltage Too Low Error |
| 0x05 | Supply Voltage Too High Warning |
| 0x06 | Supply Voltage Too High Error |
| 0x07 | Power Supply Interrupted Warning |
| 0x08 | Power Supply Interrupted Error |
| 0x09 | No Load Warning |
| 0x0A | No Load Error |
| 0x0B | Overload Warning |
| 0x0C | Overload Error |
| 0x0D | Overheat Warning |
| 0x0E | Overheat Error |
| 0x0F | Condensation Warning |
| 0x10 | Condensation Error |
| 0x11 | Vibration Warning |
| 0x12 | Vibration Error |
| 0x13 | Configuration Warning |
| 0x14 | Configuration Error |
| 0x15 | Element Not Calibrated Warning |
| 0x16 | Element Not Calibrated Error |
| 0x17 | Memory Warning |
| 0x18 | Memory Error |
| 0x19 | Self-Test Warning |
| 0x1A | Self-Test Error |
| 0x1B | Input Too Low Warning |
| 0x1C | Input Too Low Error |
| 0x1D | Input Too High Warning |
| 0x1E | Input Too High Error |
| 0x1F | Input No Change Warning |
| 0x20 | Input No Change Error |
| 0x21 | Actuator Blocked Warning |
| 0x22 | Actuator Blocked Error |
| 0x23 | Housing Opened Warning |
| 0x24 | Housing Opened Error |
| 0x25 | Tamper Warning |
| 0x26 | Tamper Error |
| 0x27 | Device Moved Warning |
| 0x28 | Device Moved Error |
| 0x29 | Device Dropped Warning |
| 0x2A | Device Dropped Error |
| 0x2B | Overflow Warning |
| 0x2C | Overflow Error |
| 0x2D | Empty Warning |
| 0x2E | Empty Error |
| 0x2F | Internal Bus Warning |
| 0x30 | Internal Bus Error |
| 0x31 | Mechanism Jammed Warning |
| 0x32 | Mechanism Jammed Error |
| 0x33-0X7F | Reserved for Future Use |
| 0x80-0XFF | Vendor Specific Warning / Error |
觉得好，就一键三连呗（点赞+收藏+关注）