UNIT – 4

1. Message Query Telemetry Transport (MQTT)

The Message Query Telemetry Transport (MQTT) protocol is a lightweight, TCP-based

messaging protocol used for IoT devices. It operates on the publish-subscribe

methodology, where clients receive information through a broker only for the topics they

are subscribed to. The broker acts as a mediator, categorizing messages into labels before

delivery. This protocol is suitable for transmitting data between resource-constrained

devices with low bandwidth and low power requirements. MQTT is widely used in IoT

frameworks for machine-to-machine (M2M) communication, providing a simple way to

distribute telemetry information in low-bandwidth environments.

Created as a low-overhead protocol to accommodate bandwidth and CPU limitations,

MQTT was designed to run in an embedded environment where it could provide a

reliable, effective path for communication. Suitable for connecting devices with a small

code footprint, MQTT is a good choice for wireless networks that experience varying

levels of latency due to occasional bandwidth constraints or unreliable connections. The

protocol has applications in industries ranging from automotive to energy to

telecommunications.

1.1. How does MQTT work?

Aimed at maximizing available bandwidth, MQTT's publish/subscribe (pub/sub)

communication model offers an alternative to the traditional client-server architecture.

Unlike the direct communication of the client-server model, the pub/sub model

decouples the client that sends messages (publisher) from the clients that receive them

(subscribers). In this model, brokers manage connections between publishers and

subscribers.

61 | P a g e
MQTT clients can function as both publishers and subscribers, meaning a single MQTT

client can both send and receive messages. When a device (or client) sends data to a

server (or broker), it is called publishing. Conversely, receiving data from the broker is

called subscribing. Multiple clients can connect to a broker and subscribe to topics of

interest.

If a subscribing client's connection to a broker is broken, the broker buffers messages

and delivers them once the client is back online. If a publishing client disconnects

unexpectedly, the broker can close the connection and send subscribers a cached

message with the publisher's instructions.

1.2. MQTT communication methods.

MQTT communication revolves around three primary methods:

a. Publish: Clients send messages to the broker on a specific topic. The broker then

forwards these messages to all clients subscribed to that topic.

b. Subscribe: Clients register their interest in one or more topics with the broker. They

will receive any messages published to those topics.

c. Unsubscribe: Clients can cancel their subscription to topics, stopping further message

delivery from those topics.

These methods allow for a decoupled, efficient communication model suitable for IoT

devices with limited processing power and network bandwidth.

1.3. What is an MQTT broker?

An MQTT broker acts as a go-between for the clients who are sending messages and the

subscribers who are receiving those messages. In a post office analogy, the broker is the

post office itself. All messages have to go through the broker before they can be delivered

to the subscriber.

62 | P a g e
Brokers may have to handle millions of concurrently connected MQTT clients, so when

choosing an MQTT broker, enterprises should rate them based on their scalability,

integration, monitoring and failure-resistance capabilities.

1.4. Message delivery reliability of MQTT

MQTT provides three levels of Quality of Service (QoS) to ensure message delivery

reliability:

a. QoS 0 (At most once): Messages are delivered according to the best effort of the

underlying TCP/IP network. No acknowledgment is sent by the recipient, and message

loss can occur.

b. QoS 1 (At least once): The message is guaranteed to arrive at least once. The sender

stores the message until it receives an acknowledgment (PUBACK) from the receiver.

This can result in duplicate messages.

c. QoS 2 (Exactly once): The highest level of service. It ensures the message is received

only once by using a four-step handshake process between the sender and receiver,

preventing duplicates.

1.4.1. Quality of service levels

QoS refers to an agreement between the sender of a message and the message's recipient.

It acts as a key feature in MQTT, giving the client the ability to choose between three

levels of service.

The three different QoS levels determine how the content is managed by the MQTT

protocol. Although higher levels of QoS are more reliable, they have more latency and

bandwidth requirements, so subscribing clients can specify the highest QoS level they

would like to receive.

63 | P a g e
1.4.1.1. QoS 0: At most Once –

When message is published with QoS level 0, the message will be delivered at most once.

In other words, there is no guarantee that the message will be delivered or not. If

delivered, then it will be delivered maximum once. In this QoS level, the sender publishes

the message only once and then discards the message. There is no waiting for

acknowledgments in this scenario. Hence if the network goes down, the message might

not be delivered. If the network is stable the message will be delivered but only once.

When to use?

 While developing applications that can afford the loss of few messages.

 While developing applications that have reliable underlying network so that the

messages published only once get delivered successfully.

1.4.1.2. QoS 1: At least once –

When message is published with QoS level 1, the message will be delivered at least once.

In this QoS level, the sender publishes the message and also stores it until an

64 | P a g e
acknowledgment is received from the receiver. Once an acknowledgment is received, the

sender will discard the message. If the acknowledgment is not received in time, the

message will be sent again. Hence in this QoS level, the message can be delivered, once

and sometimes even more than once, to ensure its successful delivery.

When to use?

 While developing applications that cannot afford the loss of messages.

 While developing applications that can handle the delivery of duplicate messages.

 While developing applications that do not want additional communication costs.

 While developing applications that do not have very reliable underlying network and

hence require reliability measures to be implemented at the protocol level.

1.4.1.3. QoS 2: Exactly once –

When message is published by the client with QoS level 2, the message will be delivered

exactly once. In this QoS level, the sender publishes the message, stores it, and waits for

PUBREC. The receiver after receiving the message sends PUBREC to the sender.

PUBREC is an indication that the message has been successfully delivered to the receiver.

Hence after receiving PUBREC, the message will be discarded by the sender. It then sends

PUBREL to the receiver. On receiving PUBREL, the receiver discards the saved states

and sends PUBCOMP. When the sender receives the final PUBCOMP, it will also discard

the previously saved states. Hence in QoS level 2, the additional messages used for

communication ensure the successful delivery of the message exactly once.

65 | P a g e
When to use?

 While developing applications that require every message to be delivered exactly once.

 While developing applications that can afford the additional communication cost.

 While developing applications that do not have very reliable underlying network and

hence require reliability measures to be implemented at the protocol level.

1.5. What are the drawbacks of MQTT?

Potential downsides to MQTT include the following:

 Slower Transmit Cycles: MQTT has slower transmit cycles compared to the

Constrained Application Protocol (CoAP).

 Resource Discovery: MQTT's resource discovery relies on flexible topic subscription,

while CoAP uses a more stable resource discovery system.

 Security: MQTT itself is unencrypted and relies on TLS/SSL (Transport Layer

Security/Secure Sockets Layer) for security encryption. This increases the complexity

and resource usage.

 Scalability: Creating a globally scalable MQTT network is difficult due to the

complexity of managing large topic trees and the lack of a clear method to divide these

trees into smaller, federated domains.

 Interoperability: MQTT faces interoperability challenges because its message

payloads are binary with no standardized encoding information, making it problematic

for different applications from various manufacturers to work seamlessly together.

66 | P a g e
 Authentication: MQTT has minimal built-in authentication features. Usernames and

passwords are sent in cleartext, requiring SSL/TLS for secure use, which is not

lightweight. Client-side certificate authentication is complex, and there is no native

way to control topic ownership and publication rights.

 Security Issues: MQTT's topic structure can form extensive trees without clear

divisions, leading to difficulties in managing large networks. Additionally, without

built-in sender identification in messages, harmful messages can be easily injected into

the network. Security measures added on top of MQTT increase the code footprint and

complicate implementations.

2. Constrained Application Protocol (CoAP)

CoAP, or Constrained Application Protocol, is a client-server based protocol designed for

constrained devices and networks, defined in RFC 7252. It facilitates communication

where CoAP packets are exchanged between client nodes under the command of a CoAP

server. Unlike HTTP, CoAP is optimized for low overhead and supports state transfer

models in applications, such as M2M data exchange.

2.1. Features of CoAP

The main features of CoAP include:

1. RESTful Architecture: CoAP is designed based on REST principles similar to

HTTP, using URIs and methods like GET, POST, PUT, and DELETE.

2. Lightweight: It has a small message footprint and low overhead, making it

suitable for devices with limited resources.

3. Asynchronous Communication: CoAP supports asynchronous message

exchanges, which is beneficial for devices that are not always on or available.

67 | P a g e
 4. UDP-based: It uses UDP as its transport protocol, which is lighter than TCP and

better suited for constrained networks.

5. Reliability: CoAP includes built-in mechanisms for reliability, such as

confirmable (CON) messages that require acknowledgment.

6. Multicast Support: CoAP can use multicast for efficient communication to

multiple devices.

7. Resource Discovery: CoAP allows for easy discovery of resources on a network,

facilitating device and service discovery.

2.2. Layers and Messaging Models of CoAP

CoAP can be represented as:

There are two different layers that make CoAP protocol: Messages and Request/Response.

The Messages layer deals with UDP and with asynchronous messages. The

Request/Response layer manages request/response interaction based on request/response

messages.

2.2.1. CoAP Messages Model

68 | P a g e
This is the lowest layer of CoAP. This layer deals with UDP exchanging messages between

endpoints. Each CoAP message has a unique id, this is useful to detect message

duplicates. A CoAP message is built by these parts:

 a binary header

 a compact option

 payload

The CoAP protocol uses two kind of messages:

 Confirmable message

 Non-confirmable message

a. Confirmable Message

A confirmable message is a reliable message. When exchanging messages between two

endpoints, these messages can be reliable. In CoAP a reliable message is obtained using

a Confirmable message (CON). Using this kind of message, the client can be sure that the

message will arrive at the server. A Confirmable message is sent again and again until

the other party sends an acknowledge message (ACK). The ACK message contains the

same ID of the confirmable message (CON).

The picture below shows the message exchange process:

69 | P a g e
If the server has troubles managing the incoming request it can send back a Rest message

(RST) instead of the Acknowledge message (ACK):

b. Non-Confirmable Message

The other message category is the Non-confirmable (NON) messages. These are messages

that don’t require an Acknowledge by the server. They are unreliable messages or in other

words messages that do not contain critical information that must be delivered to the

server. To this category belongs messages that contain values read from sensors.

Even if these messages are unreliable, they have a unique ID.

2.2.2. CoAP Request/Response Model

The CoAP Request/Response is the second layer in the CoAP abstraction layer. The

request is sent using a Confirmable (CON) or Non-Confirmable (NON) message. There

70 | P a g e
are several scenarios depending on if the server can answer immediately to the client

request or the answer if not available:

If the server can answer immediately to the client request then if the request is carried

using a Confirmable message (CON) then the server sends back to the client an

Acknowledge message containing the response or the error code:

As you can notice in the CoAP message there is a Token. The Token is different from the

Message ID and it is used to match the request and the response.

If the server can’t answer to the request coming from the client immediately, then it sends

an Acknowledge message with an empty response. As soon as the response is available

then the server sends a new Confirmable message to the client containing the response.

At this point the client sends back an Acknowledge message:

71 | P a g e
If the request coming from the client is carried using a NON-confirmable message then

the server answer using a NON-confirmable message.

2.3. CoAP's block wise transfers

CoAP's blockwise transfer mechanism is crucial for handling large payloads that exceed

the maximum size of a single CoAP message. This mechanism divides large messages into

smaller blocks that can be transmitted individually, ensuring efficient and reliable

delivery over constrained networks.

Significance:

1. Fragmentation and reassembly: Blockwise transfers break down large

payloads into manageable chunks, which are reassembled at the destination.

2. Reliability: Each block can be transmitted and acknowledged independently,

ensuring that the entire payload is reliably transferred even in lossy networks.

3. Flow control: The client and server can negotiate block sizes and manage flow

control, optimizing the transfer according to the network conditions and device

capabilities.

4. Efficiency: By using smaller blocks, CoAP reduces the likelihood of message loss

and the need for retransmissions, improving overall communication efficiency.

2.4. HTTP/CoAP Proxying

HTTP/CoAP proxying involves an intermediary (proxy) that translates requests and

responses between HTTP and CoAP. This allows CoAP devices to communicate with

HTTP clients and servers. The proxy can be either:

1. Forward Proxy: Receives HTTP requests and forwards them as CoAP requests to the

CoAP server, then translates the CoAP response back to HTTP.

72 | P a g e
2. Reverse Proxy: Receives CoAP requests from CoAP clients and forwards them as

HTTP requests to an HTTP server, then translates the HTTP response back to CoAP.

Mechanism of HTTP/CoAP Proxying

In this diagram:

 The HTTP client sends an HTTP request to the proxy.

 The proxy translates this request into a CoAP request and sends it to the IoT

device.

 The IoT device processes the CoAP request and sends a CoAP response back to the

proxy.

 The proxy translates the CoAP response into an HTTP response and sends it back

to the HTTP client.

1. Request Initialization:

 An HTTP client sends a request to the proxy server. This could be a typical web

application or a cloud service that needs to interact with IoT devices.

 The request includes a method (GET, POST, etc.), a URI, headers, and possibly a

payload.

73 | P a g e
2. Proxy Server Handling:

 The HTTP/CoAP proxy server receives the HTTP request. It understands both HTTP

and CoAP protocols and is capable of translating between them.

 The proxy server translates the HTTP request into a CoAP request. This involves

mapping the HTTP method to the CoAP method, converting headers, and possibly

encoding the payload in a format suitable for CoAP.

3. CoAP Request Transmission:

 The proxy server sends the translated CoAP request to the target IoT device. CoAP

uses UDP by default, making it suitable for constrained environments with limited

bandwidth and resources.

 The IoT device receives the CoAP request, processes it, and prepares a CoAP

response.

4. Response Handling:

 The IoT device sends the CoAP response back to the proxy server.

 The proxy server translates the CoAP response into an HTTP response. This involves

mapping the CoAP response code to an HTTP status code, converting headers, and

decoding the payload if necessary.

5. Response Delivery:

 The proxy server sends the HTTP response back to the original HTTP client.

 The client receives the HTTP response and processes it as if it was communicating

directly with the IoT device.

74 | P a g e
Benefits include:

 Interoperability: Allows devices using different protocols (HTTP and CoAP) to

communicate seamlessly.

 Resource Access: Enables CoAP devices to access resources available on HTTP

servers and vice versa.

 Protocol Optimization: Takes advantage of CoAP's efficiency for constrained

environments while allowing integration with the broader HTTP ecosystem.

2.5. Differences Between CoAP and MQTT

Basis of COAP MQTT

Constrained Application Message Query Telemetry

Abbreviation
Protocol Transport
Communication It uses Request-Response It uses Publish-Subscribe
Type model. model
This uses both Asynchronous
Messaging Mode This uses only Asynchronous
and Synchronous.
Transport layer This mainly uses User This mainly uses Transmission
protocol Datagram protocol (UDP) Control protocol (TCP)

Header size It has 4 bytes sized header It has 2 bytes sized header

No, it does not use REST

RESTful based Yes, it uses REST principles
principles
Persistence It supports and best used for
It does not have such support
support live data communication
Message It provides by adding labels to
It has no such feature.
Labelling the messages.
It is used in Utility area
It is used in IoT applications
Usability/Security networks and has secured
and is secure
mechanism.
Effectiveness in LNN is
Effectiveness Effectiveness in LNN is low.
excellent.
Communication Communication model is one- Communication model is
Model one. many-many.

75 | P a g e
2.6. Differences Between AMQP and HTTP

Parameter AMQP HTTP

Advanced Message Queuing

Full Form Hyper Text Markup Protocol.
Protocol.
It was developed by JPMorgan It was developed by Tim
Developed by
Chase. Berners-Lee.
Communication It has asynchronous It has synchronous
Nature communication nature. communication nature.
It is easy to setup and It is user centric and it can be
Usage
manage. used in every aspect.
It has guaranteed message It has no guarantee for
Message Delivery
delivery. message delivery.
It provides publish/subscribe It provides point to point
Interface
interface. interface.
HTTP protocol is not capable
AMQP protocol can bear the
Fault Tolerance to react to the server
server broke issue on its own.
breakdown issue.
It has the property of It does not have this capability
Segmentation segmentation and can process to treat each message as
messages into slots. segments.
It is general purpose protocol
Protocol It is specific protocol used for
and is used for multiple
Characteristics specific purposes.
purposes.
It is fast, flexible and cost- It is well known, efficient and
Advantages
effective protocol. multi-purpose protocol.

76 | P a g e