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.