1 / 21

ORBIT: Multimedia Messaging & location-based services

ORBIT: Multimedia Messaging & location-based services. Henning Schulzrinne Columbia University. Overview. Disconnected ad-hoc networks multi-modal networking 7DS prototype Location-based services location determination service creation privacy policies.

ladonnas
Download Presentation

ORBIT: Multimedia Messaging & location-based services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ORBIT: Multimedia Messaging & location-based services Henning Schulzrinne Columbia University

  2. Overview • Disconnected ad-hoc networks • multi-modal networking • 7DS prototype • Location-based services • location determination • service creation • privacy policies

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

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

  5. Two directions for data: Internet  mobile nodes mobile nodes  Internet Each in multiple hops but not routed 7DS – a framework for intermittently connected networks delay bandwidth (peak)

  6. Realization

  7. Average Delay (s) vs Dataholders (%)Peer-to-Peer schemes high transmission power medium transmission power

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

  9. 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 Combining cellular and 7DS networks

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

  11. 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:hgs@cs.columbia.edu • sip:cepsr815@cs.columbia.edu • cross-domain, with extensive security mechanisms • domains don’t need to trust each other • scalable to global system • many other systems are mostly local

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

  13. Location information • geospatial • longitude, latitude, altitude • civil • time zone, country, city, street, room, … • categorical • type of location • properties of location • privacy (“no audio privacy”) • suitability for different communication media

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

  15. 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@cs PA HTTP SUBSCRIBE to each room tftp • discover room URI • REGISTER as contact for room URI SIP SUBSCRIBE to configuration for users currently in rooms room 815

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

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

  18. Presence model SUBSCRIBE subscription policy subscriber (watcher) for each watcher event generator policy subscriber filter rate limiter change to previous notification? NOTIFY

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

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

  21. Conclusion • 7DS as extension of infrastructure and ad-hoc 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

More Related