26 December 2015

A Study of IoT Protocols

- Raj Vignesh T. Navaneetha Krishnan

1. Introduction

IoT is where multiple devices that convey
some data are connected to each other over wired
or wireless communication infrastructure, so they
talk to each other and automate a process or task.
The working devices are called things in the IoT
context. These things are fundamentally a piece
of electronic hardware with ability to acquire and
communicate. Acquiring is connecting to sensors,
switches etc., and gathering data from them at
regular intervals. Communicating is sending the
acquired data/requesting data to/from another
device/server. The things employ standard
protocols for communication.

IoT architecture has three layers namely
D2D, D2S & S2S, however, it is not mandatory for
an IoT system to use all the three layers. Each
protocol oers services in one layer or more.

This article compares and contrasts the
popular communication protocols used for IoT,
namely HTTP, MQTT, CoAP, AMQP, XMPP and
DDS. It also discusses the relevance of each
protocol in achieving near-real time performances,
for time critical embedded IoT applications.

2. The Protocols
2.1 HTTP

HTTP is the simplest connectionless
protocol between clients and servers. The client
sends a request to the server in the form of a
request method or URI (more common in IoT) with
possibly a data and disconnects itself from the
server. On receiving the request, the server script
interprets it and sends a response to the client.
The requests and responses happen over TCP/IP.
However, delivery of requests/responses is not
guaranteed as the protocol does not support ACK.
There is no memory for HTTP, so it does not allow
clients and servers to remember each other or
relate one request with the other.

2.2 MQTT

Page 1 of 3

architecture, where a client could be a publisher or

subscriber and the broker manager data
forwarding and connections with them. A publisher
pushes data into a FIFO queue with the broker on
a specific topic and the subscribers of that topic
get the data. The broker retains details of the
clients even after disconnection and uses the same
on reconnection, so the clients so not have to
subscribe again on reconnection. Delivery
guarantee is ensured in three QoS namely Fire and
Forget, At Least Once and Exactly Once. The
protocol works on TCP/IP and does hardly
anything for D2D communication.

2.3 CoAP

CoAP a D2S protocol is usable when the things

are resource constrained in terms of program
memory and RAM. It works on UDP and hence
transceiving happens in the form of packets
between client and server. The discovery feature of
the protocol allows clients to discover resources
on the servers (what is called topic in MQTT) and
also the messaging formats. Observing feature of
the protocol lets servers send the current state of
the resource to a client at periodic intervals. All
communications between the client and server are
acknowledged. A request generated by a client
can be confirmable or non confirmable by the
server. The server confirms receipt of a request if it
i s a c o n fi r m a b l e re q u e s t . R e c o n n e c t i o n
mechanisms are not available at the protocol level,
but can be implemented at the application level.
CoAP can be dubbed to D2D by tweaking the
application layer.

2.4 AMQP

MQTT is a D2S protocol that gathers data from

multiple devices and pushes it to the servers. The
protocol is of publisher - broker - subscriber

AMQP is a very rugged protocol for transactional

message transaction between applications/servers
and naturally a S2S protocol. Its architecture is
www.rajvigneshtn.weebly.com

26 December 2015

identical to that of MQTT with a minor inclusion of

queue at the broker, so it can handle high speed
data transfer by buering in a queue. It operates
on TCP and specifies a mechanism by which the
connected applications/devices acknowledge
receipt of messages. It is also able to trace not
only the delivery of messages, but also whether it
has been delivered as intended, even across
device reboots and delivery failures. The
fundamental aim of the protocol is to deliver
messages without fail in a queue and nothing
much.

Page 2 of 3

architecture allows high speed data transfers.

Similar to MQTT and AMQP, DDS follows a
publisher-subscriber model and has additional
features like delivery filtering, delivery ensuring and
configurable QoS parameters (unique to DDS).

3. Real Time Performance Considerations

Real time performance is where a system expected
to receive inputs (messages) and delivers outputs
(messages) at stipulated time, failing which the
system will malfunction. For establishing a (near)
real time IoT, real time performances are expected
at the things level as well as at the protocol level.

2.5 XMPP
S2S >

< S2S

Server

Server

D2S

D2S

Things

Things

D2D

D2D

Things

XMPP also called Jabber is a D2S protocol that

connects one-to-one and one-to-many devices
(things) to servers. It uses e-mail like addressing to
deliver messages to servers. Unlike MQTT and
AMQP there is no central co ordinator like the
broker. The devices can get connected to the
constellation of things and servers from anywhere,
allowing portability of the things and connection
from anywhere. The protocol uses JID of a device
to deliver messages. JID is of the form
username@domain.com, where a user can have
multiple devices of unique priorities, addressable
as username@domain.com/priority. In case a
priority is not mentioned, the messages will be
delivered to all devices belonging to a user. Hence
such addressing is mostly done for broadcasting
configuration and presence identification.

2.6 DDS

DDS is a D2D protocol that oers high speeds data

transfer between the things, and is a software bus
for data transfer. There are provisions for
connecting the DDS bus to an IT infrastructure.
Things on a DDS bus are loosely coupled and have
no knowledge about each other. Unlike MQTT,
AMQP and XMPP, there is no central co ordinator
or server between the devices. This simplicity of

Things

Things

Things

3.1 RT Performance of Things

The Things are constrained pieces of
electronic hardware built around a micro processor
or micro controller, with or without an operating
system on it. While achieving real time
performance with micro controllers are not big deal
with the advent of RTOS and firmware SDKs, it is
certainly a challenge to achieve the same with a
processor based system running Linux. Although
RTLinux is available for use, its compatibility with
commercially available hardware SBCs is very
limited. The things are deprived of ample
resources like RAM, flash memory etc, to keep the
costs down, and hence it is not possible to have a
sophisticated OS demanding more processor time
and space running on it.

3.2 RT Performance of Communication Protocol

It is to be understood that in the best case,
an IoT deployment can involve just D2D
communication and in the worst case it may be as
complex as an assortment of D2D, D2S and S2S.
With this perception, it can be inferred that as the
things get separated by distance and as
distribution and filtering of messages become
complex, necessity of engaging more than one
protocol arises. Naturally RT performance of the
protocols is hindered because every protocol has
dierent QoS.

4. Relevance of IoT Protocols in Real Time IoT

From the briefs in section 2, it is seen that,

I. DDS can readily be employed for a simple IoT

deployment of connecting multiple devices, as
www.rajvigneshtn.weebly.com

26 December 2015

II.

III.

IV.
V.

it oers a simple, reliable and very high speed

communication between multiple devices on
the same network.

CoAP is a very thin implementation and its

nature makes it easily implementable on
humble micro controllers. With its confirmable
request feature and absence of internal retry
mechanisms make it a promising protocol next
to DDS for D2S communication. However, due
to absence of retry mechanisms, it cannot be
commissioned for very high speed transfers.

MQTT oers appreciable speed of data transfer

between devices and servers. However, due to
retry mechanisms, it also fails to be a real time
protocol. Yet, it stands next to DDS in this
context.

AMQP can be used for guaranteed delivery at

the cost of time. It leads to unpredictable
delivery/response time.

XMPP oers a very discrete and wide network

of things, but fails to oer real time
performance, because it does not know if a
publisher/subscriber is connected for not.
Messages could hop from one server to the
other, in search of the destination.

5. Conclusion

Elaborate study on the protocols briefed
above evince that real time performance of an IoT
constellation has to happen at all levels namely
devices (things), communication protocol, and
middleware (protocol converters). While achieving
RT performance at device level data acquisition is
pretty simple, as we move upwards the layers of
the IoT constellation, it becomes relatively harder
to maintain the same level of achievement. Though
DDS oers high speed reliable data transfers, the
RTness of the protocol is limited to few micro
seconds. When loss of RT operations is lost at
D2D level of operations itself, it is challenging to
expect it to happen at other higher levels.

However near real time performance
based on predicted delays can be implemented at
the application layer, so that delay/latency is
expected. With precisely predicted delays, a
combination of CoAP + AMQP can be used for low
speed data transfers and MQTT + AMQP can be
used for high speed data transfers. When there is
necessity for combining D2D and D2S
communication with expectation of (near) real time
performance, it is meritorious to avoid using DDS +
MQTT/AQMP/XMPP, because all D2S protocols
can handle D2D indirectly. Moreover, connecting
the devices to DDS bus deprives its instant access
to publishes, thereby reducing its relevance to real
time requirements.

Page 3 of 3

Abbreviations & Acronyms

IoT

Internet of Things

MQTT

Message Queue Telemetry Transport

HTTP

Hyper Text Transport Protocol

CoAP

Constrained Application Protocol

AMQP

Advanced Message Queuing Protocol

XMPP

Extensible Messaging & Presence

Protocol

DDS

Data Distribution Service

RT

Real Time

URI

Universal Resource Identifier

ACK

Acknowledgement

D2D

Device to Device

D2S

Device to Server

S2S

Server to Server

RAM

Random Access Memory

QoS

Quality of Service

RTOS

Real Time Operating System

SDK

Software Development Kit

SBC

Single Board Computer

www.rajvigneshtn.weebly.com