4. Mesh协议栈架构：七层结构详解
蓝牙Mesh的协议栈，说白了就是一套分层分工的通信规则。我刚开始接触时也觉得层数太多，但实际做项目就会发现——每一层都有它存在的理由。
咱们从下往上，一层一层拆开看。
核心观点：Mesh协议栈共7层，每层只干一件事，层与层之间通过固定接口通信。这种设计让调试和扩展都变得非常清晰。
4.1 整体架构概览
先看一张整体结构图，心里有个谱。
这张图我建议你保存下来。做项目时经常要回头对照，看问题出在哪一层。
4.2 承载层（Bearer Layer）
承载层是最底层，负责把数据变成物理信号发出去。Mesh协议定义了两种承载方式：
| 承载类型 | 说明 | 典型场景 |
|---|---|---|
| Advertising Bearer（广播承载） | 利用BLE广播通道发送Mesh数据包 | 节点间通信、消息中继 |
| GATT Bearer（GATT承载） | 通过BLE连接通道传输Mesh数据 | 手机配网、未加入网络的设备配置 |
我的经验：广播承载是Mesh的主力通道。GATT承载主要用于配网阶段，设备入网后基本就不用了。我曾经在一个项目中把GATT承载一直开着，结果功耗翻了一倍——后来果断切掉。
4.3 网络层（Network Layer）
网络层是Mesh的核心。它负责：
- 消息中继：收到消息后判断要不要转发
- 地址解析：判断消息是发给自己的还是别人的
- 安全校验：验证消息的完整性和来源
网络层会添加一个Network Header，里面包含：
- IV Index（网络标识索引）
- TTL（生存时间，控制消息跳数）
- 源地址和目标地址
注意：TTL值默认是127，但实际项目中建议设小一点。我见过一个客户把TTL设成127，结果消息在网络里绕了十几圈才消失，整个网络都被撑爆了。一般室内场景设3~5就够用。
4.4 底层传输层（Lower Transport Layer）
这一层处理的是分片与重组。为什么需要它？
BLE广播包最大只能带31字节的用户数据。如果你的消息超过这个长度，底层传输层就会把它切成多个小片，每个片单独发送。接收端再把这些片拼回去。
分片格式长这样：
分片1: [Seq=0][Total=3][Data: 前12字节]
分片2: [Seq=1][Total=3][Data: 中间12字节]
分片3: [Seq=2][Total=3][Data: 最后8字节]关键参数：每个分片最大12字节有效数据。一个消息最多可分64片，也就是说单条消息最大768字节。嗯，这个限制在实际项目中基本够用。
4.5 上层传输层（Upper Transport Layer）
上层传输层负责应用数据的安全传输。它做两件事：
- 加密：对应用数据进行AES-CCM加密
- 传输确认：处理可靠消息的ACK和重传
这里有个概念要分清：
| 消息类型 | 说明 | 是否需要ACK |
|---|---|---|
| Unacknowledged（无确认） | 发出去就不管了 | 否 |
| Acknowledged（需要确认） | 必须收到对方的ACK才算成功 | 是 |
我个人习惯：开关灯用无确认消息，因为偶尔丢一包不影响体验。但调光、色温设置这种关键操作，我会用确认消息，确保设备执行到位。
4.6 接入层（Access Layer）
接入层是应用和协议栈之间的翻译官。它定义了两样东西：
- Opcode（操作码）：告诉设备你要干什么（比如开灯、关灯、查状态）
- Parameters（参数）：操作的具体数据（比如亮度值、色温值）
举个例子，一个开关灯消息的接入层格式：
Opcode: 0x8201 (Generic OnOff Set)
Parameters: 0x01 (表示开灯)避坑指南：我曾经在接入层犯过一个低级错误——Opcode和参数顺序搞反了。结果设备收到消息后把亮度值当成操作码解析，直接崩溃。后来我养成了习惯：每次定义新消息都先画一张字节布局图。
4.7 基础模型层（Foundation Model Layer）
基础模型层是Mesh协议预定义的一组标准模型，用于网络管理。主要包括：
- Configuration Server Model：配置服务器，处理配网、密钥分发
- Configuration Client Model：配置客户端，发起配置请求
- Health Server Model：健康服务器，上报设备状态
- Health Client Model：健康客户端，查询设备健康信息
这些模型是强制实现的。每个Mesh设备至少要实现Configuration Server Model，否则无法入网。
4.8 模型层（Model Layer）
模型层是真正干活的地方。它定义了设备的行为和交互方式。比如：
- Generic OnOff Server：开关服务器，控制灯的亮灭
- Generic Level Server：亮度服务器，控制灯的亮度
- Light Lightness Server：光亮度服务器，专门控制灯光亮度
- Light CTL Server：色温服务器，控制色温和亮度
每个模型都有一组固定的Opcode和状态。你不需要自己发明协议，直接用这些标准模型就行。
我的建议：做智能照明系统，优先使用Light Lightness和Light CTL模型。它们是为灯光场景量身定做的，比Generic模型更精细。我之前一个项目偷懒用了Generic Level，结果调光效果总差那么一点——换成Light Lightness后，问题迎刃而解。
4.9 层间通信流程
最后，咱们看一个完整的消息发送流程，把各层串起来：
- 模型层：应用调用模型接口，比如"开灯"
- 基础模型层：（如果是配置消息，走这里）
- 接入层：封装Opcode和参数，生成接入层PDU
- 上层传输层：加密应用数据，添加传输头
- 底层传输层：如果数据太长，分片
- 网络层：添加网络头，设置TTL和地址
- 承载层：通过BLE广播或GATT发出去
接收端反过来，从下往上逐层解封装，直到模型层拿到原始数据。
重要提醒：调试时一定要搞清楚问题出在哪一层。我见过太多人一遇到通信问题就怀疑硬件，结果查了半天是上层传输层的加密密钥没配对。先看承载层能不能收到包，再看网络层能不能解析，逐层排查，效率最高。
好了，这就是Mesh协议栈的七层结构。每一层都不复杂，但合在一起就构成了一个强大的网络。做项目时多画几遍这张分层图，你会越来越熟悉。