Issue link: https://read.uberflip.com/i/1539840
Developing LoRaWAN Devices Technical Recommendation TR007-1.1 ©2021-2025 LoRa Alliance ® Page 16 of 28 The authors reserve the right to change documents without notice. contact control (power on/off, re-Join, etc.). Should an earthquake occur near a large 505 population of end-devices, it is probable that they will all simultaneously reboot and initiate the 506 Join Procedure. The fact that these messages are all sent simultaneously could overwhelm 507 the gateway front ends, the gateway backhauls, or even the Network Server or Join Server. 508 In this case, no response would be sent, causing the end-devices to again send the Join- 509 Request. In the worst case, the end-devices react by sending the requests at an even faster 510 pace to try to quickly receive a response. When large groups of end-devices behave this way, 511 it can lead to a condition in which the network cannot service any of them. 512 There are many such trigger events that can impact any end-device and any network, some 513 first order (like an earthquake or power outage), others second or third order (a chain of 514 conditions that ultimately lead to the collapse). As a result, mitigation techniques need to be 515 universally implemented. 516 Any time the end-device sends an uplink that requires a response (ACK, Join-Accept, MAC 517 Command response, Application-Layer response, etc.), an opportunity for congestion collapse 518 is introduced. If the end-device reacts to the lack of response by sending another uplink that 519 again requires a response, then it SHALL implement techniques to avoid instigating a 520 congestion collapse. 521 Even end-device communications that do not demand a response can lead to temporary 522 collapse if the end-device enters a mode where it dramatically increases the pace at which it 523 sends uplinks for an extended period of time. 524 4.8.2 Recommended Practice 525 Whenever possible, end-devices SHOULD use communication techniques that do not require 526 responses. In addition to avoiding congestion collapse, this technique also preserves the 527 downlink capacity of the network, which for LoRaWAN networks is less than the uplink 528 capacity. 529 End-devices SHALL use the randomization techniques of both transmit time and channel 530 described above to avoid synchronous transmissions among groups of end-devices. This will 531 help mitigate the temporary congestion possible even when responses are not requested. 532 In response to a missed response, the end-device SHALL decrease the pace of transmission 533 (increase the periodicity of transmission). A reasonable back-off strategy described in [TS001- 534 1.0.4] is reproduced here: 535 Uplink frames that: 536 • require an acknowledgment or answer from the Network or an Application Server 537 and are retransmitted by the end-device if the acknowledgment or answer is not 538 received 539 and 540 • can be triggered by an external event causing synchronization across a large 541 (>100) number of end-devices (power outage, radio jamming, network outage, 542 earthquake…) 543