Modeling and Analysis of Mobile Cloud Computing Based on Bigraph Theory

Lian Yu, Xin Wei School of Software & Microelectronics

Peking University Beijing, 102600. P.R. China

lianyu@ss.pku.edu.cn

Jerry Gao Dept. of Computer Engineering, College of Engineering

San Jose State University San Jose, CA, USA jerry.gao@sjsu.edu

Wei Tek Tsai, Xiao Qun Guo School of Comp., Info., and Dec. Systems Engineering

Arizona State University Tempe, AZ 85287, USA

wtsai36@gmail.com

Thomas T. Hildebrandt Process and System Models Group

IT University of Copenhagen Copenhagen, Denmark

hilde@itu.dk

Abstract—A mobile cloud is a cloud infrastructure connecting to mobile devices with a variety of applications (apps). This paper proposes utilizing bigraphical reaction systems (BRSs) to model and analyze a mobile cloud including its contexts such as mobile location, power consumption, network bandwidth, and latency. Simulations and evaluations are performed by matching the reaction rules of BRS with its current agent, on different usage scenarios of mobile cloud, to demonstrate the validity of the proposed methodology.

Keywords—mobile cloud; modeling and simulation; bigraphical reaction systems (BRSs); sorting logic; BRS-based simulation; BRS-based MOF

I. INTRODUCTION

Mobile devices provide users with “mobility” capability in a pervasive computing environment irrespective of user movement. But mobile devices have limited computing resources and energy capacity [1]. Mobile cloud computing can address these problems by executing applications in a cloud. Several definitions of mobile cloud have been proposed [2],and this paper focuses the following three types of mobile cloud:

Client-Server mobile cloud computing: This refers to run an application on a remote resource-rich server while the mobile device acts like a thin client connecting over to the remote server through 3G or WiFi.

P2P mobile cloud computing: This is a peer-to-peer network where mobile devices provide resources for each other [3], and they may be aided by additional resources from stationary devices. This approach supports user mobility, and recognizes the potential of mobile clouds to do collective sensing as well.

Cloudlet mobile cloud computing: This is an approach where mobile devices offload their workload to a local

“cloudlet” comprised of several multi-core computers with connectivity to the remote cloud servers [4].

The client-server mobile cloud is common. But in case of unexpected incidents, such as earthquake, it may be unavailable, while P2P may be used. The cloudlet approach is suitable for public areas such as coffee shops that mobile devices can connect and function as a thin client to the cloudlet as opposed to a remote cloud server that may have latency and bandwidth issues.

In a pervasive computing environment, users demand the continuous mobility while ensuring connectivity to the cloud regardless of his/her movement. When supporting mobility and connectivity, some of the questions need to contemplate: How can a user device know of impending disconnectivity? In what ways can the most ‘stable’ and ‘efficient’ surrogates be chosen so as to ensure seamless connectivity? What fault-tolerance mechanisms can be employed to minimize potential failures?

In addition, the future belongs to services that respond in real time to information provided either by their users or by nonhuman sensors stated in [3]. Real-time applications are just one type of mobile applications that demand high-levels of responsiveness, which in turn, demand significant computing resources.

Such dynamic requirements of mobile cloud as seamlessly connecting, limited resource, frequent disconnections, real-time, and continuous mobility impose challenges to design and implement a mobile cloud.

This paper proposes to utilize the bigraphical reaction systems (BRSs) [6] to model and analyze the adaptive strategies and the behaviors of context-aware mobile cloud, which adaptively connects mobile devices to different types of mobile cloud based on its contexts, such as mobile location, mobile computation speed, mobile power readings, application’s complexity, offloading rate, network bandwidth, and latency.

The research is supported by the National Science Foundation of China(No. 61033006, No. 61170002).

2014 2nd IEEE International Conference on Mobile Cloud Computing, Services, and Engineering

978-1-4799-4425-5/14 $31.00 © 2014 IEEE

DOI 10.1109/MobileCloud.2014.11

67

A BRS is a formal model proposed by Milner [6][7] to model interactive systems, particularly related to modeling the containment and connectivity. Conventional modeling languages do not model connectivity, and thus it is necessary to develop one model for each new connection. If a mobile device is connected to a new device not previously connected, a new model needs to be constructed. But a BRS allows parts of systems to be modeled independently, and these parts can be linked once a mobile device is connected to a location, another device, or a cloud. Furthermore, when a mobile device loses the connection to the previously connected device, the BRS can simply remove the link between these elements. This kind of creating and removing links in models allows modeling of mobile cloud connectivity. Furthermore, each BRS for a deviceprovides the context that the device offers to its connecting devices or clouds.

Although they have demonstrated the values in the areas,including context-aware systems [8], biological applications [6][9] and business processes [10], few work addresses data and object modeling with BRSs. This paper follows OMG meta-model architecture MOF [11], and proposes to use bigraphical sorting logic as a meta-model to constrain the construction of data and entity for modeling the mobile cloud.

This paper is organized as follows: Section II presents a mobile cloud architecture; Section III describes the BRSs and defines the corresponding sorting mechanism; Section IV presents the bigraphical model of a mobile cloud with four scenarios; Section V illustrates the simulations and evaluations of polices for the mobile cloud; Section VI describes the related work; and Section VII concludes this paper.

II. MOBILE CLOUD ARCHITECTURE

A. Architecture of Context-Awre Mobile Cloud The architecture consists of five components; Cost manager,

Job handler, Resource handler, Context-aware handler, and Privacy and security manager as shown in Fig. 1.

Cost Manager

Priority management module

Estimation & negotiation module

Resource Handler

Discovery module

communication module

Resource evaluation module

Job HandlerApplication partitioning

module

Offloading module

Job scheduling module

Privacy & Security Manager

Context-aware Handler

Monitoring mobile attributes

Acquiring sensor readings

Monitoring app partition rate

Monitoring network

Fig. 1. Architecture of mobile cloud

Resource handler: It is responsible for searching for and discovering other mobile resources, connecting, maintaining connections and communicating with the external mobile devices, and also monitoring them for potential nodes entering or leaving the cloud. Due to the high probability of disconnectivity, the resource handler must opportunistically exploit available resources, while ensuring that the system gain, privacy, and security is also not compromised.

Cost manager: It determines the user priorities (e.g.: battery conservation, fast execution, monetary gain) and by taking into account the jobs at hand, available resources, required resources, and environment contexts, comes to a decision whether to offload or not. The cost model needs inputs from the resource handler about the capabilities of the available resources.

Job handler: It dynamically partitions the application and or data set required, offloads the generated jobs, and maintains the job pool.

Context-aware handler: It collects various sensor inputs for the resource handler to manage the mobility inside the mobile cloud.

Privacy and security manager: It takes inputs from sensors and users in addition to network interfaces to determine asuitable policy to enforce. For example, the strict authentication settings needed in a public setting may not be needed when operating among a group of trusted devices such as among a group of friends or a family. Or the user might decide on less resource consuming privacy policies since his or her other requirements such as conserving battery are prioritized.

These handlers and managers work together properly to adapt to the changing environment.

B. The Process of Research Fig. 2 shows the research path used: modeling mobile cloud,

simulating mobile cloud and evaluating the strategies applied in the mobile cloud.

Modeling Mobile Cloud

Create Meta-model

Create mobile cloud model

Define sorting logic

Simulating Mobile Cloud

Design scenarios

Collect simulation results

Run Simulation

Evaluating the Strategies

Design metrics

Report results

Compare the policy & strategy

Fig. 2. The research process of this paper

� Modeling: Create a meta-model based on BRS to model a mobile cloud. Define sorting logic to explicitly constrain placing and linking in the model. Create the containments and connectivity among different components of mobile cloud, and specify the dynamic behavior of mobile cloud using bigraphical reaction rules.

� Simulation: Design simulation scenarios, and create initial bigraphical agents. Run simulation by matching the redex of reaction rules with current bigraphical agents, and replacing the matching portion with the reactum of reaction rules. Collect the status of each reaction.

� Evaluation: Design metrics to evaluate strategies used in mobile cloud. Compare these strategies and policies based on the metrics. Report the evaluation results.

68

III. BUILDING A META-MODEL FOR MOBILE CLOUD

This section illustrates bigraphs and bigraphical sorting mechanism, and then creates a meta-model to dictate the construction of the models of mobile clouds.

A. Bigraph & Sorting Logic 1) The fundamentals of Bigraphs

A bigraph can be regarded as two graphs, the place graph to represent the nesting relationship of nodes, and the link graph to represent the edges among nodes or the interfaces [6]. The main elements of bigraph can be found in Fig. 31, where control is used to define a certain set of nodes with ports, and edge is a link between two ports, the rest elements are defined to combine two bigraphs into one with certain constraints, i.e., one bigraph’s outer name connects to another bigraph’s inner name, and all elements located in one root are able to be inserted in another bigraph’s site. The constraints will be formally represented as sorting logic and described in the following sub-section.

Fig. 3. An example of bigraphs

2) Sorting logic

Bigraph is based on category theory, and has an excellent scalability and expressivity. Other modeling languages, such as Petri-net or CCS, can be represented as bigraphs [14]. How to impose constraints on the bigraphs related to specific situations or domains while keeping the scalability and expressivity, becomes a key issue. Miller uses a sorting mechanism to solve this issue [6]. This paper formally defines a signature that supports a meta-model construction to model mobile cloud.

Let Σ = (Θ, C, ar, Γ, Φ) be a signature to represent the sorting information of bigraph, where � = {��, ��} is a non-empty set of sorts, �� is the place sorts, and �� is the link sorts; = {c: θ, … , c�: θ�, … , c : θ } is a set of sorted controls, �� ∈ ��, indicating the place sort of control c�; ��: → � is a function assigning a finite ordinal (the arity) to each control, and ��(��) = ���; �: � → �� is a function assigning one sort to each arity, that is, for control ��, the ��� port is assigned sort �� ∈ �� ; � is the formation rules, and represented as sorting logic to provide some constraints on a bigraph.

For the mobile cloud computing, let �� = {class, component, value} be the placing sorts, indicating that all controls must belong to one of them; let �� = {connected, hasValue, valueIs, hasComponent, componentIs} be the

linking sorts to represent all types of ports in bigraphs; and let�� = {Class:2 Component:2 Value:1} be to represent the number of ports on each sorted control.

Let C = {Zone:class, Mobile:class, Server:class,Router:class, Network:class, ContextAwareHandler:component, ResourceHandler:component, CostHandler:component,JobHandler:component, App:component, Service:component, Bandwidth:value, Result:value, Location:value, Speed:value, Power:value, Complexity:value}, containing all controls needed to model mobile cloud computing and described in Section III.C.1.

Let Γ = {Class:hasComponent connected, Component: componentIs hasValue, Value:valueIs}, allocating a link sort information to each port. The last component Φ of the signature defines three formation rules to constrain the links among ports using the following sorting logic:

Class@1: hasComponent = Component@1: componentIs (1)

Class@2: conneted = Class@2: connected (2)

Component@2: hasValue = Value@1: valueIs (3)

These rules specify whether or not two ports can be connected with an edge. For example, rule (1) signifies the port with the sort of hasComponent on a control with the sort of class can only be connected with the componentIs-sorted port on the component-sorted control.

B. Defining a MOF for Modeling Mobile Cloud The Meta-Object Facility (MOF) [11] is a standard of

Object Management Group (OMG) for model-driven engineering, designed as a four-layered architecture, i.e., M3~M0. MOF provides a meta-meta model at the top M3 layer. This M3-model is the language used by MOF to build meta-models located at M2 layer. These M2-models describe elements of the M1-layer, i.e., M1-models. The last layer is the M0 layer or data layer used to describe the real-world objects.

M3

M2

M1

M0

MOF::Class

BRS::Component BRS::ValueBRS::Class

valueis

hasvalue componentis

hascomponent

Connected

Instance Of

Zone (Class) CAH (Component) Speed (Value)

AgentBigraphical Reaction Rule

Fig. 4. MOF structure for modeling mobile cloud

MOF is used to define the object-oriented meta-models (as UML for example) as well as non object-oriented meta-models. This paper uses MOF to build up a mobile cloud computing model based on the bigraph theory. Similar to UML, the notion of MOF::Classes is also used at M3 layer, but placing the meta-model of the mobile cloud computing instead at M2 layer with three elements named class, component and value as

1. All bigraph figures in the paper are drawn by BigM developed based on BigRed. BigM is available by sending an email to lianyu@ss.pku.edu.cn.

69

shown in Fig. 4. The M1 layer defines all elements which will be used to construct bigraphical reaction systems for mobile cloud, and the bottom M0 layer represents a bigraph to simulate different scenarios.

IV. MODELING MOBILE CLOUD COMPUTING

This section presents four scenarios representing different types of mobile cloud, and then applies the methodology described in Section III to model mobile cloud.

A. Scenarios to model Assume that a native American student named Tom is

travelling in Sichuan province in the southwest of China. He carries a mobile device and uses a variety of services in the cloud if available.

Scenario 1: Tom is visiting a famous square in Chengdu and has taken some photos. He starts an application on his mobile and sends a request to a remote server, which can create a panoramic photo and match the photo with an image database to find the introduction of such a beautiful landscape, and then produce a voice file sent back to Tom. At the same time, Tom has picked a few photos to upload to his Twitter.

Scenario 2: Tom stays in a hotel and wants to modify his photos to make them better; so he starts an image process application, luckily this hotel has a powerful computer acted as a local server, thus his mobile connects the local server and offloads the picture processing to the local server. What he needs to do is just waiting for the processing results.

Scenario 3: Tom is visiting the Sichuan museum. He finds an interesting antique and wants to know its introductory materials, but the introduction is long and written in Chinese, so he takes a photo and starts a translation application. He knows that if his mobile does all works, it might cost too much energy on his mobile, so he seeks collaborations from the people nearby via inviting other mobile devices to create an ad hoc network to participate in the computing work.

Scenario 4: An earthquake all of sudden occurred in Sichuan and Tom is buried in the ruins, and the network is poor, so he activates the security manager to lower the security level, and tries to connect with other mobile devices around.Fortunately he gets connected with a mobile and uploads some photos to the server via the proxy mobile. The rescue team could be able to obtain the information from the server, combine all photos from various mobile devices and decide how to begin the rescue.

B. Modeling Mobile Cloud with BRSs This subsection defines the signature � containing the basic

elements which will be used in bigraphical reaction systems (BRSs) for mobile cloud, and then builds the four agents corresponding to the four scenarios. This paper uses BigM (stand for: bigraphical modeler) tool to fulfill the modeling. BigM is developed by extending the features of BigRed.

1) Model the bigraphical signatures:

There are three steps to create a bigraphical signature: defining a sort set, then building formation rules, and finally specifying the signature.

a) Defining a sort set: a set of placesort and linksort with BigM tool:

Fig. 5. Specifying the signature

b) Building formation rules: represented as sorting logic to provide constrains on the bigraph:

� formation rules for Placesort: {Square in network, Hotel in network, Museum in network, Service in remoteServer, Service in localServer}

� formation rules for Linksort: {hasValue links valueIs,hasComponent links componentIs}

c) Specifying the signature: The signature is used to create a control, assign placesort to each control, add ports to the control and assign linksort to each port as shown in Fig.5.

Fig. 6. Specifying the signature

2) Model the bigraphical agents in the scenarios

This subsection creates 4 initial agents corresponding to the four scenarios based the signature defined above.

a) Create an agent for Scenario 1 The first agent models the CS-style of mobile cloud as

shown in Fig.6. “apple” is a mobile type, has three handlers (JH, RH, CAH) and two managers (CM, SM), running two applications, and located in Zone-typed square. Tom takes a scenery photo, and uses “b:APP” to request a storage service on a remote server.

On the other hand, Tom takes a photo with complicated Chinese characters on an inscription, and he would request avoice service. “a:APP” invokes on remoteServer:Server a composite service CompositeService:Service that consists of three different services, i.e., image text extraction service, translation service and audio generation service.

70

The communication between apple:Mobile and remoteServer:Server is through i:Network, using wifiNetworkType with 90:Bandwidth and 50:Latency.

Fig. 7. CS-style of mobile cloud

b) Create an agent for Scenario 2 The second agent models the Cloudlet-style of mobile

cloud, where Tom comes back to a hotel that has a localServer:Server providing services to apps in mobile, while the localserverr:Server connects with the remoteServer:Server, so Tom can use the remote services to process photos and share them to his friends.

c) Create an agent for Scenario 3 The third agent models the P2P-style of mobile cloud. In

museum, Tom wants to know the Chinese introduction of an antique in his own language. By coincidence, there are two other two foreigners with m1:Mobile and m2:Mobile, who are also interested in the antique. Tom invites the two mobile devices to create an ad hoc network, such that they can collaborate with the translation to save the energy for each. As m3:Mobile is out of the range of the network, it could not participate in the collaboration.

d) Create an agent for Scenario 4 The fourth agent models the P2P-style of mobile cloud as

well. It describes a situation of natural disasters as shown in Fig. 7. Few mobile devices in destroyed area cannot connect with the remoteServer. To survive, the mobiles lower the security levels such that mobile devices can communicate with each other as much as possible. In the agent, apple:Mobile, samsung:Mobile and nokia:Mobile form an ad hoc network.

Fortunately, nokia:Mobile is able to connect to the remoteServer:Server, and works as a proxy to send pictures from other mobiles to the remote server to report the relief team about the disasters in the area. To save the energy in nokia:Mobile, some of its applications are offloaded to the other mobiles.

Fig. 8. Another P2P -style of mobile cloud

3) Model the bigraphical reaction rules in the scenarios

This paper utilizes bigraphical reaction rules to model the dynamic behaviors and corresponding policies of different types of mobile cloud. Applying the set of reaction rules enables to simulate the real world changes automatically. A set of detailed reaction rules has been created for the four scenarios. Due to the page limitation, the following shows twotypical reaction rules to illustrate the modeling approaches.

Fig. 8 shows an example of a reaction rule to represent an action strategy: compare the cost of fulfilling tasks on his own mobile with that of offloading them to mobile cloud, if the latter’s cost is lower, then this reaction will be matched and the mobile will offload some of tasks to the remote server.

Fig. 9. Offloading tasks to remoteServer:Server

Fig. 9 shows a reaction rule to represent an action strategy: if the mobile detects that one device has been out of the ad hoc network, the mobile needs to confirm the missing task and re-surrogate the tasks to the other mobile devices staying at the network.

Fig. 10. Re-offloading tasks due to a mobile out of the range

V. SIMULATION AND EVALUATION

Based on the bigraphical agents and a set of reaction rules, this section describes the mechanism of the simulation of mobile cloud and evaluations of policies applied.

71

A. Simulation Illustration The simulation is enabled by applying the graph rewriting

algorithm to match the reaction rules against the current agents. Taking Scenario 3 as an example, this subsection describes the process of the simulations.

1) Reaction rules for Sceanrio 3 in the museum

There are fourteen reaction rules (RR) defined for Scenario 3 (to save the space, the following just gives the RR’sdescriptions informally, where app stands for application on x:Mobile, and service refers to the service on a remote server):

� RR-1: Tom takes 60 pictures of the introduction of the antique, and stores in the app.

� RR-2: The app uses the resource of x:Mobile, and processes the translation of introduction on the pictures.

� RR-3: The app uses 3G network and uploads the pictures to a service in a remote server. This reaction is based on a condition that the bandwidth of 3G network is larger than 2M.

� RR-4: The service finishes the process of the translation, and returns a result to the app. This reaction is based on a condition that the bandwidth of 3G network is larger than 2M.

� RR-5: Mobile creates an ad hoc network with WiFi,and the same app in other mobiles (m1, m2) is connected to it. This reaction is based on a condition that other mobiles are within 100 meters from the x:Mobile.

� RR-6: The app in x:Mobile breaks the translation job into 3 partitions.

� RR-7: The app in x:Mobile offloads job partitions to the apps in other mobiles via WiFi network.

� RR-8: The apps in 3 mobiles (x:Mobile, m1, m2) in network process the translation job.

� RR-9: All job partitions have been finished and returned to x:Mobile, This reaction is based on a condition that all the mobiles in the ad hoc network are within 100 meters from the x: Mobile.

� RR-10: The app merges the results, and sends descriptions to all of other mobiles in the ad hoc network. This reaction is based on a condition that all the mobiles in the ad hoc network are within 100 meters from the iPhone.

� RR-11: The app in x:Mobile merges the results.

� RR-12: The y:Mobile in the ad hoc network moves outside the range of 100 meters, so the x:Mobile receives the z:Mobile’s results and offloads y:Mobile’sjob to z:Mobile and z:Mobile completes this part of job.

� RR-13: The z:Mobile finishes the y:Mobile’s job, and returns the result to x:Mobile.

� RR-14: The y:Mobile in the ad hoc network moves outside the range of 100 meters, so the x:Mobile receives z:Mobile’s results and offloads y:Mobile’s job to itself.

TABLE I lists the impact factors that may affect the cost of time, energy and fees, and the base settings of those factors.

TABLE I. SIMULATION PARAMETERS AND BASE VALUES

Impact factors valuesC: Complexity of work 60 picturesSm: Speed of mobile m 1 picture/minSs: Speed of server s 3 pictures/minSg: Speed of 3G 10 pictures/minSw: Speed of WiFi 5 pictures/minPp: Power cost of process task 0.5 %/minPg: Power cost of 3G transition 1.5 %/minPw: Power cost of WiFi transition 2.5 %/minFg: Fee of 3G 0.2 Yuan/pictureFw: Fee of WiFi free

Based on the base setting, TABLE II shows the time, energy and fee for each reaction rule:

TABLE II. COST FOR EACH REACTION RULE IN THE SIMULATION

2) Reaction mechanism

Take as an example the agent at node 8 of Fig. 12 as shown in Fig. 11, where the apple:Mobile setups an ad hoc network, and m1:Mobile and m2:Mobile connect to it. Each mobile has a partitioned job for language translation. Fig. 10 shows the redex and reactum of Rule 12: the m2:Mobile is out of range of 100 meters, and the job offloaded to m2:Mobile is re-dispatched to m1:Mobile. Using term rewriting algorithm [21],BigSim tool matches the redex with the agent, if matched, uses the reactum to replace the matched part in agent. Fig. 13 shows that at node 11, the reactum of Rule 12 as shown in Fig. 10 replaces the redex appearing in Fig. 11.

Fig. 11. The agent at node 8 of the labeled transition system in Fig. 12

Each bigraph can be represented as a term, consisting of a prefix-suffix structure. The prefix can be a node of a control, and suffix can be a paraller structure of prefix-suffix structures. The matching process of the example goes as follows:

72

Fig. 12. Bigraphical labeled transition systems as simulation results of mobile cloud (for Scenario 3 )

Fig. 13. The agent at node 9 of the labeled transition system in Fig. 15

1. Match the roots of redex and agent: the redex is a prefix-suffix structure, and the agent is also a prefix-suffix structure, therefore they match with each other, and go to step 2.

2. Match the node, control and ports of the two prefixes:In the example, the node in the prefix of redex is museum, and it equals to that of agent. The control in the prefix of redex is Zone, and it also equals to that of agent. In addition, the port lists of two prefixes are the same, so they match with each other, and go to step 3.

3. Match the suffixes of the prefixes: the suffix of museum:Zone in the agent is a paraller, so is the suffix of the redex, and go to step 4. Note that if the suffixes of both the agents and redexs are Nils, then go to step 5.

4. Match the two parallers: the paraller in agent contains two prefix-suffix structures, and so is the paraller in redex. For each pair of one prefix-suffix from agent and one from redex, recursively continue the same process from step 2 to step 4 until meet the condition in step 3 to go to step 5.

5. Since each part of agent can be put into a site, site 0 to site 4 in redex match the contents in each mobile.

6. Finally, after each successful matching of paraller, prefix, site and so on, the redex is matched with the agent. The matched part in agent is replace by reactum, and put the contents in the agent into the sites in the replaced one.

3) Reaction paths

The simulation obtains 8 reaction paths as shown in Fig. 11,the paths start from node 1, and end at Node 3 or Node 10. Fig. 14 shows the costs, power consumptions and times for reaction rules of each path in Scenario 3 at the museum. Note that the data in Fig.14 is scaled in order to put the three types of resultsin one figure.

Fig. 14. Simulation results for Scenario 3

In Path 1, Tom only uses the resource of apple:Mobile to translate the introduction. The process time is long, about 70minutes. In Path 2, Tom uses instead 3G to call service in the remote server. The process time is shorter than Path 1, but it needs to spend some money. In Path 3 to Path 8, Tom uses P2P schema to process the translation. In Path 3 to Path 5, Tom doesn’t share the result with others. In Path 6 to Path 8, he shares the result with others. Paths 4, 5, 7 and 8 consider the movement of other mobiles. When m2:Mobile leaves the ad hoc network, Path 4 and Path 7 use apple:Mobile to process the work assigned to m2:Mobile, and Path 5 and Path 8 use m1:Mobile to process the work belonged to m2:Mobile.

Apparently, the ad hoc network model can save money and time, and the fault-tolerate is able to be considered as well,such as one node in the network lost. In addition, sharing result also spares times and money for other people who need the translation.

B. Simulation to Evaluate Impact Factors 1) Simulation Objective and Settings:

This simulation analyzes the impact factors on energy and time of mobile cloud. Scenario 2 is used, where Tom is running an image process application on his mobile and the mobile cloud needs to calculate the cost of each path and choose the best one. The parameters used in this experiment are: the work complexity is 15 pictures and the process speed of local server

73

is 3 pictures per minute. Some other relative parameters can be referred in TABLE I.

The simulation shows the energy consumptions for one base case, and 4 other cases by changing the values of one other parameter while keeping the rest the same at a time toobserve their impacts on the energy.

a) Complexity: value from 15 pictures to 30 pictures. b) Network: type from 3G to WiFi. The former uses Sg,

Pg and Fg to calculate, and the latter uses Sw, Pw and Fw. c) Server speed: value from 3 to 2 pictures per minute. d) Mobile speed: value from 1 to 2 pictures per minute.

2) Simulation results and analysis Fig. 15 shows the simulation paths, where each of

simulation paths stands for a path of a labeled transition system of a BRS, representing the whole task on its own device or offloading the task to a local server.

Fig. 15. The two paths of the simulation

The results in Fig. 16 represent the consumptions of time. It is observed that Path 2 is better than Path 1 in terms of time in the base case. Although the changes of complexity, server speed and network type cause the changes of time consumptions in both paths, Path 2 still achieves better. However, if the mobile speed changes to 2 pictures per minute, the simulation provides a different decision according to the time cost. Actually when the mobile speed is about 1.36 pictures per minute and other parameters stay unchanged, the time cost of two paths is even. Keeping the rest the same may affect both paths while other changes may affect only one path.

Fig. 16. Factors impacting on time

Fig. 17. Factors impacting on energy

In terms of energy consumption in the base case, It is observed that Path 1 is better than that of Path 2 due to 3G transition as shown in Fig. 17. No matter the changes of complexity, server and mobile speed, and network type, the observation keeps the same.

C. Simulation to Evaluate Partition Strategies 1) Simulation Objective and Settings:

This simulation is to analyze how the number of partitions of jobs affects the task completion time, which is based on the scenario of museum. Tom builds an ad hoc network and shares his work with other mobile devices in the network. The simulation has the following assumptions:

a) All devices in the ad hoc network have the same processing capacity, Sp, and there are at most 6 devices in the network.

b) When a task fails, the host mobile will re-assign the task. The probility of failure will be the same, and only one other task than the host mobile will fail at a time.

c) The translation time for each picture will be the same. In addition to the above assumptions, more setting data are

defined as follows in TABLE III:

TABLE III. COST VIS FAULT TOLERANCE IN SIMULATION

Parameters ValuesC: Complexity of work 60 pictures totallySd: Speed of division 5 minutes per partitionP: Number of partitions changeable variablePr : Probability of Failure 20% for each deviceCt: Time for transmission 10 pictures per minute

The task is divided into 2, 3, 4, 5, 6 parts, respectively. The time cost is using the following formula to calculate:

Cost = (P-1)/Sd+2*Ct+C/(P*Sp)+ (1/N*((N-1)/N)(P-2)* (P-1))* (Ct/(P-1)+C/(P*Sp)) (4)

Where the term (P-1)/Sd is the time cost of partition, 2*Ctthe time cost of transmission, C/(P*Sp) the time cost of processing task, and the last term means if one device’s task fails, the work needs to be re-done.

2) Simulation results and analysis The results of different partitions are shown in Fig. 18,

representing the times needed to complete the work. Fig. 19 shows the simulation processes for different partitions.

Fig. 18. Job partition strategy analysis

74

Fig. 19. Simulation in different partitions

D. Simulation to Evaluate Fault Tolerance This simulation uses the forth scenario, Tom and other

people build an ad hoc network to get information about the disaster, while one mobile acts as a connector and shares information with others using a service, which can be pre-installed in other mobile devices. The following elements are defined as in this simulation:

a) Pre-installed service cost: 10 yuan for each device. b) One device down probability: 20%. c) Number Of devices in ad hoc network: 6.

If only one device installs the service, when it goes down, all the six mobiles will lose connection to the outside world. Ifall six install the app, the cost was a little high. The cost and fault occurring probability are listed in TABLE IV:

TABLE IV. COST VIS FAULT TOLERANCE IN SIMULATION

Result Devices With Service1 2 3 4 5 6

Cost 10 20 30 40 50 60Fault 20% 4% 0.8% 0.16% 0.032% 0.0064%

Fig. 20 shows the result of this simulation. Tom and his friends may pre-install the app or not, the one device acts as a proxy to connect remote server.

Fig. 20. Simulation for fault tolerance

Let’s define success rate as (1- fault occurring probability). It is observed that the success rate of four devices installing the app is up to 99.84%, and costs at 40 units. If increasing the success rate, the cost will increase as well, while decreasing the cost, the success rate will drop a lot. The simulation helps to choose the proper balance between cost and success rate.

VI. RELATED WORK

Mobile cloud is a new research area that addresses both mobile computing and cloud computing at the same time. Many applications such as image processing [20], natural language processing [20], crowd computing [25], sharing GPS data [26], sensor data application, multimedia search and social networking [3] can be done in a mobile cloud.

Mobile cloud has many research issues including offloading mechanisms and algorithms, cost estimation, security, context awareness, and data management. As to the offloading, three methods are proposed, client-server communication, virtualization, and mobile agents. For example, the MAUI [16] framework uses virtual machine migration and code partition to offload work to a cloud at runtime to save power.

For the cost estimation, various researches have proposed different models for the cost analysis, including the software characteristics, the hardware prices and the context data [24]. Scavenger [17] framework employs a cost assessment method to decide whether one should offload its work to a cloud, and this method considers the network bandwidth and latency, task complexity, device’s state, the relative speed and capability of resources in the cloud. Kumar and Lu provide a formula to analyze and calculate the cost [18].

Various modeling languages have been proposed to model dynamic systems including CCS [28][29], Petri-net [27] and UML [21]. But they do not address mobility issues. Bigraph [23] [14] based on the category theory can model mobility, and has BRSs mechanisms. A model in other modeling language can be converted to bigraphs [10][31][32], which address the mobility but others do not.

Gian defined a sorting logic and a term language to bigraph [15], the former represents the sorting constrains like nesting constrains and link constrains, and the latter allows bigraphs to be coded so to be processed by software.

Faithful [12] developed a software tool, BigRed, for editing the signature, bigraphical agent, and BRS rules in the term languages. The original version of the tool does not support modeling the sorting information, and does not have data elements in its model. BigM is a new tool by extending BigRed with the following features:

� Add sorting information to allow users to allocate place sort to each control and link sort to each port;

� Realize the sorting logic user interface by adding constrains in the bigraphical models;

� Develop a data model to store data;

� Reconstruct the user interfaces so that it is easy to use based on the Graphical Editor Framework (GEF) [30].

Another important software tool to support the applications is BigMC, a bigraphical model checker, developed by Gian [13], which evolves BRSs based on current agents and reaction rules to simulate the real world transition. Given an agent represented by the term language, the original version of BigMC iterates all reaction rules and tries to match the rules

75

whose redex is part of the current agent, and then the tool fires these reactions and replaces the redex with the reactum in the current agent. BigMC explores all possible paths from aninitial agent and export a graph to represent all paths. The original version of BigMC does not support sorting logic, timing specification, and relational expression. This paper extends the features and develops a tool, BigSim, standing for bigraphical simulator, to support the simulation of mobile cloud, to evaluate the policies and strategies.

VII. CONCLUSION AND FUTURE WORK

This paper creates a BRS-oriented (bigraphical reaction systems) meta-model based on OMG MOF architecture, and formally specifies bigraphical sorting mechanism. The meta-model and sorting logic are used to define a bigraphical signature as a quintuple, including place sorts, link sorts, sorted controls, port sorts and port numbers on the controls, and formation rules to constrain the nest positions and links. Bigraphical models are created for different types of mobile cloud based on the signature, including bigraphical agents and a set of reaction rules. By applying term rewriting algorithms to current agent and reaction rules, the BRSs get evolved to simulate the dynamic placing and linking behaviors of mobile cloud. Four scenarios are used to demonstrate the validity of the proposed methodologies. The future work will create more scenarios and perform more simulations to evaluate the proposed approach.

ACKNOWLEDGMENT

Gian and Faithful worked on the initial version of the bigraphical editing and model-checking tools, Wei Liang, Yi Han Xu, Na He improved the tool using BigM and BigSIM.

REFERENCES

[1] M. Satyanarayanan, “Fundamental challenges in mobile computing”, inproceedings of the Fifteenth Annual ACM Symposium on Principles of Distributed Computing, PODC 96, ACM, New York, NY, USA, 1996, pp. 1 7.

[2] Niroshinie Fernando, Seng W. Loke, Wenny Rahayu, “Mobile cloud computing: A survey”, Future Generation Computer Systems vol. 29,pp.84-106, 2013.

[3] E.E. Marinelli, “Hyrax: cloud computing on mobile devices using MapReduce”, Masters Thesis, Carnegie Mellon University, 2009.

[4] M. Satyanarayanan, P. Bahl, R. Caceres, N. Davies, “The case for VM-based cloudlets in mobile computing”, IEEE Pervasive Computing, vol. 8, pp. 14 23, 2009.

[5] L. Siegele, “Let it rise: a special report on corporate it”,http://www.economist. com/node/12411882, 2008.

[6] R. Milner, The space and motion of communicating agents, Cambridge University Press, 2009.

[7] R. Milner: “Pure bigraphs: structure and dynamics”, Information and Computation, vol. 204, no. 1, pp. 60–122, 2006.

[8] L. Birkedal, S. Debois, E. Elsborg, T. Hildebrandt, and H. Niss, “Bigraphical models of context-aware systems”, FOSSACS 2006, LNCS 3921, pp. 187-201.

[9] Jean Krivine, Robin Milner, Angelo Troina, “Stochastic bigraphs”,Electronic Notes in Theoretical Computer Science (ENTCS), Volume 218, pp. 73-96, October, 2008.

[10] T. Hildebrandt, H. Niss, and M. Olsen, “Formalising business process execution with bigraphs and reactive XML”, in Paolo Ciancarini and

Herbert Wiklicky, editors, Proceedings of the 8th International Conference on Coordination Models and Languages, vol. 4038, Lecture Notes in Computer Science, Springer-Verlag, pp. 113-129, January 2006.

[11] OMG metamodel architecture: http://www.omg.org/mof/ [12] Alexander Faithfull, Gian Perrone, and Thomas T. Hildebrandt, “Big

Red: a development environment for bigraph”, in 4th International Workshop on Graph Computation Models, 2012.

[13] Gian Perrone, Soren Debois, Thomas T. Hildebrandt, “A model checker for bigraph”. Proceedings of the 27th Annual ACM Symposium on Applied Computing, ACM New York, NY, USA, 2012, pp. 1320-1325.

[14] Robin Milner, The space and motion of communicating agents, Cambridge University Press, Mar 19, 2009.

[15] Gian Perrone, “Domain-specific modelling languages in bigraphs”, PhD thesis, 2013.

[16] E. Cuervo, A. Balasubramanian, D.-K. Cho, A. Wolman, S. Saroiu, R.Chandra, P. Bahl, “Maui: making smartphones last longer with code offload”, in proceedings of the 8th International Conference on Mobile Systems, Applications, and Services, MobiSys’10, ACM, New York, NY, USA, 2010, pp. 49–62.

[17] M. Kristensen, “Scavenger: transparent development of efficient cyber foraging applications”, in proceedings of the IEEE International Conference on Pervasive Computing and Communications, PerCom,2010.

[18] K. Kumar, Y.-H. Lu, “Cloud computing for mobile users: can offloading computation save energy?”, Computer, vol.43, no.4, pp.51–56, April, 2010.

[19] J. Carolan, S. Gaede, J. Baty, G. Brunette, A. Licht, J. Remmell, L. Tucker, J. Weise, “Introduction to cloud computing architecture—white paper”, 2009.

[20] J. Cheng, R.K. Balan, M. Satyanarayanan, “Exploiting rich mobile environments”, Technical Report, 2005.

[21] J.W.Klop, Term rewriting system, Handbook of logic in computer science, Oxford University Press, Inc. New York, NY, (vol. 2), pp. 1 –116, 1992.

[22] Satish Mishra, “Visual modeling & unified modeling language (UML): introduction to UML”. Rational Software Corporation. Accessed 9 November 2008.

[23] Robin Milner, “Bigraphs as a model for mobile interaction (invited paper)”, ICGT 2002: First International Conference on Graph Transformation. Lecture Notes in Computer Science 2505. Springer-Verlag. pp. 8-13.

[24] E. Walker, W. Brisken, J. Romney, To lease or not to lease from storage clouds, Computer, vol.43, no.4, pp.44 50, April, 2010.

[25] M. Satyanarayanan, “Mobile computing: the next decade”, inproceedings of the 1st ACM Workshop on Mobile Cloud Computing and Services: Social Networks and Beyond, MCS’10, ACM, New York, NY, USA, 2010, pp. 5:1–5:6.

[26] N. Vallina-Rodriguez, J. Crowcroft, “Erdos: achieving energy savings in mobile OS”, in proceedings of the Sixth International Workshop on MobiArch, MobiArch’11, ACM, New York, NY, USA, 2011, pp. 37–42.

[27] Tadao Murate, “Petri nets: properties, analysis and applications”, inproceedings of IEEE, vol. 77, no 4, April 1989.

[28] Robin Milner: A Calculus of Communicating Systems, Springer Verlag, 1980.

[29] Robin Milner, Communication and Concurrency, Prentice Hall, International Series in Computer Science, 1989.

[30] GEF: http://en.wikipedia.org/wiki/Graphical_Editing_Framework[31] R. Milner. “Bigraphs for petri nets’, in Lectures on Concurrency and

Petri Nets, pages 686-701. Springer, 2004.[32] M. Bundgaard and V. Sassone. “Typed polyadic pi-calculus in bigraphs”,

in proceedings of the 8th ACM SIGPLAN international conference on Principles and practice of declarative programming, pages 1-12. ACM, 2006.

76