網頁

Mobile cloud computing was referred as an infrastructure in which processing and data storage were outside the mobile device. The mobile cloud framework is going to extend the computing model from the client-server model to the application partitioning model.

Overview

Imagine a personal virtual phone which has the same capability as the physical phone in a user's hand and share a large data storage with his/her physical phone with a cloud storage. The user may use either phones to execute an application or have the application migrate between two phones. The virtual phone helps offload intensive workload from the physical phone as it accelerates computation, data access, and network operations. The user may even migrate an application from the virtual phone to a personal computer, so that certain interactive tasks can be done more quickly on a large display.

Fig.1 Overview of mobile cloud services

There are several key issues in designing a framework to facilitate the aforementioned scenario: How to clone the physical phone and create a virtual phone? How to minimize the time required to migrate an application over a mobile network? How to minimize the costs for sharing and synchronization of data between two phones? How to secure the virtual phone? Since we were not aware of any previous work, we developed a framework to create virtual phones based on the Google Android operating environment.

Fig 2. Key issues of a mobile cloud framework

The procedures for creating a virtual phone is automated by our framework as the following:

1. Installing our agent program: The user simply installs and runs our agent program, which automates the rest of the procedures. The agent also provides the interface for the user and applications to interact with the virtual phone.

2. Allocation of a delegate system: The agent allocates a delegate system to host the virtual phone by subscribing to a virtual machine from an infrastructure as a service (IaaS) provider. The delegate system In our prototype runs the Linux operating system and may host multiple virtual phones to save the operation cost.

3. Setting up a virtual phone: The agent sets up a virtual phone on the delegate system using Google Android Emulator, an open-source software which employs QEMU virtual machine software to emulate the reference Android hardware dened by Google. QEMU provides a fast emulation speed via dynamic binary translation techniques.

4. Cloning of the operating environment: The agent copies the operating environment of the physical phone or uses a standard image stored in the delegate system to create a fresh virtual phone. An exact clone of the operating environment should increase the compatibility for applications which requires vendor-specific a quick method to create the virtual phone.

5. Migration of applications: The agent on the physical phone takes commands from the user and communicates with the agent on the virtual phone to control the operation of the virtual phone. The user of an application (or the application itself) may request the agent to migrate the application between two phones. Since the latency to migrate a live (executing) application aects the user experience signicantly, we developed an innovative approach to dramatically reduce the latency.

6. Synchronization of applications and user data: The agent programs on both phones collaborate to keep the application packages and user data consistent and coherent on both phones. Since continuous mirroring of les would generate a large amount of network tracs, the policies and protocols of synchronization are critical.

Fig.3 The procedures to create a virtual environment in the clouds

Our application migration mechanism leverages the application pause-resume scheme dened by the Android application framework. On an Android phone, only one application is actively running on the foreground, and the other applications are either running or suspended in the background. To keep the background applications from hogging the system resources, the Android runtime system may opt to close background applications when a resource on the phone is running out. Thus, application developers are advised to use the pause-resume scheme provided by the Android application framework to save application state in the non-volatile memory (e.g. flash memory) so that the applications can resume later. Noticing that many Android applications follow this paradigm, we may migrate such applications between phones simply by transferring the saved application state.

The procedure for migrating an application is illustrated step-by-step in Figure 3. On the left-hand side: (1) The agent sends a signal to the application and has the application enter the OnPause function. (2) The application saves its states in the OnPause function and (3) informs the agent when the states are saved. (4) The agent reads the states and (5) sends the states to the agent on the other side. Then, on the right-hand side: (6) The agent saves the states and (7) starts the application (or copies the application from the other side if it does not exist). (8) The application resumes by calling the OnResume function and (9) resumes the execution after restoring the application state.

Fig 4. Illustration of application migration to the clouds by the pause-resume scheme


Publications
  • Shih-Hao Hung, Tei-Wei Kuo, Chi-Sheng Shih, Jeng-Peng Shieh, Chen-Pang Lee, Che-Wei Chang, and Jie-Wen Wei, A Cloud-based Virtualized Execution Environment for Mobile Applications, ZTE Communications, Vol.9, No.1, March 2011, pp.15-21. 
  • Shih-Hao Hung, Jeng-Peng Shieh, Chen-Pang Lee, Migrating Android Applications to the Cloud, SC2 2011 
  • Shih-Hao Hung, Jeng-Peng Shieh, Chen-Pang Lee, Virtualizing smartphone application to the cloud, IMIS 2010 
  • Chun-Chung Chen, Shih-Hao Hung, and Chen-Pang Lee. Protection against Buffer Overflow Attacks via Dynamic Binary Translation, The International Conference on Reliable & Autonomous Computational Science (RACS 2010), Atlanta, GA, USA, Oct. 2010 (EI).