MODULE – 3

Business case for IP

KeyAdvantages of IP in IoT
What is IP? Internet Protocol (IP) is a standardized set of rules that enables devices in IoT
systems (e.g., sensors, smart devices, servers) to communicate by routing data across
networks. It underpins the internet and supports both IPv4 and IPv6, making it critical for
connecting IoT devices globally.

Advantages of IP in IoT:

• Open and Standards-Based: Developed by the IETF, IP ensures IoT devices are
interoperable, secure, and compatible across vendors, unlike proprietary systems,
fostering widespread adoption.

• Versatile: IP works with various IoT connectivity technologies (e.g., Wi-Fi, Ethernet,
cellular) and adapts to new ones, supporting the 10-20 year lifespan of IoT solutions
without needing major redesigns.

• Ubiquitous: Most IoT devices, from tiny sensors (running TinyOS, Contiki) to servers,
have built-in IP stacks (IPv4/IPv6). Many IoT industrial protocols now use IP, easing
integration.

• Scalable: IP handles billions of devices, as proven by the internet, making it ideal

for large-scale IoT deployments like smart cities or industrial networks.

• Manageable and Secure: IP’s 30-year history provides robust network management
and security tools, ensuring reliable and safe IoT operations.

• Stable and Resilient: IP’s reliability in critical IoT applications (e.g., industrial
control, smart grids) is backed by its use in finance and defense, supported by a vast
expert ecosystem.

• Consumer Market Fit: IP connects IoT devices (e.g., smart home gadgets) to
consumer platforms like smartphones and tablets over broadband or mobile
networks.

• Drives Innovation: IP enables IoT innovations, supporting applications like remote

monitoring, smart appliances, and cloud-based analytics, similar to its role in web
and mobile advancements.
Adoption vs. Adaptation of IP in IoT
Adoption:

• Definition: Using IP directly across all IoT devices and networks for end-to-end
communication, replacing non-IP protocols.

• IoT Example: Smart factory SCADA devices using Ethernet and IPv4 to send data
directly to control systems via routers.

• Benefits:

o Simplifies IoT network design and management.

o Enables seamless data exchange between any IoT device and application.

o Leverages IP’s scalability, security, and tools for large IoT systems.

• Challenges:

o Requires a full IP stack, adding overhead (e.g., IPv4: 20-byte header, IPv6: 40-
byte header), which can be inefficient for low-power IoT devices sending
small data packets (e.g., sensors).

Adaptation:

• Definition: Using gateways to translate between non-IP protocols (used by IoT

devices) and IP networks, allowing non-IP devices to connect to IP-based systems.

• IoT Example: ZigBee smart home devices (non-IP) communicating via a gateway
that translates data to IP for cloud servers.

• Benefits:

o Ideal for resource-constrained IoT devices (e.g., battery-powered sensors)

sending small, infrequent data, avoiding the need for a full IP stack.

o Supports unidirectional communication (e.g., fire alarms sending alerts).

• Challenges:

o Gateways add complexity and cost to IoT deployments.

o Non-IP devices are limited to specific protocols (e.g., ZigBee), reducing

flexibility and interoperability.
 o Unidirectional systems may not support firmware updates or two-way
communication.

Factors Influencing Adoption vs. Adaptation in IoT:

• Data Flow: Adoption suits IoT systems needing end-to-end communication (e.g.,
real-time industrial monitoring); adaptation works for devices sending data to one or
two applications (e.g., smart meters).

• Overhead: Adaptation is better for low-power, wide-area (LPWA) IoT devices with
minimal data, reducing header overhead; adoption may overburden such devices.

• Communication Type: Unidirectional IoT devices (e.g., water meters) favor

adaptation; bidirectional systems (e.g., smart thermostats) benefit from adoption.

• Network Diversity: Adaptation locks IoT devices to specific protocols (e.g., ZigBee
networks), limiting scalability; adoption supports diverse IoT network types,
enhancing flexibility.

Need for Optimization in IoT

Unlike traditional internet devices (e.g., PCs, servers), many IoT devices and networks
operate under severe constraints, such as limited power, processing capacity, and
bandwidth.

To enable the Internet Protocol (IP) in such environments, optimization is critical.

Optimization ensures that IP-based IoT solutions are efficient, scalable, and interoperable,
meeting both technical and business requirements.

IoT deployments differ significantly from traditional IP networks due to the resource
limitations of devices and networks.

Constrained Nodes
Constrained nodes are IoT devices with limited computational resources, such as
processing power, memory, storage, and energy.

These devices include sensors, actuators, and microcontrollers used in applications like
smart homes, industrial automation, and agriculture.

Characteristics of Constrained Nodes

 • Low Processing Power: Constrained nodes often use low-cost microcontrollers
(e.g., 8-bit or 16-bit processors) with clock speeds in the range of a few MHz,
compared to GHz processors in traditional devices.

• Limited Memory: Typically, these devices have:

o RAM: A few kilobytes (e.g., 10–50 KB).

o Flash Storage: Tens to hundreds of kilobytes (e.g., 128–512 KB).

o This restricts the size of the protocol stack and application logic.

• Energy Constraints: Many IoT devices are battery-powered or energy-harvesting,

requiring ultra-low power consumption to operate for months or years without
battery replacement.

• Small Form Factor: Physical size constraints limit the inclusion of powerful
hardware or large batteries.

Why Optimization is Needed

• IP Stack Overhead: Standard IP stacks (e.g., TCP/IP, UDP/IP) are designed for
resource-rich devices and are too heavy for constrained nodes. For example, a full
IPv6 stack may require significant memory and processing power.

• Energy Efficiency: Running complex protocols increases power consumption,

draining batteries quickly.

• Cost Sensitivity: IoT deployments often involve thousands or millions of devices, so

optimizing hardware and software reduces per-unit costs.

Optimization Strategies

• Lightweight Protocols:

o 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks):

Compresses IPv6 headers to fit within the small packet sizes of constrained
nodes (e.g., 127 bytes in IEEE 802.15.4).

o CoAP (Constrained Application Protocol): A lightweight, RESTful protocol

running over UDP, designed for low-memory devices.

o MQTT-SN (MQTT for Sensor Networks): A version of MQTT optimized for low-
power, constrained devices.

• Reduced Stack Size:

 o Use minimalistic IP stacks that exclude unnecessary features (e.g., omitting
TCP for UDP-based communication).

o Employ header compression techniques to reduce protocol overhead.

• Low-Power Hardware:

o Use energy-efficient microcontrollers (e.g., ARM Cortex-M series) and low-

power radio transceivers.

o Implement sleep modes to minimize energy consumption during idle

periods.

• Firmware Optimization:

o Write compact firmware to maximize the use of limited flash storage.

o Use event-driven programming to reduce CPU cycles.

Example

In a smart agriculture system, soil moisture sensors (constrained nodes) use 6LoWPAN
and CoAP to transmit data over a low-power IEEE 802.15.4 network.

These sensors operate on small batteries, using sleep modes to conserve energy and
compressed IPv6 headers to minimize memory usage, enabling years of operation without
maintenance.

Constrained Networks
Constrained networks are communication networks used in IoT with limitations in
bandwidth, reliability, and power.

These networks include wireless technologies like IEEE 802.15.4, Bluetooth Low Energy
(BLE), and LoRaWAN, often deployed in challenging environments (e.g., industrial plants,
remote areas).

Characteristics of Constrained Networks

• Low Bandwidth:

o Data rates are typically in the range of tens to hundreds of kbps (e.g., IEEE
802.15.4 offers up to 250 kbps).

o Small Maximum Transmission Unit (MTU) sizes (e.g., 127 bytes for IEEE
802.15.4) limit packet sizes.
 • High Packet Loss:

o Wireless networks in IoT are prone to interference, fading, and physical

obstructions, leading to packet loss rates of 10–30% or higher.

• Intermittent Connectivity:

o Devices may enter sleep modes to save power, causing temporary

disconnections.

o Remote or mobile IoT devices (e.g., in logistics) may experience network

outages.

• Power Constraints:

o Network interfaces (e.g., radios) consume significant energy, requiring

optimization to extend device lifespan.

• Topology Challenges:

o IoT networks often use mesh or star topologies, which introduce routing
complexities and latency.

Why Optimization is Needed

• Protocol Overhead: Standard IP protocols (e.g., IPv6, TCP) have large headers and
retransmission mechanisms that are inefficient for low-bandwidth, lossy networks.

• Reliability: High packet loss requires robust error-handling mechanisms tailored to

IoT networks.

• Energy Efficiency: Network communication is a major source of power

consumption, necessitating low-power protocols and duty cycling.

• Scalability: Constrained networks must support thousands of devices without

congestion or performance degradation.

Optimization Strategies

• Header Compression:

o 6LoWPAN: Reduces IPv6 header size (40 bytes) to as little as 2–3 bytes
through compression techniques like HC1/HC2.

• Lightweight Routing:
 o RPL (Routing Protocol for Low-Power and Lossy Networks): A routing
protocol optimized for constrained networks, supporting mesh topologies
and energy-efficient paths.

• Low-Power Networking:

o Time-Slotted Channel Hopping (TSCH): A technique in IEEE 802.15.4e that

synchronizes communication to reduce collisions and save energy.

• Fragmentation and Reassembly:

o 6LoWPAN fragments large IPv6 packets to fit within small MTUs and
reassembles them at the destination, ensuring compatibility with
constrained networks.

Example

In a smart city deployment, streetlight sensors use an IEEE 802.15.4 network with
6LoWPAN and RPL. The network employs TSCH to minimize energy consumption and
header compression to fit data within small packets, ensuring reliable communication
despite urban interference.

IP Versions
The Internet Protocol (IP) exists in two versions: IPv4 and IPv6. The choice of IP version
significantly impacts IoT deployments due to differences in address space, features, and
compatibility with constrained environments.

IPv4 Overview

• Address Space: 32-bit addresses, providing approximately 4.3 billion unique

addresses.

• Features:

o Widely deployed in traditional networks.

o Uses Network Address Translation (NAT) to overcome address scarcity.

o Smaller header size (20 bytes) compared to IPv6.

• Limitations for IoT:

o Address Exhaustion: The limited address space is insufficient for the billions
of IoT devices, requiring NAT, which adds complexity and latency.
 o Lack of Autoconfiguration: IPv4 relies on DHCP, which is resource-intensive
for constrained nodes.

o Security: IPv4 lacks built-in security features, relying on external protocols

like IPsec.

• Use in IoT:

o Suitable for small-scale, legacy IoT deployments with existing IPv4

infrastructure.

o Less common in modern IoT due to scalability limitations.

IPv6 Overview

• Address Space: 128-bit addresses, providing 2^128 (approximately 340 undecillion)

unique addresses.

• Features:

o Virtually unlimited address space, eliminating the need for NAT.

o Stateless Address Autoconfiguration (SLAAC), enabling devices to self-

configure IP addresses.

o Simplified header processing for efficient routing.

o Built-in support for IPsec (optional) for enhanced security.

o Larger header size (40 bytes) but optimized for modern networks.

• Advantages for IoT:

o Scalability: Supports the massive number of IoT devices without address

conflicts.

o End-to-End Connectivity: Eliminates NAT, enabling direct device-to-device

communication, critical for real-time IoT applications.

o Energy Efficiency: SLAAC reduces the need for resource-intensive DHCP

servers.

o Future-Proofing: IPv6 is designed for modern and emerging technologies like

5G and edge computing.

Optimization for IoT

 • IPv6 as the Default: IPv6 is the preferred choice for IoT due to its scalability and
autoconfiguration features. It is supported by IoT-specific protocols like 6LoWPAN,
RPL, and CoAP.

• Header Compression: 6LoWPAN compresses IPv6 headers to make them viable for
constrained nodes and networks.

• Dual-Stack Support: Some IoT deployments use dual-stack (IPv4/IPv6) gateways to

bridge legacy and modern networks during the transition to IPv6.

• Tunneling: Techniques like 6to4 or Teredo enable IPv6 traffic over IPv4 networks,
supporting gradual adoption.

Optimizing IP for IoT

The Internet of Things (IoT) involves connecting billions of constrained devices (e.g.,
sensors, actuators) over low-power, low-bandwidth networks.

Standard Internet Protocol (IP) stacks, designed for resource-rich devices, are too
resource-intensive for IoT environments.

These optimizations address challenges such as limited processing power, small packet
sizes, and lossy networks, enabling scalable, interoperable, and efficient IoT deployments.

Optimizing IP for IoT involves adapting IP protocols to operate efficiently on constrained

nodes and networks while retaining the benefits of IP, such as interoperability, scalability,
and end-to-end connectivity.

6LoWPAN
• 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) is an IETF
standard that enables IPv6 communication over low-power, low-bandwidth
wireless networks, such as those based on IEEE 802.15.4.

• Designed for resource-constrained IoT devices (e.g., sensors, actuators) with limited
processing power, memory, and energy.

2. Purpose in IoT

• Bridges the gap between IP-based internet and constrained IoT networks,
allowing seamless integration of IoT devices with the global internet.
 • Enables end-to-end IPv6 connectivity for applications like smart homes, industrial
IoT, and environmental monitoring.

3. Key Features

• Header Compression:

o Reduces the large IPv6 header (40 bytes) to fit the small frame sizes of IEEE
802.15.4 (max 127 bytes).

• Fragmentation:

o Breaks large IPv6 packets into smaller fragments to match the limited
payload size of 802.15.4 frames (e.g., 25-80 bytes after headers).

• Mesh Addressing:

o Supports multi-hop mesh networking, allowing devices to relay data

through intermediate nodes.

o Uses 16-bit short addresses or 64-bit extended addresses for efficient

routing in IoT networks.

• Adaptation Layer:

o Acts as an adaptation layer between the network layer (IPv6) and data link
layer (IEEE 802.15.4).

o Handles compression, fragmentation, and reassembly to make IPv6

compatible with constrained networks.

• Interoperability:

o Enables IoT devices to communicate with standard IP networks using

protocols like CoAP, RPL, and 6TiSCH.

4. Role in IoT

• Foundation for IP-Based IoT:

o Allows resource-constrained devices to use IPv6, ensuring compatibility with

internet standards.

o Supports protocols like RPL for routing and CoAP for lightweight application-
layer communication.

• Integration with 6TiSCH:

 o Used in 6TiSCH networks to provide IPv6 connectivity over IEEE 802.15.4e
TSCH, enabling deterministic and reliable communication for industrial IoT.

• Support for RPL and DODAG:

o Works with RPL to form DODAGs (Destination-Oriented Directed Acyclic

Graphs) for efficient routing in multi-hop IoT networks.

9. Relation to Other IoT Technologies

• 6Lo Working Group:

o 6LoWPAN is part of the IETF 6Lo Working Group, which extends IPv6 to other
constrained networks (e.g., Bluetooth, DECT ULE).

• 6TiSCH:

o 6LoWPAN provides the IPv6 layer for 6TiSCH, enabling IP-based

communication over TSCH for industrial applications.

• RPL and DODAG:

o 6LoWPAN uses RPL for routing, forming DODAGs to manage multi-hop

communication in mesh networks.

• CoAP:

o Works with CoAP for lightweight, RESTful communication, complementing

6LoWPAN’s network-layer optimizations.

From 6LoWPAN to 6Lo

The term "6Lo" represents the broader evolution of 6LoWPAN to support additional low-
power networks, such as Bluetooth Low Energy (BLE), DECT Ultra Low Energy (ULE), and
Power Line Communication (PLC).

Evolution to 6Lo

• Motivation: While 6LoWPAN was designed for IEEE 802.15.4, IoT deployments
increasingly use diverse low-power networks (e.g., BLE, PLC). 6Lo extends
6LoWPAN’s principles to these networks.

• Scope: 6Lo adapts IPv6 for any constrained link layer, ensuring compatibility with
emerging technologies.
 • Examples:

o 6LoWPAN over BLE: Compresses IPv6 headers for Bluetooth’s smaller MTU
(e.g., 27 bytes).

o 6LoWPAN over PLC: Optimizes IPv6 for power line networks in smart grids.

Business Implications

• Interoperability: 6Lo enables diverse IoT devices to communicate over a unified IP-
based network.

• Scalability: Supports large-scale deployments across multiple link-layer

technologies.

• Cost Efficiency: Reduces the need for proprietary protocols, lowering development
and maintenance costs.

Example

A smart home system uses 6LoWPAN for IEEE 802.15.4-based sensors (e.g., motion
detectors) and 6Lo for BLE-based devices (e.g., smart locks), ensuring all devices
communicate via IPv6 on a single network.

Header Compression

Header compression reduces the size of IPv6 headers to fit within the small packet sizes of
constrained networks, such as IEEE 802.15.4’s 127-byte Maximum Transmission Unit
(MTU).

Why It’s Needed

• IPv6 Header Size: A standard IPv6 header is 40 bytes, which is significant compared
to the 127-byte MTU of IEEE 802.15.4. With additional headers (e.g., UDP, 8 bytes),
little room remains for application data.

• Energy Efficiency: Smaller headers reduce transmission time, conserving battery

power.

• Bandwidth Constraints: Low-bandwidth networks require minimal overhead to

avoid congestion.

How Header Compression Works

• 6LoWPAN Compression:
 o HC1/HC2 (Header Compression 1 and 2): Early 6LoWPAN standards that
compress IPv6 headers by omitting redundant fields (e.g., version, traffic
class) and using context-based encoding.

o IPHC (IPv6 Header Compression): A more advanced mechanism defined in

RFC 6282, compressing headers to as little as 2–3 bytes in optimal cases.

o Fields Compressed:

▪ Version: Omitted (assumed to be 6 for IPv6).

▪ Traffic Class/Flow Label: Omitted or encoded compactly if unused.

▪ Payload Length: Inferred from the link-layer frame.

▪ Next Header: Compressed using predefined values for common

protocols (e.g., UDP).

▪ Source/Destination Addresses: Elided if derivable from link-layer

addresses or context.

• Context-Based Compression: Uses shared context (e.g., network prefix) to further

reduce header size.

• NHC (Next Header Compression): Compresses higher-layer headers (e.g., UDP) to

2–4 bytes.

Benefits

• Increases payload capacity, allowing more application data per packet.

• Reduces energy consumption by minimizing transmission time.

• Improves network efficiency in bandwidth-constrained environments.

Fragmentation

Fragmentation divides large IPv6 packets into smaller fragments to fit within the small MTU
of constrained networks, with reassembly at the destination.

Why It’s Needed

• MTU Mismatch: IPv6 requires a minimum MTU of 1280 bytes, but IEEE 802.15.4
supports only 127 bytes (including headers).

• Data Requirements: IoT applications (e.g., firmware updates) may require large
packets that exceed the link-layer MTU.
 • Reliability: Fragmentation ensures data delivery in lossy networks by retransmitting
only lost fragments.

How Fragmentation Works

• 6LoWPAN Fragmentation (RFC 4944):

o Fragment Header: Adds a small header (4–5 bytes) to each fragment,

including:

▪ Datagram Size: Total size of the original packet.

▪ Datagram Tag: Unique identifier for the packet.

▪ Fragment Offset: Position of the fragment in the original packet.

o First Fragment: Includes the compressed IPv6 header and part of the
payload.

o Subsequent Fragments: Contain only payload data and the fragment

header.

• Reassembly: The receiving node buffers fragments and reassembles them into the
original packet using the datagram tag and offset.

• Error Handling: If a fragment is lost, only that fragment is retransmitted, improving

efficiency.

Challenges

• Memory Constraints: Constrained nodes have limited buffer space for reassembly.

• Lossy Networks: Packet loss requires retransmissions, increasing latency.

• Overhead: Fragment headers add overhead, reducing payload efficiency.

Benefits

• Enables IPv6 compatibility with small-MTU networks.

• Supports large data transfers (e.g., configuration updates) in IoT.

• Improves reliability by isolating retransmissions to specific fragments.

Mesh Addressing

Mesh addressing enables multi-hop communication in IoT mesh networks, where devices
relay data to extend network coverage.
Why It’s Needed

• Limited Range: Low-power radios (e.g., IEEE 802.15.4) have short transmission
ranges (10–100 meters).

• Scalability: Mesh networks support large-scale deployments by allowing devices to

act as routers.

• Coverage: Mesh addressing extends connectivity in environments like smart cities

or industrial plants.

How Mesh Addressing Works

• 6LoWPAN Mesh Addressing:

o Header: Adds a mesh header (4–10 bytes) to packets, including:

▪ Originator Address: Source device’s link-layer address.

▪ Final Destination Address: Target device’s link-layer address.

▪ Hop Limit: Maximum number of hops to prevent infinite loops.

o Forwarding: Intermediate nodes forward packets based on the destination

address, decrementing the hop limit.

• Link-Layer Addressing: Uses short 16-bit addresses or 64-bit EUI-64 addresses to

reduce overhead.

Mesh-Under vs. Mesh-Over Routing

• Mesh-Under Routing:

o Definition: Routing occurs at the link layer (below the IP layer).

o Mechanism: 6LoWPAN handles routing using link-layer addresses,

transparent to the IP layer.

o Advantages:

▪ Simplifies IP stack, as routing is managed by the link layer.

▪ Reduces IP-layer overhead.

o Disadvantages:

▪ Limited to homogeneous link layers (e.g., IEEE 802.15.4 only).

▪ Less flexible for integrating diverse networks.

 o Example: A smart lighting network uses mesh-under routing to relay
commands between IEEE 802.15.4-based bulbs.

• Mesh-Over Routing:

o Definition: Routing occurs at the IP layer using protocols like RPL.

o Mechanism: Each node runs an IP routing protocol, forwarding packets

based on IPv6 addresses.

o Advantages:

▪ Supports heterogeneous networks (e.g., IEEE 802.15.4 and Wi-Fi).

▪ Enables end-to-end IP connectivity.

o Disadvantages:

▪ Increases complexity and resource usage on constrained nodes.

▪ Requires larger IP stacks.

o Example: A smart grid uses mesh-over routing with RPL to route data across
a mix of IEEE 802.15.4 and PLC networks.

Benefits

• Extends network coverage without requiring additional infrastructure.

• Enhances scalability for dense IoT deployments.

• Improves reliability by providing multiple paths for data delivery.

6Lo Working Group

The 6Lo Working Group, part of the Internet Engineering Task Force (IETF), develops
standards to extend 6LoWPAN’s principles to various low-power link layers beyond IEEE
802.15.4.

Objectives

• Adapt IPv6 for constrained link layers, including BLE, PLC, DECT ULE, and NFC.

• Standardize header compression, fragmentation, and addressing mechanisms.

• Ensure interoperability across diverse IoT networks.

Key Contributions
 • 6LoWPAN-GHC (Generic Header Compression): A flexible compression scheme
for any link layer, improving on IPHC.

• 6Lo Standards:

o RFC 8163: IPv6 over BLE.

o RFC 8105: IPv6 over DECT ULE.

o RFC 7428: IPv6 over PLC.

• SCHC (Static Context Header Compression): A framework for compressing

headers in LPWANs (e.g., LoRaWAN, Sigfox).

Business Implications

• Vendor Neutrality: Standardized protocols reduce vendor lock-in.

• Future-Proofing: Supports emerging link-layer technologies, protecting

investments.

• Global Adoption: IETF standards ensure compatibility across regions and

industries.

6TiSCH
6TiSCH (IPv6 over the Timeslotted Channel Hopping mode of IEEE 802.15.4e) is a protocol
stack that combines 6LoWPAN with Time-Slotted Channel Hopping (TSCH) to provide
deterministic, low-power, and reliable communication for industrial IoT.

What is 6TiSCH? 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) is a protocol stack
developed by the IETF for the Industrial Internet of Things (IIoT).

It combines IPv6 connectivity with Time-Slotted Channel Hopping (TSCH) to enable

reliable, low-power, and deterministic communication for IoT devices in industrial
applications like smart factories and process control.

Key Features:

• IPv6 Integration: Uses 6LoWPAN, RPL, and CoAP to enable IP-based

communication, ensuring interoperability with internet systems.

• TSCH: Employs time-synchronized schedules and channel hopping for high

reliability (>99.999%) and low latency, critical for industrial control.
 • Energy Efficiency: Optimized for battery-powered IoT devices, extending device
lifetime through low-power operation.

Advantages in IoT:

• Deterministic Performance: TSCH ensures predictable data delivery, vital for time-
sensitive IIoT applications like robotics.

• Scalability: Supports large-scale, multi-hop mesh networks, ideal for industrial

environments.

• IT/OT Convergence: Bridges operational technology (OT) with information

technology (IT) using open IP standards, simplifying integration with cloud systems.

Applications: Used in industrial monitoring, smart grids, and m-Health, where reliable,
low-latency, and secure IoT communication is essential.

Key Features

• TSCH:

o Synchronizes communication using time slots, reducing collisions and

energy consumption.

o Uses channel hopping to mitigate interference and improve reliability.

• 6LoWPAN Integration: Enables IPv6 with header compression and fragmentation.

• RPL Support: Uses RPL for mesh-over routing in multi-hop networks.

• Deterministic Networking: Allocates specific time slots for critical data, ensuring
low latency and reliability.

6TiSCH architecture defines four schedule management mechanisms:

• Static scheduling: All nodes in the constrained network share a fixed schedule. Cells are
shared, and nodes contend for slot access in a slotted aloha manner.

• Neighbor-to-neighbor scheduling: A schedule is established that correlates with the

observed number of transmissions between nodes. Cells in this schedule can be added or
deleted as traffic requirements and bandwidth needs change.

• Remote monitoring and scheduling management: Time slots and other resource
allocation are handled by a management entity that can be multiple hops away.
• Hop-by-hop scheduling: A node reserves a path to a destination node multiple hops
away by requesting the allocation of cells in a schedule at each intermediate node hop in
the path

Three 6TiSCH forwarding models:

• Track Forwarding (TF): This is the simplest and fastest forwarding model. A “track” in this
model is a unidirectional path between a source and a destination. This track is
constructed by pairing bundles of receive cells in a schedule with a bundle of receive cells
set to transmit

• Fragment forwarding (FF): This model takes advantage of 6LoWPAN fragmentation to

build a Layer 2 forwarding table. IPv6 packets can get fragmented at the 6LoWPAN sublayer
to handle the differences between IEEE 802.15.4 payload size and IPv6 MTU.

• IPv6 Forwarding(6F): This model forwards traffic based on its IPv6 routing table. Flows of
packets should be prioritized by traditional QoS (quality of service)

Why It’s Needed

• Industrial IoT Requirements:

o High reliability in harsh environments (e.g., factories with interference).

o Low latency for real-time applications (e.g., robotic control).

o Energy efficiency for battery-powered devices.

How 6TiSCH Works

• Time Slots: Divides time into slots (e.g., 10 ms), with each slot assigned for
transmission, reception, or sleep.

• Channel Hopping: Uses multiple frequency channels, switching channels per slot
to avoid interference.

• Scheduling:

o Centralized: A network controller assigns time slots and channels.

o Distributed: Nodes negotiate schedules dynamically.

• Protocol Stack:

o Link Layer: IEEE 802.15.4e TSCH.

o Adaptation Layer: 6LoWPAN (header compression, fragmentation).

 o Network Layer: IPv6 with RPL for routing.

o Application Layer: CoAP or MQTT-SN.

RPL
RPL (Routing Protocol for Low-Power and Lossy Networks) is an IPv6 routing protocol
designed for constrained IoT networks, standardized in RFC 6550.

In an RPL network, each node acts as a router and becomes part of a mesh network.
Routing is performed at the IP layer.

Each node examines every received IPv6 packet and determines the next- hop destination
based on the information contained in the IPv6 header.

Key Features

• Distance-Vector Protocol: Builds a Destination-Oriented Directed Acyclic Graph

(DODAG) for routing.

• Support for Multiple Topologies:

o Point-to-Multipoint: From nodes to a root (e.g., gateway).

o Multipoint-to-Point: From root to nodes.

o Point-to-Point: Between nodes.

• Energy Efficiency: Optimizes routes based on energy consumption and link quality.

• Self-Healing: Dynamically adapts to network changes (e.g., node failures).

Core Concept: RPL organizes devices into a Directed Acyclic Graph (DAG), a directed
graph with no cycles, ensuring loop-free routing paths oriented toward one or more root
nodes.

2. DODAG (Destination-Oriented Directed Acyclic Graph)

• DODAG stands for Destination-Oriented Directed Acyclic Graph, a specific type

of Directed Acyclic Graph (DAG) used in the RPL protocol for IoT networks.

• It is a loop-free, hierarchical routing structure with a single root (typically a border

router) as the destination for all paths.

• Ensures efficient, reliable routing in low-power, lossy networks (LLNs) like sensor
networks or industrial IoT.
 • Structure:

o Each node in a DODAG maintains up to three parent nodes, with one

designated as the preferred parent for upward routes to the root.

o The set of parent nodes across all devices forms the upward routing graph,
ensuring loop-free paths by excluding parents farther from the root.

• Comparison with DAG:

o DAG: May have multiple root nodes, allowing multiple destinations.

o DODAG: Has a single root, focusing all paths toward one destination (e.g.,
border router).

• Role in RPL:

o DODAGs provide a structured topology for routing data to a central point in

IoT networks, critical for applications like data aggregation in smart grids or
industrial monitoring.

3. RPL Operations

• Upward Routes:

o Discovered using DAG Information Object (DIO) messages.

o Nodes listen to DIOs to detect topology changes, identify parents, and

determine the best path to the DODAG root.

• Downward Routes:

o Established via Destination Advertisement Object (DAO) messages.

o Nodes advertise their parent set to the root or other nodes, enabling
reachability to descendants.

• Modes of Operation:

o Non-Storing Mode:

▪ Nodes send DAO messages to the DODAG root, which stores all
routing information.

▪ The root computes source routes for downstream data delivery.

▪ Requires all packets to pass through the root, increasing latency for
intra-mesh communication.
 o Storing Mode:

▪ Each node stores routing information from DAO messages.

▪ Enables shorter, direct paths within the mesh, as nodes make local
routing decisions.

▪ More resource-intensive (power, CPU, memory) but reduces latency.

• Message Transport: DIO and DAO messages run over IPv6, facilitating upstream
and downstream routing information exchange.

Authentication and Encryption on Constrained Nodes

ACE

ACE (Authentication and Authorization for Constrained Environments) is an IETF framework

for securing constrained IoT devices, enabling lightweight authentication and authorization.

Why It’s Needed

• Security Risks: Constrained devices are vulnerable to attacks (e.g., unauthorized

access, data tampering).

• Resource Constraints: Traditional security protocols (e.g., OAuth 2.0) are too heavy
for constrained nodes.

• Interoperability: IoT requires standardized security across diverse devices.

How ACE Works

• Framework:

o Client: The IoT device requesting access.

o Resource Server (RS): The device hosting the resource (e.g., sensor data).

o Authorization Server (AS): Issues access tokens.

• Protocol Flow:

o The client requests an access token from the AS.

o The AS authenticates the client and issues a token (e.g., JSON Web Token).

o The client presents the token to the RS, which verifies it and grants access.

• Security Protocols:
 o DTLS: Secures communication between client and RS.

o OSCORE (Object Security for Constrained RESTful Environments):

Provides end-to-end security for CoAP.

Benefits

• Secure access control for constrained devices.

• Interoperable with standard protocols like CoAP and DTLS.

• Scalable for large IoT deployments.

DICE

• DICE (Device Identifier Composition Engine) is a Trusted Computing Group (TCG)

standard providing a hardware-based Root-of-Trust (RoT) for IoT and edge devices.

• Designed for resource-constrained devices (e.g., sensors, actuators) lacking a

Trusted Platform Module (TPM) due to cost, size, or power limitations.

2. Purpose in IoT

• Ensures secure device identity, integrity, and attestation for IoT devices in low-
power, lossy networks (LLNs), such as those using RPL or 6TiSCH.

• Protects against attacks like device cloning, firmware tampering, or unauthorized

network access.

3. Key Features

• Unique Device Secret:

o Embeds a cryptographic secret in hardware during manufacturing.

o Used to generate unique cryptographic keys, ensuring each device has a

distinct identity.

• Cryptographic Security:

o Produces keys for authentication (e.g., proving device identity) and

encryption (e.g., securing data).

o Protects against supply chain attacks or device impersonation.

4. Role in IoT

• Secure Bootstrapping:
 o Ensures devices securely join IoT networks (e.g., a DODAG in RPL) by proving
their identity during onboarding.

• Network Security:

o Supports secure communication in protocols like 6TiSCH by providing

trusted identities for nodes exchanging RPL messages (e.g., DIO, DAO).

6. Advantages

• Robust Security: Prevents firmware tampering, device cloning, and unauthorized

network access.

• Cost-Effective: Enables strong security in low-cost, constrained devices without

requiring TPM hardware.

• Compatibility: Integrates with IoT protocols (e.g., CoAP, 6LoWPAN, RPL) and
security frameworks (e.g., ACE).

Profiles and Compliances Notes for IoT

• Purpose: Profiles and certifications ensure interoperability and interchangeability
of IoT devices using the Internet Protocol (IP) suite, coordinating protocols across
network layers.

• Importance: Industry organizations define profiles and conduct certifications to

validate that IoT devices and networks work seamlessly, promoting adoption and
reliability.

IPSO Alliance

• Role: Promotes and validates IP-based solutions for smart objects.

• Focus:

o Organizes interoperability tests among members to ensure IP-based IoT

devices implement industry standards correctly.

o Documents use cases and educates on how to use IP effectively in IoT.

• Key Goal: Equip engineers with tools to "build the IoT RIGHT" without defining new
technologies (relies on IETF standards).
 • Significance: Ensures IP-based IoT solutions are interoperable and reliable across
vendors.

Wi-SUN Alliance

• Focus: Defines communication profiles for IEEE 802.15.4g networks, supporting

secure IPv6 communications over UDP.

• Wi-SUN FAN Profile:

o Enables resilient, secure, and cost-effective connectivity for smart utility

networks.

o Supports diverse environments (urban to rural) with excellent coverage.

• Significance: Provides standardized, secure networking for utility-focused IoT

applications.

Thread Group

• Focus: Defines an IPv6-based wireless profile for consumer IoT using IEEE
802.15.4.

• Key Features:

o Supports low-power, wireless mesh networks connecting over 250

devices.

o Optimized for smart home applications (e.g., lights, thermostats).

• Significance: Ensures reliable, scalable, and low-power connectivity for consumer

IoT devices.

IPv6 Ready Logo Program

• Role:

o Provides conformance and interoperability testing for IPv6-enabled

devices.

o Certifies components like IPv6 Core, DHCP, IPsec, and customer edge
routers.

• IoT Relevance: Developing specific IPv6 certification for IoT to increase user
confidence in constrained devices.
 • Significance: Validates IPv6 compatibility, ensuring IoT devices integrate
seamlessly with IP networks.

Transport Layer in IoT

The transport layer, part of the TCP/IP protocol suite, is responsible for end-to-end
communication between devices, ensuring data is delivered reliably, efficiently, and
securely.

In the context of the Internet of Things (IoT), the transport layer must accommodate the
unique constraints of IoT devices (e.g., limited CPU, memory, and energy) and networks
(e.g., low bandwidth, high packet loss).

The transport layer provides services such as data segmentation, flow control, error
correction, and connection management, enabling reliable communication between IoT
devices and applications.

Why the Transport Layer is Critical in IoT

• Device Constraints: IoT devices, such as sensors and actuators, have limited
processing power, memory (e.g., 10–50 KB RAM), and energy, requiring lightweight
transport protocols.

• Network Constraints: IoT networks (e.g., IEEE 802.15.4, LoRaWAN) have low
bandwidth (e.g., 250 kbps), small packet sizes (e.g., 127-byte MTU), and high packet
loss (10–30%), necessitating efficient data transfer.

• Diverse Use Cases: IoT applications range from real-time monitoring (e.g.,
healthcare) to periodic data collection (e.g., agriculture), each with unique reliability
and latency requirements.

• Security Needs: The transport layer must support security mechanisms (e.g., DTLS,
TLS) to protect sensitive IoT data.

• Interoperability: Standardized transport protocols ensure devices from different

vendors can communicate seamlessly.

Transmission Control Protocol (TCP)

TCP is a connection-oriented transport layer protocol that ensures reliable, ordered, and
error-free data delivery between devices.
It is widely used in traditional internet applications (e.g., web browsing, email) but faces
challenges in IoT due to its resource-intensive nature.

Key Features of TCP

• Connection-Oriented:

o Establishes a connection using a three-way handshake (SYN, SYN-ACK, ACK)

before data transfer.

o Maintains connection state (e.g., sequence numbers, window size) during

communication.

o Terminates the connection with a four-way handshake (FIN, ACK, FIN, ACK).

• Reliability:

o Uses acknowledgments (ACKs) to confirm receipt of data.

o Retransmits lost or corrupted packets, ensuring no data loss.

o Implements error detection via checksums.

• Ordered Delivery:

o Segments data into packets and reassembles them in the correct order using
sequence numbers.

• Flow Control:

o Uses a sliding window mechanism to regulate the amount of data sent,

preventing receiver buffer overflow.

• Header Size: Typically 20–60 bytes (20 bytes base header + optional fields), which is
significant for IoT’s small MTUs.

TCP in IoT

• Use Cases:

o File Transfers: Large data transfers, such as firmware updates or

configuration files, require guaranteed delivery.

o Web-Based IoT: Applications using HTTP/HTTPS (e.g., smart home

dashboards) rely on TCP for reliable communication.

o Secure Communication: TCP supports TLS (Transport Layer Security) for

encrypted data transfer, critical for sensitive applications like healthcare.
 • Examples:

o A smart thermostat downloading a 1 MB firmware update over Wi-Fi uses

TCP to ensure all packets are received correctly.

o A healthcare IoT system transmitting patient records to a cloud server uses

TCP with TLS for secure, reliable delivery.

Challenges in IoT

• Resource Intensity:

o Memory: TCP’s connection state (e.g., buffers, sequence numbers) requires

significant RAM, challenging for constrained devices with 10–50 KB.

o Processing: Handshake, retransmission, and congestion control algorithms

demand CPU resources.

o Energy: Frequent ACKs and retransmissions increase radio usage, draining

batteries.

• Header Overhead:

o A 20–60-byte TCP header consumes a large portion of IEEE 802.15.4’s 127-

byte MTU, reducing payload capacity.

• Latency:

o The three-way handshake and retransmissions introduce delays, unsuitable

for real-time IoT applications (e.g., industrial control).

• Lossy Networks:

o IoT networks (e.g., IEEE 802.15.4) have high packet loss (10–30%). TCP’s
retransmissions and congestion control may misinterpret losses as
congestion, reducing throughput.

• Scalability:

o Maintaining TCP connections for thousands of devices increases network

and device overhead, limiting scalability in dense IoT deployments.

Optimizations for TCP in IoT

• Lightweight TCP Stacks:

 o Use minimal TCP implementations (e.g., uIP, lwIP) that reduce memory and
CPU usage.

o Example: uIP supports a single TCP connection with a small buffer, suitable
for constrained devices.

• Header Compression:

o 6LoWPAN’s NHC (Next Header Compression, RFC 6282) compresses TCP

headers to 4–8 bytes, improving efficiency in constrained networks.

• Congestion Control Tuning:

o Adjust TCP parameters (e.g., smaller initial window, faster retransmission

timers) to handle lossy IoT networks without overreacting to packet loss.

• Proxy-Based Solutions:

o Use gateways to terminate TCP connections locally, converting to lightweight

protocols (e.g., CoAP over UDP) for device communication.

o Example: A gateway handles TCP/HTTPS for cloud communication, while

devices use UDP/CoAP internally.

o Implement lightweight TLS libraries (e.g., mbedTLS) for constrained devices.

User Datagram Protocol (UDP)

UDP is a connectionless transport layer protocol that provides lightweight, low-overhead
communication without guarantees of reliability or ordered delivery. It is widely used in IoT
due to its efficiency and suitability for constrained environments.

Key Features of UDP

• Connectionless:

o No handshake or connection state, reducing overhead.

o Each packet (datagram) is sent independently, with no dependency on

previous packets.

• Low Overhead:

o Fixed 8-byte header (Source Port, Destination Port, Length, Checksum),

minimal compared to TCP’s 20–60 bytes.

• No Reliability Mechanisms:
 o No acknowledgments, retransmissions, or error correction.

o Packet loss or corruption is handled by the application layer, if needed.

• No Ordered Delivery:

o Datagrams may arrive out of order, requiring application-layer reordering if

necessary.

• No Flow or Congestion Control:

o Sends data at the application’s rate, risking network congestion but

simplifying implementation.

• Broadcast/Multicast Support:

o Supports sending datagrams to multiple devices, useful for IoT device

discovery or group commands.

UDP in IoT

• Use Cases:

o Real-Time Applications: Low-latency applications like industrial control,

remote monitoring, or smart home automation benefit from UDP’s speed.

o Periodic Data: Sensors sending small, frequent updates (e.g., temperature

readings) tolerate occasional packet loss, making UDP ideal.

o Constrained Devices: UDP’s simplicity suits devices with limited CPU,

memory, and energy.

• Examples:

o A soil moisture sensor in a smart agriculture system sends 10-byte readings

every 5 minutes using UDP/CoAP over IEEE 802.15.4, minimizing energy use.

o A smart factory uses UDP for real-time vibration sensor data, prioritizing low
latency over occasional packet loss.

Advantages in IoT

• Low Resource Usage:

o Memory: No connection state or buffers, requiring minimal RAM (e.g., <1

KB).

o Processing: Simple header processing reduces CPU demands.

 o Energy: Fewer transmissions (no ACKs or handshakes) conserve battery
power.

• Small Header:

o The 8-byte header fits easily within IEEE 802.15.4’s 127-byte MTU, leaving
more room for payload.

o 6LoWPAN’s NHC compresses UDP headers to 2–4 bytes, further improving

efficiency.

• Low Latency:

o Connectionless design eliminates handshake delays, ideal for real-time IoT

applications.

• Scalability:

o UDP’s stateless nature supports thousands of devices without connection

overhead, suitable for dense IoT networks.

• Flexibility:

o Application-layer protocols (e.g., CoAP) can implement selective reliability or

ordering, tailoring UDP to specific needs.

Challenges in IoT

• Lack of Reliability:

o Packet loss in lossy networks (e.g., IEEE 802.15.4) may result in missing data,
unacceptable for critical applications.

o Solution: Application-layer protocols like CoAP implement lightweight

retransmission mechanisms (e.g., Confirmable messages).

• No Congestion Control:

o UDP’s unrestricted sending can overload constrained networks, causing

packet loss.

o Solution: Rate limiting at the application layer or network-level traffic

shaping.

• Security:
 o UDP lacks built-in security, requiring external protocols like DTLS (Datagram
Transport Layer Security) for encryption and authentication.

o DTLS adds overhead (e.g., 13-byte header), partially offsetting UDP’s

efficiency.

• Out-of-Order Delivery:

o Applications requiring ordered data must implement reordering logic,

increasing complexity.

o Solution: Use sequence numbers in application-layer protocols.

Optimizations for UDP in IoT

• Header Compression:

o 6LoWPAN’s NHC compresses UDP headers to 2–4 bytes by eliding ports or

checksums when predictable.

o Example: In a smart meter network, NHC reduces the UDP header to 2 bytes,
maximizing payload within the 127-byte MTU.

• Application-Layer Protocols:

o CoAP (Constrained Application Protocol, RFC 7252):

▪ Runs over UDP, providing RESTful communication for constrained

devices.

▪ Supports Confirmable (CON) messages for reliability and Non-

Confirmable (NON) messages for speed.

o MQTT-SN (MQTT for Sensor Networks):

▪ A lightweight version of MQTT over UDP, optimized for low-power

networks.

▪ Uses topic-based messaging for efficient data distribution.

• DTLS Optimization:

o Use lightweight DTLS implementations (e.g., TinyDTLS) to secure UDP traffic.

o Employ session resumption to reduce handshake overhead.

• Multicast Support:
 o Leverage UDP’s multicast capabilities for efficient device discovery or group
commands.

o Example: A smart home uses UDP multicast to send a “turn off” command to
all lights simultaneously.

Comparison of TCP and UDP in IoT

Feature TCP UDP

Connection Connection-oriented (handshake

Connectionless (no handshake)
Type required)

Guaranteed delivery (ACKs, No guarantees (application-layer

Reliability
retransmissions) reliability)

Ordered Ensures correct order (sequence No ordering (application-layer if

Delivery numbers) needed)

20–60 bytes (compressible to 4–

Header Size 8 bytes (compressible to 2–4 bytes)
8 bytes)

Resource
High (memory, CPU, energy) Low (minimal memory, CPU, energy)
Usage

Higher (handshake,
Latency Lower (no handshake, stateless)
retransmissions)

Congestion Built-in (slow start, congestion

None (application-layer if needed)
Control avoidance)

Security TLS for encryption DTLS for encryption

Firmware updates, web-based Real-time monitoring, periodic

IoT Use Cases
apps, secure data updates, constrained devices

Smart thermostat firmware

Examples Soil sensor data transmission
update

IoT Application Transport Method

1.Application Layer Protocol Not Present
Background – What Are Class 0 Devices?

Let’s start by imagining the world of IoT devices. They range from smart cameras and
industrial machines to tiny temperature sensors placed in farms, warehouses, or remote
fields. Now, within this ecosystem, there exists a category called Class 0 devices, as
defined by IETF RFC 7228.

These are the most basic, lightweight devices. They:

• Can only send or receive a few bytes of data.

• Are very limited in processing power, memory, and energy.

• Are usually designed to be ultra-cheap, and battery-efficient.

• Cannot support full network stacks like IP, TCP, UDP, or even application-layer
protocols like MQTT or CoAP.

So what does this mean practically? It means these devices can’t “speak” in the usual
structured internet protocols. Instead, they send out tiny chunks of raw data — no
headers, no formats, no metadata, just the data.

Example – The Minimalist Sensor Setup

Imagine a field full of low-cost sensors measuring temperature and humidity. Each
sensor:

• Captures temperature (2 bytes)

• Captures humidity (2 bytes)

• Sends just 4 bytes of data

They use LoRaWAN, a low-power wide-area (LPWA) network — perfect for long distances
with minimal energy use.

Here's the key: these sensors don’t wrap their data in the usual communication layers.
Instead, they send these 4 bytes directly on top of LoRaWAN’s MAC layer. No TCP. No IP.
No application layer.

The Problem – No Standard, No Clarity

Now, imagine:
 • You buy Sensor A from Company X.

• Then later, you get Sensor B from Company Y.

• Both measure temperature, but they encode it differently:

o One might use Celsius as an integer.

o Another might use Fahrenheit as a float with 1 decimal.

o A third might add an offset of 100 to avoid negative numbers.

The application receiving this data doesn’t automatically know how to interpret it,
because there’s no standard format.

It has to be manually told how to decode each device’s data — and that’s a huge
headache when you have hundreds or thousands of devices from different vendors.

The Real Challenge – Interoperability at Scale

This unstructured communication approach:

• Works fine for a small number of known devices.

• Becomes a nightmare when scaled across:

o A city full of smart sensors

o A logistics company with different tracking tools

o An agricultural project with diverse hardware suppliers

Without a standard protocol or data model, every application must be customized for
each device’s encoding format. That’s time-consuming, error-prone, and not scalable.

The Solution – IoT Data Broker

Enter the IoT Data Broker — a middleware platform that:

• Receives raw data from different sensors (e.g., Sensor X, Y, Z)

• Understands how each vendor encodes their data

• Decodes the raw values into a standardized, common format

• Delivers this cleaned-up, consistent data to applications (e.g., App A, B, C)

So now, instead of teaching every application how to understand every sensor, you only
have to connect them to the data broker, which acts like a universal translator.

Bonus – Commercial Use of Data Brokers

IoT data brokers are not just technical tools — they can also become business tools.

For example:

• A company collects air quality data via sensors.

• They use a broker to clean and standardize this data.

• Then they sell access to other companies (like weather apps, pollution monitoring
services, etc.).

• This becomes a revenue stream, depending on how valuable or unique the data is.

2.SCADA (Supervisory Control and Data Acquisition)

A Bridge from Old to New in Industrial Control

In the fast-moving world of networking and IoT, it’s easy to think everything is brand new —
but industrial control systems like SCADA have been around for decades.

They’re the backbone of large-scale automation in industries like energy, water, gas, and
manufacturing.

A Bit of Background – The Pre-IP Era

Long before Wi-Fi and the internet became common, industrial systems still needed ways
to:

• Monitor sensor data (e.g., pressure, flow, temperature)

• Control machines remotely (e.g., turning a pump on or off)

This is where SCADA comes in.

Originally, SCADA systems used serial communication (e.g., RS-232 or RS-485), which are
older forms of physical connection — like a telephone wire — where one device would talk
directly to another in a master/slave relationship.

At that time:
 • IP-based communication didn’t exist

• SCADA systems used proprietary protocols built for specific industries

• Each system was isolated, hard-wired, and had limited remote access

Evolution with IP and Ethernet

As the internet (IP networking) became the standard for everything — from emails to
enterprise software — these older SCADA systems began to adapt.

SCADA protocols, once designed for serial links, were re-engineered to run over:

• Ethernet

• IPv4/IPv6 networks

This was a game-changer:

• SCADA systems became more open and interoperable

• Remote monitoring and control could now happen over the internet

• It allowed for real-time data collection, remote diagnostics, and global decision-
making

SCADA in Action Today

SCADA systems are still very much alive — especially in:

• Utilities (power grids, water treatment, oil & gas)

• Manufacturing and Industry (automated production lines, robots)

• Building Management (HVAC, elevators, energy meters)

These systems include:

• Sensors and actuators in the field (e.g., valves, meters)

• RTUs (Remote Terminal Units) or PLCs (Programmable Logic Controllers) to

interact with them

• A central control system (like a dashboard or command center) that

sends/receives data

Common Protocols in SCADA

Different industries use different communication protocols within their SCADA networks.
These include:

1. Modbus (and variants)

o Used in industrial automation, smart buildings, and transport systems

o Simple and efficient, works on master/slave principles

o Can now run over Ethernet and TCP/IP (called Modbus TCP)

2. DNP3 (Distributed Network Protocol)

o Designed for reliability in harsh environments (e.g., power grids)

o Supports event logging, time stamping, and encryption

3. IEC 60870-5-101 / -104

o International standards for telecontrol in electric power systems

o Used in European and global utility infrastructures

2.1Adapting SCADA for IP

But as the industrial world started embracing Ethernet in the 1990s, a big shift happened:
legacy industrial protocols had to evolve to work with IP networks.

This change was driven by a few clear needs:

• Industries wanted to connect SCADA systems to corporate networks (WANs).

• They wanted to reuse existing infrastructure (Ethernet cables, routers, etc.).

• And they needed easier integration, scalability, and remote access.

So began the process of "IP-ifying" SCADA protocols.

Protocol Evolution – From Serial to IP

Protocols that were once tightly tied to serial cables were adapted to run over Ethernet
and IP.

To do this:

• OSI model principles were adopted (especially by standards bodies like IEC).
 • Protocol specifications were updated and republished, showing how to operate
over IP.

• Standard port numbers were assigned, just like how HTTP uses port 80 or HTTPS
uses 443.

Why This Was a Big Deal

Industries had invested heavily in:

• Remote sensors, actuators, and controllers

• Substations and field equipment

• SCADA software built for legacy protocols

Rewriting or replacing everything would have been too costly and risky.
Instead, adapting protocols like DNP3 and Modbus for IP allowed industries to:

• Keep their existing gear

• Upgrade their network capabilities

• Integrate SCADA with cloud services, data analytics, and corporate IT

Deep Dive: DNP3 as an Example

Let’s look at DNP3 (Distributed Network Protocol 3), a widely used protocol in utilities.

DNP3 Architecture:

• Master: A central control computer (e.g., in a utility’s headquarters)

• Slave (Outstation): A remote field device (e.g., in a power substation)

Functionality:

• The outstation collects data (e.g., is the breaker on or off? What's the current
voltage?).

• It can send data either:

o On request from the master, or

o Asynchronously (e.g., to report a fault or trigger an alarm).

• The master receives the data, logs it, and can issue commands like:
 o Start a motor

o Reset a breaker

o Change a threshold value

2.2Tunneling Legacy SCADA Over IP Networks

As industries modernize their infrastructure, they often face a mismatch between older
SCADA systems and newer IP-based networks.

• Some older SCADA devices don’t natively support IP, meaning they can’t just plug
into the internet or an Ethernet network.

• But ripping out and replacing these devices is too expensive and would disrupt
operations.

• So instead of replacing them, industries use "tunneling" techniques to carry the

old serial data over IP — kind of like giving legacy data a ride on a modern highway.

What Is Tunneling?

Tunneling means taking data meant for an older system (like serial RS-232
communication) and encapsulating it inside a modern IP-based packet (TCP or UDP), so it
can travel across an IP network.

This is done using a method called a raw socket connection.

• A socket is like a virtual door — a combination of an IP address + port number that

lets applications talk over a network.

• A raw socket means the data is passed through as-is — there’s no change to the
legacy protocol, it’s just packed and unpacked across IP.

You wrap the old serial message in an IP envelope, send it over the network, and unwrap
it at the other end.

Three Common Tunneling Scenarios

Scenario A – Routers Do the Work

• Both the SCADA server (master) and the RTUs (slaves) are legacy devices,
connected via serial cables to their routers.

• The routers are smart — they encapsulate the serial data into raw sockets and
send it across the IP network.
 • At the other end, the receiving router unpacks the data and forwards it over serial to
the connected RTU.

Scenario B – Use of IP/Serial Redirector Software

• Here, the SCADA server is older and doesn’t support IP natively.

• A special IP/serial redirector software is installed on the server. It:

o Maps the server’s serial COM ports to IP ports.

o Sends data over IP using raw socket encapsulation.

• On the RTU side, the setup remains the same — routers receive and decode the IP
packets back into serial.

🅲️ Scenario C – Native Raw Socket Support

• The SCADA server is modernized — it natively understands raw socket

connections.

• It can directly encapsulate and send serial messages over IP, without needing
redirector software or router translation.

• RTUs still connect via routers that handle the other end of the tunneling.

Why This Matters

Legacy SCADA systems aren’t going away any time soon — they're still critical in:

• Utilities (electricity, water, gas)

• Manufacturing plants

• Remote monitoring stations

By tunneling serial protocols over IP, companies get to:

• Extend the life of their existing equipment

• Integrate older devices with modern networks

• Save time and cost on infrastructure overhaul

2.3SCADA Protocol Translation

But there’s another, smarter approach: instead of just wrapping the data, we can
translate it into a proper IP-friendly version.

What Is Protocol Translation?

Imagine you have two people who speak different languages — one only speaks Hindi, and
the other only speaks English. A translator listens to one, converts the message, and
delivers it in the other’s language.

In SCADA systems:

• The legacy RTU "speaks" in serial DNP3 (non-IP).

• The modern master application "understands" only DNP3 over IP.

• A device like an IoT gateway sits in between and translates the protocol so both
ends can communicate.

How Protocol Translation Works (Story with Context)

• There are two RTUs that communicate using serial DNP3 (the old format).

• There are two master servers that communicate using DNP3 over IP (modern
format).

• In between them is an IoT gateway — think of this as a smart translator.

o It listens to the serial communication from the RTUs.

o It then translates the message into the IP version of DNP3.

o This translated message is then forwarded to the modern master application

over the IP network.

o Responses from the master are also translated back into the serial version
for the RTUs.

Bonus Benefit: Intelligence at the Edge (Fog Computing)

The IoT gateway here isn’t just a dumb cable — it’s doing some computing. It’s running
translation software, possibly applying data filtering, formatting, or even security
checks.

This is an example of "computing at the edge", or fog computing:

 • Instead of sending all the raw data to the cloud or a central server to be processed,
some of the "thinking" happens closer to where the data is generated — at the
network’s edge.

• This reduces latency, saves bandwidth, and makes the system more scalable and
efficient.

2.4SCADA in Modern, Constrained Networks

• Many industries today still rely on legacy SCADA systems and industrial protocols
like DNP3/IP, Modbus/TCP, and IEC 60870-5-104.

• These systems typically use IPv4 and often communicate over UDP (User
Datagram Protocol) because it’s lightweight and better suited for real-time,
constrained environments.

The Challenge:

• As IoT expands, many of these systems are now being deployed over LLNs (Low-
power and Lossy Networks).

• LLNs are found in environments with limited power, computing capacity, and
memory — like wireless sensor networks, remote field installations, or smart
meters.

• These LLNs often use 6LoWPAN and RPL, which are standards designed
specifically for IPv6-only communication.

But here’s the issue:

Legacy devices and SCADA servers only understand IPv4, while the LLN only supports
IPv6.

The Solution: MAP-T (Mapping of Address and Port using Translation)

What is MAP-T?

MAP-T (defined in RFC 7599) is a protocol translation mechanism that allows IPv4-only
devices to communicate across IPv6-only networks.

It works by:

• Translating the IPv4 address and port information into an IPv6 packet format.

• Routing the data through the IPv6-only LLN.

 • Translating it back to IPv4 at the other end so the IPv4 SCADA server can
understand it.

This happens transparently, meaning the devices on either end don’t need to know that
IPv6 is being used in the middle.

Why Not Just Upgrade Everything to IPv6?

It’s not that simple.

• Most legacy industrial and SCADA devices were built long before IPv6 became
popular — and they’re costly to replace.

• Many mission-critical systems can’t afford downtime or disruption.

• Even today, a large number of OT (Operational Technology) systems are IPv4-only.

3.Generic Web-Based Protocols

These are common internet protocols originally designed for websites, web apps, and
enterprise platforms, but are now being reused in IoT. Examples include:

Leveraging these protocols simplifies the integration of IoT devices and data from
prototyping to production, enabling seamless connectivity and scalability.

Key Benefits

• Familiarity: Programmers with basic web programming skills can develop IoT
applications, fostering innovation in handling real-time IoT data.

• Scalability: Well-understood web scaling methods support large-scale IoT

deployments.

• Versatility: Protocols support diverse use cases, such as triggering video capture or
sending notifications to collaboration tools (e.g., Cisco Spark) based on IoT events.

Considerations for IoT Protocol Selection

• Constrained vs. Non-Constrained Environments:

o Constrained Nodes/Networks: Devices with limited power, memory, or

bandwidth (e.g., low-power sensors) require lightweight protocols.

o Non-Constrained Networks: Ethernet, Wi-Fi, or 3G/4G networks support

verbose data models (e.g., XML, JSON) and protocols like HTTP/HTTPS or
WebSocket.
 • Client vs. Server Role:

o Client-Side: IoT devices pushing data (e.g., weather stations, health scales)
initiate connections and require lightweight client implementations.

o Server-Side: Devices accepting incoming connections (e.g., video cameras)

need server-side implementations but must limit connections due to
resource constraints.

Key Web-Based Protocols

1. HTTP/HTTPS (Hypertext Transfer Protocol/Secure)

• Description: Foundation of the World Wide Web, using a client-server model for
data exchange.

• Characteristics:

o Operates over TCP, secured via TLS/SSL (HTTPS).

o Supports verbose data formats like XML or JSON.

o Stateless, request-response model with methods (GET, POST, PUT, DELETE).

• IoT Relevance:

o Suitable for non-constrained networks (e.g., Ethernet, Wi-Fi, 3G/4G).

o Embedded web server software now requires minimal memory (tens of

kilobytes), enabling use on some constrained devices.

o Client-side HTTP is ideal for devices pushing data (e.g., weather stations,
health scales).

o Server-side HTTP is used for devices like video cameras but requires limiting
incoming connections.

• Use Cases: IoT gateways, cloud-based IoT platforms, devices with sufficient
resources.

2. WebSocket

• Description: Enables full-duplex, real-time communication over a single, long-lived

connection.

• Characteristics:

o Starts with an HTTP handshake, then upgrades to WebSocket.

 o Supports bidirectional communication with low latency.

o Suitable for real-time data exchange.

• IoT Relevance:

o Ideal for non-constrained networks where real-time updates are needed.

o Used in IoT applications requiring continuous data streams (e.g., live sensor
data, dashboards).

• Use Cases: Real-time monitoring, collaborative IoT applications.

3. XMPP (Extensible Messaging and Presence Protocol)

• Description: A protocol for real-time messaging, presence, and collaboration,

extended for IoT use (XMPP-IoT).

• Characteristics:

o Supports asynchronous, event-driven communication.

o Facilitates interactions between IoT devices and collaborative tools (e.g.,

voice, video, chat).

o Extensible for IoT-specific use cases (see www.xmpp-iot.org).

• IoT Relevance:

o Simplifies communication between people and IoT devices.

o Suitable for applications integrating IoT with human collaboration (e.g.,

instant notifications to technicians).

• Use Cases: Collaborative IoT applications, real-time alerts, smart environments.

4.IoT Application Layer Protocols

When considering constrained networks and/or a large-scale deployment of constrained
nodes, verbose web based and data model protocols, as discussed in the previous section,
maybe too heavy for IoT applications.

To address this problem, the IoT industry is working on new lightweight protocols that are
better suited to large numbers of constrained nodes and networks.
CoAP
CoAP stands for Constrained Application Protocol. working group as a lightweight
protocol to manage and communicate with constrained devices — think small sensors,
actuators, or embedded systems that have:

• Limited power

• Limited memory

• Limited network bandwidth

In simpler terms: CoAP is like HTTP but optimized for tiny devices and low-power
networks.

What Can CoAP Do?

Just like HTTP, CoAP is resource-oriented and based on REST principles. Devices (like
temperature sensors) expose their functions or data as resources (like a webpage), and
clients can interact with these using methods like:

• GET – to read data (e.g., get temperature)

• POST – to send data (e.g., send a command)

• PUT – to update configurations

• DELETE – to remove settings or data

But CoAP has extra features tailored for IoT:

• Works over UDP (instead of TCP like HTTP) – faster and lighter for small devices.

• Supports message reliability through confirmable messages.

• Handles asynchronous communication efficiently.

• Supports multicast – to talk to many devices at once (great for group commands or
updates).

• Has low overhead – messages can be just a few bytes long.

CoAP Messaging Model (Reliable Even on UDP)

Because CoAP uses UDP (which is connectionless and doesn’t guarantee delivery), it adds
its own reliability mechanism:

• There are 4 types of messages:

1. Confirmable (CON) – requires acknowledgement.

2. Non-confirmable (NON) – no ACK expected (used for fast, one-way

updates).

3. Acknowledgement (ACK) – response to a confirmable message.

4. Reset (RST) – sent when a message is unrecognized or rejected.

Every message has a unique Message ID (e.g., 0x47) to detect duplicates and manage
retransmissions. If a message is marked CON, it will be retransmitted until an ACK is
received.

Example:

• A utility center (client) sends a GET request to a temperature sensor (server), tagged
with ID 0x47 and marked as CON.

• The sensor replies with an ACK, referencing the same ID and including the
temperature data.

• This ensures reliable delivery even over unreliable UDP.

CoAP Security

CoAP supports DTLS (Datagram Transport Layer Security) for encrypted and secure
communication. There are 4 security modes:

1. NoSec – no encryption (testing/devices in safe environments).

2. PreSharedKey – shared key known in advance.

3. RawPublicKey – public keys without certificates.

4. Certificate – full X.509 certificate-based authentication.

At minimum, NoSec and RawPublicKey must be supported.

CoAP Message Structure

A CoAP message is designed to be small and efficient:

• Header (4 bytes) – fixed-length, includes type, code, message ID

• Token (0–8 bytes) – identifies matching requests/responses

• Options – optional info (like headers in HTTP)

• Payload – actual data (optional)

General Structure

| Header (4 bytes) | Token (0-8 bytes) | Options (0 or more) | Payload (optional) |

Header Fields

1. Ver (Version, 2 bits):

o Indicates the CoAP version number.

o Current version: 01 (binary).

2. T (Type, 2 bits):

o Specifies the message type:

▪ 00: Confirmable (CON) - Requires acknowledgment.

▪ 01: Non-confirmable (NON) - No acknowledgment needed.

▪ 10: Acknowledgment (ACK) - Confirms receipt of a CON message.

▪ 11: Reset (RST) - Indicates an error or inability to process.

3. TKL (Token Length, 4 bits):

o Specifies the length of the Token field (0–8 bytes).

o Values 9–15 are reserved and invalid.

4. Code (8 bits):

o Indicates the request method (for requests) or response status (for

responses).

o Format: c.dd (c = class, dd = detail).

▪ Request Codes (Class 0):

▪ 0.01: GET
 ▪ 0.02: POST

▪ 0.03: PUT

▪ 0.04: DELETE

▪ Response Codes (Classes 2, 4, 5):

▪ 2.00: OK (Success)

▪ 2.01: Created

▪ 2.04: Changed

▪ 4.00: Bad Request

▪ 4.04: Not Found

▪ 5.00: Internal Server Error

5. Message ID (16 bits):

o A unique identifier for matching CON/ACK and NON/RST messages.

o Used for detecting duplicates and correlating messages.

For larger data transfers (like firmware updates), CoAP uses Block-wise Transfer (RFC
7959) – splits data into chunks sent in multiple request/response pairs.

CoAP Network Flexibility

CoAP can run over:

• IPv4 or IPv6

• UDP (main) or SMS (used in mobile networks)

• Secure transport like DTLS, and possibly TCP, TLS, or WebSockets in the future

Supports Proxying:

• CoAP can map to HTTP, so proxies can translate between them (e.g., HTTP clients
accessing CoAP devices).

• The proxy can sit anywhere, not just between networks.

MQTT
MQTT (Message Queuing Telemetry Transport), specifically for industries like oil and gas.
These environments were harsh, remote, and often had unreliable communication
networks. So, MQTT was designed to be:

• Lightweight

• Reliable

• Efficient in low-bandwidth, high-latency environments

• Ideal for constrained devices like sensors

Enable central servers to monitor and control a large number of sensors spread across
vast, unreliable networks.

Key Characteristics

• Transport: Operates over TCP, with optional TLS for security.

• Architecture: Publish-subscribe model with a central broker facilitating message

exchange.

• Efficiency: Minimal overhead (2–5 byte header), suitable for constrained devices.

• Reliability: Supports three Quality of Service (QoS) levels for message delivery:

o QoS 0: At most once (fire-and-forget, no acknowledgment).

o QoS 1: At least once (acknowledged delivery).

o QoS 2: Exactly once (guaranteed delivery without duplication).

• Use Cases: Remote monitoring, telemetry, smart homes, industrial IoT, real-time
data streaming.

• IoT Relevance: Asynchronous, event-driven communication reduces bandwidth

usage, making it suitable for IoT devices in constrained environments.

MQTT Architecture: Client-Server & Publish-Subscribe

MQTT uses a publish/subscribe model with a central message broker (server), unlike
traditional request-response models like HTTP or CoAP.

How it works:

1. Publisher (e.g., a sensor) sends data (e.g., temperature, humidity) to the broker.
 2. Broker receives data and stores/distributes it.

3. Subscriber (e.g., a monitoring dashboard) tells the broker, “I’m interested in

temperature data.”

4. Broker pushes data to all interested subscribers when it’s published.

The publisher and subscriber don’t need to know about each other—the broker handles
it all. This decoupling is what makes MQTT flexible and powerful.

MQTT Protocol Characteristics

Transport Layer:

• Runs over TCP (default port 1883)

• Can be secured using TLS (port 8883)

• Supports WebSockets (great for web-based applications)

Message Format:

• Very small overhead: 2-byte fixed header

• Optional variable header and payload

• Max payload: 256 MB

• Much lighter than CoAP or HTTP—ideal for bandwidth-constrained environments

Message Types:

• MQTT has 14 message types (e.g., CONNECT, PUBLISH, SUBSCRIBE, etc.)

• Each type is identified using the Message Type field

• Includes other flags like:

o DUP (message was sent before but not acknowledged)

o QoS (Quality of Service level)

o Retain (store the message for new subscribers)

o Remaining Length (size of remaining data in the message)

 Quality of Service (QoS) Levels in MQTT

MQTT offers three levels of message delivery guarantees between the publisher and the
subscriber (via the broker):

1. QoS 0 – "At most once":

o Fire and forget

o No acknowledgements

o Might not be delivered

o Low overhead, fastest

2. QoS 1 – "At least once":

o Message is acknowledged by the receiver

o If no ACK is received, it is retransmitted

o Might lead to duplicate messages

3. QoS 2 – "Exactly once":

o Most reliable and safest

o Ensures no message is lost or duplicated

o Uses four-step handshake (PUBLISH → PUBREC → PUBREL → PUBCOMP)

o Highest overhead

MQTT is symmetric in its protocol—both client and server can send and receive messages.

When to Use MQTT in IoT

MQTT is best suited for:

• Remote monitoring systems

• Constrained devices

• Low-bandwidth and high-latency networks

• Use cases where:

o Device-to-server communication is more important than device-to-device.

 o Data needs to be buffered and sent reliably even if a device temporarily loses
connectivity.

MQTT Message Format

MQTT messages are compact, consisting of a Fixed Header, an optional Variable Header,
and an optional Payload. The message format is designed to minimize overhead, making it
suitable for constrained networks.

General Structure

| Fixed Header (2–5 bytes) | Variable Header (optional, variable length) | Payload (optional,
variable length) |

1. Fixed Header

The Fixed Header is present in all MQTT messages and contains control information.

Fields:

• Message Type (4 bits): Specifies the type of MQTT control packet (1–14, 0 and 15 are
reserved):

o 1: CONNECT (Client requests connection to broker).

o 3: PUBLISH (Publish a message to a topic).

o 8: SUBSCRIBE (Client subscribes to topics).

o 10: UNSUBSCRIBE (Client unsubscribes from topics).

o 14: DISCONNECT (Client terminates connection).

• Flags (4 bits): Specific to message type, controlling behavior:

o For PUBLISH:

▪ DUP (bit 3): Duplicate delivery flag (1 if retransmitted, 0 otherwise).

▪ QoS (bits 2–1): Quality of Service level (00, 01, 10 for QoS 0, 1, 2).

▪ Retain (bit 0): Retain flag (1 to store message for new subscribers, 0
otherwise).

o For other messages, flags are fixed or reserved.

 • Remaining Length (1–4 bytes): Length of the Variable Header and Payload
combined, encoded as a variable-length integer (up to 268,435,455 bytes). Each
byte uses 7 bits for the value and 1 bit to indicate continuation.

Difference Between CoAP and MQTT

Application Protocols for IOT
IoT application protocols enable communication between devices, gateways, and cloud
platforms, supporting data exchange, control, and monitoring.

They address IoT challenges like low power, limited bandwidth, scalability, and security.
Protocol choice depends on device constraints, network type, and application needs (real-
time, event-driven, or request-response).

Key Considerations

• Constrained Devices/Networks: Lightweight protocols for low-power, low-memory

devices (e.g., sensors).

• Non-Constrained Networks: Support verbose protocols (e.g., JSON, XML) on Wi-Fi

or 4G.

• Scalability: Must manage large device networks.

• Security: Requires encryption (TLS/DTLS) and authentication.

• Familiarity: Web-based protocols ease integration.

Key IoT Application Protocols

1. MQTT (Message Queuing Telemetry Transport)

o Description: Lightweight, publish-subscribe protocol for low-bandwidth,

unreliable networks.

o Framework: Broker-based, TCP transport, TLS for security.

o Features: QoS levels (0: at most once, 1: at least once, 2: exactly once),
topic wildcards, persistent sessions.

o IoT Relevance: Ideal for constrained devices, real-time telemetry.

o Use Cases: Smart homes, industrial monitoring.

2. CoAP (Constrained Application Protocol)

o Description: RESTful protocol for constrained devices, similar to HTTP.

o Framework: Client-server, UDP transport, DTLS for security.

o Features: Compact binary format, multicast, resource observation.

o IoT Relevance: Suits ultra-constrained devices, supports device discovery.

 o Use Cases: Sensors, industrial IoT.

3. HTTP/HTTPS

o Description: Web communication protocol for RESTful APIs, cloud

integration.

o Framework: Client-server, TCP transport, TLS for security.

o Features: Supports JSON/XML, GET/POST methods.

o IoT Relevance: Fits non-constrained devices (e.g., gateways).

o Use Cases: Cloud platforms, smart appliances.

4. WebSocket

o Description: Full-duplex, real-time communication over a single

connection.

o Framework: Starts with HTTP handshake, upgrades to WebSocket, TCP

transport, TLS for security.

o Features: Bidirectional, low-latency, supports text/binary data.

o IoT Relevance: Ideal for real-time applications on non-constrained

networks.

o Use Cases: Real-time dashboards, control systems.

5. XMPP (Extensible Messaging and Presence Protocol)

o Description: Real-time messaging and presence protocol, extended for IoT.

o Framework: Decentralized client-server, TCP transport, TLS for security.

o Features: Asynchronous, supports messaging, presence, IoT extensions.

o IoT Relevance: Suits human-device interactions in non-constrained

environments.

o Use Cases: Collaborative apps, smart offices, alerts.

Comparison of IoT Application Protocols

Constrained
Protocol Transport Model Overhead Key IoT Use Cases
Devices
 Publish- Telemetry, smart
MQTT TCP Low Yes
Subscribe homes, monitoring

Client-Server Sensors, industrial IoT,

CoAP UDP Very Low Yes
(REST) discovery

Client-Server Gateways, cloud, non-

HTTP/HTTPS TCP High Limited
(REST) constrained

Real-time dashboards,
WebSocket TCP Full-Duplex Medium Limited
control

Collaborative apps,
XMPP TCP Client-Server High Limited
alerts