Code Offloading

Code offloading solutions offload specific marked parts of application code, rather than application components. A first example of this kind of solution is the MAUI platform by Cuervo et al [21]. MAUI will offload application code at the method level, marked by developers as "Remoteable". This works at the VM level as part of the Microsoft .Net Common Language Runtime (CLR). Not all methods are suitable for offload, such as code that accesses the resources on the device such as the sensors, the camera, or native code. It is up to the developer to mark suitable methods themselves according to the given con-straints. All object state within the class containing the Remoteable method on the heap is serialised and offloaded with the method code. Code is executed on

Figure 2.3: Code Offloading Model. Specific parts of mobile application code, normally methods, are offloaded to a cloud server for execution. Results, in the form of changed object state, newly created objects, and destroyed objects, are returned to the mobile device upon completion.

the MAUI platform on the cloud infrastructure, and the resulting state changes are returned to the device, at which point execution resumes. If offloaded code tries to call native code however, execution must be suspended and returned to the device before continuing.

The architecture of MAUI is similar to other code offloading approaches.

MAUI carries out various profiling tasks to determine if code should be of-floaded or not. MAUI is designed with the goal of saving energy. If energy can be saved by carrying out code offload, then it should take place. The MAUI profiler estimates the energy required to execute a Remoteable method on the mobile device by measuring CPU cycles (assisted by past invocations of the method). At runtime, by profiling the network quality, it estimates the energy cost of offloading the device to the cloud. This profiling data is given to an opti-misation solver, to then determine should the code be offloaded. The profiling of the network and the solver run constantly to provide the latest estimates.

MAUI showed great potential for energy savings on the mobile device. In favourable network conditions, always on Wi-Fi, it resulted in significant

en-ergy savings, yet in tests on 3G networks, no enen-ergy savings were found. In-fact, the optimisation solver always refused to carry out code offloading on 3G networks in all experiments, based on the profiling results, instead opting for local execution. This is a significant problem, as users on the move through cel-lular networks in a public area would not be able to take advantage of MAUI.

It also suffers from the fact it can only offload developer written methods at the VM level. In some cases this makes sense, such as methods accessing the camera, but native code which does not access the physical resources cannot be offloaded. In terms of disconnection, it is handled, but not gracefully. If a timeout period elapses for a return from an offloaded method, MAUI on the mobile device will assume the network connection is lost (or very poor), and will re-execute the offloaded code locally. This is a significant waste of time and energy. Another non-negligible concern is the profiling overhead from de-termining the network status, and optimisation solver overhead, just as with the application partitioning approaches.

Another example of code offloading by Chun et al [19] is CloneCloud. Like MAUI, profiling takes place and an optimisation solver will decide if code should be offloaded at runtime. Unlike in MAUI, CloneCloud offloads on a method basis, but at the thread level of the VM. The CloneCloud applica-tion on the cloud infrastructure is a VM running a clone of the mobile device software, meaning it cannot offload native OS methods. However, offloaded developer methods can call native code, without execution returning to the device. CloneCloud does not require any developer intervention; code does not need to be annotated as Remoteable. CloneCloud can also offload based on saving time, not just energy. Static profiling, which is run once, estimates the time and energy required to execute methods. Suitable offloading points according to constraints are detected and stored in a file during this process.

At runtime, a partition of code offload points are given to the CloneCloud soft-ware on the mobile device, and by dynamically profiling the network quality, an optimisation solver decides to offload if time or energy is saved. In terms of the experiments, CloneCloud was only evaluated on Wi-Fi networks, and no consideration was given to cellular networks, which of course is of criti-cal importance. Once again, the profiling overhead is a concern for the user experience.

Mobile Augmentation Cloud Services (MACS) by Kovachev et al [71] also per-forms code offload. MACS requires the developer to write all code that may be resource intensive into an Android service; the service can then be offloaded

at runtime in suitable conditions based on network and resource availability profiling. The services are presented to the rest of the application (UI activ-ities etc.) in the Android Interface Definition Language (AIDL), so the code that calls a service to perform an intensive task has no knowledge of the code possibly being offloaded. Like MAUI and CloneCloud, it uses an optimisation problem to decide to offload, based on minimising an objective cost function, such as time or energy savings. MACS also has this common weakness of not being able to offload native code or code that accesses physical resources such as the camera. Results showed tremendously high speedup as their test appli-cations, such as solving the N-Queens problem, grew in complexity for greater values of N. However for small values of N, it was found that code offload introduced more overhead than local execution. This project shares the same weaknesses as CloneCloud, in that the authors did not test MACS on a cellular network, assuming (as MAUI showed), that results for the cellular network would be poor due to lower bandwidth.

To illustrate the overhead of offloading techniques, Ma and Wang [86] also developed a code offload approach, which uses a technique called stack-on-demand execution. This technique was specifically used to address the over-head of offloading possibly unnecessary data, and the overover-head involved in other code offload approaches, even when offloading does not take place.

Stack-on-demand, rather than offloading all state within a method’s class such as in MAUI, will only offload the stack frame on top of the call stack. There-fore, only the state required for a given execution context (such as a method) is offloaded. It also aimed to reduce the overhead in cases where offloading does not take place, by keeping two sets of methods, one with offloading code and one without. Rather than having offloading code placed at, for example, the method level, it delegated offloading code to exception handling code. So if for example a required library is not found on the device, an exception is thrown, and offloading can then be signalled to take place. The authors found great savings using these techniques when offloading does not take place. Unlike in other works, time and energy considerations for offload are not considered, offload is either requested by an application or a condition for offload such as a missing library is met.

The authors provide an implementation of this concept in [87], known as eX-Cloud. The implementation aims at not just migrating from mobile device to cloud, but between cloud nodes, emphasising application parallelism with the Message Passing Interface (MPI) on cloud infrastructure, so the focus is

some-what split. The results showed offload time for their sample applications be-tween two hundred and four hundred milliseconds. Overhead resulted from the state capturing time like in the other approaches, even with the stack on demand technique. The authors did not carry out any results comparison with the related work like MAUI and CloneCloud.

The Uniport programming support framework by Yuan et al [148] can be con-sidered as another code offloading project. Uniport is designed to allow de-velopers to create cross platform mobile applications with ease, following the Model View Controller (MVC) design pattern. This pattern is used extensively in web applications, and in particular, with the iOS platform. Briefly, the Model contains the data and associated data logic of the application. The View is the presentation layer, which presents the data in the Model, as part of a GUI.

The Controller contains the overall application business, event, and flow logic, and passes the data from the Model to the View. The goal behind the Uniport framework, is that a mobile cloud application (MCA), should execute expen-sive operations on the Model, and the Model should be offloaded to the cloud server for execution. The Uniport client synchronises the local data Model on the mobile device, with the Uniport server application. The Uniport client can send an execute call to the server when required, to start the expensive Model operations. After completion, the updated Model is returned back to the mo-bile device, and the Controller passes the updated Model data to the View. The authors also developed a code generator, to generate projects stubs with skele-ton code for the different mobile and server platforms, along with an analyser, which aims to assist the developer in converting existing mobile applications, into the Uniport MVC architecture, which is a considerable advantage for this project, considering the lack of support for existing applications to be con-verted for other code offload and application partitioning approaches. The evaluation goal of the framework was response time and energy savings for various implementations of Gomoku, a board-based strategy game, for each mobile platform (iOS, Android, and Windows Phone), which the evaluation demonstrated. Like MAUI, this approach also deals with disconnection based on time-outs, and will re-execute offloaded and synchronised Models locally.

A final example of a code offloading approach for mobile cloud computing, for comparison with MAUI and CloneCloud, is the ThinkAir framework by Kosta et al [70] It bears similarities to MAUI, in that it requires developers to annotate code at the method level, that is suitable for consideration for remote execution. It is also similar to CloneCloud, in that it uses a copy of the

mo-bile operating system located in the cloud (minus some features such as GUI libraries). According to the authors, it improves on CloneCloud, by having an online profiling engine, compared to CloneCloud’s approach, where offload-ing plans must be generated from an application graph duroffload-ing the develop-ment phase. ThinkAir uses profilers to monitor network, program, and device conditions/factors, and an Execution Controller then determines if there is an energy or time benefit to the code being offloaded over Wi-Fi and 3G inter-faces (consider that the CloneCloud work did not evaluate 3G for offloading).

A big focus in ThinkAir for the authors was to utilise cloud scalability for par-allelism similar to exClouds goal; the cloud part of the ThinkAir framework can startup or unpause existing VMs, and delegate offloaded work to them to exploit parallel computation. In the results, offloading computationally expen-sive applications (an image combiner, a virus scanner, and an N-Queens puz-zle) improved energy consumption and execution time to a point (8 VMs), at which time the overhead of managing that number of VMs started outweigh-ing the benefits. Similar to MAUI and CloneCloud, ThinkAir carries the cost of having to profile network conditions, along with program and device con-ditions, in preparation for an offload. The paper also does not discuss what code may or may not be suitable for offloading, in the same way MAUI does, but the authors do mention that their Execution Controller will make the deci-sion on behalf of the developer, so that there will be no errors should a novice developer make a mistake.

Another work, not aimed directly at solving the problems of mobile cloud computing, but similar to both code offloading and application partitioning projects, is the Sapphire framework by Zhang et al [149]. The Sapphire frame-work is designed to ease and separate the deployment considerations for ap-plications, that can run on both mobile and cloud platforms. The authors recognise a need for users to execute some applications, both locally on mobile devices, and remotely on cloud infrastructure. The authors argue that coding the deployment logic to handle different deployment configurations (mobile, or cloud, or even both), can be difficult for the developer. The Sapphire frame-work allows a developer to build an application on-top of Sapphire. Sapphire will then take care of handling deployment configurations and features, on be-half of the developer. The Sapphire system features a Deployment Kernel at it’s bottom layer. This is a runtime to provide deployment support to the de-veloper. On top of this, the developer uses extensible Deployment Managers, to describe the features they want for deployment. For example, one built in

feature is the CodeOffload deployment manager. The developer creates a Sap-phire object, containing the work to be remotely executed. A SapSap-phireObject is an executable object that has its deployment managed by Sapphire, and the ob-ject can be executed on mobile, cloud, or even both platforms. In this example, this object, which uses the CodeOffload Deployment Manager, will be moved from the mobile device, to the cloud, for execution. The mobile application is transparent to this; any calls to the code in this Sapphire Object, are made transparently by Sapphire to the cloud, with Remote Procedure Call (RPC).

The system features other DeploymentManagers for other required features of application deployment, such as caching, replication, and load-scaling. This work does to a small extent address the disconnection problems that interfere with MAUI and CloneCloud, in that if a device becomes disconnected, the De-ployment Kernel on that device continues to run, but cannot make RPC calls.

The authors state their expectation that devices are connected to the internet most of the time, which in the mobile cloud computing paradigm, should not be the expectation.

To summarise code offloading, it can be seen from the works discussed in this subsection that code offload is capable of bringing dramatic speedup and en-ergy savings for intensive work, but only in favourable network conditions, and when the amount of work is large enough such that the overhead of of-floading is made somewhat negligible by comparison with the overall cost. To the mobile user it can in some cases solve the battery power constraint, and even enable tasks that would not be possible on the mobile device alone [21].

However, in the absence of a suitable quality network it does not solve this problem. MAUI and Sapphire were the only works to discuss what should happen if the device is disconnected while code is offloaded. Any solution therefore needs to weigh up the amount of work and quality of the network before deciding to offload, and tackle the overhead of offloading such as in [86]. As with application partitioning, network profiling costs for the opti-misation solver, are non-negligible. Aside from poor performance on cellular networks and the profiling overhead, collectively, application partitioning and code offload solutions meet more of the user experience goals outlined than the Cloudlet-based projects; however these approaches for all practical still do not solve the mobility aspects of disconnection.

Figure 2.4: Remote Display Model. Similar to Cloudlets and application par-titioning, a virtual machine runs on a cloud server. The component of the solution that displays the visual GUI output of the virtual machine runs on the mobile device.