Mobility-Enhanced
Network Services
Todd Hodes, Randy Katz
Computer Science Division
University of California, Berkeley
http://www.cs.berkeley.edu
Scenario
Soda Hall
Current Cell
• Enter campus, check PDA for list of services
– e.g., obtain campus map, check building location
Enter Soda Hall
“foyer services”
• Available services change
– e.g., Current map changes
Move to Auditorium
“auditorium services”
“foyer 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
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
3
clients
1) Non-intrusive
Mobile Devices
2) Remote-Controllable
Devices / Apps
1
2
3) Service Discovery
4) Transducers
between objects
and clients
objects
?
4
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
computer
IP
control
interfaces
accessible
via IP
RS-232
device
• Define and create specific API for control of apps
• Expose control interface over the network while
separating/minimizing UI assumptions
Example Devices: UCB CoLab
Echo Canceller
Mic amp
A / V switch
Scan Converters
TV monitor,
Camera, &
Speaker
sets
Computers
Receiver
Serial mux
LiveBoard
Not shown: VCR, power control, ON-AIR sign, WaveLAN base station, ...
3) Service Discovery
clients
objects
query
?
advertise
register
Service
Discovery
Service
Other
Services
• Advertise, register, & query
– Scalable management of hierarchy of available services
– Scoping, rate-limiting for wide-area
• Naming
......
Scoped Discovery Bootstrap
(header) SIP IP addr
port
ticket
application-specific payload …
beacon packets
• 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)
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
4) Transducing Interfaces
Application
Proxy
Client
Wireless
Device
Proxy
Wired IP
Device
RS-232
• 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
On-the-fly Transduction
Client
Application
Proxy
Wireless
Original or
Generated UI
Wired IP
Device
Proxy
Generation
Process
Device
RS-232
Control Interface
and/or
Existing UI Code
• Utilize interface specification for on-the-fly UI
generation/modification
• Still can use existing client-specific UI code
Remapping
on
off
(boolean)
(enumerated)
0.5
0.0
1.0
(real)
• Client UI data type to that expected by control interface
• Current interface widget(s) to new servers
• Control messages to other control messages
Aggregate or Subset
Aggregate
Interface
Definitions
Client
Application
Proxy
Device
Proxies
Devices
• Create custom UIs that can use a portion of the
functionality from one or more control interfaces
• controllable objects/servers remain independent
Compose
Aggregate
Interface
Definitions
Client
Application
Proxy
Device
Proxies
Devices
• Compose device/server interaction behind
unified interface
• Create complex behaviors from independent
controllable objects/servers
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
Service
Discove
ry
Service
Screenshots
Service Interaction Client
Monolithic A/V controller
Screenshots (cont.)
Lights
Map with Exported Object Locations
Screenshots (cont.)
Audio / Video Switching
Camera Control
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
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)
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
Interface
Definition
Client
Application
Proxy
Device
Proxy
Device
Device
Proxy
Device
• 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