The example below shows the essential commands needed to join a LoRaWAN network using OTAA join. Also some optional commands are shown. This process uses mainly 'mac' level commands, although a few 'sys' commands are used as well. The test mode 'radio' commands are not needed when using the LoRaWAN mac protocol.
 
Over-The-Air-Activation (OTAA) join relies on identifying the end node and the target application using EUIs (deveui & appeui) plus an encryption key is also used during the negotiation (appkey). In the join accept response, the server will provide a device address (devaddr) and both the end node and server will derive the session keys (nwkskey & appskey) so that they are never passed over the air.
The end result of the OTAA join is that the end-node is configured with the same three essential parameters as used for ABP (devaddr, nwkskey & appskey). It is possible to save these to EEPROM using 'mac save' therefore allowing the possibility to re-join using ABP after a power cycle or reset. This avoids the air-time and associated power consumption of OTAA.
 
Some network servers are capable of also returning an optional CF-List, which configures the channels and data-rates used by the end device. This is done using mac-layer commands from the server, and so no additional API commands are needed. 
 
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
> 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 is used
> 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 
// 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
// OPTIONAL - mac save used here to store devaddr & nwks/apps keys to EEPROM
> mac save                                           < ok
// DEFAULT - tx an unconfirmed packet on port 1. "Hello World!"
> mac tx uncnf 1 48656c6c6f20576f726c6421            < ok
                                                     < mac_tx_ok
// OPTIONAL - tx a confirmed packet on port 1. "Hello World!"
> mac tx cnf 1 48656c6c6f20576f726c6421              < ok
                                                     < mac_tx_ok
                                                     < mac_rx 1 23                       
// NOTE - cnf or uncnf uplinks may receive a downlink packet from the server. E.g. 0x23 on port 1
 
In this example ASCII text is being sent, but the payload can be any hexidecimal bytes

 
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. 
 

Thank you very much. I am a beginner and have a stupid question I guess.  I know that I can perform these orders one by one using the GUI. But, is there any way to write the commands in one file allow the node to execute it as a patch file. If so what is the required programs and tools. Thank you very much. 

Hello Ahmed, 
 
Interesting idea, but there is no embedded way of doing that as it stands today. The source code of the Mote kit is available (http://www.microchip.com/DM164138) so you could take that project as a starting point and convert it to simply play out a list of commands. Right now its broken down in to functions and subroutines. You'd need MPLAB-X as a development environment (http://www.microchip.com/mplab/mplab-x-ide) 
 
You could do it from a computer via USB connection. Using terminal programs like TeraTerm or Coolterm, you can normally play out a file of commands. I've done it successfully and just needed to add a fixed delay of a few hundred ms between each line (a function available within the terminal settings)

Thank you very much for your comprehensive reply. I will try it, it sounds very interesting.