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

1. 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.
2. 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...
3. 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).
4. 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...
5. 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.
6. 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:

• ForwardUplinkReq/ForwardDownlinkReq are the end-device's UL/DL packets encapsulated by the relay and forwarded to the network over FPort 226.
• UpdateUplinkLinkReq is 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.

Main pre-requisites

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.

For relays

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. To learn more about battery requirements of both relays and end-devices, see the power consumption calculator.

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 a ThingPark subscription can only serve end-devices belonging to this same subscription, not those belonging to other subscriptions.

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.

Supported use cases and known limitations

As of ThingPark release 7.3.6, the following use cases are supported:

• OTAA end-devices under the exclusive coverage of one or several relays.

  In case of several relays, the nearest relay to the end-device is selected by the network server. This best relay is selected according to the end-device/relay link budget, evaluated during the end-device's join cycle by comparing the ESP of each relay forwarding the device's Join-Request message.

  Important

  To avoid WOR ACK collisions, an end-device cannot be associated with more than one relay at the same time.

• OTAA end-devices under a mixed coverage of conventional gateways and relays.

  In this case, the uplink packets received by conventional gateways (direct mode) + the best-serving relay (relay mode) are deduplicated by the network server. To maximize the delivery success rate of downlink packets, whenever possible, the network server leverages the mixed mode to send downlinks to the end-device via both the best-serving gateway (over the device's RX1 or RX2 slot) and the relay (over RXR slot).

• Thanks to the automatic discovery mode supported by the LoRaWAN relay protocol, end-devices may be served in relay mode without initiating a new join cycle. Example of use cases:

  • A new relay is installed close to an existing end-device to improve its RF coverage.
  • A moving end-device enters the relay's coverage area.
  • Relay replacement, for instance due to hardware failure.

  This automatic discovery relies on the relay notify the network server of the presence of a new device through the NotifyNewEndDeviceReq MAC command.

  When a new relay is deployed to enhance the radio coverage of an existing end-device that is already served by another relay, the end-device switches to the new relay without initiating a new join cycle.

The following limitations apply to ThingPark release 7.3.6:

• Only OTAA end-devices may connect to ThingPark via relay, ABP mode is not yet supported.
• Among the relay-specific MAC commands defined in the LoRaWAN technical specification TS011, only the UpdateUplinkListReq/Ans, NotifyNewEndDeviceReq/Ans and CtrlUplinkListReq/Ans pairs are currently supported. Other MAC commands will be progressively supported in the next ThingPark releases.
• Since the MAC command pair RelayConfReq/Ans is not yet supported, the relay mode must be locally activated in devices acting as relays.
• Only the default WOR channel is supported since the MAC commands required to configure a second WOR channel are not yet supported in this release.
• Due to a known limitation of the v1.0 LoRaWAN relay protocol, the automatic discovery mechanism based on NotifyNewEndDeviceReq MAC command does not work in case of DevAddr collision (that is to say, the same DevAddr is shared between several devices). Therefore, if the DevAddr included in the relay's notification is used by more than one DevEUI, the network server ignores the NotifyNewEndDeviceReq command.

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 F symbol on its logo; such as and for uplink and downlink packets respectively.F stands 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 226 Relay.
  To make traffic analysis simpler, WLogger displays the content of ForwardUplinkReq and ForwardDownlinkReq payloads 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.

Power Consumption

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).