LoRaWAN Sequence Numbers

[kiwi64ajs]

@bmarkus said in LoRaWAN Sequence Numbers:

If LoPy is not incrementing FCNT it is a bug in the LoRaWAN stack implementation.

Well the issue is my code start, connects and sends the data and then exist. The first run is ok, but any subsequent runs restarts the lora stack and the Sequence starts from 1 again, which is fine for the sender, but the receiving end at the server see packets with the same Sequence number and assumes they are duplicates, which is not so not good from the sender's perspective, but ignoring the duplicate Sequence numbers if not a good thing either from a robustness perspective.

I changed my code to send packets in a loop and the Sequence number IS being incremented each time it goes around the loop, but if I run and then exit and then run again the Stack only send one packet per run and so the Sequence restarts from 1 each time.

Being able to manage (get, persist, restore, set) the Sequence numbers used in the LoRa stack is probably a better approach. That way the developer has some choices about how best to manage this issue.

[somu]

Hello @kiwi64ajs

Thank you so much for your code snippet. We are facing the similar issue of duplication of packets. Did you solved the problem?

[hemalchevli]

Hi Alex,
I was struggling to get the data to server, using your code you shared it worked once, I don't have debug information from the server side. Were you able to fix the issue?
I'm a newbie in python, where can I find the fcnt or sequence number variable?
Thanks
Cheers!

[Antony]

Incrementing the sequence number is mandatory in the LoRaWAN spec, and is necessary for devices to be secure. Hacking this at the Loriot server isn't a good solution. Alex, what you say is right - you need to cache the sequence number counter and then restore it. Or even better, the stack would do it for you.

But I don't see anything in the Pycom LoRa API that makes it possible to do this? For example, it could be done through socket.setsockopt() but there is no mention of this in the (1.8.4) documentation.

Should this be submitted as a bug?

Antony

[bmarkus]

@Antony said in LoRaWAN Sequence Numbers:

Incrementing the sequence number is mandatory in the LoRaWAN spec, and is necessary for devices to be secure. Hacking this at the Loriot server isn't a good solution. Alex, what you say is right - you need to cache the sequence number counter and then restore it. Or even better, the stack would do it for you.

But I don't see anything in the Pycom LoRa API that makes it possible to do this? For example, it could be done through socket.setsockopt() but there is no mention of this in the (1.8.4) documentation.

Should this be submitted as a bug?

Antony

In other cases, like RN2483 sequence number is incremented by the LoRaWAN stack and not by the application.

At the Loriot server it is a great feature to disable sequence number during development, it saves you hours. Agree, in production system it is not adviced.

[kiwi64ajs]

@hemalchevli said in LoRaWAN Sequence Numbers:

Hi Alex,
I was struggling to get the data to server, using your code you shared it worked once, I don't have debug information from the server side. Were you able to fix the issue?
I'm a newbie in python, where can I find the fcnt or sequence number variable?

No and there does not seem to be anyway to really fix this at an application level unless the check at the server is turned off - which is NOT ideal.

The stack could cache the last used number in EEPROM / FLASH and resume from there next time, but we don't have get/set access the sequence number at the API level so I don't know what to do next.

This is a problem when you're trying to develop a product against a commercial LoRaWAN service provider who does have the sequence number check enabled... Guess I need my own LoRaWAN Gateway with the sequence check turned off for now

Alex

[jmarcelino]

I agree these settings should be exposed somewhere (and both the UpLinkCounter and DownLinkCounter!) but please take care if making them restore automatically - and if so definitely make it optional.

The Flash chip is only specced for 100,000 erase/program cycles, so if you're updating the frame counter in Flash every time and you send a frame for example every 5 minutes the Flash would only last one year.

The recommended way is really to use OTAA and do a join at every reset, so you get fresh counter and don't have to worry about this. In this case storing the counters would be of no use.

If you really want to store your counters I suggest some external FRAM (Ferroelectric) which is good for 10 trillion cycles. There are easy to use chips with I2C and ready made breakouts for prototyping.

[bmarkus]

@jmarcelino said in LoRaWAN Sequence Numbers:

The recommended way is really to use OTAA and do a join at every reset, so you get fresh counter and don't have to worry about this

Depends on your use case. OTAA is good for fixed sensor devices, but for e.g. moving mobile devices (trackers) doesn't, there ABP is the proper method.

[hemalchevli]

@kiwi64ajs Yep, I'm developing a product for a commercial LoRaWAN and they have provided a nano gateway from orbiwise and on the server I can only view the data, no server settings are exposed, may be I'll too have a gateway setup for the product demo if this doesn't work.

One more option its to edit and compile the firmware and try exposing it at app level, don't know how that will go, but I'll give it a try.

Thanks again for your code, it really made my day to see that one frame being uploaded to my server. :)
Cheers!!

[jmarcelino]

@bmarkus
I disagree, for mobile devices in particular the advantages of OTAA (provisioning setup inc. counter reliability and added security) outweigh the disadvantages.

Here's a big problem with ABP: imagine you leave an active ABP node outside of reach of a gateway for a while. The frame counter on the node will keep on ticking, increasing the difference between it and what the backend expects. According to the spec once this difference goes over the allowed range (just 16384 packets for TTN) the backend will start rejecting any further packets. If you send a packet every minute this happens in less 12 days, a realistic scenario for a mobile LoRa device.

This would then have to be detected and counters manually reset at both node and backend. A provisioning nightmare if you have devices in the hands of users!

With OTAA once the node receives a join response you can be sure 1) there's coverage and 2) the data you send will match up, no guessing if you have stale encryption keys or frame counters. Also if you receive a fail response from the backend your node can alert the user.

To me there's just a small set of use cases where you really need ABP and for most applications - especially if you're deploying devices to other users and want to sleep at night - OTAA really is the way to go.

[cmsedore]

@kiwi64ajs I've written an add-on for the firmware to allow setting the uplink counter. I need to test it tomorrow (I don't have a functional gateway at home)--assuming it works, I'll create a pull request.

[hemalchevli]

I was able to solve my problem, and now having seamless uplinks and downlinks. There was a issue with my channels settings that the gateway supported.
Also was having issues with pymakr with uploading code to lopy which caused delay in code testing. Now compeletly abandoned pymakr and moved to transfer file using FTP.

[kots]

hello!
Anyone who found how to solve this problem?

[jmarcelino]

@kots
In the latest firmware you can now use lora.nvram_save() to save your current frame counters and then lora.nvram_restore() to restore them again after power-on/reset.

[kots]

@jmarcelino Thanks!
Any idea how they work?

[jcaron]

@kots As @jmarcelino said, just call lora.nvram_save() before going to deep sleep, and lora.nvram_restore() after initialising LoRa but before sending your message.