Policy-driven Middleware for Personal Area Networks

1. Policy-driven Middleware for Personal Area Networks Neil Madhvani MEng in Information Systems Engineering Imperial College, London Supervisor Dr Naranker Dulay Second Marker Dr Emil Lupu

2. 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. 

3. 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. 

4. 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. 

5. Why can’t we do this today? • Multitude of electronic ‘pocket’ devices • A number of communications protocols for Personal Area Networks such as Bluetooth™ BUT… • 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  ‘Management Burden’ on the end user and subsequent frustration with the technology

6. 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.

7. 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?

8. The Self-Managed Cell (SMC) • Based on the AMUSE project (e-Healthcare) • A single asynchronous event bus for all communication

9. Policies for specifying behaviour • Policies are persistent rules. • We look at the two classical types of policies that form part of the Ponder language. Authorisation inst auth+ sendTextMessages { subject /users/children ; target /dev/cellular/phones ; action send_text_message(msg) ; when time.between(“0900”,”1900”) ; } Define which resources or services a subject can access. Enforced at target. Obligation 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” ; } Event-triggered condition-action rules, defining what a subject must or must not do.

10. 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 a SMC policy

11. 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

12. Grouping entities into domains • A hierarchical tree structure • Distributed or centraliseddomain system supported • A device can belong to one ormore domains – it is affectedby all the corresponding policies Mapping from device profiles to domains… phone /dev/phone pda  /dev/pda phone && pda  /dev/phone/smartphone Sample Ruleset profileString “phone;pda”  domain set {/dev/phone, /dev/pda, /dev/phone/smartphone}

13. A sample domain hierarchy

14. Policy Management Agents • 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 • Events only transmitted to PMAs who have subscribed to them • DSTC’s Elvin system used as the events engine in our implementation

15. 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

16. Serializable action objects • Encapsulation inside aserializable 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.

17. 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 { … whencontext(location) == “CINEMA” ; } Context data is obtained by PMAs using the getContextData(variable) event. The context system returns the data within a sendContextData(data) event.

18. Responding to a pattern of events For example, we may only want to carry out an action if we miss two consecutive calls and then get a text message… inst oblig myCorrelatedPolicy { onderived(“2 * missedCall -> textMsg”) ; subject /policies/derived ; doevent(urgentCall) ; } • 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

19. 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 }

20. 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

21. 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

22. 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

23. Thank You!