A survey on context-aware systems
by Baldauf et al.
Hyunjong Cho
Computer Science Department,
University of Maryland, College Park
Table of Contents
• Context-aware systems Basics
– Context-aware systems
– Definition of Context
– Classification of Context
– Classification of Architecture
– Abstract Layer Architecture
– Context Models
• Existent context-aware systems
Context-aware systems
• Are able to adapt their operations to the
current context without explicit user
intervention
• Aim at increasing usability and effectiveness
by taking environmental context into account
Definition of Context
•
•
•
•
•
•
Location, identities of nearby people and objects and changes to those objects
(1994)
The user’s location, the environment, the identity and the time (1997)
The user’s emotional state, focus of attention, location and orientation, data and
time, objects and people in the user’s environment, user preferences, patterns,
calendar, team structure (1998)
The aspects of the current situation
The elements of the user’s environment that the computer knows about
Any information that can be used to characterize the situation of entities (i.e.
whether a person, place or object) that are considered relevant to the interaction
between a user and an application, including the user and the application
themselves [DeyAbowd2000]
Classification of Context
• External (physical)
– measured by hardware sensors
– Ex) location, light, sound, movement, touch, temperature,
air pressure, etc.
• Internal (logical)
– specified by the user or captured monitoring the user’s
interaction
– Ex) the user’s goal, tasks, work context, business processes,
the use’s emotional state, etc.
Classification of Architecture
- by the context acquisition method
• Direct sensor access
– Tightly coupled
– No extensibility
• Middleware
– Hiding low-level sensing details
– Extensible
• Context server
– Permit multiple clients access to remote data sources
– Relieve clients of resource intensive operations
– Has to consider appropriate protocols, network performance, quality
of service parameters
Challenges
• Context is most useful in dynamic, mobile environments. But
what is the relevant information in various situations?
• Mobility results in continuous updates of context information.
How can we efficiently manage this?
• How can we share context?
• How do we handle uncertainty of context information?
• How do we ensure privacy control and management of
context information?
• How do we reach a common understanding of implications
and semantics of (shared) context information?
• Resource restrictions
• Connectivity - devices/services
7
Applications
• Tourist Guides & Navigation Systems
– Disney World [Pascoe, 1997]
– Atlanta [Abowd et a., 1997]
– Exhibits [Sumi et al, 1998]
• Office Awareness Systems
– User Tracking [Xerox Parctab]
• Tagging Systems
– Fieldwork data collection [Pascoe]
– Stick-e notes [Pascoe]
Conceptual framework
application
storage/management
preprocessing
raw data retrieval
sensors
Abstract Layer Architecture (cont’d)
• Sensors
– Physical sensors
• light, camera, microphone, accelerometer, GPS, thermometer, biosensors
– Virtual sensors
• From software: browsing an electronic calendar, a travel booking system,
emails, mouse movements, keyboard input
– Logical sensors
• Combination of physical and virtual sensors with additional information
from databases: analyzing logins at desktop pcs and a database mapping
fixed devices to location information
• Raw data retrieval
– Drivers for physical sensors, APIs for virtual and logical sensors
– Query functionality (ex: getPosition())
– Exchangeable (ex: getPosition() for both GPS and RFID)
Abstract Layer Architecture (cont’d)
•
Preprocessing
– responsible for reasoning and interpreting
– Aggregation or compositing
• from single sensor values to context information
• Ex) time + location + audio -> meeting@office
– Ex) not the exact GPS coordinations of a person, but the name of the city
•
Storage/Management
– interface to the client/application
•
Applications
– Actual reaction on different events and context-instances is implemented
– gain access to the storage/management layer in two ways
• Synchronous (pull/polling) and asynchronous (push/subscription)
Context Models
• define and store context data in a machine processable form
– Key-Value models
– Markup scheme models
– Graphical models
– Object oriented models
– Ontology based models
• requirements for ontology model
–
–
–
–
Simplicity
Flexibility and extensibility
Genericity
Expressiveness
Existent context-aware frameworks
• 8 Context-aware frameworks
–
–
–
–
–
–
–
Architecture
Resource Discovery
Sensing
Context Model
Context Processing
Historical context data
Security and Privacy
Architecture:
Context Managing Framework
• Centralized Context Manager
• Pros
– Overcome memory and
processor constraints of
small mobile devices
• Cons
– One single point of failure
Architecture:
CASS (Context-awareness sub-structure)
• Centralized middleware approach
• Local caching on the client side
Architecture:Hydrogen
• Specializing in mobile devices
– All architecture located on the
same device
• Remote context and local context
– Context sharing In a P2P
manner
• Object oriented approach
– Superclass ContextObject
Architecture:Hydrogen
•
All located on the same device
•
Context Server
– Synchronous and asynchronous methods
•
All inter-layer communication is based on a XML-protocol
Architecture: CORTEX
•
Context-aware middleware approach
•
Architecture is based on the Sentient Object Model
•
Supports a graphical development tool for building sentient objects
– Specify relevant sensors and actuators
– Specify context hierarchy and production rules
– no need to write any code
Architecture:Gaia
• Middleware infrastructure
– Gaia extends typical OS concepts to include
context-awareness
Architecture:
Etc.
• SOCAM (Service-oriented Context-Aware Middleware)
– Centralized context interpreter
• CoBrA (Context Broker Architecture)
– Agent based architecture
– (Centralized) context broker
• Context Knowledge Base, Context Inference Engine, Context Acquisition
Module, Privacy Management Module
– Broker federations
• Context Toolkit
– Peer-to-peer architecture, still needs a centralized discoverer
• Distributed sensor units (widgets), interpreters and aggregators
– Object-oriented API: super class BaseObject
Resource Discovery
• Discoverer [Context Toolkit]
– A white page lookup (via names)
– A yellow page lookup (via attributes)
• Service locating service [SOCAM]
• Registry component [Gaia]
• Cf) pure p2p context-aware system only uses
local built-in sensors [Hydrogen]
Sensing
• “The separation of acquisition and use of
context”
– Context Widgets [Context Toolkit]
– Sensor nodes [CASS]
– Context providers [SOCAM]
– Resource servers [Context Managing Framework]
– Context acquisition components [CoBrA]
Context Model
• Attribute-value-tuples [Context Toolkit]
• Object-oriented context model [Hydrogen]
• Ontologies [SOCAM, CoBrA, Context Managing
Framework]
• 4 predicates [Gaia]
– (<ContextType>, <Subject>, <Relator>, <Object>)
– Used for both representing context and forming inference
rules
Context Processing
•
Context aggregators, context interpreters [Context Toolkit]
•
Resource servers, context manager, context recognition services [Context
Managing Framework]
•
Context Reasoning Engine [SOCAM]
•
Inference Engine [CoBrA]
•
Inference engine and knowledge base [CASS]
•
Sentient Objects [CORTEX]
•
Context Service Module [Gaia]
– First order logic: quantification, implication, conjunction, disjunction, and
negation
•
Cf) leave the higher-level abstraction for the applications’ layer [Hydrogen,
Owl]
Historical context data
• A centralized high-resource storage
component is needed
– Database, SQL [Context Toolkit, CoBrA, CASS,
SOCAM, CORTEX, Owl]
– Context Knowledge Base [CoBrA, CASS]
• No persistent storage due to limited memory
resources [Hydrogen]
Security and Privacy
• Context ownership [Context Toolkit]
– Mediated Widgets, Owner Permissions, a
modified BaseObject and Authenticators
• Role Based Access Control (RBAC) [Owl]
• Rei, an own flexible policy language [CoBrA]
End
Context-aware systems: A literature
review and classification
by Hong et al.
Hyunjong Cho
Computer Science Department,
University of Maryland, College Park
about this paper..
• reviews 237 journal papers published in 2000
to 2007
– methodology extract the literature
– general characteristics of the literature research
• draws abstract architecture of context-aware
systems
• classifies papers based on the architecture
• suggests some possible future research
agenda
abstract architecture
future research agenda
• how to extract and use the context?
– external context
• retrieved directly from sensors
• Ex) location, distance, temperature, audio, lighting, …
– internal context
• provide personalized services according to user
preferences
• Ex) help decision making, music suggestions, …
future research agenda
• which is the best inferring algorithm?
– infer accurate context of user
– recommend suitable service
• based on the gathered contexts above
• consider not only external context, but also internal
context Ex) user profile such as sex, age, style, ..
– figure out causal relationships between contexts
and recommendations
• by using probabilistic logic, fuzzy logic, SVM, …
future research agenda
• how to deal with enormous data with
different data type, formats, abstraction level?
– various contexts from various sensors
• different unit and scale, element
– no comprehensive research
future research agenda
• how to manage the conflict between contexts?
– sensing conflict: conflicts between physical sensor
context
• Ex) outdoor from audio sensor, but indoor from light
sensor
– service resource conflict: only several users among
many are provided with updated context
– user preference conflict: same contexts for the
same user, but different choice
future research agenda
• privacy and security, system evaluations, ..
End