Document

TR016-1.0.0 LoRaWAN Relay Technical Recommendations

Issue link: https://read.uberflip.com/i/1546053

Contents of this Issue

Navigation

Page 16 of 19

LoRaWAN ® Relay Technical Recommendations TR016-1.0.0 ©2026 LoRa Alliance ® Page 17 of 20 The authors reserve the right to change specifications without notice. 5 Practical Constraints 355 5.1 Relay operation in US915 356 Since the maximum allowed frame payload size for DR0 in US902-915 band is 11bytes, relays 357 deployed in this band SHOULD NOT use DR0 (SF10/125KHz). 11 bytes is not enough to 358 forward an encapsulated LoRaWAN uplink packet together with its metadata. 359 5.2 Network time synchronization 360 For end-devices under Relay and using the DeviceTimeReq MAC command, the network 361 access mechanisms that may be used by Relay, such as a value of NbTrans greater than 1, 362 the use of CSMA [TR013], or the use of LBT could impact the time accuracy provided to the 363 end-device. 364 This timing inaccuracy is dependent on the transmission delay of the forwarded uplink 365 received by the Network Server relative to the minimum delay of a single forwarding uplink 366 (i.e., RELAY_FWD_DELAY after the relay's reception of the original uplink). 367 In the worst case, the error is equal to RXR_DELAY - RECEIVE_DELAY1 (typically 13 368 seconds if RXR_DELAY=18 and RECEIVE_DELAY1=5) 369 5.3 Relay operation constraints 370 Although the LoRaWAN Relay is behaving like a special end-device from the Network 371 perspective, LoRaWAN end-devices SHOULD not behave like Relays leading to a single-hop 372 mesh network. Indeed to keep network capacity optimized, multi-channel multi-datarate 373 LoRaWAN Gateways SHOULD always be the dominant deployment model. 374 However, the LoRaWAN Relay MAY send some specific application frames (with FPort 375 different from 226) in addition to the frames related to the relaying function. 376 5.4 ADR mechanism for end-device under Relay 377 The NS SHOULD have an ADR algorithm dedicated for end-devices served by a Relay. 378 Since any relayed LoRaWAN uplink packet is preceded by a WoR frame, having a NbTrans 379 (for the relayed end-device) higher than 1 is not efficient. Therefore NbTrans SHOULD be 380 equal to 1. 381 The data rate of the standard LoRaWAN uplink SHOULD be optimized depending on the link 382 quality (based on the meta data forwarded in the encapsulated packet) between the Relay 383 and end-device. 384 More specifically, the NS SHOULD not assign a data rate for the end-device transmission of 385 the relayed LoRaWAN uplink that is well below the data rate of the WoR channel. 386 NOTE : For example, if the WOR Channel is using SF9 / 125 KHz, then the DR of the standard 387 LoRaWAN uplink, should not be lower than SF10 / 125 KHz. 388 5.5 Relay Notifications 389 The WOR frame of an end-device could be received by several relays operating in the area, 390 leading these relays to send the NotifyNewEndDeviceReq notification to the network, 391 possibly simultaneously, which might produce collisions. 392 To avoid this scenario, the relay SHOULD introduce a random delay, not greater than 10 393 seconds, before sending the notification to the network. 394 In addition, the relay SHOULD decrease the number of notifications sent for a given end- 395 device if it keeps receiving its WOR frames without receiving any update from the network. 396

Articles in this issue

view archives of Document - TR016-1.0.0 LoRaWAN Relay Technical Recommendations