LoRaWAN 与 LoRaMESH：拓扑、场景和选型对比

01 一个常见误解

不少工程师以为"都用 LoRa 物理层，选哪个都差不多"。其实 LoRaWAN 和 LoRaMESH 是两个完全不同的网络协议——它们只是共用了 Semtech 的 LoRa CSS 调制层，但在拓扑、调度、入网、应用场景上几乎没有交集。选错协议会让整个项目返工。

本文从拓扑结构开始讲清两者差异，重点说明 LoRaMESH 在哪些场景下是无可替代的选择。

Tip：判断标准很简单——你的网络是"中心—终端"模式还是"邻居互助"模式？

02 拓扑对比：星型 vs 网状

LoRaWAN：标准星型拓扑。所有终端只与网关单跳通信，网关再统一上联网络服务器。终端之间不通信，也不互相转发。

LoRaMESH：多跳网状拓扑。基于 Gossip 邻居发现机制，每个节点同时承担采集 / 中继 / 转发角色，节点之间互相协作扩展网络覆盖。

拓扑差异的工程含义

• LoRaWAN 强依赖基础设施（网关），网关坏掉整个覆盖区失联
• LoRaMESH 不需要基础设施，任意两个节点都能通过中间节点接力
• LoRaWAN 部署简单（装网关即可），LoRaMESH 部署灵活（撒节点就能扩展）

对于公网基础设施完好的场景，星型更简单；对于公网中断或没有基础设施的场景，网状才是唯一解。

03 场景一：广覆盖、低密度、稳定基础设施 → LoRaWAN

典型场景：智慧抄表、智慧路灯、智慧农业、慢速环境监测。这些场景的共同特征：

• 节点位置固定
• 上报频率低（小时级 / 天级）
• 网关可以预先架设并保持稳定供电
• 终端无需互通

LoRaWAN 的星型拓扑在这种场景下部署成本低、协议简单、电池寿命可达 10 年。

但这不是艾森智能现在主推的方向——LoRaWAN 业务我们已逐步收敛。

04 场景二：临时部署、复杂地形、公网失效 → LoRaMESH

典型场景：应急救援、矿难搜救、隧道施工、大型活动安保、移动式工业测试。这些场景的共同特征：

• 现场临时部署，没有预先架好的网关
• 公网可能受损或本身不存在（地下、远山、灾区）
• 节点会移动（救援人员、车辆、无人机）
• 拓扑随人员调度动态变化

在这些场景下，LoRaWAN 完全无法工作——网关从哪里来？基站谁来供电？而 LoRaMESH 通过节点之间的自组网恰好就是为这类场景设计的。

艾森智能 LoRaMESH 多跳自组网协议支持：

• Gossip 邻居发现 + 动态路由维护
• 单网最多 120 节点 / 5 跳深度
• 节点开机即扫邻、自动加入网络
• LoRaMESH_PA 增程模组（叠加 PA 功放，单跳更远）

对应急救援队来说，LoRaMESH 不是"备选方案"而是"唯一方案"——公网中断时，它是现场指挥的通信底座。

05 场景三：园区 / 工业现场的高密度互通 → AIMesh 2.5

需要说明的是，LoRaMESH 并不适合所有"网状"场景。对于工业现场高密度、确定性、低时延的需求，艾森智能推荐 AIMesh 2.5 而非 LoRaMESH：

• AIMesh 2.5 基于 IETF 6TiSCH + IPv6，单网最大 5000 节点
• 端到端可靠性 99.99%、时延 < 1 秒
• GMSK + FEC 物理层比 LoRa CSS 更适合工厂车间的高密度回传

简单分工：LoRaMESH 管"野外、临时、移动"，AIMesh 2.5 管"室内、固定、高密度"。

06 可靠性与功耗对比

LoRaMESH 牺牲电池寿命换来的是"无依赖部署 + 节点互通"，这是 LoRaWAN 永远做不到的。

07 选型决策

简化决策路径：

选 LoRaMESH 的场景（艾森智能强推）

• 应急救援、矿难、隧道、户外保障
• 公网中断或无基础设施
• 节点会移动（人员 / 车辆 / 无人机）
• 终端之间需要互相通信

选 AIMesh 2.5 的场景

• 工业现场高密度采集（车间、配电站、园区光伏）
• 需要 99.99% 可靠性和 < 1 秒时延
• 需要 IPv6 直接接入工业互联网

仍考虑 LoRaWAN 的场景（艾森智能不再主推）

• 城市级智慧抄表 / 智慧路灯（公共网关已建好）
• 大量低频上报、静态点位

一句话：临时移动选 LoRaMESH，固定密集选 AIMesh 2.5。