See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/261283944

Adaptive Computation Offloading from Mobile Devices into the Cloud

Conference Paper · July 2012

DOI: 10.1109/ISPA.2012.115

CITATIONS READS

122 744

3 authors, including:

Dejan Kovachev Ralf Klamma

RWTH Aachen University RWTH Aachen University
25 PUBLICATIONS   544 CITATIONS    379 PUBLICATIONS   2,988 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Special Issue on "Learning Analytics in primary, secondary and higher education" View project

tech4comp View project

All content following this page was uploaded by Ralf Klamma on 14 July 2017.

The user has requested enhancement of the downloaded file.

 Adaptive Computation Offloading from Mobile
Devices into the Cloud
Dejan Kovachev, Tian Yu and Ralf Klamma
Information Systems and Database Technologies
RWTH Aachen University
Ahornstr. 55, 52056 Aachen Germany
{kovachev|tianyu|klamma}@dbis.rwth-aachen.de

Abstract—The inherently limited processing power and battery Offloading has gained big attention in mobile cloud com-
lifetime of mobile phones hinder the possible execution of puting research, because it has similar aims as the emerging
computationally intensive applications like content-based video cloud computing paradigm, i.e. to surmount mobile devices’
analysis or 3D modeling. Offloading of computationally intensive
application parts from the mobile platform into a remote cloud shortcomings by augmenting their capabilities with external
infrastructure or nearby idle computers addresses this problem. resources. Offloading or augmented execution refers to a tech-
This paper presents our Mobile Augmentation Cloud Services nique used to overcome the limitations of mobile phones in
(MACS) middleware which enables adaptive extension of Android terms of computation, memory and battery. Such applications,
application execution from a mobile client into the cloud. Applica- which can adaptively be split and parts offloaded [4], [5],
tions are developed by using the standard Android development
pattern. The middleware does the heavy lifting of adaptive are called elastic mobile applications. Basically, this model of
application partitioning, resource monitoring and computation elastic mobile applications enable the developers the illusion
offloading. These elastic mobile applications can run as usual as if he/she is programming virtually much more powerful
mobile application, but they can also reach transparently re- mobile devices than the actual capacities. Moreover, elastic
mote computing resources. Two prototype applications using the mobile application can run as stand-alone mobile application
MACS middleware demonstrate the benefits of the approach. The
evaluation shows that applications, which involve complicated but also use external resources adaptively. Which portions of
algorithms and large computations, can benefit from offloading the application are executed remotely is decided at runtime
with around 95% energy savings and significant performance based on resource availability. In contrast, client/server appli-
gains compared to local execution only. cations have static partitioning of code, data and business logic
between the server and client, which is done in development
I. I NTRODUCTION phase.
Our contributions include an integration with the estab-
Resource-demanding multimedia applications such as 3D lished Android application model for development of “offload-
video games are being increasingly demanded on mobile able” applications, a lightweight application partitioning and
phones. Even if mobile devices’ hardware and mobile net- a mechanism for seamless adaptive computation offloading.
works continue to evolve and to improve, mobile devices will We propose Mobile Augmentation Cloud Services (MACS), a
always be resource-poor, less secure, with unstable connectiv- services-based mobile cloud computing middleware. Android
ity, and with constrained energy. Resource poverty is major applications that use the MACS middleware benefit from
obstacle for many applications [1]. Therefore, computation seamless offloading of computation-intensive parts of the ap-
on mobile devices will always involve a compromise. For plication into nearby or remote clouds. First, from developer’s
example, on-the-fly editing of video clips on a mobile phone perspective, the application model stays the same as on the
is prohibited by the energy and time consumption. Same Android platform. The only requirement is that computation-
performance and functionalities on mobile devices still cannot intensive parts are developed as Android services, each of
be obtained as on their desktop PCs’ or even notebooks’ when which encapsulates specific functionality. Second, according
dealing with tasks containing resource-demanding tasks. to different conditions/parameters, the modules of program are
Recently, the combination of cloud computing [2], wire- divided into two groups; one group runs locally, the other
less communication infrastructure, ubiquitous computing de- group is runs on cloud side. The decision for partitioning
vices, location-based services, mobile Web, etc., has laid is done as an optimization problem according to the input
the foundation for a novel computing model, called mobile on the conditions of cloud side and devices, such as CPU
cloud computing [3]. It provides to users an online access load, available memory, remaining battery power on devices,
to unlimited computing power and storage space. The cloud bandwidth between the cloud and devices. Third, based on the
abstracts the complexities of provisioning computation and solution of the optimization problem, our middleware offloads
storage infrastructure, which the end user uses them as utility parts to the remote clouds and returns the corresponding results
and in reality they can be far away data center or nearby idle back. Two Android applications on top of MACS demonstrate
hardware. the potential of our approach.
 In the rest of the paper, we first review related research Zhang et al. [13], [14] use a general Bayesian inference to
work mobile cloud computing in Section II. Then we describe make the partitioning decision. However, executing constantly
our MACS middleware with detailed descriptions of the im- executing graph or inference algorithms on the mobile device
plementation (Section III). We explain the offloading model takes significant resources on the constrained device. We use
in our middleware in Section IV. In Section V we introduce integer linear optimization model to describe the offloading
the two use case applications, the setup of the evaluation so that it is not only easy to implement, but it can also be
and the corresponding evaluation results based on those two independently solved if the remote clouds are temporarily not
applications. After that, we discuss about the results in Section available.
VI. Finally, draw conclusions and refer to the future work.
III. M OBILE AUGMENTATION C LOUD S ERVICES
II. R ELATED W ORK
The goal of our MACS middleware is to enable the execu-
Previous work has proposed many mechanisms that address tion of elastic mobile applications. Zhang et al. [14] consider
the challenges of seamless offloaded execution from a device elastic applications to have two distinct properties. First, an
to a computational infrastructure (cloud). A “brute force” elastic application execution is divided partially on the device
approach to offloading can be considered the encapsulation and partially on the cloud. Second, this division is not static,
of mobile device’s software stack into a virtual machine but is dynamically adjusted during application runtime. The
image and executing it on a more powerful hardware, such as benefits of having such application model are that the mobile
proposed by Chun and Maniatis [6] or Satyanarayanan et al. applications can still run independently on mobile platforms,
[1]. More recently, Kosta et al. [7] have further improved this but can also reach cloud resources on demand and availability.
idea. Although such virtualized offloading can be considered Thus, mobile applications are not limited by the constraints of
as simple and general solution, it lacks flexibility and control the existing device capacities.
over offloadable components. Therefore, we consider that MACS architecture is depicted on Figure 1. In order to
application developers can better organize their application use MACS middleware, the application should be structured
logic using the established Android service design patterns using established Android services pattern. Android is already
and benefit from the MACS middleware. established as the most prominent mobile phone platform.
Ou et al. [8] propose class instrumenting technique, i.e. a Additionally, its application architecture model allow decom-
process to transform code classes into a form which is suitable position of applications into service components which can be
for remote execution. Two new classes are generated from shared between applications. A MACS application consists of
the original class, one is an instrumented class which has the an application core (Android activities, GUI, access to devices
real implementation and the same functionality as the original sensors) which can not be offloaded, and multiples services
class, the other is a proxy class, whose responsibility is only (Si ) that encapsulate separate application functionality (usu-
to call the function written in the instrumented class. Then, ally resource-demanding components) which can be offloaded
the instrumented class can be offloaded to remote cloud, and (SRi ). The services communicate with the application through
the call will be invoked from the instrumented in the remote an interface defined by the developer in the Android interface
cloud. In MACS we adopt similar idea, but unlike Ou et al. [8] definition language (AIDL).
we use standardized language for the proxy interfaces which As service-based implementation is adopted, for each ser-
is already widespread in the Android platform. The Cuckoo vice we can profile following metadata:
framework [4] and MAUI system in [9] implement a similar
• type: whether can be offloaded or not
idea. Our MACS middleware is inspired by these solutions.
• memory cost: the memory consumption of the service on
However, MACS middleware does extra profiling and resource
the mobile device
monitoring of applications and adapts the paritioning decision
• code size: size of compiled code of the service
at runtime.
• dependency information on other services, for each re-
An important challenge in partitioned elastic applications
lated module, we collect following:
is how to determine which parts of code should be pushed
to the remote clouds. The graph based approach to model – transfer size: amount of data to be transferred
the application has been used in several works. Giurgiu et – send size: amount of data to be sent
al. [10] use “consumption” graph and decide which part – receive size: amount of data to be received
should be running locally or remotely by finding a cut of the Metadata is obtained by monitoring the application execution
consumption graph with a goal function, which minimizes the and environment.
total sum of communication cost, transmitting cost and the Android services are using Android interprocess communi-
cost of building local proxies. The AIDE platform [11] uses a cation (IPC) channels to do RPC. The services are registered
component-based offloading algorithm, which mainly focuses in the Service Manager, and a binder maintains a handle for
on minimum historical transmission between two partitions. each service. Then an application, that wants to use a service,
The (k +1) partitioning algorithm, introduced by Ou et al. [8], can query the service in the Service Manager. Upon service
is applied to a multi-cost graph to represent the class-based discovery, the Android platform will create a service proxy for
components. A similar approach is done by Gu et al. [11], [12]. the client application. All the requests to access the service will
 execute the service remotely. If there is no such service on
the remote clouds, our framework transmits the service code
(jar file) to the cloud, and the corresponding results after the
service execution are returned to the mobile device. The cloud
caches the jar files for subsequent execution.
Except for the computation offloading, our framework also
features simple data offloading. If files are needed to be ac-
cessed on the remote cloud, MACS file transmission (MACS-
FTM) transfers automatically the non-existed files from the
local device and vice versa.
IV. A DAPTIVE C OMPUTATION O FFLOADING
The proposed model and corresponding algorithm are sup-
posed to be applied for scenario which is computation-
intensive [15], and the requirements for the developer is that
the code should be structured in a model in advance.
Fig. 1. MACS architecture. Application logic is structured from multiple Let us suppose that we have n number of modules which
Android services (Si ). Some of them can be offloaded into the cloud (SRi ).
can be offloaded, S1 , S2 ...Sn . Each of modules has several
properties described as metadata, i.e. for specific module i,
its memory cost memi , code size codei . Let us consider
be sent through the service proxy, and then forwarded to the the k number of related module which can be offloaded.
service by the binder. After processing the requests, results For each of them, we denote the transfer size tr1 , tr2 ...trk ,
are sent back to the service proxy on the client application send size send1 , send2 ...sendk , receive size rec1 , rec2 ...reck ,
through the binder. Finally, the client gets the result from where {1..k} ⊆ {1..n} and sendk + reck = trk . Meanwhile,
the service proxy. From client’s point of view, there is no we introduce xi for module i, which indicates whether the
difference between calling a remote service or calling a local module i is executed locally (xi = 0) or remotely (xi = 1).
function. The solution x1 , x2 ...xn represents the required offloading
The offload manager determines the execution plan, and partitioning of the application.
then the services to be offloaded are pushed to the cloud. The The cost function is represented as follows:
results are sent back to the application upon completion. Our
approach is similar to the Cuckoo framework [4], however, min (ctransf er ∗ wtr + cmemory ∗ wmem + cCP U ∗ wCP U )
x∈0,1
MACS allows dynamic application partitioning at runtime, (1)
where Cuckoo only enables static partitioning at compile where
time. MACS monitors the execution of the services and the n
X n X
X k
environment parameters. Whenever the situation changes, the ctransf er = codei ∗ xi + trj ∗ (xj XOR xi ) (2)
middleware can adapt the offloading and partitioning. i=1 i=1 j=1
The main goal of MACS is to enable transparent com- n
X
putation offloading for mobile applications. Therefore, our cmemory = memi ∗ (1 − xi ) (3)
middleware tries to fit the usual Android development process i=1
and bring the developers an easier way to offload parts of their n
X
applications to remote clouds in a transparent way. MACS cCP U = codei ∗ α ∗ (1 − xi ) (4)
hooks into the Android compile system, makes modifications i=1
of generated Java files from AIDL in the pre-compile stage. There are three parts in the cost function. The first part
Developers need to include MACS SDK libraries into their depicts the transfer cost for remote execution of services, in-
Android project. cluding the transfer cost of its related services which are not at
At the cloud side, the MACS middleware handles the the same execution location. The latter part of Eq.(2) implicitly
offload requests from the clients, installs of offloaded services, includes the dependency relationship between modules, i.e. if
their initialization and method invokes. The cloud-side MACS the output of one module is an input of another. The cmemory
middleware is written with pure J2SE so that it can run on contains the memory cost on the mobile device, and cCP U
any machines with installed J2SE. the CPU cost on the mobile device is, where α is the convert
MACS middleware monitors the resources on the mobile factor mapping the relationship between code size and CPU
execution environment and available clouds. It then forms instructions, which is taken to be 10 based on [16]. wtr , wmem ,
an optimization problem whose solution is used to decide wCP U are the weights of each cost, which can lead to different
whether the service which contains the called function should objectives, for example lowest memory cost, lowest CPU load
be offloaded or not. When the service is determined to be or lowest interaction latency.
offloaded to the remote cloud, our middleware tries first to The three constraints are expressed as the following.
 Minimized memory usage. First, the memory cost of n
resident service can not be more than available memory on Ds =
X
sendi ∗ typei ∗ xi (11)
the mobile device, i.e. i=1
n
X Xn
memi ∗ (1 − xi ) ≤ availmem ∗ f1 (5) Dr = reci ∗ typei ∗ xi (12)
i=1 i=1

where availmem can be obtained from the mobile device, where typei ∈ {0, 1} represents whether a service is
f1 is the factor to determine the memory threshold to be used, offloadable or not.
because the application can not occupy the whole free memory Minimized execution time. Third, the third constraint is
on the mobile device. enabled when the user prefers fast execution, i.e.
Minimized energy usage. Second, for the offloaded ser-
tlocal − tof f load > 0 (13)
vices, the energy consumption of offloading should not be
greater than not offloading [17], i.e. The local execution time can be expressed as the ratio
of CPU instructions to local CPU frequency, meanwhile, the
Elocal − Eof f load > 0 (6) remote execution time consists of the time consumed by CPU,
file transmission and the overhead of our middleware.
The local energy consumption can be expressed using the
number of local instructions to be executed Ilocal , local execu- Ilocal
tlocal = ∗ xi (14)
tion speed Slocal and the power used of local execution Plocal Slocal
[17]. At the first decision time, Ilocal is estimated according to
the code size. After the first decision, this number is collected Ilocal Dextra
tof f load = ( + + toverhead ) ∗ xi (15)
from our framework (by calling the statistic method provided Scloud Bs
from Android API). Obviously, there is relationship between where toverhead is the overhead which our framework brings
instruction number and the power used for that instruction in.
while doing power profiling. According to the constraints above, we now transform the
Plocal ∗ Ilocal partitioning problem to an optimization problem. The solution
Elocal = (7) of x1 , x2 ...xn , is the optimized partitioning strategy. By using
Slocal
integer liner programming (ILP) on the mobile device, MACS
The energy cost of offloading some parts to remote cloud gets a global optimization result. Whenever the the parameters
can be expressed as the sum of energy consumption during in the model change, such as available memory or network
waiting for the results from the cloud Eidle , transferring bandwidth, the partitioning is adapted by solving the new
(including sending Es and receiving Es ) the services to be optimization problem.
offloaded [17] and also the additional data which may be Although MACS introduces the overhead because of using
needed on the remote cloud Eextra . a proxy for communication between offloaded services and
the mobile application, the overhead is relatively small, which
is shown in the evaluation part. Our MACS also does the
Eof f load = Es + Eidle + Er + Eextra profiling for each offloaded module/service to dynamically
= Ps ∗ (ts + textra ) + Pidle ∗ tidle + Pr ∗ tr (8) change its execution plan and adjust the partitioning.
V. E XPERIMENTAL E VALUATION OF O FFLOADING
The idle time of the mobile device waiting for the result We evaluate our MACS framework with two use case phone
from cloud can be treated as the execution time of remote applications. The first application implements the well-known
cloud, so the formula becomes N-Queens problem. It is chosen because the performance
bottleneck represents a pure computation problem. This use
Plocal ∗ Ilocal Plocal ∗ Ilocal
Elocal − Eof f load = − case can easily show the overhead introduced by MACS
Slocal Scloud middleware. The second application involves face detection
Ps ∗ (Ds + Dextra ) Pr ∗ Dr and recognition in video files. This use case involves lots of
− − (9)
Bs Br computation, but also requires much more memory resources
where Ds and Dr are the total data sizes to be sent and to process and obtain results.
received, Dextra is the size of extra data needed because of The second case can process a video file, and detect faces
offloading, which is determined at runtime, Bs and Br are the from the video file, cluster them and provide the time point
bandwidths of sending and receiving data, and Scloud is the cues for video navigation. The results can then be used for
remote execution speed. Additionally, faster video navigation on small screen devices (Figure 2). The
video file is processed with OpenCV 1 and FFmpeg 2 libraries.
n
X
1 http://opencv.willowgarage.com
Ilocal = codei ∗ typei ∗ xi (10)
2 http://ffmpeg.org
i=1
Fig. 2. Snapshot of prototype application of face detection and recognition
using MACS middleware

Fig. 3. Execution time of N-queens

In the processing, faces in the video file are detected by the
existed implementation in OpenCV, and then the detected faces
are recognized by the method proposed by Turk and Pentland consumption on the Android-based mobile device on the
[18], and after that, the faces are clustered. fly. Using their software, the energy consumption of each
In the implementation we used JavaCV 3 for video process- hardware component of the Motorola Milestone such as LCD,
ing. When the application gets the results from the processing, CPU and Wi-Fi can be measured separately (see Table II).
it shows all detected faces as a clustered view. The user can
select a cluster, and then navigate to the time points where that TABLE II
face occurs in the video. Thus, the application can accelerate E STIMATED ENERGY CONSUMPTION OF MOBILE DEVICE
navigation in a video based on persons that occur within. Hardware Estimated Energy
A. Setup of the Evaluation Component Consumption (W)
Processor 0.4 (Idle: 0.05 )
Hardware. The hardware we are using in the evaluation Wi-Fi 0.75 (Low: 0.03)
is as follows. A Motorola Milestone mobile phone based on LCD 0.9
Android platform 2.2 is used in the evaluation. A desktop
computer which includes quad-core CPU acts as a cloud
provider that can host the offloaded computation. The details B. Results of the Use Case 1
about the hardware components for the mobile device and We use the algorithm by Sedgewick and Wayne1 . The basic
desktop computer are shown in Table I. idea is to use recursion and back-tracking to enumerate all
TABLE I
possible solutions. Although it is not the best algorithm, it is
H ARDWARE COMPONENTS OF MOBILE DEVICE AND DESKTOP COMPUTER often used for solving the N-queens puzzle. It is clear that with
the increase of N, much more steps are spent to find solutions,
Hardware which is extremely time-consuming for the mobile device.
Milestone PC
Component
We run the N-Queens on the local device and offload to
Processor ARM A8 600 MHz Quad-Core 2.83GHz
Memory 256MB 8GB the remote cloud separately, for N = 1 to N = 13. As when
WLAN Wi-Fi 802.11 b/g N/A N = 14, it will take hours to finish on the local device, it is
OS Android 2.2 Windows XP x64 not realistic not to be offloaded while doing computation after
N = 14.
Network Topology. While offloading services to the remote Figure 3 shows the time duration of execution of the specific
cloud, the mobile phone connects to a nearby access point. calculation service. From N = 1 to N = 9, the execution
Since the wireless local area network is encrypted with Wi-Fi speed on the local device is acceptable compared with the
Protected Access 2 (WPA2) security protocol, the data speed remote speed and to run the method locally is better, but after
is not as fast as non-encrypted considering of the overhead N = 10, the remote speed dominates to be the better option
introduced by the security protocol. The desktop computer is as the computation time dominates the total time in the rest
connected to the Internet directly by network cable, whose cases, and the remote execution speed is also relative stable,
bandwidth is 100 Mbps. there is no huge variation for remote speed.
Energy Estimation Model. We adopt a method as the Figure 4 shows the different time parts, which are made
one proposed by Zhang et al. [19], a power model for an up of the total spent time. With the increase of the queens
Android phone and a measurement application for the energy number, the local execution time increases outstandingly,
3 http://code.google.com/p/javacv 1 http://introcs.cs.princeton.edu/java/23recursion/Queens.java.html
 (a)
Fig. 5. Energy consumption of N-queens

TABLE III
V IDEO DURATION AND FILE SIZE

Duration File size

(seconds) (bytes)
10 1864984
20 3864612
30 5827420
40 7754219
50 9633240
60 11584020

so that the consumed energy is almost at the same level.

C. Results of the Use Case 2
(b)
Six video files are used in the evaluation. All of them belong
Fig. 4. Total time distribution of N-queens: (a) local execution and (b) remote to a same original video file with different length of time,
execution 10, 20, 30, 40, 50 and 60 seconds (see Table III). The video
resolution is 720 pixels × 480 pixels, the fps is set to 30, the
overall bit rate is 1500 Kbps and the video is compressed with
especially from N = 9, the execution time of calculating
MPEG-4 format, 3GPP Media Release 5 profile. The audio
solution occupies more than half of the total time. Meanwhile,
codec is AAC, and the bit rate for audio is 30 Kbps.
the overhead, our framework brings, stays constant. As for
In order to get an more accurate estimation of execution
the remote execution, the overhead is broken down to three
time which is used in the model, we first run the face detection
parts, one is the package offloading time, one is the decision
services locally, and keep track of the spent time (second) and
maker time, the rest one is the residual overhead. It shows
the file size (bytes), and then a linear regression is used to
that our decision model costs only little time to finish the
reflect the relationship between the spent time and the file
determination, and the transmission time of remote package
size. Considering the number of CPU instructions provided
occupies also few parts of total time, since the remote package
by Android API, it can only be used to make estimation on
is small. The execution time of solving the N-queens is relative
the execution which involves no native calls, we don’t directly
stable, except for the N = 11, which is a deviation during the
use that count, but focus on the execution time. The regression
execution and measurement.
shows that,
The last Figure 5 shows the results of consumed energy with
and without offloading. As for the local execution, most of the
T ime = 0.0005 ∗ F ileSize − 246.09 (16)
time is spent on computation, since our energy model involves
CPU and LCD, and the LCD is always on while computation, We use this heuristic equation in our model to make
so that the energy consumption of CPU and LCD dominates determination of the execution time.
the total energy consumption of local execution. The execution On Figure 6 can be seen clearly that the execution time
time is significantly increased from N = 9 compared to the is reduced hugely while offloading compared with the local
remote execution, which leads to the highest energy value. In execution. Even dealing with the 10 seconds video file, the
contrast to those, the remote execution time is nearly stable, local device spends more than 15 minutes on processing and
 TABLE V
V IDEO DURATION AND ENERGY SAVE

Duration
10 20 30 40 50 60
(seconds)
Energy
94.98 96.07 95.59 96.37 96.33 96.55
save (%)

Fig. 6. Execution time of face detection

TABLE IV
V IDEO DURATION AND SPEED UP OF FACE DETECTION IN VIDEO FILE

Duration
10 20 30 40 50 60
(seconds)
Speed up ×20 ×26 ×23 ×28 ×28 ×29
(a)

detecting, but the corresponding remote offloading takes only

less than 1 minute. Each time the computation is offloaded to
the remote cloud, the execution speed can be reduced to more
than 20 times, see Table IV. It is absolutely not acceptable to
let the CPU of local mobile device 100% load for such long
time, and it confirms that the video processing task is still a
huge burden for the mobile device.
With the huge difference between local and remote exe-
cution time, it can apparently conclude that the local energy
consumption is worse than the remote ones, because most of
the time are spent on CPU and LCD, which are the top two
of energy consuming components, see Figure 7. The Table V
also depicts the energy saving situation while offloading, the (b)
energy can be saved more than 94 percentage thanks to the Fig. 8. Total time distribution of face detection: (a) local execution and (b)
offloading. remote execution
Figure 8 describes the composition of the local and remote
total spent time in details. As the execution time increases
with the bigger video file size, the overhead our framework brings occupies about only 0.1%, which can be nearly omitted.
Regarding to the remote execution, the total spent time consists
of execution time, needed file transmission time, package
transmission (service offloading) time, decision maker time
and so on. With the increase of the video file size, the file
transmission time also raises, but compared to the total time,
it is not significant. The decision maker does its determination
in less than 1 second, which is only 1 percentage of the total
spent time. The total overhead our framework brings is about
5 percentage of the total time, which is acceptable considering
about the speed up and energy save above.
The face clustering can only be done on the remote cloud
because of the software limitation on the local mobile device.
Most of the execution time is spent on building/rebuilding
training set. If the training set is already available before the
remote execution, then the estimated execution time can be
Fig. 7. Energy consumption of face detection significantly reduced.
 VI. D ISCUSSION R EFERENCES
[1] M. Satyanarayanan, P. Bahl, R. Cáceres, and N. Davies, “The Case for
Offloading perhaps is not the suited for every mobile VM-Based Cloudlets in Mobile Computing,” IEEE Pervasive Comput-
applications, but from the results of the two use cases, we ing, vol. 8, no. 4, pp. 14–23, Oct. 2009.
see that when an application uses complex or time-consuming [2] P. Mell and T. Grance, “The NIST Definition of Cloud
Computing,” 2009. [Online]. Available: http://csrc.nist.gov/groups/
algorithms such as recursion, by offloading those parts into SNS/cloud-computing/cloud-def-v15.doc
the cloud, time and energy consumption are reduced, so that [3] D. Kovachev, Y. Cao, and R. Klamma, “Mobile Cloud Computing: A
the local execution time is reduced to an acceptable level. Comparison of Application Models,” CoRR, vol. abs/1107.4940, 2011.
[4] R. Kemp, N. Palmer, T. Kielmann, and H. Bal, “Cuckoo: a Computation
Offloading can lower the CPU load on a mobile device Offloading Framework for Smartphones,” in Proceedings of the 2nd
significantly. It can also save lots of energy, which indicates International ICST Conference on Mobile Computing, Applications, and
that the battery time can be increased compared to the local Services (MobiCASE 2010), Santa Clara, CA, USA, October 2010.
[5] X. Zhang, A. Kunjithapatham, S. Jeong, and S. Gibbs, “Towards an
execution, as shown in the second use case, where more than Elastic Application Model for Augmenting the Computing Capabilities
90% of energy is saved and the calculation speed is up to 20 of Mobile Devices with Cloud Computing,” Mobile Networks and
times over local execution. Applications, vol. 16, pp. 270–284, 2011.
[6] B.-G. Chun and P. Maniatis, “Augmented Smartphone Applications
The results also prove that the overhead of our framework is Through Clone Cloud Execution,” in Proceedings of the 12th Workshop
small and acceptable with the increase of needed computation, on Hot Topics in Operating Systems (HotOS XII). Monte Verita,
Switzerland: USENIX, 2009.
it is better to push those computations which cost considerable [7] S. Kosta, A. Aucinas, P. Hui, and R. M. X. Zhang, “Unleashing
resources to the remote cloud. But for the small N in the N- the Power of Mobile Cloud Computing using ThinkAir,” CoRR, vol.
Queens problem, the overhead occupies almost half of the total abs/1105.3232, 2011, informal publication.
[8] S. Ou, K. Yang, and J. Zhang, “An Effective Offloading Middleware for
execution time because of the needed computation is small so Pervasive Services on Mobile Devices,” Pervasive Mob. Comput., vol. 3,
that it takes only little time to obtain the results. This shows pp. 362–385, August 2007.
a clear advantage of local execution over remote offloading [9] E. Cuervo, A. Balasubramanian, D.-k. Cho, A. Wolman, S. Saroiu,
R. Chandra, and P. Bahl, “MAUI: Making Smartphones Last Longer
when the needed computation is not much. In a word, the with Code Offload,” in Proceedings of the 8th International Conference
more computation is needed, offloading has more advantage. on Mobile Systems, Applications, and Services (ACM MobiSys ’10). San
Since we use Wi-Fi in the evaluation, the time of sending files Francisco, CA, USA: ACM, 2010, pp. 49–62.
[10] I. Giurgiu, O. Riva, D. Juric, I. Krivulev, and G. Alonso, “Calling the
and receiving results has small proportion, but if 3G or GPRS Cloud: Enabling Mobile Phones as Interfaces to Cloud Applications,” in
are used, the offloading time will surely increase. Proceedings of the 10th ACM/IFIP/USENIX International Conference on
Middleware (Middleware ’09). Urbana Champaign, IL, USA: Springer,
Nov. 2009, pp. 1–20.
VII. C ONCLUSIONS AND F UTURE W ORK [11] X. Gu, A. Messer, I. Greenberg, D. Milojicic, and K. Nahrstedt, “Adap-
tive Offloading for Pervasive Computing,” IEEE Pervasive Computing,
The results show that the local execution time can be vol. 3, pp. 66–73, July 2004.
[12] X. Gu, K. Nahrstedt, A. Messer, I. Greenberg, and D. Milojicic,
reduced a lot through offloading, which is sometimes not ac- “Adaptive Offloading Inference for Delivering Applications in Per-
ceptable for users to wait for, and by pushing the computation vasive Computing Environments,” in Proceedings of the First IEEE
to the remote cloud can lower the CPU load on mobile devices International Conference on Pervasive Computing and Communications
(PerCom 2003). Dallas-Fort Worth, TX, USA: IEEE, 2003, pp. 107–
significantly thanks to the remote cloud, since most of the 114.
computations are offloaded to the remote cloud. Meanwhile, [13] X. Zhang, J. Schiffman, S. Gibbs, A. Kunjithapatham, and S. Jeong,
lots of energy can be saved which indicates users can have “Securing Elastic Applications on Mobile Devices for Cloud Comput-
ing,” in CCSW ’09: Proceedings of the 2009 ACM Workshop on Cloud
more battery time compared to the local execution. The results Computing Security. Chicago, IL, USA: ACM, Nov. 2009, pp. 127–134.
also prove that the overhead of our framework is small. [14] X. Zhang, S. Jeong, A. Kunjithapatham, and S. Gibbs, “Towards an
Our framework supports offloading of multiple Android Elastic Application Model for Augmenting Computing Capabilities of
Mobile Platforms,” in Third International ICST Conference on Mobile
services. If there are multiple services in one application and Wireless Middleware, Operating Systems, and Applications, Chicago, IL,
all of those services can be offloaded to the remote clouds, USA, 2010.
our resource monitor natively supports this situation and can [15] R. Kemp, N. Palmer, T. Kielmann, F. Seinstra, N. Drost, J. Maassen, and
H. Bal, “eyeDentify: Multimedia Cyber Foraging from a Smartphone,” in
make the corresponding allocation determination, so that some Proceedings of the 11th IEEE International Symposium on Multimedia
of the services should be offloaded and the rest of the services (ISM 2009) , 2009, pp. 392–399.
should be run locally. [16] J. K. Ousterhout, “Scripting: Higher Level Programming for the 21st
Century,” IEEE Computer, vol. 31, pp. 23–30, 1997.
The next steps are to enable parallelization of the offloaded [17] K. Kumar and Y.-H. Lu, “Cloud Computing for Mobile Users: Can
services. Additionally, we can extend the current middleware Offloading Computation Save Energy?” Computer, vol. 43, no. 4, pp.
so that it supports automatic partitioning arbitrary mobile 51–56, April 2010.
[18] M. Turk and A. Pentland, “Eigenfaces for Recognition,” J. Cognitive
applications. A great challenge is how to estimate the char- Neuroscience, MIT Press, vol. 3, pp. 71–86, January 1991.
acteristics of an application depending on different input [19] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. P. Dick, Z. M. Mao, and
parameters, which is precisely the relationship between the L. Yang, “Accurate Online Power Estimation and Automatic Battery
Behavior Based Power Model Generation for Smartphones,” in Pro-
input of the invoked method and the execution time. We could ceedings of the Eighth IEEE/ACM/IFIP International Conference on
characterize the relationship between execution time and input Hardware/Software Codesign and System Synthesis. ACM, 2010, pp.
parameters by running the target application several times and 105–114.
adapt the offloading algorithm.

View publication stats