Ao

GI

a

ARRAA

KMCGD

1

ihtmptatndld

mtAt

h1

Applied Soft Computing 25 (2014) 253–265

Contents lists available at ScienceDirect

Applied Soft Computing

j ourna l h o mepage: www.elsev ier .com/ locate /asoc

utomatic offloading of mobile applications into the cloud by meansf genetic programming

. Folino ∗, F.S. PisaniCAR-CNR Istituto di Calcolo e Reti ad Alte Prestazioni, Via P. Bucci, 87036 Rende (CS), Italy

r t i c l e i n f o

rticle history:eceived 12 July 2013eceived in revised form 10 July 2014ccepted 1 September 2014vailable online 2 October 2014

eywords:obile computing

loud computingenetic programming

a b s t r a c t

The limited battery life of modern mobile devices is one of the key problems limiting their use. Even if theoffloading of computation onto cloud computing platforms can considerably extend battery duration, itis really hard not only to evaluate the cases where offloading guarantees real advantages on the basis ofthe requirements of the application in terms of data transfer, computing power needed, etc., but also toevaluate whether user requirements (i.e. the costs of using the cloud services, a determined QoS required,etc.) are satisfied. To this aim, this paper presents a framework for generating models to make automaticdecisions on the offloading of mobile applications using a genetic programming (GP) approach. The GPsystem is designed using a taxonomy of the properties useful to the offloading process concerning theuser, the network, the data and the application. The fitness function adopted permits different weights to

ata mining be given to the four categories considered during the process of building the model. Experimental results,conducted on datasets representing different categories of mobile applications, permit the analysis of thebehavior of our algorithm in different applicative contexts. Finally, a comparison with the state of theart of the classification algorithm establishes the goodness of the approach in modeling the offloadingprocess.

© 2014 Elsevier B.V. All rights reserved.

. Introduction

Modern smartphones boosted their capabilities due to thencreasing coverage of mobile broadband networks, to the newigh-performance processors, to the large-volume storage ando new different types of sensors. All these capabilities together

ake it possible for mobile devices to handle much more com-lex tasks and to execute modern mobile applications; howeverhat consumes a lot more computing and networking resourcesnd therefore demands much more energy, while the batteryechnology has not developed as fast as mobile computing tech-ology and has not been able to satisfy the increasing energyemand. In addition, in the last few years, the introduction of

arger screens further reduces the battery life of the mobileevices.

Therefore, owing to these problems and to the proliferations ofobile devices (i.e. tablets and smartphones), the interest in trying

o improve the limited life of their batteries is greatly increased. possible solution to alleviate this problem is to offload part of

he application or the whole computation to remote servers, as

∗ Corresponding author. Tel.: +39 0984831731.E-mail addresses: folino@icar.cnr.it (G. Folino), fspisani@icar.cnr.it (F.S. Pisani).

ttp://dx.doi.org/10.1016/j.asoc.2014.09.016568-4946/© 2014 Elsevier B.V. All rights reserved.

explained in [11], where software-based techniques for reducingprogram power consumption are analyzed, considering both staticand dynamic information in order to move the computation toremote servers.

In the last few years, the emergence of cloud computing tech-nology and the consequent wide availability of cloud servers [3],has encouraged research into the use of offloading techniques oncloud computing platforms. A number of papers were publishedtrying to cope with the main issues of the process of offloading,mainly oriented toward a particular problem area, i.e. wifi issues[14], network behavior [18] and network bandwidth [22], the trade-off between privacy and quality [15] and the effect of the context[1].

However, to the best of our knowledge, the works concern-ing this theme do not consider a model taking into account boththe hardware/software issues and the user requirements, neitheris there reference to an automatic and adaptive model to takethe decision of performing the offloading. Indeed, the offload-ing technique potentially could improve both performance andenergy consumption; however, it is an NP-hard problem to estab-

lish whether it is convenient to perform the migration, especiallyconsidering all the correlated problems such as network discon-nections and variability, privacy and security of the data, variationsof load in the server, etc.

2 Soft Co

oatafwmeoaolaodedpTpfit

f

•

•

•

•

•

etSid

2

wvffcfim

otowatt

54 G. Folino, F.S. Pisani / Applied

This paper presents a framework for modeling the automaticffloading of mobile applications using a genetic programmingpproach, which attempts to address the issues listed above; fur-hermore, it can be used to simulate different kinds of mobilepplications and to generate rules for the offloading process inorm of decision trees that can be analyzed by the user. The frame-ork, originally introduced in [6], is made up of two parts: aodule that simulates the entire offloading process, and an infer-

nce engine that builds an automatic decision model to handle theffloading process. The simulator and the inference engine bothpply a taxonomy that defines four main categories concerning theffloading process: user, network, data and application. The simu-ator evaluates the performance of the offloading process of mobilepplications on the basis of user requirements, of the conditionsf the network, of the hardware/software features of the mobileevice and of the characteristics of the application. The inferencengine is used to generate decision tree-based models that takeecisions concerning the offloading process on the basis of thearameters contained in the categories defined by the taxonomy.his is based on a GP-based tool that generates the models using thearameters defined by the taxonomy and driven by a function oftness, giving different weights to the costs, time, energy accordingo the priorities assigned.

The main contribution of the framework can be summarized asollows:

The proposal of a taxonomy of the main properties of a mobileapplication useful for the task of offloading, divided into fourcategories: user, network, data and application.The design of an automatic framework that drives the process ofoffloading, by building and validating models for that process.A GP-based tool for building the decision tree-based model, whichwill decide whether it is convenient to perform the offloading ofa mobile application, is adopted.The system permits the analysis of the behavior of our algorithmfor different categories of mobile applications, presenting differ-ent distributions of the main properties.A simulation tool integrating both the cloud and the mobile part.

The rest of the paper is structured as follow: Section 2 surveysxisting works; Section 3 describes the software architecture ofhe system and the different modules composing the framework;ection 4 presents the results of the method using different exper-mental setups; Section 5, finally, concludes this paper by giving aiscussion of the approach and some final considerations.

. Background and related works

All the issues involved in the offloading decision, such as net-ork disconnections and variability, data privacy and security,

ariations in load of the server, etc. need to be evaluated care-ully and that makes it difficult to design an automatic systemor this purpose. In fact, analyzing the works in the literatureoncerning the offloading of mobile applications, the problem ofnding an automatic methodology to perform offloading is notuch explored.A paper introducing general arguments on the process of

ffloading was written by Kumar and Lee [13]. The authors analyzehe main problems derived from offloading mobile applicationsnto the cloud such as privacy, costs, energy consumption and show

hich applications can benefit from this approach. They introduce

simple model for deciding whether it is convenient to performhe offloading and they try to apply the technique only to compu-ationally expensive functions while computing other tasks locally.

mputing 25 (2014) 253–265

Other papers are devoted to the utility of performing offloading,basing their considerations on some criteria, i.e. energy consump-tion, costs, network use, etc. For instance, in [16] the decision toperform the offloading is based on the difference between theenergy used when the task was executed locally on the mobiledevice or remotely on the cloud servers. The power consumption ofthe local execution is estimated by counting the CPU cycles while,as for the remote execution, it is calculated only considering thenetwork use (data transfer). Our model is more sophisticated, asit considers also the hardware components that are used duringcomputation and the issues concerning the transfer of the data (i.e.CPU, wifi, 3g, display, system, etc.).

In [11] a two-step method is used. First, a database of appli-cation power use is built through standard profiling techniques.Then, the authors exploit the property stated in the paper that, fora limited class of applications (i.e. applications in which the costdepends only on the scale of the input), the algorithmic complexitycombined with the profiling can be used to predict the energy costof the execution of the application itself. Unfortunately, real-worldapplications can be hardly modeled considering only their input.

Many papers are devoted to techniques and strategies to allevi-ate the process of offloading analyzing the code of the applicationor optimizing some energy-consuming processes, i.e. the acquisi-tion of the GPS signal. For instance, Saarinen et al. [20] analyze theapplication source code and identify methods presenting hardwareand/or software constraints, which do not permit the offloading.In addition, they also consider traffic patterns and power savingmodes. However, the work does not consider network conditionsand user requirements. Note that these approaches are orthogonalto our work and can be adopted in order to optimize some phasesof the offloading process.

Spectra [5] is a remote execution system that monitors applica-tion resource use and the availability of the resources on the deviceand dynamically chooses how and where to execute applicationtasks. The framework provides APIs to developers to build applica-tion suitable to the defined architecture. X-ray [19] is an automaticsystem, which profiles an application and decides what offloadingcomputation is useful and when. The X-ray profiling stage observesapplication and system events (Gui, sensor, GPS, memory, CPU)and identifies “remotable” methods. If a method does not use localresources then it is remotable. Differently from these two systems,our framework is not method-based, but considers the entire appli-cation and the decision to perform the offloading is based not onlyon the application characteristics (size of data, privacy concern)but also on the system status (battery, 3g or wifi connection) andon some constraints requested by the user.

Gu et al. [10] extend an offloading system with an offloadinginference engine (OLIE), mainly used to overcome the memory limi-tations of a mobile device. OLIE solves two problems: first, it decideswhen to trigger the offloading action; second, it selects a parti-tioning policy that decides which objects should be offloaded andwhich pulled back during an offloading action. The decision of per-forming the offload is based on the available memory and on thenetwork conditions (i.e. bandwidth, delay). To achieve a more pow-erful triggering system, OLIE uses a fuzzy control-based model withrules specified by the system and by the application developers.For instance, a simple rule for making adaptive offloading trigger-ing decisions can be specified as follows: “if (AvailMem is low) and(AvailBW is high) then NewMemSize is low” and the fuzzy systemsimply uses a linguistic approach to assign a specific value to thelinguist value of low (i.e. 500 k). In comparison to simple threshold-based offloading triggering, the fuzzy control model allows OLIE to

implement more expressive and configurable triggering conditions.This approach is orthogonal to our and could be used to improve thethresholds decided by our tool, but our decision tree-based modelis more expressive and powerful, as it considers also issues related

G. Folino, F.S. Pisani / Applied Soft Co

ta

3

twctpTw

isoSttttastm

tbr

mitdbtem

BoostCGPC adopts the AdaBoost.M2 version of the well-known

Fig. 1. The overall software architecture of the system.

o the user requirements and not only the hardware/software char-cteristics of the application and of the device.

. System architecture and main modules of the framework

The main idea behind our system is using genetic programmingo evolve models, in the form of decision trees, which will decidehether it is convenient to perform the offloading of a mobile appli-

ation on the basis of the parameters and the properties typical ofhe application, of the user and of the environment, with the sup-ort of a tool for simulating both cloud and mobile environments.he overall software architecture of the system, illustrated in Fig. 1,ill be helpful in understanding how the framework works.

On the top of the architecture, there are the modules contain-ng the data, which will be used by the other components of theystem. These different modules will contain a set of data for eachf the four different categories considered. We refer the reader toection 4.1 for a detailed description of these categories. It is out ofhe scope of this paper to describe the techniques used to estimatehese components; we just would like to mention that in the case ofhe parameters describing the mobile devices, they can be found inhe literature for some models and can be estimated using appropri-te applications, such as PowerTutor, available in the Google Playtore for android-based mobile devices. The process to estimatehe energy consumption for various types of applications and for

ultiple classes of devices is analogous to that presented in [17].Afterwards, the sampler module will generate the training and

he validation dataset, by randomly combing the data estimatedy the above-mentioned models. These two datasets will be usedespectively to generate and validate the decision models.

Analyzing the rest of the software architecture, we find the twoain modules, used respectively for the simulation and for the

nference of the mobile offloading module. The inference part ofhe designed system consists of a genetic programming module,eveloping a population of models, suitable to decide the possi-le offloading of a mobile application. Indeed, each single model of

he GP population represents a decision tree able to decide a strat-gy for the offloading and must be evaluated using the simulationodule.

mputing 25 (2014) 253–265 255

BoostCGPC is used to generate the models by randomly combin-ing the function and terminal nodes, then each model is sent for theevaluation to the simulation module (the entire block, now namedsimulator module, comprising the mobile and the GreenCloud sim-ulator).

The simulation module consists of the GreenCloud simulator(simulating the cloud part of the offloading process) and of a mobilesimulator designed in order to model the mobile device behavior.In practice, each model generated by the GP module is passed to thesimulator module, which performs the fitness evaluation directlyon the basis of the results obtained simulating the model using thetraining dataset.

At the end of the process, the best model (or the best models)will form the rules adopted by the offloading engine, which willdecide whether an application must be offloaded, considering thedefined conditions (user requirements, bandwidth, characteristicof the mobile device and so on). The evaluation set could be usedto decide if it is convenient to maintain all or part of the generatedmodels in the repository for future use. In fact, the user can choose,as parameter of the system, the maximum number of models (or inalternative an error-based threshold) and consequently, when themaximum number of models is reached, the models with the worstaccuracy is eliminated or, in alternative, other pruning criteria canbe adopted.

Note that the entire system is adaptive; in fact, in the case ofchanges in the data modules, it is not necessary to run again all thecomponents from scratch. For instance, if we have new data, theycan be added to the training data, then, the BoostCGPC algorithmwill run for a number of rounds and the weights of the ensemblewill be consequently adjusted. In addition, just in the case of drasticchanges in the data (i.e. concept drifts), the GP module must runentirely and it will generate new models that will replace partsof the old models in accordance to some pruning criteria (i.e. byreplacing the oldest or the worst performing classifiers).

3.1. The GP module

In this section, the GP system and its design are described.The rules used to perform the offloading process are generated

using a genetic programming tool, named BoostCGPC Boost Cellu-lar Genetic Programming Classifier [8]. One of the advantages of thechosen GP-based module is that it can run on parallel/distributedarchitectures, permitting time-saving in the most expensive phaseof the training process. Furthermore, the use of GP supplies thecharacteristic of adaptivity and the possibility of working with lit-tle knowledge of the domain, which is really useful to this particularaim. As usual, in order to use GP for a particular domain, it is suf-ficient to choose an appropriate terminal and function set and todefine a fitness function. We chose a typical approach to GP forgenerating decision trees, choosing as terminals simply the twoanswers, yes and no, to the question “Is the process offloadable?”. Asnodes, the main parameters/properties that will drive the offload-ing process are used. More details about functions and terminalswill be given in Section 3.1.2.

3.1.1. The distributed GP engineThe Boost Cellular Genetic Programming Classifier [8] algorithm

builds GP ensembles using a hybrid variation of the classical GPdistributed island model. GP ensembles offer several advantagesover a monolithic GP, i.e. the possibility of coping with very largedata sets, more simple and understandable models, robustness andobviously the advantages related to a distributed implementation.

boosting algorithm introduced by Schapire and Freund [9] for“boosting” the performance of any weak learner, i.e. an algorithmthat “generates classifiers which need only be a little better than

2 Soft Computing 25 (2014) 253–265

riv

tstfi1si

nt�orw

“tgwa

h

wcnrnamirrdhttuo

isd

spKtpsmovfiwed

w

s

56 G. Folino, F.S. Pisani / Applied

andom guessing”. Therefore, in this section, first the original boost-ng algorithm is described, then BoostCGPC and the distributedariant of boosting used are illustrated.

The boosting algorithm adaptively changes the distribution ofhe training set depending on how difficult each example is to clas-ify. Given the number T of trials (rounds) to execute, T weightedraining sets S1, S2, . . ., ST are sequentially generated and T classi-ers C1, . . ., CT are built to compute a weak hypothesis ht. The value

is assigned to the weak hypothesis ht(xi, yi) if the hypothesis clas-ifies the example xi to the class yi, else the value 0 is assigned tot.

Let wti

denote the weight of the example xi at trial t. At the begin-ing w1

i= 1/n for each xi, where n is the number of tuples of the

raining set. At each round t = 1, . . ., T, a weak learner Ct, whose errort is bounded to a value strictly less than 1/2, is built and the weightsf the next trial are obtained by multiplying the weight of the cor-ectly classified examples by ˇt = �t/(1 − �t) and re-normalizing theeights so that �iw

t+1i

= 1.In this way, it focuses on examples that are hardest to classify, as

easy” examples get a lower weight, while “hard” examples, whichend to be misclassified, get higher weights. The boosted classifierives the class label y that maximizes the sum of the weights of theeak hypotheses predicting that label, where the weight is defined

s log(1/ˇt). The final classifier hf is defined as follows:

f = arg maxy∈Y

(T∑t

log(

1ˇt

)ht(x, y)

)(1)

In practice, BoostCGPC is an ensemble-based algorithm, inhich each GP classifier forming the ensemble is built using a

ellular GP algorithm (cGP)[7], enhanced with the boosting tech-ique, which runs on each node. cGP runs for T rounds; for everyound it generates a classifier per node, exchanges it with the otherodes, and updates the weights of the samples for the next round,ccording to the boosting algorithm. The selection rule, the replace-ent rule and the asynchronous migration strategy are specified

n the cGP algorithm. Each node generates the GP classifier byunning for a fixed number of generations. During the boostingounds, each classifier maintains the local vector of the weights thatirectly reflect the prediction accuracy. At each boosting round theypotheses generated by each classifier are exchanged among allhe processors in order to produce the ensemble of predictors. Inhis way, each node maintains the entire ensemble, which can besed to recalculate the new vector of weights. After the executionf the fixed number of boosting rounds, the classifiers are updated.

The distributed variant of AdaBoost.M2 used in BoostCGPC isllustrated in the pseudocode reported in Fig. 2 and describedhortly in the following (we refer the reader to [8] for a detailedescription of the algorithm).

Given the training set S = {(x1, y1), . . ., (xN, yN)}, containing Namples, where xi represents the feature vector of the ith sam-le and yi the corresponding label (assigned among the possible

classes), and given the number p of processors to be used to runhe algorithm, we partition the population of classifiers in p sub-opulations, one for each processor, and draw p sets of samples ofize n = N

p , by uniformly sampling instances from S with replace-ent. Each subpopulation is evolved for g generations and trained

n its local sample by running cGP. After g generations, the indi-idual with the best fitness is selected for participating to vote. Thetness is weighted using the distribution wt

i,y, which represents the

eight of the tuple i, when it is assigned to the class y. Note that

ach processor maintains a local vector of the weights, so that theistribution wt

i,yon processor 1 is different from the distribution

ti,y

on processor 2 and so on. Then, the p individuals, one for eachubpopulation, with the best fitness are exchanged among the p

Fig. 2. The algorithm parallel BoostCGPC version AdaBoost.M2.

subpopulations and make up the ensemble of predictors that willdetermine the weights of the examples for the next round. Afterthe execution of the fixed number T of boosting rounds, the over-all classifiers composing the ensemble (the overall number will bep · T), collected during the different rounds, are used to evaluate theaccuracy of the classification algorithm.

3.1.2. Functions, terminals and fitness evaluationThis section describes the fitness function used in the GP infer-

ence engine and the function and terminal nodes used.For this particular domain, in order to design an appropriate fit-

ness function, it is necessary to take into account three objectives:the energy wasted, the cost supplied to use the Cloud and the timesaved (or wasted) in performing the offload process. In practice, itis a multi-objective optimization problem and clearly there doesnot exist a single solution that simultaneously optimizes eachobjective. In fact, it is evident that there is no way to improve onone objective without degrading at least another one (i.e. reducingthe time without increasing the cost in using the Cloud platform).Different taxonomies were proposed for classifying multi-objectiveproblems in the context of evolutionary algorithms [4]. From thepoint of view of the user preferences (decision maker), we candistinguish the case of no-preferences, a-priori and a-posteriori,indicating that, respectively, the user does not indicate any prefer-ences or makes his choice before or after the optimization process.In our case, we are interested in defining the preferences before theprocess begins. A different classification concerning evolutionaryalgorithms distinguishes aggregation-based, criterion-based anddominance-based fitness assignment strategies. In the first case,the objectives are parameterized in a single-objective function, i.e.a weighted sum can be used. The second case affects the selectionof the individuals, which switches among the different objectives,i.e. different portions of individuals are chosen in accordance todifferent objectives. The latter uses some criteria based on thePareto dominance in order to compute the fitness. In our case,we are mostly interested in defining the fitness in accordanceto the user’s preferences that can be also drastically oriented

towards one or two objectives. Therefore, we decided to choice anaggregation-based (weighted sum) strategy, as differently from theother two strategies, it permits to directly choose the weights togive to the different criteria used (i.e. the energy, the time and the

Soft Co

cmrb

f

rdv

etwdt

et

iaC

t(rc

nof

t

tdttaftfXoanrsog

3

pcdcCt

coa

server, rack and switch. Servers are responsible for the task execu-tion and they are described by computational limits (MIPS, million

G. Folino, F.S. Pisani / Applied

ost saved by performing the offloading process); therefore, it isore appropriate in the cases in which the different criteria can be

eally unbalanced. By using the other two techniques, it would note easy to define the relative importance of the different criteria.

In the following, we described more in details as the fitnessunction is defined.

First of all, we define three normalized functions, representingespectively the energy saved, the time saved and the cost saveduring the process of offloading (actually the latter is a negativealue, as it is a cost not a saving): Senergy, Stime and Scost.

Senergy = Elocal−Eoffloadmax(Eoffload,Elocal)

, i.e. the ratio between the energy saved

xecuting the process on remote servers and the energy necessaryo perform the offloading. The energy is computed in accordanceith the analysis defined in [13] and the methodology is betteretailed in Section 3.2 together with the costs derived from usinghe cloud resources.

Stime = Tlocal−Toffloadmax(Toffload,Tlocal)

, i.e. the ratio between the time saved

xecuting the process on remote servers and the time necessaryo perform the offloading.

Differently, the cost function is computed as Scost = − CoffloadCsup

,

.e. the ratio between the cost due to the remote execution and parameter Csup defining a threshold of cost (if the cost overcomessup, Scost becomes −1).

Finally, the fitness is computed as the weighted sum of thehree equations described above, using three positive parameterspenergy, ptime, pcost), modeling the importance we want to giveespectively to the energy saving, to the time saving and to theost saving.

Considering an element Ti (representing an application run-ing on a determined device) of the training set T composedf n tuples, the fitness of this element is computed as:(Ti) = penergy * Senergy + ptime * Stime + pcost * Scost and consequently

he total fitness is given by ftot =∑i=n

i=1f (Ti).As for the functions and terminals, they were chosen following

he typical approach to GP for generating decision trees. In practice,ecision trees can be interpreted as composition of functions wherehe function set is the set of attribute tests and the terminal set arehe classes. The function set can be obtained by converting eachttribute into an attribute–test function. Thus, there are as manyunctions as attributes. For each attribute X, if X1, X2, . . ., Xn arehe possible values X can assume, the corresponding attribute–testunction fx has arity n, and if the value of X is Xi, then fx(X1, X2, . . .,n) = Xi. When a tuple has to be evaluated, the function at the rootf the tree tests the corresponding attribute and then executes thergument that outcomes from the test. If the argument is a termi-al, then the class name for that tuple is returned that, in our case,epresent the decision of taking (or not taking) the offloading deci-ion; otherwise the new function is executed. A detailed descriptionf the function set together with the set of possible values will beiven in Section 4.1.

.2. The simulator module

The mobile simulator is written in java and its architecture com-rises two sub-modules. The first computes the (time, energy andost) models that specify hardware characteristics of the mobileevices and the costs of the cloud services. The second sub-moduleomputes the fitness for all the tasks and interacts with the Green-loud simulator in order to obtain the estimated values concerninghe cloud environment (cost, execution time memory used, etc.).

The main aim of the simulator is to estimate the three importantomponents, which will be used to estimate the goodness (fitness)f a determined model built by the GP system: the time, the energynd the cost associated with that model. The equations used to

mputing 25 (2014) 253–265 257

estimate these three functions are based on the model developedby Kumar [13]. The first element is function of the time requiredto perform the task entirely on the mobile device and of the timerequired to perform the same task (or at least part of the task) onthe cloud server considering also the overhead associated with thecommunication; the second element is determined by the energywasted on the mobile device and the energy consumed performingthe offload; finally, the third module represents the cost of the cloudcomputing services.

The time component is the difference between the time to per-form the task locally or remotely. The time of local computationmainly depends on three factors: the average execution time, theprobability of interruption and the available memory. A higherprobability of interruption corresponds to a large amount of timeto complete the task. The available memory has effects on the com-putation time because the mobile OS performs a time-consumingswapping operation when memory is not sufficient.

In the case of the offload, the time depends on the computationtime on the server (obtained from the GreenCloud simulator) thatcorresponds to the waiting time of the mobile device and the timerequired to perform the migration of the data (and of part of theapplication). These delays depend on the type of network, on thelatency and on the bandwidth available.

The energy component is obtained from the difference of theenergy consumed when the task is executed on the mobile device(EM) and the energy consumed when the task runs on the cloudservers (EC). The energy wasted on the mobile system is given by theproduct between the average energy consumption of the systemfor unity of time (Pm) and the execution time (Tm). Obviously, theenergy depends on the CPU usage and on the system resources used(GPS, camera, etc.) that are correlated to complexity of the task, tothe available battery and to the system load.

Using the model proposed by Kumar, we indicate with C, thenumber of instructions required by the computation, with S thespeed (in number of instructions for second) of the cloud server andwith M the speed of the mobile device. If the data to be transferredbetween the mobile and the cloud system are D (bytes) and B is thenetwork bandwidth, it takes D

B seconds to transmit and to receivethe data. In addition, the mobile consumes (watts) are indicatedwith Pc (computing), Pi (idle), and Ptr (sending and receiving data).So, the following equations represents respectively, (2) the energyconsumed on the mobile system, (3) the energy consumed for theoffloading process and for waiting the end of the computation onthe cloud server and (4) the effective saving (ES), if positive of thecomplete offloading process.

EM = Pc ∗ C

M(2)

EC = Pi ∗ C

S+ Ptr ∗ D

B(3)

ES = Pc ∗ C

M− Pi ∗ C

S− Ptr ∗ D

B(4)

3.3. The GreenCloud simulator

The GreenCloud simulator1 [12], is a simulation environmentfor energy-aware cloud computing datacenters. It is derived fromNS2 (network simulator) and tracks the power use of all the com-ponents involved in a datacenter: hosts, communication switches,etc. Datacenter power analysis is focused about three core objects:

instructions per second), storage limits and memory limits. A rack

1 http://greencloud.gforge.uni.lu/.

2 Soft Co

ics

tmilmllBcCr

tsttpda

4

otd

4

tscftbaotpetobsp

esr

4

wda

4

f

58 G. Folino, F.S. Pisani / Applied

s a group of servers linked together by a Top-of-Rack switch thatonnects these servers to the main network. Each switch, and con-equently the underlying servers, can be disabled to save energy.

In order to model the server load, the GreenCloud simulator useshe workloads. The workloads are the objects designed for universal

odeling of various cloud user services, such as social networking,nstant messaging, and content delivery. Indeed, only three work-oad types are provided: CIWs (Computation Intensive Workloads)

odel high performance applications that have high-computingoad with very few data to transfer; DIWs (Data Intensive Work-oads) are designed to simulate tasks with very heavy data transfers.Ws (Balanced Workloads) model applications with both data andomputing requirements. Using these three types of jobs, Green-loud is able to simulate different datacenter configurations and toeport detailed energy consumption of all the components.

In our framework, the GreenCloud simulator is used to evaluatehe execution times of the part of the application offloaded on theervers and consequently the costs necessary to use the servers andhe energy wasted. Although the main interest of this paper is onhe mobile side, on the datacenter side, we need to simulate therocessing delays, the submitting task rates, the impact of mobileata size in the overall performance in order to identify classes ofpplications that benefits from the computation offloading.

. Taxonomy and data

In this section, we describe the taxonomy of the parameters andf the properties, which the GP module will use to build the modelhat will decide the offloading strategy and the way in which theata modules are related to the taxonomy.

.1. A taxonomy of the main properties for the offloading process

Unfortunately, there is no comprehensive taxonomy concerninghe different aspects of the offloading process. Therefore, in thisection, we define a taxonomy that divides the main parametersonsidered in the analysis of a mobile environment into four dif-erent categories: Application (i.e. the parameters associated withhe application itself); User (the parameters desired and imposedy the user’s needs); Network (i.e. parameters concerning the typend the state of the network); Device (i.e. the parameters dependingnly on the hardware/software features of the devices). In practice,he decision model, built by the GP module of our architecture, willerform the decision of offloading or not on the basis of the differ-nt parameters associated to these categories. It is worth noticinghat many parameters could be more detailed and complex andther could be added; however, our taxonomy does not claim toe exhaustive, but we tried to simplify the model and did not con-ider particular aspects, which should not influence the offloadingrocess.

In the following, we will give a short description of the param-ters chosen for each defined category. Where not differentlypecified, the values of the parameters have been discretized inanges, using discrete values such as low, moderate, high, etc.

.2. Application

The parameters associated with this category consider features,hich are typical of the application to be executed on the mobileevices, in an attempt to characterize all the aspects useful to take

decision on the offloading process.

.2.1. Average execution timeThe average execution time of the application measured for dif-

erent typical dimensions of the input.

mputing 25 (2014) 253–265

4.2.2. Data sizeThe size of the data, which eventually should be transferred

during the offloading process.

4.2.3. Local computation/communication ratioA value expressing whether the application devotes most of

its execution time to the execution of the local computation or tousing the network (0 indicates an application performing only localcomputation, 1 an application continuously interacting with thenetwork).

4.2.4. Probability of interruptionA mobile application could be interrupted for different rea-

sons: system crash, user interruption, no availability of a necessaryresource (network, GPS, etc.). This parameter represents the prob-ability the application is interrupted before the end of the process.

4.3. User requirements

This class of parameters considers the needs and the behaviorof the user of the mobile device, modeling the different categoriesof users with their different styles.

4.3.1. MobilityEvery user has different behaviors and habits in terms of mobil-

ity. Some users spend most of the time in the same place (typicallyat home and at work), while others move frequently in differentplaces and this should be considered in the process of offloadingfor the continuous changes in the network used, the need for abetter duration of battery and so on. This parameter models theprobability of mobility of the user.

4.3.2. UrgencyThis parameter models the urgency or the priority with which

the user wants to obtain the partial/final results of the application.If the user is too impatient to get results, he could prefer a greaterbattery consumption to a longer waiting time.

4.3.3. Privacy sensitivityPeople are understandably sensitive about how the application

captures their data and how the data are used. However, differ-ent users can present different sensibility, from the paranoiac tothe too confident user. In our context, choosing privacy-preservingsolutions can degrade the performance of the offloading process,owing to the difficulty of moving the data or to the additional costof adding protection.

4.3.4. CostThe cost a user can/wants to pay is a fundamental parameter

in order to perform the offloading. In fact, the cost of the cloudplatform is usually correlated to the time and the resources used.

4.4. Network

The network plays a fundamental role in the process of offload-ing, as it determines the velocity of the process and limits thepossibility of exchanging data in real time. In fact, it is not con-venient to perform the offloading of an application needing toexchange a large stream of data when the efficiency of the networkdoes not permit a fast transfer of the data itself.

4.4.1. QoS of the networkAs quality of service of the network we consider a parameter

estimating the reliability and stability of the network.

Soft Computing 25 (2014) 253–265 259

4

eq

4

d

4

3fb

4

mmic

4

i

4

pt

4

dd

4

oi

tcuvtmcptiiApuoo

utplaf

Table 1A synthetic description of the properties defined in the taxonomy and their possi-ble values (D1 corresponds to the discretization in: very low, low, low medium,medium, high medium, high, very high and D2 in: low, medium, high).

Category Property Values

ApplicationAvgtime D1Datasize D1Interruption D1

User

Mobility D2Urgency D2Privacy D2Cost D1

Network

QoS D2Bandwidth D2Latency D2Network type Wifi, 2G, 3G, LTE

Battery D2CPU D1

G. Folino, F.S. Pisani / Applied

.4.2. BandwidthThe bandwidth of the network is an important parameter to

stablish whether the offloading of large applications/data can beuickly executed.

.4.3. LatencyThe latency of the network is useful when small quantities of

ata must be exchanged during the offloading process.

.4.4. Type of networkThis parameter models the type of network available, i.e. Wifi,

G, 2G, etc. The type of the network is crucial for saving energy, asor instance, a device transmitting data using wifi consumes lessattery than using 3G.

.5. Mobile device

The last class of parameters we consider is pertinent to theobile device. Analyzing the state and the characteristics of theobile device is essential in order to drive the process of offload-

ng. On the following we list the most important parameters to beonsidered.

.5.1. Battery levelThe battery charge level is of fundamental importance, as, when

t is low, the process of offloading can be encouraged.

.5.2. CPU load and memory availabilityThe load of the CPU and the available memory are two important

arameters, which can influence the choice of the offloading ratherhan the execution on local resources.

.5.3. ConnectivityThis parameter represents the strength of the network signal

etected by the mobile device (obviously it depends both on theevice and on the quality of the network).

.6. The data modules

In this section, a description of the datasets modeling theffloading process and of the distributions used to generate thems supplied.

We remember that the first four modules of the software archi-ecture contain the sets of data for each of the four categoriesonsidered (user, device, network and application), which will besed by the sampler module in order to generate the training andalidation datasets, simply by randomly combing the data. Thesewo datasets will be used to generate and validate the decision

odels. Each dataset consists of a number of tuples and each featureomposing the tuple is associated with a property described in therevious section and it is associated with a set of values. For eachuple, each feature (corresponding to a property of the taxonomy)s selected randomly by following a probability distribution. Thiss done to ensure that the dataset represents a realistic scenario.s, for many properties, the distributions are determined by thearticular class of application, we choose to generate the datasetssing different distributions in order to model the different typesf behavior. In the experimental section, more details will be givenn the chosen distributions.

It is out of the scope of this paper to describe the techniquessed to estimate parameters (mean value, etc.) used in the dis-ributions; we just would like to mention that in the case of the

arameters describing the mobile devices, they can be found in the

iterature for some models and can be estimated using appropriatepplications, such as PowerTutor, available in the Google Play storeor the android-based mobile devices. The process we conduct to

Device Memory available D1Connectivity D1

estimate the energy consumption for various types of applicationsand for multiple classes of devices is analogous to that presentedin [17], conducted on some modern android-based mobile devices.The other parameters of the distributions were taken from the liter-ature [14,18,21,2]. In the following, we just cite some specific casesuseful to justify our choices.

The probability of interruption specifies a probability and thevalue is defined in [0, 1] range. A mobile application could be inter-rupted for different reasons: system crash, user interruption, notavailability of a necessary resource (network, GPS, etc.). This param-eter represents the probability that an application is interruptedbefore the end of its process.

As for the properties concerning the category of user require-ment, most of them are subjective (i.e. mobility, urgency andprivacy sensitivity) and are modeled using discrete values as verylow, low, medium, high and very high. The network category alsoneeds some explanations. The property named Quality of Service ofthe network estimates the reliability and stability of the network.The bandwidth of the network is another important parameter toestablish whether the offloading of large applications/data can bequickly executed. The latency of the network is useful when smallquantities of data must be exchanged during the offloading pro-cess. All these three properties are modeled using discrete values(very low, low, medium, high and very high). The last property ofthis category is the type of the network. This parameter modelsthe type of network available and consequently affects the speedof transmission of the data (i.e. LTE is considerably faster than a 2Gnetwork). The feasible values are: wifi, 3G, 2G, LTE.

Table 1 synthesizes the discretization used for the differentproperties of the taxonomy; some properties need a finer level ofdiscretization and we choose to use 6 values (D1), while for othersusing 3 values (D2) is sufficient to model their behavior.

Finally, it is common that some of properties may present miss-ing values (i.e. unknown or not specified, wrong or other) and thatis handled with the possibility of having the value “undefined”(indicated with the symbol ?) in most of the features.

5. Experimental results

In this section, we present an experimental evaluation of ourframework, aimed to establish whether it can be profitably used

to build models for the process of offloading and to analyze thebehavior of our algorithm for different categories of mobile appli-cations. A first set of experiments, described in Section 5.3, analyzesthe performance of our framework when the distributions of the

260 G. Folino, F.S. Pisani / Applied Soft Co

Table 2A synthetic description of the datasets and of the typical applications they model.

Dataset Synthetic description Use cases

A Average time and datasizeproperties are generated with azipf distribution. Probability ofinterruption property follows anormal distribution

Applications usuallyinterrupted by an event (i.e. acall, a text message, anotification of another app,etc.). This datasets presents anequal distribution oflong/heavy and short/lighttasks

B Datasize, average time andprobability of interruptionproperties are generated with anormal distribution

Applications presenting amedium/long execution timeor computationally intensive(i.e. gaming, image processing,etc.)

C Probability of interruption,network QoS, averageexecution time, networkbandwidth, battery level andCPU available are generatedwith a zipf distribution.Datasize, network latency,network type, memoryavailable and connectivity are

Most complex scenario(communication, multimedia,sport and shoppingapplications). They are usedfrequently and for short timeand have very lowrequirements in terms of time,energy or performance

meaFa(pd

5

dgoctdidtf

tlmfbmia

tsdag

ntd

generated with a normaldistribution

ain properties of the systems and the parameters weighting thenergy, the cost and the time are varied. Then, a comparison with

well-known classification algorithm is performed in Section 5.4.inally, the model obtained are shown and described in Section 5.5nd the behavior of the framework in a real scenario is analyzedSection 5.6). On the following two sections, the datasets and thearameters used in the experiments and the metrics adopted areescribed.

.1. The dataset and the distributions

To the best of our knowledge, in the literature, there are no realatasets modeling the behavior of mobile devices. Therefore, weenerated three datasets (named A, B and C) to model a numberf realistic scenarios for our experiments. A tuple of a dataset isomposed from a set of features, each one modeling a property ofhe mobile system (see Section 4.1) and the class represents theecision of offloading or not. A percentage of 70% of the datasets

s used as training set and the remainder for testing. A syntheticescription of the datasets, together with the typical applicationshey represent is reported in Table 2 and described in detail in theollowing.

Dataset A is modeled using a zipf distribution for the averageime and for the datasize property, while the other properties fol-ows a uniform distribution. This choice replicates the case in which

ost part of the applications have short execution times and veryew applications present high execution times, while the proba-ility of interruption follows a normal distribution. This datasetodels the common mobile user behavior in which an application

s interrupted by an event (a call, a text message, a notification ofnother app, etc.).

The three main properties in the dataset B (datasize, averageime and probability of interruption) follow a normal distributiono that we have a dataset that represents the typical case of the topownloaded apps (mainly game, social and messaging apps), with

similar use behavior. Also in this case, the other properties areenerated with a uniform distribution.

As for the third dataset (C), the probability of interruption, theetwork QoS, the average execution time, the network bandwidth,he battery level and the CPU available are generated using a zipfistribution, while the other properties are generated using a

mputing 25 (2014) 253–265

normal distribution. Using this dataset we want to model a morecomplex environment in which most of the applications are definedby a moderate use of memory and size of data to transmit and aver-age values for network latency and signal strength in 3G networks,which is the most used type of network. For these reasons, moreenergy is required for the transmission. For values generated withzipf distribution, the applications have low resource available, poornetwork performance as mean value and most of the applicationspresents a low use time. These characteristics reproduce a scenariowhere offloading is less profitable.

It is worth noticing that experts of the domain could find dis-tributions modeling the real behavior of the previously describedproperties better than how defined in this section; however, theaim of this work is not to define the “best” distributions for theproperties of the mobile applications, but to build a framework ableto simulate different distributions and understand the behavior interms of cost, energy and time savings.

5.2. Parameters and metrics used in the experiments

All the experiments were performed on a Linux cluster with16 Itanium2 1.4 GHz nodes, each having 2 GBytes of main memoryand connected by a Myrinet high performance network. In eachexperiment, the BoostGCPC module uses the same GP parametersused in the original paper [8](prob. of crossover = 0.8, prob. of muta-tion = 0.1, maximum depth = 17) and a population of 100 individualsper node. The algorithm was run for 5 rounds of boosting on 5nodes, using 100 generations for rounds. The original training setwas partitioned among the 5 nodes. It is worth remembering thatthe algorithm produces a different classifier for each round on eachnode, generating a final ensemble of 25 classifiers. A parsimony fac-tor of 0.0001 was used in order to reduce the size of the classifiers.All results were obtained by averaging 30 runs.

In order to evaluate the behavior of different configurations andtypes of mobile applications, besides the classical error measure inthe classification task (the ratio between the number of correctlyclassified cases and the total number of cases), the two standardmetrics of false negative rate and false positive rate developed fornetwork intrusions, have been used. If the process does not needto be offloaded is considered normal, the false positive (also calledfalse alarm) rate can be computed as the ratio between the num-ber of normal processes classified as to be offloaded and the totalnumber of normal processes, that is:

FP = #FalseAlarm#TrueNegative + #FalseAlarm

while false negative is the opposite case (i.e., the ratio betweenthe number of “to be offloaded” processes classified as normal andthe total number of “to be offloaded” processes). These metrics areimportant because they help to understand which of the two casesis most costly for the offloading process.

5.3. Comparing different experimental setups and distributions

In this section, a suite of experiments is conducted in order toanalyze the behavior of our algorithm for different categories ofmobile applications and for different experimental setups. The falsepositive and false negative rate and the overall error is computedby running the framework on the three datasets described in Sec-tion 5.1, by varying the parameters weighting the energy, the costand the time. In this way, we want to understand if the frameworkis particularly suitable to a specific distribution or is more oriented

toward a specific parameter (i.e. energy), or it is effective to detectthe rate of false positives or false negatives.

The results of this evaluation are illustrated in Figs. 3–5. Foreach dataset, we used six different setup configurations reported in

G. Folino, F.S. Pisani / Applied Soft Computing 25 (2014) 253–265 261

Fig. 3. The different errors (FP, FN and total) for the dataset A using different con-figurations.

Fig. 4. The different errors (FP, FN and total) for the dataset B using different con-figurations.

Fig. 5. The different errors (FP, FN and total) for the dataset C using different con-figurations.

Table 3The different configurations of parameters used.

C1 C2 C3 C4 C5 C6

penergy 1 1 1 2 2 2ptime 1 1 1 0.2 0.2 1pcost 0.1 0.5 1 0.2 1 1

Table 4The percentage of tasks, for which it is convenient to perform the offloading process,for each dataset and for each configuration.

C1 C2 C3 C4 C5 C6

A 62.82% 71.62% 80.48% 40.11% 51.72% 62.74%

B 98.65% 99.58% 99.95% 76.68% 85.33% 96.43%C 46.54% 52.95% 61.27% 24.43% 29.26% 40.53%

Table 3. The parameters were chosen to give different importanceto the energy, the time and the cost components of the fitness func-tion, in order to represent a good assortment of cases. From Table 4,it is evident that, in the particular case of the dataset B, using theconfigurations named C1, C2, C3, we should perform the offloadingin almost all the cases and the percentage of the minority class isvery low and it would be almost impossible to be correctly deter-mined by a classification algorithm; therefore, for this dataset, weused only the configurations C4, C5 and C6.

It is clear that the ability in detecting the false positive rate isgenerally preferable than that in detecting the false negative ratein almost all cases, typically because the cost in offloading a notoffloadable application can be really high. In fact, for the dataset Aand for the cases in which the two classes are well balanced (C4 andC5), the algorithm is really effective in detecting the false positives.In the dataset B (Table 4), the number of examples, which is conve-nient not to offload, is very low, especially for the configuration C6.Therefore, in this particular case, the algorithm has a large error interms of false positive and obtains a very low error in term of falsenegatives. Differently from the previous datasets, for the datasetC, which represents the most complex case, there is not much dif-ference between the detection rate of false positives and that offalse negatives, as probably there are present many situations inwhich the advantage in offloading a particular application can bereally elevated (and compensate the cost derived from offloading awrong application).

5.4. Comparing with the boosted version of C4.5

C4.5 is one of the most-used classifications methods and itsimplementation is contained in the WEKA open source software2.For the sake of comparison, we decided to compare our algo-rithm with a boosted version of the C4.5 algorithm, modified touse instances with a weight given by the fitness function of ouralgorithm.

The entropy measure defined in the C4.5 algorithm measuresthe average amount of information necessary to identify the classof a training case. By computing the formula, every instance of thetraining set is considered as having a weight equal to 1. However,the weka implementation has the possibility to assign a differentweight to each tuple (i.e. the cost of misclassifying the class towhich the instance belonged). We modify the weight of an instance,replacing it with the same fitness function we used in our algorithm.The sum is normalized, so that the sum of all training instance

weights is still equal to the dimension of the training set. Thismodification transforms the standard tree-based C4.5 procedure

2 http://www.cs.waikato.ac.nz/ml/weka/.

262 G. Folino, F.S. Pisani / Applied Soft Computing 25 (2014) 253–265

Table 5Comparison between BoostCGPC (BG in the table) and Boost-C4.5 (BC in the table) on the different metrics; bold values represent the best statistically significant results.

Dataset Conf. Fit. diff FN BG FN BC FP BG FP BC Error BG Error BC

A C1 −0.43% 13.37% 15.27% 22.54% 21.03% 16.72% 17.38%A C2 −1.66% 5.84% 20.86% 40.13% 16.36% 15.53% 17.51%A C3 −3.98% 2.24% 26.67% 48.59% 12.59% 11.04% 17.35%A C4 −4.29% 15.65% 4.73% 9.91% 36.56% 12.24% 17.17%A C5 −1.13% 16.60% 11.16% 14.54% 30.31% 15.62% 17.32%A C6 −0.21% 7.02% 15.81% 39.03% 21.57% 15.17% 17.49%B C4 −1.46% 4.61% 5.57% 55.88% 61.59% 16.57% 13.38%B C5 −1.64% 1.09% 6.80% 63.64% 49.93% 10.47% 13.27%B C6 −3.49% 0.07% 10.90% 94.78% 25.19% 3.24% 13.20%C C1 −1.15% 14.48% 19.90% 9.19% 8.68% 11.68% 13.95%C C2 −1.20% 18.41% 26.45% 9.17% 6.68% 14.12% 14.21%C C3 −2.33% 10.44% 35.20% 19.53% 5.33% 13.86% 14.05%C C4 −3.49% 24.49% 7.05% 4.73% 23.84% 9.60% 13.66%

9%

1%

iw

uIfr

dbTfasfip

tc

5

f

C C5 −1.68% 16.90% 11.5C C6 −0.93% 16.00% 17.6

n a method that seeks to minimize the number of errors with higheight or cost.

We compared our algorithm with the boosted version of C4.5,sing the weights in accordance with the above-given description.

n order to validate statistically the comparison results, we per-ormed the two-tailed t-test ( ̨ = 0.05) over the 30 runs and theesults are shown in Table 5.

The values in bold in the error columns highlight, for eachataset, the results that, according to the t-test, are significantlyetter with respect to the other corresponding column of the error.he boosted version of C4.5 was run using standard parametersor 25 rounds in order to generate the same number of classifierss our algorithm. In the table, the fitness difference column repre-ents the difference in percentage between this function and thetness function of our algorithm (negative values indicate a bettererformance of our system).

Our framework presents better results in term of fitness func-ion for all the datasets and configurations and, as for the overalllassification error, it behaves better in most of the cases.

.5. Analyzing the models

In this section, we analyze some examples of trees generatedrom the framework. One tree for each dataset, randomly taken

Fig. 6. An example of generated

7.55% 20.56% 10.40% 13.74%9.11% 13.86% 11.96% 13.96%

from the final ensemble, is shown in Figs. 6, 7 and 8. We alsoanalyzed the other trees belonging to the ensembles and the con-siderations on the following are generally valid. From the exampleof generated tree for the dataset A, shown in Fig. 6, it is imme-diately evident that the execution time, the amount of data to betransmitted and the type of network used for transmission are themain discriminating factors to perform the offloading process ornot. This is due to the impact that the offloading process has interms of energy and time taken to perform the offloading. It is use-ful to remember that communication has a significant impact onenergy consumption on a mobile device. Indeed, the first and sec-ond level of the tree are sufficient to classify applications with avery short or very long execution times. Obviously, if the data tobe transmitted are low, then the offloading is preferable. This treereflects the nature of the applications modeled by this dataset: vari-ables execution time, very different amount of transmitted dataand, in general, no predominant trend to decide of performing theoffloading.

As for the dataset B (Fig. 7), the percentage of offloadable tasks ispredominant. The decision to make or not the offloading depends

on the situations in which the power consumption is excessive inrelation to the task requirements or to the condition of the battery.For example, tasks with low avgtime, medium qos and a high-energynetwork usage do not perform the offloading. The same decision is

model for the dataset A.

G. Folino, F.S. Pisani / Applied Soft Computing 25 (2014) 253–265 263

Fig. 7. An example of generated model for the dataset B.

erated

tsCtdoil

5

rart

E

tion: Smart OCR TextMiner6, which permits to convert images totext and extract text from PDF files. This application was run ona sample of ten images of different sizes from 100 K to 3M, with

Fig. 8. An example of gen

aken whether the network type is not specified (indicated with theymbol ? in the figure) and the device has low battery. As for dataset

(Fig. 8), composed by a low percentage of tasks that benefits fromhe offloading, the final decision is mainly determined from the con-itions of the network (bandwidth available, network type, latency)r from the amount of data to be transferred. The execution times only used for the decision in the rare case of applications with aong execution time (i.e. games).

.6. A real scenario: an OCR application

In this section, we want to analyze the performance of our algo-ithm from the point of view of the accuracy of the prediction, when

real application and a real environment is used. We would like to

emark that our tool is mainly oriented toward simulation and thenhe obtained result must be always validated on a real environment.

For our experiments, we used a private homogenousucalyptus-based Cloud environment at ICAR-CNR and two

model for the dataset C.

android-based smartphones: the LG Nexus 43 and the SamsungNexus S4. As for the cloud side, we run VMs based on the ORACLEvirtualbox with the Genymotion version of the android emulator5

running Android 4.3 and each node of the Cloud has an Intel I52.5 GHz processor and 8 GBytes of main memory. The Nexus 4has a 1.5 GHz quad-core Snapdragon processor and 2 GBytes ofmemory, while the Nexus S has a 1 GHz Arm Cortex A8 processorand 512 MBytes of memory.

The application chosen is a CPU time-consuming OCR applica-

3 http://www.lg.com/in/mobile-phones/lg-Nexus4-E960-mobile-phones.4 http://www.samsung.com/it/consumer/mobile-devices/smartphone/

smartphones/GT-I9023FSAITV.5 http://www.genymotion.com/.6 https://play.google.com/store/apps/details?id=com.appstyle.gosmartocr.

264 G. Folino, F.S. Pisani / Applied Soft Co

Fc

dli

p4aot

oveaTtuu

t8scbOhmd2vdab

6

dtwof

[

[

[

ig. 9. The different errors (FP, FN and total) for the OCR application using differentonfigurations (C4, C5 and C6).

ifferent difficulties in the OCR task (from simple text to complexayout, images, tables, etc.), taken from a public source of OCRmages7.

In order to test the application, we generated a dataset com-rising 5000 tasks, obtained by combining 10 sizes of documents,

types of networks (2g, 3g, Wifi, LTE) and 5 different bandwidths;s the dataset B (Table 2) models better this kind of application, thether parameters follow the same distributions chosen to modelhis dataset.

Note that the previous simulated experiments were averagedver 30 runs, then generating 30 different ensembles; in order toalidate the ensemble on our real scenario, we run the differentnsembles on 10% of the test dataset (i.e. 500 tasks) for validation,nd we selected the ensemble that performed better on these cases.his ensemble will be used on the remaining 4500 tuples, in ordero evaluate the goodness of our simulator in the real case. The eval-ation was performed on the same configurations (C4, C5 and C6)sed in Fig. 4 and the different errors are reported in Fig. 9.

The percentage of cases in which is more convenient to performhe offloading was respectively for the three configurations, 74%,3% and 91%. The trend of the results concerning the real data isimilar to the results of the simulated dataset; however, in the realase, we can observe a slight increase in the percentage of erroroth for the FNs and for the FPs (for the configurations C4 and C5).n the contrary, for the configuration C6 (in which the time savingsas a greater weight), the capacity in detecting the FPs is improved,ainly because the classes are not so unbalanced as for the real

ataset. However, the overall error is considerably worsened (about0%), probably because the dataset is quite homogenous in thealues of the features avgtime and datasize and consequently theecision trees are not able to discriminate well the different casesnd do not perform the offloading in many cases in which it woulde necessary (FNs).

. Conclusions and future work

This work presents an automatic approach to generatingecision-taking models for the offloading of mobile applications onhe basis of user requirements, conditions of the network, the hard-

are/software features of the mobile device and the characteristics

f the application. The system is made up of a general frameworkor testing offloading algorithms and includes a mobile simulator,

7 http://ocrsdk.com/documentation/sample-images/.

[

[

[

mputing 25 (2014) 253–265

which computes the energy wasted in the process of offloadingand an inference engine that generates the models performing theautomatic offloading process. The latter is based on a distributedGP module, in which the functions are the parameters of a ad-hoc designed taxonomy, and the fitness function is parametricallydefined in a way that permits one to give a different weight to thecost, the time, the energy and the quality of service depending onwhat interests more.

Experimental evaluation of our framework permitted the analy-sis of the behavior of our algorithm for different categories of mobileapplications, when the distributions of the main properties of thesystems and the parameters weighting the energy, the cost andthe time are varied. We also compared our system with a boostedversion of the C4.5 algorithm in order to establish the goodness ofour approach in modeling the offloading process. Finally, we vali-date the framework on a real case concerning an OCR application.Ongoing and future activities involve testing the framework withother real-world datasets in order to verify whether the obtainedmodels improve battery performance in real environments and toperform an analysis of the sensitivity of the system when the mainparameters change.

Acknowledgments

This research work has been partially funded by the MIURproject FRAME, PON01-02477.

References

[1] G.D. Abowd, A.K. Dey, P.J. Brown, N. Davies, M. Smith, P. Steggles, Towardsa better understanding of context and context-awareness, in: Handheld andUbiquitous Computing, First International Symposium, HUC’99, Karlsruhe,Germany, Springer, 1999, pp. 304–307.

[2] M. Böhmer, B. Hecht, J. Schöning, A. Krüger, G. Bauer, Falling asleep with angrybirds, facebook and kindle: a large scale study on mobile application usage,in: Proceedings of the 13th International Conference on Human ComputerInteraction with Mobile Devices and Services, MobileHCI ’11, ACM, 2011, pp.47–56.

[3] R. Buyya, C.S. Yeo, S. Venugopal, J. Broberg, I. Brandic, Cloud computing andemerging it platforms: Vision, hype, and reality for delivering computing asthe 5th utility, Future Gener. Comput. Syst. 25 (6) (2009) 599–616.

[4] C.A.C. Coello, G.B. Lamont, D.A.V. Veldhuizen, Evolutionary Algorithms forSolving Multi-Objective Problems. Genetic and Evolutionary Computation,Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2006.

[5] J. Flinn, S. Park, M. Satyanarayanan, Balancing performance, energy, and qualityin pervasive computing, in: Proceedings of the 22 nd International Conferenceon Distributed Computing Systems (ICDCS’02), IEEE Computer Society, 2002,pp. 217–226.

[6] G. Folino, F.S. Pisani, A framework for modeling automatic offloading of mobileapplications using genetic programming, in: Applications of Evolutionary Com-putation – 16th European Conference, EvoApplications 2013, Vienna, Austria,April 3–5, volume 7835, Springer, 2013, pp. 62–71.

[7] G. Folino, C. Pizzuti, G. Spezzano, A scalable cellular implementation of parallelgenetic programming, IEEE Trans. Evol. Comput. 7 (February (1)) (2003) 37–53.

[8] G. Folino, C. Pizzuti, G. Spezzano, Gp ensembles for large-scale data classifica-tion, IEEE Trans. Evol. Comput. 10 (October (5)) (2006) 604–616.

[9] Y. Freund, R. Shapire, Experiments with a new boosting algorithm, in: MachineLearning, Proceedings of the Thirteenth International Conference (ICML ’96),Morgan Kaufmann, Bari, Italy, 1996, pp. 148–156.

10] X. Gu, K. Nahrstedt, A. Messer, I. Greenberg, D.S. Milojicic, Adaptive offloadinginference for delivering applications in pervasive computing environments, in:Proceedings of the First IEEE International Conference on Pervasive Computingand Communications (PerCom’03), March 23-26, Fort Worth, Texas, USA, 2003,pp. 107–114.

11] S. Gurun, C. Krintz, Addressing the energy crisis in mobile computing withdeveloping power aware software, in: UCSB Technical Report. UCSB ComputerScience Department, 2003.

12] D. Kliazovich, P. Bouvry, S.U. Khan, Greencloud: a packet-level simulator ofenergy-aware cloud computing data centers, J. Supercomput. 62 (3) (2012)1263–1283.

13] K. Kumar, Y.-H. Lu, Cloud computing for mobile users: Can offloading compu-tation save energy? IEEE Comput. 43 (4) (2010) 51–56.

14] K. Lee, I. Rhee, J. Lee, S. Chong, Y. Yi, Mobile data offloading: how much can wifi

deliver? IEEE/ACM Trans. Netw. 21 (2) (2013) 536–550.

15] J. Liu, K. Kumar, Y.-H. Lu, Tradeoff between energy savings and privacy pro-tection in computation offloading, in: Proceedings of the 2010 InternationalSymposium on Low Power Electronics and Design, Austin, Texas, USA, August18–20, 2010, ACM, 2010, pp. 213–218.

Soft Co

[

[

[

[

[

[

MobiArch ’12, ACM, 2012, pp. 3–10.

G. Folino, F.S. Pisani / Applied

16] A.P. Miettinen, J.K. Nurminen, Energy efficiency of mobile clients in cloud com-puting, in: Proceedings of the 2nd USENIX Conference on Hot Topics in CloudComputing, HotCloud’10, Berkeley, CA, USA, USENIX Association, 2010.

17] V. Namboodiri, T. Ghose, To cloud or not to cloud: a mobile device perspectiveon energy consumption of applications, in: The Thirteenth International Sym-posium on a World of Wireless, Mobile and Multimedia Networks, WOWMOM’12, pp. 1–9, IEEE Computer Society, San Francisco, California, 2012.

18] A. Ortiz, J. Ortega, A.F. Díaz, A. Prieto, Modeling network behaviour by full-system simulation, J. Softw. 2 (2) (2007) 11–18.

19] A. Pathak, Y.C. Hu, M. Zhang, P. Bahl, Y.-M. Wang, Enabling automatic of fload-ing of resource-intensive smartphone applications. Technical report, PurdueUniversity, 2011.

[

mputing 25 (2014) 253–265 265

20] A. Saarinen, M. Siekkinen, Y. Xiao, J.K. Nurminen, M. Kemppainen, P. Hui,Offloadable apps using smartdiet: Towards an analysis toolkit for mobile appli-cation developers. CoRR, abs/1111.3806, 2011.

21] A. Saarinen, M. Siekkinen, Y. Xiao, J.K. Nurminen, M. Kemppainen, P. Hui, Canoffloading save energy for popular apps? in: Proceedings of the Seventh ACMInternational Workshop on Mobility in the Evolving Internet Architecture,

22] R. Wolski, S. Gurun, C. Krintz, D. Nurmi, Using bandwidth data to make compu-tation offloading decisions, in: 22nd IEEE International Symposium on Paralleland Distributed Processing, IPDPS 2008, Miami, Florida USA, April 14–18, 2008,pp. 1–8. IEEE, 2008.