Unit 4

IOT Protocols
Web browsers use HTTP protocol to communicate with the servers on the
internet. Likewise, IoT devices use specific protocols to communicate (send
and receive data) over the internet to each other.
And here are some of the most known IoT protocols:

▪ CoAP (Constrained Application Protocol)

▪ AMQP (Advanced Message Queuing Protocol)
▪ DDS (Data Distribution Service)
▪ STOMP (Simple Text Oriented Messaging Protocol)
▪ MQTT (Message Queue Telemetry Transport)
In a message queue, each incoming message is stored in the queue until it is picked
up by a client (often called a consumer).
If no client picks up the message, the message remains stuck in the queue and waits
to be consumed. In a message queue, it is not possible for a message not to be
processed by any client, as it is in MQTT if nobody subscribes to a topic.

In a traditional message queue, a message can be processed by one consumer only.

The load is distributed between all consumers for a queue.

In MQTT the behavior is quite the opposite: every subscriber that subscribes to the
topic gets the message.
 HTTP MQTT
IoT Agent communicates with IoT devices indirectly
IoT Agent communicates with IoT devices directly
via an MQTT Broker
Request-Response Paradigm Publish-Subscribe Paradigm
IoT Devices must always be ready to receive
IoT Devices choose when to receive communication
communication
Higher Power Requirement Low Power Requirement
What is MQTT?
Message Queuing Telemetry Transport.

MQTT is a lightweight publish/subscribe messaging protocol designed for low bandwidth

environments.

MQTT Clients
Because MQTT clients don’t have addresses like email addresses, phone numbers etc.
you don’t need to assign addresses to clients like you do with most messaging systems.

MQTT Brokers or Servers

Note: The original term was broker but it has now been standardized as Server.
MQTT requires the use of a central Broker

MQTT uses TCP/IP to connect to the broker.

Message Brokering Basic Terms

1.Broker: The broker accepts messages from clients and then delivers them to any interested clients.
Messages belong to a topic. (Sometimes brokers are called “servers.”)

2.Client: A “device” that either publishes a message to a topic, subscribes to a topic, or both.

3.Topic: A namespace (or place) for messages on the broker. Clients subscribe and publish to a topic.

4.Publish: A client sending a message to the broker, using a topic name.

5.Subscribe: A client tells the broker which topics interest it. Once subscribed, the broker sends
messages published to that topic. (In some configurations the broker sends “missed” messages.) A client
can subscribe to multiple topics.

6.Unsubscribe: Tell the broker you are bored with this topic. In other words, the broker will stop sending
messages on this topic.
Client
MQTT clients are both publishers and subscribers.

An MQTT client is any device (from a micro controller up to a full-fledged server) that runs an MQTT
library and connects to an MQTT broker over a network.
MQTT server is called a broker and the clients are simply the connected devices.

•When a device (a client) wants to send data to the broker, we call this operation a “publish”.
•When a device (a client) wants to receive data from the broker, we call this operation a
“subscribe”.
The publish/subscribe pattern

The publish/subscribe pattern (also known as pub/sub) provides an alternative

to traditional client-server architecture.

In the client-sever model, a client communicates directly with an endpoint.

In pub/sub model the publishers and subscribers never contact each other
directly. In fact, they are not even aware that the other exists.

The connection between them is handled by a third component (the broker).

The job of the broker is to filter all incoming messages and distribute them
correctly to subscribers.
1.Clients do not have addresses like in email systems, and messages are not sent to
clients.
2.Messages are published to a broker on a topic.
3.The job of an MQTT broker is to filter messages based on topic, and then distribute
them to subscribers.
4.A client can receive these messages by subscribing to that topic on the same broker
5.There is no direct connection between a publisher and subscriber.
6.All clients can publish (broadcast) and subscribe (receive).
7.MQTT brokers do not normally store messages.
Example:
Let’s say there is a device that has a temperature sensor. Certainly, it wants to send his readings to the broker.
On the other side, a phone/desktop application wants to receive this temperature value.

•The device defines the topic it wants to publish on, ex: “temperature”. Then, it publishes the message
“temperature value”.
•The phone/desktop application subscribes to the topic “temperature”. Then, it receives the message that
the device has published, which is the temperature value.
the broker role here is to take the message “temperature value” and deliver it to phone/desktop application.
The MQTT connection is always between one client and the broker. Clients never connect to
each other directly.

To initiate a connection, the client sends a CONNECT message to the broker. The broker responds with a
CONNACK (Acknowledgement) message and a status code.

Once the connection is established, the broker keeps it open until the client sends a disconnect command
or the connection breaks.
The broker is responsible for receiving all messages, filtering the messages, determining who is
subscribed to each message, and sending the message to these subscribed clients.

It also holds the sessions of all persisted clients, including subscriptions and missed messages.
Another responsibility of the broker is to authenticate and authorize the clients.

the broker is the central hub through which every message must pass.
ClientId

The client identifier (ClientId) identifies each MQTT client that connects to an MQTT broker. The broker
uses the ClientID to identify the client and the current state of the client. Therefore, this ID should be
unique per client and broker.

Clean Session

The clean session flag tells the broker whether the client wants to establish a persistent session or not. In a
persistent session (CleanSession = false), the broker stores all subscriptions for the client and all missed
messages for the client that subscribed with a Quality of Service (QoS) level 1 or 2.

If the session is not persistent (CleanSession = true), the broker does not store anything for the client and
purges all information from any previous persistent session.
KeepAlive:

The keep alive is a time interval in seconds that the client specifies and communicates to the
broker when the connection established.

This interval defines the longest period of time that the broker and client can endure without
sending a message.The client commits to sending regular PING Request messages to the broker.

The broker responds with a PING response. This method allows both sides to determine if the
other one is still available.
There are many MQTT brokers available that you can use for testing and for real
applications.

Mosquitto is a free open source MQTT broker that runs on Windows and Linux.

If you don’t want to install and manage your own broker you can use a cloud
based broker.

Eclipse has a free public MQTT broker and COAP server that you can also use
for testing.
Mosquitto is an open source message broker that implements the MQTT protocol. It’s lightweight
and suitable for use on all devices from a low power single board like Arduino, ESP8266 to full
computers and servers.

Cloud-based Mosquitto brokers are many, like:

•ThingMQ
•ThingStudio
•MQTT.io
•Heroku
•CloudMQTT

CloudMQTT broker
CloudMQTT is one of the best and easiest cloud-based Mosquitto broker.
CloudMQTT has a free plan that allows you to set up your own CloudMQTT broker instance that will run on their
hardware servers. Hence, you can have an online broker that’s ready to use in your IoT project.
It also has a well designed GUI to monitor the publishing and subscribing processes and topics through an easy to
use WebSocket UI.
You can consider a TCP/IP connection to be similar to a telephone connection.
Once a telephone connection is established you can talk over it until one party hangs up.
Most MQTT clients will connect to the broker and remain connected even if they aren’t
sending data.
MQTT clients publish a keepalive message at regular intervals (usually 60 seconds)
which tells the broker that the client is still connected.

The Client Name or Client ID

All clients are required to have a unique client name or ID.

If you attempt to connect to an MQTT broker with the same name as an existing client
then the existing client connection is dropped.
Clean Sessions
MQTT clients by default establish a clean session with a broker.
A clean session is one in which the broker isn’t expected to remember anything about the client when it
disconnects.

With a non clean session the broker will remember client subscriptions and may hold undelivered messages
for the client.
Last Will Messages
to notify a subscriber that the publisher is unavailable due to network outage.

The last will message is set by the publishing client, and is set on a per topic basis
which means that each topic can have its own last will message.

The message is stored on the broker and sent to any subscribing client (to that topic)
if the connection to the publisher fails.

If the publisher disconnects normally the last Will Message is not sent.
The most important aspect of pub/sub is the decoupling of the publisher of the
message from the recipient (subscriber).

•Space decoupling: Publisher and subscriber do not need to know each other (for
example, no exchange of IP address and port).

•Time decoupling: Publisher and subscriber do not need to run at the same time.

•Synchronization decoupling: Operations on both components do not need to be

interrupted during publishing or receiving.
Message filtering
1: Subject-based filtering

This filtering is based on the subject or topic that is part of each message. The receiving client
subscribes to the broker for topics of interest. From that point on, the broker ensures that the receiving
client gets all message published to the subscribed topics. In general, topics are strings with a
hierarchical structure that allow filtering based on a limited number of expressions.

2: Content-based filtering
In content-based filtering, the broker filters the message based on a specific content filter-language. The
receiving clients subscribe to filter queries of messages for which they are interested. A significant
downside to this method is that the content of the message must be known beforehand and cannot be
encrypted or easily changed.

3: Type-based filtering
When object-oriented languages are used, filtering based on the type/class of a message (event) is a
common practice. For example,, a subscriber can listen to all messages, which are of type Exception or
any sub-type.
Client and Server model
Client-server architecture

An application program running on the local machine sends a request to another application
program is known as a client, and a program that serves a request is known as a server. For
example, when a web server receives a request from the client host, it responds to the request to
the client host.

Characteristics Of Client-server architecture:

•In Client-server architecture, clients do not directly communicate with each other. For
example, in a web application, two browsers do not directly communicate with each other.

•A server is fixed, well-known address known as IP address because the server is always ON
while the client can always contact the server by sending a packet to the sender's IP address.
•A client program runs only when it requests for a service from the server while the server program
runs all time as it does not know when its service is required.

•A server program is an infinite program means that when it starts, it runs infinitely unless the problem
arises. The server waits for the incoming requests from the clients. When the request arrives at the
server, then it responds to the request. But it never initiates the service.

•A server provides a service for many clients not just for a single client. Therefore, we can say that
client-server follows the many-to-one relationship. Many clients can use the service of one server.

•Services are required frequently, and many users have a specific client-server application program. For
example, the client-server application program allows the user to access the files, send e-mail, and so
on.
Advantages of Client-server networks:

Centralized back-up is possible in client-server networks, i.e., all the data is stored in a server.

These networks are more secure as all the shared resources are centrally administered.

The use of the dedicated server increases the speed of sharing resources. This increases the
performance of the overall system.

We can increase the number of clients and servers separately, i.e., the new element can be added,
or we can add a new node in a network at any time.
Disadvantages of Client-Server network:

•Traffic Congestion is a big problem in Client/Server networks. When a large number of

clients send requests to the same server may cause the problem of Traffic congestion.

•It does not have a robustness of a network, i.e., when the server is down, then the client
requests cannot be met.

•A client/server network is very decisive. Sometimes, regular computer hardware does not
serve a certain number of clients. In such situations, specific hardware is required at the server
side to complete the work.

•Sometimes the resources exist in the server but may not exist in the client. For example, If the
application is web, then we cannot take the print out directly on printers without taking out the
print view window on the web.
Quality of Service (QoS) Levels :
Quality of Service is a level of agreement between the client and the broker. This level
helps the clients to ensure the reliability for the delivery of their message.

There are 3 QoS levels :

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.
There is no waiting for acknowledgments in this scenario. Hence if the network
goes down, the message might not be delivered.
QoS 1: At least once –
the message will be delivered at least once.

In this QoS level, the sender publishes the message and also stores it until an 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 can not 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.
QoS 2: Exactly once –
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.
Constrained Application Protocol (CoAP)

is a specialized web transfer protocol for use with constrained nodes and constrained
networks with low bandwidth and low availability in the Internet of Things.

The protocol was designed by the Internet Engineering Task Force (IETF)

CoAP is application layer protocol

The Application layer includes the following functions:

•Identifying communication partners:
•Determining resource availability:
•Synchronizing communication:
Message Format

•Ver: It is a 2 bit unsigned integer indicating the version

•T: it is a 2 bit unsigned integer indicating the message type: 0 confirmable, 1 non-confirmable
•TKL: the token 4 bit length
•Code: It is the code response (8 bit length)
•Message ID: It is the message ID expressed with 16 bit
CoAP employs a two layers structure
CoAP has four messaging modes:
Confirmable and non‐confirmable modes represent the reliable and unreliable transmissions,
respectively, while the other modes are used for request/response.

Piggyback is used for client/server direct communication where the server sends its response
directly after receiving the message, i.e., within the acknowledgment message.

On the other hand, the separate mode is used when the server response comes in a message
separate from the acknowledgment, and may take some time to be sent by the server.

Similar to HTTP, CoAP utilizes GET, PUT, PUSH, DELETE messages requests to retrieve,
create, update, and delete, respectively
A confirmable message is a reliable message.
When exchanging messages between two
endpoints, these messages can be reliable.
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).

If recipient fail to process message, it

responses by replacing ACK with RST
If the server has troubles managing the incoming request, it can send back a Rest
message (RST) instead of the Acknowledge message (ACK):
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.

Even if these messages are unreliable, they have a

unique ID.
CoAp Request/Response Model
The request is sent using a Confirmable (CON)
or Non-Confirmable (NON) message. There 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), the server sends
back to the client an Acknowledge message
containing the response or the error code:
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:
Non confirmable request and response:

in Non confirmable request client send NON type message

indicate that Server don't need to confirm.
Server will resend a NON type message with response
 COAP MQTT
Message Query Telemetry
Abbrevation Constrained Application Protocol
Transport
Communication Type It uses Request-Response model. It uses Publish-Subscribe model
This uses both Asynchronous and
Messaging Mode This uses only Asynchronous
Synchronous.
This mainly uses User Datagram This mainly uses Transmission
Transport layer protocol
protocol(UDP) Control protocol(TCP)
Header size It has 4 bytes sized header It has 2 bytes sized header
Parameter MQTT HTTP
Abbrevation Message Queuing Telemetry Transport Hyper Text Transfer Protocol

It works on request/response
Architecture It works on publish/subscribe model.
model.
Complexity It has less complexity. It is more complex.
It runs over User Datagram
Runs over It runs over Transmission Control Protocol.
Protocol.
This protocol’s design is
Protocol Design This protocol’s design is Data centric.
Document centric.
The message size generated is less as it uses The message size generated is
Message Size
binary format. more as it uses ASCII format.
Header Size It is of 2 bytes. It is of 8 bytes.
Port Number It works on 1883 port. It works on 80 or 8080 port.
REST
REST stands for REpresentational State Transfer.

An API is an application programming interface. It is a set of rules that allow

programs to talk to each other. The developer creates the API on the server and
allows the client to talk to it.

REST determines how the API looks like. REST is a set of rules that developers
follow when they create their API. One of these rules states that you should be able
to get a piece of data (called a resource) when you link to a specific URL.

Each URL is called a request while the data sent back to you is called a
response
RESTFul web services

A web service is a collection of open protocols and standards used for exchanging data between
applications or systems. Software applications written in various programming languages and
running on various platforms can use web services to exchange data over computer networks like the
Internet in a manner similar to inter-process communication on a single computer.

Web services based on REST Architecture are known as RESTful web services. These webservices
uses HTTP methods to implement the concept of REST architecture.
REST is web standards based architecture and uses HTTP Protocol.
An HTTP Request has five major parts −

•Verb − Indicates the HTTP methods such as GET, POST, DELETE, PUT, etc.
•URI − Uniform Resource Identifier (URI) to identify the resource on the server.
•HTTP Version − Indicates the HTTP version. For example, HTTP v1.1.
•Request Header − Contains metadata for the HTTP Request message as key-value pairs. For
example, client (or browser) type, format supported by the client, format of the message body,
cache settings, etc.
•Request Body − Message content or Resource representation.
•Status/Response Code − Indicates the Server status for the requested resource.
e.g., 404 means resource not found and 200 means response is ok.
•HTTP Version − Indicates the HTTP version. For example HTTP v1.1.
•Response Header − Contains metadata for the HTTP Response message as keyvalue
pairs. For example, content length, content type, response date, server type, etc.
•Response Body − Response message content or Resource representation.
a request is made up of four things:

1.The endpoint
2.The method
3.The headers
4.The data (or body)
The endpoint (or route) is the url you request for.

It follows this structure:

root-endpoint/?
The root-endpoint is the starting point of the API you’re requesting from.

The root-endpoint of Github’s API is https://api.github.com

while the root-endpoint Twitter’s API is https://api.twitter.com.

 The path determines the resource you’re requesting for.

https://www.smashingmagazine.com/tag/javascript/

https://www.smashingmagazine.com/ is the root-endpoint and

/tag/javascript is the path.

JSON

JSON (JavaScript Object Notation) is a common format for sending and requesting data
through a REST API

In JSON, each property and value must be wrapped with double quotation marks, like
this:
The Method
The method is the type of request you send to the server. You can choose from these five types below:

•GET − Provides a read only access to a resource.

•POST − Used to create a new resource.
•DELETE − Used to remove a resource.
•PUT − Used to update a existing resource or create a new resource.

These methods provide meaning for the request you’re making.

They are used to perform four possible actions:

Create, Read, Update and Delete (CRUD).

A RESTful web service usually defines a URI, Uniform Resource Identifier a service,
provides resource representation such as JSON and set of HTTP Methods.
Examples:

•GET http://www.example.com/customers/12345
•GET http://www.example.com/customers/12345/orders
•GET http://www.example.com/buckets/sample

Examples:

•POST http://www.example.com/customers
•POST http://www.example.com/customers/12345/orders

PATCH is used for **modify** capabilities. The PATCH request only needs to contain the changes to the
resource, not the complete resource.
Examples:

•DELETE http://www.example.com/customers/12345
•DELETE http://www.example.com/customers/12345/orders
•DELETE http://www.example.com/bucket/sample

Calling DELETE on a resource a second time will often return a 404 (NOT FOUND) since it was already
removed and therefore is no longer findable.
Separation of Client and Server
In the REST architectural style, the implementation of the client and the implementation of the server
can be done independently without each knowing about the other. This means that the code on the
client side can be changed at any time without affecting the operation of the server, and the code on
the server side can be changed without affecting the operation of the client.

As long as each side knows what format of messages to send to the other, they can be kept modular
and separate. Separating the user interface concerns from the data storage concerns, we improve the
flexibility of the interface across platforms and improve scalability by simplifying the server
components. Additionally, the separation allows each component the ability to evolve independently.
By using a REST interface, different clients hit the same REST endpoints, perform the same actions,
and receive the same responses.
Statelessness

Systems that follow the REST paradigm are stateless, meaning that the server does not need to
know anything about what state the client is in and vice versa. In this way, both the server and the
client can understand any message received, even without seeing previous messages.

This constraint of statelessness is enforced through the use of resources, rather than commands.
Resources are the nouns of the Web - they describe any object, document, or thing that you may
need to store or send to other services.

These constraints help RESTful applications achieve reliability, quick performance, and scalability,
as components that can be managed, updated, and reused without affecting the system as a whole,
even during operation of the system.
Restful Architecture

1] State and functionality are divided into distributed resources –

every resource should be accessible via the normal HTTP commands
of GET, POST, PUT, or DELETE.

2] The architecture is client/server, stateless, layered, and supports

caching
RESTFul Principles and Constraints

1. RESTFul Client-Server

2. Stateless

3. Cache
What is Interoperability?
Interoperability is a characteristic of a product or system, whose interfaces are
completely understood, to work with other products or systems, present or future, in
either implementation or access, without any restrictions.

Communicate meaningfully

Exchange data or services

Why is Interoperability Important in Context of IoT?

• To fulfill the IoT objectives

• Physical objects can interact with any other physical objects and can share their
information

• Any device can communicate with other devices anytime from anywhere
Machine to Machine communication(M2M), Device to Device Communication
(D2D), Device to Machine Communication (D2M)

• Seamless device integration with IoT network

Why is Interoperability required?

Heterogeneity
Different wireless communication protocols such as ZigBee (IEEE 802.15.4), Bluetooth (IEEE
802.15.1), GPRS, 6LowPAN, and Wi-Fi (IEEE 802.11)

Different wired communication protocols like Ethernet (IEEE 802.3) and Higher Layer LAN
Protocols (IEEE 802.1)

Different programming languages used in computing systems and websites such as JavaScript, JAVA,
C, C++, Visual Basic, PHP, and Python

Different hardware platforms such as Crossbow, NI, etc.

Why is Interoperability required?
Different operating systems:
(for sensor node) TinyOS, SOS, Mantis OS, RETOS)

(for personal computer): Windows, Mac, Unix, and Ubuntu

Different databases: DB2, MySQL, Oracle, PostgreSQL, SQLite, SQL Server, and
Sybase

Different data representations

User Interoperability The following problems need to be solved

Device identification and categorization for discovery

There are different solutions for generating unique address

Electronic Product Codes (EPC)

Universal Product Code (UPC)
Uniform Resource Identifier (URI)
IP Addresses : IPv6
WebSocket API
The idea of WebSockets was borne out of the limitations of HTTP-based technology.

In a traditional HTTP system, a web server is designed to receive and respond to requests from
clients via HTTP messages. This traditional communication can only be initiated in one direction:
from the client to the server.

the only way for clients to get updated information from the server is to send requests.

The WebSocket API is an advanced technology that makes it possible to open a two-way
interactive communication session between the user's browser and a server.
Web sockets are defined as a two-way communication between the
servers and the clients, which mean both the parties, communicate
and exchange data at the same time.

This protocol defines a full duplex communication from the

ground up.

Web sockets take a step forward in bringing desktop rich

functionalities to the web browsers.
In computer science, handshaking is a process that ensures the server is in sync with its
clients. Handshaking is the basic concept of Web Socket protocol.
https://1sheeld.com/mqtt-protocol/?__cf_chl_jschl_tk__=4cde343d3b5c242a55a0272c36b8d12b59594cbf-1615300893-
0-AdpNwHT4ypDD2Xh-C6H3qF3El6-cUqdutsmUtTXHj7azENFRuMY-
7lQ5tLz62gJVhMPeH6Wro0aHiCXXoeL8sXGfTs3ubv8Xzu-
OD3co5S9VX2Ov8bOSiujCz_JfDN5P4P6CK1xRGZPpgOlkJ9Ih_Jndx94On2uWj-91lAkSWOIqimx2VOG-
euZVwarnOO2LYSlESCMKhNpyTuhxCW2pdzte_v19idcvMA1b-
7tb6T6QJfLWUjBeW1Y1Q3hcAIu8VqowEU65KQYi78GHID1RQT1BR5t7RzhLjQN8xUoTsRPvaB7a58mpUklklzuMzOrzoEANVO
joO6nzRpqiSPlYVA8