universal inbox ericsson2000

Information about universal inbox ericsson2000

Published on February 4, 2008

Author: Pasquale

Source: authorstream.com

Content

Universal Inbox: Personal Mobility and Service Mobility in an Integrated Network:  Universal Inbox: Personal Mobility and Service Mobility in an Integrated Network Bhaskaran Raman ICEBERG, EECS, U.C.Berkeley Design Decisions / Lessons Learned:  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 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:  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:  Motivating Scenario Problem Statement:  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?:  Universal Inbox: What is it? Policy-based Location-based Activity-based Speech-to-Text Speech-to-Voice Attached-Email Call-to-Pager/Email Notification Email-to-Speech All 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:  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:  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):  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 Slide10:  Bhaskar’s Cell-Phone Barbara’s Desktop Illustrating Extensibility Slide11:  800-MEDIA-MGR UID: [email protected] mediamgr: Cluster locn. Bhaskar’s Cell-Phone Barbara’s Desktop Naming Service Preference Registry Automatic Path Creation Service Slide12:  510-642-8248 UID: [email protected] hohltb: Prefers Desktop Bhaskar’s Cell-Phone Barbara’s Desktop Naming Service Preference Registry Automatic Path Creation Service 1 Extensibility:  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 Leveraging Extensibility in the APC:  Leveraging Extensibility in the APC This extensibility translates to ease of end-point addition in the Universal Inbox Implementation Experience:  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 Inbox:  Extensions to the Universal Inbox Step-wise addition of eight different devices and services to the system 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:  Extensions to the Universal Inbox Extensions to the Universal Inbox:  Extensions to the Universal Inbox Implementation Experience with Extension:  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?:  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:  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:  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:  Path Creation: Latency vs. Load Toast Operator Untoast Operator About 50ms latency for path creation Path Creation: Throughput vs. Load:  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:  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:  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:  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:  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:  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:  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

Related presentations


Other presentations created by Pasquale

ancient olympic games
02. 05. 2008
0 views

ancient olympic games

VRA Glass Markets Presentation
09. 01. 2008
0 views

VRA Glass Markets Presentation

AppliedMechanics
13. 01. 2008
0 views

AppliedMechanics

Chapter9
15. 01. 2008
0 views

Chapter9

2007Somera
15. 01. 2008
0 views

2007Somera

puschel spiral
16. 01. 2008
0 views

puschel spiral

Excavations2
19. 01. 2008
0 views

Excavations2

NCMA Berry Amendment Rex Bragaw
22. 01. 2008
0 views

NCMA Berry Amendment Rex Bragaw

moscowforumenglish
23. 01. 2008
0 views

moscowforumenglish

BEEDL 123a finalPPT v6
04. 02. 2008
0 views

BEEDL 123a finalPPT v6

Hydrogen Economy
05. 02. 2008
0 views

Hydrogen Economy

Joos QCSE07
09. 01. 2008
0 views

Joos QCSE07

ravenous uk ltd
29. 01. 2008
0 views

ravenous uk ltd

WNC07
07. 02. 2008
0 views

WNC07

PalliativeCare
15. 01. 2008
0 views

PalliativeCare

electronID
20. 01. 2008
0 views

electronID

WatershedCommunicati onChannels
26. 02. 2008
0 views

WatershedCommunicati onChannels

20070306
28. 02. 2008
0 views

20070306

Course chp
16. 01. 2008
0 views

Course chp

RichmondRegionalMobi litySystem
31. 01. 2008
0 views

RichmondRegionalMobi litySystem

lebilinguisme Mar2703
29. 02. 2008
0 views

lebilinguisme Mar2703

05 a NCEM Brownian v1
25. 01. 2008
0 views

05 a NCEM Brownian v1

Ergo Keween
05. 03. 2008
0 views

Ergo Keween

SLiCE
14. 03. 2008
0 views

SLiCE

Transport lecture11
21. 03. 2008
0 views

Transport lecture11

Fingerhut welcome
03. 04. 2008
0 views

Fingerhut welcome

BHTV BITE2000
08. 04. 2008
0 views

BHTV BITE2000

east vs west
10. 03. 2008
0 views

east vs west

Kids andTableTennis1
14. 04. 2008
0 views

Kids andTableTennis1

Self Leadership Lynn Joseph
16. 04. 2008
0 views

Self Leadership Lynn Joseph

WU Course 3
17. 04. 2008
0 views

WU Course 3

2007611162243264
23. 04. 2008
0 views

2007611162243264

CLI GM Vodcast trial
24. 04. 2008
0 views

CLI GM Vodcast trial

chintoda
07. 05. 2008
0 views

chintoda

insagb
02. 05. 2008
0 views

insagb

Lsn 9 SSA
03. 04. 2008
0 views

Lsn 9 SSA

EYESAFE
22. 01. 2008
0 views

EYESAFE

Wykle2007
16. 01. 2008
0 views

Wykle2007

tdb
07. 02. 2008
0 views

tdb

COED CMS Overview Oct 16 Final
10. 01. 2008
0 views

COED CMS Overview Oct 16 Final

colloq hc99
18. 01. 2008
0 views

colloq hc99

FairCASH Best Path ID
17. 01. 2008
0 views

FairCASH Best Path ID

Light 6
04. 02. 2008
0 views

Light 6