TEMS: An Algorithm to Minimize Energy Consumption and Elapsed Time for IoT Workloads in a Hybrid Architecture

Advances in communication technologies have made the interaction of small devices, such 1 as smartphones, wearables, and sensors, scattered on the Internet, bringing a whole new set of complex 2 applications with ever greater task processing needs. These Internet of Things (IoT) devices run on 3 batteries with strict energy restrictions. They tend to o oad task processing to remote servers, usually 4 to Cloud Computing (CC) in datacenters geographically located away from the IoT device. In such a 5 context, this work proposes a dynamic cost model to minimize energy consumption and task processing 6 time for IoT scenarios in Mobile Edge Computing environments. Our approach allows for a detailed cost 7 model, with an algorithm called TEMS that considers energy, time consumed during processing, the cost 8 of data transmission, and energy in idle devices. The task scheduling chooses among Cloud or Mobile 9 Edge Computing (MEC) server or local IoT devices to better execution time with lower cost. The simulated 10 environment evaluation saved up to 51.6% energy consumption and improved task completion time up to 11


Introduction
International Data Corporation (IDC) report appoints there will be 41.6 billion IoT devices 16 up to 2025 with a potential for data generation up to 79.4 ZB [1]. In such a context, IoT 17 applications have evolved the use of arti cial intelligence, arti cial vision, and object tracking, 18 which require high computing power [2,3]. They usually rely on task processing o oad and 19 data storage to remote Cloud Computing (CC) Data Centers to boost processing time and 20 reduce battery energy consumption [4]. Unfortunately, those remote servers are geographically 21 located away from the end-user and IoT device, resulting in high latency due to delay and 22 congestion over the communication channels [5][6][7]. Moreover, the use of a centralized control 23 (provider-centric) cannot deliver proper connectivity or even support computation closer to the 24 edge of the network, thus becoming ine cient for highly distributed scenarios. 25 Mobile Edge Computing (MEC) can represent an option to increase the performance of CC 26 applications, as it denotes a network architecture designed to provide low latency with adequate 27 Quality of Service (QoS) to end-users [8,9]. Besides, MEC relies on top of high-speed mobile 28 networks such as 5G to allow fast and stable connectivity for mobile devices and users. Thus, resource allocation with the more inexpensive cost for executing tasks. A simulator has also 48 been developed for the MEC evaluation with IoT devices and associated CC resources. The

49
TEMS algorithm gathers data about the environment and associated energy and time costs to 50 decision-making about the task scheduling. MEC Simulator is available at https://github.com/ 51 jlggross/MEC-simulator. 52 The main contributions of this work are: The methodology covers a considerable number of energy and time metrics for task 54 processing and data transmissions, including the accounting of CPU cores idle energy 55 consumption; 56 ii) The CPU processing time and energy consumption optimization using DVFS technique; 57 iii) The scheduling policies consider task processing in the IoT device itself, in a local MEC 58 server, and in a remote Data Center from CC at the same time; 59 The remainder of this paper is organized as follows. Section 2 discusses previous related architectures [18]. However, the strategic use of CC as the only alternative to task processing 71 adds higher latency to IoT applications [19]. 72 Few proposals use CC as an option to task execution [11,20,21]. Other approaches use Fog

75
TEMS is a three-layer architecture that combines MEC and CC added to local IoT computation.

76
This approach also provides a cost model, with the energy and run time evaluations on the y, 77 including the data transmission costs.

78
As for the parameters used in third-party cost models, the energy consumption of task 79 processing is used by all works mentioned. However, the energy consumption for data trans-80 missions is shown in the works [4,[12][13][14]. The processing time of tasks is evaluated in major of 81 the works, except to [22,24] and the spent time on data transmissions is limited to studies of 82 [4,[11][12][13]21].

83
On the other hand, the energy consumption of the equipment in the idle state is measured 84 exclusively in [22,24]. Models that include the battery level of the IoT devices are only [4,12,13].

85
Our proposed model uses the DVFS technique [15,16] to allow both the dynamic minimization 86 of energy and execution time during task processing.

87
All these execution time and energy consumption variables are consolidated in our model.

88
A monitor for battery levels of IoT devices allows rational energy consumption. or Fog, or Cloud environments. This is a multiple-objective optimization problem. Therefore, 95 nd a minimal cost to all these system variables is an NP-Hard problem.

96
The solution must consider the energy consumption, such as the computation variables, 97 energy to send tasks, energy consumption to data download, energy for the task processing, 98 energy cost with CPU idle, and battery level. Also, it requires estimating the execution time to 99 variables, like time spent on task transmission, wait time in queues, task runtime, and time spent 100 on downloads. Simultaneously, the system must choose one among three distinct environments 101 to produce the best performance considering energy optimize.

102
Thus, the computation to solve these issues is hard to model. Deciding between three 103 di erent environments is another complex task due to needing to produce good data and task 104 distributions. We propose a dynamic solution in real-time for each task using an Integer Linear 105 Programming (ILP) optimization to achieve this challenge. This section introduces the model to minimize cost dynamically.  The generated results forward back to the origin. t The deadline associated with the task. W The number of wireless channels.

A
The task set that will be executed.

PS
A processor in the MEC server. f mec Frequency of one core in a MEC server processor. C mec E ective commutative capacitance in a processor in the MEC server.

V mec
Voltage in the MEC processor device. g (S l ,j) Channel gain between the local MEC server and the mobile device. P i,mec The Consumed power in MEC server.
The dynamic energy consumed in MEC server. Cost i,mec The total cost in MEC server.
The model associates the cost in terms of energy consumed and elapsed time for the 122 allocation policy of each layer, taking into account task processing and data transmissions costs.

123
The DVFS technique is used to calculate processing costs, proving the best pair of CPU core 124 voltage and CPU core operating frequency that reduces total cost. Finally, the TEMS scheduler 125 seeks the best cost among all three allocation policies and selects the lowest one. The scheduler 126 decides between MEC and CC layers to o oad a task. Otherwise, the processing takes place on 127 the device itself.

128
The rest of this section covers an extension of the cost model previous work shown in [26]. 129 First, it is introduced assumptions about the network and the architecture components. After  Figure 1. Each task represents a tuple A i = (C i , sc i , d i , t i ) composed of CPU cycles needed 137 to conclude an execution (Cc), the source code (sc), the input data (d), and the deadline (t) 138 associated with the task. The deadline associated represents if a task is normal (t = 0) or it is 139 critical (t > 0).  Each mobile device has a respective number of CPU cores (PL j = {pl j,1 , pl j,2 , ..., pl j,n }).

145
The energy consumption in idle time is computed in Equation 1 based on a total number of 146 CPU cycles (Cc i ), operating frequency ( f local,j,k ), voltage supply (V local,j,k ) and in the e ective 147 commutative capacitance (C local,j,k ) of each core, which dependents of the chip architecture 148 [21]. Equation 1 computes the local dynamic energy consumed by the IoT device.

149
The total execution time of task is calculated based on total cycles C cT i [27] where i ∈ A 150 to a CPU core j ∈ PL in Equation 2. The dynamic power consumed during the execution is Where, Considering battery level and latency as model constraints, a device D j must decide 153 whether it is more appropriate to process the task locally or remotely. As the battery level 154 is a critical factor in the decision, the system will appreciate a policy that reduces energy 155 consumption. The local cost of one task i is expressed in Equation 4.
The coe cients u localT ∈ [0, 1] and u localE ∈ [0, 1] are weightings, where u localT + 157 u localE = 1. These variables represent a trade-o between execution time and energy consump-158 tion and minimize one of the costs, according to Wang et al. [4]. local server S j are given by PS j = {ps j,1 , ps j,2 , ps j,3 , ..., ps j,n }. Each core ps j,k has an operat-

164
IoT devices and MEC servers cause mutual interference between each other (I i ) because 165 they use the same wireless channel. Thus, the data transfer rate (r(h i )) to o oad task i to the 166 channel (h i ) attenuates according to Shannon's formula [21]. The data transfer rate is determined 167 in Equation 5 and the mutual interference between wireless channels is computed in Equation 6.

171
In the local server, data and source code need to be sent to the application processing, and 172 the generated results must be sent back to the origin. Thus, the time required for an IoT device can be computed as.
The total time required to complete the task execution in the local server considers the .
The energy spent for the data communications from the IoT device to the local MEC server Moreover, the cost computation for the local server is expressed in Equation 11.
Finally, the cost to run a single task i in the Cloud is given in Equation 18 as. 195 The idle energy cost of CC is not considered, since the CPU o er is virtually in nite.

196
Therefore it does not make sense to account for this cost, which would cause the system to have 197 equally in nite cost.

198
For every task i the minimum cost is chosen between all three allocation policies, one from 199 each layer, as in Equation 19.
The total system cost, represented by Equation 20, is equal the sum of all task costs plus 201 the idle energy of CPU cores from IoT devices and from MEC servers.
202   Step 3 monitors the task completion status. When one task was completed, the CPU core The TEMS algorithm complexity analysis considers the four steps in Algorithm 1. The 237 task of information collection and system setup occur a single time in the system setup. This 238 step identi es "n" mobile devices added to the network, and it has "m" processor cores. There 239 are a total of "n" local MEC servers with the "m" core processors and a number of "n" wireless 240 network channels to "n" tasks with a tuple of four variables each. The algorithm must choose 241 among "n" possible options with three variables each and nine coe cients to the cost equation.

242
Thus for step 1, the complexity is as in Equation 21.
However, as the smartphone nowadays has a limit of eight cores. Also, simple IoT devices, developed with Python programming, and the Python sorting executes three times. Thus, the 254 complexity for step 2 is described as in Equation 22.
Thus, the step 2 has a complexity O(n 2 ).

256
Step 3 has n interactions of simple tasks, so O(n), and step 4 seeks the battery level in n 257 IoT devices, i.e., O(n).

258
Hence, considering all TEMS algorithm steps and exchanging these steps by respective individual complexity as in Equation 23.
Therefore, the TEMS Algorithm complexity is O(n 2 ).

260
This section explains the simulation details and the di erent experimental scenarios used.  with and without Turbo Boost, respectively.

275
The network throughput was con gured to achieve up to 1 Gbps speed and latencies to 5ms, 276 for both 5G and ber optics communications [29] [30]. Moreover, two vehicular applications 277 were de ned [31], one with high processing workload and high task creation time (Application 278 1), and another with low processing workload and low task creation time (Application 2).

279
Application 2 creates more tasks than Application 1 in the same time interval, but each task has 280 lower processing requirements. Table 3 shows the characteristics of each application.

282
The tested scenarios used di erent con gurations for parameters such as the computational  in Table 3. The tested scenario has 500 tasks distributed to 100 IoT devices in two di erent 291 cases, one with a single MEC server, in Figure 2. The energy and time coe cients were set, respectively, to 4/5 and 1/5, that is, a high 295 weight was given to the energy consumed so that it could be minimized. In Figure 2  from one to two, which made fewer tasks be to allocated in the CC layer. This positively impacts 298 the total energy consumed because tasks running in the MEC layer demand less energy when 299 the workload is higher. However, when the workload is composed of little tasks with a high 300 transfer rate, the scheduler tends to maintain all tasks nearest from devices due to deadline 301 restrictions.
302 Table 4 shows the relationship between the number of MEC Servers related to energy 303 consumption. When comparing cases A and B with a third case C with no MEC servers, the 304 reduction in energy consumption for case A was 42.51%, while for case B 44.71%. In case C, 305 tasks are just o oaded to the Cloud, adding too much energy consumption to the system. Thus, 306 the use of MEC servers helps the system to lower the total energy consumed. With Application 2, that has lower workload compared to Application 1, the allocation   Our analysis indicates that low battery levels quickly reach LSL and make IoT devices 326 unavailable for processing. High computational workloads also negatively a ect the battery 327 level. Therefore, a battery with a healthy energy level and adequate task processing workloads, 328 allows the allocation to be performed on the IoT device, without making it unavailable due to 329 lack of battery, contributing to total cost reduction.   We also designed two other cases, one with 5,000 tasks and 362 MB per task and another 344 with 500 tasks and 3.6 GB per task, with roughly 1.8 TB in total each.    In this experiment we chose Application 2 to execute on four scenarios, with task generation 369 rates of 0.05, 0.1, 0.2, and 0.3 seconds. All scenarios were con gured with 500 tasks, 100 IoT 370 devices and 1 MEC server. Figure 5 shows that small task generation rates ood the network 371 with tasks, rapidly consuming all local resources. As an e ect, TEMS allocates the majority of 372 tasks to the CC layer, even though time and energy costs are higher, because no local CPU core 373 is available. Although, when task generation rate increases, tasks enter the network in more Task generation rates should be designed with a time interval that favors usage of local 377 resources, which may help reduce total costs depending on the application and the costs of each 378 allocation policy.

379
By con guring deadlines with very restrictive time limits, the experiments showed that 380 critical tasks were canceled because the scheduler could not nd an allocation policy to achieve 381 task completion. To avoid this behavior, deadlines must be appropriately con gured so that at 382 least one allocation policy has su cient time to process and complete the task correctly.