Internet of Things

Module 4
Syllabus

Choice 1 (20 marks) Choice 2 (20 marks) Important (Priority

wise)

IP as IoT Network layer Application Protocols for IoT IP as IoT Network layer

Business Case for IP Transport Layer Business Case for

IP
Key advantages Application Transport
Key advantages
methods
Adoption
Adoption
Application layer
Need for Optimization Need for
protocol not
Constrained Nodes Optimization
present
Constrained Networks Constrained
Background only
Nodes
IP Versions of SCADA
Constrained
Optimizing IP for IoT Generic Web Networks
based Protocols IP Versions
IoT Application Optimizing IP for
Layer Protocols IoT
Data and Analytics for IoT
Introduction
Structured and
Unstructured data
IoT Data Analytics
Overview and Challenges

Application Protocols for IoT

The Transport Layer:
The major protocols supported by transport layer are TCP and UDP
Transmission Control Protocol (TCP): TCP is a connection-oriented protocol requiring a
session to get established between the source and destination before exchanging data. TCP is
the main protocol used in the transport layer of cellular networks due to its inherent
characteristics such as the ability to transport large volumes of data into smaller sets of packets.
TCP also ensures the reassembly of packets in the correct sequence, flow control, and
retransmission of lost packets. Limitations of TCP are high overhead per packet and per
session, thus impacting overall performance and latency.
User Datagram Protocol (UDP): UDP is a connectionless protocol where data can be quickly
sent between source and destination, but with no guarantee of delivery. UDP is most often used
in the context of network services or for real-time data traffic, including voice and video over
IP. UDP is preferred where performance and latency are more important than packet
retransmissions.
Why UDP over TCP for constrained nodes and networks?
While using TCP may not strain generic compute platforms and high data rate networks, it can
be challenging and is often overkill on constrained IoT devices and networks. IoT devices
normally send only a few bytes of data per transaction. Each packet needs to add a minimum of
20 bytes of TCP overhead when using TCP, while UDP adds only 8 bytes. TCP also requires
the establishment and maintenance of an open logical channel. When it comes to networks,
LLNs may not cope well with TCP sessions for the same reasons. This is why IoT application
protocols such as CoAP, and industrial application layer protocols, if run over LLNs, almost
always use UDP.
Eg: Transport of DLMS/ COSEM over a cellular network versus an LLN deployment
Device Language Message Specification (DLMS)/ Companion Specification for Energy Metering
(COSEM) is a popular protocol for reading smart meters in the utilities space
● Select TCP for cellular networks as these networks are typically more robust and can
handle the overhead. For LLNs, UDP is a better choice
● DLMS/ COSEM can reduce the overhead associated with session establishment by
offering a long association over LLNs. Long association means that sessions stay up
once in place because the communications overhead necessary to keep a session
established is much less than closing and opening separate sessions over the same time
period. Conversely, for cellular networks, a short association better controls the costs by
tearing down the open associations after transmitting.
● When transferring large amounts of data, cellular links are preferred to optimize each
open association, whereas smaller amounts of data can be handled efficiently over LLNs.
 Since packet loss ratios are generally higher on LLNs than on cellular networks, keeping
the data transmission amounts small over LLNs limits the retransmission of a large
number of bytes.
While selecting a particular protocol one should take care of Multicast requirements,
interoperability, performance and stability requirements, and so on

Difference between TCP and UDP

Basis TCP UDP

Type of Connection-oriented protocol; Datagram-oriented connectionless

service
Connection-orientation means that the protocol; This is because there is no
communicating devices should overhead for opening a connection,
establish a connection before maintaining a connection, and
transmitting data and should close the terminating a connection. UDP is
connection after transmitting the data. efficient for broadcast and multicast
types of network transmission.

Reliability Reliable Not as reliable as TCP

Error Extensive Basic

checking
mechanism

Acknowledge Present Absent

ment
Segment

Sequencing Present; Sequencing of data is a Absent; There is no sequencing of

of data
feature of Transmission Control data in UDP. If the order is required,
Protocol (TCP). This means that it has to be managed by the
packets arrive in order at the receiver. application layer.

Speed Comparatively slower Comparatively faster

Retransmissi Possible Not possible

on of lost
packets
 Header 20 - 60 bytes variable length header 8 bytes fixed length header
length

Weight Heavyweight Lightweight

Handshaking Present Absent

Broadcasting Possible Not possible

Stream type Byte stream Message stream

Overhead High compared to UDP Very low

IoT Application Transport Methods

Application Layer Protocol Not Present
Here, the data payload is directly transported on top of the lower layers. No Application
layer protocol is used. Eg: Class 0 devices which are usually smart objects, send or receive only
a few bytes of data, are resource constrained, and also do not implement a network protocol
stack. A low-cost temperature and humidity sensor sending data over a network has no need for
application layer protocol as the data payload is small.
This transportation method has not been standardized. Lack of standardization makes it
difficult for generic implementation from an interoperability perspective.
IoT data broker: Consider a scenario where temperature sensors from different manufacturers
are being used. These sensors will report temperature data in varying formats. Now the problem
is that decoding these temperature data is vendor specific. If this scenario is scaled to thousands
of sensors, the level of complexity is simply too much to handle. The solution to this problem is
the use of an IoT data broker. An IoT data broker is a middleware that standardizes sensor
output into a common format that can then be retrieved by authorized applications.
In the figure above, Sensors X, Y, and Z are all temperature sensors, but their output is encoded
differently. The IoT data broker understands the different formats and is, therefore, able to
decode this data into a common, standardized format. Applications A, B, and C can access this
temperature data without having to deal with decoding multiple temperature data formats.
IoT data brokers are also utilized from a commercial perspective to distribute and sell IoT data
to third parties.
In summary, while directly transporting data payload without a structured network stack
optimizes data transmission over low data rate networks, the lack of a data model means that
each application needs to know how to interpret the data-specific format. This becomes
increasingly complex for larger networks of devices with different data payload formats.
Furthermore, it makes the IoT application environment challenging in terms of evolution,
development, interoperability, and often calls for structured data models and data broker
applications.

SCADA
SCADA is an automation control system used to gather data in real-time from remote
locations in order to control equipment and conditions.
SCADA networking protocols are well-structured protocols. SCADA systems collect sensory
data and telemetry from remote devices, while also providing the ability to control them.
SCADA systems allow real-time, data-driven decisions to be made regarding business processes.

Generic Web-based Protocols

Web-based protocols have become common in consumer and enterprise applications and
services. Hence, it makes sense to adopt these protocols for IoT applications in order to ease
the integration of data and devices from prototyping to production.
The level of familiarity with generic web-based protocols is high. Therefore, programmers with
basic web programming skills can work on IoT applications, and this may lead to innovative
ways to deliver and handle real-time data. In addition, web-based protocols are also easy to
scale. The definition of constrained nodes and networks should be analyzed when selecting a
web-based protocol.
The HTTP/ HTTPS client/server model serves as the foundation for the World Wide Web.
Recent evolutions of embedded web server software with advanced features are now
implemented with very little memory. This enables the use of embedded web services software
on constrained devices.
When considering web services implementation on an IoT device, the choice between
supporting the client or server side of the connection must be carefully weighed. IoT devices
that only push data to an application may need to implement web services on the client side. The
HTTP client side only initiates connections and does not accept incoming ones. On the other
hand, some IoT devices such as video surveillance cameras may have web services implemented
on the server side. However, because these devices often have limited resources, the number of
incoming connections must be kept low. In addition, advanced development in data modeling
should be considered as a way to shift the workload from devices to clients such as web browsers
on PCs.
IoT Application Layer Protocols
New lightweight protocols that are better suited to large numbers of constrained nodes and
networks have been developed. CoAP and MQTT are among the same.

CoAP (Constrained Application Protocol)

Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with
constrained nodes and constrained networks in the Internet of Things. CoAP is designed to
enable simple, constrained devices to join the IoT even through constrained networks with low
bandwidth and low availability. It is generally used for machine-to-machine (M2M)
applications such as smart energy and building automation. The protocol was designed by the
Internet Engineering Task Force (IETF).
CoAP Features
1. The CoAP messaging model is primarily designed to facilitate the exchange of messages
over UDP
2. Asynchronous message exchange
3. Low overhead
4. Uniform resource identifier (URI)
5. Proxy and caching capabilities
6. Very Simple To Perform Syntactic Analysis
7. CoAP supports congestion control, detection of duplicate messages, multicasting
(firmware upgrade for smart meters), and so on
CoAP functions as a sort of HTTP for restricted devices, enabling equipment such as sensors or
actuators to communicate on the IoT. These sensors and actuators are controlled and made to
contribute by passing along their data as part of a system. The protocol is designed for reliability
in low bandwidth and high congestion through its low power consumption and low network
overhead. In a network with a lot of congestion or limited connectivity, CoAP can continue to
work where TCP-based protocols such as MQTT fail to exchange information and communicate
effectively
CoAP message format
CoAP message format is composed of a short fixed length Header field of 4 bytes, a variable
length but mandatory Token field of 0 - 8 bytes, Options field if necessary, and the Payload
field. CoAP message format delivers low overhead which is critical for constrained
networks while decreasing parsing complexity.

CoAP Message format

CoAP message fields
1. Ver (Version): Identifies the CoAP version
2. T (Type): Defines one of four message types
a. CON - Confirmable; While running over UDP, CON ensures reliable
transmission of messages
b. NON - Non-confirmable
c. ACK - Acknowledgement
d. RST - Reset
3. TKL (Token length): Specifies the size (0 - 8 bytes) of the Token field
4. Code: Indicates the request method for a request message and a response code for a
response message
5. Message ID: Detects message duplication and used to match ACK and RST message
types to Con and NON message types
6. Token: Correlates requests and responses
7. Options: Specifies option number, length, and option value
8. Payload: Carries the CoAP application data. This field is optional, but when present, a
single byte of all 1’s precedes the payload. The purpose is to delineate the end of
Options field and the beginning of the Payload
CoAP is based on REST architecture, with a thing acting as both the client and the server. A
client requests an action via a method code on a server resource. A uniform resource identifier
(URI) localized on the server identifies this resource. The server responds with a response code
that may include a resource representation. The CoAP request/response semantics include the
methods GET, POST, PUT, and DELETE.
CoAP Reliable transmission example
Figure shows a utility operations center on the left, acting as a CoAP client, with the CoAP
server being a temperature sensor on the right of the figure. The communication between client
and server uses a CoAP message ID of 0x47. The CoAP message ID ensures reliability and is
used to detect duplicate messages. The client sends a GET CON message with message ID to
get the temperature from the sensor. A CON marking means the message will be
retransmitted until the recipient sends an acknowledgement (ACK) with the same message
ID. Here, the temperature sensor does reply with an ACK message with the same message ID. In
addition, this ACK message piggybacks a successful response to the GET request. This is
indicated by the 2.05 response code followed by the requested data.
In summary, CoAP is a key application protocol which is fully optimized for IoT
constrained nodes and networks.

MQTT (Message Queuing Telemetry Transport)

At the end of the 1990s, Engineers from IBM were looking for a reliable, lightweight, and cost
effective protocol to monitor and control a large number of sensors and their data from a
central server location. This resulted in MQTT.
MQTT is a lightweight, publish-subscribe, machine to machine network protocol for
Message queue/Message queuing service. It is designed for connections with remote locations
that have devices with resource constraints or limited network bandwidth. MQTT is based on a
client/server and publish/subscribe framework and TCP/IP architecture.

MQTT Publish/ Subscribe framework

An MQTT client acts as a publisher to send data to an MQTT server acting as an MQTT
message broker. In the figure shown above, the MQTT client on the left side is a temperature
and RH sensor that publishes Temp/RH data. The MQTT server accepts the network
connection along with application messages such as Temp/RH data from the publishers. It
also handles subscription and unsubscription processes and pushes data to MQTT clients
acting as subscribers shown on the right side of the figure. This is a well known model where
subscribers express a desire to receive information from publishers (twitter).
With MQTT, clients can subscribe to all data or specific data from the publisher. In addition,
the presence of a message broker in MQTT decouples the data transmission between
publishers and subscribers. Here, publishers and subscribers do not even need to know about
each other. A benefit of decoupling is that the MQTT message broker ensures that information
can be buffered and cached in case of network failures. This also means publishers and
subscribers do not need to be online at the same time.
MQTT is a lightweight protocol as each control packet consists of a 2 byte fixed header with
optional variable header fields and optional payload up to 256 MB.
MQTT message format

MQTT contains a smaller header of 2 bytes compared to 4 bytes for CoAP

1. The first MQTT field is the message type, which identifies the kind of MQTT packet
within a message. 14 different control packets are specified in MQTT.

Message type Value Flow Description

CONNECT 1 Client to server Request to connect

 CONNACK 2 Server to Client Connect acknowledgement

PUBLISH 3 Client to server Publish message

Server to Client

PUBACK 4 Client to server Publish Acknowledgement

Server to Client

PUBREC 5 Client to server Publish received

Server to Client

PUBREL 6 Client to server Publish release

Server to Client

PUBCOMP 7 Client to server Publish complete

Server to Client

SUBSCRIBE 8 Client to server Subscribe request

SUBACK 9 Server to Client Subscribe acknowledgement

UNSUBSCRIBE 10 Client to server Unsubscribe request

UNSUBACK 11 Server to Client Unsubscribe acknowledgement

PINGREQ 12 Client to server Ping request

PINGRESP 13 Server to Client Ping response

DISCONNECT 14 Client to server Client disconnecting

Values 0 and 15 are reserved

2. The next field in the MQTT header is DUP (Duplication flag). This flag, when set,
allows the client to notate that the packet has been sent previously, but an
acknowledgement was not received.
3. The QoS (Quality of Service) header field allows for the selection of three different
QoS levels:
a. QoS 0: QoS 0 level ensures “at most once delivery”. The publisher sends its
message one time to a server, which transmits it once to the subscribers. No
response is sent by the receiver, and no retry is performed by the sender. The
message arrives at the receiver either once or not at all.
 b. QoS 1: QoS 1 level ensures that the message delivery between the publisher and
server and then subscribers occurs at least once. Packet identifier is included. If
the message is not acknowledged by a PUBACK packet, it is sent again. This
level guarantees “at least once” delivery.
c. QoS 2: In this level, neither loss nor duplication of message is acceptable.
Packet identifier and optional variable header leads to increased overhead.
This level provides a guaranteed service known as exactly once delivery, with
no consideration for the number of retries as long as the message is delivered
once.
4. The next field is the Retain flag. Retain flag notifies the server to hold onto a message
data. This allows new subscribers to instantly receive the last known value without
having to wait for the next update from the publisher.
5. The last mandatory field in the MQTT message header is the remaining length. This
field specifies the number of bytes in the MQTT packet following this field.
6. MQTT sessions between each client and server consist of four phases: session
establishment, authentication, data exchange, and session termination. Each client
has a unique client ID.
Comparison between CoAP and MQTT

Factor CoAP MQTT

Main transport protocol UDP TCP

Typical messaging Request/response Publish/subscribe

Effectiveness in LLNs Excellent Low/fair

Security DTLS SSL/TLS

Communication model One-to-one many-to-many

Strengths Lightweight, fast, low Robust communication,

overhead, suitable for simple management, easy to
constrained networks scale using a broker
architecture

Weaknesses Not reliable Higher overhead, no

multicasting, can drain
low-power devices
An Introduction to Data Analytics for IoT
The real value of IoT is not just in connecting things but rather in the data produced by those
things, the new services one can enable via those connected things, and the business insights
that the data can reveal
In the world of IoT, the creation of massive amounts of data from sensors is common and one
of the biggest challenges, both from a transport perspective and data management
standpoint. Eg: Commercial aviation industry - Modern jet engines are fitted with thousands
of sensors that generate a whooping 10GB of data per second. Considering that there are
approximately 100,000 commercial flights per day, the amount of data being generated is
overwhelming. Analyzing this amount of data in the most efficient manner possible falls
under the umbrella of data analytics. Data analytics must be able to offer actionable insights
and knowledge from data in a timely manner.

Structured versus Unstructured Data

Structured data: Structured data means that the data follows a model or schema that defines
how the data is represented or organized. Thus, it fits well with a traditional relational database
management system (RDBMS). Eg: Data in a simple tabular form - a spreadsheet. Structured
data can be found in most computing systems and includes everything from banking transactions
and invoices to computer log files and router configurations. IoT sensor data often uses
structured values, such as temperature, pressure, humidity, and so on. Structured data is easily
formatted, stored, queried, and processed. For these reasons, structured data has been the core
type of data used for making business decisions. A wide array of data analytics tools are readily
available for processing structured data.
Unstructured data: Unstructured data lacks a logical schema for understanding and decoding
the data through traditional programming means. Eg: Text, Speech, Images, Video. Data that
does not fit neatly into a predefined data model is classified as unstructured data. According
to some estimates, around 80% of a business’s data is unstructured.
Semi-structured data: Hybrid of structured and unstructured data and shares characteristics of
both. Eg: Email - Fields are well defined but the content contained in the fields and attachments
is unstructured.
Smart objects in IoT networks generate both structured and unstructured data. Structured data
is more easily managed and processed due to its well-defined organization. On the other hand,
unstructured data can be harder to deal with and typically requires very different analytics
tools for processing the data.

Data in Motion Versus Data at Rest

Data in IoT networks is either in transit (‘data in motion”) or being held or stored (“data at
rest”). Examples of data in motion: Email. Examples of data at rest: Hard drive, USB drive
From an IoT perspective, the data from smart objects are considered data in motion as it passes
through the network en route to its final destination. This is often processed at the edge using
FOG computing. Data does not come to rest at the edge. Data at rest in IoT networks can be
typically found in IoT brokers or in storage arrays at the data center. Hadoop is one tool that
helps in data storage and processing.

IoT Data Analytics Overview

Data analytics is typically broken down by the types of results that are produced:
1. Descriptive: Descriptive data analytics tells what is happening, either now or in the past
2. Diagnostic: Diagnostic data analytics tells why something has happened
3. Predictive: Predictive data analytics aims to foretell problems or issues before they
occur
4. Prescriptive: Prescriptive data analytics goes a step beyond predictive and recommends
solutions for upcoming problems
Eg: A thermometer in a truck engine reports temperature values every second. From a
descriptive analysis perspective, one can pull this data at any moment to gain insight into the
current operating condition of the truck engine, say, engine temperature value. Now if one finds
that the engine temperature is too high, diagnostic analysis might tell us that this is because the
engine has overheated. Now, if one looks at the historical values of temperatures for the truck
engine, predictive analysis could provide an estimate on the remaining life of certain
components in the engine. These components could then be proactively replaced before failure
occurs. If temperature values of the truck engine start to rise slowly over time, this could indicate
the need for an oil change. A prescriptive analysis of the temperature data from a truck engine
might calculate various alternatives to cost-effectively maintain the truck. These calculations
could range from the cost necessary for more frequent oil changes to installing new cooling
equipment on the engine.
Both predictive and prescriptive analyses are more resource intensive and increase
complexity, but the value they provide is much greater than the value from descriptive and
diagnostic analysis.
IoT Data Analytics Challenges
IoT data places two specific challenges on a relational database:
1. Scaling Problems: Due to the large number of smart objects in IoT networks that
continually send data, relational databases can grow incredibly large very quickly. This
can result in performance issues, often requiring expensive hardware and
architecture changes.
2. Volatility of data: Relational databases demand that schema be designed correctly from
the beginning. Changing it later can slow or stop the database from operating. Due to
the lack of flexibility, revisions to the schema must be kept at a minimum. IoT data,
however, is volatile as they change and evolve over time. A dynamic schema is often
required so that data model changes can be made daily or even hourly.
To deal with these challenges, a different type of database, known as NoSQL is being used.
NoSQL databases do not enforce a strict schema, and they support a complex, evolving data
model. These databases are also inherently much more scalable.
In addition, IoT also brings challenges with the live streaming nature of data as they are of a
very high volume, and analysis is valuable if only carried out in real time. Real time analysis of
streaming data allows us to detect patterns and anomalies that could indicate a problem that
needs some kind of immediate response.
Network Analytics: Networks are at the center of today’s world, so understanding how the
network is performing is critical, not just for technical reasons, but for the operation of the
business itself. Network operators are utilizing analytics to gain a deeper understanding of the
network, and are able to make smarter, data-driven decisions about their operations that help
them achieve their desired business outcomes. Network analytics involves the analysis of
network data and statistics to identify trends and patterns. Once identified, operators take
the next step of ‘acting’ on this data—which typically involves a network operation or a set of
operations. For example, if a network operator finds that there may be a congestion problem in
a certain area of the network, traffic can be routed through a different part of the network to
meet service performance objectives. The large numbers of smart objects in IoT networks that
are communicating and streaming data make it highly challenging to ensure that data flows are
effectively managed, monitored, and secure.
Network analytics provides deeper insight into how the network is performing and how an
organization is using the network. IT can use analytics to improve security, fine-tune
performance, troubleshoot subtle problems, and spot potential trouble.
Some other key benefits of network analytics include:
1. Optimized use of network resources: Analytics can help you understand your network,
and balance and utilize resources in the best way possible so you can optimize network
performance and lower cost structures
2. New revenue streams: Analytics plays a critical role in mining insights that can identify
new revenue streams and build data-driven business cases for quick action
3. Accelerated time to market: Analytics can help make capacity planning easier for new
services. As a result, the resources required for a new or expanded service can be
calculated and then provisioned well in advance of going live, ensuring products get to
market on time.