Module 03 IoT Networking.............pdf

Module 03:
IoT Networking
Protocols
Developed By
Ahmed Abdelmoamen Ahmed
Kiranmai Bellam
Yonggao Yang
Supported By
National Science Foundation (NSF)
Lesson 01: IoT Requirements for
Networking Protocols

Learning Outcomes
• Upon completion of this lesson, students will be able to:
• Describe the key IoT requirements and constraints on the layers of the TCP/IP
protocol stack.
• Explain the layered view of the IoT protocol stack.
• Gain knowledge about the characteristics of the principal IoT protocols on
each layer of the TCP/IP protocol stack.

IoT Networking
 The classic TCP/IP protocol stack is not suitable for sensor-based networks such
as IoT because its requirements in each layer are sufficiently different.
 So, there is a need for an evolution of TCP/IP protocol stack to address the IoT
requirements and the shortcomings of TCP/IP technologies.

Support for Constrained Devices
• IoT devices span a wide range of capabilities and characteristics
• Computational power, mobility, size, complexity, dispersion (timing out), power
resource, placement and connectivity patterns.
• These characteristics impose new requirements and restrictions for the
underlying network infrastructure
• In particular, the devices computational capabilities and their power resources
introduce challenging requirements for IP networking technologies.
• Traditional devices connected to the internet are homogeneous
• Fully capable computers (e.g. servers, desktops and laptops) have an endless
source of power.

• IoT devices with limited processing, memory and power resources are referred to as
constrained devices.
 Maximum code complexity (ROM/Flash)
 Size of run-time state and buffers (RAM)
 Amount of computation feasible in a specific period of time ("processing power")
 Available power resources
 Management UI and accessibility in deployment (ability to set security keys, update software, etc.).
• IETF RFC 7228 defines a taxonomy of constrained devices based on the first two
dimensions above, which recognizes three classes of devices:
Name Data Size Code Size
Class 0 << 10 KB << 100 KB
Class 1 ~ 10 KB ~ 100 KB
Class 2 ~ 50KB ~ 250KB

• Class 0 devices are the most constrained in memory and processing power
• They do not have resources to connect to an IP network directly, and will leverage the services of
gateways for connectivity. E.g., sensors typically fall under this class.
• Class 1 devices are highly constrained in terms of code space and processing capacity
• However they can connect to an IP network directly
• These devices face challenges in running certain demanding IP protocols such as BGP, OSPF, HTTP.
• Class 2 devices are capable of running the same IP stack that runs on general compute nodes today.
• Nevertheless, these devices can still benefit from lightweight and efficient communication stacks since
the resources may then be directed towards applications in lieu of networking.
Name Data Size Code Size
Class 0 << 10 KB << 100 KB
Class 1 ~ 10 KB ~ 100 KB
Class 2 ~ 50KB ~ 250KB

• Another dimension that characterizes constrained devices is
power/energy resource constraints.
• IoT devices range from devices that uses energy from the environment,
to battery-powered devices, to non-field replaceable battery powered
devices, to mains powered devices.
• Studies show that communication is over 3 orders of magnitude more
expensive in terms of energy consumption than performing local
processing functions.
 This is especially the case when wireless communication is used, where the radio
takes the lion’s share of the energy consumed by the device.

• To this reason, a common strategy employed by power-constrained
devices is to remain in sleep mode with no network connectivity for
extended periods of time, and to connect only long enough to send
data either based on periodic timers or when new data is present or
an event is detected.
• To address the requirements of constrained devices, lightweight,
energy-efficient and bandwidth-conscious communication protocols
are required across all the Layers of the protocol stack.

IoT Protocol Stack: A Layered View
• The Application Layer of the TCP/IP protocol stack is expanded into two layers in the IoT
protocol stack:
 Application Protocols
 Application Services

Link Layer
• Device characteristics: IoT covers a wide spectrum of “things” that span from fully capable
computing nodes to highly constrained devices.
• Traffic characteristics: IoT endpoints vary widely depending on the application’s demands and
nature of devices.
 Some applications have relaxed requirements on packet loss, latency and jitter (e.g.
meteorological monitoring application)
 Other devices have very tight availability, latency and jitter tolerance (e.g. jet engine control
application).
• Access characteristics: IoT endpoints are increasingly diverse - the footprint of the network grows
beyond traditional LAN and WAN technologies into industrial plant floor, oil fields, marine platforms,
mines, wells, power grids, vehicles, locomotives, and even the human body.
• IoT scalability demands, especially for wireless technologies.

Link Layer Protocols
• IEEE 802.15 Task Group 4 (TG4) developed solution for
 Low data rate wireless connectivity
 Low complexity
 Extended battery lifespan
 Operate in an unlicensed, international frequency band.
 Potential applications: toys, smart badges, remote controls and home
automation - short-range communication.
• The standard operates over several frequency bands, which vary by region:
 868 – 868.6 MHz
 902-928 MHz
 2400-2483.5 MHz
 In China 314–316 MHz, 430–434 MHz and 779–787 MHz
 In Japan 950-956 MHz
• Transmission range varies from tens of meters up to 1 kilometer.
• The protocol is fully acknowledged for transfer reliability.

• IEEE 802.15.4e is the Next Generation 802.15.4 wireless mesh with
 Improved energy consumption; and
 Increased reliability.
• The standard introduces a new MAC layer to 802.15.4 while maintaining
the same Physical layer.
• Two key capabilities are added:
 Time Synchronization for better energy utilization.
 Channel Hopping increase the reliability of communication.
• With Time Synchronization, time is sliced into fixed length Timeslots and
all nodes are synchronized.
• A Timeslot is long enough to allow a station to send a Maximum
Transmission Unit (MTU) sized frame and receive an acknowledgement
back.

• Channel Hopping enhances the reliability of communication against multi-path fading and
interference.
• If a specific frequency is subject to fading or interference, then by changing the frequency
used for new messages, only a subset of the messages will be lost.
 Whereas, if all communication were to occur on the same frequency, then all messages would
be lost during the fading or interference event.
• The organization of communication in the schedule allows the network to operate using
collision free communication, by ensuring that only a single station transmits in a given cell.
• Alternatively, it can allow the network to operate in a Slotted Aloha model (i.e. Carrier
Sensing Multi-Access with Collision Detection – CSMA/CD) by allowing multiple stations to
transmit in the same cell.
 IEEE 802.15.4e does not define the mechanisms by which the TSCH schedule is built, and leaves
that responsibility to upper protocol layers.

• Popularity of IEEE 802.11 (Wi-Fi) has grown steadily over the years in home & business
• Short coming of 802.11 for IoT:
 High power consumption stations: wake up at regular intervals to listen to Access Point (AP) announcements
 Unsuitable frequency bands: 2.4 - 5 GHz frequency bands ~ short transmission range and high degree of loss
due to obstructions
• The 802.11ah group was chartered to develop a wireless connectivity solution that operates in the
license-exempt sub-1GHz bands addressing IoT requirements:
 large number of constrained devices,
 long transmission range,
 small and infrequent data messages,
 low data rates
 one-hop network topologies.
• Solution is intended to provide a transmission range of up to 1 km in outdoor areas with data rates
above 100 kbps, while maintaining the current Wi-Fi experience.

• 802.11ah introduces several enhancements to Wi-Fi technology:
 Mechanisms for client stations to save power through longer sleep times.
 Improving the mechanisms by which a client station accesses the medium
 Enhancing the throughput of a client station that accesses the channel
• This translate into the fowling enhancements
 Short MAC Header
 Large Number of Stations
 Speeding Frame Exchanges
 Relay
 Target Wake Time
 Grouping
 Traffic Indication Map (TIM) and Paging Mechanism
 Restricted Access Windows
 Time Sensitive Networking

Internet Layer
• Many IoT deployments constitute Low power &
Lossy Networks (LLNs)
 A large number of constrained embedded devices with
limited power, memory, and processing resources.
 They are interconnected using a variety of Link Layer
technologies, e.g. IEEE 802.15.4, Bluetooth, WiFi.
• LLNs use cases includes industrial monitoring,
building automation, connected homes, health
care, environmental monitoring, Smart Grid and
asset tracking.
• LLNs present these five challenges to the Internet
layer of the protocol stack:

• IPv6 over Low power Wireless Personal Area Networks (6LowPAN) provides three main functions:
 IPv6 header compression: 6LowPAN introduces three headers for each of the three functions that it provides.
Those headers are: Compression header, Fragment header, and Mesh header.
 IPv6 packet segmentation and reassembly
 Layer 2 forwarding (also referred to as Mesh Under).
• With 6LowPAN, it is possible to compress the IPv6 header into 2 bytes, as most of the information is
already encoded into the Link layer header.
Internet Layer

• The Routing over Low power & Lossy Networks (ROLL) Working Group in Internet Engineering
Task Force (IETF) has defined an IPv6 routing protocol for Low power and Lossy Networks (LLNs),
known as RPL .
• RPL is a distance-vector routing protocol (e.g. distance of 5 hops).
• Reason for choosing a distance-vector protocol, as opposed to a link-state, is to minimize the
amount of control-plane state (memory) that needs to be maintained on the constrained nodes
of LLNs.
• Link-state routing protocols build and maintain a link-state database of the entire network on
every node, and hence tend to be heavier on memory utilization compared to distance-vector
algorithms.
• RPL computes a Destination Oriented Directed Acyclic Graph based on an objective function and
a set of metrics and constraints.
Internet Layer

• An adaptation layer is required in order to run the IPv6 stack on top of IEEE 802.15.4 TSCH
(Time Synchronization Channel Hopping, Data Link Layer).
• Goals are to address the following issues:
 Network Formation: the mechanisms by which new nodes securely join the network and the mechanisms by
which nodes that are already part of the network advertise its presence.
 Network Maintenance
 Topology and Schedule Mapping
 Resource Management
 Flow control
 Determinism
 Scheduling Mechanisms
 Secure Communication
Internet Layer

Application Protocols Layer
• Application protocols are responsible for handling the communication
between Application Entities (i.e. Things and Gateways) and Applications.
• They typically support the flow of data (e.g. readings or measurements)
from Things to Applications and the flow of command or control information
(e.g. to trigger or actuate end-devices) in the reverse direction.
• Application protocols define the semantics and mechanisms for message
exchanges between the communicating endpoints.
• The landscape of the Application Protocols Layer in IoT is currently crowded
with competing protocols and standards, each having its own set of
strengths and weaknesses and with no clear path towards convergence
being agreed upon by the industry yet.

Application Protocols Layer
• Applications Protocols vary in the data serialization formats used to encode information into
messages.
• Challenges in IoT data serialization formats:
1. Mapping between the formats used in constrained devices and those used by applications in the
World Wide Web. Popular data serialization formats on the Web include XML and (JavaScript Object
Notation) JSON.
2. The impact data serialization formats have on device resource utilization, socially energy consumption.
3. The impact data serialization formats have on network bandwidth utilization.

Communication Models/Paradigms
• Request/Response enables bi-directional communication between
endpoints
 The initiator of the communication sends a request message, which is
received and operated upon by the target endpoint.
 The latter then sends a response message to the original initiator.
• Request/Response paradigm is well suited for IoT deployments that have
one or more of the following characteristics:
 The deployment follows a client-server architecture
 The deployment requires interactive communication: both endpoints have
information to send to the other side
 The receipt of information needs to be fully acknowledged (e.g. for reliability).
• Disadvantage: one-way communication is often sufficient in IoT
deployments (sensors to applications). Request/Response paradigm is
sub-optimal due to the overhead of the unneeded messages running in
the reverse direction.

• The Publish/Subscribe model enables unidirectional communication from a publisher to
one or more subscribers.
• The subscribers declare their interest in a particular class, or category, of data to the
publisher.
• When the publisher has new data available from that class, it pushes it in messages to
interested subscribers.
• Pub/Sub model is well suited for IoT deployments that can benefit from the following
characteristics:
 Loose coupling between the communicating endpoints, especially when compared with the
client-server model.
 Better scalability by leveraging parallelism and the multicast capabilities of the underlying
transport network.

• Blocking vs. Non-Blocking
Application protocols can offer IoT endpoints blocking or non-blocking messaging service.
In the blocking mode, the endpoint originating a request must wait to get a response to its request,
after the requested operation has finished on the other endpoint. This involves potentially long for the
originator.
In the non-blocking mode, the endpoint originating a request does not wait until the other endpoint
has fully serviced the request. Rather, it expects a prompt acknowledgement of the request together
with a specified reference, so that the originator can retrieve the outcome of the requested operation
at a later point of time.
In the synchronous case, the originator of a request is not able to receive asynchronous messages, i.e.
all exchanges of information between the originator and the receiver need to be initiated by the
originator. The later retrieval of the result of a requested operation is through the exchange of
Request/Response messages between the originator and the receiver.
In the asynchronous case, the originator of a request is able to receive notification messages, i.e. the
receiver can send an unsolicited message to the originator at an arbitrary time to report the of a
requested operation. The mechanisms for the notification to the originator are the same as in the case
of a notification after a subscription.

• Application protocols should provide control over the real-time behavior and
performance of IoT applications by means of a rich set of QoS Policies.
 Control of local resources
 End-to-end properties and characteristics of data transfer.
• Resource Utilization:
 QoS policies to control the amount of memory and CPU processing resources
used by the Application protocol for data transmission and reception.
 These policies include: Resources Limits Policy (buffering) and Time Filter Policy
(min inter-arrival time between sate samples)
Quality of Service (QoS)

RESTfull Model
• Some Application protocols follow a set of constraints defined by the
REpresentational State Transfer (REST) architectural model.
• REST is a distributed client-server software architecture is an ideal model
for IoT. The REST architectural is simple, scalable and reliable.
• Client/Server Communication Model: This allows for separation of concerns where the server
focuses on functions such as data storage whereas clients focus on the user interface and user
state. Uniform interfaces separate the clients from the servers. This allows for independent
development of servers and clients as long as they honor the same interface.
• Stateless Communication: The server must not store any client context that continues between
requests. Session state is maintained by the client, which passes all the information necessary to
service a particular request in the request itself. In other words, requests are self-contained from
a server perspective.

• Cacheable Communication: Responses from the server may be cacheable by clients
and intermediate nodes. This improves the scalability and performance of the system
by partially or completely eliminating some client-server interactions.
• Layered Architecture: To allow for better scalability, the system comprises of a layered
architecture that includes clients, servers and potentially multiple intermediate nodes
interspersed between them. Clients may be in communication with intermediate
nodes or directly with servers without ordinarily being able to identify a difference
between the two.
• Uniform Interfaces: All interactions between clients and servers (or intermediate
nodes) are governed by uniform interfaces.
• Code on Demand: Client functionality may be extended or modified by the server
through the transfer of executable pieces of code that can be executed on the client
side (e.g. scripts or applets). This is an optional REST constraint known as “code on
demand”.
RESTfull Model

The Constrained Application Protocol (CoAP)
• CoAP is a lightweight alternative to HTTP, targeted for constrained nodes in Low-power and Lossy Networks
(LLNs).
• Lightweight examples: minimize no of messages that need to be exchanged between a client and a server to
perform a simple Get operation on a resource:
• First, there are 3TCP SYN messages exchanged to bring up the TCP session, followed by the HTTP Get
request from the client;
• and then the HTTP Response from the server; and
• finally 2 messages to terminate the TCP session.
• Hence, a total of 7 messages are required just to fetch a resource.
• CoAP reduces this overhead by using UDP as a transport in lieu of TCP.
• CoAP also uses short headers to reduce message sizes.
• Similar to HTTP, CoAP is a RESTful protocol. It supports the Create, Read, Update and Delete (CRUD) verbs but
in addition provides built in support for the publish/subscribe paradigm via the new Observe verb.
• CoAP optionally provides a mechanism where messages may be acknowledged for reliability and provides a
bulk transfer mode.

Extensible Messaging and Presence Protocol (XMPP)
• XMPP was originally designed for instant messaging, contact list
and presence information maintenance. It is a message centric
protocol based on the Extensible Markup Language (XML).
• It’s been used in several applications: NM, video, voice over IP,
file sharing, social networks and online gaming.
• In IoT, XMPP has been positioned for Smart Grid solutions. It
started as an open source effort, but the core protocol was later
standardized by IETF.
• The native transport protocol for XMPP is TCP. However, there is
an option to run XMPP over HTTP.

Message Queue Telemetry Transport (MQTT)
• MQTT protocol is a light-weight publish/subscribe messaging protocol that
was originally designed by IBM for enterprise telemetry.
• MQTT follows a client-server architecture where clients connect to a central
server. The protocol is message oriented, where messages are published to an
address, referred to as a topic.
• Clients subscribe to one or more topics and receive updates from a client that
is publishing messages for this topic. In MQTT, topics are hierarchical (similar
to URLs) and subscriptions may use wildcards.
• MQTT is a binary protocol and it uses TCP transport. The protocol is being
standardized by the Organization for the Advancement of Structured
Information Standards (OASIS).
• The protocol targets endpoints where “a small code footprint” is required, or
where network bandwidth is limited, hence it could prove useful for
constrained devices in IoT.

Advanced Message Queuing Protocol (AMQP)
• AMQP originates from financial sector applications but is generic enough to accommodate
other types of applications.
• AMQP provides message delivery guarantees for reliability, including: at least once, at most
once and exactly once. The importance of such guarantees can be easily seen in the context
of financial transactions (e.g. when executing a credit or debit transaction).
 AMQP offers flow control through a token-based mechanism, to ensure that a receiving endpoint is
not overburdened with more messages than it is capable of handling. AMQP assumes a reliable
underlying transport protocol, such as TCP.
• AMQP was standardized by OASIS in 2012 and then by the International Standards
Organization (ISO) and the International Electrotechnical Commission (IEC) in 2014.
 Several open source implementations of the protocol are available. AMQP defines a type system for
encoding message data as well as annotating this data with additional context or meta-data.
 AMQP can operate in simple peer-to-peer mode as well as in hierarchical architectures with
intermediary nodes, e.g. messaging brokers or bridges. Finally, AMQP supports both point-to-point
communication and multipoint publish/subscribe interactions.

The Session Initiation Protocol (SIP)
• SIP handles session establishment for voice, video and instant messaging
applications on IP networks.
• SIP invitation messages used to create sessions carry session descriptions
that enable endpoints to agree on a set of compatible media types.
• SIP leverages elements called proxy servers to route requests to the user's
current location, authenticate and authorize users for services, implement
call-routing policies, and provide features.
• SIP also defines a registration function that enables users to update their
current locations for use by proxy servers.
 SIP is a text-based protocol and can use a variety of underlying transports: TCP
or UDP for example.

IEEE 1888
• IEEE 1888 is an application protocol for
environmental monitoring, smart energy and facility
management applications.
• It is a simple protocol that supports reading and
writing of time-series data using the extensible
markup language (XML) and the simple object access
protocol (SOAP).
 The data is identified using Universal Resource Identifiers
(URIs).
 The latest revision of the protocol was standardized by the
IEEE Standards Association in 2014.

Distributed Data Service - Real Time Publish & Subscribe (DDS RTPS)
• DDS RTPS is a data-centric application protocol that supports the publish/subscribe
paradigm.
 DDS organizes data into "topics" that listeners can subscribe to and receive asynchronous updates when
the associated data changes.
 DDS RTPS provides mechanisms where listeners can automatically discover speakers associated with
specific topics. IP multicast or a centralized broker/server may be used to that effect.
 Multiple speakers may be associated with a single topic and priorities can be defined for different
speakers. This provides a redundancy mechanism for the architecture in case a speaker fails or loses
communication with its listeners.
• DDS RTPS supports very elaborate QoS policies for data distribution, covering reliability,
data persistence, delivery deadlines and data freshness. DDS RTPS is a binary protocol
and it uses UDP as the underlying transport. The latest version of the protocol was
standardized by the Object Management Group (OMG) in 2014.

Survey of IoT Application Protocols
Protocol Functions Primary Use Transport Format Org.
CoAP REST resource manipulation via CRUD
Resource tagging with attributes
Resource discovery through RD
LLNs UDP Binary IETF
XMPP Manage presence
Session establishment
Data transfer (text or binary)
Instant Messaging TCP
HTTP
XML IETF
XSF
MQTT Light weight Pub/sub messaging
Message queuing for future subscribers
Enterprise Telemetry TCP Binary OASIS
AMQP Message orientation, queuing & pub/sub
Data transfer with delivery guarantees (at least once,
at most once, exactly once)
Financial services TCP Binary OASIS
SIP Manage presence
Session establishment
Data transfer (voice, video, text)
IP Telephony TCP, UDP, SCTP XML IETF
IEEE 1888 Read/write data into URI
Handling time-series data
Energy & Facility
Management
SOAP / HTTP XML IEEE
DDS (RTPS) Pub/Sub messaging with well-defined data types
Data Discovery
Elaborate QoS
Real time distributed
systems (military,
industrial, …)
UDP Binary OMG

• Machine-to-Machine (M2M) deployments have existed for over two decades.
However, what has characterized these deployments is a state of fragmentation:
vertical solutions are implemented in silos with proprietary communication stacks
and tight coupling between applications and devices: "one application - one device".
• Need Common Abstraction Layer: Application Services Layer
Application Services Layer

OneM2M
• OneM2M standards consider any IoT deployment to be comprised of two domains:
 Field Domain: includes the Things (e.g. sensors, actuator) and gateways
 Infrastructure Domain: includes the communication networks (aggregation, core) and data centers.
 Each of these domains includes three flavors of entities:
 Application Entity,
 Common Services Entity
 Network Services Entity.

• Application Entity: implements the vertical-specific application logic. It may reside on one or multiple physical nodes
in the deployment. Examples of an Application Entity would be a home automation application or a smart parking
application.
• Common Services Entity: is a middleware layer that sits in between applications (Application Entity) and the
underlying network services (Network Services Entity). The Common Services Entity (CSE) provides the following set
of common functions to applications:
 Identity Management: Identification of Applications Entities and CSEs.
 Registration: Includes registration of Application Entities and CSEs.
 Connectivity Handling: This ensures efficient, reliable and scalable use of the underlying network.
 Remote Device Management: This includes configuration & diagnostic functions.
 Data Exchange: Supports storing & sharing of data between applications and devices, in addition to event notification.
 Security & Access control: Provides control over access to data (who can access what and when, etc.).
 Discovery: Provides discovery of entities as well as data and resources.
 Group Management: Support of bulk operations and access.
 Location: Provides an abstraction for managing and offering location information services.
• Network Services Entity: provides value added services to the CSE, such as QoS, device management, location
services and device triggering.
OneM2M

• OneM2M follows a RESTful architecture style where all
data is modeled as Resources.
• Although oneM2M does not define a static Resource
structure like the ETSI Resource Tree.
• Instead, the standard provides means by which
Resources can be linked together (through Resource
links).
• Client applications can discovery the Resource
organization dynamically
OneM2M

Module 03 IoT Networking.............pdf

Recommended

More Related Content

Similar to Module 03 IoT Networking.............pdf (20)

More from arabnuradin (16)

Recently uploaded (20)

Module 03 IoT Networking.............pdf