universal inbox: personal mobility and service mobility in an integrated network bhaskaran raman...
TRANSCRIPT
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
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: [email protected]
Naming Service
11
hohltb: Prefers Desktop
Preference Registry2233
MediaManager Mail Access Service
Illustrating Extensibility
800-MEDIA-MGR UID: [email protected]
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: [email protected]
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: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