OTAA best practice: how to not join every time?

[arjanvanb (Arjan)]

@brulath

Some things to monitor:

• Uplink and downlink counters must be tracked
• Network and app session keys, device ID, etc. must be tracked
• Adaptive data rate state including target data rate, ADR ack counter, etc. must be tracked
• Joins can provide channel plans which must be tracked
• MAC commands which change settings/channels/frequencies/rx frequencies/max EIRP/etc. must be tracked
• MAC commands which require a response (i.e. request battery level/RSSI) must either be serviced immediately or tracked
• (there’s more I can’t recall off-hand)

And:

• Channel usage for proper channel hopping.
• Channel usage for regional duty cycle limitations.
• Very much part of your second-last bullet, but just to make it explicit for future readers: pending confirmations for confirmed downlinks.
• For LoRaWAN 1.0.x: maybe all used values for the OTAA DevNonce; see OTAA shows "Activation DevNonce not valid: already used".
• For LoRaWAN 1.1x: the OTAA join counter (nonce).

As an aside, since version 1.0.0 the RN2483 mac save command saves much more, and does include the frame counters, but no mention of the pending MAC command responses. (But maybe more recent versions even include that?)

See also How to persist LMIC OTAA parameters with an ESP32?