# 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

{% hint style="warning" %}
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.
{% endhint %}

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

| Parameter   | Explanation                                                                             | Responsibility             |
| ----------- | --------------------------------------------------------------------------------------- | -------------------------- |
| **DevEUI**  | Unique device identifier.                                                               | Device manufacturer or KPN |
| **DevAddr** | Unique device address.                                                                  | KPN                        |
| **AppEUI**  | Unique application instance identifier, used during the JOIN request.                   | Device manufacturer or KPN |
| **JoinEUI** | Replaces AppEUI as from LoRaWAN specification v1.1                                      | Device manufacturer or KPN |
| **AppKey**  | The AppKey encrypts the data during the JOIN request.                                   | Customer                   |
| **NwkSKey** | The NwkSKey validates the data integrity between the end device and the Network Server. | KPN (Join Process)         |
| **AppSKey** | The AppSKey encrypts the data between the end device and Application server.            | KPN (Join process)         |

## 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:

* MAC-L: <http://standards.ieee.org/develop/regauth/oui/>
* MAC-M: <http://standards.ieee.org/develop/regauth/oui28/index.html>
* MAC-S: <http://standards.ieee.org/develop/regauth/oui36/index.html>

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**

&#x20;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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.kpnthings.com/kpn-things/kpn-lora/technical-information/device-identification.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.