JSS Mahavidyapeetha

JSS Science and Technology University, Mysuru – 570 006

DEPARTMENT OF COMPUTER APPLICATIONS

Internet of Things
Presented By,
Prof . BHAVYA N
Assistant Professor
Dept of computer applications
JSSSTU, Mysuru
 IP as the IoT Network Layer
• we move up the protocol stack and extend the conversation to
network layer connectivity,
• Referring back to the Core IoT Functional Stack , this chapter
covers the network transport layer sublayer that is part of the
communications network layer.
• Alternatively, you can also align this chapter with the network
layer of the oneM2M architecture or the connectivity layer of
the IoT World Forum architecture
This chapter is composed of the following sections:

■ The Business Case for IP: This section discusses the advantages of IP
from an IoT perspective and introduces the concepts of adoption and
adaptation.
■ The Need for Optimization: This section dives into the challenges of
constrained nodes and devices when deploying IP. This section also looks
at the migration from IPv4 to IPv6 and how it affects IoT networks.
■ Optimizing IP for IoT: This section explores the common protocols
and technologies in IoT networks utilizing IP.
■ Profiles and Compliances: This section provides a summary of some
of the most significant organizations and standards bodies involved with
IP connectivity and IoT.
 The Business Case for IP
• Data flowing from or to “things” is consumed, controlled, or monitored by data
center servers either in the cloud or in locations that may be distributed or
centralized.
• Dedicated applications are then run over virtualized or traditional operating
systems or on network edge platforms (for example, fog computing).
• These lightweight applications communicate with the data center servers.
• The system solutions combining various physical and data link layers call for an
architectural approach with a common layer(s) independent from the lower
(connectivity) and/or upper (application) layers.
• This is how and why the Internet Protocol (IP) suite started playing a key
architectural role in the early 1990s.
• IP was not only preferred in the IT markets but also for the OT environment.
 The Key Advantages of Internet Protocol
• One of the main differences between traditional information technology
(IT) and operational technology (OT) is the lifetime of the underlying
technologies and products.
• An entire industrial workflow generally mandates smooth, incremental
steps that evolve, with operations itself being the most time- and
mission-critical factor for an organization.
• One way to guarantee multi-year lifetimes is to define a layered
architecture such as the 30-year-old IP architecture. IP has largely
demonstrated its ability to integrate small and large evolutions.
• At the same time, it is able to maintain its operations for large numbers
of devices and users, such as the 3 billion Internet users.
the key advantages of the IP suite for the Internet of Things:

1. Open and standards-based:

• Operational technologies have often been delivered as turnkey features by vendors
who may have optimized the communications through closed and proprietary
networking solutions.
• 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
interchangeability and interoperability ,security, and management.
• This calls for implementation, validation, and deployment of open, standards-based
solutions.
• While many standards development organizations (SDOs) are working on Internet of
Things definitions, frameworks, applications, and technologies, none are questioning
the role of the Internet Engineering Task Force (IETF) as the foundation for
specifying and optimizing the network and transport layers.
 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 center.
• Even if physical and data link layers such as Ethernet, Wi-Fi, and cellular are widely
adopted, the history of data communications demonstrates that no given wired or
wireless technology fits all deployment criteria.
• Communication technologies evolve at a pace faster than the expected 10- to 20-year
lifetime of OT solutions.
• So, the layered IP architecture is well equipped to cope with any type of physical and
data link layers.
• This makes IP ideal as a long-term investment because various protocols at these layers
can be used in a deployment now and over time, without requiring changes to the whole
solution architecture and data flow.
 3. Ubiquitous
• All recent operating system releases, from general-purpose computers
and servers to lightweight embedded systems (TinyOS, Contiki, and so
on), have an integrated dual (IPv4 and IPv6) IP stack that gets
enhanced over time.
• In addition, IoT application protocols in many industrial OT solutions
have been updated in recent years to run over IP.
• While these updates have mostly consisted of IPv4 to this point, recent
standardization efforts in several areas are adding IPv6.
• In fact, IP is the most pervasive protocol when you look at what is
supported across the various IoT solutions and industry verticals.
 4. Scalable
• As the common protocol of the Internet, IP has been massively deployed
and tested for robust scalability.
• Millions of private and public IP infrastructure nodes have been
operational for years, offering strong foundations for those not familiar
with IP network management.
• Of course, 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.
• One of the benefits that comes from 30 years of operational IP
networks is the well-understood network management and security
protocols, mechanisms, and toolsets that are widely available.
• 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 been around for 30 years, and it is clear that IP is a workable
solution.
• 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 defense 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.
• Finally, its stability and resiliency benefit from the large ecosystem of
IT professionals who can help design, deploy, and operate IP-based
solutions.
 7. Consumers’ market adoption
• When developing IoT solutions and products targeting the
consumer market, vendors know that consumers’ access to
applications and devices will occur predominantly over
broadband and mobile wireless infrastructure.
• The main consumer devices range from smart phones to tablets
and PCs.
• The common protocol that links IoT in the consumer space to
these devices is IP.
 8. The innovation factor
• The past two decades have largely established the adoption of
IP as a factor for increased innovation.
• IP is the underlying protocol for applications ranging from file
transfer and e-mail to the World Wide Web, e-commerce, social
networking, mobility, and more.
• Even the recent computing evolution from PC to mobile and
mainframes to cloud services are perfect demonstrations of the
innovative ground enabled by IP.
 Adoption or Adaptation
of the Internet Protocol
• Adaptation means application layered gateways (ALGs) must
be implemented to ensure the translation between non-IP and IP
layers.
• Adoption involves replacing all non-IP layers with their IP
layer counterparts, simplifying the deployment model and
operations.
The IP adaptation versus adoption model still requires investigation for
particular last-mile technologies used by IoT. Consider the following factors
when trying to determine which model is best suited for last-mile
connectivity:

 Bidirectional versus unidirectional data flow:

• While bidirectional communications are generally expected, some last-mile
technologies offer optimization for unidirectional communication.
• These sorts of devices, particularly ones that communicate through LPWA
technologies, include fire alarms sending alerts or daily test reports,
electrical switches being pushed on or off, and water or gas meters sending
weekly indexes.
 Overhead for last-mile communications paths:
• IP adoption implies a layered architecture with a per-packet overhead that varies depending on the
IP version.
• 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.
• If the data to be forwarded by a device is infrequent and only a few bytes, can potentially have
more header overhead than device data—again, particularly in the case of LPWA technologies.

 Data flow model:

• One benefit of the IP adoption model is the end-to-end nature of communications.
• 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.
• 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.
• Depending on the network topology and the data flow needed, both IP adaptation and adoption
models have roles to play in last-mile connectivity.
 Network diversity:
• One of the drawbacks of the adaptation model is a general
dependency on single PHY and MAC layers.
• For example, ZigBee devices must only be deployed in ZigBee
network islands.
• Integration and coexistence of new physical and MAC layers or
new applications impact how deployment and operations have to
be planned.
• This is not a relevant consideration for the adoption model.
 The Need for Optimization
• 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.
• The following sections take a detailed look at why optimization is
necessary for IP. Both the nodes and the network itself can often be
constrained in IoT solutions.
 Constrained Nodes
• Depending on its functions in a network, a “thing” architecture
may or may not offer similar characteristics compared to a
generic PC or server in an IT environment.
• Another limit is that this network protocol stack on an IoT node
may be required to communicate through an unreliable path.
• Even if a full IP stack is available on the node, this causes
problems such as limited or unpredictable throughput and low
convergence when a topology change occurs.
Finally, power consumption is a key characteristic of constrained nodes.
• Many IoT devices are battery powered, with lifetime battery requirements
varying from a few months to 10+ years. This drives the selection of
networking technologies since high-speed ones, such as Ethernet, Wi-Fi, and
cellular, are not (yet) capable of multi-year battery life.
• Current capabilities practically allow less than a year for these technologies on
battery powered nodes. Of course, power consumption is much less of a
concern on nodes that do not require batteries as an energy source.
• To help extend battery life, you could enable a “low-power” mode instead of
one that is “always on.” Another option is “always off,” which means
communications are enabled only when needed to send data
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 behaviors must cope with the bandwidth constraints.
 Constrained Networks
• In the early years of the Internet, network bandwidth capacity was restrained due to
technical limitations.
• Connections often depended on low-speed modems for transferring data. However,
these low-speed connections demonstrated that IP could run over low bandwidth
networks.
• Fast forward to today, and the evolution of networking has seen the emergence of
high-speed infrastructures. However, high-speed connections are not usable by some
IoT devices in the last mile.
• The reasons include the implementation of technologies with low bandwidth, limited
distance and bandwidth due to regulated transmit power, and lack of or limited
network services.
• When link layer characteristics that we take for granted are not present, the network
is constrained. A constrained network can have high latency and a high potential for
packet loss.
• Constrained networks have unique characteristics and requirements.
• In contrast with typical IP networks, where highly stable and fast links are available,
constrained networks are limited by low-power, low-bandwidth links (wireless and wired).
• They operate between a few kbps and a few hundred kbps and may utilize a star, mesh, or
combined network topologies, ensuring proper operations. Large bursts of unpredictable
errors and even loss of connectivity at times may occur.
• These behaviors can be observed on both wireless and narrowband power-line
communication links, where packet delivery variation may fluctuate greatly during the
course of a day.
• Unstable link layer environments create other challenges in terms of latency and control
plane reactivity.
• One of the golden rules in a constrained network is to “underreact to failure.”
• Due to the low bandwidth, a constrained network that overreacts can lead to a network
collapse—which makes the existing problem worse
 IP Versions
• 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.
• Serial Communications: Many legacy devices in certain industries, such as
manufacturing and utilities, communicate through serial lines.
• 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 (Ethernet, Wi-Fi, and so
on)
 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.
 6LoWPAN to 6Lo
6LoWPAN – IPv6 over low-power wireless personal area networks.
• 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 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.
 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.
• Note that header compression for 6LoWPAN is only defined for an IPv6
header and not IPv4.
• 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.
 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.
• 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.
 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.
 Profiles and Compliances
• As discussed throughout this chapter, the Internet Protocol suite for smart
objects involves a collection of protocols and options that must work in
coordination with lower and upper layers.
• Therefore, profile definitions, certifications, and promotion by alliances can
help implementers develop solutions that guarantee interoperability and/
or interchangeability of devices.
• This section introduces some of the main industry organizations working on
profile definitions and certifications for IoT constrained nodes and networks.
• You can find various documents and promotions from these organizations in
the IoT space, so it is worth being familiar with them and their goals.
 Internet Protocol for Smart Objects (IPSO) Alliance
• 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.
• 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.
 Wi-SUN Alliance
• The Wi-SUN Alliance is an example of efforts from the industry to define a
communication profile that applies to specific physical and data link layer
protocols.
• Currently, Wi-SUN’s main focus and its support for multiservice and secure
IPv6 communications with applications running over the UDP transport
layer.
• The Wi-SUN field area network (FAN) profile enables smart utility
networks to provide resilient, secure, and cost-effective connectivity with
extremely good coverage in a range of topographic environments, from
dense urban neighborhoods to rural areas.
• Website - www.wi-sun.org
 Thread
• A group of companies involved with smart object solutions for
consumers created the Thread Group.
• This group has defined an IPv6-based wireless profile that
provides the best way to connect more than 250 devices into a
low-power, wireless mesh network.
• visit http://threadgroup.org.
 IPv6 Ready Logo
• Once IPv6 implementations became widely available, the need for
interoperability and certification led to the creation of the IPv6 Ready Logo
program.
• The IPv6 Ready Logo program has established conformance and
interoperability testing programs with the intent of increasing user confidence
when implementing IPv6.
• The IPv6 Core and specific IPv6 components, such as DHCP, IPsec, and
customer edge router certifications, are in place.
• These certifications have industry-wide recognition, and many products are
already certified. An IPv6 certification effort specific to IoT is currently under
definition for the program
 Application Protocols for IoT
This chapter focuses on how higher-layer IoT protocols are
transported. Specifically, this chapter includes the following sections:

• The Transport Layer: IP-based networks use either TCP or UDP.

However, the constrained nature of IoT networks requires a closer
look at the use of these traditional transport mechanisms.
• IoT Application Transport Methods: This section explores the
various types of IoT application data and the ways this data can be
carried across a network.
 The Transport Layer
• This section reviews the selection of a protocol for the transport
layer as supported by the TCP/IP architecture in the context of
IoT networks.
• With the TCP/IP protocol, two main protocols are specified for
the transport layer:
»Transmission Control Protocol (TCP)
»User Datagram Protocol (UDP)
• Transmission Control Protocol (TCP): This connection-oriented
protocol requires a session to get established between the source and
destination before exchanging data. You can view it as an equivalent to
a traditional telephone conversation, in which two phones must be
connected and the communication link established before the parties
can talk.
• User Datagram Protocol (UDP): With this connectionless protocol,
data can be quickly sent between source and destination—but with no
guarantee of delivery. This is analogous to the traditional mail delivery
system, in which a letter is mailed to a destination. Confirmation of the
reception of this letter does not happen until another letter is sent in
response.
 IoT Application Transport Methods
• Because of the diverse types of IoT application protocols, there are various means for
transporting these protocols across a network.
• To make these decisions easier, it makes sense to categorize the common IoT
application protocols and then focus on the transport methods available for each
category.
• The following categories of IoT application protocols and their transport methods are
explored in the following sections:
1. Application layer protocol not present: In this case, the data
payload is directly transported on top of the lower layers. No
application layer protocol is used.
2. Supervisory control and data acquisition (SCADA): SCADA is one of the most
common industrial protocols in the world, but it was developed long before the days
of IP, and it has been adapted for IP networks.

3. Generic web-based protocols: Generic protocols, such as Ethernet, Wi-Fi, and 4G/
LTE, are found on many consumer and enterprise-class IoT devices that
communicate over non-constrained networks.

4. IoT application layer protocols: IoT application layer protocols are devised to run
on constrained nodes with a small compute footprint and are well adapted to the
network bandwidth constraints on cellular or satellite links or constrained
6LoWPAN networks. Message Queuing Telemetry Transport (MQTT) and
Constrained Application Protocol (CoAP), covered later in this chapter, are two
wellknown examples of IoT application layer protocols.