Issue link: https://read.uberflip.com/i/1428395
LoRaWAN ® L2 1.0.4 Specification © 2020 LoRa Alliance ® Page 49 of 90 The authors reserve the right to change specifications without notice. 7 Retransmissions Backoff 1577 1578 Uplink frames that 1579 require an acknowledgment or answer from the Network or an Application Server and 1580 are retransmitted by the end-device if the acknowledgment or answer is not received. 1581 and 1582 can be triggered by an external event causing synchronization across a large (>100) 1583 number of end-devices (power outage, radio jamming, network outage, earthquake…) 1584 can trigger a catastrophic, self-persisting, radio network overload situation. 1585 1586 Note: A typical example of such an uplink frame is a Join-Request if the 1587 implementation of a group of end-devices decides to reset the MAC 1588 layer in the case of a network outage. The entire group of end-devices 1589 will start broadcasting Join-Request uplinks and will stop only upon 1590 receiving a Join-Accept from the Network. 1591 1592 For those frame retransmissions, the interval between the end of the RX2 slot and the next 1593 uplink retransmission SHALL be random and follow a different sequence for every end-device 1594 (for example using a pseudo-random generator seeded with the end-device's address). The 1595 transmission duty-cycle of such a frame SHALL respect local regulations and the following 1596 limits, whichever is more constraining: 1597 1598 Aggregated during the first hour following power-up or reset T 0 < t < T 0+1 Transmit time < 36 s per hour 1% duty cycle Aggregated during the next 10 hours T 0+1 < t < T 0+11 Transmit time < 36 s per 10 h 0.1% duty cycle After the first 11 hours, aggregated over 24 h, where N refers to days starting at 0 T 0+11 + N × (24 hours/day) < t < T 0 + 35 + N × (24 hours/day), N ≥ 0 Transmit time < 8.7 s per 24 h 0.01% duty cycle Table 56: Transmit duty-cycle limitations 1599 1600 1601