Personal data storage on mobile cloud

One of the key concerns for people about using a mobile cloud is that their personal data on mobile device could be stored on, or accessed by the cloud. A mobile device contains contact lists, text messages, personal photos and videos, calendars, location information, and these data can reveal many things about someone’s personal life. However, a personal computer also stores many such personal data such as photos and other multimedia, chat logs, emails, passwords, financial records or access to such records, calendar and contact lists. Today, thousands of monetary transactions are being done in online shopping sites such as eBay, and Amazon. Therefore, the risks involved in mobile cloud are not necessarily greater than those involved in traditional clouds. However, the issue here is whether the means of handling those risks have been properly implemented in the mobile cloud. Despite reservations, people do tend to use their mobile devices with the cloud. Some recent examples of mobile cloud storage are Apple’s iCloud, Google Drive and Dropbox. Apple iCloud enables users of iOS devices to synchronize their application data such as photos, iTunes music, calendars, email, and messages. An initial 5 GB of iCloud storage is free for an Apple user, with additional storage available for a monthly fee. Although iCloud offers an Apple user an impressive user friendly feature suite (such as Find my Phone), it is only for data related to Apple devices. In contrast, Dropbox is less specialized, but works across heterogeneous platforms including Microsoft Windows, Linux, Mac OS, iOS, Android, and Blackberry. Dropbox also allows sharing stored data with friends, and file revisions.

Data management

For many cloud users and providers, managing data on the cloud raises many complications. In mobile cloud computing, as the name itself suggests, data that would traditionally be only accessible only to the mobile device’s owner, would now be stored on, accessible to, shared with external devices or users. For many mobile users, this raises privacy and security questions. Also, data representation in mobile devices vary, and in a heterogeneous mobile cloud, this would lead to problems with portability and interoperability. Computations in a mobile cloud would be spread across a distributed file system, where multiple devices may need to access and modify files.

Furthermore, special considerations must be given to accessing files from mobiles over wireless networks. In a mobile cloud, users geographical locations are not fixed, and bandwidth must be conserved because of data access costs. However, it is also vital that mobile databases contain policies to safeguard against data loss while ensuring it conforms to mobility constraints. We discuss these issues in the following subsections. Issues regarding data privacy and security are not discussed here, since they have already been explained at length in Section 4.4: Privacy, Security and Trust.

Energy awareness

Because a mobile device operates on a finite supply of energy contained in its battery, energy is one of the key resources that needs to be used carefully [99]. In the context of mobile clouds, the cost of participation (such as power consumption) should be less than the benefit gained [100]. Also, it will enable the mobile device to take appropriate component level action to minimize unnecessary energy consumption, and hence, lengthen the system’s life span by unloading unneeded software components, redeploying energy intensive components to more resourceful hosts, and collocating frequently communicating hosts, as suggested in [101]. For these reasons, being aware of a device’s energy usage is vital.

In the following we discuss the research on energy consumption, mainly focusing on work on energy profiling and energy usage estimation.

Energy profiling. In PowerScope  [102] the authors present a profiling tool for mobile applications. The tool maps power usage to specific code components in applications and the operating system, allowing an analysis of power draining procedures. Using this analysis, the developers can modify their software to be more energy efficient. The authors report a 46% energy saving by using PowerScope to profile an adaptive video application run on the Odyssey platform [44]. Experiments were carried out with several laptops and pocket computers. Profiling is done offline after collecting data, to ensure no overheads are added to the analysis. A digital multimeter measures the electric current used by the profiling computer and the energy profile is generated using these correlated current measurements. The apps can only be profiled on an open source operating system however, as small modifications to the kernel are required.

In [103], Rice and Hay present a power consumption measurement framework, specifically for mobile phones. In particular, they explore the effect of message size and send buffer size when transmitting data on two Android 1.5-based phones. Power usage during connection to a WiFi network and idle power costs for WiFi, 3G and 2G are also discussed. Power consumption is measured by sampling the voltage drop across the phone battery and a high precision resistor. The mobile device first downloads the test script from a central server and uploads the results to the same server. The central server aligns the test results with the traces and logs. Their findings can be summarized as follows:

1.

When connecting to a WiFi network through DHCP, a significant portion of the time and therefore power, are taken by the ARP Probe packets and the delay between them.

2.

In the case of idle power, WiFi has the lowest energy cost, followed by 3G and 2G respectively. However, it should be noted that the locations of the base stations will also affect radio transmission.

3.

Although it would be logical to expect that the energy cost per byte will decrease as the message size increases, results show that this is not the case. There appears to be a sharp increase of power cost from sending a 7 kB message to 8 kB. However, the reason for this is not clear.

4.

The choice of buffer size can significantly affect the power consumption.

The work discussed previously measures the energy via hardware. A different approach is to take the measurements via software to query battery levels as done in PowerSpy [104], implemented in the Windows operating system. PowerSpy operated in two stages; event tracking and analysis. In the event tracking stage, the application is run and tracked for CPU time, I/O activity and energy consumption. In the analysis stage, the data acquired in the previous stage is processed. To filter out the energy consumed by I/O activities, an estimation of energy usage by various devices to run particular tasks (such as energy used by the disk to read 1 kB) as specified by the devices manufacturer, is used. This estimation is subtracted from the total of recorded energy use, and the remainder is taken as the energy taken up by CPU threads. Next, energy consumption is drilled down to individual threads, on the assumption that CPU power usage is proportional to the number of CPU cycles spent on a thread.

Work done by Cano et al. [105] and [106] provides insight into the energy consumption of the Bluetooth protocol. The focus of their work is on the different states of Bluetooth such as Startup, Standby, Inquiry, Connection and especially the low power modes provided by the protocol.

Energy usage estimation. Work done by Chiyoung et al.  [101] and Seo et al. [107]focused on the energy (electrical) consumption estimation of Java based pervasive systems at the level of its system level components. The initial estimation in [101] is done prior to runtime—during construction time. Then the estimation is refined during runtime automatically depending on certain system parameters such as size of data exchanged over the network, inputs to the components’ interfaces, and invocation frequency of components’ interfaces. The exact formulas for calculating the estimation are given in [107]. Their methodology gives an Energy Cost Framework as follows:

•

Overall Energy cost = Computational energy cost + Communicational energy.

•

System Energy cost = Overall Energy cost + Overall infrastructure energy cost

where infrastructure cost is the cost incurred by the operating system. The computational cost is determined by the level of its public interfaces and the computational cost of an j$$th invocation of an i$$th interface on a given JVM is modeled in terms of byte codes, native methods and monitor operations. Communication cost due to the j$$th invocation of component c₁${}_{\mathrm{}}$’s interface I₁${}_{\mathrm{}}$ on host H₁${}_{\mathrm{}}$ is calculated in terms of the size of the transmitted and received data and the energy consumption of transmission/receive cost of H₁${}_{\mathrm{}}$. The authors claim that based on their evaluations in which they ran distributed applications on Kaffe 1.15 JVM on Compaq iPAQ PDAs, their estimations are within 5% of the actual power consumption.

Risk assessment using context-awareness

In MobiCloud [37], context information is used to facilitate risk assessment and routing decisions. MobiCloud introduces Virtual Trusted and Provisioning Domains (VTaPDs), which is a service that can isolate different information flows in in different domains by way of programmable router technologies. VTaPDs identify these separate flows and create virtual domains. By doing this, a user is able to securely run multiple applications on different security domains, and to separate services for different settings based on context. The MANET’s contextual information such as device sensing values, location, and neighboring device status are recorded by the VTaPD manager, and used for risk management and intrusion detection procedures. Parameter values related to devices, network, content, and security such as battery level, connectivity, predefined goals, and privacy, are used to provide context-aware service migrations. Risk management is aided through context information because the status of the entire system (end-to-end communication delay, reachability of the destination, security status of each mobile node, etc.) is available. From this centralized data collection and processing, knowledge of the full MANET system is gained, and MobiCloud can easily identify malicious nodes.

4.5.3. Identifying potential resources and common activities using context-awareness

In [12], a Context Manager component is deployed to sense context information and store it to be used for other components such as Application Manager, which launches, intercepts and modifies an application according to the current context. Location and number of nearby devices in the vicinity are the key contexts, with location information used for mobility traces, and number of devices used to aid the forming of the mobile cloud. Thus, the system is made aware if a new device enters the resource pool, or leaves it, thereby leading to better scalability and content distribution. Furthermore, this information is used to infer if a particular device is ‘stable’ or not, which is essential to decide if it is following a common movement pattern with the other devices, leading to common activities.

Context-aware service provisioning

It has been suggested that, mobile clouds can utilize the sensing abilities of their mobile devices such as location, acceleration, etc. and act as providers of context awareness/information. In [95] the authors suggest utilizing the sensing capabilities of mobile Internet devices to provide such context-aware service provisioning. Consider a mobile device connected to a remote cloud service through the Internet. As the context of the user changes, this prompts invocation of different cloud services based on the current context. With this kind of context-awareness, a service would not be bound to a user. Instead, when a mobile user invokes a cloud service, the request is accompanied by his/her context information, and the most suitable service is selected based on that information. Therefore, context is used to provide personalized services, and also as fault tolerant mechanisms such as rectifying low quality of service problems. Here, the authors identify a model consisting of four layers of context elements:

1.

Monitored context: refers to current monitored context consisting of: device context which includes the environmental and device settings, user preference for user-specific preference settings, such as those regarding services selection and invocation, situational context relating to monitored data on user location, time etc., and Service Context information such as QoS.

2.

Types of gaps: refers to gaps that happen as a result of content changes. For example, when the user’s service is changed from Service1 to Service2 owing to a context change, there is a gap between the two services. Mainly, two types of gaps are identified: gap on functionality that relates to an available service and the needed service, and gap on nonfunctionality relating to differences in QoS values between the previous service and the current one.

3.

Types of causes: refers to the factors that can cause the aforementioned gaps. A service may have multiple interfaces, and an interface may have different implementations. Similarly, there can be different component instantiations for the same service component. The gaps arise because of the mismatches between these: Service-level Unmatched, Service Interface-level Unmatched, Service Component-level Unmatched, and Component Instance-level Unmatched.

4.

Adapters: refers to the remedial actions that should be taken to remove the aforementioned causes.

Based on this model, the authors propose a context aware service provisioning architecture consisting of three tiers: User Layer that is made up by the mobile devices where the applications run on, Agent Layer that adapts the services according to context, and Service Layer that deploys the services.

Volare [96] introduces a middleware for monitoring the context of a mobile device that is connected to a cloud service, and dynamically adapts the services so as to make them more resource efficient, reliable and cost efficient. Acting as an intermediary, VOLARE intercepts service discovery requests from applications while monitoring mobile device’s context such as battery consumption, CPU usage, network bandwidth, user preferences like low power operation etc. Depending on this contextual information, VOLARE tries to adapt each service request by comparing the current QoS level with predefined thresholds. Instead of modifying the applications, a declarative language has been created to describe the adaptation policies. If at any time, the QoS level and the cost changes beyond the predefined values, VOLARE will automatically rebind to another service that can satisfy the requirements.

In MoCA [59], a proxy can register an ‘interest expression’ on a mobile, i.e., “FreeMem <10 kB” for a particular client, which would result in the proxy getting notified if and when the client’s free memory drops below 10 kB. These context specific “interests” depend on those specific applications requirements. For example, if the proxy gets an update that a client’s wireless connectivity has gone down a certain point, it could take certain actions such as compressing the data.

Using ‘Intelligent access’ for Mobile Cloud Computing is discussed in [97], where use of context information provided by terminals, network nodes, or sensors deployed in the users environment enables efficient network access management across different Radio Access Technologies (RATs) such as GPRS, WCDMA/HSPA, LTE, WiMAX, cdma2000 and WLAN. Conventional intelligent access schemes assume that all categories of dynamic context information such as user profiles, terminal status and sensor information and external sensor networks would aid in improving mobile access. However, mobile cloud computing requires a wireless connection with a set of different necessities than classical heterogeneous access scenarios: connectivity for long periods, scalable bandwidth, network selection and usage based on energy costs. To satisfy these requirements, the paper proposes Intelligent Radio Network Access (IRNA). The status and attributes of each RAT is considered, while at the same time effort is taken to entertain the user requirements based on environmental factors. Their proposed context management architecture (CMA), based on the producer–consumer role model such as given in [98], is responsible for acquiring, processing, managing, and delivering context information. To control the supply of context information according to the mobile cloud’s requirements, the framework has a Context Quality Enabler (CQE). The CMA is made up of three components:

1.

Context Provider (CP): this is where the context information originates from and is provided to other components of the architecture. The communication between CPs and other components are done through context requests.

2.

Context Broker (CB): acting as a middleman, the CB keeps a registry of available CPs and their capabilities, and provides a CP look-up service. Also, the CB itself is able to forward the data it receives from CPs.

3.

Context Consumer: these are the entities that take context data as inputs for their actual functionality, e.g.: network services, applications for end users, and service enablers.

In MiPeG [25], a middleware for integrating mobile devices into grid environments, several mechanisms for providing and using context awareness are discussed. Context information such as location, resources and environment conditions is used to adapt the services provided by the grid, using Semantic Web technologies, thus supporting the ‘pervasive grid’ concept. The ‘Context Reasoning Engine’ forms the main component of the context service. Its responsibilities include handling the context, information gathering from sensing devices, and forming higher level semantic rules depending on the context information received.

Context-awareness

Schilit et al. [94] describes the three important aspects of context as: the user’s location, other users in the vicinity, and the resources in the user’s environment. For example, in a mobile user’s perspective, ‘context’ means things such as lighting, noise level, network connectivity, communication costs, communication bandwidth, and even the social situation.

Importance of context-awareness for mobile clouds. Systems with context-awareness are able to use contextual information to change and automatically reconfigure their configurations to adapt to the context  [44]. This behavior is very useful in the case of mobile systems since these deal with an execution environment that is subject to constant change. In the case of mobile cloud computing, context awareness can be used in forming resource clouds as well as processing information. For example, a device can infer its location through GPS, Bluetooth, or some other forms of positioning and use that information to prepare itself for upcoming processing.

In the rest of this section, we review the use of context-awareness for mobile cloud computing systems, and also discuss a key concern of mobile device, energy awareness.

Mobile cloud security

In addition to the aforementioned concerns, securing a mobile cloud introduces the following challenges as discussed in [85] where the authors propose a security model for elastic applications made up of ‘weblets’ that can be migrated to and from a cloud to a mobile device:

1.

authentication between the weblets that would be distributed between the cloud and the device,

2.

authorization for weblets that could be executing on relatively untrusted cloud environments to access sensitive user data, and

3.

establishment and verification of trusted weblet execution cloud nodes.

Their security framework is based on the assumption that the cloud elasticity service (CES), including the cloud manager, application manager, cloud node manager, and cloud fabric interface (CFI), is trustworthy. The security threats are categorized as threats to mobile devices, threats to cloud platform and application container, and threats to communication channels. The authors propose a framework with the following security objectives: Trustworthy weblet containers (VMs) on both device and cloud, authentication and secure session management needed for secure communication between weblets and multiple instantiation concurrently, authorization and access control enforcing weblets on the cloud to have the lowest privileges, and logging and auditing of weblets.

MobiCloud [37] aims to provide a security services architecture for MANET clouds in three ways:

1.

Acting as an intermediary for identity, key, and secure data access policy management: Identity management is supported by Attribute-Based Identity Management (ABIDM), which supports user-centric identity management schemes also known as Identity 2.0. They propose ABKM, a system for key management, which is an extension of identity-based cryptography. However, in ABKM, the Trust Authority (TA) generates private key components for each user depending on their public attributes, and the key exchange protocol is not required. Therefore, this is effective for delay tolerant MANETs where the source and the destination do not usually talk prior to sending the data.

2.

Protect information belonging to mobile users by means of security isolations: MobiCloud has Virtual Trusted and Provisioning Domains (VTaPD), which are virtual domains enforced with resource isolation. A VTaPD contains various nodes corresponding to different physical systems. Nodes in the same VTaPD support the secure MobiCloud communication system when passing messages to each other. A cryptography based approach is used to enforce data access control and information isolation.

3.

Assess risks by monitoring MANET status: the centralized data collection and processing in the MANET is used by the risk management service to identify malicious nodes and take preventive measures according to estimated risks.

General cloud security

In [84] Brodkin outlines seven security risks users need to consider in Cloud computing;

1.

Privileged user access: offloading sensitive data to the cloud would mean the loss of direct physical, logical and personnel control over the data.

2.

Regulatory compliance: the cloud service providers should be willing to undergo external audits and security certifications.

3.

Data location: the exact physical location of user’s data is not transparent, which may lead to confusion on specific jurisdictions and commitments on local privacy requirements.

4.

Data segregation: since cloud data is usually stored in a shared space, it is important each user’s data is separated from others with efficient encryption schemes.

5.

Recovery: it is imperative that cloud providers provide proper recovery mechanisms for data and services in case of technological failure or other disaster.

6.

Investigative support: since logging and data for multiple customers may be co-located, inappropriate or illegal activity should they occur may be very hard to investigate.

7.

Long-term viability: assurance that users data would be safe and accessible even if the cloud company itself goes out of business.

Privacy, security and trust

Whether offloading intensive computations, or data storage, using the cloud for mobile devices does pose questions of security and trust issues. In her article in [80], Kharif outlines the potential pitfalls in using cloud services for mobile devices. Because of the low capacity of mobile device storage, many users are starting to store data such as contacts, calendars and SMS on clouds. However, these cloud services are stated to be vulnerable and users may lose their data if the services go out of business, or simply if the services fail due to technological problems.

Recent examples. For example, in the October of 2009, a large number of T-Mobile Sidekick users discovered that their personal data stored in the mobiles had disappeared due to a server failure  [81]. The Sidekick data, such as users’ contacts, photos and calendar appointments, was stored in a cloud service operated by the Microsoft company Danger. Although the majority of users did recover most of their personal data by November, this outage caused many difficulties, and raised many questions about how secure and robust the cloud really is.

Is cloud security applicable to mobile clouds as well? Mobile cloud computing inherits the security threats of conventional cloud computing in cases when the definition of mobile cloud means to connect mobile devices to a remote cloud. In this case, the remote cloud server would be the same as a conventional cloud computing provider, making the general cloud security threats valid. At the same time, mobile clouds present a group of issues that are particular to mobile devices offloading jobs through wireless communication channels. Furthermore, security concerns that are specific to mobile devices such as battery exhaustion attacks  [82], mobile botnets and targeted attacks [83] should also be considered.

Cloud APIs

Mobile clouds have been implemented using APIs provided by distributed computing frameworks such as Hadoop [14] and Ibis [77]. Futhermore, there are cloud APIs catering to mobile devices as well. For example, the Funambol Cloud API¹³ provides server and client side SDKs to develop mobile cloud applications and services that make use of images, calendar, contacts etc. stored in a Funambol server. Other open source APIs include Eucalyptus,¹⁴ Nimbus,¹⁵ and OpenNebula.¹⁶ Commercial cloud APIs include frameworks such as Dropbox,¹⁷ Azure,¹⁸ Amazon and Google Apps.

Supporting performance at service level

A majority of Application Programming Interfaces used to build mobile applications targeted for cloud computing are based on service oriented architecture such as REST and/or SOAP. Mobile applications are able to connect to and request services hosted on a remote cloud through interfaces. However, mobile Web services need to consider additional constraints other than standard Web services: frequent loss of connectivity, low computational resources, and low bandwidth.

Web service caching. To improve the user experience that can be hindered because of disconnection, caching and prefetching has been proposed in research  [78] and [79]. This approach enables the user to continue his/her work for a period of time while in offline mode. Furthermore, caching and prefetching also gives an increased response time. In [78], CRISP, a SOAP cache that can be embedded in client side application, or deployed as a separate proxy, is introduced. In [79] a dual caching strategy is proposed, where both the nomadic client and server have caches running, storing request–response pairs. Even though the overhead of storing these pairs is considerable over time, the performance gain is significant.

Fault-tolerance for meeting availability requirements

Fault-tolerance is a highly important aspect in a mobile cloud, even more so than a conventional cloud because of the mobile nature of the devices, i.e. “mobility is inherently hazardous” [2]. Disconnection can happen due to user mobility as devices enter and leave a network. Running out of battery power, network signal loss, or hardware failures are other common factors.

Redundancy. The FT support in Hyrax  [14] comes from the FT mechanisms of Hadoop on which Hyrax is based. Hadoop recovers from task failure by re-execution and redundancy. If node failure is anticipated, the task is replicated on another node/s that is deemed to be stable. In their testing and evaluations, where applications such as Sort, Grep and Word Count were ported, it was found that Hyrax was able to recover more effectively when the number of nodes was higher.

In [12] although FT is not implemented, it is mentioned as future work, where the authors suggest using context-awareness for fault-tolerance purposes. Context information would be used to judge if a node is unstable, and if so, task redundancy could be carried out to increase the success level of task completion.

Proxy migration. In  [62] FT is achieved by migrating the proxy service. In the event that a proxy node fails, its place is taken up by another node in the service cloud so as to ensure minimal disruption to the communication stream/s. This was tested using a testbed comprising PlanetLab nodes and hosts on a university intranet, and two strategies were implemented: on demand backup where another service is migrated as soon as system detects failure, and ready backup where a backup node is configured by default at the time of service composition. Of these two strategies, the ready backup was slightly faster, as can be expected, since the system only needs to reconfigure the relay to forward the stream in that case. The authors also suggest using the client middleware to trigger reconfiguration faster in future work.

Resource tracking. In  [77], Palmer et al. proposes using the Ibis grid computing platform to address similar problems in mobile computing. The Ibis framework enables users to integrate their mobile devices onto the grid taking advantage of the grid’s computational power. Here, FT is achieved by the Ibis system’s resource tracking model using the ‘JEL’ API standing for ‘Join, Elect, Leave’. As the name suggests the JEL API gives the system malleability, enabling it to adapt as new mobile nodes join and leave the network. The ‘Join’ operation notifies the application when a new node connects to the distributed system, thereby facilitating the applications to scale up. The ‘Elect’ operation is used to elect a node into the coordinating role. Whenever a node is disconnected, whether by choice or fault, the ‘Leave’ operation notifies the application and triggers an ‘Elect’ to select a new node to fill in.

Incentives to collaborate

In cases of mobile devices themselves acting as resource providers as discussed in Section 3.2 and in works such as Hyrax [14], the participating devices need to have incentives as to ‘loaning’ their resources. Furthermore, there need to be mechanisms to prevent ‘free riding’.

In [12], users are enticed to participate in sharing their mobile resources by ‘common goals’. If many users need to execute the same task, it can be partitioned so that each user only has to do a small part. The result of the task will be shared among all the participants. For example, consider the case of a group of people performing an activity together, such as visiting a museum. Say someone is interested in translating a foreign text on an exhibit, but his/her phone does not possess the capabilities or resources to process such a task. Connecting to a remote server via the Internet would mean paying for data roaming. His/her solution is to collaborate with other people in the same group who would also be interested in translating the aforementioned text. The authors argue that people sharing the same location are also likely to share common objectives, thereby providing them with an incentive to share their resources.

For the same kind of collaborative cloud computing, monetary incentives can also be considered in the means of micropayment schemes as discussed in [69] and [70]. In [71], the use of monetary and social incentives for mobile distributed systems based on opportunistic networks have been discussed. Their focus is on message transmissions in delay tolerant networks (DTN) formed by typical mobile devices. The monetary incentives are proposed to be implemented in the form of prioritizing the payload in the order of importance. Thus, a selfish mobile host will only relay a message with a certain priority or higher since it implies the sender is willing to pay a price for successful delivery. The authors argue that, as the mobile hosts become more and more selfish, the delivery rate of high priority messages become higher while the low priority message delivery rate slowly decreases. However, this result depends on the high to low priority ratio as well, since if all messages have a high priority, there will be no discrimination.

The social incentives are based on the premise that even a selfish host will have a set of social relationships, and hence, will not display the same behavior towards all the other hosts. The authors surmise that since the selfish host will also need to send messages using other hosts at times, it is in the selfish host’s interest not to ask for monetary payment from hosts in its work group/community. They also implemented a simulation where each host records encounters with other hosts. Whenever a selfish host receives a message from another host, it refers to these records and calculates the percentage of meeting days, and the standard deviation of the daily meetings. Based on this, the selfish hosts display an altruistic behavior towards hosts they meet often, and the authors show that these hosts are better off than the hosts who are always selfish.

Other methods include enforcement schemes employed in peer-to-peer file sharing systems to control free riding [72].

4.2.2. Presentation and usability issues

Although there is lack of focus in this issue in mobile cloud computing research, presentation in the user interface does pose a valid challenge. This has been frequently discussed in mobile computing research [73], [74], [75] and [76], and lessons can be drawn from these to apply for mobile clouds as well.

User interface issues in mobile computing. Mobile devices span a large number of heterogeneous platforms. To design and develop separate user interfaces (UIs) for each and every type of device would be highly inconvenient and unrealistic for the UI developers  [74].

Since the display area of a mobile device is small, which information and the way to present it to the user is a problem. Applications designed for mobiles may interact differently with users from normal desktops, for example, less data entry, and using popup menus to conserve the meager screen space [75].

Furthermore, user interaction methods with the application may depend on the user’s context such as location, bandwidth and remaining energy [76].

In addition, users of mobile cloud computing frameworks would also need some user level controls in the interface specific mobile clouds. For example, users may need to specify constraints, select from available surrogates, define their priorities, and deal with cost negotiation.

4.3. Service and application level issues

Service and application level issues relate to the factors concerned with performance measurements of the system, and the QoS of the system. For example, in what ways do mobile cloud computing systems ensure availability? What are the fault-tolerance (FT) mechanisms employed to ensure smooth execution and uninterrupted service? Cloud APIs providing libraries to support cloud application development for mobiles are also discussed.