A Novel Low-Latency and Energy-Efficient Task Scheduling Framework for Internet of Medical Things in an Edge Fog Cloud System

In healthcare, there are rapid emergency response systems that necessitate real-time actions where speed and efficiency are critical; this may suffer as a result of cloud latency because of the delay caused by the cloud. Therefore, fog computing is utilized in real-time healthcare applications. There are still limitations in response time, latency, and energy consumption. Thus, a proper fog computing architecture and good task scheduling algorithms should be developed to minimize these limitations. In this study, an Energy-Efficient Internet of Medical Things to Fog Interoperability of Task Scheduling (EEIoMT) framework is proposed. This framework schedules tasks in an efficient way by ensuring that critical tasks are executed in the shortest possible time within their deadline while balancing energy consumption when processing other tasks. In our architecture, Electrocardiogram (ECG) sensors are used to monitor heart health at home in a smart city. ECG sensors send the sensed data continuously to the ESP32 microcontroller through Bluetooth (BLE) for analysis. ESP32 is also linked to the fog scheduler via Wi-Fi to send the results data of the analysis (tasks). The appropriate fog node is carefully selected to execute the task by giving each node a special weight, which is formulated on the basis of the expected amount of energy consumed and latency in executing this task and choosing the node with the lowest weight. Simulations were performed in iFogSim2. The simulation outcomes show that the suggested framework has a superior performance in reducing the usage of energy, latency, and network utilization when weighed against CHTM, LBS, and FNPA models.


Introduction
As technology has advanced, applications of the Internet of Things (IoT) have become a part of our everyday lives. As a result, the number of devices employed in these applications will grow, resulting in massive amounts of data being generated. Because the information will be transmitted to the cloud for processing, there will be a delay in response because the cloud is located far away from these devices. Every physical device, such as cameras, automobiles, sensors, wearables, and home appliances, is connected via IoT apps [1]. One of the core branches of IoT is ubiquitous home healthcare, also known as the Internet of Medical Things (IoMT). Recent developments in IoT and the increasing use of wearables 1.
It suggests an Energy-Efficient Internet of Medical Things to Fog Interoperability of Task Scheduling (EEIoMT) Framework for real-time healthcare applications.

2.
It proposes an efficient task scheduling algorithm that increases proficiency and quality of service (QoS) and reduces energy consumption in the system and the latency for healthcare tasks. 3.
The proposed solution deploys IoT services on accessible edge devices to enhance the continuous monitoring of chronic patients, improve their quality of life, and lower The arrangement of this study is organized into the following sections: Section 2 explores the related work on scheduling in fog computing and health monitoring systems. Section 3 presents the research methodology of the EEIoMT framework with the suggested algorithm. Section 4 shows the experimental results' evaluation and a comparison with state-of-the-art methods. Section 5 concludes the study and introduces future work.

Related Work
Most of the related studies that focus on task scheduling in fog computing and healthcare monitoring are examined in this part to highlight the contributions and compare the outcomes with the suggested framework.
Paul et al. [4] introduced a three-layer architecture to monitor patient health using cloud and fog computing. Cloud computing servers, fog computing servers and resources, and sensors such as biomedical health monitoring sensors make up this architecture. The fog tier performs the aggregation and analysis of data that are obtained from edge devices. It then uses a task scheduling algorithm to deliver tasks to the cloud and fog nodes. The proposed algorithm and architecture were assessed as regards network use, delay, and power usage by comparing simulation results to the cloud design alone. Hassan et al. [24] presented a three-layer distant pain tracking system design, in which the fog node uses digital signal processing techniques to detect pain. The proposed solution had lower latency than a cloud-only implementation. The proposed method, however, will not be sufficient when the number of patients rises because the hospital's data are handled by a single fog node. Abdelmoneem et al. [25] suggested a cloud-based, interoperable healthcare IoT architecture to reduce application latency and costs and meet time constraints. To achieve an effective balance in the distribution of healthcare tasks, a task scheduling and allocation approach was proposed. A variety of tasks and cloud nodes were used to evaluate the proposed system's performance. Fog nodes are responsible for executing computational tasks such as context management and data analysis. The scheduling module represents a mapping among tasks represented as a binary graph that will be executed on fog nodes and cloud servers. The task dispatcher module assigns the scheduled tasks to fog nodes or the cloud. In terms of mass ratio, delay, and cost, the simulation's results were satisfactory. However, it lacks necessary QoS metrics in healthcare applications, including energy consumption, processing time, and memory usage. Mukherjee et al. [26] presented a three-layer mobility-aware Internet of Health Things (IoHT) architecture that included sensor nodes, fog nodes for parametric health control, and a cloud server for evaluating aberrant health conditions. The performance of the suggested algorithm and architecture in terms of latency and power use was evaluated by comparing simulated results to the cloud-only architecture.
Mutlag et al. [27] introduced the Multi-Agent Fog Computing (MAFC) concept for managing important healthcare tasks. This strategy allocates fog resources by allowing for task prioritization at two levels: locally on fog nodes and globally in the cloud. To optimize scheduling for critical tasks, this model maps between three tables: task priorities, network load, and network resources. Then, it assigns tasks according to these tables. However, numerous criteria are required to process critical and emergency tasks. In terms of energy consumption, managed services, and latency, the proposed model's performance was assessed by comparing simulation results to the cloud-only architecture. Ying Wah et al. [28] proposed a system relying on the fog-cloud paradigm for healthcare applications. This system implemented a novel algorithm, called Health Care-awareness Cost-Efficient Task Scheduling (HCCETS), which defines vital tasks of a heartbeat application to schedule and execute them with the lowest cost while meeting their deadline. To acquire the cost-efficiency of tasks during allocation under the requirements of QoS, the method is implemented in several phases: task prioritization, resource search, and task scheduling. The outcomes indicated that the performance of the proposed algorithm exceeded that of previous algorithms in terms of cost. However, it does not consider resource limitations or energy consumption. Additionally, this system does not support mobility awareness. Asghar et al. [29] presented a fog-relaying architecture for a health tracking system to reduce network usage and latency. When the health monitoring system is widely deployed, they also suggested a novel Load Balancing Scheme (LBS) to help fog nodes manage their load. They performed large-scale simulations in the iFogSim toolkit to validate the efficacy of the proposed technique, comparing the results to the cloud-only architecture, the LoAd Balancing (LAB) scheme, and Fog Node Placement Algorithm (FNPA) in terms of network use and latency. In comparison to cloud-only, LAB, and FNPA, the suggested health monitoring solution dramatically reduced network usage and latency. However, it does not consider energy consumption. The Fog Node Placement Algorithm (FNPA) was presented by Tun and Paing [30], which connects IoT devices to the closest fog node with sufficient resources (bandwidth, RAM, and CPU). FNPA outperformed the cloud-only implementation and the fog node with a minimal distance method by significantly reducing latency, implementation cost, and network usage. The Critical Healthcare Task Management (CHTM) model was developed by Mutlag et al. [31] and tested using an ECG dataset. At the fog level, they also established a resource scheduling model for fog nodes. They also demonstrated a multi-agent system that can manage the entire network from the edge to the cloud. To successfully manage crucial activities, the proposed solution exceeds the restrictions of interoperability, scheduling, resource sharing, and dynamic job assignment. When compared to the cloud-only model, the simulation outcomes indicated that their model decreased the time response by 90%, network usage by 79%, cost by 80%, network latency by 65%, and energy usage by 81%.
The importance of the location where the task is to be examined in the fog computing architecture was not taken into account by the task scheduling algorithms in most related publications. The incoming tasks from the IoT device were assigned to the nearest accessible fog node in these cases, regardless of the node's capacity. Further, several of them failed to examine the task's requirements and importance. In the evaluation of the proposed architectures, several publications never addressed the performance metric of energy consumption. Furthermore, the performance of some proposed architectures and algorithms was assessed by contrasting simulation outcomes with cloud-only architectures but not with fog-based architectures. In contrast to previous research, we ran extensive simulations using four distinct topology configurations and compared the outcomes to the best three fog-based implementations: CHTM, LBS, and FNPA models. The proposed EEIoMT outperformed the CHTM [31], LBS [29], and FNPA [30] models in four parameters: latency, energy consumption, network usage, and CPU usage.
Many researchers have developed fog-based designs for health monitoring systems that outperform cloud-based architectures. However, for the previously presented health observing systems, none of the scholars contrasted their suggested technique with a fogbased architecture. As a result, developing a fog-based strategy that is more effective than previous fog-based solutions is desirable. Because latency, energy consumption, and network usage are all significant characteristics for health monitoring systems, most studies simply compared their proposed approach to latency and network utilization. Energy consumption, however, was not regarded as a performance indicator. As a result, in addition to delay and network utilization, we must compare our suggested strategy in terms of energy consumption.
In the proposed algorithm, the tasks are classified according to the patient's condition into normal, moderate, and critical. Then, critical tasks are given high priority, moderate tasks are given medium priority, and normal tasks are given low priority so that each classified task is placed in its own queue using the Earliest Deadline First (EDF) algorithm. After that, the appropriate fog node is carefully selected to execute the task by giving each fog node a special weight based on the expected amount of energy consumed and latency in executing this task and choosing the lowest weight.

Research Methodology
This part presents the methodology of the EEIoMT framework. Figure 1 depicts the research methodology flowchart. In order to develop a solution, we first looked at previous studies to determine the most pressing issue and the elements that influence it. The second step was to determine the goals. The proposed framework's design and development was the third step. The role of each algorithm in the framework to tackle the problem was identified during the demonstration process. The final step was to analyze the outcomes by evaluating energy consumption, latency, and network usage with the iFogSim2 simulator.
that each classified task is placed in its own queue using the Earliest Deadline First (EDF) algorithm. After that, the appropriate fog node is carefully selected to execute the task by giving each fog node a special weight based on the expected amount of energy consumed and latency in executing this task and choosing the lowest weight.

Research Methodology
This part presents the methodology of the EEIoMT framework. Figure 1 depicts the research methodology flowchart. In order to develop a solution, we first looked at previous studies to determine the most pressing issue and the elements that influence it. The second step was to determine the goals. The proposed framework's design and development was the third step. The role of each algorithm in the framework to tackle the problem was identified during the demonstration process. The final step was to analyze the outcomes by evaluating energy consumption, latency, and network usage with the iFogSim2 simulator.

Proposed Framework Architecture
The proposed architecture assumes that a group of patients is being monitored in a smart city for emergency situations such as arrhythmia. Cardiovascular disorders are well-known to be among the top main causes of death in the world today. Cardiologists utilize the ECG sensor as one of the tools to diagnose and identify indicators of heart disease in their patients because preserving patients' lives from a sudden heart attack or cardiac arrest necessitates quick and correct interpretation and decisions. As a result, pa-

Proposed Framework Architecture
The proposed architecture assumes that a group of patients is being monitored in a smart city for emergency situations such as arrhythmia. Cardiovascular disorders are well-known to be among the top main causes of death in the world today. Cardiologists utilize the ECG sensor as one of the tools to diagnose and identify indicators of heart disease in their patients because preserving patients' lives from a sudden heart attack or cardiac arrest necessitates quick and correct interpretation and decisions. As a result, patients' current conditions, emergency situations, and decisions are addressed to the best of their abilities. Two important and fundamental design factors related to the scope of this research must be considered: First, the healthcare system must operate 24/7 without downtime. Thus, the caregiver can always monitor the condition of the patients. Second, the information must always be up to date. If the information is not up to date, the missing factors could cost human lives. Furthermore, in comparison to static techniques in the literature, our system allows for real-time dynamic allocation of health duties across fog and cloud devices based on the algorithms employed.
The architecture is made up of three layers: a bottom layer (IoT and edge equipment), an intermediate computing layer (fog devices), and a top layer (cloud). The IoT device is the lowest layer, and it comprises all of the connected devices that are involved in the sensing and actuation processes. For time-sensitive task applications, task achievement should be performed by the appropriate compute node. Because no standard architecture is available at this time, one of the current designs must be chosen and modified to make it appropriate for the algorithm to be created. For this study, a three-tier architecture is used, as presented in Figure 2. The update aims to reduce latency in real-time data transfer while simultaneously improving QoS. the information must always be up to date. If the information is not up to date, the missing factors could cost human lives. Furthermore, in comparison to static techniques in the literature, our system allows for real-time dynamic allocation of health duties across fog and cloud devices based on the algorithms employed.
The architecture is made up of three layers: a bottom layer (IoT and edge equipment), an intermediate computing layer (fog devices), and a top layer (cloud). The IoT device is the lowest layer, and it comprises all of the connected devices that are involved in the sensing and actuation processes. For time-sensitive task applications, task achievement should be performed by the appropriate compute node. Because no standard architecture is available at this time, one of the current designs must be chosen and modified to make it appropriate for the algorithm to be created. For this study, a threetier architecture is used, as presented in Figure 2. The update aims to reduce latency in real-time data transfer while simultaneously improving QoS. The following are the detailed three-tier layer architectures.

•
First tier (IoT devices and edge devices): The first layer is a collection of sensors, actuators, and ESP32 microcontrollers. Actuators can be a smartphone or smartwatch. In the proposed architecture, ECG sensors are used to evaluate heart health and send the sensed data continuously to the ESP32 microcontroller through Bluetooth (BLE). This microcontroller is responsible for: (1) data acquisition: it collects the ECG signals from the ECG sensor; (2) data analysis: it analyzes the ECG signals and classifies the patient condition into normal or abnormal in comparison with standard ECG intervals. The microcontroller is connected to the fog scheduler through Wi-Fi. The smartphone is used to receive a notification from the system or from the specialist doctor. The following are the detailed three-tier layer architectures.
• First tier (IoT devices and edge devices): The first layer is a collection of sensors, actuators, and ESP32 microcontrollers. Actuators can be a smartphone or smartwatch. In the proposed architecture, ECG sensors are used to evaluate heart health and send the sensed data continuously to the ESP32 microcontroller through Bluetooth (BLE). This microcontroller is responsible for: (1) data acquisition: it collects the ECG signals from the ECG sensor; (2) data analysis: it analyzes the ECG signals and classifies the patient condition into normal or abnormal in comparison with standard ECG intervals. The microcontroller is connected to the fog scheduler through Wi-Fi. The smartphone is used to receive a notification from the system or from the specialist doctor. • Second tier (fog layer): This layer is set near the end gadgets. It consists of fog servers and the fog scheduler. Fog devices include computation, communication, and storage capabilities, as well as the ability to perform a variety of processing tasks. The fog scheduler is linked to a network of IoT devices that typically spans a neighborhood or a small town, and it performs task analysis in real time. Each fog device has an internal database that is used to compute and store the tasks that have been assigned to it. In addition to the internal databases, this layer maintains two global fog databases: (1) a resource database, which reports on the capability for processing, usage, remaining energy, and each processor device's storage, and (2) a patient record database, which stores patient health data and analysis results. The fog scheduler is in charge of accessing information from these databases, aiming to manage the scheduling of those resources.
The fog scheduler includes the following modules: (1) The Task Collector Module collects all tasks from the ESP32 microcontrollers that need to be processed. It also classifies the tasks according to the proposed task classification algorithm. It creates a series of structures that contain information and task characteristics. (2) The Task Prioritization Module prioritizes the tasks based on the task priority algorithm. Critical tasks are given high priority, moderate tasks are medium priority, and normal tasks are low priority. There is a queue for each task classification; the tasks are arranged in each queue based on their deadlines. As a result, critical activities will be completed sooner, thus helping to satisfy the deadline and reaction time requirements. (3) The Resource Collector Module receives information about the fog layer's available resources. It keeps track of how often the fog devices are used, as well as their updated capabilities (processor, RAM, energy, etc.). (4) The Task Scheduling and Allocation Module is in charge of establishing and customizing the task allocation method for fog and cloud devices. This module principally provides a software routine for an optimization method aimed at lowering the system's energy consumption and decreasing the time that it takes to complete health tasks.

•
The cloud, which gathers data and information from intermediary computing nodes, is the third tier (cloud layer) of the architecture (fog layer). It uses cloud-based resource devices to complete portions of jobs that are not completed in the fog layer, which are typically non-time-sensitive. It also has a permanent database that caregivers can use to keep track of the patient's health analysis results. A proxy server establishes a communication channel between a cloud server and fog nodes.
The suggested architecture has been utilized to enable rapid response, IoT healthcare, and monitoring applications since these applications are latency-sensitive and require real-time monitoring. In healthcare applications, information analysis and decision making are critical. The most time-sensitive data (critical tasks) are processed in the appropriate fog node in our architecture; this allows important jobs to be completed earlier, which helps in meeting the deadline and response time requirements.

The Proposed Task Scheduling Algorithm
Various sensors and equipment provide huge amounts of data in real-time applications, such as healthcare applications, which involve crucial tasks. Fog computing implementation can be used to manage them at the network's edge. However, fog nodes lack resources, which may limit the amount of time required for the ultimate outcome/analytics. Only a few tasks can be performed by fog nodes. Choosing which tasks the fog nodes will perform is a difficult decision.
To address various flaws in existing task scheduling algorithms, an Energy-Efficient Internet of Medical Things to Fog Interoperability of Task Scheduling (EEIoMT) framework is proposed. This framework has three algorithms: a task classification algorithm to classify the tasks into three categories (normal tasks, moderate tasks, and critical tasks), a task priority algorithm to give priority to each task according to each category from the previous algorithm, and a dynamic task assignment algorithm to allocate tasks to the proper fog node. The major function of algorithms in this framework is to assign tasks and prioritize them, as well as to determine network resource availability. We place processing nodes closer to sensors to reduce latency and energy consumption by minimizing the physical distance between sensors and computing nodes. We also limit the energy in IoT devices that can be consumed when transferring tasks to a far computing node. Each task should be completed as quickly as possible to save the patient's life, such as contacting the civil defense and the hospital. There are three layers of processing in the suggested framework: ESP32 microcontrollers, fog nodes, and the cloud. Fog servers, which are micro data centers and virtual machines, are present in each node in the fog layers. Each layer's server capacity is different. Fog nodes have substantially less computational power, storage, and server capacity than the fog cloud, and fog nodes also have significantly more computing power, storage, and capacity than the ESP32 microcontroller. However, when it comes to delays, response time, and distance from end users, the closer the computing nodes are to the data source, the lower the delay and the higher the response speed. Therefore, critical and time-sensitive tasks must be executed at the appropriate computational node to ensure that they are executed with minimal delay and meet their deadlines.
In fog computing, the task scheduling challenge is to allocate IoT tasks to suitable fog nodes from a list of potential fog nodes in order to optimize QoS. In this research, latency, energy consumption, and network usage are considered QoS parameters.
Assuming that there are n tasks T to be delivered to the fog scheduler, the following can be expressed: in which each parameter t i is characterized using a set of attributes where TS i is task size (in bits), TL i is task length (in MI (Millions of Instructions)), the type i of the task is normal, moderate, or critical, and dt i is the deadline of the task to be respected for achieving the task. Assume that the fog computing system has m Fog nodes F, which may be expressed as follows: in which each parameter f j is described using a set of attributes f j = S j , CC j , E j , where S j refers to storage capacity, CC j is computing capacity (in MIPS (Millions of Instructions Per Second)), and E j is the total battery capacity (Energy) of f j . The task scheduling challenge is to allocate n tasks to m fog nodes in such a way that the QoS parameters are optimal using the notations above. X ij refers to the assignment of task t i to fog node f j , whereas X icloud refers to the assignment of task t i to the cloud.
We can analytically analyze the execution time, transmission time, response time, and energy use to distribute the requested tasks to the appropriate fog node. After that, the relevant node is chosen, and the task is assigned to it.

• Execution time
The execution time of processing task t i on fog node f j or the cloud is calculated according to Equations (3) and (4): where Et X ij , and Et(X icloud ) are the execution time of the task in the fog node and cloud, respectively, and CC j , and CC cloud are the computation capacity of the fog node, and cloud, respectively.

• Transmission time
The transmission time of task t i from the ESP32 to the fog scheduler T r t(FS) is calculated by the task size TS i of task t i divided by the transmission rate (bandwidth) BW. The transmission time of task t i from the fog scheduler to the fog node T r t X ij or to the cloud T r t(X icloud ) is calculated as follows: The total transmission time of tasks from the ESP32 to the appropriate fog node f j or the cloud can be calculated by combining Equations (5) and (6) or (5) and (7), respectively.
The response time of a task t i that is handled in many layers is the sum of the specified node's execution time plus the task's transmission time from the source to the destination. The next formula is utilized to compute the response time of task t i that is handled at fog node f j : The response time of task t i that is processed in the cloud is calculated as follows: • Energy consumption Energy consumption in our work is composed of two components: the energy spent on transmitting a task to a computing node and the energy spent on executing the task.
The energy E tr X ij required to transmit task t i to fog node f j is calculated by multiplying the transmission time by a constant coefficient as follows: However, when calculated, the energy required to transmit task t i to the cloud is calculated as follows: where λ is a constant related to the wireless interface [32]. The energy consumption E p X ij for processing task t i on fog node f j is expressed by multiplying the execution time by a constant coefficient as follows: The energy consumption E p (X icloud ) for processing task t i in the cloud is as follows: where µ is the coefficient denoting the energy consumption per CPU cycle [33]. The total energy is calculated by a combination of processing energy and transmission energy for the fog or cloud, as follows: • Makespan The makespan is the maximum completion time (CT) of a resource. It is denoted as follows, according to the equation in [34]: •

Resource Utilization
Resource Utilization (RU) refers to the most efficient use of resources. Reduced makespan is critical to utilization performance. As a result, these two concepts are inversely connected. The usage of Virtual Machines (VMs) is computed as follows: The total use of all assets present in the fog environment is defined as the average utilization of the resource. The average resource consumption is computed as follows: • Proposed formulation for task scheduling problem The goal of scheduling is to distribute IoT tasks to the resources of fog nodes or the cloud in the most efficient way possible to reduce latency and energy consumption. Integer Linear Programming (ILP) [35] can be used to represent the issue of assigning IoT tasks to suitable fog nodes, as follows: Equation (21) prevents a task from being assigned to more than one fog node at the same time. Equation (22) shows that the computation intensity necessary to complete a set of tasks assigned to the fog node cannot be greater than the computing capability of the fog node. Equation (23) states that the task size necessary to complete a set of tasks given to the fog node cannot exceed the fog node's storage capacity. Equation (24) ensures that the fog node's energy consumption needed for completing a set of activities is less than the fog node's remaining battery capacity. Equation (25) ensures that the total time required by fog node f j to complete task t i does not exceed the task deadline. Equation (26) defines our binary decision variables, in which X ij is 1 if f j is selected for performing task t i and 0 otherwise.
The fog scheduler selects the correct fog node by assigning a weight to each node so that the selection ensures that the optimization of QoS parameters is achieved. We modified the Weighted Sum Method (WSM) to be the dynamic Modified WSM (MWSM) and compatible with our work.
where N MWSM−score ij indicates the QoS score of X ij (the weight assigned to fog node f j ).
The lower the N MWSM−score ij , the more appropriate the fog node for executing task t i . The QoS score given to X ij is calculated as the weighted sum of QoS parameters, total energy consumption, and latency (expressed as response time). The summation of the weight factors must be equal to 1, as shown below.
where w E and w L are weight factors relating to the significant influence of the QoS parameters energy consumption and latency in a given node, respectively. Nomenclature contains a list of all of the notations used in the mathematical model.

ECG Signal Analysis
The diagnosis of cardiac problems known as arrhythmias, such as bradycardia, tachycardia, and heart rate variation, is made easier with an ECG feature extraction algorithm. The heart rate and arrhythmias are determined using beat detection, and abnormal beats are detected using additional processing. The acquired ECG signal can be segmented into the P wave, T wave, and QRS complex. Different time intervals, such as PR, QRS, QT, and ST, are obtained, as shown in Figure 3.
The ECG signals are analyzed every 8 s [36] and classify the patient's state into normal or abnormal in comparison with the typical values of waves and intervals of ECG signals, which are shown in Table 1. If the result of analyzing the ECG signals is within the permissible duration for each wave or interval, the patient's condition is considered normal. However, if there is any difference, whether an increase or decrease in the periods, the patient has an abnormal condition and must be monitored.
given to the fog node cannot exceed the fog node's storage capacity. Equation (24) ensures that the fog node's energy consumption needed for completing a set of activities is less than the fog node's remaining battery capacity. Equation (25) ensures that the total time required by fog node to complete task does not exceed the task deadline. Equation (26) defines our binary decision variables, in which is 1 if is selected for performing task and 0 otherwise.
The fog scheduler selects the correct fog node by assigning a weight to each node so that the selection ensures that the optimization of QoS parameters is achieved. We modified the Weighted Sum Method (WSM) to be the dynamic Modified WSM (MWSM) and compatible with our work.
where − indicates the QoS score of (the weight assigned to fog node ). The lower the − , the more appropriate the fog node for executing task . The QoS score given to is calculated as the weighted sum of QoS parameters, total energy consumption, and latency (expressed as response time). The summation of the weight factors must be equal to 1, as shown below.
where and are weight factors relating to the significant influence of the QoS parameters energy consumption and latency in a given node, respectively.
Nomenclature contains a list of all of the notations used in the mathematical model.

ECG Signal Analysis
The diagnosis of cardiac problems known as arrhythmias, such as bradycardia, tachycardia, and heart rate variation, is made easier with an ECG feature extraction algorithm. The heart rate and arrhythmias are determined using beat detection, and abnormal beats are detected using additional processing. The acquired ECG signal can be segmented into the P wave, T wave, and QRS complex. Different time intervals, such as PR, QRS, QT, and ST, are obtained, as shown in Figure 3.
The ECG signals are analyzed every 8 s [36] and classify the patient's state into normal or abnormal in comparison with the typical values of waves and intervals of ECG signals, which are shown in Table 1. If the result of analyzing the ECG signals is within the permissible duration for each wave or interval, the patient's condition is considered normal. However, if there is any difference, whether an increase or decrease in the periods, the patient has an abnormal condition and must be monitored.  In our work, the Novel Windowing Algorithm [38] was used to analyze ECG signals in the ESP32 microcontroller.

Task Classification Algorithm
We classified IoT tasks into three types: normal tasks, moderate tasks, and critical tasks according to the patient's condition.

•
Normal tasks If the condition of the patient is normal, the tasks are considered normal tasks. The data will be aggregated in ESP32, and the analysis will be performed every 24 s, for example, instead of 8 s, aiming to decrease energy usage during the analysis. In the given period of time, the patient's health data will be delivered to the patient record database in the fog layer to update and store their data.

Moderate tasks
If the patient's condition is abnormal and the patient has no history of heart attacks, the tasks are considered moderate tasks. These tasks are delivered to the fog scheduler to be treated in the appropriate fog node.

• Critical tasks
If the patient's condition is abnormal and the patient has a history of heart attacks, the tasks are considered critical tasks. These tasks must be processed in the appropriate available fog node because they are time-sensitive, and delays in response may put the patient's life at risk.

Task Priority Algorithm
To assign tasks to the correct fog node and ensure that tasks are executed by their deadline, tasks must be scheduled according to their priority. In the priority algorithm, critical tasks are given high priority and should be treated in the appropriate fog node. Although moderate tasks have a medium priority, when the deadline for these tasks approaches, moderate tasks will be changed to critical tasks, and they will be given a high priority. Normal tasks are not time-sensitive tasks, so these tasks have low priority.

Dynamic Task Assignment Algorithm
After categorizing the tasks and giving each of them a priority, it is necessary to select the correct fog node for processing. When selecting a fog node, we make sure that the QoS is optimized in terms of lag and energy consumption. A dynamic task assignment algorithm is proposed to assign tasks dynamically to the correct fog node according to the task priority, the weight of the fog node, and resource availability.
The Weighted Sum Method (WSM) [40] is a multi-criterion decision-making method that takes into account a list of criteria, such as current battery state, energy consumption, latency, response time, and load, among others. The WSM is the best-known and most widely used method for making decisions with multiple criteria. The method is clearly explained in [41]. We can make a decision using this technique based on a lot more useful data on the effectiveness of any node. Each node has a different weight, which allows it to stand out from the others. The WSM is time-independent and can be described as a static WSM. Therefore, we modified this method to be a dynamic MWSM and compatible with our work.
The MWSM is implemented to select the appropriate node in terms of latency and energy consumption according to Equation (27) in the mathematical model.
If the task is critical, the weight factors are w E = 0; w L = 1. This type of task is timesensitive, so the task should be executed with the least possible latency because any further delay will put the patient's life at risk. When the task is moderate, the weight f actors w E = 0.5; w L = 0.5 are used. In order to conserve energy and, at the same time, take care of the delay, we set an equal weight factor between them while ensuring the execution of these tasks within their deadlines. However, in the case of normal tasks, the weight f actors w E = 1; w L = 0 are used. These tasks are not time-sensitive, and therefore, we do not consider the latency and focus on energy while ensuring the execution of these tasks within their deadlines.
The tasks will be routed to the cloud if resources are not accessible in the fog layer.

Task Scheduling Algorithm Design
Tasks are categorized into three types: normal tasks, moderate tasks, and critical tasks according to the patient's condition in comparison with standard ECG intervals. All important tasks will be placed into a high-priority queue, while moderate tasks will be added to a separate queue, ensuring that all high-priority tasks are handled first. The suggested method executes a task categorization procedure depending on the patient's status whenever a task comes from an edge device. Then, it puts the task into the appropriate queue according to its priority. After that, the dynamic task assignment algorithm assigns the task to the suitable layer. The Pseudo-Code of the proposed EEIoMT framework algorithm is shown in Algorithm 1. Call Task Priority Algorithm; 5.
Call Dynamic Task Assignment Algorithm; 6. End Therefore, a task classification algorithm was designed, as shown in Algorithm 2.

•
Task priority algorithm In the task priority algorithm, critical tasks are given high priority, moderate tasks are medium priority, and normal tasks are low priority. There are three queues for each task classification, and the tasks are arranged in each queue based on their deadlines. The EDF method is used to order the list of tasks by deadline. The assignment with the shortest deadline is completed first. When two jobs have the same deadline, the task is ordered by FCFS. Critical activities will be completed sooner as a result, helping to satisfy the deadline and reaction time requirements. The Pseudo-Code of the task priority algorithm is shown in Algorithm 3.

Algorithm 2. Task Classification Algorithm
Input: Tasks with patient's condition attribute (Normal or Abnormal) History of heart attacks attribute (Yes, No) Output: Task Categorization (Normal, Moderate, or Critical) Begin: 1. Incoming tasks T 2. Foreach task t i ∈ T do 3.
If (patient condition is Normal) 4.
Categorize task t_i as Normal task 5.
If (patient condition is Abnormal) 6.
Foreach t i ∈ T do 5.
Else if (task is moderate) 8.

•
Dynamic task assignment algorithm The Pseudo-Code of the dynamic task assignment algorithm is shown in Algorithm 4.

Algorithm 4. Dynamic Task Assignment Algorithm
Number of fog node F, cloud Output: Task to be assigned in fog layer or cloud Begin: Find the available fog nodes in the system;

4.
Calculate T r t total X ij based on Equation (8);
Calculate the weight for all available fog node based on Equation (27); 10.
Q F ← Sort all available fog nodes by their weights with ascending order; Algorithm 4. Cont.

11.
Foreach f j ∈ Q F do

14.
Make the assignment based on Equations (21) and (26) If X ij = 0;//No available fog nodes in fog layer
Make the assignment

33.
Find the available fog nodes in the system;

35.
Calculate T r t total X ij based on Equation (8);
Calculate the weights for all available fog node based on Equation (27); 41.
Q F ← Sort all available fog nodes by their weight with ascending order; 42.
End 61. End Find the available fog nodes in the system;

66.
Calculate T r t total X ij based on Equation (8);

68.
Calculate E total X ij based on Equation (16); Calculate the weight for all available fog node based on Equation (27); 72.
Q F ← Sort all available fog nodes by their weight with ascending order; 73. Foreach
Calculate E total (X icloud ) based on Equation (17)

Scenario
Assume that a group of patients in a smart city is tracked in order to detect emergency circumstances such as arrhythmia. Each patient has an ECG sensor attached to his/her body that is connected to the ESP32 microcontroller. Assume that each group of ESP32 in a specific geographical area is linked to the one fog scheduler by a Wi-Fi connection. Each patient has a smartphone connected to the system, receiving important notifications from the system or the specialist doctor. ECG signals are collected in the ESP32 and analyzed periodically (every 8 s).
Case 1: If the outcome of the analysis shows that the patient's condition is normal, the information will be aggregated, and the analysis will be performed every 24 s, for example, instead of 8 s, in order to limit the amount of energy used during the analysis. The patient's health information and the results of the analysis will be delivered to the fog layer's patient record database, which will be updated and stored.
Case 2: If the patient's condition is abnormal, the result is sent to the fog scheduler through Wi-Fi. The proposed algorithm will first classify the tasks; if the patient has a previous history of heart attacks, their condition will be considered critical. It will be given high priority and executed at the appropriate fog node that fulfills the lowest possible latency. A sound alert will be sent to the smartphone to notify the patient's family of their condition, and a notification will also be sent to the civil defense and the hospital.
Case 3: If the patient's condition is abnormal and the patient has no history of heart attacks, their condition will be considered moderate. It will be given medium priority and executed at the available fog node. The patient's data for the last 30 min will be sent to the hospital for further analysis. The specialist doctor will send a set of instructions for the patient to follow to avoid reaching a critical condition.
In all of the patient conditions, the patient's health data will be delivered to the patient record database in the fog layer to update and store the data.

Implementation
Using the Eclipse IDE environment (version 2021-03 (4.19.0), the suggested scheduling technique was implemented in the iFogSim2 simulation toolbox. The simulation was run on a real-world ECG dataset obtained from the University of California at Irvine's Archive database (UCI) [42], which was utilized for cardiac arrhythmias. This database contains 452 heart rate samples, 279 attributes, and 16 classes. Some of the most important attributes are shown in Table 2. Table 3 shows the number and names of the classes, as well as the quantity of information in every class. Class 1 denotes a normal ECG, whereas classes 2 through 15 denote various classes of arrhythmia (abnormal). The rest of the unclassified ones are referred to as class 16.

Age Age in years Sex
Sex (0 = male, 1 = female) Height Height in centimeters (cm) Weight Weight in kilograms (kg) QRS duration Average QRS duration in milliseconds.

P-R interval
Average time interval between the start of waves P and Q in milliseconds Q-T interval Average time interval between the start of wave Q and end of wave T in milliseconds T interval Average time interval of wave T in milliseconds P interval Average P wave distance in milliseconds Heart rate Number of heart beats per minute In a 3000 × 2000 m area, six fog nodes were constructed and randomly placed. Every fog node had four connected IoT devices at first, with a coverage area of 500 m.
For the real-time implementation of our proposed framework, the configuration characteristics required for the cloud, proxy server, fog server, fog scheduler, and IoT devices are presented in Table 4.

Number of Class Name of Class Amount of Data in
Supraventricular premature contraction 2 9 Left bundle branch block 9 10 Right bundle branch block 50 11 Degree atrioventricular block 0 12 Degree AV block 0 13 Degree AV block 0 14 Left ventricular hypertrophy 4 15 Atrial fibrillation or flutter 5 16 Others 22

Experimental Results and Discussion
In this part, the most important outcomes of the research are explained, discussed, and analyzed. Healthcare applications are time-sensitive and require real-time processing to monitor patients, and this is supported by the proposed framework. It also optimizes the QoS for home health monitoring systems by fog computing in terms of energy usage, latency, and network utilization. Since this system relates to human life, a delay in responding to critical tasks must have the lowest value, and this is what is provided in our proposed framework. Furthermore, caregivers can always control a patient's state in real time and make the appropriate decision to save their life.
In this research, the simulation was run on a laptop with 8 GB of RAM, a 3.2 GHz Core i7 processor, 10th GEN DELL, a 500 GB HDD, 250 GB SSD, Windows 10 Pro, and a 64-bit operating system.

Experimental Results
The behavior evaluation of the suggested EEIoMT framework was performed against CHTM [31], LBS [29], and FNPA [30], which are high-level models, and outcomes are shown in this part. The following performance metrics are used in the performance evaluation: 1.
Average energy consumption: This is the overall energy utilized by the entire system. It is measured by the amount of energy consumed while tasks are being transmitted and processed through any of the system elements, such as IoT devices, fog nodes, and the cloud. The energy consumption needs to be minimized. It is measured in joules.

2.
Average latency: This is the time that it takes for the system to complete all of its tasks.
In our system, the response time is adopted as the main criterion for lag, which is the total time required to transfer and perform tasks and return the results. As a result, when the reaction time is lowered, the latency is reduced as well. The latency needs to be minimized. It is measured in milliseconds (ms).

3.
Network usage: In our research, the amount of data transferred and received by a certain user within a network in a given amount of time is referred to as bandwidth use. The more data exchanged, the greater the risk of clogging the network, and the more energy consumed by a single user. Typically, bandwidth is measured in bits per second and expressed as a bit rate (bps). In other words, it demonstrates how the proposed framework contributes to balancing network load while executing tasks. The network usage needs to be minimized. It is measured in kilobits per second (kbps). 4.
CPU usage: The amount of work handled by a CPU or the number of processing resources used by a computer is referred to as "CPU use." The volume and type of managed computing tasks determine how much CPU is used. Due to non-CPU resource needs, certain operations demand a lot of CPU time, while others require a lot less.
In the first experimental test, the number of fog nodes was set to 6, the number of VMs was 3, the number of patients was 24, and the number of tasks for each patient was 3. The results are the average of the 1000-time test. The outcomes for the behavior metrics of average latency, average energy consumption, network usage, and CPU usage are shown in Figures 4-7, respectively.
Sensors 2022, 22,5327 In the first experimental test, the number of fog nodes was set to 6, the nu VMs was 3, the number of patients was 24, and the number of tasks for each pati 3. The results are the average of the 1000-time test. The outcomes for the behav rics of average latency, average energy consumption, network usage, and CPU us shown in Figures 4-7, respectively.          The simulation results show that EEIoMT significantly reduces all of the mance metrics as compared to the CHTM, LBS, and FNPA models. This is due to sign of this framework, where the ECG sensor signals are analyzed near the se  The simulation results show that EEIoMT significantly reduces all of the performance metrics as compared to the CHTM, LBS, and FNPA models. This is due to the design of this framework, where the ECG sensor signals are analyzed near the sensor inside the ESP32 microcontroller; thus, the distance over which the signals are transmitted is greatly reduced, and therefore, the transmission time will be significantly reduced. If the result of the analysis indicates that the patient's condition is normal, the data are aggregated and not sent directly to the fog layer, where in every given period of time, a report is sent with the patient's data to be stored, and the previous data are updated in the fog layer and then sent to the cloud. However, if the patient's condition is abnormal, the task with the abnormal condition will be sent to the fog layer, thus reducing the amount and size of data transmitted to the fog layer, which in turn reduces the latency, the amount of energy consumed during the transmission and processing of these tasks, and the amount of bandwidth consumed during the transmission of these tasks. Fog nodes are also used efficiently, and the load is distributed among them, which reduces the latency, energy consumption, and network usage that would result from giving one of the nodes a heavy burden and leaving the other idle. In the proposed framework, three algorithms are designed to improve the task execution process and reduce response time and energy consumption. The tasks are classified into normal, moderate, and critical tasks, and then each of them is given priority so that we ensure the execution of critical tasks in the least time and ensure that all other tasks are executed within their deadlines. The appropriate fog node is carefully selected to carry out the task by giving special weight to each node. In the case of critical tasks, the latency is given full importance, and thus, the fog node that achieves the least latency is chosen even if there is higher energy consumption. In the case of a moderate task, equal importance is given to energy consumption and latency, while when the task is normal, full importance is given to energy consumption while ensuring that tasks are executed within their deadline. In this way, the appropriate fog node is selected that achieves the best results depending on the type of task to be executed. In contrast, in the CHTM, LBS, and FNPA models, the sensor signals are sent to the fog layer, and thus, more time, energy, and bandwidth are consumed when transmitting and also when processing them in the fog nodes because the data size is much larger than the data that are transferred and processed through the proposed framework. Additionally, because the size of the tasks to be processed in our framework is small, they do not require high CPU usage.
It can be noticed that the proposed EEIoMT framework achieves the least latency, energy consumption, network usage, and CPU usage.
In the following experiments, the results were obtained by changing one parameter each time. These parameters are the number of patients, the number of fog nodes, the number of Virtual Machines (VMs), the number of tasks, and the percentage of the type of each task. All of the results are the average of the 1000-time test.

Changing the Number of Patients
In this part of the experimental test, the number of fog nodes was set to 6, the number of VMs was 3, and the number of tasks for each patient was 3. As each patient has a fixed number of tasks, when the number of patients increases, the tasks will increase by a constant number of tasks for each patient, as shown in Table 6. The number of patients was changed to 36, 48, 60, and 72. Table 6. Number of tasks when increasing the number of patients.

Number of Patients
Number of Tasks  Number of Tasks for Each Patient   36  108  3  48  144  3  60  180  3  72  216  3 When the number of patients increases, the IoT devices connected to the fog layer will increase, and therefore, the tasks that are sent to the fog layer will increase. These tasks require more time and energy to transmit and process, and this increases latency and energy consumption. These tasks also consume more network bandwidth and CPU usage.
When the number of patients grows and there are not enough fog nodes with sufficient resources, the tasks are forwarded to the cloud. As a result of the increasing load on the cloud server, latency and network utilization increase. Figures 8-11 illustrate the findings for the performance parameters of latency, energy consumption, network utilization, and CPU usage, respectively.

216 3
When the number of patients increases, the IoT devices connected t will increase, and therefore, the tasks that are sent to the fog layer will i tasks require more time and energy to transmit and process, and this in and energy consumption. These tasks also consume more network bandw usage.
When the number of patients grows and there are not enough fog no cient resources, the tasks are forwarded to the cloud. As a result of the i on the cloud server, latency and network utilization increase. Figures 8-11 illustrate the findings for the performance parameters o gy consumption, network utilization, and CPU usage, respectively.     To allocate workload, FNPA chooses the fog node with the shortes most resources (bandwidth, RAM, and CPU). When the number of user    To allocate workload, FNPA chooses the fog node with the shortes most resources (bandwidth, RAM, and CPU). When the number of user To allocate workload, FNPA chooses the fog node with the shortest distance and most resources (bandwidth, RAM, and CPU). When the number of users grows to the point where no more fog nodes with sufficient capacity are available, the tasks are routed to the cloud server. As a result of the increasing demand on the cloud server, latency increases. Likewise, each IoT device has only one fog node or BS in LBS, although it might be located in the coverage region of many BSs. In an effort to decrease latency, the IoT device chooses an appropriate fog node. The message is transmitted to IoT devices after each BS's traffic and computing loads are iteratively calculated. The fog node's communication and computation latency will be determined after the BS and fog nodes' traffic and computing loads have been estimated, respectively. Each IoT device will verify the parameters before selecting the best BS in each iteration with the least amount of latency. When the number of IoT devices rises while the number of BSs remains the same, it is possible for many IoT devices to choose the same BS that achieves the least latency at the same time, and therefore, it receives an overload, and the latency will increase. Moreover, the selection of the suitable BS by IoT devices is inefficient, as there must be a scheduler for controlling these devices and selecting the most appropriate BS for them.
Prioritization is performed by Personal Agents (PAs) in the CHTM model before arrival tasks are designated to fog nodes. Then, in the fog nodes, utilizing Fog Node Agents (FNAs), all of the associated PAs are prioritized. The task scheduling module will decide whether to deal with incoming duties locally (if the task's size is within the local node's resources) or to send them to neighboring nodes (in case of the unattainability of local node resources). This module, in other words, provides three major options: executing locally, in a neighbor, or in the cloud.

Changing the Number of Fog Nodes
In this part of the experimental test, the number of fog nodes was set to 24, the number of VMs was 3, and the number of tasks for each patient was 3. The number of fog nodes was changed to 8, 10, 12, and 14.
The simulation outcome indicates that as the number of fog nodes accumulates, latency, energy consumption, and network usage in all models decrease in varying proportions because when the number of fog nodes increases, there will be more options from which to choose the most suitable nodes to perform the tasks, and the possibility of sending tasks to the cloud will also be reduced, thus reducing latency and consuming less energy and less network bandwidth. There will also be more calculations for choosing the most suitable nodes to perform the tasks, and the execution of tasks will be distributed among these fog nodes, thus slightly decreasing CPU usage.
The outcomes for the behavior metrics of latency, energy consumption, network usage, and CPU usage are shown in Figures 12-15, respectively. latency. When the number of IoT devices rises while the number of BS same, it is possible for many IoT devices to choose the same BS that achiev tency at the same time, and therefore, it receives an overload, and the l crease. Moreover, the selection of the suitable BS by IoT devices is ineff must be a scheduler for controlling these devices and selecting the most a for them.
Prioritization is performed by Personal Agents (PAs) in the CHTM m rival tasks are designated to fog nodes. Then, in the fog nodes, utiliz Agents (FNAs), all of the associated PAs are prioritized. The task sched will decide whether to deal with incoming duties locally (if the task's siz local node's resources) or to send them to neighboring nodes (in case of th ity of local node resources). This module, in other words, provides three executing locally, in a neighbor, or in the cloud.

Changing the Number of Fog Nodes
In this part of the experimental test, the number of fog nodes was number of VMs was 3, and the number of tasks for each patient was 3. T fog nodes was changed to 8, 10, 12, and 14.
The simulation outcome indicates that as the number of fog nodes ac tency, energy consumption, and network usage in all models decrease in portions because when the number of fog nodes increases, there will be from which to choose the most suitable nodes to perform the tasks, and th sending tasks to the cloud will also be reduced, thus reducing latency a less energy and less network bandwidth. There will also be more calculat ing the most suitable nodes to perform the tasks, and the execution of tas tributed among these fog nodes, thus slightly decreasing CPU usage.
The outcomes for the behavior metrics of latency, energy consump usage, and CPU usage are shown in Figures 12-15, respectively.   In this part of the experimental test, the number of fog nodes was set to 6, the n   In this part of the experimental test, the number of fog nodes was set to 6, the num ber of patients was 24, and the number of tasks for each patient was 3. Then, the numbe of VMs was changed to 5, 7, 9, and 11.   In this part of the experimental test, the number of fog nodes was set to 6, the nu ber of patients was 24, and the number of tasks for each patient was 3. Then, the numb

Changing the Number of Virtual Machines
In this part of the experimental test, the number of fog nodes was set to 6, the number of patients was 24, and the number of tasks for each patient was 3. Then, the number of VMs was changed to 5, 7, 9, and 11. When the number of VMs increases, most of the tasks will be executed in the fog layer, so the latency and the network usage will decrease, but the energy consumption will increase due to executing more tasks earlier, which requires more energy. The execution of tasks will also be distributed among these VMs, and thus, the CPU usage will decrease. Figures 16-19 illustrate the findings for the performance measures of latency, energy consumption, network utilization, and CPU usage, respectively. When the number of VMs increases, most of the tasks will be executed in the fo layer, so the latency and the network usage will decrease, but the energy consumptio will increase due to executing more tasks earlier, which requires more energy. The exe cution of tasks will also be distributed among these VMs, and thus, the CPU usage wi decrease. Figures 16-19 illustrate the findings for the performance measures of latency energy consumption, network utilization, and CPU usage, respectively.   Sensors 2022, 22,5327 When the number of VMs increases, most of the tasks will be executed in layer, so the latency and the network usage will decrease, but the energy consu will increase due to executing more tasks earlier, which requires more energy. cution of tasks will also be distributed among these VMs, and thus, the CPU us decrease. Figures 16-19 illustrate the findings for the performance measures of energy consumption, network utilization, and CPU usage, respectively.

Changing the Number of Tasks
In this part of the experimental test, the number of fog nodes was set to 6 ber of VMs was 3, and the number of patients was 24. Then, the number of changed to 120, 168, 216, and 264.
When the number of tasks rises, there is a rise in time and energy consu transmit and process these tasks. These tasks also need more processing in t the CPU usage increases. Furthermore, these tasks consume more network b so the network usage increases.
The outcomes are presented in Figures 20-23, which show performance latency, energy consumption, network usage, and CPU usage, respectively.

Changing the Number of Tasks
In this part of the experimental test, the number of fog nodes was set to 6, t ber of VMs was 3, and the number of patients was 24. Then, the number of ta changed to 120, 168, 216, and 264.
When the number of tasks rises, there is a rise in time and energy consum transmit and process these tasks. These tasks also need more processing in the the CPU usage increases. Furthermore, these tasks consume more network ban so the network usage increases.
The outcomes are presented in Figures 20-23, which show performance me latency, energy consumption, network usage, and CPU usage, respectively.

Changing the Number of Tasks
In this part of the experimental test, the number of fog nodes was set to 6, the number of VMs was 3, and the number of patients was 24. Then, the number of tasks was changed to 120, 168, 216, and 264.
When the number of tasks rises, there is a rise in time and energy consumption to transmit and process these tasks. These tasks also need more processing in the CPU, so the CPU usage increases. Furthermore, these tasks consume more network bandwidth, so the network usage increases.
The outcomes are presented in Figures 20-23, which show performance metrics for latency, energy consumption, network usage, and CPU usage, respectively.

Changing the Percentage of Each Type of Task
In this part of the experimental test, the number of fog nodes was set to 6, the nu ber of VMs was 3, the number of patients was 24, and the number of tasks for each tient was 11. Then, the types of tasks were determined, namely, critical, moderate normal, and each type was given a certain percentage of the total number of tasks. T percentage of each type was changed to (70% normal, 20% moderate, 10% critical), (5 normal, 35% moderate, 15% critical), (30% normal, 40% moderate, 30% critical), a (10% normal, 50% moderate, and 40% critical).
The simulation results demonstrate that in our proposed EEIoMT, when the nu ber of critical tasks increases, the energy consumption, network usage, and CPU us are increased, but the latency is decreased because we are focused on minimizing lat cy. In this case, the fog nodes that achieve the least latency are selected, and when e cuting these tasks within the fog layer, the CPU usage and the bandwidth consumpt will also increase.
It can be seen that in the proposed EEIoMT, when the percentage of normal task 70%, the energy consumption is as low as possible because we are focused on minim ing energy while meeting their deadlines. In the other models, slight changes are served in energy consumption, latency, network usage, and CPU usage because th tasks are not categorized and given priorities, as is implemented in our propo framework, and therefore, changing the percentages of these tasks will not grea change the values of any of the performance metrics in other models.
The results for the performance metrics of latency, energy consumption, netw usage, and CPU usage are shown in Figures 24-27, respectively.

Changing the Percentage of Each Type of Task
In this part of the experimental test, the number of fog nodes was set to 6, the number of VMs was 3, the number of patients was 24, and the number of tasks for each patient was 11. Then, the types of tasks were determined, namely, critical, moderate, or normal, and each type was given a certain percentage of the total number of tasks. The percentage of each type was changed to (70% normal, 20% moderate, 10% critical), (50% normal, 35% moderate, 15% critical), (30% normal, 40% moderate, 30% critical), and (10% normal, 50% moderate, and 40% critical).
The simulation results demonstrate that in our proposed EEIoMT, when the number of critical tasks increases, the energy consumption, network usage, and CPU usage are increased, but the latency is decreased because we are focused on minimizing latency. In this case, the fog nodes that achieve the least latency are selected, and when executing these tasks within the fog layer, the CPU usage and the bandwidth consumption will also increase.
It can be seen that in the proposed EEIoMT, when the percentage of normal tasks is 70%, the energy consumption is as low as possible because we are focused on minimizing energy while meeting their deadlines. In the other models, slight changes are observed in energy consumption, latency, network usage, and CPU usage because their tasks are not categorized and given priorities, as is implemented in our proposed framework, and therefore, changing the percentages of these tasks will not greatly change the values of any of the performance metrics in other models.
The results for the performance metrics of latency, energy consumption, network usage, and CPU usage are shown in Figures 24-27, respectively.
In summary, the energy consumption in our work is composed of two portions: the amount of energy expended in completing a task to a computing node and the energy spent on executing the task. In time-sensitive applications such as health monitoring systems, latency must also be decreased. It can be observed that in the proposed EEIoMT, the latency increases and decreases depending on the type of task being performed. If most of them are critical tasks, the latency decreases, and if they are moderate or normal, the latency will be a little high. Furthermore, because only the cloud server is in charge of all data processing, using the cloud-only implementation of the architecture results in high network usage due to the expanded load of traffic on the cloud server. In contrast, in fog-based architectures such as EEIoMT, CHTM, LBS, and FNPA, every fog node is expected to handle and evaluate information streams acquired from its linked IoT devices, resulting in lower network use. Despite the scarce number of resources available at fog nodes, the burden is distributed among all fog nodes, resulting in decreased bandwidth usage. As a result, fog-based computing could be a great way to meet the QoS demands of real-time systems such as health monitoring. It is clear that the novel low-latency and energy-efficient task scheduling framework for the Internet of Medical Things in an edge-fog-cloud system can be used for many applications such as Vital Sign Monitoring [44], Smart-Contract-Aware Ethereum [45], hospitals and medical enterprises [46], Accelerating Edge Intelligence using Integrated Sensing [47], and a POMDP approach for age-of-information-based scheduling in multiuser uplinks with stochastic arrivals [48].
It can be seen that in the proposed EEIoMT, when the percentage of n 70%, the energy consumption is as low as possible because we are focuse ing energy while meeting their deadlines. In the other models, slight ch served in energy consumption, latency, network usage, and CPU usage tasks are not categorized and given priorities, as is implemented in framework, and therefore, changing the percentages of these tasks w change the values of any of the performance metrics in other models.
The results for the performance metrics of latency, energy consump usage, and CPU usage are shown in Figures 24-27, respectively.           Regarding latency, energy consumption, and network usage, the suggested EEIoMT framework outperformed CHTM, LBS, and FNPA. The proposed fog-based health monitor-ing system will be able to process a high number of patient requests in a timely manner thanks to the proposed EEIoMT, which will assist patients, healthcare workers, and medical caregivers. People will be able to check their health condition at home and only need to see their doctor if their health status is critical, reducing the strain on clinics and hospitals.

Conclusions and Future Work
In recent years, the health field has received great attention due to the spread of the Coronavirus, which in turn has placed great pressure on hospitals and medical staff. Thus, the role and importance of healthcare applications in remote monitoring have greatly increased. In order to protect the elderly from this virus without direct interaction with medical staff who could transmit this virus to them, they can be monitored with the help of remote monitoring systems to prevent permanent stays in the hospital for monitoring. Therefore, the number of gadgets employed in these applications will rise, generating huge amounts of data. Using the cloud only causes delays while transferring information from sensors to the cloud and from the cloud to hospitals or caregivers. Fog computing, which sits between end-users (IoT devices) and cloud computing, was suggested by Cisco in 2012. Fog computing is not a replacement for cloud computing; rather, it mitigates cloud computing's drawbacks and improves its efficiency. At the network's edge, it also delivers storage and computational functions. Although fog computing is utilized in real-time healthcare applications, there are still limitations on response time, latency, and energy consumption. Although some researchers have proposed scheduling algorithms to overcome these limitations in a fog computing environment, there is still a gap in task scheduling regarding the time response and the amount of energy consumed. Most of the algorithms assign all incoming tasks coming from IoT devices to the nearest fog node without giving them priorities and without regard for the load on the fog nodes.
This research mitigated these limitations by proposing an EEIoMT framework. This framework consists of three algorithms for efficient task scheduling to ensure that critical tasks are executed in the shortest possible time within the deadline while balancing energy consumption when processing other tasks. In our architecture, ECG sensors are used to monitor heart health at home in a smart city. The ECG sensors continuously send the sensed data to the ESP32 through BLE. The ECG signals are analyzed in the ESP32 microcontroller, which is also connected to the fog scheduler via Wi-Fi connection to send the analysis results data (tasks). The appropriate fog node is carefully selected to perform the task by giving each node a special weight based on the expected amount of energy consumed and latency in performing the task and choosing the node with the lowest weight.
The proposed algorithm was assessed utilizing the iFogSim2 simulator. The simulation outcomes show that our framework, in comparison with the CHTM model, decreases the latency by 59%, energy consumption by 61%, and network usage by 57%. When compared with LBS, it reduces the latency by 60%, the consumption of energy by 62%, and the network usage by 64%. In comparison with FNPA, it reduces the latency by 62%, energy consumption by 63%, and network usage by 65%. The results indicate that the suggested framework has superior performance in decreasing energy consumption, latency, and network usage when contrasted to CHTM, LBS, and FNPA.
In the future, an enhancement to the framework is needed in order to process more types of vital signs simultaneously. In addition, the proposed framework will be applied in other real-time applications in addition to healthcare applications. Furthermore, the suggested algorithm needs to be tested on larger and more diverse data with real equipment if possible.  Data Availability Statement: In this research, the data were taken from the Cleveland dataset, which is freely available online at http://archive.ics.uci.edu/mL/datasets/arrhythmia (accessed on 16 January 2022).

Conflicts of Interest:
The authors declare no conflict of interest.

T
Set of tasks n Number of tasks t i Task i ∈ T TS i Task size of task t i TL i Task length of task t i type i The type of task t i , which is normal, moderate, or critical dt i The deadline of task t i to be respected for completing the task F Set of fog nodes m Number of fog nodes in the system f j Fog node j ∈ F S j Storage capacity of fog node f j CC j Computing capacity of fog node f j E j Total battery capacity of Fog node f j X ij A binary variable determining whether t i is assigned to f j or not X icloud A binary variable determining whether t i is assigned to the cloud or not Et X ij Execution time of processing task t i on fog node f j Et(X icloud ) Execution time of processing task t i in the cloud CC cloud Computing capacity of the cloud T r t(FS) The transmission time of task t i to the fog schedule BW The transmission rate of the task to be sent from one node to the other T r t X ij The transmission time of task t i from the fog scheduler to fog node f j T r t(X icloud ) The transmission time of task t i from the fog scheduler to the cloud T r t total X ij The total transmission time of tasks from the ESP32 or smartphone to fog node f j T r t total (X icloud ) The total transmission time of tasks from the ESP32 or smartphone to the cloud RT X ij The response time of tasks t i that are processed in fog node f j RT(X icloud ) The response time of tasks t i that are processed in the cloud E tr X ij The energy required to transmit task t i to fog node f j E tr (X icloud ) The energy required to transmit task t i to the cloud λ Constant related to the wireless interface E p X ij The energy consumption for processing task t i on fog node f j E p (X icloud ) The energy consumption for processing task t i in the cloud µ The coefficient denoting the energy consumption per CPU cycle E total X ij The total energy is calculated by a combination of processing energy and transmission energy for fog E total (X icloud ) The total energy is calculated by a combination of processing energy and transmission energy for the cloud X assign The weight assigned to fog node f j N WSM−score ij The QoS score of X ij w E The weight factors related to the energy consumption in a selected node w L The weight factors related to the latency in a selected node CT The completion time RU Resource Utilization