1 / 9

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. State-of-the-Art.

dimaia
Télécharger la présentation

Problem Statement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. Key Ideas • 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 separate infrastructure components • Reusable pieces • Extensibility is easier: just add to the piece that requires extension

  4. Bhaskar’s PSTN Phone Name Mapping Service 800-MEDIA-MGR UID: mediamgr@cs.berkeley.edu 510-642-8248 UID: hohltb@cs.berkeley.edu Any-to-any Communication 2 3 1 IAP Preference Registry Barbara’s Desktop hohltb: Prefers Desktop mediamgr: Cluster locn. IAP Bhaskar’s Cell-Phone 3’ Automatic Path Creation Service IAP IAP MediaManager Mail Access Service

  5. 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 Universal Inbox: Personal Mobility and Service Mobility in an Integrated Network Bhaskaran Raman ICEBERG, EECS, U.C.Berkeley

  6. Tel. No:s Pager no:s Email-addrs IP-Addrs 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

  7. Implementation Experience • Testbed with GSM cell-phones and VoIP end-points • Components on top of Ninja 1.5 (iSpace) • 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)

  8. 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

  9. 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 depoyled by independent service providers • Extensibility • Made easy by the separation and reuse of functionality • Open Questions • Security issues • Billing issues

More Related