Downlink Payload Sequence Number Not Correct After A Number Of Downlinks Are Sent To End Node

End Devices (Nodes)
1

Hello,

We are having issues with the Sequence Number Not Being Correct After We Issue A Number of downlink commands to our end node. The first three or four downlink commands work. We then issue a another command and the downlink does not work due to the downlink sequence number not being correct. Where does this number come from and why is it not correct. See printout below from our end node when a downlink command is issued to our end node.

OnRadioRxDone 17 -58 23

60 17 23 02 26 00 00 00 01 AF B8 3C B9 E9 66 3E

EA

macHdr.Bits.MType 3

sequenceCounter 0 sequenceCounterPrev 0 sequenceCounterDiff 0 0

downLinkCounter 0

downLinkCounter 0

sequenceCounterDiff 0 phyParam.Value 16384 0

OnRadioRxDone 17 -55 27

60 17 23 02 26 00 00 00 01 AF B8 3C B9 E9 66 3E

EA

macHdr.Bits.MType 3

sequenceCounter 0 sequenceCounterPrev 0 sequenceCounterDiff 0 0

downLinkCounter 0

downLinkCounter 0

sequenceCounterDiff 0 phyParam.Value 16384 0

OnRadioRxDone 17 -58 24

60 17 23 02 26 00 00 00 01 AF B8 3C B9 E9 66 3E

EA

macHdr.Bits.MType 3

sequenceCounter 0 sequenceCounterPrev 0 sequenceCounterDiff 0 0

downLinkCounter 0

downLinkCounter 0

sequenceCounterDiff 0 phyParam.Value 16384 0

OnRadioRxDone 17 -54 27

60 17 23 02 26 00 00 00 01 AF B8 3C B9 E9 66 3E

EA

macHdr.Bits.MType 3

sequenceCounter 0 sequenceCounterPrev 0 sequenceCounterDiff 0 0

downLinkCounter 0

downLinkCounter 0

sequenceCounterDiff 0 phyParam.Value 16384 0

OnRadioRxDone 17 -54 28

60 17 23 02 26 00 01 00 01 D1 56 EA 78 88 38 94

63

macHdr.Bits.MType 3

sequenceCounter 1 sequenceCounterPrev 0 sequenceCounterDiff 1 1 <-- sequence counter goes to 1

downLinkCounter 0

downLinkCounter 1

sequenceCounterDiff 1 phyParam.Value 16384 0

OnRadioRxDone 17 -54 29

60 17 23 02 26 00 00 00 01 AF B8 2E B9 D9 76 19

6E

macHdr.Bits.MType 3

sequenceCounter 0 sequenceCounterPrev 1 sequenceCounterDiff 65535 -1 <-- next sequence number not right

downLinkCounter 1

downLinkCounterTmp 65536

sequenceCounterDiff 65535 phyParam.Value 16384 1 <- fails and does not process the packet

2

It’s increased by TTN until you reset the frame counters. (Or, for ABP, until you change any of the device settings, which will also reset the counters.) So, it will match the counter you see in TTN Console. In the payload it’s the 7th and 8th byte, LSB.

and why is it not correct.

I assume you did reset the frame counters. Here it’s 01 00, being 1:

60 17 23 02 26 00 01 00 01 D1 56 EA 78 88 38 94 63

…and then here it’s 00 00, being 0:

60 17 23 02 26 00 00 00 01 AF B8 2E B9 D9 76 19 6E

At this point your node’s security rejects the too low of a number. (Also, the first messages show that the counter was not increased at all. I assume you somehow reset the counters in TTN Console for those messages as well?)

3

Arjan,

Thanks for the information. As far as we know we did not reset the frame counters. All that we do is schedule our downlink data and wait for TTN to send the data during the next transmit cycle. How are the frame counters reset? Maybe we are doing something that we are not aware of to reset the counters.

4

I have a hypothesis about this problem. And a question. I know that the TTN console allows one to register a (DevEUI,AppKey) pair to more than one Application AppEUI, but on the other hand, I have read that it is a bad idea to do that. If jlcolemanttn had indeed registered one pair to both AppEUI1 and AppEUI2, is it possible that he would see the counter problem when he is using that node with either AppEUI1 or AppEUI2? I had the opportunity to use hardware from jlcolemanttn and I can confirm that I saw the problem, too. I also verified that setting up my own AppEUI and AppKey with that hardware (DevEUI is fixed) then the problem disappeared. I did not try keeping the original AppKey and only changing AppEUI. If my hypothesis is correct that would beg a 2nd question: should the TTN console block me from registering DevEUI1/AppKey1 to a new Application when that pair is registered to an existing application.

5

I did more tests and I cannot replicate this problem with my own application, so I will cancel my previous hypothesis. Something else is going on.

1 Like