See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/215697414

A Survey on context-aware systems

Article  in  International Journal of Ad Hoc and Ubiquitous Computing · January 2007

DOI: 10.1504/IJAHUC.2007.014070

CITATIONS READS

1,709 2,212

3 authors, including:

Schahram Dustdar Florian Rosenberg

TU Wien Braintribe
806 PUBLICATIONS   20,055 CITATIONS    65 PUBLICATIONS   3,952 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

CPPS-DC: Doctoral College on Cyber-Physical Production Systems View project

VieCAR - Enabling Self-adaptive Collaboration Services View project

All content following this page was uploaded by Matthias Baldauf on 04 June 2014.

The user has requested enhancement of the downloaded file.

Int. J. Ad Hoc and Ubiquitous Computing, Vol. 2, No. 4, 2007 263

A survey on context-aware systems

Matthias Baldauf
V-Research, Industrial Research and Development,
Stadtstrasse 33, 6850 Dornbirn, Austria
E-mail: [email protected]

Schahram Dustdar* and Florian Rosenberg

Distributed Systems Group, Information Systems Institute,
Vienna University of Technology, Argentinierstrasse 8/184-1, 1040 Vienna, Austria
E-mail: [email protected] E-mail: [email protected]
*Corresponding author

Abstract: Context-aware systems offer entirely new opportunities for application developers and
for end users by gathering context data and adapting systems behaviour accordingly. Especially
in combination with mobile devices these mechanisms are of high value and are used to
increase usability tremendously. In this paper, we present common architecture principles of
context-aware systems and derive a layered conceptual design framework to explain the different
elements common to most context-aware architectures. Based on these design principles, we
introduce various existing context-aware systems focusing on context-aware middleware and
frameworks, which ease the development of context-aware applications. We discuss various
approaches and analyse important aspects in context-aware computing on the basis of the
presented systems.

Keywords: context-awareness; context framework; context middleware; sensors; context model;

context ontology; context-aware services.

Reference to this paper should be made as follows: Baldauf, M., Dustdar, S. and Rosenberg, F.
(2007) ‘A survey on context-aware systems’, Int. J. Ad Hoc and Ubiquitous Computing, Vol. 2,
No. 4, pp.263–277.

Biographical notes: Matthias Baldauf is project manager at V-Research, an Austrian

competence center for industrial research and development. In the Department of Technical
Logistics he develops location-aware systems based on GPS, GSM and RFID technology with a
focus on track and trace solutions. His research interests include modern localisation methods and
efficient, flexible localisation architectures.

Schahram Dustdar is a Full Professor of Computer Science with a focus on Internet Technologies
at the Distributed Systems Group, Information Systems Institute, Vienna University of
Technology (TU Wien). In 1999 he co-founded Caramba Labs Software AG (CarambaLabs.com)
in Vienna, a venture capital co-funded software company focused on software for collaborative
processes in teams. Caramba Labs was nominated for several (international and national) awards.
He has published some 100 scientific papers as conference-, journal-, and book contributions.
He has written three academic books, one professional book, and co-edited six
books/proceedings. More information can be found at: http://www.infosys.tuwien.ac.at/Staff/sd.

Florian Rosenberg is research assistant and PhD student at the Distributed Systems Group,
Information Systems Institute, Vienna University of Technology. His research areas include
context-aware and autonomic services, service-oriented architectures and web service
technologies. More information can be found at: http://www.infosys.tuwien.ac.at/Staff/rosenberg.

1 Introduction background to make the user and his tasks the central focus
rather than computing devices and technical issues.
With the appearance and penetration of mobile devices such
One field in the wide range of pervasive computing are
as notebooks, PDAs, and smart phones, pervasive
the so-called context-aware (or sentient) systems.
(or ubiquitous) systems are becoming increasingly popular
Context-aware systems are able to adapt their operations to
these days. The term ‘pervasive’ introduced first by Weiser
the current context without explicit user intervention and
(1991) refers to the seamless integration of devices into
thus aim at increasing usability and effectiveness by taking
the users everyday life. Appliances should vanish into the
environmental context into account. Particularly when it

Copyright © 2007 Inderscience Enterprises Ltd.

264 M. Baldauf, S. Dustdar and F. Rosenberg

comes to using mobile devices, it is desirable that programs captured by monitoring user interactions, i.e., the user’s
and services react specifically to their current location, time goals, tasks, work context, business processes, the user’s
and other environment attributes and adapt their behaviour emotional state. Most context-aware systems make use of
according to the changing circumstances as context data external context factors as they provide useful data, such as
may change rapidly. The needed context information may location information. Furthermore, external attributes are
be retrieved in a variety of ways, such as applying sensors, easy to sense by using off-the-shelf sensing technologies.
network information, device status, browsing user profiles Virtually all systems presented in this paper apply physical
and using other sources. The history of context-aware context information. Examples for the use of logical
systems started when Want et al. (1992) introduced data are the Watson Project (Budzik and Hammond, 2000)
their Active Badge Location System which is considered to and the IntelliZap Project (Finkelstein et al., 2001) which
be one of the first context-aware applications. The infrared support the user by providing relevant information due to
technology based system is able to determine a user’s information read out of opened web pages, documents, etc.
current location which was used to forward phone calls to a When dealing with context, three entities can be
telephone close to the user. In the middle of the 1990s, distinguished (Dey and Abowd, 2001): places (rooms,
a couple of location-aware tour guides (Abowd et al., 1997; buildings etc.), people (individuals, groups) and things
Sumi et al., 1998; Cheverst et al., 2000) emerged which (physical objects, computer components etc.). Each of these
provided information according to the user’s current entities may be described by various attributes which can be
location. While location information is by far the most classified into four categories: identity (each entity has a
frequently used attribute of context, attempts to use other unique identifier), location (an entity’s position, co-location,
context information as well have grown over the last few proximity etc.), status (or activity, meaning the intrinsic
years as the examples in this paper will show. Hence, properties of an entity, e.g., temperature and lightning for a
it is a challenging task to define the word ‘context’ room, processes running currently on a device etc.) and time
and many researchers tried to find their own definition for (used for timestamps to accurately define situation, ordering
what context actually includes. In literature the term events etc.).
context-aware appeared in Schilit and Theimer (1994) the This paper is structured as follows. Section 2 introduces
first time. There the authors describe context as location, current design principles for context-aware systems and
identities of nearby people, objects and changes to those common context models used in various context-aware
objects. Such enumerations of context examples were often systems. In Section 3, we present a comparison of existent
used in the beginning of context-aware systems research. context-aware systems and explain approaches, varieties
Ryan et al. (1997) referred to context as the user’s location, and similarities. In Section 4, we discuss the presented
environment, identity and time. Dey (1998) defines context approaches, and highlight advantages and disadvantages.
as the user’s emotional state, focus of attention, location and Finally, Section 5 draws some concluding remarks and
orientation, date and time, as well as objects and people in presents some future work in this area.
the user’s environment. Another common way of defining
context was the use of synonyms. Hull et al. (1997) describe
context as the aspects of the current situation. These kind of 2 Design principles
definitions are often too wide. However, a good one can be In this section, we describe basic design principles and
found in Brown (1996). Brown defines context to be the introduce a conceptually layered framework, to associate the
elements of the user’s environment which the computer functionality implemented in existent frameworks to
knows about. One of the most accurate definitions is various layers. Furthermore, we depict different context
given by Dey and Abowd (2000b). These authors refer to models used for representing, storing and exchanging
context as contextual information.
“any information that can be used
to characterize the situation of entities
(i.e., whether a person, place or object)
2.1 Architecture
that are considered relevant to the interaction Context-aware systems can be implemented in many ways.
between a user and an application, including The approach depends on special requirements and
the user and the application themselves.”
conditions such as the location of sensors (local or remote),
One popular way to classify context instances is the the amount of possible users (one user or many), the
distinction of different context dimensions. Prekop and available resources of the used devices (high-end-PCs or
Burnett (2003) and Gustavsen (2002) call these dimensions small mobile devices) or the facility of a further extension
external and internal, and Hofer et al. (2002) refer to of the system. Furthermore, the method of context-data
xtitphysical and logical context. The external (physical) acquisition is very important when designing context-aware
dimension refers to context that can be measured by systems because it predefines the architectural style of the
hardware sensors, i.e., location, light, sound, movement, system at least to some extent. Chen (2004) presents three
touch, temperature or air pressure, whereas the internal different approaches on how to acquire contextual
(logical) dimension is mostly specified by the user or information.
 A survey on context-aware systems 265

• Direct sensor access. This approach is often used in • Networked services. This more flexible approach,
devices with sensors locally built in. The client argued for example in Hong and Landay (2001),
software gathers the desired information directly from resembles the context server architecture. Instead of a
these sensors, i.e., there is no additional layer for global widget manager discovery techniques are used to
gaining and processing sensor data. Drivers for the find networked services. This service based approach is
sensors are hardwired into the application, so this not as efficient as a widget architecture due to complex
tightly coupled method is usable only in rare cases. network based components but provides robustness.
Therefore, it is not suited for distributed systems due to
• Blackboard model. In contrast to the process-centric
its direct access nature which lacks a component
view of the widget and the service-oriented model, the
capable of managing multiple concurrent sensor
blackboard model represents a data-centric view. In this
accesses.
asymmetric approach processes post messages to a
• Middleware infrastructure. Modern software design shared media, the so-called blackboard, and subscribe
uses methods of encapsulation to separate e.g., business to it to be notified when some specified event occurs.
logic and graphical user interfaces. The middleware Advantages of this model are the simplicity of adding
based approach introduces a layered architecture to new context sources and the easy configuration. One
context-aware systems with the intention of hiding drawback is the need of a centralised server to host the
low-level sensing details. Compared to direct sensor blackboard and the lack in communication efficiency as
access this technique eases extensibility since the client two hops per communication are needed.
code has not be modified anymore and it simplifies the
In this paper we will focus on middleware based and
reusability of hardware dependent sensing code due to
context-server based systems with regards to their usability
the strict encapsulation.
in distributed systems. Many layered context-aware systems
• Context server. The next logical step is to permit and frameworks have evolved during the last years. Most of
multiple clients access to remote data sources. This them differ in functional range, location and naming of
distributed approach extends the middleware based layers, the use of optional agents or other architectural
architecture by introducing an access managing remote concerns. Besides these adaptations and modifications, a
component. Gathering sensor data is moved to this common architecture in modern context-aware applications
so-called context server to facilitate concurrent multiple is identifiable when analysing the various design
access. Besides the reuse of sensors, the usage of a approaches.
context server has the advantage of relieving clients of As mentioned above, a separation of detecting and
resource intensive operations. As probably the majority using context is necessary to improve extensibility and
of end devices used in context-aware systems are reusability of systems. The following layered conceptual
mobile gadgets with limitations in computation power, architecture, as depicted in Figure 1, augments layers for
disk space etc., this is an important aspect. In return one detecting and using context by adding interpreting and
has to consider about appropriate protocols, network reasoning functionality (Ailisto et al., 2002; Dey and
performance, quality of service parameters etc., when Abowd, 2001).
designing a context-aware system based on
client-server architecture. Figure 1 Layered conceptual framework for context-aware
systems
In a similar manner, Winograd (2001) describes three
different context management models for coordinating
multiple processes and components:
• Widgets. Derived from the homonymous GUI elements
a widget is a software component that provides a public
interface for a hardware sensor (Dey and Abowd,
2000a, 2001). Widgets hide low-level details of
sensing and ease application development due to their
reusability. Because of the encapsulation in widgets it is
possible to exchange widgets which provide the same
kind of context data (e.g., exchange a radio frequency The first layer consists of a collection of different sensors.
widget by a camera widget to collect location data). It is notable that the word ‘sensor’ not only refers to
Widgets are usually controlled by some kind of a sensing hardware but also to every data source which may
widget manager. The tightly coupled widget approach provide usable context information. Concerning the way
increases efficiency but is not robust to component data is captured; sensors can be classified in three groups
failures. (Indulska and Sutton, 2003).
266 M. Baldauf, S. Dustdar and F. Rosenberg

• Physical sensors. The most frequently used type of The Preprocessing layer is not implemented in every
sensors are physical sensors. Many hardware sensors context-aware system but may offer useful information if
are available nowadays which are capable of capturing the raw data are too coarse grained. The preprocessing layer
almost any physical data. Table 1 shows some is responsible for reasoning and interpreting contextual
examples of physical sensors (Schmidt and van information. The sensors queried in the underlying layer
Laerhoven, 2001). most often return technical data that are not appropriate
to use by application designers. Hence this layer raises
• Virtual sensors. Virtual sensors source context data
the results of layer two to a higher abstraction level.
from software applications or services. For example, it
The transformations include extraction and quantisation
is possible to determine an employee’s location not
operations. For example, the exact GPS position of a person
only by using tracking systems (physical sensors) but
might not be of value for an application but the name of the
also by a virtual sensor, e.g., by browsing an electronic
room the person is in, may be.
calendar, a travel-booking system, emails etc., for
In context-aware systems consisting of several different
location information. Other context attributes that can
context data sources, the single context atoms can be
be sensed by virtual sensors include, e.g., the user’s
combined to high-level information in this layer.
activity by checking for mouse-movement and
This process is also called ‘aggregation’ or ‘composition’.
keyboard input.
A single sensor value is often not important to an
• Logical sensors. These sensors make use of a couple of application, whereas combined information might be more
information sources, and combine physical and virtual precious and accurate. In this vein, a system is able to
sensors with additional information from databases or determine, e.g., whether a client is situated indoor or
various other sources in order to solve higher tasks. outdoor by analysing various physical data like temperature
For example, a logical sensor can be constructed to and light or whether a person is currently attending a
detect an employee’s current position by analysing meeting by capturing noise level and location. To make this
logins at desktop PCs and a database mapping of analysis work correctly a multitude of statistical methods
devices to location information. are involved and often some kind of training phase is
required.
Table 1 Commonly used physical sensor types Obviously, this abstraction functionality could also be
implemented directly by the application. But due to a couple
Type of
of reasons this task should better be encapsulated and
context Available sensors
moved to the context server. The encapsulation advances
Light Photodiodes, colour sensors, IR and UV- the reusability and, hence, eases the development of client
sensors etc.
applications. And by making such aggregators remotely
Visual Various cameras accessible the network performance increases (as clients
context
have to send only one request to gain high-level data instead
Audio Microphones of connecting to various sensors) and limited client
Motion, Mercury switches, angular sensors, resources are saved.
acceleration accelerometers, motion detectors, magnetic The problem of sensing conflicts that might occur when
fields
using several data sources has to be solved in this layer as
Location Outdoor: Global Positioning System (GPS), well. For example, when a system is notified about a
Global System for Mobile Communications
person’s location by the coordinates of her mobile phone
(GSM); Indoor: Active Badge system, etc.
and by a camera spotting this person, it might be difficult to
Touch Touch sensors implemented in mobile devices decide what information to use. Often this conflict is
Temperature Thermometers approached by using additional data like time stamps and
Physical Biosensors to measure skin resistance, blood resolution information.
attributes pressure The fourth layer, Storage and Management, organises
the gathered data and offers them via a public interface to
The second layer is responsible for the retrieval of raw the client. Clients may gain access in two different ways,
context data. It makes use of appropriate drivers for synchronous and asynchronous. In the synchronous manner
physical sensors and APIs for virtual and logical sensors. the client is polling the server for changes via remote
The query functionality is often implemented in reusable method calls. Therefore, it sends a message requesting some
software components which make low-level details of kind of offered data and pauses until it receives the server’s
hardware access transparent by providing more abstract answer. The asynchronous mode works via subscriptions.
methods such as getPosition(). By using interfaces for Each client subscribes to specific events it is interested in.
components responsible for equal types of context these On occurrence of one of these events, the client is either
components become exchangeable. Therefore, it is possible, simply notified or a client’s method is directly involved
for instance, to replace a RFID system by a GPS system using a call back. In the majority of cases the asynchronous
without any major modification in the current and upper approach is more suitable due to rapid changes in the
layers. underlying context. The polling technique is more resource
 A survey on context-aware systems 267

intensive as context data has to be requested quite often and • Object oriented models. Modelling context by using
the application has to prove for changes itself, using some object-oriented techniques offers to use the full power
kind of context history. of object orientation (e.g., encapsulation, reusability,
The client is realised in the fifth layer, the inheritance). Existing approaches use various objects to
Application layer. The actual reaction on different events represent different context types (such as temperature,
and context-instances is implemented here. Sometimes location, etc.), and encapsulate the details of context
information retrieval and application specific context processing and representation. Access the context and
management and reasoning is encapsulated in form of the context processing logic is provided by well-defined
agents, which communicate with the context server and act interfaces. Hydrogen (Hofer et al., 2002) uses such an
as an additional layer between the preprocessing and the object-oriented example. We explain the system in
application layer (Chen, 2004). An example for context more detail in Section 3.
logic at the client side is the display on mobile devices: as a
• Logic based models. Logic-based models have a high
light sensor detects bad illumination, text may be displayed
degree of formality. Typically, facts, expressions and
in higher colour contrast.
rules are used to define a context model. A logic based
All the systems, we analysed in this paper implement
system is then used to manage the aforementioned
most of the layers of the conceptual framework presented
terms and allows to add, update or remove new facts.
above.
The inference (also called reasoning) process can be
used to derive new facts based on existing rules in the
2.2 Context models systems. The contextual information needs to be
represented in a formal way as facts. One of the first
A context model is needed to define and store context data
approaches was published by McCarthy and Buvac
in a machine processable form. To develop flexible and
(1997).
useable context ontologies that cover the wide range
of possible contexts is a challenging task. Strang and • Ontology based models. Ontologies represent a
Linnhoff-Popien (2004) summarised the most relevant description of the concepts and relationships.
context modelling approaches, which are based on the data Therefore, ontologies are a very promising instrument
structures used for representing and exchanging contextual for modelling contextual information due to their high
information in the respective system. and formal expressiveness and the possibilities for
applying ontology reasoning techniques. Various
• Key-Value models. These models represent the simplest
context-aware frameworks use ontologies as underlying
data structure for context modelling. They are
context models. We describe some of them in
frequently used in various service frameworks, where
Section 3.
the key-value pairs are used to describe the capabilities
of a service. Service discovery is then applied by using The conclusion of the evaluation presented in Strang and
matching algorithms which use these key-value pairs. Linnhoff-Popien (2004), based on six requirements, show
that ontologies are the most expressive models and fulfil
• Markup scheme models. All markup based models use a
most of their requirements. Korpipää et al. (2003) present
hierarchical data structure consisting of markup tags
some requirements and goals having designed a context
with attributes and content. Profiles represent typical
ontology:
markup-scheme models. Typical examples for such
profiles are the Composite Capabilities/Preference • simplicity: the used expressions and relations should be
Profile (CC/PP) (W3C, 2004a) and User Agent Profile as simple as possible to simplify the work of
(UAProf) (Wapforum, 2001), which are encoded in applications developers
RDF/S. Various other examples can be found in Strang
• flexibility and extensibility: the ontology should support
and Linnhoff-Popien (2004).
the simple addition of new context elements and
• Graphical models. The Unified Modelling Language relations
(UML) is also suitable for modelling context. Various
• genericity: the ontology should not be limited to special
approaches exist where contextual aspects are modelled
kind of context atoms but rather support different types
in by using UML, e.g., Sheng and Benatallah (2005).
of context
Another modelling approach includes an extension to
the Object-Role Modelling (ORM) by context • expressiveness: the ontology should allow to describe
information presented in Hendricksen et al. (2003). as much context states as possible in arbitrary detail.
268 M. Baldauf, S. Dustdar and F. Rosenberg

Numerous tools are available to define declarative technical data. It simplifies the description of various
representations and to publish and share ontologies context atoms and context instances. Table 2 shows a
developed by the World Wide Web Consortium, e.g., the small part of an example vocabulary from Korpipää and
Resource Description Language (RDF) (W3C, 2000) and Mäntyjärvi (2003). Notice that not all contexts have to be
the Web Ontology Language (OWL) (W3C, 2004b). available at a time. In contrast to temperature, a light source
A single context atom can be described with a couple of is not always measurable.
attributes. The two most obvious are:
• Context type. The context type refers to the category of
3 Existent systems and frameworks
context such temperature, time, speed, etc. This type
information may be used as a parameter for a context In this section, we discuss three types of existing
query or a subscription, e.g., subscribeToChanges context-aware systems. Firstly, we briefly describe a special
(‘temperature’). It is important to use case of context-aware systems, the so-called location-aware
meaningful type names, hence, as the system grows, systems. Secondly, we describe an existing context-aware
some names might not be unique anymore. For example system assisting hospital information management. Thirdly,
the type position may belong to a mobile device or a we draw our main focus on context-aware frameworks, as
user. One solution for creating well-structured type basic building block for context-aware systems and
names is the use of cascaded names (Korpipää and applications.
Mäntyjärvi, 2003) as shown in Table 2.
• Context value. Context value means the raw data 3.1 Location-aware systems
gathered by a sensor. The unit depends on the context Context-aware systems dealing with location information
type and the applied sensor, e.g., degree Celsius, miles are widespread and the demand for them is growing due to
per hour, etc. the increasing spread of mobile devices. Examples for
In most cases, context type and context value are not location-aware systems are various tourist guide projects
enough information to build a working context-aware where information dependent to the current location is
system. Additional attributes that might be useful include: displayed. Other examples can be found in Espinoza et al.
(2001), Priyantha et al. (2000), Burrell and Gay (2002) and
• Time stamp. This attribute contains a date/time-value Kerer et al. (2004). A couple of different location aware
describing when the context was sensed. It is needed infrastructures are available in order to collect position data.
e.g., to create a context history and deal with sensing These include GPS satellites, mobile phone towers, badge
conflicts. proximity detectors, cameras, magnetic card readers,
• Source. A field containing information how the barcode readers, etc. These sensors can provide either
information was gathered. In case of a hardware sensor position or proximity information. In addition, they differ in
it might hold the ID of the sensor and allow an price and accuracy. Some need a clear line of sight, other
application to prefer data from this sensor. signals can travel through walls, etc. As a detailed example,
we introduce an indoor location sensing system from Harter
• Confidence. The confidence attribute describes the et al. (2002), who describes a location-aware system using
uncertainty of this context type. Not every data source ultrasonic technique. To each entity (person or equipment),
delivers accurate information, e.g., location data suffers which should be detectable, a small sending unit called bat
inaccuracy depending on the used tracking tool. is attached. These bats have globally unique identifiers and
contain ultrasonic transducers. To monitor the signals sent
Table 2 Example context vocabulary by the bats, receivers are installed at the rooms ceilings and
Context type Context connected by a wired network. The third hardware type
needed is a base station. It periodically sends radio
Environment:Temperature Cold
messages with specific bat ids and resets the receivers.
Environment:Temperature Normal A corresponding bat reacts by emitting an ultrasonic
Environment:Temperature Hot impulse which is caught by the receivers. By recording the
Environment:Light:Source 50 Hz time of arrival of signals the distance between the bat and
Environment:Light:Source 60 Hz the receiver can be calculated. The bat’s exact position is
Environment:Light:Source NotAvailable
then determined by using multilateration (an extension of
trilateration). A challenge the authors where confronted
Device:Activity:Placement AtHand
with due to the use of ultrasonic technique was the
Device:Activity:Placement NotAtHand incorrect measurement because of unwanted reflections of
the signals. The problem was solved by using a statistical
Part of a flexible context model is an extendable context outlier rejection algorithm to improve the accuracy of the
vocabulary to deal with abstract descriptions rather than calculated positions.
 A survey on context-aware systems 269

3.2 Context-aware systems Figure 2. Four main functional entities comprise this context
framework: the context manager, the resource
The systems named in the prior chapter use only one aspect
servers, the context recognition services
of context, namely location information. The use of
and the application.
different types of context atoms such as noise, light and
location allows the combination to high-level context
Figure 2 Context managing framework architecture
objects. These elements are necessary to build more
adaptive, useful and user-friendly systems. As an example
for this kind of context-aware infrastructures serves the
system presented by Munõz et al. (2003), which extends the
instant messaging paradigm by adding context-awareness to
support information management within a hospital setting.
All users (in this case physicians, nurses etc.) are equipped
with mobile devices to write messages that are sent when a
specified set of circumstances is satisfied. For example, a
user can formulate a message that should be delivered to the
first doctor that enters room number 108 after 8 am. The
Whereas the resource servers and the context recognition
contextual elements this system is aware of include location,
services are distributed components, the so-called context
time, roles and device state. Its context functionality is
manager represents a centralised server managing a
moved to agents which include three modules (layers).
blackboard. It stores context data and provides this
The perception module gathers raw context information
information to the client applications.
from data sources (sensors, users, other agents, the server).
The Service-Oriented Context-Aware Middleware
The reasoning module governs the agents’ actions and
(SOCAM) project introduced by Gu et al. (2004a, 2004b) is
finally the action module triggers a user-specified event.
another architecture for the building and the rapid
All messages between agents are XML encoded.
prototyping of context-aware mobile services. It uses a
central server as well, here called context interpreter, which
3.3 Context-aware frameworks gains context data through distributed context providers and
Context-aware systems capable of dealing with special offers it in mostly processed form to the clients. The
types of context are well-suited for specific conditions, context-aware mobile services are located on top of the
e.g., in hospital scenarios. These systems can be optimised architecture, thus, they make use of the different levels of
for the situations they are used in. They do not have to be context and adapt their behaviour according to the current
flexible and extensible. To actually simplify the context.
development of context-aware applications an abstract One further extensible centralised middleware approach
framework is needed. Such a generic infrastructure not designed for context-aware mobile applications is a project
only provides a client with access to retrieve context data, called Context-Awareness Sub-Structure (CASS) presented
it also permits the simple registration of new distributed in Fahy and Clarke (2004). In Figure 3, the system
heterogeneous data sources. In this section different architecture of CASS is presented. The middleware
context-aware frameworks are introduced and compared contains an Interpreter, a ContextRetriever,
based on various design criteria (architecture, resource a Rule Engine and a SensorListener. The
discovery, sensing, context model, context processing SensorListener listens for updates from sensors,
historical context data, security and privacy). which are located on distributed computers called
sensor nodes. Then the gathered information is stored
in the database by the SensorListener. The
3.3.1 Architectures
ContextRetriever is responsible for retrieving stored
The most common design approach for distributed context data. Both of these classes may use the services of
context-aware frameworks is a classical hierarchical an interpreter. The ChangeListener is a component
infrastructure with one or many centralised components with communication capabilities that allows a mobile
using a layered architecture as presented in Section 2. computer to listen for notification of context change events.
This approach is useful to overcome memory and processor Sensor and LocationFinder classes also have built-in
constraints of small mobile devices but provides one communications capabilities. Mobile clients connect to the
single point of failure and thereby lacks robustness. The server over wireless networks. To reduce the impact of
architecture of the Context Managing Framework intermittent connections local caching is supported on the
presented by Korpipää et al. (2003) is depicted in client side.
270 M. Baldauf, S. Dustdar and F. Rosenberg

Figure 3 Architecture of the CASS system information among client devices is called context sharing.
Figure 4 shows the management of a device’s context
which consists of its own local context and a set of remote
contexts gathered from other devices. Both local and remote
context are made up of context objects. The superclass
ContextObject is extended by different context types,
e.g., LocationContext, DeviceContext, etc. This
approach allows the simple addition of new context types by
specialising ContextObject. A context type has to
implement the methods toXML() and fromXML() from
the ContextObject class in order to convert the data
from and to a XML stream.

Figure 4 Hydrogen’s object-oriented approach

Context Broker Architecture (CoBrA) (Chen et al., 2003) is

an agent based architecture for supporting context-aware
computing in so-called intelligent spaces. Intelligent spaces
are physical spaces (e.g., living rooms, vehicles, corporate
offices and meeting rooms) that are populated with
intelligent systems that provide pervasive computing
services to users. Central to CoBrA is the presence of an
intelligent context broker that maintains and manages a
shared contextual model on the behalf of a community of
agents. These agents can be applications hosted by mobile
devices that a user carries or wears (e.g., cell phones, PDAs
and headphones), services that are provided by devices in a
room (e.g., projector service, light controller and room
temperature controller) and web services that provide a web
presence for people, places and things in the physical world
(e.g., services keeping track of peoples and object
whereabouts). The context broker consists of four functional
main components: the Context Knowledge Base, the
Context Inference Engine, the Context Acquisition Module The architecture consists of three layers which are all
and the Privacy Management Module. To avoid the bottle located on the same device (Figure 5). The Adaptor layer is
neck problem CoBrA offers the possibility of creating responsible for retrieving raw context data by querying
broker federations. sensors. This layer permits a sensor’s concurrent use by
The Context Toolkit (Salber et al., 1999; Dey and different applications. The second layer, the Management
Abowd, 2000a; Dey, 2001), another context-aware layer, makes use of the Adaptor layer to gain sensor data
framework, takes a step towards a peer-to-peer architecture and is responsible for providing and retrieving contexts.
but it still needs a centralised discoverer where distributed The so-called Context server offers the stored information
sensor units (called widgets), interpreters and aggregators via synchronous and asynchronous methods to the client
are registered in order to be found by client applications. applications. On top of the architecture is the Application
The toolkits object-oriented API provides a superclass layer, where the appliance code is implemented to react on
called BaseObject which offers generic communication specific context changes reported by the context manager.
abilities to ease the creation of own components. Due to platform and language independency, all inter-layer
Another framework based on a layered architecture is communication is based on a XML-protocol.
built in the Hydrogen project (Hofer et al., 2002). Its context
Figure 5 Architecture of the hydrogen project
acquisition approach is specialised for mobile devices.
While the availability of a centralised component is essential
in the majority of existent distributed content-aware systems,
the Hydrogen system tries to avoid this dependency.
It distinguishes between a remote and a local context.
The remote context is information another device knows
about, the local context is knowledge our own device is
aware of. When the devices are in physical proximity they
are able to exchange these contexts in a peer-to-peer manner
via WLAN, Bluetooth, etc. This exchange of context
 A survey on context-aware systems 271

The CORTEX system is an example for a context-aware In this paper, we focus on Gaia’s parts concerning
middleware approach. The architecture is based on the context-awareness, namely the Event Manager, the Context
Sentient Object Model (Biegel and Cahill, 2004) which was Service and the Context File System. The Event Manager
designed for the development of context-aware applications service is responsible for event distribution in the active
in an ad-hoc mobile environment. The model’s special space and implements a decoupled communication model
suitability for mobile applications depends on the use of based on suppliers, consumers, and channels. Each channel
STEAM, a location-aware event-based middleware service has one or more suppliers that provide information
designed specifically for ad-hoc wireless networking to the channel and one or more consumers that receive the
environments. information. The reliability is increased as suppliers are
A sentient object is an encapsulated entity consisting of exchangeable. With the help of the Context Service,
three main parts, as depicted in Figure 6, Sensory capture, applications may query and register for particular context
Context hierarchy and Inference engine. Via interfaces a information and higher level context objects. Finally the
sentient object communicates with sensors which produce Context File System makes personal storage automatically
software events and actuators which consume software available in the users present location. It constructs a
events. As Figure 6 shows, sentient objects can be both virtual directory hierarchy to represent context as
producer and consumer of another sentient object. Own directories, where path components represent context types
sensors and actuators are programmed using STEAM. and values. For example, to determine which files have the
For building sentient objects, a graphical development tool context of location == RM2401 && situation
is available which allows developers to specify relevant == meeting associated with them, one may enter
sensors and actuators, define fusion networks, specify the /location:/RM2401/situation:/meeting
context hierarchies and production rules, without the need to directory.
write any code.
The Gaia project (Roman et al., 2002; Gaia Project, 3.3.2 Resource discovery
2005), another middleware infrastructure, extends typical
operating system concepts to include context-awareness. As sensors in a distributed network may fail or new ones
It aims at supporting the development and execution of may be added, a discovery mechanism to search for and find
portable applications for active spaces. Gaia exports appropriate sensors at runtime is important. For these
services to query and utilise existing resources, purposes the Context Toolkit offers the already mentioned
to access and use current context, and it provides a discoverer. The discoverer works as registry component
framework to develop user-centric, resource-aware, which interpreters, aggregators and widgets have to notify
multi-device, context-sensitive and mobile applications. about their presence and their contact possibilities. After
The current system consists of the Gaia kernel and the registration the components are pinged to ensure that they
application framework as depicted in Figure 7. are operating. If a component does not respond to a
specified number of consecutive pings, the discoverer
Figure 6 The sentient object model determines that the component is unavailable and removes it
from its registry list. Customers may find appropriate
components querying the discoverer either via a white page
lookup (a search for the components name) or a yellow page
lookup (a search for specific attributes). In case the lookup
was successful the discoverer returns a handle to contact the
context component.
SOCAM offers a discovery mechanism as well called
Service Locating Service. In Gaia different context
providers are stored in a registry component. A pure
peer-to-peer context-aware system such as Hydrogen only
uses local built-in sensors and does not connect to distributed
Figure 7 Architecture of the Gaia system sensors, therefore, no discovery mechanism is involved.

3.3.3 Sensing
The Context Toolkit authors presented a new approach to
handle different data sources. Derived from the use of
widgets in GUI development, they introduced so-called
context widgets to separate applications from context
acquisition concerns. In these widgets the complexity of
sensing is hidden. Furthermore, they abstract the gained
272 M. Baldauf, S. Dustdar and F. Rosenberg

context information (e.g., the accurate position of a Listing 1 CORBA-ONT example

person might not be of value but the application should be
notified when this person enters another room) and as
widgets are encapsulated software components, they are
reusable. Each widget owns some attributes that can be
queried by applications, e.g., the IdentityPresence
widget, implemented by the authors, offers attributes
such as its location, the last time a presence was
detected and the identity of the last user detected.
Beside the polling mechanism an asynchronous way
of data retrieval is possible too: if an application
subscribes to a widget, it is notified when the widgets
context changes. The IdentityPresence provides the In Gaia context is represented in a special manner,
callbacks PersonArrives(location, identity, namely through 4-ary predicates in the way Context
timestamp) and PersonLeaves (location, (<ContextType>, <Subject>, <Relater>,
identity, timestamp) which are triggered when a <Object>) written in DAML + OIL. The <Context
person either arrives or leaves a room. The separation of Type> refers to the type of context the predicate is
acquisition and use of context permits a simple exchange of describing, the <Subject> is the person, place or thing
widgets since e.g., identity may be sensed in various ways with which the context is concerned, and the <Object> is
like Active Badges, video recognition, etc. This manner of a value associated with the <Subject>. The <Relater>
building reusable sensor units that make the action of relates the <Subject> and the <Object> such as a
sensing transparent to the customer (whether it is a comparison operator (=, >, or <), a verb, or preposition.
centralised server or a distributed client component), An example for a context instance is Context(temperature,
became widely accepted in distributed context-aware room 3231, is, 98 F). This syntax is used for both,
systems: CASS applies sensor nodes, SOCAM uses context representing context and for forming inference rules.
providers, the Context Managing Framework refers to
resource servers and CoBrA makes use of context 3.3.5 Context processing
acquisition components.
As soon as the raw context data is sensed by a data source, it
has to be processed as its customers mostly are rather
3.3.4 Context model
interested in already interpreted and aggregated information
An efficient model for handling, sharing and storing than in raw, fine-grained data. Whereas context aggregation
context data is essential for a working context-aware refers to the composition of context atoms either to collect
system. The Context Toolkit handles context in simple all context data concerning a specific entity or to build
attribute-value-tuples, which are encoded using XML for higher-level context objects, context interpretation refers to
transmission. As already described above Hydrogen uses an the transformation of context data including special
object-oriented context model approach with a superclass knowledge. These forms of context data abstraction
called ContextObject which offers abstract methods to ease the application designer’s work tremendously.
convert data streams from XML representations to context The Context Toolkit offers facilities for both context
objects and vice versa. More advanced ways of dealing with aggregation and context interpretation. The context
context data based on ontologies are found in SOCAM, aggregators (former called context servers) are responsible
CoBrA and the Context Managing Framework. The SOCAM for composing context of particular entities by subscribing
authors divide a pervasive computing domain into several to relevant widgets, context interpreters provide the
sub-domains, e.g., home domain, office domain etc., and possibility of transforming context, e.g., in a simple case
define individual low-level ontologies in each sub-domain returning the corresponding e-mail address to a passed
to reduce the complexity of context processing. Each of name. Like widgets aggregators and interpreters inherit
these ontologies implemented in OWL provides a special communication methods from the upperclass BaseObject
vocabulary used for representing and sharing context and have to be registered at the discoverer in order to be
knowledge. CoBrA also uses an own OWL-based ontology found. The Context Managing Framework presented by
approach, namely COBRA-Ont (Chen et al., 2003, 2004). Korpip et al. (Figure 2) offers various processing facilities
Listing 1 shows parts of an COBRA-Ont example. as well. The resource servers’ tasks are complex. First they
The ontology structure and vocabulary applied in the gather raw context information by connecting to various
Context Managing Toolkit are described in RDF. Parts of its data sources. After the preprocessing and feature abstraction
vocabulary are used as an example in Table 2 in Section 2. crip limits and fuzzy sets are used for quantisation. But now
 A survey on context-aware systems 273

the data are delivered by posting it to the context manager’s higher-level abstractions are handled by the application
blackboard. The context recognition services are used layer, such as in Hydrogen.
by the context manager to create higher-level context object
out of context atoms. In this vein new recognition services
3.3.6 Historical context data
are easy to add.
In SOCAM, the Context Reasoning Engine reasons over Sometimes it might be necessary to have access to historical
the knowledge base, its tasks include inferring deduced context data. Such context histories may be used to establish
contexts, resolving context conflicts and maintaining the trends and predict future context values. As most data
consistency of the context knowledge base. Different sources constantly provide context data, the maintenance of
inference rules used by the reasoning engine can be a context history is mainly a memory concern, so a
specified. The interpreter is implemented by using Jena2 centralised high-resource storage component is needed.
(Jena, 2005), a semantic web toolkit. Since in a server-based architecture the context data
In CoBrA the so-called Inference Engine processes provided by sensors has anyway to be stored at the
context data. The engine contains the Context Reasoning server-side to offer it to customers, the majority of these
Module responsible for aggregating context information. systems has the facility to query historical context data.
It reasons over the Context Knowledge Base and deduces The Context Toolkit, CoBrA, CASS, SOCAM and CORTEX
additional knowledge from information acquired from save sensed context data persistently in a database. A further
external sources. advantage of using a database is the use of the Structured
In CASS deriving of high-level context is also based on Query Language (SQL) which enables to read and to
an inference engine and a knowledge base. The knowledge manipulate operations at a high abstraction level. In the
base contains rules queried by the inference engine to find CoBrA and the CASS architecture the persistent storage is
goals using the so-called forward chaining technique. called Context Knowledge Base. Additionally a set of APIs
As these rules are stored in a database separated from the is offered to assert, delete, modify and query the stored
interpreter neither recompiling nor restarting of components knowledge. CASS uses its database not only to save context
is necessary when rules change. Table 3 shows an example data but also to store domain knowledge and inference rules
rule database entry containing criteria to display rather needed for creating high-level context. Due to limited memory
indoor than outdoor activities in a CASS based tour-guide resources a peer-to-peer network of mobile devices like
application. Hydrogen is not able to offer persistent storage possibilities.

Table 3 Example rule database entry

3.3.7 Security and privacy
Rain Brightness Temperature Goal
As context may include sensitive information on people,
Wet Dull Cold Indoor e.g., their location and their activity, it is necessary to have
the opportunity to protect privacy. For these purposes the
In CORTEX, the whole context processing is encapsulated Context Toolkit introduces the concept of context
in Sentient Objects. The sensory capture unit performs ownership. Users are assigned to sensed context data as
sensor fusion to manage uncertainty of sensor data their respective owners. They are allowed to control the
(sensing conflicts) and to build higher-level context objects. other users’ access. New components involved in this access
Different contexts are represented in a so-called context control are the Mediated Widgets, Owner Permissions,
hierarchy together with specific actions to be undertaken in a modified BaseObject and Authenticators.
each context. Since only one context is active at any point The MediatedWidget class is an extension of a basic
in time (concept of the active context) the number of rules widget which contains a so-called widget developer
that have to be evaluated are limited. Thus efficiency of the specifying who owns the data being sensed. The Owner
inference process is increased. The inference engine Permission is the component that receives permission
component is based on C Language Integrated Production queries and determines to grant or to deny access based on
System (CLIPS). It is responsible for changing application stored situations. These situations include authorised
behaviour according to the current context by using users, time of access etc. The modified BaseObject contains
conditional rules. Gaia’s context processing is hidden in the all the original methods augmented with identification
Context Service Module allowing the creation of high-level mechanisms. Now applications and components have to
context objects by performing first order logic operations provide their identity along with the usual request for
such as quantification, implication, conjunction, disjunction, information. Finally the authenticator is responsible for
and negation of context predicates. One example of a rule is proofing the identity by using a public-key infrastructure.
Context(Number of people, Room 2401, >, 4) CoBrA includes an own flexible policy language to control
AND Context(Application, Powerpoint, is, context access, called Rei (Kagal et al., 2003). This policy
Running) Ÿ Context(Social Activity, Room language is modelled on deontic concepts of rights,
2401, Is, Presentation). Almost all current prohibitions, obligations and dispensations and controls data
context-aware frameworks permit the aggregation and access through dynamically modifiable domain dependent
interpretation of raw context data. Only in a few cases the policy rules.
274 M. Baldauf, S. Dustdar and F. Rosenberg

4 Discussion of approaches are consumed by using context events represented in OWL

based on a predefined ontology.
In Table 4 we have summarised the main aspects
The context model and the context processing logic
of the discussed approaches. The architectural style of a
supported by different frameworks is a major criteria for
context-aware system is mainly driven by the context
providing intelligent and adaptable context-aware services
acquisition method. The main criteria for a reasonable
or applications. As mentioned before, ontologies provide a
architectural approach is the separation of concerns between
rich formalism for specifying contextual information. Based
the context acquisition and the user components as proposed
on such ontological models, highly sophisticated ontology
by Dey (2000). All the frameworks presented in this paper
reasoning engines can derive new concepts to adapt the
support this separation of concerns.
service behaviour accordingly. The major drawback of the
The sensing technology is implemented differently in
Context Toolkit is, therefore, its context model, a set of
every framework. It is important, that the concrete
attribute-value tuples. The development of intelligent context
sensing mechanism is encapsulated in separate components,
processing and aggregation is limited due to the fact that
to support the aforementioned separation of concerns.
such attributes do not have a meaning. Furthermore, using
Furthermore, it encapsulates sensing and allows to access
non-ontology based models requires a lot of programming
the contextual data via defined interfaces. Currently, there is
effort and tightly couples the context model to the rest of
no standard description language or ontology for sensing
the system. Moreover, the lack of declarative semantics of
contextual information from various sources to enable reuse
programs does not allow reasoning and knowledge sharing
across various middleware systems and frameworks.
amount systems. For example, SOCAM uses a general upper
Therefore, proprietary solutions as used by the different
ontology to specify basic common contextual properties and
frameworks, have emerged. SOCAM use the most
to refine this general ontology. Domain-specific ontologies
sophisticated approach for sensing context information.
can be defined to provide very fine grained possibilities for
External virtual sensors are consumed via web services
specifying and formalising context.
(by using SOAP). Internal providers for querying sensors

Table 4 Summary of discussed approaches

Context Context Historical Security

Architecture Sensing model processing Resource discovery context data and privacy
CASS Centralised Sensor nodes Relational Inference engine n.a. Available n.a.
middleware data model and knowledge base
CoBra Agent based Context Ontologies Inference engine n.a. Available Rei policy
acquisition (OWL) and knowledge base language
module
Context Blackboard Resource Ontologies Context recognition Resource servers n.a. n.a.
Management based servers (RDF) service + subscription
Framework mechanism
Context Widget based Context Attribute-value Context Discoverer Available Context
Toolkit widgets tuples interpretation and component ownership
aggregation
CORTEX Sentient object Context Relational Service discovery Resource Available n.a.
model component data model framework management
framework component
framework
Gaia MVC Context 4-ary predicates Context-service Discovery service Available Supported
(extended) providers (DAML + OIL) module (first-order (e.g., secure
logic) tracking, location
privacy, access
control)
Hydrogen Three layered Adapters Object-oriented Interpretation and n.a. n.a. n.a.
architecture for various aggregation of raw
context types data only
SOCAM Distributed with Context Ontologies Context reasoning Service Available n.a.
centralised providers (OWL) engine locating service
server
 A survey on context-aware systems 275

Resource discovery mechanisms are currently rarely used in Other often disregarded aspects are security and
the presented frameworks. Such dynamic mechanisms are privacy issues. These facets belong to the most important
important, especially in a pervasive environment, where components of a context-aware system as the protection of
available sensors, the context sources, change rapidly sensitive context data must be guaranteed. Many systems
(new ones are added or removed). SOCAM, for example, totally lack security modules, others provide basic security
which is the only system that is based on a service-oriented mechanisms and only a few systems offer advanced and
architecture, offers a service locating service, which sufficient security options. Probably the main problem in
dynamically binds to available context providers. the presented approaches is the variety of used context
These providers can also be changed at runtime. The lack of encodings and ways to find and access context sources.
resource discovery support is a major drawback of many Every system and framework uses its own format to
frameworks, because it implies that the used context sources describe context and its own communications mechanisms.
are stable and permanently available, which is not always We believe that standardised formats and protocols are
the case in real-world applications. Erroneous behaviour of important for the enhancements of context-aware systems to
one or more context sources may lead to a decreased make the development of context services the focus rather
availability of the context-aware service or application. than the communication between context sources and users.
Managing historical context data provides the ability In our opinion web service technologies seem to be an
to implement intelligent learning algorithms which allow appropriate solution to achieve that aim as they provide
to provide highly adaptable context-aware services. standardised methods for service description and access.
Furthermore, based on learning algorithms, contextual Our future work in this area will investigate the use of
information can be predicted to proactively provide a certain service-oriented and autonomic computing concepts for
set of services to the user. Many of the systems store building context-aware service frameworks. We believe
contextual information but none of them do not use learning that standardised technologies and protocols, such as
techniques to provide context-aware service proactively. WSDL and SOAP, could help to build more interoperable
Another important aspect is security and privacy. context aware services. Furthermore, the use of ontologies
Contextual information mostly considers user profile for building a context model is an important approach
information and other sensitive information. Therefore, (as can be seen from existing approaches) to build
concepts are needed to express policies and to define more sophisticated algorithms, which derive new contextual
ownership of context information. CoBra uses the Rei knowledge or patterns to proactively aggregate new
policy language, to express (security) policies about context-aware services. Autonomously orchestrating atomic
contextual information. Gaia uses several mechanisms to context-aware services into higher level services based
define privacy restrictions and secure communication on context information and available QoS parameters
for tracking locations of people. The Context Toolkit provides high potential for offering more accurate services
implements the concept of context ownership, which is used to the user.
to allow access to the context to the owner only. The other
frameworks do not use security concepts, which is one of
their major drawback. When dealing with sensitive data, References
secure connections for context acquisition as well as privacy Abowd, G.D., Atkeson, C.G., Hong, J., Long, S., Kooper, R.
of different user specific contextual information is very and Pinkerton, M. (1997) ‘Cyberguide: a mobile
important. context-aware tour guide’, Wirless Networks, Vol. 3, No. 5,
pp.421–433.
Ailisto, H., Alahuhta, P., Haataja, V., Kylloenen, V. and
Lindholm, M. (2002) ‘Structuring context aware applications:
5 Conclusions and future work Five-layer model and example case’, Proceedings of the
Workshop on Concepts and Models for Ubiquitous
In this survey paper we described different design principles Computing, Goteborg, Sweden, available online: http://
and context models for context-aware systems and www.comp.lancs.ac.uk/computing/users/dixa/conf/ubicomp2
presented various existent middleware and server-based 002-models/pdf/Ailisto-Ubicomp%20Workshop8.pdf.
approaches to ease the development of context-aware Biegel, G. and Cahill, V. (2004) ‘A framework for developing
applications. The direct comparison of the named systems mobile, context-aware applications’, Proceedings of the 2nd
and frameworks shows their similarity concerning the IEEE Conference on Pervasive Computing and
Communication, pp.361–365.
layered structure. Especially remarkable is the strict division
of the context data acquisition and use. Thus context sources Brown, P.J. (1996) ‘The stick-e document: a framework for
creating context-aware applications’, Proceedings of the
become reusable and are able to serve a multitude of context
Electronic Publishing, Palo Alto, pp.259–272.
clients. Although most authors refer to abstract context
Budzik, J. and Hammond, K.J. (2000) ‘User interactions with
sources, the currently mainly used and tested sources are
everyday applications as context for just-in-time information
physical sensors. Virtual and logical sensors are capable of access’, Proceedings of the 5th international Conference on
providing useful context data as well and should be more Intelligent User Interfaces, New Orleans, Louisiana, USA,
incorporated in ongoing research. pp.44–51.
276 M. Baldauf, S. Dustdar and F. Rosenberg

Burrell, J. and Gay, G. (2002) ‘E-graffiti: evaluating real-world Gustavsen, R.M. (2002) ‘Condor – an application framework for
use of a context-aware system’, Interacting with mobility-based context-aware applications’, Proceedings of
Computers – Special Issue on Universal Usability, Vol. 14, the Workshop on Concepts and Models for Ubiquitous
No. 4, pp.301–312. Computing, Goeteborg, Sweden.
Chen, H. (2004) An Intelligent Broker Architecture for Pervasive Harter, A., Hopper, A., Steggles, P., Ward, A. and Webster, P.
Context-Aware Systems, PhD Thesis, University of Maryland, (2002) ‘The anatomy of a context-aware application’, Wirless
Baltimore County. Networks, Vol. 8, Nos. 2–3, pp.187–197.
Chen, H., Finin, T. and Joshi, A. (2003) ‘An ontology for Hendricksen, K., Indulska, J. and Rakotonirainy, A. (2003)
context-aware pervasive computing environments’, The ‘Generating context management infrastructure from
Knowledge Engineering Review, Cambridge University Press, high-level context models’, Proceedings of the 4th
Vol. 18, pp.197–207. International Conference on Mobile Data Management
Chen, H., Finin, T. and Joshi, A. (2004) ‘An ontology for (MDM'03), pp.1–6.
context-aware pervasive computing environments’, Special Hofer, T., Schwinger, W., Pichler, M., Leonhartsberger, G.
Issue on Ontologies for Distributed Systems, Knowledge and Altmann, J. (2002) ‘Context-awareness on mobile
Engineering Review, Vol. 18, No. 3, pp.197–207. devices – the hydrogen approach’, Proceedings of the 36th
Cheverst, K., Davies, N., Mitchell, K., Friday, A. and Annual Hawaii International Conference on System Sciences,
Efs-tratiou, C. (2000) ‘Developing a context-aware electronic pp.292–302.
tourist guide: some issues and experiences’, Proceedings of Hong, J.I. and Landay, J.A. (2001) ‘An infrastructure for
the SIGCHI conference on Human Factors in Computing context-aware computing’, Human-Computer Interaction,
Systems, ACM Press, New York, USA, pp.17–24. Vol. 16, pp.287–303.
Dey, A.K. (1998) ‘Context-aware computing: the CyberDesk Hull, R., Neaves, P. and Bedford-Roberts, J. (1997) ‘Towards
project’, Proceedings of the AAAI, Spring Symposium on situated computing’, Proceedings of the First International
Intelligent Environments, Menlo Park, CA, pp.51–54. Symposium on Wearable Computers (ISWC ‘97), p.146.
Dey, A.K. (2000) Providing Architectural Support for Building Indulska, J. and Sutton, P. (2003) ‘Location management in
Context-Aware Applications, PhD Thesis, Georgia Institute of pervasive systems’, CRPITS’03: Proceedings of the
Technology, Georgia Institute of Technolgy, USA. Australasian Information Security Workshop, pp.143–151.
Dey, A.K. (2001) The Context Toolkit – A Toolkit for Jena (2005) A Semantic Web Framework for Java, http://jena.
Context-aware Applications, http://www.cs.berkeley.edu/ sourceforge.net/.
~dey/context.html. Kagal, L., Finin, T. and Joshi, A. (2003) ‘A policy language for a
Dey, A.K. and Abowd, G.D. (2000a) ‘The context toolkit: aiding pervasive computing environment’, Proceedings of the 4th
the development of context-aware applications’, Workshop on IEEE International Workshop on Policies for Distributed
Software Engineering for Wearable and Pervasive Systems and Networks (POLICY), pp.63–74.
Computing, Limerick, Ireland. Kerer, C., Dustdar, S., Jazayeri, M., Gomes, D., Szego, A. and
Dey, A.K. and Abowd, G.D. (2000b) ‘Towards a better Caja, J.A.B. (2004) ‘Presence-aware infrastructure using web
understanding of context and context-awareness’, Proceedings services and RFID technologies’, Proceedings of the 2nd
of the Workshop on the What, Who, Where, When and How of European Workshop on Object Orientation and Web Services,
Context-Awareness, ACM Press, New York. Oslo, Norway.
Dey, A.K. and Abowd, G.D. (2001) ‘A conceptual framework and Korpipää, P. and Mäntyjärvi, J. (2003) ‘An ontology for mobile
a toolkit for supporting rapid prototyping of context-aware device sensor-based context awareness’, Proceedings of
applications’, Human-Computer Interactions (HCI) Journal, CONTEXT, 2003, Vol. 2680 of Lecture Notes in Computer
Vol. 16, Nos. 2–4, pp.7–166. Science, pp.451–458.
Espinoza, F., Persson, P., Sandin, A., Nystrom, H., Cac-ciatore, E. Korpipää, P., Mantyjarvi, J., Kela, J., Keranen, H. and Malm, E-J.
and Bylund, M. (2001) ‘GeoNotes: social and navigational (2003) ‘Managing context information in mobile devices’,
aspects of location-based information systems’, Proceedings IEEE Pervasive Computing, Vol. 2, No. 3, July–September,
of the 3rd International Conference on Ubiquitous pp.42–51.
Computing, Atlanta, Georgia, USA, pp.2–17. McCarthy, J. and Buvac, S. (1997) ‘Formalizing context
Fahy, P. and Clarke, S. (2004) ‘CASS – a middleware for (expanded notes)’, in Buvac, S. and Iwahska, L. (Eds.):
mobile context-aware applications’, Workshop on Context Working Papers of the AAAI Fall Symposium on Context in
Awareness, MobiSys 2004. Knowledge Representation and Natural Language, California.
Finkelstein, L., Gabriolovic, E., Matias, Y., Rivilin, E., Solan, Z., American Association for Artificial Intelligence, Menlo Park,
Wolfman, G. and Ruppin, E. (2001) ‘Placing search in context: pp.99–135.
the concept revisited’, Proceedings of the 10th International Munõz, M.A., Gonzalez, V.M., Rodriguez, M. and
World Wide Web Conference (WWW 10), Hong Kong. Fa vela, J. (2003) ‘Supporting context-aware collaboration
Gaia Project (2005) http://gaia.cs.uiuc.edu/. in a hospital: an ethnographic informed design’, Proceedings
of Workshop on Artificial Intelligence, Information
Gu, T., Pung, H.K. and Zhang, D.Q. (2004a) ‘A middleware Access, and Mobile Computing 9th International
for building context-aware mobile services’, Proceedings Workshop on Groupware, CRIWG 2003, Grenoble, France,
of IEEE Vehicular Technology Conference (VTC), Milan, pp.330–334.
Italy.
Prekop, P. and Burnett, M. (2003) ‘Activities, context and
Gu, T., Pung, H.K. and Zhang, D.Q. (2004b) ‘A middleware for ubiquitous computing’, Special Issue on Ubiquitous
building context-aware mobile services’, Proceedings of Computing Computer Communications, Vol. 26, No. 11,
IEEE Vehicular Technology Conference (VTC 2004), Milan, pp.1168–1176.
Italy.
 A survey on context-aware systems 277

Priyantha, N.B., Chakraborty, A. and Balakrishnan, H. (2000) Strang, T. and Linnhoff-Popien, C. (2004) A Context Modeling
‘The cricket location-support system’, Proceedings of the 6th Survey, First International Workshop on Advanced Context
Annual International Conference on Mobile Computing and Modelling, Reasoning and Management, UbiComp.
Networking, ACM Press, pp.32–43. Sumi, Y., Etani, T., Fels, S., Simonet, N., Kobayashi, K. and Mase,
Roman, M., Hess, C., Cerqueira, R., Ranganathan, A., K. (1998) ‘C-map: Building a context-aware mobile assistant
Campbell, R.H. and Nahrstedt, K. (2002) ‘A middleware for exhibition tours’, Community Computing and Support
infrastructure for active spaces’, IEEE Pervasive Computing, Systems, Social Interaction in Networked Communities
Vol. 1, No. 4, pp.74–83. [the book is based on the Kyoto Meeting on Social Interaction
Ryan, N., Pascoe, J. and Morse, D. (1997) ‘Enhanced reality and Communityware, held in Kyoto, Japan, in June 1998],
fieldwork: the context-aware archaeological assistent’, Springer-Verlag, London, UK, pp.137–154.
Proceeding of the 25th Anniversary Computer Applications in W3C (2000) Resource Description Framework (RDF),
Archaeology, http://www.caaconference.org/. http://www.w3.org/RDF.
Salber, D., Dey, A.K. and Abowd, G.D. (1999) ‘The context W3C (2004a) Composite Capability/ Preference Profiles (CC/PP),
toolkit: aiding the development of context-aware http://www.w3.org/TR/2004/ REC-CCPP-struct-vocab-
applications’, Proceedings of the ACM CHI, Pittsburgh, PA, 20040115/.
pp.434–441. W3C (2004b) OWL Web Ontology Language Overview, W3C
Schilit, B. and Theimer, M. (1994) ‘Disseminating active map Recommendation 10 February, http://www.w3.org/TR/
information to mobile hosts’, IEEE Network, Vol. 8, No. 5, owl-features/.
pp.22–32. Want, R., Hopper, A., Falcao, V. and Gibbons, J. (1992)
Schmidt, A. and van Laerhoven, K. (2001) ‘How to build smart ‘The active badge location system’, ACM Transactions on
applications?’, IEEE Personal Communications, Vol. 8, Information Systems, Vol. 10, No. 1, pp.91–102.
No. 4, pp.66–71. Wapforum (2001) User Agent Profile (UAProf) Specification,
Sheng, Q.Z. and Benatallah, B. (2005) ‘ContextUML: http://www.wapforum.org.
a UML-based modeling language for model-driven Weiser, M. (1991) ‘The computer for the 21st century’, Scientific
development of context-aware web services’, Proceedings of American, pp.94–104.
the International Conference on Mobile Business (ICMB’05),
pp.206–212. Winograd, T. (2001) ‘Architectures for context’, Human-Computer
Interaction (HCI) Journal, Vol. 16, No. 2, pp.401–419.

View publication stats