Abstract

The Internet of Things (IoT) is becoming pervasive and with each new installation of IoT platforms new and legacy brokers have to be exploited. New internal brokers are those under the control of the platform, while legacy external brokers are those in place managed by third parties. The solution proposed addressed problems of (a) interoperability to reduce set up time to cope with unknown data structures (devices, entities) distributed via brokers; (b) performance by dimensioning both front-end and back-end processes to reach high rates in a broker-based platform, while preserving full capability features of the data warehouse. Interoperability aspects have been addressed by introducing our concepts and a reasoner into an IoT Directory tool to manage Internal and External brokers, automate device discovery and registration from both standard and customized data models. Despite the managed complexity, a broker-based solution turned out to provide high performance. To this end, a specific assessment and architecture tuning have been performed and reported in the paper to give evidence and validation. The proposed integrated IoT Directory has been developed in the context of the Herit-Data Project, and it is currently used in the whole Snap4City network of 18 tenants and billions of data. Snap4City is an open-source IoT platform for Smart Cities and Industry 4.0, which is an official FIWARE platform and solution, EOSC service and libs of Node-RED.

Introduction

The Internet of Things (IoT) defined a paradigm for the computation and communication amongst things, which is becoming every day more and more pervasive and adopted in many different domains [1,2]. It is partially due to the worldwide intense deployment campaign about Low-Power Wide Area Network technologies [3], as well as to many approaches and protocols for communications amongst devices (e.g., Message Queue Telemetry Transport or MQTT, Next Generation Service Interfaces or NGSI, Advanced Message Queuing Protocol or AMQP, Constrained Application Protocol or COAP). The approach is also covering the cloud and fog infrastructures [4,5]. Thus, IoT network infrastructures are becoming every day more complex to be managed due to the networks’ structure and existence of several protocols, formats, and concepts [1,6]. Hence, the complexity is growing in terms of data management, not only for huge amount of data but also for interoperability and abstraction levels needed to data managing. Relevant aspects to be considered are security and privacy [7] on specific data models and entities. To increase the complexity, there is a range of different owners and managers who may control different parts of such IoT networks [8].

In this context, the concept of Gateway is relevant for any segments of IoT networks connecting, as well as for the Web of Things, WoT [9]. Gateways may be integrated with one or more Brokers to send/receive data to/from Devices/entities. The Gateways and Brokers are typically compliant with a single protocol and may be managed by third parties with respect to data management platform. In some cases, they are provided as public services for several interested customers in the same area (for example: Proximus for LoraWAN services [10]). A Gateway may abstract from the IoT Broker level managing multiple brokers for multiple organizations/tenants (which can be regarded as customers of Gateway services to manage several Devices), via some API and/or Web user interface. Typical IoT Brokers can only manage one organization, and thus are single tenant, meaning they broker messages using topic/entity concepts (which can be regarded as the key for subscription on that specific device/entity) without any internal partition of services, but as a sort of family of devices and subscriptions. Some IoT Brokers can be multi-tenant, such as the FIWARE Orion Broker [11,12], which provides support for partitioning the served devices/entities/topics in groups, and each of them may have a dedicated service/path for a specific scope (or a specific customer). Furthermore, devices of different tenants could exist physically in different places (even having identical identifiers, IDs), and the subscription to the broker’s tenant may imply receiving all messages/services in the partition in push. That is feasible only if the subscriber knows the service/path identifier and, in the event of access control, the subscriber has the grant to access the broker’s services. Different IoT Devices connected to the same broker adopt the same protocol, may use different data structures/models and have the same semantic information.

Conclusions

The proliferation of IoT devices, brokers, networks, data models, operators and tenants, makes the harmonization and management of IoT Platform a hard goal. This paper offers an analysis and a comparison amongst relevant existing platforms, and it points out the basic requirements to achieve such aims. These identified requirements are in most cases not addressed by main platforms which prefer to stay on their own end-to-end solutions with limited interoperability and capacity of exploiting legacy IoT networks in place, in terms of performance. The proposed solution addressed problems of (a) interoperability by reducing set up time to efficiently detect and learn how to process unknown data structures (devices, entities) distributed via brokers; (b) performance by dimensioning the front-end and back-end processes to reach high rates in a broker-based platform, while preserving full capabilities features of data warehouse.

As to interoperability, the main identified and solved problems are those related to a large variety of Data Models coming from non-controllable External Brokers. The issue has been solved by designing and implementing a harvester and reasoner that is capable to automatically recognize/understand and map the new data models/types into those already known by Knowledge Base. This approach, together with the definition of a comprehensive meta model and dictionary, has allowed to speed up the process more than 800 times. The harvesting and comprehension process can be periodically performed to keep the platform updated with any newly defined data models by third party brokers. Furthermore, the process is helped by Km4City ontology and Data Dictionary to recognize the new data types and models according to the semantic domain.