1. Mesh网络基础回顾：节点、中继、好友、代理特性，以及消息发布/订阅模型

各位好，我是老周。做蓝牙协议栈十几年了，Mesh这块从2017年规范刚出来就开始啃。今天咱们先不急着排查故障，把地基打牢。Mesh网络和传统蓝牙最大的区别在哪？说白了，它不再是「一对一」的短连接，而是一个「多对多」的网状网络。你想想看，一个灯泡坏了，整个灯控系统不能瘫痪吧？Mesh就是干这个的。

节点是Mesh网络里最基础的设备。一个灯、一个开关、一个传感器，只要加入了Mesh网络，都叫节点。每个节点都有一个唯一的单播地址，就像门牌号。

节点分两种：

我的经验： 很多工程师以为节点只要上电就能通信。不对。节点必须完成配网流程，拿到NetKey、AppKey和地址，才算真正「入网」。我在项目中遇到过客户抱怨设备连不上，结果发现是配网流程没走完——节点还在「待配网」状态呢。

中继功能是Mesh网络的灵魂。没有中继，消息就只能直连，那和传统蓝牙有什么区别？

中继节点做的事情很简单：收到一条消息，检查是不是发给自己的。如果不是，就转发出去。但这里有个关键——TTL（生存时间）。

避坑指南： 我曾经遇到一个客户，整个办公楼Mesh网络经常丢包。排查到最后，发现所有节点TTL都设成了127。消息在网络里反复广播，造成广播风暴。中继不是越多越好，TTL也不是越大越好。一般场景7跳足够了。

低功耗节点（LPN）不能一直监听网络，否则电池撑不住。这时候就需要好友节点来帮忙。

好友节点会替LPN缓存消息。LPN醒来后，问好友：「有我的消息吗？」好友把缓存的消息发给它，然后LPN继续睡。

好友关系有几个要点：

    关键参数： Friend Receive Window（好友接收窗口）。LPN发送Poll请求后，好友在这个窗口期内回复。窗口太短，LPN收不到回复；窗口太长，LPN要一直开着接收器，费电。我一般建议设100ms左右，兼顾功耗和可靠性。

手机没有Mesh协议栈，怎么控制Mesh网络？靠代理节点。

代理节点在Mesh网络和手机之间搭了一座桥。手机通过GATT连接代理节点，发送Mesh消息。代理节点把消息转成Mesh广播包，发到网络里。反过来也一样。

代理协议（Proxy Protocol）定义了四种PDU类型：

嗯，这里要注意：代理节点不能是低功耗节点。它得一直在线，否则手机连不上。

Mesh网络里，消息不是直接发给某个具体设备的。它用的是发布/订阅模型。

每个节点可以订阅一个或多个组地址。当某个节点发布消息到组地址时，所有订阅了这个组地址的节点都能收到。

举个例子：

发布/订阅模型的好处是解耦。开关不需要知道灯泡的地址，灯泡也不需要知道开关在哪。加一个新灯泡，只要订阅同一个组地址就行。

我的习惯： 做项目时，我会把组地址规划好。比如0xC001是「客厅灯组」，0xC002是「卧室灯组」。千万别用随机地址，否则后期维护会疯掉。我曾经接手过一个项目，组地址全是乱的，排查消息路由问题花了两周。

下面这张图把上面讲的几个角色和它们之间的关系串起来了。你看一眼就能明白Mesh网络是怎么工作的。

这一章我们把Mesh网络的五个核心角色和消息模型过了一遍。你记住一句话就行：节点是基础，中继是骨架，好友是省电方案，代理是手机入口，发布/订阅是消息路由的灵魂。

后面排查连接断开问题时，你会反复用到这些概念。比如设备掉线了，先看它是普通节点还是LPN？如果是LPN，好友节点还在不在？消息发不出去，先查发布/订阅配置对不对？这些基础打牢了，排查起来才有方向。