4.1.1 User-centric Mobile Cloud Computing

The next-generation MCC applications demand tight integration of the physical and virtual functions running on the mobile devices and cloud servers, respectively. Moreover, due to the mobility of mobile users and the changes of the application running environment, the MCC application functions are not fixed on their running hosts. As an illustrative vehicle traffic management example shown in Fig. 4.1A, a vehicle may request Video Capture (VC) functions from other vehicles directly (the dashed line) or through a centralized video fusion function to get a holistic view of the entire road intersection. In this example, the VC providers are not fixed and are selected by their location. Moreover, a VC function may not only be used for individual vehicle, but also for road traffic management, accident/hazard detection, traffic monitoring, etc. The resources include mobiles, cloud servers, and corresponding networking that form an ad hoc cloud application running environment that can be customized for each individual user. We refer to such a customizable ad hoc cloud application running system as a user-centric MCC application. The basic functions that are used to form this MCC application (VC, display, and data fusion, etc.) are called Provisioning Functions (PFs) and is similar to the microservices described in Chapter 3, Section 3.4.

The user-centric mobile cloud application running environment can be further illustrated in Fig. 4.1B, where mobiles ($M_A,M_B,M_C$) and their corresponding cloud virtual resources ($CV{R}_A,CV{R}_B,CV{R}_C$) construct a pairwise resource pool $R_X=(M_X,CV{R}_X)$ including both physical and virtualized resource. $R_X$ represents the user X to construct MCC applications formed by a set of provisioning functions ${\{\mathit{PF}\}}_X$ running on local or remote resource pools. In this user-centric mobile cloud application running environment, a PF can be highly mobile, and it can be composed and used by multiple applications at the same time.

4.1.2 Design Principles of User-centric Mobile Cloud Computing

Future MCC should be reconsidered as a new service model, where mobile agents, i.e., both physical and virtual entities, and related resources collectively operate as mobile clouds that enable computing, storage and networking capabilities, context awareness modeling, content discovery, data collection and dissemination. To build the future user-centric mobile cloud computing based on the described concepts and requirements, mobile clouds should be shifted from the traditional Internet cloud by using the following principles:

•  Principle 1: User-centric. MCC applications should be designed in a way that the users can control their own data and activities with strong privacy and security protection. Cloud resources should be collected and allocated according to mobile applications customized for each individual user.

•  Principle 2: Service-oriented application platform. Due to the symmetric service model, every mobile node can potentially serve as an MCC service provider, and thus service-oriented application platform is the natural choice for MCC. With the popularity of IoT devices and services established based on IoT, microservice model has become one of important service frameworks for MCC.

•  Principle 3: Mobility-aware. MCC resources should be dynamically allocated and managed according to the need of mobile cloud applications. Mobility of MCC should be confined through a set of mobile cloud application constrains to maximize the efficiency using a set of system performance evaluation metrics such as availability, computing power, storage, and their spatiotemporal boundaries.

•  Principle 4: Virtual representation. MCC maintains a trustworthy, reliable, and accessible virtual representation for each user. The virtualized representation can be considered an assistant for mobile users and performs actions such as sensing a user's daily activity to build user's behavior and activity profiles, and delegates the user's activities in the virtual environment. The virtual representation concepts can be extended to any entity that may mirror its functions into the CVS.

4.1.3 Mobile-as-a-Representer: A User-centric Approach

The future mobile cloud service model should be delivered based on the principles illustrated in Section 4.1.2. Besides previously presented service models, i.e., MaaSC, MaaSP, and MaaSB, we present a new user-centric MCC service model called Mobile-as-a-Representer (MaaR). The architecture of MaaR can be found in Fig. 4.2. In MaaR, each user can be represented by a virtualized entity in the cloud through his/her physical entity (i.e., mobile device). User behaviors and attributes can be collected from the real world (people, environment, or mobile devices) in real time and sent to their corresponding virtual entities in the cloud to perform further analysis and processing. Data mining and machine learning algorithms can be used to analyze a mobile user's situation and perform actions proactively. MaaR can be regarded as the next-generation MCC service model in that both physical systems and virtual systems are seamlessly integrated through virtualization technologies to provide services. In MaaR, the mobile devices and clouds are highly interactive, and as a result, the service flow can be presented as bidirectional arrows. In addition to helping mobile entities execute tasks more efficiently, MaaR is able to accomplish some tasks that are impossible with current MCC architecture.

MaaR model is presented to support the next-generation user-centric MCC services and applications. A conceptual architecture of MaaR is presented in Chapter 1, Fig. 1.3, where both PS and CVS are integrated as a whole system. In the PS, heterogeneous networks coexist, and all these networks can be virtualized at the CVS by performing operations including presenting, offloading, abstracting, caching, migration, etc. All data with the spatial, temporal, and correlation information from the PS will be submitted to the CVS. Among all these three types of information, correlation information is essential in that it helps to fuse different types of data together into a well formatted one so that the CVS can further perform context awareness, user-centric proactive, and security protection tasks. For example, the sensor network carries the sensed data while the social network collects and generates the social relationship data. The correlation information helps the CVS to generate sensing data with social attributes (e.g., personal data that is only accessible from a specific social group, like people in the user's friend list).

In MaaR, the CVS has three main types of provisioning resources: computing resource, storage resource, and networking resource. The user's virtual entity is represented by maintaining seamless communication between the PS and the CVS, which also allows for establishing multiple personalized MCC clouds due to different application purposes. An MCC application is able to control integration of PS and CVS through a well-defined API and MCC tools. The traditional Internet cloud is one-way operational as users can only submit data from the PS to the CVS, while it is possible to allow the CVS to further control the PS functions in a highly adaptive and dynamic fashion based on the MaaR model. Besides physical data being virtualized, the CVS can provide feedback and control functions in the PS.

To enable the service-oriented application running environment, MaaR provides POEM (Personal On-demand execution Environment for Mobile cloud computing) framework [278] to achieve the user-centric MCC service running platform, where an illustrative vehicular system example is provided in Fig. 4.1. POEM is a mobile cloud application execution platform that enables mobile devices to easily discover and compose cloud resources for their applications. For mobile resource providers, they may not even know what applications and who may call their provisioned functions beforehand. In this way, the mobile application design should not be application-oriented; instead, it should be functionality-oriented (or service-oriented). To achieve these features, we can consider those PFs as the fundamental application components in the MaaR model, which can be composed by mobile cloud service requesters at runtime.

POEM takes a comprehensive approach by incorporating the OSGi-based [222] service-oriented architecture into MCC. OSGi bundles² are treated as implementations of PFs in MCC conceptual model. It treats the offloading as part of service composition, and as a result, bundles (or computation tasks) are considered services provided by mobile devices and the cloud. In this way, offloading and migration operations can be multidirectional (i.e., among mobile devices and the cloud) compared to one-directional (i.e., from a mobile device to the cloud) in previous solutions. Moreover, due to the popular Java-based OSGi framework, POEM can greatly improve the adoption of the Service-Oriented Architecture (SOA)³-based code reuse and composition for MCC.

4.1.4 An Application Scenario Based on User-centric MaaR Model

To better understand the proposed MaaR model, we revisit the vehicular video sensing and collaboration example presented in Fig. 4.1A. We assume that MaaR service modules are already equipped on many users' smart phones. When user Alice is driving, her smart phone uses onboard sensors, like camera or GPS, to detect her location, driving speed, and image/video captured on the road. As shown in Fig. 4.1B, the information can be collected and virtualized into the CVS to construct a virtual representation of the mobile device in the cloud for Alice, which is the essence of MaaR in that the virtual representer depicts the real situation of the physical user. Practically, the representer is implemented through a set of software agents (i.e., OSGi bundles) on a dedicated VM allocated for Alice, where Alice has the administrative privilege, to decide what data can be shared and protected (by encryption). The dedicated VM is the application holder for Alice to incorporate various data processing models and functions for security, data mining, and intelligent situation-aware decision making that are personalized for the uses of Alice. In this model, the VM can be hosted in public or private cloud as the choice of Alice.

User Bob may want to know the current traffic status around the bridge 5 miles ahead of where Alice is driving. Users with MaaR services running on their mobile devices near the bridge can provide sensing functions, e.g., GPS, video/camera, which are searchable by Bob so that Bob's display function can call those functions in real-time through either direct P2P connections or a centralized traffic monitoring function provided by a third party. In addition to the presented video capturing usage of the application, MaaR services and applications can also maintain social diagrams for each user. For example, when Bob is driving in the area during the lunchtime, the MaaR service representer of Bob can prepare for suggestions such as good nearby restaurants with high ratings by Bob's trusted friends. Other suggestions may relate to Bob's daily activities and job functions according to his current location, and can be provided promptly when Bob needs them. These personalized suggestions are based on correlating the location and various sensed data by the MaaR service representer.

4.2.1 POEM Application Framework

POEM is implemented based on OSGi framework [223] that is a general purpose, secure, and managed Java framework and supports the deployment of extensible and downloadable applications [223]. Due to the popularity of Java, OSGi framework is compatible with major operating systems for both desktop and mobile device systems. The layered framework is stacked from bottom-up into three layers: module layer, life cycle layer, and service layer. The framework defines a unit of modularization, called a bundle, i.e., “PF” in the POEM. In the later descriptions, we do not differentiate the terms bundle and PF. In POEM, a PF comprises Java classes and other resources, and is deployed as a Java ARchive (JAR) file. PF sits on the top of stacked layers and interacts with them through PF context. Module layer and life cycle layer handle PF installation and activation. PF can be installed/uninstalled and started/stopped. The service layer has a service registry and handles service publication and discovery. A service is a normal Java object that is registered under one or more Java interfaces with the service registry. PFs can register services, search for them, or receive notifications when services' states change. When PF is installed, the framework must cache the PF JAR file. A SERVICE_RANKING property may be specified when a service is being registered. The service with the highest ranking is returned when the framework receives service query. Before the service is consumed, it may become a stale reference. Service tracker is usually used for service consumer to prevent stale reference by obtaining reference when consumption happens. Besides local service activities, a distribution provider can export service to another framework by creating an end point or import services from another framework by creating a proxy for service composition, and then registering the proxy as an imported service.

POEM models a mobile cloud application as a set of PFs. The PF may provide class definitions and host services that implements PFs. POEM does not differentiate PFs on mobile devices and PFs on their VMs as the PFs may be migrated from mobile side to cloud side or vice versa without any modification. The uniform PF format makes PFs reusable and reduces develops' workload by avoiding developing separate PFs for specific platform. The application may use services provided by local or remote PFs. The application can migrate PFs between mobile devices and VMs without disrupting the other active PFs.

POEM achieves social feature through an implemented the XMPP [282] system within a cloud, e.g., MobiCloud [141]. The availability information of the system resources and mobile devices is maintained through a decentralized client–server architecture, where every mobile cloud entity needs an address called a JabberID (JID). JID is presented in the form of user@domain/resource. Domain represents the XMPP service provider, user represents virtual identity in the domain, and resource identifies connection to an XMPP server. Three basic status services are achieved through XMPP: message, presence, and info/query(or iq). POEM's service discovery protocol provides two discovery methods: one enables discovering information about an entity, and the other enables discovery of items associated with an entity.

In POEM, each entity, i.e., a mobile device or a VM, runs an OSGi framework, which is identified uniquely by its JID. One POEM entity discovers services hosted by his/her friends through XMPP service discovery protocol and XMPP publish–subscribe protocol. Mobile applications offload PFs to VMs through XMPP file transfer protocol, and the data exchange with remote application in POEM is through XMPP iq communication.

4.2.2 Execution Model

According to previous application scenario, there are three fundamental execution patterns in POEM, as shown in Fig. 4.4. The first pattern describes how one PF discovers remote available PFs, which is shown in Fig. 4.4A. PF b hosts a service and it publishes the service through local POEM for remote PF to discover. Then PF a can discover the published service on remote side with local POEM PF's help. One prerequisite for a to discover and use the service of b is that they are mutual friends. In other words, they are on each other's contact lists. PF a does not know that PF b is running on a remote side because POEM pretends that b is running locally. Thus, a programmer does not need special treatment in coding when developing PF a.

The second pattern presents how an application recruits a service provided by a remote PF, which is shown in Fig. 4.4B. The PF c sends method invocation parameters, which are transferred by the POEM on the local side and then on the remote side, to the destination PF d. Then, the service result returns along the reverse route from d back to c. PF c also believes it is calling a local target d due to POEM's transparent transfer, and d also thinks a local c is calling it.

The third pattern presents how one PF migrates to a remote entity. A POEM PF initializes the migration process. There are two types of migrations, pull and push. In pull migration, the POEM PF on the right side sends request to the left side POEM PF, and then the latter fetches and transfers the target PF e to the right side. In push migration, the POEM PF on the left side transfers PF e to the remote side. The source keeps the PF e active during transfer to provide the failsafe when the transfer is not successful.

4.3.1 Distributed POEM Service Platform

POEM's networking and signaling system is deployed based on XMPP approaches. The communication between POEM entities (i.e., mobile devices and VMs) is a full duplex compared to a half duplex HTTP approach deployed by many web-based service frameworks. In a distributed execution environment, any entity can be both a client and a server at the same time, which is different from web-based service models where clients and servers are explicitly defined. Moreover, POEM inherits the XMPP trust and identity management framework, where every POEM entity is authenticated when joining the system, and the data transferred is also protected through cryptographic approaches. As a result, the PF offloading and PF compositions can utilize the XMPP trust management framework with fine-grained access control capabilities. Furthermore, POEM entities need to provide their presence information to indicate their availability information in real-time, which is also used to indicate their service status.

4.3.2 POEM Implementation

POEM Manager consists of several objects as shown in Fig. 4.6. They are categorized as three sets – XMPP connection and related listeners, PF context and related listeners, and proxy and migration management. The three object sets represent three POEM functional sets: XMPP connection set represents remote POEM framework; PF context set represents local POEM framework; proxy and migration management represent core POEM logic and operation that connect the other two parts.

XMPP connection object maintains three XMPP managers that manage service discovery, publish–subscribe, and file transfer separately. Besides, it also maintains a roster that publishes local presence and a publish node that local service change notification is posted on. There is a set of listeners registered with XMPP connection. They are noticed when corresponding events occur. Roster listener tracks friends' presence and updates proxy pool accordingly. Item event listeners, one listener for each friend, waits for friends' service change notice and updates proxy pool accordingly. Connection listener monitors connection status and executes robustness strategy. File transfer listener handles file transferring. Packet listeners handle iq packets defined in POEM name space between POEM PFs. Service discovery provider responds to remote service discovery by querying PF context.

Other POEM components are as follows: PF context handles interaction to POEM framework. Service listener monitors local service change and publishes change to a publish node maintained by XMPP connection. Proxy management contains a database and a proxy pool. It memorizes remote service status and local proxy status in database, and provides proxy generation and recycling methods. Migration management implements migration service registered by POEM Manager. PF repository provides JAR file source for file transfer request.

4.3.3 Seamless Offloading

POEM Manager registers a service with a Java interface that contains a method to do service migration. Service migration involves two framework instances that are the source and destination frameworks. The offloading process can be illustrated using the following application scenario. The source is device 1 and the destination is a VM. The migration method is called on device 1. Service name and destination XMPP identity are passed to the migration method. The migration process consists of five steps as follows. First, a migration notice is sent by device 1 to the VM. Along with the migration notice, the PF JAR file that owns the indicated service is transferred from device 1 to the VM. Second, POEM Manager in the VM starts the PF. When PF is running, services including the indicated service are registered. Third, POEM Manager in the VM is notified with service changes in last step. It unregisters the existing proxy under the same service name. Then it publishes the new services to the VM's publish node. At this point, both sides have the running PF that provides services to local PFs. Fourth, POEM Manager on device 1 is notified due to the publishing in the last step. It creates the proxy for the published services with a higher ranking. Then it stops the local PF. At this point, the PFs on device 1 are consuming services provided by the VM. The sequence diagram of migration process is shown in Fig. 4.7.

Besides device 1 and the VM, a third framework instance on device 2 is using the service being migrated. When POEM Manager in the VM signals the new service, POEM Manager on device 2 creates a proxy for the new service with a higher ranking than device 1 does. When POEM Manager in the VM signals the service recycling, POEM Manager on device 2 recycles the proxy for that service. Other PFs on device 2 are not disturbed during the process.

4.4.1 Methodology

The POEM Manager is implemented on Felix [52] OSGi implementation version 4.0.3. Felix cached PF JAR files are used as POEM Manager repository. XMPP PF from SpringSource [252], which wraps smack XMPP library version 3.1.0, is used as XMPP implementation.

Mobile application that contains a Felix OSGi framework instance that hosts POEM Manager runs on Android Motorola phone A855, running Android version 2.2.3. The phone's parameters are 600 MHz CPU and 256 MB memory. One Felix OSGi Gogo Shell runs in one Ubuntu virtual machine hosted by a cloud. The virtual machine's parameters are 1 GHZ CPU and 512 MB memory. The Ubuntu version is 11.10.

Four applications are used to evaluate the POEM performance. They are Fibonacci sequence generator, N-Queens puzzle, nested loop, and permutation generator. The Fibonacci application generates the Fibonacci sequence in a recursive manner. Its time complexity is $O(2^n)$ and its stack usage is high due to the recursive algorithm. The N-Queens application calculates all solutions for the input chessboard size. Its time complexity is $O(n^2)$ and its stack usage is also high due to the recursive algorithm. The nested loop application contains a six layer loop which leads to time complexity $O(n^6)$. The permutation application's time complexity is $O(n!)$ and it uses little memory. Experiment result is obtained by running the application 50 times for every scenario and then averaging. Between two consecutive executions there is a pause of 1 second.

The experiments are run under two scenarios:

•  Phone – the applications are run only in phone.

•  WiFi – the phone is connected to the VM through WiFi.

The WiFi connection has average latency of 70 ms, download bandwidth of 7 Mbps, and upload bandwidth of 0.9 Mbps. Ping is used to report the average latency from the phone to the VM, and Xtremelabs Speedtest [42], downloaded from Android market, is used to measure download and upload bandwidth.

4.4.2 Macro-benchmarks

For typical input parameter values, four applications are run on the phone and in the VM separately. The application running time is recorded in Table 4.1. By subtracting time on the phone and in the VM, the max speedup is put in the last column of the table. However, the max speedup is seldom achieved due to cost of communication and proxy. This cost changes a little while offloading, but the benefit changes a lot, so there should be some point when the benefit of offloading surpasses its cost, giving application net gain.

Boundary input value (BIV) [169] is measured to show the offloading benefit starting point. The BIV values are shown in Table 4.2. The result shows that BIV is higher for an application that is of high time complexity and space complexity. High time and space complexity application component tends to be offloaded and migrated to the VM. So BIV provides an indicator for application optimizer to decide which service should be offloaded and migrated to the VM. By comparing BIV and expected value range, the application can decide whether to move to the VM. For example, if one application often calculates Fibonacci numbers greater than 50, the Fibonacci component should be put into the VM. On the contrary, if the Fibonacci component is usually called with input less than 10, it is not necessary to be moved out of the mobile device.

The macro-service execution time evaluation results are presented in Fig. 4.8. Fibonacci application takes a sequence index number and calculates the corresponding number in the Fibonacci sequence. Fig. 4.8A shows the execution time of Fibonacci application. The intersection of execution time on the phone and WiFi offloading is the BIV value. N-Queens application takes a chess board size and calculates all solutions and returns solution number. Fig. 4.8B shows execution time of N-Queens application. The execution time on the phone rises dramatically as the chessboard size increases one scale step. Offloading offers benefit as soon as the chess board size is larger than 10. Nested loop application takes loop times and executes a loop without memory operation. The execution time on the phone is convex, which means it is less than an exponential increase compared to the above two applications that require both computing and storage. The execution time of offloading increases slowly. Permutation application takes a max number N and returns count of prime number within the range $(1,N)$. The prime number searching algorithm used is Permutation algorithm. The execution time increases on the phone; however, the execution time for offloading approach remains almost the same.

The offloading line of the four applications is increasing slowly compared to the phone line. As the phone line starts from a low point, which indicates the application runs fast when input is small, the offloading and phone lines intersect finally. Comparing the offloading line and the VM execution time column in Table 4.1, the slow increase is reasonable due to the execution time increase, which is slowing in the VM as well. Besides, the starting point of the offloading line is higher than that of the phone line, so there must be a cost for the remote method invocation.

4.4.3 Micro-benchmarks

This experiment measures service invocation time. The time is measured on the phone where there is service on the consumer side. The remote service consuming time consists of three parts: marshaling time of both consumer and provider sides, network transfer time, and actual execution time. The result is shown in Fig. 4.9.

Fig. 4.9 shows time against different input parameters. The actual execution time is similar to the execution in the VM; see the VM time column in Table 4.1. At the beginning, execution time is nearly zero. The execution time increases as input parameter increases. Fig. 4.9 shows that marshaling time is relatively small compared to network delay. Fig. 4.9 also shows that the main cost for the remote method invocation is network delay around the BIV point. And marshaling time and network time against different input parameters are approximately identical. The marshaling and network cost determines the starting points of the offloading lines in Figs. 4.8A–D. And execution time determines the trend of those offloading lines. If the network delay or the marshaling is reduced in some situation, the offloading line will drop and then BIV point will go to the left, which means the range of benefit will increase and application components are supposed to be offloaded to the VM. In another perspective, if the component's ratio of computation cost to network cost increases, it is better to offload that component to the VM.