MODULE 3

IP as the IoT Network Layer

Introduction:
In module 1, we have understood the architecture of IoT. IoT architecture is layered. In module 2,
we have discussed the bottom two layers: layer 1 (PHY) and layer 2(MAC). We have also seen
the different access technologies with respect to these layers.
In module 3 we discuss remaining upper layers. First let’s describe 3rd layer i.e, Network Layer.
We know that Internet Protocol IP is the majorly used network layer protocol. To start, let’s look
at the advantages of the Internet Protocol (IP).
Internet Protocol (IP) has its own advantages. Because of these advantages we use IP as a layer 3
protocol even in IoT
Advantages of Internet Protocol
1. Open and standards-based: IP is open and standard based solution for devices and
applications of IoT as it guarantees interchangeability and interoperability, security and
management.
2. Versatile: IP architecture is well equipped to cope up with any type of physical and data
link layers such as Ethernet, Wi-Fi, Cellular etc.This makes IP an ideal protocol and does
not require any changes.
3. Ubiquitous: Almost all Operating Systems of PC, servers, Embedded devices are
integrated with dual IP stack (IPV4 and IPV6). So IP is available almost everywhere to use
in IoT solutions
4. Scalable: IP is massively deployed and tested for robust scalability. IP supports huge
number of new devices.
5. Manageable and highly secure: Well known network and security management tools are
easily leveraged with an IP network layer.
6. Stable and resilient: IP exists from past 30 years. It has a large and well-established
knowledge base. It has been used in many critical infrastructures such as financial and
defense networks. It is deployed for many critical services, such as voice and video. Many
IT professionals can help in designing, deploying and operating IP-based solutions. IP
addresses the network issues such as naming, time distribution, traffic prioritization,
isolation etc. very well.
7. Consumer’s market adoption: IoT consumers access IoT applications and devices
through smart/phones, tablets or PCs (broadband/wireless). IP is the common protocol that
links IoT consumer space to the accessing devices.
8. The innovation factor: IP has very high innovation factor. Many advancements have
happened in the past two decades.
We know that IoT aims to merge IT with OT. IP is widely used in IT sector, but in OT some were
using IP some were not using. So, there is a necessity to convert these non IP layers of OT to IP,
if we want to give IoT solutions merging IT with OT.
The following two models are proposed to achieve a common network layer between IT and OT
1. Adaptation model: One new layer is used that ensures the translation of non IP layers too
IP
2. Adoption model: All non IP layers from OT is converter to IP layers.
Now the question is which model to use Adaptation or adoption?? The choice between these two
models can made by considering the following points:
1. Bidirectional versus unidirectional data flow: If the application contains bidirectional
dataflow then adaptation is preferred. If it has unidirectional dataflow, then adoption is
preferred.
2. Overhead for last-mile communications paths: Both models involve overhead. The model
that gives minimum overhead for last mile communication path is used for an application
3. Data flow model: If data flow is end to end meaning if a node is capable of communicating
with any of the other node in the network then adoption model is used as it provides end to
end communication.
If the data flow is limited to one or two applications, then adaptation is used.
4. Network Diversity:
If there exists network diversity, then adoption model is used. Adaptation model depends
on single PHY and MAC layers. Example: Zigbee device must be deployed only in Zigbee
network island. Adaptation layer can be used when there is no diversity in network.
The need for Optimization
In spite of having all the above-mentioned advantages, we cannot use the IP directly to the IoT
solutions as IoT has its own constraints with respect to nodes and networks. Hence IP has to be
optimized to use in IoT applications.
IoT has constrained nodes and networks.
Constrained Nodes: WKT there are three classes of constrained nodes. If the application is using
class 0 nodes, then we use adaptation model, as these nodes don’t have sufficient memory to
implement the full IP stack(adoption layer). Class 1 nodes can use adaptation model or the
optimized IP stack. Class 2 nodes are capable of implementing the full IP stack.
Constrained Networks: For typical IP networks, the available links are highly stable and reliable
whereas IoT has constrained networks where the link has very low power, low bandwidth, the link
may lose communication (not reliable), lots of variation exists in the packet delivery rate, latency
exists, they can support only fewer traffic etc. etc.
Hence, IP cannot be used directly to IoT solutions. IP should be optimized.
IP Versions
WKT IP has two versions IP Version 4 and IP Version 6 which is popularly known as IPV4 and
IPV6. As the number of devices connected to the IoT network is very large, usage of IPV4 may
run out of address space. The following factors are considered to choose among IPV4 or IPV6 for
IoT applications.
1. Application Protocol
The version of the IP is decided by the Application protocol that is being used. If SCADA
protocols (DNP3/IP, modbus TCP)are used, then we can use only for IPV4. If we use the
Application protocols defined by IETF(HTTP, CoAP, MQTT and XMPP), they support both
versions of IP.
2. Cellular Provider and Technology
For the first three generation of data services (GPRS, Edge and 3G) – IPV4 is the base protocol
version. If IPV6 is used with these generations, it must be tunneled over IPV4. On 4G/LTE
networks, data services can use either IPV4 or IPv6 as base protocol, depending on the provider.
3. Serial Communications
Many legacy devices in manufacturing and utility industry communicate through serial lines.
Earlier serial communication was handled by analog modem. Now the legacy device is connected
to router and it forwards the serial traffic over IP to the central server for processing. Encapsulation
of serial protocols is done by TCP and UDP. TCP and UDP runs on both IPV4 and IPV6.
4. IPV6 Adaptation Layer
IPV6 adaption layer of recent protocols support only IPV6. IEEE 802.15.4, IEEE 1901.2 and
ITU G.9903 has only IPV6 adaption layer.
Optimizing IP for IoT
The following Figure 3.1 shows the use of Adaptation Lay for optimizing IP. The model for
packaging IP into lower layer protocols is referred as adaptation layer
Transport Layer TCP/UDP
Network Layer IPV4/IPV6
Adaptation Layer
Data Link Layer 802.15.4g, e etc.
Physical Layer Wired/Wireless
Figure 3.1: Optimizing IP for IoT using Adaptation Layer
From 6LoWPAN to 6Lo
Adaptation layer includes optimizations to deal with constrained nodes and networks. The
examples of adaptation layers for constrained nodes are
1. 6LoWPAN working group &
 2. 6Lo working group
6LoWPAN
Here the focus was to optimize the transmission of IPV6 packets over constrained nodes. This was
done in the following 3 ways
1. Header Compression
2. Fragmentation
3. Mesh Addressing
Header Compression
---------------------------------------127 Byte IEEE 802.15.4 Frame-----------------------------------
1B 40 B 8B 53 B
802. 15.4 6LoWPAN IPV6 UDP Payload FCS
Header Header without
compression
Figure 3.2: 6LoWPAN Header without compression

---------------------------------------127 Byte IEEE 802.15.4 Frame-----------------------------------

2B 108 B
802. 15.4 6LoWPAN Header Payload FCS
Header with compression
Figure 3.3: 6LoWPAN Header with compression
This header compression is applicable only to IPV6. Doesn’t support IPV4. Figure 3.2 and 3.3
shows 6LoWPAN Header without compression and 6LoWPAN Header with compression
respectively.
What happens here:
1. The size of the header shrinks from 48 bytes to 6 bytes.
Header size without compression: 48 bytes (IPV6- 40 B & UDP – 8 B)
Header size with compression: 6 bytes (6LoWPAN- 2 B & UDP – 4B)

2. The size of the payload almost doubles.

Payload size without compression: 53 bytes
Payload size with compression: 108 bytes
How it is done? Idea behind:
The following information are omitted from header to compress it
1. Shared information known by all nodes of the local network
2. Standard header fields by assuming commonly used values
 Disadvantage:
This is applicable only to intra-cell communication. Communications external to cell contains
fields that can’t be compressed.
Fragmentation
MTU- maximum transmission unit defines the size of the largest protocol data unit that can be
passed.
MTU for an IPV6 network - at least 1280 bytes
MTU for an IEEE 802.15.4 network - 127 bytes
We want to carry an IPV6 packet inside an IEEE 802.15.4 packet. This is not possible as we want
to transfer a larger packet inside a smaller frame. The solution to this problem is fragmentation of
IPV6 packets. These fragmented packets are sent across multiple 802.15.4 frames. Figure 3.4
shows 6LoWPAN Fragmentation Header

1B 1B 2B 1B
802.15.4 6LoWPAN Datagram Datagram Tag Datagram FCS
Header fragmentation Size Offset
header field
Figure 3.4: 6LoWPAN Fragmentation Header

6LoWPAN fragmentation header field - 1byte: it is set to unique bit value that tells, subsequent
fields behind it are the fragment fields. It has the following three fields:
1. Datagram size: 1 byte- specifies the total size of the unfragmented payload
2. Datagram tag: 2 bytes- it identifies the set of fragments for a payload.
3. Datagram Offset field: 1 byte- it tells how far this fragment is from the first fragment.
Hence this field is absent in the first fragment.

Size of first fragmentation header- 4bytes (as offset field is absent)

Size of the remaining fragments- 5 bytes (with appropriate offset value)

Mesh Addressing
The purpose of 6LoWPAN mesh addressing function is to forward packets over multiple hops
within the mesh. This can be used only in a single IP subnet. It is usually used when layer2
performs the routing (mesh under). Figure 3.5 shows 6LoWPAN Mesh Addressing Header.

1B 2B 2B
802.15.4 6LoWPAN mesh Source Address Destination Address FCS
Header Addressing header-
hop count
Figure 3.5: 6LoWPAN Mesh Addressing Header

6LoWPAN Mesh Addressing header contains three fields:

 1. Hop limit: gives the upper limit on how many times the frame can be forwarded. Each
time when forwarded, the hop decrements it's value by 1. Once it's value becomes 0, that
packet is no longer forwarded. It will be dropped.
2. Source Address: IEEE 802.15.4 address of the starting hop.
3. Destination Address: IEEE 802.15.4 address of the ending hop.

Mesh Under versus Mesh Over Routing

The network Technologies such as IEEE 802.15.4, IEEE 802.15.4g and IEEE 1902.2a support
mesh topology and they operate at physical and data link layers. These networks uses the following
options to establish reachability and to forward packets.

1. Mesh-Under routing: The term "mesh under" tells that multiple link layer hops can be used to
complete a single IP hop. Here the Routing of IP packets is handled at the 6LoWPAN Adaptation
layer. Nodes have a Layer 2 forwarding table. This table is consulted to route the packets to their
final destination within the mesh. An edge gateway terminates this mesh-under domain.

2. Mesh- over routing: (also called route-over) uses IP routing (layer 3 routing) to forward the
packets to destination either inside or outside the mesh domain. Each full functioning node acts as
an IP router and each link layer hop is an IP hop. When a LoWPAN is implemented using different
link layer technologies, mesh-over routing setup is useful. Along with traditional IP routing
protocols, a specialised routing protocol for smart objects RPL can also be used.

6Lo Working Group

(also called IPV6 over networks of Resource Constrained Nodes)

6Lo Working Group focuses on IPV6 connectivity over constrained- node networks. This group
particularly focuses on the following:

1. IPV6-over-foo adaptation layer specifications using 6LoWPAN technologies for link layer
technologies: This includes transmission of IPV6 packets over the following:
• Bluetooth low energy
• Near field communication
• 802.11ah
• DECT Ultra Low Energy
• WIA-PA (Wireless Networks for Industrial Automation- Process Automation)
• Master Slave/ Token Passing (MS/TP)
2. Information and data models such as MIB modules
3. Optimizations that are applicable to more than one adaptation layer specification
4. Informational and maintenance publications needed for the IETF specifications in this area

6TiSCH
IEEE 802.15.4e, Time Slotted Channel Hopping (TSCH) is a standardized, deterministic
communication path over wireless networks. 6TiSCH is the IPV6 standardization of TSCH mode
of IEEE 802.15.4e. This is given by IEEE 802.15.4e working group. TSCH communicates by
following Time Division Multiple Access (TDMA) schedule. A unit of bandwidth or time slot is
scheduled between neighbor nodes. 6TiSCH performs the following two jobs:
1. Schedule Management
2. Packet Forwarding
6top
6top is a sublayer that exists in between MAC layer (i.e IEEE 802.15.e TCSH) and 6LoWPAN
Header Compression Adaptation layer as shown in figure 3.6. This sublayer provides commands
to the upper network layers. These commands enable functionalities including network layer
routing decisions, configurations and control procedures for 6TiSCH schedule management.

IPV6
6LoWPAN HC
➔ 6top
IEEE 802.15.e TCSH
Figure 3.6 Location of 6TiSCH’s 6top Sublayer
Schedule Management
Basically, 6TiSCH is scheduling algorithm that decides how the time slots are utilized. This
scheduling affects throughput, latency and power consumption. Schedules in 6TiSCH are broken
down into cells. A cell is a single element in the TSCH schedule that can be allocated for
unidirectional or bidirectional communications between specific nodes. Nodes will transmit only
when schedule announces that their cell is open for communication. The 6TiSCH architecture
defines four schedule management mechanisms:
1. Static scheduling:
 All nodes in the constrained network share a fixed schedule.
 Cells are shared, nodes contend for slot access using slotted ALOHA
 Nodes may expect a packet at any cell in the schedule.
 Energy is wasted idly listening across all cells
2. Neighbor-to-neighbor scheduling
 A schedule is established by observing the correlation and number of transmissions
between nodes
 Cells can be added or deleted depending on traffic requirements and bandwidth
3. Remote monitoring and scheduling management
 Time slots and other resources are allocated and managed remotely
4. Hop-by-hop scheduling
  A node reserves a path to a destination node that is multiple hops away by requesting
the allocation of cells in a schedule at each intermediate node hop in the path.
Packet Forwarding Models
6TiSCH architecture defines three forwarding models. They are:
1. Track Forwarding (TF)
 This is a simplest and fastest forwarding model.
 A track is a unidirectional path between a source and a destination.
 Track is formed by pairing bundles of receive cells in a schedule with a bundle of receive
cells set to transmit
 A frame received within a particular cell/cell bundle is switched to another cell/cell bundle
 Network layer protocol is not involved in this forwarding
2. Fragment forwarding (FF)
 First fragment is routed based on the IPV6 header.
 The sub-layer learns the next-hop selection of the first fragment, which is applied to all
subsequent fragments of that packet
3. IPV6 Forwarding (6F)
 This model forwards the traffic based on its IPV6 routing table
 Flow of packets is prioritized by traditional QoS and RED operations. QoS(Quality of
Service) is a classification scheme for flows based on their priority and RED(Random Early
Detection) is a common congestion avoidance mechanism.

RPL(IPV6 Routing Protocol for Low Power and Lossy Network)

It is a routing protocol used by smart objects over constrained networks. 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, when it receives the IPV6 packet determines the next hop destination based on the
information present in the IPV6 header.
RPL protocol defines two modes to cope with the constrained nodes:
1. Storing mode:
 All node contains full routing table of the RPL domain.
 Every node knows how to directly reach every other node
2. Non- storing mode:
 Only the border router of the RPL domain contains the full routing table.
 All other nodes in the domain only maintain their list of parents.
  It saves memory space and CPU.
 A node always forwards its packet to border router, which knows how to ultimately reach
the final destination
 RPL process involves building a DODAG(Destination Oriented Directed Acyclic Graph).
DODAG is a DAG(Directed Acyclic Graph) rooted to one destination. The destination is
at border router. DAG can have multiple roots whereas DODAG has only one root. The
figure 3.7 shows DODAG graph. Each node maintains upto 3 parents that provide path to
the root. One of these will be preferred parent which is used as next hop for upward routes
toward the root.

DAG Root

Figure 3.7: DODAG graph

Upward routes in RPL are discovered and configured using DAG Information Object
messages(DIO). Nodes listen to DIOs to handle changes in the topology that can affect routing.
The information in the DIO messages determines parents and the best path to DODAG root
Nodes establish downward routes by advertising their parents set toward DODAG root using a
Destination Advertisement Object(DAO) message. DAO messages allow nodes to inform their
parents of their presence and reachability from descendants.
Non storing mode of RPL: nodes sending DAO messages report to their parents and then parents
inform to DODAG root. Only root stores the routing information. Root determines source routes
for delivering packets to individual nodes downstream in the mesh by using this routing
information.
Storing mode of RPL: Each node keeps track of routing information. The nodes can choose the
shorter path between destinations.
Objective Function (OF): Defines how metrics are used to select routes and establish a node’s
rank.
Rank:
 Is an approximation of how close a node is to the root
 It helps to avoid routing loops and the count-to-infinity problem.
 Nodes can increase their rank if they receive a DIO message with a larger version number
  It can decrease the rank whenever it establishes a lower cost routes
RPL Headers: helps in loop detection
Metrics: RPL routing metrics are as follows:
 Expected Transmission Count (ETX): value that tells the number of transmission a node
expects to make to deliver a packet
 Hop count: tracks the number of nodes traversed in a path
 Latency: varies depending on power consumption. Paths with lower latency is preferred.
 Link Quality Level: measures the reliability of a link. It considers the packet error rate
caused by factors such as signal attenuation and interference
 Link color: Allows manual influence of routing by choosing the links
 Node state and Attribute: Identifies nodes that functions as traffic aggregators and nodes
that are being impacted by high workload
 Node Energy: Avoids node with low power and battery –powered nodes
 Throughput: provides the amount of throughput for a node link

Authentication and Encryption on constrained Nodes

ACE (Authentication and Authorization for Constrained Environments):
It is a standardized solution that enables authorized access to resources in constrained
environments.
DICE- DTLS In Constrained Environment
It implements DTLS (Datagram Transport Layer Security) which is a transport layer
security protocol for constrained Environment
The Transport Layer