Policy-driven Middleware for Personal Area Networks

Neil Madhvani

Supervisor Dr Naranker Dulay

Second Marker Dr Emil Lupu

MEng in Information Systems EngineeringImperial College, London

What if... (1)From…

Whilst listening to his MP3 player, Bob often misses several important phone calls, since he is unable to hear his phone ring.

To…

Bob is listening to music on his MP3 player and a call comes in – the music automatically pauses and he hears a message announcing the phone number of the person calling him. Once the call is over, his MP3 player resumes playback.

What if... (2)From…

Bob uses the appointments feature on his PDA which sounds an alarm 15 minutes in advance of each event. However as he keeps his PDA in his bag, he often fails to hear the alarm.

To…

When Bob’s PDA sounds an alarm, his digital watch (which doesn’t hold any data on appointments) also does the same. Whilst the watch cannot display alphanumeric characters, it alerts Bob to pick his PDA up for further details.

What if... (3)From…

As an avid movie lover, Bob regularly visits the cinema. However he almost always forgets to switch his phone on to a silent mode, and this often causes him embarrassment.

To…

When Bob comes within proximity of a cinema, his phone automatically switches to a silent mode – he no longer needs to worry about doing this himself. When he leaves the cinema, his phone returns to an audible ring mode.

Why can’t we do this today? Multitude of electronic ‘pocket’ devices A number of communications protocols for

Personal Area Networks such as Bluetooth™

An inability to specify rules to determine how devices should behave in response to changes in state of other devices

A lack of standards for device capabilities

BUT…

‘Management Burden’ on the end user and subsequent frustration with the technology

Our Key Objectives To design a set of middleware to allow devices

within a Personal Area Network to be managed in a co-ordinated manner via the definition of a set of rules governing behaviour.

Minimise input needed from end users.

To enable devices to respond not only to change in state of other devices, but also of the surrounding environment.

Open up a new range of exciting opportunities and paradigms that were previously infeasible.

Issues to be considered

Most devices have limited battery life

Mobility – devices tend to move in and out of proximity of each other on a regular basis

Grouping ‘similar’ devices together

What are the key management services that need to exist and how should these interact with one another?

The Self-Managed Cell (SMC)

Based on the AMUSE project (e-Healthcare) A single asynchronous event bus for all

communication

Policies for specifying behaviour

inst auth+ sendTextMessages { subject /users/children ; target /dev/cellular/phones ; action send_text_message(msg) ; when time.between(“0900”,”1900”) ; }

inst oblig muteMusicOnPhoneCall { on incomingCellularCall(callerID) ; subject s = /dev/cellular/phones/Manager ; target t = /dev/music ; do t.mute() -> t.playCallerID(callerID) ; when t.profile != “do not disturb” ; }

Authorisation

Obligation

Define which resources or services a subject canaccess. Enforced at target.

Event-triggered condition-action rules, defining what a subject must or must not do.

Policies are persistent rules. We look at the two classical types of policies that

form part of the Ponder language.

Our use of policies Based on obligation policies when conditions based on:

Event Target device Contextual data

System vs user policies Derived event policies SMC (Configuration) policies

inst config discoveryServer { pollInterval 10000 ; -- in milliseconds timeToLive 5000 ; -- in milliseconds maxRetries 3 ;}

An example of aSMC policy

Discovering devices Ping/pong mechanism – periodic whoIsAlive()

responded to by iAmAlive(deviceID, profileString) Discard device data if maxRetries count exceeded Events generated to indicate new and lost devices

newDevice(deviceID, profileString) lostDevice(deviceID)

Stored for each device:

- deviceID

- connectedSince

- numRetriesLeft

Grouping entities into domains A hierarchical tree structure Distributed or centralised

domain system supported A device can belong to one or

more domains – it is affectedby all the corresponding policies

phone /dev/phonepda /dev/pdaphone && pda /dev/phone/smartphone

Mapping from device profiles to domains…

Sample Ruleset

profileString “phone;pda” domain set {/dev/phone, /dev/pda, /dev/phone/smartphone}

A sample domain hierarchy

Events system: ‘One-shot’ paradigm rather than request/reply

Each PMA runs as a separate thread with its own mailbox

PMAs subscribe to events they are interested in

Policy Management Agents

Events only transmitted to PMAs who have subscribed to them

DSTC’s Elvin system used as the events engine in our implementation

Efficiency through quenching Devices only send an event onto the bus if there are

one or more consumers listening for it Reduce unnecessary network traffic Works via ‘reverse subscriptions’ that devices make

to the events engine upon startup Quench events inform devices about subscription

changes

Functionality provided to all devices in our implementation via the abstract DeviceAdapter class

Serializable action objects Encapsulation inside a

serializable object: conditions to test on device action(s) to perform on device

Each domain managed by a Domain Management Agent (DMA) – a thread

DMA passes action object to devices and propagates to the DMAs of any sub-domains

In our implementation, the action object is serialized into a byte stream by the PMA, sent within an event and is deserialized at each of the devices, before being processed.

Handling contextual data Examples are time, location, temperature. Raw vs processed data Abstracting low-level concepts (e.g. location co-

ordinates) to higher-level ones (e.g. “HOME”, “WORK”, “CINEMA”)

Maintenance of a ‘context store’ – periodic recalculation of data

inst oblig myPolicy { … when context(location) == “CINEMA” ; }

Context data is obtained by PMAs using the getContextData(variable) event. The context system returns the data within a sendContextData(data) event.

Responding to a pattern of events

Our model is based on a state-machine approach The correlation engine performs state transitions

for individual events and generates a correlated event if reaching the end state

inst oblig myCorrelatedPolicy { on derived(“2 * missedCall -> textMsg”) ; subject /policies/derived ; do event(urgentCall) ; }

For example, we may only want to carry out an action if we miss two consecutive calls and then get a text message…

Prototype & Demonstration ‘Proof of concept’ system built using Java iPAQ h5550 running JeodeRuntime PersonalJava

1.2 – a limited subset of the J2SE 1.1 API Elvin Router running on a laptop as a Windows

service – no specific PDA support at present

inst oblig muteMusicOnPhoneCall { on e = incomingCallReceived() ; subject /policies/system/audio ; target t = /devices/musicplayers ; do t.muteAudio() t.muted = true ;}

inst oblig resumeMusicAfterPhoneCall { on e = callHangup() ; subject /policies/system/audio ; target t = /devices/musicplayers ; do t.resumeAudio() t.muted = false ; when t.muted }

Recommendations for future prototyping work...

Additional devices, e.g. several more iPAQs Use of other platforms such as .NET CF or Symbian

OS to allow better control of hardware Integration with devices that can provide

contextual data, e.g. location

Our contributions A new approach and application domain Proposed extensions to the Ponder

language A model for event correlation Event quenching Encapsulation of actions in serializable

objects Multi-threaded architecture Design of a middleware and corresponding

prototype

Future Work Cells as building blocks – composing SMCs

into larger structures and peer-to-peer interactions between SMCs

Policy compilation Security & trust issues Conflict detection & resolution

Thank You!