Context-awareness and Heterogeneity in Pervasive Computing Environments

1. Context-awareness and Heterogeneity in Pervasive Computing Environments Kashif Imran Ravi Tiwari

2. Overview • Pervasive computing • Requirements for ubiquitous and adaptive collaboration • Middleware to provide heterogeneity and context-awareness in pervasive computing environments • Model for adaptive collaborative mechanisms in heterogeneous environments • A generic framework for context-awareness • Middleware providing network heterogeneity

3. Pervasive Computing • Computing appliances seemly integrated into our lives, providing any time anywhere information. • Vision of digital life style • Early work at Palo Alto Research Center • Intelligent doorknobs to toilet-paper holders

4. Handheld Devices Network camera Atlas nodes Laptops Pervasive Computing Environments Pervasive computing devices communicate and take actions.

5. Requirements for ubiquitous and adaptive collaboration • Dynamic application adaptation to contextual changes, such as changes in users’ interest, location, communication bandwidth etc • Platform-independent application descriptions to support multiple platform deployment • Heterogeneous service and device discovery • Support of heterogeneous data formats e.g. by not sending a high quality video stream to a low resolution screen

6. Role of Middleware • To analyze the role of middleware in context-aware application development for heterogeneous pervasive environments. • Application adaptation to multiple platforms • Networked, heterogeneous devices • Interoperability among heterogeneous networks

7. Middleware for heterogeneous context-aware applications • Kernel Runner, KR • Application Package, AP • Application Repository, AR • Configuration Repository, CR • Resource Repository, RR • Context sensor, CS • Mobility and Configuration Manager, MCM • Context Manager, CM

8. Kernel Runner • Responsible for mobility and adaptation of apps • Enables loading, execution, updating and stopping of the applications or components • Composed of three elements • The Interface • Application Cache • ExistApp, UploadApp • Execution Engine • StartExecution, StopExecution, CheckRunning and OnlineReloadParameters

9. Application Package • Facilitates the distribution of the applications through the different nodes • The AP is an XML file with two kinds of information • Configuration parameters • Application executables • Separates the application files from the execution parameters achieving platform independent description of application • Able to send all the running files needed in an XML formatted file, to extract and launch them in the different KRs

10. Application Package

11. Other Components • Application repository, AR • An application repository on the network • Stores each application developed as XML file • SearchApp, DownloadApp, UploadAdd • There can be many AR in a network • Configuration repository, CR • Similar to the AR, the CR holds information in XML file format related with the application configurations • Resource repository, RR • Holds information in XML file format on music, photos, videos, etc. and information can be served online to an external component.

12. Other Components • Context sensor, CS • components that inform of the state of the environment and any changes to the same • Mobility and configuration manager, MCM • responsible for the discovery and control of the different KRs on the network • has the ability to move, launch, or stop the applications in the different KRs • moves the correct version of application from the AR to the KR along with required configuration file with the • application’s last execution parameters from the CR • Context Manager, CM • On context change the CM uses its inference system to decide what action it must perform.

13. Comparison with OSGi • Intermediary between different bundles • Bundles provide service to other bundles • OSGi limitation: Interoperability is ensured in the same machine between different bundles. It does not ensure correct running of different bundles in an open, distributed system using different devices such as PC, PDA, smartphones etc. • AP can be launched without partner AP.

14. WILDCAT • Generic framework to ease the development of context-aware applications • Provides dynamic model to represent application’s execution context • Facilitates the acquisition and aggregation of contextual data to create reusable objects to represent aspects of execution context relevant to many applications

15. Logical Data Model • Context class • Facade of whole system from client’s view • One instance per application • Context is made of several domains • Sys: local hardware, net: topology, geo: geophysical info (location, temperature..), user: preference (activity, mood..) • ContextDomain • Object representing each domain of context • Tree of named resources each being described by attributes (simple key/value pair) • Separates different aspects of execution context and allow custom implementation

16. Logical Data Model

17. Logical Data Model • Events • Each change occurring in the context model is represented by an event • RESOURCE_ADDED • RESOURCE_REMOVED • ATTRIBUTE_ADDED • ATTRIBUTE_REMOVED • ATTRIBUTE_CHANGED • EXPRESSION_CHANGED • CONDITION_OCCURED

18. Logical Data Model • Addressing • URI inspired syntax to denote elements • A resource • sys://storage/memory • An attribute • sys://storage/disks/hda#removable • Input devices • Sys://devices/input/* • Mouse attributes • sys://devices/input/mouse#*

19. External Interfaces • Context class offers two interfaces • Synchronous requests (pull mode) • Asynchronous notification (push mode)

20. Synchronous requests (pull mode) public class Context { String[] getDomains(); Path[] getChildren(Path res); Path[] getAttributes(Path res); boolean exists(Path path); Object resolve(Path attr); } //Returns the list of all disk drives currently known context.getChildren(new Path("sys://storage/disks")); //Returns the amount of memory currently available context.resolve(new Path("sys://storage/memory#free"));

21. Asynchronous notification (push mode) public class Context { long register(ContextListener listener, int eventKinds, Path pp); long registerExpression(ContextListener listener, int eventKinds, String expr); void unregister(long regId); } //Get notified each time a new input device is plugged or unplugged context.register(myListener, RESOURCE_ADDED | RESOURCE_REMOVED, new Path("sys://devices/input/*")); //Get notified when the room temperature goes beyond 30 C context.registerExpression(aListener, CONDITION_OCCURED, "geo://location/room#temperature > 30");

22. Internal Design

23. The ContextDomain interface public interface ContextDomain { void initialize(Context ctx); String getName(); boolean exists(Path path); Object resolve(Path attr); Path[] getAttributes(Path res); Path[] getChildren(Path res); void register(ContextListener listener, int eventKinds, Path path); void unregister(ContextListener listener, int eventKinds, Path path); void update(Path path, Path cause); }

24. Sensor Management • SensorManager class • organizes all the sensors • Active sensors • implement directly the Sensor interface and run in their own thread public interface Sensor { String getName(); void setListener(SamplesListener listener); void start(); void stop(); boolean isStarted(); }

25. Sensor Management • Passive sensors • created by associating a Sampler and a Schedule to create a SamplingSensor public interface Sampler { SampleSet sample(); } • XMLCommandSensor class • Make it easier to integrate WildCAT with existing systems

26. Example Application

27. Network Heterogeneity in Pervasive App Environments • Involvement of heterogeneous networks in pervasive computing environments • Infrastructure network, Ad-hoc network, Sensor network

28. Example Scenarios • Forest Firefighting • Group communication service • Publish-subscribed service

29. Example Scenarios • Environmental informatics • Data retrieval service • Event service

30. Limitations of current middleware solutions • Network-style centric • Support individual network dependent services (RPC, publish-subscribe etc) • Static middleware services

31. Gridkit Middleware • Addresses two key requirements within the pervasive application domain • Service deployment • Suitable middleware service for developers • Dynamic reconfiguration • Adapt to changing network heterogeneity

32. Gridkit Architecture • Extensive services on top of overlay networks • Overlay of overlays

33. Gridkit Architecture

34. Structure of Overlay Plug-in

35. Deployment and Reconfiguration of Middleware Services • Policy-based deployment of middleware services • Appropriate stack of software on each node • Roles of a node: Participant or Facilitator

36. Leveraging Facilitators • Deployment configurator • Work for the nodes in the same overlay

37. Gridkit Deployment Service

38. Bridging Overlays

39. Conclusion • Middleware can ease the development of context-aware applications and provide transparency in heterogeneous pervasive computing environments

40. Qustions… ???