An OTAA device must join before the network server accepts its data. This page follows a join request through every check, so you can tell from the join state or the frames log where a failing join stops.
The steps
- The device sends a join request. It carries the JoinEUI, the DevEUI, a DevNonce (a number the device chooses) and an integrity code (MIC) computed with the AppKey.
- Gateways forward it. Copies from several gateways are merged, like any uplink.
- The DevEUI is looked up. The network server looks the DevEUI up in the platform-wide directory.
- Not registered anywhere: if one of your profiles is in pairing mode and the request matches its shared AppKey, pairing takes over (see Pairing mode). Otherwise the request is dropped as Unknown DevEUI.
- Registered in another organisation: dropped as A device of another network. You learn nothing more about it.
- The device record is checked.
- An ABP device that sends a join request is refused (ABP device sent a join request).
- A device held by pairing mode is refused (Waiting for approval).
- A device without a key is refused (No AppKey stored).
- The JoinEUI is compared with the stored one, unless the device accepts any JoinEUI. A different one is refused (Join refused: other JoinEUI).
- The integrity code is checked with the AppKey (the device’s own, or the profile’s shared key for devices added by pairing). A mismatch is refused (Join refused: wrong AppKey?).
- The DevNonce is checked (see below). A reused one is refused (Join refused: DevNonce used before).
- A session is created. The network server picks a free device address (DevAddr) in its network, derives the two session keys and stores them encrypted. The new session is pending until the device’s first uplink.
- The join accept is sent. It goes through the best gateway that can still reach the device: 5 seconds after the request (RX1, same channel) or 6 seconds after (RX2, 869.525 MHz, DR0). The accept tells the device its address, the RX1 delay of its profile (5 s by default), the RX1 data-rate offset, the RX2 data rate and five extra EU868 channels.
- The device sends its first uplink with the new session. From now on its frames are accepted.
When all checks pass, the device’s join badge says Joined, and its device gets the attributes lora.devAddr and lora.joinedAt.
If no gateway can make either window (all offline, disabled, or out of duty-cycle budget), the session is created but the accept is not sent. The join badge then says Join answer not sent (no gateway in time) and the device will try again.
A device that was refused never gets an answer. LoRaWAN has no “join rejected” message, so the device simply retries later.
DevNonce rules
The DevNonce stops anyone from replaying an old join request.
| LoRaWAN version | Rule |
|---|---|
| 1.0.4 | Each DevNonce must be greater than the last accepted one. |
| 1.0.2 and 1.0.3 | A DevNonce must not have been used before. The last 256 values are remembered. |
A device that restarts and counts its DevNonce from 0 again (1.0.4), or picks a value it used before (1.0.2, 1.0.3), is refused until it uses a new one. Setting a new AppKey for the device clears its DevNonce history.
Join states
The device’s LoRaWAN tab shows a join badge:
| Badge | Meaning |
|---|---|
| Not joined yet | No join recorded and no session. |
| Joined | The last join was accepted, or the device has a live session. |
| Join refused: wrong AppKey? | The integrity check failed. |
| Join refused: DevNonce used before | Replay protection refused the DevNonce. |
| Join refused: other JoinEUI | The JoinEUI differs from the stored one. |
| Join answer not sent (no gateway in time) | All checks passed, but no gateway could send the accept. |
| No AppKey stored | The device has no key to check with. |
| Waiting for approval | Added by pairing mode, not approved yet. |
| ABP device: it does not join | An ABP device sent a join request. |
| Join refused (reason) | Any other refusal, with its code. |
Through the API, the device list takes the filter joinState with joined, refused or never.
Reset session
Reset session on the device’s LoRaWAN tab ends the device’s current session. Its uplinks are refused until it joins again.
Use it after the device was reset to factory settings, or after you changed its keys, so that no old session lingers. Confirm Reset the session: “The device must join again before its uplinks are accepted. Use it after a device was reset or its keys were changed.”
Reset session does not make the device join: the device must start a join itself (power-cycle it, or use its join button). It is not available for ABP devices. Each reset is audited as iot_lorawan.device.session_reset.