基础参考：
架构概述
传统蓝牙的Host/Controller架构，在Mesh协议栈中被完整保留了。 Mesh并非抛弃了这一经典架构，而是在其基础之上，新增了一套独立的网络层。简单来说，它是在同一个地基上，盖了另一栋楼。
让我们通过架构图来清晰地展示这一点：
从图中可以清晰地看到，Mesh协议栈与传统BLE协议栈在主机层并驾齐驱，但它们都通过同一个 HCI 接口，共享底层的控制器和物理层硬件。
🧱 "主机-控制器"架构是蓝牙的基石
这个架构是蓝牙技术的核心。
主机 (Host) ：这是系统的"大脑"，运行在设备的主CPU上。它负责处理各种高级协议，比如你熟知的 GAP（通用访问协议）和 GATT（通用属性协议）。对于Mesh来说，它的协议栈（网络层、传输层等）也全部运行在这一层。
控制器 (Controller)：这是系统的"耳朵和嘴巴"，通常集成在蓝牙芯片中。它负责底层的物理工作：按照严格的时间要求在2.4GHz频段上收发无线电信号。
HCI (主机控制器接口)：这是连接"大脑"和"耳朵"的标准通道。正是因为这个标准接口的存在，Mesh协议栈才能和传统BLE协议栈一样，通过相同的方式向控制器发送指令。
🆚 Mesh与传统BLE在架构下的分工
在这套统一的架构下，两者的分工非常明确：
层级 传统 BLE BLE Mesh 说明 应用层 耳机、手环、鼠标等应用逻辑 灯、开关、传感器等模型 (Model) 逻辑 这是开发者编写业务代码的地方。 主机层 GAP/GATT 协议，管理连接 Mesh协议栈 (网络层、传输层等)，管理网络 和消息转发 Mesh协议栈和传统BLE协议栈在主机层是并列的。 主机控制器接口 (HCI) 标准HCI命令，如 LE Create Connection相同的HCI命令，主要使用 LE Set Ext Scan/Adv Enable来收发广播包两者复用同一套HCI接口，这是关键。 控制器层 执行连接、更新参数等链路层任务 执行广播、扫描等链路层任务 控制器"不知道"自己是在为传统BLE还是Mesh服务，它只执行命令。 📡 Mesh是如何复用BLE控制器的？
Mesh网络主要依赖 广播 (Advertising) 机制进行通信。当Mesh协议栈（在主机层）需要发送一条消息时，它并不是发明了一种新的调用方式，而是通过标准的HCI命令，比如
LE Set Extended Advertising Enable，来指示BLE控制器去广播一个特定的数据包。所以，对于底层的BLE控制器而言，它看到的工作负载依然是自己熟悉的：广播、扫描、建立连接（为GATT承载）。它完全不感知自己传输的数据是来自一个传统BLE应用，还是一个复杂的Mesh网络。
Mesh协议栈本身并不是一个独立的"方向"，它是构建在经典的Host/Controller架构之上的一个 "高级应用层游戏规则"。它利用标准HCI接口调用控制器的广播能力，实现了一套去中心化的设备组网。
Mesh协议栈和各层模型
Mesh 协议栈是一个结构清晰、分工明确的多层架构。它构建在 BLE 核心协议之上，在主机（Host）层内部新增了完整的网络、传输和应用层。
下面这张图清晰地展示了 BLE Mesh 协议栈的分层结构，以及每一层在整个架构中的位置和作用：
📡 第一层：物理与承载层
承载层定义了 Mesh 消息如何在物理上传输，包含两种方式：
承载类型 通信方式 使用场景 广播承载 (Advertising Bearer) 使用 BLE 的广播信道发送不可连接广播包 节点与节点之间的主要通信方式 GATT 承载 (GATT Bearer) 通过 BLE 连接，使用代理协议传输 让普通手机（不支持 Mesh 广播）接入网络 BLE 控制器直接复用标准的 BLE 物理层（2.4GHz）和链路层。这意味着 Mesh 没有定义新的物理层，而是"寄生"在 BLE 之上。
🌐 第二层：网络与传输层
网络层 (Network Layer)
这是 Mesh 网络的核心，负责：
消息中继 (Relay)：采用基于泛洪（Flooding）的方式转发消息。节点收到消息后，除非 TTL（Time to Live）为 0，否则会继续广播
地址解析：识别消息是发给自己的（单播）、一组设备的（组播）还是所有人
加密与认证：使用网络密钥（NetKey）对网络层消息进行加密
底层传输层 (Lower Transport Layer)
负责数据的分段与重组：
当 Mesh 消息超过单包容量时，拆分成多个数据块发送
接收端将分段消息重新组装
在朋友关系中，朋友节点在此层为低功耗节点暂存消息队列
上层传输层 (Upper Transport Layer)
负责：
应用数据加解密：使用应用密钥（AppKey）对应用层数据进行端到端加密
传输控制消息：管理心跳消息（Heartbeat）、朋友关系建立等
访问层 (Access Layer)
定义上层应用如何使用传输层：
数据格式定义：规定应用数据应该如何打包
发布/订阅管理：处理模型（Model）的消息发布和订阅关系
访问控制：验证消息是否使用了正确的密钥
💡 第三层：应用与模型层
模型层 (Model Layer)
模型定义了设备的具体功能，是应用开发者直接打交道的层。规范的摘要如图所示：
image-1\] 模型包含状态和操作，并以 Client/Server 的形式暴露给其他节点。 每个模型分为三类： | 类型 | 功能 | 控制方式 | |------------------|----------------------------------------------|-------------| | **Server Model** | 包含状态，维护设备当前状态（如"灯是开的"） | 被动接收指令并执行 | | **Client Model** | 读取和修改 Server 的状态 | 主动发出控制指令 | | **Setup Server** | 配置参数的 Server（与 Server Model 共享状态，但使用不同的应用密钥） | 供配置工具进行高级设置 | **多个模型组织。** 一个节点可以包含多个模型，这些模型被组织成**元素（Element）**。每个元素拥有独立的单播地址，代表节点的一个"功能面"。例如，一个节点可以同时拥有一个"Light Server"用于控制灯光，和一个"Sensor"用于报告温度。 **基础模型层 (Foundation Model Layer)** 提供网络**配置和管理**的标准模型，是所有节点必须支持的基础： * **配置模型 (Configuration Model)**：用于配网、地址分配、开启中继/代理/朋友功能等 * **健康模型 (Health Model)**：监控节点健康状态（如电量不足、故障），用于故障报告 **SIG 定义的模型类型** 以下是 Mesh 设备常见的一些标准模型分类： | 类别 | 核心模型示例 | 设备应用场景（举例） | |-------------------------|------------------------------------------------|-------------------------| | **基础模型** | `Configuration Server`， `Health Server` | **所有节点必备**，负责入网配置和故障上报 | | **通用模型** | `Generic OnOff Server`， `Generic Level Server` | 基础二值开关、调光/调温/音量等连续调节 | | **照明模型** | `Light Lightness Server`， `Light CTL Server` | 智能灯泡的亮度、色温、XYZ 颜色控制 | | **传感器模型** | `Sensor Server` | 温湿度传感器、人体传感器等数据上报 | | **时间与场景模型** | `Time Server`， `Scene Server` | 定时任务、一键场景切换 | | **厂商模型 (Vendor Model)** | 厂商自定义操作码 | **私有功能**，当标准模型无法覆盖需求时使用 | *** ** * ** *** **状态绑定机制** 模型中有一个特殊机制------**状态绑定** 。当一个状态发生变化时，会要求另一个相关状态也随之更新。例如，调节色温时，人眼的**感知亮度** 会随之变化，可设置 `Light CTL Temperature` 状态与 `Light Lightness` 状态绑定，系统自动进行亮度的非线性补偿，从而保证用户调节色温时，主观感受的亮度保持恒定。 *** ** * ** *** **一个智能灯泡的实现实例** Nordic 提供了一个演示示例，展示了一个节点如何组合多个模型： | 功能 | 实现的模型 | 绑定的硬件 | |------|------------------------------|-----------------| | 开关控制 | `Generic OnOff Server` | LED1（开/关） | | 亮度调节 | `Light Lightness Server` | LED3（亮度变化） | | 色温调节 | `Light CTL Server` | LED4（色温变化） | | 按钮输入 | `Generic OnOff Client`（发布指令） | Button1、Button2 | | 厂商私有 | `Vendor Model` | LED2（私有功能） | > 这个例子中的"Client"和"Server"同时存在于一个物理设备上。这在 BLE Mesh 中是合法且常见的，它们负责不同功能模块的协作。 **💎 总结** Mesh 协议栈与各层模型的关系可以这样理解： * **协议栈是"骨架"**：承载层、网络层、传输层定义了数据的"打包"和"运输"规则 * **模型是"血肉"**：模型层定义了设备的功能和行为，是应用开发者编程的接口 开发者主要工作在模型层，通过调用预定义的标准模型（如开、关、调光、上报温度），或自定义厂商模型，来实现具体的产品功能。这种分层设计让 Mesh 网络既具备强大的底层通信能力，又保持了上层应用的灵活性和标准化。 更多待补充。。。
