1. 项目背景LoRa 自组网到底卡在哪LoRa 自组网这个事圈子里吵了很久了。有人一上来就问“用洪泛还是用路由”也有人直接丢一句“干脆上 LoRaWAN 得了”。我最早做 LoRa 的时候也犯过难明明射频芯片选型差不多PA 功率也差不离为什么别人做出来的网络那么稳我做出来的一下雨就丢包、一动就断链后来才明白问题根本不在硬件而在你选择了哪条“网络路线”去组织这些节点。先说清楚一个概念LoRa 本身只是物理层的一种调制方式它解决的是“点对点能不能传”的问题并不负责“数据怎么绕路到达目的地”。所谓自组网是在 LoRa 之上额外搭建的一套传输组织逻辑。这就出现了三条公认的技术路线洪泛、路由、网络栈。三者不是简单的版本迭代而是在“网络容量、实时性、功耗、部署复杂度”这四个维度上做了完全不同的取舍。这篇文章我会把我们实测过的三套方案全部摊开原理层面怎么理解、代码和参数层面怎么落、实测数据到底差多少、还有哪些坑是文档里绝不会写的。如果你正要做一个 LoRa 传感网项目或者已经在为网络不稳定掉头发这篇应该能帮你少走不少弯路。需要说明的是文中的测试数据来自我在城市小区、郊野公园两种场景下的实测结果硬件平台以 SX1268 433MHz / SX1276 470MHz 为主环境不同结论可能略有差异但取舍逻辑是通用的。2. 路线拆解从“无脑广播”到“分层协议栈”2.1 洪泛最原始的自组织逻辑洪泛的意思一句话就能说明白节点收到一包数据如果它不是给自己的就直接转发出去。这种方式最大的优势是几乎没有组网开销不需要维护路由表也不需要知道网络的拓扑结构任何一个节点进入网络就能立刻干活。它的代价也同样明显——广播风暴。在一个 10 个节点的网络里一包数据会被反复复制转发多次信道占用呈指数级增长。我最早用纯洪泛做过一个 30 节点的温湿度采集网在每 10 秒上报一次的情况下实测信道冲突率接近 40%网关收到的重复包占了有效负载的一半以上。这是因为 LoRa 是半双工的一个节点在发射的时候会占住整个信道一旦大量节点同时转发冲突就不可避免。但洪泛有一个门道LoRa 的每个包天然携带 RSSI接收信号强度指示值和 SNR信噪比。你完全可以在转发逻辑里加上“弱信号不转发”的规则让只有信号足够好的节点才参与转发。这么做能把参与转发的节点数量砍掉一半以上同时又不破坏洪泛的“免组网”特性。实际做的时候RSSI 阈值不是拍脑袋设的而是要在部署区域里拿几个节点实测信号分布再拿中位数做基准。2.2 路由从“所有人都转发”到“有人探路”路由路线的本质是把“广播”换成“单播”。先通过一种发现机制把路径找出来之后节点就沿着这条路径精确转发不再需要全网广播。LoRa 自组网里常见的路由协议有 AODV、DSR 和 RPL 这几类我三个都试过最推荐从 AODV 入手它对动态拓扑的适应能力比较均衡实现上也相对成熟。AODV 的逻辑不复杂源节点发一个 RREQ路由请求广播出去中间节点收到后先记录“我是从哪个邻居听到这个请求的”再继续转发当 RREQ 到达目标节点后目标节点沿着记录的路径回一个 RREP路由回复源节点就有了完整的路径。听起来干净利落但放到 LoRa 上有个现实问题LoRa 的速率太低了SF10、带宽 125kHz 时有效速率可能只有几百 bps一个 RREQ 包本身就要占几十毫秒的空中时间等整个路径建立起来可能已经过了好几秒。这就带出一个很关键的设计取舍路由发现不能像 WiFi 那样频繁做而应该是一次建立、长期复用只有当路径断了才重新发起发现。我们实际工程里把路由表老化时间设成了 30 分钟只有当连续 3 次数据包无 ACK 才触发重寻路。这个参数比协议本身更影响网络稳定性必须根据你数据的采集频率动态调整。2.3 网络栈把传统网络的层次思维搬进来网络栈这条路跟前两者最大的区别是它不再把“网络层”和“链路层”混在一起而是像 TCP/IP 那样分层处理。在 LoRa 自组网里常见的做法是参考 IEEE 802.15.4e 的 TSCH时隙跳频思想把时间切成固定时隙每个节点在专属的时隙里发送数据其他时间休眠同时在物理信道之间跳频避开干扰。分层带来的直接好处是可控性。你可以用底层时隙机制保证不冲突用上层的 mesh 路由保证路径冗余再用传输层的分片重组解决 LoRa 单包长度有限的问题。坏处也显而易见协议栈复杂度上来了开发和调试成本成倍增加。LoRaWAN 本身就是一个分层协议栈但它依赖中心化的网关自组网场景下你需要的是一个去中心化但又有分层的栈。我们最后用的是基于 LoRaMesh 改造的方案在应用层之上叠加了自己的信令协议才勉强达到了生产可用的水平。每一条路线都不是银弹。选型时你需要先回答一个问题网络的规模预期是多少20 个节点以内洪泛完全够用20 到 100 个节点路由是性价比最高的选择100 个节点以上还要考虑多跳实时性那网络栈几乎是绕不开的。3. 一步一坑三条路线的落地方案与参数细节3.1 洪泛方案落地的三个关键参数洪泛方案的工程实现其实只有三个参数需要重点调最大跳数、RSSI 转发阈值、重传抑制时间。最大跳数直接限制了广播风暴的半径比如一个覆盖半径 500 米的网络每一跳按 200 米算那最大跳数设成 3 就够了再多就是白白浪费信道。RSSI 转发阈值的作用前面提过它决定了哪些节点有资格转发重传抑制时间则是让收到重复包的节点在一定时间内忽略相同来源的包避免立即二次转发。我踩过最大的坑是重传抑制时间。一开始设了 500ms结果在一个多跳链路的场景里下游节点收到数据后要等 500ms 才允许转发整条链路的时延直接拉到了秒级数据实时性彻底没戏。后来改成了 100ms同时配合“包 ID 源地址”去重时延降到了 300ms 以内而且没有出现明显的重复包爆炸。在实际测试中还发现一个反常识的现象降低发射功率反而能提升洪泛网络的吞吐量。因为洪泛网络里真正的瓶颈是信道冲突而不只是覆盖距离。把 SF 从 10 降到了 7单包空中时间从 300ms 左右降到了 50ms 以下虽然单跳距离缩短了但在多跳接力模式下单位时间内整个网络能发出的数据量反而上去了。如果你的网络节点密度够大不妨试试用低 SF 换吞吐。3.2 AODV 路由在 LoRa 上的改造要点LoRa 上跑 AODV 不能拿现成的 Linux 实现直接搬必须针对射频特性做改造。我做的第一版是用标准的 AODV结果一个 15 节点的链式拓扑里路由发现过程占了整个通信周期的一半节点大部分时间都在“找路”真正传数据的时间被压缩到了可怜的地步。改造方向有三点。第一把 RREQ 重试次数从默认的 3 次降到 2 次因为 LoRa 一个 RREQ 广播的空中时间可能长达几百毫秒重试太频繁会导致信道拥塞。第二在 RREP 里携带 RSSI 信息让源节点可以同时评估路径的“连通性”而不是只看跳数。第三把路由表容量限制在 16 条以内超过就按最久未使用原则淘汰。LoRa 节点的内存通常只有几十 KB路由表膨胀会直接挤占通信缓冲区导致大量丢包。路由建立之后的稳定性也值得关注。我们把每条路由的 ACK 间隔压到了 15 秒也就是说 15 秒内没有收到下一跳的 ACK就判定这条路断了立即启动局部修复而不是直接从头做全网路由发现。这个优化让链式拓扑的断线恢复时间从 6 秒降到了 2 秒左右体感提升非常明显。3.3 TSCH 风格网络栈的搭建思路网络栈方案的门槛最高但天花板也最高。我们实现的是一个简化版 TSCH先把时间划分为定长的周期帧例如 2 秒一个周期每个周期内分成 50 个时隙每个时隙 40ms每个节点在分配到的时隙里发射在非发射时隙里接收或休眠。这种机制从根本上消除了同频干扰带来的随机冲突因为每个发射行为都发生在约定好的时间窗口内。搭建的时候要特别注意“时钟漂移”问题。LoRa 节点用的晶振精度一般是 20ppm 左右两个节点间的时钟漂移累积起来会导致时隙错位。所以我们必须在每个超帧里留出一个“维护窗口”所有节点在窗口内广播自己的绝对帧号其他节点收到后校准本地时钟。这个维护窗口不能省一旦省了跑 24 小时后整个网络就会出现严重的时隙偏移。网络栈方案另一个加分项是它能天然支持“低功耗侦听”。节点绝大部分时间处于休眠状态只有在自己时隙前几毫秒才唤醒接收。实测下来一个 5 分钟上报一次的节点休眠电流能做到 10uA 以下平均功耗比洪泛方案低了近 50 倍。这也是为什么在电池供电和节点数多的场景下网络栈是唯一能长期自持的方案。4. 量化对比三套方案的实测数据与结论为了把争议变成数据我在同一块场地上、同一批硬件里分别跑了三套方案。硬件统一用 STM32L0 SX1268发射功率固定 22dBm天线高度 1.5 米场景一个是城市小区建筑密集多径明显一个是郊野公园地势开阔遮挡少。每个方案部署 25 个节点模拟多跳场景网关位于中心位置数据上报周期统一设为 30 秒。4.1 关键指标实测结果指标纯洪泛AODV 路由TSCH 网络栈组网时间25 节点即时无需组网8~12 秒30~50 秒端到端时延3 跳150ms 左右400ms 左右300ms 左右数据包到达率小区84%93%97%数据包到达率公园90%96%99%平均节点功耗1 小时26mAh13mAh4mAh网关接收重复包占比40%5%1%节点内存占用3.2KB9.8KB17.5KB扩展极限估计30 节点左右100 节点左右300 节点先说到达率。在小区场景下纯洪泛只有 84%这个数字其实已经低于很多项目的最低要求了。原因是小区环境多径效应严重同一个区域里多个节点同时转发同一个包的概率大增冲突率和漏检率高。AODV 因为路径是单播的转发者固定为一个节点冲突概率骤降TSCH 网络栈则因为时隙机制从根本上避免了并发发射所以在两个场景下到达率都最高。功耗方面差距更悬殊。洪泛模式下每个节点都可能是转发者接收状态和发射状态频繁切换电流根本降不下来AODV 只有在转发时才全速发射其余时间可以低速侦听TSCH 节点大部分时间在休眠功耗低了不止一个量级。如果节点是用两节五号电池供电、要求续航半年以上洪泛方案基本就可以直接淘汰了。内存占用这点容易被忽略。洪泛方案只维护一个包头去重表3KB 左右就够AODV 要维护路由表、RREQ 缓存和邻居列表10KB 上下TSCH 因为要有超帧调度、邻居管理、时隙分配表17KB 跑不掉。选型之前一定要对照芯片规格书看 RAM 余量否则代码写完才发现塞不进包就尴尬了。4.2 实测定点测试过程与图表记录测试流程我是这样跑的每个节点以 30 秒周期上报温湿度网关上记录收到的时间戳、包序号、RSSI 和转发次数连续跑 30 分钟后统计到达率。为排除偶发干扰一个方案跑完会休息 5 分钟再跑下一个。城市的测试刚好赶上上午高峰路上汽车多对 LoRa 的 470MHz 频段有些邻频干扰但因为三个方案都测在同一时段横向对比仍然有效。最有意思的一组数据是网关收到的重复包占比。洪泛方案里一个来自最远节点的数据包经常被 4 到 5 个中间节点重复转发网关收到同一包的多个副本是常态。AODV 方案因为有路由表定向转发重复包几乎绝迹。这个差异直接影响了网关的软件设计——洪泛网关要花大量精力去重而路由模式的网关只需要做 ACK 超时重传代码逻辑完全是两码事。从扩展性的推算来看洪泛网络在 30 个节点左右就已经逼近瓶颈因为信道资源被广播包吃掉了大半AODV 在 100 个节点内都能维持 90% 以上的到达率再往上路由表维护的开销会压过收益TSCH 网络栈理论容量最大但实现代价也最大它需要每个节点做时间同步和调度协调节点越多超帧的规划和维护就越困难。所以“哪个方案最好”这个问题永远要加上一个前提你的节点数和数据频率是多少。5. 工程实战中的高频问题与排查手记5.1 洪泛网络“全部节点都有信号但就是传不出去”这个现象我查了很久才找到根因。看起来每个节点都能收到上一跳的数据但到达网关的包极少。后来用频谱分析仪盯着看才发现问题出在“多节点同时转发”两个中间节点在同一个信道上、几乎同一时间往外发相同的数据包在网关这边形成强碰撞结果全盘皆输。解决办法有两个方向。一是把洪泛改成带随机延时转发即收到包后等待一个随机长度的时间再决定是否转发这个等待时间必须在 0 到全包传输期的 2 倍之间随机取值。二是给不同跳数的节点预设不同的发射 SF让上一跳和下一跳不在同一速率上天然错开时间窗口。两者结合起来以后洪泛方案的到达率能回升 10 个百分点左右但代价是端到端时延增加了 200ms 上下需要结合场景做取舍。5.2 AODV 的路由环路问题AODV 在拓扑变化频繁时容易产生路由环路比如两个节点同时断开又重新连接旧路由还没失效新路由已经开始建立数据包就会在两个节点之间来回跳。标准的解决办法是让每个数据包携带跳数计数器超过最大跳数直接丢弃同时回送一个路由错误消息让上游节点重新发起路由发现。这个机制一定要做不做的话环路会把电池一直耗到没电。不过在 LoRa 上做环路检测有个特殊的地方LoRa 本身单包最大只有 255 字节跳数计数器这种控制字段会挤占有效负载。我们选择在应用层数据包头里只保留 3 位跳数计数最大支持 7 跳超过就丢。如果你的网络确实需要超过 7 跳可以适当加长数据包头但一定要和有效负载长度做权衡分片传输的代价远大于省下这 3 个比特。5.3 TSCH 网络栈的时隙错位排查TSCH 方案最隐蔽的问题是“看似同步、实则漂移”。节点在出厂时做了时钟校准刚开始跑一天完全正常到第二天就出现随机丢包。排查的时候直接看节点日志里记录的预期发送帧号和实际发送帧号差异发现问题节点每次都要偏差 20ms 左右。原因是它在维护窗口内没有成功地收到基准节点的广播帧本地时钟没有得到校准。这种问题解决起来不复杂在超帧里加一个强制同步逻辑——连续两个维护窗口没收到基准帧的节点自动切换到“搜网模式”全信道扫描窗口信号重建同步。另外把维护窗口间隔从 2 秒缩短到 1 秒也能显著减少漂移累积代价是降低了休眠占比平均电流会上升 0.5uA 左右属于可以接受的量级。我在文档里很少看到有人提这一条但实测下来它比任何参数调优都重要。6. 选型建议到底选哪条路根据我们这些项目里的“折返跑”经验我最终会按这样一条线来推荐。如果节点数不超过 30、对功耗不敏感、随时可能有节点增删、还希望零配置部署那就安心用洪泛关键是调好跳数和重传抑制时间。如果你需要做到 100 个节点左右、要求数据稳定到达、但也接受秒级组网时间AODV 或者简化的 RPL 路由是性价比最高的选择。如果你的项目面向长期无人值守运行、节点数量奔着 200 以上去那不要挣扎了直接上 TSCH 风格的网络栈前期多付出的开发时间会在后期运维里几十倍地赚回来。这里要特别提醒一句不要因为在实验室里洪泛跑得好就不加思考直接上量产。实验室环境干净干扰少、节点少、数据量低真实环境有树、有墙、有车辆、有别人的无线电信号。我自己在项目里就吃过这种亏实验环境 99% 到达率一上现场打了对折。硬件方案定型前最好在目标现场先拉一组真实节点做 24 小时稳定性摸底这个投入远比“上线后救火”更划算。7. 我在几轮迭代中的真实体会做完这几轮方案对比最大的感受是LoRa 自组网没有“最好”的协议只有“最匹配需求”的组合。洪泛的简单是它的护城河路由的可控是它的卖点网络栈的复杂度则是在换取极致的可靠和功耗。每一次方案切换本质上都是拿一类指标交换另一类指标没有谁是在所有维度上都赢的。如果让我给一个在手项目的建议从小规模起步先在洪泛上把业务跑通同时把路由和网络栈的软件框架预留好接口。等业务量上来、节点数逼近当前方案的瓶颈时再平滑切到高一层方案。这样做的好处是前期的业务验证不会被协议复杂度拖死后期的扩容又不必推倒重来。我们在项目中就是这么干的目前线上跑的是一个“洪泛 简单路由混合”的模式默认洪泛转发一旦检测到重复包过多自动启用局部路由缓存相当于两条路线之间的过渡态。这种渐进式策略应该比较贴合多数团队的迭代节奏。