Noname manuscript No.

(will be inserted by the editor)

Mobile Cloud Face Recognition Based on Smart
Cloud Ranking
Francisco Airton Silva Paulo Maciel
Gileno Filho Rubens Matos
Jamilson Dantas
Received: date / Accepted: date
Abstract Resource scarcity is a major obstacle for many mobile applica-
tions, since devices have limited energy power and processing potential. As
an example, there are applications that seamlessly augment human cognition
and typically require resources that far outstrip mobile hardwares capabili-
ties, such as language translation, speech recognition, and face recognition. A
new trend has been explored to tackle this problem, the use of cloud comput-
ing. This study presents SmartRank, a scheduling framework to perform load
partitioning and ooading for mobile applications using cloud computing to
increase performance in terms of response time. As a rst case study, we have
applied the approach to a face recognition process based on two strategies:
cloudlet federation and resource ranking through balanced metrics (level of
CPU utilization and round-trip time). We evaluate the approach in two steps.
First we tested the feasibility of cloudlet federation measuring its level of re-
sponse time improvement which resulted in a speedup of 48%. Second, using
a full factorial experimental design we tuned the SmartRank with the most
suitable partitioning decision calibrating the scheduling parameters. Finally,
SmartRank uses an equation that is extensible to include new parameters and
make it applicable to other scenarios.
Keywords Mobile Cloud Computing Ooading Partitioning Performance
Evaluation
F. A. Silva P. Maciel G. Filho R. Matos J. Dantas
Informatics Center, Federal University of Pernambuco
Road Jorn. Anbal Fernandes - Cidade Universit aria, Recife 50740-560, PE, Brazil
E-mail: faps@cin.ufpe.br
2 Francisco Airton Silva et al.
1 Introduction
Mobile cloud computing, which integrates cloud computing and mobile com-
puting, is a new paradigm for supporting mobile users. Mobile cloud computing
(MCC) can improve the performance of mobile applications by ooading data
processing from mobile devices to servers. MCC can also reduce the energy
consumption of mobile devices [11]. However, running applications in a mobile
cloud computing environment requires ecient resource management.
Many types of intensive mobile applications may benet from the pool of
manageable resources accessible in a cloud infrastructure. There are a num-
ber of examples related to automatic processing of digital images, including
biometric authentication, surveillance, human-computer interaction, and mul-
timedia management [10]. Face recognition, for instance has outside the mobile
computing context a few successful examples such as Smartgate in Australia
[18] and the border control system in China [21], however is a challenging task
to execute in mobile applications due to the high processing power required.
The resources of MCC may aid this process using optimized scheduling of
requests.
According to Dey et al. [3], an ecient scheduling algorithm in mobile cloud
must consider simultaneously both, communication and computation require-
ments. He also concludes with experiments that there is a tradeo between
satisfying response time for dierent user requests and maximizing system ca-
pacity. They tried to solve this problem by ranking the current capacity of
heterogeneous access networks (like macrocell, microcell, carrier WiFi, public
WiFi, etc.) and dierent clouds. In other words, for each network and cloud
it assigns a utilization percentage. The problem with this strategy is the low
level of resources granularity, not considering the machines as a resource unit,
which could lead to a more ecient scheduling.
Evolving this approach, Soyata et al. [19] have implemented a software
called MOCHA to improve mobile cloud face recognition simulating public
clouds and a cloudlet. A cloudlet is a resource-rich computer or cluster of
computers with fast Internet and available for use by nearby mobile devices
[17]. MOCHA has demonstrated that a cloudlet as a unique server enhances
face recognition. It redistributes the load to remote machines and ranking
them by their round-trip time (RTT). Although MOCHA has presented an
ecient behaviour, some improvements are still feasible.
In this paper, we extend the idea of the MOCHA project and present a
framework called SmartRank to increase performance of mobile applications
through load ooading. As a rst case study we adapt the face recognition
process developing a smart scheduling algorithm that ranks cloud servers and
distributes pictures of human faces among them. Our proposal combines three
main contributions, as follows:
1. Cloudlet federation: we maximize the cloudlet capability using a cloudlet
federation instead of a unique cloudlet. Thus, before sending requests to
public clouds we explore these resources that in our scenario are composed
Mobile Cloud Face Recognition Based on Smart Cloud Ranking 3
of private clouds. Such strategy prevents the high latency between mobile
device and public clouds.
2. CPU load metric inclusion: as aforementioned, communication and compu-
tation requirements must be considered in mobile cloud scheduling. How-
ever, regarding computation, the MOCHA strategy uses only a xed metric
representing the server capacity. In our proposal we have included the met-
ric CPU load to give a more realistic instant capacity.
3. Weighted metrics: since we consider heterogeneous environments we asso-
ciated weights to the ranking metrics (CPU utilization and RTT). Such
choice was supported by an experimental evaluation. It provided evidence
that the load metric has larger inuence on response time than the RTT
has, reinforcing its inclusion.
The remainder of this paper is structured as follows: in Section 2 we de-
scribe the face recognition process and the adopted private cloud framework.
Section 3 presents the related works we have found in a literature review. Sec-
tion 4 introduces the SmartRank strategy. Section 5 presents the evaluation of
our approach. We conclude this paper in Section 6 by discussing future works.
2 Background
This section introduces some concepts of face detection and recognition re-
quired for understanding the proposed work. This is followed by an intro-
duction to the Eucalyptus private cloud framework, used in the tests of the
SmartRank approach.
2.1 Face Detection and Recognition
There is an obvious and strong need for user-friendly systems that can secure
our assets and protect our privacy, without losing our identity in a sea of
numbers. At present, one needs a personal identication number to withdraw
money from an automated banking machine, a password for a computer, a
dozen others to access some Internet services, and so on. Although reliable
methods of biometric personal identication exist, such as ngerprint analysis
and iris scans, these methods rely on the cooperation of the participants,
whereas a personal identication system based on analysis of frontal or prole
images of the face is often eective without the participants cooperation or
knowledge [27].
A general statement of the problem of face recognition can be formulated
as follows: given images of a scene, identify or verify one or more persons in the
scene using a stored database of faces. The solution to the problem involves
segmentation of faces (face detection) from cluttered scenes and extraction of
features from the facial regions for recognition. In this work we consider face
detection and extraction in the same phase, since face extraction is responsible
4 Francisco Airton Silva et al.
for capturing the specic facial characteristics. We call the entire process,
including all three steps, the face recognition process [27].
The face detection determines the potential locations of the human faces
within an image (e.g.: Figure 1). In this work we have utilized the Haar Fea-
tures and Haar Classiers [25] to perform face detection. This decision was
motivated by their widespread adoption for a vast range of computer vision
applications [22].
Fig. 1 Face Detection: This picture was processed by Haar Features and Classiers tech-
nique.
The face recognition determines the match-likelihood of each face to a
template element from a database. The potential faces determined in the pre-
vious face detection phase are then recognized. We have employed the widely
accepted Eigenfaces approach [23]. This process extracts the relevant informa-
tion in a face image, encodes it, and compares the encoded face image with a
database of models, similarly encoded. A simple approach to extracting the in-
formation contained in an image of a face is to somehow capture the variation
in a collection of face images (called training images) and use this information
to encode and compare individual face images.
In mathematical terms, the objective of Eigenfaces approach is to nd the
principal components of the distribution of faces, i.e., the eigenvectors of the
covariance matrix of the set of face images. Let = (
1
,
2
, ...,
M
) be the
set of M face images used as a database of face models, where each
i
is a
vector of N pixel values constituting a single face image. The average face
=
1
M

M
i=1

i
is computed from this database. The dierence from each face
image to the average face is
i
=
i
. The covariance matrix of the face
images is computed as:
C =
1
M
M

i=1

T
i

i
= AA
T
, (1)
where A = [
1
,
2
, ...,
n
].
Mobile Cloud Face Recognition Based on Smart Cloud Ranking 5
The eigenvectors of the covariance matrix C can be thought of as a set
of features that together characterize the variation between face images. Each
image location contributes more or less to each eigenvector, so that we can
display the eigenvector as a sort of ghostly face that we call an eigenface.
Some eigenfaces were generated using the image depicted in Figure 1, and the
result is shown in Figure 2. It is important to highlight that these eigenfaces
are just examples, because in practice hundreds of faces are used to build a
training set. In the actual recognition phase, a new face undergoes a pattern
matching to the eigenfaces in the training images database.
Fig. 2 (a) Thirteen eigenfaces calculated considering the faces of Figure 1; (b) The average
face.
2.2 Eucalyptus Private Cloud
In our study, we consider that a cloudlet is a private cloud running a Eucalyp-
tus infrastructure, but other cloud frameworks could be used with little impact
to our approach. Eucalyptus is an open source software framework for cloud
computing that implements what is commonly referred to as infrastructure as
a service (IaaS), a system that gives users the ability to run and control entire
virtual machine (VM) instances deployed across a variety of physical resources.
It is composed of several components that interact with each another through
well-dened interfaces [14].
The main components of a Eucalyptus cloud include the cloud controller
(CLC), which is the user-visible entry point and global decision-making compo-
nent. The CLC is responsible for processing incoming user-initiated or admin-
istrative requests, making high-level VM instance-scheduling decisions. The
node controller (NC) is the component that manages the physical resources
which host VM instances and is responsible for startup, inspection, shutdown,
and clean-up of VMs. The cluster controller (CC) is responsible for gather-
ing state information from its collection of NCs and scheduling incoming VM
instance-execution requests to individual NCs. The Storage Controller (SC)
provides block-level storage service and the Walrus consists of a le-level stor-
age system that extends across the cloud.
6 Francisco Airton Silva et al.
3 Related Work
This section focuses on the related work that deals with face recognition using
mobile cloud computing or cloudlets. Starting with face recognition, Indrawan
et al. [7] implemented a real-time image processing application for face recog-
nition systems with a user interface on Android mobile devices. Unlike Smar-
tRank, their goal was the recognition algorithm accuracy and how to show
recognizable faces in a friendly way. Additionally, they did not mention the
use of cloudlets.
Srirama et al. [20] proposed CroudSTag, an Android application that aids
in forming social groups of common interest from mobile devices. The applica-
tion obtains a set of pictures from a storage cloud, uses face recognition cloud
services to identify people, and forms social groups on Facebook, a well-known
social network. The CloudSTag focuses on the mobile application and not on
the architectures of cloudlets to enhance performance.
The number of studies that have explored cloudlets is expressive, but to
the best of our knowledge, only the MOCHA project has studied them in
conjunction with face recognition functionality so far. In the following, we
reference some work related to cloudlets in general. Fesehaye et al. [4] studied
the impact of cloudlets in interactive mobile cloud applications. To study their
impact, they proposed the design of cloudlet network and service architectures
but focusing on video streaming.
Verbelen et al. [24] used a similar idea of cloudlet federation, but it works
like a peer-to-peer network instead of having a central controller. Their pro-
posal also considered cloudlets as heterogeneous structures, including static
and ad hoc organizations. The applications were distributed and partitioned
among cloudlets as components without replications. OSGi and modules called
cloudlet agents are used to manage the application components. The drawback
on the approach of [24] is that the components are xedly installed among the
cloudlets. In our proposal, all VMs run the recognition software, and a dy-
namic distribution of faces occurs based on the VMs ranking so that it is not
necessary to migrate software components.
Regarding the balanced metrics strategy, Shumao et. al [16] explore parti-
tioning for ooading of mobile applications assigning weights to each partition,
in which the unit is a java class. In our work the weights are applied under re-
source rates of VMs and not the application code. In addition the architecture
of [16] uses only one server to execute the remote task.
4 The SmartRank Strategy
Although mobile hardware continues to evolve and improve, it will always be
resource poor when compared to static hardware. Such fact occurs because
improving size, weight, and battery life are higher priorities than enhancing
computational power for the hardware that people carry or wear for extended
periods of time. This is not just a temporary limitation of current technology
Mobile Cloud Face Recognition Based on Smart Cloud Ranking 7
but is intrinsic to mobility. Another point is related to connectivity at long
distances by means of Wide Area Networks (WANs), which have delays in the
critical path of user interaction can hurt usability by degrading the system
response [17].
The problems exposed above are common for any mobile application that
somehow interacts with the Internet and undergo situations that call for a
high level of processing, such as face recognition programs. As a solution for
this problem, previous work such as MOCHA project tried to use a cloudlet
as a near resource and a scheduling mechanism (see Figure 3). We extend this
idea by maximizing the cloudlet capacity using an additional cloudlets federa-
tion. We call this approach as SmartRank framework, illustrated in Figure 4.
SmartRank performs load partitioning and ooading in an attempt to get a
response faster than other approaches. With this tool, users can take a picture
using their hand-held devices (smartphones, tablets, etc.) and request face
recognition from the cloudlet infrastructure nearby. In our work, the mobile
device is a thin client that sends a picture and receives the recognition result.
If no cloudlet is available nearby, the mobile device goes to a fallback mode
that involves a distant cloud, or in the worst case it could rely solely on its
own resources.
Cloudlet 3G
WiFi
Amazon
Web Services
Windows
Azure
Fig. 3 MOCHA: An Overview.
Cloudlets
Manager
Cloudlets Federation
1: VM_192.168.20.3 (cost: 0,1)
2: VM_192.168.20.2 (cost: 0,2)
3: VM_192.168.20.10 (cost: 0,3)
4: VM_192.168.20.1 (cost: 0,4)
Ranking
3G
WiFi
VM VM
RPC
VM VM
Amazon
Web Services
Windows
Azure
RPC
Fig. 4 SmartRank: an Overview.
8 Francisco Airton Silva et al.
SmartRank has a scheduler algorithm that take into account multiple met-
rics and assign weights to these metrics. The request from a mobile device is
received by a server that acts as load balancer, called cloudlets manager. As
the name implies, this machine knows all the federation resources. Thus, the
cloudlets are registered to be used when necessary and the cloudlet manager
ranks the VMs from all cloudlets based on two metrics:
CPU utilization (U): Measures the current machines CPU utilization
percentage at a specic period. In other words, if the VM has two or more
CPU cores then the CPU utilization will be the average use of these cores.
The higher the CPU utilization the lower the chances of allocating more
requests to that particular VM.
Round-Trip Time (RTT) [3]: Returns the sum of two sub-metrics:
the processing time on server-side and the transmission time measured for
only one face recognition. Similarly to the other metric, the higher the RTT
the less requests the VM receives.
Processing Time (PT): Represents the average time each VM type
(large and small) takes to perform the recognition process. To get this
measure we have run an experiment described in Section 5.3.1.
Transmission Time (TT): This value is obtained dynamically for
each execution and means the total time for a request to reach a VM and
come back to the requester (cloudlet manager) without any processing.
As aforementioned, to balance the metrics, each one is associated with a
weight, the metrics CPU utilization (U), and round-trip time (RTT) have cor-
responding weights (wU and wRTT) that sum up to the value 1. These weights
are used to balance the formula that calculates the cost (Ct) for a machine
executing the recognition. It considers the normalized metrics based on their
amplitudes. We used the widely adopted min-max normalization method in
which an attribute is normalized by scaling its values so that they fall within
a small specied range, in our case 0.0 to 1.0 [2]. Min-max normalization per-
forms a linear transformation of the original data. Suppose that min
A
and
max
A
are the minimum and maximum values of an attribute A. Min-max
normalization maps a value v to v

in the new range [min

A
, max

A
]. The gen-
eral corresponding formula for normalization is depicted in Equation (2) and
the cost formula in Equation (3).
v

=
v min
A
max
A
min
A
(2)
Ct = ((wU NormU) + (wRTT NormRTT)) (3)
The Figure 5 illustrates how the three macro components (mobile device,
cloudlet manager and federation of cloudlets) interact with each other. As
aforementioned, the face recognition process is divided into two phases, detec-
tion and proper recognition. In such gure we highlight the steps by sequential
numbers in order to make it easier to understand: 1) rst the user takes a
Mobile Cloud Face Recognition Based on Smart Cloud Ranking 9
picture of a group of people and sends it to the cloudlet manager; 2) a sub-
module called distributor receives and forwards this picture to the detecting
module, where the human faces are detected and cropped to be recognized
subsequently; 3) next, the distributor instantiates a set of threads according
to the number of available VMs and calculates the cost for sending the faces
for each VM; 4) then, based on the calculated costs, the faces are distributed
among the VMs for recognition; 5) when the recognition process has nished
the result is returned to the mobile device.
The Equation 4 shows the formula to calculate how many faces each VM
will receive. Let the VM costs be Ct
vm1
, Ct
vm2
, Ct
vm3
, Ct
vm4
, ..., Ct
vmk
. The
number of faces that a VM will process (NF
vm
) is obtained by the product of
its cost percentage and the total number of faces to recognize (TNF). We use
1 Ct
vm
because the lower the cost, the more faces that particular VM will
process. Therefore, the faces are proportionally distributed among the VMs
considering the NF
vm
parameter. In other words, the machine with high cost
will recognize less faces and that ones with low cost will process more faces.
Table 1 illustrates an example with arbitrary values using 4 VMs and 14 faces.
It is important to stress that the weights at the bottom of the table were just
an example and Section 5.3 shows what is the most eective balance for such
weights.
Cloudlets-Manager
Federation of
Cloudlets
VM
VM
VM
VM
Thread 01
Distributor
2 faces
2 faces
5 faces
5 faces
recog. result 01
recog. result 02
recog. result 03
recog. result 04
original image
recog. result
Detecting
Module
Thread 02
Thread 03
Thread 04
1
2
3 4
5
Fig. 5 SmartRank: Recognition Steps.
NF
vm
=
1 Ct
vm

K
N=1
1 Ct
vmN
TNF (4)
SmartRank is implemented on top of OpenCV[15]. It is an open source
computer vision library with a strong focus on real-time applications. In our
scenario, the OpenCV must be installed inside each VM and the databases
images must be replicated among them. As our focus is not improving the
proper face recognition algorithm, we have adopted the wrapper JavaCV[8] to
access the OpenCV, due to its expressive number of adapters.
10 Francisco Airton Silva et al.
Table 1 Example of costs calculation using 4 VMs and 14 faces.
Vm Code U PT TT RTT Cost NF
vm
m1.m a 69 21574,4 2345 23919,4 0,915 1
m1.m b 12 21574,4 444 22018,4 0,330 4
m1.l a 80 18551,0 182 18733 0,600 3
m1.l b 2 18551,0 700 19251 0,040 6
Metric Wgt. CostSum: 2,11
U 0,6 TNF: 14
RTT 0,4
The communication between mobile devices and the cloudlet-manager is
implemented using sockets. We have chosen synchronous strategy because we
judge real-time communication as more important than any other require-
ments. For the same reason, the messages are exchanged between cloudlet-
manager and cloudlets with a synchronous remote procedure call (RPC) chan-
nel. There are many attractive aspects of RPC. One is clean and simple se-
mantics: these should make it easier to build distributed computations, and
to get them right. Another is eciency: procedure calls are simple enough
for the communication to be quite fast. A third is generality: in single ma-
chine computations, procedures are often the most important mechanism for
communication between parts of the algorithm [1].
5 Evaluation
This section is divided into three parts. The rst (Section 5.1) addresses the
experimental setup used to evaluate the SmartRank capabilities. The second
(Section 5.2) tries to answer the question How much does the use of cloudlet
federation improves the speed of face recognition performance?. The last part
(Section 5.3), seeks to answer the question Which is the metrics calibration
that results in the lowest recognition process time?.
5.1 Experimental Setup
The environment was assembled with one cloudlet comprising three machines
with the same hardware conguration: Intel Core i7-3770 3.4 GHz CPU, 4
GB of RAM DDR3, 500 GB SATA HD. One machine is congured as the
front-end, running the CLC, CC, SC, and Walrus. The remaining two run the
node controllers (NC). They execute the Linux CentOS 6 operating system
and Eucalyptus platform 3.4.0.1. We use a 10/100 Mbps Ethernet network to
connect the PCs through a single switch.
Two VM types were adopted: m1.medium (1 CPU, 512MB Mem., and
10GB Disk) and m1.large (2 CPUs, 512MB Mem., and 10GB Disk). As de-
picted in Figure 5, we simulate two cloudlets with four VMs (2 m1.medium
Mobile Cloud Face Recognition Based on Smart Cloud Ranking 11
and 2 m1.large). To narrow the scope, the mobile device is only responsible for
sending raw images to the cloudlet-manager and this process is not repeated
during the experiments. Constant mobile transfer time is added in every ex-
periment.
5.2 Cloudlet Federation Feasibility Evaluation
In this work, the use of a pool of resources as a cloudlet intends to provide more
ecient image-recognition services to mobile clients. There are some previous
studies that proved the eciency of cloudlets [6], [19], [17]. In special, Soyata
et. al [19] claimed that using a unique server as a cloudlet may get a speed up
of 8%, comparing with no cloudlet use. Focusing on the cloudlet performance
improvement we intended to observe the speed up obtained when maximizing
the number of resources in the cloudlet. Thus, we compared the performance
of recognition process considering the cloudlet as a single cloudlet (one VM)
or a cloudlet federation (multiple VMs). In this case, the cloudlet federation
is composed of two cloudlets with the four VMs.
We have repeated 30 image recognition processes considering a picture
with 24 faces and collecting its corresponding response times. As scheduling
strategy we used the simple round-robin method [9] because our focus was
not evaluate the scheduling algorithm but the cloudlet federation gains. We
rst used the single cloudlet comprising one VM of type m1.large and then the
cloudlet federation composed of four VMs (2 m1.medium and 2 m1.large). The
respective mean response times were 1458 ms for single cloudlet and 983 ms for
cloudlet federation. As we want to know whether the maximization of cloudlet
capability brings performance improvements we applied the t-test to ensure
that these mean response times are statistically dierent. Through a successful
Anderson Darling test, we assume the normality of both samples considering
95% of condence. The p-value for single cloudlet was equal to 0.506 and 0.06
in the other (>0.05). The t-test showed that there is a signicant dierence
in the samples: single cloudlet (M=1458.3, SD=59.4) and cloudlet federation
(M=983.9, SD=84.8); T(51)=25.1, p=0.000. This result give evidences that if
performance is a priority (excluding nancial requirement for example) the use
of cloudlet federation is preferable than single cloudlets for face recognition,
since in our experiment we got a speedup of 48%. Figure 6 depicts a box-plot
illustrating the samples distance.
5.3 The SmartRank Exploratory Evaluation
Flores [5] claims that the ooading is not a local decision process that happens
just within the device, it involves a global understanding of the infrastructure.
According to Tianyi et. al [26], scheduling schemes for mobile cloud must
consider multiple parameters such as computation and connectivity resources
since the cloud environments are heterogeneous. We presented that the use of
12 Francisco Airton Silva et al.







4 VMs 1 VM
1600
1500
1400
1300
1200
1100
1000
900
800
R
T
T

(
m
s
)
Boxplot of 1 VM; 4 VMs
Fig. 6 Box-Plot graph to illustrate the distance between the samples.
cloudlet federation decreased the mean response time around 48% considering
the round-robin scheduling strategy. However, such strategy do not take into
account the dierent VMs capabilities and latencies.
This way, as aforementioned, SmartRank performs face detection and recog-
nition through distribution of tasks among servers based on RTT and CPU
utilization to make better use of heterogeneous infrastructures. Thus, we as-
sign weights to these metrics because we suppose that depending on the sce-
nario one metric can inuence more the response time than the other. This
aspect motivates in this context the following question: There is a calibration
of weights that results in the lowest mean response time, executing in dier-
ent scenarios in which the VMs have distinct initial CPU utilization levels?
This section will present an exploratory evaluation that aims to answer such
a question.
5.3.1 Virtual Machines Capacity Estimation
Before the calibration process we had to estimate the metric processing time
(PT), referring to the time for a VM perform recognition without considering
transmission time, as explained in Section 4. RTT is composed of transmission
time (TT) that is dynamically obtained and the processing time (PT) that is
an estimation resulted from an experiment described in this section. Hence,
in the case of TT metric, for each scheduling execution a simple request is
spread for all VMs and then their response times are recorded. In the case of
PT metric we shall not do the same because it could signicantly decrease the
scheduling performance, so such metric is obtained as a mean value through
experiment.
We registered the PT mean for one VM instance of type m1.medium and
other of type m1.large. They received a specic workload 80 times composed
of one picture with 17 faces. The VM of type m1.large obtained a lower PT
mean (18551 ms) than the m1.medium (21575 ms). This result was expected
due to its dierent computational power (m1.medium has 1 CPU core and
m1.large has 2 CPU cores).
Mobile Cloud Face Recognition Based on Smart Cloud Ranking 13
To use these PT mean values only make sense if the two samples are sta-
tistically dierent, otherwise the type of VM would not inuence the desired
response time. So, aiming to ensure that these means could be used as a
relevant metric for ranking, we again applied the t-test to verify whether
these means were statistically dierent. Considering 95% of condence, we
assume the normality of both samples (p-values equal to 0.735 and 0.300).
The t-test showed that there is a signicant dierence between them: VM
type m1.medium (M=21575, SD=32.26) and VM type m1.large (M=18551,
SD=27.10); T(153)=642.02, p=0.000. Figure 7 depicts a box-plot illustrating
the samples distance.



m1.large m1.medium
22000
21500
21000
20500
20000
19500
19000
18500
P
T

(
m
s
)
Boxplot of m1.medium; m1.large
Fig. 7 Box-Plot graph to illustrate the distance between the samples.
5.3.2 SmartRank Calibration
Aiming to nd the calibration of weights that results in the lowest mean re-
sponse time we arranged dierent scenarios where the initial CPU utilization
of four VMs (2 m1.large and 2 m1.small) are dierent. We performed experi-
ments using the real RTT as a dependent variable. It is important to stress
that we refer two types of RTTs. The rst is that used by the scheduling al-
gorithm, including the pre-calculated PT values and instant TT. The second
is the real RTT, recorded in our experiments. Table 2 shows the factors and
their respective levels. We have chosen the weight balance as a factor because
we want to nd the weight balance that results in the lowest RTT. The second
factor is the initial CPU utilization level because depending the level of this
metric a VM should not receive more requests.
In the case of weight balance factor we have chosen three calibrations,
considering RTT (acronym R) and CPU utilization (acronym U). First,
giving more importance for U (with 20% for R and 80% for U). Second, giving
more importance for R (with 80% for R and 20% for U). Third, considering
them equally important (with 50% for R and 50% for U). We have tried others
values, however the above 80 and below 20 the dierence was inexpressive.
14 Francisco Airton Silva et al.
Table 2 Factors and the parameters chosen as relevant.
Factors Wgt. Balance (%) Initial CPU Utl. (%)
Levels
20R80U m.a:10,m.b:20,l.a:30,l.b:40
80R20U m.a:40,m.b:30,l.a:20,l.b:10
50R50U m.a:10,m.b:10,l.a:20,l.b:20
We have simulated the initial CPU Utl. level using the LookBusy
1
tool that
generate xed and pre-congured loads on CPUs. The acronym m.a means
m1.medium.a, m.b means m1.medium.b, l.a means m1.
large.a and l.b means m1.large.b. The letters a and b are used only to
identify the two VMs of each distinct type. We congured three scenarios
setting arbitrary CPU utilization levels for the four VMs varying the load
from 10 to 40 percent. The acronyms presented in Table 2 will be used it the
remainder of the paper.
As the experiments were executed on the same network, we did not con-
sider transmission time as a factor, setting a xed value equals to 3, a value
previously observed in the previous executions. To capture the real RTTs, we
just instrumented the source code before and after the process in the cloudlet-
manager, registering the dierence in milliseconds in a text log. For each se-
quence of execution, the VMs were cleaned (processes stopped) and the text
logs were also recreated.
We have adopted the statistical method factorial Design of Experiments
(DOE) [12], as we have two factors to obtain the desired measures, and our
intent is to study the impact of each factor on those measures to nally extract
the best weights balance. Considering the two factors (weight balance and
initial CPU utilization), and three levels for each one of them, there are nine
experiments to run, which are described in Table 3, presenting the real RTT
mean and respective standard deviations (SD). In order to get results in an
acceptable condence level, we decided to use a photo with 15 faces and run
35 replicas for each executions, yielding a total of 315 experiments. When
observing the real RTT results, it shall be noticed that the total times are
very similar, requiring a closer analysis to identify well-dened behaviours.
The eect and relevance of each factor and their interactions were com-
puted by using the results of the real RTT time, shown in Table 3 applying
the method factorial Design of Experiments (DOE). Table 4 introduces the
respective estimated eects.
The results in Table 4 showed that the factor with the greatest impact is
weight balance (weight balance), generating an eect with a relevance of 61%
(p=0.000, as it is lower than 0.05, it is signicant). It means that a variation
in such a balancing may increase or decrease the resulting response time over
the face recognition. The initial CPU utilization (initial U) also inuences the
real RTT, but only by 36% (p=0.013). The interaction between both factors
1
hPT://www.devin.com/lookbusy/
Mobile Cloud Face Recognition Based on Smart Cloud Ranking 15
Table 3 Results of each treatment of the experiment.
Initial CPU utilization Wgt. B. RTT M. SD
m.a:10,m.b:10,l.a:20,l.b:20 20R80U 988.14 31.22
m.a:10,m.b:10,l.a:20,l.b:20 80R20U 1045.06 43.73
m.a:10,m.b:10,l.a:20,l.b:20 50R50U 1022.86 153.56
m.a:10,m.b:20,l.a:30,l.b:40 20R80U 1078.69 98.68
m.a:10,m.b:20,l.a:30,l.b:40 80R20U 1194.71 233.05
m.a:10,m.b:20,l.a:30,l.b:40 50R50U 1163.63 174.48
m.a:40,m.b:30,l.a:20,l.b:10 20R80U 1018.06 51.27
m.a:40,m.b:30,l.a:20,l.b:10 80R20U 1162.94 270.51
m.a:40,m.b:30,l.a:20,l.b:10 50R50U 1111.00 140.47
Table 4 Estimated eects and relevances for the RTT mean time.
Factor Eect T Relev. P
weight balance 110.93 4.24 61% 0.000
initial U -65.73 -2.51 36% 0.013
weight balance*initial U -5.1 -0.19 2% 0.846
resulted in a p-value=0.846, indicating absence of mutual inuence. Thus, we
analyse the eect of factors on an individual level.
The Pareto chart (see Figure 8) depicts the importance of an eect by its
absolute value, drawing a reference vertical line on the chart. The more the ef-
fect extends this line the more it inuences the dependent variable (that is the
RTT in our study). The line indicates the minimum magnitude of statistically
signicant eects, using the criterion of statistical signicance = 0.05. Figure
8 presents a Pareto Chart in which can be observed the signicant inuence
of weight factor (weight balance) compared with the initial CPU utilization
of VMs before sending faces for recognition (initial U). The graph also shows
the little interaction between the factors (term AB), without statistical signif-
icance.
The eect of one factor may depend on the level of the another factor,
resulting in the so called factors interaction. This phenomenon may be evi-
denced when plotting each level of a factor and keeping the level of a second
factor constant. Thus, it compares the relative strength of the eects across
factors observing the existence of a pattern, if noted, this pattern means that
there is not interaction. For such intent we use a bar plot (Figure 9) looking
for a pattern on the factor initial CPU utilization (initial U) whereas keeping
the weight balance (weight balance) constant. By the gure we can reinforce
that there is not interaction between the factors, since for each weight balance
level the RTT increases proportionally to the initial CPU utilization.
Since the interaction between the factors is not signicant we can treat the
factors individually. Figure 10 presents the average result for each one of the
factors and then we can make some conclusions about the factor levels (from
left to right side). First, as observed in the last plot shown in Figure 9, the
16 Francisco Airton Silva et al.



AB
B
A
4 3 2 1 0
T
e
r
m

(
F
a
c
t
o
r
)
Standardized Effect
1.978
A weight_balance
B initial_U
Factor Name
Pareto Chart of the Standardized Effects
(response is RTT, Alpha = 0.05)
Fig. 8 Pareto Chart representing the eects of each factor. The red line represents the
minimum magnitude of statistically signicant eects.
R
T
T

(
m
s
)

U1: m.a:10,m.b:10,l.a:20,l.b:20
U2: m.a:40,m.b:30,l.a:20,l.b:10
U3: m.a:10,m.b:20,l.a:30,l.b:40
Legend:
weight_balance

initial_U

20R80U
50R50U
80R20U

0.00
200.00
400.00
600.00
800.00
1000.00
1200.00
U1 U2 U3
Chart Title
Fig. 9 Bar plot with the level of relationship between the factors.
dierent weight balances present distinct results. The best performance was
when using the balance of 20% for RTT and 80% for CPU utilization metric, it
obtained a 5.5% faster result comparing to the average of the three real RTTs.
It can be explained by the invariance of the RTT, as the PT is a xed number
and the transmission time is equal for all VMs in our experiments. In the right
side of the graph, the factor initial CPU utilization (initial U) resulted in a
higher real RTT mean when the values were in a high level, that is, when
the VM owned an expressive initial workload. Thus, when the VMs were with
this level of CPU utilization m.a:10,m.b:20,l.a:30,l.b:40, the performance
was the worst because the instance types m1.large were running more busy,
with 30% and 40% of the CPU utilization.
Mobile Cloud Face Recognition Based on Smart Cloud Ranking 17
R
T
T

(
m
s
)

weight_balance
W1: 20R80U
W2: 50R50U
W3: 80R20U
U1: m.a:10,m.b:10,l.a:20,l.b:20
U2: m.a:40,m.b:30,l.a:20,l.b:10
U3: m.a:10,m.b:20,l.a:30,l.b:40
950.00
1000.00
1050.00
1100.00
1150.00
1200.00
W1 W2 W3 U1 U2 U3
Chart Title
initial_U
Fig. 10 Bar plot showing the relative eects of each level.
Thus, we conclude that the weight balance 20R80U will result in the
best face recognition performance under some assumptions: assuming that all
cloudlets are near from each other (similar transmission time); the pool of
resources is divided into two groups of VM types (medium and large); and the
VMs CPU utilization do not exceed 40%. This scenario is plausible because
our proposal aims to have a federation on cloudlets near the client and close
to each other. The RTT can be decreased if more resources are included.
SmartRank can redirect the requests every time the cloudlets federation is
overloaded, however this is not covered in this paper.
6 Conclusion and Future Work
We have presented SmartRank, a framework for partitioning and ooading
tasks of mobile applications. SmartRank intends to minimize the response
time of mobile applications by using cloud computing with heterogeneous com-
munication latencies and compute power in terms of CPU and memory. We
evaluated our approach using the context of face detection and recognition al-
gorithms. To the best of our knowledge, this is the rst work to show such an
strategy comprising private cloud resources and distribution of faces. We de-
signed SmartRank to integrate mobile devices (e.g: smartphones), the cloudlet
manager, and multiple cloudlets. This work focused on describing the strategy
and a sensitivity analysis of SmartRank to nd suitable parameters that would
result in good results considering response time. The experiments evidenced
that: the use of cloudlets federation is feasible for face recognition, since max-
imization of cloudlet capabilities improved the response time of recognition
process by 48%, that is, instead of one resource, multiple machines can solve
faster a recognition task; and it was possible to nd a calibration for the met-
rics CPU utilization and RTT based on weights, a functionality not applied so
far in our known literature. SmartRank distributes human faces for detection
and recognition, and as future work we intend to distribute general jobs and
18 Francisco Airton Silva et al.
to apply SmartRank for other types of intensive mobile systems such as mo-
bile games [3] and m-health [13]. We also plan to extend our experiments by
analyzing energy consumption, and also considering heavier workloads (i.e.,
more faces) and dierent mobile devices.
References
1. A. D. Birrell and B. J. Nelson. Implementing remote procedure calls. ACM Trans.
Comput. Syst., 2(1):3959, Feb. 1984.
2. S. Chakrabarti, E. Cox, E. Frank, R. H. Gting, J. Han, X. Jiang, S. S. Kamber, T. P.
Nadeau, R. E. Neapolitan, D. Pyle, M. Refaat, M. Schneider, T. J. Teorey, and I. H.
Witten. Data Mining: Know It All. Morgan Kaufmann Publishers Inc., 2008.
3. S. Dey, Y. Liu, S. Wang, and Y. Lu. Addressing response time of cloud-based mobile
applications. In Proc. of the First Int. Workshop on Mobile Cloud Computing &
Networking, MobileCloud, pages 310, New York, USA, 2013. ACM.
4. D. Fesehaye, Y. Gao, K. Nahrstedt, and G. Wang. Impact of cloudlets on interactive
mobile cloud applications. In Enterprise Distributed Object Computing Conference
(EDOC), 2012 IEEE 16th Int., pages 123132, 2012.
5. H. Flores and S. Srirama. Mobile code ooading: Should it be a local decision or
global inference? In Proceeding of the 11th Annual Int. Conference on Mobile Systems,
Applications, and Services, MobiSys 13, pages 539540, New York, NY, USA, 2013.
ACM.
6. X. Gu, K. Nahrstedt, A. Messer, I. Greenberg, and D. Milojicic. Adaptive ooading
for pervasive computing. Pervasive Computing, IEEE, 3(3):6673, July 2004.
7. P. Indrawan, S. Budiyatno, N. M. Ridho, and R. F. Sari. Face recognition for social
media with mobile cloud computing. Int. Journal, 2013.
8. JavaCV. Java interface to opencv and more, 2014. Available on https://code.google.
com/p/javacv/.
9. T. Knauth and C. Fetzer. Energy-aware Scheduling for Infrastructure Clouds. In Cloud
Computing Technology and Science (CloudCom), 2012 IEEE 4th Int. Conference on,
pages 58 65. IEEE Computer Society, dec. 2012.
10. P. Kocjan and K. Saeed. Face recognition in unconstrained environment. In K. Saeed
and T. Nagashima, editors, Biometrics and Kansei Engineering, pages 2142. Springer
New York, 2012.
11. K. Kumar and Y.-H. Lu. Cloud computing for mobile users: Can ooading computation
save energy? Computer, 43(4):5156, April 2010.
12. D. C. Montgomery and D. C. Montgomery. Design and analysis of experiments, vol-
ume 7. Wiley New York, 1984.
13. M. Nkosi and F. Mekuria. Cloud computing for enhanced mobile health applications.
In Cloud Computing Technology and Science (CloudCom), 2010 IEEE Second Int.
Conference on, pages 629633, Nov 2010.
14. D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman, L. Youse, and
D. Zagorodnov. The eucalyptus open-source cloud-computing system. In Cluster Com-
puting and the Grid, 2009. CCGRID 09. 9th IEEE/ACM Int. Symposium on, pages
124131, 2009.
15. OpenCV. Open source computer vision library, 2014. Available on http://opencv.org/.
16. S. Ou, K. Yang, and J. Zhang. An eective ooading middleware for pervasive services
on mobile devices. Pervasive and Mobile Computing, 3(4):362 385, 2007. Middleware
for Pervasive Computing.
17. M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies. The case for vm-based cloudlets
in mobile computing. Pervasive Computing, IEEE, 8(4):1423, 2009.
18. Smartgate. http://www.customs.gov.au/smartgate/default.asp, 2014. Acessed:
02/12/2014.
19. T. Soyata, R. Muraleedharan, C. Funai, M. Kwon, and W. Heinzelman. Cloud-vision:
Real-time face recognition using a mobile-cloudlet-cloud acceleration architecture. In
Computers and Communications (ISCC), 2012 IEEE Symposium on, pages 000059
000066, 2012.
Mobile Cloud Face Recognition Based on Smart Cloud Ranking 19
20. S. N. Srirama, C. Paniagua, and H. Flores. Croudstag: Social group formation with
facial recognition and mobile cloud services. Procedia Computer Science, 5(0):633
640, 2011. The 2nd Int. Conference on Ambient Systems, Networks and Technologies
(ANT-2011) / The 8th Int. Conference on Mobile Web Information Systems (MobiWIS
2011).
21. Chinese/hong kong border automated with biometrics. Biometric Technology Today,
15(5):3 , 2007.
22. H. Tang, Y. Sun, B. Yin, and Y. Ge. Face recognition based on haar lbp histogram.
In Advanced Computer Theory and Engineering (ICACTE), 2010 3rd Int. Conference
on, volume 6, pages V6235V6238, 2010.
23. M. Turk and A. Pentland. Face recognition using eigenfaces. In Computer Vision
and Pattern Recognition Proc. CVPR, IEEE Computer Society Conference on, pages
586591, 1991.
24. T. Verbelen, P. Simoens, F. De Turck, and B. Dhoedt. Cloudlets: Bringing the cloud to
the mobile user. In Proc. of the third ACM workshop on Mobile cloud computing and
services, pages 2936. ACM, 2012.
25. P. Viola and M. J. Jones. Robust real-time face detection. Int. J. Comput. Vision,
57(2):137154, May 2004.
26. T. Xing, H. Liang, D. Huang, and L. Cai. Geographic-based service request scheduling
model for mobile cloud computing. In Trust, Security and Privacy in Computing and
Communications (TrustCom), 2012 IEEE 11th Int. Conference on, pages 14461453,
June 2012.
27. W. Zhao, R. Chellappa, P. J. Phillips, and A. Rosenfeld. Face recognition: A literature
survey. ACM Comput. Surv., 35(4):399458, Dec. 2003.