Unit -3

IP at the IoT Network Layer

The Key Advantages of Internet Protocol:

The key advantages of the IP suite for the Internet of Things:
1. Open and standards-based: The Internet of Things creates a new paradigm in which
devices, applications, and users can leverage a large set of devices and functionalities
while guaranteeing interchange ability and interoperability, security, and management.
2. Versatile: A large spectrum of access technologies is available to offer connectivity of
“things” in the last mile. Additional protocols and technologies are also used to
transport IoT data through backhaul links and in the data centre.
3. Ubiquitous: All recent operating system releases, from general-purpose computers and
servers to lightweight embedded systems, have an integrated dual (IPv4 and IPv6) IP
stack that gets enhanced over time.
4. Scalable: Adding huge numbers of “things” to private and public infrastructures may
require optimizations and design rules specific to the new devices. However, you should
realize that this is not very different from the recent evolution of voice and video
endpoints integrated over IP. IP has proven before that scalability is one of its
strengths.
5. Manageable and highly secure: Communications infrastructure requires appropriate
management and security capabilities for proper operations. Adopting IP network
management also brings an operational business application to OT. Well-known
network and security management tools are easily leveraged with an IP network layer
6. Stable and resilient: IP has a large and well-established knowledge base and, more
importantly, it has been used for years in critical infrastructures, such as financial and
defines networks. In addition, IP has been deployed for critical services, such as voice
and video, which have already transitioned from closed environments to open IP
standards.

Need for optimization in IP in IoT Networks:

The Internet of Things will largely be built on the Internet Protocol suite. However, challenges
still exist for IP in IoT solutions. In addition to coping with the integration of non-IP devices,
you may need to deal with the limits at the device and network levels that IoT often imposes.
Therefore, optimizations are needed at various layers of the IP stack to handle the restrictions
that are present in IoT networks.

Constrained Nodes
Power consumption is a key characteristic of constrained nodes. IoT constrained nodes can be
classified as follows:
Devices that are very constrained in resources, may communicate infrequently to transmit a few
bytes, and may have limited security and management capabilities: This drives the need for the
IP adaptation model, where nodes communicate through gateways and proxies.
Devices with enough power and capacities to implement a stripped-down IP stack or non-IP
stack: In this case, you may implement either an optimized IP stack and directly communicate
with application servers (adoption model) or go for an IP or non-IP stack and communicate
through gateways and proxies (adaptation model).
Devices that are similar to generic PCs in terms of computing and power resources but have
constrained networking capacities, such as bandwidth: These nodes usually implement a full
IP stack (adoption model), but network design and application behaviours must cope with the
bandwidth constraints.

Constrained Networks
Constrained networks have unique characteristics and requirements. In contrast with typical
IP networks, where highly stable and fast links are available, constrained networks are limited
by low-power, low-bandwidth links (wireless and wired). They operate between a few kbps and
a few hundred kbps and may utilize a star, mesh, or combined network topologies, ensuring
proper operations.
IP Versions
A variety of factors dictate whether IPv4, IPv6, or both can be used in an IoT solution. Most
often these factors include a legacy protocol or technology that supports only IPv4. Newer
technologies and protocols almost always support both IP versions. The following are some of
the main factors applicable to IPv4 and IPv6 support in an IoT solution:
Application Protocol: IoT devices implementing Ethernet or Wi-Fi interfaces can communicate
over both IPv4 and IPv6, but the application protocol may dictate the choice of the IP version.

Cellular Provider and Technology: IoT devices with cellular modems are dependent on the
generation of the cellular technology as well as the data services offered by the provider. For
the first three generations of data services GPRS, Edge and 3G, IPv4 is the base protocol
version. Consequently, if IPv6 is used with these generations, it must be tunnelled over IPv4.
On 4G/LTE networks, data services can use IPv4 or IPv6 as a base protocol, depending on the
provider.
Serial Communications: Many legacy devices in certain industries, such as manufacturing and
utilities, communicate through serial lines. Data is transferred using either proprietary or
standards-based protocols. Encapsulation of serial protocols over IP leverages mechanisms
such as raw socket TCP or UDP. While raw socket sessions can run over both IPv4 and IPv6,
current implementations are mostly available for IPv4 only.
IPv6 Adaptation Layer: IPv6-only adaptation layers for some physical and data link layers for
recently standardized IoT protocols support only IPv6. While the most common physical and
data link layers stipulate adaptation layers for both versions, newer technologies, such as
IEEE 802.15.4, IEEE 1901.2, and ITU G.9903 (Narrowband Power Line Communications) only
have an IPv6 adaptation layer specified.

Optimizing IP for IoT:

While the Internet Protocol is key for a successful Internet of Things, constrained nodes and
constrained networks mandate optimization at various layers and on multiple protocols of the IP
architecture. Figure highlights the TCP/IP layers where optimization is applied.

In the IP architecture, the transport of IP

packets over any given Layer 1 (PHY) and
Layer 2 (MAC) protocol must be defined and
documented. The model for packaging IP into
lower-layer protocols is often referred to as
an adaptation layer. The main difference is
that an adaptation layer designed for IoT may
include some optimizations to deal with
constrained nodes and networks. The main
difference is that an adaptation layer
designed for IoT may include some optimizations to deal with constrained nodes and networks.
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.

Comparison of IP protocol stack and IoT Protocol stack

Figure shows an example of an IoT protocol

stack using the 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. These headers can be stacked
in the adaptation layer to keep these
concepts separate while enforcing a
structured method for expressing each capability. Depending on the implementation, all, none,
or any combination of these capabilities and their corresponding headers can be enabled.
Figure shows some examples of typical 6LoWPAN header stack and the sub headers related to
compression, fragmentation, and mesh addressing.

Header Compression
6LoWPAN header compression is stateless, and conceptually it is not too complicated. However,
a number of factors affect the amount of compression, such as implementation of RFC 4944
versus RFC 6922, whether UDP is included, and various IPv6 addressing scenarios. It is beyond
the scope of this book to cover every use case and how the header fields change for each.
However, this chapter provides an example that shows the impact of 6LoWPAN header
compression.
At a high level, 6LoWPAN works by taking advantage of shared information known by all nodes
from their participation in the local network. In addition, it omits some standard header fields by
assuming commonly used values. Figure 5-
4 highlights an example that shows the
amount of reduction that is possible with
6LoWPAN header compression.

At the top of Figure shows a 6LoWPAN

frame without any header compression
enabled: The full 40-byte IPv6 header and
8-byte UDP header are visible. The
6LoWPAN header is only a single byte in
this case. Notice that uncompressed IPv6
and UDP headers leave only 53 bytes of
data payload out of the 127-byte maximum
frame size in the case of IEEE 802.15.4.
The bottom half of Figure shows a frame where header compression has been enabled for a best-
case scenario. The 6LoWPAN header increases to 2 bytes to accommodate the compressed IPv6
header, and UDP has been reduced in half, to 4 bytes from 8. Most importantly, the header
compression has allowed the payload to more than double, from 53 bytes to 108 bytes, which is
obviously much more efficient. Note that the 2-byte header compression applies to intra-cell
communications, while communications external to the cell may require some field of the header
to not be compressed.

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.
The fragment header utilized by 6LoWPAN is composed of 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. Figure
provides an overview of a 6LoWPAN fragmentation header.

IP Protocol for smart objects (IPSO) Alliances

Established in 2008, the Internet Protocol for Smart Objects (IPSO) Alliance has had its
objective evolve over years. The alliance initially focused on promoting IP as the premier
solution for smart objects communications. Today, it is more focused on how to use IP, with
the IPSO Alliance organizing interoperability tests between alliance members to validate that IP
for smart objects can work together and properly implement industry standards. The IPSO
Alliance does not define technologies, as that is the role of the IETF and other standard
organizations, but it documents the use of IP-based technologies for various IoT use cases and
participates in educating the industry. As the IPSO Alliance declares in its value and mission
statement, it wants to ensure that “engineers and product builders will have access to the
necessary tools for „how to build the IoT RIGHT.‟” For more information on the IPSO Alliance,
visit www.ipso-alliance.org.