MQTT, AMPQ, CoAP

Reference and further reading:

1. Ala Al-Fuqaha, Mohsen Guizani, Mehdi Mohammadi, Mohammed Aledhari, and

Moussa Ayyash, “Internet of Things: A Survey on Enabling Technologies, Protocols,
and Applications”, IEEE COMMUNICATION SURVEYS & TUTORIALS, VOL. 17, NO. 4,
FOURTH QUARTER 2015

2. RFC 7252 - The Constrained Application Protocol (CoAP)

MQTT is an OASIS standard messaging protocol for the Internet of Things (IoT).

(https://mqtt.org/)

Machine to machine internet of things connectivity protocol.

Lightweight and publish-subscribe messaging transport protocol.

It is ideal for connecting remote devices with a small code footprint

and minimal network bandwidth

OASIS (Organization for the Advancement of Structured Information

Standards) is an international non-profit consortium that promotes
open, collaborative development of e-business specifications
The MQTT protocol was introduced
in 1999 by Andy Stanford-Clark
(IBM) and Arlen Nipper (Arcom,
now Cirrus Link). They needed a
protocol for minimal battery loss
and minimal bandwidth to connect
with oil pipelines via satellite.
Over the next ten years, IBM
used the protocol internally
until they released MQTT 3.1
as a royalty-free version in
2010. Since then, everyone
is welcome to implement
and use the protocol.
On October 29, 2014, MQTT
became an officially approved
OASIS Standard.
In March 2019, OASIS ratified the
new MQTT 5 specification.
Introduced new features to MQTT
that are required for IoT applications
deployed on cloud platforms
Publisher -Subscriber

Enable an application to announce events to multiple interested consumers asynchronously,

without coupling the senders to the receivers.

Also called: Pub/sub messaging

In cloud-based and distributed applications, components of the system often need to provide
information to other components as events happen.

Asynchronous messaging is an effective way to decouple senders from consumers, and avoid
blocking the sender to wait for a response.

Using a dedicated message queue for each consumer does not effectively scale to many consumers

Some of the consumers might be interested in only a subset of the information.

How can the sender announce events to all interested consumers without knowing their identities?
Introduction of an asynchronous messaging subsystem that includes the following:

An input messaging channel used by the sender.

The sender packages events into messages, using a known message format, and sends these
messages via the input channel.

The sender in this model is also called the publisher.

One output messaging channel per consumer. The consumers are known as subscribers.

A mechanism for copying each message from the input channel to the output channels for all
subscribers interested in that message. This operation is typically handled by an intermediary such as
a message broker
MQTT is a messaging protocol that was introduced by Andy Stanford-Clark of IBM and Arlen
Nipper of Arcom (now Eurotech) in 1999 and was standardized in 2013 at OASIS

MQTT aims at connecting embedded devices and networks with applications and middleware.

The connection operation uses a routing mechanism (one-to-one, one-to-many, many-to-many) and
enables MQTT as an optimal connection protocol for the IoT and M2M.

MQTT utilizes the publish/subscribe pattern to provide transition flexibility and simplicity of
implementation

MQTT is suitable for resource constrained devices that use unreliable or low bandwidth links.

MQTT is built on top of the TCP protocol. It delivers messages through three levels of QoS.
Major specifications for MQTT: MQTT v3.1 and MQTT-SN (formerly known as MQTT-S) V1.2.

The latter was defined specifically for sensor networks and defines a UDP mapping of MQTT and adds broker
support for indexing topic names.

The specifications provide three elements: connection semantics, routing, and endpoint.

MQTT simply consists of three components, subscriber, publisher, and broker.

An interested device would register as a subscriber for specific topics in order for it to be informed by the
broker when publishers publish topics of interest.

The publisher acts as a generator of interesting data. After that, the publisher transmits the information to the
interested entities (subscribers) through the broker.

Furthermore, the broker achieves security by checking authorization of the publishers and the subscribers
A number of applications utilize the MQTT such as health care, monitoring, energy meter, and Facebook
notification.

The MQTT protocol represents an ideal messaging protocol for the IoT and M2M communications and is
able to provide routing for small, cheap, low power and low memory devices in vulnerable and low
bandwidth networks
 The architecture of MQTT.

Publish/subscribe process utilized by MQTT

 MQTT message format.

The first two bytes of message are fixed header. In this format, the value of the Message Type field indicates
a variety of messages including CONNECT (1), CONNACK (2), PUBLISH (3), SUBSCRIBE (8) and so on.
The DUP flag indicates that the massage is duplicated and that the receiver may have received it before.
Three levels of QoS for delivery assurance of Publish messages are identified by the QoS Level field.
The Retain field informs the server to retain the last received Publish message and submit it to new
subscribers as a first message.
The Remaining Length field shows the remaining length of the message i.e., the length of the optional parts.
Example
Mosquitto is an open source (EPL/EDL licensed) message broker that
implements the MQTT protocol versions 5.0, 3.1.1 and 3.1.

Mosquitto is lightweight and is suitable for use on all devices from low
power single board computers to full servers.

The MQTT protocol provides a lightweight method of carrying out

messaging using a publish/subscribe model.

This makes it suitable for Internet of Things messaging such as with low
power sensors or mobile devices such as phones, embedded computers or
microcontrollers.
(Mosquitto is part of the Eclipse Foundation, and is an iot.eclipse.org project. The
development is driven by Cedalo)
https://mosquitto.org/download/
The Eclipse Paho project provides open source, mainly client side,
implementations of MQTT and MQTT-SN in a variety of programming languages
Advanced Message Queuing Protocol (AMQP): AMQP is an open standard application
layer protocol for the IoT focusing on message-oriented environments.

It supports reliable communication via message delivery guarantee primitives

including at-most-once, at-least-once and exactly once delivery.

AMQP requires a reliable transport protocol like TCP to exchange messages.

Publish/subscribe
mechanism of AMQP
Communications are handled by two main components: exchanges and message
queues.

Exchanges are used to route the messages to appropriate queues.

Routing between exchanges and message queues is based on some pre-defined

rules and conditions.

Messages can be stored in message queues and then be sent to receivers.

Beyond this type of point-to-point communication, AMQP also supports the

publish/subscribe communications model.
An AMQP network consists of nodes connected via links.

A link is a unidirectional route between two nodes.

A link attaches to a node at a terminus.

There are two kinds of terminus: sources and targets.

A terminus is responsible for tracking the state of a particular stream of incoming or

outgoing messages. Sources track outgoing messages and targets track incoming
messages.

Nodes exist within a container. Examples of containers are brokers and client
applications. Each container MAY hold many nodes.
As a message travels through an AMQP network, the responsibility for safe storage
and delivery of the message is transferred between the nodes it encounters.

Message Transfer between Nodes

Communication Endpoints
The AMQP transport specification defines a peer-to-peer protocol for transferring
messages between nodes in an AMQP network.

In order for communication to occur between nodes in different containers a

connection needs be established

An AMQP Connection
An AMQP connection consists of a full-duplex, reliably ordered sequence of frames.

Connections have a negotiated maximum frame size

The precise requirement for a connection is that if the nth frame arrives, all frames
prior to n MUST also have arrived.

An AMQP connection is divided into a negotiated number of independent unidirectional

channels.

Each frame is marked with the channel number indicating its parent channel, and the
frame sequence for each channel is multiplexed into a single frame sequence for the
connection.
An AMQP session correlates two unidirectional channels to form a bidirectional,
sequential conversation between two containers.

Sessions provide a flow control scheme based on the number of transfer frames
transmitted.

Since frames have a maximum size for a given connection, this provides flow control
based on the number of bytes transmitted and can be used to optimize
performance.

An AMQP Session
 AMQP message format.
AMQP defines a layer of messaging on top of its transport layer. Messaging
capabilities are handled in this layer.

AMQP defines two types of messages: bare massages that are supplied by the
sender and annotated messages that are seen at the receiver.

The header in this format conveys the delivery parameters including durability,
priority, time to live, first acquirer, and delivery count.
 The first four bytes show the frame size.

DOFF (Data Offset) gives the position of the

body inside the frame.

The Type field indicates the format and

purpose of the frame.

For example, 0x00 is used to show that the

frame is an AMQP frame or type code 0x01
AMQP frame format. represents a SASL frame

Simple Authentication and Security Layer (SASL)

 The Constrained Application Protocol (CoAP)

CoAP is to design a generic web protocol for the special requirements of this
constrained environment, especially considering energy, building automation, and other
machine-to-machine (M2M) applications.
CoAP has the following main features:

o Web protocol fulfilling M2M requirements in constrained environments

o UDP binding with optional reliability supporting unicast and multicast requests.
o Asynchronous message exchanges.
o Low header overhead and parsing complexity.
o URI and Content-type support.
o Simple proxy and caching capabilities.
A stateless HTTP mapping, allowing proxies to be built providing access to CoAP resources
via HTTP in a uniform way
Stateless Protocol does not require the server to retain the server information or session details.
Stateful Protocol require server to save the status and session information.

Endpoint
An entity participating in the CoAP protocol

Sender
The originating endpoint of a message.

Recipient
The destination endpoint of a message.

Client
The originating endpoint of a request; the destination endpoint of a response.
 Server
The destination endpoint of a request; the originating endpoint of a response.

Origin Server
The server on which a given resource resides or is to be created.

Intermediary
A CoAP endpoint that acts both as a server and as a client towards an origin server

Proxy
An intermediary that mainly is concerned with forwarding requests and relaying
back responses, possibly performing caching, namespace translation, or protocol
translation in the process.
The interaction model of CoAP is similar to the client/server model of HTTP.
However, machine-to-machine interactions typically result in a CoAP
implementation acting in both client and server roles.

A CoAP request is equivalent to that of HTTP and is sent by a client to request

an action (using a Method Code) on a resource (identified by a URI) on a server.

The server then sends a response with a Response Code; this response may
include a resource representation.
Unlike HTTP, CoAP deals with these interchanges asynchronously over a
datagram-oriented transport such as UDP.

This is done logically using a layer of messages that supports optional reliability
(with exponential back-off).
CoAP defines four types of messages:

Confirmable

Non-confirmable

Acknowledgement

Reset

The basic exchanges of the four types of messages are somewhat orthogonal to
the request/response interactions; requests can be carried in Confirmable and
Non-confirmable messages, and responses can be carried in these as well as
piggybacked in Acknowledgement messages.
Abstract Layering of CoAP
 Messaging Model

The CoAP messaging model is based on the exchange of messages over

UDP between the endpoints.

CoAP uses a short fixed-length binary header (4 bytes) that may be followed by
compact binary options and a payload.

This message format is shared by requests and responses.

Each message contains a Message ID used to detect duplicates and for optional
reliability.
Reliability is provided by marking a message as Confirmable (CON). A Confirmable
message is retransmitted using a default timeout and exponential back-off between
retransmissions, until the recipient sends an Acknowledgement message (ACK) with the
same Message ID

The Message ID is compact; it is 16-bit in size,

enables up to about 250 messages per second
from one endpoint to another with default
protocol parameters

Reliable Message Transmission

When a recipient is not at all able to process a Confirmable message (i.e., not even able
to provide a suitable error response), it replies with a Reset message (RST) instead of an
Acknowledgement (ACK).
A message that does not require reliable transmission (for example, each single
measurement out of a stream of sensor data) can be sent as a Non-confirmable
message (NON). These are not acknowledged, but still have a Message ID for
duplicate detection

Unreliable Message Transmission

As CoAP runs over UDP, it also supports the use of multicast IP destination addresses,
enabling multicast CoAP requests.
Request/Response Model
A request is carried in a Confirmable (CON) or Non-confirmable (NON) message,
and, if immediately available, the response to a request carried in a Confirmable
message is carried in the resulting Acknowledgement (ACK) message. This is called
a piggybacked response

Two GET Requests with Piggybacked Responses

If the server is not able to respond immediately to a request carried in a Confirmable
message, it simply responds with an Empty Acknowledgement message so that the
client can stop retransmitting the request. When the response is ready, the server
sends it in a new Confirmable message (Separate response)

A GET Request with a Separate Response

CoAP makes use of GET, PUT, POST, and DELETE methods in a similar
manner to HTTP

The protocol supports the caching of responses in order to efficiently fulfil

requests.

Proxying is useful in constrained networks for several reasons, including to limit

network traffic, to improve performance, to access resources of sleeping devices, and
for security reasons.

The proxying of requests on behalf of another CoAP endpoint is supported in the

protocol.
 CoAP is based on the exchange of compact messages that, by default, are
transported over UDP (i.e., each CoAP message occupies the data section of
one UDP datagram).

CoAP may also be used over Datagram Transport Layer Security (DTLS)

CoAP messages are encoded in a simple binary format.

The message format starts with a fixed-size 4-byte header. This is followed by a
variable-length Token value, which can be between 0 and 8 bytes long.