无线传输标准协议怎么选：从链路预算到空口效率的工程账本

1. 从"信号格满格却丢包"说起：无线传输标准协议到底在解决什么

几年前接手一个仓储场景的采集项目，设备装完之后现场反馈"信号显示满格，但数据就是断断续续"。我带着笔记本去现场蹲了一整天，最后发现问题跟信号强度几乎没关系：货架之间的金属反射让同一个信道上挤了三十多个节点，物理层收得清清楚楚，链路层的确认帧却一直排不上队。那次经历让我对"无线传输标准协议"这七个字有了完全不一样的理解——它不是一份速率对照表，而是一套关于"谁在什么时候可以说话、说错了怎么办、说不上又怎么办"的仲裁规则。

很多人第一次接触无线传输标准协议，是从选型表开始的：几个协议摆在一起，速率、距离、功耗三列数字一比，挑个顺眼的。这种做法在实验室里能跑通，到了真实环境十有八九要返工。原因很朴素：速率那一栏是物理层的峰值，距离那一栏是理想视距下的理论值，功耗那一栏是芯片手册里的典型电流，三者都不包含协议自身的开销——帧头、确认、重传、退避、广播、入网握手，这些才是真正吃掉你预算的东西。

所以这篇文章我想换个角度写。不谈"哪个协议更好"，而是把无线传输标准协议拆成一份可以逐项核对的账本：它由哪几层组成，每一层各自承担什么责任，协议参数怎么换算成你现场能观测到的现象，选型时哪些约束是硬性的、哪些是可以商量的，以及自己写一套私有协议到底值不值。适合正在做硬件选型的产品同学、刚接手无线项目的固件工程师，也适合被"理论值"坑过一次、想搞清楚背后逻辑的人。读完你应该能做到两件事：拿到一份协议手册能看出门道，拿到一个现场需求能算出边界。

1.1 能被"看见"的速率和真正决定体验的指标

物理层速率和用户感知的吞吐之间，隔着一条很长的损耗链。假设某协议标称物理速率 150 Mbps，实际跑文件传输能到 60 Mbps 就算不错了。中间损失在哪？帧头与前导码开销、竞争窗口的退避等待、每帧必回的确认、丢包后的重传、上层协议的握手与窗口管理。高速率下这些开销占比还算可控，低速率场景就非常难看：一个 250 kbps 的低功耗链路，光是前导码加同步字就可能占掉整帧一半以上的空中时间。

我习惯用三个指标代替"速率"来做判断。第一个是有效吞吐，指应用层每秒真正拿到多少字节，通常只能做到物理速率的四到六成。第二个是空口占用率，指一个信道在一段时间内被成功传输占用的比例，这个数字超过三成，网络的时延抖动就会明显变大。第三个是重传率，正常环境应该在个位数百分比，超过一成基本可以判定存在干扰或覆盖不足。这三个数字都能从抓包和芯片计数器里读出来，比厂家给的速率表靠谱得多。

1.2 协议的本质是一份"冲突仲裁与错误恢复的合同"

把无线传输标准协议当成合同来理解，很多设计就顺了。空口是共享资源，所有节点都想说话，合同第一条规定的是介质访问规则：谁先听、听多久、听到忙怎么退、退多久再试。第二条是帧的格式，哪几位是地址、哪几位是长度、校验怎么算，这决定了不同厂家的设备能不能互相听懂。第三条是错误恢复，收到坏帧怎么办，没收到确认怎么办，重传几次放弃。第四条是状态机，从入网、鉴权、密钥协商到休眠唤醒，每一步允许的动作和超时。

这四条里，第一条最容易被低估。所有基于竞争的协议都有一个共同的软肋：节点越多，碰撞概率越高，退避窗口就得越长，有效吞吐随之下降。这里的规律大致是，在理想退避模型下，信道利用率会随着竞争节点数增加先上升后下降，峰值通常出现在几十个活跃节点附近。这也解释了一个常见困惑：十几台设备测得好好的方案，装到两百台的环境里就崩了——不是信号问题，是仲裁规则在节点规模上撞了墙。

判断一个协议适不适合你的项目，先问一句：它假设同时活跃的节点是多少？这个数字写在标准的适用范围里，也藏在退避窗口的参数里。超出这个数量级，加中继、分信道、改星型拓扑，比换天线有用得多。

1.3 互操作性才是标准协议真正的价值所在

私有协议在单项指标上经常吊打标准协议，延迟更低、开销更小、功耗更省。但标准协议卖的不是指标，是互操作。你买的模组、你同事手里的测试仪、第三方做的网关、几年后接手的运维团队，之所以能凑在一起工作，靠的就是大家都遵守同一份文档。这份文档的价值在你需要替换供应商、需要接入别人的平台、需要把设备送去目标市场做准入检测的时候才会集中兑现。

代价也很明显：标准协议要照顾所有人的需求，就必须留出大量可选字段和可配置参数，实现的复杂度上去了，开销也上去了。同一份标准，A 厂的实现和 B 厂的实现在极端场景下的表现可能差出一倍，因为标准只规定"必须做什么"，剩下"可以怎么做"的部分全靠各家自己发挥。我在实际项目里踩过好几次这种坑：协议文档上写着某个参数是可选的，两家模组一家开了、一家没开，联调时死活对不上，最后翻实现说明才发现问题。

2. 把协议拆成四本账：从电磁波到应用语义

一份完整的无线传输标准协议，纵向可以切成四段：物理层、链路层、网络与传输层、应用剖面。切开的目的是为了定位问题——现场出故障时，你能快速判断这次是电磁波不够、帧没收全、路由断了，还是应用层的数据模型对不上。不同层的问题，排查手段和修复成本差着数量级。

2.1 物理层：调制方式、带宽与灵敏度决定了下限

物理层管三件事：把比特变成波形、把波形变回比特、以及在什么条件下能变回来。决定这一层能力的核心参数是调制阶数、信道带宽、接收灵敏度三者。调制阶数越高，同样带宽下速率越快，但对抗噪声的能力越差；带宽越宽，速率越高，但单位频段上的功率被摊薄，灵敏度随之下降；灵敏度越低（数值越负），能收到的最小信号越弱，通信距离越远。

举个具体的换算。某低速模式带宽 125 kHz、扩频因子取较高档位，接收灵敏度可以做到 -137 dBm 左右，对应速率只有几百到几千比特每秒。同样一套射频，切到高速模式，灵敏度退到 -100 dBm 附近，速率能上到几十上百 kbps。这中间差着三十多 dB，换算成自由空间距离就是三十倍以上。所以"这个协议能传多远"这个问题本身没有答案，必须先问"你要多快"。

自由空间路径损耗的估算是基本功，公式是FSPL(dB) = 32.44 + 20log10(f_MHz) + 20log10(d_km)。2.4 GHz、100 米代入：32.44 + 67.6 - 20 = 80 dB。也就是说，这一百米的距离吃掉了 80 dB 的链路预算。如果你的发射功率是 0 dBm、天线增益 2 dBi、接收灵敏度 -95 dBm，可用预算只有 96.5 dB，扣掉 80 dB 还剩 16.5 dB 余量。这 16.5 dB 要用来扛穿墙损耗、人体遮挡、多径衰落和器件误差，室内场景穿一堵承重墙就要吃掉 10 到 15 dB。算完这笔账你就明白，为什么标称"室内 100 米"的设备，实际隔两堵墙就只剩十几米。

2.2 链路层：帧结构、确认机制与退避策略

链路层是我认为最值得细看的一层，因为它直接决定了空口效率。一帧数据从物理层发出去，实际占用空口的时间是：前导码 + 同步字 + 帧头 + 净荷 + 校验 + 帧间隔。净荷之外的固定开销通常在十几到三十几个字节，如果净荷只有 4 个字节的传感器读数，效率低到 10% 以下。这就是为什么低功耗协议普遍拼命压缩帧头，甚至把地址和功能位折叠进一个字节里。

确认机制的选择影响巨大。逐帧确认最可靠，但每个数据帧后面都要跟一个确认帧，一来一回空口时间翻倍；块确认可以批量确认，吞吐上去了，但丢一帧要重传一整块；无确认靠上层超时重传，空口最省，但端到端时延不可控。实际项目里我一般按数据性质分通道：控制指令走可靠确认，周期性传感器读数走无确认加序号去重。

退避策略是碰撞后的礼貌规则。主流做法是二进制指数退避：碰撞一次，退避窗口翻倍，随机等一段时间再试。这个机制在节点少的时候很高效，节点一多就会陷入"大家都在等、等完又一起冲"的循环。有些协议会引入载波侦听加随机化退避的组合，或者干脆改用时分调度，让网关统一分配时隙，把竞争变成预约。后者的代价是需要一个中心节点，网络变成星型，灵活性和自愈能力下降。

2.3 网络与传输层：拓扑形态决定了系统的天花板

拓扑这件事，选错一次基本等于重做。常见形态就那么几种：点对点、星型、树型、网状。点对点最简单，两端配对，没有路由问题；星型所有节点直连中心，中心扛全部并发，覆盖靠中心天线和功率堆；树型是星型的多级扩展，中间层做转发；网状让节点互相转发，覆盖和自愈最好，代价是路由开销和转发时延。

网状网络有个容易被忽略的容量上限。以洪泛式广播为例，一条消息要让全网知道，每个节点都要转发一次，空口总占用是节点数的线性函数。100 个节点、单次转发占用 5 毫秒，一条广播就要 500 毫秒的空口时间。如果网络里还有周期性的路由维护广播，实际可用带宽会被吃掉一大块。所以洪泛式网状网络的舒适区通常在几十到一两百个节点，超过这个规模就得分簇、上路由表、或者改成以网关为中心的多信道架构。

一个实用的判断方法：先估算你每秒需要多少条消息、每条消息转发几次、每次占用多少空口时间，三者相乘再除以信道总容量，得到的就是理论占用率。超过 20% 就该考虑分信道或换拓扑了，留余量不是为了保守，是给重传和突发留活路。

传输层这块，短距物联网协议大多不自带端到端可靠传输，靠应用层自己做序号、超时、去重。这看起来原始，实际上是有意为之：端到端重传在无线环境里效率很低，中间任何一跳丢了都要从头来，不如让每一跳各自负责可靠，端到端只做幂等去重。

2.4 应用剖面：配网、数据模型与升级才是落地门槛

协议文档最后一章往往是应用剖面，讲数据怎么组织、设备怎么描述自己、状态怎么上报。这一层看着不涉及射频，实际是项目延期的高发区。配网流程尤其典型：按一下按钮进配对模式、扫码带参数入网、靠手机中转、还是出厂预置密钥，每种方式对应不同的产线工序和用户操作成本。我见过一个项目硬件和协议都定完了，卡在配网方式上反复了两个月，因为产线没有扫码工位、用户又不愿意拆开外壳按键。

数据模型的设计也有讲究。把每个传感器做成一个独立属性、还是打包成一个结构体上报，直接影响帧长和空口开销。属性化设计灵活，便于平台侧做通用解析，但帧头开销大；打包设计省空口，但扩展性差，加一个字段就要改所有端的解析逻辑。我的经验是：变化频率低、字段固定的数据打包上报；需要远程配置、状态可查询的维度走属性化。

固件升级是另一个大坑。无线升级对空口占用极大，一次几百 KB 的镜像，在 250 kbps 的链路上传完要好几个小时，期间网络基本处于半瘫痪状态。可行的做法是分片、限速、断点续传，并且把升级窗口放在业务低谷期，同时保证升级失败能回滚。这些能力协议标准里通常只给框架，具体实现得自己补。

3. 六类主流协议族的真实能力边界

市面上常见的无线传输标准协议，按能力和用途大致可以归成几类。下面这张表是我自己整理的口径，数字取的是各类协议的典型区间，不是某一款具体产品的规格，实际选型时仍要以器件手册为准。

3.1 高速无线局域类：能力最强，也最挑环境

这一类协议的物理层用了正交频分复用和更高阶调制，配合多天线技术，速率能拉到很高。它的优势不只是快，还有成熟的网络管理、安全机制和漫游能力，接入现有网络基础设施几乎零成本。缺点同样明显：功耗高、信道带宽宽、对干扰敏感、竞争机制在密集部署下效率下降很快。

工程上用这类协议，关键不在速率而在信道规划。2.4 GHz 频段总共只有八十多兆赫兹可用，信道之间还大量重叠，真正能同时使用而不互相干扰的只有三个。部署超过三个热点，就必须在平面图上做蜂窝式排布，控制单点功率，让相邻热点落在不同信道。5 GHz 频段信道多得多，代价是穿透损耗更大、覆盖半径更小，隔墙衰减比 2.4 GHz 高出好几个 dB。

功耗方面要有清醒预期：这类协议的接收窗口很长，即使挂着不发数据，维持连接也要持续消耗毫安级电流。用它做电池设备基本不现实，除非做极端的占空比控制，而那又违背了它"随时在线"的设计初衷。

3.2 低功耗短距类：把"省"做到了极致

这一类协议的设计哲学完全是另一套：牺牲速率和连接灵活性，换取极低的平均电流。它的广播机制很有意思，设备可以只发不收，用几十微秒的广播包把数据甩出去，然后立刻睡回去；需要交互的时候再建立短连接，传完就断。这套机制让平均电流能压到几十微安甚至更低。

广播信道的设计也值得说一句。为了抗干扰，这类协议通常把广播信道分散在三个特定频点上，并且每次广播在三个频点轮流发送，接收方扫描时只要对上其中一个就能收到。这个设计巧妙地绕开了 2.4 GHz 频段最拥塞的区域，代价是广播包不能太大，单包净荷通常被限制在三十字节以内。

实际用起来最大的坑是连接参数。连接间隔、从机延迟、监督超时这几个参数互相牵制，设得太激进省电但容易断连，设得太保守稳定但功耗上去了。我的经验值：需要交互的设备连接间隔设在几十毫秒量级，纯上报的设备直接走广播不建连接，能省一个数量级的电。

3.3 扩频低功耗广域与窄带蜂窝：距离换速率

这两类协议解决的是同一个问题：几公里范围内、极低数据量、电池供电、几年不换电池。技术路线上，一类用扩频把信号淹没在噪声底下，靠处理增益换取灵敏度；一类用窄带加上重复传输，靠时间和功率换覆盖增强。

扩频这类协议最迷人的地方是链路预算能到 150 dB 以上。换算成自由空间距离，Sub-GHz 频段下视距可以到十几公里。代价是速率极低，扩频因子调高一档，速率减半，空中时间翻倍。所以它的参数配置本质是在做权衡：扩频因子越高越远越慢，带宽越宽越快越不灵敏。我一般按场景定：城市密集区用较低扩频因子换速率和容量，郊区农场用较高扩频因子换覆盖。

窄带蜂窝类的优势是频谱干净、干扰可控、覆盖有保障，不用自己规划频点。它的省电模式设计得很细，设备可以长时间不监听网络，只在约定的窗口醒来。代价是每次唤醒都有一次网络交互的固定开销，唤醒太频繁反而费电，而且链路建立时延可能到秒级甚至更长。

这两类协议共同的软肋是下行。上行数据可以很长很省电，下行必须等设备醒来才能送达，所以远程配置、远程升级这类操作体验都很差。设计产品时要把这一点考虑进去，不要假设"随时能下发指令"。

3.4 Sub-GHz 私有星型与网状自组网：成本与灵活性的两端

Sub-GHz 私有星型协议是成本敏感型项目的常客。芯片便宜、外围简单、协议栈可以自己精简到几 KB，很多遥控、门磁、简单传感器用的都是这类方案。它的短板是缺乏统一的互操作标准，不同厂家的东西只能各玩各的，而且抗干扰能力完全取决于你自己的实现水平。

网状自组网类的价值在覆盖扩展和自愈。一栋楼里几百个灯，靠单个网关覆盖不了，让每个灯兼做转发节点，网络自然就铺开了。这类协议的关键参数是路由维护的频率和跳数上限，跳数越多覆盖越大，时延和空口开销也越大。实际项目里我一般把跳数限制在三到五跳，再远就加网关。

网状网络的调试体验不太友好：问题往往不是"通不了"，而是"时通时不通"，路由表在后台悄悄变化，你今天测好的路径明天就换了。排查这类问题必须有网络拓扑的可视化工具，能看到每个节点的父节点、路由代价、最近一次通信时间。没有这套工具，调试基本靠猜。

4. 选型不看参数表，看五个约束条件

前面把协议拆完了，现在说选型。我的做法是先不看协议，先把自己的需求写成五个约束，然后拿这五个约束去筛协议，剩下的再比价格和生态。

4.1 距离约束：先算链路预算，再谈覆盖

链路预算的算法很直接：可用裕量 = 发射功率 + 天线增益 - 线损 - 接收灵敏度。所有量都用 dBm 或 dBi，加减就行。算出来的裕量要覆盖三部分：自由空间损耗、环境附加损耗、衰落余量。

环境附加损耗靠经验取值：开阔视距接近 0；办公室隔一堵轻质墙 10 到 15 dB；仓库货架密集区 15 到 25 dB；金属货架加设备密集再加 10 dB；地下室或混凝土结构 25 dB 以上。衰落余量室内一般留 10 到 15 dB，工业环境留 15 到 20 dB。

举个我实际调过的例子：发射 10 dBm、天线 2 dBi、线损 1 dB、灵敏度 -105 dBm，裕量是 116 dB。目标是在仓库里隔两堵墙传 50 米。50 米 2.4 GHz 自由空间损耗约32.44 + 67.6 - 26 = 74 dB，两堵墙按 25 dB 算，剩 17 dB 做衰落余量，勉强够用但没有任何冗余。后来我们把天线换成带增益的定向天线，裕量提到 125 dB，现场才稳定下来。

4.2 功耗约束：从平均电流倒推电池寿命

功耗不能看工作电流，要看平均电流。算法是：平均电流 = Σ(各状态电流 × 该状态时长) / 上报周期。以每 10 秒上报一次、单次通信 3 毫秒、发射电流 30 毫安、睡眠电流 2 微安为例：

• 发射段贡献：30 mA × 3 ms = 90 µA·s，摊到 10 秒周期是9 µA
• 睡眠段贡献：2 µA × 9.997 s / 10 s ≈ 2 µA
• 平均电流约11 µA

2000 毫安时的电池，理论寿命2000 / 0.011 ≈ 181818 小时 ≈ 20 年。听起来很美好，实际要打三到四折：电池自放电、低温容量衰减、电容充电的浪涌、唤醒时的时钟稳定时间、以及最容易被忽略的漏电流——PCB 上的助焊剂残留和潮气能让睡眠电流从 2 微安变成 50 微安，直接把寿命砍掉一个数量级。

功耗预算做完之后，务必实测一遍睡眠电流。我习惯在样品阶段用高精度源表测整机的关断电流，超过 10 微安就要查板子，别急着怪协议。

4.3 规模约束：节点数超过多少就该换架构

规模约束有两个维度：单网关能带多少节点，以及网络里同时活跃的节点有多少。前者受地址空间和网关处理能力限制，后者受空口仲裁效率限制。

算法很简单：先算单个节点每次通信占用的空口时间T，乘以节点数N，再除以上报周期P，得到占用率U = N × T / P。以上面那组数据为例，N = 100、T = 5 ms、P = 5 s，U = 100 × 5 / 5000 = 10%。看着还行，但这是理想值，实际要加上重传和广播开销，翻一倍到 20%，再留点余量，基本就到这类星型架构的上限了。

节点数再多，出路只有三条：拉长上报周期、增加信道并行、改成分簇多网关。三条路各有代价，第一条影响数据时效，第二条需要多套射频，第三条增加系统复杂度。没有哪个方案是免费的。

4.4 时延约束：确定性比平均值更重要

很多需求文档写的是"时延小于 1 秒"，这个描述太粗。要区分平均时延和尾部时延。竞争式协议的平均时延可能只有几十毫秒，但 99 分位的时延可能是几百毫秒甚至上秒，因为碰撞后退避窗口会指数增长。对控制类应用，尾部时延才是真正要命的指标。

需要确定性时延的场景，就要往调度式协议上靠：时分多址、时隙预约、或者带优先级的通道。代价是需要中心节点统一授时，网络规模受限，灵活性下降。我一般会问一句：如果这条指令晚到 500 毫秒，业务上会不会出事？会，就往确定性方案走；不会，就接受竞争式的灵活性。

4.5 共存约束：频谱环境比协议本身更重要

最后一个约束经常被完全忽略：你打算用的频段，现场已经有多少人在用。2.4 GHz 是全球最拥挤的免许可频段，微波炉、无线鼠标、安防摄像头、邻居家的路由器全在里面。把关键业务放在这个频段，等于把命运交给别人。

共存问题的解法有几个：换频段（Sub-GHz 相对干净，但天线尺寸大、速率低）、限功率（减小自己的干扰范围，也减小被干扰的概率）、跳频（在多个频点间快速切换，避开固定干扰）、以及物理隔离（把网关和干扰源拉开距离，哪怕两三米也有明显效果）。

实测经验：2.4 GHz 的干扰往往有强烈的方向性和时间规律。我遇到过一次，某片区域的设备每天下午三点到五点集中掉线，最后发现是隔壁的作业区在那个时段启用了一批设备。改用 Sub-GHz 之后问题消失。这类问题在实验室里永远复现不出来。

5. 用可控实验验证协议扛不扛得住

协议选型和参数配完了，接下来是验证。我不太相信"跑通 Demo"这种结论，因为 Demo 通常是在最理想的条件下跑出来的。真正有价值的是三组基线测试加上现场踏勘。

5.1 实验室里的三组基线测试

第一组：纯吞吐与空口效率。固定距离、固定信道、无干扰源，让一个节点持续发包，另一个节点收，统计应用层有效吞吐和空口占用率。这组测试的目的是拿到你这套方案的"最好成绩"，后面所有现场数据都跟它对比。测试时要注意把净荷长度扫一遍，从最小包到最大包各测一轮，你会发现吞吐随包长变化很大，小包场景下的效率可能只有大包的三分之一。

第二组：干扰敏感性。在旁边开一个持续工作的干扰源，可以是同频段的另一个设备，也可以是宽带噪声发生器，然后逐步拉近干扰源距离，记录重传率和丢包率的变化曲线。这组测试能告诉你系统的抗干扰余量有多大。我一般会测到丢包率超过 20% 为止，那个距离就是你的"干扰崩溃点"，实际部署时要保证设备离干扰源比这个距离更远。

第三组：规模与并发。这一组最费事但最有价值。用十几台设备同时上电，逐渐增加到设计规模，观察入网时间、重传率、时延分布的变化。很多问题只在这个阶段暴露：入网风暴、地址冲突、路由震荡、网关队列溢出。测试时一定要抓包，把整个过程录下来，出问题的时候回放比现场猜快得多。

5.2 现场踏勘要记录什么

现场踏勘不是拿个手机走一圈看看信号格数，那东西参考价值接近于零。我带的清单是这样的：

背景噪声底这个指标特别有用。理论上 2.4 GHz 频段的噪声底应该在 -100 dBm 以下，如果现场测出来是 -85 dBm，说明有强干扰源在附近，链路预算里必须扣掉这 15 dB。我有一次在配电房附近测到 -70 dBm 的噪声底，换什么协议都没用，最后只能把网关挪位置。

5.3 数据怎么读：三个关键判据

拿到测试数据之后，怎么判断"行"还是"不行"？我用三个判据。

判据一：重传率。干净环境下应该在 2% 以内，工业现场控制在 5% 以内可以接受，超过 10% 说明链路质量有问题，先解决干扰再谈其他。重传率高但信号强度也高，通常是干扰；信号强度低且重传率高，是覆盖不足。

判据二：时延的 P95 与 P50 之比。这个比值反映网络的稳定性。比值在 2 以内，说明时延比较集中；比值超过 5，说明存在明显的长尾，可能是碰撞退避或者路由切换导致的。长尾严重的网络，平均时延再漂亮也不能用在控制场景。

判据三：空口占用率的余量。把实测占用率乘以 2，如果还低于 40%，说明这个网络还有扩容空间；乘 2 之后超过 60%，就该考虑分信道或者减少节点了。留余量的逻辑是：现场环境会变，人多了、设备多了、隔壁新装了东西，都会让占用率上升。

6. 踩过的坑：从天线到认证的那些意外

技术层面讲完了，说点文档里不会写的。下面这些坑我都实打实踩过，每一个都让我付出了几天到几周的代价。

6.1 天线和外壳：最容易被当成"玄学"的部分

第一个项目我把天线贴在外壳内侧，实测距离只有标称的三分之一。排查了两天才发现外壳的喷漆里含金属成分，等于给天线罩了个屏蔽罩。后来改成外壳开窗加非金属盖板，距离立刻恢复。这件事之后我养成一个习惯：天线周围 10 毫米内不允许有任何金属，包括螺丝、屏蔽罩、电池、甚至走线。

天线方向性也常被忽略。板载天线大多有明确的辐射方向图，正上方最强，侧面和背面衰减十几 dB。设备安装方向一旦和设计预期不符，覆盖就会差一大截。我在一个壁挂式产品上吃过这个亏：设计时假设天线朝外，实际安装工人为了走线方便把设备转了 90 度，结果整面墙的信号都不行。

还有一个隐蔽问题：人体遮挡。2.4 GHz 频段下水对人的衰减可以到 10 到 20 dB，取决于姿势和距离。可穿戴设备贴着身体用，链路预算里必须预留这块损耗。我做过一个手环类项目，戴在手腕上时信号比放在桌上低了 15 dB，原因就是手臂挡住了辐射方向。

6.2 2.4 GHz 拥塞：不是你的问题，但你要负责

有一次客户投诉说设备每天上午十点左右集体掉线，我去现场蹲了三天，发现那个时间段保洁会推着设备经过一片区域，设备上有无线设备在工作。这个案例的教训是：在现场，你的协议要跟所有你看不见的东西共存。

应对思路有几条。降低发射功率反而可能提升稳定性，因为功率低了自己受干扰的范围也小，而且减少了对他人的干扰，整体环境更友好。开启跳频或自适应信道选择，让设备主动避开脏频点。把网关的天线抬高或外置，物理上拉近距离。最后一条最有效也最容易被忽略：给关键链路留出重传余量，让偶发干扰不至于造成业务中断。

6.3 认证与准入：别等产品定型才想起它

无线电产品进目标市场前要通过当地的准入检测，涉及频段、功率、带宽、杂散发射等一堆指标。这些要求会反过来约束你的技术方案：某些频段的发射功率上限很低，某些调制方式不允许使用，某些占空比有硬性限制。

我见过一个项目，硬件和固件全做完了，送去检测才发现最大发射功率超了 3 dB，只能改射频前端重新打板。这件事的教训很直白：选型阶段就把目标市场的准入要求拉出来看一眼，特别是功率上限和占空比限制这两项，它们直接决定你的链路预算和功耗预算。

认证周期也要算进项目计划。从送样到拿证，顺利的话几周，遇到指标不过要整改，可能拖几个月。产品发布节点卡得紧的话，提前把这块排进去。

6.4 版本漂移：协议栈升级带来的兼容性事故

标准协议本身在演进，芯片厂商的协议栈也在打补丁。这两个变量叠在一起，很容易出兼容性问题。我们遇到过一次：网关固件升级后，一批老设备连不上了。查下来是新版本对某个可选字段的解析变严格了，老设备发的帧里那个字段填的是保留值，以前被忽略，现在被当成非法帧丢弃。

这类问题的防御手段是版本协商加灰度。设备入网时上报固件版本和协议版本，网关按版本走不同的解析分支；升级时分批推，先升一小批观察，确认无异常再全量。另外，协议栈的升级说明一定要读，特别是标注了"行为变更"的那些条目，往往就是坑所在。

7. 什么时候该自研私有协议

聊到这儿，肯定有人会问：标准协议这么多限制，我能不能自己写一套？答案是能，但要先想清楚代价。

7.1 标准协议覆盖不到的三类场景

自研协议真正合理的场景，我见过三类。第一类是极致的开销压缩：净荷只有几个字节、节点数量巨大、上报频率极高，标准协议的帧头开销占比太大，自己设计的紧凑帧能把效率提升好几倍。第二类是极致的时延确定性：工业控制里的同步采样，要求全网节点在微秒级对齐，标准协议的竞争机制满足不了，必须自己设计时隙调度。第三类是封闭系统：所有设备都是自己生产、自己维护、不需要和外界互通，互操作性带来的成本没有任何回报。

除此之外的场景，自研基本都是亏的。你省下的那点开销，会在调试、维护、人员交接、器件替换上成倍还回去。

7.2 自研的最小可行设计

如果确定要自研，别一上来就设计一个完整协议栈。最小可行的做法是只替换链路层，物理层直接用现成的射频芯片和它的调制解调能力，网络层以上能复用就复用。

链路层最小设计需要包含四样东西：帧同步（前导码加同步字，保证接收方能找到帧头）、长度与校验（防止把噪声当数据）、地址与序号（区分设备、去重）、确认与重传（保证可靠性）。四样之外的东西都可以后加。我见过有人一上来就设计路由、加密、分片、QoS，结果半年过去连点对点都跑不稳。

参数设计上有一条经验：帧越短越好，短帧的抗干扰能力和碰撞成功率都更高。宁可用多个短帧拼一条长消息，也不要发一个长帧。另外，把最关键的字段放在帧头附近，这样即使后半段被干扰，接收方至少知道这是谁发的、要干什么。

7.3 自研的长期成本账

最后算一笔账。自研协议的成本不止在开发阶段，更大的开销在后面：新人接手的学习成本、出问题时的排查成本、器件换代时的移植成本、以及最隐蔽的一项——你自己会成为唯一的专家，所有疑难问题最后都会汇总到你这里。

我的判断标准是这样的：如果这个项目生命周期短于两年、团队规模小于三人、设备数量少于一千台，自研要慎之又慎；如果项目要跑五年以上、设备上万台、有稳定的团队维护，并且标准协议确实在核心指标上卡住了你，那自研才值得认真考虑。

实际项目里更常见的做法是混合：核心链路上用标准协议保证互通和生态，在标准协议的扩展字段或者应用层里做自己的优化。这样既拿到了标准协议的底子，又保留了自己调优的空间。我在几个项目里都是这么干的，效果比纯自研稳，也比纯标准灵活。

我个人在这些年项目里最大的体会是，无线传输标准协议的选择从来不是技术问题，而是约束条件下的权衡问题。把距离、功耗、规模、时延、共存这五个约束写清楚，把账算明白，答案往往会自己浮出来。真正让人返工的，通常不是选错了协议，而是压根没算过账。