can you develop a bit, please?
I will give more context here to discuss on…
We used to use ABP, but up/down counters management was a pain to deal with… my device is an actuator, with periodic reporting of its state, not a class A sensor, just to give more context…
With ABP, we had only strictly growing counters, but a serious problem occured, when there was either outage of the network server, or worse, something did not go well after for example an update and we did not have the information about current state of the up/down counters.
With OTAA + join procedure, this problem is gone. The device is using unconfirmed messages to report its state, but from “time to time” it send a confirmed message and keeps sending confirmed messages up until it gets an acknowledge back. After a certain threshold it decides, it got “disconnected” and re-tries to join.
We also introduced periodic re-joins with a period of a week or so, to be sure the device eventually joins, even if the mechanism mentioned above does not work for some reason. This gives theoretically ~60 rejoins per year, which is ok, if our limit is 65535, but there is a limit…
That is why I strongly consider using the clearing, but maybe I could increase the period from 100days to something even higher. More “nonces” get for example consumed, when the join fails or when there is some longer outage of gateways in the network or worse, outage of the network server - in this case, the device re-tries joining with a certain period and consumes more than ~60 nonces per year.