Environmental Context Detection for Context-Aware Systems

Download as PDF

Abstract - In recent years, research activities in the area of context aware systems have increased. The mobile communications industry and network operators are interested in systems which account for user pref- erences to offer tailored services.For these demands, a system must be able to capture context information about the user and its environment. Sensors in the environment as well as in the mobile devices are required to provide context information to the system. This article introduces a Context Distribution Architecture and describes all associated components and interfaces. An important feature of this concept is the ability to integrate any kind of sensor irrespective of type, manufacturer, accuracy, etc. Further, sensors can easily be attached and removed from the running system without any additional administrative work. All necessary registration is automatically handled by the system.
Therefore, a Context Broker (CB) is introduced which is responsible for registering all Context Providers (CPs), requesting context data and providing this to the requesting Context Consumer (CC). An important task of the Context Broker is the selection of an appropriate Context Provider (depending on context requirements). Each Context Provider (CP) includes one ore more sensors.

Key words: Context Aware System, Context Provider, Context Broker, Context Consumer, Context Quality Enabler, Context Distribution, Context History, Context Cache, Context-Awareness Function, Wireless Sensor Network, Mobile Terminal Sensors, Data Plane, Control Plane, Sensor

1 Introduction

The importance of context-aware systems has recently increased and become a widely discussed research topic. Chen [1] considers context as a collection of information that characterizes a person or a computing entity. For example, context can be seen as a location and its environmental attributes (e.g., tem- perature, illumination, available networks). This also includes people, physical objects, and computing entities that are in this location.
Today, context information is made available for a broad variety of applications,

2    Context Detection
for instance context-aware services for mobile terminals or for intelligent radio network and access management [2],[3],[4],[5]. Context data is gathered by Wireless Sensor Networks (WSN), Mobile Terminal Sensors (MTS) or retrieved from databases and web services. A reasoning mechanism abstracts the data to higher-level context information and provides this information to a Context Broker (CB). The CB is a functional component which takes care that context data is provided to requesting Context Consumers (CCs). This context data can be used for different services. Examples are location-based services or providing users information about products depending on their preferences which are stored in a database. The aim of this architecture is to integrate different kind of sensors, independent of manufacturer and sensor type. All sensors can be attached to the system and are registered automatically to the context broker via a ”plug and play” functionality.
The growing need for mobile information increases the demand for such Context Aware Systems. They shall provide the user the desired information ”as fast as possible”, ”as topical as possible” and ”as accurate as possible”. In some cases it might be necessary to ensure a ”real time” delivery of context information. An additional requirement is that the CB has to decide whether the context from a Context Provider (CP) is applicable with regards to the quality of the context. For this requirement, the CB includes a Context Quality Enabler (CQE). All available CPs are registered at the CB with the information about their capabilities (e.g. available context data, measuring range, accuracy). With this information, the CQE assigns an appropriate CP to the requesting CC.
The article is organized as follows. Section 2 gives an overview about the state of the art and the related work. Section 3 shows the system architecture for context detection and Section 4 presents the context distribution architecture. A conclusion is given in Section 5.

2 State of the Art and Related Work

Context-aware systems should facilitate the adaptation of the behavior of a mobile service to the environment and user preferences. To achieve this, the environment and the mobile devices must be equipped with sensors that can detect the according context information. The idea of the proposed architecture is to use available sensors and not to develop new sensors. Typically, environmental context information is acquired via sensors e.g. for temperature, illumination, noise, acceleration, smoke, fire or gas.

2.1 Context Detection
Today, many companies and research groups work on projects for such context- aware systems. But most of the currently available systems are not standardized. An example for such a system is discussed by the Mobile Codes Consortium [6]. In this project cameras, which are available in most mobile phones are used to read barcodes. Another proprietary approach is the NOKIA Remote Sensing Platform (NORS) project [7]. It developed an event driven system which utilizes stationary multi-sensor modules to optimize sensor data transmission. However, the disadvantage of all of these systems are their specialized hardware platforms and the heterogeneous interfaces.

2.2 Context Delivery
To distribute context information, a context management system is needed. This system is responsible for acquiring, processing, managing, and distributing context information with respect to the specific needs of applications and services. Chen [1] presents three different ways to gather and deliver context data:

1. Direct access to sensors - The sensors are deployed on the network termi- nals and can collect environmental context (e.g. temperature, illumination, acceleration).
2. Facilitated by a middleware infrastructure. With the introduction of middleware it is possible to separate sensor control and data acquisition. The management of low level sensing is done by the middleware and the application can focus on how to use the context. This also improves system extensibility and reusability.
3. Acquire context from a context server. The idea is to shift context acquisition procedures into the implementation of a server entity. This entity consists of a resource-rich device. Hence applications without build-in sensing capability acquire context and become context-aware.

The concept of a Context Broker for distributing information is not entirely new. It has for instance been studied in the IST-FP6 project MobiLife [8]. Fig- ure 1 shows the Context Management Framework which is split in to relevant functions.

SPICE (Service Platform for Innovative Communication Environment) [9] is another European project which also works on a platform for utilizing context information from heterogeneous context sources (e.g. physical sensors, WWW/Internet, system data, etc.).
Fahy [10] proposed a Context-awareness sub-structure (CASS) which is a serverbased middleware to support context aware application on small mobile computers like hand-helds. An important feature of the CASS system is the support for high level context data abstraction. CASS is also able to separate context-based inferences and behaviors from application code. With this separation, the context-aware application can be configured by the user.

3 System Architecture for Context Detection

Today, a variety of different sensors and sensor networks from various manufacturers are available on the market. The proposed concept for a context detection architecture is shown in Figure 2.

The architecture is divided into the following domains:

1. Wireless Sensor Networks - The sensors of a WSN are stationary mounted in the environment (e.g. in buildings, trains) to measure context information such as temperature, humidity or illumination. Each sensor has a known position. In addition to these sensors, RFID readers are installed in the environment to complement the GPS-based positioning technology of mobile devices. If a mobile device is not equipped with a RFID tag, Bluetooth or ZigBee tech- nology can also be used to determine the proximity to the base station. In this case, the base station or the mobile device, respectively, only needs to check if an according signal is available. The distance to the respective base station can be estimated using the received signal strength indicator (RSSI). Each wireless sensor network acts together with its gateway as a Context Provider.
2. Mobile Devices - Mobile devices are also equipped with sensors like temperature, illumination and acceleration sensors. Additionally to these sensors, GPS, Bluetooth or ZigBee, and a RFID tag or RFID reader is available. These technologies are used to determine the position as mentioned in the preceding paragraph.
   Each mobile device acts as a Context Provider and Context Consumer, respectively. As a Context Provider, the device itself delivers the context data of its internal sensors to the CB. By contrast, if the device acts as a Context Consumer, the device requests context data from the CB. The requested context data will be used by an application running on the mobile device, making it context-aware.

3.1 Context Detection by Sensors

The component for context detection can be divided in the submodules ”Sensor Data Plane” and ”Sensor Control Plane”.  A generic model of the ”Context Detection by Sensor” module is shown in Figure 3.
In the ”Sensor Data Plane”, raw sensor data is processed and low level reasoning is performed. For this, the ”Sensor Data Plane” includes the following functionalities:

• Filtering: select the requested context information
• Fusion: derive stable measurement values, e.g., by averaging
• Aggregation: combine heterogeneous context information to derive new, higher level context, e.g. location + temperature + humidity = weather
• Low level reasoning: use logical rules to derive conclusions about user situation from fusioned and aggregated sensor data and network context

The ”Sensor Control Plane” is responsible for managing sensor activity with respect to terminal needs e.g. in terms of power consumption. It is also accountable for telling the ”Sensor Signal processing” unit to represent the requested sensor data in a valid context information format.
Furthermore, the ”Sensor Control” unit has to register with the CB. This process will be explained in section 4.

3.2 Context Delivery

The context delivery is a functional submodule of a CP and controls all context detection units of the CP. Each context detection unit is responsible for delivering one context value (for example temperature or humidity). The context delivery combines these values to the requested context information. Figure 4 shows a generic CP model.
The Context Delivery module is also responsible for processing status infor- mation of the sensors, controlling sensing activities, processing of requests from the Context Broker and reporting of context information to the CB. All CPs include a ”Context Delivery” module. It is a key component because it collects the data from different sensors, generates context information by filter- ing, fusion, aggregation and low level reasoning. The execution of this processes is performed in the ”Sensor Data Plane” but controlled by the ”Context Delivery” module.
Additionally, the ”Context Delivery” module is in charge of for announcing a CP to the CB. In this announcement, the CP reports its capabilities (list of available sensors, their accuracies, provision mode) and attendance times (times when the CP is available) to the CB.
Along with context data, the ”Context Delivery” generates context metadata. This data includes additional information about the context data such as accuracy and period of validity. Moreover status information about the CP itself is provided to the CB. A periodic request from the CB to each registered CP ensures that the registry maintained by the CB is always up-to-date. If a CP does not answer the request after a specified time, the CB removes it from the list. On the other hand, if a CP does not receive periodic check-requests from a CB, the CP must send a new announcement. This process ensures the ”plug and play” capability of the system. If a new CP is attached to the system, the announcement starts automatically and the CP is added to the registry of the CB.

4 Context Distribution Architecture

In the following subsections we describe the different components of the proposed Context Distribution Architecture. Figure 5 illustrates a generic structure of this architecture. Additionally, we explain how context data is exchanged between the different entities.

4.1 Context Provider

A Context Provider (CP) is an entity which supplies the system with context data. Context data is gathered by a set of heterogeneous sensors (e.g. temper- ature, illumination, available networks, position). The process of context data generation consists of filtering, fusion, aggregation and low level reasoning. After the aggregation process, the context data is delivered in a standardized XML format (e.g. ContextML).
For each request, the Context Delivery module generates a corresponding XML document which includes the respective values (e.g. temperature, humidity, ...) as well as additional meta information. This document is subsequently delivered to the requesting entity (CC or CB).

4.2 Context Consumer

The Context Consumer (CC) is an entity which requests and receives context information. Depending on the respective needs, CCs can request context information from the CB or retrieve the URI of an appropriate CP from the broker. In the second case, CCs directly request context data from a CP.
Typically, a CC is a mobile end user device with an application that uses context data. However, the architecture is not limited to this and also e.g. web services are thinkable as CC.

4.3 Context Broker

The Context Broker (CB) plays a significant role in the Context Distribution Architecture. It contains a registry of all Context Providers and their capabilities. All available CPs and their features are stored in the CP Registry database. The according information is send from the CP to the CB using an announcement. Based on this registry, a CB can provide a look-up service to search for entities that can provide certain context data. Two different kinds of context provision are available. In the first case, the CB receives the context data from a CP and provides the data by forwarding it to the CC. In the second case, the CB commits the address of a CP with the corresponding context information to the CC. The context information is directly exchanged between the corresponding CP and CC. The requesting entities can communicate in an asynchronous mode, i.e. context forwarding is event-driven (”publish/subscribe mode”), or in a synchronous mode, i.e. the request is instantly answered by the CB (”request/provide mode”). To accelerate the request process, the CB itself maintains a Context Cache to store context which has not expired yet. The expired context is moved from the Context Cache to a Context History database. This expired data can also be requested by a CC.

4.4 Context Quality Enabler

The Context Quality Enabler (CQE) supports the CB in finding a suitable CP for the requested context. All available CPs are listed in the CP Registry with their capabilities and accuracies. With this knowledge and the knowledge of the requested accuracy and/or other requirements (e.g. values for a confined area), the CQE selects a suitable CP. If no CPs fulfilling the requirements are available, the CQE selects the CP with the best available accuracy. This CP is also used in the default mode, i.e. if no requirements are defined.

4.5 Context Exchange

Two ways for context data provision are available. In the first one (indirect), the CC asks the CB for context data (e.g. temperature and humidity in a specific location) and the CB requests this context data from an appropriate CP. Subsequently, the CB delivers the context data to the requesting CC. All non-expired context data is stored in a Context Cache. This cache accelerates similar requests, because the CB does not need to ask for that context data again. Expired data is moved to a Context History database which can be used for statistical analysis (e.g. user behavior, situation identification). The control unit of the CB is responsible for moving all the expired data from the Context Cache to the Context History. All CCs have access to this Context History database.
In the second case (direct), the CC only requests the address (URI) of an ap- plicable CP from the CB to retrieve the respective context data. Thus the CB does not receive the context data itself, it is directly exchanged between the CP and CC. For data, which is needed immediately, this way is the better choice, since the context data does not need to pass the CB.
The provision of context can be carried out, as mentioned in section 4.3, in an asynchronous or a synchronous mode. Each provisioning of context data is initiated by a CC and includes information about the communication mode, i.e. asynchronous or synchronous mode, and request type, i.e. direct or indirect request.

5 Conclusion

This article presented a generic architecture for context detection, distribution and exchange using standardized interfaces. All essential components and con- text exchange mechanisms were described. An important feature of the proposed architecture is the capability to integrate various kinds of sensors. This ensures a scalable and extensible system architecture. Furthermore, the ”plug and play” feature allows for adding or removing CPs in a running system. All necessary administration of CCs and CPs is automatically handled by the CB. This results in a self-controlling architecture without any additional administrative work when adding or removing entities.
Acknowledgements. This work has been partially supported by the Collaborative Project Context Casting (C-CAST - Provide an End-to-End Context- Aware Communication Framework), which is funded by the European Commission under the Seventh Framework Programme. However, this article expresses the authors’ personal views, which are not necessarily those of the C-CAST consortium.

References

1. Chen,H.:AnIntelligentBrokerArchitectureforPervasiveContext-AwareSystems. University of Maryland, College Park, MD (2004)
2. Klein, A., Mannweiler, C., Schneider, J., Schotten, H.: A Framework for Intelligent Radio Network Access Based on Context Models. Proceedings of 22nd WWRF Meeting, Paris (2009)
3. Janneteau, C., Simoes, J., Antoniou, J., Christophorou, C., Kellil, M., Klein, A., Neto, A., Pinto, F.C., Roux, P. Sargento, S., Schotten, H.D., Schneider, J.: Context- aware Multiparty Networking. Conference Proceedings of ICT MobileSummit, San- tander (2009)
4. Mannweiler, C., Klein, A., Schneider, J., Schotten, H.: Exploiting User and Net- work Context for Intelligent Radio Network Access. Proceedings of International Conference on Ultra Modern Technologies, St. Petersburg, Russia (2009)
5. Mannweiler, C., Klein, A., Schneider, J., Schotten, H.: Context-Awareness for Het- erogeneous Access Management. In Advances in Radio Science (ARS) - Klein- heubacher Berichte (2009)
6. Mobile Codes Consortium - MC2, http://www.mobilecodes.org
7. NOKIA    Remote    Sensing    Platform    (NORS)    project, http://opensource.nokia.com/projects/nors/index.html
8. Floren, P., Przybilski, M., Nurmi, P., Koolwaaij, J., Tarlano, A., Wagner, M., Luther, M., Bataille, F., Boussard, M., Mrohs, B., Lau, S.: Towards a Context Management Framework for MobiLife. 14th IST Mobile and Communications Summit, Dresden (2005)
9. Zhdanova, A.V., Zoric, J., Marengo, M., Van Kranenburg, H., Snoeck, N., Sutterer, M., Ra ̈ck, C., Droegehorn, O., Arbanowski, S.: Context Acquisition, Representa- tion and Employment in Mobile Service Platforms. 15th IST Mobile and Wireless Communications Summit, Myconos (2006)
10. Fahy, P., Clarke, S.: CASS - a middleware for a mobile context-aware application. In Workshop Context Awareness, MobiSys 2004 (2004)
11. Context Casting C-CAST, http://www.ICT-CCAST.eu