IoT Application Layer Protocols

When considering constrained networks and/or a large-scale deployment of

constrained nodes, verbose web-based and data model protocols, may be too
heavy for IoT applications. To address this problem, the IoT industry is working on
new lightweight protocols that are better suited to large numbers of constrained
nodes and networks. Two of the most popular
protocols are CoAP and MQTT. Figure 2.19 highlights their position in a common
IoT protocol stack.

Figure 2.19: Example of a High-Level IoT Protocol Stack for CoAP and MQTT
In Figure 2.19, CoAP and MQTT are naturally at the top of this sample IoT stack,
based on an IEEE 802.15.4 mesh network. While there are a few exceptions, you
will almost always find CoAP deployed over UDP and MQTT running over TCP. The
following sections take a deeper look at CoAP and MQTT.
CoAP
Constrained Application Protocol (CoAP) resulted from the IETF Constrained
RESTful Environments (CoRE) working group’s efforts to develop a generic
framework for resource-oriented applications targeting constrained nodes and
networks. The CoAP framework defines simple and flexible ways to manipulate
sensors and actuators for data or device management.
The CoAP messaging model is primarily designed to facilitate the exchange of
messages over UDP between endpoints, including the secure transport protocol
Datagram Transport Layer Security (DTLS).
From a formatting perspective, a CoAP message is composed of a short fixed-
length Header field (4 bytes), a variable-length but mandatory Token field (0–8
bytes), Options fields if necessary, and the Payload field. Figure 2.20 details the
CoAP message format, which delivers low overhead while decreasing parsing
complexity.
 Figure 2.20: CoAP Message Format
The CoAP message format is relatively simple and flexible. It allows CoAP to
deliver low overhead, which is critical for constrained networks, while also being
easy to parse and process for constrained devices.
Table 2.4 CoAP Message Fields

CoAP can run over IPv4 or IPv6. However, it is recommended that the message fit
within a single IP packet and UDP payload to avoid fragmentation. For IPv6, with
the default MTU size being 1280 bytes and allowing for no fragmentation across
nodes, the maximum CoAP message size could be up to 1152 bytes, including
1024 bytes for the payload. In the
case of IPv4, as IP fragmentation may exist across the network, implementations
should limit themselves to more conservative values and set the IPv4 Don’t
Fragment (DF) bit.
CoAP communications across an IoT infrastructure can take various paths.
Connections can be between devices located on the same or different
constrained networks or between devices and generic Internet or cloud servers,
all operating over IP. Proxy mechanisms are also defined, and RFC 7252 details a
basic HTTP mapping for CoAP. As both HTTP and CoAP are IP-based protocols, the
proxy function can be located practically anywhere in the network, not
necessarily at the border between constrained and non-constrained networks.

Figure 2.21: CoAP Communications in IoT Infrastructures

Just like HTTP, CoAP is based on the REST architecture, but with a “thing” acting
as both the client and the server. Through the exchange of asynchronous
messages, a client requests an action via a method code on a server resource. A
uniform resource identifier (URI) localized on the server identifies this resource.
The server responds with a response code that may include a resource
representation. The CoAP request/response semantics include the methods GET,
POST, PUT, and DELETE.
Message Queuing Telemetry Transport (MQTT)
At the end of the 1990s, engineers from IBM and Arcom (acquired in 2006 by
Eurotech) were looking for a reliable, lightweight, and cost-effective protocol to
monitor and control a large number of sensors and their data from a central
server location, as typically used by the oil and gas industries. Their research
resulted in the development and implementation of the Message Queuing
Telemetry Transport (MQTT) protocol that is now standardized by the
Organization for the Advancement of Structured Information Standards (OASIS).
The selection of a client/server and publish/subscribe framework based on the
TCP/IP architecture, as shown in Figure 2.22
 Figure 2.22: MQTT Publish/Subscribe Framework
An MQTT client can act as a publisher to send data (or resource information) to
an MQTT server acting as an MQTT message broker. In the example illustrated in
Figure 2.22, the MQTT client on the left side is a temperature (Temp) and relative
humidity (RH) sensor that publishes its Temp/RH data. The MQTT server (or
message broker) accepts the network connection along with application
messages, such as Temp/RH data, from the publishers. It also handles the
subscription and unsubscription process and pushes the application data to
MQTT clients acting as subscribers.
The application on the right side of Figure 2.22 is an MQTT client that is a
subscriber to the Temp/RH data being generated by the publisher or sensor on
the left. This model, where subscribers express a desire to receive information
from publishers, is well known. A great example is the collaboration and social
networking application Twitter.
With MQTT, clients can subscribe to all data (using a wildcard character) or
specific data from the information tree of a publisher. In addition, the presence of
a message broker in MQTT decouples the data transmission between clients
acting as publishers and subscribers. In fact, publishers and subscribers do not
even know (or need to know) about each other. A benefit of having this
decoupling is that the MQTT message broker ensures that information can be
buffered and cached in case of network failures. This also means that publishers
and subscribers do not have to be online at the same time. MQTT control packets
run over a TCP transport using port 1883. TCP ensures an ordered, lossless
stream of bytes between the MQTT client and the MQTT server. Optionally, MQTT
can be secured using TLS on port 8883, and WebSocket (defined in RFC 6455)
can also be used.
MQTT is a lightweight protocol because each control packet consists of a 2-byte
fixed header with optional variable header fields and optional payload. You
should note that a control packet can contain a payload up to 256 MB. Figure
2.23 provides an overview of the MQTT message format.
 Figure 2.23 MQTT Message Format
Compared to the CoAP message format, MQTT contains a smaller header of 2
bytes compared to 4 bytes for CoAP. The first MQTT field in the header is
Message Type, which identifies the kind of MQTT packet within a message.
Fourteen different types of control packets are specified in MQTT version 3.1.1.
Each of them has a unique value that is coded into the Message Type field. Note
that values 0 and 15 are reserved. MQTT message types are summarized in Table
2.5.
Table 2.5 MQTT Message Type
The next field in the MQTT header is DUP (Duplication Flag). This flag, when set,
allows the client to notate that the packet has been sent previously, but an
acknowledgement was not received. The QoS header field allows for the
selection of three different QoS levels. The next field is the Retain flag. Only
found in a PUBLISH message, the Retain flag notifies the server to hold onto the
message data. This allows new subscribers to instantly receive the last known
value without having to wait for the next update from the publisher.
The last mandatory field in the MQTT message header is Remaining Length. This
field specifies the number of bytes in the MQTT packet following this field.
MQTT sessions between each client and server consist of four phases: session
establishment, authentication, data exchange, and session termination. Each
client connecting to a server has a unique client ID, which allows the
identification of the MQTT session between both parties. When the server is
delivering an application message to more than one client, each client is treated
independently.
Subscriptions to resources generate SUBSCRIBE/SUBACK control packets, while
unsubscription is performed through the exchange of UNSUBSCRIBE/UNSUBACK
control packets. Graceful termination of a connection is done through a
DISCONNECT control packet, which also offers the capability for a client to
reconnect by re-sending its client ID to resume the operations.
A message broker uses a topic string or topic name to filter messages for its
subscribers. When subscribing to a resource, the subscriber indicates the one or
more topic levels that are used to structure the topic name. The forward slash (/)
in an MQTT topic name is used to separate each level within the topic tree and
provide a hierarchical structure to the topic names.

Comparison of CoAP and MQTT