协议栈选型：主流无线协议栈的OTA能力对比与选型依据

做物联网产品，选无线协议栈就像选房子——地段、户型、预算都得看。OTA升级能力更是关键中的关键。我见过太多项目，硬件做完了才发现协议栈不支持差分升级，或者功耗高得离谱。今天咱们就掰开揉碎，把BLE、Wi-Fi、Zigbee、Thread这四家的OTA底牌翻个底朝天。

一、四大协议栈OTA能力速览

先给个全景图。我习惯把OTA能力拆成三个维度：传输带宽、升级可靠性、功耗开销。下面这张表是我自己整理的，项目选型时直接拿来用。

协议栈	典型速率	单包最大载荷	OTA方式	差分升级支持	升级功耗
BLE 5.x	1~2 Mbps	251 bytes	GATT通知/写入	需应用层实现	低（mA级）
Wi-Fi 4/6	10~100 Mbps	1500 bytes	HTTP/MQTT/TCP	原生支持	高（百mA级）
Zigbee 3.0	250 kbps	127 bytes	APS数据帧	需应用层实现	低（mA级）
Thread	250 kbps	127 bytes	CoAP/UDP	需应用层实现	低（mA级）

二、BLE OTA：小而美的升级方案

BLE是我用得最多的协议栈。它的OTA设计很巧妙——利用GATT服务的Notify和Write特性，把固件切成小包，一包一包往上捅。

我记得有个智能门锁项目，客户要求升级时不能中断蓝牙连接。我踩过一个坑：MTU协商没做，默认23字节的MTU，实际有效载荷才20字节。升级128KB的固件，要传6500多包，用户体验极差。

BLE的差分升级需要自己实现。我一般用bsdiff算法，在手机端做差分，MCU端做合并。注意，差分算法对RAM有要求——至少需要固件大小1.5倍的RAM。如果MCU只有32KB RAM，就别想差分升级了。

三、Wi-Fi OTA：快，但代价不小

Wi-Fi的OTA能力是最强的。直接走HTTP下载，支持断点续传、差分升级、多版本管理。我做过一个智能摄像头项目，固件有4MB，用Wi-Fi OTA，30秒搞定。

但代价也很明显——功耗高。Wi-Fi模块在OTA期间，平均电流150~300mA。如果是电池供电的设备，一次升级可能吃掉10%的电量。

Wi-Fi OTA的另一个坑是安全证书管理。HTTPS下载需要预置CA证书，证书过期了怎么办？我建议用固件签名+明文传输的方式，既保证安全，又避免证书管理麻烦。

四、Zigbee OTA：Mesh网络的升级难题

Zigbee的OTA标准叫OTA Upgrade Cluster，是ZCL（Zigbee Cluster Library）的一部分。它定义了升级服务器、升级客户端、镜像通知、镜像块请求等完整流程。

但实际用起来，问题不少。Zigbee的单包只有127字节，去掉协议头，有效载荷不到100字节。升级一个256KB的固件，要传2600多包。而且Zigbee是Mesh网络，多跳传输时，每跳都会增加延迟和丢包率。

我做过一个智能照明项目，50个灯组成Mesh网络。升级时，离网关近的灯10分钟搞定，离网关远的灯要1个多小时。为什么？因为中间节点要转发数据包，转发优先级又低，经常被业务数据挤掉。

五、Thread OTA：基于CoAP的轻量级方案

Thread的OTA基于CoAP协议，走UDP传输。它的设计思路和Zigbee类似，但更灵活——CoAP支持观察模式、块传输、重传机制。

Thread的OTA标准叫Thread OTA Service，定义了固件分发、版本管理、回滚等接口。我比较喜欢它的多播升级能力——一次发送，所有节点都能收到，适合批量升级场景。

但Thread也有短板：生态不成熟。市面上支持Thread OTA的芯片和SDK不多，很多需要自己实现应用层逻辑。我去年做一个智能家居项目，Thread的OTA部分花了3个月才调通。

六、选型决策框架

说了这么多，到底怎么选？我总结了一个决策框架，用SVG画出来，方便你对照。

七、我的选型清单

最后，给一份我实际项目中的选型清单。每次做新项目，我都会过一遍这个清单，基本不会踩大坑。

1. 功耗预算：OTA期间平均电流不能超过多少？电池容量够支撑几次完整升级？
2. 固件大小：超过512KB，优先考虑Wi-Fi或差分升级；小于256KB，BLE/Zigbee都行。
3. 网络拓扑：星型网络用BLE或Wi-Fi；Mesh网络用Zigbee或Thread。
4. 升级频率：一年升级一次，选什么都行；一个月升级一次，必须考虑差分升级。
5. 安全要求：需要加密传输？需要签名验证？Wi-Fi的TLS最成熟，BLE的加密最轻量。
6. 回滚能力：升级失败后，能不能自动回滚？Zigbee和Thread的标准OTA都支持，BLE需要自己实现。