ORBIT: Multimedia
Messaging & locationbased services
Henning Schulzrinne
Columbia University
Overview

Disconnected ad-hoc networks



multi-modal networking
7DS prototype
Location-based services



location determination
service creation
privacy policies
Wireless Network: filling the
infrastructure-ad hoc gap





Wireless networks:
 Ubiquitous, fast, cheap: pick any two…
Currently, varies from 0.1c to $4/MB
Research has primarily explored:
 one-hop infrastructure extension (2G, 3G, 802.11)
 multi-hop connected ad-hoc networks (mesh networks)
But:
 2G/3G bandwidth will remain low and precious
 hot spots not ubiquitous
 ad hoc networks don’t scale
 brittle if spanning large areas
Our proposal: use mobile nodes to carry data
 to and from infrastructure networks
Applications




Tourism:
 get information about sights, travel, public transport schedules, ..
 upload picture postcards and video recordings
Transportation:
 users in buses and trains leverage data capability
Emergencies:
 propagate “I’m alive” and rescue information
Mobile sensors:
 sensors spread too far to communicate directly with each other
 large sensor data objects
7DS – a framework for
intermittently connected networks
Two directions for data:




delay
Internet  mobile nodes
mobile nodes  Internet
Each in multiple hops
but not routed
bandwidth
(peak)

high
low
high
7DS
802.11
hotspots
low
satellite
SMS?
voice (2G,
2.5G)
Realization
Average Delay (s)
Average Delay (s) vs Dataholders (%)
Peer-to-Peer schemes
1600
1400
1200
1000
800
600
400
200
0
high transmission power
medium transmission power
0
10
20
30
40
50
60
70
80
90
100
Dataholders (%)
P2P (high transmission power) one initial dataholder & 20 cooperative hosts in 2x2
P2P(medium transmission power) one initial dataholder & 20 coperative hosts in 1x1
Current status: prototype

Initial Java implementation




search not just by URL, but by content
 greater likelihood of finding appropriate material
(“news”)
Working on PDA implementations
Also, considering Linux embedded systems

low-power, self-contained
Combining cellular and 7DS
networks

Proposed research

use ubiquitous, low-speed
networks for control



some only one-way
(satellite, XM, Spot)

short-range, multi-hop for bulk
data transmission
Cellular reselling



pay once for bandwidth, use
many times
Inverse multiplexing

for high-priority content

Content location
 find nearest hotspot
Cache cleaning
 indicate popular
content for proactive
querying
 remove stale content in
mobile  Internet case
Incentive management


reputation management
credit for delivering data
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


configuration


others are (selectively) made aware of my location
security


devices in room adapt to their current users
awareness


incoming communications changes based on where I am
proximity grants temporary access
Privacy rules for access to context data
Location-based services & SIP

We’re 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
 sip:[email protected]
 sip:[email protected]
cross-domain, with extensive security mechanisms
 domains don’t need to trust each other
scalable to global system
 many other systems are mostly local
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
Location information

geospatial


civil


longitude, latitude, altitude
time zone, country, city, street, room, …
categorical


type of location
properties of location


privacy (“no audio privacy”)
suitability for different communication media
Determining location


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
Example: user-adaptive device
configuration
802.11 signal
strength  location
SLP
“all devices that are in the building”
RFC 3082?
device
controller
REGISTER
To: 815cepsr
Contact: [email protected]
PA
HTTP
SUBSCRIBE
to each room
1. discover room URI
2. REGISTER as contact for room URI
tftp
SIP
SUBSCRIBE to configuration
for users currently in rooms
room 815
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
Presence/Event notification

Three places for policy enforcement



subscription  binary
 only policy, no geo information
 subscriber may provide filter  could reject based on filter
(“sorry, you only get county-level information”)  greatly
improves scaling since no event-level checks needed
notification  content filtering, suppression
 only policy, no geo information
third-party notification
 e.g., event aggregator
 can convert models: gateway subscribes to event source,
distributes by email
 both policy and geo data
Presence model
SUBSCRIBE
subscription
policy
subscriber (watcher)
for each
watcher
event generator
policy
subscriber
filter
rate limiter
change to previous
notification?
NOTIFY
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
Processing models

Sequential model:



for each subscriber, apply rules to new data
doesn’t scale well to large groups
Relational database model:




re-use indexing and other query optimizations
well-defined query and matching semantics
e.g., mySQL and PostGres have geo extensions
At time of subscription:
 SELECT address FROM policies WHERE
person=$subscriber (AND now()
between(starttime,endtime) OR starttime is null) AND
(a3=$a3 or a3 is null) …
Conclusion



7DS as extension of infrastructure and adhoc networks
Combine benefits of low bit-rate, but
ubiquitous and high bit-rate, but sparse
networks
Location-based services as core wireless
service

from location determination to location
management and privacy
Descargar

Location-based services