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 following table provides a summary of the identifiers mentioned in this section.
Unique device identifier.
Device manufacturer or KPN
Unique device address.
Unique application instance identifier, used during the JOIN request.
Device manufacturer or KPN
The AppKey encrypts the data during the JOIN request.
The NwkSKey validates the data integrity between the end device and the Network Server.
KPN (Join Process)
The AppSKey encrypts the data between the end device and Application server.
KPN (Join process)
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.
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.
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.
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.
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.
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.