1. A Study of Context-Awareness - CASS, Hydrogen 2008. 7. 17 Context Team Summarized and Presented by Seungseok Kang

2. CASS (Context-awareness sub-structure) Middleware for Mobile Context-Aware Applications –Server-based middleware –Provides support for context-aware application on hand-held and other mobile devices –Supports high level context data abstraction –Overcomes the memory and processor constraints Small mobile computer platform –Separation of context based inference and behaviors from application code

3. Background High-level context information –Higher-level context abstraction makes it easier for application designer –The higher level of the context, the easier it should be use Requirements for context-aware mobile system –Supporting a large number of context sources –Provision for context history –Supporting for context interpretation –Supporting higher-level abstraction of contexts –Event-based extensible middleware –Supporting transparent use of distributed sources –Supporting the separation of application

4. Architecture CASS Middleware –Server-based middleware Does not suffer from the processor and memory constraints –Supports application in the use of local caching of information CASS application do not need to store low-level details of context sources CASS Design –RuleEngine –SensorListener : update and store context information –ContextRetriever : retrieve stored context –ChangeListener : listen for notification of context change events Data Management –Use database for persistent data storage Context, application, user data and domain knowledge –Data can be read and manipulated by SQL

5. Context Inference Mechanism Inference engine –Works in conjunction with separated knowledge base Represents knowledge in a more natural fashion Knowledge can be updated without changing the engine –Forward chaining Contexts lead to fewer higher-level contexts Knowledge base –Database tables with high-level context states and behavior Abstraction and search –Reducing the state-space of individual context components Ex) degrees of temperature -> Cold, Normal, Hot (context ontology)

6. Applications Developing some applications currently MALLET –“Maintenance assignment listing lightweight electronic tool” –Building maintenance to be organized in a context-aware way STONE –“Start on entrance” –Avoiding awkward start to presentations and lectures Ex) presenter can enable some preparations to happen automatically as soon as the presenter enters the presentation area (beam projector, presentation application, presentation file)

7. Sensors Works with sensors –Sensor-derived context management –Sensor failure –Sensor fusion Sensor software is extensible –To allow new types of sensors to be added

8. Hydrogen Context-awareness framework on mobile devices –Supports context-awareness for considering some constraints Network connections Limited computing power Characteristics of mobile users –Extensible framework to consider all kind of context information Related works –ContextToolkit –GeoNotes –CampusSpace –……

9. Background Context characteristics –Physical context Representing the level of environment sensors –Logical context Representing more abstract information Enrich the semantics of physical context information Requirements for an architecture of a framework to support context-awareness on mobile devices –Lightweightness – limited processing power –Extensibility – limited sensor extension –Robustness – network disconnection –Meta-information – controversial information between sensors –Context-Sharing – incomplete sensed context

10. Hydrogen Context-Framework Framework Architecture –Three layer Application layer Management layer –Providing and retrieving contexts and sharing context information with other devices using P2P communication Adaptor Layer –Separating context storing, sensing from other layers –Responsible to get information from sensors –Providing same context information to multiple applications –All application have access to all context data by querying the ContextServer –All layers are located on one device Robust against network disconnections

11. Implementation Prototypical implementation –PersonalJava, Jeode, J2ME, iPAQs, PocketPC 2002 –ContextClient Inter-layer communication with XML protocol Provides sending and listening data functionally

12. Implementation (cont.) Context –Includes the context of the location / remote devices –Time, Location, Device, User, Network –Other context can be specialized by ContextObjects ContextClient –Responsible for communication : open ports, queries data ContextServer –Java-executable object –Storing all information about the contexts –Two-way communication : XML streams / serialized java objects Adaptors and Applications –Simplify the communication between ContextClient and ContextServer

13. Impelemtation (cont.) Extending the framework –Covering new types of context Can be specialized by ContextObject –Two abstract methods toXML() : convert the values of object into an XML stream fromXML() : parsing the stream and filling into object Exemplary Applications –Context-aware postbox Delivering images and intelligent business card (text) to mobile devices and local desktop computer

14. Open Issues Comprehensive context model –Integration of comprehensive context models –W3C supports CC/PP (composite capabilities / preference profiles) XML protocol –ContextObjects can be converted into an XML representation Context can be processed by every application Context Sharing –Offering the opportunity to gain information about the context of other context-aware devices –Exchanging complementary context information between ContextServer by network –Security and reliability problem

15. Conclusion CASS –Server-based middleware –Context-aware application with high-level context abstraction –Context inferences separated from application –Configuration by users Hydrogen –Identifying the requirements for a context-aware architecture –Three-layer framework for context-awareness system –Feasible context architecture with XML –Extensible framework to consider all kind of context information

16. Evaluation of papers Pros –Moving context sensors to separate computers and allowing the sensors to communicate with the middleware allows any types of devices, with or without context sensing capabilities, to run context-aware applications –Because devices acquires context data from middleware, context data can be shared among multiple devices Cons –Only getting context related data may limit the possible application scenarios for context-aware services An application will be more interested in local temperature around the device, and not the temperature at some point where sensing node is deployed

17. And We Think…… Similarity between CASS and Hydrogen –Requirements for context-aware system on mobile devices –Separation of context management module from devices and applications Middleware (CASS), Layer architecture (Hydrogen) –Context modeling Definition of context dimensions High-level context abstraction Extensibility and feasibility of context information –Context sharing To overcome the incompleteness of sensed data So, we should consider about…… –The limitation of mobile device environment –Extensible definition of context dimensions –Separated and reusable modules in context-aware system –Proper algorithms of mechanisms for context-sharing

18. Appendix Gaia –A distributed middleware infrastructure that coordinates software entities and heterogeneous networked devices contained in a physical space –Exports services to query and utilize existing resources, to access and use current context, and provides a framework to develop user-centric, resource-aware, multi-device, context-sensitive, and mobile applications –GAIA architecture

19. Appendix (cont.) GAIA services –event service –context service –presence service –space repository –context file system Discussion –It is good to think ubiquitous computing environment like an operating system and give basic functionalities for applications. –But it is hard to determine what functionalities are needed for context aware applications. The authors suggest only basic functionality so that consideration about more functionalities is needed.