Context-addressed communication dispatch

Context-addressed communication dispatch

Licentiate defense presentation

Alisa Devlic

29 May 2009

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

• Context dependent information and services

Introduction → Background → Context management → CAM → Context-aware session control → Conclusions

Slide 2 of 36

• 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


Slide 3 of 36

Problem statement• Context-addressed messaging & communication

– How to address, 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, even during a communication session


Slide 4 of 36

Proposed system

SIP-based multicast• context distribution• group management• group queries

• 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)


Slide 5 of 36

Context managementContext any information that characterizes the situation of an entityEntity 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

Context model

Person Place

ObjectDevice

Network

currentDevice relatesTo

Thing

locatedIn

locatedIn

relatesTo

Applications

Middleware

Knowledge environment(context discovery, aggregation, synthesizing, storage)

Sensor1 Sensor2 SensornSensor3 . . . . . . .

Communication and dissemination

<applications used as sensors>

<applications use context information>

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.


Slide 6 of 36

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


Slide 7 of 36

Context distribution methodsBluetooth Context Distribution

PANBluetooth

application

1. Propagate the list of discovered devices and services in a file to all discovered devices

2. Distribution of aggregated information

enables discovery of devices and services beyond single hop limit

WLAN Context Distribution

Server

Send merged file to clients Send merged file to clients

Client

Listen to discoverPeers messages

Timeout -Message(s)

arrived? Multicast discoverPeers message

Sends peerReply message and a file Waits for peerReply and a file

Timeout -Message(s)

arrived?Merges received file into existing one

Yes

Yes

Start

End

Battery ran out

Any state

No

No

Waits for merged file

Assumes each device has already discovered some context and stored it in a file


Slide 8 of 36

Battery power evaluation results

n

iFTi

n

ioffFTioffFTFTFT

FT

iiiiTsizefileIUIU

sbitratedatatransferfileWPbitJbitdatauserdtransferreperEnergy

11

)_(**

/___/_____

HP iPAQ 4150 Bluetooth WLAN

Energy_per_transferred_user_data_bit 481.7nJ/bit 1.56µJ/bit

Energy_per_received_user_data_bit discovery of 2 devices & services (approx. 2.7kB of data, 1.5J)

1.33µJ/bit

n

ii

n

iRMFoffRMFioffRMFRMFRMF

RMF

sizefilereceived

TIUIU

bitsizefilereceivedJEbitJbitdatauserreceivedperEnergy

iiii

1

1

__

***

__/_____

Energy would increase with the number of discovered devices

3.2x more energy was consumed per bit by sending data over WLAN than over Bluetooth

Distributing data over WLANis more power efficient when number of recipients >3


Slide 9 of 36

Context middleware

Context distribution

Context sensing

Context modeling

Context retrieval

Context synthesis


Slide 10 of 36

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


Slide 11 of 36

Context operators

i

ii

iiiii

iii

n

OutInFop

UsesOutInnameopopopop

nopopop

typeofoutputtypeofinputsimplimpl

,,,descimpl,desc

,,...,,Οp 21

Namei the 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

InRange.manIndividual: CyclistsInRange

Types: InRangeFacts:

hasName CyclistsInRangehasInputType CyclisthasOutputType Cyclistuses DistanceBetweenXYZLocations


Slide 12 of 36

Operator modelGeneric operators

operators/

InRange/

DistanceBetween/

CyclistsInRange.bsh

InRange.man

DistanceBetween.man

DistanceBetweenXYZLocations.bsh

Specialized operators

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

Operator space

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.


Slide 13 of 36

Operator matching

Performance evaluationAverage response times with varying number of specialized operators (i.e., 1, 2, 5, 10)

Based on 10 first queries

Standard deviation (based on 10 first queries)

Based on 10 subsequent queries

Standard deviation(based on 10 subsequent queries)

Matching algorithm time 2.49 sec 0.009 sec 1.94 sec 0.07 sec

Loading specialized & root scripts time 1.7 sec 0.087 sec No average, for the

first time only (1.7 sec) No standard deviation

Total operator matching time 4.2 sec 0.087 sec 1.94 sec 0.07 sec

Context retrieval time 0.37 sec 0.006 sec 0.09 sec 0.001 sec

Loading dependency scripts time 0.15 sec 0.001 sec 0.17 sec 0.015 sec

Operator invocation time 0.67 sec 0.008 sec 0.36 sec 0.04 sec

Total query time 5.4 sec 0.045 sec 2.57 sec 0.07 sec

• 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


Slide 14 of 36

To which device should the call be redirected?

Context-aware communication

Context space multiple context parameters sensed about the environmentSender addresses a call/message based on the receivers’ target contextReceiver different communication preferences in different context spaces

» Detect changes in the receiver’s context space » Adapt communication according to the receiver’s preferences in this context

Sender uses smart phone to initiate communication with a Receiver

Context spacei Network infrastructure

Call/messageSmart phone

Receiver1’s available devices

Receivern’s available devices

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?


Slide 15 of 36

Specify call/message destinations based on target users’ context

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 Sergels Torg”

not known in advance!


Slide 16 of 36

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

Context-addressed message requirements

Message delivery modesSender-push Receiver-pull Sender-Intent-

based-Receiver-Pull (SIRP)

Receiver-Intent-based-Sender-Push (RISP)

1:N communication + X X +

Receiver's control over message delivery

X + + +/-

Asynchronous model

+ X +/- +

Extend RISP with context-based filtering at the receiver’s trusted entity


Slide 17 of 36

Common Profile for Context-Addressed Messaging (CPCAM)

Content-type: Message/CPCAMFrom: Bob <sip:[email protected]> 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:00Subject: traffic jam at Sergels torgNS: 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-8Content-ID: <[email protected]>

There is a developing traffic jam at Sergels torg!

Encapsulated in SIP PUBLISH message with traffic topic’s AoR and Content-type=“message/CPCAM”

CAM URI = “cam:” [operators]operators = 1*(namespace “.” operator)operator = operator-name “(“ [output-type] “,” [input-types] “)”namespace = absoluteURIoutput-type = namespace “.” (operator / context-class)input-types = input-type * (“,” input-type)input-type = namespace “.” (operator / context-class “=“ input-value)context-class = alphainput-value = alpha


Slide 18 of 36

sip:[email protected]

http://www.example.com/models/operators/DrivingTo/DrivingTo.man

http://www.example.com/models/operators/InRange/InRange.man

http://www.example.com/models/context.man

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

Matching context address with recipient’s context

Filtering out unwanted messages

Learning unspecified preferences

Delivering relevant messages

Context updates

Preferences management

Context based address

Communication adaptation

Feedback link


Slide 19 of 36

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

http://www.example.com/operators/DrivingTo/UsersDrivingTo.bsh

Context-addressed messaging mechanismBob To: "All people driving toward and within 5 km from Sergels torg interested in traffic info"Subject: traffic jam at Sergels torgBody: There is a developing traffic jam at Sergels torg!

Alice Subscribe to: traffic infoCurrent context: location=Kungstradgården, activity=drivingPreferences: current location based traffic info


Slide 20 of 36

Sender’s infrastructureSender’s infrastructure

Sender’s trusted entity

Context spacejContext spacei

Smart phone

Anonymizer

Message publisher

Sender’s trusted entity

1. Context-addressed message

2. Anonymous sender address

Reply message handler

Network infrastructure

Receivers

Context spacek

Smart phone

5. Message reply

Sender

Broker

3. Publish (message, topic)

0. Subscribe (topic)

4. Notify (message)


Slide 21 of 36

Receiver’s infrastructure


Slide 22 of 36

Application and sensor device configuration

Receiver1’s infrastructure

Sender

Context spacei

Network infrastructure

Smart phone Receiver’s trusted

entity

Context-based filtering

Context provider

raw context data

4. Subscribe (topic)

2. Subscribe (context)

5. publish (message, topic)

6. Notify (message)

7. Compute high-level receiver’s context

3. Notify (context)

Broker

Communication dispatcher1

9. Ensure message delivery

Context updates

Operator matching

8. Adapt (message, device, comm.means)

1. Context-dependent preferencesPreferences

management

SIP network infrastructure


Slide 23 of 36

SIP operations for context-addressed messaging


Slide 24 of 36


DB

2. HTTP PUT (sip:[email protected]; entity=slussen;scope=temperature)

3. SIP REGISTER (sip:[email protected])

4. HTTP GET ([email protected])

6. SIP NOTIFY(sip:[email protected])

5. SIP SUBSCRIBE (sip:[email protected], xcap-diff)

8. SIP NOTIFY(sip:[email protected], added D)Resource

list |

null

1. SIP REGISTER (sip:[email protected])


Slide 25 of 36


DB

5. SIP SUBSCRIBE (sip:[email protected])

8. SIP NOTIFY(sip:example.com)

6. SIP NOTIFY(sip:[email protected])

7. SIP SUBSCRIBE (sip:[email protected];entity=slussen;scope=temperature)

7. SIP SUBSCRIBE (sip:[email protected]; entity=slussen;scope=temperature)

8. SIP NOTIFY(sip:example.com)

9. SIP NOTIFY(sip:[email protected], aggregated context)


Slide 26 of 36

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

Context trigger

Context update

Action

Context switch

Incoming event

Action

Current contextPreference

set

Introduction → Background → Context management → CAM → Context-aware session control → ConclusionsSlide 27 of 36

Context-based call signaling

SER(extended CPL-C

module)SIP UA

Callredirect

reject

mail

proxy

Context repository CPL repository

Match

CPL script uploadstore context values

CPL

MySQL

Wrapper

store/retrieve context values

store/retrieve CPL script

accept

Client application

select CPL scriptselect ontology

0

0.002

0.004

0.006

0.008

0.01

0.012

0.014

1 2 3 4 5

Number of switches

Resp

onse

tim

e [s

]

Address-switch

Context-switch

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 → ConclusionsSlide 28 of 36

CPL-based context trigger

• 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

Implicit permission to insert some of its private context into a group query


Slide 29 of 36

Communication initiated by a preference match


Slide 30 of 36

Context-addressed messagingAlice's context

providerBrokerTed's trusted proxyTed Ted's context

providerAlice's

trusted proxy

Context-addressed message (friends, biking, location range 5 km)

Query (location)

Ted's location

Alice

Add Ted’s anonymous address

to the message

PUBLISH (message, biking)

Context-dependent preferences

Subscribe to Alice's activity

Context update (free time) Current

preference (interest for biking)

SUBSCRIBE (biking)

NOTIFY (message)

Context-based filtering1 (message,

current context)

Deliver message

Message reply

Message reply

Allow message reply

Context trigger

Context switch

Add location info to the message


Slide 31 of 36

Context-aware CPL scripts


Slide 32 of 36

SIP NOTIFY (context update)

<context-CPL> <valid-rules>  </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>

Action 2

Related work1. Distributed location infrastructure

• Spreitzer and Theimer’s Ubiquitous Message Delivery (1993)• Dey at al.’s Context-Aware Mailing List (2002)

2. Content-based publish/subscribe mechanisms• Carzaniga et al.’s content-based addressing and routing (2000)

3. Variations of multicast • Lee’s Xcast (2008), Ko’s and Vaidya’s Geocast (2002)

4. Restricted flooding & ontology-based reasoning• Domaszewicz’s context-addressed messaging & routing (2008)

5. Similarity-based profile matching• Hsu, Dutta, and Helmy’s Profile-Cast (2008)

6. Preference rule-based reasoning• Miller’s Contextual Information Service (2002)


Slide 33 of 36

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


Slide 34 of 36

ConclusionsContext-addressed communication dispatch – main components:

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

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

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


Slide 35 of 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?


Slide 36 of 36

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:a) create a new topic and subscribe to itb) 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?


Slide 37 of 36

Documents

Context-addressed communication dispatch