Focus on the MQTT Bridge NGSI-LD context broker

In IoT environments data is characterized is by its heterogeneity due to the variety of used data sources such as satellites, sensors, GPS... and their various format ways of produced data. Integrating and exploiting this kind of data in Context brokers poses several challenges since that they are designed to enable the integration of gathered data for further exploitation in a standardized way. In this context, the MQTT bridge is designed as a connector that enhances IoT device communication using a simple JSON protocol over MQTT brokers and NGSI-LD interface used by Stellio Context Broker.

In a nutshell, the MQTT bridge is designed to subscribe to IoT data published by devices over MQTT brokers, consume, and then produce NGSI-LD event updates, consumed by Stellio context broker.

To ensure the interoperability and genericity of the bridge, it expects data from devices in senML format. SenML is standardized format for representing simple sensor measurements and device parameters in Sensor Measurement Lists. The bridge disposes also of its own mechanism to map and find correspondent CEFACT units (the accepted unit format in NGSI-LD) from senML messages. Examples of senML/CEFACT units mapping are available here.

One of the main issues of the received IoT data is about the ownership of these data. In fact, data comes with provider ids (device ids for example) and following the entity model of NGSI-LD, it is possible that data issued from a device will be stored in the other entity (called context entity).

For these purposes, the process of device provisioning (device registration, device properties definition and defining the correspondent NGSI-LD entity that this device will update) in the MQTT bridge is designed to an automatic process. In fact, the MQTT bridge disposes of his own database in which the bridge will try to find the correspondent entity and property that needs to be updated. The figure below details main components and possible interactions of the MQTT bridge.

Figure 1: Main components of the MQTT bridge

Use-case example: Let’s take the example of a device attached to a Tank. This device will generate values of the Water level in the Tank.

The NGSI-LD model of this use-case consists of 2 entities Tank and Device where the Entity Tank have a property waterLevel, observedBy (as a Relationship) by the Device. The graphical presentation of this model is depicted in the Figure below:

Figure 2: Use-case NGSI-LD data model

The NGSI-LD correspondent Tank entity stored in the context broker is depicted below.

Let’s suppose that the device is publishing data over an MQTT broker is as follows:

The main role of the MQTT bridge is to (i) subscribe to these senML data, (ii) check if the correspondent senML device (field bn) is provisioned in local database and then (iii) Generate updates on the correspondent Tank and its waterLevel property entity with mapping the senML unit (field u) “m” to “MTR” (field unitCode in NGSI-LD) and the timestamp (field bt) to the ISO 8601 format (field observedAt), if the mapping exists in the database.

 In this document, we have tried to show main roles of the MQTT Bridge NGSI-LD context broker via a simple example. Developments of new features such as including automatic device provisioning and supporting NGSI-LD sub-attributes updates are in progress. For more details or new use cases, please do not hesitate to contact us!

From Easy Global Market (EGM)