
> 汇率说明：本文涉及美元金额处，按 2026 年 10 月基准 1 美元 ≈ 6.71 元人民币折算。

每一张 LoRaWAN 网络图纸上，都有几个"最后 5%"的设备：埋在混凝土井室里的水表、金属配电柜里的温度传感器、地下二层没有电源的车库末端。它们离最近的网关只有几百米，中间却隔着一堵按分贝计算的墙。

传统的解法只有两种：把网关搬到设备旁边，或者放弃这几个点。前者意味着电源、回传、施工、运维全部跟过去，为了三五个传感器新增一台网关，投资逻辑很难成立。后者意味着运营商最不愿意听到的词——白区，以及为白区安排的人工抄表。

2022 年 10 月 3 日，LoRa Alliance 发布了 LoRaWAN Relay 规范（TS011-1.0.0），给这个问题补上了标准化的第三种解法：​**用一台电池供电的中继节点，把被覆盖盲区挡住的设备流量，原样接力到网关**​。本文把这套机制拆开来看：它是怎么工作的、安全模型是什么、边界在哪里、什么场景该用、什么场景不该用。

## 一、Relay 的定位：补盲，不是组网

先说清楚 Relay 不是什么。它不是 Mesh。

LoRaWAN 的星型拓扑里，终端只和网关说话。Relay 规范没有改变这个拓扑——它只是在这条星型链路中间，插进了一个**标准终端形态**的中继节点：一台电池供电、外形和功耗都和普通终端差不多的设备，替深覆盖盲区里的终端转发流量。中继节点自己仍然是一个标准的 LoRaWAN 终端，向网络服务器注册、上报自己的数据，一切都按普通终端的方式管理。

规范里有三条设计约束值得记住：

**第一，只有一跳。** 终端到网关之间最多允许一台中继节点，不允许中继串中继。这意味着覆盖扩展的上限大约是把原有半径拉长一倍，而不是无限延伸。LoRa Alliance 把它设计成"深覆盖补盲工具"而非"组网技术"，是有意为之——多跳路由会带来指数级的功耗、时延和故障域复杂度，和 LoRaWAN 的低功耗定位直接冲突。

**第二，中继必须是电池供电的形态。** 不要求市电、不要求网线，这决定了它可以被塞进井室、天花板、机柜夹层这些"最后一米"的位置。Semtech 公布的参考实现里，中继节点电池寿命可达 7 到 10 年，具体取决于服务的设备数量和每日数据量。

**第三，被服务的设备随时可以退回直连。** 规范要求运行在中继后面的终端，具备回退到普通 LoRaWAN 直连模式的能力。这个"可逆性"是选型时的重要保险：中继坏了、搬走了，终端不会变成砖。

## 二、上行链路：WOR 先敲门，数据再进门

Relay 机制的核心矛盾在于：中继是一台电池设备，不可能一直开着接收机等数据；但终端的上行是随机的，网关那种"多信道常开"的接收能力，普通终端硬件根本没有。

规范用两段式通信解决这个问题。整个上行分四步：

**第一步，WOR 帧（Wake On Radio）。** 被服务终端不直接发数据，而是先在一个专用的 WOR 信道上发一个短的唤醒帧。这个帧不含业务数据，只携带"接下来那次真实上行"的元数据：频率、数据速率等。WOR 帧用加长的前导码，让处于深睡眠的中继能靠低功耗检测被唤醒，而不是靠常开接收机。

WOR 信道有默认参数：在 EU868、AS923 等区域默认是 SF9/BW125，在 US915、AU915 区域默认是 SF10/BW500。规范允许运营商配置第二个 WOR 信道，缓解多台中继同址时的串扰——一个 WOR 帧把附近多台中继全部唤醒、各自处理一遍却发现不是发给自己的，这是规范明确要防的浪费。

**第二步，CAD 监听。** 中继并不是在等 WOR 帧，而是在做信道活动检测（Channel Activity Detection）。它按周期醒来，检测 WOR 信道上有没有前导码能量，没有就继续睡。CAD 周期可在 25 毫秒到 1 秒之间配置（默认 1 秒）——周期越短，唤醒响应越快，但电池消耗越大。这是中继功耗的主要调节旋钮。

**第三步，WOR-ACK 握手。** 中继检测到 WOR 帧后，解密校验，确认这个唤醒是发给自己的，然后回一个 WOR-ACK，把接下来转发链路的参数告诉终端：中继到网络侧的数据速率、晶振精度、CAD 周期、转发余量等。终端拿到这些参数，才知道下一次该怎么发、中继什么时候能转发。

**第四步，真实上行与封装转发。** 终端在约定参数上把真正的 LoRaWAN 上行帧发给中继。中继收到后，把它封装进自己的一个标准 LoRaWAN 上行帧里，通过 ​**FPort 226**​（规范为中继保留的专用端口）发给网关，帧内同时附带元数据：终端原帧到达中继时的 RSSI、SNR、数据速率和 WOR 信道信息。网络服务器解开封装，看到的仍然是终端原本的帧——对应用服务器来说，走中继来的数据和直连来的数据没有区别。

## 三、下行链路：18 秒后的 RXR 窗口

下行方向，网络服务器把发给深覆盖终端的下行帧，封装在**中继自己**的 RX1 或 RX2 窗口里下发——也就是说，服务器先把下行交给中继，再由中继转交给终端。

中继转发下行时使用的窗口叫 RXR：固定在**被服务终端发出上行之后 18 秒**打开。18 秒是刻意留出的缓冲，让"终端 → 中继 → 网关 → 服务器"整条往返链路有时间走完，服务器做出的下行能赶在中继的 RXR 窗口内回到中继。RXR 使用 WOR 帧的数据速率，但频率沿用终端真实上行的频率。

这个设计直接给了一个工程结论：​**走中继的链路，不适合做实时性双向交互**​。一次问答往返至少要跨越 18 秒的窗口时序，再加上 CAD 唤醒延迟。参数配置这类偶发下行没问题；Class C 那种秒级实时控制，不是 Relay 的设计目标。

## 四、安全模型：中继是哑管道

Relay 链路上有两段独立的无线链路，规范为它们建立了两套独立的会话密钥：

* 终端到中继这段，使用一套专门的密钥：RootWorSKey 派生出 WorSIntKey（校验 WOR 帧的完整性）和 WorSEncKey（加密 WOR 帧载荷）。OTAA 入网时这套密钥在 Join-Accept 之后派生，ABP 则随设备预置。
* 中继到网关这段，使用中继自己的标准 LoRaWAN 会话密钥。

关键点是：终端的业务载荷（FPort 数据）始终用终端自己的应用会话密钥加密，中继拿不到那把钥匙。中继能做的只是把加密后的帧原样封装转发——​**中继是一个哑管道，不是解密节点**​。中继被物理窃取，攻击者拿到的也只是中继自己的会话，而不是它服务过的那些终端的数据。

这延续了 LoRaWAN 一贯的端到端安全哲学，也是 Relay 能进入水表、燃气这类市政关键基础设施的前提。

## 五、硬边界：四条先说在前面

Relay 规范很好用，但有四条边界，选型前必须核对：

**一跳上限。** 前文说过，终端与网关之间只能有一台中继。信号需要穿两道"墙"的场景，Relay 方案直接不成立，只能重新规划网关。

**容量上限。** 规范的最低要求是每台中继至少服务 10 台终端；Semtech 的实现和 Actility ThingPark 的文档口径是单台中继最多服务 16 台。一个井室里塞三四十台设备的场景，不适用。

**被服务设备的模式限制。** 以 Actility ThingPark 的实现为例，运行在中继后面的终端必须使用 ​**Class A + OTAA**​。ABP 预激活的存量终端、需要 Class C 实时下行的终端，都无法走中继链路（中继节点本身倒是可以是任意 Class、任意入网方式）。

**生态成熟度。** Relay 需要 NS 侧解封装、终端固件实现 WOR/CAD 状态机。Semtech 已把 Relay 集成进 LoRa Basics Modem v4 协议栈，Actility ThingPark 自 7.3 起提供中继支持（初期为 PoC 形态，随版本逐步放开 MAC 命令）。但相比 1.0.x 主协议，Relay 的设备侧和平台侧生态仍在铺开的过程中——采购前确认终端芯片栈版本和 NS 支持状态，是必做的功课。

## 六、该用与不该用：一张决策清单

**适合 Relay 的场景，四个条件同时满足：**

1. 盲区设备数量少（几个到十几个），新增网关的投资无法成立；
2. 盲区无市电、无回传，或者施工成本高到不合理——井室、地埋、金属柜顶上；
3. 数据是周期性上报，能接受 18 秒级的下行时延；
4. 设备是 Class A + OTAA 形态，或可以换成这种形态。

典型客户画像就是规范最初瞄准的市场：市政水气热表、深楼宇末端、工业金属环境里的监测点。Semtech 与 Arad、Actility、Deviceroy 合作，在美国科罗拉多州做了偏远水表的中继采集试验，验证的就是"边缘白区补盲"这条主路线。

**不适合的场景：**

1. 大规模设备聚集区——那应该加网关，中继的 16 台上限和单跳转发会成为瓶颈；
2. 需要秒级下行实时性的控制类应用；
3. 存量 ABP 终端为主、无法改造固件的网络；
4. 期望"信号穿两堵墙"的场景——一跳上限卡死了这条路。

还有一类常见的混淆值得单独说：​**Relay 不是"中继器"（Repeater）**​。市面上有大量 PHY 层的 LoRa 中继器产品，收到信号就放大重发，不解析协议。它们实现简单、无需 NS 支持，但重发的是物理层信号——重复占用信道、无鉴权（谁都能让它转发）、无法做下行、功耗高（不能睡）。Relay 规范本质上是把"中继"从 PHY 层的哑放大器，升级成了 MAC 层可管理、可鉴权、可休眠、双向的标准网络节点。私有协议项目里用中继器将就一下可以；要长期运维、要安全、要纳入平台管理，应该走标准 Relay。

## 七、认证与平台侧：两件事要提前排进计划

**认证上，Relay 没有捷径。** 第 29 期讲设备认证时提过：Relay、SCHC、FUOTA 这三类特性的协议认证只能走 ATL 实验室，自测实验室无权覆盖。而且截至目前 LoRa Alliance 的 ATL 名单里没有中国大陆的实验室，样品需要出境送测。如果你的产品线要宣布"支持 Relay"，认证周期和费用要提前排进项目计划。

**平台侧，按标准终端的思路管理。** 从网络架构看，网关仍然是透明转发物理层信号的设备，Relay 的封装与解封装发生在终端、中继和 NS 三方之间——这也是为什么 Relay 依赖 NS 侧支持。ThinkLink 目前的版本口径是支持 LoRaWAN 1.0.2 / 1.0.3 / 1.0.4，Relay 属于 TS011 扩展规范，具体支持节奏以官方确认为准；在做 Relay 项目规划时，第一件事是和平台方确认 NS 解封装与中继设备管理的现状，而不是先买硬件。

## 写在最后

Relay 规范解决的是一个很"土"的问题：最后一百米里那几个最难的设备。它没有引入新拓扑，没有破坏安全模型，用一跳、16 台、18 秒这些克制的边界，换来了电池供电、随处可装、随时可退的补盲能力。

对一个做表计、楼宇或工业监测的团队来说，值得把 Relay 放进网络规划的备件清单：多数项目用不上它，但那几个白区设备出现时，它是唯一不需要重新做投资论证的标准答案。




汇率说明：本文涉及美元金额处，按 2026 年 10 月基准 1 美元 ≈ 6.71 元人民币折算。

LoRaWAN Relay 中继规范解读：一跳之内，把信号送进最难覆盖的地方

LoRaWAN Relay（TS011-1.0.0，2022 年发布）用电池供电的中继节点补覆盖盲区：WOR 唤醒、CAD 监听、FPort 226 封装、18 秒 RXR 下行窗口、双会话密钥安全模型。本文拆清上行/下行全流程、单跳与 16 台容量等硬边界、与 PHY 层中继器的区别、认证只能走 ATL 的约束，以及该用与不该用的决策清单

人工智能

LoRaWAN Relay规范解析：标准化的网络补盲方案，通过电池供电中继节点实现单跳转发，解决深覆盖盲区设备连接问题。支持10-16台终端，18秒下行延迟，保持端到端加密安全。适用于市政表计、楼宇监测等无市电场景，需OTAA+ClassA设备配合，当前生态仍在完善中。

服务器

路由

LoRa

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

LoRaWAN Relay 中继规范解读：一跳之内，把信号送进最难覆盖的地方-腾讯云开发者社区-腾讯云

LoRaWAN Relay 中继规范解读：一跳之内，把信号送进最难覆盖的地方

LoRaWAN Relay 中继规范解读：一跳之内，把信号送进最难覆盖的地方

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐