LoRaWAN best practices

  • 27 June 2018
  • 2 reacties
  • 1753 keer bekeken

Reputatie 3
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.
  • FPort 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.
  • Mobility 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.

2 reacties

Thank you for the useful best practices overview.

About detecting network connectivity it seems to me that setting ADRACKReq after ADR_ACK_LIMIT is a nice way to implement it as it minimizes the number of downlink messages and gives the NS the chance to optimize downlinks. MachineQ wrote a nice article about this: https://machineq.com/post/how-to-detect-connection-loss-on-a-lorawan-device-and-why-it-matters.

What I don't understand why a ADR_ACK_LIMIT value 64 is considered a best practice. For example for devices which issue only a single uplink a day it would take 2 to 3 months before the device notices connectivity issues. For such devices I would consider to set ADR_ACK_LIMIT to 14 and ADR_ACK_DELAY to 10.
Hi @markruys,

You are right that there is a slight tweaking possible in the ADR_ACK_LIMIT and the ADR_ACK_DELAY in very specific use cases. However, since the ADR algorithm requires quite some uplinks to optimize the device transmission, lowering the ADR_ACK_LIMIT to a value lower than the KPN recommendations is not advisable. This interferes with the ADR mechanism and might cause the device to eventually drain its battery faster than it should.