FCntUp and FCntDown size

[FoujanetG]

Hi,

The specification says FcntUp and Down can be 16-bit or 32-bit variables , but only the 16-bit LSB are used.

In the FW, 32-bit counters are uased.

What is the benefit?

Is not simpler if end node and server use 16-bit counter?

Thanks a lot.

[kjendal]

The end device must rejoin the network on a counter rollover to prevent reuse of the key/counter combination. Using a 16 bit only counter means that the device would have to rejoin every 65535 frames.

Note: this behavior must be negotiated out-of-band with the network provider today.

-Dave Kjendal, Senet, Inc.

[FoujanetG]

Ok,

when you say "rejoin", it's like a stack reset with ABP or a new join request with OTAA?

Currently, the downLinkCounter in the stack is a 65535, whereas the provider sends a downLinkCounter bigger. My exemple is a endNode sending a ConfirmedFrame, with a very short period to check the behavior of 16-bit counter.
So my endPoint doens't received Acknowledge.

I understand of the loramac.c file ,l.1043, that the roll over is automatically, when the difference between the stack counter value and the provider counter value is bigger than 1<<15

This part of the stack has been checked?

Thanks a lot.

[Smarco10]

Hi all,

When we look at the code in loramac.c:1043:

            sequenceCounter = ( uint16_t )payload[pktHeaderLen++];
            sequenceCounter |= ( uint16_t )payload[pktHeaderLen++] << 8;

            [...]
            sequenceCounterPrev = ( uint16_t )downLinkCounter;
            sequenceCounterDiff = ( sequenceCounter - sequenceCounterPrev );

            if( sequenceCounterDiff < ( 1 << 15 ) )
            {
                downLinkCounter += sequenceCounterDiff;
                LoRaMacComputeMic( payload, size - LORAMAC_MFR_LEN, nwkSKey, address, DOWN_LINK, downLinkCounter, &mic );
                if( micRx == mic )
                {
                    isMicOk = true;
                }
            }
            else
            {
                // check for sequence roll-over
                uint32_t  downLinkCounterTmp = downLinkCounter + 0x10000 + ( int16_t )sequenceCounterDiff;
                LoRaMacComputeMic( payload, size - LORAMAC_MFR_LEN, nwkSKey, address, DOWN_LINK, downLinkCounterTmp, &mic );
                if( micRx == mic )
                {
                    isMicOk = true;
                    downLinkCounter = downLinkCounterTmp;
                }
            }

There is a check of the difference between the two downlink FCnt.
Question is: why checking if the difference is bigger than 32768 (1<<15)? I thought the MAX_FCNT_GAP (16384=1<<14) where the variable which was used as comparison threshold?

Then when the difference is bigger than 32768, it's using the actual downlink counter + 65536 + the difference. in other words it's using the new received downlink counter (old + diff = old + (new - old) = new) + 65536. That means if at the first message we receive a downlink which specify a FCnt which is bigger than 32768, the actual downlink used to decrypt the payload will be the new FCnt + 65536 which has no sens. Or am I wrong?

[mpt8153]

Hi,
I don't understand Downlink and Uplink management in case of Activation by personalization. Reading implementation every time end node will be reset then these counters will be setted to zero and radio frames will be duplicated. I think if server implements strictly LoRaWAN specification will discard messages with uplink counter < of stored one. To avoid this in case of ABP this counters has to be stored in EEPROM? I know this will implies problems with EEPROM writing cycles and will give a limit to end node life.

[djaeckle]

Hi all,

@Smarco10
I double checked the implementation of the downlink counters with unit tests. Here are the results:

First Test case:
Node downlink counter: 0x01
Simuated frame downlink counter: MAX_FCNT_GAP + 2
Difference: MAX_FCNT_GAP + 1
Result: Node accepts the frame. New downlink counter of the node: MAX_FCNT_GAP + 2

Second Test case:
Node downlink counter: 0xFFFF
Simuated frame downlink counter: MAX_FCNT_GAP + 1
Difference: MAX_FCNT_GAP + 1
Result: Node accepts the frame. New downlink counter of the node: 0x1000 + MAX_FCNT_GAP + 1

Third Test case:
Node downlink counter: 0x0000
Simuated frame downlink counter: ( 1 << 15 ) + 1 )
Difference: ( 1 << 15 ) + 1 )
Result: Node accepts the frame. New downlink counter of the node: ( 1 << 15 ) + 1 ). Calculation is:

downLinkCounterTmp = downLinkCounter + 0x10000 + ( int16_t )sequenceCounterDiff;
downLinkCounterTmp = 0 + 0x10000 + ( -32767 ) = 32769

Fourth Test case:
Node downlink counter: 0xFFFF
Simuated frame downlink counter: ( 1 << 15 ) + 1 )
Difference: ( 1 << 15 ) + 2 )

Result: Node accepts the frame. New downlink counter of the node: ( 1 << 15 ) + 1 ) + 0x10000. Calculation is:

downLinkCounterTmp = downLinkCounter + 0x10000 + ( int16_t )sequenceCounterDiff;
downLinkCounterTmp = 0xFFFF + 0x10000 + ( -32766 ) = 98305

I think the implementation is ok as it is. However, as you can see, the validation for a counter difference of >MAX_FCNT_GAP is missing. We will fix that soon.

@mpt8153
Your statement is correct. When the node performs a reset, it the uplink counter resets, too. This is an issue of the specification which must be handled by the LoRaWAN Alliance.

[mpt8153]

*@djaeckle *
"Your statement is correct. When the node performs a reset, it the uplink counter resets, too. This is an issue of the specification which must be handled by the LoRaWAN Alliance."

Ok but at this moment if I want to develop a standard End-Node that it would be interoperable with differents networks including ones working with ABP I will have to store counters in persistent way (like EEPROM)?

[djaeckle]

@mpt8153
This depends on the implementation on the server side. Actually, some servers just reset the counters of the related node, if the node sends a frame with an uplink counter of 1. Other servers implement an additional timeout, in which they don’t accept a second frame with an uplink counter of 1.

[ygaklk]

Hi all,

According to the LoRaWAN_1.0.1/1.0.2, it is not clear about the Fcnt value management :
LoRaWAN - 4.3.1.5 Frame counter (FCnt)
"After [...] a reset for a personalized end-device, the frame counters on the end-device and the frame counters on the network server for that end-device are reset to 0."
in contradiction with:
"The end-device shall not reuse the same FCntUp value, except for retransmission, with the same application and network session keys."

I am agree with the last statement, for security reasons. Thus, I am also agree with @mpt8153 about storing Fcnt in a persistant way. But, if my End-Node has an FcntUp greater than 0x10000, and that the NetworkServer ignore this (due to a new declaration on the NS, or a due to a new NS for example [Fcnt=0x00000 on the NS] ), my End-Node will never never be accepted by the NetworkServer (MIC failed), and there is no way to get out of this situation...

What is the good behavior ?
Is it possible to have a clarification about the LoRaWAN specification ?
Thanks

[ycsunjane]

LoRaWAN™ 1.1 Specification still have no clarification