An Architecture to Support Context-Aware Applications

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

2. Introduction • What is Context? • 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 • 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 • 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 Context Architecture Sensor

12. Context Widgets • Attributes • 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 • 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 a.Subscribe Gregory in Room 343 Location Widget Base Object Base Object Application Handle Sensor d.Callback delivered to a handler b.Sensor Data arrives c.Callback if data Matches Gregory in 343:

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