LoRaWAN Relay Explained: One Hop Into the Hardest Corners of Your Network

Every LoRaWAN deployment drawing has them: the last 5 percent of devices. A water meter buried in a concrete valve chamber, a temperature sensor inside a metal distribution cabinet, a parking sensor at the far end of a basement level with no power supply. These devices may sit only a few hundred meters from the nearest gateway — with a wall in between that costs tens of decibels.

Traditionally there have been only two options: move a gateway next to the devices, or abandon those points. Moving a gateway means power, backhaul, construction and ongoing operations all follow it — hard to justify for three or five sensors. Abandoning means white spots, and manual meter reading for exactly the accounts that are hardest to serve.

On October 3, 2022, the LoRa Alliance added a standardized third option: the LoRaWAN Relay Specification (TS011-1.0.0). A battery-powered relay node forwards the traffic of devices stuck in coverage dead zones to the nearest gateway, with no new infrastructure. This article breaks the mechanism down: how it works, what the security model is, where the hard limits are, and when to use it — and when not to.

1. What Relay Is — and What It Is Not

First, what it is not: Relay is not a mesh.

LoRaWAN's star-of-stars topology is unchanged. The Relay specification inserts a single, standard end-device-shaped node into that star: a battery-powered relay whose form factor and power budget resemble an ordinary end device, which forwards traffic on behalf of devices in deep-coverage blind spots. The relay itself is still a standard LoRaWAN end device — it registers with the Network Server, reports its own data, and is managed like any other node.

Three design constraints are worth memorizing:

One hop only. At most one relay may sit between an end device and the gateway. No relay-to-relay chaining. That caps coverage extension at roughly a doubling of the original radius. The LoRa Alliance deliberately scoped Relay as a coverage-patching tool, not a networking technology: multi-hop routing brings compounding costs in power, latency and failure domains that conflict with LoRaWAN's low-power positioning.

Battery powered by design. No mains, no Ethernet. That is what allows a relay to be tucked into a valve chamber, a ceiling void, or a cabinet — the "last meter" positions where gateways cannot go. In Semtech's reference implementation, relay battery life reaches 7 to 10 years depending on the number of served devices and daily data volume.

Reversibility. Devices operating behind a relay must be able to fall back to normal direct LoRaWAN operation. This reversibility is an important insurance policy: if the relay fails or is decommissioned, the served devices are not stranded.

2. The Uplink: WOR Knocks First, Data Follows

The core tension: a relay is a battery device that cannot keep its receiver on continuously, yet uplink traffic from served devices is random — and a gateway's always-on multi-channel receiver is far beyond what end-device hardware offers.

The specification solves this with two-stage communication. An uplink takes four steps:

Step 1 — the WOR frame (Wake On Radio). The served device does not send data first. It sends a short wake-up frame on a dedicated WOR channel. This frame carries no application data — only metadata about the transmission to follow, such as frequency and data rate. WOR frames use a long preamble so a deeply sleeping relay can be woken by low-power detection rather than a continuously listening receiver.

Default WOR channel parameters: SF9/BW125 in EU868, AS923 and similar regions; SF10/BW500 in US915 and AU915. Operators may configure a second WOR channel to reduce cross-waking — a single WOR frame waking several nearby relays that each process it before discovering it is not addressed to them is exactly the waste the specification is designed to prevent.

Step 2 — CAD listening. The relay does not "wait" for WOR frames; it performs Channel Activity Detection. It wakes periodically, samples the WOR channel for preamble energy, and goes back to sleep if there is nothing. The CAD period is configurable between 25 milliseconds and 1 second (default 1 second). Shorter periods mean faster response but higher battery drain — this is the main power-consumption tuning knob.

Step 3 — the WOR-ACK handshake. On detecting a WOR frame, the relay decrypts and validates it, and if it is addressed to this relay, replies with a WOR-ACK carrying the parameters for the forwarding link: data rate between relay and network, crystal accuracy, CAD periodicity, and forwarding capacity. The served device now knows exactly how to transmit and when the relay will forward.

Step 4 — the real uplink, encapsulated and forwarded. The device sends its actual LoRaWAN uplink frame to the relay on the agreed parameters. The relay wraps this frame inside its own standard LoRaWAN uplink and sends it to the gateway on FPort 226 — the port the specification reserves exclusively for relay traffic — together with metadata: the RSSI, SNR, data rate and WOR channel observed when the original frame arrived at the relay. The Network Server unwraps the frame and sees the device's original frame, unmodified. To the Application Server, data arriving via a relay is indistinguishable from data arriving directly.

3. The Downlink: the RXR Window, 18 Seconds Later

Downlink works the other way around: the Network Server delivers a downlink destined for a deep-coverage device inside the relay's own RX1 or RX2 window — the server first hands the downlink to the relay, and the relay then hands it to the served device.

The relay transmits the downlink in a window called RXR, which opens at a fixed 18 seconds after the served device's uplink. Those 18 seconds are deliberate headroom, letting the full round trip — device, relay, gateway, server — complete so the server's response makes it back to the relay in time. RXR uses the WOR frame's data rate but the frequency of the device's actual uplink.

This yields a direct engineering conclusion: relay links are not for latency-sensitive bidirectional interaction. A single request-response round trip must traverse the 18-second window timing plus CAD wake-up latency. Occasional downlinks such as parameter configuration are fine; Class C-style real-time control is not what Relay was designed for.

4. Security: the Relay Is a Dumb Pipe

There are two independent radio links on a relay path, and the specification provisions two independent sets of session keys:

• Device-to-relay uses a dedicated key set: RootWorSKey derives WorSIntKey (verifying WOR frame integrity) and WorSEncKey (encrypting WOR frame payloads). With OTAA these are derived after the Join-Accept; with ABP they are pre-provisioned.
• Relay-to-gateway uses the relay's own standard LoRaWAN session keys.

The critical point: the served device's application payload remains encrypted under the device's own application session key, which the relay never holds. The relay can only encapsulate and forward the already-encrypted frame — the relay is a dumb pipe, not a decryption node. Physically stealing a relay yields the relay's own session, not the data of the devices it serves.

This preserves LoRaWAN's end-to-end security philosophy, and it is what makes Relay acceptable for metering and other municipal critical infrastructure.

5. Four Hard Limits to Check Before You Commit

One hop. As above — a single relay between device and gateway, no exceptions. Scenarios requiring two hops to breach two barriers are out of scope; re-plan the gateway.

Capacity. The specification's minimum requirement is that a relay serves at least 10 end devices; Semtech's implementation and Actility ThingPark's documentation both state a maximum of 16 served devices per relay. A chamber holding thirty or forty devices does not fit this model.

Device-mode restrictions. In Actility ThingPark's implementation, devices operating behind a relay must use Class A with OTAA. Pre-provisioned ABP devices and devices requiring Class C real-time downlink cannot run behind a relay (the relay node itself may be any Class and either activation mode).

Ecosystem maturity. Relay requires NS-side decapsulation and a WOR/CAD state machine in device firmware. Semtech has integrated Relay into LoRa Basics Modem v4, and Actility ThingPark has supported relays since release 7.3 (initially as a proof of concept, with MAC command support expanding across releases). But relative to the 1.0.x core protocol, the device- and platform-side ecosystem is still ramping up. Verifying the terminal's software stack version and your Network Server's support status is mandatory homework before procurement.

6. When to Use Relay — and When Not To

Use Relay when all four conditions hold:

1. Few devices in the dead zone (a handful to a dozen or so), too few to justify a gateway;
2. No mains power and no backhaul in the zone, or construction costs are unreasonable — valve chambers, buried vaults, tops of metal cabinets;
3. Traffic is periodic uplink reporting, tolerant of 18-second-class downlink latency;
4. Devices are Class A + OTAA, or can be migrated to that mode.

The canonical profile is the market the specification originally targeted: municipal water, gas and heat metering, deep-indoor building endpoints, and monitoring points inside industrial metal environments. Semtech ran field trials for remote water meter collection in Colorado with Arad, Actility and Deviceroy — validating exactly this "edge white-spot" route.

Do not use Relay when:

1. The area has a dense device population — add a gateway; the 16-device cap and single-hop forwarding become bottlenecks;
2. The application needs second-class real-time downlink control;
3. The network is dominated by legacy ABP devices that cannot be firmware-upgraded;
4. You expect the signal to pass two barriers — the one-hop limit closes that door.

One common confusion deserves its own paragraph: Relay is not a repeater. The market is full of PHY-layer LoRa repeaters that receive a signal and blindly retransmit it. They are simple, need no NS support — and retransmit raw physical-layer signals: they double channel occupancy, have no authentication (anyone can make them forward), cannot do downlink, and cannot sleep. The Relay specification upgrades "relaying" from a dumb PHY-layer amplifier to a manageable, authenticated, sleep-capable, bidirectional standard network node at the MAC layer. For a throwaway private-protocol project a repeater may do; for anything with a long operations lifetime, security requirements, or platform management, use standard Relay.

7. Certification and Platform Side: Two Items for the Project Plan

Certification has no shortcut. As covered in our article on the LoRaWAN certification program: protocol certification for Relay, SCHC and FUOTA can only be performed at ATL laboratories — self-test labs are not authorized to cover them. And the ATL list currently includes no laboratory in mainland China, so samples must travel abroad for testing. If your product line is going to claim Relay support, schedule the certification timeline and budget into the project plan.

Platform side, manage it like a standard end device. In the architecture, the gateway remains a transparent radio-to-IP forwarder; encapsulation and decapsulation happen between the end device, the relay and the Network Server — which is exactly why Relay depends on NS-side support. ThinkLink's current stated compatibility is LoRaWAN 1.0.2 / 1.0.3 / 1.0.4; Relay is a TS011 extension specification, and its support timeline should be confirmed with the platform vendor directly. When planning a Relay project, the first step is confirming your NS's decapsulation and relay-management status — before buying hardware.

Closing Thoughts

The Relay specification solves a decidedly unglamorous problem: the hardest few devices in the last hundred meters. It introduces no new topology and breaks no security model; with restrained boundaries — one hop, 16 devices, 18 seconds — it buys battery-powered, install-anywhere, reversible coverage patching.

For teams working in metering, buildings or industrial monitoring, Relay belongs on the network-planning shelf: most projects will not need it, but when those white-spot devices appear, it is the only standard answer that requires no new investment case.