Context-addressed communication dispatch

1. Context-addressed communication dispatch Licentiate defense presentation Alisa Devlic 29May 2009

2. Introduction • Communication An essential part of life • Increasing globalization and user mobility  device-mediated communication: • Exploiting nearly constant connectivity by various types of mobile devices • Providing location-independent access to information and services • Contextdependent information and services Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

3. Mobile communication systems → IP based communications • cellular phones becoming mobile Internet devices • increasingly powerful • equipped with various sensors • Mobile device manufacturers • Focusing on mobile platform development • more intelligence in terminal • combining knowledge from the environment with mobile platforms APIs • to enhance people’s communication experience via context-aware applications and systems for communication Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

4. Problem statement • Context-addressed messaging & communication • How toaddress, route, and deliver a message/call to people based on their context?  Using context as an address • Context-aware session control • How to initiate communication among users based on matching of their preferences and current context?  Context-based session initiation • How to enhance session initiation decision making using context information?  Context-aware call signaling • How to adapt, modify, and manage a user’s communication sessions based on context?  Context-aware session management • While enabling a user to modify their preferences at any time, evenduring a communication session Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

5. Proposed system • Format for composing context addresses • Inner-routing of this message to correct recipient(s) • Context-aware call signaling • based on design of context switch • Context-based session initiation • based on match of users’ interests and context • Context-aware session management • based on design of context triggers Context operators Context distribution vs. context discovery (Bluetooth and WLAN evaluation of Battery power consumption) • SIP-based multicast • context distribution • group management • group queries Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

6. Context management Context any information that characterizes the situation of an entity Entity user, his/her currently used device, the network this device is connected to and the status of this connection, physical locations in the user’s surroundings, or nearby objects Entities are dependent and have these relations Context consists of a number of attributes that are known to application and used by an application to adapt its behavior. Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

7. Context discovery vs. distribution • Mobile devices move in & out of ranges of other devices and sensors • Challenge: discover, collect, and adapt to new context data • A device can share its context knowledge with other geographically distant devices – in advance of arriving at a new location • this can potentially reduce the delay or energy required by a device to adapt to a new environment • Cost of distribution: usefulness of context that is distributed in advance to peers vs. its time-dependent value Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

8. Context distribution methods Bluetooth Context Distribution WLAN Context Distribution Assumes each device has already discovered some context and stored it in a file • Propagate the list of discovered devices and services in a file to all discovered devices • Distribution of aggregated information  enables discovery of devices and services beyond single hop limit Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

9. Battery power evaluation results 3.2x more energy was consumed per bit by sending data over WLAN than over Bluetooth Distributing data over WLAN is more power efficient when number of recipients >3 Energy would increase with the number of discovered devices Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

10. Context middleware Context synthesis Context retrieval Context modeling Context distribution Context sensing Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

11. Context synthesis • Inferring high-level context information from the existing information using application-specific inference rules • Problem with rule-based reasoning: long delays experienced by end user waiting for result of a context query, especially when large data sets and rule sets are used • Proposed solution: Context operators • domain-specific functions over context data • synthesize information for a certain user, device, network, place, or other object • Reduced waiting time - achieved by: • finding and applying the relevant operator(s) to synthesize desired context information • finding the relevant operator – requires only the subclass ontology relationship from the whole ontology reasoning support • use of Beanshell scripts written in Java to perform operator functions • only the scripts that will be invoked are loaded into an interpreter Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

12. Context operators Operator model Operator space Repository of operators • proposed file structure – reduces the search effort of finding the relevant operators parsing smaller ontology files instead of one large ontology file • path to the operator description file programmatically constructed • Generic operators directly sub-classed from the class Operator • Specialized operators individual instances of generic operators Nameithe name of opi Ini a list of types of inputs that will be provided to opi Outi the type of output produced by opi Usesi a list of other (simpler) operators opi used in its execution Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

13. Operator matching Context query (step 1): InRange(”101”, 50, ModelConstants.Cyclist), where response time is bounded to 5 seconds Operator matching (steps 2 - 4) Specialized operator invocation (step 5) Operator matching algorithm determines the most appropriate specialized operator to invoke from the available (specialized) operators using a reasoning process (taking into account the required output type and supplied input types). result of a context query =output of the operator This is a synthesized context, since it was generated by context synthesis. This synthesized context can be shared among different applications (or even different context systems) in the same domain, using the same “functions” to synthesize context information and without being concerned about implementation of these functions. Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

14. Performance evaluation • This evaluation was part of MIDAS project, where all context information was available locally on a mobile device • Therefore, operator space had 3 additional specialized operators to retrieve context information: GetContext.bsh, GetClassContext.bsh, and GetInstanceContext.bsh • All performance tests were run on Nokia N800 with JamVM, Java 1.4 compiler, and Beanshell Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

15. Context-aware communication Specify call/message destinations based on target users’ context To which device should the call be redirected? Context space multiple context parameters sensed about the environment Sender addresses a call/message based on the receivers’ target context Receiver different communicationpreferences in different context spaces • Detect changes in the receiver’s context space • Adapt communication according to the receiver’s preferences in this context How can I specify on which device I want to be contacted in this context? Should the sender be informed about change in device or context? Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

16. Context-addressed messaging scenario Alice interested to receive local traffic information when commuting to her home or work in the car To receive Bob’s message Alice’s context must be: • activity=driving • direction=Sergels Torg • location=within Bob’s specified range Bob • currently driving, notices a traffic jam • composes and sends a message to: “all people driving towards and within 5km of SergelsTorg” not known in advance! Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

17. Requirements for context-addressed messaging • relevant message delivery • at least one recipient  1:N communication model • sender and recipients decoupled in space and time  asynchronous message delivery • receiver’s control over message delivery • receiver expressed interest in receiving messages on a particular topic • message delivery according to receiver’s preferences • timeliness, privacy, and scalability Extend RISP with context-based filtering at the receiver’s trusted entity Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

18. Common Profile for Context-Addressed Messaging (CPCAM) CAM URI = “cam:” [operators] operators = 1*(namespace “.” operator) operator = operator-name “(“ [output-type] “,” [input-types] “)” namespace = absoluteURI output-type = namespace “.” (operator / context-class) input-types = input-type * (“,” input-type) input-type = namespace “.” (operator / context-class “=“ input-value) context-class = alpha input-value = alpha Content-type: Message/CPCAM From: Bob <sip:bob@example.com> To: cam:operator1.And(operator2.DrivingTo(context.User, context.Location="Sergels torg"), operator3.InRange(context.User, context.Location="Sergels torg", context.Range="5000")) DateTime: 2009-01-24T21:40:00+01:00 Subject: traffic jam at Sergels torg NS: operator1 <http://www.example.com/models/operators/And/And.man>, operator2 <http://www.example.com/models/operators/DrivingTo/DrivingTo.man>, operator3 <http://www.example.com/models/operators/InRange/InRange.man>, context <http://www.example.com/models/context.man>  Content-type: text/plain; charset=utf-8 Content-ID: <12345667890@example.com>  There is a developing traffic jam at Sergels torg! Encapsulated in SIP PUBLISH message with traffic topic’s AoR and Content-type=“message/CPCAM” Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

19. Context-based filtering • determines if the message is relevant to receiver before delivering it to his/her device • routing of messages within the user’s infrastructure – protects the user’s privacy • inner routing – inserting context-addressed message in the body of SIP message and utilizing context matching to find suitable recipients • routing decisions at the receiver’s trusted entity – increases system scalability • Address resolution • performed after receiving SIP NOTIFY • operator matching to find the correct • specialized operator • generic and specialized operators • should be part of service offering • additional updates of spec. operators • through website, example: • http://www.example.com/operators/DrivingTo/UsersDrivingTo.bsh Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

20. Context-addressed messaging mechanism Bob To: "All people driving toward and within 5 km from Sergels torg interested in traffic info" Subject: traffic jam at Sergels torg Body: There is a developing traffic jam at Sergels torg! Alice Subscribe to: traffic info Current context: location=Kungstradgården, activity=driving Preferences: current location based traffic info Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

21. Sender’s infrastructure Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

22. Receiver’s infrastructure Application and sensor device configuration Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

23. SIP network infrastructure Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

24. SIP operations for context-addressed messaging Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

25. Context distribution 5. SIP SUBSCRIBE (sip:slussen.temperature@example.com, xcap-diff) 3. SIP REGISTER (sip:A@example.com) 4. HTTP GET (slussen.temperature@example.com) Resource list | null 6. SIP NOTIFY (sip:A@example.com) 8. SIP NOTIFY (sip:A@example.com, added D) 2. HTTP PUT (sip:C@example.com; entity=slussen;scope=temperature) 1. SIP REGISTER (sip:C@example.com) Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

26. Context distribution 5. SIP SUBSCRIBE (sip:slussen.temperature@example.com) 9. SIP NOTIFY (sip:A@example.com, aggregated context) 6. SIP NOTIFY (sip:A@example.com) 7. SIP SUBSCRIBE (sip:D@example.com; entity=slussen;scope=temperature) 8. SIP NOTIFY (sip:example.com) 8. SIP NOTIFY (sip:example.com) 7. SIP SUBSCRIBE (sip:C@example.com; entity=slussen;scope=temperature) Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

27. Context-aware session control • Context update can trigger an action: • finding people with the same interest or current context • initiate communication with them • adapt a user’s communication sessions • subscribe to a different type of content • In case of incoming communication event: • context can assist in decision making about how to process this event on behalf of a user Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

28. Context-based call signaling Context-based CPL (Call Processing Language) script <?xml version=“1.0” encoding=“UTF-8”> <!DOCTYPE cpl SYSTEM ‘context.dtd’> <cpl> <incoming> <context-switch owner=“jim”> <user_context location=“grimeton” task=“meeting” activity=“presenting”> <reject status=“Reject” reason=“In major meeting presenting”/> </user_context> </context-switch> </incoming> </cpl> Call decision making criteria Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

29. CPL-based context trigger Implicit permission to insert some of its private context into a group query • Activated by arrival of SIP NOTIFY message • Context parameters: • user’s location, task, activity • device’s bandwidth and battery • A group query is sent as a SIP MESSAGE to a list of user’s contacts • using resource list URI Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

30. Communication initiated by a preference match Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

31. Context-addressed messaging Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

32. Context-aware CPL scripts <context-CPL> <valid-rules> <!-- call decision rule3 --> </valid-rules> <context-node> <context condition1> <!— call decision rule1/--> </context condition1> <context condition2> <!—call decision rule3/--> <!—action2/--> </context condition2> <otherwise> <!--action4/> </otherwise> </context-node> </context-CPL> SIP NOTIFY (context update) Action 2 Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

33. Related work • Distributed location infrastructure • Spreitzer and Theimer’s Ubiquitous Message Delivery (1993) • Dey at al.’s Context-Aware Mailing List (2002) • Content-based publish/subscribe mechanisms • Carzaniga et al.’s content-based addressing and routing (2000) • Variations of multicast • Lee’s Xcast (2008), Ko’s and Vaidya’s Geocast (2002) • Restricted flooding & ontology-based reasoning • Domaszewicz’s context-addressed messaging & routing (2008) • Similarity-based profile matching • Hsu, Dutta, and Helmy’s Profile-Cast (2008) • Preference rule-based reasoning • Miller’s Contextual Information Service (2002) Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

34. Related work • Systems developed by groups (1) and (2) • risks of revealing users location information to unintended parties • broker – able to learn sender and receiver’s identities and to inspect sent and received subscriptions and publish messages • Our design decision • keep processing of context within the user’s infrastructure • context-based filtering at the receiver’s trusted entity • the only address that the broker learns • Systems developed by groups (3), (4), (5), and (6) • Lack of receiver’s control to receive messages of interest • Inability to express preferences in content or message delivery • Our design decision • topic-based publish/subscribe system and context-based filtering • Group (4): timeliness, unreliable, and privacy issues Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

35. Conclusions Context-addressed communication dispatch – main components: • Context-addressed messaging • Common Profile for Context-Addressed Messages (CPCAM) • novel format able to use any high-level context to compose context address • Inner-routing of context-addressed messages • context-addressed messages inserted into the body of SIP messages • context-based filtering of received messages at the receiver’s trusted proxy • Context-aware message delivery • to the receiver’s preferred device using his/her preferred communication means • Context-aware session control • Initiation of communication sessions among users • based on match of their preferences and/or current context, taking their social relationship into account • group queries • Adapt and modify user’s communication sessions & subscribe to desired content • based upon users context-dependent preferences and relevant context updates • All context-aware communication • can be implemented using context switch and context trigger (context-based CPL extensions) • Context management • Context discovery vs. distribution – battery power evaluation (BT & WLAN) • Context synthesis using context operators • Context distribution using SIP-based multicast and group management Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

36. Future work • System implementation and performance evaluation • Open issues • Expressing user context-dependent preferences • Importing some preferences from existing social networks • Prioritization of importance of preferences • Specification of topics for publish/subscribe system • Anonymizing sender’s identity • Should it always anonymize? When and when not? • Can we allow responder to be anonymous? • How should reply messages be configured in that case? • Context management • How to perform and control all activities in a distributed manner? • Context modeling schema - part of system delivery? • Find the bottleneck of the context synthesis performance • Introduce caching of decisions made by operator matching for a query • How to deal with uncertainty and highly-volatile context data? Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

37. Open issues • Learning of user’s unspecified preferences • How to deliver messages for which the receiver was not subscribed to, but could be potentially interested to receive? • Should we invent some new mechanism for subscribing to undefined topic (similar to use of wildcards)? • Once the user feedback is obtained, new preference will cause the proxy to: • create a new topic and subscribe to it • or unsubscribe to this topic and create a new negative preference instead • How should the user provide this feedback to the system? How to incorporate this feedback into the learning process? • Where should the learning take place? • How will the observed behavior be logged, by which component, how often will it be analyzed, and by which methods/tools? • Can the user specify when it should not be logged and under which conditions? How to enable a user to specify such conditions? • How is the usability of the system related to the learning curve and the amount of a priori knowledge inserted into the system? • What are the risks of an unexpected, emergent behavior of the system and how to deal with it? Introduction → Background → Context management → CAM → Context-aware session control → Conclusions