Issue link: https://read.uberflip.com/i/1539840
Developing LoRaWAN Devices Technical Recommendation TR007-1.1 ©2021-2025 LoRa Alliance ® Page 15 of 28 The authors reserve the right to change documents without notice. detect all Join-Request replays instead of only being able to detect replays of a limited number 470 of random DevNonces. 471 LoRaWAN 1.0.4+ and 1.1+ make this behavior mandatory. 472 4.6.2 Recommended Practice 473 For LoRaWAN prior to 1.0.4, refer to [TR001-1.0.0]. 474 4.7 Avoiding Synchronous Behavior 475 4.7.1 Description 476 To maximize network capacity and message receipt success, it is important that end-devices 477 implement randomness in both the transmission timing and channel selection. Randomness 478 in these two dimensions helps prevent collisions and uplink spikes, which can artificially limit 479 gateway and network capacity. 480 4.7.2 Recommended Practice 481 End-devices SHALL create a pseudo-randomly sorted list of enabled channels and iterate 482 through this list with each transmission. The list SHALL be re-sorted when new channels are 483 enabled or disabled. The end-devices SHALL ensure that the pseudo-random number 484 generators used to create this list are seeded with truly random values to prevent multiple end- 485 devices from systematically using identically sorted lists. Some regulatory regions require 486 every channel to be used equally, and this technique also meets that requirement. 487 End-devices SHALL add a pseudo-random delay to all periodic transmissions (including Join 488 Requests and retransmissions controlled by NbTrans or the application-layer). The end- 489 device SHALL ensure that the pseudo-random number generators used to create this list are 490 seeded with truly properly random values (see [RFC4086] for examples and methodology), to 491 prevent multiple end-devices from systematically using the same delay values. 492 Groups of end-devices SHALL NOT be coordinated to transmit at the same real-time. Even 493 loose coordination of transmit time places undue burden on the network. An example of 494 behaviors to be avoided are: 495 1 Daily uplinks at midnight of a day's worth of sensor readings. 496 2 Weekly validation of the configuration of a fleet of devices to occur with a 12-hour 497 window every week. 498 3 Transmitting subsequent confirmed uplinks, having not received an 499 acknowledgement at exactly 2500 mSec after the previous uplink. 500 4.8 Avoiding Congestion Collapse 501 4.8.1 Description 502 A network congestion collapse occurs when an event triggers widespread and repeated 503 communication attempts. For example, many end-devices use a reed-switch for basic, non- 504