Operational issues refer to underlying technological matters such as the method of offloading computations, cost–benefit models that aid in taking the decision to offload or not, how the mobility of devices is managed/supported, and connection protocols used.
4.1.1. Method of offloading
The main operation in any mobile cloud would be the offloading of jobs that take place from the resource constrained mobile device to the cloud. Because of issues such as the physical distance separating the mobile device and the cloud and the heterogeneity of the underlying systems, different research has tackled this in a variety of ways. Current research discusses offloading methods in three main directions; Client–Server Communication methods, Virtualization, and Mobile agents.
Client–Server Communication. In the Client–Server Communication process communication is done across the mobile device(offloader) and surrogate device via protocols such as Remote Procedure Calls (RPC), Remote Method Invocation (RMI) and Sockets. Both RPC and RMI have well supported APIs and are considered stable by developers. However, offloading through these two methods mean that services need to have been pre-installed in the participating devices. This is a disadvantage when considering the ad hoc and mobile nature of a mobile cloud and restricts the mobility of users if in the vicinity of devices that do not support the needed services.
Spectra [27] and Chroma [28] are two examples of systems that use pre-installed services reachable via RPC to offload computation. Applications use RPC to invoke functionality in remote and local Spectra servers. When the device needs to offload an application, the Spectra client consults a database that stores information about Spectra servers such as their current availability, CPU load etc. These servers are pre-installed with application code acting as services. Developers need to manually partition the applications by specifying which methods might be candidates for offloading. Spectra decides at runtime depending on the resource pool, which of those aforementioned methods, if any will be offloaded and to which surrogate.
Marinelli [14] has presented ‘Hyrax’ for Android smartphone applications which are distributed both in terms of data and computation based on Hadoop9 ported to the Android platform. Hyrax explores the possibility of using a cluster of mobile phones as resource providers and shows the feasibility of such a mobile cloud. As a sample application, they present ‘HyraxTube’; which is a simple distributed mobile multimedia search and sharing program. The objective of HyraxTube is to allow users to search through multimedia files in terms of time, quality, and location. Apache Hadoop is an open source implementation of MapReduce [29] and provides a virtualized interface to a cluster of computers scaled randomly. In Hyrax, a central server with access to each mobile device coordinates data and jobs, and the phones communicate with each other on an isolated 802.11g network. Just like in a normal Hadoop implementation, Hyrax also has a NameNode and a JobTracker instance running on a central server with access to each of the client mobile devices. The central server does not do any of the processing, and is responsible for coordinating data and jobs. Each mobile phone runs instances of the DataNode and the TaskTracker in separate Android services. Additionally, each phone runs threads that stores the phones’ multimedia data on the Hadoop Distributed File System (HDFS) and threads that record sensor data. The TaskTrackers and DataNodes use a periodic heartbeat call through RPC to JobTracker and NameNode, and vice versa on heartbeat response. The heartbeat is sent from TaskTrackers to show the JobTracker that they are ‘alive’ and JobTracker can assign jobs in the response of this heartbeat.
Another framework based on Hadoop is presented by Huerta-Canepa and Lee [12], for a virtual mobile cloud focusing on common goals in which mobile device are considered as resource providers. They argue that people’s location plays a major role in their activities; hence, collocation leads to common activities, especially place bound tasks such as visiting a museum, and performing archaeological expeditions. The system’s Offloading manager module organizes sending and receiving jobs to and from other devices and creating virtual machines on surrogates. On a surrogate device, the tasks are executed on a virtual machine acting as a protected space thus ensuring the security of device data. The implementation was tested using a Korean OCR application. Their results do not show a speedup, however, though they suggest an energy saving, since the processing time is actually less than when executed on a single mobile device.
The ‘Cuckoo’ framework [30] presents a system to offload mobile device applications onto a cloud using a Java stub/proxy model. Cuckoo can be offloaded onto any resource that runs the Java Virtual machine, be it a commercial cloud such as Amazon EC210 or a private mini cloud comprised of laptops and local clusters. However, other mobile phones have not been mentioned as potential resource providers. Implemented for Android, Cuckoo’s offloading objectives are to enhance performance and reduce battery usage. The Ibis High Performance Programming System [31] is used as the basis for Cuckoo’s communication component. To use Cuckoo, the applications need to be re-written such that the application supports remote execution as well as local execution. For this purpose, a programming model, functioning as an interface of the system, is made available to application developers. The programming model uses the Android’s existing ‘activity/service’ model that separates the services (compute intensive methods that are candidates for offloading) and activities (interactive methods of the application). A proxy object is created at the activity which is linked to the actual implementation. Here, in addition to the normal local implementation, Cuckoo generates code for the same implementation for the remote service that may or may not be identical to the local one, since the remote version could be run on a multi-core computer for instance, and take full advantage of parallelism. If remote resources are not available (network connectivity is not available) then the application can run on local resources (the phone) entirely. They have re-implemented two existing applications ‘eyeDentify’ and ‘PhotoShoot’ in Cuckoo to demonstrate the effectiveness of the framework and report that they gained a speedup of a factor of 60 and reduced the battery consumption by a factor of 40 in ‘eyeDentify’ by offloading. Although they mention that they have gained considerable speedups for ‘PhotoShoot’ as well, exact figures are not mentioned. However, they do not provide a method to decide whether to offload or not. This has been included as a future research step, but for now, the framework always offloads by default if the phone can connect to a cloud of resources.
The Mobile Message Passing Interface (MMPI) framework [32] is a mobile version of the standard MPI over Bluetooth where mobile devices function as fellow resource providers. Instead of the typical star network structure of normal piconets, MMPI employs a fully interconnected mesh structure so that each node can communicate with the other. Tasks such as device discovery, and connections are handled by the libraries provided in the framework, eliminating the need for writing any Bluetooth specific code explicitly. The framework is implemented in Java and the third party library BlueCove [33] is used to handle Bluetooth operations. The master mobile device passes job parameters to the slave devices, which they then proceed to execute. As a sample application, they have tried with fractal generation over different devices (phones, laptops, PDAs) on cross-platforms and reported the time cost. However, they do not give the cost in terms of using just one machine (in the conventional way) so it is not clear what the speedup was. The setting up of MMPI system is in three steps: Device discovery, Service discovery, and Network formation. Their tests show that service discovery time increases as more devices are discovered. Network formation takes the smallest time with 136 ms for a two node network and 2.3 s for a four node network.
In [34], Deboosere et al. propose a grid model, where a mobile device connects to a server as a thin client over a classic thin client protocol such as VNC (Virtual Network Computing) or a streaming protocol. In this system, user input is sent via the wireless network to the server, and after processing the input, the server sends back the appropriate graphical output, which is then displayed on the mobile device. In particular, this research focuses on server selection algorithms that are needed when the mobile device’s location changes. To minimize the delay from server, and provide a quick response time, the application may need to be migrated to a nearby server, which may affect the performance. The authors aim to provide effective algorithms to minimize this degradation in performance, while supporting user mobility as well.
Virtual machine (VM) migration. VM migration refers to transferring the memory image of a VM from a source server to the destination server without stopping its execution [35]. In such a live migration, the memory pages of the VM are pre-copied without interrupting the OS or any of its applications, thereby providing an illusion of seamless migration. This method ensures that no code changes are needed when programs are offloaded, and provides a relatively secure execution, since the VM boundary insulates the surrogate device. However, VM migration is somewhat time consuming and the workload could prove to be heavy for mobile devices.
Rather than connecting to a distant cloud, Satyanarayan et al. [23] suggests ‘cloudlets’ as a solution. A cloudlet is similar to a small data center that is situated on designated areas/places and is connected to a larger cloud server via the Internet. They state that “internally, a cloudlet resembles a cluster of multi-core computers, with gigabit internal connectivity and a high-bandwidth wireless LAN”.
Thus, the mobile devices are in physical proximity to the resource rich cloudlet and it can function as a thin client while all the resource intensive computation happens inside the cloudlet. The mobile device would be connected to the cloudlet by a low-latency one hop high bandwidth wireless connection, thereby guaranteeing real time interactive response. If the user moves away from the cloudlet, the mobile device could fall back to a degraded service mode that connects to a distant cloud server—or at worst case—even operate offline. Cloudlets would be decentralized, widely dispersed and self-managing requiring little power, internet connectivity and control for setup. They could be owned by a particular local business (as opposed to cloud ownership by companies such as Amazon, Google etc.), such as a coffee shop or a dentist’s office. Also, a cloudlet would only contain cached data that is available elsewhere, so that the loss of a cloudlet would not be disastrous. Instead of tightly restricting the software that can be run on the cloudlet, the research suggests having minimal restrictions on the software and simplifying management. Their solution is to use “transient customization of cloudlet infrastructure using hardware VM technology”. The transient nature means that pre-use customizations and post-use cleanups would restore the cloudlet infrastructure to its original software state after each use. The VM would encapsulate and separate the guest software from the cloudlet’s host software. A VM based approach is more stable than other alternatives such as process migration and would also be more flexible than language-based virtualization. Two approaches are considered to transfer the VM state from the mobile device to the cloudlet: VM migration, and dynamic VM synthesis. Of those two, the authors propose to use dynamic VM synthesis because its performance depends solely on local resources and WAN failure wouldn’t affect synthesis (in which case base VMs could be transferred to the cloudlet via physical media).
MAUI [24] uses a combination of VM migration and code partitioning. Their objective is to save energy. Applications are offloaded from phones to surrounding infrastructure—i.e. local and remote servers. Implemented in.NET, MAUI’s partitioning is done at runtime and is very dynamic. It can use either 3G or WiFi for connectivity. Developers annotate which methods can be offloaded and at the time of execution, if there is a remote server available, MAUI decides whether or not to offload these methods.
CloneCloud [36] also uses VM migration to offload part of their application workload to a resourceful server through either 3G or WiFi. Because they use device clones, the mobile applications are unmodified and there is no need of even annotating methods such as done in MAUI [24]. They have a ‘cost model’ that analyses the cost involved in migration and execution on the cloud and compares the cost against a monolithic execution. CloneCloud was tested using Android phones with the clones executing on a Dell desktop running Ubuntu. For testing purposes, they considered three applications; a virus scanner, image search, and a privacy-preserving targeted advertising and report speedups up to 21.2× with WiFi giving better performance over 3G. However, they assume that the clone VM environment is by default a trusted one, and mention establishing trust as future work.
MobiCloud [37] discusses using cloud computing technology for MANETs (mobile ad hoc networks) in a secure way. Traditional MANETs can be transformed into a service oriented architecture by MobiCloud. Each mobile node is considered as a ‘Service Node’ that can be used as a service provider or a service broker depending on its computation and communication capabilities and available resources. Every service node is incorporated on to the cloud as a virtualized component and is mirrored in the cloud. These Extended Semi-Shadow Images (ESSIs) are not exactly the same as virtual images since an ESSI could be an exact clone, a partial clone, or merely an image that has extended functions of the physical device. A virtualized MANET routing and communication layer is established by these ESSIs to assist the physical mobile nodes that they represent. The key focus of MobiCloud is to provide a security service architecture and they present ‘Virtual Trusted and Provisioning Domain’ (VTaPD), which is a service to handle information flows in various security domains, using programmable routing [38].
Mobile code. Scavenger [39] is another framework that employs cyber-foraging using WiFi for connectivity, and uses a mobile code approach to partition and distribute jobs. It also introduces a scheduler for cost assessment. Its method of cost assessment is based on the speed of the surrogate server and it uses a benchmarking method to do this. Using its framework, it is possible for a mobile device to offload to one or more surrogates and its tests show that running the application on multiple surrogates in parallel is more efficient in terms of performance. However, it does not discuss fault tolerance mechanisms and since its method is strictly about offloading on surrogates and not sharing, it is not really dynamic. Also its surrogates are all desktops and it is unclear if Scavenger is too heavy to run on mobile phones.
Discussion. With the exception of Hyrax [14], Virtual cloud [12] and Cuckoo [30], the most recent works have used either VM migration or Mobile code to offload tasks. Even the aforementioned projects, are based on much older frameworks; Hadoop [40] and Ibis [31], designed for distributed and grid programming. Therefore it is safe to say that the trends in this particular area favor VM migration and Mobile code over the conventional Client–Server Communication systems. The advantages of these two approaches over Client–Server Communication methods such as RPC can be given as a reason for this. Although Client–Server Communication methods have well supported APIs and are robust, they require the applications to be pre-installed. Also, disconnected operations are not supported in this method. Considering the ad-hoc nature of mobile systems, this is a disadvantage. Furthermore, the continuous on-going interaction and communication between the client and server may lead to network congestion.
VM migration is used by a majority of frameworks, including Cloudlets [23], MAUI [24], CloneCloud [36], and MobiCloud [37]. Virtualization greatly reduces the burden on the programmer, since very little or no rewriting of applications is required. However, full virtualization with automatic partitioning is unlikely to produce the same fine grained optimizations as that of hand coded applications, although rewriting each and every application for code offload is also not practical. MAUI [24] actually does not rely on pure VM migration as done in CloneCloud [36] and Cloudlets [23], but uses a combination of VM migration and programmatic partitioning. However, in cases where the mobile device user is within range of a surrogate device for a few minutes, using VM migration may prove to be too heavyweight, as is pointed out in [39] which uses mobile agents in light of its suitability in a dynamic mobile environment.
Fig. 5 provides a general overview of these points discussed.
- Fig. 5.
An overview of the major approaches in offloading methods for mobile cloud computing, and their advantages and disadvantages.
Although the evaluation results have been given in some projects, comparing them against each other is difficult since the performance and energy savings depend on the application as well. In fact even when using the same framework, performance varies for different applications. The input size and connection protocol (whether 3G or WiFi) also plays a key role. For example, MAUI [24] reports maximum energy savings of 90%, 45%, and 27% for three applications (face recognition, chess, video game) and maximum performance speedups of roughly 9.5, 1.5, and 2.5 for the same respectively. CloneCloud [36] also reports test results on three applications; virus scanning, image search, behavior profiling. They show maximum speedups of 14.05, 21.2, and 12.43 respectively for the aforementioned applications. Scavenger [39] also reports test results evaluated using an image editor application, and their results show a maximum speedup of 38.7 and a maximum power saving of 24%.
