IoT Protocol Stack

Presented By:
Bimal Patel
Assistant Professor
Department of I.T.
CSPIT,CHARUSAT
 Outline of Presentation

• IoT World Forum Architecture

• IoT Protocol Stack Architecture
• Communication Models
• Communication API
• IoT levels and Deployment Templates
 IoT World Forum (IoTWF)
Standardized Architecture
• IoTWF architectural committee published 7-
layer IoT architectural reference model in 2014
• This committee was led by Cisco, IBM,
Rockwell Automation, and others
• While various IoT reference models exist, the
one put forth by the IoT World Forum offers
clean, simplified perspective on IoT
• Includes edge computing, data storage, and
access
3
IoT World Forum (IoTWF)
Standardized Architecture

4
 Layer 1: Physical Devices and
Controllers Layer
• This layer is home to the “things” in the IoT,
including various endpoint devices & sensors
• Size of these “things” can range from almost
tiny sensors to huge machines in factory
• Their primary function is generating data and
being capable of being controlled over
network

7
Layer 2: Connectivity Layer

8
Layer 3: Edge Computing Layer

9
Upper Layers: Layers 4–7

10
Protocol Stack

Overall Protocols and efforts in support of IoT [04]

IoT Protocol Stack [01]

 IoT
Protocols
• Link Layer
• 802.3 – Ethernet
• 802.11 – WiFi
• 802.16 – WiMax
• 802.15.4 – LR-WPAN
• 2G/3G/4G
• Network/Internet Layer
• IPv4
• IPv6
• 6LoWPAN
• Transport Layer
• TCP
• UDP
• Application Layer
• HTTP
• CoAP
• WebSocket
• MQTT
• XMPP
• DDS
• AMQP
Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015
 IEEE 802.15.4
• Provides framework for lower layers (MAC
and PHY) for wireless PAN
• PHY defines frequency band,
transmission power, and modulation
scheme of the link
• MAC defines issues such as medium
access and flow control (frames)
• Used for low power, low cost and low
speed communication between devices (<
~75m) 13
 Features of IEEE 802.15.4
• Nature of transmission is line of sight
• Standard range of transmission - 10 to 75m
• Transmission of data uses CSMA-CA (carrier
sense multiple access with collision
avoidance)
• Star and peer-to-peer network topology
is included

14
 IEEE 802.15.4
Version Feature
802.15.4 Basic version. The modulation schemes and data rates were
- 2003 fixed for different frequency band – 868, 915 MHz, and
2.4 GHz.
802.15.4 - Also known as 802.15.4b. Provides higher data rate even on
2006 the
lower frequency bands. In the 868 MHz, the data
transmission rate is up to 100 kb/s while in 915 MHz, the
data transmission rate is up to 250 kb/s. Uses OQPSK for all
the frequency bands.
802.15.4 a Increases range capability. Defines two new physical layers –
Direct Sequence ultra-wideband (UWB) – 249.6 - 749.6 MHz
(sub-gigahertz band), 3.1 - 4.8 GHz (low band), and 6 - 10 GHz
(high band). Chirp spread spectrum (CSS) approach in ISM
band at 2.4 GHz.
802.15.4 c This version provides 780 MHz band in China. It uses either
O-QPSK or MPSK (Multiple frequency-shift keying) using
data transmission rate 250 kb/s.
15
 IEEE 802.15.4
Version Feature
802.15.4 d This version provides 950 MHz band in Japan. It uses either
GFSK (Gaussian frequency-shift keying) using data rate
100 kb/s or BPSK using data rate 20 kb/s.
802.15.4e Defines MAC developments to IEEE 802.15.4 towards ISA
SP100.11a application (industrial applications).
802.15.4f Defines fresh PHYs for 433 MHz frequency band (RFID
applications), 2.4 GHz frequency band and UWB.
802.15.4g Defines fresh PHYs for smart utility networks for 902 - 928
MHz band (smart grid applications, majorly for the energy
industry).

16
802.15.4
 802.15.4

• IEEE 802.15.4 task group began to develop

a standard for LR-WPAN.
• The goal of this group was to provide a
standard with ultra-low complexity, cost, and
power for low-data-rate wireless connectivity
among inexpensive fixed,portable, and
moving devices.
802.15.4
 Approaches for Low Power
In order to achieve the low power and low cost goals
established by IEEE 802.15.4 the following approaches
are taken
• Reduce the amount of data transmitted
• Reduce the transceiver duty cycle and frequency of
data transmissions
• Reduce the frame overhead
• Reduce complexity
• Reduce range
• Implement strict power management mechanisms
(power-down and sleep
 IEEE 802.15.4

• IEEE 802.15.4 deals with only PHY layer

and portion of Data link layer.
• The higher-layer protocols are left to industry
and the individual applications.
• The Zigbee Alliance is an association of
companies involved with building higher-layer
standards based on IEEE 802.15.4. This
includes network, security, and application
protocols.
 IEEE 802.15.4

IEEE 802.15.4 draft standard supports multiple

network topologies including star and peer to peer
topology.
IEEE 802.15.4
 IEEE 802.15.4
• IEEE 802 splits DLL into MAC and LLC sublayers.
• LLC is standardized and is common in
802.3,802.11,802.15.1.
• Features of the IEEE 802.15.4 MAC
are
– Association and disassociation
– acknowledged frame delivery
– Channel access mechanism
– Frame validation
– Guaranteed time slot management
– Beacon management.
 IEEE 802.15.4 …MAC

• MAC provides data and management

services to upper layers
• 802.15.4 MAC is of very low complexity,
making it very suitable for its intended low-
end applications, albeit at the cost of a
smaller feature set than 802.15.1 (e.g.,
802.15.4 does not support synchronous voice
links).
IEEE 802.15.4 …MAC
 IEEE 802.15.4 …MAC
• Frame control field indicates the type of MAC
frame being transmitted, specifies the format of
the address field, and controls the
acknowledgment.
• Multiple address types : 64 bit physical address
and short 8 bit network assigned address are
provided.
• Address field size may vary from 0 to 20 bytes.
• Payload field is variable with condition size of
mac frame <= 127 bytes.
• FCS is used for integrity check using 16 bit CRC.
 IEEE 802.15.4 …PHY
• This standard provides 2 PHY options with
frequency band as fundamental difference.
• 2.4 GHz band has worldwide availability and
provides a transmission rate of 250 kb/s.
• The 868/915 MHz PHY specifies operation in the
868 MHz band in Europe and 915 MHz ISM band
in the United States and offer data rates 20 kb/s
and 40 kb/s respectively.
• Different transmission rates can be exploited to
achieve a variety of different goals.
IEEE 802.15.4 …Channel Structure
IEEE 802.15.4 …Modulation
 Parameter EtherNet WiFi WiMax LR- Cellular
WPAN(ZigBee)
Used Inside Outside Outside Outside Outside
offices and offices and offices and offices and offices and
houses houses houses houses houses

IEEE 802.3 802.11 802.16 802.15.4

Standards:

Range 100mtrs 100 mrts 80-90kms 10-100 mtrs 1-5kms

Data 10Mb 54Mbps 40Mbps 250kbit/s 100Kb

Transfer ps- ps-
Rate 100M 1MB
bps ps
Application Houses, Mobile MetroPolita Smart Camera on
Offices, Applications n Area Metering, Traffic
Industries , Video Network Home Light,
Conferenci Automation Video on
ng (Alexa), Smart Demand
Asset Tracking
Working of RPL [02][05][06][07]

RPL concepts

• Follows distance-vector routing protocol based on IPv6

• Directed Acyclic Graph(DAG):No cycles
• Destination-Oriented DAG(DODAG):Single root
• Up: Towards root
• Down: Away from root
• Objective Function: Hop count, ETX(Expected Transmission Count)(OF0,MHROF)
• Rank : Distance from root using specified objective
• RPL Instance: One or more DODAGs.
A node may belong to multiple RPL instances.
• DODAG ID: IPv6 Adr. Of the root
• DODAG Version: Current version of DODAG.Every time a new DODAG is computed
with the same root,its version incremented(for global repair)
Working of RPL

RPL concepts
Working of RPL

RPL Control Messages

1. DODAG Information Object(DIO):

▫ Downward RPL instance multicasts
▫ Allows other nodes to discover an RPL instance and join it
2. DODAG Information Solicitation(DIS)
▫ Link-Local multicast request for DIO(neighbour discovery)
▫ Do you know of any DODAGs?
3. Destination Advertisement Object(DAO)
▫ From child to parents or root
▫ Can I join you as a child on DODAG #x?
4. DAO Ack:Yes,you can! Or Sorry,you cant!
5. Consistency Check: Challenge/response messages for security
RPL Operation
0 DIO

DIO 1
DIO
DIO
DIO 2
1 1 DIO
DIO DIO 2
DIO DIO
DIO
2 3
2
2 DIO DIO
3

3 3 3

• Directed Acyclic Graph (DAG) Information Option (DIO) messages are

broadcast to build the tree; includes a node’s rank (its level), ETX, etc.
• ETX probe is sent periodically to probe neighboring ETX
Working of RPL
Traffic Flows supported by RPL
Self Healing in RPL

• On a link failure a local repair mechanism tries to select a new parent or

path.
• If there are more local failures, RPL performs a complementary global
repair where the whole DODAG is rebuilt with different version number.
• The RPL protocol uses the link-layer metric as a parameter in the
calculation of a default route. The path is assumed to be good if link-layer
acknowledgements are received on it.
• RPL also uses a trickle timer to handle inconsistencies in the RPL
DODAG.
Summary of RPL [05]

Feature Description
Target Network LLN:IPv6/6LowPAN networks
Routing Type Source-routing,Distance-Vector
Topology Mesh,Hierarchical based on DAG
Traffic Flows MP2P,P2MP and P2P
Message update Trickle Timer
Control Messages DIO,DAO,DIS
Transmission Unicast and Multicast
Metrics and Dynamic, based on OF and Rank
Constraints
Modes Storing and non-storing
RPL Implementation at various OS/Simulation Tools

Name OS Protocol Version Notes(Extensions…)

TinyRPL TinyOS Draft-ietf-roll-rpl-17 • Uses BLIP2.0
• Only Storing mode
• Only Single RPL instance ID
• Security options not supported
• Only telosb and epic platform
supported
ContikiRPL Contiki RFC 6550 By default enabled on Tmote sky platform
OpenWSN OpenWSN RFC 6550
NanoRK Nano-RK Draft-ietf-roll-rpl-07
NanoQplus NanoQplus Draft-ietf-roll-rpl-13

Operating System incorporating RPL [02]

Name Language Protocol Version Notes(Extensions…)

Cooja C RFC 6550 MSPsim

NS-3 C++ and Python Draft-ietf-roll-rpl-19

Omnet++ C++ Draft-ietf-roll-rpl-19

J-SIM Tcl/Java Draft-ietf-roll-rpl-19 EU Funded Project

Simulators incorporating RPL [02]

 IoT Protocols…Application Layer…
Hyper Text Transfer Protocol
• Forms foundation of World Wide Web(WWW)
• Includes commands such as GET,PUT, POST, HEAD, OPTIONS, TRACE..etc
• Follows a request-response model
• Uses Universal Resource Identifiers(URIs) to identify HTTP resources
 IoT Protocols…Application Layer…CoAP

• Constrained Application Protocol

• Used for Machine to machine (M2M) applications meant for constrained
devices and n/w’s
• Web transfer protocol for IoT and uses request-response
model
• Uses client –server architecture
• Supports methods such as GET,POST, PUT and DELETE
• CoAP makes use of the UDP protocol for lightweight
implementation.
• It also uses restful architecture, which is just like the
 IoT Protocols…Application Layer…WebSocket
• Allows full-duplex communication over single socket
• Based on TCP
• Client can be a browser, IoT device or mobile application

IoT Protocols…Application Layer…MQTT

• Message Queue Telemetry Transport , light-weight messaging protocol
• Based on publish-subscribe model
• Well suited for constrained environments where devices have limited processing, low
memory and n/w bandwith requirement
MQTT and AMQP figures

MQTT Model

AMQP Model
 IoT Protocols…Application Layer…AMQP

• Advanced Messaging Queuing Protocol used for business messaging.

• Supports both point-to-point and publisher/subscriber models, routing
and queuing
• Broker here receives messages from publishers and route them over
connections to consumers through messaging queues.
 IoT Protocols…Application Layer…XMPP

• Extensible messaging and presence protocol

• For Real time communication and streaming XML data between n/w
entities
• Used for Applications such as Multi-party chat and voice/video calls.
• Decentralized protocol and uses client server architecture.
 IoT Protocols…Application Layer…DDS

• Data Distribution service is a data-centric middleware standard for

device-to-device or machine-to-machine communication.
• Publish subscribe model where publishers create topics to which
subscribers can use.
• Provides Quality-of-service control and configurable reliability.
Parameter HTTP CoAP XMPP(Ope DDS AMQP MQTT
n XML)
Protocol TCP UDP TCP TCP and TCP TCP
UDP
Network IP 6LowPAN IP IP IP IP
Layer

Architectu Clie Client- Client- Publish- Client- Publish-

re nt- Server and Server Subscribe Server and Subscribe
Serv Publish- Publish-
er Subscribe Subscribe

Synchroni Needed No Need Needed Sometimes Needed Needed

zation Needed,
Sometimes
Not

Designed Internet IoT/M2M IoT/M2M Real Time M2M IoT/M2M

for SYstems
Application WWW Retrieving WhatsApp, Volswagen Google Facebook
Sensor Gaming, Smart Cars Cloud Messenger
Data Google for Video
Talk Assistance
Communication
Models
 Request–Response Communication Model
• Request–Response is
a communication model in
which the client sends requests to
the server and the server
responds to the requests.

• When the server receives a

request, it decides how to
respond, fetches the data,
retrieves
resource representations,
prepares the response and then
sends the response to the client.

• Stateless communication model

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

Stateful v/s Stateless
 Publish–Subscribe Communication Model

• Publish–Subscribe is
a communication model that
involves publishers, brokers and
consumers.
• Publishers are the source of data.
Publishers send the data to the
topics which are managed by the
broker. Publishers are not aware of
the consumers.
• Consumers subscribe to the topics
which are managed by the broker.
• When the broker receives data for
a topic from the publisher, it sends
the data to all the subscribed
consumers.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

 Push–Pull Communication Model

• Push–Pull is a communication
model in which the data
producers push the data to
queues and the consumers pull
the data from the queues.
Producers do not need to be
aware of the consumers.
• Queues help in decoupling the
messaging between the producers
and consumers.
• Queues also act as a buffer which
helps in situations when there is a
mismatch between the rate at
which the producers push data
and the rate at which the
consumers pull data.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

Push v/s Pull communication
 Exclusive Pair Communication Model

• Exclusiv Pair is a
bidirectional,
ecommunicationfully duplex
model
uses
that a persistent connection
between the client and the
server.
• Once the connection is set
up it, remains open until the
client sends a request to
close the connection.
• Client and server can send
messages to each other after
connection setup.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

Communication
APIs
 REST-based Communication APIs
• Representational State Transfer
(REST) is a set of architectural
principles by which you can
design web services and web
APIs that focus on a system’s
resources and how resource
states are addressed and
transferred.
• REST APIs follow the request–
response
communication model.
• REST architectural constraints
apply to the components,
connectors and data elements
within a
hypermedia system.
distributed Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015
 REST-based Communication APIs Constraints
• Client – Server
Client Server
• Stateless
• Cacheable Request
• Layered System
• Uniform Interface Response
• Code on demand
Request

Response

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

 WebSocket-based Communication APIs

• WebSocket APIs allow bi-

directional, full duplex
communication between
clients and servers.
• WebSocket APIs follow the
exclusive pair
communication model.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

Difference between REST and WebSocket-based
Communication APIs
Comparison Based on REST Websocket
State Stateless Stateful
Directional Unidirectional Bidirectional
Req-Res/Full Duplex Follow Request Response Model Exclusive Pair Model
TCP Connections Each HTTP request involves Involves a single TCP
setting up a new TCP Connection for all
Connection requests
Header Overhead Each request carries HTTP Headers, Does not involve overhead of
hence not suitable for real-time headers.
Scalability Both horizontal and vertical Only Vertical is easier
are easier
 IoT Levels and Deployment Templates

An IoT system comprises the following components:

• Device: An IoT device allows identification, remote sensing, actuating and
remote monitoring capabilities.
• Resource: Resources are software components on the IoT device for
accessing, processing and storing sensor information, or for controlling
actuators connected to the device. Resources also include the software
components that enable network access for the device.
• Controller Service: Controller service is a native service that runs on the
device and interacts with the web services. Controller service sends data
from the device to the web service and receives commands from the
application (via web services) for controlling the device.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

 IoT Levels and Deployment Templates

• Database: Database can be either local or in the cloud and stores the data
generated by the IoT device.
• Web Service: Web services serve as a link between the IoT device,
application, database and analysis components. Web service can be
implemented using HTTP and REST principles (REST service) or using
the WebSocket protocol (WebSocket service).
• Analysis Component: This is responsible for analyzing the IoT data and
generating results in a form that is easy for the user to understand.
• Application: IoT applications provide an interface that the users can use to
control and monitor various aspects of the IoT system. Applications also
allow users to view the system status and the processed data.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

 IoT Level-1

• A level-1 IoT system has

single
a node/device that
performs sensing
actuation, stores and/or
performs analysis
data,and
hosts the application.
• Level-1 IoT systems
suitable for
are modelling low-
cost and low-complexity
solutions where the
involved is not big and
data
the
not computationally
analysis requirements
intensive
are
.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

IoT – Level 1 Example …Home
Automation System
 IoT Level-2

• A level-2 IoT system has a

single node that performs
sensing and/or actuation
and local analysis.
• Data is stored in the cloud
and the application is usually
cloud-based.
• Level-2 IoT systems are
suitable for solutions where
the data involved is big;
however, the primary
analysis requirement is not
computationally intensive
and can be done locally.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

IoT – Level 2 Example …Smart
Irrigation
 IoT Level-3

• A level-3 IoT system has a

single node. Data is stored
and analyzed in the cloud
and the application is
cloud-based.
• Level-3 IoT systems are
suitable for solutions
where the data involved is
big and the analysis
requirements are
computationally
intensive.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

IoT – Level 3 Example …
Tracking Package Handling
Sensors used accelrometer and gyroscope
 IoT Level-4

• A level-4 IoT system has multiple

nodes that perform local analysis.
Data is stored in the cloud and the
application is cloud-based.
• Level-4 contains local and cloud-
based observer nodes which can
subscribe to and receive
information collected in the cloud
from IoT devices.
• Level-4 IoT systems are suitable
for solutions where multiple
nodes are required, the data
involved is big and the analysis
requirements are computationally
intensive.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

 IoT – Level 3 Example …Noise
Monitoring
Sound Sensors are used
 IoT Level-5

• A level-5 IoT system has multiple end

nodes and one coordinator node.
• The end nodes perform sensing
and/or actuation.
• The coordinator node collects data
from the end nodes and sends it to
the cloud.
• Data is stored and analyzed in the
cloud and the application is cloud-
based.
• Level-5 IoT systems are suitable for
solutions based on wireless sensor
networks, in which the data involved
is big and the analysis requirements
are computationally intensive.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

 IoT Level-6

• A level-6 IoT system has multiple

independent end nodes that
perform sensing and/or actuation
and send data to the cloud.
• Data is stored in the cloud and the
application is cloud-based.
• The analytics component analyzes
the data and stores the results in
the cloud database.
• The results are visualized with the
cloud-based application.
• The centralized controller is aware
of the status of all the end nodes
and sends control commands to
the nodes.

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015