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.

We present a Communication-Centric IoT Reference Model (CIoT). Although there exists a significant
number of initiatives or standards that attempt to solve IoT challenges across different domains, they
vary considerably in terms of the following factors: (a) architecture, (b) communication, (c) security and
privacy, (d) interoperability, (e) integration, (f) device types and sensor technology, (g) deployment
models (h) services’ provisioning and (i) application and device management. In this paper, we provide a
comprehensive study that investigates the use of existing messaging protocols for IoT application and
identify the challenges associated with their usage across various IoT deployment strategies (e.g. edge-
or fog- versus cloud-based).

SECTION I.

Introduction
Advances in networking technology have profoundly contributed to how IoT devices produce, exchange
and perceive data. This is becoming more evident as the magnitude and rate at which data is generated
by IoT devices is rapidly increasing. This has also contributed to the deployment of a wide array of
messaging protocols that enabled IoT devices to exchange messages more efficiently. Application layer
protocols are considered as the underlying layers used by applications in defining the structure of
message exchanges and how they can be transmitted. In this paper, we primarily focus on the messaging
protocols at the application layer of the Open System Interconnection (OSI) model [8].

There are a number of communication or middleware protocols that are commonly used in the
deployment of IoT applications including HyperText Transfer Protocol (HTTP), Message Queuing
Telemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP), Constrained Application
Protocol (CoAP), Extensible Messaging and Presence Protocol (XMPP), and Data Distribution Service
(DDS), among others. Such protocols support to some extent similar features in terms of connectivity,
however, they vary in the degree to which these features are offered. Given that IoT systems primarily
depend on IoT devices for data collection and message exchanges for the overall functioning of the
system, the choice of which communication or messaging protocol to use for device interconnectivity
becomes a very time consuming and challenging task. Furthermore, when choosing a suitable messaging
protocol, it is imperative to consider the hardware characteristics of IoT devices and type of data link
layer protocols employed.

In addition, IoT devices can vary significantly in terms of the bandwidth they support. That is, IoT devices
do not use a universal radio technology and therefore the physical data rate they support varies
considerably depending on the size and hardware components used to build these devices. For example,
low-rate wireless personal area networks (LR-WPANs) leverage the IEEE 802.15.4 physical layer that
supports data rates up to 250 Kbps with packet length of approximately 127 bytes. Other variations also
exist at other layers of the OSI model such as HTTP.

A common request header size in HTTP, which includes basic attributes such as user-agent, is
approximately 700–800 bytes. However, an uncompressed request header may vary in size ranging from
200 bytes to more than 2KB. Moreover, using application layer protocols that are capable of capturing
data much faster than actual physical data rates often leads to high latency. Therefore, it would be
desirable when developing IoT applications to consider messaging protocols that can accommodate or
support physical data rates at the data link layer.

IoT devices producing data at a high velocity often require lightweight communication protocols. For
example, a small battery-supported IoT temperature device programmed to send localized temperature
readings at a fixed frequency (e.g. every 10 seconds) to an IoT hub (e.g. Microsoft Azure IoT Hub) may
not have sufficient power by the time it transmits a day-long temperature readings using HTTP. It would
be desirable in this case to alternatively use a lightweight messaging protocol such as Message Queuing
Telemetry Transport (MQTT) in which the smallest packet size is 2 bytes (compared to 200 bytes in HTTP
in the uncompressed header size scenario). MQTT is a Machine-to-Machine (M2M)/ Internet of Things
(IoT) connectivity protocol designed as an asynchronous lightweight publish/subscribe messaging
transport protocol [1].

Performance of IoT devices and applications can be significantly influenced by the choice of messaging
protocol used. By employing a suitable messaging protocol helps reduce network traffic and latency and
thus increases an IoT application’s reliability [8]. However, there exists no universal protocol that can be
used across heterogeneous IoT environments. To this extent, choosing an appropriate messaging
protocol depends on a number of factors including IoT application’s business requirements, software
capabilities, device or hardware capabilities, and average size of data exchanges, among many others.
Furthermore, in deploying IoT devices and developing an IoT application, it is imperative to consider the
main characteristics and distinctive features offered by existing protocols. Hence, throughout this study
we focus primarily on present messaging or middleware protocols that are commonly used in deploying
IoT systems.

There are a number of survey research studies that have examined protocols used for IoT connectivity at
the data link layer [120]–[129]. However, the diversity which exists at this layer in terms of protocols’
goals, architecture and capabilities makes it progressively difficult to relate these protocols with those
that interface at the application level. That is, understanding protocols at the data link layer is not
sufficient to build IoT applications. It is essential to also consider protocols that exist at the application
level complementing those that exist at the data link layer.

Understanding data link protocols that indirectly interact with those at application layer through the OSI
model is essential. Because data link layer protocols (e.g. WirelessHART, Sigfox, LoRa, among others)
have different goals and target different types of IoT devices, carefully choosing a protocol closer to the
application layer (e.g. HTTP, CoAP, MQTT, among others) while also considering crucial system
requirements such as Quality of Service (QoS), bandwidth, interoperability and security becomes
inevitable. Although there exists a number of studies that have examined protocols at the data link
layer [120]–[129] and the application layer [2]–[7], [130]–[140], there exists a gap on how these studies
connect protocols across a number of layers of the OSI model. That is, complementing the knowledge
area across multiple layers of the protocol stack for supporting an application’s lifecycle is therefore
needed. This paper attempts to reduce this gap by providing technical details and thorough analysis of
protocols that can be used for developing IoT applications.

This research paper is organized as follows. Section II discusses some of the related work. Section
III discusses existing protocols and the different layers of the OSI model. Section IV presents a detailed
analysis of existing messaging or middleware protocols including HTTP, CoAP, MQTT, AMQP, XMPP and
DDS. Section V provides a comprehensive comparison of the features of existing messaging
protocols. Section VI discusses how messaging protocols address the challenges associated with building
IoT applications. Section VII highlights the strengths and weaknesses of each protocol in the context of
IoT. Finally, Section VIII provides the conclusion and future work suggestions.

SECTION II.

Related Work

Research and investigation in the IoT domain has focused primarily on data accumulation, data analysis
and transformation and collaborative processes implemented in the form of RESTful services. To organize
IoT data flows, a multilevel model of IoT or an IoT reference model is employed consisting of a number
of layers including: (a) physical device and controllers, (b) connectivity, (c) data accumulation and
abstraction (e.g. big data) and (d) application. In this section, we identify key research studies at the
application layer protocol.
In [2], the authors conduct a comparison study into the usefulness of utilizing CoAP and MQTT in smart
healthcare IoT applications. The paper identifies weaknesses of each of these protocols and security
implications in the context of healthcare. Furthermore, the study focuses on the security aspects and
identifying weaknesses in protecting sensitive and private patient data. The authors attempt to classify
the types of threats as Privacy and Confidentiality, Availability and Integrity [2]. In [3], Naik provides a
study surveying some of the existing messaging protocols and identifying their pros and cons [3]. In [7],
Dizdarević et al. provide another survey study of existing application layer protocols while distinguishing
their operability for possible integration into fog- and cloud-based systems [7].

In [4], Thangavel et al. examine the end-to-end performance of MQTT and CoAP using a common
middleware. The study focuses primarily on the usefulness of such protocols in wireless sensor networks
(WSNs). The authors propose a middleware for extending existing and future protocols. Results from this
study show that MQTT messages have lower delay compared to those of CoAP when considering lower
packet loss rates. However, MQTT’s performance degrades compared to that of CoAP when considering
messages at higher data loss rates. The study also identifies that CoAP generates much less traffic
overhead compared to MQTT when message sizes are small and loss rate is equal to or less than twenty-
five percent [4].

Tandale et al. performed a similar study in which they considered CoAP, MQTT and HTTP REST [5]. The
authors used an arm-based device (Raspberry Pi 3) acting as a gateway to examine the reliability and
network traffic of these protocols while considering various network conditions. That is, the study
included two types of networks: (a) cellular 4G and (b) high-speed broadband connection. The authors
conclude that CoAP performs more efficiently for small payloads and its performance deteriorates as the
size of messages increases [5].

In [6], the authors focus in their study on the implementation and comparison of Machine-to-Machine
(M2M) protocols for IoT. The study was centered on the deployment of an IoT system that collects
temperature data while using both the MQTT and CoAP protocols. The study determines that both of
these protocols achieve 100% data transfer with minimal packet loss induced and have relatively efficient
support for re-transmitting data packets. Furthermore, the study finds that CoAP protocol’s data loss rate
is low when handling smaller data sizes. The study concludes that the performance of each protocol is
fairly dependent on various network conditions (e.g. in the case of data retransmission as data size
increases) [6].

Apart from research efforts that investigated the use of messaging protocols at the application layer,
there have been a number of research studies that focused on the network layer protocols. Network
layer protocols enable technologies at that layer to communicate in a unidirectional or bidirectional
capability [119]. For example, network protocols have different identification techniques for locating
devices over different types of networks (i.e. small or large). Such identification can be achieved, for
example, through network addresses using IPv4, IPv6 or 6LoWPAN [120]. Because IoT devices vary in
hardware capabilities (e.g. power consumption, connectivity medium, transmission coverage),
identifying a suitable communication medium that can be used within the boundaries of IoT devices is
challenging [121]–[123]. A number of survey studies examined the various differences amongst existing
network layer protocols in the context of IoT.

In [124], the authors discuss key identification and tracking technologies for IoT devices. For example,
the Radio Frequency Identification (RFID) is a suitable technology that is generally used for tracking and
identification. RFID devices are commonly used in applications such as transportation, logistics,
manufacturing, and equipment tracking, among others [119], [122]. However, IoT systems require smart
devices that go beyond the traditional identification capabilities [124].

In addition, there exists multiple different types of networks that can be employed in IoT systems such as
wireless sensor networks (WSNs). WSNs support longer transmission ranges and, unlike RFID sensor
networks, offer a peer-to-peer communication mode. Because of the need for enhancing the network
identification of IoT devices, improving data transmission rates and supporting mobility, a number of
activities or alliances have evolved in recent years including, but not limited to, Electronic Product Code
(EPC) led by EPCGlobal, Machine-to-Machine (M2M), 6LoWPAN, ZigBee, WirelessHART, NFC, ANT+,
Thread, MiWi, and Weightless, among many others [119]. Many of these activities vary in terms of
communication strategies they support or enable.

The authors in [125] provide a survey of the communication strategies that can be applied for building or
deploying smart IoT applications. In this study, the authors identify four main communication strategies:
(a) device-to-device (D2D), (b) device-to-cloud (D2C), (c) device-to-gateway (D2G) and (d) device-to-
application (D2A). The authors examined the current state-of-the-art for identifying a technical taxonomy
that can potentially cover all possible IoT communication types [124]. However, the study focused
primarily on a broad taxonomy for covering these communication strategies. It would be desirable to
include, in addition to considering this high-level overview of the communication strategies, more
granular technical details that can help identify the scope to which existing messaging protocols map or
support these communication strategies. This research study attempts to reduce this gap by identifying
the level of support provided by existing messaging protocols for each of these communication
strategies.

Furthermore, other studies have limited their scope to focus mainly on a particular applied area of IoT.
For example, the authors in [120] reviewed communication technologies primarily for smart home
systems. The survey study provides a feature comparison of many elements including architecture,
software implementations, privacy and security and communication. The study also discusses the
advantages and disadvantages of applying wired and wireless communication protocols in terms of
frequency, data rates, and network topology, among others. However, the primary focus of the study
in [120] is on short range technologies at the data link layer protocols without connecting them to those
that exist at the application layer.

Although many of the existing research studies have focused on identifying the advantages and
disadvantages of a number of communication protocols, the need for having a research study that
provides detailed comparison with relevant IoT use cases of the existing messaging protocols at the
application layer while considering differentiating factors such as interoperability, scalability and
performance adaptability and extensibility, security and reliability becomes inevitable. In this paper, we
provide a comprehensive study that investigates the use of existing messaging protocols for IoT
application and identify the challenges associated with their usage across various IoT deployment
strategies (e.g. edge- or fog- versus cloud-based). The following section describes a communication-
centric IoT reference model, IoT application requirements and various IoT-related specifications,
standards and alliances that exist today.

SECTION III.
IoT Messaging Protocols

In a traditional IoT cloud architecture, the plurality of data generated by IoT devices relocate to the cloud
for data accumulation (i.e. storage) and abstraction (i.e. aggregation and access). In contrast, an IoT
edge-based architecture reduces the amount of data in which only partial data relocates to the cloud for
further storage and processing.

In the edge-based model, network and system architectures are generally responsible for not only
collecting data at the edge of the network but also performing advanced functions such as data analysis
and processing. That is, the data accumulation and abstraction partially shift from the cloud to the edge
of the network which significantly contributes to reduction in network traffic as the number of IoT
devices increases. Therefore, it is imperative when choosing a deployment architecture to identify a
suitable messaging protocol. To this extent, in the following section, we discuss a communication-centric
IoT reference model for the purpose of distinguishing the various protocols and specifications that exist
across the various IoT layers.

A. The IoT Reference Model

Despite the differences between IoT deployment approaches, producing data which occurs at various
rates is achieved by the physical layer to which IoT devices connect to a network (i.e. wired or wireless).
Given that IoT devices at this layer may have limited power, the rate at which data generates requires
special consideration to the amount of power consumed by these devices. That is, reducing the velocity
or the rate at which data generates on the edge of the network translates into longer battery life of IoT
devices while reducing bandwidth.

A plethora of standards, specifications and technologies at this layer exist including Ethernet 802.3, Wi-Fi
802.11 a/b/g/n, Low Power Wide Area Network (LWPAN), Long Range Radio (e.g. LoRa, Sigfox,
Narrowband IoT – NB-IoT), Zigbee, Cellular (2G, 3G, 4G, LTE, 5G), 802.15.4, among many others. Figure
1 presents a Communication-centric Internet of Things (CIoT) reference model.
FIGURE 1.

A communication-centric IoT reference model (CIoT).

In the following sections, we describe the main functionality supported by the layers presented in Figure
1 and briefly discuss the relevant protocols, specifications or standards that exist at each layer.

B. Physical and Data Link Layers

At the lowest level of the IoT reference model presented in Figure 1 is the physical layer which contains
the electronic circuitry for transmissions. The data link layer is responsible for data transfers between
network entities. There are a large number of technologies that exist at the data link layer each of which
has been designed to target specific applications or connectivity strategy. For example, Z-Wave enables
IoT devices to be controlled via the Internet and is very common among smart home systems.

On the other hand, the Weightless technology uses a set of Low-Power Wide-Area Network (LPWAN)
standards for data exchanges primarily between a base station and thousands of IoT nodes. There are
three types of Weightless protocols including: (a) Weightless-N, Weightless-W and Weightless-P. Each of
these Weightless protocols is designed for specific use cases. Weightless-W, for example, operates in the
TV White Space (TVWS) spectrum and takes advantage of the ultra-high frequency (UHF). Weightless-N
uses an ultra-narrowband which is ideal for sensor-based networks and metering systems, among
others. Weightless-P offers bi-directional support and operates in both licensed and unlicensed ISM radio
bands. Common applications using Weightless-P include industrial machine monitoring and health
equipment monitoring, among others.

Sigfox is another data link layer technology which offers subscription-based connectivity services over a
dedicated LPWAN networks and can be used in smart alarm systems and metering systems, among
others. LoRaWAN provides a low-cost and secure bi-directional long-range transmissions supporting very
large networks that consist of hundreds, thousands or millions of nodes. Ideal applications of LoRaWAN
include smart cities, smart street lighting and smart waste management, among many others.

ZigBee, a technology developed by the ZigBee Alliance, is based on the IEEE 802.15.4 standard and
operates in unlicensed radio bands while it supports a number of topologies including the star, cluster
tree and mesh topologies. ZigBee can support up to 65,000 nodes over a network and has low data
rates. Table 1 provides a feature comparison for a subset of the existing data link layer technologies
sorted by the transmission range in an ascending order.

TABLE 1 Some of the Data Link Layer Protocols Comparison

C. Network and Transport Layers

Above the data link layer as can be seen in Figure 1 is the network layer. This layer is responsible for the
logical addressing and delivery of packets between source and destination, which generally requires
routing. Hence, a lightweight routing process is essential for IoT devices particularly constrained devices
while maintaining a high level of scalability. Because some IoT devices may operate using low-power
radio communication, IPv6 Low Power Wireless Personal Area Network (6LoWPAN) provides an optimal
method for transmitting IPv6 packets for low-power or constrained devices.

The transport layer is mainly responsible for the end-to-end communication via a network and provides
many services such as data-stream support, reliability, multiplexing and security, among others. For
connection-oriented transmissions, Transmission Control Protocol (TCP) is used for messaging
transmissions. Although TCP is considered one of the most widely used protocols over the Internet, TCP
may not be ideal for all types of IoT systems. An IoT system that uses a large number of constrained
devices disseminated across multiple geographical areas may benefit significantly from using a
connectionless service protocol such as User Datagram Protocol (UDP) for messaging transmissions
versus TCP.

D. Application Layer

The application layer is an abstraction layer that identifies a variety of protocols and interfacing
methods [8]. There exists several application layer protocols that address a wide range of application
requirements. Each of these protocols provide various features that vary in terms of reliability, quality of
service, performance, functionality and scalability, among other factors.

Some of the protocols that exist at the application layer include: (a) HyperText Transfer Protocol (HTTP),
(b) Secure HTTP (HTTPS), (c) Message Queueing Telemetry Transport (MQTT), (d) Advanced Message
Queuing Protocol (AMQP), (e) Extensible Messaging and Presence Protocol (XMPP) and (f) Constrained
Application Protocol (CoAP), among many others. In addition, a number of industry-specific protocols
used primarily in IoT environments (mainly industrial) also exist such as Modbus, Distributed Network
Protocol (DNP3), OLE for Process Control (OPC), Manufacturing Message Specification (MMS), among
many others. A software developer, system designer or network administrator needs to consider not
only an application protocol but also relevant protocols employed at other layers in the OSI model by an
IoT system. In Section IV, we discuss in details each of the IoT messaging protocols that exist at the
application layer.

E. IoT Application Range Requirements

Because of the diversity of IoT devices, there exists no single communication technology that is capable
of supporting heterogeneous environments. To have a more thorough understanding of the transmission
requirement ranges for the various IoT application domains, we present in Table 2 a list of some of the
common IoT application domains with corresponding ranges based on data we collected from existing
research work [2]–[7], [120]–[123], [130]–[140].

TABLE 2 IoT Application Range Requirements [120]–[123], [130]–[140]

F. Specifications, Standards and Alliances

Over the past few years, there have been a significant increase in the number of standards’ governing
bodies and alliances that have been formed for enhancing communication technologies for the IoT
landscape. Identifying the scope and goals of these initiatives is beyond the scope of this paper.
However, we would like to provide the reader an overview of some of these initiatives that we believe
would be relevant to this study. In Figure 2, we present a subset of the organizations and alliances that
have been playing an increasingly important role in solving challenges that exist in the IoT paradigm in
recent years.
FIGURE 2.

Standards governing bodies and alliances in the IoT Landscape.

The initiatives, specifications and standards presented by the various organizations and alliances shown
in Figure 2 have different focuses and target specific stakeholders or markets. For example, some of
these initiatives offer solutions that aim to solve challenges for Business to Consumer (B2C) or Business
to Business (B2B) applications. Other initiatives were developed to accommodate specific vertical or
horizontal domains in the IoT landscape. Consider, for example, organizations or alliances such as the
IEEE, ZigBee Alliance, ISO, CEN and ULE. All of these organizations or alliances have proposed standards
or specifications for a vertical domain which primarily focus on solving a very specific area such as home
and building automation.

Other organizations such as the IEC, ISO, oneM2M, OPC and OpenIndustry 4.0 Alliance provide
specifications or recommendations that are domain-specific or solve problems within the manufacturing
and industrial automation vertical domain. Furthermore, organizations such as the W3C, ITU, OASIS,
OMG, IETF and HyperCat [163] provide standards, specifications and recommendations that provide
broader support for a number of IoT applications while encompassing many different domains (e.g.
industrial, home automation, healthcare, energy, oil and gas, among many others.

G. Choosing Messaging Protocols

Although there exists a significant number of initiatives or standards that attempt to solve IoT challenges
across different domains, they vary considerably in terms of the following factors: (a) architecture, (b)
communication, (c) security and privacy, (d) interoperability, (e) integration, (f) device types and sensor
technology, (g) deployment models (h) services’ provisioning and (i) application and device
management. Some of these features are also supported by a number of protocols that exist across the
link and application layers. Examining similarities and differences among existing data link layer’s
specifications, standards or initiatives is beyond the scope of this paper. However, due to the fact that
exchanging data through messages is fundamental for the development and deployment of IoT
applications, we focus primarily in this paper on investigating messaging protocols that support IoT data
exchange.

As a first step into identifying the protocols to be part of this research paper, we conducted a review of
the existing research studies that have examined protocols for IoT applications [7], [118], [121]–[138]. As
part of our selection strategy, we also considered the following factors:

 What are the system requirements and challenges that may influence choosing an application
protocol for IoT development?

 What is the extent of the coverage of these challenges in existing literature?

 Which communication types are covered by existing application layer protocols?

 What factors were used or applied in conducting prior research studies?

 What is the depth of the examined literature in terms of coverage, comprehensibility and
technical knowledge?

 What is the adoption rate of the existing protocols used for IoT applications?

For considering the communication scope, we reviewed the current state-of-art literature to identify the
IoT communication types based on environments running IoT applications. The authors
in [124] identified four classical communication types for IoT environments. We summarize these
communication types below.

 Device-to-Device (D2D) where communication is provided between two nodes or devices

directly.

 Device-to-Application (D2A) where communication is performed between devices and an IoT

application.

 Device-to-Gateway (D2G) where communication is provided through a gateway that resides in

close proximity to the edge of the network while interacting with IoT devices.

 Device-to-Cloud (D2C) where communication is achieved directly between IoT devices and cloud
service providers.

We use these communication types to identify existing application layer protocols that provide support
for D2D, D2A, D2G and D2C. Not all protocols support all of the identified communication types. For
example, MQTT functions in the communication type D2C whereas CoAP only supports D2D. In addition,
supporting the communication scope depends on a number of factors such as device capabilities. For an
IoT device to send data streams to an IoT cloud platform directly (e.g. Azure IoT Hub), the device must be
equipped with networking technology (e.g. WiFi or Ethernet) to send data to the cloud. However, if the
device does not support direct connectivity to the cloud (e.g. an RFID tag), performing a D2C
communication is not possible. Hence, a gateway may be used to collect data streams from the IoT
device and then forward the stream to the cloud. As part of our comprehensive analysis and review of
IoT application protocols, we take into consideration these variations and compare these protocols
based on the scope of the communication type they support.
In addition, we considered published literature for identifying the adoption rate of the plurality of
messaging protocols that exist today. To this extent, we reviewed existing surveys conducted across the
IoT developers’ community. We make use of the results from surveys conducted by the Eclipse
Foundation between 2015 and 2019 that received significant feedback from the IoT developers’
community [155]. We collected statistical data about the adoption rate published by Eclipse Foundation
through these surveys and used it to identify protocols that we should consider as part of our study.

Combining the data we collected from our literature review and the results of the surveys published by
the Eclipse Foundation, we identify the following messaging protocols as part of our comprehensive
review: (a) HTTP(S), (b) CoAP, (c) MQTT, (d) AMQP, (e) XMPP and (f) DDS. We believe that by thoroughly
investigating these protocols while having general understanding of the existing data link layer protocols,
it is then possible to determine how each of these protocols can address system requirements or
challenges that exist across the IoT communication landscape while also identifying suitable IoT cloud
service providers for deploying crucial IoT services.

H. Support for IoT Messaging Protocols on the Cloud

Apart from examining adoption rates for IoT messaging protocols, it would be desirable to identify any
patterns or trends for protocols that are supported by existing IoT cloud platforms. To this extent, we
conducted a literature review examining support levels of messaging protocols across the plurality of
existing IoT cloud platforms [166]–[175]. Table 3 presents a detailed list of supported protocols that we
gathered for ten of the major players or the plurality of IoT cloud platforms that exist today.

TABLE 3 List of Protocols/Technologies Supported by Existing IoT Platform Providers for Data
Transmission
As can be seen in Table 3, all of the IoT cloud platforms support
HTTP(S) and MQTT across all ten cloud platforms, followed by
AMQP supported by six platforms, then CoAP supported by four IoT
platforms. These results align with those of the Eclipse Foundation
survey noting that HTTP and MQTT constituted the top two
messaging protocols used by developers according to the survey
results [155]. We discuss the results of the survey in Section VI.I.
Unfortunately, none of the existing IoT cloud platforms provide
support for DDS although it is being used by IoT developers based
on the results gathered from the survey conducted by the Eclipse
Foundation (Section VI.I).

We summarize the distribution of the support by cloud platform

providers in Figure 3. Figure 4 presents a comparison of the
messaging protocol support across cloud platforms examined
in Table 3. As can be seen in Figure 4, Oracle IoT and Siemens
MindSphere provide support for all of the five protocols, followed
by Eclipse Hono.

FIGURE 3.

A. IoT platform support distribution.

FIGURE 4.

B. Comparison of messaging protocol support by IoT platforms.

C. In addition to supporting IoT messaging protocols, some IoT service

providers also provide support for proprietary protocols or protocols that are
specific at the IoT device level. For example, Siemens’ MindSphere supports
Modbus, Lightweight M2M (LwM2M), LoRaWAN and OPC UA technologies
which are commonly used in industrial automation, manufacturing or home
automation. Although Alibaba IoT provides support for two of the protocols
that we are investigating, it also supports IoT device mobility through
dedicated transmission channels on its IoT platform providing support for a
number of cellular network types including 2G, 3G, 4G and NB-IoT.
D. Apart from the complexities in choosing an appropriate messaging protocol
for IoT applications, results from Figures 3 and 4 show that considering the
IoT deployment platform is also important. In cases where an IoT application
has high levels of heterogeneity, choosing an IoT platform that supports
diverse IoT messaging protocols would be a good choice. However, there are
also other factors that may influence the choice of IoT cloud platforms such
as cost, bandwidth, reliability, security, service provisioning, interoperability,
resiliency and composability, among others.
E. In addition, the degree of the services offered by existing IoT cloud service
providers varies depending on the technologies used or applied. For example,
 IBM offers hosting services for its SoftLayer data centers [141] which support
a large magnitude of data streams (i.e. in billions) from connected IoT
devices. Deploying an IoT application on GCP, for example, can take
advantage of Google’s fiber optics network [142] which can significantly
support low-latency IoT application deployments. Microsoft Azure offers a
number of services through the Azure Suite running applications such as
Salesforce, SAP, Oracle database and Microsoft Dynamics. AWS enables
messages to be routed to AWS endpoints through the Rules Engine to AWS’s
Lambda, Kinesis, machine learning and Elasticsearch service, among many
others. In the following sections, we describe the various messaging protocols
that exist at the application layer that can be used for developing and
deploying IoT applications.
F. SECTION IV.
G. Messaging Protocols for the Internet of Things
H. In this section, we primarily focus on the application layer protocols that
support the data link layer protocols discussed in Section III. We applied a
selection strategy based on the adoption rates of the application layer
messaging protocols from a survey conducted by the Eclipse
Foundation [155] as discussed in Section III.G. In addition, we considered the
support level of messaging protocols by existing IoT cloud platforms as
discussed in Section III.H.
I. A. Hypertext Transfer Protocol (HTTP)
J. HTTP is an application-level, generic, stateless protocol [9] that is used
generally for data communication over the World Wide Web. One of the key
features of HTTP is content negotiation of data representation. This enables
different heterogeneous devices built independently of the data to be
shared [8]. HTTP is a request-response protocol in which a client (e.g. a
browser) sends a request message and a host (e.g. a server) generates a
response message. HTTP version 3.0 or H3 is the latest (draft) version of
HTTP introduced in 2018 [10]. However, the common HTTP version used
today is HTTP 1.1. Figure 5.0 presents variations among HTTP versions 1.0,
1.1 and 2.0. In this paper, we focus primarily on the common HTTP version
used in IoT applications or HTTP 1.1.
K. FIGURE 5.
L. HTTP message control flow (left: HTTP 1.0, middle: HTTP 1.1, right: HTTP
2.0.
FIGURE 5.

M. HTTP message control flow (left: HTTP 1.0, middle: HTTP 1.1, right: HTTP 2.0.

B. Constrained Application Protocol (CoAP)

Constrained Application Protocol (CoAP) is a web transfer protocol
that is intended for devices running on constrained (e.g., low-
power, lossy) networks [11]. Constrained devices generally have 8-
bit microcontrollers with small amounts of memory. The CoAP
standard was designed for Machine-to-Machine (M2M) applications
(e.g. factory automation, smart energy). Similar to HTTP, CoAP is a
request-response interaction model and uses major concepts from
the web such as Uniform Resource Identifiers (URIs) and Internet
media types [11]. CoAP aims to bridge HTTP and RESTful services
through simple interfacing. This protocol is used over the UDP
transport protocol using the coap scheme and over DTLS using
the coaps scheme [11]. An abstract layer of a DTLS-Secured CoAP
is shown in Figure 6.
FIGURE 6.

N. Layers of DTLS-Secured CoAP [11].

A request URI can be split into multiple parts: (a) Uri-Host, (b) Uri-Port, (c) Uri-Path and Uri-Query
Options. These features provide easy and intuitive way to communicate using this protocol with RESTful
services. CoAP supports CRUD operations through HTTP methods as shown in Table 4 and provides
status codes that are very similar to those in HTTP.

TABLE 4 CoAP Methods

CoAP also provides support for discovering services and resources. In addition, when a message is
published in a URI, notifications are sent to clients who can access the resource. An example of a CoAP
message format is shown in Figure 7. The version specifies the CoAP version number and the type
indicates the type of message. CoAP uses a simple binary-base header format and the smallest size is 4
bytes.

FIGURE 7.

O. CoAP message structure.

Table 5 outlines the four different message types that CoAP support. The message types provide a
certain guarantee to the delivery of messages and hence increases the level of quality overall. For
example, when a server processes a response identified by a given code (in the code field) matching the
request, an 8-bit response code identifies the class of the response: (2) success, (4) client error and (5)
server error.

TABLE 5 CoAP Message Types

A confirmable message (CON) represents reliable message delivery since this type of message is
retransmitted one or more times until the server ultimately receives the message. The ACK message will
contain the same message id of the confirmable message (CON). An example of a confirmable message
with an acknowledge response message is shown in Figure 8.

FIGURE 8.

P. CoAP message control flow.

Q. Through the message types and HTTP-like status codes, CoAP becomes an
easy to use protocol for integrating into the existing web. IoTivity, an open
source software framework that enables device-to-device communication,
uses CoAP as its application layer [18]. In addition, CoAP offers extensions
such as the Observe Option which helps in observing the changes in the state
of resources giving it a RESTful architecture support.
R. C. Message Queuing Telemetry Transport (MQTT)
S. Although HTTP and CoAP can be used as a request/response protocols used
by IoT systems or devices, there is a need for a lightweight protocol that is
designed to handle situations in cases of unreliable networks or intermittent
connectivity. MQTT, an OASIS standard, is a publish-subscribe lightweight
messaging protocol designed for constrained devices [12] and is well-suited
for these types of scenarios while enabling the exchange of data with the cloud
in a real-time manner.
T. As outlined in Table 3, nearly all of the existing IoT cloud platform providers
including IBM Watson IoT Platform [13], Microsoft Azure IoT Hub [14],
Google Cloud IoT Core [15], Bosch IoT Hub [16] and AWS IoT [17], among
many others provide support for an IoT application to send data using the
MQTT protocol. MQTT, an application layer protocol designed for Machine-
to-Machine (M2M) communication, uses a publish-subscribe model and runs
on top of the Transmission Control Protocol/Internet Protocol (TCP/IP) as
shown in Figure 9.