基础参考BLE MESH基础知识总结-CSDN博客架构概述传统蓝牙的Host/Controller架构在Mesh协议栈中被完整保留了。Mesh并非抛弃了这一经典架构而是在其基础之上新增了一套独立的网络层。简单来说它是在同一个地基上盖了另一栋楼。让我们通过架构图来清晰地展示这一点从图中可以清晰地看到Mesh协议栈与传统BLE协议栈在主机层并驾齐驱但它们都通过同一个 HCI 接口共享底层的控制器和物理层硬件。 “主机-控制器”架构是蓝牙的基石这个架构是蓝牙技术的核心。主机 (Host)这是系统的“大脑”运行在设备的主CPU上。它负责处理各种高级协议比如你熟知的 GAP通用访问协议和 GATT通用属性协议。对于Mesh来说它的协议栈网络层、传输层等也全部运行在这一层。控制器 (Controller)这是系统的“耳朵和嘴巴”通常集成在蓝牙芯片中。它负责底层的物理工作按照严格的时间要求在2.4GHz频段上收发无线电信号。HCI (主机控制器接口)这是连接“大脑”和“耳朵”的标准通道。正是因为这个标准接口的存在Mesh协议栈才能和传统BLE协议栈一样通过相同的方式向控制器发送指令。 Mesh与传统BLE在架构下的分工在这套统一的架构下两者的分工非常明确层级传统 BLEBLE 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的方式转发消息。节点收到消息后除非 TTLTime 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 ServerHealth Server所有节点必备负责入网配置和故障上报通用模型Generic OnOff ServerGeneric Level Server基础二值开关、调光/调温/音量等连续调节照明模型Light Lightness ServerLight CTL Server智能灯泡的亮度、色温、XYZ 颜色控制传感器模型Sensor Server温湿度传感器、人体传感器等数据上报时间与场景模型Time ServerScene Server定时任务、一键场景切换厂商模型 (Vendor Model)厂商自定义操作码私有功能当标准模型无法覆盖需求时使用状态绑定机制模型中有一个特殊机制——状态绑定。当一个状态发生变化时会要求另一个相关状态也随之更新。例如调节色温时人眼的感知亮度会随之变化可设置Light CTL Temperature状态与Light Lightness状态绑定系统自动进行亮度的非线性补偿从而保证用户调节色温时主观感受的亮度保持恒定。一个智能灯泡的实现实例Nordic 提供了一个演示示例展示了一个节点如何组合多个模型功能实现的模型绑定的硬件开关控制Generic OnOff ServerLED1开/关亮度调节Light Lightness ServerLED3亮度变化色温调节Light CTL ServerLED4色温变化按钮输入Generic OnOff Client发布指令Button1、Button2厂商私有Vendor ModelLED2私有功能这个例子中的“Client”和“Server”同时存在于一个物理设备上。这在 BLE Mesh 中是合法且常见的它们负责不同功能模块的协作。 总结Mesh 协议栈与各层模型的关系可以这样理解协议栈是“骨架”承载层、网络层、传输层定义了数据的“打包”和“运输”规则模型是“血肉”模型层定义了设备的功能和行为是应用开发者编程的接口开发者主要工作在模型层通过调用预定义的标准模型如开、关、调光、上报温度或自定义厂商模型来实现具体的产品功能。这种分层设计让 Mesh 网络既具备强大的底层通信能力又保持了上层应用的灵活性和标准化。更多待补充。。。