Module 4: IoT Network Layer

The Business Case for IP

 IoT Devices and Data Flow:

o IoT devices send data to be consumed, monitored, or controlled by centralized or
distributed data centers.
o Applications running on cloud servers or at the network edge (fog computing)
interact with these devices.
o IP enables seamless data transmission between IoT devices and data centers.

Key Advantages of the IP Suite for IoT

1. Open and Standards-Based

o IP protocols are developed by the IETF (Internet Engineering Task Force).

o Ensures interoperability, security, and efficient management.

o Encourages use of open protocols rather than proprietary solutions.
2. Versatile
o Compatible with a wide range of physical and link-layer technologies (Ethernet,
Wi-Fi, Cellular).
o Adapts easily to future technologies without altering upper layers.
o Devices using IP can be easily replaced or upgraded without compatibility issues.
3. Ubiquitous
o Present in all modern operating systems (including embedded OS like Contiki,
TinyOS).
o Supports both IPv4 and IPv6.
o IP is the most widely supported protocol across IoT platforms.
4. Scalable

o With IPv6, trillions of devices can be given unique addresses.

o Features like subnetting, hierarchical routing, and multicasting support vast
deployments.
o Example: A smart grid with millions of smart meters using IPv6 to communicate
with control centers

5. Manageable and Highly Secure

o IP supports SNMP, NetFlow, Syslog, etc., for remote monitoring.

o Can integrate with firewalls, intrusion detection systems, VPNs.
o Protocols like IPsec and TLS secure the data in transit.

6. Stable and Resilient

o IP suite has matured over decades, Over 30 years of proven deployment.
o TCP/IP handles retransmission, flow control, and congestion handling.

o Proven reliability in mission-critical applications like banking and healthcare.

o Supported by a large ecosystem of IT professionals.

7. Consumer Market Adoption

o Most consumer devices use IP-based networks like smart TVs, phones, tablets,
smart fridges, and printers.
o Enables seamless communication in smart homes.
o Users can control IoT devices over their home Wi-Fi or remotely using apps.
o Facilitates integration of IoT products with consumer devices like smartphones
and tablets.
8. Innovation Factor

o Open IP stack supports rapid development.

o Reuse of web-based tools and infrastructure (HTTP, MQTT, CoAP).
 o Examples: Smart home hubs, health monitoring apps, logistics tracking solutions.

3. Adoption vs Adaptation of IP in IoT

 Adoption:
o IP adoption refers to IoT devices directly running the full IP protocol stack,
typically including:
 IPv6/IPv4
 TCP/UDP
 Application protocols like HTTP, CoAP, or MQTT
Characteristics:
o Devices are smart and capable (have enough CPU, RAM, storage).
o Enable end-to-end communication across the internet without translation.
o Devices are directly addressable using IP addresses (especially IPv6).
o Allows remote management, OTA updates, security policies, etc.
Example: Modern SCADA with Ethernet

 Adaptation:
IP adaptation refers to using non-IP protocols on the device side, while a
gateway or proxy translates this communication into IP-based messages.
✅ Characteristics:
 Used for legacy or constrained devices.
 Devices use local, lightweight protocols (e.g., Modbus, Zigbee, Bluetooth).
 Gateways handle protocol conversion and forward data using IP.
 Communication is not end-to-end IP; the gateway is the endpoint for IP traffic.
Example: SCADA via serial port connected to a gateway

Discuss the factors to be considered for selecting a model (adoption/adaptation) for last-
mile connectivity.
Factors for Selecting Adoption vs Adaptation

1. Bidirectional vs Unidirectional Data Flow

2. Overhead of last-mile communication
 3. Data flow model
4. Network diversity

1) Bidirectional vs. Unidirectional Communication

 Unidirectional Communication:
o Some devices only need to send data, not receive it.
o Example: A temperature sensor that periodically transmits readings to a cloud
server.
o These devices do not need IP overhead, so adaptation is ideal.
o Protocols like Zigbee or Bluetooth Low Energy (BLE) can be used for
transmission, and a gateway converts this to IP for Internet access.
 Bidirectional Communication:
o Devices that send and receive data require a more robust communication model.
o For instance, Over-The-Air (OTA) updates, acknowledgments, control
commands, and diagnostics require end-to-end IP connectivity.
o Devices like smart thermostats or IP cameras need IP adoption to support
bidirectional traffic and secure communication channels (e.g., TLS, MQTT over
TCP/IP).

2) Overhead of Communication
o IPv4 has 20 bytes of header at a minimum, and IPv6 has 40 bytes at the IP
network layer. For the IP transport layer, UDP has 8 bytes of header overhead,
while TCP has a minimum of 20 bytes.
o If the data to be forwarded by a device is infrequent and only a few bytes, you can
potentially have more header overhead than device data—again, particularly in
the case of LPWA technologies.
3) Data Flow Model
o One benefit of the IP adoption model is the end-to-end nature of communications.
o Any node can easily exchange data with any other node in a network, although
security, privacy, and other factors may put controls and limits on the “end-to-
end” concept.
o In many IoT solutions, a device’s data flow is limited to one or two applications.
 o In this case, the adaptation model can work because translation of traffic needs to
occur only between the end device and one or two application servers.
4) Network Diversity
o One of the major drawbacks of the IP adaptation model is its reliance on
specific physical (PHY) and MAC layers .
o For example, ZigBee devices must only be deployed in ZigBee network islands.
o This same restriction holds for ITU G.9903 G3-PLC nodes.
o Therefore, a deployment must consider which applications have to run on the
gateway connecting these islands and the rest of the world.

Differentiate between IP adoption and IP adaptation in IoT. Give examples.

Aspect Adoption Adaptation

Replaces all non-IP layers with IP-
Definition Translates non-IP to IP via gateways
based ones
Non-IP devices connect through
Architecture End-to-end IP communication
Application Layer Gateways (ALGs)
More complex due to translation and
Complexity Simpler to manage over time
compatibility
SCADA via serial port connected to a
Example SCADA over Ethernet using IPv4
gateway

 SCADA Adoption: SCADA devices use Ethernet and IP directly.

 SCADA Adaptation: Legacy devices use serial links; a gateway translates
protocols to IP.

4.Need for optimization

Constrained Nodes and Networks
Constrained Nodes:
  Devices with limitations in processing power, RAM/ROM, power, and
communication are called constrained nodes

 Even if an IoT node has a full IP stack, communication may suffer due to:
1. Unpredictable throughput
2. High latency or jitter
3. Slow convergence during route or topology changes

Example: A sensor node at the edge of a smart farm may experience weak
signal or interference from machinery. Despite supporting IPv6, it fails to
maintain stable end-to-end IP connectivity.

 Power consumption is a key characteristics of constrained nodes. Many IOT devices are
battery powered with battery life varying from few months to 10+years. But networking
technologies such as Ethernet, WiFi and cellular are not capable of multilayer battery life.
 The IOT constrained node scan be classified as

Device Type Characteristics Communication Strategy

Adaptation model — use
Very Constrained Low CPU, RAM, sporadic data,
lightweight local protocols via
Devices weak security
gateways
Moderately Can run basic IP stack or non-IP Either optimized IP adoption or
Capable Devices stack adaptation model
Full IP adoption, but bandwidth
High-Resource Similar to PCs, but with limited
constraints must be considered in
Devices bandwidth
app logic

Constrained Networks (LLNs):

 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.
  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). Examples: narrowband PLC, low-power wireless.
 A constrained network can have high latency and a high potential for packet loss.
 They operate between a few kbps and a few hundred kbps and • may utilize a star,
mesh, or combined network topologies, ensuring proper operations.

IP Versions in IoT
 Some IoT protocols are tightly coupled with IPv4-only implementations.
 Examples include legacy SCADA protocols like:

 DNP3/IP (IEEE 1815)

 Modbus TCP
 IEC 60870-5-104

 These protocols were built on IPv4 infrastructure and are not designed to support
IPv6.

 Devices using Ethernet or Wi-Fi generally support both IPv4 and IPv6 stacks at the
network layer.

 The application protocol used on top of that interface is the deciding factor.

 Modern protocols such as:

 HTTP / HTTPS
 CoAP
 MQTT
 XMPP

are all designed by the IETF and natively support both IPv4 and IPv6.

5.Optimizing IP for IoT

 Adaptation Layer allows IP to run over constrained networks.
 Are defined by IETF via RFC(Request for comments)s.
 The main examples of adaptation layers optimized for constrained nodes or “things” are
the ones under the 6LoWPAN working group and its successor, the 6Lo working group.
 The initial focus of the 6LoWPAN working group was to optimize the transmission of
IPv6 packets over constrained networks such as IEEE 802.15.4.
 The figure 5.2 shows an example of an IOT protocol stack using 6LoWPAN adaptation
layer beside the well known IP protocol stack for reference

 The 6LoWPAN working group published several RFCs, but RFC 4994 is foundational
because it defines frame headers for the capabilities of header compression,
 fragmentation, and mesh addressing.

 Figure 5-3 shows some examples of typical 6LoWPAN header stacks.

Header Compression

 IPv6 header compression for 6LoWPAN was defined initially in RFC 4944 and
subsequently updated by RFC 6282.
 This capability shrinks the size of IPv6’s 40-byte headers and User Datagram Protocol’s
(UDP’s) 8-byte headers down as low as 6 bytes combined in some cases.
 Figure 5- 4 highlights an example that shows the amount of reduction that is possible
with 6LoWPAN header compression.
Fragmentation

 The maximum transmission unit (MTU) for an IPv6 network must be at least 1280 bytes.
 The term MTU defines the size of the largest protocol data unit that can be passed.
 For IEEE 802.15.4, 127 bytes is the MTU.
 You can see that this is a problem because IPv6, with a much larger MTU, is carried
inside the 802.15.4 frame with a much smaller one.
 To remedy this situation, large IPv6 packets must be fragmented across multiple 802.15.4
frames at Layer 2
three primary fields: Datagram Size, Datagram Tag, and Datagram Offset. The 1-byte Datagram
Size field specifies the total size of the unfragmented payload.

Datagram Tag identifies the set of fragments for a payload

Finally, the Datagram Offset field delineates how far into a payload a particular fragment occurs.

Mesh Addressing

 The purpose of the 6LoWPAN mesh addressing function is to forward packets over
multiple hops.
 Three fields are defined for this header: Hop Limit, Source Address, and Destination
Address.
 Analogous to the IPv6 hop limit field, the hop limit for mesh addressing also provides
an upper limit on how many times the frame can be forwarded. Each hop decrements
this value by 1 as it is forwarded. Once the value hits 0, it is dropped and no longer
forwarded.
 The Source Address and Destination Address fields for mesh addressing are IEEE
802.15.4 addresses indicating the endpoints of an IP hop.
 Figure 5-6 6LoWPAN Mesh Addressing Header
Mesh-Under vs Mesh-Over Routing
Feature Mesh-Under Mesh-Over (Route-Over)
Routing Layer Link Layer (L2) Network Layer (L3, IP)
Forwarding 6LoWPAN handles forwarding IP routing (e.g., RPL)
Node Role Layer 2 forwarding tables Each node is an IP router
Gateway Role Converts L2 to L3 Normal IP router
Use Case Homogeneous networks Mixed network technologies

IOT application layer protocols:

 The two most popular lightweight protocols that are better suited to large number of
constrained nodes and networks are CoAP and MQTT.
 In Figure 2.19, CoAP and MQTT are naturally at the top of this sample IoT stack, based
on an IEEE 802.15.4 mesh network.
 CoAP deployed over UDP and MQTT running over TCP.

 CoAP was developed by the IETF Constrained RESTful Environments (CoRE)

working group.
  CoAP is a lightweight , binary, and RESTful protocol used for constrained networks and
devices, such as those found in IOT (Internet Of Things) applications.
 CoAP is based on REST architecture making it easier to integrate with web-based
applications.
 CoAP uses binary format which is more efficient than text based protocols.
 CoAP is designed to be lightweight, making it suitable for use in resource constrained
devices and networks.
 CoAP runs over UDP (User Datagram Protocol).
 For security, it uses DTLS (Datagram Transport Layer Security).

CoAP Messaging Model

 Designed for low-overhead communication between endpoints in constrained

environments.
 Message Components:
1. Header:
 Fixed length of 4 bytes
 Contains basic information like version, message type, token length, code,
and message ID.
2. Token:
 Variable length, 0 to 8 bytes
 Used to match responses with requests.
3. Options:
 Optional field used for additional message metadata (e.g., URI path,
content format).
4. Payload:
 Optional field for the actual data content
 Separated from options by a payload marker (0xFF) if present.
 Efficiency:

o The compact format ensures low bandwidth usage and minimal processing
complexity, suitable for constrained devices.
 Field Description
Ver (Version) Identifies the version of CoAP being used. Currently, it is set to version 1.
Specifies the message type. Four types: – CON (Confirmable) – NON (Non-
T (Type)
confirmable) – ACK (Acknowledgement) – RST (Reset)
TKL (Token
Specifies the length of the Token field, ranging from 0 to 8 bytes.
Length)
Indicates the request method (e.g., GET, POST) for requests, and the response
Code
code (e.g., 2.05) for responses. Refer to RFC 7252 for full code list.
Helps detect duplicate messages and is used to match ACK/RST responses to
Message ID
CON/NON messages.
A value of 0–8 bytes, used to match a response to a request. Length is defined
Token
by TKL.
Includes metadata like URI path, content type, etc. It helps identify the target
Options
resource and can support proxy functions.
Contains the actual application data (e.g., sensor reading). Optional. If present,
Payload
it's preceded by a payload marker (0xFF) to separate it from the Options field.

Message Queuing Telemetry Transport (MQTT)

 MQTT is a lightweight, publish-subscribe network protocol designed for low-
bandwidth, high-latency, or unreliable networks.
 It is ideal for communication between IoT devices, sensors, and applications.
 An MQTT client can act as a publisher to send data (or resource information) to an
MQTT server acting as an MQTT message broker.
 In the example illustrated in Figure 2.22, the MQTT client on the left side is a
temperature (Temp) and relative humidity (RH) sensor that publishes its Temp/RH data.
 The MQTT server (or message broker) accepts the network connection along with
application messages, such as Temp/RH data, from the publishers.
 It also handles the subscription and unsubscription process and pushes the application
data to MQTT clients acting as subscribers.
 The application on the right side of Figure 2.22 is an MQTT client that is a subscriber to
the Temp/RH data being generated by the publisher or sensor on the left.
 This model, where subscribers express a desire to receive information from publishers, is
well known.
 A great example is the collaboration and social networking application Twitter.
 With MQTT, clients can subscribe to all data (using a wildcard character) or specific
data from the information tree of a publisher.
 In addition, the presence of a message broker in MQTT decouples the data transmission
between clients acting as publishers and subscribers.
 In fact, publishers and subscribers do not even know (or need to know) about each other.
A benefit of having this decoupling is that the MQTT message broker ensures that
information can be buffered and cached in case of network failures.
 This also means that publishers and subscribers do not have to be online at the same time.
MQTT control packets run over a TCP transport using port 1883.
 TCP ensures an ordered, lossless stream of bytes between the MQTT client and the
MQTT server.
 Optionally, MQTT can be secured using TLS on port 8883, and WebSocket (defined in
RFC 6455) can also be used.
 Figure 2.23 provides an overview of the MQTT message format.
 Compared to the CoAP message format, MQTT contains a smaller header of 2 bytes
compared to 4 bytes for CoAP. The first MQTT field in the header is Message Type,
which identifies the kind of MQTT packet within a message. Fourteen different types of
control packets are specified in MQTT version 3.1.1. Each of them has a unique value
that is coded into the Message Type field. Note that values 0 and 15 are reserved. MQTT
message types are summarized in Table 2.5.
 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 sessions between each client and server consist of four phases: session
establishment, authentication, data exchange, and session termination.
 Each client connecting to a server has a unique client ID, which allows the identification
of the MQTT session between both parties. When the server is delivering an application
message to more than one client, each client is treated independently.
 The three levels of MQTT QoS :
Comparison between CoAP and MQTT
Data Analytics for IOT:
An Introduction to Data Analytics for IOT:

Structured vs unstructured data :

IOT data analytics overview: