A survey on context-aware systemsby 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

7

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

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

sensors

raw data retrieval

preprocessing

storage/management

application

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