Device Identification

LoRa devices typically communicate via uplink messages; sensors generate data which is sent towards the customer application by using the KPN LoRa access network and core server (LRC). Data is forwarded from the core server to the customer Application Server. For downlink messages, the customer Application Server (AS) communicates with the LRC, which handles the communication towards the device.

  • Over-The-Air Activation (OTAA): the device is provisioned with root keys that is used to calculate session keys each time the device joins the network. That way session keys are not long living and thus more secure.

  • Activation by Personalisation (ABP): the device is directly provisioned with the session keys

The KPN network only allows Over-The-Air Activation (OTAA). Activation by Personalisation is considered not secure enough and is therefor not allowed on the KPN LoRa network.

The following table provides a summary of the identifiers mentioned in this section.

Device provisioning

DevEUI

Each device that joins the KPN LoRaWAN network needs to have a unique identifier. This identifier is called the DevEUI, and it must be a unique IEEE MAC address. A device manufacturer must acquire an address block with IEEE, or, when the customer requires a small “sub block”, this can be requested from KPN.

There are 3 available ranges from IEEE:

For off-the-shelf LoRa devices, the manufacturer should already have a range of addresses. Then, each device should be delivered with its pre-defined DevEUI.

AppEUI

The 64-bit AppEUI, which is used as an identifier for an application instance, is also a unique identifier and is always an address provided by KPN. Note: the name AppEUI will be replaced with JoinEUI as from LoRaWAN specifications v1.1.

JoinEUI

The 64-bit JoinEUI, which is used as an identifier for an application instance, is also a unique identifier and is always an address provided by KPN. Note: the name JoinEUI replaces the name AppEUI from specifications older than LoRaWAN v1.1.

AppKey

The 128-bit AppKey must be personalized in each device during production. It may be distinct per device or unique per application depending on the use-case. Providing the AppKey is the responsibility of the customer, such that the AppKey can be provisioned to the Application Server associated with the end device.

Data session

DevAddr

Devices that are pre-provisioned or once active on the network have a unique DevAddr to make sure the routing can take place while on the KPN network (or on the roaming network). The DevAddr is dynamically assigned by KPN during the OTAA Join procedure. The DevAddr (and the NwkSKey) must be globally unique.

NwkSKey

The authenticity and integrity of LoRa messages is verified using the 128-bit NwkSKey. It is important that a different NwkSKey is used for each device (allocated randomly). KPN provides the NwkSKey during the OTAA Join process.

AppSKey

Apart from the NwkSKey, a 128-bit AppSKey is used to encrypt the payload of LoRa messages. A unique AppSKey can be used for all LoRaWAN ports used by your device, or a specific AppSKey can be used for each port. The AppSKey is provided by KPN during the OTAA Join of the end device.

Last updated