Universal Inbox Personal Mobility and Service Mobility in

Universal Inbox: Personal Mobility and Service Mobility in an Integrated Network Bhaskaran Raman ICEBERG, EECS, U. C. Berkeley Friends & family calls Calls during business hours Cell Phone E-mail access via phone Office Phone Home Phone Calls in the evening E-Mail Important e-mail headers Pager Voice Mail Anonymous Calls

Design Decisions / Lessons Learned Monday 21 August 2000 10: 15 - 10: 35 Top-level design decisions Rationale for IP-based approach Why an infrastructure based approach? Leveraging cluster-computing environments: Ninja v. Space 10: 35 - 12: 00 Design of the ICEBERG components and capabilities Signaling protocol for flexible multi-party communication Service creation model Clearing House for resource reservation 13: 00 - 15: 00 Design of the ICEBERG components and capabilities Automatic Path Creation service Naming service Preference Registry and Preference Manager Personal Activity Coordinator Universal Inbox for personal mobility and service mobility

Outline • Aug 21, 2000, Monday – “Universal Inbox” set of capabilities – Goals and how they are achieved in ICEBERG – Extensibility and Scalability properties illustrated • Aug 22, 2000, Tuesday – Details of redirection mechanism – Example of extension to the Universal Inbox • Access to the Jukebox Service – APIs for extension • Programmer’s perspective • Service provider’s perspective – Details of scaling measurements

Motivating Scenario

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

Universal Inbox: What is it? Speech-to-Text Speech-to-Voice Attached-Email Call-to-Pager/Email Notification Email-to-Speech All compositions of the above! Universal Inbox Policy-based Location-based Activity-based Universal Inbox: Metaphor for personalized, integrated communication User sees unified, conceptual inbox of incoming communication One of the first applications to drive the design of ICEBERG

Design Principles • Separation of functionality – Separation independent and reusable components – Reuse easy extensibility – Shared network services Economy of scale • Network and device independence – Needed for extensibility to new devices • Push control towards callee – In current communication networks, caller has control – Callee needs to have control for flexible handling of incoming communication

Use of ICEBERG Components • 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 core infrastructure components – Reusable pieces; Extensibility is easier: just add to the piece that requires extension

Use of ICEBERG Components (Continued) • Automatic Path Creation (APC) service – Generic any-to-any data transformation – Provides data-type independence • Preference registry – Mechanism for ubiquitous redirection – Achieves the “control to callee” design principle • Naming service – Mapping between different device identities – Provides device name independence • ICEBERG Access Points (IAPs) – Provide network independence

Naming Service 510 -642 -8248 UID: hohltb@cs. berkeley. edu 1 2 Preference Registry 3 Barbara’s Desktop hohltb: Prefers Desktop Bhaskar’s Cell-Phone Automatic Path Creation Service Illustrating Extensibility Media. Manager Mail Access Service

Naming Service 800 -MEDIA-MGR UID: mediamgr@cs. berkeley. edu 1 2 Barbara’s Desktop Preference Registry mediamgr: Cluster locn. Bhaskar’s Cell-Phone 3 Automatic Path Creation Service Bhaskar’s PSTN Phone Media. Manager Mail Access Service

Naming Service 510 -642 -8248 UID: hohltb@cs. berkeley. edu 2 Preference Registry 3 Barbara’s Desktop hohltb: Prefers Desktop Bhaskar’s Cell-Phone 1 Automatic Path Creation Service Bhaskar’s PSTN Phone Media. Manager Mail Access Service

Extensibility • Name-space – Hierarchical – New name-spaces added by creating a new sub-tree at root • Automatic Path Creation service Tel. No: s Email. IPaddrs Addrs Pager no: s – 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

Leveraging Extensibility in the APC HTML Email Speech synthesize r PCM encode r GSM audio GSM encoder HTML text extractor Plain text PCM audio This extensibility translates to ease of end-point addition in the Universal Inbox

Implementation Experience • Extensibility – Universal Inbox set of features extended to lot of device and service end-points • Scalability – Components tested for latency and scaling bottlenecks

Step-wise addition of eight different devices and services to the system Extensions to the Universal Inbox Each step involves addition of an IAP – for the device/network or the service Each step integrates the device/service with ALL existing ones

Extensions to the Universal Inbox 1 Device/Service AP Operators in APC Personal/Service mobility features Cell-Phones (#1) & Voice-over-IP (#2) (none) Call redirection/screening based on time-of-day & caller -id 2 (+) Voice-mail (#3) (none) Call redirection to voice-mail also possible, Voice-mail access from cell-phone/Vo. IP end-points 3 (+) Mail-push-client (#4) Op 1 (text to sun-audio) Op 2 (sun-audio to PCM) Op 3 (PCM to GSM) Email redirection to cellphone/Vo. IP/Voice-mail 4 (+) Instantmessage-client (#5) (none) Instant message redirection to cell-phone/Vo. IP/Voicemail

Extensions to the Universal Inbox Device/Service AP Operators in APC Personal/Service mobility features Op 4 (MPEG 3 to PCM) Jukebox access from cellphone/Vo. IP 5 (+) Jukebox-service (#6) 6 (+) Media. Manager Service (#7) (none) Media. Manager access from cell-phone/Vo. IP 7 (+) PSTN endpoints (#8) Op 5 (G. 723 to PCM) Op 6 (PCM to G. 723) Op 7 (GSM to PCM) Call redirection to PSTN, E -mail redirection to PSTN, Instant-message redirection to PSTN, Jukebox and Media. Manager access from PSTN Incremental addition of ICEBERG access-point and necessary operators results in incremental addition of functionality

Implementation Experience with Extension • 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 Media. Manager • Allow access to the Media. Manager 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)

Lessons learned: What was easy? • Extension to include a new communication service or device – Build an IAP – Add appropriate operators Effort involved in building a service is independent of the number of networks it is made available on

Scalability Analysis • Shared infrastructure components scaling and provisioning concerns • Would like to – Answer provisioning questions – Identify scaling bottlenecks • Three shared core components are: – APC – Preference Registry – Naming service

Scalability Analysis: APC • One round of performance optimization – Originally, operators were unix processes and one would run for each path – Now, operators can be shared across paths • Performance for the following operators – Null (copies input to output), – Toast (PCM to GSM), Untoast (GSM to PCM), and – G. 723 encoder, decoder • Path creation latency and throughput measured as a function of increasing load • 500 MHz Pentium-III 2 -way multiprocessor running Linux-2. 2 with IBM’s JDK 1. 1. 8

Path Creation: Latency vs. Load Untoast Operator Toast Operator About 50 ms latency for path creation

Path Creation: Throughput vs. Load Untoast Operator About 7. 2 path creations/sec at a load of 64 simultaneous paths Toast Operator

Calculation of Scaling • On average – 2. 8 calls/hour/user – Average duration of calls (path) is 2. 6 minutes • Using these – 571 users can be supported by a two-node APC service – Encouraging since the telephone network uses expensive hardware equipment for these transformations (TRAU at the Inter-Working Function) • About 1/4 th of this for G. 723 decoder • G. 723 encoder: heavy-weight

Scalability Analysis: Preference Registry • Uses cluster-based distributed storage for storing preference profiles • Throughput: 55. 3 requests/sec (for dummy user preference profiles) • This means about 71, 100 users for a single preference registry • Clearly not a scaling bottleneck

Additions to call-setup latency • Universal Inbox’s redirection mechanisms cause extra delay • Preference registry lookup – About 35 ms • Path creation at APC – About 50 ms • Such latencies may be high for regular call setup – Need to be brought down in the next round of implementation

Related Work: State-of-the-Art • Commercial services – Concentrate on functionality – No any-to-any capability • Research projects – Mobile People Architecture: Personal Proxies – Telephony Over Packet network. S – UMTS • Issues not addressed: – – Infrastructure support for network integration Extensibility Scalability Personal mobility + Service mobility

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, Media. Manager, Two way call with Cell-Phone, Vo. IP, etc. ) • Inside department deployment – Make system more usable – Extend to more services and end-points – Scaling and latency issues • Services on v. Space – 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 deployed by independent service providers • Extensibility – Made easy by the separation and reuse of functionality • Open Questions – Security issues – Billing issues