Marius Mikalsen Research Scientist, SINTEF ICT, Norway MCISME, Nara 09.05.06

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 09.05.06

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

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

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

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:

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

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 2 Select lest bad CP (from Huebscher) Figure 1 Select best CP available (from Huebscher)

8. Background – more system support Adaptation middleware: Dey, Capra, Huebscher ++: adapts adapts adaptable application adaptationmanager adaptable application Manages and provides context Manages and provides context contextmanager contextmanager

9. Background • Using Adaptation Enabling Middleware

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

11. Thesis • 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 need for context management component to handle context • Two main responsibilities in an adaptation enabling middleware: • Reduce number of unnecessary adaptations. • Separate context management concerns from adaptation reasoning

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

13. link component node Why is context information important? influencesuser needs mobile user neededservice quality uses service position light offeredservice quality noise adaptable application usercontext represented as monitors reconfigures architecture model configuration manager contextmanager monitors uses instructs adaptationmanager uses network QoS shareddevices battery selects application variant applicationvariant legend: execution context

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?

15. The context model

16. Context manager components

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)

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

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)

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

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