MODULE 3

 IP as the IoT Network Layer

 The Business Case for IP
 The need for Optimization
 Optimizing IP for IoT
 Profiles and Compliances
 Application Protocols for IoT
 The Transport Layer
 IoT Application Transport Methods.
The Business Case for IP
The key advantages of Internet Protocol
 Open and standards-based
 The devices, applications, users and their functionalities in IoT
should guarantee interchangeability and interoperability,
security and management.
 The IETF(Internet Engineering Task Force) is an open
standards body that focuses on the development of the Internet
Protocol suite and related Internet technologies and protocols
 Versatile
 The layered IP architecture is well equipped to cope up with any
type of physical and data link layers.
 This makes IP an ideal protocol and does not require any
changes.
 Ubiquitous
 All recent OS of personal computers, servers and light
weighted embedded systems are integrated with dual
(IPV4 and IPV6) IP stack.
 IP is supported across various IoT solutions and
industrial verticals

 Scalable
 IP is a common Internet protocol that has been
massively deployed and tested for robust scalability.
 IP has scalability as one of its strength.
 Manageable and highly secure
 Communications infrastructure requires appropriate
management and security capabilities for proper operations
 Well known network and security management tools are easily
leveraged with an IP network layer.
 Real challenges still exists in securing constrained nodes,
handling legacy OT protocols and scaling operations
 IP provides a solid foundation for IoT by allowing secured and
manageable bidirectional data communication capabilities
between all devices in the network
 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.
 Deployed for many critical services, such as voice and
video
 A large number of 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.
 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.
 The innovation factor
 IP has the increased innovation factor.
 It is the underlying protocol for applications ranging from
file transfer and email to the world wide web, e-commerce,
social networking, mobility etc.
 From cloud, centralized or distributed architectures, IP data
flow can be developed and implemented according to the
business requirements
Adoption or Adaptation of the IP
 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 following parameter should be considered:
 Bidirectional versus unidirectional data flow:
 Most of the IoT applications reports only few bytes of data
infrequently to an application.
 By this it feels that implementing full IP stack is not necessary.
 But one way communication has drawbacks. If we can only
upload a data to an application, then it is not possible to
download new software or firmware to the devices.
 Integrating new features, bug fixing and security fixing
becomes more difficult.
 Overhead for last-mile communications paths
 Overhead increases in IP adoption model
 IPV4→ 20 bytes of header & IPV6 → 40 bytes of header
 UDP → 8 bytes of header & TCP → 20 bytes of header.
 If device forwards only few bytes of data infrequently, then
header overhead is more than the device data
 Adoption model has to optimized to overcome this overhead.
 Data flow model
 IP adoption model → any node can easily exchange data with
any other node in a network.
 But in IoT, device data flow is limited to one or two
application.
 Adaption model→ translates traffic only between the end
device and one or two application servers.
 Network diversity
 Adaption model disadvantage:
 Its dependency on single PHY and MAC layer. (i.e. Zigbee
devices must be deployed only in Zigbee network islands)
 A deployment must consider which applications have to
run on gateway connecting these islands to the rest of the
world.
 This is not a relevant consideration in adoption model
 The Need for Optimization
IoT often limits at the device and network levels.
Optimization is needed at various layers of IP stack to handle
the restriction that are present in IoT networks.
 Constrained nodes (less computing power, memory, storage
devices, power consumption)
 Devices that are very constrained in resources, may
communicate infrequently a few bytes, and may have
limited security and management capabilities (class 0)
 IP adaptation model suits, where nodes communicate through
gateways and proxies
 Devices with enough power and capacities to
implement a stripped-down IP stack or non- IP
stack(class 1)
 May implement an (adoption model)optimized IP stack and
directly communicate with application server
OR
 Non-IP stack and communicate through gateways and proxies
(adaption model)
 Devices that are similar to generic PCs in terms of
computing and power resources but have constrained
networking capacities such as bandwidth (class 2)
 Usually implement a full IP stack (adoption model), but
network design and application behaviors must cope with the
bandwidth constraints
 Constrained Networks
 Today’s network has high-speed infrastructure, but this
is not usable by some IoT devices.
 Hence a constrained network is used due to regulated
transmit power and limited network services.
 A constrained network can have high latency and a high
potential for packet loss
 Constrained networks are limited by low-power, low-
bandwidth links. They operate between a few kbps and a
few hundred kpbs.
 May have unusual packet delivery rate (PDR)
 Control plane traffic must be kept minimum else it
consumes the bandwidth needed by the data traffic.
IP Versions
The following factors supports the IPV4 and IPV6 for IoT:
 Application Protocol
 IoT devices can communicate over both IPV4 and IPV6.
 Application protocol may dictate the choice of the IP
version
 Example: SCADA protocols (DNP3/IP, modbus TCP)are
specified only for IPV4
 Application protocols by IETF(HTTP, CoAP, MQTT and
XMPP) support both versions of IP.
 Selection of IP version depends on the implementation
 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.
 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.
 IPV6 Adaptation Layer
 IPV6 adaption layer of recent protocols support only
IPV6.
 IEEE 802.1.4, IEEE 1901.2 and ITU G.9903 has only IPV6
adaption layer.
 Any device implementing a technology that requires an
IPV6 adaption layer must communicate over an IPV6-
only sub-network.
 It is done by IETF routing protocols for LLNs, and RPL,
which is IPV6 only
Optimizing IP for IoT
 Constrained nodes and constrained networks of IoT
mandate optimization of IP at various layers and on
multiple protocols of the IP architecture.
 From 6LoWPAN to 6Lo
 The 6LoWPAN working group optimized the
transmission of IPV6 packets over the constrained
networks such as IEEE 802.15.4
 The 6LoWPAN working group published several RFCs
(4944 and 6282)
 RFC 4994 includes header compression,
fragmentation and mesh addressing
 Depending on the implementation, all, none or any
combination of these can be enabled.
Header Compression
 Header compression was defined in RFC 4944 and updated
in RFC 6282
 It shrink’s the size of IPV6’s 40 byte header and UDP’s 8
byte header (48 bytes) to 6 bytes
 Header compression for 6LoWPAN is only defined for an
IPV6 header
 It does not support IPV4, there is no IPV4 adaption layer
for IEEE 802.15.4
Without any header compression → IPV6 header – 40 B
and UDP header- 8 bytes.
The 6LoPWAN header is only 1 Byte.
It can have only 53 bytes of payload out of 127-byte maximum
frame size
With header compression →
 The 6LoWPAN header increases to 2 bytes to accommodate
the compressed IPV6 header.
 UDP is reduced by half to 4 bytes from 8 bytes.
 This doubles the payload size from 53 to 108 bytes which is
more efficient
 This header compression applies to intra-cell
communications.
 Communications external to the cell may have some field of
the header not to be compressed
Fragmentation
Maximum transmission unit (MTU) for IPV6 → 1280 bytes
MTU for IEEE 802.15.4 → 127 Bytes
Much larger MTU has to be carried on much smaller MTU
Hence IPV6 packets must be fragmented across multiple
802.1.54 frames at layer 2

Fragment header of 6LoWPAN is composed of three fields:

Datagram Size, Datagram Tag and Datagram Offset.
Datagram size: 1 byte -> specifies the total size of the
unfragmented payload
Datagram Tag: identifies the set of fragments for a payload
Datagram offset: tell how far into a payload a particular
fragment occurs
Mesh Addressing
 The purpose of mesh addressing function is to forward
packets over multiple hops
 Three field defined for this header:
 Hop limit → gives the upper limit on how many times
the packets can be forwarded. Each hop decrements the
value by 1 as it is forwarded. Once the value hits 0, it is
dropped and no longer forwarded
 Source address
 Destination address
 Two options exist for forwarding packets
 Mesh-under
 Mesh-over
 Mesh under : routing of packets is handled at
6LoWPAN adaption layer
 Mesh over: utilizes IP routing for forwarding packets to
their destination
6Lo Working group:
IPV6 over foo adaption layer specification using
6LoWPAN. It includes
 IPV6 over Bluetooth Low Energy
 Transmission of IPV6 over NFC
 IPV6 over 802.11 ah
 Transmission of IPV6 over Master slave/ Token passing
6TiSCH
To standardize IPV6 over the TSCH mode (Time slotted
channel hopping) of IEEE 802.15.4e, the IETF formed the
6TiSCH
 6 top, a sublayer that glues together the MAC layer and
6LoWPAN adaptation layer.
 It provides command to the upper layers
 In return these commands enable the functionalities
including network layer routing decisions, configurations
and control procedures for 6TiSCH schedule
management

Schedules in 6TiSCH are broken down into cells. A cell is

simply a single element in the TSCH schedule that can be
allocated for unidirectional or bidirectional
communications between specific nodes.
The 6TiSCH architecture defines four schedule management
mechanisms:
 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
 Neighbor-to-neighbor scheduling
 A schedule is established by observing the correlation and
number of transmission between nodes
 Cells can be added or deleted depending on traffic
requirements and bandwidth
 Remote monitoring and scheduling management
 Time slots and other resources are allocated and
managed remotely

 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.
There are three 6TiSCH forwarding models:
Track Forwarding (TF): Simplest and fastest
 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 or cell bundle is
switched to another cell or cell bundle
Fragment forwarding (FF):
 First fragment is routed based on the IPV6 header.
 The sub-layer learns the next-hop selection of this first
fragment, which is applied to all subsequent fragments of
that packet
 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.
RPL: IPV6 Routing Protocol for Low
Power and Lossy Network
 RPL specification was published as RFC 6550 by the
RoLL(Routing over Low Power and Lossy Network)
working group
 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:
Storing mode:
 All node contains full routing table of the RPL domain.
 Every node knows how to directly reach every other node
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)
 It is a DAG rooted to one destination. The destination
is at border router.
 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.
 Objective Function (OF)
 Defines how metrics are used to select routes and
establish a node’s rank.
 Rank
 Is a 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
 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)

 DICE- DLTS In Constrained Environment

(Datagram Transport Layer Security)
Profiles and Compliances
 Internet Protocol for Smart Objects (IPSO) Alliance
 Wi-SUN Alliance
 Thread
 IPV6 Ready Logo
Application Protocols for IoT
With the TCP/IP, the two main protocols specified for
transport layer are:
 Transmission Control (TCP)
 Connection oriented protocol
 Session must be established between source and
destination before exchanging data
 User Datagram Protocol (UDP)
 Connection less protocol
 Data can be quickly sent between source and destination
 There is no guarantee of delivery
 To choose the transport of DLMS/COSEM(Device
Language Message Specification/Companion
Specification for Energy Metering) over a cellular
network versus an LLN deployment, the following
should be considered
 Select TCP for cellular networks because it is robust
and can handle the overhead. For LLNs, both device
and network are constrained, so UDP is best
 LLNs offers long association which reduces the
overhead whereas in cellular, short associations are
best
 When data is large → cellular, data is small → LLN
IoT Application Transport Methods
 Application layer protocol not present
 Supervisory control and data acquisition (SCADA)
 Generic web-based protocols
 IoT application layer protocols
 Application Layer Protocol Not Present
 Class 0 devices will send and receive only few bytes of data.
 Since they are very much constrained, they don’t use IP,
TCP, UDP and application layer protocol
 Example: consider a low cost temperature and relative
humidity sensors sending data over an LPWA LoRaWAN,
temp → 2 bytes, RH → 2 bytes, this data is sent directly on
top of LoRaWAN, without the use of TCP/IP
 Different temperature sensors from different
manufacturers will report temperature data in varying
formats
 IoT data broker: piece of middleware that standardize
sensor output into a common format that can be
retrieved by authorized applications
SCADA: Supervisory control and
Data Acquisition
 SCADA networks can be found across various
industries
 SCADA mainly concentrates utility and manufacturing
industry
 Commonly used protocols → Modbus, DNP3, IEC
60870-5-101
 Adapting SCADA for IP
 Modbus messaging service → TCP
 DNP3 → TCP or UDP
 IEC 60870-5-101 is serial which runs over Ethernet and
IPV4
 DNP3 is based on master/slave relationship
 Master is located in control centre of a utility
 Slave is a remote device with computing resource (out
stations)
 Outstations monitor and collect data from devices that
indicate their state, and measure values
 This data is transmitted to the master when it is
requested.
 Master initiates connections by TCP active open
 Outstation listens for connection request by passive
open

Tunneling Legacy SCADA over IP Networks

 The transport of original serial protocol over IP can be
done by tunneling using raw sockets over TCP or UDP
 Installing intermediate device that performs protocol
translation between the serial protocol version and its
IP implementation
 A: raw socket encapsulation to transport the serial
payload. Router converts serial to TCP/IP
 B: IP/serial redirector Software is installed on SCADA
server that maps the serial COM ports to IP ports. This
terminates the serial connection of server and converts
it into TCP/IP using a raw socket connection
 C: SCADA server has full IP support for raw socket
connections
SCADA protocol Translation
SCADA Transport over LLNs with
MAP-T
 SCADA supports only IPV4 and network supports only
IPV6
Generic web- Based Protocol
 IoT greatly benefits from the existing web based
protocols including HTTP/HTTPS and XMPP.
 To fully address the constrained nodes and devices, we
have CoAP and MQTT
IoT Application Layer Protocols
CoAP- Constrained Application
Protocol
MQTT-Message Queuing Telemetry
Transport
 DUP(Duplication Flag): when set, allows the client to
note that the packet has been sent previously, but
acknowledgement was not received
 Retain: Only in PUBLISH message. It notifies the
server to hold the message data. The new subscribers
will use it as last known value.
 MQTT offers three levels of QoS:
 QoS 0: unacknowledged data service referred as “at
most once” delivery. The publisher sends message one
time to server, which transmits it once to subscribers.
 No response is sent by receiver, no retry is done by
sender
 QoS 1: ensures message delivery between publisher
and server and then between server and subscriber.
This occurs at least once.
 In PUBLISH and PUBACK, a packet identifier is
included in variable length. If not acknowledged, it is
sent again
 QoS 2: guaranteed service known as “exactly once”
 Highest level used when neither loss nor duplicate
messages is acceptable
 Increases overhead. Each packet contains a optional
variable header with a packet identifier.
 Confirming the receipt of PUBLISH message requires a
two step acknowledgement process.
 First step is done through PUBLISH/PUBREC packet
pair
 Second with PUBREL/PUBCOMP packet pair
 MQTT session between each client and server consist
of four phases :
 Session establishment
 Authentication
 Data exchange
 Session termination
 Message broker uses a topic string or topic name to
filter messages for its subscribers
 Forward slash (/) is used to separate each level with in
the topic which provides hierarchical structure
 Example: Home/livingroom/temperature
 Home/kitchen/temperature
 Wild cards
 + matches only one level can access only
home/livingroom/temp or home/kitchen temp but
not home/livingroom/temperature/noon
 # matches any number of levels within a topic
 Topics beginning with $ sign must be excluded by the
server when subscriptions start with wild characters (+
or #)