enhancing offloading systems with smart decisions...

Research ArticleEnhancing Offloading Systems with Smart Decisions AdaptiveMonitoring and Mobility Support

Paulo A L Rego 1 Fernando A M Trinta1 Masum Z Hasan2 and Jose N de Souza1

1Group of Computer Networks Software Engineering and Systems (GREat) Federal University of Ceara (UFC) Fortaleza CE Brazil2Verizon San Jose CA USA

Correspondence should be addressed to Paulo A L Rego pauloalrufcbr

Received 17 December 2018 Revised 16 March 2019 Accepted 24 March 2019 Published 21 April 2019

Academic Editor Mohammad Shojafar

Copyright copy 2019 Paulo A L Rego et alThis is an open access article distributed under theCreative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Mobile cloud computing is an approach for mobile devices with processing and storage limitations to take advantage of remoteresources that assist in performing computationally intensive or data-intensive tasks The migration of tasks or data is commonlyreferred to as offloading and its proper use can bring benefits such as performance improvement or reduced power consumptionon mobile devices In this paper we face three challenges for any offloading solution the decision of when and where to performoffloading the decision of which metrics must be monitored by the offloading system and the support for userrsquos mobility in ahybrid environment composed of cloudlets and public cloud instances We introduce novel approaches based on machine learningand software-defined networking techniques for handling these challenges In addition we present details of our offloading systemand the experiments conducted to assess the proposed approaches

1 Introduction

The use of mobile devices in the daily activities of a largepart of the world population is a common reality Mobileapplications (or apps) allow users to access data and servicesquickly and easily virtually anywhere Over the last decadesmobile apps have evolved significantly with 3D graphicssupport growing integration with different kinds of sensorsand remote services In consequence some devices withlimited processing and storage capabilities face the challengeof running applications with some aforementioned features

One strategy to address this issue is the integrationbetween mobile devices and cloud resources through aparadigm calledmobile cloud computing (MCC) [1] Accord-ing to [2] MCC aims to provide a range of servicesequivalent to the cloud adapted to the capacity of resource-constrained devices besides performing improvements oftelecommunications infrastructure to improve the serviceprovisioning Along last years different research groups havebeen studying this theme including white-papers softwarearchitecture case studies and research challenges for MCCMost of them focus on the migration of data and tasks frommobile devices to remote servers with better processing and

storage capacity This migration is known in the literature asoffloading

In general when proposing an offloading solution themost important issue to be addressed is how to decide whenit is worthwhile to migrate data or tasks from amobile deviceto a remote execution environment (REE) which might beanother mobile device or a cloudletcloud This decision maytake into account the time needed to transfer and execute thetask remotely and the energy cost of the offloading operationas well as several software hardware and network-relatedmetrics Diverse solutions have been proposed to decidewhen to offload [3ndash10] but most of them depend on constantprofiling of metrics which imposes the use of local resourcesthat should be avoided Besides that the decision-makingprocesses may also use computationally costly tasks whichshould preferably be executed outside the mobile device

Another important aspect in offloading systems is thesupport for usersrsquo mobility Mobility is one of themost impor-tant characteristics of a pervasive computing environmentand is defined as the ability of mobile nodes to seamlesslycontinue their work regardless of their displacements [11]Many obstacles hinder the goals of seamless connectivity andconsistency in mobile applications services [12] As a result

HindawiWireless Communications and Mobile ComputingVolume 2019 Article ID 1975312 18 pageshttpsdoiorg10115520191975312

2 Wireless Communications and Mobile Computing

Public Cloud

Internet BroadbandOffloadingInternet (3G 4G)WiFi

Vertical handover

Horizontal handover

Vertical handover

Cloudlet 1 Cloudlet 2

App1

App1

App2

App2

Figure 1 Supported scenario hybrid environment composed of cloudlets and public cloud instances

providing seamless connectivity and uninterrupted access tothose services is a serious research issue for MCC mainlybecause the execution of a mobile application may be highlycontext-dependent which means that several metrics suchas availability of network and localremote resources impactat runtime [13]

In previous works [14 15] we introduced amethod-basedmultiplatform offloading system developed in our researchgroup and a decision tree-based approach for assisting theoffloading decision on MCC systems Herein we face someof the challenges of MCC and related computing paradigms(eg Fog Computing and Fog of Everything [16]) such ashandling adaptive energy-efficient reconfiguration reducingcomputing-plus-communication delay and service latencyand supporting devices mobility To do that we extend ouroffloading framework in three ways (i) to adopt a lightweightoffloading decision module where the high intensive oper-ations related to decision-making are executed outside themobile device (ii) to leverage an adaptive monitoring systemto reduce the burden of metrics monitoring and (iii) toprovide seamless connectivity to mobile applications in ahybrid environment composed of public cloud and cloudlets

Our enhanced framework leverages machine learn-ing and software-defined networking techniques to handleoffloading decision and to provide mobility support Severalexperiments were conducted to evaluate the three aspects ofthe proposed solution

The rest of the paper is structured as follows FirstSection 2 describes the proposed solution and Section 3presents details and results of the experiments performed toevaluate the work Section 4 discusses related work FinallySection 5 presents conclusion and future work

2 Enhanced Offloading System

Existing offloading frameworks have motivated us to developan offloading solution [17] in which the decisions of when

and where to offload are not performed exclusively onmobiledevices Also the lack of mobility support when a hybridscenario is considered and the overhead caused by periodiccontext information gathering have also motivated this workIn the face of such problems herein we introduce novelsolutions to handle offloading decisions perform adaptivemonitoring and support usersrsquo mobility

We present Figure 1 to clarify the scenario supportedby this work As illustrated our solution considers mobiledevices and two types of remote servers (cloudlets and publiccloud instances) where one or more mobile devices can usethe same remote server We assume that mobile devices andcloudlets are connected to the same Wi-Fi access point (ieone-hop away) or to a group of access points (when WLANcontrollers are used) while mobile devices can connectto public cloud instances via Internet using either cellularnetwork (eg 3G or 4G) or Wi-Fi hotspots

Regarding usersrsquo mobility the solution supports (i) hor-izontal handover when a user moves from one cloudlet toanother and (ii) vertical handover when the user moves froma cloudlet to public cloud or from public cloud to a cloudlet

The proposed offloading system was built upon threesolutions the MpOS framework [3 14] the OpenStackplatform and seamless cloud (SLC) API [18] MpOS is anoffloading framework for Android and Windows Phonewhere mobile applications are composed of a set of methodswhich can be marked by developers using the RemotableJava annotation As presented in Listing 1 the methodsapplyEffect1 and applyEffect2 are marked in lines (2)and (4) as candidates to be offloaded

OpenStack is an open source cloud computing platformthat we use to run remote servers (cloudlets and public cloudinstances) and SLC is an abstraction to facilitate secure andseamless interconnection of distributed clouds One can usethe SLC API to perform CRUD operations (ie create readupdate and delete) on cloud resources programmaticallywhich means resources under control of multiple cloud

Wireless Communications and Mobile Computing 3

(1) public interface Effect (2) Remotable(3) public byte[ ] applyEffect1(byte source[ ])(4) Remotable(5) public byte[ ] applyEffect2(byte source[ ])(6) (7) public class ImageEffect implements Filter (8) public byte[ ] applyEffect1(byte source[ ]) (9) public byte[ ] applyEffect2(byte source[ ]) (10) Listing 1 Example of the Remotable markup

Mobile Application Remote Execution Environment (REE)

Offloading System Framework (RPC Server)Application Service

(RPC Server)Application Service

Discovery and Deployment ServiceDeployment ServiceAuthentication Service Discovery and

Authentication Service

Mobile Device Remote Server (CloudletPublic Cloud)

Mobile Platform (Android) Virtual Machine Operating System

Monitoring Service Monitoring Service

REE Handler

Decision Enforcer

DataHistorical

Mobility ManagerProxyOffloading Service

Offloading DecisionEngine

OpenStack andSeamlessCloud Agent

Offloading Dispatcher

Offloading System Server

Figure 2 Overview of the new architecture components

controllers can be seen as one seamless cloud instancealthough resources are widely distributed on multiple cloudsand geographical locations

As in the MpOS framework mobile devices are clientsand access services executed on remote servers Figure 2presents an overview of the proposed offloading systemarchitecture In the following subsectionswe present themostimportant components and details of the offloading decisionapproach the adaptive monitoring service and the schemefor providing mobility support

21 Handling Offloading The Offloading Service is respon-sible for intercepting all methods that are marked with theRemotable Java Annotations The service uses the DecisionEnforcer to make the offloading decision based on a two-classdecision tree that is created on the remote serverTheDecisionEnforcer uses the monitoring information provided by theMonitoring Service to parse the decision tree and decide atruntime where the methods must be executed (eg locallyon mobile device or on remote server) When a method isoffloaded the Offloading Dispatcher acting as a reverse proxyreceives the offloading request and distributes it to a properApplication Services even when such service is running in adifferent REE (in a different geographical location)

Then the Application Service component receives themethodrsquos arguments executes the method and sends the

result back to the mobile device which can continue theapplication execution flow The Historical Data is a databasethat stores details of all executed methods such as applicationand method names the size of arguments and result anduploaddownload rate during the offloading beyond othermetrics

The role of the Offloading Decision Engine is to usethe history offloading and profiling information (monitoringdata) to create an offloading decision tree for each applicationand user The Offloading Decision Engine is also responsiblefor asynchronously sending the decision tree to the mobiledevice when a different tree is created (eg when the offload-ing decision is affected by changes in network condition orremote server workload)

The Monitoring Service collects information regardingseveral software hardware and network metrics which arelisted in Table 1 Such metrics are important to decidewhether a method must be offloaded or not However con-tinuous monitoring can profoundly impact the consumptionof mobile devices resources To handle this problem weintroduce an adaptive monitoring service in which onlythe metrics actually ldquorelevantrdquo to the offloading decision arecontinuously monitored

211 System Model The computation offloading techniquedoes not always increase performance [3ndash5] Kumar et al


Table 1 Metrics monitored by the monitoring service

MetricsSoftware heap size local execution time remote execution time queue timeHardware available memory processor type and number of coresNetwork connection type RTT jitter upload and download rate wireless RSS

Table 2 Model notation

Symbol Description119864119897119900119888119886119897119898 Time to execute the method119898 on mobile device (seconds)119878119864119898 Time to serializeencrypt input data of method119898 (seconds)119863119863119898 Time to deserializedecrypt output data of method119898 (seconds)119880119898 Time to transfer the method119898 (upload) (seconds)119863119898 Time to transfer the method119898 (download) (seconds)119864119903119904119898 Time to execute the method119898 on remote server 119903119904 (seconds)lowast119876119903119904 Queue waiting time on remote server 119903119904 (seconds)lowast119868119898 Size of the input data of the method119898 (bytes)119874119898 Size of the output data of the method119898 (bytes)119879119906119901 Upload rate of the network in use (bytessecond)119879119889119900 Download rate of the network in use (bytesseconds)lowastNote 119903119904might be 119888119897119900119906119889119897119890119905 or 119888119897119900119906119889

[19] present an analytical model to answer the question ofwhenoffloading improves the performance ofmobile devicesThemodel decides when to offload by comparing the time toexecute the computation on the mobile device with the timerequired to execute the computation on the remote serverplus the time to transfer the data tofrom such server

In [15] we have extended Kumar et al by considering (i)methods as the offloading units and (ii) other aspects relatedto the execution of the method outside the mobile devicesuch as encryptiondecryption time and queue waiting timeon remote server Herein we discuss the model inmore detail(Table 2 presents the notation for easy reference)119860 denotes the mobile application and119872119860 = 119898119896 (1 le 119896)the set of methods of the application 119860 that can be offloadedLet 119864119897119900119888119886119897119898119896 be the time to execute the method 119898119896 on themobile device and 119864119903119904119898119896 the time to execute the method 119898119896on the remote server

If a method is offloaded to a remote server we have toconsider the time to upload the input data 119868119898119896 of method 119898119896to the server as

119880119898119896 = 119868119898119896119879119906119901 (1)

and the time to download the output data 119874119898119896 of method119898119896from the server as

119863119898119896 = 119874119898119896119879119889119900 (2)

Besides that 119878119864119898119896 denotes the time to serializeencryptthe input data of the method 119898119896 and 119863119863119898119896 denotes thetime to deserializedecrypt the output data of the method119898119896 while 119876119903119904 denotes the queueing time on the remoteserver (ie delay before beginning the computation) which

is variable and depends on the remote server workloadHence by extending the inequality ofKumar et al offloadingimproves performance when (3) is satisfied (as illustrated inFigure 3(a))

119864119897119900119888119886119897119898119896 gt 119878119864119898k + 119880119898119896 + 119876119903119904 + 119864119903119904119898119896 + 119863119898119896 + 119863119863119898119896 (3)

To decide where to offload we consider two scenarios

(i) The mobile device using 3G4G since there is nocloudlet the only option is to perform offloading tothe public cloud

(ii) The mobile device using Wi-Fi when cloudlet andpublic cloud are available the mobile device sendsits offloading requests to the cloudlet which has todecide where to execute the method locally on thecloudlet or the public cloud (the same idea of (3))

119864119888119897119900119906119889119897119890119905119898119896 + 119876119888119897119900119906119889119897119890119905 gt 119880119898119896 + 119876119888119897119900119906119889 + 119864119888119897119900119906119889119898119896+ 119863119898119896 (4)

If (4) is satisfied the method must be executed on thepublic cloud (as illustrated in Figure 3(b)) Otherwise itmust be executed on the cloudlet Unlike (3) we considerthe waiting time on both remote execution environmentsand we disregard encryption and decryption times becausethe connection between REEs must be secure Thereforedepending on the queue waiting time 119876119903119904 of each REE andthe network condition between cloudlet and public cloud thesystem may offload the methods to different REE

Mathematical models similar to ours have been used forsimulation in the literature [20] where a method can be rep-resented as a number of instructions to be executed and thecomputational power of mobile devices and remote servers


Remote Server

Mobile Device

Time

performance gainOffloading

Umk Dmk

Elocalmk

SEmk DDmk

QrsErsmk

(a) Equation (3) When to offload

Cloudlet

Public Cloud Time

Performancegain

Qcloudlet Ecloudletmk

Umk Dmk

Qcloud Ecloudmk

(b) Equation (4) Where to offload

Figure 3 Parameters that comprise the decisions of when and where to offload

(1) 119860V119890119903119886119892119890119868 larr997888 Average 119868119898 for all method119898 isin 119872119860(2) 119860V119890119903119886119892119890119874 larr997888 Average 119874119898 for all method119898 isin 119872119860(3) if 119876119888119897119900119906119889119897119890119905 gt 119860V119890119903119886119892119890119868119879119906119901 + 119876119888119897119900119906119889 + 119860V119890119903119886119892119890119874119879119889119900 then(4) return ldquopublic cloudrdquo(5) else(6) return ldquocloudletrdquo(7) end if

Algorithm 1 Procedure for selecting the main REE for the application 119860 of user119880

can be represented based on MIPS (millions of instructionsper second) In contrast to simulated environments calculat-ing 119864119897119900119888119886119897119898 and 119864119903119904119898 in real systems is challenging That iswhy our solution relies on online profiling and historical datato estimate such values

Among other metrics theMonitoring Service stores in theHistorical Data database the context of themobile device (eg119879119906119901 119879119889119900 119864119897119900119888119886119897119898 119864119903119904119898 and 119876119903119904) when a method is executedand information about the method itself (eg 119868119898 and 119874119898)

In [15] we presented all details regarding the experimentperformed to validate the model and show how well ourmodel represents the offloading process previously described

212 Decision Tree Creation Process Thefirst step to creatinga decision tree is to define the main REE (cloudlet or publiccloud) Such remote server selection is a step prior to decidingwhen to perform computation offloading Nevertheless inthis paper we consider that there is only one remote serveravailable or the server was randomlypreviously selected Infact when multiple remote servers are considered one canuse 0-1 integer linear programming to model and solve theproblem

Once the main REE is defined we use the heuristicpresented in Algorithm 1 The idea is to simplify (4) byconsidering that 119864119879119888119897119900119906119889119897119890119905 = 119864119879119888119897119900119906119889 In fact our experimentshave shown that public cloud instances are usually less or aspowerful as cloudlets therefore the waiting time and timespent transferring the data (which includesRTT) are themostrelevant metrics for deciding where to offload Thereforewe consider the average size of input and output data of alloffloaded methods of the same application

Once the remote server is known the Offloading Deci-sion Engine uses inequation (3) and the metrics estimatedvalues to classify each instance of the historical data betweentwo classes local and remote Such labeled data is used asthe training set for creating the offloading decision tree thatwill assist the Decision Enforcer in the offloading decisionSince a decision tree learns from the given data set thenumber of instances in the training data set may impactthe decision tree generalization and prediction accuracyTherefore before creating the decision tree our algorithmanalyzes the historical data and considers different networkconditions to create new instances for the training data setIn Algorithm 2 we present the pseudocode of the algorithmdeveloped to handle the data and to create the decision tree

The CollectDataprocedure (line (1)) gets the data froma database ClassifyInstance (lines (4) (9) and (13))classifies an instance as 119897119900119888119886119897 or 119903119890119898119900119905119890 based on inequality(3) In line (5) we duplicate the instance to use differentnetwork conditions Thus when the instance is classifiedas 119897119900119888a119897 we check whether the classification would changewhen improving upload and download rates (lines (7) and(8)) Otherwise when the instance is classified as 119903119890119898119900119905119890we check whether the classification would be the sameeven when the network condition gets worse (lines (11) and(12)) Depending on the impact of the network condition onclassification we add both or only one instance to the trainingdata set (lines (15) to (19)) Then the CreateDecisionTreeprocedure (line (21)) creates a C45 decision tree [21] In thecurrent implementation we use the J48 algorithm of the JavaWeka library (Weka httpwwwcswaikatoacnzmlweka)

It is important to highlight that a decision tree createdfor a specific pair of mobile device and remote server may


(1) 119863119886119905119886119878119890119905 larr997888 119862119900119897119897119890119888119905119863119886119905119886(119880 119860)(2) 119879119903119886119894119899119894119899119892119878119890119905 larr997888 0(3) for all 119894119899119904119905119886119899119888119890 119868 isin 119863119886119905119886119878119890119905 do(4) 119868119888119897119886119904119904 larr997888 119862119897119886119904119904119894119891119910119868119899119904119905119886119899119888119890(119868)(5) 119873 larr997888 119868(6) if 119868119888119897119886119904119904 = 119897119900119888119886119897 then(7) 119873119906119901119897119900119886119889 larr997888 2 times 119873119906119901119897119900119886119889(8) 119873119889119900119908119899119897119900119886119889 larr997888 2 times 119873119889119900119908119899119897119900119886119889(9) 119873119888119897119886119904119904 larr997888 119862119897119886119904119904119894119891119910119868119899119904119905119886119899119888119890(119873)(10) else

(11) 119873119906119901119897119900119886119889 larr997888 1198731199061199011198971199001198861198892

(12) 119873119889119900119908119899119897119900119886119889 larr997888 1198731198891199001199081198991198971199001198861198892(13) 119873119888119897119886119904119904 larr997888 119862119897119886119904119904119894119891119910119868119899119904119905119886119899119888119890(119873)(14) end if(15) if 119868119888119897119886119904119904 = 119873119888119897119886119904119904 then(16) 119879119903119886119894119899119894119899119892119878119890119905 larr997888 119873(17) else(18) 119879119903119886119894119899119894119899119892119878e119905 larr997888 119868119873(19) end if(20) end for(21) 119863119890119888119894119904119894119900119899119879119903119890119890119880119860larr997888 119862119903119890119886119905119890119863119890119888119894119904119894119900119899119879119903119890119890(119879119903119886119894119899119894119899119892119878119890119905)

Algorithm 2 Procedure for creating a decision tree of an application 119860 and a user119880

not be suitable for a different mobile device or remote serversince any change in 119864119897119900119888119886119897119898 or 119864119903119904119898 can affect the result ofinequality (3) and therefore the decision tree created

22 Handling Adaptive Monitoring The algorithm used forbuilding a C45 decision tree uses a top-down greedy searchthrough the space of possible trees [21] An important phaseof the algorithm is the tree building in which the decisionmodel is built by making locally optimal decisions aboutwhich attribute to use for partitioning the data Then the treegrows in a recursive fashion by partitioning the training setinto successively purer subsets

The central choice in decision tree algorithms is selectingwhich attribute is most useful for classifying the data Thereare many measures that can be used to determine the bestattribute on which to split the data The C45 algorithm usesa statistical property derived from information theory calledinformation gain that measures how well a given attributeseparates the training instances according to their targetclassification

The information gain 119866119886119894119899(119860 119878) of an attribute 119860relative to a data set 119878 is

119866119886119894119899 (119860 119878) = 119864119899119905 (119878) minus sumVisin119860

(1003816100381610038161003816119878V1003816100381610038161003816|119878| 119864119899119905 (119878V)) (5)

where V represents any possible values of attribute 119860 119878V is thesubset of 119878 for which attribute 119860 has value V (ie 119878V = 119904 isin 119878 |119860(119904) = V) and 119864119899119905(119878) represents the entropy of the data setS Entropy of any two-class (eg local and remote) data set119863is defined as

119864119899119905 (119863) = minus (119875119863119871) log2 (119875119863119871) minus (119875119863119877) log2 (119875119863119877) (6)

where119875119863119871 is the proportion of119863 belonging to class119871119900119888119886119897 and119875119863119877 is the proportion of119863 belonging to class 119877119890119898119900119905119890Our solution uses the concepts of entropy and infor-

mation gain to identify the most relevant metrics for theoffloading decision as the decision tree creation algorithm Indoing so we can dynamically adapt theMonitoring Service tomonitor only such metrics instead of monitoring all of them(like MpOS does) For instance considering the decisiontree depicted in Figure 4 the system only needs to monitorupload rate andRTTHence themobile device does notwasteresources monitoring download rate and other metrics atleast until a new decision tree is created The experimentspresented in Section 3 show how this innovative scheme canconserve the battery life of handsets

Figure 4 presents an example of an offloading decisiontree for a dummy application In this example if the uploadrate is equal to 200 Kbps and RTT is equal to 100 ms themethod Bar must be executed locally Moreover in all casesthe method Foomust be executed on the remote server

23 Handling Mobility In order to support mobile devicesmobility our system needs to interconnect geographicallydistributed remote servers therefore allowing all of them toreach each other The OpenStack and Seamless Cloud Agentis responsible for managing the OpenStack platform and theseamless cloud controller The component is the interfacebetween our solution and the underlying cloud and networkplatform

By managing the SLC controller our solution can seam-lessly and programmatically interconnect multiple cloudletsand public cloud instances by creating a secure overlaynetwork using IPSec over GRE tunnels SLC uses Ciscorsquos One


Dummy App

no

no

yes

Local Remote

RemoteRTT gt 50

yes

Upload lt 300 Remote

FooBar

Figure 4 Example of offloading decision tree

Platform Kit (onePK) or Network Configuration Protocol(NETCONF) to configure real or virtual equipment In ourcurrent implementation we use the SLCRESTAPI to interactwith the SLC controller which leverages the NETCONFprotocol to configure virtual routers (Cisco CSR 1000V)and interconnect different sites by creating a seamless net-work which enables our system to migrate applications andoffloaded computations between distributed remote serversin order to follow users displacements

The REE Handler is the component responsible formanaging the endpoint of the REE being used by the mobileapplication When the mobile device leaves or enters acloudlet coverage area the endpoint is updated According tothe type of handover the new endpoint points to a differentcloudlet or public cloud

TheMobilityManager is the component that detects whena mobile device enters or leaves a cloudlet coverage areaIn these situations the component triggers the migration ofoffloaded methods as well as the entire application when theApplication Service related to the mobile application is notyet deployed and running on the destination cloud

The Mobility Manager uses the Cisco wireless locationservices (CiscoMSE (httpwwwciscocomcenusproductswirelessmobility-services-engineindexhtml) andCiscoCMX(httpsdeveloperciscocomsitecmx-mobility-services))tomonitor the location of mobile devices In a nutshell CiscoMSE collects discrete time location and MAC address ofevery device detected within the coverage area of networkaccess points even when mobile devices are not connectedto the WLAN Once a significant amount of data is collectedCisco CMX assembles observations into a set of time-ordered points per device and processes data with movementanalytics algorithms Hence we leverage the REST APIexposed by Cisco MSE to track usersrsquo location

Figure 5 presents a view of the components in a geo-graphically distributed scenario In the illustrated scenariothe SLC controller is executed in the public cloud and isused to configure all virtual routers Once the seamless cloud

network is configured the Mobility Manager can use CiscoMSE to handle vertical and horizontal handovers

3 Evaluation

This section presents the experiments performed to evaluatethe proposed offloading solution The experiments wereplanned to assess (i) the performance of mobile applicationswhen using the proposed offloading solution under differentscenarios (ii) the impact of using decision trees in thedecision module (iii) the impact of using the adaptivemonitoring service in the energy consumption of mobiledevices and (iv) the userrsquos mobility support in scenarioscomposed of multiple cloudlets and public cloud

31 Experiment 1 UsingDecisionTrees in the DecisionModuleThe objective of this experiment is to evaluate the impactof leveraging decision trees in the decision module of theproposed solution The experiment aims to calculate thetime needed to create decision trees in remote servers whenvarying the amount of historical data and number of clientsand also the time required to parse decision trees on mobiledevices when changing the tree height

We consider a scenario composed of two remote serversand two mobile devices which are described in Table 3

311 Experiment 11 The Impact of the Decision Tree CreationIn order to assess the overhead of creating decision trees onremote servers we developed a Java program that measuresthe time required to create trees under different conditionsWe executed the experiment on two remote servers (acloudlet and a public cloud instance) considering a variablenumber of clients (1 2 5 and 10) and historical records (10100 1000 10000 and 100000) The experiment was repeated30 times for each client to all possible combinations of remoteserver and amount of historical records

Figure 6 presents the results of the experiment the meantime for creating decision trees with 95 confidence intervalAs we can see the process of creating decision trees dependson the amount of historical records used When the trainingdata set is composed of 1000 or fewer historical recordsthe time needed to create decision trees is less than 25 mseven when ten concurrent clients are considered The timerequired for creating decision trees exceeds 1 second onlywhen the largest training data set is used (100000 historicalrecords) reaching approximately 25 seconds when decisiontrees for ten concurrent clients are created on the cloudletremote server The results also show that in most cases thetime for creating decision trees on the cloud remote server isshorter than on the cloudlet

This experiment indicates that the decision tree creationprocess is fast and lightweight Even when ten concurrentclients are considered remote servers with standard comput-ing resources performed well with large data sets

312 Experiment 12 The Impact of the Decision Tree ParsingIn order to assess the overhead of handling decision trees onmobile devices we developed an Android application thatmeasures the time required to deserialize and parse decision


Cloudlet 1Cloudlet 2

CMX APICMX API

Public Cloud

Virtual Router

Virtual RouterVirtual Router

DataHistorical

DataHistoricalData

Historical

Mobility Manager

Cisco MSECisco MSE

Mobility ManagerMobility Manager

SLC Controller


Offloading System ServerOffloading System Server




Figure 5 Overview of the components related to the user mobility support

0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

10 records

0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

100 records

0

5

10

15

20

25

DT

Crea

tion

Tim

e (m

illise

cond

s)

1000 records

0

20

40

60

80

100

120

140

DT

Crea

tion

Tim

e (m

illise

cond

s)

1 client 2 clients 5 clients 10 clients

CloudCloudlet


Cloud


CloudCloudlet


CloudCloudlet


CloudCloudlet

Cloudlet

10000 records

0

500

1000

1500

2000

2500

DT

Crea

tion

Tim

e (m

illise

cond

s)

100000 records

Figure 6 Decision treesrsquo creation time (Experiment 11 results)

Table 3 Devicesrsquo configuration

Mobile Device Configuration

Handset A Android 51 4G capable 3 GB RAM and processor Qualcomm Snapdragon 808(18 GHz 6-core)

Handset B Android 412 768 MB RAM and processor QualcommMSM8225 Snapdragon (1GHz dual-core)

Cloudlet VM instance running on Laptop connected to a 80211bg network Ubuntu Server1404 2 VCPU 4 GB RAM

Public Cloud VM instance running on Cisco Intercloud Services (CIS) Amsterdam datacenterUbuntu Server 1404 general purpose medium instance (1 VCPU 4 GB RAM)


1 2 4 8Tree height

0

3

6

9

12

15

Proc

essin

g tim

e (m

illise

cond

s)

Handset A (deserialization)

Handset B (deserialization)Handset A (parsing)

Handset B (parsing)

Time to deserialize and parse the DT

Figure 7 Time needed to deserialize and parse decision trees(Experiment 12 result)

trees with different heights We executed the experiment ontwo mobile devices (handset A and handset B) consideringdifferent tree heights (1 2 4 and 8) The experiment wasrepeated 100 times for each combination ofmobile device andtree height

It is important to highlight that the deserialization processis executed only when the mobile device receives a decisiontree which is asynchronously sent from the remote serverwhile the parsing process is executed whenever a ldquoremotablerdquomethod is called

Figure 7 presents the mean time for deserializing andparsing decision trees with 95 confidence interval As wecan see regardless of the tree height deserialization andparsing times slightly vary Handset A takes approximately3 ms for deserializing decision trees while handset B takesabout 10 ms Now regarding the parsing time both handsetstake in average less than 1 ms to parse decision trees even forthe ones with the height equal to 8

These results are important to show how lightweightis to handle decision trees on mobile devices The pars-ing time is particularly relevant because the decision treeparsing process is executed whenever a ldquoremotablerdquo methodis called Thus we show that the idea of using decisiontrees to assist the offloading decision is not overloading thesystem

32 Experiment 2 Applications Performance When Offload-ing The objective of this experiment is to assess the per-formance of two applications when using the proposedoffloading solution under different scenariosThe experimentaims to calculate the execution time of methods when theyare executed locally on mobile devices and when they areexecuted on remote servers (ie when offloading)

As in Experiment 1 we used the mobile devices hand-set A and handset B and the remote servers cloudletand public cloud described in Table 3 And in addi-tion to the performance evaluation we used the Mon-soon power monitor (Monsoon power monitor websitehttpswwwmsooncomLabEquipmentPowerMonitor) to

measure the energy consumption of smartphones during theexperiment

Several types of applications have been used in theliterature to evaluate offloading solutions In this regard[22] performed a systematic mapping to catalog the mostcommonly used applications in mobile cloud computingresearch papersThe authors identified that image processingand mathematical tools are the categories of applicationsmost used which is consistent withwhat we have identified inour literature review Therefore we rely on such findings anduse the applications BenchImage and MatrixOperations Theformer is an image processing application that allows users toapply filters to pictures with different resolutions (8MP 4MP2 MP 1 MP and 03 MP) The application provides the filtersSharpen Cartoonizer and Red Tone which have differentcomputation requirements and therefore different executiontimes [3] The latter is an application to perform commonoperations with matrices such as addition andmultiplicationof matrices

Since the applications are different and have distinctconfiguration options we present details of the experimentsin separate subsections

321 Experiment 21 BenchImage We executed the Ben-chImage application on handset A and handset B Themethods Maptone and Cartoonizer were executed 30 timeslocally on smartphones and also offloaded to the cloudlet andpublic cloud remote servers with different picture resolutions(1 MP 2 MP 4 MP and 8 MP) Handset A used both Wi-Fiand 4G LTE to perform offloading to the public cloud whilehandset B used only Wi-Fi because the smartphone does notsupport 4G

Tables 4 and 5 present the mean execution time of themethods Maptone and Cartoonizer with 95 confidenceinterval for handsets A and B respectively As we can see inboth tables the best results are achieved when performingoffloading to the cloudlet In such a case handset A reducesthe execution time of the method Maptone approximately25 times while the method Cartoonizer is executed approx-imately 3 times faster when offloaded to the cloudlet (whenthe 8 MP picture is considered) When analyzing the resultsfor handset B we can see that the methods Maptone andCartoonizer are respectively executed approximately 5 and11 times faster when offloaded to the cloudlet (when the 8MPpicture is considered) The difference in results is due to thefact that handset B is less powerful than handset A

Since handset A is a powerful device we can see in Table 4that offloading to the cloud is not always worth it In otherwords it is better to execute the method locally dependingon the picture resolution and the connection being used (egwhen executing the method Maptone on cloud via 4G witha 2 MP picture or when executing the method Cartoonizeron cloud via Wi-Fi with a 1 MP picture) On the other handTable 5 shows that the performance of handset B is so poorthat performing offloading to the cloud using either 4G orWi-Fi always speeds up the method execution Thereforethis experiment reinforces the importance of the offloadingdecision which has to consider the context of mobile devicesamong other variables as discussed in Section 21


Table 4 Results of the BenchImage experiment for handset A

Execution time for different resolutions (seconds)Method Where 1 MP 2 MP 4 MP 8 MP

Maptone

Locally 124 plusmn 001 194 plusmn 0006 378 plusmn 0009 1074 plusmn 006Cloudlet 061 plusmn 001 104 plusmn 001 165 plusmn 001 415 plusmn 005Cloud (4G) 443 plusmn 007 633 plusmn 005 756 plusmn 023 1448 plusmn 028Cloud (Wi-Fi) 219 plusmn 004 315 plusmn 007 385 plusmn 012 745 plusmn 029

Cartoonizer


Table 5 Results of the BenchImage experiment for handset B


MaptoneLocally 521 plusmn 002 909 plusmn 005 1682 plusmn 001 3498 plusmn 003Cloudlet 084 plusmn 004 22 plusmn 014 269 plusmn 01 688 plusmn 018

Cloud (Wi-Fi) 336 plusmn 016 563 plusmn 04 746 plusmn 041 2478 plusmn 128Cartoonizer

Locally 1574 plusmn 001 2905 plusmn 001 5785 plusmn 02 11824 plusmn 05Cloudlet 143 plusmn 02 201 plusmn 008 35 plusmn 017 1066 plusmn 09

Cloud (Wi-Fi) 457 plusmn 023 619 plusmn 022 1075 plusmn 047 2794 plusmn 129

368

1017

1503

09631080911 0868

Locally Cloudlet Cloud (4G) Cloud (Wi-Fi)0

1

2

3

4

Pow

er (W

)

Handset AHandset B

Mobile devicesrsquo average power

Figure 8 Mobile devicesrsquo average power during the BenchImageexperiment

We used the power monitor to measure the energy con-sumption of smartphones during the experiment Figure 8shows the average power of handsets A and Bwhen executingthe methods on different locations As we can see for bothmobile devices the average energy consumedwhen amethodis executed locally is greater than when amethod is offloadedMoreover the average power consumed when handset A uses4G is greater than when it uses Wi-Fi

Using the average values presented in the figure wecan do a fair estimation of how much energy the mobiledevices consume when executing a method by multiplyingthe average power by the methodrsquos execution time Forinstance handset A consumes approximately 16J (368W times435s) when executing the method Cartoonizer locally for a 2MP picture while it consumes approximately 1211J (1503W

times 806s) when executing the same method with the samepicture on the cloud using 4G

322 Experiment 22 MatrixOperations We executed theMatrixOperations application on handset A and handset BThe methods Add and Multiply were executed locally onsmartphones and offloaded to the cloudlet and the publiccloud remote servers As in Experiment 21 handset A usedboth Wi-Fi and 4G LTE to perform offloading to the publiccloud while handset B used only Wi-Fi

We considered different dimensions for the matrices(200times200 400times400 600times600 800times800 and 1000times1000)during the experiment and eachmethodwas executed locallyas well as offloaded to remote servers being repeated 30 timesfor each combination of mobile device and dimensions of thematrices

Tables 6 and 7 present the mean execution time of themethods Add and Multiply with 95 confidence intervalfor handsets A and B respectively As we can see in bothtables the method Add is faster when executed locallybecause performing the addition of two matrices is a quitesimple operation On the other hand when the methodMultiply is considered the best results are achieved in mostcases when performing offloading to the cloudlet In facthandset B reduces the execution time of the methodMultiplyapproximately 9 times when the larger matrix dimension isconsidered (1000x1000)

Handset A also performs well when offloading to thecloudlet achieving a speedup of approximately 4 times whenthe larger matrix dimension is considered Nevertheless it isimportant to highlight two cases (1) it is faster to execute themultiplication locally when considering 200x200 matricesand (2) sometimes it is faster to perform offloading to the


Table 6 Result of the experiment execution time for different cases on handset A

Execution time for matrices with dimension 119899 times 119899 (seconds)Method Where 119899 = 200 119899 = 400 119899 = 600 119899 = 800 119899 = 1000

Add

Locally 0008 plusmn 0001 001 plusmn 0001 002 plusmn 0001 004 plusmn 0001 007 plusmn 0002Cloudlet 044 plusmn 002 140 plusmn 005 33 plusmn 01 539 plusmn 016 872 plusmn 025Cloud (4G) 397 plusmn 010 806 plusmn 025 1028 plusmn 025 1502 plusmn 041 2022 plusmn 055Cloud (Wi-Fi) 257 plusmn 006 515 plusmn 01 827 plusmn 059 983 plusmn 024 1299 plusmn 055

Multiply


Table 7 Result of the experiment execution time for different cases on handset B

Execution time for matrices with dimension 119899 times 119899 (seconds)Method Where 119899 = 200 119899 = 400 119899 = 600 119899 = 800 119899 = 1000Add

Locally 002 plusmn 0002 007 plusmn 0001 012 plusmn 0001 015 plusmn 0001 024 plusmn 0003Cloudlet 089 plusmn 008 195 plusmn 006 386 plusmn 023 676 plusmn 021 1107 plusmn 067

Cloud (Wi-Fi) 353 plusmn 012 1056 plusmn 063 1962 plusmn 116 3295 plusmn 22 5238 plusmn 286Multiply


Cloud (Wi-Fi) 367 plusmn 016 1026 plusmn 056 1763 plusmn 119 3599 plusmn 197 4872 plusmn 197

Cloudlet Cloud (Wi-Fi)Where the method was executed

0

5

10

15

20

25

Tim

e (se

cond

s)

Upload timeComputation timeDownload timeOthers

Execution time comparison

Figure 9 Execution time comparison of two observations ofhandset A

cloud using Wi-Fi than offloading to the cloudlet (eg whenthe larger matrix dimension is considered) Figure 9 helpsto explain the latter case by showing the main variablesthat compose the total offloading time for two observationscollected during the experiment As we can see the cloudoutperforms the cloudlet when comparing the computationtime of the matrix multiplication Thus despite the shortdownload and upload times when offloading to the cloudletit is better to perform offloading to the cloud These resultsreinforce how important the context of mobile devices is tothe offloading decision

We also used the power monitor to measure theenergy consumption of smartphones during this experimentAs in the last experiment to simplify and expedite the

4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B


Figure 10 Mobile devicesrsquo average power during the MatrixOpera-tions experiment

measurement we monitored the average power of mobiledevices during the MatrixOperations execution in bench-mark mode (ie during the 30 executions of the methodsAdd andMultiply for eachmatrix dimension)Thus Figure 10shows the average power of handsets A and Bwhen executingthe methods on different locations As we can see for handsetA the average energy consumed when a method is executedlocally is greater than when it is offloaded On the other handfor handset B the average energy consumed is greater whena method is executed on cloudlet

Using the average values presented in the figure we cando a fair estimation of how much energy the mobile devicesconsume when executing a method by multiplying theaverage power by the methodrsquos execution time For instancehandset A consumes approximately 205J (438W lowast 469s)when executing the method Multiply locally for 400x400


BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Cartoonizer

yes

Local

Local

Upload Rate lt= 8665 KBs


Input Size lt= 726252 bytes

(a) Handset A - cloud

BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local

Upload Rate gt 3580 KBs



(b) Handset B - cloud

Remote

BenchImage

(c) Handsets Aand B - cloudlet

Figure 11 Decision trees created for handsets A and B when connected to the cloud or the cloudlet

matrices while it consumes approximately 125J (158W lowast796s) when executing the same method for the same matrixdimension on the cloud using 4G

33 Experiment 3 Adaptive Monitoring Service EvaluationThe objective of this experiment is to assess the impactof using the adaptive monitoring service in the energyconsumption of mobile devices The experiment aims tocompare the energy consumed by mobile devices when theyare using or not the adaptive monitoring service

To perform the experiment we launched the BenchImageapplication onhandsetA and handset B (described inTable 3)with different configurations for the adaptive monitoringservice (enabled and disabled) and we considered that theapplication could connect to the remote servers cloudlet orpublic cloud Then we used the Monsoon power monitorto measure the energy consumption of the mobile devicesfor 100 seconds while they were running the BenchImageapplication

This experiment was performed after Experiment 2 sothe remote servers created decision trees based on the offload-ing historical records and the trees were asynchronouslysent to mobile devices It is also important to highlightthat no method was executed on mobile devices duringthe measurement to avoid affecting the results Thus inall experiments the power values were taken with thescreen on 50 display brightness Bluetooth disabled min-imal background application activity and no foregroundactivity

Figure 11 presents the offloading decision trees createdfor the BenchImage application when handsets A and B areconnected to the cloudlet and public cloud remote serversAs we can see when both mobile devices are using thecloudlet regardless of the handset context all methods mustbe offloaded (Figure 11(c)) which is a quite straightforwardoffloading decision On the other hand when mobile devicesare using the cloud the created offloading decision trees aremore complex depending on the metrics method nameupload rate and methodrsquos input size

When the adaptive monitoring service is disabled theoffloading framework monitors several metrics such asupload rate download rate latency and wireless RSS Incontrast when the adaptive monitoring service is enabledthe decision tree is used to define which metrics must bemonitored since the idea is to monitor only the metricsrelevant to the offloading decision For this experiment theMonitoring Service is configured to measure each metricevery 30 seconds

Figure 12 compares the power consumption variationof handsets A and B during the experiment for each sce-nario (adaptivemonitoring disabled and adaptivemonitoringenabled with the mobile device connected to the cloudletand public cloud remote servers) As we can see when theadaptive monitoring service is disabled both mobile devicesconsume more energy In turn the best case scenario iswhen the adaptive monitoring is enabled and mobile devicesare connected to the cloudlet because according to thedecision trees presented in Figure 11(c) no metric needs tobe monitored

Figure 13 presents the total energy consumed by mobiledevices during the experiment When the adaptive monitor-ing service is disabled handset A consumes approximately2 times more energy than when the adaptive monitoringservice is enabled while handset B consumes approximately80 more energy In turn when the adaptive monitoringservice is enabled the difference in energy consumptionreaches 10 when comparing mobile devices connectedto the cloud and cloudlet In such a case the differ-ence is caused by the overhead of monitoring the metricupload rate which is a metric relevant to the offload-ing decision when mobile devices are connected to thecloud

As a result since the offloading framework only needsto monitor the relevant metrics for the offloading decisionwe can reduce the overhead of monitoring the entire systemand consequently reduce the energy consumption of mobiledevices


Experiment duration (seconds)

0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)

AM DisabledAM CloudAM Cloudlet

Handset A power consumption over time

(a) Handset A

10 20 30 40 50 60 70 80 90 100Experiment duration (seconds)

05

1

15

2

Aver

age p

ower

(W)


Handset B power consumption over time

(b) Handset B

Figure 12 Mobile devicesrsquo power consumption during the experiment AM Disabled adaptive monitoring disabled AM cloudlet handsetconnected to the cloudlet and adaptive monitoring enabled AM cloud handset connected to the cloud and adaptive monitoring enabled

14596

10513

78716486

72895846

Handset A Handset B0

40

80

120

160

Ener

gy (J

)


Mobile devicesrsquo energy consumption

Figure 13 Result of the experiment mobile devicesrsquo energy con-sumption

34 Experiment 4 Mobility Support The objective of thisexperiment is to evaluate the proposed solution for support-ing usersrsquo mobility in hybrid scenarios composed of multiplecloudlets and public cloud We used an application calledCameraOffloading which allows a user to take a picture andapply filters called Effect 1 Effect 2 and Effect 3 to the picturetaken

This experiment was performed in a testbed configuredin the Cisco campus at San Jose California United StatesThis testbed leverages the Cisco wireless network and iscomposed of two cloudlets and a public cloud instancerunning in a Cisco datacenter at Amsterdam NetherlandsThe configuration of the mobile device and remote serversused is presented in Table 8

The filters were applied in 24 MP pictures taken duringa walk across the Cisco campus Figure 14 shows the map of

the campus detailing the path taken during the walk and thelocations where the pictures were taken Depending on thelocation handset C used Wi-Fi or 3G to perform offloadingrespectively to cloudlets and public cloud

Figure 15 presents a graph with the total execution timeof the methods executed during the experiment Naturallythe execution time when we perform offloading to thepublic cloud is longer than when we use cloudlets Butas expected the framework handled userrsquos displacementsand the execution flow of the mobile application was notaffected despite the changes in the REE endpoint which weretransparent to the user

4 Related Work

In the last few years several studies have been developedin response to the challenges offered by MCC [3ndash10] andwith them different approaches for performing computationoffloading of mobile applications were proposed MpOS [3]MAUI [4] ThinkAir [5] MobiCOP [8] Foreseer [9] andCSOS [10] usemethods as offloading units whileCloneCloud[6] and EMCO [7] migrate threads to a remote serverSince our solution extends MpOS we also work at methodgranularity

Regarding the offloading decision MobiCOP ThinkAirand MpOS execute all operations related to the decision onthe mobile device On the other hand CloneCloud MAUIEMCO and CSOS are some of the few works that executethe complex operations of the decision component outsidethe mobile device Since the overall idea is to offload dataand computation from mobile devices to remote servers itseems reasonable to avoid storing profiling information andtraces of offloaded tasks on mobile devices Besides that wecan leverage a cloudcloudlet to store such data as well as toperform the compute-intensive tasks related to the offloadingdecision


CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13

Figure 14 Map of the Cisco campus testbed that was used in the vertical handover experimentThe path starts in the green user symbol (inbuilding SJC-15) and ends in the red user symbol (in building SJC-13) The yellow circles indicate the coverage area of cloudlets

Table 8 Configuration of the equipment used in the vertical handover experiment

Equipment Description

Cloudlet SJC-15 VM instance running on Laptop connected to a 80211bgn network UbuntuServer 1404 4 VCPUs 4 GB RAM

Cloudlet SJC-13 VM instance running on an Intel MiniPC connected to a wired network UbuntuServer 1404 2 VCPUs 2 GB RAM


Handset C Android 410 1 GB RAM and processor ARM Cortex A9 (1 GHz dual-core)

Methodsrsquo execution time

130

1) Effect 3 2) Effect 3

Cloudlet SJC-15 Cloudlet SJC-13Public Cloud

3) Effect 2 4) Effect 1 5) Effect 3 6) Effect 1

Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602

Figure 15 Result of the experiment execution time ofmethodswithvertical handover

Some solutions such as CloneCloud and CSOS rely onan offline phase in order to train the decision algorithm InCloneCloud during the development phase developers mustcollect traces of the application being executed under differ-ent network and hardware conditions to create a database ofpossible ways to partition the application Once the tracesare collected CloneCloud solves a standard integer linear

problem to decide which precomputed partition must beoffloaded

In CSOS the developer must run offline experiments togenerate a data set of executions that will be used to trainclassifiers models which must be included in the applicationin order to enable the offloading system to decide at runtimewhen to offload The offline training process is a burden forthe developer and generates amodel that is heavily dependenton the offline experiment context (eg handsets and remoteservers used network condition) In our solution remoteservers create a unique decision tree for each mobile devicebased on its profiling data

MAUI and EMCO are more similar to our proposalMAUI solves a 0-1 integer linear programming problem onthe remote server to decide where each method must beexecuted and periodically updates themobile device partitioninformation Since MAUIrsquos objective is to save energy thesolution depends on mechanisms to identify the energyconsumption of each method On the other hand EMCOproposes the use of a fuzzy logic system to aggregate theprofiling metrics and use historical data for building onthe remote server an inference system that can be used bythe mobile device to classify where the threads must beexecuted


Foreseer [9] is one of the few works that investi-gates the overhead caused by frequently measuring metricssuch as upload and download rate of a mobile deviceTo reduce the data transmission and battery consumptioncaused by profiling operations the authors exploit crowd-sourcing to collect the users trajectories and bandwidth intheir locations and learn the probabilistic model of net-work bandwidth conditioned on the location Foreseer thendynamically decides when to offload based on the networkstatus

As shown by related works historical data can be usedto improve the offloading decision especially by using classi-fication mechanisms In this regard our solution innovatesby leveraging decision trees to instrument the offloadingdecision of when eachmethodmust be offloaded In additionto the best of our knowledge the idea of using an adaptivemonitoring scheme to monitor only the metrics that arerelevant to the offloading decision is unique and saves energyprolonging the battery life of mobile devices

Regarding the mobility support few solutions haveaddressed the offloading continuity when users are movingin a hybrid environment composed of cloudlets and publiccloud instances The authors of [23] propose a solution thatconsiders usersrsquo mobility when deciding where to performoffloading The decision module is executed on mobiledevices which receive periodical information regarding allavailable servers and communication latency and defineswhere to offload based on received information In orderto handle server transitions the origin server where theuser was previously connected sends results of existingcomputations to the destination server which forwardsresults to the mobile device The solution only considersmobility between public clouds not considering hybridenvironments

In [24] the authors propose a system architecture com-posed of three remote execution environments (cloudcloudlet and other mobile devices) The solution provides amulticriteria offloading decision algorithm to select where tooffload tasks and a handover strategy to move offloaded tasksbetweenREEs aiming to reduce energy consumptionMobiledevices execute offloading decisions and the solution assumesthat all resources can connect each other Besides that thesolution considers that applications are already running onall resourcesThis is one of the fewworks that considers userrsquosmobility between cloudlets and public cloud

The authors of [20] also use public cloud and cloudletsas REEs They propose an architecture based on ThinkAirand an offloading algorithm that aims to decide whether toperform offloading to clones running in a public cloud ora cloudlet The offloading decision takes into considerationthe energy consumption for offloaded methods and networkcontext while satisfying certain response time constraintsBesides the solution considers usersrsquo disconnection and han-dles usersrsquo mobility by migrating data between public cloudsand cloudlets Nevertheless it is not clear how the proposedmechanism will be implemented in practice since authorsimplemented the solution using the simulator CloudSim[25] which is not properly designed to simulate networkevents

MOSys [26] supports userrsquos mobility while compute-intensive methods are offloaded to a cloudletcloud Thesolution is based on MpOS and leverages OpenFlow rulesto seamlessly switch ongoing sessions when a mobile devicemoves between access points Besides the authors use datacaching to improve offloading performance The solutiononly considers mobility between access points in a cloudlet-based scenario not considering hybrid environments com-posed of multiple cloudlets and public cloud where users canoffload to any of the remote execution environments usingWi-Fi or mobile networks (eg 3G or 4G)

Current computational offloading techniques are sub-ject to several challenges inherent to wireless networksand mobile devices mobility such as network disruptionlatency and packet loss In the face of such challenges ouroffloading framework leverages network programmability tointerconnect geographically distributed cloudlets and publiccloud instances in order to handle users mobility Table 9summarizes the comparison to the aforementioned relatedworks We highlight six features to differentiate the worksoffloading granularity offline training dependency decisionmodule location type of profiling usedmobility support andscenario supported

5 Conclusion and Future Work

This paper presented novel approaches for handling theoffloading decision performing adaptive monitoring andsupporting usersrsquo mobility on mobile cloud computing sys-tems We introduced a mathematical model and algorithmsthat leverage profiling information and historical data tocreate decision trees for assisting the offloading decision Dif-ferent from related works all compute-intensive operationsrelated to the creation of a decision tree are performed onremote servers while mobile devices only have to parse thetree to make a decision The results of the experiments showthat the decision tree creation process on remote servers isfast and lightweight as well as the process of parsing decisiontrees on mobile devices

Also we develop a solution to reduce the burdenof monitoring the metrics related to the offloading deci-sion by using statistical concepts of information gain andentropy The experiments showed that in some cases itis possible to reduce the energy consumption of a mobiledevice up to 50 when the adaptive monitoring service isenabled

Finally we implemented a scheme to handle usersrsquo mobil-ity in a scenario composed of multiple cloudlets and publiccloud instances where users can perform horizontal andvertical handovers The experiments show that the proposedsolution supports the most variate scenarios of userrsquosmobilityand can perform offloading to different remote serverstransparently to the user while maintaining the correctexecution flow of the mobile application without interferingwith the userrsquos decisions and displacements

As the next steps of our research we intend to investigatethe scalability of remote servers for mobile cloud computingapplications and the use of crowdsensing techniques toimprove the offloading decision


Table9Comparisontotherelatedworks

OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency

DecisionModuleLocation

TypeofMonitoring(Profiling)

MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No

RemoteServerandDevice

Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device

Allmetrics(Crowdsourcing)

No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes

CloudletsandPublicCloud

[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No


Relevantmetrics(Adaptive)

Yes



Data Availability

Applications and experimental data are available from thecorresponding author (Paulo Rego) upon request

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research is partially supported by the Brazilian NationalCouncil for Scientific and Technological Development(CNPq) under grant numbers 4772232012-5 and 2019862014-0 and by the Sao Paulo Research Foundation (FAPESP)under grant number 201524144-7 We would like to ac-knowledge Cisco Systems for the support provided duringthe first authorrsquos internship

References

[1] L Li X Zhang K Liu F Jiang and J Peng ldquoAn energy-awaretask offloading mechanism in multiuser mobile-edge cloudcomputingrdquo Mobile Information Systems vol 2018 Article ID7646705 12 pages 2018

[2] H T Dinh C Lee D Niyato and PWang ldquoA survey of mobilecloud computing Architecture applications and approachesrdquoWireless Communications andMobile Computing vol 13 no 18pp 1587ndash1611 2013

[3] P B Costa P A Rego L S Rocha F A Trinta and JN de Souza ldquoMpOS a multiplatform offloading systemrdquo inProceedings of the 30th Annual ACM Symposium on AppliedComputing (SAC rsquo15) pp 577ndash584 ACM Salamanca SpainApril 2015

[4] E Cuervoy A BalasubramanianD-K Cho et al ldquoMAUImak-ing smartphones last longer with code offloadrdquo in Proceedingsof the 8th Annual International Conference on Mobile SystemsApplications and Services (MobiSys rsquo10) pp 49ndash62 ACM NewYork NY USA June 2010

[5] S Kosta A Aucinas P Hui R Mortier and X ZhangldquoThinkair dynamic resource allocation and parallel executionin the cloud for mobile code offloadingrdquo in Proceedings of theIEEE INFOCOM pp 945ndash953 March 2012

[6] B-G Chun S Ihm P Maniatis M Naik and A PattildquoCloneCloud elastic execution between mobile device andcloudrdquo in Proceedings of the 6th ACM EuroSys Conference onComputer Systems (EuroSys rsquo11) pp 301ndash314 ACM New YorkNY USA April 2011

[7] H R Flores Macario and S Srirama ldquoAdaptive code offload-ing for mobile cloud applications Exploiting fuzzy sets andevidence-based learningrdquo in Proceeding of the 4th ACM Work-shop onMobile Cloud Computing and Services (MCS rsquo13) pp 9ndash16 ACM New York NY USA June 2013

[8] J I Benedetto G Valenzuela P Sanabria A Neyem J Navonand C Poellabauer ldquoMobiCOP a scalable and reliable mobilecode offloading solutionrdquoWireless Communications andMobileComputing vol 2018 Article ID 8715294 18 pages 2018

[9] L Yang J Cao S Tang D Han and N Suri ldquoRun time appli-cation repartitioning in dynamic mobile cloud environmentsrdquoIEEE Transactions on Cloud Computing vol 4 no 3 pp 336ndash348 2016

[10] W Junior E Oliveira A Santos and K Dias ldquoA context-sensitive offloading system using machine-learning classifica-tion algorithms for mobile cloud environmentrdquo Future Genera-tion Computer Systems vol 90 pp 503ndash520 2019

[11] N Fernando S W Loke and W Rahayu ldquoMobile cloudcomputing a surveyrdquo Future Generation Computer Systems vol29 no 1 pp 84ndash106 2013

[12] M Shiraz A Gani R H Khokhar and R Buyya ldquoA review ondistributed application processing frameworks in smart mobiledevices for mobile cloud computingrdquo IEEE CommunicationsSurveys amp Tutorials vol 15 no 3 pp 1294ndash1313 2013

[13] S Abolfazli Z Sanaei andAGani ldquoMobile cloud computing Areview on smartphone augmentation approachesrdquo CoRR 2012httpsarxivorgabs12050451

[14] P A L Rego P B Costa E F Coutinho L S Rocha F A MTrinta and J N D Souza ldquoPerforming computation offloadingonmultiple platformsrdquo Computer Communications vol 105 pp1ndash13 2017

[15] P A L Rego E Cheong E F Coutinho F A M Trinta MZ Hasany and J N D Souza ldquoDecision tree-based approachesfor handling offloading decisions and performing adaptivemonitoring in MCC systemsrdquo in Proceedings of the 5th IEEEInternational Conference on Mobile Cloud Computing Servicesand Engineering (MobileCloud rsquo17) pp 74ndash81 April 2017

[16] E Baccarelli P G V Naranjo M Scarpiniti M Shojafar andJ H Abawajy ldquoFog of everything energy-efficient networkedcomputing architectures research challenges and a case studyrdquoIEEE Access vol 5 pp 9882ndash9910 2017

[17] P A L Rego Applying smart decisions adaptive monitoring andmobility support for enhancing offloading systems [PhDThesis]Federal University of Ceara 2016

[18] M Z Hasan M Morrow L Tucker S L D Gudreddi and SFigueira ldquoSeamless cloud abstraction model and interfacesrdquo inProceedings of the ITU - Fully Networked Human - Innovationsfor Future Networks and Services (K rsquo11) pp 1ndash8 December 2011

[19] K Kumar J Liu Y-H Lu and B Bhargava ldquoA survey ofcomputation offloading for mobile systemsrdquo Mobile Networksand Applications vol 18 no 1 pp 129ndash140 2013

[20] C M Sarathchandra Magurawalage K Yang L Hu and JZhang ldquoEnergy-efficient and network-aware offloading algo-rithm formobile cloud computingrdquoComputerNetworks vol 74pp 22ndash33 2014

[21] J R Quinlan C45 Programs for Machine Learning MorganKaufmann Publishers Inc San Mateo Calif USA 1993

[22] F A Silva G Zaicaner E Quesado M Dornelas B Silvaand P Maciel ldquoBenchmark applications used in mobile cloudcomputing research a systematic mapping studyrdquoThe Journalof Supercomputing vol 72 no 4 pp 1431ndash1452 2016

[23] S Tasnim M A R Chowdhury K Ahmed N Pissinou andS S Iyengar ldquoLocation aware code offloading on mobile cloudwith QoS constraintrdquo in Proceedings of the IEEE 11th ConsumerCommunications and Networking Conference (CCNC rsquo14) pp74ndash79 January 2014

[24] A Ravi and S K Peddoju ldquoHandoff Strategy for ImprovingEnergy Efficiency and Cloud Service Availability for MobileDevicesrdquoWireless Personal Communications vol 81 no 1 pp101ndash132 2015

[25] R N Calheiros R Ranjan A Beloglazov C A F de Rose andR Buyya ldquoCloudSim a toolkit for modeling and simulationof cloud computing environments and evaluation of resourceprovisioning algorithmsrdquo Software Practice and Experience vol41 no 1 pp 23ndash50 2011


[26] W Junior A Franca K Dias and J N de Souza ldquoSupportingmobility-aware computational offloading in mobile cloud envi-ronmentrdquo Journal of Network and Computer Applications vol94 pp 93ndash108 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018


Active and Passive Electronic Components

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of



Journal ofEngineeringVolume 2018

SensorsJournal of



RotatingMachinery


Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation


Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom


Public Cloud

Internet BroadbandOffloadingInternet (3G 4G)WiFi

Vertical handover

Horizontal handover

Vertical handover

Cloudlet 1 Cloudlet 2

App1

App1

App2

App2

Figure 1 Supported scenario hybrid environment composed of cloudlets and public cloud instances

providing seamless connectivity and uninterrupted access tothose services is a serious research issue for MCC mainlybecause the execution of a mobile application may be highlycontext-dependent which means that several metrics suchas availability of network and localremote resources impactat runtime [13]

In previous works [14 15] we introduced amethod-basedmultiplatform offloading system developed in our researchgroup and a decision tree-based approach for assisting theoffloading decision on MCC systems Herein we face someof the challenges of MCC and related computing paradigms(eg Fog Computing and Fog of Everything [16]) such ashandling adaptive energy-efficient reconfiguration reducingcomputing-plus-communication delay and service latencyand supporting devices mobility To do that we extend ouroffloading framework in three ways (i) to adopt a lightweightoffloading decision module where the high intensive oper-ations related to decision-making are executed outside themobile device (ii) to leverage an adaptive monitoring systemto reduce the burden of metrics monitoring and (iii) toprovide seamless connectivity to mobile applications in ahybrid environment composed of public cloud and cloudlets

Our enhanced framework leverages machine learn-ing and software-defined networking techniques to handleoffloading decision and to provide mobility support Severalexperiments were conducted to evaluate the three aspects ofthe proposed solution

The rest of the paper is structured as follows FirstSection 2 describes the proposed solution and Section 3presents details and results of the experiments performed toevaluate the work Section 4 discusses related work FinallySection 5 presents conclusion and future work

2 Enhanced Offloading System

Existing offloading frameworks have motivated us to developan offloading solution [17] in which the decisions of when

and where to offload are not performed exclusively onmobiledevices Also the lack of mobility support when a hybridscenario is considered and the overhead caused by periodiccontext information gathering have also motivated this workIn the face of such problems herein we introduce novelsolutions to handle offloading decisions perform adaptivemonitoring and support usersrsquo mobility

We present Figure 1 to clarify the scenario supportedby this work As illustrated our solution considers mobiledevices and two types of remote servers (cloudlets and publiccloud instances) where one or more mobile devices can usethe same remote server We assume that mobile devices andcloudlets are connected to the same Wi-Fi access point (ieone-hop away) or to a group of access points (when WLANcontrollers are used) while mobile devices can connectto public cloud instances via Internet using either cellularnetwork (eg 3G or 4G) or Wi-Fi hotspots

Regarding usersrsquo mobility the solution supports (i) hor-izontal handover when a user moves from one cloudlet toanother and (ii) vertical handover when the user moves froma cloudlet to public cloud or from public cloud to a cloudlet

The proposed offloading system was built upon threesolutions the MpOS framework [3 14] the OpenStackplatform and seamless cloud (SLC) API [18] MpOS is anoffloading framework for Android and Windows Phonewhere mobile applications are composed of a set of methodswhich can be marked by developers using the RemotableJava annotation As presented in Listing 1 the methodsapplyEffect1 and applyEffect2 are marked in lines (2)and (4) as candidates to be offloaded

OpenStack is an open source cloud computing platformthat we use to run remote servers (cloudlets and public cloudinstances) and SLC is an abstraction to facilitate secure andseamless interconnection of distributed clouds One can usethe SLC API to perform CRUD operations (ie create readupdate and delete) on cloud resources programmaticallywhich means resources under control of multiple cloud











REE Handler

Decision Enforcer

DataHistorical























119880119898119896 = 119868119898119896119879119906119901 (1)


119863119898119896 = 119874119898119896119879119889119900 (2)



119864119897119900119888119886119897119898119896 gt 119878119864119898k + 119880119898119896 + 119876119903119904 + 119864119903119904119898119896 + 119863119898119896 + 119863119863119898119896 (3)




119864119888119897119900119906119889119897119890119905119898119896 + 119876119888119897119900119906119889119897119890119905 gt 119880119898119896 + 119876119888119897119900119906119889 + 119864119888119897119900119906119889119898119896+ 119863119898119896 (4)




Remote Server

Mobile Device

Time


Umk Dmk

Elocalmk

SEmk DDmk

QrsErsmk


Cloudlet

Public Cloud Time

Performancegain


Umk Dmk

Qcloud Ecloudmk















(11) 119873119906119901119897119900119886119889 larr997888 1198731199061199011198971199001198861198892







119866119886119894119899 (119860 119878) = 119864119899119905 (119878) minus sumVisin119860

(1003816100381610038161003816119878V1003816100381610038161003816|119878| 119864119899119905 (119878V)) (5)









Dummy App

no

no

yes

Local Remote

RemoteRTT gt 50

yes


FooBar








3 Evaluation










CMX APICMX API

Public Cloud

Virtual Router


DataHistorical

DataHistoricalData

Historical

Mobility Manager

Cisco MSECisco MSE


SLC Controller







0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

10 records

0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

100 records

0

5

10

15

20

25

DT

Crea

tion

Tim

e (m

illise

cond

s)

1000 records

0

20

40

60

80

100

120

140

DT

Crea

tion

Tim

e (m

illise

cond

s)


CloudCloudlet


Cloud


CloudCloudlet


CloudCloudlet


CloudCloudlet

Cloudlet

10000 records

0

500

1000

1500

2000

2500

DT

Crea

tion

Tim

e (m

illise

cond

s)

100000 records









1 2 4 8Tree height

0

3

6

9

12

15

Proc

essin

g tim

e (m

illise

cond

s)



Handset B (parsing)


















Maptone


Cartoonizer








368

1017

1503

09631080911 0868


1

2

3

4

Pow

er (W

)

Handset AHandset B













Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia












REE Handler

Decision Enforcer

DataHistorical























119880119898119896 = 119868119898119896119879119906119901 (1)


119863119898119896 = 119874119898119896119879119889119900 (2)



119864119897119900119888119886119897119898119896 gt 119878119864119898k + 119880119898119896 + 119876119903119904 + 119864119903119904119898119896 + 119863119898119896 + 119863119863119898119896 (3)




119864119888119897119900119906119889119897119890119905119898119896 + 119876119888119897119900119906119889119897119890119905 gt 119880119898119896 + 119876119888119897119900119906119889 + 119864119888119897119900119906119889119898119896+ 119863119898119896 (4)




Remote Server

Mobile Device

Time


Umk Dmk

Elocalmk

SEmk DDmk

QrsErsmk


Cloudlet

Public Cloud Time

Performancegain


Umk Dmk

Qcloud Ecloudmk















(11) 119873119906119901119897119900119886119889 larr997888 1198731199061199011198971199001198861198892







119866119886119894119899 (119860 119878) = 119864119899119905 (119878) minus sumVisin119860

(1003816100381610038161003816119878V1003816100381610038161003816|119878| 119864119899119905 (119878V)) (5)









Dummy App

no

no

yes

Local Remote

RemoteRTT gt 50

yes


FooBar








3 Evaluation










CMX APICMX API

Public Cloud

Virtual Router


DataHistorical

DataHistoricalData

Historical

Mobility Manager

Cisco MSECisco MSE


SLC Controller







0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

10 records

0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

100 records

0

5

10

15

20

25

DT

Crea

tion

Tim

e (m

illise

cond

s)

1000 records

0

20

40

60

80

100

120

140

DT

Crea

tion

Tim

e (m

illise

cond

s)


CloudCloudlet


Cloud


CloudCloudlet


CloudCloudlet


CloudCloudlet

Cloudlet

10000 records

0

500

1000

1500

2000

2500

DT

Crea

tion

Tim

e (m

illise

cond

s)

100000 records









1 2 4 8Tree height

0

3

6

9

12

15

Proc

essin

g tim

e (m

illise

cond

s)



Handset B (parsing)


















Maptone


Cartoonizer








368

1017

1503

09631080911 0868


1

2

3

4

Pow

er (W

)

Handset AHandset B













Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia










119880119898119896 = 119868119898119896119879119906119901 (1)


119863119898119896 = 119874119898119896119879119889119900 (2)



119864119897119900119888119886119897119898119896 gt 119878119864119898k + 119880119898119896 + 119876119903119904 + 119864119903119904119898119896 + 119863119898119896 + 119863119863119898119896 (3)




119864119888119897119900119906119889119897119890119905119898119896 + 119876119888119897119900119906119889119897119890119905 gt 119880119898119896 + 119876119888119897119900119906119889 + 119864119888119897119900119906119889119898119896+ 119863119898119896 (4)




Remote Server

Mobile Device

Time


Umk Dmk

Elocalmk

SEmk DDmk

QrsErsmk


Cloudlet

Public Cloud Time

Performancegain


Umk Dmk

Qcloud Ecloudmk















(11) 119873119906119901119897119900119886119889 larr997888 1198731199061199011198971199001198861198892







119866119886119894119899 (119860 119878) = 119864119899119905 (119878) minus sumVisin119860

(1003816100381610038161003816119878V1003816100381610038161003816|119878| 119864119899119905 (119878V)) (5)









Dummy App

no

no

yes

Local Remote

RemoteRTT gt 50

yes


FooBar








3 Evaluation










CMX APICMX API

Public Cloud

Virtual Router


DataHistorical

DataHistoricalData

Historical

Mobility Manager

Cisco MSECisco MSE


SLC Controller







0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

10 records

0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

100 records

0

5

10

15

20

25

DT

Crea

tion

Tim

e (m

illise

cond

s)

1000 records

0

20

40

60

80

100

120

140

DT

Crea

tion

Tim

e (m

illise

cond

s)


CloudCloudlet


Cloud


CloudCloudlet


CloudCloudlet


CloudCloudlet

Cloudlet

10000 records

0

500

1000

1500

2000

2500

DT

Crea

tion

Tim

e (m

illise

cond

s)

100000 records









1 2 4 8Tree height

0

3

6

9

12

15

Proc

essin

g tim

e (m

illise

cond

s)



Handset B (parsing)


















Maptone


Cartoonizer








368

1017

1503

09631080911 0868


1

2

3

4

Pow

er (W

)

Handset AHandset B













Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Remote Server

Mobile Device

Time


Umk Dmk

Elocalmk

SEmk DDmk

QrsErsmk


Cloudlet

Public Cloud Time

Performancegain


Umk Dmk

Qcloud Ecloudmk















(11) 119873119906119901119897119900119886119889 larr997888 1198731199061199011198971199001198861198892







119866119886119894119899 (119860 119878) = 119864119899119905 (119878) minus sumVisin119860

(1003816100381610038161003816119878V1003816100381610038161003816|119878| 119864119899119905 (119878V)) (5)









Dummy App

no

no

yes

Local Remote

RemoteRTT gt 50

yes


FooBar








3 Evaluation










CMX APICMX API

Public Cloud

Virtual Router


DataHistorical

DataHistoricalData

Historical

Mobility Manager

Cisco MSECisco MSE


SLC Controller







0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

10 records

0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

100 records

0

5

10

15

20

25

DT

Crea

tion

Tim

e (m

illise

cond

s)

1000 records

0

20

40

60

80

100

120

140

DT

Crea

tion

Tim

e (m

illise

cond

s)


CloudCloudlet


Cloud


CloudCloudlet


CloudCloudlet


CloudCloudlet

Cloudlet

10000 records

0

500

1000

1500

2000

2500

DT

Crea

tion

Tim

e (m

illise

cond

s)

100000 records









1 2 4 8Tree height

0

3

6

9

12

15

Proc

essin

g tim

e (m

illise

cond

s)



Handset B (parsing)


















Maptone


Cartoonizer








368

1017

1503

09631080911 0868


1

2

3

4

Pow

er (W

)

Handset AHandset B













Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




(11) 119873119906119901119897119900119886119889 larr997888 1198731199061199011198971199001198861198892







119866119886119894119899 (119860 119878) = 119864119899119905 (119878) minus sumVisin119860

(1003816100381610038161003816119878V1003816100381610038161003816|119878| 119864119899119905 (119878V)) (5)









Dummy App

no

no

yes

Local Remote

RemoteRTT gt 50

yes


FooBar








3 Evaluation










CMX APICMX API

Public Cloud

Virtual Router


DataHistorical

DataHistoricalData

Historical

Mobility Manager

Cisco MSECisco MSE


SLC Controller







0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

10 records

0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

100 records

0

5

10

15

20

25

DT

Crea

tion

Tim

e (m

illise

cond

s)

1000 records

0

20

40

60

80

100

120

140

DT

Crea

tion

Tim

e (m

illise

cond

s)


CloudCloudlet


Cloud


CloudCloudlet


CloudCloudlet


CloudCloudlet

Cloudlet

10000 records

0

500

1000

1500

2000

2500

DT

Crea

tion

Tim

e (m

illise

cond

s)

100000 records









1 2 4 8Tree height

0

3

6

9

12

15

Proc

essin

g tim

e (m

illise

cond

s)



Handset B (parsing)


















Maptone


Cartoonizer








368

1017

1503

09631080911 0868


1

2

3

4

Pow

er (W

)

Handset AHandset B













Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Dummy App

no

no

yes

Local Remote

RemoteRTT gt 50

yes


FooBar








3 Evaluation










CMX APICMX API

Public Cloud

Virtual Router


DataHistorical

DataHistoricalData

Historical

Mobility Manager

Cisco MSECisco MSE


SLC Controller







0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

10 records

0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

100 records

0

5

10

15

20

25

DT

Crea

tion

Tim

e (m

illise

cond

s)

1000 records

0

20

40

60

80

100

120

140

DT

Crea

tion

Tim

e (m

illise

cond

s)


CloudCloudlet


Cloud


CloudCloudlet


CloudCloudlet


CloudCloudlet

Cloudlet

10000 records

0

500

1000

1500

2000

2500

DT

Crea

tion

Tim

e (m

illise

cond

s)

100000 records









1 2 4 8Tree height

0

3

6

9

12

15

Proc

essin

g tim

e (m

illise

cond

s)



Handset B (parsing)


















Maptone


Cartoonizer








368

1017

1503

09631080911 0868


1

2

3

4

Pow

er (W

)

Handset AHandset B













Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




CMX APICMX API

Public Cloud

Virtual Router


DataHistorical

DataHistoricalData

Historical

Mobility Manager

Cisco MSECisco MSE


SLC Controller







0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

10 records

0

2

4

6

8

10

DT

Crea

tion

Tim

e (m

illise

cond

s)

100 records

0

5

10

15

20

25

DT

Crea

tion

Tim

e (m

illise

cond

s)

1000 records

0

20

40

60

80

100

120

140

DT

Crea

tion

Tim

e (m

illise

cond

s)


CloudCloudlet


Cloud


CloudCloudlet


CloudCloudlet


CloudCloudlet

Cloudlet

10000 records

0

500

1000

1500

2000

2500

DT

Crea

tion

Tim

e (m

illise

cond

s)

100000 records









1 2 4 8Tree height

0

3

6

9

12

15

Proc

essin

g tim

e (m

illise

cond

s)



Handset B (parsing)


















Maptone


Cartoonizer








368

1017

1503

09631080911 0868


1

2

3

4

Pow

er (W

)

Handset AHandset B













Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



1 2 4 8Tree height

0

3

6

9

12

15

Proc

essin

g tim

e (m

illise

cond

s)



Handset B (parsing)


















Maptone


Cartoonizer








368

1017

1503

09631080911 0868


1

2

3

4

Pow

er (W

)

Handset AHandset B













Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





Maptone


Cartoonizer








368

1017

1503

09631080911 0868


1

2

3

4

Pow

er (W

)

Handset AHandset B













Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





Add


Multiply









0

5

10

15

20

25

Tim

e (se

cond

s)






4383

1228158

12621073 1211 101


1

2

3

4

5

Pow

er (W

)

Handset AHandset B






BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



BenchImage

no

nono

no

no

yes

yes

yes

Remote

Remote

Remote


yes

Local

Local





BenchImage

no

no

no

no

yes

yes

yes

Remote

Remote

Remote

Method == Maptone

yes

Local

Local





Remote

BenchImage














0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




0510 20 30 40 50 60 70 80 90 100

1

15

2

25

Aver

age p

ower

(W)



(a) Handset A


05

1

15

2

Aver

age p

ower

(W)



(b) Handset B


14596

10513

78716486

72895846


40

80

120

160

Ener

gy (J

)









4 Related Work




CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



CloudletSJC-13

CloudletSJC-15

SJC-15

SJC-13









130




Exec

utio

n tim

e (se

cond

s)

0

3

6

9

12

15

18

173

1304

180 139

1602





















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia

















OffloadingSolution

Offloading

Granularity

OfflineTraining

Dependency



MobilitySupport

SupportedMobility

Scenario

MpOS[3]

Method

No

Device

Allmetrics

No

-MAUI[4]

Method

No


Allmetrics

No

-ThinkAir[5]

Method

No

Device

Allmetrics

No

-CloneCloud[6]

Thread

Yes

Device

Allmetrics

No

-EM

CO[7]

Thread

No


Allmetrics

No

-CSOS[10]

Method

Yes


Allmetrics

No

-MobiCOP[8]

Method

No

Device

Allmetrics

No

-Foreseer[9]

Method

No

Device


No

-[23]

Method

No

Device

Allmetrics

Yes

PublicCloud

[24]

Method

No

Device

Allmetrics

Yes


[20]

Method

No

Device

Allmetrics

Yes


MOSys

Method

No

Device

Allmetrics

Yes

Cloudlets

Our

Work

Method

No



Yes



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Data Availability




Acknowledgments


References






























RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia






RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


enhancing offloading systems with smart decisions...

Documents