¶ LoRaWAN corner cases - Motivation
When OTAA is used for connection of an end device, it is reasonable to have a method allowing to restart the connection (join) procedure when it is lost. It can be lost by somehow loosing the security context on server-side (LoRaWAN Network-Server database disaster) or simply the device may be moved out of range of given network server. One option would be to handle the reconnection or re-join in user's Lua script, however it is also possible to setup internal counters allowing to obtain "smart" behavior transparently from ACR-CV. (e.g. user can simply call api.loraSend() without taking care of any kind of join request sending whatsoever).
¶ Parameters
The parameters have a default value and can be modifies using the api.loraSetup() function.
Please refer to Lua API documentation for detailed description of default values and exact names of the variables.
¶ Algorithm of recovery
Following communication diagram shows how a device, which joins a network server and from user Lua script keeps sending only unconfirmed messages is internally force to send a confirmed message once in every OTAA-MINIMAL-CONFIRMED-PERIOD-th nessage. If such message is not confirmed by the Network Server, then when the user Lua application script sends another unconfirmed message again, this is again forced to be sent in the confirmed mode. If more than OTAA-REJOIN-CONFIRMED-FAILED-COUNTER messages is not confirmed, then the devices jumps back into the not-joined state and tries to join before further message sending.
All described behavior above happens when the user only calls the api.loraSend() function. It is also possible to set the internal variables (OTAA-REJOIN-CONFIRMED-FAILED-COUNTER, OTAA-MINIMAL-CONFIRMED-PERIOD) to such value, that the "smart" algorithm is not used and join can be controlled only by calling api.loraJoin(), however we recommend to keep those variables at least at certain higher value to have "backup" in case there is a corner case in the user Lua script.
The following diagram shows, how the OTAA-MINIMAL-CONFIRMED-PERIOD variable is used to force re-join once in x days. This is an alternative approach how to re-establish a potentially lost connection/security context between the end-node (CV) and the Network Server.
