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

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

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 Name Mapping Service 800-MEDIA-MGR UID: mediamgr@cs.berkeley.edu 510-642-8248 UID: hohltb@cs.berkeley.edu 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

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 E-Mail Important e-mail headers E-mail access via phone

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 Email-addrs Pager no:s IAP IAP IAP IAP

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

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