# How often should a node do an OTAA Join, and is OTAA better than ABP?

**URL:** <https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192>\
**Category:** Application Development\
**Created:** [December 16, 2017, 11:05am UTC](https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192 "2017-12-16T11:05:26Z")\
**Posts on this page:** 1\
**Showing post:** 47

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [February 15, 2020, 11:29am UTC](https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192/47 "2020-02-15T11:29:29Z")

</div>

> [@davelong](#):
>
> Have a look in the article at the link I posted, I didnt understand it at first, the ‘0000000’ values are really important, without this the whole idea doesnt work.

Quite late, but just for future reference:

Indeed, I’ve also seen that this is required for a Libelium device back in May 2016, which identified as `RN2483 1.0.1 Dec 15 2015 09:38:09`. And here’s the part that is relevant [from that link](http://www.microchip.com/forums/m945840.aspx), **October 2016** , numbered and formatted for readability:

> The initial RN2483 and RN2903 both contained an errata meaning that the sleep current is above spec, and this can be an issue for sleepy devices trying to achieve very long battery life. As hinted in the post above, there is a work-around for this which allows Vdd to be completely removed, but then for the module to continue after Vdd is re-applied. Using OTAA to rejoin would cause a lot of over-the-air communication and so could negate any current benefit of removing Vdd in the first place.
> 
> The solution is to store all the radio state before sleeping, including the session keys, using the “mac save” command and then to continue the session after waking using the “mac join abp” command, with no over-the-air comms needed. To the network this is invisible and no different from the module sleeping instead of being turned off.
> 
> In the RN2483 example below, `>` indicates a command to the modem and `<` indicates a response from the modem:
> 
> 1. OPTIONAL - resets the module firmware to default values
> 
> 2. OPTIONAL - resets the module firmware to default values, plus clears the EEPROM (session keys, EUIs etc)
> 
> 3. OPTIONAL - reads the IEEE EUI of the module. Can be useful for node serialisation
> 
> 4. **MANDATORY** - in this example the hweui value (read above) is used to uniquely serialise the deveui
> 
> 5. **MANDATORY** - unique per web app. Used to route data
> 
> 6. **MANDATORY** - unique per device & must match server
> 
> 7. **MANDATORY** - create blank ABP credentials in preparation for ABP re-join. These blank credentials will be overwritten with server assigned values during the successful OTAA join accept process
> 
> 8. OPTIONAL - default value is 34. Some private networks use 12
> 
> 9. OPTIONAL - default is off, but ADR is healthy for battery life & capacity if supported by the network
> 
> 10. OPTIONAL - saves all the settings to EEPROM for future use
> 
> 11. **MANDATORY** - starts the join request/accept negotiation process, over the air
> 
> 12. **DEFAULT** - tx an **unconfirmed** packet on port 1. “Hello World!”
> 
> 13. **MANDATORY** - “mac save” used here to store all radio state, inc counters, devaddr & nwks/apps session keys to EEPROM
> 
> 14. REMOVE VDD AND POWER DOWN INDEFINITELY
> 
> 15. **MANDATORY** - prepares the LoRaWAN mac with the radio state previous stored using “mac save”. No server intervention needed
> 
> 16. **DEFAULT** - transmit an **unconfirmed** packet on port 1. “Hello World!”
> 
> In both the initial session and the follow-on session the same network credentials are used and the radio state (data rates, counters etc) remain in sync, so the network server can not distinguish between this and a continuous session.

For more recent RN2xx3 devices, maybe removing the full power is no longer needed to achieve good battery life, and a regular sleep (if that exists…?) without the need for the `mac join abp` trickery suffices?

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192)._