Uplink FCnt 32 bits


We use ABP devices that have 32-bit FCnt, but in the LoraWAN 1.0.x specification, only the 16 LSB of the counter is transmitted. So, LoRa Server has to “guess” whats is the upper part (16 MSB) of FCnt to calculate MIC correctly.

So if device is never seen before (or the Skip FCnt validation is active), LoRa Server should not try all possible 65,536 values for MSB until a valid MIC is found? Since that if this device is already in network a long time, the 32 bits Fcnt is possible over 65535.

I had look on the LoraServer source code, and the validation process described in device_sessions.go and phypayload.go seems to me that validation only test the Fcnt + gap, not all possibilities.

In resume: since all devices in our tests are 32 bits FCnt thas is bigger the 65535, and the uplink package is always Unconfirmed, I don’t see how to sincronize the ABP devices and LorServer without reset the end device FCnt.



LoRa Server does not guess, internally it keeps track of the 32 bit frame-counter. Please see the unit-tests of this and “resolves” the full 32 frame-counter from the communicated 16 bit frame-counter, before it calculates / validates the MIC.


Yes, its keep tracking, but assume the following situation:

1 - Device, ABP, reset FCnt (=0x00000000), installed on a remote point, never receive by gateway
2. Few months later, the FCnt of the device is 0x00456789.
3 - The device now is in a range of a gateway, and the uplink finally arrive at Loraserver (1o packet that LoraServer received by gateway).
4. The uplink FCnt arrive at value 0x6789, 16 LSB, but the MIC is calculate from 32 bits value 0x00456789
5. How LoraServer knows the 16 bits MSB value of FCnt is 0x0045, in order to calculate the MIC ?