UNIT – II:

• IoT Protocols:
• Message Queuing Telemetry Transport (MQTT),
• Secure Message Queuing Telemetry Transport (SMQTT),
• Constrained Application Protocol (CoAP),
• Extensible Messaging and Presence Protocol (XMPP),
• Advanced Message Queuing Protocol (AMQP).
Functionality-based IoT Protocol Organization

 Connectivity (6LowPAN, RPL)

 Identification (EPC, uCode, IPv6, URIs)
 Communication / Transport (WiFi, Bluetooth, LPWAN)
 Discovery (Physical Web, mDNS, DNS-SD)
 Data Protocols (MQTT, CoAP, AMQP, Websocket, Node)
 Device Management (TR-069, OMA-DM)
 Semantic (JSON-LD, Web Thing Model)
 Multi‐layer Frameworks (Alljoyn, IoTivity, Weave, Homekit)

• Source: Internet of Things Protocols (Online)

Message Queue Telemetry Transport.
• Message Queue Telemetry Transport.

• ISO standard (ISO/IEC PRF 20922).

• MQTT was introduced by IBM in 1999 and standardized by OASIS in 2013.

• MQTT is a Client Server publish/subscribe messaging transport protocol.

• Designed for:
• Remote connections
• Limited bandwidth
• Small‐code footprint

• A message broker controls the publish‐subscribe messaging pattern.

• A topic to which a client is subscribed is updated in the form of messages and distributed by
the message broker.
• It is light weight, open, simple, and designed so as to be easy to implement.

• These characteristics make it ideal for use in many situations, including constrained environments
such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts
where a small code footprint is required and/or network bandwidth is at a premium.

• The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-
directional connections. Its features include:

• Use of the publish/subscribe message pattern which provides one-to-many message

distribution and decoupling of applications.
• A messaging transport that is agnostic to the content of the payload.
• Three qualities of service for message delivery:
• "At most once", where messages are delivered according to the best efforts of the operating
environment. Message loss can occur. This level could be used, for example, with ambient
sensor data where it does not matter if an individual reading is lost as the next one will be
published soon after.

• "At least once", where messages are assured to arrive but duplicates can occur.

• "Exactly once", where message are assured to arrive exactly once. This level could be used,
for example, with billing systems where duplicate or lost messages could lead to incorrect
charges being applied.

• A small transport overhead and protocol exchanges minimized to reduce network traffic.

• A mechanism to notify interested parties when an abnormal disconnection occurs.

MQTT Components

Publishers • Lightweight sensors

Subscribers • Applications interested in sensor data

Brokers • Connect publishers and subscribers

• Classify sensor data into topics

Source: “MQTT”, Wikipedia (Online)

Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)
Communic ation
 The protocol uses a publish/subscribe architecture (HTTP uses a
request/response paradigm).
 Publish/subscribe is event‐driven and enables messages to be
pushed to clients.
 The central communication point is the MQTT broker, which is in charge
of dispatching all messages between the senders and the rightful
receivers.
 Each client that publishes a message to the broker, includes a topic into
the message. The topic is the routing information for the broker.
Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)
  Each client that wants to receive messages subscribes to a certain topic
and the broker delivers all messages with the matching topic to the
client.

 Therefore the clients don’t have to know each other. They only
communicate over the topic.

 This architecture enables highly scalable solutions without

dependencies between the data producers and the data consumers.

Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)
MQTT Topics
 A topic is a simple string that can have more hierarchy levels, which are
separated by a slash.
 A sample topic for sending temperature data of the living room
could be house/living‐room/temperature.
 On one hand the client (e.g. mobile device) can subscribe to the exact
topic or on the other hand, it can use a wildcard.
Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)
  The subscription to house/+/temperature would result in all messages sent to the
previously mentioned topic house/living‐ room/temperature, as well as any topic
with an arbitrary value in the place of living room, such as
house/kitchen/temperature.
 The plus sign is a single level wild card and only allows arbitrary values for one
hierarchy.
 If more than one level needs to be subscribed, such as, the entire sub‐tree, there is
also a multilevel wildcard (#).
 It allows to subscribe to all underlying hierarchy levels.
 For example house/# is subscribing to all topics beginning with house.
Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)
MQTT Methods
Connect
Disconnect
Subscribe
Unsubscribe
Publish

Source: “MQTT”, Wikipedia (Online)

 Applic ations
 Facebook Messenger uses MQTT for online chat.
 Amazon Web Services use Amazon IoT with MQTT.
 Microsoft Azure IoT Hub uses MQTT as its main protocol for
telemetry messages.
 The EVRYTHNG IoT platform uses MQTT as an M2M protocol for
millions of connected products.
 Adafruit launched a free MQTT cloud service for IoT
experimenters called Adafruit IO.
SMQTT

 Secure MQTT is an extension of MQTT which uses encryption based

on lightweight attribute based encryption.
 The main advantage of using such encryption is the broadcast
encryption feature, in which one message is encrypted and delivered
to multiple other nodes, which is quite common in IoT applications.
 In general, the algorithm consists of four main stages: setup,
encryption, publish and decryption.
Source: M. Singh, M. Rajan, V. Shivraj, and P. Balamuralidhar, "Secure MQTT for Internet of Things (IoT)," in Fifth International Conference on Communication Systems
and Network Technologies (CSNT 2015), April 2015, pp. 746-751
 In the setup phase, the subscribers and publishers register themselves to
the broker and get a master secret key according to their developer’s
choice of key generation algorithm.
 When the data is published, it is encrypted and published by the broker
which sends it to the subscribers, which is finally decrypted at the
subscriber end having the same master secret key.
 The key generation and encryption algorithms are not standardized.
 SMQTT is proposed only to enhance MQTT security features.

Source: M. Singh, M. Rajan, V. Shivraj, and P.Balamuralidhar, "Secure MQTT for Internet of Things (IoT)," in Fifth International Conference on
Communication Systems and Network Technologies (CSNT 2015), April 2015, pp. 746-751
The process of message transfer and receiving consists of four major stages:
 Setup: In this phase, the publishers and subscribers register themselves to the
broker and get a secret master key.
 Encryption: When the data is published to broker, it is encrypted by broker.

 Publish: The broker publishes the encrypted message to the subscribers.

 Decryption: Finally the received message is decrypted by subscribers with the

same master key.
 SMQTT is proposed only to enhance MQTT security feature.
• Data of connected devices routes over the web in two types of communication
environments.
Constrained RESTful Environment (CoRE):
 IoT devices or M2M devices communicate between themselves in a Local Area Network.
 A device typically sends or receives 10s of bytes.
 The data gathered after enriching and consolidating from a number of devices consists of
100s of bytes.
A gateway in the communication framework enables the data of networked devices that
communicate over the Internet using the REST software architecture.

Unconstrained Environment:
 Web applications use HTTP and RESTful HTTP for web client and web server
communication.
 A web object consists of 1000s of bytes. Data routes over IP networks for the Internet.
 Web applications and services use the IP and TCP protocols for Internet network and
transport layers.
CoAP
Introduction
 CoAP – Constrained Application Protocol.
 The protocol was designed by the Internet Engineering Task Force
(IETF),
 CoAP is specified in IETF RFC 7252.
 Web transfer protocol for use with constrained nodes and
networks.
 Designed for Machine to Machine (M2M) applications such as
smart energy and building automation.
 Based on Request‐Response model between end-points
 Client-Server interaction is asynchronous over a datagram
oriented transport protocol such as UDP

Source: Z. Shelby , K. Hartke, C. Bormann, “The Constrained Application Protocol (CoAP)”, Internet Engineering Task Force (IETF), Standards Track,
2014
 CoAP Position
Application

Request
CoAP
Messages

UDP

Source: Z. Shelby , K. Hartke, C. Bormann, “The Constrained Application Protocol (CoAP)”, Internet Engineering Task Force (IETF), Standards Track,
2014

Introduction to Internet ofThings

 The Constrained Application Protocol (CoAP) is a session
layer protocol designed by IETF Constrained RESTful
Environment (CoRE) working group to provide lightweight
RESTful (HTTP) interface.

 Representational State Transfer (REST) is the

standard interface between HTTP client and
servers.

 Lightweight applications such as those in IoT, could result

in significant overhead and power consumption by REST.

 CoAP is designed to enable low-power sensors to use

RESTful services while meeting their power constraints.
 Built over UDP, instead of TCP (which is commonly used with HTTP)
and has a light mechanism to provide reliability.

 CoAP architecture is divided into two main sub-layers:

 Messaging
 Request/response.

 The messaging sub-layer is responsible for reliability and duplication

of messages, while the request/response sub-layer is responsible
for communication.

 CoAP has four messages CON,NON,ACK,RST.

Source: V. Karagiannis, P.Chatzimisios, F. Vazquez-Gallego, and J. Alonso-Zarate, "A survey on application layer protocols for the internet of
things," Transaction on IoT and Cloud Computing, vol. 3, no. 1, pp. 11-17, 2015
CoAP Message Types
Confirmable

Non-Confirmable

Piggyback

Separate

Source: Z. Shelby , K. Hartke, C. Bormann, “The Constrained Application Protocol (CoAP)”, Internet Engineering Task Force (IETF), Standards Track,
2014
 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.
CoAP Request-Response Model

Source: V. Karagiannis, P.Chatzimisios, F. Vazquez-Gallego, and J. Alonso-Zarate, "A survey on application layer protocols for the internet of
things," Transaction on IoT and Cloud Computing, vol. 3, no. 1, pp. 11-17, 2015
CoAP Request-Response Model

Source: V. Karagiannis, P.Chatzimisios, F. Vazquez-Gallego, and J. Alonso-Zarate, "A survey on application layer protocols for the internet of
things," Transaction on IoT and Cloud Computing, vol. 3, no. 1, pp. 11-17, 2015
Features
 Reduced overheads and parsing complexity.
 URL and content-type support.
 Support for the discovery of resources provided by known
CoAP services.
 Simple subscription for a resource, and resulting push
notifications.
 Simple caching based on maximum message age.
Source: ”Constrained Application Protocol”, Wikipedia (Online)
XMPP
• XMPP was created by jabber 1999 and acquired by CISCO
in 2008
• XMPP is an XML-based specification for messaging and
presence protocols.
• XMPP is also an open-source protocol recommended
specification which is accepted by IETF.
• RFC is an international organisation and stands for
’Recommended for Comments’.
• RFC 6120 document specifies the XMPP for CoRE.
• RFC 6121 XMPP specifies the instant messaging (IM) and
presence, and RFC 6122 XMPP specifies the (message)
address format.
XMPP is a short form for Extensible Messaging Presence Protocol. It’s protocol for streaming XML
elements over a network in order to exchange messages and presence information in close to real
time. This protocol is mostly used by instant messaging applications like WhatsApp.

Each character of word XMPP:

•X : It means eXtensible. XMPP is a open source project which can be changed or extended
according to the need.
•M : XMPP is designed for sending messages in real time. It has very efficient push mechanism
compared to other protocols.
•P : It determines whether you are online/offline/busy. It indicates the state.
•P : XMPP is a protocol, that is, a set of standards that allow systems to communicate with each other.
  XMPP – Extensible Messaging and Presence Protocol.

 A communication protocol for message‐oriented middleware

based on XML (Extensible Markup Language).

 Real-time exchange of structured data.

 It is an open standard protocol.

Source: “XMPP”, Wikipedia (Online)

XML messages are for a temperature sensor. Assume that more than
one sensor measures the temperature and put time of measurement
stamp also.

An XML message sent by a temperature sensor is as follows:

<SensTemp> 22 degree C </SensTemp>.
<SensTemp> can associate with the attributes as:
<SensorTemp ID = ‘250715’ TimeDate = ‘19:28:33 Jul 17 2016’> 22 </SensTemp>.

A Java parser can read the file when it streams and in which the above text message is
present.
That parser creates a database.
The database may be a table with the columns: Sensor ID, Time, Date and Temperature.
An associated program (application) uses these results.

For example, application sends a message for an actuator circuit to switch off Air Conditioner,
again in XML.
The message format from the Application with ID = 241206 to Air conditioner of ID = 2075 can
be:
  XMPP uses a client‐server architecture.

 As the model is decentralized, no central server is required.

 XMPP provides for the discovery of services residing locally or across a network, and
the availability information of these services.

 Well-suited for cloud computing where virtual machines, networks, and firewalls
would otherwise present obstacles to alternative service discovery and presence-based
solutions.

 Open means to support machine-to-machine or peer-to-peer communications across a

diverse set of networks.
Source: “XMPP”, Wikipedia (Online)
 XMPP is extensible—XSF (XMPP standards foundation) develops and publishes the xeps
(XMPP extension protocols).

 The xeps enable the addition of features and new applications.

 XMPP-IoT xeps extend the use of XMPP to IoT and machine-to-machine messaging.

 List of extensions (xeps) is quite long. Examples of xeps are:

● xep-0322 efficient XML interchange (EXI) format
●xep-0323 Internet of Things-Sensor Data (http://xmpp.org/extensions/xep-0323.html)
● xep-0324 Internet of Things-Provisioning
● xep-0325 Internet of Things-Control (http://xmpp.org/extensions/xep-0325.html)
● xep-0326 Internet of Things-Concentrators.

 The xeps are the base for IEEE/ISO/IEC recommended “Sensei/IoT” related standards,
sensei/IoT ISO/IEC/IEEE P21451-1-4 and other standardizations.
 XMPP-IoT enables communication machine to web application and M2M
interoperable.

 Many connected-devices-based business applications, processes, smart home, smart

city,
 smart energy saving and smart street lighting and traffic are possible using XMPP,
XMPPIoT and other servers communicating with XMPP servers.

 Figure shows use of the XMPP and XMPP extension protocols for connected devices
 and web objects.
 The protocols are for messaging, presence notification, response-on demand and
service discovery using XML streams.

 XMPP-IoT server consists of xeps and services.

 XMPP services are extensible to publisher/subscriber, MUC and other services, devices
and connected devices area network which interact with XMPP-IoT services.

 The XMPP-IoT server, through a gateway between connected devices and IP networks,
communicates with XMPP APIs in web objects.
Features of XMPP are:
 XMPP uses XML.
 XML elements are sent in the open-ended stream within the tag <stream> and
corresponding end tag </stream>.

 Three basic types of XMPP stanzas (elements) are:

❍ message
❍ presence
❍ iq (information/query, request/response)

 Extensibility to constrained environment messaging and presence protocols as well as

IP network messaging.

 Extensibility of request-response (client-server) architecture to iq (information

through querying), PubSub messaging, Chat room MUC messaging and other
architecture (where group of people exchange information when present in a chat
room), decentralised XMPP server.
Highlights
 Decentralization – No central server; anyone can run their
own XMPP server.
 Open standards – No royalties or granted permissions are
required to implement these specifications
 Security – Authentication, encryption, etc.
 Flexibility – Supports interoperability

Source: “XMPP”, Wikipedia (Online)

The XMPP network uses a client–server architecture (clients
do not talk directly to one another).

However, it is decentralized—by design, there is no central

authoritative server, as there is with services such as AOL
Instant Messenger or Windows Live Messenger.

Clients send and receive messages only to and from their

respective server and it is the server's responsibility to route
appropriately-addressed messages through the network to
the intended user. For this purpose, every user on the
network has a unique Jabber ID (usually abbreviated
as JID ).

To avoid requiring a central server to maintain a list of IDs,

the JID is structured like an email address with a username
and a domain name for the server where that user resides,
separated by an at sign (@), such as
[email protected].

Source: “JabberNetwork.svg”, Wikimedia Commons (Online)

Core XMPP Technologies
Core
• information about the core XMPP technologies for XML streaming

Jingle
• multimedia signalling for voice, video, file transfer

Multi‐user Chat
• flexible, multi-party communication

PubSub
• alerts and notifications for data syndication

BOSH
• HTTP binding for XMPP
Source: “XMPP: Technology Overview”, XMPP.org (Online)
Weaknesses
 Does not support QoS.

 Text based communications induces higher network overheads.

 Binary data must be first encoded to base64 before transmission.

18
Applic ations
 Publish-subscribe systems
 Signaling for VoIP
 Video
 File transfer
 Gaming
 Internet of Things applications
 Smart grid
 Social networking services

Introduction to Internet ofThings 19

AMQP
Introduction
 Advanced Message Queuing Protocol.
 Open standard for passing business messages between
applications or organizations.
 Connects between systems and business processes.
 It is a binary application layer protocol.
 Basic unit of data is a frame.
 ISO standard: ISO/IEC 19464
Source: “Advanced Message Queuing Protocol”, Wikipedia (Online)
AMQP
Features

Organizations Technologies Time Space

Connects across
Features
Security
Reliability
Interoperability
Routing
Queuing

Open standard

Introduction to Internet ofThings 6

Message Delivery Guarantees

 At‐most‐once
 each message is delivered once or never
 At‐least‐once
 each message is certain to be delivered, but may do so multiple times
 Exactly‐once
 message will always certainly arrive and do so only once

Reference: "OASIS AMQP version 1.0, sections 2.6.12-2.6.13". OASIS AMQP Technical Committee

Introduction to Internet ofThings 7

AMQP Frame Types
 Nine AMQP frame types are defined that are used to initiate, control and
tear down the transfer of messages between two peers:
 Open (connection open)
 Begin (session open)
 Attach (initiate new link)
 Transfer (for sending actual messages)
 Flow (controls message flow rate)
 Disposition (Informs the changes in state of transfer)
 Detach (terminate the link)
 End (session close)
 Close (connection close)
Source: O.S. Tezer, “An advanced messaging queuing protocol walkthrough ”, DigitalOcean (Online), 2013

Introduction to Internet ofThings 8

Components
Publisher •Client app create Messages
•Which are Given to the Broker

Exchange •Part of Broker

•Message Contain Routing key
•Receives messages and routes them to Queues

Queue •Separate queues for separate business processes

•Consumers receive messages from queues

Bindings •Rules for distributing messages (who can access

what message, destination of the message)

Publisher
Subscriber •Client apps Subscribe messages form broker

9
•It’s a message attribute

Routing key •The exchange look at this key to route the

message to the queue
AMQP Exchanges
Direct
Fan‐out
Topic
Header
Source: O.S. Tezer, “An advanced messaging queuing protocol walkthrough ”, DigitalOcean (Online), 2013

Introduction to Internet ofThings 10

https://www.youtube.com/watch?v=wPnrb0KjTFU&ab_channel=kanishkadas
AMQP Features
 Targeted QoS (Selectively offering QoS to links)
 Persistence (Message delivery guarantees)
 Delivery of messages to multiple consumers
 Possibility of ensuring multiple consumption
 Possibility of preventing multiple consumption
 High speed protocol
Source: O.S. Tezer, “An advanced messaging queuing protocol walkthrough ”, DigitalOcean (Online), 2013

Introduction to Internet ofThings 11

Applic ations
 Monitoring and global update sharing.
 Connecting different systems and processes to talk to each other.
 Allowing servers to respond to immediate requests quickly and
delegate time consuming tasks for later processing.
 Distributing a message to multiple recipients for consumption.
 Enabling offline clients to fetch data at a later time.
 Introducing fully asynchronous functionality for systems.
 Increasing reliability and uptime of application deployments.
Source: O.S. Tezer, “An advanced messaging queuing protocol walkthrough ”, DigitalOcean (Online), 2013

Introduction to Internet ofThings 12