IoT Broker

What it is

The IoT Broker Generic Enabler is specified as a lightweight and scalable middleware component that separates IoT applications from the underlying device installations. The IoT Broker implementation available through the FIWARE Catalogue is the reference implementation of this Generic Enabler by NEC. This implementation satisfies all properties described in the specification of the Generic Enabler. The IoT Broker has unique properties that you will not find in other IoT Platforms:

The IoT Broker Generic Enabler is based on the simple and powerful information model standardized in OMA Next Generation Service Interface Context Enabler (NGSI 9 / NGSI 10). This API has emerged in FIWARE as an important open standard of information exchange, implemented by a considerable number of FIWARE GEs. In NGSI 9/10, all objects of the real world, being it sensor/actuator devices or arbitrary objects (like tables, rooms, cars, ...) are represented as so-called Context Entities, while information about these objects is expressed in the form of attributes. For more information about the OMA NGSI 9/10 information model and the related interfaces, please refer to the Open API Specification.

Why get it

Offering a single point of contact to the user, hiding the complexity of the multi-provider nature of the Internet of Things.

Collecting and aggregating information about thousands of real-world objects on behalf of the user.

Provide means to assemble lower-level device information (device-centric access) into higher-level Thing information (information-centric access).

Avaliable for:


Functionality outline


The IoT Broker GE is the point of contact for accessing information about things and their attributes (see data model above). Applications can access this information using the NGSI 10 interface of the IoT Broker. In the overall FI-WARE reference architecture [7], the Context Broker GE from the Data & Context Chapter enables up-to-date access to Context Information (not only things) by any application. Such Context Information can be of any nature and comprises, but is not limited to, the Context Information about things that is made available by the IoT Broker GE. However, the IoT Broker GE can as well be accessed by any number of applications directly via its NGSI 10 interface. This enables a simpler setup when applications only use IoT information.

The NGSI context management interface describes three types of operations for exchanging context information. The first and most basic kind of operation is a simple query. When an application invokes the query, it expects to receive context information as the response. The second kind of operation is a subscription. When an application subscribes to certain context information, it just receives a subscription ID as the response. Context information is then sent to the application in the form of notifications. Finally, there is a mode of information exchange defined in the NGSI context interface where information updates are sent without the need to ask for them. When the IoT Broker receives such updates, it forwards the information to some default application that is responsible for further processing and/or storing such updates. In the FI-WARE reference architecture this application is the Context Broker GE.

For basic usage the IoT Broker is a stateless component in the sense that it neither stores context information (i.e. attribute values) nor context availability information. Instead, it interacts with the whole IoT deployment in order to satisfy the requests it receives from the Context Broker GE or final applications: When receiving a query on Context Information, e.g. attributes of Context entities, the IoT Broker GE first contacts the IoT Discovery GE to perform a discovery. Using the resulting availability information, the IoT Broker then contacts the information providers (depicted as IoT Agent in the figure) using NGSI 10 to receive the actual attribute values. Note that the number of information providers to be contacted can be arbitrary. The information is then aggregated and returned to the application. For subscription it is applied a similar approach but with a concept of asynchronous query: once the IoT Broker receives a context subscription request, the IoT Broker subscribe for context availability to the IoT Discovery GE; when a notification of availability of context matching the context subscription is issued to the IoT Broker (caused by a context registration to the IoT Discovery GE by a context provider), the latter initialize a context subscription to the context provider and links it to the original context subscription; when the IoT broker receives a context notification this will be forwarded to the subscriber. For the subscription scenario the IoT Broker is stateful since it needs to keep track of existing subscriptions using the Subscription Storage. This includes both subscriptions received from applications and subscription issued to IoT Agents (e.g. Gateway Data Handling GE) by the IoT Broker

In case of advanced usage IoT Broker keeps also context states as represented in the architecture picture. Firstly, the IoT Broker includes a repository of context registrations (aka ConfMan) that is information about where certain context information can be retrieved. The latter is a new feature since version 4.2, and its purpose is to enable usage of the IoT Broker without an external IoT Discovery GE for simple scenarios.

Secondly, the IoT Broker is able to process context information passing through it and indexing it before to persistently storing in a Key-Value Store (CouchDB). This functionality is available since version 5.2.

Finally, the IoT Broker is capable to query a Knowledge Base Server which can add semantic behavior to IoT query/subscription. For instance when a context of a certain type is requested, also all the sub-types will be taken into consideration in the response.

In the above picture, all the mentioned component are depicted. It is worth to note in the architecture picture the difference between rounded and squared boxes: the firsts are modules which can be enabled only together with an IoT Broker instance, the lasts are standalone components and works as autonomous servers. For this reason it is possible the IoT Broker can be scaled by replicating the IoT Broker core instance, see figure below. All the basic IoT Broker functionalities load can be distributed among several instances.


FIWARE Webpage

IoT Broker


IoT Broker Documentation


IoT Broker Download

Fiware Academy

IoT Broker Courses


Click on the images to enlarge them.