Study of IoT Protocols

Contents

1 Introduction 3

2 IoT Protocols 3
2.1 Constrained Application Protoco (COAP) . . . . . . . . . . . . . . . . . . 4
2.1.1 Implementation of COAP . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Message Queuing Telemetry Transport (MQTT) . . . . . . . . . . . . . . . 11
2.2.1 Implementation of MQTT . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 AMQP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Comparison Chart of IoT Protocols 25

4 Course Conclusion 25
List of Figures
1 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 COAP Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 COAP Request Response Model . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Start Cooja Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Create Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 Add New Mote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7 View Option for Mote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8 Node Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9 Connect Bridge between two networks . . . . . . . . . . . . . . . . . . . . 9
10 Data Transfer between Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 10
11 COAP GUI to handle devices remotely . . . . . . . . . . . . . . . . . . . . 10
12 Control LED on mote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
13 Control LED on mote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
14 MQTT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
15 Node Red GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
16 Node Setup for MQTT Publisher . . . . . . . . . . . . . . . . . . . . . . . 16
17 Edit MQTT Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
18 Edit Inject Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
19 MQTT Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
20 MQTT - Read the message from GUI . . . . . . . . . . . . . . . . . . . . . 18
21 MyMQTT - Setting Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
22 MyMQTT - Subscribe Topic . . . . . . . . . . . . . . . . . . . . . . . . . . 19
23 MyMQTT - Notication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
24 AMQP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
25 6LowPAN Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
26 Comparison between Data Protocols . . . . . . . . . . . . . . . . . . . . . 25
27 Comparison between Data Protocols . . . . . . . . . . . . . . . . . . . . . 26

2
1. Introduction
Embedding certain electronics such as sensors and controller boards to the everyday
things around us, enabling them to communicate with each other and with the servers
on cloud using wireless communication technologies such as WIFI, ZigBee, and Bluetooth
etc. is what creates Internet of Things, as mentioned in Fig. 1. These everyday physical
things around us are uniquely identied when in IoT Architecture.
The Internet of Things (IoT) extends from a single constrained device to a whole range of

Figure 1: Internet of Things

cloud systems, all connected by a set of IoT protocols that allow devices and servers to talk
to one another. The term ‘Internet of Things’ consists of two words – Internet
and things. The term ‘Things’ refers to various IoT devices with unique identities,
which have the capabilities to perform remote sensing, actuating and live monitoring of
certain sorts of data. IoT devices are also enabled for the live exchange of data with
other connected devices and applications, either directly or indirectly, or collecting data
from other devices, processing it and sending it to various servers. The other term,
‘Internet’, is dened as a global communication network connecting trillions of
computers across the planet, enabling the sharing of information.

2. IoT Protocols
IEEE (Institute of Electrical and Electronics Engineers) and ETSI (European Telecom-
munications Standards Institute) have dened some of the most important IoT protocols.

3
All the protocols have their own signicance. The protocols are classied based on their
functionalities as mentioned below.

• Connectivity (6LoWPAN, RPL)

• Identication (EPC, uCode, IPV6, URIs)
• Communication/Transport (WiFi, Bluetooth, LPWAN)
• Discovery(Physical Web, mDNS, DNS-SB)
• Data Protocols (MQTT, COAP, AMQP, XMPP)
• Device Management(TR-069, OMA-DM)
• Semantic(JSON-LD, Web Thing Model)
• Multi-layer Frameworks(Alljoyn, IoTivity, Weave, Homekit) 

we are going to discuss the most important and frequently used protocols in detail.

2.1. Constrained Application Protoco (COAP)

This was created by the IETF Constrained RESTful Environments (CoRE) working
group. CoAP is an Internet application protocol for constrained devices. It is designed to
be used between devices on the same constrained network, between devices and general
nodes on the Internet, and between devices on dierent constrained networks—both
joined on the Internet. This protocol is especially designed for IoT systems based on
HTTP protocols.
CoAP makes use of the UDP protocol for lightweight implementation. It also makes
use of RESTful architecture, which is very similar to the HTTP protocol. It is used
within mobiles and social network based applications and eliminates ambiguity by using
the HTTP get, post, put and delete methods. Apart from communicating IoT data, CoAP
has been developed along with DTLS for the secure exchange of messages. It uses DTLS
for the secure transfer of data in the transport layer.It makes use of dtls for the cozy
switch of statistics within the slipping layer [1]. COAP stack is shown in Fig.2. CoAP
provides a request/response interaction model between application endpoints, supports
built-in discovery of services and resources, and includes key concepts of the Web such
as URIs and Internet media types. CoAP is designed to easily interface with HTTP

4
for integration with the Web while meeting specialized requirements such as multicast
support, very low overhead, and simplicity for constrained environments.
The main features of CoAP protocols are:

• Web protocol used in M2M with constrained requirements

• Asynchronous message exchange

• Low overhead and very simple to parse

• URI and content-type support

• Proxy and caching capabilities

Some features are very similar to HTTP even if CoAP must not be considered a
compressed HTTP protocol because CoAP is specically designed for IoT and in more
details for M2M so it is very optimized for this task.

Figure 2: COAP Stack

There are two dierent layers that make CoAP protocol: Messages and Re-
quest/Response. The Request-Response model for this protocol is shown in Fig. 3. The
Messages layer deals with UDP and with asynchronous messages. The Request/Response
layer manages request/response interaction based on request/response messages.
CoAP supports four dierent message types:

• Conrmable

• Non-conrmable

• Acknowledgment

5
 Figure 3: COAP Request Response Model

• Reset

A conrmable message is a reliable message. When exchanging messages between two

endpoints, these messages can be reliable. In CoAP, a reliable message is obtained using
a Conrmable message (CON). Using this kind of message, the client can be sure that
the message will arrive at the server. A Conrmable message is sent again and again
until the other party sends an acknowledge message (ACK). The ACK message contains
the same ID of the conrmable message (CON).

2.1.1. Implementation of COAP

We are going to perform COAP using Contiki and Cooja. Instant Contiki is an entire
Contiki development environment in a single download. It is an Ubuntu Linux virtual
machine that runs in VMWare player and has Contiki and all the development tools,
compilers, and simulators used in Contiki development installed. Instant Contiki is so
convenient that even hardcore Contiki developers use it.
Cooja is the Contiki network simulator. Cooja allows large and small networks of Contiki
motes to be simulated. Motes can be emulated at the hardware level, which is slower but
allows precise inspection of the system behavior, or at a less detailed level, which is faster
and allows simulation of larger networks. We are performing the practical in windows
system by installing VMware Player. Also we require instant contiki, you can download
it from here. Follow below mentioned steps to demonstrate the COAP in cooja.

• After successfully installing instant contiki in VMware player, open the terminal
and execute the commands to start cooja. Once you are in cooja directory (contiki-
2.7/tools/cooja) execute the command "ant run", will start your cooja simulator.
See g.4.

6
 Figure 4: Start Cooja Simulator

• In cooja simulator create new simulator using the menu. See g. 5.

Figure 5: Create Simulation

• It will create new simulator and number of panels will be displayed like Network,
simulation control, Notes, Mote Output, Radio messages etc..

• Click on 'Motes'. From the drop down menu select 'Add New Motes' followed by
'Create new motes' and select the mote type as 'Sky'. See g. 6.

7
 Figure 6: Add New Mote

• Browse to the location '/contiki-2.7/examples/ipv6/rpl-border-router' and select the

le rpl-border-router.c. Click on 'Create'. Add one mote of this type.

• Select the options under View as shown in g. 7. These will help you creating a
topology of your choice. The colors of around the node indicates the radio coverage.
Green indicates good radio coverage while grey indicates poor radio coverage.

Figure 7: View Option for Mote

• Now to create another network repeat the process of creating the motes. But this
time add 2 motes and browse the location '/contiki-2.7/examples/er-rest-example/
and select er-example-server.c.

• Arrange the node position in such a way that packet from node 1 transfers to node
3 via node 2 as shown in g. 8

8
 Figure 8: Node Position

• Now, we need to create a bridge between the RPL network simulated on Cooja
and the other network. This can be done by right clicking on the mote which is
programmed as the border router. Select 'More tools for border router' and then
select 'Serial Socket (SERVER)'. You will get the following message on the successful
completion of this step.Note that the message says 'Listening on port 60001'.

• To provide bridge you need to connect router to the other network. Open the
terminal and nevigate to the '/contiki-2.7/examples/ipv6/rpl-border-router'.

• Execute the command 'make connect-router-cooja' as shown in g. 9.

Figure 9: Connect Bridge between two networks

• Go back to the Cooja simulator GUI and look at the dialogue box. The message
has now changed to 'Client connected: /127.0.0.1'

• Click on start button in simulation network panel. you can see the simulation as
shown in g. 10.

9
 Figure 10: Data Transfer between Nodes

• Open any browser any type ip address of any node. ( Ip address of any node can
be seen using the view menu).

• Pick IP address of any node and in browser type

coap://. [IP _ADRESS _OF _N ODE] . refer g. 11.

Figure 11: COAP GUI to handle devices remotely

By accessing the IP address remotely you can control the nodes. Now to check it lets
display the LED at a particular node. As shown in g. 12, right click mote2 and click
the option which says "show LED on sky2".
Now from the browser (COAP GUI) in the outgoing panel type 1 and click on the post
method. The LED at mote2 will be blown and when you send 0 it will be o. see
g. 13. This way we can control our devices remotely.This will be very handy in

10
 Figure 12: Control LED on mote

Figure 13: Control LED on mote

many applications. For example for the doctor, a patient who is just discharged from
the hospital. At home patient with all the equipments and by using any application or
any browser doctor can get all the data and act wisely. Smart home network provide
controlling and monitoring energy of home devices. Energy control systems employ smart
socket management and monitor power consuming equipment to provide voltage, current
and other energy information. It could realize accident warning, remote control and
dynamic energy saving. Every data collection node with CoAP client could exchange
information with other nodes. CoAP could both be installed in LAN or Internet. Unlike
Many wireless protocols for home automotive devices, CoAP is designed not constrained
in a local network but provide the fundamental basis of the web. In this system, CoAP-
HTTP proxies are employed to provide HTTP client connection to CoAP resources and
vice versa.

2.2. Message Queuing Telemetry Transport (MQTT)

MQTT (Message Queuing Telemetry Transport) protocol is a Machine to Machine

(M2M) protocol widely used in Internet of things. The MQTT protocol is a message
based protocol, extremely light-weight and for this reason, it is adopted in IoT ecosys-
tem. It’s far normally used for faraway tracking in IoT. Its primary challenge is to
gather statistics from many gadgets and delivery of its infrastructure. MQTT connects
gadgets and networks with packages and middleware. A hub-and-spoke structure is herbal

11
for MQTT. All the devices hook up with facts concentrator servers like IBM’s new
message sight appliance. MQTT protocols paintings on top of TCP to oer easy and
dependable streams of information [1]. Almost all IoT platforms support MQTT proto-
col to send and receive data from smart objects. There are several implementations for
dierent IoT boards like Arduino, Raspberry and so on.
This protocol used publish-subscriber paradigm in contrast to HTTP based on re-
quest/response paradigm. It uses binary messages to exchange information with a low
overhead. It is very simple to implement and it is open. All these aspects contribute to
its large adoption in IoT. Another interesting aspect is the fact that MQTT uses TCP
stack as transmission substrate. MQTT architecture is shown in Fig. 14.

Figure 14: MQTT Architecture

MQTT Message pattern

As said before, MQTT protocol implements publish-subscriber paradigm. This paradigm
decouples a client that publishes a message ("publisher") to other clients that receive the
message ("subscribers"). Moreover, MQTT is asynchronous protocol, that means that it
does not block the client while it waits for the message. In contrast to HTTP protocol,
that is mainly asynchronous protocol. Another interesting property of MQTT protocol
is that it does not require that the client ("subscriber") and the publisher are connected
at the same time.
MQTT Publisher-subscriber pattern (MQTT Broker, MQTT Client) As
described above MQTT is a message based protocol that uses publisher-subscriber

12
pattern. The key component in MQTT is the MQTT broker. The main task of MQTT
broker is dispatching messages to the MQTT clients ("subscribers"). In other words, the
MQTT broker receives messages from publisher and dispatches these messages to the
subscribers. While it dispatches messages, the MQTT broker uses the topic to lter the
MQTT clients that will receive the message. The topic is a string and it is possible to
combine the topics creating topic levels.
Information is organized in a hierarchy of topics. When a publisher has a new item of
data to distribute, it sends a control message with the data to the connected broker. The
broker then distributes the information to any clients that have subscribed to that topic.
The publisher does not need to have any data on the number or locations of subscribers,
and subscribers in turn do not have to be congured with any data about the publishers.

If a broker receives a topic for which there are no current subscribers, it will discard
the topic unless the publisher indicates that the topic is to be retained. This allows new
subscribers to a topic to receive the most current value rather than waiting for the next
update from a publisher.
When a publishing client rst connects to the broker, it can set up a default message
to be sent to subscribers if the broker detects that the publishing client has unexpectedly
disconnected from the broker.
Clients only interact with a broker, but a system may contain several broker servers
that exchange data based on their current subscribers' topics.
A minimal MQTT control message can be as little as two bytes of data. A control
message can carry nearly 256 megabytes of data if needed. There are fourteen dened
message types used to connect and disconnect a client from a broker, to publish data, to
acknowledge receipt of data, and to supervise the connection between client and server.
MQTT relies on the TCP protocol for data transmission. A variant, MQTT-SN, is
used over other transports such as UDP or Bluetooth.
MQTT sends connection credentials in plain text format and does not include any
measures for security or authentication. This can be provided by the underlying TCP
transport using measures to protect the integrity of transferred information from inter-
ception or duplication.
A topic is a virtual channel that connects a publisher to its subscribers. MQTT broker

13
manages this topic. Through this virtual channel, the publisher is decoupled from the sub-
scribers and the MQTT clients (publishers or subscribers) do not have to know each other
to exchange data. This makes this protocol highly scalable without a direct dependency
from the message producer ("publisher") and the message consumer (“subscriber”).
There are various application in which the MQTT protocol is being used. Some of
them are lsited below.

• 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.

2.2.1. Implementation of MQTT

This practical is based on the MQTT node, which provides a convenient way to take
input from an MQTT broker. It is an example of a publish/subscribe system (usually
shortened to pub/sub system) which lets sensors publish updates that are delivered to
clients subscribed to that sensor. MQTT uses a topic model allowing publishers (e.g.
sensors) to create topics and publish data to the topics. Equally, others can subscribe to
a topic and will receive asynchronous notication of data posted to the topic.
Pub/Sub systems are a great way to connect loosely coupled distributed systems and
they map well to typical IoT patterns where devices or things generate events that you
want to share. The MQTT protocol, apart from being asynchronous, is also lightweight
and doesn’t have as high an overhead as HTTP; which for resource-constrained
devices is often an important advantage.
We are going to implement MQTT using node red and also using MyMQTT(Android
Application) to demonstrate basic publish subscribe model.
Follow the below mentioned steps to install node red in your system (Windows).

14
 1. Download NodeJS by clicking here

2. Complete the installation process.

3. After Installation open command prompt and execute the commands : node -h and
npm -h

4. To install Node Red execute the command : npm -g install node-red

5. Once you are done with installation execute the command : node-red -v. It will
start node-red server in your system. You can use the server ip address in any
browser to view the GUI of node red. Probably the IP address of node red server is
http://127.0.01:1880. See the Figure. 15.

Figure 15: Node Red GUI

Now you can use the input and output nodes by dragging them into the ow screen and
congure them. We are going to use MQTT publisher node and subscriber node at the
rst level. To use the mqtt node, you need to have access to a broker. There are a
number of free MQTT servers running, for example http://test.mosquitto.org/, or the
one that will be used in this lecture, www.hivemq.com. Using the broker address and the
topic, you can congure the mqtt input node to subscribe on that topic, causing it to
generate a new message whenever new data is published on that topic. The message will
contain information on the published data, including the data itself in msg.payload and
the MQTT broker topic in msg.topic.

15
 To get you started with the mqtt node, you’ll be using the free mqqt broker hivemq
– which is available via (http://www.hivemq.com/showcase/public-mqtt-broker/). Of
course you can use any MQTT broker, including your own, if you have installed one.

1. To setup publisher, kindly drag inject node from the INPUT panel and MQTT
(publisher) from the OUTPUT panel. And provide connection from inject node to
MQTT publisher. See Fig. 16

Figure 16: Node Setup for MQTT Publisher

2. To congure MQTT node, double click on the node. It will open the conguration
window. In the server (Broker) eld you can give any free broker or your broker
address (if you have installed any).

3. As you know the model uses topic to broadcast and receive, you have to mentioned
the topic name in the topic eld. See g. 17. Then you are required to click on the
DEPLOY button (Top Right corner).

4. Edit inject node (double click on the node). For now change the Inject Payload to
string from TimeStamp. See Fig. 18. Also assign any message to the payload which
you want to broadcast and the topic name as well. After this we are done with our
publisher part. Keep in mind whenever you change any conguration of any node
you are required to deploy it by clicking the deploy button.

Now we will implement MQTT subscriber. We are doing it in two ways, rst in the
GUI only and using the MyMQTT android application which is available in Google Play
Store. We will create subscriber in the GUI as well as in an android application.

16
 Figure 17: Edit MQTT Node

Figure 18: Edit Inject Node

1. For GUI take two nodes namely MQTT Subscriber and debug (MSG PAY-
LOAD).Congure the MQTT node in the same way by giving the broker address
and topic name.

2. Connect the two nodes. See g. 19.

3. Deploy it.

4. When you click the left button on inject node that message will be broadcasted to
all the subscriber who has subscribed the specic topic. (research in our example).

5. You can view the message in the GUI by clicking the debug option below deploy
button. See g. 20.

Now we are going to subscribe the topic using MyMQTT (android application).

17
 Figure 19: MQTT Subscriber

Figure 20: MQTT - Read the message from GUI

1. Download MyMQTT application from google play store.

2. In the setting menu of the application enter the broker address and leave all other
elds as it is. See g. 21.

3. From the subscriber tab you can add the name of the topics for which you want to
subscribe. See g. 22.

4. Now whenever from your node red the inject button will be triggered you will receive
the notication in your application. See g.23.

5. The same way you can publish the message for the other subscriber from the publish
screen in the application.

MQTT Protocol, due to its working based on the Publisher Subscriber Model, can be

18
 Figure 21: MyMQTT - Setting Screen

Figure 22: MyMQTT - Subscribe Topic

Figure 23: MyMQTT - Notication

used for a wide range of applications. Some of such applications are: Weather Updates
(In this application, all the people who have subscribed to the service supplying weather

19
information sensed by an IoT Architecture will receive a notication about the same
at a pre-set Interval), Animal Tracking Application in Wild Life Sanctuaries, Reserved
Forest Areas and National Parks (In this application, Animal Location Updates are sent
to the guides' or forest ocers' devices if subscribed for the service), IoT based Public
Transport Vehicle Tracking System (In this application, the passengers who travel by
public transport vehicles receive notications about the vehicle's location if subscribed
for the service).

2.3. AMQP

The Advanced Message Queuing Protocol (AMQP) is an open standard for passing
business messages between applications or organizations. It connects systems, feeds
business processes with the information they need and reliably transmits onward the
instructions that achieve their goals.
It is an Open standard for passing business messages between applications or
organizations as shown in Fig. 24. It Connects between systems and business processes.It
is a binary application layer protocol.In AMQP basic unit of data is a frame. Every
protocol, related to IoT or more precisely wireless sensor network has its own signicance
which means applicability of that particular protocol purely depends on application.
Key Capabilities of AMQP :

Figure 24: AMQP

• Organization : applications in dierent organizations

• Technology : applications in dierent platforms
20
 • Time : systems don’t need to be available simultaneously
• Space : reliably operate at a distance, or over poor networks
The key features of AMQP are namely : Security, Reliability, Interoperability, Standard
and Open.The capable, commoditized, multi-vendor communications ecosystem which
AMQP enables creates opportunities for commerce and innovation which can transform
the way business is done on the Internet, and in the Cloud.

Appliations of AMQP :

1. Monitoring and global update sharing

2. Connecting dierent systems and processes to talk to each other.

3. Allowing servers to respond to immediate requests quickly and delegate time con-
suming tasks for later processing.

4. Distributing a message to multiple recipients for consumption.

5. Enabling oine clients to fetch data at a later time.

6. Introducing fully asynchronous functionality for systems.

7. Increasing reliability and uptime of application deployments.

2.4. XMPP

XMPP is the Extensible Messaging and Presence Protocol, a set of open technologies
for instant messaging, presence, multi-party chat, voice and video calls, collaboration,
lightweight middleware, content syndication, and generalized routing of XML data.
XMPP was originally developed in the Jabber open-source community to provide an
open, decentralized alternative to the closed instant messaging services at that time.
XMPP oers several key advantages over such services namely open,standard, proven,
decentralized, secure, extensible, exible and diverse.
Key Technologies of XMPP

• Core : information about the core XMPP technologies for XML streaming
21
 • Jingle : SIP-compatible multimedia signalling for voice, video, le transfer, and
other applications

• Multi User Chat : exible, multi-party communication

• PubSub : alerts and notications for data syndication, rich presence, and more

• BOSH : an HTTP binding for XMPP (and other) trac

The applications where XMPP is being used are mentioned below.

• Publish-subscribe systems

• Signaling for VoIP

• Video

• File Transfer

• Gaming

2.5. 6LoWPAN

6LoWPAN is an acronym of IPv6 over Low-Power Wireless Personal Area Networks.

6LoWPAN is the name of a concluded working group in the Internet area of the IETF.
The 6LoWPAN concept originated from the idea that the Internet Protocol could and
should be applied even to the smallest devices, and that low-power devices with limited
processing capabilities should be able to participate in the Internet of Things. Packet
format of 6LowPAN is shown in Fig. 25.
The 6LoWPAN group has dened encapsulation and header compression mechanisms
that allow IPv6 packets to be sent and received over IEEE 802.15.4 based networks. IPv4
and IPv6 are the work horses for data delivery for local-area networks, metropolitan area
networks, and wide-area networks such as the Internet. Likewise, IEEE 802.15.4 devices
provide sensing communication-ability in the wireless domain. The inherent natures of
the two networks though, are dierent. The base specication developed by the 6LoW-
PAN IETF group is RFC 4944 (updated by RFC 6282 with header compression, and by
RFC 6775 with neighbor discovery optimizations). The problem statement document is
RFC 4919. IPv6 over Bluetooth Low Energy (BLE) is dened in RFC 7668.
Adapting the packet sizes of the two networks
22
 Figure 25: 6LowPAN Packet Format

IPv6 requires the maximum transmission unit (MTU) to be at least 1280 octets. In con-
trast, IEEE 802.15.4's standard packet size is 127 octets. A maximum frame overhead of
25 octets spares 102 octets at the media access control layer. An optional but highly rec-
ommended security feature at the link layer poses an additional overhead. For example,
21 octets are consumed for AES-CCM-128 leaving only 81 octets for upper layers.
Address resolution
IPv6 nodes are assigned 128 bit IP addresses in a hierarchical manner, through an arbi-
trary length network prex. IEEE 802.15.4 devices may use either of IEEE 64 bit extended
addresses or, after an association event, 16 bit addresses that are unique within a PAN.
There is also a PAN-ID for a group of physically collocated IEEE 802.15.4 devices.
Diering device designs
IEEE 802.15.4 devices are intentionally constrained in form factor to reduce costs (allow-
ing for large-scale network of many devices), reduce power consumption (allowing battery
powered devices) and allow exibility of installation (e.g. small devices for body-worn
networks). On the other hand, wired nodes in the IP domain are not constrained in this
way; they can be larger and make use of mains power supplies.
Diering focus on parameter optimization
IPv6 nodes are geared towards attaining high speeds. Algorithms and protocols imple-
mented at the higher layers such as TCP kernel of the TCP/IP are optimized to handle
typical network problems such as congestion. In IEEE 802.15.4-compliant devices, energy
conservation and code-size optimization remain at the top of the agenda.
Adaptation layer for interoperability and packet formats

23
An adaptation mechanism to allow interoperability between IPv6 domain and the IEEE
802.15.4 can best be viewed as a layer problem. Identifying the functionality of this layer
and dening newer packet formats, if needed, is an enticing research area. RFC 4944
proposes an adaptation layer to allow the transmission of IPv6 datagrams over IEEE
802.15.4 networks.
Addressing management mechanisms
The management of addresses for devices that communicate across the two dissimilar
domains of IPv6 and IEEE 802.15.4 is cumbersome, if not exhaustingly complex [2].
It uses two routing protocols : LOADing Routing:
Generation of Route Requests (RREQs) by a LOADng Router (originator) for discover-
ing a route to a destination.Forwarding of such RREQs until they reach the destination
LOADng Router. Generation of Route Replies (RREPs) upon receipt of an RREQ by
the indicated destination, and unicast hop-by-hop forwarding of these RREPs towards
the originator. If a route is detected to be broken, a Route Error (RERR) message is
returned to the originator of that data packet to inform the originator about the route
breakage.
Optimized ooding is supported, reducing the overhead incurred by RREQ generation
and ooding. Only the destination is permitted to respond to an RREQ. Intermediate
LOADng Routers are explicitly prohibited from responding to RREQs, even if they may
have active routes to the sought destination.RREQ/RREP messages generated by a given
LOADng Router share a single unique, monotonically increasing sequence number.
The second one is RPL routing.
Distance Vector IPv6 routing protocol for lossy and low power networks.Maintains routing
topology using low rate beaconing.Beaconing rate increases on detecting inconsistencies
(e.g.node/link in a route is down). Routing information included in the datagram it-
self. Proactive is used for Maintaining routing topology. Reactive is used for Resolving
routing inconsistencies.RPL separates packet processing and forwarding from the routing
optimization objective, which helps in Low power Lossy Networks (LLN).RPL supports
message condentiality and integrity. Supports Data-Path Validation and Loop Detec-
tion Routing optimization objectives include minimizing energy, minimizing latency and
satisfying constraints.

24
3. Comparison Chart of IoT Protocols
Amongst the data protocols used in IoT Applications, the ones that nd the wide most
applicability are CoAP (Constrained Application Protocol), XMPP (Extensible Messag-
ing and Presence Protocol), MQTT (Message Queue Telemetry Transport), AMQP (Ad-
vanced Message Queuing Protocol), DDS (Data Distribution Service) and REST/HTTP
(Representational State Transfer/ HyperText Transfer Protocol). A comparison of these
data protocols with each other over parameters such as Transport Protocol used, Interac-
tion Model, Scope, Automatic Discover feature, Content Awareness, QoS, Interoperability
Level, Security, Data Prioritization, Fault Tolerance, Advantages and Disadvantages has
been shown in g. 26. [3] and g. 27 [4].

Figure 26: Comparison between Data Protocols

4. Course Conclusion
In this course [5], The amalgamation of the physical entities into a virtual network
causing the seamless merger of the physical entities around us in a virtual network con-
nected via the wireless communication technologies is the essence of IoT is. Wide appli-
cability of IoT in various elds has opened doors for research in node identication, node
addressing, energy consumption, access controls, security, privacy and in communication
protocols, out of which, Communication Protocols are of the most importance and it is
what denes the strength of IoT.

25
 Figure 27: Comparison between Data Protocols

References
[1] D. Team, Iot protocols, https://data-flair.training/blogs/iot-protocols/,
2018.

[2] Wikipedia contributors, 6lowpan, https://en.wikipedia.org/wiki/6LoWPAN, 2014.

[Last Updated on 15th March 2019].

[3] N. S. S. M. Sakina Elhadi, Abdelaziz Marzak, Comparative study of iot protocols,

Elsevier (2018).

[4] B. McIlvride, Iot protocols comparison, https://skkynet.com/

iiot-protocol-comparison/, 2018.

[5] S. Misra, Introduction to internet of things, https://nptel.ac.in/courses/

106105166/, 2019.

26