Requirements for your LoRa Devices

  • 13 September 2016
  • 7 reacties
  • 1665 keer bekeken

Reputatie 2
Badge +1
This post has become obsolete as it was incorporated in the Certification and requirements of LoRaWAN devices topic.

If you are going to make your own LoRa device it is important to know what requirements KPN gives for our devices. Here are a few requirements and some advise on how to build and config your device.

  • Certification: Each commercial LoRa solution with more than a few devices must be certified by the LoRa Alliance. See this topic for more information.
  • OTAA : Each solution with more than 256 devices must use Over the Air Activation (OTAA). This adds security becasue session keys can be renewed and enables easy roaming from one provider to another.
  • Random send/receive schedule: Solution providers must make sure that devices in their solution do not send uplink or receive downlink message at the same time (synchronised). Synchronised messages will result in heavy load on the network and increase collisions making succesfull communication less likely. Some (random) scheduling must be implemented to ensure that messages are spread out in time. This is especially true for OTAA devices that do join request triggered by time or power cycles.
  • Reference Configuration: Each device must be able to use a reference configuration for troubleshooting. The reference configuration is a Class A device, ADR enabled and send 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 and AppSkey, Tx power and datarate. Also it must remember last used Spreading Factor and Frame Counters. This will prevent large number of simultanious messages for a power cycle and limit the number of messages a device needs to send and receive.
  • Deal with packet-loss of 10%: The LoRa protocol is very lightweight but will inherently have more missed packets than conventional communication protocols. Please see this topic.
  • Moving Devices: should use static SF 10 (no ADR) to disable problems with ADR.
  • Well behaved counters: FctUp & FctDown counters should not be increased when a message is not send successfully. We have seen some devices not sending a message but increasing the FctUp for example, resulting in problems with ADR and false packet loss alerts in our network.
  • Regular OTAA rejoin: to enhance your device security we advise to rejoin your OTAA device at least once every year to refresh your AppSKey and NwkSKey.
  • Antenna design: a well-designed and placed antenna is crucial for success. Please refer to this topic on Antenna design.

Useful links

- LoRa: Starters Guide

- LoRa: Forum and Manuals

- LoRa: Geolocation

- LoRa: Dictionary & Definitions

- FAQ: Frequently Asked Questions

- Tools:

7 reacties

Sir I want know some details about your requirements,if i use a certified module with a sensor should i do a do a certification or a Certification-by-Similarity (i noticed this in LoRa Alliance™️ Certification Overview) .And you say devices in their solution do not send uplink or receive downlink message at the same time. So at least how long each device sends between.
Reputatie 7
Badge +6
Goodafternoon @ddddway,

Thanks for your reaction!

In this case i think you don't need a new certification or a Certification-by-Similarity. When you add a sensor to a certified module you don't change the module itself. The sensor is a addition to the module 😉

Furthermore, the downlink and uplink messages are linked to each other. When you send an uplink it is answered with a downlink. The time between these messages is a few milliseconds.
Thanks for your answer @Rick S.

I want know about how to use thingpark but i cant find any post about it.I can only find the link to Developer Portal .🤔 Please offer me a link to thingpark.
Reputatie 7
Badge +6
You're welcome @ddddway!

Off course I can send you the links from ThingPark. However, you only benefit from this if you also have a subscription with a ThingPark account. I see that you registered on the Developer Portal yesterday. This is the test environment where you can test your devices without a subscription. Do you already have a subscription and a ThingPark account?

ThingPark links:

Thanks @Rick S.

I got the ThingPark Wireless ™️Advanced Developer Guide,i will ask you here if i got some problems. 🙂
@Rick S.

Hello I find Simpoint and thingpark in this forum,What is the relationship between them ? If I want to join KPN Lora should I meet both of them or just one of them. 🤔
Reputatie 7
Badge +6
Hi @ddddway,

Simpoint is a reseller for LoRa subscriptions. Depending on the situation and the amount of devices we decide what the best solution is. ThingPark is the software platform for LoRa. So when you have a LoRa subscription within KPN or Simpoint, the data between your devices and application server are send through the ThingPark network.