Scribd
Upload
467 views

Application Protocol Not Present

This document discusses various methods for transporting IoT application protocols across networks. It describes four categories of IoT application protocols: those without an application layer protocol, supervisory control and data acquisition (SCADA) protocols, generic web-based protocols, and IoT-specific application layer protocols. It focuses on protocols without an application layer and SCADA protocols. For the former, an IoT data broker is recommended to standardize sensor output for different applications. SCADA protocols were originally developed for serial links but have been adapted to run over IP networks.

Uploaded by

PlayIt All
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
467 views

Application Protocol Not Present

This document discusses various methods for transporting IoT application protocols across networks. It describes four categories of IoT application protocols: those without an application layer protocol, supervisory control and data acquisition (SCADA) protocols, generic web-based protocols, and IoT-specific application layer protocols. It focuses on protocols without an application layer and SCADA protocols. For the former, an IoT data broker is recommended to standardize sensor output for different applications. SCADA protocols were originally developed for serial links but have been adapted to run over IP networks.

Uploaded by

PlayIt All
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

In

summary, TCP and UDP are the two main choices at the transport layer for
the TCP/IP protocol. The performance and scalability of IoT constrained
devices and networks is impacted by which one of these is selected.

IoT Application Transport Methods


Because of the diverse types of IoT application protocols, there are various
means for transporting these protocols across a network. Sometimes you may
be dealing with legacy utility and industrial IoT protocols that have certain
requirements, while other times you might need to consider the transport
requirements of more modern application layer protocols. 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:
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 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.
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 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 well-known examples of
IoT application layer protocols.

Application Layer Protocol Not Present


As introduced in Chapter 4, IETF RFC 7228 devices defined as class 0 send
or receive only a few bytes of data. For myriad 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. (LPWA and
LoRaWAN are discussed in Chapter 4.) 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. Example 6-1 shows the raw data for temperature and relative
humidity and how it can be decoded by the application.
Example 6-1 Decoding Temperature and Relative Humidity Sensor Data
Click here to view code image

Temperature data payload over the network: Tx = 0x090c


Temperature conversion required by the application
T = Tx/32 - 50 to T = 0x090c/32 - 50 to T = 2316/32 - 50 =
22.4°
RH data payload over the network: RHx = 0x062e
RH conversion required by the application:
100RH = RHx/16-24 to 100RH = 0x062e/16-24 = 74.9 to RH = 74.9%

While many constrained devices, such as sensors and actuators, have adopted
deployments that have no application layer, this transportation method has not
been standardized. This lack of standardization makes it difficult for generic
implementations of this transport method to be successful from an
interoperability perspective.
Imagine expanding Example 6-1 to different kinds of temperature sensors
from different manufacturers. These sensors will report temperature data in
varying formats. A temperature value will always be present in the data
transmitted by each sensor, but decoding this data will be vendor specific. If
you scale this scenario out across hundreds or thousands of sensors, the
problem of allowing various applications to receive and interpret temperature
values delivered in different formats becomes increasingly complex. The
solution to this problem is to use an IoT data broker, as detailed in Figure 6-1.
An IoT data broker is a piece of middleware that standardizes sensor output
into a common format that can then be retrieved by authorized applications.
(The concept of the IoT data broker is introduced in Chapter 1, “What Is
IoT?”)
Figure 6-1 IoT Data Broker
In Figure 6-1, Sensors X, Y, and Z are all temperature sensors, but their
output is encoded differently. The IoT data broker understands the different
formats in which the temperature is encoded and is therefore able to decode
this data into a common, standardized format. Applications A, B, and C in
Figure 6-1 can access this temperature data without having to deal with
decoding multiple temperature data formats.
You should note that IoT data brokers are also utilized from a commercial
perspective to distribute and sell IoT data to third parties. Companies can
provide access to their data broker from another company’s application for a
fee. This makes an IoT data broker a possible revenue stream, depending on
the value of the data it contains.
In summary, while directly transporting data payload without a structured
network stack clearly optimizes data transmission over low-data-rate
networks, the lack of a data model implies 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 so on, and often calls for
structured data models and data broker applications.

SCADA
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.

A Little Background on SCADA


For many years, vertical industries have developed communication protocols
that fit their specific requirements. Many of them were defined and
implemented when the most common networking technologies were serial
link-based, such as RS-232 and RS-485. This led to SCADA networking
protocols, which were well structured compared to the protocols described in
the previous section, running directly over serial physical and data link layers.
At a high level, SCADA systems collect sensor data and telemetry from
remote devices, while also providing the ability to control them. Used in
today’s networks, SCADA systems allow global, real-time, data-driven
decisions to be made about how to improve business processes.
SCADA networks can be found across various industries, but you find
SCADA mainly concentrated in the utilities and manufacturing/industrial
verticals. Within these specific industries, SCADA commonly uses certain
protocols for communications between devices and applications. For
example, Modbus and its variants are industrial protocols used to monitor and
program remote devices via a master/slave relationship. Modbus is also found
in building management, transportation, and energy applications. The DNP3
and International Electrotechnical Commission (IEC) 60870-5-101 protocols
are found mainly in the utilities industry, along with DLMS/COSEM and
ANSI C12 for advanced meter reading (AMR). Both DNP3 and IEC 60870-5-
101 are discussed in more detail later in this chapter.
As mentioned previously, these protocols go back decades and are serial
based. So, transporting them over current IoT and traditional networks
requires that certain accommodations be made from both protocol and

You might also like