- 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[/color]- [color=#094ab1]LoRa:[/color] Starters Guide
- [color=#094ab1]LoRa:[/color] Forum and Manuals
- [color=#094ab1]LoRa:[/color] Geolocation
- [color=#094ab1]LoRa:[/color] Dictionary & Definitions
- [color=green]FAQ:[/color] Frequently Asked Questions
- [color=green]Tools:[/color] www.LoRaTools.nl