1. 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 devicesCommunication services

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

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 800-MEDIA-MGR UID: mediamgr@cs.berkeley.edu 510-642-8248 UID: hohltb@cs.berkeley.edu hohltb: Prefers Desktop mediamgr: Cluster locn. Bhaskar’s Cell-Phone Bhaskar’s PSTN Phone Barbara’s Desktop Name Mapping Service Preference Registry Automatic Path Creation Service 1 1 2 2 3 3 MediaManager Mail Access Service 3’ IAP

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

6. 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 IP-Addrs Tel. No:s Email-addrs Pager no:s

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 –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