INTERNET OF THINGS AND ITS APLICATIONS

Unit-II
IoT ACCESS TECHNOLOGIES

Presented By:
K.JYOTHI
Designation :Assoc.Prof
Department: ECE
Lecture Details: College:GIET(A)
Topic Name: IOT Access Technology
IOT and its Applications/Common to CIVIL,CSE,CSM,CSC / 6 SEM
• This unit provides an in depth look at some of access technologies that are
considered for connection of smart Objects.
• The following are the technologies for connecting smart objects:
• 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.
• 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.
 USE CASES
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 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.
S.No Protocol Description
1. 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

2. 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
3. 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.
4. ISA100.11 This is developed by the International Society of
a 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
5. Wireles Wireless HART promoted by the HART Communication
s HART Foundation, is a 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.
6. 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.
 ZigBee

• ZigBee is one of the most well-known protocols listed in Table. In addition, ZigBee
has continued to evolve over time.
• The Zigbee Alliance is an industry group formed to certify interoperability between
vendors and it is committed to driving and evolving ZigBee as an IoT solution for
interconnecting smart objects
• ZigBee solutions are aimed at smart objects and sensors that have
low bandwidth and
low power needs.
 • The traditional ZigBee stack is illustrated in Figure 2.1. As mentioned
previously, ZigBee utilizes the IEEE
• 802.15.4 Standard at the lower PHY and MAC layers. ZigBee
specifies the network and security layer and application support layer
that sit on top of the lower layers.
• High Level ZigBee Protocol Stack
High Level ZigBee Protocol Stack
 Applications
•The main areas where ZigBee is the most well-known include
automation for commercial, retail, and home applications and
smart energy.
•In the industrial and commercial automation space, ZigBee-
based devices can handle various functions, from measuring
temperature and humidity to tracking assets.
•For home automation, ZigBee can control lighting,
thermostats, and security functions
• ZigBee Smart Energy brings together a variety of
interoperable products, such as smart meters, that can
monitor and control the use and delivery of utilities,
such as electricity and water.
• These ZigBee products are controlled by the utility
provider and can help coordinate usage between
homes and businesses and the utility provider itself to
provide more efficient operations.
 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 long- range, two-way communications and low
power consumption, the technology evolved from Layer 1 to
a broader scope through the creation of the LoRa Alliance
Figure 2.8
• Figure 2.8 provides a high-level overview
of the LoRaWAN layers. In this figure,
notice that Semtech is responsible for the PHY
layer
• While the LoRa Alliance handles the MAC
layer and regional frequency bands.
• Physical Layer
• Semtech LoRa modulation is based on chirp spread
spectrum modulation, which trades a lower data rate for
receiver sensitivity to significantly increase the communication
distance.
• In addition, it allows demodulation below the noise floor,
offers robustness to noise and interference, and manages a
single channel occupation by different spreading factors. This
enables LoRa devices to receive on multiple channels in parallel.
 Physical Layer

• It uses unlicensed sub- GHz frequency bands of 433 MHz, 779–787 MHz,
863–870 MHz, and 902–928 MHz, as well as regional profiles for a subset
of the 902–928 MHz bandwidth
• A LoRa gateway is deployed as the center hub of star network
architecture.
• It uses multiple transceivers and channels and can demodulate multiple
channels at once or even demodulate multiple signals on the same
channel simultaneously
• The data rate in LoRaWAN varies depending on the frequency bands and
adaptive data rate (ADR).
• An important feature of LoRa is its ability to handle various
data rates via the spreading factor (SF) .
• Devices with a low spreading factor (SF) achieve less distance
in their communications but transmit at faster speeds,
resulting in less airtime.
• A higher SF provides slower transmission rates but achieves a
higher reliability at longer distances
 MAC Layer

• The MAC layer is defined in the LoRaWAN specification.

• This layer takes advantage of the LoRa physical layer and
classifies LoRaWAN endpoints to optimize their battery life
and ensure downstream communications to the LoRaWAN
endpoints.
• The LoRaWAN specification documents three classes of
LoRaWAN devices:
 Class A: This class is the default implementation. Optimized for battery-
powered nodes, it allows bidirectional communications, where a given
node is able to receive downstream traffic after transmitting. Two receive
windows are available after each transmission.
 Class B: This class was designated “experimental” in LoRaWAN 1.0.1 until
it can be better defined. A Class B node or endpoint should get additional
receive windows compared to Class A, but gateways must be synchronized
through a beaconing process.
 Class C: This class is particularly adapted for powered nodes. This
classification enables a node to be continuously listening by keeping it’s
receive window open when not transmitting.
• LoRaWAN messages, either uplink or downlink, have a PHY payload composed of a
1- byte MAC header, a variable-byte MAC payload, and a MIC that is 4 bytes in
length.
• The MAC payload size depends on the frequency band and the data rate, ranging
from 59 to 230 byte for the 863–870 MHz band and 19 to 250 bytes for the 902–
928 MHz band
 Topology

•LoRaWAN topology is often described as a “star of stars”

topology.
•As shown in Figure 2.10, the infrastructure consists of
endpoints exchanging packets through gateways acting as
bridges, with a central LoRaWAN network server.
•Gateways connect to the backend network using standard
IP connections, and endpoints communicate directly with one
or more gateways.
Figure 2.10
 LoRaWAN Gateways
• Figure 2.10 also shows how LoRaWAN gateways act
as bridges that relay between endpoints and the
network servers.
• Multiple gateways can receive and transport the
same packets. When duplicate packets are received,
de-duplication is a function of the network server.
 LoRaWAN Network Server
• The LoRaWAN network server manages the data rate
and radio frequency (RF) of each endpoint through
the adaptive data rate (ADR) algorithm.
• ADR is a key component of the network scalability,
performance, and battery life of the endpoints. The
LoRaWAN network server forwards application data
to the application servers, as depicted in Figure 2.10.
LoRaWAN Security
 THE NETWORK LAYER
Constrained Nodes
• 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.
• 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.
 THE NETWORK LAYER
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.
• 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).
• 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.
The definition of constrained nodes is evolving. The costs of
computing power, memory, storage resources, and power
consumption are generally decreasing.
At the same time,networking technologies continue to improve
and offer more bandwidth and reliability.
In the future, the push to optimize IP for constrained nodes will
lessen as technology improvements and cost decreases address
many of these challenges.
• The definition of constrained nodes is evolving.
• The costs of computing power, memory, storage resources, and
power consumption are generally decreasing. At the same
time,networking technologies continue to improve and offer
more bandwidth and reliability.
• In the future, the push to optimize IP for constrained nodes will
lessen as technology improvements and cost decreases address
many of these challenges.
 Constrained Networks

• 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.
• 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.
• When link layer characteristics that we take for granted are not present, the
network is constrained.
• 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.
• With a constrained network, in addition to limited bandwidth,
it is not unusual for the packet delivery rate (PDR) to oscillate
between low and high percentages.
• Large bursts of unpredictable errors and even loss of
connectivity at times may occur. These behaviours can be
observed on both wireless and narrowband power-line
communication links, where packet delivery variation may
fluctuate greatly during the course of a day.
 IPv4 IPv6

IPv4 has a 32-bit address length IPv6 has a 128-bit address length

It Supports Manual and DHCP address It supports Auto and renumbering

configuration address configuration

In IPv4 end to end, connection integrity is In IPv6 end to end, connection integrity is
Unachievable Achievable

Address space of IPv6 is quite large it can

It can generate 4.29×109 address space
produce 3.4×1038 address space
Optimizing IP for IoT Using an
Adaptation Layer
Comparison of an IoT Protocol Stack Utilizing 6LoWPAN and an IP
Protocol Stack
6LoWPAN header stacks
 Application layer Protocols
• CoAP and MQTT are naturally at the top of this
sample IoT stack, based on an IEEE 802.15.4 mesh
network.
• While there are a few exceptions, you will almost
always find CoAP deployed over UDP and MQTT
running over TCP.
• Constrained Application Protocol (CoAP) resulted from the
IETF Constrained RESTful Environments (CoRE) working
group’s efforts to develop a generic framework for resource-
oriented applications targeting constrained nodes and
networks.
• The CoAP framework defines simple and flexible ways to
manipulate sensors and actuators for data or device
management.
• From a formatting perspective, a CoAP message is composed
of a short fixed-length Header field (4 bytes)
• A variable-length but mandatory Token field (0–8 bytes)
• Options fields if necessary, and the Payload field
• The CoAP message format is relatively simple and flexible. It
allows CoAP to deliver low overhead, which is critical for
constrained networks, while also being easy to parse and
process for constrained devices.
• CoAP communications across an IoT infrastructure can take
various paths.
• Connections can be between devices located on
The same or different constrained networks
or between devices and generic Internet or cloud servers, all
operating over IP
• Message Queuing Telemetry Transport (MQTT) protocol that is now standardized
by the Organization for the Advancement of Structured Information Standards
(OASIS).
• Reliable, lightweight, and cost-effective protocol to monitor and control a large
number of sensors and their data from a central server location, as typically used
by the oil and gas industries
• An MQTT client can act as a publisher to send data (or resource information) to an
MQTT server acting as an MQTT message broker. In the example illustrated in Figure
2.22,
• The MQTT client on the left side is a temperature (Temp) and relative humidity (RH)
sensor that publishes its Temp/RH data.
• The MQTT server (or message broker) accepts the network connection along with
application messages, such as Temp/RH data, from the publishers.
• It also handles the subscription and un-subscription process and pushes the
application data to MQTT clients acting as subscribers.
• The application on the right side of Figure 2.22 is an MQTT client that is a subscriber
to the Temp/RH data being generated by the publisher or sensor on the left.
MQTT Publish/Subscribe Framework
• MQTT is a lightweight protocol because each control packet consists of a
2-byte fixed header with optional variable header fields and optional
payload.
• You should note that a control packet can contain a payload up to 256
MB. Figure 2.23 provides an overview of the MQTT message format.
• Compared to the CoAP message format, MQTT contains a smaller header
of 2 bytes compared to 4 bytes for CoAP. The first MQTT field in the
header is Message Type, which identifies the kind of MQTT packet within a
message.
MQTT Message Format