Basic Commands for OTAA Join

 
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:
 
// OPTIONAL - resets the module firmware to default values 
> sys reset                                          < RN2483 1.0.1 Dec 15 2015 09:38:09
// OPTIONAL - resets the module firmware to default values, plus clears the EEPROM (session keys, EUIs etc)
> sys factoryRESET                                   < RN2483 1.0.1 Dec 15 2015 09:38:09
// OPTIONAL - reads the IEEE EUI of the module.  Can be useful for node serialisation
> sys get hweui                                      < 0123456789ABCDEF
// MANDATORY - in this example the hweui value (read above) is used to uniquely serialise the deveui
> mac set deveui 0123456789ABCDEF                    < ok
// MANDATORY - unique per web app. Used to route data
> mac set appeui 0123456789ABCDEF                    < ok
// MANDATORY - unique per device & must match server
> mac set appkey 0123456789ABCDEF0123456789ABCDEF    < ok 
// MANDATORY - create blank ABP credentials in preparation for ABP re-join
> mac set devaddr 00000000                           < ok
// MANDATORY - these blank credentials will be overwritten with server assigned values during ....
> mac set nwkskey 00000000000000000000000000000000   < ok
// MANDATORY - ... the successful OTAA join accept process
> mac set appskey 00000000000000000000000000000000   < ok 
// OPTIONAL - default value is 34. Some private networks use 12
> mac set sync 34                                    < ok
// OPTIONAL - default is off, but ADR is healthy for battery life & capacity if supported by the network
> mac set adr on                                     < ok
// OPTIONAL - saves all the settings to EEPROM for future use
> mac save                                           < ok
// MANDATORY - starts the join request/accept negotiation process, over the air
> mac join otaa                                      < ok
                                                     < accepted (or denied)  
// NOTE - accepted/denied response is useful to validate network coverage & set up

// DEFAULT - tx an unconfirmed packet on port 1. "Hello World!"
> mac tx uncnf 1 48656c6c6f20576f726c6421            < ok
                                                     < mac_tx_ok


// MANDATORY - "mac save" used here to store all radio state, inc counters, devaddr & nwks/apps session keys to EEPROM
// Note: “mac save” command is writing to EEPROM which is a slow process. Wait for "ok" response to confirm completion

> mac save                                           < ok
 
=========REMOVE VDD AND POWER DOWN INDEFINITELY===========
 
 
// MANDATORY - prepares the LoRaWAN mac with the radio state previous stored using "mac save". No server intervention needed
> mac join abp                                       < ok
                                                     < accepted
// DEFAULT - transmit an unconfirmed packet on port 1. "Hello World!"
> mac tx uncnf 1 48656c6c6f20576f726c6421            < ok
                                                     < mac_tx_ok
 
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.