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

1 Name Mapping Service 800-MEDIA-MGR UID: [email protected] 510-642-8248 UID: [email protected] 2 Preference Registry hohltb: Prefers Desktop mediamgr: Cluster locn.

IAP Bhaskar’s Cell-Phone

Any-to-any Communication

3 IAP Barbara’s Desktop 3’ Automatic Path Creation Service IAP Bhaskar’s PSTN Phone IAP MediaManager Mail Access Service

Universal Inbox: Personal Mobility and Service Mobility in an Integrated Network

Bhaskaran Raman ICEBERG, EECS, U.C.Berkeley

Friends & family calls Cell Phone E-mail access via phone E-Mail Important e-mail headers Pager Calls during business hours Office Phone Home Phone Calls in the evening Voice Mail Anonymous Calls

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