LoRaWAN is a low-power wide-area network technology used to communicate with IoT devices. There are different providers who provide a LoRaWAN network.

Since LoRaWAN only standardizes the path from the end device to the network provider’s infrastructure, the interface to the end application must be developed anew for each network provider. Also, many IoT devices are out in the field and need to be managed remotely.

Abstracting Network Providers

The LoRaWAN Management Platform (LMP) fixes these problems. It introduces an abstraction layer between network providers and end application. This provides a uniform interface to the various network providers, which can be used to perform the usual actions such as create devices, delete devices, re-register devices as well as sending data packets to the device.

But the most important task the LMP takes on is receiving data packets from the IoT devices. When receiving such packets, the LMP saves them in an internal database before forwarding them to one or many end applications. To achieve this the LMP provides various connectors, such as simple HTTP POST or an interface into InfluxDB.

Abstracting IoT Devices

Thanks to the LMP not only the network providers can be abstracted, but also the end devices (sensors). The LMP can parse the transmitted binary data, and thus create a unified JSON, which can be processed more easily by end applications. This helps, for example, when devices with different firmware versions are in operation. Especially when they send the messages in different formats. The LMP can standardize these.

Analytics

Since the LMP acts as a broker between the network provider and the end application and thus sees all data packets, the LMP can already perform analyses. Alarms can be created, which are either sent to a responsible person, or the end application can be notified over HTTPS. This allows the end application to react in a custom way. For example, sensors can be detected that have low battery status, poor reception or a strange transmission frequency. Of course, alarms depending on the measurements of the end devices, e.g. low temperature alerts, can also be generated.

Scalability

Since we expect a larger sensor volume in the next few years, the requirement for scalability was a central concern. As a result, the LMP grows with the end application, and can even intercept unexpectedly high data volumes at short notice, thus smoothing out peaks.

User-Interface and API

All actions provided by the LMP can be executed either via a good documented API or via the user-friendly interface. Thus, the LMP is not only designed for software developers, but also for employees who develop or manage end devices.

“When out in the field testing some IoT use case, the LMP gives me the best possible overview. I can manage devices, see network diagnostics and see at which time the application got which data. I see what is going on and, if necessary, I can change the whole setup with a few clicks.” – Christoph Zaugg, IoT Hardware Engineer

Here is a summary

• Network provider abstraction: Develop only against one interface of the LMP, and use all supported network providers, without additional development time.
• Abstraction of the end devices: For new end devices, or a new firmware version, you can record the new protocol in the LMP. There is no need to roll out a new version of the end application.
• Central analysis: If you have several LoRaWAN end applications, you can still evaluate all data centrally.
• Scalable: The LMP grows with your use case.
• GUI: Thanks to a user-friendly interface, the LMP can be operated by all employees.