Application Layer Protocols:

CoAP and MQTT

 108

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 new lightweight protocols that
are
better suited to large numbers constrained nodes
of networks. and
• Two of the most popular protocols
are
• CoAP
• MQTT
 109

IoT Application Layer

Protocols
 110

IoT Application Layer

Protocols
• CoAP and MQTT are at the top of this sample IoT stack,
based on an IEEE 802.15.4 mesh network.
• CoAP deployed over UDP and MQTT running over TCP.
 111

IoT Application Layer

Protocols CoAP
• Constrained Application Protocol (CoAP)
• is 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).
• CoAP over Short Message Service (SMS) as defined in Open Mobile
Alliance for Lightweight Machine-to-Machine (LWM2M) for IoT device
management.
 112

IoT Application Layer

Protocols CoAP
• 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.
 113

IoT Application Layer

Protocols CoAP
 114

IoT Application Layer

Protocols CoAP
• 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.
 115

IoT Application Layer

Protocols CoAP
 116

IoT Application Layer

Protocols CoAP
• 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.
• 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.
• 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.
 117

IoT Application Layer

Protocols MQTT
• Message Queuing Telemetry Transport
(MQTT) :
• Considering the harsh environments in the oil and gas industries, an
extremely simple protocol with only a few options was designed,
with considerations for constrained nodes, unreliable WAN backhaul
communications, and bandwidth constraints with variable latencies.
• These were some of the rationales for the selection of a
client/server and
 publish/subscribe framework based on the TCP/IP architecture,
 118

IoT Application Layer

Protocols MQTT
 119

IoT Application Layer

Protocols MQTT
• 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 Figure 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 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.
 120

IoT Application Layer

Protocols MQTT
• 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.

• Compared to the CoAP message, MQTT

contains a smaller header of 2 bytes compared
to 4 bytes for CoAP.
 121

IoT Application Layer

Protocols MQTT
 122

IoT Application Layer

Protocols MQTT
• MQTT is a lightweight protocol because each control packet
consists of a 2-byte fixed header with optional variable header
fields and optional payload.
• 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.
• Each of them has a unique value that is coded into the Message
Type field.
 123

IoT Application Layer

Protocols MQTT
 124

IoT Application Layer

Protocols MQTT
• 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
 125

IoT Application Layer

Protocols MQTT
• 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.