a client of mine is installing sensors on single gateway deployments for agri-tech purposes. The gateways are on LTE backhaul and Solar power. So GW downtime and network latency are a reality.
There are maybe 30 sensors on a gateway. They are transmitting non-ACK packets every 10 minutes with ADR. (we are using a private network server, not TTN by the way).
Currently I have the devices on OTAA and setup to do a LinkADRReq every 5-6 hours with a threshold of 2 failed attempts (LinkADRAns not received) before restart and rejoin.
So when a device tries to re-join, and there is no GW, it will attempt to rejoin aggressively for a few hours and than it will decrease the attempts until it tries maybe once every few hours. So the gateway can be backup but it won’t be for a few hours until the device re-joins and starts sending sensor data again.
What I am thinking here is that, for this use-case, perhaps it is best for me to do ABP authentication method instead, and to eliminate this whole join process which might cause me data-lost issues, joining problems and etc.
That said, it is worth considering that OTAA doesn’t get you as much as might be assumed.
Particularly in the case where you are able to load credentials and appropriate network settings into devices before deploying them, there’s not a whole lot offered by OTAA that solves problems that actually need solving.
The one thing it’s tempting to think is being offered is immunity from the frame counter reset problem, but in reality that problem is just re-created with the join nonce re-use problem - you can’t actually build a compliant LoRaWAN node without a reliable memory of what values have been used before, either frame count or join nonce as applicable. In theory join nonces should be used enough less frequently that storing them in EEPROM is probably within write limitations, but if you have a behavior where a device starts aggressively joining when it gets no response, that might not be true. You might even exhaust the range of values.
Another way of thinking about it: what do you hope to accomplish by doing a re-join? Having a gateway go down and come back up doesn’t require that, because gateways aren’t actually participants in the protocol which hold any state; what would require a new join is having the network server lose the database of device sessions. The design goal is more likely about roaming to a different network provider, something it doesn’t sound like you’ll face in your application.
(Incidentally if you are using LTE you might consider increasing the RX window delay in your static configuration - there seems very little reason not to, if used with a jit-capable packet forwarder and a network server that knows the gateway can thus buffer packets ahead of their send time it buys you some protection from backhaul delays, and with ABP you can’t really change it once a node is in the field)
@cslorabox thanks for the detailed answer, I know this isn’t TTN related, but I find this forum to be the most active and knowledgeable place for lorawan discussion, and I think my question can easily be valid for TTN/TTI installations as well.
So yea thanks for expanding my understanding here about OTAA and indeed it might not be required at all for this use-case. And indeed it might be causing more issues than solving them for us.
I need to figure out about the packet counter, and if I can ignore it or not.
I setup a couple of devices now testing this method, I will try various scenarios and report back here.