Before a LoRaWAN device can send or receive any data, it must complete a process called activation — the step where the device obtains its network address and session keys. The activation method you choose affects security, deployment complexity, and day-to-day operations.
The LoRaWAN specification defines two activation methods: OTAA (Over-The-Air Activation) and ABP (Activation By Personalization). This article breaks down how each works, compares them side by side, and gives practical selection guidance.
OTAA is the recommended activation method. Devices ship without session keys and complete authentication over the air after the first power-up.
OTAA activation happens in three steps:
1. The device sends a Join Request
The device transmits a Join Request carrying:
| Field | Description |
|---|---|
| JoinEUI / AppEUI | Application identifier (64-bit) that selects the application or network server to join |
| DevEUI | Globally unique device identifier (64-bit), typically derived from the hardware MAC or programmed at manufacture |
| DevNonce | A random number (16-bit) that increments on every Join Request, preventing replay attacks |
The Join Request is authenticated with a MIC (Message Integrity Code) computed using the AppKey, ensuring the message was not tampered with.
2. The network server validates and sends a Join Accept
On receiving the Join Request, the network server:
The Join Accept carries:
| Field | Description |
|---|---|
| JoinNonce | Random value (24-bit) generated by the network server, used for key derivation |
| NetID | Network identifier (24-bit) |
| DevAddr | The assigned network address (32-bit) |
| DLSettings | Downlink settings (RX2 data rate, RX1 offset, etc.) |
| RxDelay | Receive window delay |
| CFList | Optional list of channel frequencies |
3. The device derives its session keys
The device decrypts the Join Accept with its AppKey, then derives session keys from the AppKey, JoinNonce, DevNonce, and NetID.
LoRaWAN 1.0.x (1.0.2 / 1.0.3 / 1.0.4) derives two keys:
Simplified derivation:
NwkSKey = aes_encrypt(AppKey, 0x01 | AppNonce | NwkID | DevNonce)
AppSKey = aes_encrypt(AppKey, 0x02 | AppNonce | NwkID | DevNonce)
LoRaWAN 1.1 introduces key separation, deriving four keys:
LoRaWAN 1.1 renames AppEUI to JoinEUI and separates the NwkKey from the AppKey, enabling network-level and application-level key separation — the foundation for secure roaming.
ABP skips the join procedure entirely. Devices are pre-provisioned with all communication parameters at manufacture and start sending immediately after power-up.
The following must be written to the device before shipping and registered on the network server in advance:
| Parameter | Description |
|---|---|
| DevAddr | Device network address (32-bit), must be unique within the server's allocation |
| NwkSKey | Network session key (128-bit AES) |
| AppSKey | Application session key (128-bit AES) |
ABP devices do not need a DevEUI, JoinEUI, or AppKey (unless you plan to migrate to OTAA later).
An ABP device goes straight to work after power-up:
There is no Join Request / Join Accept handshake.
ABP devices must manage their uplink (FCntUp) and downlink (FCntDown) frame counters. Network servers track these counters to prevent replay attacks — if a device reboots and its counter resets below the value the server last recorded, its frames will be rejected.
Two common approaches:
| Dimension | OTAA | ABP |
|---|---|---|
| Security | High — keys derived over the join procedure, never transmitted | Low — keys must be written at manufacture and registered server-side; exposure risk |
| Key rotation | Yes — re-join to obtain fresh keys | No — keys are fixed; changing them requires reflashing devices |
| DevAddr assignment | Dynamically assigned by network server | Fixed at manufacture; uniqueness must be managed manually |
| Deployment complexity | Device only needs root keys; server handles the rest | Both device and server need full pre-configuration |
| Time to first packet | Join procedure first (typically 5–15 seconds) | Instant — works right after power-up |
| Frame counter management | Starts from zero after join; no conflict issues | Must be managed carefully; reboot may cause rejected frames |
| Roaming | Supported (LoRaWAN 1.1 key separation) | Not supported |
| LoRaWAN 1.1 | Fully supported — 1.1 relies on OTAA | Not recommended under 1.1 |
| Deployment scale | Suitable for production fleets | Suitable for small tests |
| Network switching | Change JoinEUI to join another network | Requires reflashing all parameters |
"ABP saves power because there's no join procedure."
Not really. The join procedure costs very little — one Join Request and one Join Accept, typically completed in a few seconds. Compared to a device's multi-year battery life, the energy of the join phase is negligible. What ABP actually saves is development-time configuration effort — and in production that convenience comes at the cost of lower security and higher operational overhead.
On ThinkLink:
| OTAA | ABP | |
|---|---|---|
| One-liner | Like joining Wi-Fi — automatic authentication, automatic address | Like a landline — number and line pre-configured at the factory |
| Security | High | Low |
| Recommended for production | Yes | No (debugging/teaching only) |
| LoRaWAN 1.1 | Required | Not recommended |
Bottom line: use OTAA in production, ABP only for debugging and teaching. If you have more than ten devices, or if devices sit in environments you can't physically control, OTAA is the only sensible choice.
Written against the LoRaWAN 1.0.4 and 1.1 specifications. Protocol details follow the LoRa Alliance specification documents; operational advice draws from ThinkLink platform experience.
ThinkLink is the IoT platform product from ManThink, providing LoRaWAN network management, device operations, and data services.