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.