If there is a possibility that the End-device may need to generate more than 65,536
Join-requests in its lifetime, then the End-device SHALL be configured with multiple
AppEUIs, and the End-device SHALL switch to another AppEUI upon consuming the
whole DevNonce space of a given AppEUI.
This document is using the old term “AppEUI” instead of “JoinEUI”, so is the document completely obsolete? My takeaway from this document would be a change to “JoinEUI” would give a fresh DevNonce space but that doesn’t make much sense to me.
Is flushing the OTAA DevNonces for a device the only solution once the space is exhausted?
I believe so, but someone more familiar with ChirpStack internals can probably answer definitively. There shouldn’t be any automatic expiration of nonces, for example.
But backing up the original topic…
I recommend handling it by avoiding it entirely. In what scenarios are you filling the DevNonce space for a device? I see this most frequently when device firmware has been (incorrectly) coded to perform a join before every uplink.
I’m working with class C devices which are not hyper focused on conserving power so they are probably doing too many rejoins. The devices don’t join before every uplink but they do reboot/reset from time to time and when they reboot/reset they will always try to rejoin. If they reboot/reset and the gateway happens to be down as well the device will repeatedly try to rejoin. Currently the device rejoin period is 5 seconds in this case.
Based on your feedback I’m thinking I should be implementing the following:
Don’t attempt a rejoin on reboot/reset. Store everything needed to continue on reboot/reset under the assumption that nothing has changed on the network. Only rejoin when absolutely necessary. If the gateway is ok, reboots introduce no new rejoins.
If rejoin is really necessary because stored parameters no longer work or gateway is down, make the device smarter about rejoins and backoff retry interval.
A couple points of very generalized advice, since I don’t know anything about your device or use case:
This would work, my only concern would be that users might expect a rebooted device to behave the same way as a fresh power-on (i.e. clean slate). Although maybe you’re including power-on in this approach.
Both of the above are good ideas.
Regardless, I would check the logs/LoRaWAN frames tab to verify you’re seeing as many rejoins through to ChirpStack as you think with the current behavior. Unless your use case expects poor gateway connectivity for some reason, I would expect joins/rejoins to be rare occurrences.