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 certified. Certification of the LoRa devices can be performed by several official test houses that are working with the LoRaWAN Certification Program. An actual overview of certified devices can be found on the website of the LoRa Alliance.
In order to enable development, KPN allows small volumes of uncertified devices on the network. This is only allowed in development projects that have a goal of certification in the long term. The LoRa Developer portal is specifically intended to help in this type of development.
When devices or modules are used that are certified themselves, no extra certification is needed as long as no changes are made to the devices of modules that could impact certification. However, in case the implementation of the LoRaWAN protocol on certified devices or modules is changed, a new certification will be needed.
Minimum requirements for using the KPN LoRa network
The minimum requirements have been changed to a standard that is valid for several operators and, among other things, supports the preparation of roaming between LoRaWAN operators. This is the Collective LoRaWAN Device Qualification Program (CLDQP). This way, the requirements are the same everywhere in the near future and users are not faced with surprises if they want to use a different network.
The minimum requirements for using the KPN LoRa network are:
LoRaWAN Certification CM Version 1.0.1 or newer (test mode and continuous wave mode must be supported)
RF Performance tests
Device requirements/best practices
Apart from the device certification metnioned above, there are additional requirements and best practices for LoRaWAN devices:
- OTAA. All devices on the KPN LoRa network should be provisioned using Over The Air Activation (OTAA).
- (Pseudo)-random send-receive schedule. End-devices should send messages at pseudo-random times (and thus not send uplink or receive downlink messages at synchronised times). Synchronised messages will result in a heavy load on the network and it increases collisions making succesfull communication less likely.
- Reference configuration. Each End-Device must be able to use a reference configuration for troubleshooting. The reference configuration is a Class A device with ADR ON, which sends the first message on Spreading Factor (SF) 12.
- Remember network settings on reboot. When a device reboots often or synchronised with many other devices (e.g. on power cycle) this device must remember it's network settings. This enables the device to 'silently' rejoin without the need of new messages to join and set network settings. The network settings to be remembered include RF channels, Channel Mask, NwkSkey, AppSkey, Tx power and Datarate. Also it must remember the last used Spreading Factor and Frame Counters. This will prevent large numbers of simultanious messages for a power cycle and it limits the number of messages a device needs to send and receive.
- Packet Error Rate (PER). The LoRa protocol is very lightweight to reduce battery consumption and does not contain as many error correction methods as conventional communication protocols. KPN strives to have a optimal network performance., but will not be able to avoid collisions between LoRa packets in the air interface, meaning missed packets that will not be resend by the protocol. Solution Providers should build in error correction methods in their application to compensate for missed packets.
- Antenna design. Antenna design is one of the key factors in creating a properly functioning LoRa device. Please refer to the topic regarding Antenna Design