Thursday, February 19, 2015

ThinkAir: Dynamic resource allocation and parallel execution in cloud for mobile code offloading

Motivation:

Smartphones are becoming increasingly popular, with approximately 550,000 new Android devices being activated worldwide every day. These devices have a wide range of capabilities, typically including GPS, WiFi, cameras, gigabytes of storage, and gigahertz-speed processors. As a result, developers are building ever more complex smartphone applications such as gaming, navigation, video editing, augmented reality, and speech recognition, which require considerable computational power and energy. Unfortunately, as applications become more complex, mobile users have to continually upgrade their hardware to keep pace with increasing performance requirements but still experience short battery lifetime. Although considerable research work, like MAUI and CloneCloud, have proposed solutions to address the issues of computational power and battery lifetime by offloading computing tasks to cloud, MAUI work does not address the scaling of execution in cloud and CloneCloud only considers limited input/environmental conditions in the offline pre-processing and needs to be bootstrapped for every new application built.

Main points:

Assumption:

The design of ThinkAir is based on some assumptions which we believe are already, or soon will become, true:
1.  Mobile broadband connectivity and speeds continue to increase
2.  As mobile device capabilities increase, so do the demands placed upon them by developers
3.  Cloud computing continues to develop, supplying resources to users at low cost and on-demand.

Architecture:

1.    Execution environment:
Programmer API: ThinkAir provides a simple library that any method to be considered for offloading is annotated with @Remote
Compiler: the compiler comes in two parts: the Remoteable Code Generator and the Customized Native Development Kit (NDK). The Remoteable Code Generator is a tool that translates the annotated code as described above. The Customized NDK exists to provide native code support on the cloud.
Execution Controller: The Execution Controller drives the execution of remoteable methods. It decides whether to offload execution of a particular method, or to allow it to continue locally on the phone. The decision depends on data collected about the current environment as well as that learnt from past executions
Execution flow:If the method should be offloaded but the connection fails for any reason during remote execution, the framework falls back to local execution, discarding any data collected by the profiler. At the same time, the Execution Controller initiates asynchronous reconnection to the server.
2.       Application server:
Client Handler: The Client Handler executes the ThinkAir communication protocol, managing connections from clients, receiving and executing offloaded code, and returning results.
Cloud Infrastructure: To make the cloud infrastructure easily maintainable and to keep the execution environment homogeneous,we use a virtualization environment allowing the system to be deployed where needed, whether on a private or commercial cloud. To reduce its memory and storage demand, we build a customized version of Android x86, leaving out unnecessary components such as the user interface and built-in standard applications.
Automatic Parallelization: Parallelization considers intervals of input values.
3.       Profiler:
Hardware Profiler: The Hardware Profiler feeds hardware state information into the energy estimation model, which is considered when an offloading decision is made.
Software Profiler: The Software Profiler tracks a large number of parameters concerning program execution.
Network Profiler: The Network Profiler tracks the network state, involves measuring the network RTT as well as the amount of data that ThinkAir sends/receives in a time interval, and tracks several other parameters for the WiFi and 3G interfaces.
Energy Estimation Model: They devise a method with only minor deviations from the results obtained by PowerTutor to dynamically estimate the energy consumption of each running method.


Trade-offs: 
   
   1. ThinkAir targets a commercial cloud scenario with multiple mobile users, so that they focus not only on the offloading efficiency and convenience for developers, but also on the elasticity and scalability of the cloud side for the dynamic demands of variant customers.

   2. It also has the drawback of introducing latency by resuming, starting, and synchronizing among the VMs.

1 comment:

  1. Good description. Try to add more of your own thoughts of the paper's strengths and weaknesses. Thanks.

    ReplyDelete