Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Why is the Lobaro Platform mandatory for our NB-IoT Sensors & Gateways?

This common question often sometimes arises from integrators who run their own type of IoT platform tailored to a particular use-case and don't want an intermediate between their system and the IoT hardware to integrate. In contrast to this our platform is primary considered for device management of Lobaro and 3rd party sensors and gateways. It's meant as secure, stable and scalable abstraction layer to the actual hardware complexity and gives the following benefits to the integrator or end-user:

  • Client Encrypted data transfers using UDP and NB-IoT, client and server certificate-based secured data transfers , using DTLS between hardware and Lobaro while maintaining battery lifetime friendly UDP data transfers over NB-IoT
  • Functionality for remote configuration updates using simple standardized APIs (HTTPS PUSH, REST, MQTT, SFTP)
  • Functionality to trigger remote firmware updates if new features become available or a security update must be deployed
  • Providing a simple frontend for data retrieval independent of any upstream external system 
  • Merging different sensor technologies (e.g. Wireless-MBUS, LoRaWAN, NB-IoT) to create a uniform interface for connecting external systems and platforms.
  • , while still being able to use battery life friendly UDP transfers with little overhead.
  • Administration of client and server certificates.
  • Remote configuration of sensors via simple APIs (Web UI, REST).
  • Support for Firmware Updates Over The Air (FOTA).
  • Scalability, even with many thousands of data nodes.
  • Intermediate storage for sensor data before further processing in the downstream platform.
  • Data insight and export independent of downstream platform via CSV export or REST API.
  • Integration with LoRaWAN Network Servers (ChirpStack, TTN / TTI, Lotiot, and many more ...).
  • Unified API for downstream system across different connectivity technologies on the device side (e.g. NB-IoT, LoRaWAN, wireless MBUS, LAN).
  • Quickly bring IoT applications to market by focusing on the use case and the actual Fast time to market for integrators and platform operators, as they can focus on the use case and data without having to deal with hardware -dependent and firmware implementation details of secure data transfers with unknown hardware.Small memory footprint can in most cases run in parallel to your own system on your serveror properly secured data transfers from the sensor to the cloud.
  • Low hardware requirements for the server of the Lobaro Platform. Can run in parallel on a server next to the use-case specific platform or even an Raspberry PI for embedded use-cases.
  • Internal APIs between hardware and Lobaro Platform can be changed, e.g. for firmware extensions, without compromising a stable API to the downstream system and thus increasing the stability of the end application.

As one might see, all these functionality require a high level of knowledge about the hardware and how it internally works. Lobaro can only provide support and guarantees that all features of our NB-IoT products are available and function as expected if the Lobaro Platform is also used as a counterpart.

If using the Lobaro IoT platform is absolutely not an option many of our NB-IoT products can also be configured to use LoRaWAN uplinks which shifts the dependence to the used LoRaWAN network server beside the well-known challenges of LoRaWAN networks compared to cellular IoT.