OTAA then ABP


(Adam Jp) #1

Hi All, I would like to clarify something that I have read on the forum about node authentication:

Does OTAA generate keys for ABP authentication?

Example communication flow of the application in a common sleep/awake/send:

1: Join with OTAA then store the keys
2: Use stored keys to send data via ABP?

Is this correct?


OTAA best practice: how to not join every time?
#2

this could probably help


(Adam Jp) #3

Thanks @ursm, that’s where I read it. But I love to hear from others if this is the correct way to use OTAA.

Maybe my question should be: Should all node send one OTAA request to join (assuming its successful) then use ABP to send data unless otherwise told to OTAA join again?

Cheers


(Vanthome) #4

Hello, yes, that’s the idea of OTAA. I’m also working with a node and I’m trying to resume sending with the negotiated keys, but so far I failed to send after wake up. Will post here when I have found out more.


(Arjan) #5

No, not really:

  • 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:

2.5.4 void LMIC_setSession (u4_t netid, devaddr_t devaddr, u1_t* nwkKey, u1_t* artKey)

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.

And so does the code:

void LMIC_setSession (u4_t netid, devaddr_t devaddr, xref2u1_t nwkKey, xref2u1_t artKey);

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.

Be careful where to save such details:

And if one happens to use an ESP32:


Big ESP32 + SX127x topic part 2
OTAA - save Keys and?
LMiC does not receive Join Accept