SIG Mesh 到底要不要做？蓝牙设备接网关的几种方式
私有广播、BLE 直连、私有 Mesh 和 SIG Mesh 怎么选？分清「不用 SIG Mesh」和「不做 SIG 认证」两件事，讲清标准模型对 Matter 网关的价值，以及节点数、网络规模这些代价。
上一篇用电脑和手机把 Matter 这一半跑通了。接下来要面对网关的另一半：网关和蓝牙设备之间，到底用什么协议通信？
我们的设备原来用的是一套自己定义的蓝牙广播协议，靠自家 App 控制，跑了很久也没出什么问题。所以项目一开始，团队里就有人问：SIG Mesh 是不是可以不做？
这个问题值得单独写一篇。因为「不做」可能是两件完全不同的事，而它们的后果也完全不同。
先分清楚：「不做」指的是什么
第一种，不用 SIG Mesh 协议。 设备继续用私有广播协议，网关照着这套协议去收发。
第二种，用 SIG Mesh 协议，但不做蓝牙 SIG 认证。 技术上走标准，只是不去 SIG 那边登记、交费。
前者是技术选型，后者是合规问题。很多讨论之所以吵不清楚，就是把这两件事混在了一起。下面先讲技术，认证放在后面。
设备接网关，大概有四种方式
| 方式 | 覆盖范围 | 设备数量 | 互通性 | 安全 | 开发量 |
|---|---|---|---|---|---|
| 私有广播协议 | 网关周围一圈，不能中继 | 理论上不限 | 只能和自家产品通 | 全部自己做 | 小 |
| BLE 直连（每个设备和网关建立连接） | 网关周围一圈 | 受网关同时连接数限制，通常十几个 | 一般 | 有标准加密 | 中 |
| 自研私有 Mesh | 可以中继 | 看实现 | 只能和自家产品通 | 全部自己做 | 很大 |
| SIG Mesh | 可以中继，整屋覆盖 | 几百个节点没问题 | 跨厂商互通 | 标准加密、防重放 | 中，大部分在芯片 SDK 里 |
私有广播协议最简单：网关想开灯，就广播一条命令，设备听到就执行。问题是没有中继，网关在客厅，卧室的灯可能就收不到了。配网、加密、防重放这些也都得自己设计、自己兜底。
BLE 直连是手机连蓝牙耳机那种方式。好处是有标准的加密，坏处是网关能同时保持的连接数有限，一个家里几十个开关和灯根本连不过来。
自研私有 Mesh等于把 SIG Mesh 重新发明一遍。中继风暴怎么控制、消息怎么去重、密钥怎么更新、序号怎么防重放，每一项都是坑。早年有不少厂商做过自己的私有 Mesh，后来大多转向了 SIG Mesh。
SIG Mesh 是蓝牙技术联盟定的标准。设备之间可以互相中继，覆盖整个房子；安全机制是现成的；更重要的是，它定义了一套标准的「设备模型」。
SIG Mesh 真正值钱的地方：标准模型
SIG Mesh 规定了开关、灯这些常见设备该怎么描述、怎么控制：
| SIG Mesh 模型 | 对应设备 | 在 Matter 里对应 |
|---|---|---|
| Generic OnOff | 开关、插座 | On/Off Light |
| Light Lightness | 调光灯 | Dimmable Light |
| Light CTL | 色温灯 | Color Temperature Light |
| Light HSL | 彩色灯 | Extended Color Light |
这张表对网关来说太重要了。Matter 也有一套几乎一一对应的设备类型，网关翻译起来非常直接。用私有协议的话，这层翻译就得自己定义一遍，以后每加一种设备都要改。
标准模型还带来两个好处：
- 网关和设备可以用不同厂商的芯片。 我们的网关用芯科的模组，设备用泰凌的芯片，两边只要都按标准模型来，就能互通。不会被某一家芯片厂绑死。
- 以后接其他生态更容易。 比如小米的蓝牙 Mesh 本身就是基于 SIG Mesh 的，灯、开关的产品模板用的也是这些标准模型。将来如果要出米家版，业务代码大部分能复用，主要换掉配网和认证那一层。
选了 SIG Mesh，要付出什么
SIG Mesh 不是没有代价，只是代价大多已经有人替你付了。
协议本身很复杂。 配网要做 ECDH 密钥交换，消息有网络层、传输层两层加密，还有分段重组、序号、IV Index。但这些都在芯片厂的 SDK 里，而且已经过了 SIG 的测试。设备端直接用 SDK，不要自己写。
网络规模有上限。 SIG Mesh 靠中继洪泛转发消息，同一片区域里节点越多，空中越拥挤。一般经验是一个网络控制在几百个节点以内表现比较好。商用照明动辄上千个点，就要按楼层、按区域拆成多个网络、多个网关。
网关能存的节点数也有限。 这一点很容易被忽略：
- 泰凌官方的网关固件，默认最多存 200 个节点，开启远程配网时是 110 个。一个四路开关算 1 个节点，不是 4 个。
- 用 Nordic 的 Zephyr 协议栈自己做网关，配置里默认只允许 8 个节点，防重放列表默认只有 10 条。不改的话，第 11 个设备发来的消息就会出问题。
家庭场景 200 个节点足够，但这些数字一定要在方案阶段就查清楚。
一个设备只能属于一个网络。 同一个灯不能既被我们的网关管，又被米家网关管。要两个生态都做，就得出两个版本，分别配网。
不做 SIG 认证行不行
回到开头那个问题的第二种含义：用了 SIG Mesh，但不做 SIG 认证。
技术上完全没影响，设备照常工作，和别家的 SIG Mesh 设备也能互通。风险在别的地方：
| 风险 | 说明 |
|---|---|
| 专利授权 | SIG 的专利授权只覆盖认证过的产品 |
| 销售渠道 | 亚马逊等平台、大型零售商、海外分销商经常要求提供蓝牙认证编号 |
| SIG 执法 | SIG 会给未认证的产品发通知，要求补认证或下架 |
| 商标 | 包装和宣传里不能用「Bluetooth」字样和蓝牙标志 |
还有一个常见误解：改回私有协议也省不掉 SIG 认证。 只要产品用了蓝牙，不管用不用 Mesh，上市销售都需要认证。不用 Mesh，只是少了 Mesh 那部分的测试。
好消息是，认证不一定要重新测试。直接用芯片厂已经认证过的协议栈，并且不改动其中已认证的部分，就可以引用对方的认证编号，只需提交声明、交费。开关、灯、无线开关如果蓝牙部分完全一样，还能合并成一个设计，只交一次费用。
另外要注意，SRRC、CE、FCC 这些无线电认证是法规强制的，和 SIG 认证是两回事，不做就不能合法销售。认证的费用和顺序，后面会单独写一篇。
网关这边，Mesh 放在哪里
设备端用芯片 SDK，这没什么争议。网关这边的 Mesh 协议栈放在哪里，其实也有三种做法：
| 做法 | 说明 | 优缺点 |
|---|---|---|
| 网关主程序自己实现 Mesh | 用 Linux 主板自带的蓝牙收发 Mesh 广播 | 少一颗芯片；但要自己写几千行协议栈、自己做认证测试 |
| 蓝牙模组当协处理器 | Mesh 协议栈跑在模组里，主程序通过串口发指令 | 协议栈现成、能引用厂商认证；多一颗模组 |
| 模组只当蓝牙控制器 | 模组跑标准 HCI，Mesh 跑在 Linux 上（比如 BlueZ） | 模组固件现成；但 Windows 上没法开发 |
我们选的是第二种：蓝牙模组当协处理器。Mesh 里最难、最需要认证背书的部分交给芯片厂，我们只负责串口指令和 Matter 翻译。哪家的模组更适合当协处理器，下一篇专门讲。
最后
回到「SIG Mesh 能不能不做」：
- 不用 SIG Mesh 协议：能做，但会失去中继、标准安全和跨厂商互通，而且省不掉蓝牙认证；
- 用 SIG Mesh 但不认证：功能不受影响，但出口、上电商、进大渠道基本都绕不开。
对我们来说，SIG Mesh 最大的价值不是「标准」两个字，而是那套和 Matter 几乎一一对应的设备模型。网关这一层的翻译因此变得简单，芯片也能自由选。
如果你的设备也还在用私有协议，正在纠结要不要迁到 SIG Mesh，或者已经在做蓝牙 Mesh 网关，欢迎来聊：linktr.ee/weiyii