IoT Processing Topologies and Types

Data : This huge data volume is composed of a variety of data such as

e-mails, text documents (Word docs, PDFs, and others), social media
posts, videos, audio files, and images.
Data Types
Structured Data
These are typically text data that have a pre-defined structure [1]. Structured data
are associated with relational database management systems (RDBMS). These are
primarily created by using length-limited data fields such as phone numbers, social
security numbers, and other such information.
Even if the data is human or machine generated, these data are easily searchable
by querying algorithms as well as human generated queries.
Common usage of this type of data is associated with flight or train reservation
systems, banking systems, inventory controls, and other similar systems.
Established languages such as Structured Query Language (SQL) are used
for accessing these data in RDBMS. However, in the context of IoT, structured data
holds a minor share of the total generated data over the Internet.
Unstructured Data
• In simple words, all the data on the Internet, which is not structured,
is categorized as unstructured. These data types have no pre-defined
structure and can vary according to applications and data-generating
sources.

• Some of the common examples of human-generated unstructured

data include text, e-mails, videos, images, phone recordings, chats,
and others
Some common examples of machine-generated unstructured data
include sensor data from traffic, buildings, industries, satellite imagery,
surveillance videos, and others.

As already evident from its examples, this data type does not have fixed
formats associated with it, which makes it very difficult for querying
algorithms to perform a look-up. Querying languages such as NoSQL
are generally used for this data type.
Importance of Processing in IoT

The vast amount and types of data flowing through the Internet
necessitate the need for intelligent and resourceful processing
techniques.
This necessity has become even more crucial with the rapid
advancements in IoT, which is laying enormous pressure on the existing
network infrastructure globally.

when to process and what to process?

Divide the Data
1) Very time critical
2) Time critical
3) normal
Very time critical

Data from sources such as flight control systems, healthcare, and other
such sources, which need immediate decision support, are deemed as
very critical. These data have a very low threshold of processing
latency, typically in the range of a few milliseconds.
Time critical

Data from sources that can tolerate normal processing latency are
deemed as time critical data. These data, generally associated with
sources such as vehicles, traffic, machine systems, smart home
systems, surveillance systems, and others, which can tolerate a latency
of a few seconds fall in this category.
Normal

Finally, the last category of data, normal data, can tolerate a processing
latency of a few minutes to a few hours and are typically associated
with less data-sensitive domains such as agriculture, environmental
monitoring, and others.
Processing Topologies

1) On – Site Processing
2) Off – Site Processing
a) Remote Processing
b) Collaborative Processing
On – Site Processing
On – Site Processing
The on-site processing topology signifies that the data is processed at
the source itself.
This is crucial in applications that have a very low tolerance for
latencies(delay).

These latencies may result from the processing hardware or the

network (during transmission of the data for processing away from the
processor).
Applications such as those associated with healthcare and flight control
systems (realtime systems) have a breakneck data generation rate.
Off-site processing
The off-site processing paradigm, as opposed to the on-site processing
paradigms,allows for latencies (due to processing or network latencies);
it is significantly cheaper than on-site processing topologies.

This difference in cost is mainly due to the low demands and

requirements of processing at the source itself.

Often, the sensor nodes are not required to process data on an urgent
basis.
In the off-site processing topology, the sensor node is responsible for
the collection and framing of data that is eventually to be transmitted
to another location for processing.

the data from these sensor nodes (data generating sources) is

transmitted either to a remote location (which can either be a server or
a cloud) or to multiple processing nodes. Multiple nodes can come
together to share their processing power in order to collaboratively
process the data (which is important in case a feasible communication
pathway or connection to a remote location cannot be established by a
single node)
Remote Processing
This is one of the most common processing topologies prevalent in
present-day IoT solutions. It encompasses sensing of data by various
sensor nodes; the data is then forwarded to a remote server or a cloud-
based infrastructure for further processing and analytics.

The processing of data from hundreds and thousands of sensor nodes

can be simultaneously offloaded to a single, powerful computing
platform; this results in massive cost and energy savings by enabling
the reuse and reallocation of the same processing resource while also
enabling the deployment of smaller and simpler processing nodes at
the site of deployment.
• This setup also ensures massive scalability of solutions, without
significantly affecting the cost of the deployment.

• where the sensing of an event is performed locally, and the decision

making is outsourced to a remote processor (here,cloud). However,
this paradigm tends to use up a lot of network bandwidth and relies
heavily on the presence of network connectivity between the sensor
nodes and the remote processing infrastructure.
Collaborative processing
• This approach also reduces latencies due to the transfer of data over
the network.
collaborative processing topology for collaboratively processing data
locally.

• This topology can be quite beneficial for applications such as

agriculture, where an intense and temporally high frequency of data
processing is not required as agricultural data is generally logged after
significantly long intervals (in the range of hours).
IoT Device Design and Selection
Considerations
• we mainly focus on the deciding factors for selecting a processor for
the design of a sensor node.
• Size
• Energy
• Cost
• Memory
• Processing Power
• I/O Rating
• Add -Ons
• Size : This is one of the crucial factors for deciding the form factor and
the energy consumption of a sensor node It has been observed that
larger the form factor, larger is the energy consumption of the
hardware.

• Additionally, large form factors are not suitable for a significant bulk
of IoT applications, which rely on minimal form factor solutions (e.g.,
wearables).
Energy: The energy requirements of a processor is the most important
deciding factor in designing IoT-based sensing solutions. Higher the
energy requirements, higher is the energy source (battery)
replacement frequency. This principle automatically lowers the long-
term sustainability of sensing hardware, especially for IoT-based
applications.
• Cost: The cost of a processor, besides the cost of sensors, is the
driving force in deciding the density of deployment of sensor nodes
for IoT-based solutions.
• Cheaper cost of the hardware enables a much higher density of
hardware deployment by users of an IoT solution.

• For example, cheaper gas and fire detection solutions would enable
users to include much more sensing hardware for a lesser cost.
• Memory: The memory requirements (both volatile and non-volatile
memory) of IoT devices determines the capabilities the device can be
armed with. Features such as local data processing, data storage, data
filtering, data formatting, and a host of other features rely heavily on
the memory capabilities of devices.
• However, devices with higher memory tend to be costlier for obvious
reasons.
• Processing power: As covered in earlier sections, processing power is
vital (comparable to memory) in deciding what type of sensors can be
accommodated with the IoT device/node, and what processing
features can integrate on-site with the IoT device.
• The processing power also decides the type of applications the device
can be associated with. Typically, applications that handle video and
image data require IoT devices with higher processing power as
compared to applications requiring simple sensing of the
environment.
• I/O rating: The input–output (I/O) rating of IoT device, primarily the
processor, is the deciding factor in determining the circuit complexity,
energy usage, and requirements for support of various sensing
solutions and sensor types.
• Newer processors have a I/O voltage rating of 3.3 V, as compared to 5
V for the somewhat older processors. This translates to requiring
additional voltage and logic conversion circuitry to interface legacy
technologies and sensors with the newer processors.
• Despite low power consumption due to reduced I/O voltage levels,
this additional voltage and circuitry not only affects the complexity of
the circuits but also affects the costs.
• Add-ons: The support of various add-ons a processor or for that
matter, an IoT device provides, such as analog to digital conversion
(ADC) units, in-built clock circuits, connections to USB and ethernet,
inbuilt wireless access capabilities, and others helps in defining the
robustness and usability of a processor or IoT device in various
application scenarios.
• Additionally, the provision for these add-ons also decides how fast a
solution can be developed, especially the hardware part of the whole
IoT application. As interfacing and integration of systems at the circuit
level can be daunting to the uninitiated, the prior presence of these
options with the processor makes the processor or device highly
lucrative to the users/developers.
Offload Location
which outlines where all the processing can be offloaded in the IoT
architecture

Edge
Fog
Remote server
Cloud
Processing Offloading
Edge: Offloading processing to the edge implies that the data
processing is facilitated to a location at or near the source of data
generation itself.

Offloading to the edge is done to achieve aggregation, manipulation,

bandwidth reduction,and other data operations directly on an IoT
device.
Fog: Fog computing is a decentralized computing infrastructure that is
utilized to conserve network bandwidth, reduce latencies, restrict the
amount of data unnecessarily flowing through the Internet, and enable
rapid mobility support for IoT devices.

The data, computing, storage and applications are shifted to a place

between the data source and the cloud resulting in significantly
reduced latencies and network bandwidth usage.
Remote Server: A simple remote server with good processing power
may be used with IoT-based applications to offload the processing from
resource constrained IoT devices. Rapid scalability may be an issue with
remote servers, and they may be costlier and hard to maintain in
comparison to solutions such as the cloud.

Cloud: Cloud computing is a configurable computer system, which can

get access to configurable resources, platforms, and high-level services
through a shared pool hosted remotely.
Offload decision making
how to choose where to offload the processing to and by how much

• Naïve Approach
• Bargaining based approach
• Learning based approach
• Naïve Approach : It can be considered as a rule-based approach in
which the data from IoT devices are offloaded to the nearest location
based on the achievement of certain offload criteria.

• Bargaining based approach : This approach, although a bit processing-

intensive during the decision making stages, enables the alleviation of
network traffic congestion, enhances service QoS (quality of service)
parameters such as bandwidth, latencies, and others.
Learning Based Approach : Unlike the bargaining based approaches, the
learning based approaches generally rely on past behavior and trends
of data flow through the IoT architecture.

• The memory requirements and processing requirements are high

during the decision making stages. The most common example of a
learning based approach is machine learning.
Offloading Considerations
deciding when to offload

• Bandwidth
• Latency
• Criticality
• Resources
• Data Volume
• Bandwidth: The maximum amount of data that can be
simultaneously transmitted over the network between two points is
the bandwidth of that network. The bandwidth of a wired or wireless
network is also considered to be its data-carrying capacity and often
used to describe the data rate of that network.
• Latency: It is the time delay incurred between the start and
completion of an operation. In the present context, latency can be
due to the network (network latency) or the processor (processing
latency).

• In either case, latency arises due to the physical limitations of the

infrastructure, which is associated with an operation. The operation
can be data transfer over a network or processing of a data at a
processor.
Criticality: It defines the importance of a task being pursued by an IoT
application. The more critical a task is, the lesser latency is expected
from the IoT solution.

For example, detection of fires using an IoT solution has higher

criticality than detection of agricultural field parameters.
• Resources: It signifies the actual capabilities of an offload location.
These capabilities may be the processing power, the suite of analytical
algorithms, and others. For example, it is futile and wasteful to
allocate processing resources reserved for real-time multimedia
processing.

• Data volume: The amount of data generated by a source or sources

that can be simultaneously handled by the offload location is referred
to as its data volume handling capacity. Typically, for large and dense
IoT deployments, the offload location should be robust enough to
address the processing issues related to massive data volumes.