EXTENDING LoRaWAN®
COVERAGE WITH RELAY
Thior Santander – Actility
Davide Orifiamma – Semtech
March 15, 2023
LoRaWAN® LIVE
WHY A LoRaWAN® RELAY
2
With only gateways, cost of
coverage may become too high
when only few end nodes at the
edge* of the network must be
connected
# Sensors covered
100%
95%
Reduce infrastructure CAPEX to
ensure target coverage at the edge
Low cost network
extender for few
devices at the edge
# of gateways (CAPEX)
*Meaning edge of coverage,
i.e. devices slightly out of coverage
LoRaWAN® RELAY REQUIREMENTS
3
Gateway
 Low power & low cost
 Architecture equivalent to a LoRaWAN end-device
 Battery powered
 The relay is capable to handle at least 10 LoRaWAN end-devices
 The relay appears as a standard LoRaWAN end-device
LoRaWAN
Relay
 The relay is secure as a LoRaWAN end-device
 End-devices working under a relay shall be capable
to revert back to traditional LoRaWAN configuration
LoRaWAN
Relay
Generic Sensor
end device
LoRaWAN
Relay
Generic Sensor
end device
PRINCIPLE OF OPERATION – CHANNEL SCAN
• 1 mandatory channel. Frequency and DR are
defined by region:
CAD
WOR
Default
Channel
CAD
• CAD : Channel Activity Detect
6
CADPeriodicity
Time
Only default channel
• SF10 BW500 in USA and Australia
• SF9 BW125 (EU868 / AS923 / …)
CAD
CADPeriodicity
• CAD period goes from 25ms to 1s (default
value)
CAD
CAD
WOR
Second
Channel
CAD
• 1 second channel freely defined by Network
Operator.
WOR
Default
Channel
CADPeriodicity/2
Default and second channel
Time
PRINCIPLE OF OPERATION – OVERVIEW
7
Send by relay
Send by ED
• WOR : Wake On Radio
• RXR : Relay reception window
WOR
WOR
ACK
R
X
R
LoRaWAN®
Uplink
18 s
• WOR ACK: Wake On Radio Acknowledge
• WOR specification:
• Variable preamble length (up to 1 s)
• 2 type of frame
• Join-Request
• Uplink
• Contain information about the following LoRaWAN® frame (frequency and datarate)
PRINCIPLE OF OPERATION – WAKE ON RADIO ACKNOWLEDGE
• Sent by the relay only to WOR Uplink
• Contains following information:
• Data rate between relay and NS
• Relay XTAL accuracy
• CAD periodicity
• Toffset
• CAD To Rx delay
• Forward capacity
Help to reduce WOR preamble length
with synchronization mechanism
8
MESSAGE FORWARDING - UPLINK
End-Device
Relay
WOR
C
A
D
RX
9
RX
LoRaWAN®
Uplink
R
X
1
WOR
ACK
RX
Uplink +
metadata
Network Server
/ Gateway
RX
R
X
2
RXR
R
X
1
or
R
X
2
Downlink
Downlink +
metadata
time
• Relay forward uplink
• On dedicated FPORT 226
• With metadata (Uplink RSSI/SNR/DR and WOR channel)
• Fix timing between end of uplink and forwarded uplink
MESSAGE FORWARDING - DOWNLINK
End-Device
Relay
WOR
C
A
D
RX
Network Server
/ Gateway
10
RX
LoRaWAN®
Uplink
R
X
1
WOR
ACK
RX
Uplink +
metadata
RX
R
X
2
RXR
R
X
1
or
R
X
2
Downlink
Downlink +
metadata
time
• Relay receives end-device downlink on RX1/2 and forwards it to the end-device on RXR
• RXR window parameters are:
•
Open 18s after end of uplink
•
Frequency of WOR frame
•
Data rate of LoRaWAN® Uplink
SECURITY
• RootWorSKey is computed for each end-device
after a successful Join-request.
11
NwkSKey
• The RootWorSKey is transferred to the relay to
allow secure relay transaction.
 A relay can only decrypt the WOR frame, not
the LoRaWAN® uplink.
RootWorSKey
• WorSIntKey and WorSEncKey are derived
locally and used to compute the WOR MIC and
encrypt/decrypt the WOR payload.
WorSIntKey
WorSEncKey
BATTERY LIFE SIMULATION – LoRaWAN® RELAY
CAD every 1s with 10 end-devices:
- sending 50 bytes every hour
- receiving 20 byte once per day
Default channel only (SF9 BW125)
- SF9 BW125 for WOR and LoRaWAN® exchange
Estimated battery* :
•
1 channel (default) : 10 years (1 x SAFT LS 33600)
•
2 channel : 7.5 years (1 x SAFT LS 33600)
Default channel (SF9 BW125) +
Second channel (SF7 BW125)
* : ±30 ppm quartz on relay and end-device. Refer to AT-cut XTAL or MCU XTAL
calibration procedure. Estimation done for a SX1261
12
LoRaWAN RELAYS IN ACTILITY THINGPARK
ThingPark offers a state-of-the-art implementation of the MAC layer
•
For the Relay:
• RF macro diversity (relay coverage through multiple gateways) including uplink frame deduplication
• Advanced ADR mechanisms, offering the best trade-off between QoS (packet error rate) and Relay’s battery consumption
• 100% configurability through the LNS, over the air
• Smart selection of the best gateway to route downlink packets to each Relay
• Optimum selection of the Relay’s DL receive window (RX1/RX2), based on link budget, DL capacity and backhaul latency
• Replay attack detection and mitigation
•
For the End-device:
• Support the hybrid/mixed mode, i.e., the same End-device may
be served in both direct (through a conventional gateway) and
relay (through a Relay equipment) modes
• Automatic selection of the best-serving Relay, in case of high
Relay density
• Both ABP and OTA activation modes
• Support both stationary and mobile End-devices
14
RELAY DEMO WITH THINGPARK
(1/3)
Direct connection blocked by configuration
End-device
(Mbed Shield SX1261MB2xAS)
DevEUI: 5911111111111111
Relay
(Mbed Shield LR1110MB1LCKS)
DevEUI: 5811111111111111
LoRaWAN gateway
(Kerlink iFemtoEvo)
•
US915 ISM band (EU868 band also supported)
•
Both End-device and Relay use OTA activation mode, End-device joins the network through the relay
•
ThingPark packet sniffer (aka Wireless Logger) displays encapsulated messages (Fport 226) for the
Relay and decapsulated messages for the End-device
15
RELAY DEMO WITH THINGPARK
(2/3)
16
Relay sends JoinAcc to End-device
LNS updates Relay
with device’s relay-key
+18 sec (RXR)
Relay sends
encapsulated J.R. and
receives encapsulated
J.A.
End-device Join-Req
Relay is configured
Relay is joining
RELAY DEMO WITH THINGPARK
(3/3)
17
Relay forwards the downlink
ACK to the device (RXR)
LNS answers the Relay (RX1)
+50 msec
Relay forwards the UL frame
using Fport 226 and Channel #3
End-device sends an uplink
frame in “Confirmed” mode
(using Channel #1)
18
THANK YOU!
LoRaWAN® LIVE