7 Retransmissions back-off
2
- Uplink frames that:
- Require an acknowledgement or an anwser by the network or an application
- server, and are retransmitted by the device if the acknowledgement or answer is not
- received.
- and
- can be triggered by an external event causing synchronization across a large
- (>100) number of devices (power outage, radio jamming, network outage,
- earthquake…)
- can trigger a catastrophic, self-persisting, radio network overload situation.
12
| 13 | Note: An example of such uplink frame is typically the JoinRequest if |
|---|---|
| 14 | the implementation of a group of end-devices decides to reset the |
| 15 | MAC layer in the case of a network outage. |
| 16 | The whole group of end-device will start broadcasting JoinRequest |
| 17 | uplinks and will only stops when receiving a JoinResponse from the |
| 18 | network. |
| 19 | |
| 20 |
- For those frame retransmissions, the interval between the end of the RX2 slot and the next
- uplink retransmission shall be random and follow a different sequence for every device (For
23 example using a pseudo-random generator seeded with the device‘s address) .The
- transmission duty-cycle of such message shall respect the local regulation and the following
- limits, whichever is more constraining:
26
| Aggregated during the first | T0<t<T0+1 | Transmit time < 36Sec |
|---|---|---|
| hour following power-up or | ||
| reset | ||
| Aggregated during the next | T0+1<t<T0+11 | Transmit time < 36Sec |
| 10 hours | ||
| After the first 11 hours , | T0+11+N<t<T0+35+N | Transmit time < 8.7Sec per |
| aggregated over 24h | N>=0 | 24h |
27
©2016 LoRa™ Alliance Page 37 of 70
The authors reserve the right to change specifications without notice.
LoRaWAN Specification
1 CLASS B – BEACON
2
3 Class B must be considered as experimental in this version of the specification
©2016 LoRa™ Alliance Page 38 of 70
The authors reserve the right to change specifications without notice.
LoRaWAN Specification