-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Baremetal LoRaWAN rejoin best pratices #204
Comments
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) 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. |
@marnixcro can you please adjust the the description of the issue following Miguel's input. |
is this still relevant? |
It is. We need to look into this. |
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
The text was updated successfully, but these errors were encountered: