MODULE-3

Chapter- 6 Application Protocols for

IoT
 Application Protocols for IoT
• IoT application protocols you select should be contingent on
the use cases and vertical industries they apply to
• IoT application protocols are dependent on the characteristics
of the lower layers themselves
• For example, application protocols that are sufficient for
generic nodes and traditional networks often are not well
suited for constrained nodes and networks
• This chapter focuses on how higher-layer IoT protocols are
transported
• 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
• 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): This
connection-oriented protocol requires a session to get
established between the source and destination before
exchanging data.
• User Datagram Protocol With this
(UDP): quickly
connectionless
between protocol,
source and data can with
destination—but be no guarantee
sent
of delivery. This is analogous to the traditional mail
delivery system
• With the predominance of human interactions over the
Internet, TCP is the main protocol used at the
transport layer.
• This is largely due to its inherent characteristics,
such as its ability to transport large volumes of data
into smaller sets of packets.
• In addition, it ensures reassembly in a correct
sequence, flow control and window adjustment, and
retransmission of lost packets
• UDP is most often used in the context of network
services, such as Domain Name System (DNS),
Network Time Protocol (NTP), Simple Network
Management Protocol (SNMP), and Dynamic Host
Control Protocol (DHCP), or for real-time data traffic,
including voice and video over IP.
IoT Application Transport Methods
• Because of the diverse types of IoT application
protocols, there are various means for transporting
these protocols across a network
• The following categories of IoT application protocols
and their transport methods are explored in the
following sections:
• 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.
• Supervisory control and data acquisition
(SCADA): SCADA (real time) is one of the most
common Industrial protocols in the world, but it were
developed long before the days of IP, and it has been
adapted for IP networks.
• 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
• IoT application layer protocols: IoT application layer protocols are
devised to run on constrained nodes with a small compute footprint and
are well adapted the network bandwidth constraints on cellular or
satellite links or constrained 6LoWPAN networks.
• Message Queuing Telemetry Transport (MQTT) (transmit and
receive data over a resource-constrained network with limited
bandwidth.) and Constrained Application Protocol (CoAP), constrained
devices to join the IoT even through constrained networks with low
bandwidth and low availability.
 Application Layer Protocol Not Present
• IETF RFC 7228 devices defined as class 0 send or receive
only a few bytes of data. reasons, such as processing
capability, power constraints, and cost, these devices do
not implement a fully structured network protocol stack,
such as IP, TCP, or UDP, or even an application layer
protocol.
• Class 0 devices are usually simple smart objects that are
severely constrained Implementing a robust protocol stack
is usually not useful and sometimes not even possible with
the limited available resources.
• For example, consider low-cost temperature and relative
humidity (RH) sensors sending data over an LPWA
LoRaWAN infrastructure
• Temperature is represented as 2 bytes and RH as another
2 bytes of data. Therefore, this small data payload is
directly transported on top of the LoRaWAN MAC layer,
without the use of TCP/IP.
SCADA (supervisory control and data
acquisition)
• In the world of networking technologies and
protocols, IoT is relatively new. Combined with the
fact that IP is the de facto standard for computer
networking in general,
• Older protocols that connected sensors and
actuators have evolved and adapted themselves to
utilize IP.
• A prime example of this evolution is supervisory
control and data acquisition (SCADA).
• Designed decades ago, SCADA is an automation
control system that was initially implemented without
IP over serial links, before being adapted to Ethernet
and IPv4
Adapting SCADA for IP
• Legacy serial protocols have adapted and evolved to
utilize IP and TCP/UDP as both networking and
transport mechanisms
• The IEEE 1815-2012 specification describes how the
DNP3(Distributed Network Protocol3) protocol
implementation must be adapted to run either over
TCP (recommended) or UDP.
• DNP3 is based on a master/slave relationship.
• Master: a powerful computer located in the control
centre of a utility.
• Slave: a remote device with computing resources
found in a location such as substation.
• DNP3 typically referred as outstations.
• The master side initiates connections by performing a
TCP active open
• The outstation listens for a connection request by
performing a TCP passive open
• Dual endpoint is defined as a process that can both
listen for connection requests and perform an active
open on the channel if required
• Master stations may parse multiple DNP3 data link
layer frames from a single UDP datagram, while
DNP3 data link layer frames cannot span multiple
UDP datagram’s
• Single or multiple connections to the master may
get established while a TCP keep alive timer
monitors the status of the connection
SCADA Protocol Translation
• An alternative to a raw socket connection for transporting
legacy serial data across an IP network is protocol translation
• With protocol translation, the legacy serial protocol is translated to
corresponding IP version
• For example, Figure 6-4 shows two serially connected DNP3
RTUs and two master applications supporting DNP3 over IP that
control and pull data from the RTUs
• The IoT gateway in this figure performs a protocol translation
function that enables communication between the RTUs and servers
• RTU: a multi purpose device used to monitor and control various
systems, application and devices managing automation
IoT Application Layer Protocols
• When considering constrained networks and/or a
large-scale deployment of constrained nodes, verbose
web-based and data model protocols, may be too
heavy for IoT applications.
• To address this problem, the IoT industry is working
on new lightweight protocols that are better suited to
large numbers of constrained nodes and networks.
Two of the most popular protocols are CoAP and
MQTT
• CoAP and MQTT are naturally at the top of this
sample IoT stack, based on an IEEE 802.15.4 mesh
network. While there are a few exceptions, you will
almost always find CoAP deployed over UDP and
MQTT running over TCP
 CoAP (Constrained Application Protocol)
• The IETF Constrained RESTful Environments (CoRE)
working group’s efforts to develop a generic framework for
resource-oriented applications targeting constrained nodes
and networks
• The CoAP framework defines simple and flexible ways to
manipulate sensors and actuators for data or device
management.
• The CoAP messaging model is primarily designed to
facilitate the exchange of messages over UDP between
endpoints, including the secure transport protocol
Datagram Transport Layer Security (DTLS).
• CoAP message is composed of a short fixed-length Header
field (4 bytes), a variable-length but mandatory Token field
(0–8 bytes), Options fields if necessary, and the Payload
Figure 6-7 CoAP Message Format
• As you can see in Figure 6-7, the CoAP message
format is relatively simple and flexible.
• It allows CoAP to deliver low overhead, which is
critical for constrained networks, while also being
easy to parse and process for constrained devices.
• Table 6-1 provides an overview of the various
fields of a CoAP message
• CoAP can run over IPv4 or IPv6. However, it is
recommended that the message fit within a single IP
packet and UDP payload to avoid fragmentation.
• For IPv6, with the default MTU size being 1280 bytes
and allowing for no fragmentation across nodes, the
maximum CoAP message size could be up to 1152
bytes, including 1024 bytes for the payload
• CoAP communications across an IoT infrastructure
can take various paths. Connections can be between
devices located on the same or different constrained
networks or between devices and generic Internet or
cloud servers, all operating over IP
• Proxy mechanisms are also defined, and RFC 7252
details a basic HTTP mapping for CoAP. As both HTTP
and CoAP are IP-based protocols, the proxy function can
be located practically anywhere in the network, not
necessarily at the border between constrained and non-
constrained networks.
• Just like HTTP, CoAP is based on the REST
architecture, but with a “thing” acting as both the client
and the server. Through the exchange of asynchronous
messages, 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. Example 6-2
shows the CoAP URI format.
• You may notice that the CoAP URI format is similar
to HTTP/HTTPS. The coap/coaps URI scheme
identifies a resource, including host information and
optional UDP port, as indicated by the host and port
parameters in the URI
• coaps-URI = "coaps:" "//" host [":" port] path-abempty
["?" query]
• The client in Figure 6-9 sends a GET message to get the
temperature from the sensor.
• Notice that the 0x47 message ID is present for this GET
message and that the message is also marked with CON.
A CON, or confirmable, marking in a CoAP message
means the message will be retransmitted until the
recipient sends an acknowledgement (or ACK) with the
same message ID.
• In Figure 6-9, the temperature sensor does reply with an
ACK message referencing the correct message ID of
0x47.
• In addition, this ACK message piggybacks a successful
response to the GET request itself. This is indicated by
the 2.05 response code followed by the requested data
 Message Queuing Telemetry Transport (MQTT)
• At the end of the 1990s, engineers from IBM and Arcom
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
• As typically used by the oil and gas industries. Their
research resulted in the development and implementation
of the Message Queuing Telemetry Transport (MQTT)
protocol that is now standardized by the Organization for
the Advancement of Structured Information Standards
(OASIS).
• These were some of the rationales for the selection of a
client/server and publish/subscribe framework based on
the TCP/IP architecture, as shown in Figure 6-10.
• An MQTT client can act as a publisher to send data (or
resource information) to an MQTT server acting as an
MQTT message broker.
• In the example illustrated in Figure 6-10, the MQTT
client on the left side is a temperature (Temp) and relative
humidity (RH) sensor that publishes its Temp/RH data.
• The MQTT server (or message broker) accepts the
network connection along with application messages,
such as Temp/RH data, from the publishers.
• It also handles the subscription and un-subscription
process and pushes the application data to MQTT clients
acting as subscribers.
• This model, where subscribers express a desire to receive
information from publishers, is well known. A great
example is the collaboration and social networking
application Twitter.
• MQTT is a lightweight protocol because each control
packet consists of a 2-byte fixed header with optional
variable header fields and optional payload
• You should note that a control packet can contain a payload
up to 256 MB. Figure 6-11 provides an overview of the
MQTT message format
• Compared to the CoAP message format in Figure 6-7, you
can see that MQTT contains a smaller header of 2 bytes
compared to 4 bytes for CoAP.
• The first MQTT field in the header is Message Type,
which identifies the kind of MQTT packet within a
message. Fourteen different types of control packets are
specified in MQTT version 3.1.1.
• Each of them has a unique value that is coded into the
Message Type field. Note that values 0 and 15 are reserved
MQTT message types are summarized in Table 6-2.
• As mentioned earlier, the QoS process is symmetric in
regard to the roles of sender and receiver, but two separate
transactions exist.
• One transaction occurs between the publishing client
and the MQTT server, and the other transaction happens
between the MQTT server and the subscribing client.
• Figure 6-13 provides an overview of the MQTT QoS
flows for the three different levels
• The client on each side of the MQTT flow sets the QoS
level. The publishing client side sets the QoS level for
communications to the MQTT server.
• On the other side, the client subscriber sets the QoS
level through the subscription with the MQTT server.
• As illustrated in Figure 6-13, in most cases, QoS
remains the same between clients and broker end to end.
• However, you should be aware that in some scenarios, QoS
levels change and are not the same end to end.
• In summary, MQTT is different from the “one-to-
one” CoAP model in its “many-to-many”
subscription framework, which can make it a better
option for some deployments.
• MQTT is TCP-based, and it ensures an ordered and
lossless connection.
• It has a low overhead when optionally paired with
UDP and flexible message format, supports TLS for
security, and provides for three levels of QoS.
• This makes MQTT a key application layer protocol
for the successful adoption and growth of the Internet
of Things.