We are having latency issues with our lorawan setup recently as we are scaling and we think it is due to the airtime limitations of lorawan. Our system devices are set up to send small data packets once an hour. If this is not acknowledged by the server it will be saved in a backlog and retry in an hour again. Then old messages from backlog is sent, if acknowledged, the newest messages are sent 15 secs later and this continues if there are more in the backlog. We save up to 169 messages in backlog, so if full this can mean the device is transmitting for over 40 mins every 15 seconds until it has finished. We also need to take into account we, on average, have 100-150 devices per gateway in a regular setup.
I feel this is causing us issues with channels being blocked due to traffic restrictions is in the link below:
We strongly recommend DO NOT USE CONFIRMED uplinks! Whilst allowed in the spec’s you will realise of course that when TXing the downlink with your confirmation you are rendering the GW deaf to any uplinks from the other devices…which then dont get to see a confirmation as no uplink received so they try again and so it compounds and a complete $41t$t0rm of messgaes that are not doing what is needed and overlay each other…you effectively create a DOS attack on your own deployments…and worse still if a shared resource like TTN GW’s used by the community you are DOSing everyone else and of course the retrys consume precious resource - RF spectrum used by everyone. In short your system is bady architected and poorly crafted and is pushing LoRaWAN to its limits. The GW will max out once it hits its own TX duty cycle limits (and no longer downlink to anyone, no one can get a join ack, no MAC commands to optimise node behaviour, ADR etc.) in short - self inflicted wounds I’m afraid!
That likely can never realistically be used/recovered - again poorly designed IMHO - sounds like you need to engage with someone who can guide you wrt what is practical using the technology. Look at windowed schemas using a small number of prior messages (3, 4, maybe 5?). What are you monitoring that is so critical as to need all that history?
When you say traffic restrictions, you obviously mean the law, not some arbitrary set of rules, but the commonly agreed legal boundaries.
But including all Jeff’s comments above, there is how you manage to experience such packet loss - because even with 150 devices using confirmed uplinks, you shouldn’t be seeing so much in the way of dropped packets in the first place.
So you’d benefit from looking at the signal quality & current DR/SFs to see if you actually need three or more gateways because of the potentially spread out geographical area.
To underline your marvellous piece of self-sabotage, once devices start not hearing acks back, they all get shouty which actually makes the problem far worse, it would be interesting to see the stats to see where the tipping point is that causes devices that were OK to be dropped in to the pool of doom.
A better approach would be just to do unconfirmed uplinks. I guess that you store your data in some kind of database? Since you already have a queue of old messages that have been sent, what you instead could do is to have a function in your backend that checks for jumps in your frame counter for each device.
Then you can just request the missing frame counters with a downlink, to get your device to send the lost packets. Remember to set a threshold, so you only can request a packet maximum X times etc, and you can request multiple packets within a single downlink for each device.
This also solves the issue in case your gateway goes offline, then you are still able to get hold of all the lost packets.