Leveraging Service Clouds for Power and QoS Management for Mobile Devices
Yunqi Ye, Liangliang Xiao, I-Ling Yen, Farokh Bastani
Department of Computer Science
University of Texas at Dallas
{yxy078000, xll052000, ilyen, bastani}@utdallas.edu
Abstract. We propose a QoS and power management (QPM)
framework for mobile devices making use of the service
cloud. Several techniques for the realization of the QPM
framework have been developed. First, we develop a
function pool based prediction model to predict the power
and QoS behaviors of the task activated by a mobile device.
Based on the prediction, we design the cost function and the
decision algorithm for selecting the best platforms for
executing the services/applications in order to achieve
optimal energy saving while satisfying QoS requirements.
Several service and data migration policies have been
designed for a service to be migrated and executed on a
mobile device to achieve power and QoS gains. We apply
the QPM framework and associated techniques to a facial
recognition case study system to validate our approach.
Experimental results show that, in the best case, the QPM
framework can achieve 66.7% energy saving for the mobile
device and at the same time, reduce the response time by
54.3%.
Keywords: mobile device, service cloud, power
management, quality of service (QoS), data migration,
service migration.
1 Introduction
Mobile devices are becoming the primary platforms for
many users to roam around and to access the service cloud.
With the advances in mobile devices and the supporting
environment, the user tasks issued on mobile devices are
increasing in complexity and sophistication. However,
limited battery life of the mobile device is a major concern,
especially when recharging is not available. According to a
survey from ChangeWave Error! Reference source not
found. on Apple’s iPhone 3GS in 2009, short battery life is
considered as the most disliked feature by 41% of the
respondents. A Nokia poll in 2009 Error! Reference
source not found. also shows that the battery life is the
most important feature for a music phone, instead of sound
quality. In critical applications, loss of power can adversely
impact mission success and cause severe consequences.
There have been a lot of works addressing the power
management issues. For example, the dynamic power
management (DPM) approaches Error! Reference source
not found. try to turn off the devices when they are idle. In
the dynamic voltage and frequency scaling (DVFS)
approaches [4, 5, 6], the processor can work under various
performance-states (p-state) that provide tradeoffs between
execution performance and energy consumption. These
works focus on power management on local devices and can
save 9-50% energy at the cost of reduced performance.
Cloud computing is a promising paradigm, enabling
accesses to a pool of configurable computing resources such
as networks, servers, storage, applications and services.
Service oriented computing (SOC) has brought added values
to this paradigm. SOC can deliver an integrated suite of
functionalities to end users through discovery and
composition of loosely and tightly coupled services. All the
computing resources, smart devices, applications, data and
information sources in the cloud can be wrapped as services,
creating a service cloud that can provide much richer
capabilities than a single device. With the service cloud, the
mobile users can offload tasks to the cloud for execution so
that the local computation can be totally eliminated, which
has the potential of achieving very significant energy saving.
In fact, for some computation-intensive services, it is
possible to save energy as well as reduce processing latency
if they are executed in the cloud. However, task offloading
involves communication costs for request uploading and
response downloading. For some communication-intensive
services, the power consumed for communication may
exceed potential savings if executed in the service cloud.
Thus, to actually achieve power saving, it is necessary to
make the execution platform selection decisions properly to
balance the computation and communication costs tradeoffs.
In Error! Reference source not found., we have proposed
a preliminary architecture for QoS and power management
(QPM framework) for mobile devices in a service cloud (as
shown in Figure 1).
Figure 1. QPM framework
The QPM framework includes the service profile that
provides the QoS and power behavior specifications of the
services under different configurations and the user profile
that specifies the users’ historical service usage patterns.
The schemas of service and user profiles are given in [7].
With the service cloud, many tasks activated by a mobile
user may involve a composed service chain, including
services on the mobile device and/or in the service cloud.
One major component in QPM is the service execution
platform selection decision module (SEPSDM) which
selects the appropriate service execution platform (mobile
device or service cloud) to satisfy the QoS constraints and
achieve maximum energy saving. To support SEPSDM
processes, it is necessary to predict the QoS behaviors with
various input parameters and executing environments, which
is done by the QoS prediction module (QoS-PM). To allow
the selection of execution platforms, it is necessary for the
service/application to be available on the mobile device as
well as in the service cloud. When it is not the case, service
and the associated data should be migrated to the mobile
device, which is done by the service and data allocation
module (SDAM). Another important component in the QPM
framework is the service migration infrastructure (SMI) that
is used to minimize the communication latency by migrating
some frequently used services of a user to platforms in the
service cloud that are close to the user. Several prior works
have investigated the service migration infrastructure
implementation and migration decision issues [8, 14].
Realization of the QPM framework requires advanced
techniques for implementing QPM components, which was
not considered in [7]. In this paper, we focus on the schemes
for realizing QoS-PM, SEPSDM, and SDAM in the QPM
framework.
Accurate prediction of QoS behavior is the key to the
success of the QPM framework. We develop a function pool
based prediction (FPP) model for QoS-PM. FPP is based on
the parametric regression approach, but enhanced with a
parametric function pool FP to facilitate the proper selection
of the parametric function. FPP not only optimize the
parameters for the functions mapping input and system
characteristics to QoS behaviors based on the data stored in
the service profile, but also optimize the selections of the
parametric functions. It uses the Conjugate-Gradients
Method (CGM) to optimize the squared correlation
coefficient for each QoS behavior and use the selected
relation function for QoS prediction. Experimental results
show that FPP can predict QoS relatively accurately and
yields higher prediction accuracy than the standard
parametric regression prediction model.
For SDAM, we develop a migration cost model and
compare the migration cost and potential gains to make a
service migration decision. For the service related backend
data, we consider both the full and partial data migration
policies according to the divisibility of backend data and the
QoS impacts of the size of partial data set to optimize the
energy consumption on mobile device.
In SEPSDM, we design an interface to allow users to
specify the end-to-end QoS constraints and objectives for
the service chain execution and use them to guide the
decision process for selecting the optimal service execution
platforms. To support efficient on-the-fly decision making,
we consider a one sub-chain selection approach to greatly
reduce the decision space. Instead of making execution
platform decisions for each individual service, we select one
entire sub-chain for potential service cloud execution. To
achieve the one sub-chain selection approach, we also
design a proxy based service execution architecture, which
uses a proxy server to mediate service execution in the cloud
so that the mobile device only needs to process one sending
and one receiving message, which further reduces the
2
energy cost for communication on the mobile device.
Experimental results show that SDAM and SEPSDM do
reach the best migration and service execution platform
selection decisions and achieve significant energy saving
while improving QoS behaviors.
The rest of the paper is organized as follows. Section 2
discusses the function pool based QoS prediction model. We
introduce service execution platform decision making
algorithm in Section 3. Section 4 presents the service and
data migration policies. Experimental studies and results are
discussed in Sections 5 to show the effectiveness of the
framework. Then the paper is concluded in Section 6.
2 QoS Prediction
QoS-PM plays a critical role in the QPM framework. For
a given service chain, QoS-PM needs to estimate the QoS
behaviors of each service in the chain and then aggregate
them for a specific execution platform selection. Various
prediction technologies such as neural networks, Bayesian
prediction, and regression model, have been used in the
literature to make prediction based on historical data.
Regression based approaches have been successfully used in
the literature for various predictions, such as biological,
social science, stock price, market forecasting. There are
two major types of regression models, parametric and nonparametric. The parametric regression model uses a
predetermined parametric function to best fit the set of
observed data. The parameters of the function are
determined by minimizing the distance of the estimated
values to the original data (this is also known as the method
of least squares). Many optimization algorithms, such as
Levenberg-Marquardt (LM), Quasi-Newton (BFGS),
Conjugate-Gradients Method (CGM), etc., have been
developed to derive the parameters in the optimization
problem. The selection of the parametric function has a
significant impact on the accuracy of the prediction.
However, there is no standard method for parametric
function selection and it depends on the expertise knowledge
to the model as well as the data. The non-parametric model
is built directly upon the sample data without any
predetermined function. Three common methods, including
kernel regression, local polynomial regression, and
smoothing splines Error! Reference source not found.,
can be used to estimate the regression function. But it
requires a very large sample size and extensive computation
to support the model structure and the model estimates.
In QPM framework, data for different applications and
different QoS attributes are collected and for each data set, a
different parametric function is needed. Also, the analyses
need to be done automatically due to the potential of a large
number of applications and continuously updated data
repository. Thus, the parametric based approach will not
work. On the other hand, the dataset for each QoS attribute
and for each application in QoS-PM repository may be
relatively small. Therefore, the nonparametric based
approach cannot be used effectively either.
We propose a function pool based prediction (FPP)
model for QoS-PM. FPP is based on parametric regression
but introduces a parametric function pool FP. Usually,
without the expertise knowledge, the common choice of
regression function is a linear or a polynomial parametric
function. In FP, we collect basis parametric functions such
as linear, polynomial, logarithm, exponential, and the
rational forms and linear combinations of the basis
parametric functions. Then in FPP, we optimize both the
regression model and the selection of the parametric
function. Thus, FPP can yield better predictions than
conventional parametric regression with a linear or
polynomial parametric function. To avoid the potential
overhead in FPP while achieving accurate prediction, we use
the iterative algorithm Conjugate-Gradients Method (CGM)
to optimize the regression model, and set the maximum
iterative times for CGM to control the time cost.
We apply FPP model to predict QoS behaviors of an
individual service S based on the historical information
stored in the service profile S.SP. S.SP specifies the QoS
behaviors of S, which depend on the input/output
characteristics (IOC) such as input/output size, service
related configurable parameters (CP) such as encryption key
size, execution platform characteristics (EPC) such as CPU
speed, power policy, operating system, and network location
of the service. Let IOCj, 1 ≤ j ≤ s, denote the variables of
IOC; CPj, 1 ≤ j ≤ t, denote the variables of CP; and EPCj, 1
≤ j ≤ u, denote the variables of EPC (each variable
represents one characteristic). Also, let QoSj, 1 ≤ j ≤ v,
denote the variable of QoS (each variable represents one
QoS attribute, such as the communication latency, execution
time and power consumption). Thus, each data entry in S.SP
can be represented as
(ioci,1, …, ioci,s, cpi,1, …, cpi,t, epci,1, …, epci,u, qosi,1, …,
qosi,v), 1 ≤ i ≤ N,
where ioci,j / cpi,j / epci,j denote the sample of the dependent
variable IOCj / CPj / EPCj, respectively, and qosi,j denotes
the sample of the independent variable QoSj. For each QoSj,
1 ≤ j ≤ v, FPP establish the candidate relations
QoSj = fk(IOC1, …, IOCs, CP1, …, CPt, EPC1, …, EPCu,
k,1, …, k,m)
where k,1, …, k,m are the parameters of the parametric
function fk  FP. FPP first finds the solution for parameters
k,1, …, k,m, for each fk  FP, by minimizing the distance
between the observed and estimated values of the dependent
variable QoSj, for all j, i.e.,
min ∑1≤𝑖≤𝑁 𝑞𝑜𝑠𝑖,𝑗 − 𝑓𝑘 (𝑖𝑜𝑐𝑖,1 , … , 𝑖𝑜𝑐𝑖,𝑠 ,
𝛽𝑘,1 ,…,𝛽𝑘,𝑚
𝑐𝑝𝑖,1 , … , 𝑐𝑝𝑖,𝑡 , 𝑒𝑝𝑐𝑖,1 , … , 𝑒𝑝𝑐𝑖,𝑢 , 𝛽𝑘,1 , … , 𝛽𝑘,𝑚 ))2
Various optimization algorithms such as LevenbergMarquardt (LM), Quasi-Newton (BFGS), ConjugateGradients Method (CGM), etc., can be applied to solve
k,1, …, k,m. After the candidate relations are solved, FPP
computes the squared correlation coefficient Rk2, which is
3
used to confirm the goodness and the statistical significance
of the estimated parameters. The formula of Rk2 can be
found in Error! Reference source not found. and is
𝑗
omitted here. FPP selects the optimal parametric function 𝑓𝑘
for QoSj, i.e., the corresponding relation has the greatest Rk2
𝑗
value. Then, FPP use 𝑓𝑘 to predict the QoSj value qosj for
given IOC/CP/EPC characteristics, i.e.,
𝑗
qosj = 𝑓𝑘 (ioc1, …, iocs, cp1, …, cpt, epc1, …, epcu,
k,1, …, k,m).
3 Service Execution Platform Selection
In the QPM framework, each task is composed of a
chain of services. Let T = <A, S1, S2, …, Sn, F> denote a
service chain of a user task where A is the task activation
and input data capturing (such as taking a picture) and F is
the action for displaying the final results. As can be seen, A
and F have to be executed on the mobile device. Si, 1 ≤ Si ≤
n, are individual services in the chain. Si may be hosted by
the service cloud, the mobile device or both of them.
SEPSDM selects the execution platforms for Si to achieve
best QoS and energy saving objectives.
Since each service Si in T can be executed either in the
service cloud or on the mobile device, there are totally 2n
possible solutions, which is infeasible for SEPSDM. Though
heuristic search algorithms can be used to find the best
solutions in the large search space, we choose to further
explore the problem and determine its effective solution
space. In the following subsections, we consider the
implementation issues in SEPSDM as well as the decision
space reduction approach and the decision algorithm for the
service execution platform selection problem.
3.1
Proxy Server
When invoking a sequence of services in the service
cloud, the current technology requires the invoker to
communicate with each service to issue the request and
receive the responses. If the invoker is the mobile device,
then there will be significant communication overhead for
the mobile device, which also results in power consumption.
Even though executing the service in the cloud would result
in QoS gains, additional techniques can be used to further
reduce the overhead for the mobile device. We consider
designating the invoker role to a proxy server in the cloud
such that the execution of a sequence of services can be
done without needing the involvement of the mobile device.
The proxy server can be a node in the cloud that is closest to
the mobile device. Figure 2 illustrate the use of the proxy
server. With the proxy server, for executing a service
sequence <Si, …, Sj>, the mobile device only needs to send
the request of Si to the proxy server and receive the final
response of Sj from it, greatly reducing the overall
communication cost and power consumption on the mobile
device.
Figure 2. Proxy Server
Consider an SEPSDM solution in that the first service to
be executed in the cloud is Si and the last is Sj. Also, assume
that the sub-service-chain between Si and Sj (including Si and
Sj) can be further decomposed into a series of service
sequences Seq1, Seq2, …, Seqk where all the services in one
sequence are executed in the same environment, either in the
cloud or on the mobile device, and any two consecutive
sequences are executed in different environments. Note that
the first and the last sequences are executed in the cloud.
Each time the execution switches from one sequence to
another, the mobile device has to send or receive one
message to or from the proxy server. Assume that the proxy
hosts all the services that are on the mobile devices it serves.
Now consider the case that k > 2. Seq2 will be executed on
the mobile device. However, if Seq2 is executed in the cloud,
it is highly likely that the total latency and the mobile device
power consumption will be reduced. In case executing Seq2
by their original service providers incurs a high overall
communication cost, then it can be executed on the proxy
server, resulting in a lower cost than executing it on the
mobile device. The same is true for all other sequences are
to be executed on the mobile device. Thus, the optimized
solution is to have only one sequence in the sub-servicechain, i.e., we should identify a single sub-service-chain for
cloud execution so that the mobile device only needs to
interact with the cloud once. Specifically, in SEPSDM, we
select one and only one sub-service-chain SubT of T for
cloud execution. Let Si be the first service in SubT and Sj be
the last, i ≤ j. Selecting two indices i and j out of n has a
solution space of 𝐶2𝑛 , which is much less than 2n.
In the service cloud, the proxy service can be considered
as a migratable service. SMI can select the most suitable
locations to host proxy services for mobile devices. Also, to
minimize the communication overhead, SMI is likely to
migrate all the migratable services that are hosted by the
mobile devices to the proxy server. Thus, the solution of
selecting a single sub-service-chain will be feasible.
3.2
Service Execution Platform Selection
When a user activates the task T, it can specify a set of
QoS constraints and objective functions for the service
execution. Let RC = {ci, wi| 1≤i≤N} denote the N constraints
where ci is the constraints value for the ith QoS attribute and
wi is its weight that reflects the preference degree of the user
on this constraint. Also, let RO = {(oj, uj) | 1≤j≤M} denote
the QoS objectives where oj is an objective function and uj is
its weight. The overall objective value of an SEPSDM
solution sol is computed as follows:
O(sol) = ∑𝑀
𝑗=1 𝑢𝑗 ∗ 𝑜𝑗 (𝑠𝑜𝑙)
4
Based on RC and RO, and the prediction results from
QoS-PM, SEPSDM makes the service execution platform
selection decisions as shown in Figure 3.
First, all the possible solutions in the solution space are
inserted into a set Solution_Set and we apply QoS-PM to
each solution in it. Generally, there will be some dominated
solutions (we say that a solution is dominated when there is
SEPSDM (T, RC, RO):
1. Solution_Set := the solution space
for each solution sol in Solution_Set
sol.QoS := QoS_PM(sol)
end for
2. Eliminate dominated solutions from Solution_Set
3. Normalize each QoS attribute into range [0, 1] for each
solution in Solution_Set
4. Candidates := ∅
for each solution sol in Solution_Set
if sol satisfies RC, then put sol into Candidates
sol.Objective := O(sol)
end if
end for
if Candidates ≠ ∅, then
Select solution with lowest sol.Objective in Candidates
5. else, then Candidates := Solution_Set
for each solution sol in Candidates
sol.Objective := O'(sol)
end for
Select solution with lowest sol.Objective in Candidates
end if
Figure 3. Service Execution Platform Selection Decision
another solution that has better behavior in all QoS attributes)
from that we cannot achieve any benefits. Thus, we can
eliminate these dominated solutions to reduce the space of
candidate solutions further. Also, since various QoS
attributes may have very different value ranges, it is not fair
to directly use the original values of the QoS attributes to
compute the overall objective of a solution. So we normalize
all the QoS attributes to the same value range such as [0, 1].
Then for each of the remained solutions in Solution_Set, if it
can satisfy the RC, put it to the candidate solution set
Candidates. And from Candidates, we select the solution
with the lowest overall objective value.
Sometimes we may find that there is no solution that can
satisfy all the constraints in RC. In this case, rather than
reporting an error, we consider all the solutions in
Solution_Set as candidates and try to select the solution that
has the best overall result regarding the objective and QoS
violations. Let sol.QoS = {sol.vi | 1≤i≤N} denote the
estimated QoS of solution sol where sol.vi is the QoS value
of the ith attribute. We use the following equation to
compute the distance of QoS violations of a solution sol:
Dist(sol) = ∑𝑁
𝑖=1 𝑤𝑖 ∗ 𝐷𝑖𝑠𝑡𝑖 (sol), where
|𝑠𝑜𝑙. 𝑣𝑖 − 𝑐𝑖 |, 𝑐𝑖 𝑖𝑠 𝑛𝑜𝑡 𝑠𝑎𝑡𝑖𝑠𝑓𝑖𝑒𝑑
Disti(sol) = {
0,
𝑒𝑙𝑠𝑒
Here we assume that ci and sol.vi are all normalized values
to make sure that each attributes are considered fairly. From
the equation we can see that when the QoS violation is
minor, the value of Dist(sol) is also small. The overall
objective of sol is updated to the following equation:
O'(sol) = O(sol) + Dist(sol)
Then, O' instead of O is used to evaluate each solution.
A lower value of O'(sol) implies that solution sol has both
lower objective value and lower QoS violation distance.
SEPSDM will select the solution with lowest O' value for
following execution.
4 Service and Data Allocation
To take advantage of the QPM framework, we need to
have services replicated on the mobile device if local
execution can achieve some QoS benefits. However, mobile
devices are resource constrained. It is impossible to have all
services on the mobile device. Thus, services may be
migrated to the mobile devices dynamically based on the
migration policies of SDAM. We discuss the service
migration issues in Subsection 4.1. Some services have
dependency to their backend data. Thus, SDAM should
consider data migration as well. We consider the full and
partial data migration policies in Subsection 4.2 according to
the backend data characteristics.
4.1
Service Migration
Some service may depend on some special hardware or
software at its local site and, hence, cannot be migrated. For
a migratable service, the service provider should prepare
installation packages for different mobile platforms and
make them available in the service cloud. These packages
can be used for service installation on the mobile device.
To make an appropriate decision of migrating a service
to a mobile device, we need to consider the potential
migration cost and gains. We construct the migration cost
model based on the service installation cost (IC), the data
consistency maintaining cost (CC) and the resource cost (RC)
on mobile device. Since SDAM will not make migration
decision if there are no QoS benefits of local execution, in
the cost model, we focus on the energy and space cost.
When SDAM consider a service for migration, it can use
QoS-PM to predict the installation energy cost IC since
SDAM is also a service in QPM. Generally, installing a
service is a one-time operation, so we can set IC = 0 if the
installation is performed when battery recharging is
available:
0, 𝑖𝑓 𝑏𝑎𝑡𝑡𝑒𝑟𝑦 𝑐𝑎𝑛 𝑏𝑒 𝑟𝑒𝑐ℎ𝑎𝑟𝑔𝑒𝑑
IC(S) = {
𝑄𝑜𝑆 − 𝑃𝑀(𝑆𝐷𝐴𝑀, 𝑆),
𝑒𝑙𝑠𝑒
The consistency maintenance energy cost CC depends
on the backend data consistency synchronization frequency
(sync_freq). For example, with strong consistency model, all
update accesses (including the updates issued by other users)
involve consistency synchronization operations that may
impact not only the energy consumption but also the service
QoS significantly. CC can be estimated from the service
profile and historical access pattern as following where
sync_cost can be predicted by QoS-PM:
5
0, 𝑖𝑓 𝑏𝑎𝑐𝑘𝑒𝑛𝑑 𝑑𝑎𝑡𝑎 𝑖𝑠 𝑟𝑒𝑎𝑑 𝑜𝑛𝑙𝑦
CC(S) = {
𝑠𝑦𝑛𝑐_𝑓𝑟𝑒𝑞 ∗ 𝑠𝑦𝑛𝑐_𝑐𝑜𝑠𝑡,
𝑒𝑙𝑠𝑒
The resource cost (RC) is the space occupation for the
service and the migrated data on the mobile device. The
total migration cost MC(S)is:
MC(S) = (IC(S)+CC(S), RC(S)).
Consider a user u, according to the potential energy
saving(ES) of executing a service S locally and the access
frequency (AF), the migration gain (MG) of energy
u.MG(S) = ES*AF
The resource capacity of the user (u.RP) generally is the
current available space. But the user can also constrain RP
and preserve some space to install other services in the
future according to the space cost of other users with similar
user profiles.
Based on the above migration cost model, given a
service S and user u, only if MC(S) < u.MG(S) and the RC(S)
<u.RP, SDAM may recommend u to download and install
the service on the mobile device. The user can then decide
whether to authorize the migration.
4.2
Data Migration
Many services need to access their backend data to the
serve the users. Let S.Data denote the backend data set of S.
Some services may require the whole data set for execution.
In contrast, some services can work with partial data but
provide trade-offs on different QoS attributes and energy
consumption. According to the characteristics of S.Data and
the various QoS impacts of the backend data, we consider
full and partial data migration policies.
Full Migration. The simplest case is to migrate all the
backend data to the mobile device. When the whole data set
is critical for service execution, this policy is the only choice.
Sometimes, even if the service can work with a subset of the
data, but using the whole data set on the mobile device may
not have significant impacts on the QoS according to the
QoS-PM results. Then, the data can also be fully migrated to
the mobile device. With this policy, the backend data are
integrated into the installation packages and downloaded to
the mobile device automatically when the service is installed.
Partial Migration. Some services can be executed with
a subset of the data. For example, in a facial recognition
service, a face database is used for pattern comparing and
the algorithm can work with a subset of the face database.
This not only yields reduced space cost, but also may imply
lower computation cost. But using a smaller dataset may
degrade the recognition quality because the required data
item may not be migrated. SDAM can switch the execution
platform to service cloud automatically when local
execution encounters the data miss at the cost of both local
and remote execution. However, since the potential set of
data items to be used for a specific user generally is much
less than the whole set, we can still achieve the benefits with
the small data set without significant QoS penalty. SDAM
can select and adjust the data item set for a user according to
the data access pattern.
5 Experimental Studies
We conduct experiments to evaluate the effectiveness of
the QPM techniques. The experimental system consists of a
mobile device and a simulated service cloud. The mobile
device is a Netbook with Intel® Atom(TM) CPU N270
@1.60GHz 1.60GHz, 1GB memory and Ubuntu 9.10
operating system. We have used the open source project
PowerTop [12] to obtain the battery power consumption
data for the services running on the mobile device. The
systems that simulate the service cloud are PCs with Intel®
Core 2 E8400 @ 3.00GHz, 3.24 GB Memory and running
Ubuntu Linux v9.10 operating system. Tomcat 6.0 is
deployed in the machines to host the services. The mobile
device accesses the service cloud through a 54Mb wireless
LAN. In the experiments, we do not consider SMI and
assume that the services are already migrated to the
platforms that are close to the user.
data. We derive the prediction interval for each QoS
attribute based on a predetermined confidence level Error!
Reference source not found. and examine whether the
actual measurement fall in the prediction interval. Let 
denote the significance level and we set  = 0.05 (i.e., the
confidence level is 1− = 0.95). We select a new setting for
IS and DIS (specifically we selected IS = 50240 and DIS =
3891) and apply FPP to predict the corresponding LE, LL,
RE, RL values and their prediction intervals. Then, we
conduct experiments to obtain LE, LL, RE, RL measures for
the new IS and DIS. The results are shown in Figure 5 and
summarized in Table 1. In Table 1, MV represents the
measured value, PV represents the predicted value, and PI
represents the prediction interval. As can be seen from the
table, the measurement values always fall in the prediction
intervals computed from FPP with  = 0.05. Also, the errors
of the estimated values are reasonably small.
LE
LL
RE
RL
MV
0.016
0.053
0.024
0.292
PV by FPP
0.0171
0.066
0.0277
0.314
PI by FPP
[0.0077, 0.0265]
[0.038, 0.094]
[0.0212, 0.0342]
[0.287, 0.341]
Table 1. Prediction of FPP model
Figure 4. Service chain for facial recognition application
We use a facial recognition service chain as a case study
system. Consider a user attend a conference. She/he may
recognize a face but cannot recall the person’s name and
other information. The user can compose a service chain as
shown in Figure 4: first a picture of the person is captured
by the mobile device, then the picture is resized to fit the
size of the face database, then a facial recognition service is
activated to identify the person in the picture, next the
detailed information about the person is retrieved, and
finally the retrieved information is displayed on the device.
5.1
QoS-PM
We apply the prediction model based on the data
collected in service profile for each service in the case study
system. Due to space constraints, we select the image
resizing service to illustrate the prediction accuracy of our
function-pool based prediction (FPP) model.
In the experiment, we consider two QoS attributes: the
access latency and energy consumption for both local and
remote executions. Let LE, LL, RE, and RL denote local
energy, local latency, remote energy, and remote latency,
respectively. The four QoS behaviors depend on the input/
output characteristic inputsize (denoted by IS) and the
configurable parameter of the image resizing service
DBImageSize (denoted by DIS). The historical data mapping
different IS and DIS values to LE, LL, RE, and RL are stored
in the corresponding S.SP. For different QoS behavior, the
number of data entries in S.SP varies from 9 to 19. Every
selected optimal parametric function 𝑓𝑘𝐿𝐸 / 𝑓𝑘𝐿𝐿 / 𝑓𝑘𝑅𝐸 /𝑓𝑘𝑅𝐿 has
high Rk2 value, which is great than 0.98.
We study the prediction quality of the FPP model by
comparing the prediction results and the actual measurement
6
5.2
SEPSDM and SDAM
We use “xxx” to denote the execution platform selection
solutions for the three services in the case study, where x is
“L” (corresponding service is executed on the mobile device)
or “R” (corresponding service is executed in the service
cloud). For example, LRL represents that image resizing and
personal information retrieval services are executed on
mobile devices while the facial recognition service is
executed in the service cloud. Also, we use BASE to denote
the base line configuration, in which all services are
executed on the mobile device and the facial image database
is fully replicated on the mobile device (it is different from
LLL in which SADM allocates partial database on the
mobile device).
We assume that the image resizing, facial recognition
and personal information retrieval services have already
been deployed in the service cloud and also installed on the
mobile device. The data allocation policies for them are as
follows:
 Image resizing service: no data involvd.
 Facial recognition service: The size of the face
database and the image size in the face database can
impact the response latency and energy consumption.
We consider partial data migration policy so that the
mobile device only needs to store the faces of the
people that the user would like to know. Also, we
consider three different face databases with three face
image sizes as summarized in Table 2.
Face
Database
FaceDB-A
FaceDB-B
Image Size
(pixels)
50×50
90×100
#Images
890
890
#Images
for LLL
250
250
256×384
224
lower endpoint
upper endpoint
measured value
0.35
0.3
0.25
0.2
0.15
0.1
0.05
0
80
BASE
25
Latency (s)
0
RE
LLL
LRL
QPM
BASE
Latency (s)
40
QPM
LRL
Figure 11. Energy for various person database
5
80
LLL
LRL
QPM
60
40
20
890
50000
#records in person
information database
Figure 10. Latency for various person
database
QPM
LLL
LRL
QPM
15
10
30
20
10
0
890
50000
#records in person
information database
10
0
LLL
20
0
15
Input size (pixel)
50
5
LRL
Figure 9. Energy for various input size
QPM
10
LLL
10
8
6
4
2
0
25
15
20
Figure 7. Energy for various face database
Energy (mAh)
LRL
QPM
Figure 6. Latency for various face database
Input size (pixel)
LLL
LRL
FaceDB-AFaceDB-B FaceDB-C
Face DB
RL
Figure 8. Latency for various input size
LLL
0
Latency (s)
LL
BASE
FaceDB-A FaceDB-B FaceDB-C
Face DB
Energy (mAh)
BASE
Energy (mAh)
QPM
20
25
20
15
10
5
0
5
0
100 150 (E)150 (L) 250
Local Face DB Size and QoS
Objective
Figure 12. Latency for various local face
database size
Personal information retrieval service: the latency and
energy consumption depends on the number of records
and information length in the person database. So
we consider partial or full data migration policy.
Impact of the image size of the face database. The
latency and energy consumption for the case study system
under different face databases with different image sizes are
shown in Figures 6 and 7. In the figures, the data of BASE
for FaceDB-C is missing because the mobile client is not
7
LRL
40
Figure 5. Measured values and prediction
intervals

LLL
60
LE
Latency (s)
Table 2. Face Databases
60
Energy (mAh)
FaceDB-C
100 150 (E) 150 (L) 250
Local Face DB Size and QoS
Objective
Figure 13. Energy for various local face
database size
capable to finish the facial recognition service with FaceDBC within a reasonable latency (more than 1 hour). Here LLL
only migrates a subset of images from the remote face
database. We can see that even without considering
SEPSDM, LLL can still work much better than the baseline.
In the experiments, LRL is the best solution for both latency
and energy. The QPM can decide to use LRL and yield
better results than LLL. But due to the execution of QoS-PM
and SEPSDM, the latency and energy cost of QPM are a bit
higher than that of LRL.
Impact of the input image size. We study the impact of
different input image sizes on system QoS. FaceDB-A is
used in the experiment. The results are presented in (Figures
8 and 9). Similar to the previous case, BASE has the worst
result. LRL is still the best solution. QPM yields a bit higher
cost than LRL but lower than LLL. The energy saving and
latency improvements comparing to the baseline are
summarized in Table 3. For this application, in the best case
we can reduce 71.4% energy consumption as well as
improving the access latency by 44.0%.
Input Size
50×50
90×100
200×200
300×300
400×400
500×500
Energy Saving
66.7%
42.9%
71.4%
50.0%
37.5%
33.3%
Latency improvement
54.3%
51.1%
44.0%
37.0%
11.5%
24.7%
Table 3. Energy saving and latency improvement by QPM
Impact of the number of records in the person
database. Now we study the impact of the number of
records and record lengths of the person database on system
QoS. A long record length (i.e., a lot of information about
one person) implies a high communication cost when the
service is executed in the service cloud. When the database
contains a large number of records, the query processing
becomes costly, resulting in high access latency and energy.
As shown in Figures 10 and 11, when the database contains
50000 records, the local execution of this service will yield a
high cost and LRR is the best solution (which is correctly
selected by QPM). In this case, the partial data migration
policy is more suitable than the full migration policy. For
example, when the user only need 890 records in the person
database, executing the personal information retrieval
service on mobile device will be better (QPM correctly
selected LRL).
Impact of the size of the migrated face database. We
consider three local face database sizes for FaceDB-A: 100,
150 and 250. When there are 100 images in local face
database, executing the facial recognition service on mobile
device yields better latency and energy than executing it in
the service cloud. Thus, LLL is always the best solution. In
contrast, when there are 250 images, executing the service in
the service cloud yields better latency and energy. So, LRL
is always the best solution. When there are 150 images in
local face database, executing the service on the mobile
device results in a better latency but a higher energy
consumption than executing it in the service cloud. Thus, if
the user prefers to minimize latency, LLL should be the best
solution. If saving energy is the priority for the user, then
LRL will be the best solution. As shown in Figures 12 and
13, SEPSDM can always select the best solution according
to local face database size and the QoS objective of the user.
8
6 Conclusion
We have proposed the QPM framework in [7] to
leverage service cloud to provide power saving on the
mobile devices while satisfying QoS requirements of the
user task. In this paper, we develop techniques for
implementing the important components in QPM framework,
including QoS-PM, SEPSDM and SDAM. We also design a
case study system to validate the QPM framework and
evaluate the effectiveness of the techniques we used for
implementing QoS-PM, SEPSDM and SDAM. The
experimental results show that our techniques can yield
significant power saving and at the same time, improved
QoS. In the best case, the QPM framework approaches
achieves 66.7% energy saving while reducing the access
latency by 54.3%, attributed to accurate QoS behavior
prediction, proper service platform selection and good data
migration decisions. This work positively confirm the
feasibility and effectiveness of using service cloud to
achieve power saving and extend the battery life for mobile
devices.
Acknowledgement
This research is supported in part by grants provided by
the Net-Centric Industry University Collaborative Research
Consortium (IUCRC) industrial membership and in part by
the National Science foundation (NSF). We wish to thank
our research sponsors for their support and review.
References
[1] http://digitaldaily.allthingsd.com/20090821/iphone-ownerswould-like-to-replace-battery-att.
[2] http://conversations.nokia.com/2009/08/12/what-is-the-mostimportant-feature-in-a-music-phone/
[3] Y. Lu and G. D. Micheli, “Comparing system-level power
mangagement policies”, IEEE Design & Test of Computers,
2001
[4] C. Hsu and U. Kremer, “The design, implementation, and
evaluation of a compiler algorithm for CPU energy
reduction”, PLDI, 2003
[5] K. Rajamani, H. Hanson, J. Rubio, S. Ghiasi, and F. Rawson.
“Application-aware power management”, IISWC, 2006.
[6] X. Liu, P. Shenoy and M. D. Corner, “Chameleon: Applitionlevel Power Management”, IEEE TMC, 2008.
[7] Y. Ye, N. Jain, L. Xia, S. Joshi, et al., “A framework for QoS
and power management in a service cloud environment with
mobile devices”, SOSE’10, 2010.
[8] W. Hao, I. Yen and B. M. Thuraisingham, “Dynamic service
and data migration in the clouds”, COMPSAC, July 2009.
[9] J. Cohen, “Statistical power analysis for the behavioral
sciences”, (2nd ed.), Lawrence Erlbaum Associates, Inc.,
Publishers, ISBN 0-8058-0283-5, 1988.
[10] S. Geisser,“ Predictive inference: an introduction”, Chapman
& Hall, Inc., ISBN 0-412-03471-9, 1993.
[11] M. C. Jaeger, G. Rojec-Goldmann, G. Muhl, “QoS
aggregation for web service composition using work flow
patterns”, EDOC 2004.
[12] PowerTop: http://www.lesswatts.org/projects/powertop/
[13] J. Fox, “Multiple and generalized nonparametric regression”,
Sage, Thousand Oaks CA, ISBN: 978-0-761-92189-9, 2000.
[14] W. Hao, T. Gao, I. Yen, Y. Chen, R. Paul, “An infrastructure
for Web services migration for real-time applications,” SOSE,
Oct. 2006, pp. 41-48.
9