Application layer

1. In IoT architecture, Application layer lies above the

service discovery layer. It is highest layer in the
architecture extending from the client ends. It is the
interface between the end devices and the
network.
2. This layer is implemented through a dedicated
application at the device end. Like for a computer,
application layer is implemented by the browser.
It is the browser which implements application
layer protocols like HTTP, HTTPS, SMTP and FTP.
3. Same way, there are application layer protocols
specified in context to IOT as well. This layer is
responsible for data formatting and presentation.
4. The application layer in the Internet is typically
based on HTTP protocol. However, HTTP is not
suitable in resource constrained environment
because it is extremely heavyweight and thus
 Why Aren’t the Existing Internet Protocols “Good Enough?”

There are a few reasons, for examples,

• It cannot accommodate the major power constraints of some IoT devices.
• The connection may not always be stable or may have limited memory.
• Finally, not all IoT applications require guaranteed data delivery, data protection,
or message acknowledgment.

These capabilities may be beneficial, but the data overhead and power cost may not
be worth it.
So, there are many alternate protocols that have been
developed for IOT environments. Some of the popular IOT
Application Layer protocols are as follow

• MQTT • SMQTT • CoAP

• DDS • XMPP • AMQP
• RESTful HTTP • MQTT-SN • STOMP
• SMCP • LLAP • SSI
• LWM2M • M3DA • XMPP-IOT
• ONS 2.0 • SOAP • Websocket
• HTTP/2 • JavaScript IOT
What is MQTT?
MQTT stands for Message Queuing Telemetry Transport. It is a lightweight
publish and subscribe system where you can publish and receive messages as
a client.
MQTT is a simple messaging protocol,

designed for constrained devices with

Low-bandwidth.

So, it’s the perfect solution for Internet of Things applications.

MQTT allows you to

• send commands to control outputs

• Read and publish data from sensor nodes

Therefore, it makes it really easy to establish a communication between multiple

devices.
In MQTT there are a few basic concepts that need to understand:

1. Publish/Subscribe 2. Messages
3. Topics 4. Broker

MQTT – Publish/Subscribe

The first concept is the publish and subscribe system. In a publish and
subscribe system, a device can publish a message on a topic, or it can
be subscribed to a particular topic to receive messages

 For example Device 1 publishes on a topic.

 Device 2 is subscribed to the same topic as device 1 is publishing in.
 So, device 2 receives the message.
Rabbitmqctl.bat list_queues
MQTT – Messages

Messages are the information that you want to exchange between your
devices. This could be a command or data.

MQTT – Topics

Another important concept is the topics. Topics are the way you register
interest for incoming messages or how you specify where you want to
publish the message.
Topics are represented with strings separated by a forward slash. Each forward
slash indicates a topic level.
Broker
1. MQTT has been specially designed for sensor networks and wireless
sensor networks.
2. MQTT allows devices to send or publish data information on a given
topic to a server.
3. There is an MQTT broker (Broker- Mosquitto) in between publisher
and subscriber.
4. The broker then transfers the information to the clients that are
previously subscribed.
5. The sensors are interfaced with a broker which is an IoT device or
server that reads and publish sensor data.
6. The other devices that subscribe for and request sensor data are
called clients.
7. The sensors themselves are referred as publishers in the network.
8. The client can be a laptop, smart phone, tablet or other mobile
device.
9. The client devices need to subscribe with the broker in the network
to receive sensor data.
10. For receiving data, the subscribed client devices have to establish
connection with the broker and request data.
11. The broker takes the data from the publisher (wireless sensors) and
sends it to the client requesting for it. Even if the connection with
the client device is broken after the request has been made, the
broker saves the data and sends when the client device reconnects
with the broker, it could receive the requested sensor data.
12. Similarly, if the connection between the publisher and the broker is
broken after the request has been made, the broker forwards
appropriate instructions sent by the publisher, so that client device
can reconnect and receive requested data.
 Key
 Subscribe to temperature  Publish to temperature
An MQTT session can be divided into four stages -
1) Connection 2) Authentication 3) Communication 4) Termination
Connection- In this stage, the client (like a mobile device or laptop) initiates a
TCP-IP connection with the broker (server) using a standard port (generally
1883 for non-encrypted and 8883 for encrypted communication through Secure
Sockets Layer (SSL) or Transport Layer Security (TLS) or a port defined by the
network operator.
Authentication- In encrypted communication, the server sends server
certificate to authenticate itself by the client and client may also send a
certificate to the server to authenticate itself. Though even in encrypted
communication, the client authentication is not part of the specification and also
not common. Still, usually, the client authentication is done by passing a
username and password by the client to the broker (server).
Termination - The publisher or client can terminate the connection
by sending a DISCONNECT message to the broker, after which, the
TCP-IP connection is closed. If the connection is broken suddenly (due
to limited network bandwidth) without termination request, the broker
sends the cached messages from the publisher to the client.
Communication - The sensor data is communicated to client using small code
footprints. It usually contains 2-byte long header, an optional variable length header,
sensor data as message payload limited to 250 Mb in size and Quality of Service
Level Indication.
There can be three Quality of Service (QoS) levels

- Unacknowledged Service (QoS Level 0)

- Acknowledged Service (QoS Level 1)
- Assured Service (QoS Level 2).

Each exceeding QoS level requires more network bandwidth and tolerance to latency.

There can be four types of operations that can be performed by a client

Publish: The data is communicated between the broker and the client on a specific
topic
Subscribe: The client can subscribe for specific topics in the network like a mobile
device might subscribe with a broker to read current temperature. The client needs to
send a SUBSCRIBE/SUBACK packet pair to the broker
Unsubscribe: For unsubscribing (from a topic), the client needs to send a
UBSUBSCRIBE/UNSUBACK packet pair to the server
Ping: The ping operation can be performed by a client device to check the live
connection with the broker
MQTT QoS Level 0 – At Most Once

1. When the client sends a message to a broker with the

QoS level set to 0, it means the client sends the
message only once and the broker does not
acknowledge that the message is received.
2. There is no guarantee that the broker receives the
message sent by the client.

This service level should used if:

• The Internet is reliable.

• Message loss on a small scale does not matter.
• Messages need to be delivered fast.
MQTT QoS Level 1 – At Least Once
1. When the client publishes a message with QoS level 1, the broker sends an
acknowledgement(PUBACK) message back to the client. This informs the
client that the broker has received the message.

2. The client stores the original message until it gets a PUBACK message
from the broker. If the client does not receive the PUBACK message, it
will resend the original message.

3. If a client subscribes to a topic on a broker with QoS level 1 and if a

message is published to that topic, then the broker sends that message to
all the clients and expects a PUBACK message from the all the clients.
This ensures that the subscribing client receives all the messages that is
published to that topic.

4. In both cases, if the sender does not receive a PUBACK message within
some amount of time, it will republish the original message to the recipients
with a duplicate flag(DUP). The DUP flag is not processed by the client or
the broker but can be used based in your program to handle duplicate
message.
While QoS level 1 guarantees that the message is being received, it can cause duplicate
messages to get republished if the PUBACK is not received on time. QoS Level 1 is
slower than Level 0.

This service level should used if:

•The client or broker must receive all messages.

•Duplicate messages can be handled properly.

MQTT QoS level 1 is used in commercial MQTT brokers like AWS IoT, Azure etc.

Most commercial MQTT brokers do not support QoS level 2 as its slow and consumes
more resources.
MQTT QoS Level 2 – Exactly Once

MQTT QoS Level 1 can cause duplicate

messages. Instead of building a
mechanism to handle message duplication,
we can use QoS Level 2. This service level
guarantees that the message is being
received only once!
The steps involved in QoS Level 2 are as follows:

1. When a receiver receives a message with QoS Level 2, it replies with a

PUBlish RECeived(PUBREC) message that acknowledges that the message has
been received. If the sender does not receive the PUBREC message, it will
republish the message with a DUP flag.
2. The sender removes the first publish message after receiving
the PUBREC message and sends a PUBlish RELease(PUBREL) message to
the receiver. If the sender does not receive the PUBREL message, it will
resend the PUBREL message with a DUP flag.

3. The receiver sends a PUBlish COMplete(PUBCOMP) message to the

sender. If the sender does not receive the PUBCOMP message, then
the PUBREL message is resent.

4. The sender removes the message from the queue.

QoS Level 2 is much slower than Level 1 or 0 because of the number of steps
involved.

This service level should be used if: Messages can be delivered slowly.
Message duplication causes issues.
Most commercial brokers like AWS IoT & Azure IoT do not support QoS
Level 2 as on todays date.
MQTT’s publish/subscribe model offers several specific benefits outlined
below:
 Independent Operation

While a node and the broker need to have each other’s IP address, nodes
function independently of one another. Without any knowledge of each
other, nodes can publish information and subscribe to other nodes’ published
information.
Reason being: Everything goes through the broker.
 Time and Synchronization Independence

A node can publish its information independent of a target node being

active or not. The target node then can receive the published information from
the broker once active. This allows nodes to self-manage low power sleep
states, while still supporting interoperation.
 Security Flexibility

MQTT uses TCP for its transport layer, enabling certain TCP security
capabilities. The protocol can leverage TLS/SSL security for encrypting
traffic, but this can be resource-intensive. Another option is to encrypt only
the packet payload. This is a better approach for networks that consider
power management a higher priority than security.

 Varied levels of Guaranteed Delivery

MQTT offers three QoS levels. QoS is an important feature of MQTT

because it guarantees message delivery, regardless of how unreliable the
network is. The minimal level is QoS 0, often referred to as “fire and
forget.” This level makes a single effort, or transmit burst, with no guarantee
of message arrival. QoS 1 attempts to guarantee the message is received, at
least once. Finally, the slowest and safest level is QoS 2. This level
guarantees the message is received, only once, and is also decoded.
 Last Will and Testament (LWT)

MQTT also sends a “last will and testament (LWT)” message.

The broker then stores the LWT message in the event a node
unexpectedly disconnects from the network. If the node
disappears, the broker notifies all subscribers of the node’s
LWT. And if the node returns, the broker notifies it of its prior
state. This is a beneficial feature when on unreliable networks.
The MQTT protocol offers great benefits for IoT applications, but
there are some negative tradeoffs to consider. These include:

 Need for a Central Broker

At the core of any publish/subscribe protocol is a central broker.
This can be a drawback for some IoT applications. Being the
central hub for every message, it is important for the broker to be

• Scalable
• open to integration
• failure-resistant

This can require overhead in the form of additional resources,

software, and complexity that are not core to the end-node
function. However, if the appropriate measures are not taken, the
broker can make an entire network vulnerable.
 TCP Protocol Implications
As previously mentioned, MQTT uses TCP for its transport
layer. This provides for a reliable, ordered, and error-checked
solution. However, these benefits come with additional
overhead which may or may not be a worthwhile.
Recently, a new version of MQTT was designed to address
some of these challenges. MQTT for Sensor Networks
(MQTT-SN) operates using the user datagram protocol (UDP)
in place of TCP. This provides broker support for indexing
topics (topic ID versus topic name). Because this protocol is
still under definition, it is not well-supported
Constrained Application Protocol (CoAP)

It is specifically designed for constrained (limited) Hardware.

The hardware that doesn’t support HTTP or TCP/IP can use
CoAP Protocol.

Basically, the designers of this protocol, taking inspiration by the

HTTP, had designed the CoAP protocol using UDP and IP
protocol. It is a lightweight protocol that needs low power IOT
application like for communication between battery powered IOT
devices. Like HTTP, it also follows client-server model. The
clients can GET, PUT, DELETE or POST informational
resources over the network.
CoAP makes use of two message types

- Requests - Responses.

• The messages contain a base header followed by message

body whose length is specified by the datagram.
• The messages or data packets are small in size, so that they
can be communicated among constraint devices without
data losses. The messages can be confirmable or non-
confirmable.

• For confirmable messages, the client needs to respond with

an acknowledgement after receiving the data packet. The
request messages can contain query strings to implement
additional functionalities like search, sort or paging.
CoAP structure
• CoAP is not a replacement for HTTP, but it is a
new design, which comes with features to
accommodate the limitations of HTTP.

• CoAP employs a two layer structure.

• These two layers are: Message Layer and
Request/ Response Layer.
• Message Layer supports four types of messages:
• CON (confirmation)
• NON (non-confirmable)
• ACK (Acknowledgement)
• RST (reset)
• Message layer is meant for Retransmitting lost packets.
• Request/Response layer contains methods like GET,PUT,POST and
DELETE
 Constrained Application Protocol (CoAP)
• Wireless protocols mainly fall under three
layers Application layer HTTP, CoAP, EBHTTP, SNMP,
• IOT uses TCP & UDP protocols. UDP is IPfix

less complex when compared with TCP. Network/ IPv6/IPv4, RPL, TCP/UDP,
Communication 6LoWPAN
This makes UDP a good choice, but the layer
only problem is that it is not stable, PHY/MAC layer IEEE802.11 Series, 802.3,
to take care of that it needs to 802.16,WirelessHART, Z-
WAVE, UWB
be combined with Application layer
• HTTP has computational complexity, low
data rate and high energy consumption,
therefore it is not suitable for constrained
devices. IETF came with numerous
protocols and COAP is one of them
1. Gilles & Robert, (15th November 2016), “Mastering The IoT: | Connectivity |
Technology”, Amsterdam / The Hague.
2. Pethuru Raj, Anupama C. Raman, “The Internet of Things: Enabling Technologies,
Platforms, and Use Cases”, CRC Press, New York
3. Lawrence Miller, “Internet of Things for Dummies”, Wiley Brand
4. Zeinab Kamal Aldein Mohammeda, Elmustafa Sayed Ali Ahmedb, “Internet of
Things Applications, Challenges and Related Future Technologies”
5. Debasis Bandyopadhyay · Jaydip Sen, (2014), “Internet of Things: Applications and
Challenges in Technology and Standardization”
6. M.A. Matin and M.M. Islam, “Overview of Wireless Sensor Network”
7. D. Stephan, H Paul, (2005), “Introduction to Wireless Sensor Networks”
8. White Paper on “Machine-to-Machine Communication (M2M)”
9. Machine-to-Machine Communications: Architectures, Standards and Applications
10. Building block of IoT
11. IoT standards and Protocols
12. Low-Rate Wireless Personal Area Networks: Enabling Wireless Sensors with IEEE
802.15.4 [Book]