ICT 1 “Putting Context in Context: The Role and Design of Context Management in a Mobility and Adaptation Enabling Middleware” Marius Mikalsen Research Scientist, SINTEF ICT, Norway MCISME, Nara

ICT 2 NASA Challenges 934 million km away Signal takes 50 minutes to reach earth Interesting objects may pass without being noticed Need autonomous/adaptive space probes NASA and similar approaches to adaptation are characterized by tailored solutions which are high cost

ICT 3 Focus of this presentation Adaptation needed, also on earth, in mobile computing An approach for middleware support for the development of autonomous adaptive applications in the mobile domain (reduce costs and time to market) Differs from previous work in that it plays more active role in the adaptation process

ICT 4 Presentation outline Background Thesis Context management in an adaptation enabling middleware Evaluation Conclusion and future work

ICT 5 Background – need for adaptation Mobile applications need to adapt to changing requirements (at run-time) What is an adaptive application: Improve perceived performance by self-adapting to changing context (user and system) Example adaptations User Interface DB Proxy Satyanarayanan’s range of adaptations strategies:

ICT 6 Background – not enough system support Much context aware system research focus on high quality context delivery, but less focus on supporting the adaptation process itself

ICT 7 Background – some excellent context managers Dey’s Context Toolkit Context widgets, context interpreters, and context aggregators Capra’s Reflective Middleware Solution Reflective middleware using metadata Huebscher’s Adaptive Middleware Framework Quality of context, context (hyper) spaces, and learning Figure 1 Select best CP available (from Huebscher) Figure 2 Select lest bad CP (from Huebscher)

ICT 8 Background – more system support adaptable application adaptation manager context manager Manages and provides context adapts adaptable application context manager Manages and provides context adapts Dey, Capra, Huebscher ++: Adaptation middleware:

ICT 9 Background Using Adaptation Enabling Middleware

ICT 10 Background – context technology matures Redwine and Riddle’s six phases of technology popularisation (15-20 years): 1. Basic research 2. Concept formulation 3. Development and extension 4. Internal enhancement and exploration 5. External enhancement and exploration 6. Popularization  Weiser (1991): The ubiquitous computing paradigm

ICT 11 Thesis 1.Need tool support (such as adaptation enabling middleware) to reduce cost of building context aware adaptive systems 2.Utilising context information is essential to make such adaptation possible, and need for context management component to handle context 3.Two main responsibilities in an adaptation enabling middleware: Reduce number of unnecessary adaptations. Separate context management concerns from adaptation reasoning

ICT 12 Why do we need tool support? Tools simplify software evolution Simpler – separation of concerns (application and adaptation behavior) Tools improve scalability

ICT 13 Why is context information important? monitors influences user needs needed service quality offered service quality adaptable application user context network QoS shared devices battery execution context adaptation manager positionlight noise selects application variant uses mobile user uses service context manager monitors configuration manager uses instructs reconfigures architecture model node component legend : application variant link represented as

ICT 14 Context Manager’s responsibilities in the architecture Reduce number of unnecessary adaptations Only occur when necessary Notify of significant context change Separate context management concerns from adaptation reasoning... and what is our approach to achieve this?

ICT 15 The context model

ICT 16 Context manager components

ICT 17 Context repository Primary entry point for context clients and context sources Separate context management concerns from adaptation reasoning Tasks: Maintain context model Register and notify clients Enable plug-ins (reasoners and sensors)

ICT 18 Context sensor Context sensors sense low level or raw context information Example network sensor: Callback/call mechanism using the Birdstep MADAM Mobility API Provides access to key connectivity information such as available networks, signal strength and latency/bandwidth parameters Supports the following network adapters (non-exhaustive list): WLAN Ethernet GSM GPRS EDGE UMTS Bluetooth

ICT 19 Context reasoner Avoid unnecessary adaptations Input from two sources; adaptation manager and user, on what constitutes a significant context change Adaptation manager must communicate boundary conditions (e.g. bandwidth) Clear separation on what component reasons on what User in the loop Explicit – directives Implicit – feedback Overrides AM Example reasoning Artificial intelligence: Natural fit Challenges – context is elusive Case based reasoning QoC spaces (Huebscher)

ICT 20 Evaluation Two case examples to test performance Information service to support janitor inspections and a videostreaming application Also, two industrial pilot services with Condat and Integrasys Results: Defining architectural properties and utility functions need extensive tool support at design time The context management provides good support for accessing and identifying context elements and works well as a manager for context information Suggested improvements: Need reasoning libraries should be standardized rules in the framework as to how the user needs and preferences influence the relative importance of other context information (user must in the loop) should always be possible for the user to override context sensing, and explicitly state what is the (significant) context identified the need for more support for interoperability with third party context sensors

ICT 21 Conclusion Need tool support (such as adaptation enabling middleware) to reduce cost of building context aware adaptive systems Utilising context information is essential to make such adaptation possible and one need context management component to handle context Two main context operations that are needed in such a middleware: Reduce number of unnecessary adaptations. Separate context management concerns from adaptation reasoning Future work Evaluate and decide on suitable reasoning mechanism for avoiding unnecessary adaptations Integrating context information from different sources SOA Ontologies