MTIN 101

IoT ARCHITECTURE AND PROTOCOLS

======================================================================

Unit IV
IoT Transport & Session Layer Protocols: Transport Layer (TCP, MPTCP, UDP, DCCP, SCTP)-(TLS, DTLS) – Session
Layer-HTTP, CoAP, CoAP message types, CoAP Request-Response model, XMPP, AMQP, MQTT, MQTT methods
and components, MQTT communication, topics and applications, SMQTT.
-----------------------------------------------------------------
Transport layer which is also known as routing layer is responsible for routing of data packets over a network. At
this layer, ordering of packets, error detection and correction in delivery of data packets is performed. The
commonly used transport layer protocols include the following –

TCP – Transmission Control Protocol (TCP) is connection oriented and heavyweight protocol. It is suitable for
reliable communication because in this protocol acknowledgment is received when the client sends the packet to
the server via TCP protocol. The data must be guaranteed sent at the other end if the packet is sent via TCP
protocol.
The protocol operates in three phases – Connection establishment, data transfer and connection close. A TCP
connection is managed by an internet socket which lying at the end point (physical) undergoes various state
changes.
The packet overhead is very large in this protocol. TCP consumes more power from the devices and has large
overhead so it is not suitable for low power devices with constrained environment. Therefore, UDP is preferred as
a connection less protocol for low overhead.
UDP – User Datagram Protocol is a connection less protocol and is not reliable for guaranteed transmission of
data. However, the UDP protocol is a best protocol to send data to the server when packet loss during
transmission of the data can be afforded. UDP protocol is a lightweight protocol and is suitable for wireless sensor
network communication. UDP is often used in applications specially tuned for real-time performance.
DCCP – Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. This
protocol is more secure than TCP protocol. Compared to TCP which has a single byte long ID for each packet, the
packet ID is 48-bit long (6-bytes) in DCCP. This makes it hard for any attacker to hack data packets. This protocol is
generally used for time critical data transfers like media streaming and VoIP.
SCTP – Stream Control Transmission Protocol (SCTP) protocol is a message oriented transport layer protocol and it
uses congestion control to reliably transfer data over a network. The data transferred along with a 12-byte header
is secured using 4-way handshake. Due to multi-homing, data is reliably sent to the destination.

The Session Layer

The Session Layer manages connection between two endpoints of a network by controlling data between sender
and receiver where session layer protocols are responsible for actual transmission of data in IoT ecosystem. That’s
why these Session Layer protocols are called as IoT Messaging Protocols or sometimes referred as IoT Data
Protocols. Most of IoT applications use TCP and UDP for transport and these messaging protocols can operate
over TCP or UDP.
There are different types of messaging protocols that are present by different standardization organizations and
depending upon their implementations they are used. Below are some of popular IoT Messaging protocols used in
IoT eco-system.

MQTT (Message Queue Telemetry Transport)

MQTT (Message Queue Telemetry Transport) is a messaging protocol which was introduced by IBM in 1999. It
was initially built for monitoring sensor node and faraway tracking in IoT. Its suits are small, cheap, low-memory
and low-power devices. MQTT provides embedded connectivity between applications and middleware in one side
and another side it connects networks and communicators.

MQTT protocol is based on publish/subscribe architecture. The publish/subscribe architecture consists of three
major components: publishers, subscribers, and a broker. According to IoT point of view, publishers are lightweight
sensor devices that send their data to connected broker and goes back to sleep whenever possible. Subscribers are
applications, which are interested in a certain topic or sensory data, so they are connected to brokers to be
informed whenever new data are received. The broker receives the sensory data and filters them in different
topics and sends them to subscribers according to interest in the topics.

CoAP (Constrained Application Protocol) is a session layer protocol that provides the RESTful (HTTP) interface
between HTTP client and server. It is designed by IETF Constrained RESTful Environment (CoRE) working group. It is
designed to use devices on the same constrained network between devices and general nodes on the Internet.
CoAP enables low-power sensors to use RESTful services while meeting their low power constraints. This protocol
is specially built for IoT systems primarily based on HTTP protocols.

This network is used within the limited network or in a constrained environment. The whole architecture of CoAP
consists of CoAP client, CoAP server, REST CoAP proxy, and REST internet.
The data is sent from CoAP clients (such as smartphones, RFID sensors, etc.) to the CoAP server and the same
message is routed to REST CoAP proxy. The REST CoAP proxy interacts outside the CoAP environment and uploads
the data over REST internet.

DDS (Data Distribution Service) is a middleware (sometimes called machine-to-machine (M2M)) communication
protocol. It is implemented by the Object Management Group (OMG) standard for the real-time system with high
speed and high-performance, scalable, dependable, and interoperable data exchange. This communication
protocol is based on a publish-subscribe pattern for sending and receiving data, events, and commands among the
nodes.

The DDS protocol has two main layers:

Data-Centric Publish-Subscribe (DCPS): This layer delivers the information to subscribers.

Data-Local Reconstruction Layer (DLRL): This layer provides an interface to DCPS functionalities, permitting the
sharing of distributed data amongst IoT enabled objects.

Advanced Message Queuing Protocol (AMQP) :

AMQP is an open standard session layer protocol useful for sending transnational messages that’s why mainly
used in financial industry. It runs over TCP (Transmission Control Protocol) or UDP (User Datagram Protocol)
which is nearly similar to that of MQTT. But only difference is that Broker(Dealer) contains Exchange and
Queues as a result it is focused on not losing messages. The exchange receives messages from publishers and
distributes them to respective queues. Different subscribers collect topic wise sensory data from respective
topic queues.

Secure Message Queue Telemetry Transport (SMQTT) :

SMQTT works as an extension to MQTT protocol. It is based on an encryption messaging mechanism that’s why
it provides a secure messaging standard. In this protocol, subscriber sends encrypted messages to all nodes and
nodes receive encrypted message and use message after decryption. The encryption and decryption activities
are carried out by using master key.

This protocol follows four main stages i.e., Setup, Encryption, Publish, Decryption.
1. In Setup, both publisher and subscriber register themselves near broker and get master keys.
2. In the Encryption stage, broker encrypts published message.
3. In the Published stage, broker gives encrypted data to subscribers.
4. In the Decryption stage which is last stage, data /message is decrypted by subscriber using that master
key.

HTTP

HTTP stands for Hyper Text Transfer Protocol

WWW is about communication between web clients and servers

Communication between client computers and web servers is done by sending HTTP Requests and receiving HTTP
Responses
The World Wide Web is about communication between web clients and web servers.

Clients are often browsers (Chrome, Edge, Safari), but they can be any type of program or device.

Servers are most often computers in the cloud.

HTTP Request / Response

Communication between clients and servers is done by requests and responses:

1. A client (a browser) sends an HTTP request to the web

2. A web server receives the request
3. The server runs an application to process the request
4. The server returns an HTTP response (output) to the browser
5. The client (the browser) receives the response

The HTTP Request Circle

A typical HTTP request / response circle:

1. The browser requests an HTML page. The server returns an HTML file.
2. The browser requests a style sheet. The server returns a CSS file.
3. The browser requests an JPG image. The server returns a JPG file.
4. The browser requests JavaScript code. The server returns a JS file
5. The browser requests data. The server returns data (in XML or JSON).