Module 3
IoT Processing Topologies
&Types
IoT Processing Topologies and Types
Data Format: In an IoT system, a massive volume of data is generated by a huge number
of diversified users. These data can be broadly grouped into TWO types based on how
they can be accessed and stored: *
1. Structured data
2. Unstructured data
1. Structured data: Structured data is highly specific, typically text data, and
is stored in a predefined format. Typical examples are product databases,
contact lists, etc. These are primarily created by using length-limited data
fields such as phone numbers, social security numbers, and other such
information. Common usage of this type of data is associated with flight or
train reservation systems, banking systems, inventory controls, and other
similar systems. Languages such as Structured Query Language (SQL) are
used for accessing these data in database management systems.
2. Unstructured data:
These data types have no pre-defined structure and can vary according to
applications and data-generating sources. Examples are documents,
videos, audio files, posts on social media, and emails. In simple words, all
the data on the internet is categorized as unstructured. Querying
languages such as NoSQL are generally used for this data type.
• Importance of Processing in IoT:*** Data processing is more crucial with the
rapid advancements in IoT. Intelligent and resourceful processing techniques are
required to process vast amounts and types of data flowing through the Internet.
it is also important to decide when to process and what to process. We first divide
the data to be processed into THREE types based on the urgency of processing:
1. Very time-critical data
2. Time critical data
3. Normal data
1. Very time-critical data:
These data have a very low processing latency, typically in the range of a
few milliseconds. Data from sources such as flight control systems,
healthcare, etc need immediate decision support. Processing
requirements are exceptionally high. Processing the data in place or
nearer to the source is crucial.
2. Time-critical data: 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, smart home systems, surveillance systems, and
others, can tolerate a latency of a few seconds. These data are to be processed in
remote locations processors such as clouds.
3. Normal data: These 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. Typically have no particular
time requirements for processing urgently.
Processing Topologies:*** The various processing solutions are divided
into two large topologies:
1. On-site processing topologies
2. Off-site processing topologies: It further divides into
i. Remote processing topologies
ii. Collaborative processing topologies
1. On-site processing topologies:
In this topology, the data is processed at the source itself. It is used in
applications that have a very low tolerance for latencies. These latencies
may result from the processing hardware or the network. Applications such
as healthcare and flight control systems (real-time systems). The
processing infrastructure is fast and robust enough to handle such data
(See figure 6.2)
• Figure 6.2 shows the on-site processing topology, where an event (here,
fire) is detected utilizing a temperature sensor connected to a sensor
node. The sensor node processes the information from the sensed event
and generates an alert. The node additionally has the option of
forwarding the data to a remote infrastructure for further analysis and
storage.
2. Off-site processing:
Here processing is not done at the source point. It allows for latencies and
is significantly cheaper than on-site processing topologies. In this
topology, the sensor node is responsible for the collection and framing of
data to be transmitted to another location for processing. Simpler sensor
node borrows processing from high processing enabled device to
accomplish their task. Multiple nodes can come together to share their
processing power to collaboratively process the data. It is divided into
TWO types
• Remote processing:
It is the most common processing topology used in present-day IoT
solutions. It encompasses sensing data by various sensor nodes; the data is
then forwarded to a remote server or a cloud-based infrastructure for
further processing and analytics. Figure 6.3 shows the outline of one such
paradigm, where the sensing of an event is performed locally, and the
decision-making is outsourced to a remote processor.
Advantages:
• Massive cost and energy savings by enabling the reuse and reallocation of the same
processing resource.
• It ensures the massive scalability of solutions, without significantly affecting the cost
of the deployment.
Drawback:
• It requires a lot of network bandwidth
• Need good network connectivity between the sensor nodes and the remote
• processing infrastructure.
• Collaborative processing:
Here Sensors cooperatively process data from multiple sources to serve a
high-level task. It typically finds use in scenarios with limited or no
network connectivity. Figure 6.4 shows the collaborative processing
topology for collaboratively processing data locally.
Advantages:
• This topology can be quite economical for large-scale deployments spread
over vast areas where remote infrastructure is not viable.
• This approach also reduces latencies due to the transfer of data over the
network.
• It conserves the bandwidth of the network, especially those connecting to
the Internet.
• This topology can be quite beneficial for applications such as agriculture.
Drawback:
• This topology needs costlier mesh networks for implementation.
Collaborative
IoT Device Design and Selection Considerations:*****
The processor is the main factor for IoT device design and selection for various
applications. Other important considerations to design an IoT device are
1. Size
2. Energy
3. Cost
4. Memory
5. Processing power
6. I/O rating
7. Add-ons
1. Size: Size and energy consumption are crucial factors of a sensor node. The larger
the size factor consumes more energy. Additionally, large-size factors are not
suitable for many IoT applications.
2. Energy: Energy efficient processor is the most important factor in designing IoT-
based sensing solutions. The higher the energy requirements, the higher the battery
replacement frequency. This principle is not a good option for IoT-based
applications.
3. Cost: Cheaper cost of the hardware enables a much higher density of hardware
deployment. For example, cheaper gas and fire detection solutions would enable
users to include much more sensing hardware for a lesser cost.
4. Memory: devices with higher memory tend to be costlier. But 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.
5. Processing power: In deciding what type of sensors can be accommodated
with the IoT device/node, and what processing features can integrate on-site.
The processing power also decides the type of applications the device can be
associated with. For example, if the application involves video or audio needs
more processing power than other simple sensing IoT applications.
6. Input /output (I/O) rating: 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.
Some processors have a meager I/O voltage rating of 3.3 V, as compared
to 5 V for somewhat older processors. This needs additional voltage and
logic conversion circuitry and increases the cost and complexity of the
node.
7. Add-ons:
IoT device provides, such analog to digital conversion (ADC) units,
connections to USB and ethernet, and inbuilt wireless access capabilities
for various IoT applications. These add-ons also decide how fast a
solution can be developed others helps in defining the robustness and
usability of a processor or IoT devicein various application scenarios.
Processing
Offloading:
• The processing procedure is as follows:
• For off-site processing, data from the sensing layer can be forwarded to the fog or
cloud or contained within the edge layer.
• The edge layer makes use of devices within the local network to process data that
is similar to the collaborative processing topology as shown in fig 6.4
• Fog nodes are localized within a geographic area and serve the IoT node within a
small coverage area.
• Forwarding data to a cloud or a remote server requires the device to be
connected to the internet.
Data offloading is divided into THREE parts:
1. Offload location:
( where all the processing can be offloaded in the IoT architecture)
2. Offload decision:
(How to choose where to offload the processing to and by how much)
3. Offloading considerations:
(Deciding when to offload)
1. Offload location:
The choice of offload location decides the applicability, cost, and
sustainability of the IoT application and deployment. The offload location
into FOUR types:
(a) Edge
(b) Fog
(c) Remote server
(d) Cloud
i. 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.
ii. Fog: Fog computing is a decentralized computing infrastructure. 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.
iii. 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.
iv. Cloud: A cloud is provisioned for processing offloading so that processing resources
can be rapidly provisioned with minimal effort over the Internet, which can be accessed
2. Offload decision making:
The choice of where to offload and how much to offload is addressed
considering data generation rate, network bandwidth, the criticality of
applications, processing resource available at the offload site, and other
factors. Main three approaches are as follows.
a) Naive Approach
b) Bargaining-based approach
c) Learning-based approach
a. Naive Approach: This rule-based approach, in which the data from IoT devices are
offloaded to the nearest location based on the achievement of certain offload criteria.
Statistical measures are consulted for generating the rules.
b. Bargaining-based approach: To maximize the quality of service(bandwidth, latencies)
by reaching a point where the qualities of certain parameters are reduced, while the
others are enhanced. QoS is achieved collaboratively for better full implementation.
c. Learning-based approach: It relies on past behavior and trends of data flow through
the IoT architecture. The optimization of QoS parameters is done by learning from
historical trends and trying to optimize previous solutions further and enhance the
collective behavior of the IoT implementation.
3. Offloading considerations:*** offloading parameters need to be
considered while deciding upon the offloading type to choose arising from
the nature of the IoT application and the hardware being used to interact
with the application. These parameters are as follows.
• Bandwidth
• Latency
• Criticality
• Resources
• Data volume
• Bandwidth: The maximum amount of data that can be simultaneously transmitted over
the network between two points. 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 between the start and completion of an operation, which is
due to physical limitations of the infrastructure in the network or the processor which is
associated with an operation.
• Criticality: It defines importance of a task being pursued by an IoT application. The more
critical a task is, the lesser latency is expected. For example, detection of fires using an
IoT solution has higher criticality than detection of agricultural field parameters.
Resources: It signifies the actual capabilities(like processing power, the
analytical algorithm, etc) of an offload location.
Data volume: The amount of data generated by a source or sources that can
be simultaneously handled by the offload location. Typically, for large and
dense IoT deployments, the offload location should be robust enough to
address the processing issues related to massive data volumes.