Mobile Devices and Context Awareness

Mobile devices are the perfect enabler for truly context aware computing. As a result of their portability, which allows them to be carried while on the move, they are also the perfect ubiquitous device. Compared to their desktop coun-terparts, mobile devices feature a wide variety of sensors and other equipment that the device, and any applications running on it, can use to make informed decisions about their operation for the user, without any personal interven-tion. This can easily be seen by anyone who visits the Apple App Store, or the Google Play stores, from their mobile devices today. By far the most com-mon sensor on a mobile device is a GPS, which allows the device to detect the physical coordinates of the device location, using triangulation with satellites.

For example, travel applications use this information to pinpoint the user’s location on a map, and to show places of interest in the user vicinity. Other on-board devices include an accelerometer, which can detect physical user ac-tivity (walking, running, sitting, etc.), a light sensor to detect brightness, and even temperature reading sensors. Desktop computers, typically do not fea-ture any of these kinds of devices, and are not context-aware to the extent that mobile devices can be.

Research has harvested this information for mobile users to provide relevant computing services on their devices. For this purpose, there are several specific questions concerning collection and use of context for mobile devices:

• How is context data collected?

• How is context data stored?

• How is user context represented?

• How can context data be used?

The research literature for context awareness with mobile devices, explores these questions with varying different approaches. Going forward, it is impor-tant to define Context Producers, and Context Consumers. Context Producers are a source of context data, which can be a sensor on the mobile device, or even information provided directly by the user. A Context Consumer is an applica-tion or service that will consume context data for some specified objective.

One of the earliest works in regards to context awareness on mobile devices is that by Hofer et al [51]. This work developed the Hydrogen approach for context-awareness on mobile devices. This is a three-tier framework for

cap-turing, storing, and providing contexts to consumers, from a mobile device.

The aim of the architecture is to separate the operations involved with lecting context data (the producers), from the application who require the col-lected context data (the consumers). The framework collects a pre-specified set of context data, such as network information, and date/time information, by means of adapters. This is provided to an upper management layer, which runs a Context Server. From the server, the context data can be shared with other applications. It appears that the context data collected, is not persis-tently stored. Context that is collected is represented as objects using an Object Oriented approach. As a result, the context consumers, in advance, need to know exactly what kinds of context are collected by the framework. In terms of mobile cloud computing, an important observation, is that all of this work is carried out locally on the mobile device. This can be troublesome, as sensing and collecting context data repeatedly results in an undesirable power draw from the device battery, impacting negatively on the user experience.

In work by Lowe et al [85] a Context Directory was developed, which is a directory that stores context as key-value pairs. They key-value pairs approach does restrict the complexity of context data collected, and also implies that a consumer must know a context type by name when requesting it, similar to the hydrogen approach. Contrasting with the Hydrogen approach, this work uses a server for processing and representing the directory itself, rather than storing this data locally on the mobile device. This work does not discuss how context reaches the context directory (and also points out, that there could be several distributed directories).

This Context Directory project introduces two important concepts. One of these is what is known as Feature Extraction, also known as Context Interpre-tation. Feature Extraction is the means by which meaningful information can be extracted from the raw context data, and understood. This is a complex subject; the work by Lowe cites several feature extraction algorithms, how-ever, for their implementation, an unspecified rules-based approach is used.

The important point to be made is that it is recognised that operations like feature extraction, can be computationally expensive, and long running. As such, these operations are considered costly for a mobile device to perform, hence the desire to offload these operations to a server, such as a cloud-based approach. The Hydrogen approach, does not perform any feature extraction, and overall, may not have been viewed as a framework that was costly to run on a mobile device.

Figure 2.6: Context Awareness with Mobile Cloud Applications. A middle-ware running on the mobile device collects user context from several sources.

This is then forwarded to a cloud-based middleware which consumes this con-text, and then, in turn, passes it on to various cloud based services. This can be used to personalise the service execution and/or results to the user’s own situation or preferences.

For the mobile device, the other important consideration is storage. For the Context Directory, running on a server, context data can be persistently stored.

This results in context data taking the form of a Context History. The usefulness of this for the mobile cloud work in this thesis will be discussed further in the next subsection. What is important to highlight is that constant collection of context data, along with persistently storing it, requires significant power and storage space, which is also undesirable for a mobile device.

In work by Raento et al [108], what was titled a "ContextPhone" was devel-oped; a awareness framework that allows development of context-aware applications. This work focuses on gathering context from a pre-selected set of device sensors. This data can then be shared with applications built on top of the framework. In addition, this work places a heavy focus on context data sharing via network connectivity (i.e. Bluetooth, GPRS, SMS Mes-saging, which are all supported). For example, one application, ContextCon-tacts, can share the context of a user with others who have that user in their contacts. Two use-cases are presented for this; one is the capability for a user to see the phone noise and vibrate settings of a contact. If the ringer is turned off, and vibrate is on, one could assume that the contact is in a meeting, and

should not be disturbed. The second is location information, where you can see where that user is, should you wish to meet with that user. The authors do not consider privacy options of openly sharing this data, but stated this was something they were interested in exploring. The capability for context shar-ing is shared with the Hydrogen approach, where the authors implemented a contact business card information sharing application. In terms of the ques-tions identified for this review, data storage, representation, and usage outside the framework, are not discussed.

In work by Oriana Riva [112], the Contory (ContextFactory) was developed, with a focus on retrieving context from various distributed services, and is one of the most complete works in the literature on mobile context. This ap-proach was taken based on the fact that not all devices may have the same sensors, and so required data may not be available locally. Three different strategies are used to collect data; internal sensors, centralised external sen-sors, or ad-hoc external sensen-sors, over Bluetooth and WLAN connections. The Contory framework is deployed in the device; it can publish context gathered from internal sensors to other devices (in either push or polling fashion), and it can retrieve requested context from other devices using the external sensor strategies. Context data is stored in a local repository, in an unspecified for-mat. An SQL-like query language was also developed to allow a developer to query context information through the Contory API. Like with the Hydrogen approach, all the work is centralised on the mobile device. Details regarding the implementation of the externalised central server implementation are not given. Contexts are stored as types of Context Items, and can be stored locally on the device, or on a remote server. One concern may be the willingness for other mobile devices to share their context data, from a privacy perspective, but in the implementation, a mobile device running Contory can tag itself as being willing to share certain types of context with others.

The Mobicon (Mobile Context Monitoring) platform was developed by Lee et al [74]. Rather than a framework for context awareness, it focuses on context monitoring. The objective behind the platform was to be able to collect the context data from many sensors and devices in the vicinity of the user, such as those found in personal area networks. Despite the fact that the platform runs locally on mobile devices (it does not make use of clouds or servers for operations such as feature extraction), the work employs many techniques for optimisation to reduce the energy cost of gathering and disseminating context data to consumers. This includes aggregating the context processing

opera-tions in a pipeline together for multiple requests (the Contory framework also performs a similar aggregation to save energy while processing multiple con-text requests), resource optimisation so that an overview of the system resource usage is maintained to meet objectives (such as not to exceed a certain energy usage), and a method to reduce the number of sensors required to determine a context status to a minimal set, which is called the essential sensor set (ESS).

Also similar to Contory, a language called CMQ (Context Monitoring Query) is defined to allow a developer to specify what context situations an application should be alerted to. The platform has been provided to multiple developers to build applications upon it. However, the work does not describe how all the sensors are discovered by the platform. The work also does not describe how context is stored or represented, but it does list a pre-determined list of contexts available.

In the next subsection, techniques for context representation and storage are briefly examined.