MOCCAA: A Delta-synchronized and Adaptable

Mobile Cloud Computing Framework

Harun Baraki, Corvin Schwarzbach, Malte Fax and Kurt Geihs

Distributed Systems Group, University of Kassel, Wilhelmsh

oher Allee 73, Kassel, Germany

Keywords:

Mobile Cloud Computing, Delta Synchronization, Resource Management System.

Abstract:

Mobile Cloud Computing (MCC) requires an infrastructure that is merging the capabilities of resource-

constrained but mobile and context-aware devices with that of immovable but powerful resources in the cloud.

Application execution shall be boosted and battery consumption reduced. However, a solution’s practicabi-

lity is only ensured, if the provided tools, environment and framework themselves are performant too and

if developers are able to adopt, extend and apply it easily. In this light, we introduce our comprehensive

and extendable framework MOCCAA (MObile Cloud Computing AdaptAble) and demonstrate its effective-

ness. Its performance gain is mainly achieved through minimized monitoring efforts for resource consumption

prediction, scalable and location-aware resource discovery and management, and, in particular, through our

graph-based delta synchronization of local and remote object states. This allows us to reduce synchronization

costs signiﬁcantly and improve quality dimensions such as latency and bandwidth consumption.

1 INTRODUCTION

Companies utilize the computational power of cloud

resources, for example, to speed up their processing,

to compensate peaks under high loads or to reduce

costs by consumption-based billing and simpliﬁed

maintainability. Any such support by Cloud Compu-

ting would also extend the capabilities of resource-

constrained mobile devices. While mobile devices

have to avoid energy and computational intensive ap-

plications, clouds are designed for these particular use

cases.

Although at ﬁrst glance both Mobile Computing

and Cloud Computing ﬁt perfectly together, many

challenges have to be overcome to trigger a wide and

straightforward use of MCC. The core questions in

MCC are what to ofﬂoad (which part of a mobile ap-

plication) and how, when and where to execute the

resource-intensive part remotely. In the last few ye-

ars, several approaches have been developed and exa-

mined in the research community. Most of them deal

with one or two aspects of MCC, but do not consi-

der the downsides and effects for the other dimensi-

ons. Approaches like (Chun et al., 2011) and (Yang

et al., 2014) relieve the developer by deciding auto-

nomously what to ofﬂoad, but need synchronized Vir-

tual Machine (VM) images and adapted operating sy-

stems. Other concepts like (Kemp et al., 2012) and

(Giurgiu et al., 2009) bear on the developer’s expe-

rience and extensive code adaptations to be able to

ofﬂoad application parts. The approach of Ou et al.

(Ou et al., 2006) calculates precisely what to ofﬂoad

where, but does not consider the high monitoring and

synchronization costs. Further related works are dis-

cussed in detail in section 8. The key point is that a

comprehensive solution for MCC must handle all core

questions mentioned above simultaneously. Nonethe-

less, the solution has to be applicable to a wide range

of mobile applications and should neither slow down

the development of applications considerably nor af-

fect their usage by the end user. The objective of our

work is to provide a ﬂexible but also comprehensive

and comprehensible solution where each of the follo-

wing parts can be coordinated easily by the whole fra-

mework and where each part contributes to the overall

efﬁciency of the system:

• DRMI: An asynchronous Remote Method Invoca-

tion that applies our performant delta synchroni-

zation to ensure state consistency between client

and server.

• InspectA: A tool that helps developers to detect

resource-intensive methods, to create prediction

functions for their resource consumption and to

minimize monitoring costs by extracting the most

relevant features for prediction.

136

Baraki, H., Schwarzbach, C., Fax, M. and Geihs, K.

MOCCAA: A Delta-synchronized and Adaptable Mobile Cloud Computing Framework.

DOI: 10.5220/0006701101360147

In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018), pages 136-147

ISBN: 978-989-758-295-0

• MOCCAA-RMS: A self-conﬁguring, scalable and

distributed resource management and discovery

system.

• MOCCAA annotations: Android/Java annotations

that enable applications, for instance, to execute

methods through DRMI on one or more remote

resources found by MOCCAA-RMS whenever a

prediction function of InspectA recommends it.

On the one hand, straightforward mechanisms and

tools shall allow developers to apply MCC also for

small and simple scenarios. However, these mecha-

nisms can be combined to implement more complex

scenarios. On the other hand, our most basic mecha-

nism, an asynchronous RMI invocation, shall be as

fast and compact as possible, especially for typical

MCC payloads, that is, large messages that are pro-

cessed mutually on client and server side. Examples

of use illustrate the course of action and prove the

practicability of our solution. In addition, our expe-

riments show a signiﬁcant reduction of latency and

message size compared to the default Java RMI.

The remainder of this paper is organized as fol-

lows. Section 2 provides ﬁrst an overview of our fra-

mework and introduces each component brieﬂy. In-

spectA, MOCCAA-RMS, the MOCCAA annotations

and DRMI are explained in Section 3 to 6. Section 7

presents our experiments and their results. Section 8

discusses relevant and related works. Section 9 will

conclude this work with a summary and ongoing and

future work.

2 FRAMEWORK OVERVIEW

A fundamental requirement in MCC is that applicati-

ons shall also be executable without a network con-

nection. In general, this implies that the whole ap-

plication is installed on the mobile device. In case

sufﬁcient remote resources are accessible, parts of an

application are deployed and executed remotely. The

granularity of these parts varies depending on the ap-

proach. Our approach works at the level of method

and object granularity.

At design time the developer has to decide which

method and object can be ofﬂoaded. Our tool In-

spectA will help him to detect objects and methods

that are very resource consuming and that do not have

cyclic dependencies on their invoking methods. An

unfavorable constellation would be, for instance, a

method A.a1() calling a method B.b1() while B.b1()

itself would call, maybe indirectly, method A.a1(). In

that case, B.b1() should only be executed remotely

when A.a1() is ofﬂoaded too. Section 3 presents In-

spectA in detail.

Having established the candidate objects and met-

hods, the developer has to annotate them as shown

in Listing 1 and 2. The annotation @InjectOfﬂoa-

dable is used to mark the concrete object reference.

In this way, our framework is injecting a proxy that

holds an instance of the class referred to. Dependency

Injection is well-known to most developers and does

not impose a high burden on them. As demonstrated

in Listing 1, the objects’ methods can be invoked as

usual and do not need any special treatment.

pu bl ic class My Cl as s {

@InjectOffloadable

Co m pl exC alc co mpl ex C al c ;

pu bl ic int m1 ( int p1 , St ri ng p2 ) {

co m pl exC alc . se tVar1 (p2 );

co m pl exC alc . d oC omp lex Cal c ( p1 ) ;

...

Sy st em . o ut . prin t ( c omp le x Ca lc .

ge tV ar1 () );

}

Listing 1: Annotating the ofﬂoadable object.

The injection is implemented through bytecode

manipulation and carried out by means of the Javas-

sist library (Chiba, 1998). The injected proxy inter-

cepts all method invocations on the instantiated ob-

ject and decides whether a local or a remote execution

shall take place. The default behaviour proceeds with

a local execution. In contrast, invocations of methods,

which are labelled with the @Ofﬂoad annotation, lead

to further analyses that evaluate the availability of ap-

plicable remote resources given through the @Ofﬂo-

adServers annotation.

@Offloadable

@OffloadServers({ipAdress1, ipAdress2})

pu bl ic class Co m pl exC al c {

St ri ng v ar1 ;

@Offload

pu bl ic v oid doC omp le x Ca l c ( int p1 ) {

...

}

...

}

Listing 2: Annotating the class and the method.

This behaviour can be adapted through a plugin

architecture. Adding the annotation @OfﬂoadEva-

luator(...) to an @Ofﬂoad method, a class imple-

menting our Evaluator interface can be speciﬁed. The

MOCCAA: A Delta-synchronized and Adaptable Mobile Cloud Computing Framework

137

Evaluator will then be instantiated by the proxy and

used whenever the @Ofﬂoad method is invoked. The

method parameters and the proxied object are handed

over to the Evaluator so that it is capable to decide

with the aid of the current content and size of the para-

meters and object whether a local or remote execution

are favorable.

Assuming that the server part of our framework is

installed on the addressed servers, this conﬁguration

is already sufﬁcient to employ basic MCC functiona-

lity. Whenever a method is called remotely, the actual

proxied object will be synchronized with the server

side. The ﬁrst time, the whole object graph will be

transferred. After executing the method, the delta will

be transferred back and applied to the object graph on

client side. A second method invocation on the same

object would just transfer the delta from client to ser-

ver and subsequently call the method. Section 6 ex-

plains further details.

Although this conﬁguration provides basic MCC

functionality, it evinces a lack of ﬂexibility when it

comes to the distribution of workload. Servers might

be well utilized, suffer from bad communication links

or even be down so that alternative servers have to be

employed. Section 4 extends therefore our framework

with server monitoring and distributed registries. In

addition, many scenarios could beneﬁt from a parallel

processing of the workload on one or multiple servers.

To support this, we introduce in Section 5 additional

annotations that allow developers to split tasks and

deploy them on multiple servers and aggregate the re-

sults on one server or one device. Flexibility is also

demanded when it comes to the consideration of devi-

ces with different or varying resource capacities. The

decision to ofﬂoad may depend on the current perfor-

mance of the mobile device. Section 3, in particular

section 3.2, explains how the resource consumption

of methods can be estimated in advance and demon-

strates with the aid of an Evaluator example its use in

this sense.

3 InspectA

3.1 Ofﬂine Analysis

The InspectA tool helps developers in analyzing their

applications in a ﬁne granular way. The current ver-

sion works for Java 1.8 and Android SDK versions

greater than or equal to 23 (Android 6.0). Starting In-

spectA on the developer’s computer, it will connect

with the Android Debug Bridge (adb). This allows

him to display running applications and their overall

resource consumption within a given time frame. The

Figure 1: Application information.

Figure 2: Monitor view listing all running applications and

their overall resource consumption in a given time frame.

initial views are depicted in Figure 1 and 2. Infor-

mation such as CPU and memory consumption can

be listed, but also details like obtained and demanded

permissions and package speciﬁcs.

To obtain more detailed information, the develo-

per has to include our InspectA.aar archive and our

Gradle commands into the build process. These start

an AspectJ compiler that weaves Aspects around the

applications’ methods. After each method the current

thread’s CPU time, the memory usage, the battery sta-

tus and the execution time are recorded. During the

application’s execution a dump is created on the mo-

bile device that can be imported into InspectA. Figure

3 shows the detailed view with method granularity.

The information can now be sorted in descending or-

der so that methods with high memory, CPU, battery

or time consumption can be detected easily. Indeed,

Android provides so called tracers for battery, me-

mory and CPU. However, the dumps are created se-

parately for each dimension and the analysis requires

much experience.

Sector 4 in Figure 3 displays the invocation path

of the monitored methods. All information, inclu-

ding the invocation path and frequency, are stored as a

GraphML ﬁle that can be further analyzed. Listing 3

presents an excerpt of a GraphML ﬁle that is showing

a single invocation of MainActivity.mapGUI by Mai-

nActivity.onCreate. Section 3.2 indicates how this ﬁle

can be utilized to generate prediction functions that

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

138

estimate the future resource consumption by means

of certain monitoring points. Such functions can be

applied in Evaluators as decision-making support.

<? xml ve rs io n = "1 .0 " e nc oding =" UTF -8 "

st a nd alo ne =" no "? >

< gra ph ml xmlns = ". .. " ... >

< gr ap h id =" de . i uv os oft . an dr oid .

in spe ct a " e dg ede fa u lt =" d ir ected " >

...

< key id =" b at te ry " fo r =" n ode " attr . n ame

=" b at te ry " a ttr . type =" d ou bl e "/ >

< key id =" ram " for =" n ode " at tr . n ame ="

ram " at tr . t ype =" double "/ >

< key id =" cpu " for =" n ode " at tr . n ame ="

cpu " at tr . t ype =" lo ng "/ >

< gr ap h id = "0" ed g ed efa ult =" d ire ct ed " >

< da ta key =" n ame " > de . i uv osoft . an droid .

in spe ct a . t es ta pp . act iv it y .

MainActivity</data >

< no de id = "1" >

< da ta key =" n ame " >onCreate</data >

< da ta key =" c ounte r " >1 </ data >

< da ta key =" t ime " > 34 73663 03 </ data >

< da ta key =" b atter y " > -1.0 </ data >

< da ta key =" ram " >5 .0 19 0162658 </ data >

< da ta key =" cpu " > 16081 3228 < / data >

</ node >

< no de id = "2" >

< da ta key =" n ame " >mapGUI</data >

< da ta key =" c ounte r " >1 </ data >

< da ta key =" t ime " >1107 29 </ data >

< da ta key =" b atter y " > -1.0 </ data >

< da ta key =" ram " >0.0 </ data >

< da ta key =" cpu " >1 021 88 </ data >

</ node >

...

</ graph >

...

< ed ge id =" 4" s ou rc e ="1" t ar ge t =" 2"/ >

...

</ graph >

</ graph ml >

Listing 3: GraphML ﬁle generated by InspectA.

The ﬁnal step at this stage is to annotate the

resource-intensive methods and the associated ob-

jects. The developer may apply now a check for cy-

clic invocations between the invoking method and the

remote or annotated method. For this purpose, we

do not investigate the previously created GraphML

dump since it is very likely that it does not cover all

possible execution paths. Instead, a System Depen-

dence Graph is generated by means of the static code.

Using the JOANA library (Graf et al., 2013), Android

as well as Java applications can be analyzed. The JO-

Figure 3: Invocation graph and method details. Battery con-

sumption is set to -1 in case the mobile device is connected

to the power supply.

ANA API allows us to query whether the invoking

method is reachable by the invoked method. The de-

veloper will be informed in case a breach is detected.

Adapting and restructuring the code is recommended

then.

3.2 Resource Estimation

In a separate work, we develop and examine different

prediction techniques for our Evaluators. As the Eva-

luators are part of the framework and its utilization,

we discuss and present the general procedure brieﬂy

in this section.

A straightforward method to determine the

resource-intensive parts of an application would be to

take the average or maximum resource consumption

of each method during ofﬂine tests and mark those

with a high consumption as potential candidates for

ofﬂoading. Such a pure ofﬂine proﬁling is used, e.g.

in (Giurgiu et al., 2009) and (Chun et al., 2011), and

was also applied in the previous section. The ab-

sence of online monitoring costs is its strength, the

lack of ﬂexibility required for different devices and

scenarios its drawback. Other approaches ask the de-

velopers to mark the resource-intensive parts and the

parts that have to be monitored (Cuervo et al., 2010;

Kemp et al., 2012) or monitor each aspect of the run-

ning application (Ou et al., 2006). However, moni-

toring quality dimensions like CPU utilization, me-

mory consumption and battery usage requires itself a

signiﬁcant amount of resources and should be avoi-

ded during runtime. In addition, operating systems

may deny or not provide such information during run-

time. This is also true for Android 7 and upper ver-

sions which refuse access to such information due to

security reasons. The following approach tries to mi-

MOCCAA: A Delta-synchronized and Adaptable Mobile Cloud Computing Framework

139

nimize online monitoring costs and simultaneously to

retain a good estimation of the future resource de-

mands of annotated methods.

While InspectA was weaving aspects into the de-

veloper’s code to monitor, amongst others, the CPU

time and memory consumption of each method, now

the analysis during design time obtains the size of

passed parameters too. In case of primitive data ty-

pes such as Integer and Double, the value is taken

as size. In case of arrays and collections, the num-

ber of contained elements is recorded. The developer

should then run his application with various input data

so that variable execution times are measured. Since

testing should be anyway part of the application de-

velopment, this process step can also be included in

JUnit tests.

The order of method invocations is recorded for

each thread so that graphs are obtained. The edges of

a graph represent the communication between met-

hods, in particular, the frequency of invocations and

the parameters and their sizes. Methods are conside-

red as vertices annotated with their consumed time,

battery, memory and CPU time.

Subsequently, a Correlation-based Feature Se-

lection (CFS) (Hall, 1999) is applied that is intended

for ﬁnding relevant monitoring points whose featu-

res, particularly parameter sizes and execution times

of methods, correlate with the resource consumption

of an annotated resource-intensive method that is in-

voked later in the course of execution. It is possible

that a high number of methods exhibits a strong cor-

relation which would correspondingly lead to a high

number of monitoring points. However, using CFS,

features that correlate with each other, and, hence, are

redundant information, are penalized. This leads to a

reduced set of potential monitoring points.

Additionally, we identify features that are suitable

to predict the resource consumption of multiple anno-

tated methods. Figure 4 depicts a typical execution

path. Method 1 is invoking successively methods 2

to 5. The latter invokes methods 6 and 7. Assuming

that method 4 and 7 are annotated, method 2 and 3

and the parameters of method 1 (method 1 cannot be

considered completely as it is ﬁnished after method

4) come into question to predict methods 4 resource

consumption. Accordingly, method 2, 3, 4 and 6 and

the parameters of method 1 and 5 can be considered

for method 7. By combining a Wrapper feature sub-

set selection (Kohavi and John, 1997) with CFS, we

reward those monitoring points that can serve as fe-

ature for various annotated methods. In the example

of Figure 4, method 2 to 3 and the parameters of met-

hod 1 are considered preferably as they build the path

intersection for method 4 and 7.

12.07.2017

AFrameworkfor CodeOffloading inMCC

2 5

Method

Aspect

Input parameter

Figure 4: Monitoring method 1, 2 or 3 and their inputs may

be sufﬁcient for estimating the resource consumption of fol-

lowing methods 4 and 7.

To further reduce monitoring costs, we restrict the

feature selection by involving exclusively the met-

hods’ execution times and parameter sizes. Other di-

mensions like CPU times and memory and battery

consumption are ignored. However, during design

time we include the latter dimensions for annotated

methods. The target is to associate them with exe-

cution times and parameter sizes of previously called

methods.

Therefore, we apply ﬁnally prediction techniques

like multivariate adaptive regression splines (Fried-

man, 1991) and neural networks. Being aware of the

relevant features, for each annotated method a mo-

del is built at design time. In case of regression spli-

nes, the determined basis functions of a regression

function will retain their form during runtime. Ho-

wever, since different mobile devices may behave dif-

ferently, the weights and knots of the basis functions

are adapted during runtime if signiﬁcant discrepan-

cies occur. A detailed description including an eva-

luation of different prediction techniques is part of a

parallel work.

Lastly, an Evaluator can call the prediction functi-

ons to receive the estimated resource consumption of

a given annotated method. This information cannot

only be used for deciding about the ofﬂoading step,

but also to ﬁnd suitable servers. The following section

provides further details.

4 MOCCAA-RMS

Knowing the resource demands of the client, a mat-

ching server has to be searched that can process the

user request. Ofﬂoading shall not only reduce the

energy consumption of the mobile device but should

also reduce the overall response time of the applica-

tion. To achieve that, the following aspects and requi-

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

140

rements have to be considered.

A fast resource discovery requires registries that

have a low time and message complexity to ﬁnd suit-

able servers. What is even more important, is that

servers supporting the application’s execution are as

close as possible to the client. While the resource dis-

covery is just needed at the beginning, an intensive

communication may take place between the client and

its ofﬂoaded part on the discovered server.

A further important requirement is the ease of use

for app developers. A reliable Resource Management

System that automatically conﬁgures and monitors

servers and registries and allocates tasks is desirable.

Furthermore, it should scale well whenever more re-

sources are added to the system.

Assuming that a developer starts with one server,

mostly due to testing or during design time, he has

ﬁrst to install our framework on it. In brief, the fra-

mework encompasses ﬁrstly a Java application that is

loading Java archives and invoking methods on them

received through our Delta-synchronized RMI. It is

accessible through REST interfaces for application

clients (e.g. to search servers and upload jars) and ot-

her collaborating servers (e.g. to search for nearby re-

gistries and conﬁguration information). Furthermore,

it monitors currently running Java applications and

the available and used resources of the local system

by making use of the SIGAR library

. JMS (Java

Messaging Service) is used to receive and send aggre-

gated monitoring data from and to other servers. De-

tailed monitoring data is stored locally in MongoDB

a NoSQL database.

If the developer wants to extend the system by ad-

ding a further server, he just has to install the same

framework and setting the IP address and credentials

of the ﬁrst server in a conﬁguration ﬁle. This is also

true for any further server so that a VM image can

be created and deployed to newly added servers. The

following sections explain how the overall system is

designed and how it is growing, monitoring and con-

ﬁguring itself automatically.

The ﬁrst server is also considered as the root

of our resource management and discovery system

MOCCAA-RMS. The developer can change this by

adapting a conﬁguration ﬁle. The servers, which may

serve as working nodes as well as registries that redi-

rect to other nodes, are structured hierarchically. New

servers entering the system are asking through REST

the root node for the closest registry. This is determi-

ned through an IP to Geo localization. The selected

registry may further redirect to child registries by the

same procedure. The ﬁnally chosen registry can re-

http://support.hyperic.com/display/SIGAR/Home

https://www.mongodb.com

17.02.2016

AFrameworkfor CodeOffloading inMCC

Own Approach– Step 3– TheSystemis growing and growing

synchronized

Figure 5: A user smartphone making use of the hierarchy

of registries. Orange nodes represent leaf registries, grey

nodes servers that are monitored.

Figure 6: Registry (System Information) with one child (Sy-

stem Information Aggregated).

ject if it cannot handle more servers due to bandwidth,

processing power or other constraints. In that case,

depending on the capacity of the upper registries, a

new level or a new sibling registry will be created.

For this purpose, a clustering will rearrange the as-

signment of nodes to their registries, taking into ac-

count the newly-added server as a registry, and adap-

ting the registries’ databases. Our current implemen-

tation is therefore using the k-medoids clustering al-

gorithm (Kaufman and Rousseeuw, 2009).

Registries have to know about the free resources

of their subsequent nodes to be able to assign a user

request to a server. However, monitoring all servers

periodically and reporting to registries could over-

strain bandwidth and upper level nodes. Message and

time complexity would rise considerably with a gro-

wing number of servers. In case of MOCCAA-RMS,

Figure 7: Server details on a map.

MOCCAA: A Delta-synchronized and Adaptable Mobile Cloud Computing Framework

141

only the second last nodes, i.e. the parents of the leaf

nodes, are informed about the status of the servers.

These registries are highlighted in orange in Figure 5.

As soon as a leaf node is assigned to a user request,

the orange parent node is subtracting the estimated

resource consumption from the servers current status

vector available in the registries database (e.g. me-

mory, CPU). The resulting vector stands for the re-

maining free resources on the server. If the require-

ments proﬁle is changing during the interaction of the

client with the server or when the client ﬁnished, the

server will report the modiﬁcation to the parent node.

Nonetheless, servers also send through JMS every mi-

nute a heartbeat message and aggregated monitoring

data to their parent nodes to inform them about their

reachability and to correct estimated values.

The parent registries (the red node in Figure 5) of

the second last nodes (orange nodes) and upper level

registries (black nodes in Figure 5) only get an aggre-

gated summary (vector) of the free resources of their

child nodes. In the example of Figure 5 that would be

the aggregated values of the three orange nodes that

serve as registries for the grey nodes. Updates are

only sent when major changes with respect to the last

report occur. This avoids a higher number of messa-

ges at higher levels of the hierarchy and allows load

balancing.

Due to reliability reasons, sibling nodes know

each others IP addresses and the grandparents one au-

tomatically through their parent node. Whenever a

parent node is failing or removed, child nodes elect a

new parent node.

A client is usually querying the last contacted lo-

cal registry, if he did not move more than a conﬁgu-

red distance and if it is not the ﬁrst request, other-

wise a close registry has to be found through upper

level registries ﬁrst. The chain of registries between

root node and leaf node are also reported to the client.

Listing 4 shows the parameters that are sent by the

client to a registry’s REST interface. If a local regi-

stry does not ﬁnd any suitable servers, the request is

redirected to the upper registry. This registry knows

roughly about the situation of his child registries and

their succeeding servers. It can be thought of as a

graph whose edges are annotated with ﬂow capaci-

ties. The request will then be redirected to a registry

with servers that are underutilized.

Instead of listing potential servers with @Ofﬂo-

adServers, the developer has to indicate the root regi-

stry’s address through @OfﬂoadRegistries in the ap-

plication. In case redundant root registries are availa-

ble, all of them can be implied. Our framework offers

additionally a Java Web Archive that can be deployed

on an application server. It accesses the root node

and traverses step by step the child registries. It crea-

tes an overview for the developer or an administrator

and informs them about servers that are down or not

accessible anymore. Figure 6 shows a root node with

one child node. A map view is provided too (Figure

7). It should be noted, that a registry is considering its

own free resources as available for clients too.

@GET

@P ath (" s er v er _ se a rc h ")

@P rod uc es ( M ed ia T yp e . A P PLI CAT ION _JS O N )

pu bl ic Se rve rI n fo getServer (

@Q u er yPa ram (" a pp_ na me ") St ri ng

app_n ame ,

@Q u er yPa ram (" ap p_v ers io n ") S tr in g

ap p_ ve rs ion ,

@Q u er yPa ram (" l ati tu de ") do ub le lat ,

@Q u er yPa ram (" lo ngi tu de ") do ub le lon ,

@Q u er yPa ram (" ra m ") lo ng ram ,

@Q u er yPa ram (" cp u ") lo ng cpu ,

@Q u er yPa ram (" me s sa ge_ siz e ") lo ng

me s sa g e_ siz e ) {. .. }

Listing 4: Method signature of the registries search

method.

MOCCAA-RMS is tailored to use cases where

the consumption can be roughly estimated. This al-

lows an efﬁcient monitoring and discovery of servers.

A conﬁguration by the developer or administrator is

only needed when default values and thresholds shall

be changed.

5 PARALLEL EXECUTION

While a single @Ofﬂoad annotation supports the re-

mote execution of a method on a server, a chain of

@Ofﬂoad methods allows the server to ofﬂoad the re-

ceived object again and execute the next method on

another server.

Listing 5 shows two methods doComplexCalc and

doComplexParallelCalc. While doComplexCalc is

executed on the server with the address ipAddress1,

it delegates the execution of doComplexParallelCalc

to another server. The annotation @Splittable effects

that the array is splitted into multiple arrays. Hence,

the method doComplexParallelCalc is invoked on the

servers with the addresses ipAddress2, ipAddress3,

ipAddress4, but each of them receiving another part of

the array. Each of them could store its results in anot-

her ﬁeld or another part of an array. The implemen-

tation makes use of the OpenHFT Chronicle Engine

to distribute the tasks. Our annotation is experimental

https://github.com/OpenHFT/Chronicle-Engine

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

142

as there is no check for side effects. The developer

should be aware of the Bernstein conditions listed in

(Bernstein, 1966) and, in speciﬁc cases, further condi-

tions mentioned in (Chaumette et al., 2002). In future,

further patterns will be worked out. Additionally, the

JOANA library shall be involved to support develo-

pers in detecting side effects.

@O f fl o ad abl e

pu bl ic class Co m pl exC al c {

St ri ng N ame ;

int [] r esu ltA rr ay ;

@Offload

@OffloadServers(ipAddress1)

pu bl ic v oid doC omp le x Ca l c ( int p1 ,

URL [] i mg UR Ls ) {

...

doC o mp l exP ara l le l Cal c ( i mgU RLs , p2 )

;

...

}

@Offload

@OffloadServers({ipAddress2,

ipAddress3, ipAddress4 })

pu bl ic v oid doC o mp l exP a ra l lel C al c (

@Splittable URL [] imgURLs , int p2 )

{

...

}

Listing 5: Chain of @Ofﬂoad and @Splittable.

6 DRMI

In the scope of this work, the problem of synchroni-

zing object graphs between clients and servers is ad-

dressed too. The related work known so far transfers

the whole state or, at least, the state that is addressed

on client and server side. Our goal is to communicate

only the differences between the object states located

at the client and the server. That means, for instance,

that after the client has sent the required state to the

server, the server will subsequently return the delta

between the new and the old state after executing a

method on it. In a following request, the client may

send itself just the delta to the server.

The ﬁrst step is to extend the relevant classes with

an identiﬁcation ﬁeld ofﬂoadId that enables us to as-

sign objects unique IDs during runtime. Again, this

step is done through bytecode manipulation. Unique

IDs are essential since objects may, for instance, be

12.07.2017

AFrameworkfor CodeOffloading inMCC

2 5

Method

Aspect

Input parameter

0 1

Figure 8: Object 3 replaced on server, but still referenced

by object 0 at client side.

deleted while at the same place a new, similar one

can be created. Figure 8 illustrates this scenario. The

white object graph is transferred to a server. The in-

voked method replaces object 3 by a new object 4.

Synchronizing back the object graph, the algorithm

has to detect whether to replace or to add object 4.

Algorithms like rsync or xdelta (Tridgell, 1999) that

work on streams and are thought for ﬁle systems can-

not detect such deltas.

During runtime, the proxy intercepts calls on

@Ofﬂoad methods. If the Evaluator decides to exe-

cute remotely, the proxy serializes initially the object

graph by ﬁrst numbering the unnumbered objects and

applying then the Kryo serialization library

. The be-

neﬁt of Kryo is that classes do not need to implement

Java’s Serializable interface and that it works on An-

droid too. Furthermore, it compresses the serialized

ﬁle more efﬁciently (Zhao et al., 2016).

The method parameters are also serialized and

transferred together with the object graph and the

method name. However, parameters are passed by va-

lue, the object and its member variables behave like

passed-by-reference. In this way, the developer can

decide what shall be synchronized back and what not.

After the remote method invocation, the proxy re-

turns immediately since we apply an asynchronous

RMI. The client application can continue its execu-

tion as long as it is not invoking any further methods

on the object. In the latter case, for example after in-

voking a getter on the object, the proxy would block

until the object is synchronized back. In case a time-

out is reached or the communication link is broken,

our proxy invokes the local method.

We decided on an asynchronous RMI as we ex-

pect high workloads and long execution times. No-

netheless, the developer should take into account not

to access any objects from the transferred object graph

as long as it is not synchronized back. For this pur-

pose, he should invoke a method such as a getter on

the object so that the proxy blocks until synchroniza-

tion is ﬁnished, or access the object graph in general

through methods of the annotated object as it is prox-

ied.

https://github.com/EsotericSoftware/kryo

MOCCAA: A Delta-synchronized and Adaptable Mobile Cloud Computing Framework

143

Table 1: Experiment 1 - Locally executed RMI.

Message sizes in Bytes Roundtrip time in ms

Number of

objects

Submitted

(DRMI)

Received

(DRMI)

Submitted

(Java RMI)

Received

(Java RMI) DRMI Java RMI

10 78 35 241 241 5.0 2.5

100 708 35 1411 1411 6.2 4.4

1000 7009 35 13111 13111 7.0 21.4

10000 70009 35 130111 130111 30.4 62.3

20000 140010 35 260111 260111 35.2 72.3

30000 210010 35 390111 390111 52.9 343.0

On server side, the framework deserializes the ob-

ject graph and parameters and invokes through Java

Reﬂection the method with the given parameters. A

copy of the received original graph is kept in memory.

After method execution a depth-ﬁrst search is compa-

ring the changed and the original graph and noting

down all differences by recording the concerned ob-

ject ID, the ﬁeld ID (ﬁeld position), the new value (ID

in case of reference), and a code that is describing the

required command, for example, resizing an array, as-

signing a value, adding or removing an element from

a collection. Due to unique IDs cyclic references do

not pose a problem during the graph comparison. Ne-

wly added objects are assigned IDs from a new range

of successive IDs that does not intersect with that of

the client. The recorded deltas and the compressed

and new objects are transferred back by invoking a

callback function on the client. On client side, the

commands are applied through reﬂection.

Table 2: Results of experiment 2 with a bandwidth of 10

MBit/s for upload and 42 MBit/s for download.

Number of objects

in object graph

Roundtrip time in ms

DRMI Java RMI

10 35.5 32.4

100 36.7 34.9

1000 39.3 56.0

10000 65.4 116.1

20000 71.9 154.8

30000 84.2 448.4

On client side, the previous serialization ﬁle is re-

placed by the serialization of the updated and syn-

chronized version of the object graph. This allows

the client to transfer himself only the deltas to the ser-

ver when invoking a remote method on the object a

second time.

The following section compares Java RMI and our

Delta-synchronized RMI (DRMI) and discusses their

advantages and disadvantages.

7 EVALUATION

The ﬁrst experiment is carried out on a local compu-

ter. Both the client and the server are running on the

same device, a notebook with 8 GB of memory, an In-

tel i5 processor with two 2.6 GHz cores and Java 1.8.

All used libraries, including Kryo, Javassist, AspectJ

and our proxies and Evaluators can run on Java 1.8 as

well as on Android 6 and upper. This allows an appli-

cation for Cloud Computing as well as Mobile Cloud

Computing. However, since we compared our appro-

ach with Java RMI, which is not suited for Android,

we restricted the following experiments to Java VMs.

For the experiment, a class Node is implemented.

It has one Integer ﬁeld and two Node references so

that a tree was created. On the root node, we invoked

a method with an Integer parameter that changed the

Integer ﬁeld of a random successor node. The met-

hod was executed on the server which required ﬁrst

the whole object graph. In case of DRMI, the delta

was returned then after method execution and applied

to the client’s object graph. In case of Java RMI, the

whole object graph had to be returned to stay synchro-

nized. Each value in Table 1 shows the average of 100

runs.

The local execution shows the time overhead in-

dependent of the used network and bandwidth. The

object graphs with 10 and 100 nodes are processed

and synchronized faster with Java RMI. DRMI has

ﬁrst to create copies of the received object graphs and

traverses the object graph to detect the changes. At a

certain level, copying and traversing the object graph

with DRMI is faster then serializing with Java RMI.

The test with 1000 nodes shows that DRMI performs

faster than Java RMI when the graph gets more com-

plex and the changes are small. Since only one Inte-

ger is changed, the serialization costs for the delta are

negligible then.

Regarding the message size, the response of

DRMI retains its size as expected since all test sce-

narios change one Integer value. Hence, the new Inte-

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

144

Table 3: Experiment 3 - Locally executed. 10% of all Integers are updated.

Message sizes in Bytes Roundtrip time in ms

Number of

objects

Number of

deltas

Submitted

(DRMI)

Received

(DRMI)

Submitted

(Java RMI)

Received

(Java RMI) DRMI Java RMI

10 1 78 35 241 241 5.3 2.4

100 10 708 116 1411 1411 6.1 4.3

1000 100 7009 963 13111 13111 8.3 21.8

10000 1000 70009 9964 130111 130111 37.0 63.5

20000 2000 140010 19964 260111 260111 46.7 74.2

30000 3000 210010 29964 390111 390111 61.3 339.3

ger value, an assign command, the ﬁeld position and

the object ID and header information are returned.

Compared with Java RMI, the request message size

is smaller too due to a compression with Kryo.

Repeating the same experiment over a network

with a client upload rate of 10 MBit/s and a download

rate of 42 MBit/s, we obtain the results listed in Table

2. The message size stays the same like in experiment

1. The average ping time between client and server

were 30 ms. Compared to Java RMI, DRMI has a lo-

wer increase in roundtrip times due to small message

sizes. Restricting the bandwidth further would be in

favour of DRMI.

Experiment 3 complies with the conditions of ex-

periment 1 except that 10% of all Integer values are

changed. Thus, the number of deltas is increased. Ta-

ble 3 shows that the response message size grows and

that it almost reaches 1/10 of the Java RMI message

sizes. Each delta requires around 10 Bytes. As ex-

pected, the roundtrip time also increases slightly. Ho-

wever, the performance does not decrease much.

The experiments lead to the conclusion that an op-

tion should be provided for developers, if they want

to deactivate delta calculations and always transfer

the whole object graph. This is recommended whe-

never message sizes are a few bytes to kilobytes or

whenever most elements of the object graph are chan-

ged. In contrast, determining and transferring deltas is

highly suitable when few modiﬁcations are expected

and message sizes are a few kilobytes, megabytes or

bigger. In addition, it can also be preferred when

clients often invoke methods on the same object.

8 RELATED WORK

The different proposed methods in the area of MCC

can be distinguished ﬁrstly with respect to the gra-

nularity and structure of the partitions. Their design

affects largely the ﬂexibility and efﬁciency of the of-

ﬂoading mechanism and the layout of the correspon-

ding execution environment of the cloud counterpart.

Furthermore, it may also have an impact on the requi-

rements the developer has to adhere when developing

the mobile application. In this view, we will discuss

frequently cited related works in the following and fo-

cus particularly on their partitioning approach, their

synchronization mechanism, and the overhead for de-

velopers and users.

Chun et al. (Chun et al., 2011) employ device

clones running as applications-layer virtual machines

to enable an ofﬂoading approach that does not re-

quire any preparatory work by software developers.

Hence, their CloneCloud framework supports unmo-

diﬁed mobile applications as well. A static analysis

tool discovers ﬁrst possible migration points with re-

spect to a method- and thread-level granularity. This

implies that methods accessing certain features of a

machine or methods that share their native state with

other methods, have to stick together. A dynamic pro-

ﬁler captures then the execution and migration costs

for randomly chosen input data and creates a pro-

ﬁle tree that depicts the method invocations and their

costs, e.g. their execution time. Finally, an optimizer

selects the migration points that reduce the total exe-

cution time or the energy consumption of the mobile

device by considering the computation and migration

costs. During runtime the virtual state, the program

counter, registers, heap objects, and the stack will be

ofﬂoaded as soon as methods marked with migration

points are invoked. The downside of this approach

is that it demands for a synchronized clone. Conse-

quently, the authors presume in their evaluation that a

VM is instantiated already and that data, applications

and conﬁgurations were available in the VM. They do

not cover the additional time for the instantiation and

synchronization steps and the costs of maintenance,

bandwidth and leasing of the VM.

In (Cuervo et al., 2010) Cuervo et al. introduce

MAUI, a system that is similar to the aforementioned

framework CloneCloud. Like CloneCloud, MAUI

operates at the level of method granularity and re-

quires a VM as device clone. However, MAUI is as-

king the developer to annotate the methods that shall

MOCCAA: A Delta-synchronized and Adaptable Mobile Cloud Computing Framework

145

be considered for ofﬂoading. During runtime, MAUI

checks the resource consumption of these methods by

serializing the required member and static variables

and by monitoring the CPU cycles and the execution

times. Using the two latter values, the energy con-

sumption can be estimated with a linear regression

model. By incorporating additionally the bandwidth,

the latency, and the size of serialized data, MAUI is

able to evaluate the costs for ofﬂoading the code and

migrating the states and to decide ﬁnally where the

method will be executed. In contrast to CloneCloud,

it offers an online proﬁling, however, to the detriment

of a higher resource consumption. And due to the VM

synchronization, MAUI is exposed to the same handi-

caps like CloneCloud.

ThinkAir (Kosta et al., 2012) from Kosta et al. is

a MCC framework that was derived from CloneCloud

and MAUI. Developers shall only need the @Remote

annotation for their method to execute it remotely.

However, further details for developers are not explai-

ned. Functions for resource consumption prediction

for previously unknown methods are learned online,

that is, during runtime. Learning and capturing such

monitoring data requires many resources and usually

slows down the application. Information like CPU

time, display brightness, Garbage Collector invoca-

tions and many more are provisioned. In addition, six

different Virtual Machine (VMs) types are provided.

A developer may parallelize his methods and execute

them in parallel on these VMs.

Techniques like cloudlets (Satyanarayanan et al.,

2009) and dynamic cloudlets (Gai et al., 2016) reduce

the aforementioned synchronization costs of VM-

based approaches by detecting and leveraging nearby

resources. However, such solutions are also beneﬁ-

cial and applicable to other MCC approaches and do

not directly address the disadvantage of high synchro-

nization costs. Yang et al. (Yang et al., 2014) mi-

tigate the problem by analyzing the stack and heap

to determine possibly accessed heap objects. Com-

pared to CloneCloud, they achieve better execution

times through reduced state transfer times. Nonethe-

less, still for each user a synchronized and customized

VM is needed that runs at least the same operating sy-

stem and application.

In contrast to the ﬁne-grained VM-based approa-

ches, the idea of Giurgiu et al. (Giurgiu et al., 2009)

relies on modularized software. The developer has

therefore to create his application by small software

bundles that offer their interfaces as services and inte-

ract via services as well. Both the smartphone and the

server have to run AlfredO (Rellermeyer et al., 2008)

and OSGi (Alliance, 2009) which support modula-

rized software written in Java. An ofﬂine proﬁling

determines where to run the bundles by abstracting

the resource consumption and the data ﬂow of the

interdependent bundles as a graph and cutting it in

such a way that a given objective function is mini-

mized or maximized. According to the authors, opti-

mal cuts can be determined due to the small number

of bundles. A downside of this approach is that an

unfavourable modularization cannot even be compen-

sated by an optimal cut when there exist just a few

bundles. Despite that, the application’s adaptation to

OSGi may cause considerable additional efforts for

software developers. Compared to VM-based appro-

aches, components and their services may be reused

by different customers.

Other works make use of well-known technolo-

gies like RPC (Balan et al., 2007) and remote servi-

ces (Kemp et al., 2012) that are accessible via stubs.

The main drawback of these approaches is the con-

siderable effort a developer has to undertake to re-

ceive their beneﬁts. In (Balan et al., 2007) the kno-

wledge of the authors’ description language Vivendi

is required to create the tactics the developer wants to

apply for the methods available via RPC. In (Kemp

et al., 2012) developers have to create interfaces by

using Android’s interface deﬁnition language AIDL

and to provide methods that transform their objects

to so-called Android Parcels. Furthermore, a second

implementation has to be supplied for the remote ser-

vice.

Our MOCCAA framework makes use of Remote

Method Invocation, but uses an intermediate serializa-

tion format that is translated seamlessly from/to An-

droid as well as from/to Java representations. Delta

synchronization is supported to reduce state transfer

costs. Ofﬂoading is enabled through annotations at

object and method granularity. VMs are not needed

per user. This relieves application users as they do

not need to search and lease own VMs. Instead, ser-

vers are the responsibility of the application provi-

ders. This allows them to reuse installed applications

or even tailor them to a more efﬁcient utilization of

the available cloud resources. MOCCAA-RMS fa-

cilitates monitoring, scaling, managing and ﬁnding

suitable resources within the application provider’s

domain. Monitoring and prediction costs on the mo-

bile device are reduced through our analysis tool In-

spectA.

9 CONCLUSION AND FUTURE

WORK

We proposed a conﬁgurable and extendable frame-

work and architecture for Mobile Cloud Compu-

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

146

ting. In its simplest form, developers may use it

by applying a few annotations and install the fra-

mework on a server. However, it can be exten-

ded with resource consumption prediction, a distribu-

ted and self-conﬁguring Resource Management Sy-

stem (MOCCAA-RMS), and a grid-like computation

pattern. In addition, we presented DRMI, a delta-

synchronized RMI that is well suited for applications

communicating deltas with their ofﬂoaded part. In fu-

ture, DRMI will be equipped additionally with a sli-

ding window approach that will be applied for arrays

and Java Collections. Although the current DRMI

version works for Java Collections and arrays, it can

be further optimized for them if they only contain pri-

mitive data types. Additionally, we examine further

patterns for splitting tasks and exploiting Cloud re-

sources.

REFERENCES

Alliance, O. (2009). OSGi Service Platform Service Com-

pendium: Release 4, Version 4.2 Author: OSGi Al-

liance, Publisher: AQute Publishing Pages. AQute

Publishing.

Balan, R. K., Gergle, D., Satyanarayanan, M., and

Herbsleb, J. (2007). Simplifying cyber foraging for

mobile devices. In Proceedings of the 5th internati-

onal conference on Mobile systems, applications and

services, pages 272–285. ACM.

Bernstein, A. J. (1966). Analysis of programs for parallel

processing. Electronic Computers, IEEE Transactions

on, 5(5):757–763.

Chaumette, S., Grange, P., et al. (2002). Parallelizing

multithreaded java programs: a criterion and its pi-

calculus foundation. Workshop on Formal Methods

for Parallel Programming IPDPS.

Chiba, S. (1998). Javassist - a reﬂection-based program-

ming wizard for java. In Proceedings of OOPSLA98

Workshop on Reﬂective Programming in C++ and

Java, volume 174.

Chun, B.-G., Ihm, S., Maniatis, P., Naik, M., and Patti, A.

(2011). Clonecloud: elastic execution between mobile

device and cloud. In Proceedings of the sixth confe-

rence on Computer systems, pages 301–314. ACM.

Cuervo, E., Balasubramanian, A., Cho, D.-k., Wolman, A.,

Saroiu, S., Chandra, R., and Bahl, P. (2010). Maui:

making smartphones last longer with code ofﬂoad. In

Proceedings of the 8th international conference on

Mobile systems, applications, and services, pages 49–

62. ACM.

Friedman, J. H. (1991). Multivariate adaptive regression

splines. The annals of statistics, pages 1–67.

Gai, K., Qiu, M., Zhao, H., Tao, L., and Zong, Z. (2016).

Dynamic energy-aware cloudlet-based mobile cloud

computing model for green computing. Journal of

Network and Computer Applications, 59:46–54.

Giurgiu, I., Riva, O., Juric, D., Krivulev, I., and Alonso, G.

(2009). Calling the cloud: enabling mobile phones as

interfaces to cloud applications. In Middleware 2009,

pages 83–102. Springer.

Graf, J., Hecker, M., and Mohr, M. (2013). Using joana for

information ﬂow control in java programs-a practical

guide. In Software Engineering (Workshops), volume

215, pages 123–138.

Hall, M. A. (1999). Correlation-based feature selection for

machine learning. University of Waikato, New Zea-

land.

Kaufman, L. and Rousseeuw, P. J. (2009). Finding groups

in data: an introduction to cluster analysis, volume

344. John Wiley & Sons.

Kemp, R., Palmer, N., Kielmann, T., and Bal, H. (2012).

Cuckoo: a computation ofﬂoading framework for

smartphones. In Mobile Computing, Applications, and

Services, pages 59–79. Springer.

Kohavi, R. and John, G. H. (1997). Wrappers for feature

subset selection. Artiﬁcial intelligence, 97(1-2):273–

324.

Kosta, S., Aucinas, A., Hui, P., Mortier, R., and Zhang, X.

(2012). Thinkair: Dynamic resource allocation and

parallel execution in the cloud for mobile code ofﬂoa-

ding. In Infocom, 2012 Proceedings IEEE, pages 945–

953. IEEE.

Ou, S., Yang, K., and Liotta, A. (2006). An adaptive multi-

constraint partitioning algorithm for ofﬂoading in per-

vasive systems. In Pervasive Computing and Commu-

nications, 2006. PerCom 2006. Fourth Annual IEEE

International Conference on, pages 10–pp. IEEE.

Rellermeyer, J. S., Riva, O., and Alonso, G. (2008). Al-

fredo: an architecture for ﬂexible interaction with

electronic devices. In Proceedings of the 9th ACM/I-

FIP/USENIX International Conference on Middle-

ware, pages 22–41. Springer-Verlag New York, Inc.

Satyanarayanan, M., Bahl, P., Caceres, R., and Davies, N.

(2009). The case for vm-based cloudlets in mobile

computing. Pervasive Computing, IEEE, 8(4):14–23.

Tridgell, A. (1999). Efﬁcient algorithms for sorting and sy-

nchronization. PhD thesis, Australian National Uni-

versity Canberra.

Yang, S., Kwon, D., Yi, H., Cho, Y., Kwon, Y., and Paek, Y.

(2014). Techniques to minimize state transfer costs for

dynamic execution ofﬂoading in mobile cloud com-

puting. IEEE Transactions on Mobile Computing,

13(11):2648–2660.

Zhao, Y., Hu, F., and Chen, H. (2016). An adaptive tuning

strategy on spark based on in-memory computation

characteristics. In Advanced Communication Techno-

logy (ICACT), 2016 18th International Conference on,

pages 484–488. IEEE.

MOCCAA: A Delta-synchronized and Adaptable Mobile Cloud Computing Framework

147