OTAA activation gets the device the NwkSKey, AppSKey and DevAdr from the server, plus network settings such as additional frequencies and RX settings. (Join Request sent, Join Accept received.)
ABP “activation” sets the NwkSKey, AppSKey and DevAdr into the device while programming, and also requires one to program the network settings. (No network traffic for the “activation” at all.)
While transmitting uplinks or while decrypting downlinks, your LoRaWAN library does not care how the device got all these settings.
Only when the device somehow loses its configuration one can avoid having to do an OTAA activation again by storing the OTAA responses in non-volatile memory and then mimic an ABP “activation”. If this only happens when the device is restarted or the battery is empty: don’t worry, just do OTAA again. (Also nice to allow for simply joining a different network.) If it happens for every (deep) sleep, then store and re-use the settings and frame counters, and much more.
Some libraries or devices might support this without doing anything special in code, or with a single line of code to save the settings.
For LMiC, one needs to store and retrieve settings manually: after deep sleep, configure your node as an ABP node using LMIC_setSession(...), and set the frame counters to their last stored values, using LMIC.seqnoUp = ... and LMIC.seqnoDn = .... The session secrets have different names (which originate from the early days where LoRaWAN was still called LoRaMAC). The documentation shows:
Set static session parameters. Instead of dynamically establishing a session by joining the network, precomputed session parameters can be provided. To resume a session with precomputed parameters, the frame sequence counters (LMIC.seqnoUp and LMIC.seqnoDn) must be restored to their latest values.
Indeed, the global LMIC variable provides access to properties such as LMIC.nwkKey for NwkSKey, LMIC.artKey for AppSkey and LMIC.devaddr for DevAddr, which you should be able to retrieve and persist in case EV_JOINED.
Does that mean that ABP is always technically on the network when you start a node with it?
As in: ABP is “connected” without a GW, but OTAA needs a GW to connect. (i know this means the ABP can’t send data, but theoretically speaking.
If the keys in your device match the keys in the network server (TTN Console), then: technically, maybe, yes; as soon as it transmits a packet using those secrets, the network knows how to handle it. However, it’s not like WiFi where a device is really “connected”. A device just transmits some data, and hopefully one or more gateways will receive that, and then forward to TTN, which hopefully knows how to handle it. Such gateways will also receive messages for other operators, and even messages that just use the LoRa radio modulation but without using the LoRaWAN network protocol, and will forward all of those. Typically, gateways don’t know what they’re receiving and forwarding.
So, by using ABP you really just skip OTAA by programming the “session” secrets into the device, rather than asking for those secrets* by using OTAA (which uses another secret, the application key).
Thank you that makes a lot of sense, and should explain why some of my template code for Arduino WAN 1300 claims to be properly sending messages, even though i see nothing on TTN (whilst using ABP).
So it’s simply firing it into the atmosphere (or whatever analogy works), and hoping that a GW is close enough and actually picks it up?
Yes. But also: if the keys are wrong, then even when some gateway(s) receive the message, the message might be discarded by the operator (TTN).
If you do not have a gateway yourself (so: if you cannot access any gateway’s log files, or see its traffic in TTN Console), then to maximise the chances that your test message is received, try using SF12 for some tests.
Also beware that your node might reset its frame counters to zero when restarting, which for ABP either needs you to reset the counters in TTN Console too, or (for testing) needs you to disable the frame counter security altogether, for otherwise TTN will silently ignore the messages until it gets one that has a counter exceeding the last known value. For OTAA, the counters are reset on each join, so no problems there.