UNIT-III: IoT Protocols

IoT Protocol Stack

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