Design problem with rekey indication in LoRaWAN 1.1

[janakj]

There appears to be a minor problem with the handling of the rekey indication MAC command after a LoRAWAN 1.1 Join. When LoRaMac-node receives a Join confirmation from a LoRaWAN 1.1 network server, it schedules a rekey indication MAC command to be piggy-backed on the next uplink. The rekey indication MAC command is stored in a linked-list in RAM.

Suppose the application sends a LoRaWAN 1.1 Join, gets a confirmation, but the device is reset or rebooted before the first uplink could be sent. Upon reboot, RAM contents is lost and so is the information that a rekey indication needs to be sent with the next uplink. The application will keep sending uplinks, but those will not contain the rekey indication command and the network server will (correctly) drop all such uplinks, until the Join state is reverted at some point later.

I am not sure about the best way to fix this. A couple of options come to mind:

• Store the MAC commands to be added to the next uplink in NVM.
• Remember in NVM whether or not a rekey has been completed and check before every uplink. If not, add a rekey indication to the uplink in the function that schedules the uplink. This way, the code will not depend on the RAM contents being preserved between Join and the first uplink.
• Implicitly schedule an empty uplink to port 0 after every 1.1 Join in the LoRaMac-node library. Would most likely need to be confirmed and retransmitted to work reliably.
• Document that the application should send an uplink immediately after 1.1 Join to minimize the probability of losing RAM contents due to MCU being rebooted or put to Standby mode.
• Only transition to ACTIVATION_TYPE_OTAA after a successful rekey. Only at that point the node is considered fully joined.

One elegant solution might be to introduce an additional state to ActivationType_t called ACTIVATION_TYPE_REKEY. After a Join with LoRaWAN 1.1 network server, the MAC would first transition from ACTIVATION_TYPE_NONE to ACTIVATION_TYPE_REKEY. Only after the rekey operation has completed successfully the node would transition to ACTIVATION_TYPE_OTAA.

Since the corresponding MIB variable is already saved to NVM, it could be checked before sending an uplink. If the node happens to be in ACTIVATION_TYPE_REKEY, a rekey indication MAC command could automatically be added to the uplink message.

[mluis1]

Looks to be fixed. Please refer to hardwario/lora-modem#27
Closing the issue. Please reopen it in case of disagreement.