1. Problem Statement Communication devices Communication services
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

2. State-of-the-Art Commercial services Research projects
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

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

4. Any-to-any Communication
Name Mapping Service
800-MEDIA-MGR
UID:
UID: 2 3 1
IAP
Preference Registry
Barbara’s Desktop
hohltb: Prefers Desktop
mediamgr: Cluster locn.
IAP
Bhaskar’s Cell-Phone 3’
Automatic Path Creation Service
IAP
IAP
Bhaskar’s PSTN Phone
MediaManager Mail Access Service

5. Bhaskaran Raman ICEBERG, EECS, U.C.Berkeley
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
Important
headers
access
via phone

6. Extensibility Name-space Automatic Path Creation service Set of IAPs
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
IP-Addrs
Tel. No:s
-addrs
Pager no:s
IAP
IAP
IAP
IAP

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

8. Further Plans Extend to PCM end-points Inside department deployment
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

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