[Piotr Diop]

You’re right ! The behavior is due to having same sequence number in the linkcheckReq and it comes from the fact that my end device reboots in the early boot sequence.

In detail, the failing case goes as follows:
0) The linkCheckReq is set so the linkcheckReq is set for every Tx.
1) My end device joins the network
2) The 1st packet it sends is a confirmed packet + linkcheckReq with a given {fcnt:”N”, seqn:N”}
3) Mac command is answered with {opts:”02xx01} (so far so good)

Then due to software issue the end device reboots and the above sequence repeats.
So MQTT gets mac_recv with {id:”2″} and the exact same fcnt and seqn.
So network server must think this is a repeat packet but since this happens to be an ACK one, it has to answer with {opts:”02xx02}

Thanks for detailed answer !

[Piotr Diop]

See in GUI LoRaWAN > Network Settings > Database > Backup Interval
The default is every 1 hour to backup the database to flash.

The working database is held in RAM to allow faster reads/writes and reduce wear on the flash. It is only backed up periodically to flash per Backup Interval or when the system is shutdown gracefully.

Well that explains why the issue was not reproducible when performing a software reboot or when by only restarting the lora server itself.
Are there some benchmarking stats on flash wear/performance if the backup interval was set to different timings?

The end-devices can check that the network is available by sending a confirmed uplinks periodically. If the network does not respond the end-device can attempt a join to recover.

While that would work well in a small sized network, having hundreds of devices sending confirmed messages at an unpredictable rate would become problematic on the long term.
If I understand correctly the gateway is also subject to duty cycle restrictions (using sliding windows) so this would risk overusing available bandwidth for real downlink messages with the dummy ones used to confirm that the gateway is still alive (which would be the case 99% of time)

But that probably means that, in fine, there is a need to assess per-device what “periodically” means, depending on how often the device already sends a message and how critical it is to lose few chunks of data.

I also noted in the loraWAN spec that there are link check commands which kind of follow the same idea. I guess i’ll try to combine it with your suggestion to solve my issue.

Thanks for your quick answer !

[Piotr Diop]

Just to clarify, I power cycle the gateway by pulling the power cord out, waiting some time, then plugging it back in.

[Piotr Diop]

Thanks for quick answer Jason.
From the mqtt page it seems the syntax is not global, but per eid (lora/<DEV-EUI>/clear).
I just tested publishing to different EUIs and it looks like only messages of given EUIs are suppressed from the queue.

[Author]

Posts