Previous research efforts have been using the MCO approach such as CloneCloud [31], MAUI [35], and ThinkAir [73] due to the capability of an application to either run locally on a mobile device or to offload some of its computationally expensive tasks to be executed outside the mobile device when a connection is available. Since a mobile application can contain parts of the code which must be executed locally (unoffloadable tasks) such as codes that access local sensors (e.g. GPS, camera), it is not recommended to offload the entire application code [50].
4.4 Offloading Policy 65
Moreover, the task offloading cost (e.g. battery consumption, delay time) may outweigh the offloading benefits. Thus, deciding whether to offload and where to offload are continuous challenges in the task offloading policy.
In constructing a multisite task offloading policy, the single-site scenario offloading where only a single candidate offloading site is available at the time of offloading needs to be considered as well. Deciding whether the task is worth offloading and where to offload the task can be computed under these different circumstances.
For deciding whether the task has to be offloaded, one way is to compare profiling results of the local and remote executions for identifying the offloading cost. However, this creates an extra overhead before every offloading operation [76]. Instead, benchmarking the sites and profiling the network status can be used to calculate an offloading score as described in Subsection 4.4.2.
In an ideal multisite offloading scenario, the Host Mobile Device is connected to more than a site at the time of running the application containing the offloadable tasks. By checking the number of Sj connected candidate offloading sites, the
list of sites will be passed to the multi-criteria solver component explained in Section 4.5.
4.4.1 Decision Making Algorithm
The context-aware decision algorithm needs to consider a set of contextual pa- rameters including the network throughput and wireless properties, hardware features of both the Host Mobile Device and connected nodes in the mobile cloud infrastructure. The algorithm needs to decide whether it is beneficial to offload.
With a single offloading site, the node with the highest calculated offloading score is passed to the deployment controller for remote execution. Otherwise, a fuzzy multi-criteria mechanism to decide which resources to use as the offloading locations are used. Finally, the algorithm returns a list of decision pairs containing
[Execution Location: Offloading Percentage]
The Algorithm 4.1 demonstrates the steps involved in offloading decision making. The illustrated symbols in Table 4.3 are used in the algorithm. The inputs include Self Node modelled earlier, the respective offloadable task Ti, and a
list of currently available offloading sites S. As described in the next chapter, the offloading execution database contains all the past offloading records, including both locally LR and remotely RR executed tasks. The checkpoint variables
Symbol Meaning LR Local Results RR Remote Results
MaxLE Maximum Local Executions MaxRE Maximum Remote Executions ExecLoc Execution Location
OffPer Offloading Percentage
Table 4.3 Task Offloading Decision Algorithm Symbols
are still beneficial. Finally, the node scores that were collected and calculated earlier are returned to the decision engine.
Every time an offloadable task is initiated, the engine determines if it is beneficial to offload it. Because of the uncertainties inherent in the mobile environment, the offloading decision takes risk into consideration. If a bad decision has been made, it will also adjust its strategy with new information available.
4.4 Offloading Policy 67 Algorithm 4.1 Task Offloading Decision Algorithm
Input: SN, Ti, S . Self Node, the offloadable task, list of offloading sites
LR, RR . From past offloading execution database records
MaxLE, MaxRE .Execution checkpoint variables Output: [ExecLoc: OffPer]
1: if Cost(Ti) < 0 then . According to Eq. (4.9)
2: return [SN: 100]
3: end if
4: if P RTi AND λ
Ti
m == 1 then . For parallizable tasks
5: return Score-Partitioner(S) . According to Algorithm 4.3
6: end if 7: for result in LR do 8: if result.taskID == IDTi then 9: localExecutions.add(result) 10: else 11: remoteExecutions.add(result) 12: end if 13: end for
14: if localExecutions % maxLE == 0 then . Max local consecutive executions
reached, fall to remote execution
15: return MC-Solver(S) . According to Algorithm 4.4
16: end if
17: if remoteExecutions % maxRE== 0 then . Max remote consecutive
executions reached, fall to local execution
18: return [SN: 100]
19: end if
4.4.2 Offloading Score
In calculating the offloading score, we need to collect the device context information in the pre-processing phase to model the offloading decision-making process including the CPU power, round trip time, battery state and level of the connected devices. The benchmark score is calculated after workloads are sent to the devices and the execution results are received. The quicker the tasks are completed, the higher the benchmark score. The workloads measure the instruction performance of the device by performing processor-intensive tasks that make heavy use of integer instructions. Initially, we create two types of workloads: compute-bound and memory-bound. Mandelbrot set [45] of an 800x800 pixels sample is used for
the first type. The Fast Fourier Transform (FFT) [68] is used as a memory heavy workload. The score is calculated based on an average of both runtime scores in GFlops as shown in Eq. (4.13).
B = (Bman+ Bf tt)/2 (4.13)
Since the collected values are on different scales, standardising variables are a necessary process. Standardization (or Z-score normalization) refers to the process of subtracting the mean from the value for each variable, resulting in a mean of zero. Then, the difference between each score and the mean is divided by the standard deviation [111].
The computation power and network overhead to Nearby Mobile Devices are initially collected. If Mobile Node is not currently charging, then the offloading score is deducted by the amount of the battery level of the device. The offloading score is then calculated using the following equation:
OSM N = (BM N+ CPM N) − RT TM N −(1 − BSM N) × (100 − BLM N) (4.14)
Similar to MAC model, edge and public node modelling is a summation of their respective benchmark score, computation speed subtracted by the data transfer cost.
OSEN = (BEN + CPEN) − RT TEN (4.15)
OSP N = (BP N + CPP N) − RT TP N (4.16)
MAMoC collects the offloading scores of the local device running the mobile application and all the connected service providers. Algorithm 4.2 shows the process of collecting individual offloading scores calculated and received earlier to generate a dictionary of nodes and their corresponding offloading scores.
4.5 Multi-criteria Solver 69