Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Universal Inbox: Extensible Personal Mobility and Service Mobility in an Integrated Network Bhaskaran Raman, Randy H. Katz...
Motivating Scenario Personal Mobility Service Mobility
Problem Statement <ul><li>Requirement </li></ul><ul><ul><li>Service integration and personalization </li></ul></ul><ul><li...
ICEBERG: An IP-Centric Middleware Approach ICEBERG Network (Internet) PSTN GSM Pager WaveLAN GSM PSTN
Internet-based Infrastructure <ul><li>Components in the Internet:  open  model </li></ul><ul><li>Leverage  proxy  and clus...
Design Principles <ul><li>Separation of functionality </li></ul><ul><ul><li>Separation    independent and reusable compon...
Caller Callee Data Transformation Name Mapping & Translation Preference Management An Example Scenario
Common Functionalities <ul><li>Any-to-any data transformation </li></ul><ul><ul><li>For communication between heterogeneou...
Common Functionalities <ul><li>Device name mapping and translation </li></ul><ul><ul><li>For dealing with multiple user id...
Bhaskar’s Cell-Phone Barbara’s Desktop Illustrating Extensibility Automatic Path Creation Service 510-642-8248 UID: hohltb...
800-MEDIA-MGR UID: mediamgr@cs.berkeley.edu  mediamgr: Cluster locn. Bhaskar’s Cell-Phone Barbara’s Desktop Naming Service...
510-642-8248 UID: hohltb@cs.berkeley.edu  hohltb: Prefers Desktop Bhaskar’s Cell-Phone Barbara’s Desktop Naming Service Pr...
Extensibility <ul><li>Name-space </li></ul><ul><ul><li>Hierarchical </li></ul></ul><ul><ul><li>New name-spaces added by cr...
Implementation Experience <ul><li>Extensibility </li></ul><ul><ul><li>Universal Inbox set of features extended to many  de...
Extensions to the Universal Inbox Step-wise addition of eight different devices and services to the system Each step invol...
Implementation Experience with Extension <ul><li>Examples of extension: </li></ul><ul><ul><li>IAP for MediaManager </li></...
Lessons learned: What was easy? <ul><li>Extension to include a new communication service or device </li></ul><ul><ul><li>B...
Scalability Analysis <ul><li>Shared infrastructure components </li></ul><ul><ul><li>Scaling and provisioning concerns </li...
Scalability Analysis: APC <ul><li>Performance for the following operators </li></ul><ul><ul><li>Null (copies input to outp...
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 simultaneo...
Calculation of Scaling <ul><li>On average </li></ul><ul><ul><li>2.8 calls/hour/user </li></ul></ul><ul><ul><li>Average dur...
Related Work: State-of-the-Art <ul><li>Commercial services </li></ul><ul><ul><li>Concentrate on functionality </li></ul></...
Summary <ul><li>Universal Inbox: metaphor for any-to-any communication and service access </li></ul><ul><li>Internet-based...
The ICEBERG Project http://iceberg.cs.berkeley.edu/ (Presentation running under VMWare under Linux)
Upcoming SlideShare
Loading in …5
×

Extensible Personal Mobility And Service Mobility In An Integrated Network

579 views

Published on

Published in: Technology, Business
  • Be the first to comment

Extensible Personal Mobility And Service Mobility In An Integrated Network

  1. 1. Universal Inbox: Extensible Personal Mobility and Service Mobility in an Integrated Network Bhaskaran Raman, Randy H. Katz, Anthony D. Joseph ICEBERG, EECS, U.C.Berkeley Home Phone Voice Mail Pager Cell Phone Office Phone Calls during business hours Calls in the evening Anonymous Calls Friends & family calls E-Mail Important e-mail headers E-mail access via phone
  2. 2. Motivating Scenario Personal Mobility Service Mobility
  3. 3. Problem Statement <ul><li>Requirement </li></ul><ul><ul><li>Service integration and personalization </li></ul></ul><ul><li>Goals </li></ul><ul><ul><li>Any-to-any capability </li></ul></ul><ul><ul><li>Extensibility : ease of adding new end-points </li></ul></ul><ul><ul><li>Scalability : global scale operation </li></ul></ul><ul><ul><li>Personal mobility and Service mobility </li></ul></ul>Communication devices Communication services
  4. 4. ICEBERG: An IP-Centric Middleware Approach ICEBERG Network (Internet) PSTN GSM Pager WaveLAN GSM PSTN
  5. 5. Internet-based Infrastructure <ul><li>Components in the Internet: open model </li></ul><ul><li>Leverage proxy and cluster architectures </li></ul><ul><li>Independent components: </li></ul><ul><ul><li>Can be independently and incrementally deployed </li></ul></ul>
  6. 6. Design Principles <ul><li>Separation of functionality </li></ul><ul><ul><li>Separation  independent and reusable components </li></ul></ul><ul><ul><li>Reuse  easy extensibility </li></ul></ul><ul><ul><li>Shared network services  Economy of scale </li></ul></ul><ul><li>Network and device independence </li></ul><ul><ul><li>Needed for extensibility to new devices </li></ul></ul><ul><li>Push control towards callee </li></ul><ul><ul><li>In current communication networks, caller has control </li></ul></ul><ul><ul><li>Callee needs to have control for flexible handling of incoming communication </li></ul></ul>
  7. 7. Caller Callee Data Transformation Name Mapping & Translation Preference Management An Example Scenario
  8. 8. Common Functionalities <ul><li>Any-to-any data transformation </li></ul><ul><ul><li>For communication between heterogeneous devices </li></ul></ul><ul><ul><li>Device data-type independence </li></ul></ul><ul><ul><li>Automatic Path Creation (APC) service </li></ul></ul><ul><li>User preference based ubiquitous redirection </li></ul><ul><ul><li>For personalization of communication </li></ul></ul><ul><ul><li>Achieves the “control to callee” design principle </li></ul></ul><ul><ul><li>Preference Registry service </li></ul></ul>
  9. 9. Common Functionalities <ul><li>Device name mapping and translation </li></ul><ul><ul><li>For dealing with multiple user identities and different name spaces </li></ul></ul><ul><ul><li>Device name independence </li></ul></ul><ul><ul><li>Naming service </li></ul></ul><ul><li>Also, gateways to access networks at different locations </li></ul><ul><ul><li>Provide network independence </li></ul></ul><ul><ul><li>ICEBERG Access Points </li></ul></ul>
  10. 10. Bhaskar’s Cell-Phone Barbara’s Desktop Illustrating Extensibility Automatic Path Creation Service 510-642-8248 UID: hohltb@cs.berkeley.edu Naming Service 1 hohltb: Prefers Desktop Preference Registry 2 3 MediaManager Mail Access Service
  11. 11. 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 1 2 MediaManager Mail Access Service 3 Bhaskar’s PSTN Phone
  12. 12. 510-642-8248 UID: hohltb@cs.berkeley.edu hohltb: Prefers Desktop Bhaskar’s Cell-Phone Barbara’s Desktop Naming Service Preference Registry Automatic Path Creation Service 1 Bhaskar’s PSTN Phone 2 3 MediaManager Mail Access Service
  13. 13. Extensibility <ul><li>Name-space </li></ul><ul><ul><li>Hierarchical </li></ul></ul><ul><ul><li>New name-spaces added by creating a new sub-tree at root </li></ul></ul><ul><li>Automatic Path Creation service </li></ul><ul><ul><li>Operators can be plugged in </li></ul></ul><ul><ul><li>Old operators are reusable </li></ul></ul><ul><li>Set of ICEBERG Access Points </li></ul><ul><ul><li>New IAPs can be added independent of existing ones </li></ul></ul><ul><ul><li>All old IAPs are reachable from the new one </li></ul></ul>IAP IAP IAP IAP IP-Addrs Tel. No:s Email-addrs Pager no:s
  14. 14. Implementation Experience <ul><li>Extensibility </li></ul><ul><ul><li>Universal Inbox set of features extended to many device and service end-points </li></ul></ul><ul><li>Scalability </li></ul><ul><ul><li>Components tested for latency and scaling bottlenecks </li></ul></ul>
  15. 15. 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
  16. 16. Implementation Experience with Extension <ul><li>Examples of extension: </li></ul><ul><ul><li>IAP for MediaManager </li></ul></ul><ul><ul><ul><li>Allow access to the MediaManager service </li></ul></ul></ul><ul><ul><ul><li>~ 700 lines of Java </li></ul></ul></ul><ul><ul><ul><li>No other component had to be touched </li></ul></ul></ul><ul><ul><li>Operators for G.723 </li></ul></ul><ul><ul><ul><li>Getting codec to work required effort </li></ul></ul></ul><ul><ul><ul><li>But, adding to APC was ~ two hours of work (  simple API for adding operators) </li></ul></ul></ul>
  17. 17. Lessons learned: What was easy? <ul><li>Extension to include a new communication service or device </li></ul><ul><ul><li>Build an IAP </li></ul></ul><ul><ul><li>Add appropriate operators </li></ul></ul>Effort involved in building a service is independent of the number of networks it is made available on
  18. 18. Scalability Analysis <ul><li>Shared infrastructure components </li></ul><ul><ul><li>Scaling and provisioning concerns </li></ul></ul><ul><li>Three shared core components are: </li></ul><ul><ul><li>APC </li></ul></ul><ul><ul><li>Preference Registry </li></ul></ul><ul><ul><li>Naming service </li></ul></ul>
  19. 19. Scalability Analysis: APC <ul><li>Performance for the following operators </li></ul><ul><ul><li>Null (copies input to output) </li></ul></ul><ul><ul><li>Toast (PCM to GSM) </li></ul></ul><ul><ul><li>Untoast (GSM to PCM) </li></ul></ul><ul><li>Path creation latency and throughput measured as a function of increasing load </li></ul><ul><li>500MHz Pentium-III 2-way multiprocessor running Linux-2.2 with IBM’s JDK 1.1.8 </li></ul>
  20. 20. Path Creation: Latency vs. Load Toast Operator Untoast Operator About 50ms latency for path creation
  21. 21. Path Creation: Throughput vs. Load Toast Operator Untoast Operator About 7.2 path creations/sec at a load of 64 simultaneous paths
  22. 22. Calculation of Scaling <ul><li>On average </li></ul><ul><ul><li>2.8 calls/hour/user </li></ul></ul><ul><ul><li>Average duration of calls (path) is 2.6 minutes </li></ul></ul><ul><li>Using these </li></ul><ul><ul><li>571 users can be supported by a two-node APC service </li></ul></ul><ul><ul><li>Telephone network uses expensive TRAU at the Inter-Working Function for these transformations </li></ul></ul>
  23. 23. Related Work: State-of-the-Art <ul><li>Commercial services </li></ul><ul><ul><li>Concentrate on functionality </li></ul></ul><ul><ul><li>No any-to-any capability </li></ul></ul><ul><li>Research projects </li></ul><ul><ul><li>Mobile People Architecture: Personal Proxies </li></ul></ul><ul><ul><li>Telephony Over Packet networkS </li></ul></ul><ul><ul><li>UMTS </li></ul></ul><ul><li>Not all issues addressed </li></ul><ul><ul><li>Infrastructure support for network integration </li></ul></ul><ul><ul><li>Extensibility </li></ul></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Personal mobility + Service mobility </li></ul></ul>
  24. 24. Summary <ul><li>Universal Inbox: metaphor for any-to-any communication and service access </li></ul><ul><li>Internet-based infrastructure </li></ul><ul><li>Personal mobility </li></ul><ul><ul><li>redirection by preference registry </li></ul></ul><ul><li>Service mobility </li></ul><ul><ul><li>result of the any-to-any capability </li></ul></ul><ul><li>Architecture viable for global operation </li></ul><ul><ul><li>IAPs can be developed and deployed by independent service providers </li></ul></ul><ul><li>Extensibility </li></ul><ul><ul><li>Made easy by the separation and reuse of functionality </li></ul></ul>
  25. 25. The ICEBERG Project http://iceberg.cs.berkeley.edu/ (Presentation running under VMWare under Linux)

×