Fig. 2.2 Number of published papers by year for MCC, MEC, EC, and FC the EC attracted the attention of academia and industry. The pace of it might not keep up with EC and FC as the name was currently changed to Multi-access Edge Computing (MEC) to include a wider variety of devices [138].
2.2 Mobile Computation Offloading
Offloading computation from a weaker device to a more powerful server is not a new concept. The first attempt to conserve the energy consumption of laptops was introduced by offloading larger tasks to fixed surrogates [114]. Then, the concept of cyber-foraging was termed in [10] for offloading parts of applications from mobile devices to nearby discovered servers. Computation offloading either fully or partially migrate the resource-heavy parts of a mobile application to nearby resource-rich surrogates such as computational clouds. Computation offloading not only conserves the usage of local resources such as memory, battery, and storage but also enables execution of computation-intensive applications in mobile devices.
MCO is a mechanism to enable mobile devices to run mobile applications that require extensive computation and communication [84]. It extends battery life by moving the computation-intensive portions of the application to external resources with greater computation power. In addition, it decreases latency and communication costs by using single-hop proximity to nearby devices [49]. This improves the user experience, especially in highly interactive applications that
Fig. 2.3 Computation Offloading Process Overview [4]
require high bandwidth and low latency. Figure 2.3 illustrates the environment that supports computation offloading. In this overview, the mobile device decides to offload method B to a cloud server or a powerful machine. The cloud here provides virtual computation resources to run the offloaded components. It can be another device, a server or cluster in a nearby location or a virtual server in the public cloud datacenters.
To enable computation offloading, an offloading client needs to be running on the Host Mobile Device and an offloading server in the external resources. They need to be able to communicate for coordinating the offloading operation. After the application starts executing, the invoked task that has been identified as offloadable will be passed to the offloading client. The offloading client can either follow the "always offload" scenario where every invoked task will be offloaded, or an offloading runtime decision is made (based on a comparison of local and remote execution times or energy consumption) before transferring the task to the offloading server. Any other metadata (invocation parameters, resource files, etc.) will also be provided to the offloading server. The offloaded component starts executing and communicates directly with the mobile app for sending back the results of the remote execution.
Since offloading migrates computation to a more resourceful computer, it involves deciding whether and what computation to migrate. A vast body of research exists on offloading decisions for (1) improving performance and (2) saving energy. The offloading decision making is the bottleneck and the most prominent part of the mobile computation offloading process. This offloading decision making process is being affected by more than a factor [76]. The four
2.2 Mobile Computation Offloading 25
aspects of offload decision making are studied in mobile cloud offloading scenarios [152].
When to offload: an optimal offloading decision has to be made at the right time to offload under different conditions of the device, such as available bandwidth, amount of data to be transferred, and energy to execute.
What to offload: in dynamic mobile environments, full offloading is not always beneficial, so choosing the right component to offload by splitting a specific application into local and remote parts is also important.
Where to offload: since mobile devices are surrounded by multiple offloading sites, it is essential to find the optimal site in which the computation to be offloaded under different cloud resource conditions.
How to offload: Due to the heterogeneity of communication networks available between the mobile device and cloud resources, the right path to offload needs to be determined.
2.2.1 Adaptive Offloading
A system is considered being adaptive if it is designed to continuously monitor its environment and then modify its behaviour in response to changing environmental conditions [15]. Mobile computation offloading systems are affected by wireless network characteristics and the capabilities of available external resources. The workload also varies depending on the applications that are running on the mobile device. For designing an effective offloading system, a range of environmental variables such as bandwidth variation, intermittent connectivity and user expecta- tions need to be considered [15]. User expectations need to be incorporated into the architecture of the offloading system. The different parameters that are set by user preferences need to be defined in the deployed mobile application.
In mobile computation adaptive offloading, the system needs to implement sufficient and accurate change detection mechanisms to detect the changes in the dynamic environment. It has to be responsive to the changes and ensure a fast, accurate, user transparent, and low overhead techniques for change detection. The quality-aware opportunistic response mechanism can be implemented by employing adaptive techniques for using the available resources and by implementing high- quality degradation of the execution when network connectivity is lost or another failure occurs. The authors of [74] propose a lightweight application partitioning mechanism to achieve seamless computational offloading. The partitioning decision
is transformed into an optimization problem and solved by the optimization solver. Various performance parameters are used to fix application-based partitioning of Android applications. Android services use Inter-Process Communication channels to perform Remote Procedure Call (RPC), the middleware intercepts the requests sent to the services and decide whether the request will be sent to local or cloud services. It reduces local execution time by considering multiple environment variables in the cost function of the optimization problem including data transfer cost, CPU cost, and memory cost of the mobile device. The constraints are related to minimization of memory usage, energy usage, and execution time. A formal description and modelling of these variables will be presented in Chapter 4.
2.2.2 Multisite Offloading
There are different ways to classify current mobile computation offloading frame- works in the literature. Existing surveys and analysis studies are either based on mobile cloud application models and offloading objectives [143], challenges in designing future mobile cloud applications [150], application partitioning (how the tasks are identified for offloading) [128] [85], or context-awareness [103]. We use cloud resource types as our classification methodology by focusing on infrastruc- ture destinations for offloading. More precisely, answering the question of "where to offload" in mobile cloud offloading aspects [152].
There are numerous mobile computation offloading frameworks and mecha- nisms in the literature that aspire offloading of mobile tasks to a single or multiple servers in the same architecture tier. We consider this type of offloading to be a “Single Site Offloading” mechanism. The offloading process could be between the host mobile device and datacenter cloud servers over WAN communications through the Internet. Other works introduced Cloudlets in the LAN of the mobile device to solve the high latency issues associated with offloading to distant cloud servers. Moreover, some researchers considered using mobile devices as both service consumers and service providers in the formation of MACs.
The solutions that address offloading mobile applications to Remote Clouds use an infrastructure-based approach which refers to public cloud services including IaaS, PaaS, and SaaS. The mobile device offloads its computation to public cloud services via WiFi or cellular networks. Some solutions use an image of the mobile device operating system hosted in the cloud servers, forming a one-to-one relationship, such as in CloneCloud [31]. Other approaches of remote cloud-based offloading include MAUI [35], ThinkAir [73], Odessa [108], COSMOS [123], and Cuckoo [69].
2.2 Mobile Computation Offloading 27
As per the description in Section 2.1.1.1, cloudlets are trusted and resourceful computers deployed as middle layer servers between mobile devices and remote cloud servers to reduce latency and improve the mobile application performance. It was originally introduced by Satyanarayanan et al. [120] followed by enormous works such as [147] [48] [26].
Nearby Mobile Devices can form an ad hoc cloud among themselves using either Mobile Ad-hoc NETwork (MANET) through short-range wireless networks such as WiFi-direct and Bluetooth in dynamic topologies, with no support of networking infrastructure or infrastructural WiFi using Zero Configuration Net- work technologies [30]. Nearby local mobile devices can provide an even lower latency for computation offloading in case cloudlets or public cloud servers are out of reach of the Host Mobile Device. The most notable works in this category include Hyrax [90], Scavenger [75], Serendipity [124], and Cirrus [122].
Fig. 2.4 A Proposed Multisite Offloading System Architecture [112] With the increase in the number of heterogeneous devices all around us, future computation offloading architectures with multi-tiers will become relevant. As an example, we can contemplate a smartwatch which is connected to a smartphone via Bluetooth. The smartphone can be connected to a cloudlet in the vicinity via WiFi or to an edge server in the mobile operator base stations using cellular networks. The cloudlet or the edge server are also connected to a cloud datacenter via a fixed network. In such an n-tier system, the heterogeneous devices differ significantly in terms of energy, computation, and communication resources, increasing typically from the very limited (tier 1: smartwatch) to the virtually unlimited (tier 4: cloud servers).
In the next chapter, existing papers, publications, and frameworks in multisite offloading are presented and reviewed and a taxonomy of the primary studies is constructed.