Preference-Aware Computation Offloading for IoT in Multi-access Edge Computing Using Probabilistic Model Checking

Abstract

A key cornerstone of Multi-Access Edge Computing (MEC) is an offloading policy utilized to determine whether to execute computation tasks on IoT devices or to offload the tasks to MEC servers for processing. In this work, we propose a Probabilistic Model Checking based offloading policy catering to device user preferences. We model the interactions between the various components of the MEC environment using a Turn-Based Stochastic Multi-Player Game (SMG). We present experiments on practical scenarios on data gathered from a test-bed setup with benchmark applications to show the benefits of an adaptive preference-aware approach over conventional approaches in MEC offloading.

Appendices

A Battery Model

We use a battery model ($4 \mathrm {~V}, 2,000\,\textrm{mAh}$) which is representative of IoT devices. Further, we consider an effective battery energy $(28,800 \mathrm {~J})$ which has been utilized in several previous studies [32, 34, 40].

Battery Energy: For predicting the battery energy pattern, we consider the discharging cycles using the models utilized in several real-world studies. For estimating the remaining battery energy and SOC in smartphones during discharging, we use a discharging model [32]. For an accurate calculation of available charge, the model takes into account the rate capacity effect in batteries. According to the rate capacity effect of batteries, charging and discharging efficiency fall as charging and discharging currents increase [32]. Over each discrete time slot, we calculate the battery energy by monitoring the device’s instantaneous power consumption and discharging current E using:

$$ E(t+\varDelta t)=E(t)-E_{c}, $$

where $E_{c}$, the energy consumption $(\textrm{J})$ over one cycle $(\varDelta t)$, is given by

$$ E_{c}=\varDelta t \times P_{\text {device}}+E_{\text {loss}}, $$

where $\varDelta t$ denotes the time duration of each cycle (in second) and $P_{\text {device}}$ is the total power consumption (Watt) of the device during $\varDelta t$. In the work in [34], the authors demonstrate generation of individual power characterization of workloads on specific cores (such as the LITTLE and BIG cores) of IoT devices. We assume that such a characterization is available a priori. Thus, the value of $P_{\text {device}}$ is calculated in accordance with the power characterization depending on where the task is executed. In our work, $P_{\text {device}}$ refers to the average power consumption. $E_{\text {loss}}$ is the internal loss of the battery, caused by the rate capacity effect and is calculated by

$$ E_{\text {loss}}=\varDelta t \times \left( i_{b}^{2} R_{\text {total}}+i_{b} \cdot v_{O C} \cdot \left( 1 / \eta \left( i_{b}\right) -1\right) \right) , $$

where $i_{b}$ is the discharging current (amp) of the battery, $R_{\text {total}}$ is the total internal resistance (ohm) of the battery, $v_{O C}$ is the open circuit terminal voltage (volt) of the battery, and $\eta \left( i_{b}\right)$ denotes the battery discharging efficiency, which can be approximated as $1 /\left( \left( i_{b}\right) ^{k_{d}}\right)$, where $k_{d}$ is the parameter representing the Odroid platform utilized in [32]. $R_{\text {total}}$ and $v_{O C}$ are calculated using

$$ \begin{array}{c} R_{\text {total}}=b_{21} e^{b_{22} v_{\text {SOC}}+b_{23}} \\ v_{O C}=b_{11} e^{b_{12} v_{\text {soc}}}+b_{13} v_{\text {soc}}^{4}+b_{14} v_{\text {soc}}^{3}+b_{15} v_{\text {soc}}{ }^{2}+b_{16} v_{\text {soc}}+b_{17}, \end{array} $$

where bij are regression coefficients, and $v_{S O C}$ is the voltage representation of the battery SOC, that is,

$$ v_{S O C}=C_{b} / C_{b, f u l l} \times 1 \mathrm {~V}, $$

where $C_{b}$ is the remaining charge in the battery, and $C_{b, f u l l}$ is the battery charge when it is fully charged. Note that we utilize energy consumption in our model. The State-Of-Charge is related to the energy consumption as follows:

$$ {\text {SOC}}(t+\varDelta t)=\frac{E(t+\varDelta t) \times 100}{E_{T}} $$

The State-Of-Charge is an important factor in influencing battery life and ageing, according to [32]. Battery capacity declines with use over time owing to the loss of active components, which is known as battery ageing. As a result, in this paper, we present an offloading strategy based on the battery model used in [32]. The chosen model mimics capacity decline over time using average energy and temperature as input. In the next subsection we discuss the model of temperature utilized in our work.

Battery Temperature Model: In this paper, we employ a battery thermal model similar to the model employed in [32] that represents an IoT device. Thermal coupling between the battery and the CPU is taken into account in this model. The thermal coupling effect between the battery and the CPU plays a major role in determining the battery temperature in smartphones due to the tiny physical area. As a result, one part of a smartphone’s thermal behaviour is not independent of the other. Furthermore, the CPU’s thermal behaviour is strongly influenced by the application services that are running. By monitoring the power utilized by the CPU we can estimate the battery temperature in an indirect manner. The detailed model is presented below:

$$ \begin{aligned} T_{b a t}=&\, T_{e n v}+\frac{R_{c p u-e n v} R_{b a t-e n v}}{R_{b a t-e n v}+R_{c p u-b a t}+R_{c p u-e n v}}. P_{c p u} \end{aligned} $$

where $T_{b a t}$ and $T_{e n v}$ are battery and environment temperature, $P_{c p u}$ and $P_{b a t}$ are CPU and battery power consumption, and $R_{i-j}$ is the thermal resistance between i and j, where i and j can be CPU, environment, and battery. The value for these resistances are utilized from [32]. The above energy and thermal models can be replaced by any other model, as our framework is designed in a modular and replaceable manner.

B Experimental Setup

Workload: To the best of our knowledge, there are no real-world MEC implementation workload traces that are publicly available and sufficiently representative of our problem context. Therefore, for our experiments, we generate synthetic workloads using real-world applications from the Mibench benchmark [10, 32]. The Mibench benchmark suite provides benchmarks in various categories of standard applications ranging from sensor systems on simple microcontrollers to smartphones and desktops. Table 4 summarises the Mibench programmes utilised in this setup. The applications we employ in this research are in the network and security categories, both of which are pertinent to and reflective of IoT applications.

Fig. 9.

Comparative Computation Running Times for Combinations of Applications on the MEC server, LITTLE core and BIG core respectively

Table 4. Mibench benchmark applications used in this work

Data Gathering: We utilize the applications described in Table 4 to characterize the running times of various tasks of the applications. We utilize the executables of the Mibench benchmark as application tasks. We utilize these running times to simulate the MEC-IoT setup. We first consider a random number of applications between 2 and 4 and execute these applications simultaneously. We consider three measurements: a) by running the applications simultaneously on the MEC server b) by running the applications simultaneously by setting the processor affinity to the “LITTLE” cores and c) by running the applications simultaneously by setting the processor affinity to the “BIG” cores. Figure 9 depicts the runtimes for the various scenarios and the corresponding application scenarios utilized with a combination of the Dijkstra, Patricia, Quick Sort and Sha applications. Each combination of applications is executed 100 times. Figures 9a, 9b and 9c depict the variations in runtimes for the different combinations of applications for 100 different executions. As can be inferred from the figures, even for the same type of application combination, for example, Dijktra and Patricia, there is a variation in the runtimes depicting the stochastic nature of application execution runtimes. Additionally, note that there is a variation in the runtimes depending on whether the application is executed on the MEC server or locally as well as on the type of core when executed locally. These variations depict the impact of the hardware specifications on the runtime of application tasks. Prior work [44] has proposed that it is possible to effectively predict the combinations of applications utilized given a specific time of day as well as locality. Our methodology is thus based on such a premise. We assume that such a characterization involving a combination of applications can be derived a priori and utilizing the setup described above their running times can be determined for a specific set of hardware. We utilize these runtimes as the values of latencies (measured in seconds) to generate the DTMC model of the Task Execution Latencies as explained in Sect. 4.3.

1.1 B.1 Simulation Setup

We simulate the MEC scenario by considering an IoT device executing tasks. Upon task execution, the models are initialized into the Probabilistic Model Checker PRISM-Games [13] along with the IoT device preference¹ The model checker returns the strategy. Each discrete time slot is then simulated by executing the strategy as returned by PRISM-Games and the data gathered from the above set of experiments is used to sample the stochastic nature of task execution times. Additionally, in the simulation, the battery energy and temperature are updated according to the models described. Our simulation thus implicitly assumes that an accurate model of the energy and thermal dynamics of the MEC ecosystem is available. However, note that our SMG based model can be utilized with any other battery and energy model as well thus providing a generic approach. We simulate the MEC scenario by considering a single IoT device since the offloading scheme is identical whenever each IoT device executes a task. When the task is executed at the MEC server, the computation time distribution is obtained by considering the running times of a combination of applications. Such a setup thus simulates several applications running on the MEC server simultaneously.