---
description: Learn more about connecting LoRa
---

# Connecting LoRa devices

You can register your LoRa devices directly on KPN Things. This will register your device in our network simultaneously. After registration your device can directly join our network. Further configuration KPN Things allows you to decode and forward the data of your LoRa devices to your application. Learn more about all parts of [the data chain in KPN Things](https://docs.kpnthings.com/kpn-things/get-started/technical-overview#kpn-things-portal).

### LoRa Device registration <a href="#lora-device-registration" id="lora-device-registration"></a>

Currently only LoRaWAN 1.0.x is supported. Also, only OTAA is available. ABP is not available since it is less secure.

To register a LoRa device on KPN Things you need to enter the following details:

* **DevEUI** - Unique LoRa device identifier.
* **AppEUI** - LoRa application identifier.
* **AppKey** - LoRa device authentication and encryption root key.

#### LoRa data history <a href="#lora-data-history" id="lora-data-history"></a>

This tab shows you detailed information about the messages send to and from your Device from the perspective of our LoRa network.

Messages in LoRa data history are stored up to 1 month.

**Message overview**

The message overview of LoRa data history gives you an overview of all message to and from your Device in descending order of time. So the most recent message is at the top of the list of messages.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FXpGRZnWZ4iBivEF8tFXg%252Fimage.png%3Falt%3Dmedia%26token%3Da17560a1-00a7-4317-bca9-bb8c41f117e4&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=6b4ee7fa&#x26;sv=1" alt=""><figcaption></figcaption></figure>

What you can see here is:

1. The type of LoRa message.
   1. Whether it was an **uplink** (🔵 blue) or **downlink** (🟢 green) message.
   2. Whether it was a **Join request**, **Join accept** or regular message.
   3. Whether the message was **confirmed** or **unconfirmed**, or whether the message carried an **ACK**.
   4. Whether the messages contained **data,** **mac**, or **both**.
2. Whether a [LoRa Geolocation](https://docs.kpnthings.com/kpn-things/get-started/technical-overview/location-data#lora-geolocation) result could be determined on that message (only available for uplink).
3. The exact **timestamp** of the message, with millisecond accuracy.
4. The **frame counter value** of the message. Uplink (FCntUp) and downlink (FcntDown) communication has its own counter.
5. An indication of the **signal strength** the message.
6. Click on the chevron at the end of a row to see more details of a message.
7. Search bar to see the message history up to a certain point in time.
8. Button to load more data history (if available).

**Message detail**

When you open the details of a message by clicking the chevron at the right side of the row, you can see the following:

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FGb8wUw9o5RFrAsDI2mHr%252Fimage.png%3Falt%3Dmedia%26token%3D0b64233a-f2fe-45dd-a0f4-20d0ef505558&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=1b38b45e&#x26;sv=1" alt=""><figcaption></figcaption></figure>

1. Details about the message signal:
   1. The **Spreading factor** used, which indicates the relationship between bit and chirp rate used in the modulation. This number can vary from SF7 to SF12; [the technical details can be found here](https://docs.kpnthings.com/lora/technical-information/lora-and-lorawan).
   2. The LoRa **channel** used. Currently 16 channels are support in the KPN network, [see the KPN Thing LoRa documentation](https://docs.kpnthings.com/lora/technical-information/geographical-coverage-and-channel-setup).
   3. The **number of gateways** that received the message _(uplink only)_.
   4. The Received Signal Strength Indicator (**RSSI**) of the message _(uplink only)_. This gives you an indication of how strong the message's signal has been received by the best receiving gateway. The closer the number is to zero, the stronger is the received signal.
   5. The Signal to Noise Ratio (**SNR**) of the message _(uplink only)_. This gives you an indication of the amount of noise when the message was received by the best receiving gateway. It is used to determine the quality of the signal. If the number is high (far above zero), it is easy to demodulate the signal. If the number is low (far below zero), it is hard or impossible to demodulate the signal.
   6. The Estimated Signal Power (**ESP**) of the message _(uplink only)_. ESP is calculated from RSSI and SNR and gives an indication of the used link budget. The closer to zero the better is the signal.
2. Details about the content of the message:
   1. The LoRa **application port** on which data was send or received (if applicable).
   2. The exact **payload** of the LoRa message (if applicable).
   3. The exact **MAC content** of the LoRa message (if applicable).
   4. **Flags** that were in the LoRa message, like `ACK`, `FPending` or `ADRAckReq`.
3. Details of the LoRa Geolocation result:
   1. **Coordinates** of the calculated location.
   2. **Radius** in meters, the theoretical inaccuracy of the LoRa Geolocation result.
   3. **Method** used to determine the geolocation. Either RSSI (Received Signal Strength Indicator) or TDOA (Time Difference of Arrival). The latter is more accurate, but only possible when at least 3 gateways have received the message. [Read more about it here.](https://docs.kpnthings.com/lora/geolocation/intro)

#### What to expect on first use <a href="#what-to-expect-on-first-use" id="what-to-expect-on-first-use"></a>

This section will explain what you can expect when you first connect your LoRa Device to KPN Things.

In the screenshot below you can see the beginning of a typical LoRa data history. The message are shown in descending order of time, so the first message is at the bottom of the list of messages.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FHUKgjIyceQQwHC1nCP5l%252Fimage.png%3Falt%3Dmedia%26token%3Dc27b498d-5811-4b36-92a8-c32523e68d83&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=5c4fb2ef&#x26;sv=1" alt=""><figcaption></figcaption></figure>

Below at the section [Step 5. Normal operation](https://docs.kpnthings.com/kpn-things/components/connectivity/lora#step-5.-normal-operation) you can find an even more elaborate example. If your LoRa data history is not the same as in the screenshot above, you can continue reading to understand the chronology of LoRa data history.

**Step 1. Join request**

The first thing your device should do is try to join our network. With a _join request_, the device will ask to network whether it may join. Learn more about [joining in LoRaWAN](https://docs.kpnthings.com/lora/technical-information/joining).

Your LoRa data history should look like this when the join request is sent.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FOY9rmTpeYTMM3FjOR5o3%252Fimage.png%3Falt%3Dmedia%26token%3Dfe7c6d39-5272-4ef2-855d-dffb5e98c413&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=cd12ce8d&#x26;sv=1" alt=""><figcaption></figcaption></figure>

**I don't see a join request appearing in the LoRa data history!**

This means the network does not see any activity from your device. Try one of the following actions to fix:

* Check whether the LoRa registration was successful by checking the connectivity status on the [Device detail page](https://docs.kpnthings.com/kpn-things/components/devices#device-detail-page).
* Check if your device is programmed/configured with the same DevEUI you find in the connectivity details on the [Device detail page](https://docs.kpnthings.com/kpn-things/components/devices#device-detail-page).
* Check if your device is sending the join request on one of the default LoRaWAN channels[. Learn more about LoRaWAN channels](https://docs.kpnthings.com/lora/technical-information/geographical-coverage-and-channel-setup#channel-setup).
* Maybe the network coverage is not ideal at your current position. Thick walls or a sub-optimal antenne can cause issues. Try to move to a more exposed location for better coverage, like moving closer to a window.
* It could be that your device is not sending the join request on SF12, the spreading factor with the farthest reach. Program/configure your device to use this spreading factor when joining to increase coverage of your device.
* Maybe you are completely out of reach of the network. You can check [our LoRa network coverage](https://www.kpn.com/zakelijk/internet-of-things/lora-netwerk.htm) online.

**Step 2. Join accept**

After receiving the _join request_, the network will check whether the Device is known and whether the security details are correct. If so, the network will respond with a _join accept_.

Your LoRa data history should look like this when the join accept has been sent.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FiI5xceyLGdlPzCAHY45A%252Fimage.png%3Falt%3Dmedia%26token%3D7c7d873a-d2c6-49d1-8c32-253593797a71&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=7495c5ba&#x26;sv=1" alt=""><figcaption></figcaption></figure>

**I don't see a join accept appearing in the LoRa data history! I only see join requests.**

This means the network sees your requests to join the network, but there is a (security) reason not to accept your join request. Try the following to fix it:

* Check if your device is programmed/configured with the correct AppEUI.
* Check if your device is configured with the correct AppKey. This could also have to do with the [endianness](https://en.wikipedia.org/wiki/Endianness) with which you should enter the AppKey in your device.
* Try to remove your device from the Portal and re-add it, maybe you made a typo when registering your device.

**Step 3. First uplink**

After your Device has received and processed the _join accept_, it can begin sending data.

Your LoRa data history will look this way after your Device has sent its first uplink.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FYtDi1EHeKgm2ZccAclJo%252Fimage.png%3Falt%3Dmedia%26token%3D9e1bd7fa-9c4b-43b9-a3c8-65a10a42535e&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=b7c979d9&#x26;sv=1" alt=""><figcaption></figcaption></figure>

**I don't see uplink data appearing in the LoRa data history! I only see join requests and accepts.**

This means the join is completed from the network point of view, but somehow your device does not see it the same way. Try the following to fix it:

* Often join accepts are sent on the RX2 receive window. Is your RX2 receive window correctly configured? This should be 869525000 MHz and DR0 (SF12). Some device manufacturers have the device wrongly configured with the RX2 receive window listening on DR3 (SF9). (This is a common issue with **Dragino** devices!)
* Sometimes the link budget for downlink is smaller than uplink, meaning downlinks are harder to receive than it is to send uplinks. This accounts for worse coverage for downlink than for uplink. Try to move to a more exposed location and try again.

**The network is sending Join accepts, but my Device says joining did not succeed!**

* It could be that there is a programming error in your Device that causes your Device to incorrectly process the Join accept. Please refer to your device manufacturer documentation for more help on that.
* It could be a LoRa reception problem, due to configuration problems or insufficient coverage. You can check the possible solutions for "I don't see uplink data appearing in the LoRa data history!" above for more info.

**Step 4. First downlink**

Download messages are messages send by the network to your Device. These can be _mac_ messages, containing commands to your Device about LoRaWAN transmission settings, or they can contain _data_ from your application or from KPN Things.

After a Device has joined, the network will send up to three downlink messages with _mac_ commands in them.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252Fv1hLoye8chPHbHgoUDcE%252Fimage.png%3Falt%3Dmedia%26token%3De69fa2cb-2e89-4597-9bf7-e3a6efa88933&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=5fac4079&#x26;sv=1" alt=""><figcaption></figcaption></figure>

**Step 5. Normal operation**

Now your Device will go into normal operation, often meaning periodically sending uplink messages. In the screenshot below you can see a typical LoRa data history.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FSvK5MKafKnUCKY1YYmAr%252Fimage.png%3Falt%3Dmedia%26token%3De6059c15-7443-43ea-a1e1-4caf96553b7f&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=43a2500a&#x26;sv=1" alt=""><figcaption></figcaption></figure>

#### Other things you can see <a href="#other-things-you-can-see" id="other-things-you-can-see"></a>

**Example A. Too high sending interval ⚠**

Using the timestamps for consecutive uplink messages you can determine the average sending interval of your Device. This sending interval should not be too high, since you might be violating the [fair use policy ](https://docs.kpnthings.com/kpn-things/service-and-support/terms-of-use)of KPN Things.

Make sure your Device does not send more often than once every 5 minutes on average.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FH5Tc9ZU0nG7A2OuYUi10%252Fimage.png%3Falt%3Dmedia%26token%3D57589953-62b2-4399-bc5a-85e83cf87cc4&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=f6bfa9d7&#x26;sv=1" alt=""><figcaption></figcaption></figure>

**Example B. No answer to&#x20;**_**mac**_**&#x20;messages. ⚠**

Each _mac_ command consists of a request and an acknowledge message. So _mac_ messages should come in pares in the LoRa data history.

If this is often not the case and you see that downlink _mac_ messages are not answered by the Device, please check your Device, because there might something wrong. If your Device does not follow up _mac_ commands, the transmission settings cannot be optimized.

Make sure your Device responds to all _mac_ commands.

**Example C. No new LoRa Geolocation for an uplink. ℹ**

Not every uplink message will give a new calculated LoRa Geolocation. This is normal. It can be caused by the fact that too few gateways received the uplink, or if other circumstances were sub-optimal.

**Example D. Missing FCntUp: message lost. ℹ**

When a value for FCntUp is missing in the LoRa data history, it means that that specific message has not been received by the network. In LoRaWAN communication it is normal to have lost messages, your application should take this into account. It is a sid&#x65;**-**&#x65;ffect of the very energy efficient way LoRaWAN works. In normal situations you can expect up to 5% message loss. If your losses are higher, coverage on the location of your Device might be temperate.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FrNIjHhApwAiSyxjgUv4E%252Fimage.png%3Falt%3Dmedia%26token%3Da06b6458-29b1-4eae-95be-50ffd3d33b46&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=3e945112&#x26;sv=1" alt=""><figcaption></figcaption></figure>

**Example E. Join for each uplink message. ⚠**

If you see a join ceremony before each first message (FCntUp = 0), there is something wrong with your Device. Maybe it is losing power in between data transmissions or there is another reason your Device rejoins after each message.

Your Device should not rejoin after each message, because it puts unnecessary stress on the battery consumption of your device and it prevents the network to optimize the LoRaWAN transmission configuration through _mac_ commands.

Make sure your Device remembers its join in between uplink messages.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252FQ8yUurqVPJlvGFdhROTm%252Fimage.png%3Falt%3Dmedia%26token%3D795dc019-98fb-4d15-a731-7dcc37b2768e&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=4a765eb4&#x26;sv=1" alt=""><figcaption></figcaption></figure>

**Example F. Only Confirmed uplink messages ⚠**

If you see your Device (almost) only send Confirmed uplink messages, your Device is not properly configured. Sending too much Confirmed uplink messages puts too much demand on downlink communication, since every Confirmed uplink message requests a downlink message containing an ACK (acknowledgement) from the network. The network has not been designed to handle constant Confirmed uplink messages. This will negatively impact the overall capacity of the network. Therefor the use of Confirmed uplink messages is part of our Terms of Use.

No more than 10% of the uplink messages of your Device may be Confirmed messages. All other messages must be Unconfirmed.

<figure><img src="https://docs.kpnthings.com/~gitbook/image?url=https%3A%2F%2F375540290-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjicqUuNvLnahtbiB0G8m%252Fuploads%252Fj71l6tzFgJHOJvWBtaYz%252Fimage.png%3Falt%3Dmedia%26token%3Da1dc8415-9259-4ceb-9dde-a8ee6a740780&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=55e83bbd&#x26;sv=1" alt=""><figcaption></figcaption></figure>

### LoRa Connectivity details <a href="#lora-connectivity-details" id="lora-connectivity-details"></a>

This tab contains detailed information about how your device is configured inside the LoRa network. When a device is added to the LoRa network, it is configured with a _device profile_ and a _connectivity plan_.

#### Device profile <a href="#device-profile" id="device-profile"></a>

The device profile name consists of three things: the _device profile_, the _LoRa class_ and the _LoRa version_.

The **profile** is used when determining the geolocation of a device. Generally speaking, the geolocation can be determined with greater accuracy for slower moving devices than for faster devices. This is because the algorithm will use the average location of multiple measurements for slower devices.

The profile should describe the motion of the device as it is being tracked. A stolen bike, for example, is usually in one place as it is being located, so it should have the static profile.

The **LoRa class** is either A, B, or C. Class A is the most common and is typically used by battery powered devices to minimize power consumption and maximize battery life. [More information about the LoRa class is here.](https://docs.kpnthings.com/lora/technical-information/messaging-capabilities)

The **LoRa version** is currently always 1.0.x.

| Profile     | Class | Version | Typical Use                                                                                 | Device Profile ID         |
| ----------- | ----- | ------- | ------------------------------------------------------------------------------------------- | ------------------------- |
| Static      | A     | 1.0.x   | Battery powered door bell.                                                                  | Static V 1.0 Class A      |
| Slow moving | A     | 1.0.x   | Roll-carts, animals, ships or bicycles.                                                     | Slow moving V 1.0 Class A |
| Fast moving | A     | 1.0.x   | Cars and trains.                                                                            | Fast moving V 1.0 Class A |
| Nomadic     | A     | 1.0.x   | Roll-carts or parcels that you need to trace while in transit and register on a checkpoint. | Nomadic V 1.0 Class A     |
| Static      | B     | 1.0.x   | Battery powered always reachable sensor.                                                    | Static V 1.0 Class B      |
| Static      | C     | 1.0.x   | Net powered street light.                                                                   | Static V 1.0 Class C      |
| Slow moving | C     | 1.0.x   | Reserved for future use.                                                                    | Slow moving V 1.0 Class C |
| Fast moving | C     | 1.0.x   | Reserved for future use.                                                                    | Fast moving V 1.0 Class C |
| Nomadic     | C     | 1.0.x   | Reserved for future use.                                                                    | Nomadic V 1.0 Class C     |

#### Motion indicator <a href="#motion-indicator" id="motion-indicator"></a>

A more fine-grained version of the profile of a device. Values are Near static, Walking speed, Bike speed, Vehicle speed, and Random. Like the profile, this is used when determining the geolocation of the device.

#### Connectivity plan <a href="#connectivity-plan" id="connectivity-plan"></a>

Determines the capabilities of the device in the network. Things like how many uplinks and downlinks the device may send and receive, whether to perform geolocation and whether to use a channel mask are configured using this setting. A bit like your mobile phone bundle, this setting also determines the price for device connectivity. This is set by KPN and can't be changed.

### Data protocol choice <a href="#data-protocol-choice" id="data-protocol-choice"></a>

KPN Things supports all LoRa data protocols. All data representations can be forwarded as raw hexadecimal payload to each [destination type](https://docs.kpnthings.com/kpn-things/components/destinations).

But if you use a LoRa data protocol that is known to KPN Things, your payload can be decoded in KPN Things, allowing you use additional [data processing ](https://docs.kpnthings.com/kpn-things/components/data-processing-flows)features in KPN Things. There are several options to:

1. Use a device that is already in the [supported device types list](https://docs.kpnthings.com/kpn-things/components/devices/device-types/streamline-lora).
2. Contact [iot@kpn.com](mailto:iot@kpn.com) to get your device in the supported device types list.
3. Use [ThingsML ](https://docs.kpnthings.com/kpn-things/components/data-processing-flows/thingsml-and-senml/thingsml)as data protocol. ThingsML is an extension of [SenML](https://docs.kpnthings.com/kpn-things/components/data-processing-flows/thingsml-and-senml/senml) that is suitable for LoRa communication.

Devices with LoRa connectivity have some specific tabs on the [Device detail page](https://docs.kpnthings.com/kpn-things/components/devices#device-detail-page) to display LoRa specific information.

### Learn more <a href="#learn-more" id="learn-more"></a>

Want to learn more about LoRa connectivity? Head on over to our [KPN LoRa documentation](https://docs.kpnthings.com/lora/)!
