Investigating Messaging Protocols for the Internet of Things (IoT)

Abstract

As the number of Internet of Things (IoT) devices proliferates, the magnitude and velocity of data continues to increase rapidly. IoT systems rely primarily on using messaging protocols for exchanging IoT data and there exists several protocols or frameworks that support distinct types of messaging patterns. Given that IoT devices typically have limited computational resources and processing power, choosing a lightweight, reliable, scalable, interoperable, extensible and secure messaging protocol becomes a very challenging task. As a result, it is not uncommon that IoT systems may employ multiple messaging protocols for supporting device heterogeneity and different message exchange patterns. In addition, basic similarities among existing several messaging protocols or frameworks that exist today for exchanging IoT data within IoT systems suggest the potential of interoperability. Given that IoT systems help facilitate the interconnectivity among distributed, heterogeneous entities, interoperability among existing messaging protocols will play an increasingly important role in simplifying the development and deployment of IoT systems. In this paper, we present a comprehensive review of the existing messaging protocols that can be used in deploying IoT systems. Throughout this paper, we highlight the protocols' distinctive approaches and applicability of using them across various IoT environments. In addition, we highlight challenges, strengths and weaknesses of these messaging protocols in the context of IoT.

A Software Architecture for the Industrial Internet of Things—A Conceptual Model

“…We focused on middleware systems that are based on the publish-subscribe paradigm because the IIoT system will be much more versatile. There are other important middleware systems that are widely used in the development of IoT systems [ 52 ] such as XMPP (extensible messaging and presence protocol) or CoAP (constrained application protocol) but these middleware systems have not been considered because they are not based on the publish-subscribe paradigm. From the middleware systems that are based on the publish-subscribe paradigm, we suggest the use of DDS for real-time systems is chosen because it was designed specifically for real-time systems.…”

“…From the middleware systems that are based on the publish-subscribe paradigm, we suggest the use of DDS for real-time systems is chosen because it was designed specifically for real-time systems. In order to argue for the selection of the DDS protocol, the study by [ 52 ] can be analyzed, where the HTTP (S), CoAP, MQTT, AMQP, XMPP, and DDS are identified as the main middleware systems based on messages that can be used in the development of the IoT systems. From these middleware systems, MQTT and AMQP use a broker that can be a bottleneck point.…”

“…The DDS is the only one that uses a bus-like architecture (MQTT uses tree architecture and AMQT uses star architecture), has 23 quality of service (QoS) levels (MQTT and AMQP uses 3 QoS levels), is data-centric, and implements a security mechanism like TLS, DTLS, and DDS Security. Also, the data distribution is very versatile with the possibility to achieve 1 to 1, 1 to N, and N to 1 [ 52 ]. By using a standard middleware system, interoperability can be ensured between the IIoT systems and with other systems could take data from the IIoT system.…”

“…Through the resources policies, we can control the computing and network resources. All of these policies are described in the DDS specifications and they are included in the implementations of these specifications [ 51 , 52 , 53 ].…”

LED lighting systems for smart buildings: a review

“…Other emerging technologies framed in IoT infrastructures that are being used for lighting control applications in buildings are SigFox [35, 36], Z ‐wave [29, 37], Wings [38], EnOcean [39], among others. These technologies are implemented in mesh topologies concept and use the 900 MHz RF communication band, allowing wireless sensors and controllers to communicate in smart lighting, heating and climate control, and ancillary building diagnosis and maintenance of smart environment applications [28–30, 35, 37, 38].…”