Description
According to LoRaWAN 1.02, section 7 (page 37), lines 21 and following:
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 example using a pseudo-random generator seeded with the device‘s address)
A table that follows is hard to read, but it apparently shows the following:
| Period after starting JOIN attempt | How long to back off | Duty-cycle limit |
|---|---|---|
| First hour | base delay + (0 to 1) seconds | less than 36 seconds in first hour |
| Next ten hours | base delay + (1 to 11) seconds | less than 36 seconds in this ten-hour period |
| Subsequent 24-hour periods | base delay + 11 + N seconds (incremented once/day) + ( 0 to 24) | less than 8.7 seconds per 24h period |
The base delay is called T0 in the specification and is not used expect on that page. I believe that the implementation can choose it, but it's not clear.
In any case, the LMIC implementation doesn't do anything like this. Apart from bug #1, which leads to fairly unpredictable behavior once the first JOIN cycle fails, the delay doesn't take into account any of the above considerations.
Possibly need to consider FRAM storage of the partial join state, as devices that are power-cycling still want to delay joining (if they're in the field).