A Survey of Context-Aware System
- The Past, Present, and Future
Sang-keun Lee
Intelligent Database Systems Lab
Seoul National University
Abstract
Realizing context-aware systems has become one of the most important issues, as it is considered as a key
driver for ubiquitous environment. Since nineties, there have been a wide range of existing context-aware
systems in history. In this paper, we present a survey of a number of existing researches on context-
awareness, focusing on context-aware systems and frameworks. Firstly, we outline a general process in
context-aware systems and explain design considerations of context-aware systems. Secondly, we describe
existing context-aware systems in history and provide comparison and trend analysis of the systems. In
conclusion, we summarize our work and suggest future work for better context-aware systems.
1. Introduction
Nowadays, the advanced network and the wide spread of mobile devices such as PDAs and smart
phones make computing paradigm more distributed and pervasive. In this environment, users expect to
get useful services and information via their mobile devices. However, because the number of services and
the amount of information have been also increasing rapidly, it is difficult and time-consuming for users to
search proper services or information.
A context-aware system is one that actively and autonomously adapts and provides the most
appropriate services or information to users, using the advantage of people’s contextual information
without much interaction. Realizing it is considered as a key driver for solving the problems presented
above, and there have been many researches on the topic since early 90s.
In this paper, we surveyed a number of existing researches on context-awareness especially focusing on
context-aware systems and frameworks. The rest of the paper is organized into following sections. In
section 2, we explain a general process in context-aware systems to understand the concepts and
functionalities of general context-aware systems, and we present the other design criteria of context aware
systems and related issues. In section 3, we present history of context-aware systems and summarize
several representative context-aware systems. In section 4, we compare several representative context-
aware systems and analyze the trend. In section 5, we conclude our work and suggest future work for
better context-aware systems.
2. General Process in Context-Aware Systems
Figure 1 A General Process in Context-Aware Systems
Context-aware systems are usually complicated systems, and they are responsible for many jobs such as
representation, management, reasoning, and analysis of context information. They provide their
functionalities through the collaboration of many different components in the systems. There are various
types of different context-aware systems, thus, it is hard to generalize context-aware system process;
however, generally, a context-aware system follows four steps.
First step is acquiring context information from sensors. Sensors convert real world context information
into computable context data. By using physical sand virtual sensors, the system can acquire various types
of context-aware information. After acquiring context information, the system stores acquired context data
into its repository. When storing context data, what kind of data model is used to represent context
information is very important. Context models are diverse, and each context model has its characteristics.
To easily use the stored context data, the system controls the abstraction level of stored context data by
interpreting or aggregating context data. Finally, the system utilizes the abstracted context data for
context-aware applications.
In the following sections, we explain how a general context-aware system processes each step and
discuss related issues. Figure 1 shows a general process in context-aware system.
2.1 Acquiring Context Information
Because of the diversity of context information types, context information can be acquired in many
ways. Physical sensors, which are hardware devices that convert physical analogue properties into
computable digital data, can be used for acquiring context information. According to the types of context
information, many different physical sensors can be used. For example, to attain location information, GPS,
Active Badge System, and IR sensors can be used. Microphones can be used to get audio context, and
cameras can be used to acquire visual context. In addition, motion sensors or pressure sensors can be
applied in context-aware systems for various purposes.
However, using physical sensors is not the only way of acquiring context information. Assuming a
context-aware application which recommends a music playlist based on user’s preference, weather
conditions of current location, and current location of users. In this situation, user’s preference can be
acquired by analyzing the user’s music play history, and the weather conditions of current location can be
attained by querying a web service provided by a forecasting site. Although these context can be acquired
without using physical sensors, there needs to software modules that perform as virtual sensors. Virtual
sensors acquire context information by analyzing various data or querying external sources. Explicitly
provided context information by users also can be used in a context-aware system.
2.2 Storing Context Information
Figure 2 Context Models
Most of context systems store acquired context data into their repository. Context models are closely
related to context storing. Many factors such as expressiveness, flexibility, generality, and computational
cost to process context-aware data depend on what kind of context model is used in the system.
Context information can be represented in many ways from very simple data model like key-value
model to complex ontological model. Schilit(1994) and Context Toolkit(1999) used key-value model to
express context information. Key-value model can be easily adopted in context-aware systems, but it has
limitation of representing complex structure of context information.
McCarthy(1997) introduced logic-
based context model that represents context information using facts and rules. Logic-based context model
has high mathematical formality and support for inferences. Many structured context data models are
introduced such as Mark-up scheme context model, object-oriented context mode, or context extension of
UML, ORM.
Ontological context model has been widely used recently. Many context-aware systems such as SOCAM,
CoBrA, CoCA adopted ontology as their context data model. Ontological context model has high
expression power and formality at the same time, and it is a suitable data model for representing the
relationships among context information and entities.
2.3 Controlling Context Abstraction Level
Context-aware system is responsible for controlling abstraction level of context information and
performs context abstraction in two ways – Context aggregation and context interpretation. Context
aggregation means that the system aggregates many low-level signals (raw data) into manageable number
of high level information. For example, a context-aware system converts thousands of temperature signals
into several keywords (e.g. ‘hot’, ‘cold’, ‘moderate’, ‘cool’, ’warm’) by context aggregation. Context
interpretation is another method that interprets context information and adds semantics. For example, a
context-aware system can interpret GPS signal into street name.
It is hard for context-aware systems to directly use the raw data provided by sensors. So, context-aware
systems translate sensed signals into meaningful data so that they can understand and use context data
more easily. Additionally, context-aware systems can reduce the number of context data and achieve
better performance by controlling the level of context abstraction.
If the context abstraction is separated from a context-aware application, then the context-aware
application does not have to know the details of sensors but still can use the sensed context data by the
sensors.
2.4 Using Context Information
Utilizing acquired and abstracted context information as useful information for services or applications
is the last step of the general context-aware system process. Context-aware systems use context
information for two purposes – context information as triggering condition and context information as
additional information.
Context information can be used as a triggering condition of an action. A context-aware system can use
context information as action triggering condition when it wants to trigger actions if current context
satisfies a specific situation.
To enhance the quality of service of application, context information can be used as additional
information for services or applications. For example, assume that a user sends queries to a information
server, user’s current context information can be used as a additional information for better results of the
queries. These two purposes of context information usage can be combined together.
We can use context information for many types of context-aware application. Below presents several
examples of context-aware application categories.

Context-Aware Personalization Providing personalized contents or information based on user’s
current context information (e.g. tour guide service)

Automatic Device Configuration Automatically setting up device’s configuration according to user’s
current situation (e.g. screen brightness of PDA)

Context-aware User Interface Optimizing user interface based on user’s current context (e.g.
emphasize icons that user may select)

Context-aware Suggestion Providing suggestions to users behavior based on user’s current situation
(e.g. warning dangerous situation)
2.5. Design Considerations of Context-Aware Systems
When designing context-aware system, we need to consider many aspects of context-aware systems.
Context-aware systems can be implemented many ways and can have different structure, depending on
what the development focus of the system is. In this section, we discuss several design considerations,
which are not mentioned in the previous sections, such as architecture style, handling dynamicity, privacy
protection, and performance & scalability.

Architecture Style
Figure 3 Context-Aware Systems Architecture Styles
Context-aware system’s representative architecture styles can be categorized into three - Stand-alone,
Distributed, Centralized Architecture. Figure 3 shows the simplified architecture diagram of each category.
Characteristics, advantages, and disadvantages of each are explained below.
–
Stand-alone Architecture A basic architecture that directly accesses sensors and does not
consider context sharing of devices. This architecture can be relatively easily implemented but has
limitations in that it can’t process device collaboration. This architecture is appropriate for small
and simple application or domain-specific application.
–
Distributed Architecture Context-aware systems, which have distributed architecture, can store
context information in many separated devices, and there is no additional central server. Each
device is independent with other devices, thus, context-aware system can ignore failure or
bottleneck problem and still can continue context-aware operations. Each device manages its own
context information and share context information with other devices by communicating with
other devices, thus an ad-hoc communication protocol is required. However, it is hard for a
device to know overall situation of every device when using ad-hoc communication protocols.
Usually mobile devices lack of resources and computation power, so, distributed architecture are
with limitations in dealing with computationally intensive applications.
–
Centralized Architecture (Context Server) Sensors and devices are connected to a centralized
context server that has enough resource and computational power, and context information is
stored in a centralized server. If a device needs to get other device’s context information, the
device queries the centralized server and gets the result. In this architecture, every communication
is performed by querying the context server, so the communication protocol can be relatively
simple than distributed architecture. By using a computationally powerful device as a centralized
server, many applications which require high resources and cost can be performed. However,
there is a disadvantage of this approach in that it is crucial if the centralized server fails or
bottleneck problem occurs.

Handling Dynamicity
Handling dynamicity is one of important considerations to make a context-aware system possible to
process sophisticated context-aware applications. Entities (people, devices, sensors, etc) varying from
simple sensors, resource-poor mobile devices to central server with high performance take parts to
process context-aware applications. At the same time, connections and disconnections of many devices
dynamically occur. A context-aware system should be able to deal with heterogeneous entities and
support for resource discovery.

Privacy Protection
Supporting privacy protection is another consideration for context-aware systems. Context-aware
systems autonomously gather information from the users, so some of the users may feel uncomfortable in
that the system can use or open their information without any notice. Thus, a context-aware system
should allow users to express their privacy needs. Context-aware systems should protect user’s context
information from illegal accesses and guarantee anonymity.

Performance and Scalability
In most cases, many operations for context-aware applications should be processed in real time, and a
sophisticated context-aware system has need of reasoning and inference functionalities which require high
computational cost and resource. Performance and scalability of a context-aware system is very important
so that the system instantly response to current context of users. Also communication protocol must
perform adequately with acceptable scalability.
3. History of Context-aware Systems
From domain specific context-aware systems or location-based systems to general and extensible
systems, there have been a wide variety of context-aware systems and applications. To understand how
context aware systems have been evolved since they were introduced, we present a review of several
existing context-aware systems and analyze the trend. We categorized existing context-aware systems into
three categories based on their characteristics and the time when they were introduced, and we named
each category 1st, 2nd, 3rd generation of context-aware systems.
From early 90s, several context-aware systems started to be introduced by many researchers. We
grouped the systems that introduced from around 1990 to 2000 and use limited numbers and types of
context information such as location and time into 1st generation context aware systems (e.g. Active Badge
System, Cyberguide, Sumi, etc). Most of them focus on specific domain applications or how to achieve
location information, and they have relatively simple architectures.
2nd generation context-aware systems tend to be more general than the 1 st generation context aware
systems in that they can process more various types of context information (e.g. Watson Project) and
support for rapid prototyping various context-aware applications. Context-aware frameworks like Context
Toolkit, Hydrogen, Aura, and Gaia can be used for implementing a wide range of context-aware
applications in many domains.
Since 2003, many of 3rd generation of context-aware systems have adopted semantic markup language
OWL as their ontology model so that they can insure better flexibility and share context information more
easily. Some systems started to focus on protecting privacy of users and achieving better performance and
scalability.
3. 1 1st Generation Context-Aware Systems
Since early 90s, many of earlier context-aware system researchers have developed location-based
service systems such as The Active Badge System[], Cyberguide[], Sumi[], Cheverst[].
They share common characteristics in that they provide information according to user’s current location.
In this period, many researchers focused on how to achieve user’s location. Many of the 1st generation
context-aware systems depend on specific domain such as call forwarding [], tour-guide[][], shopping
assistant[]. The components in these systems are often integrated into a single domain, and they can be
optimized by sacrificing the system’s flexibility and generality. Followings are the brief overviews of The
Active Badge Location System (location-aware system) and Cyberguide (domain specific context-aware
application)

The Active Badge Location System
Active Badge Location System is one of the representative location-aware systems. As explained above,
the system mainly focuses on how to achieve user’s location information. By using this system, the authors
present a call forwarding application which forwards phone calls to user’s nearest phone.
Active Badge Location system uses particularly designed tags, which emit unique identifications for
approximately a tenth of a second every 15 seconds. Sensor network installed in the building gathers the
signals from the tags that users hold, and a master station polls the sensors and makes context data
available to clients. The system supports for predefined operations (e.g. FIND, WITH, LOOK, NOTIFY,
HISTORY), and the command interpreter processes the operations requested by clients.

Cyberguide
Cyberguide is a tour-guide application which provides information, which may be useful for users,
based on user’s current location and time. To achieve user’s current location, Cyberguide combines two
mechanisms – GPS and IR sensors. The system has graphic user interface, which indicates user’s current
location on the map, and it keeps the history of places tourist have visited. Figure 5 shows the graphic
user interface of Cyberguide.
Figure 4 GUI of Cyberguide
3. 2 2nd Generation Context-Aware Systems
Although the 1st generation context-aware systems explained in the previous chapter consider only
limited types of context and focus on sensing context information, 2nd generation context-aware systems
focus on achieving more generality and supporting for various types of context information In addition,
context-aware frameworks that can be used for development of application in many domains started to be
introduced.
Budzik’s Watson Project[] shows an example that context information can be acquired without using
physical sensors. It uses user interactions between user and productivity application (e.g., word processors,
Web browsers, etc.) as context data.
One of early attempts of framework to support building context-aware applications is Context Toolkit[]
proposed by Dey and Abowd in 2001. Context Toolkit can support for various domains of context-aware
applications, and it provides context widgets that can be used as reusable software components for
accessing and interpreting context data while hiding details.
In 2002, Hofer proposed another early context-aware framework called Hydrogen [] that can deal with
various types context information. Context Toolkit and Hydrogen both are distributed architecture;
however, they have differences in that Context Toolkit uses a simple attribute-value tuple as context model
and Hydrogen uses Object-oriented context data model.
Roman’s Gaia Project[] in 2003 is different from other prior existing approaches in that it is similar to
traditional operating system. It consists of core services and a framework for building context-aware
applications and uses 4-ary predicates in DAML+OIL as its context data model.

Context Toolkit[]
Figure 5 Sample Configuration of Context Components
The Context Toolkit is one of the early attempts to developing a context-aware framework that aims to
develop reusable software components to make development of context aware applications easier,
inspired by the success of GUI development kits.
The Context Toolkit has a distributed architecture, but there needs to be a central discoverer that is
used for discovering available widgets, aggregators, interpreters. It uses attribute-value tuple as its context
data model, and stores context data and its history. The Context Toolkit provides a basic access control for
privacy protection of users by providing context ownership concept.
The Context Toolkit consists of context widgets, interpreters, and aggregators. Context Widgets are
distributed sensor units encapsulating the complexity of actual sensors from applications. They can be
used as reusable building blocks for context sensing. Context Interpreters interpret context information to
abstract low-level sensed information into high-level information to suit the expected needs. Context
Aggregators are responsible composing context information by subscribing to context information
provided by Context Widgets and Context Interpreter so that it can hide even more complexity about the
context.

Hydrogen[]
Figure 6 Overview of Hydrogen Framework
Hydrogen is an approach for another open and extensible framework to support context-awareness on
mobile devices. Hydrogen is similar to Context Toolkit in that the aim of Hydrogen is also providing
reusability of software components. It differentiates between a remote and a local context and allows
context sharing among devices so that sensed context information can be provided for more than the
device connected to the sensors. Hydrogen does not support for resource discovery and persistent storage
functionalities.
Hydrogen has a there layered architecture – Adaptor Layer, Management Layer, Application Layer. All
layers are located on one device, and there is no central server. Adaptor Layer is responsible for separating
context storing, sensing from other layers and provides the same context information to multiple
applications. Management layer is responsible for sharing context information with other devices using
peer to peer communication via WLAN, Bluetooth.
Hydrogen adapted object-oriented context model as its context model. Since the context model can
take advantage of inheritance, various context objects (e.g. Location Object, Device Object) can be
supported by inheriting the super class Context Object.

Gaia[]
Figure 7 Gaia Architecture
Gaia is an agent based ubiquitous software platform project which is aiming for providing user-centric,
resource-aware, multi-device, context-sensitive mobile services in active spaces, extending contextawareness to traditional operating system concept. Gaia coordinates heterogeneous software entities and
networked devices.
Gaia represents context data using 4-ary predicates in the format of Context (<Context Type>,
<Subject>, <Relater>, <Object>). Context Provider acquires context information from sensors or external
sources, and Synthesizer infers high-level context data from low-level context data. The inference is based
on predefined first order logic rules. (E.g. Context (Number of people, Room 2401, >, 4) AND Context
(Application, PowerPoint, is, Running) => Context (Social Activity, Room 2401, Is, Presentation))
In the Gaia system, Component Management Core manipulates creation, destruction, uploading of
components. As Gaia is an extension of traditional operating system to include context-awareness, Gaia
provides several kernel services in the system to support context-aware application in active spaces.
Especially, Presence Service identifies entities (E.g. application, service, device, and person) present in an
active space. Context File System incorporates context into the traditional file system so that Gaia can
store context information in repository. The file system attaches context to files and directories, so that
important data in current context can be easily retrieved. To adapt to their environment, applications can
query or register context information from Context Service.
Gaia does not focus on scalability in that Active Spaces are small sized and constrained environment,
and Gaia does not support for privacy protection.
3. 3 3rd Generation Context-Aware Systems
W3C announced the OWL (Web Ontology Language) in 2003. OWL is a semantic markup language
designed for the Semantic Web, but many context-aware systems adopted OWL as their context-model.
OWL is suitable to be used as context model, since it’s flexible, expressive, and suitable for knowledge
sharing. Since OWL is announced by W3C, Many of 3rd generation context-aware systems have adopted
ontology as their context-model (e.g. CoBrA, SOCAM, CoCA, etc). Some other systems in this generation
tend to focus on supporting for privacy protection (e.g. CoBrA, Context Fabric) and achieving acceptable
scalability and performance of the systems (e.g. Enhanced CoCA, SOCAM)
Chen’s CoBrA (Context-Broker Architecture, 2003)[] is an agent-based context-aware system and the
first context-aware system which uses OWL to model ontological context mode and privacy policy. In
CoBrA system, a centered resource-rich context broker maintains and manages the shared context data. It
is CoBrA’s strong point that it allows users to define privacy policy so that it can protect privacy of users.
SOCAM (Service-Oriented Context-Aware Middleware) by Gu (2004) is similar to CoBrA, because it also
aims to build a middleware for context-aware services and uses OWL to model its context model; however,
SOCAM adopted hierarchical approach for designing the context ontology. The ontology used in SOCAM
consists of upper ontology and domain-specific ontologies.
Although OWL seemed very suitable as context model and many systems adopted it, but it brought
new problems – scalability and performance of context-aware systems. In 2008, Ejigu proposed Enhanced
CoCA (Collaborative Context-Aware Service Platform) that combines ontology approach and relational
database approach to achieve achieves acceptable performance of system.
The Context Fabric proposed by Hong is context-aware system architecture primarily focusing on
privacy protection. The system provides supports for building privacy-sensitive context-aware applications
by letting users define privacy tags for each context tuple.

CoBrA[]
CoBrA(Context Broker Architecture)는 agent 기반의 아키텍쳐로써 intelligent space 내에서의 상황 인식
컴퓨팅을 가능하게
한다. Intelligent space 는
pervasive 서비스가 가능한 physical 한 공간이다.
CoBrA 시스템의 중앙에는 context broker 가 존재하여 기기들간의 공유된 상황 정보를 가지고 있으며
관리한다. 사용자가 들고있거나 입고있는 모바일 장치들이 agent 의 역할을 하게 되고 방안의 다양한
environment 들이 상황 정보에 반응하게 된다. CoBrA 는 크게 네가지 콤포넌트로 되어있다. – Context
Knowledge Base, Context Inference Engine, Context Acquisition Module, Privacy Management Module,
bottleneck 의 문제 해소를 위해 broker federation 을 제공한다. CoBrA 는 OWL 로 표현된 온톨로지에
기반한 상황 정보 모델을 사용한다. Inference Engine 은 Context Reasoning Module 을 가지고 있어서
상황정보를 Aggregate 하고 외부로부터 얻어낸 상황 정보로부터 추가 지식을 추론한다. Context
knowledge API 를 제공한다 – 상황 정보를 assert, delete, modify, query 할 수 있다. CoBrA 는 Rei 라는
이름의 flexible 한 privacy policy language 를 제공한다. 규칙 정의를 통한 상황 정보의 접근 권한의
유연한 제어가 가능하다.

SOCAM[]
SOCAM(Service-Oriented Context-Aware Middleware) 은 다양한 종류의 상황 인식 서비스 개발 및
프로토 타이핑을 가능하게 하는 framework 로써 centralized architecture 를 가진다. 중앙에 집중된 서버는
context interpreter 를 갖니고 있어서 다양한 상황 정보를 분산 환경으로부터 취득하여 추상화 하고
전처리하여 클라이언트에 넘긴다. 상황 인식 서비스는 SOCAM Architecture 의 최상위에서 동작하며
상황에 반응한 서비스를 제공한다. SOCAM 은 Service Locating Service 라고 불리우는 discovery
mechanism 을 가지고 있다. Context Provider 를 통해 상황 정보를 취득한다. SOCAM 은 OWL 로 표현된
온톨로지에 기반한 상황 정보 모델을 사용한다. 특히 SOCAM 은 상황 인식 도메인을 여러 개의
도메인으로 나누어 각 도메인에 low-level ontology 들을 정의함으로써 상황 정보 프로세싱 cost 를 줄인다.
Context Reasoning Engine 은 knowledge base 에 존재하는 정보에 대해 Reasoning 을 수행한다. 새로운
context 를 추론해 내고 consistency 를 보존한다. Jena 를 이용하여 구현되었으며. Rule 들을 명시할 수
있다.

Context Fabric[]
There are not so many existing context-aware systems which cares about the privacy of users, although
protecting user’s privacy is a very important issue.
Context Fabric 은 다른 시스템들과 다르게 사용자의 privay 보장에 초점을 맞추어 개발된 상황 인식
시스템이다. Confab 은 privacy-sensitive architecture 는 각 entity 의 상황 정보를 XML 형식의 튜플 형태로
infospace 에 저장 관리한다. Confab 은 프라이버시에 관한 추가적인 Operator 가 존재하여 inforspace 에
나오고 들어가는 튜플들의 Access control 을 수행한다. Confab 은 프라이버시에 많은 초점을 맞추고
있어서 나머지 requirement 들은 부족하다.

CoCA(2008)[][]
The objective in this work is to propose and investigate architecture for context-aware services focusing
on context reasoning in pervasive computing environment using semantic ontology and collaborative
approaches.
GCoM modeling deals with how context data is collected, organized, represented, stored and presented
CoCA service interprets and aggregates the low level context values to a more meaningful high level
context performs reasoning about the context and passes decisions about the actions to be triggered
stores knowledge and decisions corresponding to the context instance into knowledge repository for
future reference. Interface Manager Manages a UI and interface between the CoCA platform and other
modules Data Source Responsible to provide necessary data to the core service (GCoM)
Core Service Responsible to provide the core context aware service after reasoning on the components
Supplementary Service Knowledge discovery & Collaboration service Enhanced CoCA : a Collaborative
Context-Aware service platform HCoM : CoCA is based on Hybrid Context Management model
. Because current ontology engines cannot process computationally intensive high-level inferences,
researchers tried to handle this problem in many ways. SOCAM reduces the scale of context knowledge
and releases the burden of context data processing by separating upper ontology and domain-specific
ontologies.
. CoCA based on HCoM(Hybrid Context Management model). To achieve better performance, CoCA
uses ontology approach to manage context semantics and uses relational database approach to manage
context data. By combining these two approaches and loading only relevant data according to heuristics, it
4. Trend Analysis & Comparison
In summary, we find out that there is a tendency for previous researches to focus more on achieving
generality as time passes.
Most of earlier context definitions are defined as a set of example context types, but later definitions
are more general and wider. We can find the same tendency in the context-aware applications and context
models. Early systems use specific kinds of context such as location and are usually domain-specific
application systems, although later systems are usually general purpose context-aware systems that can
support various types of context. Context-aware systems tend to use simple context-data models (e.g.
attribute-value tuple) in earlier days, but later they use more complex context models (e.g. object-oriented
model, graph model). After W3C announces OWL, many systems adopt ontology as their context model.
Figure 1. Briefly summarizes the history of context-aware systems.
5. Conclusions
 Although there have been several attempts, we still need to work on “Privacy Protection”
“Performance & Scalability”
 Balancing Performance, Scalability & Intelligence is important
&
 Need to utilize historical data
 Add context-aware service layer to context-aware framework

Existing context-aware framework support context-aware application development

Service
–
A set of interaction between applications & entities(devices, context data, places,
people, and so on)

6. References
Service description storage, Historical service log