1 / 35

Mobility-Enhanced Network Services

Mobility-Enhanced Network Services. Todd Hodes, Randy Katz Computer Science Division University of California, Berkeley http://www.cs.berkeley.edu. Scenario. Enter campus, check PDA for list of services e.g., obtain campus map, check building location. Soda Hall. Current Cell.

gamma
Download Presentation

Mobility-Enhanced Network 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. Mobility-EnhancedNetwork Services Todd Hodes, Randy Katz Computer Science Division University of California, Berkeley http://www.cs.berkeley.edu

  2. Scenario • Enter campus, check PDA for list of services • e.g., obtain campus map, check building location Soda Hall Current Cell

  3. Enter Soda Hall • Available services change • e.g., Current map changes “foyer services”

  4. Move to Auditorium “auditorium services” • See additional services presented • e.g., Obtain VCR and A/V switching controls • e.g.., Existing light switch UI widget remapped to local lights “foyer services”

  5. Print Notes • Select printer; location noted on current map • Print & retrieve file, return to auditorium

  6. Location-based Services • Maps + Coarse-grained location tracking • Printers, lights, audio/video equipment • DNS, NTP • many others...

  7. Outline • Requirements • Architecture • Location & Scope • Services as Partitioned Application Components • Prototype Applications • Summary • Future Work

  8. Requirements 3 clients objects ? 1) Non-intrusive Mobile Devices 2) Remote-Controllable Devices / Apps 1 2 3) Service Discovery 4) Transducers between objects and clients 4

  9. 1) Client Devices • Use of small mobile devices • promotes goal of “non-intrusive” usage • allows users to interact with their “usual” device rather a “new” (local) one

  10. Remote Control This? Or this?

  11. 2) Controllable Objects device • Define and create specific API for control of apps • Expose control interface over the network while separating/minimizing UI assumptions RS-232 control interfaces accessible via IP computer IP

  12. Example Devices: UCB CoLab Echo Canceller Mic amp TV monitor, Camera, & Speaker sets A / V switch Scan Converters Computers Receiver Serial mux LiveBoard Not shown: VCR, power control, ON-AIR sign, WaveLAN base station, ...

  13. 3) Service Discovery clients objects • Advertise, register, & query • Scalable management of hierarchy of available services • Scoping, rate-limiting for wide-area • Naming query register ? Service Discovery Service advertise Other Services . . . . . .

  14. (header) SIP IP addr port ticket application-specific payload … Scoped Discovery Bootstrap • Mobility beaconing is an announce/listen protocol • unify with a service location announce/listen protocol • announced data is location information • Advertisements (push) vs. queries (pull) • push: user anonymity, power, traffic • Contrast announce/listen with lookup-based schemes • adaptive scoping/forwarding (vs. DHCP) • no root servers (vs. DNS) • granularity varies with subnets, not area; no additional hardware required if connectivity assumed (vs. GPS) beacon packets

  15. Scoping Heuristics (scoped) beacon with ticket request + ticket • Tickets included in scoped beacons • For local per-service access • Without ticket, services are inaccessible • For local service directory (cache) access • Without a received beacon, contents (and existence) unknown

  16. 4) Transducing Interfaces • Map between object and client interfaces at application proxy • remap endpoints & data types, aggregate/subset, compose • Exploit: • COM/Java Beans-style introspection to discover objects’ interface definitions or explicit Interface Specifications • exposed indirection between client app and device (control protocol) to vary UI Application Proxy Client Device Device Proxy Wireless Wired IP RS-232

  17. On-the-fly Transduction • Utilize interface specification for on-the-fly UI generation/modification • Still can use existing client-specific UI code Application Proxy Client Device Device Proxy Wireless Wired IP RS-232 Generation Process Original or Generated UI Control Interface and/or Existing UI Code

  18. Remapping on off • Client UI data type to that expected by control interface • Current interface widget(s) to new servers • Control messages to other control messages (boolean) (enumerated) 0.0 1.0 0.5 (real)

  19. Aggregate or Subset • Create custom UIs that can use a portion of the functionality from one or more control interfaces • controllable objects/servers remain independent Aggregate Interface Definitions Application Proxy Client Devices Device Proxies

  20. Compose • Compose device/server interaction behind unified interface • Create complex behaviors from independent controllable objects/servers Aggregate Interface Definitions Application Proxy Client Devices Device Proxies

  21. Application Interfaces Summary • Allow multiple possible interfaces • Match heterogeneity in client devices • Match differences in available sevices • Mach per-user variations to suit differing usage models • Build complex behaviors from independent components • Transparent widget remapping of data type and endpoints • Feature subsets & aggregates • Composition

  22. Soda 405 Testbed Service Discovery Service

  23. Screenshots Service Interaction Client Monolithic A/V controller

  24. Screenshots (cont.) Lights Map with Exported Object Locations

  25. Screenshots (cont.) Audio / Video Switching Camera Control

  26. Screenshots (cont.) Video Monitor Switching (RVIC client & server)

  27. Detailed Example: RVIC • “Remote-controlled VIC” • Removes the UI from the monitor, places it in the user’s hand • vic’s UI overhead is useless if not used at a desktop • Reduces vic’s video window configuration complexity by supporting “standard configurations” • Messaging style: • idempotent, string-based • use announce/listen for reliability, eventual consistency

  28. RVIC Messages • RoomServer Messages: • Get SessionList [scope attribute] • Get MonitorList [scope attribute] • Get SourcesList <session> • InitMonitor <monitor> • Get RoomPresets • InitRoom <preset> • RvicServer Messages: • Get MonitorConfigs • Set MonitorConfig <configSpec> • Set VideoWindow <windowSpec> <source>

  29. RVIC Message Data • [scope attribute] : • from Service Directory bootstrap beacon • address/port + ticket • or hierarchical scope attribute string for conversion to addr/port • “…/Berkeley Campus/Soda Hall/326 Soda” (TBD) • <session> : SDP session name • <windowSpec> : integer window number, with windows ordered from top to bottom then left to right • <source> : a CNAME of a session source

  30. Detailed Example: RVIC (cont.) • Request rate and Consistency update scaling: • Eventual consistency via announce/listen • Exposes basic tradeoff in latency/bandwidth • update state on each action: minimize latency • rate-limit updates via timers and population estimation (a la SDP): tight bandwidth control • Multi-user policies atop mechanism: • “Free-for-all:” no locking • Dedicated controller: coarse locking • Rotating controller: fine-grained locking • Voting: no locking, but latency issues (c.f., SCUBA)

  31. Summary An architecture and prototype system for composable mobile services • IP Dial Tone isn’t enough • Deploy services, provide seamless access • Embed location information into data networks • Variable application interfaces • discover interfaces, move GUIs • transduce to reduce need for a priori interfaces • Used by instructor and students to control an augmented classroom (UCB CoLab)

  32. Continuing Work • MASH collaboration laboratory (326 Soda) • MBone video and audio • Conference control elements • Pilot PDA + Metricom interface implementation • User Interfaces (with J. Landay, M. Newman) • Presentation of controls • Behavior specification • Reconciliation of conflicting behaviors • Extend discovery beyond local-area • hierarchy, scoping, union/intersection

  33. Related Work • Mobile IP, Overlay Networking • Service Location Protocol • PARCTab, Active Badges • Application Partitioning (Rover, Wit, …) • Proxies/Gateways • DHTML, Universal Remote Controls • Location-based applications (Mobisaic, …) • Distributed object systems (CORBA, DCE, …)

  34. Device Mobility • Mobile IP, Overlays

  35. Composing Interface Definition • Create complex behaviors • From independent controllable objects/servers • UNIX pipe / HTTP proxy model • Exploits exposed application interface definition and indirection • Remap an RPC to multiple RPCs on-the-fly Application Proxy Client Device Device Proxy Device Device Proxy

More Related