Velammal College of Engineering and Technology- Madurai

(Autonomous)

Unit II
IoT Protocols

Dr.S.Senthilrani
Professor/ Department of Electronics Engineering
(VLSI Design and Technology)
Velammal College of Engineering and Technology- Madurai
(Autonomous)

VCET/EE/ 2024-24/ODD/21PEE22/ Internet of Things in Medicine

 Introduction
• Multiple electronic devices which are equipped with a unique IP address
and communicated with over internet are called the Internet of Things
(IoT)
• IoT is a technology, that can control the number of electronic devices
through a single device with the help of the Internet.
• Here, the electronic devices in IoT technology should have the sensors and
it should sense the signal through electrically and functions according to
it.
• The sensed data transferred to the other device through the Internet.
• IoT will make our life so simple and accurate.
• Present this technology has huge job opportunities and still there are
many developments are going on.
• Examples for IoT devices like a smartwatch, smart speakers, smart TV’s,
Amazon Alexa, Google Home devices are internet-connected devices come
under examples of IoT.
 What are IoT Protocols?
• Now the interesting question comes here, how these devices can
communicate with each other in IoT? and How IoT works?
• How we humans can communicate with each other, same like these
devices this can communicate with other devices through protocols
which are known as IoT protocols.
• The protocol is defined as a set of rules and regulation guidelines
having how to react for commands from another device.
• These protocols are very important while in communication
devices.
• The general-purpose protocols like CDMA, WAP, etc are not
suitable for this specific IoT technology.
• This technology needs some more powerful protocols.
 Specific IoT Protocols List
• MQTT – Message Queue Telemetry Transport
Protocol
• DDS – Data Distribution Service
• AMQP – Advanced Message Queuing Protocol
• CoAP – Constrained Application Protocol
 Message Queue Telemetry Transport
Protocol
• Machine to machine communication can be with this MQTT. It
was developed by IBM.
• Message queue telemetry transport protocol is a messaging
protocol.
• This protocol collects the data from the devices and forwards
to the network.
• So the connection between the devices and network can be
done by this protocol.
• It’s a simple protocol which sends the data from the sensors
to devices and then towards the network.
• This is the top protocol of the TCP/IP protocol reference
model.
 Message Queue Telemetry Transport
Protocol
• The three elements in MQTT
protocol in IoT.
• They are subscriber,
publisher and dealer/broker.
• The data can be interchanged
between subscriber and
publisher.
• The dealer/broker enables
the safety connection
between the subscriber and
publisher.
• MQTT runs over the TCP/IP
model. Because of this MQTT
protocol cannot be used for
all types of IoT applications.
Advanced Message Queuing Protocol
(AMQP)
• This advanced message queuing is a suitable
protocol for the message-oriented middleware
environments.
• This was developed by John Hara from JP
Morgan Chase, London.
• This IoT communication protocol useful for the
exchange of reliable message can be done with
this AMQP.
• The publisher can communicate with subscriber
through AMQP carrier.
Advanced Message Queuing Protocol
(AMQP)
• The messages from the publisher can be store in the
carrier of AMQP and as per the message queue and
order, they will be forwarded to the relevant subscriber
with proper security system line.
• AMQP has the following three capabilities which make it
more reliable and secure.
• This protocol has the below processing chain.
Advanced Message Queuing Protocol
(AMQP)
• Exchange: Receives the messages from the
publishers and based on priorities they are
forwarded to message queues.
• Message Queue: Stores the messages until they
are properly processed with client software.
• Binding: The connection between the exchange
and message queue will state by this binding
component.
 Data Distribution Service (DDS)
• This protocol is an IoT standard which is developed by Object
Management Group (OMG).
• This DDS can be used in small devices which occupies less area and
as well as in the cloud.
• This is a middleware protocol (lies between operating system and
application) and API (Application Programming Interface) which
enables the data connectivity between devices.
• This architecture is best suitable for IoT application.
• This protocol software is best for interchanging the information and
quick data integration in IoT systems.
• This one supports the major software programming languages.
• Scalable, real-time and reliable communication can be possible with
this Data Distribution Service (DDS).
 DDS protocol
• This DDS standard has two layers. They are:
• Data-Centric Publish-Subscribe (DCPS)
• Data Local Reconstruction Layer (DLRL)
• DCPS layer delivers the information to all
subscribers whereas DLRL providing the
interface to the functionalities of DCPS.
 Constrained Application Protocol
(CoAP)
• This protocol is an internet utility protocol for the few
(restricted) IoT gadgets.
• It is useful in most of IoT applications.
• Initially, CoAP is used in the machine to machine
communications. CoAP is the alternate protocol for the
HTTP.
• This protocol has an effective XML interchange data
format technique.
• It is a different technique of binary data format has
more preferable in terms of space.
• This could be better than plain text HTML/XML file.
 Constrained Application Protocol
(CoAP)
• CoAP has four different types of messages.
• They are: non-confirmable, confirmable, reset
and acknowledgment.
• For reliable and secure transmission over UDP
confirmable messages are used and the
responses can be in the form of
acknowledgment.
• CoAP is a very lightweight protocol and it uses
DTLS (Datagram Transport Layer Security) for
providing more security and reliable
communications.
 IoT Protocol Architecture
• The most interesting point here is, IoT has
don’t have any particular architecture.
• The researchers proposed different IoT
architectures.
• But in that most proposed architectures three-
layer architectures & five-layer architecture.
 Three-layer IoT Architecture
• This architecture introduced in the early
days of research of IoT technology.
• The three-layers are in IoT architecture is
for
• Application Layer: This layer is to deliver
the specific application to the end-user.
The specific applications can be done with
this application layer. Example of this layer
like a smart watch, smart phone, smart TV,
etc. which is used for a specific
application.
• Network Layer: Network layer have an
important role in IoT architecture. It
connects to the other smart electronic
devices (smartwatches, servers, etc). The
network layer is for transmitting and
processing the sensor data.
• Perception Layer: It is the physical layer
and it gathers the surroundings data by
sensing the area with help the of sensors.
 Five-layer IoT Architecture
• Another architecture which is five-layers IoT
architecture is proposed by the researchers
who were worked on IoT.
• In this five-layer IoT architecture, the three-
layers which are the application, network, and
perception layers are having same
architecture like three-layer IoT architecture.
• Additionally, the Business layer, Transport
layer, and processing layer are the new one.
 Five-layer IoT Architecture
• Transport Layer: This layer forward
the data from the processing layer to
perception layer and vice versa
through wireless networks like LAN,
3G, and Bluetooth, etc.
• Processing Layer: It is in the middle
of the IoT architecture. It’s having an
important role in this five-layer IoT
architecture. This layer stores the
data and process the data which
comes from the transport layer. This
processing layer able to implement
latest technologies like big data,
DBMS and cloud computing, etc.
 Five-layer IoT Architecture
• Business Layer: This layer is the
head of the IoT architecture. It
manages the complete IoT system
even applications, user’s privacy,
profit models, etc.
• The smart home consists of all the
devices are connected with a
network and communicated with
the internet. To develop a smart
system like this five-layer IoT
protocol stack is the best one.
IoT ACCESS TECHNOLOGIES
 Introduction
• IEEE 802.15.4: This is an older but foundational wireless protocol for
connecting smart objects.
• IEEE 802.15.4g and IEEE 802.15.4e: These are the result of
improvements done to 802.15.4 and are mainly targeted to utilities
and smart cities deployments.
• IEEE 1901.2a: This is a technology for connecting smart objects over
power lines.
• IEEE 802.11ah: This is a technology built on the well-known 802.11
Wi-Fi standards that is specifically for smart objects.
• LoRaWAN: This is a scalable technology designed for longer
distances with low power requirements in the unlicensed spectrum.
• NB-IoT and Other LTE Variations: These technologies are often the
choice of mobile service providers looking to connect smart objects
over longer distances in the licensed spectrum.
 IoT access technologies
• A common information set is provided about the IoT access
technologies which are as listed below:
• Standardization and alliances: The standards bodies that maintain
the protocols for a technology
• Physical layer: The wired or wireless methods and relevant
frequencies
• MAC layer: Considerations at the Media Access Control (MAC) layer,
which bridges the physical layer with data link control
• Topology: The topologies supported by the technology
• Security: Security aspects of the technology
• Competitive technologies: Other technologies that are similar and
may be suitable alternatives to the given technology
 IEEE 802.15.4
• IEEE 802.15.4 is a wireless access technology for low-
cost and low-data-rate devices that are powered or run
on batteries.
• In addition to being low cost and offering a reasonable
battery life, this access technology enables easy
installation using a compact protocol stack while
remaining both simple and flexible.
• Several network communication stacks, including
deterministic ones, and profiles leverage this
technology to address a wide range of IoT use cases in
both the consumer and business markets.
 Types of deployments
• IEEE 802.15.4 is commonly found in the
following types of deployments:
• Home and building automation
• Automotive networks
• Industrial wireless sensor networks
• Interactive toys and remote controls
 Criticisms of IEEE 802.15.4
• Criticisms of IEEE 802.15.4 often focus on its MAC reliability,
unbounded latency, and susceptibility to interference and multipath
fading.
• The negatives around reliability and latency often have to do with
the Collision Sense Multiple Access/Collision Avoidance (CSMA/CA)
algorithm.
• CSMA/CA is an access method in which a device “listens” to make
sure no other devices are transmitting before starting its own
transmission.
• If another device is transmitting, a wait time (which is usually
random) occurs before “listening” occurs again.
• Interference and multipath fading occur with IEEE 802.15.4 because
it lacks a frequency-hopping technique.
• Later variants of 802.15.4 from the IEEE start to address these
issues.
 Standardization and Alliances
• IEEE 802.15.4 or IEEE 802.15 Task Group 4 defines low-data-rate PHY and
MAC layer specifications for wireless personal area networks (WPAN).
• This standard has evolved over the years and is a well-known solution for
low-complexity wireless devices with low data rates that need many
months or even years of battery.
• Since 2003, the IEEE has published several iterations of the IEEE 802.15.4
specification.
• Newer releases typically supersede older ones, integrate addendums, and
add features or clarifications to previous versions.
• The IEEE 802.15.4 PHY and MAC layers are the foundations for several
networking protocol stacks.
• These protocol stacks make use of 802.15.4 at the physical and link layer
levels, but the upper layers are different.
• These protocol stacks are promoted separately through various
organizations and often commercialized.
 Most well-known protocol stacks
based on 802.15.4
Protocol Description
ZigBee Promoted through the ZigBee alliance, ZigBee defines upper-layer
components (network through application) as well as application profiles.
Common profiles include building automation, home automation, and
healthcare. ZigBee also defines device object functions such as device
role, device discovery, network join and security

6LoWPAN 6LoWPAN is an IPv6 adaptation layer defined by the IETF 6LoWPAN

working group that describes how to transport IPv6 packets over IEEE
802.15.4 layers. RFCs document header compression and IPv6
enhancement to cope with the specific details of IEEE 802.15.4

ZigBee IP An evolution of the ZigBee protocol stack, ZigBee IP adopts the 6LoWPAN
adaptation layer , IPv6 network layer, RPL routing protocol. In addition, it
offers improvement in IP security.
 Most well-known protocol stacks
based on 802.15.4
Protocol Description

ISA100.11a This is developed by the International Society of Automation (ISA) as

“Wireless Systems for Industrial automation: Process Control and Related
Applications”. It is based on IEEE 802.15.4-2006. The network and
transport layers are based on IETF 6LoWPAN, IPv6, and UDP standards

Wireless Wireless HART promoted by the HART Communication Foundation, is a

HART protocol stack that offers a time-synchronized, self-organizing, and self
healing mesh architecture, leveraging IEEE 802.15.4-2006 over the 2.4GHz
frequency band.

Thread Constructed on top of IETF 6LoWPAN /IPv6, Thread is a protocol stack for
a secure and reliable mesh network to connect and control products in
the home.
 LoRaWAN
• In recent years, a new set of wireless
technologies known as Low-Power Wide-Area
(LPWA) has received a lot of attention from the
industry and press.
• Particularly well adapted for long-range and
battery-powered endpoints, LPWA technologies
open new business opportunities to both services
providers and enterprises considering IoT
solutions.
• LoRaWAN is an unlicensed-band LPWA
technology.
 Standardization and Alliances
• Initially, LoRa was a physical layer, or Layer 1, modulation that
was developed by a French company named Cycleo.
• Later, Cycleo was acquired by Semtech. Optimized for
longrange, two-way communications and low power
consumption, the technology evolved from Layer 1 to a
broader scope through the creation of the LoRa Alliance.
• Semtech LoRa as a Layer 1 PHY modulation technology is
available through multiple chipset vendors.
• To differentiate from the physical layer modulation known as
LoRa, the LoRa Alliance uses the term LoRaWAN to refer to its
architecture and its specifications that describe end-to-end
LoRaWAN communications and protocols.
LoRa WAN Layers
High- Level LoRaWAN MAC Frame
Format
 LoRaWAN endpoints are uniquely
addressable through a variety of methods
• An endpoint can have a global end device ID or DevEUI
represented as an IEEE EUI64 address.
• An endpoint can have a global application ID or AppEUI
represented as an IEEE EUI64 address that uniquely
identifies the application provider, such as the owner, of
the end device.
• In a LoRaWAN network, endpoints are also known by their
end device address, known as a DevAddr, a 32-bit address.
• The 7 most significant bits are the network identifier
(NwkID), which identifies the LoRaWAN network.
• The 25 least significant bits are used as the network
address (NwkAddr) to identify the endpoint in the network.
LoRa WAN Architecture
LoRaWAN Security
 Constrained Nodes
&
Constrained Networks
 Introduction
• In IoT solutions, different classes of devices coexist.
• Depending on its functions in a network, “thing” architecture may
or may not offer similar characteristics compared to a generic PC or
server in an IT environment.
• Another limit is that this network protocol stack on an IoT node
may be required to communicate through an unreliable path
• Even if a full IP stack is available on the node, this causes problems
such as limited or unpredictable throughput and low convergence
when a topology change occurs.
• Finally, power consumption is a key characteristic of constrained
nodes.
• Many IoT devices are battery powered, with lifetime battery
requirements varying from a few months to 10+ years.
 Introduction
• This drives the selection of networking technologies since
high-speed ones, such as Ethernet, Wi-Fi, and cellular, are
not (yet) capable of multi-year battery life.
• Current capabilities practically allow less than a year for
these technologies on battery-powered nodes.
• Of course, power consumption is much less of a concern on
nodes that do not require batteries as an energy source.
• The power consumption requirements on battery-powered
nodes impact communication intervals.
• To help extend battery life, one could enable a “low-power”
mode instead of one that is “always on.” Another option is
“always off,” which means communications are enabled
only when needed to send data.
Classification of IoT constrained nodes
• Devices that are very constrained in resources,
may communicate infrequently to transmit a
few bytes, and may have limited security and
management capabilities: This drives the need
for the IP adaptation model, where nodes
communicate through gateways and proxies.
Classification of IoT constrained nodes
• Devices with enough power and capacities to
implement a stripped-down IP stack or non- IP
stack: In this case, you may implement either
an optimized IP stack and directly
communicate with application servers
(adoption model) or go for an IP or non-IP
stack and communicate through gateways and
proxies (adaptation model).
Classification of IoT constrained nodes
• Devices that are similar to generic PCs in
terms of computing and power resources but
have constrained networking capacities, such
as bandwidth: These nodes usually implement
a full IP stack (adoption model), but network
design and application behaviors must cope
with the bandwidth constraints.
Introduction- Constrained network
• In the early years of the Internet, network bandwidth capacity
was restrained due to technical limitations.
• Connections often depended on low-speed modems for
transferring data.
• However, these low-speed connections demonstrated that IP
could run over low bandwidth networks.
• But today, the evolution of networking has seen the
emergence of high-speed infrastructures.
• However, high-speed connections are not usable by some IoT
devices in the last mile.
• The reasons include the implementation of technologies with
low bandwidth, limited distance and bandwidth due to
regulated transmit power, and lack of or limited network
services.
Characteristics of constrained network
• A constrained network can have high latency and a
high potential for packet loss.
• Constrained networks have unique characteristics and
requirements.
• In contrast with typical IP networks, where highly
stable and fast links are available, constrained networks
are limited by low-power, low bandwidth links
(wireless and wired).
• They operate between a few kbps and a few hundred
kbps and may utilize a star, mesh, or combined
network topologies, ensuring proper operations.
6LoWPAN
 Introduction
• While the Internet Protocol is key for a
successful Internet of Things, constrained
nodes and constrained networks mandate
optimization at various layers and on multiple
protocols of the IP architecture.
• Some optimizations are already available from
the market or under development by the IETF.
Optimizing IP for IoT Using an
Adaptation Layer
 Optimizing IP for IoT Using an
Adaptation Layer
• In the IP architecture, the transport of IP
packets over any given Layer 1 (PHY) and Layer
2 (MAC) protocol must be defined and
documented.
• The model for packaging IP into lower-layer
protocols is often referred to as an adaptation
layer
 Comparison of an IoT Protocol Stack
Utilizing 6LoWPAN and an IP Protocol Stack
 6LoWPAN Header Stack
• The 6LoWPAN working group published several RFCs, but RFC 4994
is foundational because it defines frame headers for the capabilities
of header compression, fragmentation, and mesh addressing.
• These headers can be stacked in the adaptation layer to keep these
concepts separate while enforcing a structured method for
expressing each capability.
• Depending on the implementation, all, none, or any combination of
these capabilities and their corresponding headers can be enabled.