Using LoRaWAN® relays
This page describes the basic concepts of LoRaWAN® relays and how they get seamlessly integrated with ThingPark.
What is a relay?
A LoRaWAN® relay is a device that forwards to the network uplink LoRaWAN® frames received from trusted end-devices, by encapsulating them in its own frame payloads. Likewise, the relay receives encapsulated downlink frames from the network and forwards them to the appropriate end-devices after decapsulation.
Relays offer a practical, reliable and cost-effective way to cover white spots for sensors located at the edge of the RF coverage provided by conventional gateways. This could be the case for sensors located deep indoors, in basements or even inside metallic cabinets. A typical example is about smart metering use cases, where deploying a relay eliminates the need for costly drive-by operations to collect meter readings in white spots.
Moreover, from operational standpoint, relays are particularly useful in zones where it is not possible/practical to add pico or nano gateways, either due to lack of power supply or backhaul options. Indeed, unlike conventional gateways, relays are battery-powered and use LoRaWAN's radio interface as backhaul solution.
LoRaWAN® relays have a similar architecture to conventional LoRaWAN end-devices, they are often (but not necessarily) battery-powered. Like any conventional device, a relay can use any LoRaWAN class (class A, B, C) and can use either OTAA or ABP activation modes.
A relay can securely serve up to 16 end-devices. End-devices served exclusively by relays can only use class A mode.
Wake-on-Radio (WOR) and Channel Activity Detection (CAD) mechanisms
To preserve its battery, the relay cannot permanently listen to potential incoming messages. Therefore, the standard LoRaWAN® relay protocol defined in TS011 defines two mechanisms:
Wake-on-Radio (WOR): this uplink frame is sent by the end-device to wake up the relay and provide information about the following (regular) uplink frame so that the relay can tune its receiver to the right RF frequency and data rate.
Channel Activity Detection (CAD): the main characteristic of the Wake-on-Radio
(WOR) frame is its preamble duration which can go up to 1 second. This long preamble allows the relay to sleep and only wake up periodically to scan for radio activity. The default CAD periodicity is 1 second.
Typical message flow in relay mode
- To wake-up the nearby relay, the end-device must broadcast a WOR frame over a predefined (regional-specific) WOR channel. In this WOR frame, the end-device provides the frequency and data rate of its following uplink frame.
- If the relay has successfully authenticated the end-device (by validating the
WOR MIC), it may acknowledge this WOR frame by sending a WOR ACK.
WOR ACKs are useful for time synchronization between the relay and the end-device (thus reducing the WOR preamble length to save battery). They also allow the end-device to learn about the relay's forwarding information: UL data rate used between relay and the network, whether the forward limit has been reached...
- The end-device sends the uplink packet. This is a regular LoRaWAN® packet, not specific to the relay protocol. Besides the relay, any nearby gateway can demodulate and forward this regular uplink frame to the network (hence, RF macro diversity is fully supported).
- Having captured the device's uplink packet, the relay encapsulates it in its MAC
frame payload and appends device's uplink metadata to it (device's data rate,
frequency, RSSI and SNR measured by the relay...).
Then, the relay sends this encapsulated uplink frame over LoRaWAN® FPort 226.
The frequency and data rate used by the relay for this transmission are not
necessarily those used by the end-device.
On core network side, the network server decapsulates the relay's uplink packet to extract the end-device's original packet, then it processes the uplink packet normally: packet deduplication, ADR, MAC commands, sending ACK to confirmed uplinks, reporting to the application servers...
- If the network has a downlink packet to send to the end-device, it shall encapsulate it and send to the relay, still using FPort 226. This encapsulated packet shall be sent over the relay's RX1 or RX2 slots.
- The relay receives the encapsulated DL packet and extracts the device's original physical payload from it. Then, it forwards this payload to the device over a relay-specific RX slot called RXR. RXR slot opens 18s after the end of the device's uplink transmission. The downlink packet sent over RXR slot uses the same frequency as the WOR frame and reuses the same data rate as the end-device's last LoRaWAN® uplink packet.
The following diagram shows the end-to-end flow for an OTAA devices joining the network through a relay:
ForwardDownlinkReqare the end-device's UL/DL packets encapsulated by the relay and forwarded to the network over FPort 226.
UpdateUplinkLinkReqis a relay-specific MAC command sent by the network server to configure the relay with the end-device's DevAddr and relay key. It allows the relay to add this device to its trusted end-device list and authenticate its following WOR frames.
Note During its join cycle, the end-device broadcasts specific WOR frames that cannot be verified/ACKed by the relay. This is because the end-device key used by the relay to authenticate WOR frames is derived from the device's network session key, so it becomes only available to the relay after the successful completion of the join procedure.
For end-devices operating behind a relay
There are no particular hardware pre-requisites to use the relay protocol by an end-device.
From software standpoint, end-devices operating behind a relay must support the relay stack in their software. This stack allows those devices to use the standard radio protocol defined in TS011 to communicate with relays and the core network server.
From software standpoint, relays must obviously support the appropriate stack enabling the radio protocol defined in TS011.
From hardware standpoint, since a relay will exchange much more LoRaWAN traffic with the network than conventional end-devices, battery-powered relays should have a bigger capacity for their battery. The exact dimensioning of the relay battery depends on the number of devices it serves (up to 16) and the traffic profile it is expected to relay.
Other hardware requirements for the relay include:
- Bigger RAM and flash space than conventional end-devices, to allow storing session keys of its trusted end-devices.
- A Temperature-Compensated Crystal Oscillator (TCXO) is recommended to reduce the clock drift.
Provisioning relays on ThingPark
In the current release, relays are provisioned like any conventional device. To learn more about this procedure, see Activating new devices.
Hence, you do not need any special configuration to allow a provisioned device to act as a relay. Additionally, it is not required to statically associate end-devices with relays: the list of trusted end-devices that each relay can serve is automatically configured by the network server and sent to the relay over the air. The multi-tenant traffic isolation feature of ThingPark already applies to relays: a relay belonging to one tenant can only serve end-devices belonging to this tenant, not those belonging to other tenants.
Once provisioned, a relay may forward uplink packets from end-devices over FPort 226. Such forwarded packets are not sent to the application server(s) associated with this relay, to avoid spamming the application servers if the relay acts as a regular sensor (reporting data to applications) besides its relay functionality.
Analyzing relay traffic on ThingPark
ThingPark users can monitor and analyze the relay traffic through the Wireless Logger application.
The end-device traffic is associated with the device's DevEUI/DevAddr.
Relayed traffic can be identified by the
Fsymbol on its logo; such as and for uplink and downlink packets respectively.
Fstands for "Forwarded".
Additionally, the ID of the relay used to forward the packet is explicitly indicated in the "Relay ID" column, this ID refers to the relay's DevEUI.
The encapsulated UL/DL traffic sent by the relay is associated with the relay's DevEUI/DevAddr. Such traffic may be easily identified by the FPort field - displaying
To make traffic analysis simpler, WLogger displays the content of
ForwardDownlinkReqpayloads in decoded format. The same thing also applies to the content of the relay-specific MAC commands.
The following screenshot shows a typical example of an OTAA end-device joining the network through a relay. The sequence starts by the relay itself joining the network.
Here is an example of uplink/downlink packets exchanged between the end-device and the network through a relay:
To learn more about using Wireless Logger application, see Wireless Logger user guide.
Use the Power consumption calculator to evaluate the battery life of the LoRaWAN Relay and relayed devices from power consumption estimates (decomposed in specific estimates for Wake On Radio synchronization, Tx/Rx, sleep and battery leakage).