第三章：蓝牙Mesh协议栈详解——Profile层、Core层、Bearer层、Model层、Foundation Model与Vendor Model
好，咱们今天来啃一块硬骨头——蓝牙Mesh的协议栈。说实话，我刚接触Mesh的时候，也被这堆分层搞得有点晕。什么Profile、Core、Bearer，听着就像俄罗斯套娃。但干过几个项目之后，我慢慢摸清了门道。说白了，这玩意儿就是一套规矩，告诉你的设备怎么说话、怎么传话、怎么听懂别人的话。
我个人习惯把蓝牙Mesh协议栈想象成一栋楼。底层是地基，上层是装修。咱们从下往上聊，这样好理解。
3.1 Bearer层——消息的“运输工”
Bearer层是协议栈的最底层。它的任务很简单：把数据包从一个设备搬到另一个设备。嗯，就是个搬运工。
蓝牙Mesh定义了两种Bearer：
- Advertising Bearer（广播承载层）：利用BLE的广播通道来发送Mesh消息。这是最常用的方式。
- GATT Bearer（GATT承载层）：通过GATT连接来传输Mesh数据。主要用于手机App与Mesh网络之间的桥接。
关键点：Mesh网络不依赖传统的蓝牙连接。它用的是广播方式。每个设备都在“喊话”，其他设备在“听”。谁听到了，谁就帮忙转发。这就是Mesh的“洪泛”机制。
我在项目中遇到过一个问题：某个节点离网关太远，信号穿不过两堵墙。后来我加了一个中继节点，问题就解决了。说白了，Bearer层只管把数据发出去，至于能不能到目的地，得靠上层和中继机制。
避坑指南：我曾经在调试时发现，某些设备收不到消息。查了半天，原来是Advertising Bearer的广播间隔设置得太长。默认20ms，我改成了50ms，结果丢包率飙升。记住，广播间隔越短，网络负载越大，但实时性越好。需要根据实际场景权衡。
3.2 Core层——Mesh网络的“大脑”
Core层是协议栈的核心。它负责管理网络拓扑、消息路由、安全加密、节点配置等关键功能。你想想看，没有Core层，设备之间就是一群“哑巴”，只会喊不会组织。
Core层包含几个关键模块：
- Network Layer（网络层）：处理消息的转发和中继。它决定了消息该往哪走。
- Lower Transport Layer（低层传输层）：负责将长消息分片，以及将分片重组。Mesh消息最大380字节，超过就得切。
- Upper Transport Layer（高层传输层）：负责加密、解密和认证。确保消息只有合法设备能看懂。
- Access Layer（接入层）：定义了应用数据如何封装成消息，以及如何与Model层交互。
| 层级 | 主要职责 | 我踩过的坑 |
|---|---|---|
| Network Layer | 消息转发、中继、TTL管理 | TTL设太大，消息全网广播，网络拥塞 |
| Lower Transport | 消息分片与重组 | 分片超时导致消息丢失，需要重传 |
| Upper Transport | 加密、解密、应用层确认 | 密钥配置错误，设备之间“鸡同鸭讲” |
| Access Layer | 应用数据封装、Model交互 | Opcode定义冲突，两个Model抢消息 |
为什么会这样？因为Core层太重要了，任何一个环节出问题，整个网络都可能瘫痪。我记得有一次，客户反馈说设备偶尔掉线。我抓包一看，是Lower Transport层的分片重组超时了。网络环境差，分片丢了一个，整个消息就废了。后来我调整了重传策略，问题解决。
3.3 Profile层——应用的“说明书”
Profile层定义了设备的行为规范。它告诉设备：你是什么角色？你能干什么？你该怎么跟其他设备配合？
蓝牙Mesh标准定义了几个Profile：
- Mesh Profile：这是最基础的，定义了所有Mesh设备必须遵守的规则。
- Mesh Model Profile：定义了Model的标准化行为，比如Generic OnOff、Light Lightness等。
- Device Profile：定义了设备配置和管理的标准流程。
说白了，Profile层就是一份合同。所有设备都得按合同办事。你想想看，如果A厂家的灯用“0x01”表示开，B厂家的灯用“0xFF”表示开，那不乱套了？Profile层就是来统一这些“方言”的。
我的建议：做产品开发时，尽量遵循标准Profile。除非你有特殊需求，否则别自己发明轮子。标准Profile经过了大量验证，兼容性好，开发成本也低。
3.4 Model层——设备的“功能模块”
Model层是协议栈里最贴近应用的一层。每个Model代表了一组功能。比如，一个灯可以有“开关Model”、“亮度Model”、“色温Model”。
Model分为两种：
- Server Model（服务端模型）：提供状态和功能。比如灯的开关状态。
- Client Model（客户端模型）：发送请求，控制Server。比如开关面板。
一个设备可以同时拥有多个Model。比如一个智能灯泡，它既是Server（提供状态），也可以是Client（接收遥控指令）。
经验之谈：我在做智能家居项目时，把灯控面板设计成了纯Client，灯泡是纯Server。这样分工明确，调试起来也方便。但后来发现，如果面板和灯泡之间没有心跳检测，面板不知道灯泡是否离线。所以我又给灯泡加了一个Heartbeat Model。嗯，设计时要考虑周全。
3.5 Foundation Model——Mesh的“基础设施”
Foundation Model是蓝牙Mesh预定义的一组基础Model。它们负责网络的配置和管理。没有它们，Mesh网络根本跑不起来。
常见的Foundation Model包括：
- Configuration Server Model：提供节点配置服务，比如设置网络密钥、添加应用密钥等。
- Configuration Client Model：用于向Configuration Server发送配置命令。
- Health Server Model：监控节点健康状态，比如电池电量、错误计数等。
- Health Client Model：用于查询和清除Health Server的状态。
说白了，Foundation Model就是Mesh网络的“管理员”。设备入网、密钥分发、状态监控，全靠它们。
注意事项：我曾经在项目中忽略了Health Model。结果设备运行一段时间后，电池没电了，我完全不知道。后来加上Health Server，定期上报电量，问题才解决。记住，Foundation Model不是摆设，它们是网络稳定运行的保障。
3.6 Vendor Model——你的“定制武器”
标准Model虽然好用，但总有覆盖不到的场景。这时候，Vendor Model就派上用场了。它允许你自定义Model，实现私有功能。
Vendor Model的特点：
- 自定义Opcode：你可以定义自己的操作码，范围在0xC00000到0xFFFFFF之间。
- 自定义消息格式：消息内容完全由你定义，不受标准约束。
- 需要Vendor ID：每个Vendor Model必须关联一个蓝牙SIG分配的Vendor ID。
举个例子，我做过一个工业传感器项目，需要采集温度、湿度、气压三个数据。标准Model没有现成的，我就自己写了一个Vendor Model。Opcode用0xC00001，消息格式是：
// Vendor Model消息格式示例
typedef struct {
uint16_t vendor_id; // 厂商ID，比如0x1234
uint8_t opcode; // 操作码，比如0x01表示上报数据
int16_t temperature; // 温度，单位0.01°C
uint16_t humidity; // 湿度，单位0.01%
uint16_t pressure; // 气压，单位0.1hPa
} vendor_sensor_msg_t;这样，我的传感器节点和网关之间就能用私有协议通信了。其他厂家的设备看不懂，但没关系，它们也不需要懂。
关键提醒：Vendor Model虽然灵活，但也要注意兼容性。如果你的产品需要与其他厂家设备互通，尽量用标准Model。Vendor Model适合封闭系统或私有协议场景。
3.7 各层之间的协作——一个消息的“旅行”
咱们来模拟一下，一个开关面板控制一个灯泡的过程。消息是怎么从面板传到灯泡的？
- 面板（Client Model）：用户按下开关，面板的Generic OnOff Client Model生成一个“开灯”消息。
- Access Layer：将消息封装成Access PDU，加上Opcode和参数。
- Upper Transport Layer：对消息进行加密和认证，生成Transport PDU。
- Lower Transport Layer：如果消息太长，进行分片。每个分片加上序列号。
- Network Layer：加上网络头，包含源地址、目的地址、TTL等信息，生成Network PDU。
- Bearer Layer：通过Advertising Bearer广播出去。
- 中继节点：收到广播后，Network Layer检查TTL，如果大于0，就减1并重新广播。
- 灯泡（Server Model）：收到消息后，逐层解封装，最终交给Generic OnOff Server Model处理，灯泡亮起。
整个过程看起来复杂，但实际在芯片内部，就是几毫秒的事。你想想看，如果没有这些分层，每个设备都得自己处理所有细节，那开发效率得多低？
我的习惯：调试Mesh网络时，我经常用抓包工具看各层的PDU。比如，如果消息没到目的地，我会先看Bearer层有没有广播出去，再看Network层的TTL是不是设得太小。逐层排查，问题很快就能定位。
3.8 总结与建议
蓝牙Mesh协议栈的分层设计，说白了就是为了“解耦”。每一层只管自己的事，上层不用关心底层怎么传，底层不用关心上层传的是什么。这种设计让开发变得模块化，也方便了调试和维护。
我个人建议，初学者不要急着看代码，先把这五层的关系理清楚。你可以在白板上画一画，消息从应用层到物理层是怎么走的。画明白了，代码自然就懂了。
最后，记住一句话：Profile层定规矩，Core层管路由，Bearer层做搬运，Model层干实事，Foundation Model保基础，Vendor Model搞创新。把这六个角色记牢了，蓝牙Mesh对你来说就不再是黑盒了。
下一章，咱们会深入Model层的具体实现，手把手教你写一个Generic OnOff Server。到时候，你会真正感受到“纸上得来终觉浅，绝知此事要躬行”的道理。