IoT Processing Topologies and Types PDF

IoT Processing Topologies and Types Dr. Hazem Jihad Badarneh Internet of Things (1506493) Zarqa University [email protected] IoT Processing Topologies and Types The Internet is a vast space where huge quantities and varieties of data are generated regularly and flo...

IoT Processing Topologies and Types Dr. Hazem Jihad Badarneh Internet of Things (1506493) Zarqa University [email protected] IoT Processing Topologies and Types The Internet is a vast space where huge quantities and varieties of data are generated regularly and flow freely The massive volume of data generated by this huge number of users is further enhanced by the multiple devices utilized by most users. In addition to these data-generating sources, non- human data generation sources such as sensor nodes and automated monitoring systems further add to the data load on the Internet. 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  these data can be broadly grouped into two types Structured data These are typically text data that have a pre-defined structure. 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. Established languages such as Structured Query Language (SQL) are used for accessing these data in RDBMS 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. 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 It is important to decide—when to process and what to process? Before deciding upon the processing to pursue, we first divide the data to be processed into three types based on the urgency of processing: 1) Very time critical, 2) time critical, and 3) normal.  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. Data from sources that can tolerate normal processing latency are deemed as timecritical 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. 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  Considering the requirements of data processing, the processing requirements of data from very time-critical sources are exceptionally high. Here, the need for processing the data in place or almost nearer to the source is crucial in achieving the deployment success of such domains. Similarly, considering the requirements of processing from category 2 data sources (time-critical), the processing requirements allow for the transmission of data to be processed to remote locations/processors such as clouds or through collaborative processing. Finally, the last category of data sources (normal) typically have no particular time requirements for processing urgently and are pursued leisurely as such Processing Topologies we can divide the various processing solutions into two large topologies: 1) On-site and 2) Off-site. The off-site processing topology can be further divided into the following: 1) Remote processing and 2) Collaborative processing. On-site processing As evident from the name, 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. 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. These additionally show rapid temporal changes that can be missed (leading to catastrophic damages) unless the processing infrastructure is fast and robust enough to handle such data. 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). And cheaper. This difference in cost is mainly due to the low demands and requirements of processing at the source itself. In the off-site processing topology, the sensor node is responsible for the collection and framing of data that is eventually to be ‫ئ‬. Unlike the on-site processing topology, the off-site topology has a few dedicated high-processing enabled devices, which can be borrowed by multiple simpler sensor nodes to accomplish their tasks. In the off-site topology, 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.  Figure 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 (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 processing topology typically finds use in scena, especially systems lacking a backbone network. Additionally, this topology can be quite economical for large-scale deployments spread over vast areas, where providing networked access to a remote infrastructure is not viable. In such scenarios, the simplest solution is to club together the processing power of nearby processing nodes and collaboratively process the data in the vicinity of the data source itself. This approach also reduces latencies due to the transfer of data over the network. Additionally, it conserves bandwidth of the network, especially ones connecting to the Internet.  ‫يوضح الشكل طوبولوجيا المعالجة التعاونية للمعالجة التعاونية للبيانات محليا‬. 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). One important point to mention about this topology is the preference of mesh networks for easy implementation of this topology.  The main consideration of minutely defining an IoT solution is the selection of the processor for developing the sensing solution (i.e., the sensor node). This selection is governed by many parameters that affect the usability, design, and affordability of the designed IoT sensing and processing solution. we mainly focus on the deciding factors for selecting a processor for the design of a sensor node. The main factor governing the IoT device design and selection for various applications is the processor. However, the other important considerations are as follows. 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. 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. 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.  Memory: The memory requirements (both volatile and non-volatile memory) of IoT devices determines the capabilities the device can be armed with. 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. 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. Newe processors have a meager I/O voltage rating of 3.3 V, as compared to 5 V for the somewhat older processors. 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. Processing Offloading The processing offloading paradigm is important for the development of densely deployable, energy-conserving, miniaturized, and cheap IoT-based solutions for sensing tasks. Building upon the basics of the off-site processing topology covered in the previous sections, Figure shows the typical outline of an IoT deployment with the various layers of processing from as near as sensing the environment to as far as cloud-based infrastructure. Starting from the primary layer of sensing, we can have multiple sensing types tasked with detecting an environment (fire, surveillance, and others). The sensors enabling these sensing types are integrated with a processor using wired or wireless connections (mostly, wired). In the event that certain applications require immediate processing of the sensed data, an on-site processing topology is followed, similar to the one in Figure. However, for the majority of IoT applications, the bulk of the processing is carried out remotely in order to keep the on-site devices simple, small, and  Typically, for off-site processing, data from the sensing layer can be forwarded to the fog or cloud or can be contained within the edge layer The edge layer makes use of devices within the local network to process data that which is similar to the collaborative processing topology The devices within the local network, till the fog, generally communicate using short-range wireless connections. In case the data needs to be sent further up the chain to the cloud, long- range wireless connection enabling access to a backbone network is essential. Fog-based processing is still considered local because the fog nodes are typically localized within a geographic area and serve the IoT nodes within a much smaller coverage area as compared to the cloud. Fog nodes, which are at the level of gateways, may or may not be accessed by the IoT devices through the Internet.  Finally, the approach of forwarding data to a cloud or a remote server, as shown in the topology, requires the devices to be connected to the Internet through long-range wireless/wired networks, which eventually connect to a backbone network. This approach is generally costly concerning network bandwidth, latency, as well as the complexity of the devices and the network infrastructure involved. This section on data offloading is divided into three parts: 1) offload location (which outlines where all the processing can be offloaded in the IoT architecture), 2) offload decision making (how to choose where to offload the processing to and by how much), and finally 3) offloading considerations (deciding when to offload).  Offload location The choice of offload location decides the applicability, cost, and sustainability of the IoT application and deployment. We distinguish the offload location into four types: 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 protect 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. A cloud is supply for processing offloading so that processing resources can be rapidly supplied with minimal effort over the Internet, which can be accessed globally. Cloud enables massive scalability of solutions as they can enable resource enhancement allocated to a user or solution in an on-demand manner, without the user having to go through the pains of acquiring and configuring new and costly hardware. Computation Offloading in IOT