LoRaWAN Relay (Based on TS011-1.0.1)

A LoRaWAN Relay is a LoRaWAN end-device with additional logic that allows it to forward uplinks and downlinks for other devices that lack direct coverage to a gateway.

Overview

A relay:

Wakes on a special WOR (Wake-On-Radio) frame
Receives the end-device's uplink
Forwards that uplink using its own LoRaWAN connection
Receives downlinks from the Network Server
Delivers those downlinks to the end-device during RXR, a special relay receive window

This enables LoRaWAN coverage extension without deploying additional gateways.

Wake-On-Radio (WOR)

WOR is the mechanism that synchronizes the relay and the end-device.

What WOR Does

WOR frames:

Wake the relay
Indicate which frequency/data rate will be used for the following uplink

Because relays only listen intermittently, WOR frames must use a long preamble.

How the Relay Detects WOR

The relay:

Performs periodic CAD (Channel Activity Detection) scans
Uses a default scan interval of 1000 ms (can be shorter)
If CAD detects activity, it switches to full receive mode
The switching delay is called CadToRx

WOR Types

WOR Type	Meaning
`0`	WOR for Join-Request
`1`	WOR for Class A uplink
`2–7`	RFU or proprietary

WOR ACK

The relay responds to Class A WOR with a WOR ACK that includes:

Timing details (CAD period, CadToRx)
Clock accuracy
Supported channels
Forwarding status
Data rate information

The end-device uses this to reduce future WOR preamble lengths.

If no WOR ACK is received, the end-device still proceeds with uplink transmission using default timing.

Timing Flow (Explained in Text)

Join Procedure Flow

End-device sends a WOR with a long preamble.
After a fixed delay, it sends a Join-Request.
Relay receives and forwards the Join-Request.

Normal Class A Flow

End-device sends WOR.
Relay detects it and sends WOR ACK.
End-device waits a defined delay.
End-device sends its LoRaWAN uplink.
Relay forwards the uplink to the Network Server.
If a downlink is needed, the Network Server sends it to the relay.
Relay forwards the downlink during RXR.
End-device receives the downlink in RXR.

Loss of WOR ACK

Even if WOR ACK is lost, the uplink still occurs normally.

RXR Window (Relay Downlink Window)

RXR is a special receive window the end-device opens after a relayed uplink.

Key behavior:

RXR opens after RX1 and RX2
The end-device stops listening early if no preamble is detected
Timing tolerates both end-device and relay clock error

Synchronization States

The end-device maintains one of three synchronization states:

Initialized

No recent WOR ACK
Assumes worst-case timing
Uses long preamble
No second channel information

Unsynchronized

Has previously received WOR ACK
Information may be outdated
Moderate preamble length

Synchronized

Recent valid WOR ACK
Precise info on CAD period, CadToRx, clock accuracy
Short WOR preambles allowed

Security Model

Dedicated keys protect the WOR link:

RootWorSKey
WorSIntKey
WorSEncKey

These provide authentication and encryption for WOR/WOR ACK exchanges.

Forwarding Logic

Uplink Forwarding

The relay forwards:

Original PHYPayload
Metadata
WOR channel index
Relay header

Downlink Forwarding

Downlinks are encapsulated by the Network Server and delivered during RXR by the relay.

Payload Size

Payload must fit both ED→relay and relay→gateway links.

Forwarding Limits

Token buckets limit forwarding for:

Join-Requests
New device announcements
Uplinks (per-device and global)

If buckets are empty, the relay ignores WORs for that message type.

Relay MAC Commands

Important commands:

RelayConfReq/Ans
EndDeviceConfReq/Ans
FilterListReq/Ans
UpdateUplinkListReq/Ans
ConfigureFwdLimitReq/Ans
NotifyNewEndDeviceReq

Full Message Flow

Device sends WOR
Relay detects it
Relay may send WOR ACK
Device transmits uplink
Relay forwards
Network Server creates downlink
Relay delivers downlink in RXR
Device adjusts sync
Relay enforces rate limits