SFoG-RPI: A Secured QoS Aware and Load Balancing Framework for FoG Computing in Healthcare Paradigm

The Internet of Things (IoT) paradigm has been increasingly adopted in recent years, finding applications in diverse fields such as healthcare, smart agriculture, industrial automation, and the conception of smart cities. Traditional IoT applications directly oversee the operations of these systems, which include data collection, event detection, analysis, and actuation [1]. However, cloud data centers, which are predominantly used in these applications, are often situated several hops away from the IoT-enabled applications, posing certain challenges. Edge and Fog models have been introduced to address this issue by bringing computational capabilities closer to the applications [2]. As a result, the responsiveness of applications and the time taken for service delivery are substantially improved. Additionally, these models aid in mitigating network congestion by preventing the transfer of large data quantities to cloud data centers. In this context, the present study sets out to further explore the potential of Edge and Fog models in enhancing the efficiency and effectiveness of IoT applications across various domains.

IoT is a platform to connect many things to the internet, and these things should be integrated with both electronics software and sensors, which generates and exchange data across things. IoT allows humans to contribute, interact and collaborate with the things around us. IoT utilizes the resources efficiently which are available, resources may be in terms of inputs, monetization, etc. The time-sensitive data must be processed and analyzed very quickly and hence it should have happened very near to the devices. Time in-sensitive data will be analyzed in the cloud [3]. It reduces human efforts and time and this is why the Internet of Things has become more popular and also its ever-growing technology. IoT has certain features: connect the things to the platform, collect and analyze data for business, and integrate all the models for an improved experience. IoT Architecture consists of five layers namely: Perception, transport, processing, application, and business layer [4].

Each layer is intended to perform its assigned task, the perception layer obtains data about the atmosphere and sends it to the transport layer, in turn forwards data to the different layers using a network such as BLE, Zigbee, 6LowPan, Wi-Fi, etc. Processing layer stores, processes and analyzes the sensor data and also employs cloud, fog, and big data analytics modules to accomplish the task. Next, we have application layers that are responsible for delivering the application-specific services to the end-users. Finally, the business layer which accomplishes the complete IoT organization such as applications, business models, user’s privacy, etc.

Cloud computing is already well-known due to its extensive adoption in its target market. During the early phases of its adoption, though, it encountered various challenges like security, privacy, attacks, latency, and bandwidth. As a result, the cloud computing paradigm's primary challenges are privacy and security.

The IoT technology incorporates a fog computing paradigm towards processing power and computing close to the things that are connected. Cloud computing is the method of storing, managing, and processing data on a remote computer contained on the Internet rather a native server or a local system. Fog computing also called edge computing supports computation, storage, and networking capabilities be communal between cloud computing data centers and end devices.

Both fog and cloud deliver identical resources comprising computation, memory, storage, and infrastructure, yet they complement one another [5, 6]. As a result, the fog has evolved into a middleware capable of responding quickly and avoiding redundant data to be sent to the network and other healthcare IoTs, and ensuring that healthcare services have the necessary privacy protections. Their geographical position is a significant distinction. In contrast to the cloud, it offers more general functions and also fog is close to the IoT nodes. These devices will produce big quantities of raw data (for example, from sensors), and rather than sending all of this data to cloud-based servers to be managed, the idea behindhand fog computing is to do most of the processing work as possible by the computing units located near the data-generating devices, which results in processed data will be forwarded to the cloud rather than raw data being forwarded and due to this cause bandwidth requirement being greatly reduced. Another advantage is that the processed data may be required by the same devices that created it, which reduces the latency between input and response time by processing locally rather than remotely.

FoG architecture implemented in IoT gateway consists of security, storage, pre-processing, and monitoring layer deployed between physical and transport layer. The underlying nodes send raw and unstructured data to the fog. The monitoring layer then takes care of the data that has been received. Following that, the data is directed to the preprocessing layer, which structures the unstructured data using various data filtering and transformation techniques. At the middleware level, data storage necessitates privacy and security protections. Such duties are handled by the local storage layer. At this layer, lightweight security procedures and data integrity measures must be implemented. The temporary storage layer then stores the data for a set length of time.

As a result, data is not stored for an extended amount of time. If the data is sensitive, it is eventually securely transported to the cloud. Cloud computing can store data for prolonged periods and conduct computation-intensive activities. Fog device security and privacy is a critical concern that should be considered in Fog devices. We offer a simple, yet general, paradigm for deploying QoS-aware IoT applications on Fog infrastructures in the healthcare domain.

The QoS metrics we consider in our systems are latency, bandwidth, loss, and jitter. The QoS profiles Q are made up of the set of pairs (li,bi,ji,loi) where li,bi,ji,loi signify the average latency, bandwidth, jitter, and loss of a communication channel, respectively. The bandwidth of a link is represented by a pair (bupward, bdownward), which distinguishes the download and upload bandwidth, and π will be used to represent latency or bandwidth metrics that are unknown or unspecified.

Congestion on the network and route changes are the reason for jitter. Acceptable jitter is the smallest delay in the transmission that we are ready to allow. Milliseconds are used to measure jitter (ms). A delay of 30 milliseconds or longer might cause call distortion and disruption. Opted to prioritize packets over other types of traffic using the quality of service (QoS) setting on our router. If the jitter is caused by traffic congestion, prioritizing packets may be beneficial. Using a jitter buffer is one of the most effective techniques to reduce internet jitter. On a VoIP system, a jitter buffer is a useful component. They work by delaying and storing voice packets as they arrive. Before delivering traffic to the receiver, they buffer it for 30 to 200 milliseconds.

This procedure ensures that data packets arrive in the correct order and with little delay. They can also reorder data packets according to when they were transmitted in some cases, depending on the buffer. When sending data over the internet, there is always the possibility that packets of data will be lost or damaged. To guarantee easier and faster transfers, the packets are frequently encrypted and decreased in size. Your communication will be delayed and sometimes garbled if these packets are missing during transit. Prioritizing traffic to guarantee that the maximum critical data is sent over the network first would improve data flow and reduce congestion.

In our proposed work we have implemented Raspberry Pi as the fog node since it has a processor, memory, storage, and display devices and also it is less costly. It also has an input and output port that can be easily connected to sensors and actuators very easily. Raspberry Pis is typically equipped with moderately fast processors that facilitate peripheral interface and networking. However, the Raspberry Pi is limited in its ability to support multi-tenancy and resource sharing. Hence, we need to perform virtualization of RPis but it does not allow us to do hypervisor-based virtualization, in this case, containerization of RPis will be the best possible solution.

The privacy and security issues surrounding the capture and transfer of healthcare data first. Then, to address security problems similar to those raised above, a secure data gathering technique for IoT-based healthcare systems.

3.1 Fog architecture

Fog architecture consists of fog nodes, IoT devices, and Cloud nodes and it can be denoted as a tuple (F, I, C), where F is a group of fog nodes, and each node will be represented as f(i=1, 2, 3...n)=(€, π, µ), where € denotes the location of fog node, π refer to software and hardware specification of the fog node, µ refers to the IoT devices directly connects with this fog node. I is a collection of Things, each of which is represented by the tuple I(i=1, 2, 3...n)= (t, €) t identifies its type and € is the location of the device. C is a collection of existing Cloud data centers, all of which is identified by the tuple f(i=1, 2, 3...n)=(€, π), where € defines its location and π software and hardware specification of the cloud data centers µ in I are directly connected to the fog node, hence it has negligible latency and sufficient bandwidth. Cloud nodes connect with sensors and actuators using some API’s which supports QoS metrics.

A Fog computing infrastructure application can be assumed as a collection of autonomously deployable components that must work composed while meeting particular QoS requirements. An application is represented as a triple [£, β, µ], £ where is a group of software components, β denotes existing interactions among components in, µ and is a group of Internet of Things requests. Fog architecture is represented as (F, I, C). Figure 1 illustrates the Fog-Cloud infrastructure, in which three fog nodes and two data centers have been deployed. It also depicts the average latency and bandwidth of each link.

1.png

Figure 1. FoG-cloud communication systems

3.2 Collaboration between FoG nodes using choreography

One fog node wouldn’t be sufficient for some sophisticated queries. However, due to latency or other difficulties, forwarding multiple requests to the cloud may not be a practical answer. In this circumstance, fog resource centers that are co-located with the primary fog can be merged with the primary fog to enable the inter-fog scenario. It will be difficult to combine numerous fogs in cost-effective collaborative-fog scenarios that meet service level agreements (SLAs) and are resource-efficient. Using choreography concept inter-fog communication could be established, it allows the fog to exchange the information.

3.3 Higher level organization of SFog-RPis framework

Integrated IoT-Fog-Cloud environment using a high-level detail of SFog-RPIs is shown in Figure 2. The SFog-RPIs framework is made up of many different components, the items that follow: IoT devices, Fog Gateways, Fog Agent, Fog Computing Nodes, Fog Database, and Cloud Datacenters.

2.png

Figure 2. Inter-fog collaboration using choreography

Sensors and devices will use different protocols depending on the kind of facility, data transfer rate as well as technology used, and as an outcome, certain of them might not be capable to pad right into another software interface. Interoperability becomes a huge challenge when there are so several devices and sensors made by so many different developers working together. Protocol conversion, channeling, and other similar events will be required in the fog in this instance. In these situations, fog must be delivered using conventional techniques to enable seamless integration and interoperability.

This software component supports the collecting of generated data for every sensor node linked to the host RPi through API. It can begin sending data to the microservice as quickly as the container is launched, or it can pause till the microservice acts together. The associated sensors have two modes of operation: pull and push. Microservices receive sensor data from Sensor Manager only in the pull mode, in the push mode, Sensor Manager provides collected data to the Services autonomously.

3.4 FoG computing node and agent node

Fog Gateway Nodes filter data and convert it into standardized style. They are forwarded to another computer instances in the integrated environment by FGNs. It gives customers the ability to set login credentials, get service responses, control IoT devices, and request resources using application user interfaces. In addition to the standard functions of collecting and transferring data, Fogas-assisted smart gateways offer a variety of sophisticated services aimed at improving the quality of healthcare. Distributed local storage, data compression, and other Fog services.

If the Fog Computing Node is unable to meet the application's requirements on its own, it acts as an agent node, contacting other Fog Computing Node and Cloud data centers on behalf of the Fog Gateway Nodes to obtain the resources needed to run the back-end application. It distributes computing workloads over several Fog Computing Nodes and monitors, synchronizes, and coordinates their actions in this situation. Concerning capacity and resource architecture, Fog Computing Nodes are diverse. To undertake various SFog-RPI functions, it consists of processing cores, memory, and storage. It provides suitable security characteristics to such broker nodes, allowing them to assure the stability of communication and data exchange between Fog Nodes and Cloud.

The database nodes keep track of diverse applications' meta-data, such as the application model, runtime needs, and dependencies [18, 19]. Furthermore, during application execution, these nodes can save some intermediate data, allowing data processing to resume from any anomaly-driven stop point.

3.5 Cloud nodes

3.png

Figure 3. Higher level organization of SFog-RPis framework

Cloud servers offer many advantages, including centralized scalability, data protection, global storage, and processing. Heavy computational activities that cannot be handled by Fog could be handled efficiently by Cloud servers. The Figure 3 depicts how the Raspberry Pi integrated with various sensor nodes and external devices and how this does the job of the Fog node. Raspberry Pi can perform collecting data from sensor nodes, integrating collected data from various sensor nodes, process and analyze the data into meaningful information. We have implemented Raspberry Pi as the fog node since it has a processor, memory, storage, and display devices and it is less costly. Since for a real-time health monitoring system, during an emergency, the patients must be treated immediately, hence processing and analyzing the data very close to the sensing node is necessary. In this situation, if the Fog node does not perform this task, then processing must be done at cloud data centers, and responding to the patients in the critical situation takes lots of time which leads to life-critical. Therefore, Raspberry pi implemented in our proposed system acts as the Fog node, which provides immediate response to the patients in an emergency.

SFog-RPi Controller contains conventional algorithms and strategies for managing an RPi's computational resources. It also communicates with the information registry to obtain other RPis' references for resource and data sharing. Information Manager sends commands to RPis Operative to govern the execution of microservices formed on the results of connected algorithms and policies.

RPis Operator component is in charge of container creation and termination. RPis Operator uses APIs to inject essential arguments into containers, such as location of the microservice and the unique identifier of the RPi hosting the RPi Service. It also prevents the Sensor devices from forwarding data for newly dismissed containers and keeps informed the Information Registry's executor.

The context information extracted from the host RPis includes resource configuration, network bandwidth, remaining battery lifetime, storage, and current memory, location, and CPU utilization. Information Monitor provides such information to SFog-RPi Controller and participates in resource management decisions based on Information Manager's requirements.

Periodic Signal Generator: It produces the heartbeat data signals periodically to Information Registry of SFog-RPi Controller to alert the occurrence of the host RPi Periodic Signal Generator additionally notifies the corresponding SFog-RPi Controller of the status of microservice execution to track run-time performance. It aids in the detection of RPis that have suddenly failed. Figure 4 represents the Raspberry Pi integrated with various sensors.

4.png

Figure 4. Raspberry Pi integrated with various sensors

5.png

Figure 5. Setup for SFoG-Rpi

The data is sent to a master node via the sensor node, in turn it is distributed by the master node to the number of worker nodes on which the processing is actually to be carried out. Figure 5 shows the Setup for SFoG-Rpi. Parallelly, a traffic monitor observes the data rate of IoT devices based on which amount of data to be processed will be computed and assigned to the respective computing node. CN does the encryption process using a private key and transfers it to the FoG node for processing.

The strong traffic load reveals that dataflow latency is the primary cause of overall response time. There are two types of latency in data flow on IoT devices: first one is communication latency triggered by traffic load, and another is computing latency induced by computing load. We require a load balancing technique to stabilize together the computing and traffic loads of BSs or fog nodes in a direction to lessen the system's total latency and network use [20].

CN-Computing Node, SN-Sensing Node, MN-Master node, TN-Traffic Node. Let Fi=(f1,f2,f3…fn) be the set of FoG nodes, t(x) be the transmission power of sensor node, c(x) is the channel gain of sensor nodes, an (x) be the arrival rate, s(x) be the traffic size, ci(x) be the capacity of the sensor node, cj(x) is the FoG node computing capacity, y(x) data flow computation size, Clr is the computational latency ratio, CM is the communication latency,TL is the traffic load at the FoG node, CL is the computational load at the FoG node, tr(x) is the traffic load density of sensor node, ld(x) is the computing load density of sensor node.

In Traffic Load and Load Computation, let us assume that, a set of sensor nodes are implanted on the body of the patient and it has the transmission power of t(x) with a gain of c(x), the noise is represented as α2. The signal-to-noise ratio is calculated by:

$\operatorname{STNR}(\mathrm{x})=\frac{t(x) X c(x)}{\alpha 2}$               (1)

where, gain $\mathrm{c}(\mathrm{x})=10 \log 10\left[\frac{\emptyset 2}{(4 \pi D) 2}\right], \varnothing$ is the wavelength and D is the distance between the sensor nodes.

tr(x) is the traffic load density of the sensor node which will be calculated by:

$\operatorname{tr}(\mathrm{x})=\frac{a(x) x s(x)}{\operatorname{ci}(x)}$                   (2)

TL is the traffic load at the FoG node will be calculated by:

$\mathrm{TL}=\sum \operatorname{tr}(\mathrm{x})$             (3)

CM is the communication latency will be calculated by:

$\mathrm{CM}=\frac{T L}{1-T L}$               (4)

FoG node Computing latency is directly relative to the latency of the data flow, let ld(x) is the computing load density of sensor node can be calculated by:

$\mathrm{ld}(\mathrm{x})=\frac{a(x) x y(x) x b j(x)}{c j(x)}$              (5)

where, bj(x) is the binary indicator of the FoG node.

CL-computing load at the FoG node can be calculated by:

$C_L=\sum 1_d(x)$              (6)

C_lr is the computing latency ratio is calculated by:

$C_{1 \mathrm{r}}=\left(1-C_L\right) / C_L$                     (7)

Patients' confidential information, such as disease type, age, surgery is undergone, history, and so on, is stored in healthcare data. Unauthorized users must not have access to any of this information. With the proliferation of technology in different domains related to healthcare, guaranteeing data integrity, privacy, and security leftovers is a concern [21]. Security in storage and transmission are two distinct issues. The level of data access authorization is context-dependent. For instance, the data can be vital to a nurse in one situation, but the authorization must be confined to the doctor in another.

In the event of an emergency, paramedics may be given provisional access to the patient's private data, although, under other circumstances, same admission may be restricted to doctors exclusively. Fog must be conscious of these limits and to ensure the data it obtains/interconnects with other devices and systems is secure and private.

Fog, a middleware, can show a significant part in bringing multiple parties together to provide robust healthcare services. For example, a pharmacy may preserve a patient's medication record to see if the new medicine the patient is purchasing is compatible with the other medications she or he is already taking for the same or different health concerns. In Lightweight Secured Fog-based framework, nowadays all the PHR data will be stored on the cloud server remotely, which causes security-related issues like privacy, security, and access control. Fog computing techniques relieve the computational and communication stress on remote cloud servers and act as a middleware amongst cloud servers and IoT devices. Fog computing mainly focuses on the quality-of-service (QoS) metrics [22]. Most of the healthcare monitoring systems do not support security-related concerns, hence in this work, we are focusing on security issues also. To sort out these issues, the most direct solution is to use encryption and decryption techniques.

Because the sensor nodes are small and have limited resources, they are unable to implement the sophisticated algorithms to handle security issues. Even while sophisticated algorithms may be effectively performed on sensor nodes, it may not be used since the system's latency requirements may be violated and their battery may be drained. Raw data is frequently supplied in many IoT systems to extend the battery life of sensor nodes. Because data can be listened to by unauthorized persons, this strategy is risky [23, 24]. Sensor nodes must run a lightweight security method as well as the battery life of the sensor node cannot be greatly lowered, the algorithm must provide some levels of security.

AES uses symmetric key encryption, which use same secret key to encrypt and decrypt the data [25, 26]. For encrypted data, individual or group of sensor nodes owns its private key, whereas a gateway holds all of the private keys of entire sensor nodes. Sensor nodes deliver encrypted data using a private key, and the encrypted data received at a smart gateway is decrypted using the right private key. The AES-256 algorithm is implemented in our proposed system since it's not easy to tamper with anonymous users.

In digital signature, a public-private key pair is created for each individual who uses this system [27, 28]. The signature key acts as the private key used for digitally signing, while the verification key acts as the public key. Data is fed into the hash function by Signer, which generates a hash value of the data correspondingly. The hash value and signature key are fed into the signature algorithm, which generates a digital signature for the supplied hash. After appending the signature to the data, both are submitted to the verifier. The verification key and digital signature are fed into the verifier for the verification process, then the verification algorithm returns a value as an output.

6.png

Figure 6. Digital signature and encryption/decryption

The Verifier uses the same hash function on the supplied data to generate a hash value. The result of the verification process and this hash value are compared based on the comparison result, the verifier assesses whether the digital signature is genuine or not. Figure 6 discusses the Digital signature and encryption/decryption.

Algorithm 1: Security measures in Fog node

Step 1.Before the encryption and signing procedure must generate the private and public keys

Step 2.Generate the public-private key pair (ki,kj)

Step 3.Feed data (Di) to the hash function and generates the hash value (Hi)

Step 4.Pass (Hi, kj) to the signature algorithm and generates the digital signature (DS)

Step 5.Append the data and signature (Di, DS) using private key (pi) and generates the ciphertext (Ed)

Step 6.ciphertext (Ed) will be sent to the verifier

Step 7.Verifier decrypts the ciphertext (Ed) using private key (pi)

Step 8.After decryption the verifier generates the hash value (Hj) on the supplied data using the hash function

Step 9.Compares the output of the verification algorithm with (Hj) and if both are the same it is accepted or rejected.

Algorithm 2: Key Generation phase in RSA Digital Signature

Initialization PhasePick 2 random prime numbers m and n

Calculate $\mathrm{Z}=\mathrm{mxn}$ and $\alpha=(\mathrm{m}-1)(\mathrm{n}-1)$           (8)

Select some random integer x

Compute d using Euclidean distance algorithm where d lies between 1<d< α such that xd=1mod (α).              (9)

Finally calculate the public key (ki) and the private key (kj)

Calculate y'=Z(y), which ranges from [0 to n-1]            (10)

Calculate s= (y')2mod (n)                      (11)

Computed digital signature of A in Verification Phase

Get the A's public key ki and

Compute s'=sx mod (z)             (12)

If s=s' then the signature is correct and authentic and it is accepted.

Encryption

For every node π in L, pick up a polynomial degree pπ and assign the degree to wπ =rπ -1

For all other nodes π € L do

Assign p π (0) =parent(X)(index(π))                (13)

Select a random wX to describe a polynomial p π

End for

Let W to be group of leaf nodes in L with the verification key Ki

CT= (T, Di= Hj,Dy)               (14)

Generate signature DS

The ciphertext is Ed= (CT, DS)          (15)

Decryption

Do signature verification DS using the private key kj

For every node π do

If π is a leaf node and j € R then

Decrypt (CT, kj, π)              (16)

End if

End for

Data compression is used to reduce network bandwidth usage and increase efficiency [29, 30]. Either Lossless or lossy algorithms can be used for data compression; however, when compared to lossy techniques, the lossless approach appears to be a better fit for our e-health application. We chose to use lossless data compression and LZO (Lempel–Ziv–Oberhumer) because they are the fastest lossless data compression algorithms compared to other lossless data compression algorithms. The first method compresses data collected from nodes at the fog gateway and sends it directly to the remote server [31, 32].

Compression on data acquired from sensor nodes and save it as files; if a packet is nowhere to be found during transmission, the server can demand the file from the gateway. Because the packet is temporarily kept in the gateway, it is simple to resend it. When the server admits the positive transmission, the packet is destroyed [33, 34].

Table 1 describes the data size, compressed data size, Compression time, and Decompression Time for the varying nodes from 1 to 40.

Table 1. LZO algorithm compression results