Ubiquitous Communications

1
Ubiquitous Communications

• Henning Schulzrinne
• (with Knarig Arabshian, Stefan Berger, Stelios
  Sidiroglou, Kundan Singh, Xiaotao Wu, Weibin Zhao
  and the RPIDS authors)
• Columbia University IRT Lab
• Univ. of Pennsylvania February 2004

2
Overview

• What is ubiquitous computing?
• Core ubiquitous communications functionality
• Brief introduction to SIP
• Ubiquitous computing in SIP and SLP
• On-going work at Columbia

3
What is ubiquitous computing?

• Ubiquitous computing has as its goal the
  enhancing computer use by making many computers
  available throughout the physical environment,
  but making them effectively invisible to the
  user. (Weiser, 1993)
• Ubiquitous computing is not virtual reality, it
  is not a Personal Digital Assistant (PDA) such as
  Apple's Newton, it is not a personal or intimate
  computer with agents doing your bidding. Unlike
  virtual reality, ubiquitous computing endeavers
  to integrate information displays into the
  everyday physical world. It considers the nuances
  of the real world to be wonderful, and aims only
  to augment them. (Weiser, 1993)

4
Ubiquitous computing aspects

• Also related to pervasive computing
• Mobility, but not just cell phones
• Computation and communications
• Integration of devices
• borrow capabilities found in the environment ?
  composition into logical devices
• seamless mobility ? session mobility
• adaptation to local capabilities
• environment senses instead of explicit user
  interaction
• from small dumb devices to PCs
• light switches and smart wallpaper

5
Components of ubiquitous communications

• Service discovery ? discover devices
• Service mobility ? configuration information
  moves to new devices
• Event notification ? for context awareness
• Context-awareness ? location, user actions,
  location properties,

6
Example ubicomp projects

• Ambient Devices
• EU IST Disappearing Computer
• Project Aura, CMU ? user attention
• UNC office of real soon now
• augmented surfaces Reki99
• Microsoft Easy Living
• Oxygen, MIT
• Portolano, Univ. of Washington
• Endeavour, Berkeley
• CoolTown, HP Labs

7
Ubiquitous computing using SIP whats different?

• Traditionally, focus on closed environments (lab,
  single company, home, )
• Often, proprietary protocols ? self-contained
  environment
• Here,
• operate across Internet (? no Corba)
• trusted, semi-trusted and untrusted participants
• use standard protocol mechanisms where possible
• make minimal assumptions on homogeneity
• respect user privacy

8
Context-aware communications

• Traditional emphasis communicate anywhere,
  anytime, any media ? largely possible today
• New challenge tailor reachability
• Context-aware communications
• modify when, how, where to be reached
• ? machine context-dependent call routing
• ? human convey as part of call for human usage
• context-aware services
• leveraging local resources
• awareness of other users
• sources of location information
• voluntary and automatic
• location-based services ? privacy concerns
• applies to other personal information
• activity, reachability, capabilities, bio sensor
  data,
• emergency services as a location-based service

9
Context

• context the interrelated conditions in which
  something exists or occurs
• anything known about the participants in the
  (potential) communication relationship
• both at caller and callee

time CPL
capabilities caller preferences
location location-based call routing location events
activity/availability presence
sensor data (mood, bio) not yet, but similar in many aspects to location data
10
What is SIP?

• Session Initiation Protocol ? protocol that
  establishes, manages (multimedia) sessions
• also used for IM, presence event notification
• uses SDP to describe multimedia sessions
• Developed at Columbia U. (with others)
• Standardized by IETF, 3GPP (for 3G wireless),
  PacketCable
• About 60 companies produce SIP products
• Microsofts Windows Messenger (4.7) includes SIP

11
Basic SIP message flow
12
SIP trapezoid
13
SIP event notification

• Named events
• Typically, used for events within conferences
  (Alice joined) and call legs (e.g., call
  transfer)
• Supports arbitrary notification bodies, typically
  XML

SUBSCRIBE sipalice_at_vmail.example.com SIP/2.0 To
ltsipalice_at_example.comgt From ltsipalice_at_example.c
omgttag78923 Call-Id 1349882_at_alice-phone.example
.com Contact ltsipalice_at_alice-phone.example.comgt
NOTIFY sipalice_at_alice-phone.example.com
SIP/2.0 Event message-summary Subscription-Stat
e active Messages-Waiting yes Message-Account
sipalice_at_vmail.example.com Voice-Message 2/8
(0/2)
14
SIP event architecture

• Does not try to route notifications (application
  layer multicast) as in SIENA
• Filtering at PA under discussion (for
  low-bandwidth devices)
• rate
• content
• But most ubicomp notification groups are probably
  small
• and message volume not likely to provide much
  bandwidth saving via network-based filtering
• Greatly simplifies trust model no intermediaries
  that need to inspect content
• can encrypt via S/MIME
• However, can build redistribution exploders and
  list subscriptions (subscribe to
  engineering_at_hp.com)

15
SIP presence architecture
REGISTER
SUBSCRIBE
watcher
PA
Alice
NOTIFY
Bob
lt?xml version"1.0" encoding"UTF-8"?gt ltppresence
xmlnsp"urn" entity"presalice_at_example
.com"gt ltptuple id"sg89ae"gt ltpstatusgt
ltpbasicgtopenlt/pbasicgt lt/pstatusgt
ltpcontactgttel09012345678lt/pcontactgt lt/ptuplegt
lt/ppresencegt
PUAs
PUBLISH
16
Session mobility

• Walk into office, switch from cell phone to desk
  phone
• call transfer problem ? SIP REFER
• related problem split session across end devices
• e.g., wall display desk phone PC for
  collaborative application
• assume devices (or stand-ins) are SIP-enabled
• third-party call control

17
Session mobility via 3PCC
pc42
INVITE speakerphone maudio cpc42
192.0.2.1
INVITE pc42 mvideo c192.0.2.7 maudio c192.0.2.
1
INVITE display mvideo cpc42
192.0.2.7
18
How to find services?

• Two complementary developments
• smaller devices carried on user instead of
  stationary devices
• devices that can be time-shared
• large plasma displays
• projector
• hi-res cameras
• echo-canceling speaker systems
• wide-area network access
• Need to discover services in local environment
• SLP (Service Location Protocol) allows querying
  for services
• find all color displays with at least XGA
  resolution
• slp//example.com/SrvRqst?public?typeprinter
• SLP in multicast mode
• SLP in DA mode
• Need to discover services before getting to
  environment
• is there a camera in the meeting room?
• SLP extension find remote DA via DNS SRV

19
Service Location Protocol (SLP)

• Version 2 standardized June 1999

SrvRqst
SA
UA
SA
SrvRply
SrvReg
DA
SrvReg
SrvRqst
DAAdvert
20
SLP attribute example
URL serviceprinterlpr//igore.wco.ftp.com/draft
scope-list Development
Language tag en
Attributes (NameIgore),(DescriptionFor developers only), (ProtocolLPR),(location-description12th floor), (OperatorJames Dornan \3cdornan_at_monster\3e), (media-sizena-letter),(resolutionres-600),x-OK
21
Other service location mechanism

• DNS SRV/NAPTR
• DNS TXT records (Apple Rendezvous) ? DNS-SD
• UPnP uses SSDP
• multicast HTTP over UDP

M-SEARCH HTTP/1.1 S uuidijklmnop-7dec-11d0-a76
5-00a0c91e6bf6 Host 239.255.255.250reservedSSDPp
ort Man "ssdpdiscover ST gefridge MX
3 HTTP/1.1 200 OK S uuidijklmnop-7dec-11d0-a765
-00a0c91e6bf6 Ext Cache-Control no-cache"Ext",
max-age 5000 ST gefridge USN
uuidabcdefgh-7dec-11d0-a765-00a0c91e6bf6 AL
ltblenderixlgtlthttp//foo/bargt
22
Service mobility

• Allow access to service parameters anywhere
  payphone problem
• address book
• incoming call rules
• source name (SIP From)
• Existing solutions
• SIM card ? cumbersome to change
• synchronization (e.g., Palm) ? not suitable for
  borrowed devices
• Server-based services ? easier with SIP
  (service-routing), if carrier allows
• Emerging solutions for SIP systems
• Small user token (smart card, RFID, i-button)
  identifying user
• Temporarily download configuration from home
  server

23
Context-based communication services

• Observable state and actions
• State
• location of users
• user activities
• Derive state from
• sensors (time, location, environment, user
  interaction)
• data (calendars, address books)
• network inputs (messages)
• Actions
• incoming and outgoing calls
• incoming and outgoing IMs, SMS, email,
• Initially, focusing on location at key context

24
Location-based services

• Finding services based on location
• physical services (stores, restaurants, ATMs, )
• electronic services (media I/O, printer, display,
  )
• not covered here
• Using location to improve (network) services
• communication
• incoming communications changes based on where I
  am
• configuration
• devices in room adapt to their current users
• awareness
• others are (selectively) made aware of my
  location
• security
• proximity grants temporary access
• Privacy rules for access to context data

25
Location-based services

• Presence-based approach
• UA publishes location to presence agent (PA)
• becomes part of general user context
• other users (human and machines) subscribe to
  context
• call handling and direction
• location-based anycast (anybody in the room)
• location-based service directory
• Languages for location-based services
• building on experience with our XML-based service
  creation languages
• CPL for user-location services
• LESS for end system services

26
Location-based SIP services

• Services
• Location-aware call routing
• do not forward call if time at callee location
  is 11 pm, 8 am
• only forward time-for-lunch if destination is on
  campus
• contact nearest emergency call center
• do not ring phone if Im in a theater
• send delivery_at_pizza.com to nearest branch
• Location-based events
• subscribe to locations, not people
• Alice has entered the meeting room
• subscriber may be device in room ? our lab stereo
  changes CDs for each person that enters the room
• Person location events
• Were implementing SIP, caller-preferences and
  CPL extensions for these services

27
Locations

• Geographic location
• latitude, longitude, altitude, velocity, heading
• Civil location (? postal location!)
• time zone, street address, city
• some countries are a bit difficult
• Categorical
• office, library, theater, hospital,
• Behavioral
• public location, don't expect privacy
• silence is encouraged, don't ring the phone

28
Determining locations

• SIP entities are often far away from physical
  user or his current network (intentionally)
• For many devices, cant afford hardware to
  determine location
• different precision requirements
• in Fayette County (within driving distance of
  service or person)
• on campus
• in room 815
• in corner, talking to Bob
• GPS doesnt work indoors, but Assisted GPS
  (A-GPS) may
• Use location beacons BlueTooth, 802.11
• may not offer network connectivity
• see our 7DS project offer local content
  location
• Physically close by network entities
• DHCP (same broadcast domain)
• PPP (tail circuit)
• Not always true with VPNs, but end system knows
  that its using a VPN

29
Determining location

• Two types of sensors
• end system determines location
• handset-based ? GPS, 802.11 triangulation
• network conveys location to end system or other
  component
• MAC backtracking
• AP-based 802.11 triangulation
• swipe cards, iButtons, active badges
• Two modes
• explicit user action swipe card, touch iButton
• involuntary network-based tracking
• GPS may not be practical (cost, power, topology)
• Add location beacons
• extrapolate based on distance moved
• odometer, pedometer, time-since-sighting
• idea meet other mobile location beacons
• estimate location based on third-party
  information

30
Determining locations

• For many devices, cant afford hardware to
  determine location
• Implementing BlueTooth-based location sensor
  networks
• CU 7DS project offer local content location
• Developing programmable active badges with IR and
  RF capabilities

31
DHCP for locations

• modified dhcpd (ISC) to generate location
  information
• use MAC address backtracing to get location
  information

32
Location-based services SIP

• Were using SIP (and SIMPLE) as generic protocols
  for
• effecting change (actuators)
• send MESSAGE to devices
• distributing event information (sensors)
• Advantages
• people and rooms identified by URIs
• siphgs_at_cs.columbia.edu
• sipcepsr815_at_cs.columbia.edu
• cross-domain, with extensive security mechanisms
• domains dont need to trust each other
• scalable to global system
• many other systems are mostly local

33
Architectures for (geo) information access

• Claim all using protocols fall into one of these
  categories
• Presence or event notification
• circuit-switched model
• subscription binary decision
• Messaging
• email, SMS
• basically, event notification without (explicit)
  subscription
• but often out-of-band subscription (mailing list)
• Request-response
• RPC, HTTP also DNS, LDAP
• typically, already has session-level access
  control (if any at all)
• Presence is superset of other two

34
SIP URIs for locations
location beacon

• Identify confined locations by a SIP URI, e.g.,
  siprm815_at_cs.columbia.edu
• Register all users or devices in room
• Allows geographic anycast reach any party in the
  room

siprm815
Contact bob
Contact alice
Room 815
35
RPID rich presence data

• Basic IETF presence (CPIM) only gives you
• contact information (SIP, tel URI)
• priority
• open or closed
• Want to use presence to guide communications

watcher
everything
PA
PUA
watcher
"vague"
PUBLISH
watcher
NOTIFY
CPL
INVITE
36
Aside SIP caller preferences

• SIP core philosophy many devices, one identifier
• Address people, not plastic

37
Aside SIP caller preferences

• But caller sometimes has preferences among
  devices
• SIP caller guides call routing
• I hate voicemail!
• I hate people!
• I prefer voicemail
• Multilingual lines
• Caller proposes, callee disposes

sipisabel_at_a.comlanguages"es" sipisabel_at_a.coml
anguages"en"q0.2
INVITE sipsales_at_a.com Accept-Contact
languages"en"
REGISTER
INVITE
sipbob_at_a.comlanguages"en"
38
RPID Rich presence data

• Integrates caller preferences information into
  presence announcements
• ltactivitygt on-the-phone, away, appointment,
  holiday, meal, meeting, steering, in-transit,
  travel, vacation, busy, permanent-absence
• ltplacetypegt home, office, public
• ltprivacygt public, private, quiet
• ltspheregt facet of life (home, work, )
• ltidlegt activity for device
• ltrelationshipgt family, associate, assistant,
  supervisor
• ltclassgt grouping

39
Event filtering

• Events are core attribute of ubiquitous computing
  systems
• tell devices about people actions
• tell people about device presence
• e.g., Alice has entered Room 815
• devices that know Alices preferences subscribe
  to Alice
• locations may also have presence
• e.g., for occupancy sensors, switches

40
Location filtering language

• SIP presence information will be updated using
  REGISTER and UPDATE
• Need to constrain
• who is allowed to see what detail ? presentity
  privacy
• who wants to see what detail
• how often
• what granularity of change
• Proposal to allow SUBSCRIBE to include frequency
  limitation
• Working on CPL-like language invoked (logically)
  at publication time
• classes of users, e.g., based on entry in my
  address book
• classes get mapped to restriction
• 12 bits of long/lat resolution, 6 bits of
  altitude resolution, 0 bits of velocity
• time zone only, category only
• watchers can then add filters that restrict the
  delivery
• location difference gt threshold
• entering or leaving certain area
• entering or leaving category or behavioral type

41
Presence model
SUBSCRIBE
subscription policy
subscriber (watcher)
for each watcher
event generator policy
subscriber filter rate limiter
change to previous notification?
NOTIFY
42
Policy rules

• There is no sharp geospatial boundary
• Presence contains other sensitive data (activity,
  icons, ) and others may be added
• Example future extensions to personal medical
  data
• only my cardiologist may see heart rate, but
  notify everybody in building if heart rate 0
• Thus, generic policies are necessary

43
GEOPRIV and SIMPLE architectures
rule maker
rule interface
target
location server
location recipient
notification interface
publication interface
GEOPRIV
SUBSCRIBE
presentity
presence agent
watcher
SIP presence
PUBLISH
NOTIFY
caller
callee
SIP call
INVITE
INVITE
44
Columbia SIP servers (CINEMA)
Telephone switch
Local/long distance 1-212-5551212
rtspd media server
Quicktime
Single machine
RTSP
sipconf Conference server
RTSP clients
Department PBX
sipum Unified messaging
Internal Telephone Extn 7040
713x
sipd Proxy, redirect, registrar server
SQL database
SIP/PSTN Gateway
Web based configuration
SNMP (Network Management)
Extn 7134
H.323
Extn 7136
siph323 SIP-H.323 translator
NetMeeting
xiaotaow_at_cs
45
Location-based services in CINEMA

• Initial proof-of-concept implementation
• Integrate devices
• lava lamp via X10 controller ? set personalized
  light mood setting
• Pingtel phone ? add outgoing line to phone and
  register user
• painful needs to be done via HTTP POST request
• stereo ? change to audio CD track based on user
• Sense user presence and identity
• passive infrared (PIR) occupancy sensor
• magnetic swipe card
• ibutton
• BlueTooth equipped PDA
• IRRF badge (in progress)
• RFID (future)
• biometrics (future)

46
Example user-adaptive device configuration
all devices that are in the building RFC 3082?
SLP
802.11 signal strength ? location
device controller
REGISTER To 815cepsr Contact alice_at_cs
PA
HTTP
SUBSCRIBE to each room
tftp

1. discover room URI
2. REGISTER as contact for room URI

SIP
SUBSCRIBE to configuration for users currently in
rooms
room 815
47
Emergency calling as an LBS

• Existing emergency call systems (911) will no
  longer work in IP-based networks
• current 911 system uses outmoded operator trunk
  technology
• Emergency calling
• call identification ? sipsos_at_domain or tel112
• destination identification
• is this really an emergency call center?
• call routing to nearest emergency call center
  (ECC)
• Call routing is hardest
• must work internationally
• end system network-based location determination
• Once solved
• roadside emergency (AAA, ADAC, )
• pizza emergency (nearest PizzaHut)
• but different privacy trade-offs ? voluntary
  disclosure

48
Location-based call routing UA knows its
location
GPS
INVITE sipssos_at_
48 49' N 2 29' E
outbound proxy server
DHCP
48 49' N 2 29' E ? Paris fire department
49
Location-based call routing network knows
location
TOA
outbound proxy
include location info in 302
INVITE sipssos_at_
INVITE sipssos_at_paris.gendarme.fr
48 49' N 2 29' E
map location to (SIP) domain
50
Service creation

• Tailor a shared infrastructure to individual
  users
• traditionally, only vendors (and sometimes
  carriers)
• learn from web models

programmer, carrier end user
network servers SIP servlets, sip-cgi CPL
end system VoiceXML VoiceXML (voice), LESS
51
Call Processing Language (CPL)

• XML-based language for processing requests
• intentionally restricted to branching and
  subroutines
• no variables (may change), no loops
• thus, easily represented graphically
• and most bugs can be detected statically
• termination assured
• mostly used for SIP, but protocol-independent
• integrates notion of calendaring (time ranges)
• structured tree describing actions performed on
  call setup event
• top-level events incoming and outgoing

52
CPL

• Location set stored as implicit global variable
• operations can add, filter and delete entries
• Switches
• address
• language
• time, using CALSCH notation (e.g., exported from
  Outlook)
• priority
• Proxy node proxies request and then branches on
  response (busy, redirection, noanswer, ...)
• Reject and redirect perform corresponding
  protocol actions
• Supports abstract logging and email operation

53
CPL example
54
CPL example

• lt?xml version"1.0" ?gt
• lt!DOCTYPE call SYSTEM "cpl.dtd"gt
• ltcplgt
• ltincominggt
• ltlookup source"http//www.example.com/cgi-bin
  /locate.cgi?userjones"
• timeout"8"gt
• ltsuccessgt
• ltproxy /gt
• lt/successgt
• ltfailuregt
• ltmail url"mailtojones_at_example.comSubjec
  tlookup20failed" /gt
• lt/failuregt
• lt/lookupgt
• lt/incominggt
• lt/cplgt

55
CPL example anonymous call screening

• ltcplgt
• ltincominggt
• ltaddress-switch field"origin" subfield"user"gt
• ltaddress is"anonymous"gt
• ltreject status"reject"
• reason"I don't accept anonymous calls" /gt
• lt/addressgt
• lt/address-switchgt
• lt/incominggt
• lt/cplgt

56
Service creation for presence services
(work-in-progress)

• Accept or deny subscriptions
• Shape presence notifications
• different level of detail for family, friends and
  colleagues
• particularly important for geo data
• Subscriber can filter detail
• primarily, wireless bandwidth constraints
• rate limit notifications
• XPath?
• Mostly, condition/reaction ? CPL can be extended
  to most of these functions

57
Pushing context-sensitive data to users

• User with mobile device should get location
  information when entering city, campus or
  building
• flight and gate information
• maps and directions
• local weather forecast
• special advisories (choose security checkpoint
  2)
• Often does not require knowing user
• but interface with (e.g.) calendar
• Example Columbia implementation
• OBEX data exchange over BlueTooth
• PDA pushes current appointment or event name
• base station delivers directions and map

58
Conclusion

• SIP auxiliary protocols supports many of the
  core requirements for ubiquitous computing and
  communications
• mobility modalities terminal, user, session,
  service
• service negotiation for devices with different
  capabilities
• automatic configuration and discovery
• with SLP or similar
• event notification and triggered actions
• automatic actions event filtering, CPL, LESS
  (for end system services)
• SIP offers a loosely-coupled approach (cf. Jini
  or object models)
• Also need data push functionality
• Avoid tendency to assume SIP users are human
  want to interconnect different components and
  devices
• SIP device configuration needs automation, rather
  than screen-scraping