蓝牙Mesh协议栈详解：节点、中继、Friend、Low Power节点角色与通信机制
好，咱们进入正题。蓝牙Mesh这套协议栈，说白了就是一套让设备之间能互相传话的规则。你想想看，一个灯泡、一个传感器、一个开关，它们怎么知道该听谁的？消息怎么转发？谁可以睡觉省电？这些都得靠协议栈里定义好的角色和机制来搞定。
我个人习惯把蓝牙Mesh的节点角色分成四类：节点（Node）、中继（Relay）、Friend节点和低功耗节点（Low Power Node，LPN）。这四种角色不是硬件上固定的，而是软件配置出来的。同一个设备，今天当中继，明天改配成Friend节点，完全没问题。
核心要点：蓝牙Mesh网络里，所有设备都是节点，但只有配置了特定功能后，才会承担中继、Friend或LPN的角色。默认情况下，一个节点可以同时具备多种角色。
2.1 节点（Node）—— 网络里的基本单元
节点就是任何一个加入了蓝牙Mesh网络的设备。它至少有一个元素（Element），每个元素有自己的单播地址。节点能收发消息，也能被配置。
我记得刚开始做Mesh项目时，有个坑让我折腾了两天：节点的元素数量。一个灯控设备，如果只有一个元素，那它只能控制一路灯。但如果你想让一个设备控制三路灯光，就得声明三个元素。每个元素独立编址，独立绑定应用密钥。这个在配网时就得规划好，不然后面改配置很麻烦。
节点的基础能力包括：
- 收发消息：能接收发往自己地址的消息，也能发送消息给其他节点。
- 订阅/发布：可以订阅组地址或虚拟地址，也能向特定地址发布消息。
- 状态绑定：比如一个开关节点，它的开关状态可以绑定到灯节点的亮度状态上。
我的建议：在设计节点模型时，尽量把每个功能独立成一个元素。比如一个智能插座，把继电器控制、电量计量、温度检测分成三个元素。这样后期扩展和调试都方便。
2.2 中继（Relay）—— 消息的搬运工
中继节点是蓝牙Mesh网络的骨架。没有中继，消息就只能在一跳范围内传播，那还叫什么Mesh？
中继的工作原理其实很简单：收到一条消息后，检查消息的TTL（生存时间）值。如果TTL大于1，就把TTL减1，然后重新广播出去。如果TTL等于1或0，就不再转发。
这里有个关键参数——中继重传次数。我在项目中遇到过一个问题：车间里部署了50多个中继节点，结果消息风暴把网络搞瘫了。后来一查，每个中继默认重传3次，50个节点就是150次广播，信道全被占满了。
避坑指南：我曾经在一个仓库项目里，把中继重传次数设成了默认值7次。结果网络延迟从50ms飙升到2秒以上。后来我把重传次数降到2次，配合TTL控制在3跳以内，问题才解决。中继不是越多越好，重传也不是越可靠越好，得找到平衡点。
中继节点的配置项：
| 参数 | 说明 | 建议值 |
|---|---|---|
| 中继功能开关 | 是否启用中继能力 | 根据网络规模决定 |
| 中继重传次数 | 每条消息重复广播的次数 | 2~3次 |
| 中继重传间隔 | 两次重传之间的时间间隔 | 10~50ms |
2.3 Friend节点与低功耗节点（LPN）—— 省电搭档
这俩角色是成对出现的。低功耗节点想省电，但不能一直睡觉，否则收不到消息怎么办？Friend节点就是帮LPN缓存消息的。
工作机制是这样的：
- LPN和Friend节点建立Friend关系，协商好缓存大小和轮询间隔。
- LPN进入休眠状态，Friend节点替它监听网络消息。
- LPN醒来后，向Friend节点发送轮询请求，Friend把缓存的消息一次性发给LPN。
- LPN处理完消息，继续睡觉。
嗯，这里要注意：一个Friend节点可以同时服务多个LPN，但一个LPN只能绑定一个Friend节点。我在做智能照明项目时，一个Friend节点挂了，下面20多个LPN全部失联。后来我做了冗余设计，每个LPN配置两个备选Friend节点，主Friend失联后自动切换。
关键参数：Friend节点为每个LPN维护一个Friend缓存（Friend Cache），最大可缓存消息数由配置决定。LPN的轮询间隔直接影响功耗和实时性——间隔越短，功耗越高，但消息延迟越低。
LPN的典型应用场景：
- 电池供电的传感器（温湿度、门磁、人体感应）
- 无线开关面板
- 可穿戴设备
2.4 四种角色的通信机制
蓝牙Mesh的通信机制，说白了就是消息的发布与订阅。节点不关心消息是谁发的，只关心消息是不是发给自己订阅的地址。
消息传递的完整流程：
- 源节点发布消息到某个地址（单播、组播或虚拟地址）。
- 消息在传输层被分片（如果消息长度超过15字节）。
- 每个分片通过承载层（Advertising Bearer或GATT Bearer）发送出去。
- 中继节点收到后，检查TTL，决定是否转发。
- Friend节点如果收到发给自己服务的LPN的消息，就存入缓存。
- 目标节点收到所有分片后，重组消息，交给上层处理。
这里有个容易忽略的点——消息的可靠性。蓝牙Mesh的底层是BLE广播，广播本身是不可靠的。那怎么保证消息能送到呢？靠的是应用层的确认重传机制。比如一个开关发“开灯”命令，灯收到后要回复确认消息。如果开关没收到确认，就会重发。
我的经验：在写应用层代码时，一定要处理好消息超时和重传逻辑。我曾经偷懒没做重传，结果在信号干扰强的环境下，开关按十次只有六次能亮灯。后来加了3次重传，成功率才到99.5%。
2.5 角色关系与网络拓扑
为了让你更直观地理解这四种角色怎么配合，我画了一张图。这张图展示了一个典型的蓝牙Mesh网络拓扑：
从这张图你能看到：中继节点之间互相连接，形成消息的骨干网。Friend节点挂在中继下面，为LPN提供消息缓存服务。普通节点（比如灯控设备）直接连接中继，实时收发消息。LPN则通过Friend节点间接接入网络，大部分时间在睡觉。
2.6 角色配置实战建议
最后，我结合项目经验，给你几条配置建议：
- 中继节点密度：每100平方米部署2~3个中继节点就够了。太密反而增加冲突，太疏则覆盖不全。
- Friend节点选择：尽量用市电供电的设备做Friend节点。电池供电的设备当Friend？我试过，撑不过三天。
- LPN轮询间隔：传感器类设备可以设5~10秒，开关类设备建议设1~2秒。你想想看，按了开关要等5秒灯才亮，用户不骂娘才怪。
- TTL设置：小型网络设3~5跳，大型网络设7~10跳。TTL越大，消息传播越远，但网络负载也越大。
重要提醒：蓝牙Mesh协议栈里，节点角色是通过配置模型（Configuration Model）来设置的。配网时一定要先配好角色，再配应用。我见过有人先配了应用，再改角色，结果节点状态全乱了，只能重新配网。