TL;DR: OTAA assigns network and application session keys as well as 4 byte device address dynamically and allows for roaming and identifies the device using it’s device EUI as well as the application using the application EUI and the application key; ABP assigns both session keys and the device address statically and doesn’t allow for roaming and requires centralized administration.

Since device activation seems to be somewhat like black magic to many people playing around with LoRA-WAN devices these days I decided to write a short introduction on the role of activation from the networks point of view. It’s a rather high level introduction - in case on wants to implement activation the LoRA WAN specification is the source to rely on.

Just before talking about activation let’s recall the packet format used by LoRA-WAN on the PHY and MAC layer:

• First a preamble if used. This preamble consists of at least 8 octets that are used to synchronize clocks as known from many other communication systems. At least four of these bytes have to be seen by a device to allow synchronization.
• PHY Header (2 Byte)
• PHY Header CRC (4 Bit)
• PHY Payload:
  • MAC Header (Bits 7..5 are the message type, bits 1..0 are the major version number of the MAC specification; remaining bits are reserved). Message types can be join request, join accept, unconfirmed and confirmed data up and downlink as well as proprietary packet types.
  • MAC payload, join request or join response. In case of the MAC payload this consists of:
    • Frame header
      • The 4 byte device address DevAddr
      • FCtrl which allows to transmit control flags to modify data rates, transmit acknowledge packets, frame pending and retransmission attributes, etc.
      • The frame counter FCnt
      • Frame options FOpts that can contain MAC commands on top of data packets.
    • The port (FPort) that can be used to differentiate between different services. Port 0 is reserved for MAC commands, 224 is dedicated to the MAC layer test protocol. Values 1-223 can be used in an implementation specific way by the respective application.
    • Frame payload. This payload is usually encrypted. Note that the payload is encrypted using the AppSKey (see below) before the message integrity code is calculated. The used key is dependent on the port - in case of port 0 the NwkSKey is used instead of the application key.
  • Message integrity code (MIC)
• CRC (2 Byte)

As one can see the only way a device can be identified is the DevAddr. This field contains a short 7 bit network identifier that selects a network which allows up to 128 networks to operate overlapping in the same area. The remaining bits identify the device inside of the specific network - one can think of the DevAddr being something similar to an IP address except that there is no other subnetting than the network ID. Note that this of course would mean that only 33.554.432 devices could be present inside a single network. That might sound much but as one has seen from IPv4 address space exhaustion this is a really small key space. Fortunately one can use different encryption keys during message integrity code calculation to further differentiate. This is possible since two devices using the same DevAddr but different session keys will produce invalid integrity codes from the point of view of the other device and other application.

Persistent state on the device

What’s activation all about? Basically it’s about the determination of four parameters on the end device:

• The device address DevAddr
• A network session key NwkSKey
• An application session key AppSKey

Depending on the used activation method different initial state is required on the devices. But what are these three stateful variables used for?

The device address DevAddr consists of a 32 bit identifier that identifies the device uniquely within it’s current network. The most significant 7 bits are used as an network identifier, sometimes called NwkID. These network IDs are usually centrally assigned to separate different network providers in a given geographic location. Note that this of course limits the number of networks to 128. The least 25 bits sometimes called NwkAddr of an end device have to be assigned arbitrarily by the network management and have to be unique inside the network. Depending on the used activation procedure one has to centrally assign the NwkAddr (ABP) or is able to do this dynamically (OTAA).

There are two other unique known addresses from the EUI64 namespace:

• The AppEUI is a global application ID. Since it’s an EUI64 it’s required to be globally unique like a Ethernet MAC address. It’s not required when using ABP activation method. The AppEUI has to be pre-programmed on a device when using OTAA.
• The DevEUI is an unique EUI64 device address. This is also unique like an Ethernet MAC address and is always known on all devices during initial programming.

The other two stateful variables NwkSKey and AppSKey are AES-128 encryption keys. Since they’re session keys they should be unique for each device. Depending on the activation method they’re pre-programmed or derived during the join procedure. The network session key NwkSKey is used to verify the message integrity of data messages on the network server and device end - and it’s used to encrypt MAC-only messages. The AppSKey is an application session key that’s used - on the other hand - to encrypt but not integrity protect application payload. This encryption happens between the end device and the application server - although the specification clearly states that this encryption layer does not guarantee confidentiality or integrity. One should use an application layer cryptosystem if this level of integrity or confidentiality is required.

OTAA (Over-the-air activation)

OTAA is the preferred activation mechanism to determine the DevAddr as well as the two session keys. It initially requires:

• A known AppEUI that identifies the application.
• The DevEUI, the globally unique 8 byte device address that’s also preprogrammed.
• An known AppKey. This is not a session key but a pre-shared application key.

The device also has to create a 2 byte random value that should never be reused. This DevNonce is used to prevent replay attacks. The network server at least keeps track of the previous DevNonce and discards it at the earliest at the next successful join operation of a device.

The device joins the network by transmitting a join message. This message contains:

• The 8 byte AppEUI
• The 8 Byte DevEUI
• The 2 byte DevNonce

This join message is not encrypted but message integrity protected using

cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce)
MIC = cmac[0..3]

As one can see the AppKey is used for the calculation of the message integrity code. Note there is no limitation on the data rate and channels to be used so devices might try a variety of them starting with high bandwidth short range messages or multiple data rates at once.

The next step is the response of the network server - which is a standard downlink message inside the receive window with some different timing constraints than usual. The join accept message contains:

• A 3 byte application nonce AppNonce
• 3 bytes of network ID NetID. The 7 least significant bits are the network ID that match the 7 most significant bits from the addresses of end devices. Overlapping networks always have to differ in their network ID. The remaining 17 most significant bits can be freely chosen by the network operator.
• 4 byte device address DevAddr. Note that this is not the DevEUI, this is a dynamically assigned local device address inside the current network.
• 1 byte downlink settings. Bits 4 to 6 contain the RX1DRoffset, Bits 3 to 0 the RX2 data rate. This RX1DRoffset describes the difference between the data rate used by uplink and downlink channels to allow unlicensed operation of gateways. This information is needed for timing on the devices.
• 1 byte receive delay
• Up to 16 optional bytes that contain a list of channel frequencies (CFList).

The nonce again is a random unique value that is provided by the network server. It’s used to derive the session keys:

NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad_16)
AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pat_16)

cmac = aes128_cmac(AppKey, MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList)
MIC = cmac[0...3]

The join accept message is encrypted with the AppKey:

aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList | MIC)

As one can see the message integrity code is contained inside the encrypted payload - one can compare this with an sign then encrypt schema. The usage of the decrypt operation for encryption allows to reduce the number of operations required on the device - since encrypt and decrypt are inverse functions applying decrypt and then encrypt provides the same result as encrypt and then applying decrypt.

ABP (Activation by personalization)

This is the older and discouraged alternative to more complex OTAA. Basically OTAA is used to derive two session keys and a device address. With ABP these values

• The device address DevAddr
• A network session key NwkSKey
• An application session key AppSKey

are stored during device firmware flashing. Of course the DevEUI is already known since it’s known as soon as a LoRA MAC is present.

The main difference is that the session keys as well as the network unique device address have been preprogrammed which requires central coordination inside the network. This is not required for OTAA which allows roaming of devices between different networks when using OTAA as long as the networks support roaming. When using ABP the device is already assigned to a given network.

This article is tagged:

• Tutorial
• LoRA