Down link Fcnt sync between server and end-node

[MPC-BlackBox]

I am using the LoRaMac-node-4.4.3.

PROBLEM : How do you make sure the end-node message down counter is in sync with the server?
The function LoRaMacCryptoGetFCntDown in the stack checks the down link message frame count against the end node internal frame counter. Since the message frame count is only 16 bits and the end node internal counter is 32 bits you have to allow for the end node internal counter to overflow.
This creates real issues because if the server 32 bit frame counter and the end-node 32 bit frame counter are out of sync then all further messages are ignored.

You can easily loose sync if the end-node is reset or the server is reset.

Case 1 End node is reset. The function LoRaMacCryptoGetFCntDown will accept the first message 16bit frame count and set end-nodes internal frame count bottom 16 bits but the top 16 bits are left as zero. This means if the server frame counter top 16 bits is non zero the end-node will never accept messages.

Case 2 the server is reset. This is a real problem as the function LoRaMacCryptoGetFCntDown will increase the end node internal top 16 bit frame count if the 16 bit message frame count is lower than the end-node bottom 16 bit frame count. This means the end-node looses sync and will never recover. All further messages are ignored.

Are there any suggestions to keeping the server/end-node in sync?

Kind Regards,

Melvin.

[altishchenko]

Hello Melvin,
This is a LoRaWAN protocol security feature. First of all, network server and the end node must keep the counters in the persistent storage - flash, nvram, etc.
This is especially true for the ABP mode. There is a mechanism in 1.0.3 specification, that allows for a certain message gap to allow for the lost frames.
Most network servers allow the counters to be reset during the OTAA Join procedure.
If your device resets on its own and has no persistent storage it must utilize OTAA and it still must make sure that the Nonce value used in OTAA Join procedure never repeats itself.
Have a look at the SecureElement functions in the library - they are called at certain points in execution when the persistent part of the security context is updated - they are your gateway to NVRAM/FLASH.