universal inbox: personal mobility and service mobility in an integrated network bhaskaran raman...

Universal Inbox: Personal Mobility

and Service Mobility in an

Integrated Network

Bhaskaran RamanICEBERG,

EECS, U.C.Berkeley

Home Phone

Voice MailPager

Cell Phone Office Phone

Calls during business hours

Calls in theevening

AnonymousCalls

Friends & family calls

E-MailImportant

e-mail headers

E-mail accessvia phone

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 vSpace 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 reservation13: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

• 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 devices Communication services

Universal Inbox: What is it?

Policy-basedLocation-basedActivity-based

Speech-to-TextSpeech-to-Voice Attached-EmailCall-to-Pager/Email Notification

Email-to-SpeechAll compositions

of the above!

Universal Inbox

Universal Inbox: Metaphor for personalized, integrated communication

One of the first applications to drive the design of ICEBERG

User sees unified, conceptual inbox of incoming communication

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

Bhaskar’s Cell-Phone

Barbara’s Desktop

Automatic Path Creation Service

510-642-8248 UID: hohltb@cs.berkeley.edu

Naming Service

11

hohltb: Prefers Desktop

Preference Registry2233

MediaManager Mail Access Service

Illustrating Extensibility

800-MEDIA-MGR UID: mediamgr@cs.berkeley.edu

mediamgr: Cluster locn.

Bhaskar’s Cell-Phone

Barbara’s Desktop

Naming Service

Preference Registry

Automatic Path Creation Service

1122

MediaManager Mail Access Service

33

Bhaskar’s PSTN Phone

510-642-8248 UID: hohltb@cs.berkeley.edu

hohltb: Prefers Desktop

Bhaskar’s Cell-Phone

Bhaskar’s PSTN Phone

Barbara’s Desktop

Naming Service

Preference Registry

Automatic Path Creation Service

11

2233

MediaManager Mail Access Service

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

IAP

IAP

IAP

IP-Addrs

Tel. No:s

Email-addrsPager no:s

Leveraging Extensibility in the APC

This extensibility translates to ease of end-point addition in the Universal Inbox

Speech synthesizer

Plain text

PCM encoder

PCM audio

HTML Email

HTML text extractor

GSM audio

GSM encoder

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

Extensions to the Universal

InboxStep-wise addition of eight different

devices and services to the

systemEach 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

Device/Service AP

Operators in APC Personal/Service mobility features

1 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/VoIP end-points

3 (+)

Mail-push-client (#4)

Op1 (text to sun-audio)

Op2 (sun-audio to PCM)

Op3 (PCM to GSM)

Email redirection to cell-phone/VoIP/Voice-mail

4 (+)

Instant-message-client

(#5)

(none) Instant message redirection to

cell-phone/VoIP/Voice-mail

Extensions to the Universal Inbox

Device/Service AP

Operators in APC Personal/Service mobility features

5 (+)

Jukebox-service (#6)

Op4 (MPEG3 to PCM) Jukebox access from cell-phone/VoIP

6 (+)

MediaManager Service (#7)

(none) MediaManager access from cell-phone/VoIP

7 (+)

PSTN end-points (#8)

Op5 (G.723 to PCM)Op6 (PCM to G.723)Op7 (GSM to PCM)

Call redirection to PSTN, E-mail redirection to

PSTN, Instant-message redirection to PSTN,

Jukebox and MediaManager access

from PSTN

and necessary operators

of ICEBERG access-point

Incremental addition

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

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

• 500MHz Pentium-III 2-way multiprocessor running Linux-2.2 with IBM’s JDK 1.1.8

Path Creation:Latency vs. Load

Toast Operator

Untoast Operator

About 50ms latency for path creation

Path Creation:Throughput vs.

Load

Toast Operator

Untoast Operator

About 7.2 path creations/sec at a load

of 64 simultaneous paths

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/4th 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 35ms

• Path creation at APC– About 50ms

• 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 networkS– 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, 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 deployed by independent

service providers

• Extensibility– Made easy by the separation and reuse of

functionality

• Open Questions– Security issues– Billing issues