Module 3

IoT Protocol Suite

IoT Protocol Suite - Topics

• Physical layer,
• Link layer -BLE, LoRaWAN
• Network layer,
• Transport layer,
• Application Layer protocols - MQTT, CoAP
• Communication Models.
Layer’s - Architecture of IoT

3 Layer 5 Layer
3 Layer- Architecture of IoT
• The perception layer is the physical layer, which
has sensors for sensing and gathering information
about the environment. It senses some physical
parameters or identifies other smart objects in the
environment.
• The network layer is responsible for connecting to
other smart things, network devices, and servers. Its
features are also used for transmitting and
processing sensor data. (BLE, Wi-Fi, LoRAWAN)
• The application layer is responsible for delivering
application specific services to the user. It defines
various applications in which the Internet of
Things can be deployed, for example, smart homes,
smart cities, and smart health.
5 Layer- Architecture of IoT
• The perception layer is the physical layer, which
has sensors for sensing and gathering information
about the environment. It senses some physical
parameters or identifies other smart objects in the
environment.
• The transport layer transfers the sensor data from
the perception layer to the processing layer and vice
versa through networks such as wireless, 3G, LAN,
Bluetooth, RFID, and NFC.
• The processing layer is also known as the
middleware layer. It stores, analyzes, and processes
huge amounts of data that comes from the transport
layer. It can manage and provide a diverse set of services to the lower
layers. It employs many technologies such as databases, cloud computing, and
big data processing modules
5 Layer- Architecture of IoT
• The application layer is responsible for delivering
application specific services to the user. It defines
various applications in which the Internet of
Things can be deployed, for example, smart homes,
smart cities, and smart health.
• The business layer manages the whole IoT system,
including applications, business and profit models,
and users’ privacy.
• This Layer also has the responsibility to design, analyze,
implement, evaluate, and monitor the requirements of
the IoT system.
• This layer can use big data analysis to support decision-
making activities.
• performs a comparison of obtained versus expected
outputs to enhance the quality of services.
Arrangement of Protocols in IoT

A binary format is a format in which file information is stored in the form of ones and zeros, or in some other binary (two-state) sequence.
Concise Binary Object Representation (CBOR) is a binary data serialization format loosely based on JSON
JSON – Java Script Object Notation
UDP – User datagram Protocol
Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing
them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery.
CoAP – Constrained Application protocol
MQTT – Message Queuing Telemetry Transport ;
Extensible Messaging and Presence Protocol is an open communication protocol designed for instant messaging (IM), presence information,
and contact list maintenance. Based on XML (Extensible Markup Language), it enables the near-real-time exchange of structured data
between two or more network entities.
 IoT Access Technologies
• The technologies that IoT access for connectivity.
• Topics addressed:
• Physical layers (The wired or wireless methods and relevant
frequencies)
• MAC layers (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)
IoT Access Technologies
IEEE 802.15.4: an older but foundational wireless protocol for connecting
smart objects.
IEEE 802.15.4g and IEEE 802.15.4e: are targeted to utilities and smart cities
deployments.
IEEE 1901.2a: which is a technology for connecting smart objects over
power lines.
IEEE 802.11ah: a technology built on the well-known 802.11 Wi-Fi
standards that is specifically for smart objects.
BLE: Bluetooth Low Energy
LoRaWAN (Long Range Wide Area Network): a scalable technology
designed for longer distances with low power requirements in the unlicensed
spectrum.
NB-IoT (Narrow band – IoT) and Other LTE (Long-Term Evolution – 4G)
Variations: which are often the choice of mobile service providers looking to
connect smart objects over longer distances in the licensed spectrum.
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.
• Low cost , a reasonable battery life,
• Enables easy installation using a compact protocol
stack while remaining both simple and flexible.
Applications - IEEE 802.15.4

• Commonly found in the following types of

deployments:
• Home and building automation
• Automotive networks
• Industrial wireless sensor networks
• Interactive toys and remote controls
• This standard is a well known solution for low-
complexity wireless devices with low data rates that
need many months or even years of battery life.
Protocol stacks based on 802.15.4
• 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
IEEE 802.15.4g and 802.15.4e

• The IEEE frequently makes amendments to the core

802.15.4 specification, before integrating them into
the next revision of the core specification.
• these amendments are made, a lowercase letter is
appended.
• Two such examples of this are 802.15.4e-2012 and
802.15.4g-2012, both of which are especially
relevant to the subject of IoT.
IEEE 802.15.4e amendment:

• Expands the MAC layer feature set to remedy the

disadvantages associated with 802.15.4, including MAC
reliability, unbounded latency, and multipath fading.
• Made improvements to better cope with certain
application domains, such as factory and process
automation and smart grid.
• IEEE 802.15.4e-2012 enhanced the IEEE 802.15.4 MAC
layer capabilities in the areas of frame format, security,
determinism mechanism, and frequency hopping.
IEEE 802.15.4g-2012:

• The focus of this specification is the smart grid or, more

specifically, smart utility network communication.
• This technology applies to IoT use cases such as the following:
• Distribution automation and industrial supervisory control and
data acquisition (SCADA) environments for remote monitoring
and control.
• Public lighting
• Environmental wireless sensors in smart cities
• Electrical vehicle charging stations
• Smart parking meters
• Microgrids
• Renewable energy
IEEE 1901.2a

• IEEE 1901.2a-2013 is a wired technology that is an

update to the original IEEE 1901.2 specification.
• This is a standard for Narrowband Power Line
Communication (NB-PLC).
• NB-PLC is often found in use cases such as the
following
• Smart metering: NB-PLC can be used to automate the reading of
utility meters, such as electric, gas, and water meters. This is true
particularly in Europe, where PLC is the preferred technology for
utilities deploying smart meter solutions.
• Distribution automation: NB-PLC can be used for distribution
automation, which involves monitoring and controlling all the devices in
the power grid.
• Public lighting: A common use for NB-PLC is with public lighting—the
lights found in cities and along streets, highways, and public areas such
as parks.
• Electric vehicle charging stations: NB-PLC can be used for electric
vehicle charging stations, where the batteries of electric vehicles can be
recharged.
• Microgrids: NB-PLC can be used for microgrids, local energy grids that
can disconnect from the traditional grid and operate independently.
• Renewable energy: NB-PLC can be used in renewable energy
applications, such as solar, wind power, hydroelectric, and geothermal
heat.
IEEE 802.11ah
• In unconstrained networks, IEEE 802.11 Wi-Fi is
certainly the most successfully deployed wireless
technology.
• This standard is a key IoT wireless access technology,
either for connecting endpoints such as
• fog computing nodes,
• high-data-rate sensors,
• audio or video analytics devices or for deploying
Wi-Fi backhaul infrastructures, such as
• outdoor Wi-Fi mesh in smart cities,
• oil and mining
IEEE 802.11 Drawbacks

• Wi-Fi lacks sub-GHz support for better signal

penetration, low power for battery-powered nodes,
and the ability to support a large number of devices.
• For these reasons, the IEEE 802.11 working group
launched a task group named IEEE 802.11ah to
specify a sub-GHz version of Wi-Fi.
Use cases are identified for IEEE
802.11ah
• Sensors and meters covering a smart grid:
• Meter to pole, environmental/agricultural
monitoring, industrial process sensors, indoor
healthcare system and fitness sensors, home and
building automation sensors
• Backhaul aggregation of industrial sensors and
meter data:
• Potentially connecting IEEE 802.15.4g subnetworks
• Extended range Wi-Fi:
• For outdoor extended-range hotspot or cellular
traffic offloading when distances already covered by
IEEE 802.11a/b/g/n/ac are not good enough
Bluetooth 4.0: Low Energy

22
How much energy does traditional Bluetooth use?
• Traditional Bluetooth is connection oriented. When a
device is connected, a link is maintained, even if there
is no data flowing.
• Sniff modes allow devices to sleep, reducing power
consumption to give months of battery life
• Peak transmit current is typically around 25mA
• Even though it has been independently shown to be
lower power than other radio standards, it is still not
low enough power for coin cells and energy harvesting
applications

23
What is Bluetooth Low Energy?
• Bluetooth low energy is a NEW, open, short range radio
technology
• Blank sheet of paper design
• Different to Bluetooth classic (BR/EDR)
• Optimized for ultra low power
• Enable coin cell battery use cases
• < 20mA peak current
• < 5 uA average current

24
Basic Concepts of Bluetooth 4.0
• Everything is optimized for lowest power consumption
• Short packets reduce TX peak current
• Short packets reduce RX time
• Less RF channels to improve discovery and connection
time
• Simple state machine
• Single protocol
• Etc.

25
 Bluetooth low energy factsheet
Range: ~ 150 meters open field
Output ~ 10 mW (10dBm)
Power:
Max Current: ~ 15 mA
Latency: 3 ms
Topology: Star
Connections: > 2 billion
Modulation: GFSK @ 2.4 GHz
Robustness: Adaptive Frequency Hopping, 24 bit CRC
Security: 128bit AES CCM
Sleep current: ~ 1μA
Modes: Broadcast, Connection, Event Data Models,
Reads, Writes
26
Bluetooth low energy factsheet #2
• Data Throughput
• For Bluetooth low energy, data throughput is not a
meaningful parameter. It does not support
streaming.
• It has a data rate of 1Mbps, but is not optimized for
file transfer.
• It is designed for sending small chunks of data
(exposing state)

27
Bluetooth low energy factsheet #2
• BLE (Bluetooth Low Energy) is wireless PAN technology designed and
maintained by Bluetooth Special Interest Group (SIG). There are
various versions of bluetooth. The version 4.2 and above is referred
as BLE. The latest in the series are v5.0 and v5.1. BLE specifications
are intended to reduce power consumption and cost of devices while
maintaining coverage range. BLE is known as "Bluetooth Smart"
where as previous version is known as "bluetooth classic".
• BLE is not backward compatible with BR/EDR protocols.
• BLE uses 2.4 GHz ISM frequency band either in dual mode or single
mode. Dual mode supports both bluetooth classic and low energy
peripherals.
• All BLE devices use the GATT profile (Generic Attribute Profile). The
GATT protocol provides series of commands for the client to discover
information about BLE server.
• The BLE protocol stack architecture consists of two parts viz.
controller and host. Both are interfaced using HCI (Host to Controller
Interface). Any profiles and applications run on top of GAP & GATT 28
protocol layers.
Device Modes
• Dual Mode
• Bluetooth BR/EDR and LE
• Used anywhere that BR/EDR
is used today

• Single Mode
• Implements only Bluetooth low energy
• Will be used in
new devices / applications

29
Device Modes
• Dual mode + single modes
BR/EDR stack Dual-mode stack Single-mode stack

30
Bluetooth Low Energy Architecture

31
Physical Layer
• 2.4 GHz ISM band
• 1Mbps GFSK
• Larger modulation index than Bluetooth BR (which means
better range)
• 40 Channels on 2 MHz spacing
• The transmitter uses GFSK modulation and operates at unlicensed
2.4 GHz frequency band.
• Using this PHY layer, BLE offers data rates of 1 Mbps (Bluetooth
v4.2)/2 Mbps (Bluetooth v5.0).
• It uses frequency hopping transceiver.
• Two modulation schemes are specified to deliver 1 Msym/s and 2
Msym/s.
• Two PHY layer variants are specified viz. uncoded and coded.
A Time Division Duplex (TDD) topology is employed in both of32 the
PHY modes.
Link Layer
• Link Layer state machine
This layer sits above the Physical layer. It
is responsible for advertising, scanning,
and creating/maintaining connections.
The role of BLE devices changes in peer
to peer (i.e. Unicast) or broadcast modes.
The common roles are Advertiser/Scanner
(Initiator), Slave/Master or
Broadcaster/Observer. Link layer states
are defined in the figure below.

33
Link Layer Connection
• Very low latency connection

34
 Bluetooth Low Energy Architecture

• HCI : It provides communication between

controller and host through standard interface
types. This HCI layer can be implemented
either using API or by interfaces such as
UART/SPI/USB. Standard HCI commands
and events are defined in the bluetooth
specifications.

• L2CAP :This layer offers data

encapsulation services to upper layers. This
allows logical end to end data
communication.

• SMP :This security Manager layer provides

methods for device pairing and key
distributions. It offers services to other
protocol stack layers in order to securely
connect and exchange data between BLE
35
devices.
 Bluetooth Low Energy Architecture

• GAP : This layer directly interfaces with

application layer and/or profiles on it. It
handles device discovery and connection
related services for BLE device. It also takes
care of initiation of security features.

• GATT : This layer is service framework

which specifies sub-procedures to use ATT.
Data communications between two BLE
devices are handled through these sub-
procedures. The applications and/or profiles
will use GATT directly.

• ATT : This layer allows BLE device to expose

certain pieces of data or attributes.

36
Bluetooth Low Energy Architecture
• Application Layer :
• The BLE protocol stack layers interact with applications
and profiles as desired. Application interoperability in the
Bluetooth system is accomplished by Bluetooth profiles.
• The profile defines the vertical interactions between
the layers as well as the peer-to-peer interactions of
specific layers between devices.
• A profile composed of one or more services to address
particular use case. A service consists of characteristics
or references to other services.
• Any profiles/applications run on top of GAP/GATT
layers of BLE protocol stack. It handles device discovery
and connection related services for the BLE device.

37
What are the USE CASES planned for
BT 4.0?
• Proximity • HVAC
• Time • Generic I/O (automation)
• Emergency • Battery status
• Network availability • Heart rate monitor
• Personal User Interface • Physical activity monitor
• Simple remote control • Blood glucose monitor
• Browse over Bluetooth • Cycling sensors
• Temperature Sensor • Pulse Oximeter
• Humidity Sensor • Body thermometer
38
Example use: proximity
• It can enable proximity detection
• I’m in the car
• I’m in the office
• I’m in the meeting room
• I’m in the movie theater
• It can enable presence detection
• Turn the lights on when I walk around the house
• Automatically locks the door when I leave home
• Turn the alarm off if I’m already awake

39
Everyday objects can become sensors
My pulse is … My blood glucose is …

My temperature is …

… and monitor things unobtrusively

40
LoRaWAN
• A new set of wireless technologies known as Low-
Power Wide-Area (LPWA) has
• Particularly well adapted for long-range and
battery-powered endpoints.
• An unlicensed-band LPWA technology, known as
LoRaWAN
LoRaWAN
 LoRaWAN
• Deployed in a star-of-stars topology
• Have base stations relaying the data between sensor
nodes & network server
• Communication between sensor nodes & BS goes
over the wireless channel utilizing LoRa physical
layer, whilst the connection between gateways &
central server are over a backbone IP-based network
• End Nodes transmit directly to all gateways within
range, using LoRa
• Gateways relay messages between end-devices &
central network server using IP
LoRa Use Cases
LoRaWAN Layers
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.
• 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.
Frequency bands
• 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.
• For example, Australia utilizes 915–928 MHz
frequency bands, while
• South Korea uses 920–923 MHz and
• Japan uses 920–928 MHz.
Spreading factor
• An important feature of LoRa is its ability to handle
various data rates via the spreading factor.
• 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.
LoRaWAN Data Rate Example
MAC Layer
• 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,
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 its receive window open when not
transmitting.
High-Level LoRaWAN MAC Frame
Format
• 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 bytes for the 863–870 MHz
band and 19 to 250bytes for the 902–928 MHz band. Figure
shows a high-level LoRaWAN MAC frame format.
Topology
• LoRaWAN topology is often described as a “star of
stars” topology.
• 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.
LoRaWAN Topology
LoRaWAN - Topology
• A “star of stars” topology
• 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
• 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.
• The LoRaWAN network server manages the data rate and radio
frequency (RF) of each endpoint through the adaptive data rate (ADR)
algorithm.

02:32 AM 55
LoRaWAN
Topology
• LoRaWAN endpoints transport their selected application
data over the LoRaWAN MAC layer on top of one of the
supported PHY layer frequency bands.
• The application data is contained in upper protocol layers.
• These upper layers could just be raw data on top of the
LoRaWAN MAC layer, or the data could be stacked in
multiple protocols.
• For example, upper-layer protocols,
• ZigBee Control Layer (ZCL), Constrained Application Protocol
(CoAP), Message Queuing Telemetry Transport (MQTT), or
with/without IPv6/6LoWPAN layer.

02:32 AM 56
Security
• Security in a LoRaWAN deployment applies to
different components of the architecture.
• LoRaWAN endpoints must implement two layers of
security,
• protecting communications and
• data privacy across the network.
LoRaWAN - Security

02:32 AM 58
LoRaWAN - Security
• LoRaWAN endpoints must implement two layers of
security,
• Protecting communications
• Data privacy across the network.

02:32 AM 59
LoRaWAN - Security
• Protecting communications
• Also called “network security” but applied at the MAC layer,
• guarantees the authentication of the endpoints by the
LoRaWAN network server.
• It protects LoRaWAN packets by performing encryption
based on AES.
• Each endpoint implements a network session key
(NwkSKey), used by both itself and the LoRaWAN network
server.
• The NwkSKey ensures data integrity through computing and
checking the MIC of every data message as well as encrypting and
decrypting MAC-only data message payloads.

02:32 AM 60
LoRaWAN - Security
• Data privacy :
• An application session key (AppSKey), which performs
encryption and decryption functions between the endpoint
and its application server.
• It computes and checks the application-level MIC, if
included.
• This ensures that the LoRaWAN service provider does not have
access to the application payload if it is not allowed that access.
• Endpoints receive their AES-128 application key (AppKey)
from the application owner.
• This key is most likely derived from an application-specific root key
exclusively known to and under the control of the application
provider.

02:32 AM 61
LoRaWAN - Security
• LoRaWAN endpoints attached to a LoRaWAN network must get
registered and authenticated.
• This can be achieved through one of the two join mechanisms:
• Activation by personalization (ABP):
• Endpoints don’t need to run a join procedure as their individual details, including
DevAddr and the NwkSKey and AppSKey session keys, are preconfigured and
stored in the end device. This same information is registered in the LoRaWAN
network server.
• Over-the-air activation (OTAA):
• Endpoints are allowed to dynamically join a particular LoRaWAN network after
successfully going through a join procedure. The join procedure must be done
every time a session context is renewed. During the join process, which involves
the sending and receiving of MAC layer join request and join accept messages,
the node establishes its credentials with a LoRaWAN network server, exchanging
its globally unique DevEUI, AppEUI, and AppKey. The AppKey is then used to
derive the session NwkSKey and AppSKey keys.

02:32 AM 62
 End Nodes are LoRa embedded sensors

End Nodes typically have:

• Sensors: detect the changing parameter eg. temperature,
humidity, accelerometer, gps)
• LoRa transponder: transmit signals over LoRa patented
radio transmission method LoRa sensors can transmit signals over distances
• optionally a micro-controller (with on board Memory) from 1km — 10km
Gateways
• always connected to
power source
• connect to network
server via standard IP
connections Network servers :
• act as a transparent • cloud based platform solutions, e.g., The Things Network (TTN) or LoRIOT
bridge, simply • connect to gateways & de-dup data packets, and then routes it to the relevant application
converting RF packets to • can be used for both uplink (i.e. sensor to application) or downlink (i.e. application to sensor)
IP packets & vice versa. communication
Main Characteristics of different
Access Technologies

02:32 AM 65
Network Layer
• Network layer connectivity, which is commonly referred to as
Layer 3.
• The network transport layer sublayer that is part of the
communications network layer.
• IP Versions
• Transitioning the Internet from IP version 4 to IP version 6. The
main driving force has been the lack of address space in IPv4 as the
Internet has grown.
• IPv6 has a much larger range of addresses that should not be
exhausted for the foreseeable future.
• Today, both versions of IP run over the Internet, but most
traffic is still IPv4 based.
IP Versions
• Internet of Things support both IPv4 and IPv6 versions
concurrently.
• Techniques such as tunneling and translation need to be
employed in IoT solutions to ensure interoperability
between IPv4 and IPv6.
• A variety of factors dictate whether IPv4, IPv6, or both
can be used in an IoT solution.
• Most often these factors include a legacy protocol or
technology that supports only IPv4.
• Newer technologies and protocols almost always support
both IP versions
Main factors applicable to IPv4 and
IPv6 support in an IoT solution
• Application Protocol:
• IoT devices implementing Ethernet or Wi-Fi interfaces
can communicate over both IPv4 and IPv6, but the
application protocol may dictate the choice of the IP
version.
• For example, SCADA protocols such as DNP3/IP (IEEE
1815), Modbus TCP, or the IEC 60870-5-104 standards
are specified only for IPv4.
• For IoT devices with application protocols defined by the
IETF, such as HTTP/HTTPS, CoAP, MQTT, and XMPP, both
IP versions are supported
• Cellular Provider and Technology:
• IoT devices with cellular modems are dependent on the
generation of the cellular technology as well as the data
services offered by the provider.
• For the first three generations of data services—GPRS,
Edge, and 3G—IPv4 is the base protocol version.
• Consequently, if IPv6 is used with these generations, it
must be tunneled over IPv4.
• On 4G/LTE networks, data services can use IPv4 or IPv6
as a base protocol, depending on the provider.
• Serial Communications:
• Many legacy devices in certain industries, such as
manufacturing and utilities, communicate through serial
lines. Data is transferred using either proprietary or
standardsbased protocols, such as DNP3, Modbus, or IEC
60870-5-101.
• Encapsulation of serial protocols over IP leverages
mechanisms such as raw socket TCP or UDP. While raw
socket sessions can run over both IPv4 and IPv6,
current implementations are mostly available for IPv4
only.
Constrained Nodes
• Depending on its functions in a network, a “thing”
architecture may or may not offer similar
characteristics.
• 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
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.
• 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.
Constrained Networks
• Network bandwidth capacity was restrained due to
technical limitations. Connections often depended
on low-speed modems for transferring data.
However, these low-speedconnections
demonstrated that IP could run over low-
bandwidth networks.
• Networking has seen the emergence of high-speed
infrastructures. However, high-speed connections
are not usable by some IoT devices in the last mile.
 • implementation of technologies with low bandwidth,
• limited distance and bandwidth due to regulated
transmit power, and
• lack of or limited network services
• A constrained network can have high latency and a
high potential for packet loss.
Constrained Networks
• Constrained networks are often referred to as low-power and
lossy networks (LLNs).
• Lossy in this context refers to network unreliability that is
caused by disruptions in the data flow or 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
• 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 behaviors 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.
• Due to the low bandwidth, a constrained network that
overreacts can lead to a network collapse.
• This in turn has led various standards organizations to work on
optimizing protocols for IoT
 Optimizing IP for IoT
• 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.
Optimizing IP for IoT Using an
Adaptation Layer

• From 6LoWPAN to 6Lo:

• 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
IoT Application Layer Protocols
• IoT industry is working on new lightweight protocols
that are better suited to large numbers of constrained
nodes and networks.
• Two of the most popular protocols are CoAP and MQTT.

• Example of a High-Level IoT Protocol Stack for CoAP and MQTT

CoAP
• 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 messaging model is primarily designed to
facilitate the exchange of messages over UDP
between endpoints, including the secure transport
protocol Datagram Transport Layer Security (DTLS).
CoAP message format
• 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.
CoAP Message Fields
 CoAP Protocol Message Exchanges
There are two modes in which CoAP protocol messages get exchanged between
CoAP client and CoAP server viz. without separate response and with separate
response.
With separate response, server notifies client about receipt of the request message.
This will increase processing time but help in avoiding unnecessary retransmissions.

CoAP IoT is unreliable protocol due to use of UDP. Hence CoAP messages reach
unordered or will get lost when they arrive at destination.
To make CoAP as reliable protocol, stop and wait with exponential backoff
retransmission feature is incorporated in it. Duplicate detection is also introduced.
CoAP Communications in IoT
Infrastructures
• 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.
• As both HTTP and CoAP are IP-based protocols, the
proxy function can be located practically
anywhere in the network, not necessarily at the
border between constrained and non-constrained
networks.
• CoAP is based on the REST architecture, but with a
“thing” acting as both the client and the server.
• Through the exchange of asynchronous messages, a
client requests an action via a method code on a server
resource.
• A uniform resource identifier (URI) localized on the server
identifies this resource.
• The server responds with a response code that may
include a resource representation.
• The CoAP request/response semantics include the
methods GET, POST, PUT, and DELETE.
CoAP Reliable Transmission
Example
CoAP Protocol: Step-by-Step
Guide
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
 CoAP Protocol: Step-by-Step
Guide
From the abstraction protocol layer, CoAP
can be represented as:
As you can see there are two different layers
that make CoAp protocol:
Messages and Request/Response. 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 different message types:
•Confirmable
•Non-confirmable
•Acknowledgment
•Reset
 CoAP Protocol: Step-by-Step
Guide
CoAp protocol, structure is useful to define some terms that
we will use later:
Endpoint: An entity that participates in the CoAP protocol.
Usually, an Endpoint is identified with a host
Sender: The entity that sends a message
Recipient: The destination of a message
Client: The entity that sends a request and the destination of
the response
Server: The entity that receives a request from a client and
sends back a response to the client
 CoAP Protocol: Step-by-Step
Guide
CoAP protocol uses two kinds of messages:
• Confirmable message
• Non-confirmable message
A confirmable 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 Confirmable message (CON). Using this
kind of message, the client can be sure that the message
will arrive at the server. A Confirmable message is sent
again and again until the other party sends an acknowledge
message (ACK). The ACK message contains the same ID of
the confirmable message (CON).
 CoAP Protocol: Step-by-Step
•
Guide
Confirmable message

If the server has troubles managing the

incoming request, it can send back a Rest
message (RST) instead of the Acknowledge
message (ACK):
 CoAP Protocol: Step-by-Step
Guide
Non-confirmable (NON) messages.
These are messages that don’t require an Acknowledge by the
server. They are unreliable messages or in other words
messages that do not contain critical information that must be
delivered to the server. To this category belongs messages that
contain values read from sensors.
Even if these messages are unreliable, they have a unique ID.
CoAP message, there is a Token. The Token is
different from the Message-ID and it is used
to match the request and the response.
 CoAP Protocol: Step-by-Step
Guide
If the server can’t answer to
the request coming from the
client immediately, then it
sends an Acknowledge
message with an empty
response. As soon as the
response is available, then the
server sends a new
Confirmable message to the
client containing the
response. At this point, the
client sends back an
Acknowledge message:
If the request coming from the client is
carried using a NON-confirmable message,
then the server answer using a NON-
confirmable message.
Message Queuing Telemetry Transport (MQTT)

• A 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.
• Standardized by the Organization for the
Advancement of Structured Information Standards
(OASIS).
• Considering the harsh environments in the oil and
gas industries, an extremely simple protocol with
only a few options was designed, with considerations
for constrained nodes, unreliable WAN backhaul
communications, and bandwidth constraints with
variable latencies.
MQTT Publish/Subscribe Framework
Message:
• When the message is
transmitted over the
network, then the message
contains the following
parameters:
1. Payload data
2. Quality of Service (QoS)
3. Collection of Properties
4. Topic Name

The clients subscribe to the topics to publish and receive

messages.
Publish: When the client sends the data to the server, then we
call this operation as a publish.
Subscribe: When the client receives the data from the server,
then we call this operation a subscription.
MQTT Publish/Subscribe Framework
• Server accepts the
network connection
from the client,
accepts the messages
from the client,
processes the
subscribe and
unsubscribe requests,
forwards the
application messages
to the client, and
closes the network
connection from the
client.
MQTT Message Types
• The next field in the MQTT header is DUP (Duplication Flag). This
flag, when set, allows the client to notate that the packet has been
sent previously, but an acknowledgement was not received.
• The QoS header field allows for the selection of three different QoS
levels.
• The next field is the Retain flag. Only found in a PUBLISH message.
• The Retain flag notifies the server to hold onto the message data.
This allows new subscribers to instantly receive the last known
value without having to wait for the next update from the
publisher.
• The last mandatory field in the MQTT message header is Remaining
Length. This field specifies the number of bytes in the MQTT packet
following this field.
MQTT Packet Format

The MQTT packet consists of 2-byte fixed header + a

variable header and a payload. In this first 2-byte fixed
header will be always present in all the packets and the
other two, variable header and payload are not always
present.
 MQTT Packet Format
Command type
Out of the two-byte fixed
header, the first byte is the
control field. This 8-bit
control field Is divided into
two 4 bit fields. The first 4
MSB bits are the command
type field.
E.g. The value of the
connect command is 1.
That means for connect
command the connect type
field should be 1 which is
0001. For publish
command the value is 3,
therefore, the connect type
field should be 0011.
 MQTT Packet Format
Control Flag bits
The next 4 bits are the control
flag bits and they are used by
the publish command for the
rest of the commands they are
reserved and the value will be
0.
For PUBLISH command:
0th bit denotes if the message
that is published is retained
the message.
1st and 2nd bits are used to
select the quality of service if
it is 0 or 1 or 2.
And the 3rd bit denotes if it is
a duplicate message.
 MQTT Packet Format
Remaining Length
The second byte of the fixed header contains the remaining length which is,
length of variable header + the length of the payload. Remaining length can
use up to 4 bytes in which each byte uses 7 bits for the length and the MSB
bit being a continuation flag.
if the continuation flag bit of a byte is 1, it means the next byte is also part of
the remaining length. And if the continuation flag bit is 0, it means that byte
is the last one of the remaining length.
E.g. if the variable header length is 10 and the length of the payload is 20, the
remaining length should be 30.
Variable header
A variable header is not present in all the MQTT packets. Some MQTT
commands or messages use this field to provide additional information or
flags and they vary depending on the packet type. A packet identifier is
common in most of the packets types. We will discuss in detail the variable
header for the CONNECT packet below.
MQTT QoS Flows
MQTT Application
• Home pacemaker monitoring solution
• Sensors on patient
• Collected by a monitoring equipment in home
(broker) using MQTT
• Subscribed by a computer in the hospital
• Alerts the doctor if anything is out-of-order
Comparison Between CoAP and MQTT
IoT Communication Models
 IoT devices are found everywhere and will enable circulatory
intelligence in the future.
 For operational perception, it is important and useful to understand
how various IoT devices communicate with each other.
 Communication models used in IoT have great value. The IoTs allow
people and things to be connected any time, any space, with anything
and anyone, using any network and any service.
• Types of Communication Models :
 Request-Response Model
 Publish-Subscribe Model
 Push-Pull Model
 Exclusive Pair Model
Request-Response 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.
 Request-Response model is a stateless communication
model and each request-response pair is independent of
others. Figure 1.7 shows the client-server interactions in the
request-response model.
Request-Response model
Publish-Subscribe 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. Figure 1.8 shows the publisher-broker-
consumer interactions
Publish-Subscribe model
Push-Pull model
• Push-Pull : 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 rate at which the consumers pull
data.
• Figure 1.9 shows the publisher-queue-consumer interactions
in the push-pull model.
Push-Pull model
Exclusive Pair model
 Exclusive Pair : Exclusive Pair is a bi-directional, fully
duplex communication model that uses a persistent
connection between the client and server.
 Once the connection is setup 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.
 Exclusive pair is a stateful communication model and
the server is aware of all the open connections.
• Figure 1.10 shows the client-server interactions in
the exclusive pair model.
IoT Communication Models