universal inbox: personal mobility and service mobility in an integrated network
DESCRIPTION
Friends & family calls. Calls during business hours. Office Phone. Cell Phone. E-mail access via phone. Home Phone. Calls in the evening. E-Mail. Important e-mail headers. Anonymous Calls. Pager. Voice Mail. - PowerPoint PPT PresentationTRANSCRIPT
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 LearnedMonday 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 ICEBERGUser 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
1hohltb: Prefers Desktop
Preference Registry2
3
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
1 2
MediaManager Mail Access Service
3
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
1
23
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-id2 (+
)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