14 December 2021

Announcements

• Support for Class B devices is now available throughout the Netherlands. If you want to test with Class B devices, you have to log a ticket via our service portal.

• Roaming in several European countries is now technically available to all customers.

Releases

• In early December, the LoRa core will be provided with a new software version. This small update will improve overall stability.

• The LoRa Internet facing servers now support ipv6.

10 August 2021 LocSolve release

Release 1.2.29a

1. After a previous release the Fcount had some issues. This resulted in duplicate messages not being able to merge. This is now fixed.

2. Services kept restarting. This is now fixed.

Release 1.2.28

1. Parameters are adjusted in the locsolver so that deviations can be noticed more quickly. This will make the location more accurate.

2. Network supplier has tested the behavior of the locsolver. Through this test they saw that sometimes in a certain situation data is lost when sending a location message. This issue has been corrercted.

3. Stability of locsolver has been improved.

4. In some cases the locsolver makes an RSSI message and a TDAO message at the same time. This is now changed to TDOA.

Geographical coverage

Channel setup

Currently KPN’s network supports the 16 channels in Table 1. When configuring devices, customers must make sure they support at least the first 3 LoRaWAN default frequencies and enable ADR, because the other channels will be added dynamically and could vary for each region.

*) mandatory channels **) Channel always disabled through channel mask LinkADRReq command, because of relative high interference on this frequency

Within the EU and US, one chipset can be used to support the 868 and 900 MHz LoRaWAN frequencies. As frequencies differ, a different antenna should be used.

When OTAA is used, the DevEUI, AppEUI and AppKey are needed to register the device on the network. The NwkSKey and AppSKey are derived when joining the network. The advice for the frequency of periodically rejoining depends on the number of messages sent by the end device and the level of security required.

A device should re-join:

• Every time it has lost the session context information.

• Every x days

• Every y messages

The x and y values may differ depending on the level of security required; appropriate values could be once a month or maybe once every 2-3 months. The security risk depends on the application: metering applications sending a low amount of values typically do not need very frequent re-keying, while critical applications (e.g. alarms) would require more frequent re-keying. Currently KPN has no precise defined time or number of messages when a rejoin will be forced. Customers should make sure their device and application can still work and build a connection when a rejoin is required.

During the OTAA join, the network:

• Generates a NwkSKey and AppSKey and stores them as long as there is no new join procedure initiated.

• Forms a Join response payload that will allow the end device to compute a NwkSKey and AppSKey.

• As part of the Join procedure, the network also allocates a DevAddr to the end device.

Note: ABP configurations are not allowed on the network as this provisioning method does not meet KPN's security standards.

LoRaWAN supports both uplink as downlink messaging; messages from end-device to the network are called uplink and network to end-device messages are called downlink. The most common way to use LoRaWAN is to use the uplink so a sensor can report any value to the Application Server. Under certain conditions it might be useful to use a downlink message to provide the sensor with an acknowledgment to make clear that the message has arrived in the network and will be forwarded to the Application Server.

Downlink messages can also be used to control settings of the sensor, for instance to adjust its update frequency or any other settings on the appliance. To make sure that this downlink has arrived an acknowledgment can be sent via the uplink, so the Application Server gets notified that the sensor has received its new settings. Another application of downlink messages could be to control an actuator like a valve or a lock.

The maximum number of messages per day is related to the fact that KPN operates the LoRa network in the unlicensed 868 MHz ISM band. The number of messages is limited due to the duty cycle and payload in combination with the quality offered by the network. The 868 MHz ISM band limits the use of a device to 1% of the time on air. Meaning a sensor sending a message which takes 1 second should be quiet for 99 seconds after that. The time on air itself is related to the message size and the distance to the gateway.

The closer the end-device is to the gateway the higher the data rate (and the lower the Spreading Factor used in the LoRa modulation). While being very close to the gateway the time on air will be minimum (low modulation overhead) and maximum payload can be used, so more messages per day can be supported. Because downlink capacity is shared across all talking end-devices this is more limited than upload messaging.

The LoRaWAN protocol offers two layers of security implemented using the AES128 algorithm. On the network layer, the integrity of a message is enforced by the Message Integrity Code (MIC) and on the application layer the payload is encrypted. This means it is possible to have end-to-end encryption of the LoRa data. For LoRaWAN the used network keys are in the KPN domain and the application keys are in the customer domain and must comply to usage policies to prevent easy to guess variables. In the case of over the air activation (OTAA) the used NwkSKey and AppSKey are managed from the KPN domain (Join service) and can be periodically refreshed. Figure 4 shows the domain of the NwkSKey and the AppSKey.

KPN not only depends on the included security mechanisms such as Over-The-Air Activation (OTAA) and AES128 in the LoRaWAN protocol specification, but it also applies KPN security mechanisms.The complete solution is hosted in KPN owned datacentre premises on which the Corporate Security Policy Framework (CSPF) is applicable. The KPN CSPF consists of a set of policies, standards and guidelines and is derived from high level KPN Group Corporate Security Policy. The CSPF is based on the international standard for information security (ISO27001 ) and the international standard for business continuity (BS25999).

The connection towards the customer Application Server is using the HTTPS protocol with TLS v1.2 signed certificate requirements. Within this tunnel the application data is authenticated by using bi-directional SHA-256 token calculation.

Added security by using the HSM

To make the LoRa network carrier grade, KPN uses a Hardware Security Module (HSM). Using the HSM will ensure that the payload of each message is encrypted end-to-end, from device to application server. The KPN network will not be able to decrypt or read the encrypted payload and will deliver the payload to the application server in its encrypted state, allowing the user to decrypt the message. To make end-to-end encryption possible, users are required to generate a RSA public and private key set. In addition to the end-to-end encryption, keys will be stored in encrypted state on the LRC to ensure the highest level of security of sensitive data.

Replay attack prevention mechanism

The network owns a mechanism that prevents replay attacks from having any effect. The replay attack prevention mechanism uses the frame counter (FCntUp) to determine whether an incoming message is valid. If a new message with the same counter as the previous message is sent, this message is ignored. As a result of this mechanism, it is not possible to turn devices off after every message without storing the counter-value. Since switching the device off resets the counter value, the device will only send messages with FCntUp=1. This means that all messages will be ignored by the network; consequently, the device will no longer send messages to the Application Server. It is not in accordance with the LoRa specifications to constantly reset the counter of a device, and thus the Replay Prevention Mechanism was implemented to increase the safety of our network and its growing user group.

KPN uses LoRa modulation and LoRaWAN as LPWAN technology. The radio and modulation part is specified and patented by the company Semtech . The LoRa Alliance is in charge of standardizing the LoRaWAN part of the stack. Figure 2 gives a graphical representation of the complete stack.

Communication between communication devices and gateways is spread out over different frequency channels and data rates. The selection of the data rate is a trade-off between communication range and message duration. Within the selected channel the LoRa protocol, which is a chirp spread spectrum modulation technique, determines how many bits are required to code the data (coding rate) which results in a maximum data rate. The basic principle of spread spectrum is that each bit of information is encoded as multiple chirps. Within the given bandwidth the relationship between the bit and chirp rate for LoRa modulation may differ between spreading factor (SF) 7 to 12. The communication device may transmit on any channel available at any time, using any available data rate, as long as the following rules are respected:

• The communication device changes channel in a pseudo-random fashion for every transmission. The resulting frequency diversity makes the system more robust to interferences.

• The communication device respects the maximum transmit duty cycle relative to the sub-band used and local regulations.

• The communication device respects the maximum transmit duration (or dwell time) relative to the sub-band used and local regulations.

LoRa data rates range from 0.3 kbps to 50 kbps. Depending on the environmental conditions between the communication device and the gateway the network will determine the best spreading factor (SF) to work on. To maximize ba ttery life, range and overall network capacity, the LoRa network infrastructure can manage the data rate and output power used for the communication for each device individually by means of an adaptive data rate (ADR) scheme. This means that the better the coverage is, the lower the SF will be (Figure 3). KPN requires all users to turn on the ADR functionality to prevent unnecessary congestion in the network. ADR is switched on in the device itself, not by the network. In cases where ADR cannot continuously be used, the device needs to know when to temporarily turn off ADR and must switch it on again as soon as the use case allows it.

KPN’s Low Power Long Range (LoRa) network service is based on a relatively new LPWAN protocol for IoT and supplements existing 2G, 3G, 4G and LTE-M networks. The network eliminates significant barriers such as cost and energy consumption so that numerous (battery powered) devices can be connected. KPN has equipped hundreds of existing mobile transmission towers across the Netherlands with a LoRaWAN gateway and antenna, allowing millions of devices to be connected.

Figure 1 provides an overview of an IoT solution connecting sensors to an application server. In the figure, the following components can be distinguished:

• Sensor

• Communication device

• LoRa connect service domain

  o Network access and server

  o Software platform

• Application server

• Application

KPN offers two separate products that use KPN's LoRaWAN. The most recent and complete product is KPN Things. KPN Things offers several connectivity options, including LoRaWAN and on top of that offers options, like hardware, data management and applications. The second possibility to use KPN's LoRaWAN is the ThingPark platform. This platform was introduced at the launch of the network and is now offered only in cases where the regular option, KPN Things is not viable. The ThingPark platform offers, in addition to complete management of the operational LoRaWAN network used by KPN staff, the following functionality towards the customer:

• Device (subscription) management

• Insight in message flow

• Data routing towards the customer’s Application Server.

Certification

To ensure that KPN’s customers will experience the same quality of the KPN LoRa network as any other high-quality KPN mobile network, all LoRa devices that are connected to the KPN LoRa network must be follow the certification guidelines, compiled by several operators in the Collective LoraWAN Device Qualification Program (CLDQP). The requirements can be found at https://lora-alliance.org/in-the-news/collective-lorawanr-device-qualification-program.

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.

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

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.

The principle of the ADR (v3) algorithm in the LRC is based on a quality of service target to compute the optimal settings for communication between network and device. The settings of the spreading factor, NbTrans and TXPower. The algorithm will always first consider the primary quality of the Packet Error Rate (PER), the Minimum Antenna diversity and the Macro Diversity Reliability. After optimizing the settings for the communication from and to the device, the network will keep monitoring on these primary settings and adjust settings when necessary.

The tuning is done by adjusting the settings of the spreading factor, NbTrans (number of transmissions of each message) and TXPower (transmission power). The algorithm will use the primary quality targets of the Packet Error Rate (PER), the Minimum Antenna diversity and the Macro Diversity Reliability. After optimizing the settings for the communication with the device, the network will keep monitoring on these quality targets and adjust settings when necessary.

The network will adjust settings in the following priority if any of the quality targets is not met:

1. TXPower

2. NbTrans

3. Spreading Factor

After optimizing these primary settings and if good radio conditions are present, battery conservation optimization will be initiated. If possible, the algorithm will now adjust the previously mentioned settings to reduce battery consumption, while maintaining the quality of service.

The network will adjust settings in the following priority if the quality targets are met and battery consumption can be optimized:

1. NbTrans

2. Spreading Factor

3. TXPower

The LoRaWAN protocol is capable of transferring sensor data or changing the behavior of an actuator. LoRaWAN can be used for both uplink (device to network) as well as downlink (network to device) messaging. Within LoRaWAN, there are three traffic categories defined:

*) The KPN LoRa service currently supports LoRaWAN Class A and C

Multitech MultiConnect Conduit AP LEU1-868 (4G & Ethernet)

The MTCAP-LEU1-868 is delivered including a KPN micro SIM card that automatically connects to the KPN 4G network. The gateway will only work with this SIM card and removing or replacing the SIM will result in a non-functioning gateway. For the specifications of this gateway, see the Multitech specification document of this gateway type. Please note that a stable 4G coverage is required for this gateway to function when only using a SIM card. The coverage area and range of the gateway depends on the presence or absence of obstructions in the direct surroundings of the gateway. When there is a clear line of sight and the surfaces are not reflective or unusually rough, the expected range of the gateway in an indoor environment would be around 500 meters. The vertical signal lines are limited due to the alignment of the antennas.

Requirements for mounting

The device is shipped with a mounting bracket. To mount the device, you will need:

• The gateway with mounting bracket

• Screwdriver

• Four #6 screws, with anchors (not provided)

• Drill

Determining the mounting location

• Select a location that is central to all the devices you want to connect to this gateway. Place the device as high as possible, such as near the top of a wall.

• Avoid obstructions. Thick walls and reflective surfaces, such as metal, weaken the signal between the gateway and other devices.

• Note the location of the LoRa antenna in Figure 1. The signal will be strongest radiating from that side of the device. The LoRa antenna is 31.2 mm long.

• The LoRa antenna is an omni-directional antenna, but for best results, mount the device so the LoRa antenna is in a vertical position near the top of a wall. We recommend conducting a site survey to test the signal strength in different locations before you mount the device.

Mounting the gateway

• Determine where you want to mount the device.

• Mark where you want the screws to go.

• Drill holes for the screws and insert anchors.

• Place the mounting bracket and secure it with screws.

• Attach the device to the bracket and rotate to lock into place (Figure 2).

Connectors and LED's

Connectors

LED's

Connecting over Ethernet

When using the gateway in combination with an Ethernet cable, make sure that the gateway is directly connected to the internet. When it is connected to an intranet or when it is obstructed by a firewall, the gateway will not function. When issues occur on an Ethernet connection, make sure that the Ethernet cable leads to a direct internet connection before contacting the IoT Service Desk. They will not be able to support a gateway that is not directly connected to the internet.

Please note that when both the Ethernet and SIM card are used by the gateway, the Ethernet connection will always be chosen as the preferred connection, with the 4G connection as backup. Switching to the backup and back to the preferred connection might take a while.

Installing a SIM card

Your gateway might be delivered with a SIM card already in the SIM slot. If this is not the case, please make sure you place a micro SIM card meant for LoRa use, provided to you by KPN. If you are uncertain if you have the correct SIM card, please contact the IoT Service Desk.

To install the SIM card, align the notched edge with the contact side facing down as shown in Figure 4. Slide the SIM card completely into the SIM holder. Do not remove the SIM card from the gateway, since this will cause the SIM card to get blocked in the network.

Live use

When the gateway has been placed in the desired position and is switched on, wait until the ‘STATUS’ and ‘CELL’ light start blinking and the ‘LORA’ light is on. Your gateway is now ready for use. In case an ethernet connection is used as well, verify that the left Ethernet LED is lit.

To verify if your gateway is receiving messages, please make sure you have a LoRa device nearby to use with the gateway. The gateway is also called LRR (Long Range Router) and each gateway has its own ID, called a LRR ID. When you have sent a few uplink messages near your installed gateway, consult the traffic from the device in the Wireless Logger or on your Application Server.

When you traced the messages sent by your testing device on the Wireless Logger or Application Server, check the LRR ID field or list of receiving LRRs for the sent messages. You should see the same (Ethernet) MAC address as displayed on the back of the gateway.

In the example of Figure 5, you can identify the gateway in the Wireless Logger or on the Application server by the LRR ID 004A21CB.

KPN is continuously improving the performance of Geolocation. The accuracy might therefore vary from time to time. In short, when using the Geolocation functionality, you can expect the following:

• Static devices will have a higher accuracy than moving devices.

• Slow-moving devices will have a higher accuracy than fast-moving devices.

• Rural areas should provide higher accuracy than suburban areas.

• Suburban areas should provide higher accuracy than dense urban areas .

• In urban areas, high rise buildings will negatively influence the accuracy .

• When a static device is turned on, the accuracy will improve during the first subsequent messages.

• The accuracy will be less near the borders of the Netherlands (since less gateways will be available).

Another influence on the accuracy of Geolocation is reflection of the radio signal. Due to the reflection, you might see larger and more unstable deviations than average. This is especially relevant in areas with a lot of water, in densely-built environments and in areas with a lot of machinery or metal constructions.

KPN has done multiple tests and the following is an indication of the performance of Geolocation with different settings and in different environments. The results of these test are provided in the table below. As KPN works on improving this service continuously, the parameters are subject to change. For the results below, the number of different messages used to calculate the position lies between 3 and 8.

LoRa Geolocation is designed for outdoor applications. Please note that LoRa Geolocation is not designed to be used at indoor locations or for indoor use cases. While localization will quite frequently work for indoor use cases, KPN will only support he Geolocation functionality for outdoor usage. The main influence for indoor usage is the building material, which may prevent the LoRa message from being received by the minimum number of required gateways.

Accuracy of TDoA

Static device performance in The Netherlands

As stated earlier, several factors impact the accuracy of the Geolocation service. In general, the graph in the figure below is representative of the average accuracy in the Netherlands (all locations and all environments for a Static device profile). Depending on your location and environment, you can experience better or worse performance:

• 95% of the measurements are under 100m

• 50% of the measurements are under 60m

Accuracy in high building environments

To give an example of the impact of different environments, KPN has executed specific testing in a environment with tall buildings (more than 6 floors) in the Hague and Rotterdam with Static devices. The 95-percent interval could increase up to 250 meters in case of reflections (Figure 9). The main influence is the reflection of the uplinks. KPN expects to improve this specific case in the near future.

Accuracy of slow-moving devices (max. 25 km/h)

KPN has already performed tests with slow-moving devices. We believe that the majority of use cases should use the Static Device Profile. The main focus of our improvements is the stability and accuracy of Geolocation for static devices. To give an indication, Figure 11 shows the average performance for end devices on slow-moving device profiles.

Accuracy over time

The relevance of the number of uplinks that can be used by the locsolver is shown in Figure 10. While the accuracy with three messages is around 200 meters, it improves by 30% to around 130 meters after 15 messages. This information is relevant for the design of your solution.

Accuracy of RSSI and Both (compared to TDoA)

On introducing the RSSI and Both algorithms, we have done some tests to compare performance in success rate and accuracy.

These are the results:

So RSSI and Both have a higher success rate than TDoA, but the accuracy of TDoA is better than Both, and significantly better than RSSI.

Now let us compare the cumulative distribution function (CDF) of TDoA and Both. In this CDF you can see, for a given accuracy of Geolocation in meters, the percentage of messages that has at least that accuracy. We can see that up to around 80% of the messages, the accuracy of TDoA and Both are about the same. Then, the graph for TDoA becomes a flat line, indicating that there are no more locsolves. The graph for Both still keeps rising, indicating additional locsolves with a higher accuracy.

So from this we can conclude that the Both algorithm is a valid extension of TDoA, leaving the original locsolves intact and filling in missing locsolves with RSSI locsolves.

LoRa Geolocation will localize your LoRa device without needing additional effort from your device. Although device-side localization solutions like GPS can be more accurate, the network-side solution LoRa Geolocation does not add energy consumption to a regular LoRa device. In combination with the already low prices of LoRa devices, LoRa now supports new use cases and opens new markets. Applications like tracking of mid-valuable assets such as machines, pallets and tools are now possible which were not feasible before.

The KPN LoRa network has three LoRa Geolocation algorithms available, with each different aspects. You can learn more about the performance of these algorithms on the .

• Regular LoRa customers can often choose which LoRa Geolocation algorithm to choose.

• For KPN Things customers, on November 3rd, 2020, the default algorithm has been changed from TDoA to Both.

More information on how the algorithms work can be found on the .

Disclaimer

1. Except in case of intent and/or gross negligence on the part of KPN, KPN is not liable for any damage. Customer shall indemnify KPN against claims by third parties for compensation for damage caused by or through the use of the Geolocation functionality, or as a result of the customer not being compliant to its obligations.

2. The (intellectual) property of the equipment, programming and documentation supplied by KPN to the customer belongs to KPN or a third party that authorized KPN to share the equipment, programming, data, reports, advices and documentation to the customer.

3. When using Geolocation, keep in mind legislation (both Dutch and European) regarding privacy and personal data of natural persons. (Wet Bescherming Persoonsgegevens, Algemene Verordening Gegevensbescherming, General Data Protection Regulation).

4. The included numbers and figures are the result of intensive testing by KPN. As it is still a relatively new service, customers may experience a deviation of those numbers. The numbers provided cannot be used as an SLA (Service Level Agreement).

Mathematics

This section simply explains the math behind both types of algorithms.

Time Distance of Arrival (TDoA)

The mathematical principle behind Geolocation is Time Difference of Arrival (TDoA). An uplink message of an end device is received by a gateway and the exact arrival time (timestamp) at this gateway (nanoseconds) is attached to the uplink. The different timestamps between the gateways are used by the “Locsolver” to calculate the exact position of the device. In order for multilateration of arrival times to work properly, it is required to use a minimum of three gateways. The formula and visualization of this principle are shown in the figure below.

You can read more about multilateration on Wikipedia:

Received Signal Strength Indication (RSSI)

Now if we have multiple gateways receiving the same message, we have multiple distances to calculate with. The mathematics employed in this case is called trilateration. The drawing below illustrates how you can calculate a location with these known distances.

You can read more about trilateration (also known as True-range multilateration) on Wikipedia:

The downside of this method of localization is its accuracy. Because there are a lot of unknowns in wireless communication. The free-space path loss is not constant, but can depend on temperature and air pressure at the moment of transmission. Also, who says that the signal only travels through air? Sometimes a building is in between a Device and a Gateway, resulting in additional signal loss, meaning the Gateway things the Device is farther away than it really is. And these inaccuracies are quite significant, resulting in sometimes kilometers of measurement errors.

Algorithm

This section highlights some parts of the LoRa Geolocation algorithm in the KPN LoRa network.

Both algorithm

When using the Both algorithm, the locsolver (short for Geolocation solver) will first try to calculate a location for an incoming message using TDoA. If this does not succeed, the locsolver will try to use RSSI. This way, the Both algorithm should leave the performance of TDoA calculated locations intact, and fill in the missing locations by using RSSI.

Compared to a TDoA only configuration, you can expect the following:

• The success rate will go up, since the gaps of missing localizations will be filled with RSSI.

• All messages that would be solved by the TDoA only algorithm will also be solved by TDoA when using the Both algorithm.

• The average and mean accuracy of all localizations will go up, but only because messages that first were not solved, are now solved with the less accurate RSSI algorithm. And since the theoretical accuracy of individual localizations is provided to the application, you are able to determine what to do with each incoming localization.

Motion indicator

The locsolver algorithm uses different clusters, cluster sizes, time windows and historical data to calculate new locations of a device. Several operational examples are found below; they are summarized in the table below.

The algorithm uses the information it receives within a time window of 30,000 seconds. This is combined with the data in the cluster of the last 8 calculated locations. If the motion indicator Static is used, the algorithm also tries to detect if the device has moved in the last hour and it adopts the cluster size used in the calculation of the location.

This table is subject to change with the optimization of the locsolver algorithm.

The KPN LoRa On Premises Gateway is meant for use at locations that are not covered by the KPN LoRa nationwide coverage in the Netherlands, locations where a high density of LoRa devices is present or locations where an increased coverage quality is desirable to extend battery life to a maximum.

Differences with the nationwide network

The interaction from device and application server perspective with an On Premises Gateway does not differ in any way from the interaction with the nationwide network. There are no modifications required for the device or application server. The On Premises Gateways directly forwards data from end points towards the KPN LoRa Core.

Having an On Premises Gateway at an indoor location brings the possibility to bring the Spreading Factor at indoor locations down to 7, which results in faster message traffic and thus capacity for more devices. Duty cycles limitations however, still need to be applied. This counts for both the gateway as the devices.

Since the On Premises Gateways are delivered plug-and-play, they can be deployed easily at almost any location. This offers a lot of flexibility in bringing solutions to your customers. When deploying an On Premises Gateway, pay attention to the local laws and regulations regarding the LoRa frequency used by the gateway and the applicable duty cycles in that specific area.

Placement

Radio signals are blocked or reduced in strength when it needs to pass through an object. This means that the pathways from a gateway to the device(s) should contain the least amount of obstructions possible. Keep in mind that the thicker a wall is, the more of the radio signal is blocked. The signal will also be reflected by mirrors, metal structures and vast amounts of water.

Furthermore, the gateway should only be used in a static position. Using the gateway while moving it is not allowed, since this interferes with the optimization of other customer devices that the gateway connects to while being mobile.

Devices other than your LoRa devices, using the 868 MHz frequency could interfere with the radio waves that are transmitted by LoRa devices over the same frequency. Avoid using these devices nearby.

Limitations

The On Premises Gateways do not support Geolocation at this time due to the complexity involved with the Geolocation service. Furthermore, as previously mentioned, the legal duty cycle is still applicable for the gateway. This means that the number of downlinks is limited to 1% transmission time meant for RX1 and 10% transmission time meant for RX2. When a gateway disconnects over a long period of time, it will be blocked from connecting to the KPN LoRa network for security reasons. If you suspect this happened, please contact the IoT Service Desk.

Returns

When your contract with KPN for the LoRa On Premises Gateway ends, you can contact the IoT Service Desk to send you a return box. Do not send KPN the gateway without notifying us about the return. Use the address supplied .

The easiest way to use the Thingpark Device Manager is through the web interface found on . This web interface gives you the possibility to access all basic functions of the Device Manager.

However, provisioning or updating large numbers of devices can be a lot of work if done through the web interface. For this purpose we provide you with the Device Manager API.

Getting started

The starter documentation of the Device Manager API can be found following the link below. All API calls you need for managing your device can be found in this postman collection. If you want to do more using the API, please read on at the bottom of this page at Going further.

Setting up Postman

2. Open the documentation using the link above and click on the Run in Postman button in the top right of the page. This will open the collection in Postman.

Setting up another client

When using another API client or when you are writing your own scripts using the Device Manager API, make sure of the following things:

• The base URL for all API calls is https://www.kpn-lora.com/thingpark/wireless/rest.

• Enable cookies on all API calls, else the session on the API side will not stick.

Quick start

The following steps allow you to authenticate yourself to the API, get some data using an API call and log out again.

With this request you use your credentials to obtain an access code to access the Device Manager API. Fill in the email address and password of your Thingpark Subscription Account in the corresponding body parameters in the request and send the request.

The response of the login API call will be HTML and it will be as following:

You need to check two parts in the response body. The errorCode-span will contain an error code when there is an error. The following error codes can occur:

The redirectURI-span will contain an URI when you successfully logged in. You should take the userAccessCodeattribute from the URI.

The Postman example contains an after-request test that will interpret the error code for you. Also when successfully logged in, the test will store the userAccessCode you in your Postman Environment.

After obtaining the userAccessCode, you need to start the API session using another API call. The result of the Start session API call will give you the sessionToken and subscription values that you need for all other API calls.

The Postman example stores these values in your Postman Environment.

After you obtained the sessionToken and subscription values from the previous API call you can do all data API calls in the Device Manager API. This API call, for instance, returns you the information of your subscriber.

After executing all API calls you want, you can close the session with this API call. It will render your sessionToken invalid.

More information

Base URL

Data types

All examples are in JSON, but the API will also support XML as data type. Set the Accept header to one of the following values as you wish:

Going further

Additional information on all available API calls in the Device Manager API can be found here:

Disclaimer

The current Device Manager API is part of the so called OSS-API which is not part of our current Service Level Agreement. This means functionality can change without notice. Soon the KPN Things API's will provide you with means to provision your LoRa device through serviced API's.

The access rights to the software platform are controlled by KPN as an operator, KPN can provide customers with access to their instance or disable this access.

• To login to the LoRa subscription management portal the following URL can be used: https://www.kpn-lora.com/deviceManager/

• Tooling to verify the device connectivity, hereafter called wireless logger function is accessible via: https://www.kpn-lora.com/wlogger/

• To send a message to a sensor the following downlink URL can be used: https://api.kpn-lora.com/thingpark/lrc/rest/downlink

What is the influence of buildings?

When a device sends a signal in a highly reflective environment, it will hardly ever reach the gateway directly. The signal will bounce from one or multiple buildings until it reaches the gateway. This will create a longer path, later fine timestamp and a lower accuracy.

If the device is mounted directly next to a window (with coating) or concrete material, reflection will negatively impact the accuracy of Geolocation.

Do I need a special device to make use of LoRa Geolocation?

In general, you do not need a special device. However, instead of just having a connection (one gateway) as with regular devices, messages need to be received by multiple gateways to perform the most effectively. So, to increase quality, special attention should be given to antenna design, signal direction and configuration of the device (concerning ADR, for example).

What is KPN’s focus for improvements concerning the Geolocation service?

For now, we see that static performance is most important for our customers, so we are improving both accuracy and stability (success rate) for static device profiles first. We also noticed that the “first time Geolocation accuracy” is relevant for our customers. We are constantly innovating our IoT services and, as we are the first operator in the world to offer nationwide LoRa Geolocation, we are still expecting many improvements of this service in the future.

What about indoor Geolocation?

There is quite some pull from the market for such services. Most of the time, solutions based on LoRa only are not sufficient for indoor Geolocation, but this does not mean that KPN is not able to help you. Please talk to our IoT team; we have quite some experience with devices that support multiple technologies (RF, Bluetooth, GPS) to answer your needs.

Which Spreading Factor (SF) should I use for Geolocation?

The best practice is to enable Adaptive Data Rate (ADR) on your device, so that the network can calculate the best Spreading Factor. In the field tests KPN has performed together with customers, it turned out that using SF12 does not always provide the best results, since using SF12 results in a bigger chance of collisions in the air.

How can I improve signal quality for Geolocation?

Make sure all aspects of the device are well-designed. Take, for instance, the antenna design. A good antenna design will give you a better range, which translates into a higher accuracy of the LoRa Geolocation service. Also make sure to review the entire solution design. The antenna and device might be of very good quality, for example, but the solution as a whole would still function poorly if it is fully encased with the wrong materials. For the test houses that can check your antenna design on radio performance, visit https://www.lora-alliance.org/certification-overview.