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.
LoRa Device registration
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
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.
What you can see here is:
The type of LoRa message.
Whether it was an uplink (🔵 blue) or downlink (🟢 green) message.
Whether it was a Join request, Join accept or regular message.
Whether the message was confirmed or unconfirmed, or whether the message carried an ACK.
Whether the messages contained data, mac, or both.
Whether a LoRa Geolocation result could be determined on that message (only available for uplink).
The exact timestamp of the message, with millisecond accuracy.
The frame counter value of the message. Uplink (FCntUp) and downlink (FcntDown) communication has its own counter.
An indication of the signal strength the message.
Click on the chevron at the end of a row to see more details of a message.
Search bar to see the message history up to a certain point in time.
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:
Details about the message signal:
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.
The LoRa channel used. Currently 16 channels are support in the KPN network, see the KPN Thing LoRa documentation.
The number of gateways that received the message (uplink only).
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.
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.
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.
Details about the content of the message:
The LoRa application port on which data was send or received (if applicable).
The exact payload of the LoRa message (if applicable).
The exact MAC content of the LoRa message (if applicable).
Flags that were in the LoRa message, like
ACK,FPendingorADRAckReq.
Details of the LoRa Geolocation result:
Coordinates of the calculated location.
Radius in meters, the theoretical inaccuracy of the LoRa Geolocation result.
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.
What to expect on first use
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.
Below at the section 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.
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.
Check if your device is programmed/configured with the same DevEUI you find in the connectivity details on the Device detail page.
Check if your device is sending the join request on one of the default LoRaWAN channels. Learn more about LoRaWAN channels.
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 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.
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 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.
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.
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.
Other things you can see
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 of KPN Things.
Make sure your Device does not send more often than once every 5 minutes on average.
Example B. No answer to mac 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 side-effect 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.
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.
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.
LoRa Connectivity details
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
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.
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 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
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
KPN Things supports all LoRa data protocols. All data representations can be forwarded as raw hexadecimal payload to each destination type.
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 features in KPN Things. There are several options to:
Use a device that is already in the supported device types list.
Contact iot@kpn.com to get your device in the supported device types list.
Devices with LoRa connectivity have some specific tabs on the Device detail page to display LoRa specific information.
Learn more
Want to learn more about LoRa connectivity? Head on over to our KPN LoRa documentation!
Last updated
