1. An Architecture to Support Context-Aware Applications
Anind K.Dey
Daniel Salber
Gregory D. Abowd
May 1999.

2. Introduction What is Context? Context Aware Applications Information
Application’s operating environment
Sensed by the application
Actions based on current state
Context Aware Applications
Use context to provide task-relevant information and/or services.
eg.tour guide, conference assistant, context-aware mailing lists, Dynamic Ubiquitous Mobile Meeting Board (DUMMBO).

3. Problems with using context
Lack of standard architecture
Ad-hoc design, very little reusability
Acquired from non-standard sources
Abstraction to provide meaning to application
Dynamic

4. Context Handling Direct Hardwiring of Context Using Servers
Code to handle sensor details embedded in application
Bulky applications
Loss of generality, difficult to reuse or use by multiple applications
Using Servers
Polls sensor network
Maintains current location information
Abstracts details of sensors from application
Multiple applications
Applications must be proactive
Each server offers a different interface

5. Widget Software component State Behavior
Provides access to context information
Hide complexity of actual sensor network used
Abstract context information according to need
Provide reusable and customizable building blocks
State
Set of attributes that can be queried by an application
eg. Location, identity
Behavior
Responds to changes in environment
Provides callbacks to applications registered with it

6. Differences from GUI widgets
Distributed Architecture
3 components viz.
Generators – acquire context information
Interpreters – abstract information
Servers – Aggregate information
Active all the time
Activation not driven by other applications

7. Distribution of context sensing network
Remote context sensing devices
Eg. Indoor infrared positioning system
Multiple applications use same context information
Heterogeneous platforms for collecting context
Interoperability of context widgets and applications.

8. Context Abstraction Need for interpretation to make context usable
Transparency of low-level layers needed
Extension of existing mechanisms
Aggregation – Applications need to connect to only one component for each entity
Aggregation Improved maintainability and efficiency

9. Persistence and History
Independent execution of context widgets
Persistence required at all times
Maintenance of history necessary
Storage of history on applications not possible always

10. Architecture Requirements
Requirements summary
Allow applications to access context information from distributed machines in the same was that input information is accessed
Support execution on different platforms and the use of different programming languages
Support for the interpretation of context information
Support for the aggregation of context information
Support for independence and persistence of context widgets
Support for storage of context history

11. Architecture Application Server Interpreter Interpreter Widget Widget
Sensor
Sensor
Context
Architecture

12. Context Widgets Attributes Callbacks Methods
Interface provided to other components
Accessed via polling and subscribing
Callbacks
Events used to notify subscribing components
Methods
sendToSubscribers() – notifies concerned subscribers about change in context state
store() – stores historical data for future reference (mechanism can be modified)

13. Context Server
Single point of access/subscription to all widgets of interest – proxy behavior
Further separation, simpler design
In/Out
Board
Building
Aggregations
Location
Widget
Location
Widget
ID to Name
Interpreter
Face
Recognition
Smart Card
Reader

14. Context Interpreter In/Out Board
Convert or interpret context to higher level of information and representation
Context not available for appropriate level
In/Out Board
ID to name interpreter
Location Widget
Location Widget
Face Recognition
Smart Card Reader

15. Callback Model Transparent communications, always available Location
a.Subscribe Gregory
in Room 343
Location
Widget
Base
Object
Base
Object
Application
Handle
Sensor
b.Sensor Data
arrives
c.Callback if data
Matches
Gregory in 343:
d.Callback delivered
to a handler

16. Conference Assistant Application Recommender/ Interpreter Presentation
Server
User
Server
Question
Widget
Content
Widget
Location
Widget
Memo
Widget
Registration
Widget

17. Applications In/Out Board Serendipitous Meetings/Whiteboard Aware home
Conference Assistant

18. Conclusions
Context …
Enables context-aware applications to build smart environments
Treats context like user input
Makes it easer for applications to deal with context
Provides reusable solutions(widgets) for context handling
Achieves separation of concerns between context-sensing and application semantics