context-awareness and heterogeneity in pervasive computing environments

Context-awareness and Heterogeneity in Pervasive Computing Environments

Kashif Imran

Ravi Tiwari

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

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

Pervasive Computing Environments

Handheld Devices

Pervasive computing devices communicate and take actions.

Laptops

Atlas nodes

Network camera

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

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

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

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

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

Application Package

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.

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.

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.

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

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

Logical Data Model

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

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#*

External Interfaces

Context class offers two interfaces Synchronous requests (pull mode) Asynchronous notification (push mode)

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 knowncontext.getChildren(new Path("sys://storage/disks"));

//Returns the amount of memory currently availablecontext.resolve(new Path("sys://storage/memory#free"));

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 unpluggedcontext.register(myListener,RESOURCE_ADDED | RESOURCE_REMOVED,new Path("sys://devices/input/*"));

//Get notified when the room temperature goes beyond 30 Ccontext.registerExpression(aListener, CONDITION_OCCURED,"geo://location/room#temperature > 30");

Internal Design

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);}

Sensor Management

SensorManager class organizes all the sensors

Active sensors implement directly the Sensor interface and run in their

own threadpublic interface Sensor {

String getName();void setListener(SamplesListener listener);void start();void stop();boolean isStarted();}

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

Example Application

Network Heterogeneity in Pervasive App Environments Involvement of heterogeneous networks in

pervasive computing environments Infrastructure network, Ad-hoc network,

Sensor network

Example Scenarios

Forest Firefighting Group communication service Publish-subscribed service

Example Scenarios

Environmental informatics Data retrieval service Event service

Limitations of current middleware solutions Network-style centric Support individual network dependent

services (RPC, publish-subscribe etc) Static middleware services

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

Gridkit Architecture

Extensive services on top of overlay networks Overlay of overlays

Gridkit Architecture

Structure of Overlay Plug-in

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

Leveraging Facilitators

Deployment configurator Work for the nodes in the same overlay

Gridkit Deployment Service

Bridging Overlays

Conclusion

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

Qustions…

???