mobility-enhanced network services
Post on 05-Jan-2016
33 Views
Preview:
DESCRIPTION
TRANSCRIPT
Mobility-EnhancedNetwork Services
Todd Hodes, Randy KatzComputer 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
Enter Soda Hall
• Available services change– e.g., Current map changes
“foyer services”
Move to Auditorium
• 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”
“auditorium services”
Print Notes
• Select printer; location noted on current map• Print & retrieve file, return to auditorium
Location-based Services
• Maps + Coarse-grained location tracking• Printers, lights, audio/video equipment• DNS, NTP• many others...
Outline
• Requirements• Architecture
– Location & Scope
– Services as Partitioned Application Components
• Prototype Applications• Summary• Future Work
Requirements
2) Remote-Controllable Devices / Apps
3) Service Discovery
4) Transducers between objects and clients
clients objects
2
4
3?1) Non-intrusive
Mobile Devices
1
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
Remote Control
This? Or this?
2) Controllable Objects
• Define and create specific API for control of apps
• Expose control interface over the network while separating/minimizing UI assumptions
RS
-232
IP
computer
device
control interfacesaccessiblevia IP
Example Devices: UCB CoLab
TV monitor,Camera, &Speaker
sets
Computers
Serial muxLiveBoard
A / V switch
Mic amp
Echo Canceller
Scan Converters
Not shown: VCR, power control, ON-AIR sign, WaveLAN base station, ...
Receiver
3) Service Discovery
• Advertise, register, & query– Scalable management of hierarchy of available services
– Scoping, rate-limiting for wide-area
• Naming
?
Other Services
. . . . . .
ServiceDiscoveryService
query register
clients objects
advertise
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)
(header) SIP IP addr port ticket application-specific payload …
beacon packets
Scoping Heuristics
• 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
request + ticket(scoped) beacon
with ticket
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
ApplicationProxyClient DeviceDevice
Proxy
RS-232Wired IPWireless
On-the-fly Transduction
• Utilize interface specification for on-the-fly UI generation/modification
• Still can use existing client-specific UI code
ApplicationProxy
Client DeviceDeviceProxy RS-232Wired IPWireless
GenerationProcess
Control Interface and/or
Existing UI Code
Original or Generated UI
Remapping
• Client UI data type to that expected by control interface
• Current interface widget(s) to new servers
• Control messages to other control messages
0.0 1.00.0 1.00.5
on
off
(enumerated)
(real)
(boolean)
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
AggregateInterfaceDefinitions
ApplicationProxyClient DevicesDevice
Proxies
Compose
• Compose device/server interaction behind unified interface
• Create complex behaviors from independent controllable objects/servers
AggregateInterfaceDefinitions
ApplicationProxyClient DevicesDevice
Proxies
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
Soda 405 Testbed
ServiceDiscovery
Service
Service Interaction Client
Monolithic A/V controller
Screenshots
Lights
Map with Exported Object Locations
Screenshots (cont.)
Screenshots (cont.)
Camera Control
Audio / Video Switching
Screenshots (cont.)
Video Monitor Switching (RVIC client & server)
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
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>
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
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)
Summary
• 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)
An architecture and prototype system for composable mobile services
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
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, …)
Device Mobility
• Mobile IP, Overlays
Composing
• 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
ApplicationProxyClient DeviceDevice
Proxy
DeviceDeviceProxy
InterfaceDefinition
top related