An IoT implementation can be quite challenging especially when a developer is not familiar with all areas. When adapting new technology people ask for best practices to make sure they are not reinventing the wheel. The points below give a first overview and guidelines that can be quite helpful for new solution providers and device makers.
- ADR and Join
Before joining the network, it is advised to set the device spreading factor to SF12 and enable ADR. This should result in sending out the join message on SF12 to have the greatest possible chance that a network join will be successful.
- ADR and maximum payload
Since the maximum payload length is related to the Spreading Factor, the application must know in which SF a message will be sent to determine the maximum payload length. To be sure data will fit all SFs the maximum payload length of SF12 which is 51 bytes can be used. In order to maximize the efficiency of communications in all situations (whatever the radio condition) framing should take place.
- Channel Selection
Please setup the device with the default LoRaWAN channels only, KPN will send a new channel list according to the region. When the device selects the frequency to use among the channels proposed by the network, we recommend implementing a random selection instead of checking the received channels one by one following the exact received order.
- Confirmed messages
Each downlink message (from network to devices) has a cost in the gateway duty cycle for every end-device. This should be considered when the application is developed. It is better to resend a couple of previously made measurements in the next message then to ask for an acknowledgement if this is not mandatory.
- Duty cycle
The KPN LoRa network is operated on an ISM band, which has a regulated maximum duty cycle. Please develop your application to respect the duty cycle. The purpose of the duty cycle is to provide a fair use for every transmitter. Do not develop exactly to the boundaries of the maximum authorized duty cycle and do not block the frequency.
Several application ports are available for data. Think about the way you set this up before you use different ports. It can be used to send to different applications or device management functions.
- Join procedure
The use of OTAA on the KPN network is mandatory, ABP is not supported. In order to increase the security level on end-devices they should generate a JOIN REQUEST when the context is lost and the keys used should regularly be updated. The update frequency depends on the use case and can be discussed with KPN to find the best implementation.
Both static and mobile devices need to implement a data rate adaptation algorithm. Please enable ADR as the network will not provide consistent data rate to mobile devices and the Spreading Factor needs to be optimized as the network will densify. Make sure that you select the right device profile to optimize the network connection according to the use case.
- Network connectivity check when using ADR
When ADR is used, there is a small chance that a device has received transmission parameters that render the device unreachable. The only way for the device to verify connectivity is to check the reception of downlink messages. When a device has not received downlink messages for a long time, the ADR acknowledgment request mechanism can be used. This mechanism in short means that after a certain amount of uplink messages without downlink answer, the device can start requesting an acknowledgement while starting to increase the spreading factor. The ADR_ACK_LIMIT parameter, expressing the allowed number of uplinks without downlink answer, needs to be set to 64.
- Repetition mechanism
Please develop applications respecting the duty cycle. If you implement a repetition mechanism use a back-off timer to allow a maximum of up to 3 transmissions to increase the radio performance.