Cloud-Assisted Computation Ofﬂoading to Support … Computation Ofﬂoading to Support Mobile...

2168-7161 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. Seehttp://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI10.1109/TCC.2014.2350471, IEEE Transactions on Cloud Computing

1

Cloud-Assisted Computation Offloading toSupport Mobile ServicesKhalid Elgazzar, Patrick Martin, Hossam S. Hassanein

School of Computing, Queen’s University, Canada{elgazzar, martin, hossam}@cs.queensu.ca

Abstract—The widespread use and increasing capabilities ofmobiles devices are making them a viable platform for offeringmobile services. However, the increasing resource demandsof mobile services and the inherent constraints of mobiledevices limit the quality and type of functionality that can beoffered, preventing mobile devices from exploiting their fullpotential as reliable service providers. Computation offloadingoffers mobile devices the opportunity to transfer resource-intensive computations to more resourceful computing infras-tructures. We present a framework for cloud-assisted mobileservice provisioning to assist mobile devices in deliveringreliable services. The framework supports dynamic offloadingbased on the resource status of mobile systems and currentnetwork conditions, while satisfying the user-defined energyconstraints. It also enables the mobile provider to delegatethe cloud infrastructure to forward the service responsedirectly to the user when no further processing is requiredby the provider. Performance evaluation shows up to 6xlatency improvement for computation-intensive services thatdo not require large data transfer. Experiments show that theoperation of the cloud-assisted service provisioning frameworkdoes not pose significant overhead on mobile resources, yet itoffers robust and efficient computation offloading.

Index Terms—computation offloading, service provisioning,mobile services, mobile computing

I. INTRODUCTION

The role of mobile devices as service providers isstrongly supported by the continuous increase in theircapabilities and recent availability of high speed wirelessnetwork technologies. The range of services that involvemobile devices providing data are on the rise, rangingfrom entertainment services, such as online social gamingand networking, to crowdsourcing, such as collaborativeparticipatory sensing as well as services that can be offeredon the fly, such as video streaming of a current event.However, the rich functionalities that such applicationsoffer increasingly demand resources beyond the capabilitiesof inherently resource-constrained devices. The lack ofresources places limitations on the types of functionalityand services that can be offered.

The elastic resource provisioning of cloud computingpromises to bridge the gap between the limited resourcesof mobile devices and the growing resource demands ofmobile services through offloading resource-intensive tasks.However, offloading such tasks does not always guaranteeperformance improvements. For example, offloading mayentail large data transfer between the cloud and the mo-bile device, which compromises the potential performance

benefits and incurs higher latency. In some other casesthe mobile device may be unable to afford the energyrequirements for such data transfers. In fact, the user mightprefer to lower the bar of latency constraints to favor energysavings for some specific applications. Thus, the decisionon when to offload the execution of Web resources to thecloud becomes a critical issue to the overall performanceof mobile services.

In mobile environments, cloud-based resource provision-ing extends beyond the public cloud. A mobile systemmay also offload computations to cloudlets [1] and mobilecloud [2, 3]. Additionally, the static resource allocation tocomputation offloading is inefficient and does not exploitthe opportunities that mobility may offer. For instance, amobile system may need to re-offload computations due toa network failure. Dynamic binding to resource providersallows mobile systems to offload computations to a resourceprovider and receive results through a better provider in theclose vicinity (e.g. a smart vehicle).

This research presents a distributed mobile service pro-visioning framework that reduces the burden on mobileresources through the offloading of resource-intensive pro-cesses to the cloud. An offloading decision model isproposed to determine whether or not remote executionof a resource request brings performance improvements.The decision making involves selecting the best availableresource provider according to the resource availabilityand network conditions using our proposed Follow-Me-Provider scheme. This scheme dynamically allocates re-source providers to offload tasks to best suit the taskrequirements and environment context. The decision makerdetermines the best execution plan that achieves the highestperformance gain.

Our main contributions are as follows:• We present an enabling mechanism for context-

aware computation offloading to support resource-constrained mobile service providers.

• We introduce the Follow-Me-Provider, a robustscheme that enables dynamic binding between com-puting tasks and cloud resource providers.

The remainder of this paper is organized as follows. Sec-tion II gives a brief background on computation offloadingand outlines related work. Section III presents the proposedcloud-assisted mobile service architecture. Implementationdetails and experimental validations are given in SectionIV and Section V, respectively. Section VI presents the



2

performance evaluation and offers a comprehensive discus-sion. Section VII provides overhead analysis. Section VIIIconcludes the paper and highlights future directions.

II. BACKGROUND & RELATED WORK

Over the past few years, significant study has been doneon the resource constraints of mobile devices as computingplatforms. In this section, we provide a brief backgroundand review the related work from two perspectives: mobiledevices as service providers and computation offloading toaugment the capability of mobile devices.

A. Mobile Devices as Service Providers

Little of the previous research have been dedicated toinvestigate computation offloading in service provisioning.Weerasinghe et al. [4] studied reliable mobile service pro-visioning with respect to availability and scalability. Theauthors propose a proxy-based middleware to bootstrap theperformance of mobile services. The proxy acts as a fixedrepresentative to mobile services. This middleware supportsservice migration where mobile providers may choose toswitch to an alternate server due to close proximity orbetter connectivity. Hassan et al. [5] present a distributedmobile service provisioning framework that partitions theexecution of resource-intensive services between the mobileprovider and a backend server. The framework offers adistributed execution engine where tasks that require realtime access to local resources are executed on the mobiledevices, while the remaining processing is offloaded to aremote server. Their partitioning technique relies solely onthe available resources of the mobile device. The executionis entirely performed on the mobile device if availableresources satisfy the service execution requirements. Incontrast, our framework selects the best execution plan withthe minimum response time, while satisfying the resourceconstraints with respect to both execution requirements anduser preferences.

B. Computation Offloading

Computation offloading transfers processing outside ofthe mobile device. The objective is to improve the perfor-mance, enable advanced functionality, and preserve scarceresources. Offloading may be performed at different granu-larities ranging from methods and individual tasks [6]–[8]to applications [9] and virtual machines [10]. Offloadingtechniques are categorized into three main categories:

1) Remote Invocation: This technique requires servicesto be deployed on the remote host. The offloadingdevice invokes the target service on the remote serverusing well-known mechanisms such as Remote Pro-cedure Call (RPC) or Remote Method Invocation(RMI). Although this approach is well-supported byAPIs, service pre-deployment on remote hosts posesa critical restriction to the ad-hoc nature of mobilecloud systems. For example, mobile terminals maydiscover resource providers in close proximity that

offer IaaS. Such providers could be transient (e.g. apassing smart vehicle), or stationary, such as cloudlets[1]. In such cases, the pre-deployment requirementlimits the choices of mobile systems on where tooffload computations.

2) VM Migration: VM migration refers to transferringthe entire memory image of a running VM fromthe mobile system to a cloud infrastructure. VMmigration has advantages over other methods as VMsare created through virtualization techniques, whichoffer isolation and protection for data and processingagainst malicious entities on the remote host.

3) Code Migration: Mobile code migration transferscode and data required to carry out a certain taskon a remote host. In most cases, the code is smallin contrast to the data. However, compatibility issuesmay arise when migrated code is ported to run on ahosting platform. This method enables computationoffloading on a fine granularity level, such as individ-ual functions and methods. VM and code migrationare favored in recent works [11].

Several aspects of computation offloading have beenstudied including the feasibility of offloading, making of-floading decisions, and developing offloading infrastruc-tures [12, 13]. For example, Hyrax [2] is a platformthat supports distributed Android applications based ona version of Hadoop ported to the Android platform. Itenables Android applications to access data and offloadcomputing tasks to a mobile cloud formed by heterogenousmobile devices. Huerta-Canepa and Lee [14] propose avirtual mobile cloud computing platform using mobiledevices. The framework capitalizes on the availability ofmobile devices that are willing to share their computationalresources in the close vicinity. Giurgiu et al. [15] present amiddleware that can distribute mobile applications betweenthe mobile device and a remote server, aiming at improvingthe overall latency and reducing the amount of data transfer.The middleware generates a resource consumption graphand splits the application’s modules to optimize a varietyof objective functions. Cuckoo [16] is a framework thatprovides a runtime environment for mobile applications tosupports dynamic offloading decisions. However, mobileapplications need to be re-written according to the An-droid’s ‘activity/service’ model.

Clonecloud [8] and MAUI [7] are two recent studies oncomputation offloading that focus on performance gain andenergy saving, respectively. CloneCloud offers a runtimepartitioning approach for mobile applications based ona combination of static analysis and dynamic profilingtechniques. CloneCloud works at the application-level VMand supports up to the thread granularity. The objective isto speed up the application execution and to reduce energyconsumption at the mobile side. In CloneCloud, a deviceclone operates continuously on the cloud and communi-cates with the mobile device. MAUI enables energy-awareoffloading of mobile code to a resource-rich computinginfrastructure. It aims to alleviate the burden on the limited



3

energy resources of mobile devices while fulfilling theincreasing energy demands of mobile applications andservices. MAUI provides a disconnectivity mechanism thatenables interrupted processes to resume execution on themobile device. However, MAUI requires source code anno-tation by developers to mark which code can be executedremotely and which cannot. It uses these annotations todecide at runtime on the proper partitioning scheme.

In general, the offloading decision is made based on anobjective to either reduce the response time, save energy,or strike a balance between both. Offloading techniquesmake decisions statically based on prespecified rules, ordynamically based on context changes [17]. Dynamic deci-sions can be made using machine learning techniques [18]or based on analytical models [16, 17, 19, 20]. Spectra[19] employs computation offloading to balance betweenperformance and energy consumption. The decision is madebased on the resource usage profile of mobile applicationsand resource availability in the surrounding environment.Spectra requires continuous monitoring of local and remoteresources and network conditions. Spectra also modifies theapplication’s source code to determine possible partitioningoptions. Scavenger [20] uses various attributes to decidewhether offloading of a computing task brings performancegains. These attributes are: powerfulness and utilization ofavailable surrogates, network bandwidth, task complexity,and required data transfer. Kumar and Lu [21] providean analytical model to determine whether computationoffloading can save energy, taking into consideration theresource requirement of the computing task and currentnetwork conditions.

To the best of our knowledge, all previous researchefforts on mobile computation offloading focus only onthe interactions between the mobile system and the supportcomputing infrastructure, within the context of environmentconditions, while overlooking the possibility that a third-party data provider may exist. Many current data providersoffer their services either through the public cloud itself(e.g. Amazon S3) or connect to the cloud via a high speedinterconnect (e.g. Dropbox). Therefore, the data transferis much faster between the data provider and the cloud,than between the data provider and a mobile device. Hence,adding a data provider to the equation significantly impactsthe offloading decision. The framework proposed in thispaper addresses this issue when making offloading deci-sions. Furthermore, it also proposes an agile cloud providerselection algorithm that leverages the mobility of both usersand mobile resource providers.

III. CLOUD-ASSISTED MOBILE SERVICEARCHITECTURE

This paper presents a framework for cloud-assisted ser-vice provisioning from resource-constrained devices. Theproposed cloud-assisted mobile service architecture in-volves four key entities: a user, a mobile device, a cloud,and a data provider, as shown in Figure 1. The user repre-sents the service consumer. The mobile device represents

B2

B3

B5

B 1

Data Provider

Cloud Provider

Mob

ile S

ervi

ce

Prov

ider

Users

d in

d out

B 4

Response

Request U

M C

D

Response

B: Bandwidthdin: Size of input datadout: Size of output data

Fig. 1: An abstract view of cloud-assisted mobile servicearchitecture, showing possible interacting entities and con-text information, where B is the link bandwidth and dinand dout represent the amount of data exchange over a linkin both directions.

a mobile service provider and acts as the integration pointwhere service execution plans are generated and decisionsregarding offloading are made. The cloud is the supportingcomputing infrastructure that the mobile provider uses tooffload resource-intensive tasks. Service operations mayinvolve third-party data processing during the execution ofthe service functionality, such as weather information ornavigation databases. In such cases, data could be fetchedfrom a data provider.

The user sends the service request to the mobile provider.The mobile provider decides on the best execution plan andwhether offloading is beneficial. The cloud offers elasticresource provisioning on-demand to mobile providers. Themobile provider may collect the execution results from thecloud and generate a proper response for the use or delegatethe cloud to forward the response directly to the user, giventhat no further processing is required at the mobile side.

The proposed framework encompasses the followingmajor components: Request/Response Handler, ContextManager, Profiler, Execution Planner, Service ExecutionEngine, and Offloading Decision Maker. Figure 2 depictsan abstract view of the framework architecture. The func-tionality of each component is discussed in the followingsubsections.

A. Request/Response Handler

Internet users can request access to Web services orWeb contents. A service request could be SOAP/XML forSOAP-based Web services [22] or an HTTP request forREST-based Web services [22]. RESTful requests pointdirectly to specific operations that carry out the requiredfunctionality whereas SOAP requests associate parametersby which the service execution engine internally maps the



4

Request/Response

Handler

Execution Engine

Off

load

ing

Dec

isio

n

Mo

del

Profiler

Execution Planner

Context

ManagerR

equ

est/

Res

po

nse

Han

dle

r

Execution EngineMobile Cloud

Mobile Service Provider

Cloud Provider

Mobile Services

Fig. 2: The architecture of the cloud-assisted mobile serviceprovisioning.

request to the appropriate method. The Request/ResponseHandler plays the role of a multiplexer, distinguishingbetween SOAP requests and RESTful requests as well asdifferentiating between service and content access requests.The handler forwards the latter directly to the Web serverwhereas the former is sent to the service Execution Enginefor processing. SOAP/XML service requests are handledby SOAP Manager before they are sent to the Web server,while HTTP requests for services are analyzed directly bya servlet.

B. Profiler

This component is responsible for analyzing the charac-teristics of various service operations, deployed on the mo-bile device, in the form of a resource consumption profilethat includes the required CPU cycles, memory size, dataexchange, potential data transfer, and interactions with localresources. A service may include multiple operations. Eachoperation can be invoked separately, possibly many times,and perform its functionality independently. The profilertreats each operation as a standalone function. The profilerruns service operations offline to measure the requiredresources in terms of CPU cycles, memory, data transfer,and access to local physical resources. We instrument theseoperations to identify the dependencies and interrelation-ships between them. The profiler then generates a resourceconsumption profile for each service with a separate sectionfor each operation as shown in Listing 1. More detailsabout different types of profilers and profiling strategiescan be found in [7, 8]. The planner module uses theinformation in the consumption profile to generate possibleexecution plans. The offloading decision module uses theexecution plans along with the context information col-lected by the context manager to select the best executionstrategy for a specific service operation (method) request.

Listing 1: A snippet of a resource consumption profile<?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?><r d f :RDFxmlns : r d f =” h t t p : / / www. w3 . org /1999/02/22 − r d f−syn t ax−ns # ”xmlns : env=” h t t p : / / www. example . sample / p r o f i l e # ”>

<r d f : D e s c r i p t i o nr d f : a b o u t =” h t t p : / / s e r v i c e−r o o t / s e r v i c e−name? wsdl ”><env : se rv iceName>name</ env : se rv iceName>

</ r d f : D e s c r i p t i o n>

<r d f : o p e r a t i o nr d f : a b o u t =” h t t p : / / www. example . sample / p r o f i l e ”><env : u r i>h t t p : / / s e r v i c e−r o o r / B lu r</ env : u r i><env : cpu>16</ env : cpu><env : memory>1 6 . 2</ env : memory><env : en e r gy>1 . 9 2</ env : en e r gy><env : dependancy>None</ env : dependancy>

</ r d f : r e s o u r c e>

<r d f : o p e r a t i o nr d f : a b o u t =” h t t p : / / www. example . sample / p r o f i l e ”><env : u r i>h t t p : / / s e r v i c e−r o o r / Blend</ env : u r i><env : cpu>106</ env : cpu><env : memory>1 9 . 1</ env : memory><env : en e r gy>2 . 6 3</ env : en e r gy><env : dependancy>None</ env : dependancy>

</ r d f : r e s o u r c e>...</ r d f :RDF>

C. Context Manager

Mobile devices capitalize on their sensing capabilitiesto collect real-time context information to make betterdecisions. The context manager gathers a variety of contextinformation to be used for personalization purposes andadaptive actions [23]. The context manager gathers twocategories of context attributes:

• User Context: This category contains context informa-tion related to the user and current runtime environ-ments. This context presents a comprehensive viewof the user’s current status. User context includes thefollowing attributes:Location: The user location determines which remotehosts can be used for offloading. The automatic collec-tion of location information can be obtained in a vari-ety of ways outdoors (e.g. GPS and mobile networks)[24, 25], or indoors (e.g. Received Signal Strengthtechniques) [26, 27]. Mobility of both devices andresource providers plays a significant role in decidingthe offloading strategy. Mobile platforms provide APIsto access the location information. Location-basedmobile applications and services use these APIs toobtain the location information on-demand and utilizeit internally as required.Device Profile: This contains the hardware and soft-ware specifications of the user’s device. The deviceprofile includes the display size and specifications,sensing capabilities, network interfaces, OS platform,etc. These context attributes assist in determiningthe compatibility of offloading tasks with the remoteserver specifications. Some of the hardware featuresalso may impact the offloading decision, such asavailable network interfaces. This type of context



5

is collected one time. The framework refreshes thedevice’s profile information at restart to capture anychanges in both software and hardware.Local Resources: Upon receiving a request, the con-text manager captures on-demand the status of localresources such as: CPU utilization, available memory,battery level, and storage capacity. These attributes areused to evaluate different execution plans to determinethe potential performance gain. The context manageralso maintains a record of running applications andactivities as a load indicator.User preferences: Each user has different preferencesthat might influence the offloading decision. Thesepreferences may change according to the situation.For instance, a user running a navigation applicationmay favor execution plans with more energy savingif battery power is under certain threshold. The sameuser may be more concerned about latency if they needto find a gas station before the next exit on a highway.The framework maintains user preferences in an XMLfile with pre-defined tags. The user can update thesepreferences in an ongoing manner.

• Environment Context: Environment context encom-passes information that characterizes the surroundingsof the user. The framework utilizes this context tobetter make offloading decisions. Context attributes ofthis category are:Remote Hosting Environments: The mobile systemdiscovers and keeps track of all potential resourceproviders that can process offloading requests includ-ing public cloud, cloudlets [28], mobile cloud farm[2, 14]. Information about available public cloud andcloudlets is provided and updated by the serviceprovider. Upon receiving a service request, the frame-work sends standard resource discovery requests on-demand over short range communications to discovermobile resource providers in the close vicinity. Theframework uses the list of available resource providersto decide on the best remote server for a specificoffloading request.Network Status: Mobile environments are character-ized by intermittent connectivity and varying connec-tion quality. The context manager proactively monitorsavailable network connections, such as wired, WiFi,4G, Bluetooth, ZigBee [29], and their status. The qual-ity of the connection determines how fast data can betransferred. The network bandwidth and required dataplay a major role in determining whether offloading isfavored over local execution.

Figure 3 shows the architecture of our context manager.It contains four main components: context engine, contexttemplates, context database, and context agent.Context Engine: The context engine coordinates betweendifferent components. It creates and maintains contextagents based on registered context templates, gathers con-text information from agents and stores it in the contextdatabase, processes context information if required, and

Context Engine

Context Agent Context Agent Context Agent Context Agent

Context DBContext Templates

Context Manager

Fig. 3: The schematic architecture of context manager.

disseminates context data to requesting entities.Context Templates: Templates are configuration files thatdescribe context attributes and any associated constraintsand rules. The context engine utilizes these configurationtemplates to deploy software agents that collect contextattributes.Context Database. The context database is a lightweightrelational database that maintains various context infor-mation. Most mobile-based platforms contain embeddedlightweight database engines that support standard rela-tional database functionality. For example, the Androidplatform uses the SQLite [30] database management sys-tem. SQLite requires limited memory at runtime, whichmakes it a good candidate for mobile systems.Context Agent. The context agent is a software entity thatis deployed to gather a specific context attribute. Agentsare APIs or Web services that could be deployed locallyon the mobile system to gather local context informationor remotely to report remote context attributes.

Context information and service consumption profiles areused by the offloading decision model to select the optimalexecution plan that, in addition to achieving performancegain, satisfies the device constraints and user preferences.

D. Execution Planner

The execution planner determines the various possibleexecution plans for each service operation based on avail-able information about each operation from the servicedescription file and the behavior profile generated by theprofiler. Each operation can be executed in a variety ofdifferent ways. Possible execution plans are generatedbased on the sources of involved data objects, interactionsbetween such data and other local resources, and the execu-tion environment. Options include local execution, remoteexecution or combinations of both. Service developers mayannotate particular operations to be strictly executed onmobile systems due to security reasons or privacy concernssuch as the case when a provider wishes to ensure fullprivacy of its users’ information. Although current servicedescription standards do not support such annotation, arecent initiative has been proposed by Hassan et al. [5]on how to specify the execution environment in the servicedescription.



6

Since the functionalities of mobile services are knownin advance, execution plans could be generated during theservice deployment outside of the mobile service provider(i.e. services are deployed along with their possible execu-tion plans). These execution plans could be generated byusing the cloud resources supporting the mobile service.However, our platform supports offloading to mobile cloudand cloudlets on-demand, which means that the servicedoes not know which cloud resources are going to beused during execution. Additionally, service requests mightbe associated with user security/privacy constraints thatgovern how the requested functionality is executed. Forexample, the user requires that his/her credentials are notto be shared with third-parties (e.g., cloud providers). Thisrequires revisiting the execution plans at runtime to excludeplans that violate the request constraints. Therefore, tomaintain the generality of our framework, we implementthe execution planner component on the mobile device tofacilitate the interactions with other components, such asthe context manager, when required.

The planner starts with the possibility of performing theexecution locally on the mobile system, where the deviceacquires all the required data for processing and sendsback a response to the user. If there is local resourceaccess, the planner generates a plan consisting entirelyof remote processing. When offloading is applicable, theplanner considers response forwarding, where the mobileservice provider may delegate the cloud/remote executionenvironment to forward the response directly to the user.If the requested operation encompasses independent func-tions that can be carried out separately, further plans ofpartitioning are considered. Several partitioning strategiesare discussed in [7, 8, 15].

The framework enables and disables response forwardingthrough setting the forward response attribute to ‘ON’ and‘OFF’, respectively. Response forwarding is a two-foldbenefit: 1) mobile providers do not have to retrieve theresponse back from the cloud and send it to the user.This decreases the communication overhead and batteryconsumption on the mobile system and reduces the overallresponse time to the user, 2) the response will reach theuser even if the mobile service provider is down/discon-nected for any reason. Response forwarding is performed atthe application layer through asynchronous communicationprotocols. Applications with strict security constraints maydisable the ‘response forwarding’ service, or offload onlyto trusted providers.

A plan evaluation is performed at runtime once aninvocation request is received at the mobile provider’s side.Since the churn of services is low, these evaluations arestored for a short time tp in case the mobile providerreceives multiple requests for the same operations withinthe time interval tp. It’s uncommon that network conditions(bandwidth B in particular) fluctuate too much betweenhigh and low values within a short period of time to makesuch evaluations invalid. The framework allows serviceproviders to specify the tp based on preferences and prac-tical experience.

E. Service Execution Engine

Our architecture adopts the concept of distributed serviceexecution, where services could be executed on either themobile device, the cloud or both. The service executionengine resides on the mobile device with a supportingremote execution module at the cloud side. The controlof the service execution remains at the mobile device. Theexecution engine at the mobile provider may delegate theexecution of a service partially or entirely on the cloudbased on the recommendation of the offloading decisionmaker. Based on such a recommendation, the execution ofa service might involve data transfer between the two partsof the execution engine.

F. Offloading Decision Maker

The offloading decision involves two aspects: 1) selectingthe best available resource provider, and 2) determining thebest execution plan for a service requests. Both aspects re-quire full knowledge about the target operation and runtimecontext information.

1) Provider Selection: There are several parameters thatmake selecting where to offload computations a challengingdecision. These parameters include the possibility of net-work failure, diversity of potential resource providers andmobility of both users and providers. Our observation isthat dynamic mobile environments offer opportunities thatcould be considered when making offloading decisions. Forexample, a mobile device may use direct short-range com-munications to offload required computations to a nearbyprovider. This would avoid the long latency of the publiccloud. In this subsection, we explore various possibilitiesof remote hosting and propose the Follow-Me-Provider, adynamic resource provider selection scheme.

A mobile system can choose between multiple optionsfor computation offloading:

• Public cloud: Mobile systems may use a public cloudto fulfil their offloading demands through creatinga clone image or an on-demand remote executionenvironment. A clone image is a dedicated VM rep-resenting the mobile device on the cloud [8]. Thedevice sends offloading requests to the clone deviceon a separate thread and results are integrated withthe main execution thread on the mobile device.While this option incurs a fixed monetary cost forthe continuously running clone VM, it avoids theoverhead of creating and destroying VMs on-demand[31]. Data required for processing could be transferredto the clone device offline (i.e. before placing theoffloading request) or online during execution. Thedecision whether to download required data online oroffline depends on how frequently this data is used andhow much does it cost to store the data on the cloud.The service provider must choose between storagecost and potential performance gain. In case of onlinedata transfer, the clone device may download requireddata through a high speed interconnect with the dataprovider. This would significantly improve the overall



7

Results Req_1

Results Req_1Offl

oadin

g

Req_1

Offloading Req_1

Cloudlet_1Cloudlet_2Cloudlet_3

Device

Public Cloud

Mobil Cloud

Offl

oadi

ng

Req_2Res

ults

Req

_2

Fig. 4: Illustration of the Follow-Me-Provider selection scheme.

performance and reduce the response time. Using aclone image, data could be cached for subsequent of-floading requests, which results in more energy saving.The clone image is a better choice for mobile systemswith heavy and frequent offloading demands. The sec-ond option is to create a remote execution environment(i.e. VMs, proxies, stubs) on-demand upon makingoffloading decisions [7]. Although this seems to bemore realistic for users with low offloading demands,data transfer and management overhead of remoteexecution environments impact the overall latency andimply higher energy consumption.

• Cloudlets: A cloudlet is a hub that brings public cloudwithin close proximity of mobile users [28]. It can beviewed as the middle tier of a three tier architecture,mobile devices, cloudlets, and cloud infrastructures.Cloudlets can substitute the public cloud during net-work failures through offering essential services [32].With the recent developments of smart vehicular tech-nologies, capable mobile resource providers could alsooffer cloudlet services on the move.

• Mobile cloud: Mobile devices can collaborate to forma mobile cloud platform using virtualization tech-niques to offer resources on demand [2, 3]. Thisparadigm enables mobile devices to share their extraresources, mostly to offer location-based cloud-likeservices. While such an infrastructure might not be aspowerful as public cloud, the close proximity to of-floading entities improves communication latency. Forexample, a mobile user driving on a highway can takeadvantage of a platoon of smart vehicles moving along

to execute resource-intensive tasks through a directWiFi channel. Mobile cloud could be the only viableoption for infrastructure-less environments, such asduring disaster recovery or emergency situations.

To exploit the dynamicity of mobile environments, wepropose the Follow-Me-Provider selection scheme as illus-trated in Figure 4. The Follow-Me-Provider employs thecontext of both the mobile system and runtime conditions toestablish dynamic bindings between resource providers andcomputation offloading requests. The scheme utilizes themobility of the offloading system and the amount of timerequired for computation to determine the best resourceprovider to carry out the computations and the resourceprovider that may forward the results. For example, inFigure 4 the offloading Req 1 is best to be offloaded tocloudlet 1. When computations are complete, the resultsare better to be sent via cloudlet 3. However, for offloadingReq 2 the mobile cloud in the nearby vicinity is the bestchoice, taking advantage of the direct connection and beingin the communication range during required computationtime. The Follow-Me-Provider also takes into account thedata transfer requirements and the quality of the commu-nication link with the data provider.

2) Plan selection: The framework handles mobile ser-vices at the granularity of individual service operations,which are considered as the basic unit of computation thata service request may target. Assume that an operation(computing task) ε = µ + δ, where µ is the amount ofcomputation that must be performed on the local system(i.e. requires access to local resources) and δ is the amountof computation that can be carried out remotely. Any of



8

the two components may constitute the whole computingtask when the other component is not applicable (e.g.,δ = 0 when the whole computing task requires accessto a sensor in the mobile device). The remote componentof the task δ requires m memory space and e amountof energy to execute. The computational speed of themobile device is Sm (instructions/second), and Sc,ri isthe computational speed of a remote host server ri. Theexecution may involve communications between variousentities as shown in Figure 1, where B is the link bandwidthand din and dout are the sizes of data exchange betweentwo entities. The mobile system consumes power (in watts),pc for computing, pi while idle, and pt for transmittingdata (sending or receiving). Although, in practice, sendingdata entails more energy consumption than receiving, forthe purpose of this analysis, our model considers themidentical.

The time tm to process δ on the mobile system is:

tm = r × δ

Sm+

n∑j=1

dinj + doutjBj

(1)

where r is the number of invocations and n ≤ 2 indicatingthat the mobile system interacts with the user (servicerequester) over the link B1 and may download requireddata from the data provider over the link B2. If the taskrequires no data from the data provider, then din2 = 0 anddout2 = 0. The first term in Eq. (1) represents the executiontime on the mobile device and the second term indicates thedata transmission time. We assume that the data requiredfor multiple invocations is transferred only once.

If the task is offloaded, the time tc,ri to execute the taskon a remote server ri is:

tc,ri = r × δ

Sc,ri+

n∑j=1

dinj + doutjBj,ri

+ tα (2)

where n ≤ 5. The execution plan determines the value of n,indicating the possible interactions between various entities,as shown in Table II. The time tα represents any extra timerequired to build stubs or proxies in order to handle remoteexecution. Task offloading brings performance gain whentm ≥ tc,ri .

Similarly, the generic formula that calculates the energyconsumption on mobile system is given by Eq. (3). This isa rough estimate of the energy consumption, but the modelneeds only to project relative values among various plansin order to determine the most energy-efficient plan.

em = r × δ

Sm× pc +

n∑j=1

dinj+ doutjBj

× pt (3)

where n = 1 when the mobile system interacts only withuser with no data requirements from the data provider,n = 2 otherwise. The first term in Eq. (3) representsthe energy consumption by local computations, while thesecond term is the energy required for data transfer. Whenoffloading takes place, the energy consumption on the

mobile system is totally dependant on the offloading planand can be generally calculated by:

ec,ri = k × tc,ri × pi +n∑j=1

dinj+ doutjBj,ri

× pt (4)

where n ≤ 5, k = 0 when forward response is ‘ON’ andk = 1 if it is ‘OFF’. It’s worth mentioning that k = 0also when asynchronous communication is used, however,there will be an overhead for re-establishing the connection.Offloading incurs energy saving when em ≥ ec,ri .

The decision on whether to execute the service operationslocally must ensure that the available resources on themobile system satisfy the following constraints:1. m < mavail −mcr

2. e < eavail − ecrwhere mavail indicates the available memory on the mobiledevice, eavail indicates the remaining battery level, andboth mcr and ecr are user-defined parameters based onpreferences and context. These user-defined preferences areset to accommodate any special requirements, such as se-curing sufficient resources to maintain proper functionalityof critical applications. The framework enables users todynamically change these parameters according to theircontext.

Algorithm 1 illustrates the plan selection procedure fora particular computing task. The procedure excludes plansthat do not satisfy local resource constraints and returnsthe plan that yields the smallest response time. Inputs ofthis procedure are:- δ.profile, the resource consumption profile of thecomputing task (profiler).- list lcxt = {[B1, B2], Sm, pc, pi, pt,mavail, eavail},local context attributes of the mobile system (contextmanager).- R, list of potential resource providers (context manager).- P , possible offloading plans (execution planner).- list ecxt = {Sc, [B3, B4, B5],mavail, eavail}, theenvironment context for each potential resource providerr ∈ R (context manager).- {mcr, ecr}, user-defined constraints (context manager).

IV. IMPLEMENTATION DETAILS

We implement our validation prototype in Python.Python comes with a lightweight embedded HTTP serverthat is suitable for resource-constrained hosts, as well asmany libraries that facilitate Web service developmentsand deployments. We developed a RESTful Web ser-vice that exposes multiple functionality as Web servicemethods, each operation is represented with a uniqueURI in the form of http://base-address[host]/service-root/method-name. This service provides some image process-ing functionality ranging from low to high computational-intensity with various data transfer requirements, specif-ically Blur, Blend, Steganography, and Tag. The Bluroperation blurs all identifiable objects in a certain image.The Blend operation blends two images gradually from



9

Algorithm 1: Plan Selection Procedure.Input: δ.profile, R, P , list lcxt,list ecxt, {mcr, ecr}Output: {p, r}, //selected execution plan

and provider1 Function selectPlan(input list)2 //initialize holders of best plan andprovider

3 best p← null4 best r ← null5 min t← tm6 if e← em < (eavail − ecr) and m < (mavail −mcr)

then7 best p← p1 // local execution plan8 end9 foreach r in R do

10 foreach p in P do11 if m < (mavail −mcr) then12 t← tc13 e← ec14 if t ≤ min t and e < (eavail − ecr) then15 min t← t16 best p← p17 best r ← r18 end19 end20 end21 end22 return best p, best r

left to right so that the left edge is purely from the firstimage and the right edge is purely from the second image.The Steganography operation implements a steganographicmethod to hide a text message inside an image. The Tagoperation applies augmented reality techniques on an imagetaken by the device embedded camera. The image is labeledwith the current location and the Tag operation annotateobjects appear in the image, such as governmental build-ings, tourist attractions, public services, business facilities,etc. Augmented reality is known as a computation-intensiveprocess. This experimental setup represents a real casescenario of a photo sharing mobile service and is sufficientto illustrate the main aspects of our framework.

The Web service is deployed on a Samsung I9100 GalaxyII (Dual-core 1.2 GHz Cortex-A9, 1 GB RAM) with arooted Android 4.0.4 platform, connected to a WiFi net-work and is 3G-enabled. According to these specifications,M = 2400 MHz, pc = 0.9, pi = 0.3, and pt = 1.3 all inWatts per second. The cloud provider is represented by anAmazon EC2 virtual machine of the type ’m1.large’ with anEC2 pre-configured image (AMI) of ’Ubuntu Server 12.04LTS, 64 bit’. We placed one image and the message-to-hide on the mobile device. Another image is placed onthe cloud. The tagging information database is hosted on athird-party data provider. This data placement allows us totest a variety of execution plans of various service requests.

TABLE I: Summary of the experimental data placement.

Data Size LocationMessage to hide 150 KB Mobile DeviceImage 1 1.79 MB Mobile DeviceImage 2 1.84 MB CloudTagging Database 17 MB Data Provider

TABLE II: Possible execution plans for the offered serviceoperations.

Plan Exec. Location Exec. SequenceP1 M U → M → UP2 C U → M → C → M → UP3 C U → M → C → UP4 M U → M → D → M → UP5 M&C U → M → C → D → C → M → UP6 M&C U → M → C → D → C → U

Table I illustrates the experimental setup, indicating whereresources are located. We perform the experiments over avariety of wireless links with various levels of link qualitybetween the mobile device, the client, data provider and thecloud.

According to this setup and based on data placements,possible execution plans for the service operations areshown in Table II, where U represents the user, M rep-resents the mobile device, C denotes the cloud, and Dindicates the data provider. For example, P1 executes therequired operation locally on the mobile resources, whileP2 and P3 offload the execution to the cloud. However, inP3 the mobile system delegates the cloud to dispatch theresponse to the user directly. Not all plans are applicable forall operations, for example, P4 and P5 are applicable onlyfor the Tag operation, where a third party data provideris involved in the processing. The arrows show the datatransfer direction. In these experiments, we assume thatcommunications between different parties is carried out inan asynchronous mode [33] to overcome the possibility ofwireless link failures.

In our prototype, the profiler component uses severalPython libraries to analyze the behaviour of service op-erations and to generate a behaviour and resource con-sumption profile for each operation. Guppy-PE [34] is aPython library and programming environment that providesmemory sizing, profiling and analysis. It also includesa heap analysis toolset for memory related debugging.Guppy-PE provides the inter-function relations and showsthe count of function calls. We also found that the MemoryProfiler [35] Python library is efficient in the line-by-lineanalysis of memory consumption. The Memory Profilertool exposes a number of APIs, such as memory usage,that can be used by a third-party code to monitor thememory consumption. The cProfile [36] module is a built-in function that provides deterministic profiling for theCPU consumption of Python programs, from which ourprofiler determines the number of CPU cycles required forthe execution of service operations. Table III shows theresource consumption of the various exposed operations by



10

TABLE III: Resource consumptions of the various exposedoperations.

Operation CPU Time(m/c) Mem. Usage (MB)Blur 85/16 16.262Blend 106/24 19.141Steganography 146/40 12.363Tag 4867/1236 54.253

our Web service.The Context Manager uses Iperf [37] to monitor the

link quality between different communicating entities. Iperfis a tool that measures the bandwidth performance ofnetwork links. Unfortunately, there is no accurate toolor commercial instrument that can measure the powerconsumption per instruction or individual processes. Todate, the Android platform does not offer much with regardto energy consumption, but internal battery monitoring ona time-based level [38]. There are some recent researchefforts towards this direction [39]–[41], but none of theseefforts has offered a library accessible in the public do-main yet. For rough estimates of power consumption perAndroid process, we use the Android open source project,PowerProfile [42]. This computation estimate is sufficientfor comparison purposes between different execution plans.The context manager monitors the remaining battery powerand keeps track of the consumption profile of other runningapplications. At the time a service request is received, theframework ensures that the energy constraint would not beviolated by executing the service request whether locallyor remotely on the cloud. However, preferences are givento energy efficient execution plans. Otherwise, the requestis rejected.

V. EXPERIMENTAL VALIDATION

In our experiments, processing is performed on themobile, in the cloud, or both. Required data for processingmay be located at any of the three locations, mobile device,cloud, and data provider. According to the required processand where the data is located, our mathematical modeldetermines the best option to process the operation requestbased on the current context information and device re-source constraints. Options include moving required data tothe device or offloading the processing to the cloud with anyrequired data from the device, the data provider, or both.To validate the model recommendation, we experimentallytry all possible execution plans for a specific operationrequest and measure the end-to-end response time andenergy consumption. The end-to-end response time includescommunication, processing, and any overhead time to es-tablish a network connection or generate remote executionproxies. Our expectation is that the experimental resultsshould provide a strong backup of the model recommendedoption. In the normal practice, the mobile service executionenvironment uses the model to decide on the appropriateexecution plan of a particular service request.

Table IV shows an example of the actual average re-sponse time in contrast with the estimated response time

TABLE IV: Actual response time in contrast with estimatedresponse time and energy consumption of the variousservice operations.

Operation Exec.Plan

ActualRes.Time

Estimated

Res. time EnergyBlur P1 2205.39 2067.64 1.92

P2 2074.27 2000.78 2.46P3 1131.78 1102.33 1.29

Blend P1 2775.38 2556.58 2.63P2 1954.23 1737.74 2.16P3 1011.74 946.29 1.13

Steganography P1 2276.73 2138.98 1.98P2 2177.38 1983.50 2.42P3 1234.87 1122.04 1.30

Tag P4 12778.92 11142.56 10.68P5 2743.08 1964.33 2.06P6 2076.07 1510.62 1.47

and energy consumption of the various service operations.Experimental results validate the suggested plan by ouroffloading model for each operation, which is underlined.Although there is a marginal difference between the actualresponse time and the estimated values, the offloadingdecision maker is able to select the plan that the yieldsa better response time while satisfying the resource con-straints. We attribute this difference to the overhead timeof generating proxies and stubs for remote execution aswell as the delay incurred by the internal process of Webservers. In addition, the advanced CPU technologies such asSpeedStep, Hyper-Threading, Pipelining, and Overclockingmight also contribute to the deviation of the imperial valuesfrom calculated values with a certain offset. A system-specific calibration can capture such an offset and add itto the equation to make calculations accurate. However,estimates don’t have to be strictly accurate since our modelonly needs to project relative differences among plans toselect the proper one.

VI. EXPERIMENTAL RESULTS & DISCUSSIONS

The performance of the framework varies significantlyaccording to the several parameters including the datalocation, the link quality between different communicatingentities and the selected execution plan. The context man-ager plays an important role through real time monitoring ofresource consumption and network conditions on which theframework dynamically bases the choice of the the optimalexecution plan. The experiments are performed under threedifferent network conditions and settings: 1) the mobiledevice provider is connected through a fast WiFi link withan average Round Trip Time (RTT )=17 ms while the clientis wire connected, 2) both the mobile provider and the clientare connected through a slow WiFi connectivity with anaverage RTT=35 ms, and 3) both the provider and the clientare connected over 3G with an average RTT=280 ms. Inall settings the data service provider is linked to the cloudthrough a high speed interconnect with available bandwidth= 250.7 MB/s.



11

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

P1 P2 P3 P1 P2 P3 P1 P2 P3

WiFi (RTT=17) WiFi (RTT= 35) 3G (RTT=87)

Re

spo

nse

Tim

e (

ms)

Communications

Proccessing

Fig. 5: Mean response time of the Blur operation.

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

P1 P2 P3 P1 P2 P3 P1 P2 P3


Re

spo

nse

Tim

e (

ms)

Communications

Proccessing

Fig. 6: Mean response time of the Blend operation.

0

2000

4000

6000

8000

10000

12000

P1 P2 P3 P1 P2 P3 P1 P2 P3


Re

spo

nse

Tim

e (

ms)

Communications

Proccessing

Fig. 7: Mean response time of the Steganography operation.

0

5000

10000

15000

20000

25000

30000

35000

P4 P5 P6 P4 P5 P6 P4 P5 P6


Re

spo

nse

Tim

e (

ms)

Communications

Proccessing

Fig. 8: Mean response time of the Tag operation.

Figure 5 shows the mean response time of the Bluroperation with the possible execution plans in the threedifferent settings. In this operation, the required data islocated on the mobile device, which in our case has a littlelower processing capability in contrast with the selectedcloud server. This relatively small difference in processingcapability between the mobile provider and the cloud doesnot give the cloud an edge for non-computational intensiveprocesses, especially when communications take place overa low speed link. For the Blur operation request, only planP3 with the case of high speed WiFi link (1st setup) bringsperformance improvements. The difference between P3 andboth P2 and P1 captures the speedup opportunity that thecloud may offer due to computational offloading. The ex-perimental results reveal that P3 always yields better resultsthan P2, while P1 might be a better choice when large datatransfer is required, especially over slow interconnects. TheSteganography operation demonstrates a similar behaviorto the Blur request and is shown in Figure 7. Since all therequired data is available at the mobile provider and theoperation is not computationally intensive, local executionproves to be more efficient except when data transfer is veryfast, where offloading with P3 results in a faster responsetime and a lower energy consumption.

Figure 6 illustrates the results of executing a blendoperation request under the different settings. The executionof this service operation entails the transfer of one imageto the other side, where processing occurs. In this case,

offloading the computation to the cloud and allowing thecloud to dispatch the response to the user is always better.However, offloading achieves more than 3x overall speedupwith high WiFi connectivity. We also observe that the P3is the most energy efficient execution plan for the mobileprovider.

The image tagging operation entails a large amountof data transfer from the data provider as well as theoperation itself is computational-intensive. Resolving sucha service request on a resource-constrained mobile providersignificantly strains the limited resources and results ina high latency as shown in Figure 8. Offloading such arequest to the cloud improves the overall response timewith orders of magnitude. For example, P6 achieves 6.1x,5.5x and 4.6x speedup with settings 1, 2 and 3, respectively.The significant improvement can be attributed to the highspeed interconnect between the cloud and the third-partydata provider. In practice, the third-party data is mostlikely hosted on the cloud, which makes offloading a moreviable option. The tagging operation also is an exampleof distributed execution, where part of the operation isperformed on the mobile side, which is relating the imageto a current user location, while the object recognition andlabeling are performed on the cloud side.

The results highlight two main observations. First, of-floading does not always guarantee better performance,especially when the process requires high data transferover a low speed link. Second, offloading yields better



12

0

500

1000

1500

2000

2500

3000

Mobile System Laptop Lab Machine Amazon EC2

Re

spo

sne

Tim

e (

ms)

Resource Provider

Communications

Proccessing

Fig. 9: The performance of different resource providersin the Blur operation.

0

2000

4000

6000

8000

10000

12000

14000

Mobile System Laptop Lab Machine Amazon EC2

Re

spo

sne

Tim

e (

ms)

Resource Provider

Communications

Proccessing

Fig. 10: The performance of different resourceproviders in the Tag operation.

TABLE V: Potential resource providers for computationoffloading.

Attribute r1 r2 r3Description Laptop Lab Machine Amazon EC2

’m1.large’Architecture 64-bit 64-bit 64-bitSupport Type Mobile Cloud Cloudlet Public CloudSc(GHz) 2x2.4 2x2.8 2x2.8B2(MB/S) 32.0 10.5 6.3B4(MB/S) 14.5 45.5 250.8B5(MB/S) 3.2 20.3 20.3

performance when the cloud forwards the response to theuser directly and is responsible for collecting the necessarydata from the data cloud provider. The results also show thatthe option with the smallest response time is not alwaysthe choice of our model. For example, when the energyconstraint that is set by the user could be compromised,the response time becomes of less concern. In fact, the usermight resort to raising the critical energy threshold to securesufficient energy for essential functionality or temporallycritical applications, such as health care monitoring whenthe user is experiencing critical health conditions, or ifthe user is running a mobile-based navigation applicationwhile traveling. It is also worth noticing that P2 results insignificant energy consumption due to high data transferrequirements back and forth to the cloud.

To study the impact of provider selection, we run the Blur(low data transfer requirement) and Tag (high data transferrequirements) operations on a number of resource providerswith different settings. Table V shows the configuration andcontext information of these providers. In the experiments,we set the forward response always ‘ON’, so that theremote execution environment can send the response to theuser when offloading occurs.

Figure 9 shows the performance of the various potentialresource providers for the Blur operation. The lab machine(r2) outperforms the other resource providers due to thelow latency connection with the user and low data transferrequirement from the mobile system. Although the laptop(r1) has a higher speed connection with the mobile systemin contrast to other providers, the low quality connectionwith and user compromises the performance gain. If ‘for-

ward response’ is turned ‘OFF’, the laptop option wouldbe the most energy efficient and offer the best responsetime. Figure 10 shows the performance of the same resourceproviders for the Tag operation. In this case, the publiccloud (r3) brings the highest performance gain due tothe high speed interconnect with the data provider. Theother two options still perform significantly better than themobile device but less efficient than the public cloud. Thepublic cloud also continue to perform better even if the‘forward response’ is turned ‘OFF’. From these results,we conclude that data transfer requirements and networkconditions are significant attributes in making the offloadingdecision and selecting the most efficient resource provider.

VII. OVERHEAD ANALYSIS

There are a number of elements of our framework thatintroduce overhead that may or may not directly impactthe overall performance of computation offloading. In thissection, we provide a subjective analysis of the varioussources of overhead in our framework. We also show theframework’s footprint and how much overhead does theoperation of the framework incurs on mobile resources.

A. Context Management Overhead

Gathering and processing context information involveadditional overhead on mobile systems. However, we arguethat context information is a core component in currentand future mobile applications (e.g. Siri, Viber, GoogleNow, etc.). Therefore, context management exists in mobilesystems for adaptive and personalization purposes [43]. Theoverhead related to context management, both in energyconsumption and processing time, is not specific to ourframework. Furthermore, most of the context attributes arecollected offline on a regular basis, incurring no extra delayon offloading decisions.

B. Decision Making Overhead

The time taken to make a decision results in a directoverhead on computation offloading. When a task can beoffloaded to a remote server, the mobile system initiates thedecision making procedure to decide whether offloading



13

is beneficial. Making such a decision involves selectingthe best available provider and the best execution plan(according to our offloading model). The time to selecta resource provider is O(k), where k is the number ofavailable resource providers. Whereas the time to decideon the appropriate execution plan is O(n), where n is thenumber of possible plans (in our framework, n ≤ 5). Thecomplexity of our decision making algorithm is O(nk).Both k and n are relatively small and the delay overheadof decision making can be neglected in most cases. Basedon our implementation experience, the decision makingoverhead is within a fraction of a millisecond.

C. Creating Remote Execution Environment

Creating a remote execution environment is anotherindirect overhead on computation offloading. The overheadvaries according to the chosen offloading mechanism. Al-though the creation of this execution environment is carriedout at the server side, a fraction of delay is added tothe overall response time. The only exception is wheremobile systems are represented on the cloud with a clonedevice [8]. Shiraz et al. [31] study the diverse performancemetrics associated with the deployment of VMs in cloudcomputing infrastructures. Based on our experience, weobserve that instantiating a new VM instance on publiccloud (specifically Amazon EC2) takes 30 − 60 seconds.These numbers may be different for other cloud providers.In the case of RPC and RMI, such overhead is the same asif the computing task is invoked locally.

D. Framework Footprint

The framework operation adds extra overhead on mobiledevices but in return offers robust computation offloading.The amount of such an overhead depends on the modethe framework is running on. The framework is in activemode while evaluating the offloading decision of a servicerequest, whether offloading occurs or not. Otherwise, it runsin idle mode, where only the context manager is activein the background, gathering context information, and therequest/response handler is listening for incoming servicerequests. To estimate the overhead that the frameworkposes on mobile resources, we measure its footprint interms of CPU utilization, memory usage, storage space,and battery consumption in both active and idle modes.We remark that the measurement is carried out on themobile device concerning the framework’s footprint atthe mobile service provider’s side. This is to evaluate itsfeasibility on resource-constrained environments. Table VIshows the framework’s footprint on the mobile device. Weobserve that the battery consumption of the frameworkvaries during the active mode according to the runningactivities and the cost of acquiring required context. Thelower the cost of context acquisition, the lower the batteryconsumption of the framework while in active mode. Inthis experiment, we report the average battery consumptionmeasured by the PowerProfile toolkit while the frameworkis running in active mode. The high CPU and memory

TABLE VI: The framework’s footprint in terms of CPUutilization, memory usage, storage space, and averagebattery consumption of the mobile side portion of theframework in both idle and active modes.

Runningmode

CPU(%)

Memory(MB)

Storage(MB)

BatteryConsumption(j/minute)

Idle mode 2.3 24.2 3.2 0.45Active mode 11.6 65.6 3.2 1.2

footprint of the framework in the active mode is due tothe evaluation of execution plans and the decision makingprocess. Additionally, the context manager in the activemode acquires context information related to availablemobile resource providers, which as well contribute toCPU utilization and battery consumption. In general, theoverhead of our framework is much lower than regularcontext-aware mobile apps such as Google Now and Viber.For comparison purposes, the battery consumption of ourframework in the idle mode is 20 % lower than the WiFiscanner activity of the Android platform.

VIII. CONCLUSION

This paper presents a cloud-assisted mobile serviceframework. The objective is to augment the capabilities ofmobile devices to become reliable service providers. Theframework relies on a distributed service execution engineand a dynamic offloading scheme. Tasks that need to accesslocal resources are executed on the mobile provider, othertasks could be offloaded to the cloud execution engine, ifno constraints on remote execution exist. The frameworkincludes a profiler, context manager, execution planner,offloading decision maker, and distributed service execu-tion engine. The profiler characterizes the offered serviceoperations and generates resource consumption profiles.The context manager gathers local and environment contextinformation to make better decisions. The execution plannerinvestigates possible execution plans based on locationsof required data and current context information. Theoffloading decision maker selects the best execution planand the most efficient resource provider based on ourproposed Follow-Me-Provider scheme. The framework sup-ports forwarding the response to the user from the remoteexecution environment (when applicable) to maximize theperformance gain and reduce the energy consumption onthe mobile system. We developed a prototype to validatethe essential functionality of the framework and studythe performance aspects. Experimental results demonstratethat the proposed cloud-assisted service framework offerssignificant latency improvements and incurs less energyconsumption on the mobile system. Experiments also showthat the framework operation has a lightweight footprinton mobile systems in contrast with regular mobile apps.We plan to extend the framework’s functionality to supportinterrupted service execution due to connection failure.We also plan to enhance the Follow-Me-Provider selection



14

scheme to determine cloud resource providers that offertrusted execution environments.

REFERENCES

[1] M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies, “Thecase for vm-based cloudlets in mobile computing,” IEEE PervasiveComputing, vol. 8, pp. 14–23, Oct. 2009.

[2] E. E. Marinelli, “Hyrax: Cloud computing on mobile devices usingmapreduce,” Master’s thesis, Carnegie Mellon University, 2009.

[3] K. Stølen, “Using infrastructure-less wireless networks to synchro-nize data among mobile devices: Extending ubishare,” Master’s the-sis, Norwegian University of Science and Technology, Departmentof Computer and Information Science, 2013.

[4] T. Weerasinghe and I. Warren, “Empowering intermediary-basedinfrastructure for mobile service provisioning,” in IEEE Asia-PacificServices Computing Conference, pp. 414–421, 2009.

[5] M. Hassan, W. Zhao, and J. Yang, “Provisioning web services fromresource constrained mobile devices,” in Proceedings of the IEEE3rd International Conference on Cloud Computing, pp. 490–497,IEEE Computer Society, 2010.

[6] K. Yang, S. Ou, and H.-H. Chen, “On effective offloading servicesfor resource-constrained mobile devices running heavier mobileinternet applications,” Communications Magazine, IEEE, vol. 46,no. 1, pp. 56–63, 2008.

[7] E. Cuervo, A. Balasubramanian, D.-k. Cho, A. Wolman, S. Saroiu,R. Chandra, and P. Bahl, “Maui: Making smartphones last longerwith code offload,” in Proceedings of the 8th international confer-ence on Mobile systems, applications, and services, pp. 49–62, 2010.

[8] B.-G. Chun, S. Ihm, P. Maniatis, M. Naik, and A. Patti, “Clonecloud:Elastic execution between mobile device and cloud,” in Proceedingsof the sixth conference on Computer systems, (New York, NY, USA),pp. 301–314, ACM, 2011.

[9] S.-H. Hung, C.-S. Shih, J.-P. Shieh, C.-P. Lee, and Y.-H. Huang,“Executing mobile applications on the cloud: Framework and issues,”Computers & Mathematics with Applications, vol. 63, no. 2, pp. 573– 587, 2012. Advances in context, cognitive, and secure computing.

[10] B.-G. Chun and P. Maniatis, “Augmented smartphone applicationsthrough clone cloud execution,” in Proceedings of the 12th Confer-ence on Hot Topics in Operating Systems, (Berkeley, CA, USA),pp. 1–5, USENIX Association, 2009.

[11] N. Fernando, S. W. Loke, and W. Rahayu, “Mobile cloud computing:A survey,” Future Generation Computer Systems, vol. 29, no. 1,pp. 84 – 106, 2013.

[12] P. Bahl, R. Y. Han, L. E. Li, and M. Satyanarayanan, “Advancing thestate of mobile cloud computing,” in Proceedings of the 3rd ACMworkshop on Mobile Cloud Computing and Services, MCS ’12, (NewYork, NY, USA), pp. 21–28, ACM, 2012.

[13] K. Kumar, J. Liu, Y.-H. Lu, and B. Bhargava, “A survey ofcomputation offloading for mobile systems,” Mobile Networks andApplications, vol. 18, pp. 129–140, February 2013.

[14] G. Huerta-Canepa and D. Lee, “A virtual cloud computing providerfor mobile devices,” in Proceedings of the 1st ACM Workshop onMobile Cloud Computing & Services: Social Networks andBeyond, MCS ’10, (New York, NY, USA), pp. 6:1–6:5, ACM, 2010.

[15] I. Giurgiu, O. Riva, D. Juric, I. Krivulev, and G. Alonso, “Callingthe cloud: Enabling mobile phones as interfaces to cloud applica-tions,” in Proceedings of the ACM/IFIP/USENIX 10th internationalconference on Middleware, pp. 83–102, 2009.

[16] R. Kemp, N. Palmer, T. Kielmann, and H. Bal, “Cuckoo: Acomputation offloading framework for smartphones,” in The 2rdInternational Conference on Mobile Computing, Applications, andServices, pp. 59–79, Springer Berlin Heidelberg, 2010.

[17] K. Elgazzar, P. Martin, and H. S. Hassanein, “Empowering mobileservice provisioning through cloud assistance,” in Proceedings ofthe IEEE/ACM 6th International Conference on Utility and CloudComputing, pp. 9–12, 2013.

[18] H. Eom, P. S. Juste, R. Figueiredo, O. Tickoo, R. Illikkal, and R. Iyer,“Machine learning-based runtime scheduler for mobile offloadingframework,” in Proceedings of the IEEE/ACM 6th InternationalConference on Utility and Cloud Computing, pp. 17–25, 2013.

[19] J. Flinn, S. Park, and M. Satyanarayanan, “Balancing performance,energy, and quality in pervasive computing,” in Proceedings of the22nd International Conference on Distributed Computing Systems,pp. 217–226, 2002.

[20] M. Kristensen, “Scavenger: Transparent development of efficientcyber foraging applications,” in The IEEE International Conferenceon Pervasive Computing and Communications (PerCom), pp. 217–226, March 2010.

[21] K. Kumar and Y.-H. Lu, “Cloud computing for mobile users: Canoffloading computation save energy?,” Computer, vol. 43, pp. 51–56,April 2010.

[22] K. Elgazzar, P. Martin, and H. Hassanein, “Enabling mobile webservices provisioning,” Tech. Rep. 2012-598, Queen’s University,Kinston, ON K7L 3N6, October 2012.

[23] H. J. La and S. D. Kim, “A conceptual framework for provi-sioning context-aware mobile cloud services,” in Cloud Computing(CLOUD), 2010 IEEE 3rd International Conference on, pp. 466–473, July 2010.

[24] J. Ahn, J. Heo, S. Lim, and W. Kim, “A study on the applicationof patient location data for ubiquitous healthcare system based onlbs,” in 10th International Conference on Advanced CommunicationTechnology, vol. 3, pp. 2140 –2143, 2008.

[25] C. Xin, “Location based service application in mobile phone seriousgame,” in International Joint Conference on Artificial Intelligence,pp. 50 –52, April 2009.

[26] J. Diaz, R. de A Maues, R. Soares, E. Nakamura, and C. Figueiredo,“Bluepass: An indoor bluetooth-based localization system for mobileapplications,” in The IEEE Symposium on Computers and Commu-nications (ISCC), pp. 778 – 83, 2010.

[27] B. Altintas and T. Serif, “Indoor location detection with a rss-basedshort term memory technique (knn-stm),” in IEEE International Con-ference on Pervasive Computing and Communications Workshops(PERCOM Workshops), pp. 794 –798, 2012.

[28] M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies, “The casefor vm-based cloudlets in mobile computing,” Pervasive Computing,IEEE, vol. 8, no. 4, pp. 14 –23, 2009.

[29] T. Jin, G. Noubir, and B. Sheng, “Wizi-cloud: Application-transparent dual zigbee-wifi radios for low power internet access,”in The 30th Conference on Computer Communications,Shanghai,China, INFOCOM ’11, 2011.

[30] Android SQLite, http://developer.android.com/reference/android/database/sqlite/package-summary.html. [Accessed: Jul. 9, 2013].

[31] M. Shiraz and A. Gani, “Mobile cloud computing: Critical analysisof application deployment in virtual machines,” in Proceedings of theInternational Conference on Information and Computer Networks,2012.

[32] M. Satyanarayanan, G. Lewis, E. Morris, and K. Ha, “The roleof cloudlets in hostile environments,” IEEE Pervasive Computing,vol. 12, no. 4, pp. 40–49, 2013.

[33] J. Fuller, M. Krishnan, K. Swenson, and J. Ricker, “Oa-sis asynchronous service access protocol (asap),” May 182005. http://www.oasis-open.org/committees/documents.php?wgabbrev=asap. [Accessed: Jul. 9, 2013].

[34] Guppy-PE, https://pypi.python.org/pypi/guppy/. [Accessed: Jul. 9,2013].

[35] Memory Profiler, https://pypi.python.org/pypi/memory profiler. [Ac-cessed: Jul. 9, 2013].

[36] The Python Profilers, http://docs.python.org/2/library/profile.html.[Accessed: Jul. 9, 2013].

[37] Iperf, https://code.google.com/p/iperf/. [Accessed: Jul. 9, 2013].[38] Android Battery Monitoring, http://developer.android.com/training/

monitoring-device-state/battery-monitoring.html. [Accessed: Jul. 9,2013].

[39] A. Rice and S. Hay, “Measuring mobile phone energy consumptionfor 802.11 wireless networkingy,” Pervasive and Mobile Computing,vol. 6, no. 6, pp. 593 – 606, 2010.

[40] C. Yoon, D. Kim, W. Jung, C. Kang, and H. Cha, “Appscope:Application energy metering framework for android smartphonesusing kernel activity monitoring,” in USENIX Annual TechnicalConference, 2012.

[41] A. Carroll and G. Heiser, “An analysis of power consumption ina smartphone,” in Proceedings of the 2010 USENIX conference onUSENIX annual technical conference, (Berkeley, CA, USA), pp. 21–21, USENIX Association, 2010.

[42] Andoid PowerProfile, http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.2 r1.1/com/android/internal/os/PowerProfile.java. [Accessed: Jul. 9, 2013].

[43] K. Elgazzar, H. S. Hassanein, and P. Martin, “Daas: Cloud-basedmobile web service discovery,” Pervasive and Mobile Computing,no. 0, pp. 1 – 18, 2013.

Cloud-Assisted Computation Ofﬂoading to Support … Computation Ofﬂoading to Support Mobile...

Documents

Transcript of Cloud-Assisted Computation Ofﬂoading to Support … Computation Ofﬂoading to Support Mobile...