Baremetal LoRaWAN rejoin best pratices

[mcserved]

Summary:

Most of the LoRaWAN applications retry join attempts after a set amount of time since they try to rejoin (after being denied the first time) on sending. But this does not adhere to best practices as there is not backoff (or jitter) implemented in most applications. basic_lorawan for instance will rejoin periodically on APP_TX_DUTYCYCLE. This can lead to problems when large deployments are reset, as it can hog the network, with the potential of none of the devices being able to join. This is related to #106.

Why do we need this?

This is considered a best practice for LoRa as it helps with use cases with multiple devices.

What is already there? What do you see now?

basic_lorawan, secure_element_lorawan, and sensors_lorawan rejoin on a periodic cycle

What is missing? What do you want to see?

Jitter and backoff implemented to randomize (and constantly increase) rejoin times, optionally configurable in app_conf.h with a max, which was done for freertos_lorawan. It only needs to target rejoins and have a reasonable max value to not interfere with development and regular use cases.

How do you propose to implement this?

Use a randomizer function and wait this amount of milliseconds on rejoins (jitter), which increases over time (backoff)

Environment:

Baremetal

Acceptance Criteria:

Network rejoins don't happen based on a set value, but use jitter and backoff.

What can you do yourself and what do you need help with?

All

[mluis1]

Just for info the MAC layer already implements the Join back-off as specified by the LoRaWAN specifications chapter "7 Retransmissions back-off" (The seen behavior is like the duty-cycle enforcement)
This feature is always enforced.

The only thing that is required at application level is to insure that the end-device transmissions are randomized.

[mcserved]

Just for info the MAC layer already implements the Join back-off as specified by the LoRaWAN specifications chapter "7 Retransmissions back-off" (The seen behavior is like the duty-cycle enforcement)
This feature is always enforced.

The only thing that is required at application level is to insure that the end-device transmissions are randomized.

You're right, it's not a problem with the mac layer's implementation but rather on the device level application since basic_lorawan will join (after the initial failed attempt) when trying to sent, and the timing is set by APP_TX_DUTYCYCLE (which is set at the mentioned 10s). Thanks for pointing that out, I'll try to be more clear in the description next time.

[elsalahy]

@marnixcro can you please adjust the the description of the issue following Miguel's input.
Mainly concerning the need for backoff.

[NicolasMrad]

is this still relevant?

[azerimaker]

It is. We need to look into this.