Problem Statement

Requirement
Service integration and personalization
Goals
Any-to-any capability
Extensibility: ease of adding new end-points
Scalability: global scale operation
Personal mobility and Service mobility
Communication devices Communication services
State-of-the-Art
Commercial services
Concentrate on functionality
No any-to-any capability
Research projects
Mobile People Architecture: Personal Proxies
Telephony Over Packet networkS
UMTS
Issues not addressed:
Infrastructure support for network integration
Extensibility
Scalability
Personal mobility + Service mobility
Key Ideas
Infrastructure components for network integration
Components in the Internet: open model, can leverage proxy
and cluster architectures (Ninja)
Identification and separation of components
Name Mapping Service (NMS)
Automatic Path Creation service (APC)
Preference Registry (PR)
ICEBERG Access Points (IAP) to proxy for communication
end-points
Advantages of separate infrastructure components
Reusable pieces
Extensibility is easier: just add to the piece that requires
extension
Any-to-any
Communication
800-MEDIA-MGR
UID: mediamgr@cs.berkeley.edu
510-642-8248
UID: hohltb@cs.berkeley.edu
hohltb: Prefers Desktop
mediamgr: Cluster locn.
Bhaskars
Cell-Phone
Bhaskars
PSTN Phone
Barbaras
Desktop
Name Mapping Service
Preference Registry
Automatic Path
Creation Service
1
2
3
MediaManager
Mail Access
Service
3
IAP
IAP
IAP
IAP
Universal Inbox:
Personal Mobility and
Service Mobility in an
Integrated Network
Bhaskaran Raman
ICEBERG,
EECS, U.C.Berkeley
Home Phone
Voice Mail
Pager
Cell Phone Office Phone
Calls during
business hours
Calls in the
evening
Anonymous
Calls
Friends &
family calls
E-Mail
Important
e-mail headers
E-mail access
via phone
Extensibility
Name-space
Hierarchical
New name-spaces added by
creating a new sub-tree at
root
Automatic Path Creation
service
Operators can be plugged
in
Old operators are reusable
Set of IAPs
New IAPs can be added
independent of existing
ones
All old IAPs are reachable
from the new one
IAP
IAP
IAP
IAP
IP-Addrs
Tel. No:s
Email-addrs
Pager no:s
Implementation Experience
Testbed with GSM cell-phones and VoIP end-
points
Components on top of Ninja 1.5 (iSpace)
Examples of extension:
IAP for Ninja Jukebox
Allow service access from voice-enabled end-points
~ 700 lines of Java
Also required addition of operators to APC service: MPEG-3
to PCM
IAP for MediaManager
Allow access to the MediaManager service
Similar code-size and effort
No other component had to be touched
Operators for G.723
Getting codec to work required effort
But, adding to APC was ~ two hours of work ( simple API
for adding operators)
Further Plans
Extend to PCM end-points
PSTN phones, via H.323 gateway
Build IAP for interfacing
Hypothesis: all existing end-points and services should
interoperate without modification (e.g., Jukebox,
MediaManager, Two way call with Cell-Phone, VoIP, etc.)
Inside department deployment
Make system more usable
Extend to more services and end-points
Scaling and latency issues
Services on vSpace
Leverage cluster-computing features
Summary
Universal Inbox: metaphor for any-to-any
communication and service access
Personal mobility
redirection by preference registry
Service mobility
result of the any-to-any capability
Architecture viable for global operation
IAPs can be developed and depoyled by independent
service providers
Extensibility
Made easy by the separation and reuse of functionality
Open Questions
Security issues
Billing issues