I’m looking for information on how LoRaWAN is managing the frame loss in message decryption with a counter that has changed but not seen. Does it resync based on the SeqNumber ?
More details on my request: LoRaWan encryption is based on a XOR between payload and a key determined by AES encryption with a AppSKey and by a given sequence including the device number (fixed values) + a counter (Ablock) where the counter is incremented on every frame.
So to decrypt the server side need to compute the same key to be used for XORing. This means the counter must be synced. When a frame is loss the counter are going to run out of sync.
Can someone tells me (or give me a link) on how this resync is managed.
Paul
In LoRaWAN 1.0.x, the counter’s 16 least-significant bits (LSB) are included in the full message, and that counter is not encrypted. Also, each message includes a message integrity code, MIC, which is also not encrypted, and which takes the full 32 bits counter into account when being calculated.
The server knowns the last used MSB of that counter, and given the maximum allowed gap between the previous value and current value (MAX_FCNT_GAP, being 16,384), it only needs to try the current value of the MSB, and MSB + 1, to validate the MIC. Next, if it finds a valid MIC then it also knows the full 32 bits counter.
thank you for the quick answer
So FCntUp used for encryption is also used for maintening sequence ID. I did not see any difference in LoRaWAN 1.1. Am I correct with all of this ?
Yes, correct for 1.0.x. I’ve not checked for 1.1, but as LoRaWAN surely does not expect that each packet will be received, I have no reason to think it changed. (Maybe 1.1 sends the full 32 bits counter; easy to validate in the specifications on https://lora-alliance.org/resource-hub).