As a note on this, if your device shuts down RAM during its sleep mode then you’ll want to make sure you’re saving everything; performing an ABP join is not sufficient to restore a LoRaWAN client state properly. It may work on TTN, for now, but it’s not likely to work anywhere else (and may not be sufficient in the future for TTN).
As an example, there’s a MAC command to request the battery level and RSSI (gateway to node) from the node. If you receive that command you have to either respond immediately or keep track of the request for the next time you transmit. Other MAC commands can change the channels available, RX frequency on a per-channel basis, RX windows, max EIRP, mask out channels, etc. Not tracking these may result in communication loss.
Adaptive Data Rate (ADR) information is lost if you don’t keep track of it. If the server instructs your device to use DR4, but you power-cycle, set ABP, then transmit, your node won’t remember the data rate to use.
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)