Performance and Data Traffic Analysis of Mobile Cloud Environments

Mobile Cloud Computing (MCC) is a technique for increasing the performance of mobile apps and reducing their energy consumption through code and data offloading. Building an MCC infrastructure is a difficult task due to its inherent complexity and the involvement of different components. This paper proposes an approach for estimating applications' performance and data traffic volume generated by tasks offloading. This work proposes a Stochastic Petri Net (SPN)-based formal framework to represent the partitioning of applications in a method-call level. Our framework considers the available network bandwidth to send and receive tasks to the cloud. The modeling strategy represents the use and sharing of the actual available bandwidth for offloading operations. The approach enables designers to plan and tune MCC architectures based on Mean Time to Execute (MTTE) and Throughput estimation. Using our strategy it is possible to estimate the impact of the bandwidth variation on the application's MTTE and Throughput. In addition, the strategies proposed in this work may be adapted to support MCC applications in real time providing on-the-fly probabilistic performance predictions. One case study was performed to evaluate the approach. Our proposed approach has proven to be feasible and it highlights the most appropriate strategies for offloading.


I. INTRODUCTION
Mobile Cloud Computing (MCC) is a paradigm that increases the performance of mobile apps and reduces their energy consumption through offloading technique [9].The offloading process sends tasks to be processed on remote servers in the cloud.The first step in performing task offloading is to split an application into different parts.Next, there is a decision of which ones are most convenient for remote processing.Tasks may be partially or completely offloaded, depending on the application requirements.
Offloading does not come for free.Cloud service providers charge their clients for resource usage.A wrong offloading decision may lead a company to financial losses.The higher the resource usage, the higher the amount to be paid to the provider.Method-call offloading is a partitioning strategy that enables to split a code into multiple parts.Deciding which method to partition is not an easy task.It is necessary to analyze many possible scenarios.
This paper proposes an approach for estimating the performance and data traffic volume generated by tasks offloading to clouds.For that aim, we defined twofold steps.We propose a Stochastic Petri Net (SPN) [14] modeling strategy to represent the application source code structure.The modeling strategy represents the use and sharing of the available network bandwidth (BW) for offloading operations.Next, the proposed models are used to estimate two performance metrics of the whole application, the Mean Time to Execute (MTTE) and Throughput.The MTTE corresponds to the execution time of the application as a whole.The throughput corresponds to the number of requests per time unit made by each user.We propose a mobile cloud model to predict data traffic volume applying SPNs.
The remainder of the paper is organized as follows.Section II highlights the main concepts about Method-Call Offloading and SPNs; Section III presents the proposed strategy; Section IV details the case study to support the proposal; and finally, Section V traces conclusions, stressing future directions.

II. BACKGROUND
This section presents some concepts about Method-Call Offloading and SPNs to support the understanding of the proposed approach.

A. Partial Method-Call Offloading
An alternative to the Full Method-Call Offloading [10], is the Partial Method-Call Offloading [8].Instead of all methods, only a subset of them is offloaded.Data dependencies must be observed to perform a correct partition.For example, considering the methods m1() and m2(), two decisions should be made: Where to execute m1() and m2()?
Combining these possibilities (mobile device or the cloud), four scenarios may be exploited (see Table I).The number of possibilities increases proportionally to the application complexity.In a real-world scenario, the number of combinations of method-calls to offloading may be very large.Such variety makes harder the software engineer's work when deciding the most appropriate offloading distribution.Besides, other aspects, such as the mobile device current CPU and energy consumption level, may influence the decision.Assuming that an application with many active users uses a cloud service, a wrong offloading decision may lead to financial losses.There-1 fore, companies should plan their MCC offloading strategies balancing performance and use of remote resources.Petri Nets (PNs) are a powerful modeling tool that can be used to represent concurrent, asynchronous, distributed, parallel, deterministic, and stochastic processes [14].PNs define a specification technique that allows a mathematical and graphical representation, and it has analytical mechanisms that enable verification on the properties and correctness of modeled systems.Stochastic Petri Nets (SPNs) are an extension of Petri Nets [12].SPNs associate a stochastic delay to each timed transition.Thus, PNs become probabilistic, being described by a stochastic process.SPNs may be isomorphic for Continuous Time Markov Chains (CTMC) and, consequently, they can provide performance measures [7].

III. ESTIMATING PERFORMANCE AND DATA TRAFFIC
Companies in some situations need to balance system performance and resource consumptions to find the most appropriate strategy that meets the requirements of their projects.As the user base of an offloadable app grows, the higher may be the consumption of some remote resources.Applications' performance and data traffic are key elements in the choice of an appropriate offloading strategy.More precisely, this paper seeks to answer the following questions: 1) How to calculate the throughput and MTTE of a set of method-calls -that may represent a system functionality -using SPNs? 2) How to estimate the impact of the available bandwidth variation on the application's MTTE? 3) How to estimate the data volume that will be transferred during the offloading process of a set of method-calls?

A. Network Performance and Communication Time
Network performance is a key factor that has a direct impact on the performance of the entire MCC application.However, it is a difficult task to estimate precisely at design time the network conditions in which applications will be used.Real life network conditions may vary abruptly.
Latency variation over wireless networks is hard to predict.As the wireless channel congestion increases, the latency deteriorates rapidly.Packet loss is another factor that impacts on TCP throughput performance.This work considers the expected TCP throughput between the device and the cloud for tasks offloading.A developer may implement a strategy to estimate the actual bandwidth available during the application execution.In this context, there are many works with the aim of evaluating MCC offloading traffic considering the overall networking aspect and resulting networkinduced constraints [5].For example, based on the actual available bandwidth estimated and the performance prediction performed using the strategy proposed in this work, mobile apps may decide how the processing will be executed.
Thus when planning an MCC application, developers should consider that the expected bandwidth may vary within a specified limit.For example, if the application detects that the available bandwidth is less than the lower-limit set value, then the processing is performed locally.Based on the actual bandwidth resources available, it is possible to use the wellknown Equation 1 to estimate the communication time.

B. Execution Time (MTTE)
MTTE corresponds to the average time to finalize the processing of a set of method-calls.Figures 1 and 2 present an example of SPNs for computing MTTE.MTTE is the expected time to reach an absorbing state.A state of an SPN is absorbing whether it is impossible to leave it (i.e., P(#FINISH = 1)).It means a deadlock marking has been reached.MTTE is based on the probability that the processing of a system functionality has been completed.MTTE is the average time for a number of tokens to reach the place FINISH given they were in place START at time instant zero.SPN models can be evaluated either by numerical methods or by simulation [13].
Figures 1 and 2 demonstrate a simple representation using SPN of one functionality with only one method-call.Let us first look at the SPN representation that corresponds to the local method-call (see Figure 1).The SPN model comprises three places and two transitions.The first transition (triggertime) is immediate.It means that the transition has zero as its delay value.The second transition (processing time) is a General Time High-level Transition.It represents the time to processing the respective method-call.
The SPN pattern that represents an offloadable method-call has two new places and two new transitions (see Figure 2).Transition offloading time represents the time spent to execute offloading.Transition receiving time represents the time spent to receive the result sent by the cloud.These transitions are depicted by a gray rectangle, and the model is later refined by assigning probabilistic distribution parameter values to respective transitions.If, on the one hand, such transition is refined by poli-exponential distributions [6], the SPN can be evaluated either by numerical analysis or by simulation.On the other hand, simulation should be carried out.
The models evolved by transformation of high-level transitions into exponentially distributed timed transitions.It allows assigning average delays to respective timed transitions.Such transformation of transitions and delays assignments allow the SPN models to be solved.From here, for simplicity, all timed transitions will have exponential enabling times.However, they may adopt other probabilistic distributions as well as deterministic values.
Moment matching [6] could also be applied to obtain polyexponential distributions [15].By adopting moment matching, the planner may estimate what exponential-based probability distribution best fits the mean.Additionally, moment matching generates more accurate models, which can still be numerically evaluated.If none poly-exponential distributions are adopted, simulations should also be adopted.
Such SPN patterns may originate other models to evidence data dependency between method-calls of any source code arrangement.The SPN modelling pattern evolved to calculate MTTE of distinct scenarios.Figure 3a demonstrates the SPN that represents two serial method-calls.Figure 3b shows the SPN that represents two parallel method-calls.The pattern embraces general features common in concurrent systems.The place SYSTEM INACTIVE when having one token means that the system is idle.The timed transition T0 receives the delay to start the processing of method-calls when there is a token in the place SYSTEM INACTIVE.When there is no delay, T0 becomes an immediate transition.In a realworld context, multiple combinations can be derived taking into account the application's method-calls and the modelling patterns presented in Figures 1 and 2 The mean processing time and communication time of each evaluated method are the base for MTTE calculation.In the models presented, the processing time m1 and processing time m2 transitions receive the mean processing times of the methods m call 1 and m call 2, respectively.If the application's method under analysis is an offloadable method, it is necessary to obtain the number of bytes transferred to send tasks and to receive the remote results.
In this work, we consider that there is a specific bandwidth allocated to offloading operations, as well as to receive the remote results.More specifically, the developer should consider bandwidth variation for a more accurate estimate (see Section III-A).Equations 2 and 3 consider the probability of there being tokens in the offloading place (variable O mj ) as well as in the receiving place (variable R mj ) for other methodcalls other than mi, respectively.BW of f loading represents the actual bandwidth allocated for tasks offloading -in bits/s.BW receiving represents the actual bandwidth allocated to receive the remote results -in bits/s.Thus, if other methods are using the allocated bandwidth, the bandwidth allocated for the operation (i.e.offloading or receiving) is divided among the methods that are using the network for the same operation.Equations 4 and 5 calculate the communication time to transfer an amount of data taking into account the actual bandwidth allocated to the evaluated method mi.datasize o mi represents the amount of data transferred to offload the method mi -in bits.datasize r mi represents the amount of data received as the result of the remote processing of the method-call mi -in bits.Equations 4 and 5 are assigned as the mean delay value of transitions offloading time mi and receiving time mi of the method-call mi, respectively.In the evaluation process, developers must convert Equations 4 and 5 to the syntax of the stochastic evaluation program used.
After that, a transient analysis on the model obtains the MTTE.A tool such as the Mercury, TimeNet, GreatSPN or SHARPE may execute this analysis.These tools generate the state space of the SPN model and create the corresponding CTMC.Then, the calculations described in the next section are performed to obtain the required metrics.The behavior of the CTMC can be described by the Kolmogorov equation given the initial probability vector π(0) (see Equation 6).Equation 7gives the expected total time the CTMC spends in state i during the interval [0, t).The time spent before absorption can be calculated restricted to the states of the set of non-absorbing states (N ) by lim t→∞ L N (t).Thus, L(t) satisfies the Equation 8 where π N (0) is the vector π(0) restricted to the states in the set N .Q N is the infinitesimal generator matrix restricted to the non-absorbing states.Finally, MTTA may be described as Equation 9 [4].

C. Throughput and Data Transfer Volume
The throughput (T p) represents the number of executions per unit of time of a set of method-calls.T p is obtained by computing the expected value of tokens at a place, multiplied by the inverse of the transition delay [11].Now, as illustrated in Figure 5, the model needs two transitions to allow it to return to the initial state when workload execution is complete.
Such SPN pattern may be extended to evidence the methodcalls data dependency of any application.
The throughput may be calculated considering two possibilities: Single Server Semantics (SSS) and Infinite Server Semantics (ISS).Equation 10calculates the throughput according to the SSS strategy, and Equation 11 for ISS.The variable i represents the weight of the arc that connects the place INACTIVE and the subsequent transition T0.The variable i may vary until N, where N is the highest enabling degree of the subsequent transition at the place marking m(IN ACT IV E) = i.
Using the Equation 12it is possible to obtain the total transferred bytes (TTB).Time represents the evaluation period in milliseconds.Bytes represents the volume of data transferred in each request.This section presents a case study observing the execution time metric using an application for reducing images color.

A. Color Reduction Application
We implement and analyze an image processing mobile application following the principles of method-call computation offloading [8].The implementation uses a simple clientserver architecture with Remote Method Invocation (RMI).The relevant parts of the offloading source code are presented in Listing 1.
Application A resides on the mobile device and its methodcalls are dependency free (lines 5 to 6).That is, the methods may be executed in parallel.If the method-call is offloaded to the cloud, it means that the app makes image processing calls to the server by passing one input (original images).In this case, the app connects to one virtual machine and then calls the method reduceColor in the server side.Thereafter, the processed image returns to the mobile device.Table I reveals the method-calls distribution scheme of the application.
Both client and server side adopt the Open Source Computer Vision Library [3] and JavaCV [2].We have implemented the computing vision example of Picture's Colour Reduction [1].This example transforms images by decreasing the number of colors depending on the picture's size. 1) The Evaluation: Table I demonstrates the evaluated scenarios.The testbed executed all method-calls local and remotely (using one VM as offloading target).Through a controlled experiment, the collected input parameters for each method-call were (see Tables II and III): (i) the processing time to process the image and (ii) the number of bytes sent and received.As we can see, processing times are lower when the code is running in the cloud.The experiment executed and monitored 50 times each scenario.At the end of the process, the testbed collected the mean values of them.The analysis evaluated both the application's MTTE as well as the data traffic generated during a period of 30 days for 1,000 active users.Each user makes requests at a rate of 1/(21, 000, 000 ms) exponentially distributed.We have considered that the available BW may vary within a specified limit (see Table IV) impacting the MTTE in each variation.
First, it is necessary to analyze the MTTE of each scenario.Figure 3b represents the SPN model of the application.Transitions processing time m1 and processing time m2 are exponential.They store the mean processing times of the method-calls m1() and m2(), respectively.We have evaluated the four scenarios through the combining of the four processing time values.Equations 4 and 5 were used as the mean delay value of the transitions that represent the offloading and result receiving processes, respectively.We have calculated MTTE taking into account the worst-case BW requirement tolerated by the application as well as the expected network scenario (see Table IV).MTTE will be within these limits.Among other factors, MTTE will vary because of the inherent latency of wireless networks.The next step is to identify the expected throughput for each user in each scenario using the SPN model presented in Figure 5. Transition T0 receives the request rate which is equal to 1/(21, 000, 000 ms).A stationary analysis obtains the throughput using the Equation 10 (see Table VII).Now, let us estimate the total transferred bytes (TTB) generated by each scenario using the Equation 12. Table VI presents the number of bytes transferred for processing one user request in each scenario.Table VIII demonstrates the total bytes transferred in the evaluated period.
We can extract some conclusions by analyzing the results.The performance of scenarios #2, #3, and #4, when executed on the minimum BW requirements, was close to the performance achieved when processing the entire application locally    V).In scenarios #2 and #4 the actual BW available for offloading and receiving had a significant impact on the MTTE of the whole application.The higher the BW, the lower the MTTE.The method m2() is the heaviest, so it must be processed in the cloud.If m2() is processed locally, maybe it is not advantageous to only perform the offloading of method m1() -#3.The performance gain is small.Scenario #4 is most suitable but the volume of data transferred in the period is high (see Figure 6).Thus justifying the adoption of scenario #2 as offloading strategy.
Figure 7 shows the impact of the offloading BW variations on the MTTE.For sake of conciseness, we did not consider variation in the BW to receive the remote results (3.0 Mb/s).The higher the actual BW, the shorter the communication time.The offloading BW variation had little effect on the MTTE of the scenario #3.A large portion of the whole execution time was spent on local processing.On the other hand, scenario #4 was the most sensitive in relation to BW variation.All methodcalls were processed remotely.Scenario #4 transferred more data than the other ones.The larger the amount of data being transferred, the higher the impact of the BW variation.

V. CONCLUSION
In this paper, we proposed an Stochastic Petri Net (SPN)based formal framework to represent the partitioning of MCC applications in a method-call level.Through our modeling strategy, it is possible to evaluate performance and requests making by mobile users.Our framework considers the available bandwidth to send and receive tasks to the cloud.In this way, representing the communication time to transfer data between the mobile device and the cloud.Besides, we proposed an approach that supports data traffic evaluation using SPNs.Our approach highlights the most suitable options considering specific scenarios.Going forward, we plan to Available Bandwidth for Offloading (Mb/s) Figure 7: Bandwidth for Offloading and MTTEs perform more complex experiments and evaluate more metrics, such as energy consumption, and apply the ideas presented herein to other contexts, such as the use of wearable devices in MCC for real-time performance predictions.

Figure 5 :
Figure 5: SPN without Absorbing State Used to Calculate Throughput of an Application With Two Parallel Method-Calls

1 2 p 4 L 14 } 15 }
u b l i c c l a s s A p p l i c a t i o n A { 3 p u b l i c L i s t <Image> r e d u c e C o l o r ( Image img1 , Image img2 ) { i s t <Image> r e s u l t s = new A r r a y L i s t <Image >() ; 5 r e s u l t s .add ( r e d u c e C o l o r ( img1 ) ) ; / * m c a l l 1 * / 6 r e s u l t s .add ( r e d u c e C o l o r ( img2 ) ) ; / * m c a l l 2 * / 7 r e t u r n r e s u l t s ; b l i c c l a s s S e r v e r { 12 p u b l i c Image r e d u c e C o l o r ( Image image ) { 13 / / JavaCV c o d e s u p r e s s e d Listing 1: Client and Server Classes-Image Processing.

Figure 6 :
Figure 6: Comparing MTTEs and Volume of Transferred Data

Table I :
Scenarios to Method-Calls Executions .
Time-dependent metrics are obtained through transient evaluation.The measure of interest is the Mean Time to Absorption (MTTA).To calculate the MTTA, the model must have at least one absorbing state.In this work, the absorbing state is reached when the model is in the FINISH state.Figure4presents the CTMC that represents the elapsed time to finish the processing for an offloadable method-call.
Figure 4: CTMC of One Application with Only One Offloadable Method-Call With Absorbing State

Table II :
Registered Processing Times per Method-Call

Table III :
Transferred Bytes per Method-Call

Table IV :
Bandwidth Variation (in Megabits/s)

Table V :
Table V presents the respective MTTEs.MTTE of the Experiment

Table VI :
Transferred Bytes for Each Scenario

Table VII :
Throughput for Each User in Each Scenario

Table VIII :
Total Transferred Bytes for Each Scenario