Context Awareness

Context awareness is one of the vital issues of MCC. MCC is all about mobility, heteroge- neous environment, and technology, so, it is very important for a system to be very aware of its context or surroundings. The system should be able to reconfigure or change itself according to the change in its environment.

3.6.5.1 Context-Aware Service Provisioning

Mobile cloud provides services based on the context of a user. It can sense various attri- butes such as location, acceleration, and so on, of a mobile user. Based on this context information, cloud provides the most suitable service to the user. There are four layers of the context element [33]:

1. Monitored context: Referring to the current monitored context of a device, moni- tored context includes environmental and device settings, user-specific preference settings, service context information like QoS, and so on.

User information Location- trusted server Location- based services Cloaked information Query result Mobile device FIGURE 3.9 Cloaking architecture.

2. Types of gaps: When a user changes his or her service from the current service to a new one, there may be a gap between contexts of the two services. The gap may be functional or nonfunctional.

3. Types of causes: There may be gaps between different interfaces and different implementations of a single service. These gaps occur as a result of the mismatch of the service level, service interface level, service component level, and compo- nent instance level.

4. Adapters: Adapters are needed to remove all the previously mentioned causes. Based on these factors, context-aware service provisioning has been built with three tiers. The user tier consists of mobile devices where the application runs, the agent tier adapts the services according to the context, and the service tier deploys the services.

In intelligent access [34], context information is provided by terminals, sensor nodes deployed with the users’ environment, network nodes, and so on. Dynamic context infor- mation, such as user profile, terminal status, and sensor information, is provided to the mobile cloud. Context management architecture (CMA) is responsible for acquiring, pro- cessing, managing, and delivering context information. Context quality enabler (CQE) controls the supply of context information to the mobile cloud. CMA has the following three components, as shown in Figure 3.10.

1. Context provider: The context provider generates the context information. Then it is supplied to other components of the CMA. According to the context request, com- munication between the context provider and other components is established. Static data such as terminal capabilities, user preferences, or user information, and dynamic data such as user location and movement (i.e., speed and direction) and network conditions, and so on, are provided by the context provider.

2. Context broker: Context broker acts as a middleman between the context provider and the context consumer. There is a registry containing the information about the context provider’s availability and capabilities. It provides a look-up service for the context provider and also forwards the data received from it. There are two

Context consumer Context provider Context broker Context cache Context- quality enabler Context history FIGURE 3.10 CMA architecture.

kinds of communication mode: asynchronous and synchronous. In the asynchro- nous mode, context information is forwarded if a specific condition becomes true. In synchronous mode, context information is answered instantly by the context broker. It maintains a context cache to store context that has not expired yet, and a context history to store expired context.

3. Context consumer: These are the entities that take context data as inputs for their actual functionality, for example, network services, applications for end-users, and service enablers.

3.6.5.2 Risk Assessment Using Context Awareness

MobiCloud [19] uses context information to facilitate risk assessment and routing decisions by virtual trusted and provisioning domain (VTaPD). It can isolate different information flows in different domains via programmable router technologies by creating separate flows and different domains. Thus, a user can run different applications in different secure domains based on the context. Various pieces of context information such as device sens- ing value, location, neighboring device status, and so on, are recorded at VTaPD and used for risk management and intrusion detection.

3.6.5.3 Resource and Common Goal Identification Using Context Awareness

The context manager can sense and store context information, which can be used by other components. Using the information context, the application manager can launch, intercept, and modify the current applications. The location and the number of devices in a vicin- ity are considered the main context information. Location context is used for tracing the mobility of the user, and a number of devices are used for forming the mobile cloud, so, the system is aware of when a new node enters or leaves the system and also can identify which node is stable. These are essential to deciding whether the new node is following a common movement pattern with other devices, leading to common activities.

3.6.5.4 Energy Awareness

Because of limited battery life in a mobile device, energy awareness has become one of the vital issues of MCC. Mobile devices have a finite power source, and running many applica- tions constantly causes a large amount of battery drain. So, energy profiling and energy usage estimation of the device are very important. In MCC, the power consumption must be less than the benefit gained. Unnecessary software components should be unloaded, and the energy-intensive components should be redeployed to the more resourceful host.

PowerScope [35], which maps the power usage to a specific code component in the appli- cation and operating systems, is an energy profiling tool for mobile application. It allows the analysis of the power draining process, which helps the software developer to build energy-efficient software. An experiment was done by some laptops, minicomputers, and digital multimeters, and the result showed that 46% energy saving was possible in adap- tive video streaming by using PowerScope.

PowerSpy [36] is a software approach for the energy profiling of mobile devices in the Windows platform. It has two stages: tracking and analysis. When an application is run- ning, it tracks several factors such as the CPU time, energy consumption, and I/O activity. In the analysis stage, it filters the result by I/O activity. It estimates a certain energy con- sumption for an I/O operation specified by the manufacturer, which is then compared

with the recorded energy consumption. The difference is noted as the energy taken up by CPU threads. Next, energy consumption is drilled down to the individual threads, on the assumption that CPU power usage is proportional to the number of CPU cycles spent on a thread.

Energy usage estimation is just opposite of energy profiling. It is the prior estimation of an application not during runtime but at the construction time. This estimation is done based on some context parameters such as the size of data exchanged over the network, inputs to the components’ interfaces, invocation frequency of components’ interfaces, and so on. The equation for energy cost estimation is as follows [37]:

System energy cost = Computational energy cost + Communicational energy + Overall infrastructure energy cost

where (computational energy cost + communicational energy) refers to the overall energy cost.