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.
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.
