1 / 25

ICEBERG Release

ICEBERG Release. Version 0. The ICEBERG Team. Summer 2000 Retreat. Overview. Background Components in the release Feature set Interfaces APIs for extension Limitations Plans for next release. IAP. IAP. IAP. IAP. ICEBERG Goals: P otentially A ny N etwork S ervice.

merrillj
Download Presentation

ICEBERG Release

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. ICEBERG Release Version 0 The ICEBERG Team Summer 2000 Retreat

  2. Overview • Background • Components in the release • Feature set • Interfaces • APIs for extension • Limitations • Plans for next release The ICEBERG Team, Summer 2000 Retreat

  3. IAP IAP IAP IAP ICEBERG Goals: Potentially Any Network Service Same service in different networks Service handoff between networks 2-way Paging PSTN GSM/CDMA • Extensible network environment • Addressing access-device and access-network heterogeneity IP IAP WIP High BW IP core Diverse access links The ICEBERG Team, Summer 2000 Retreat

  4. Universal Inbox ICEBERG Goals: Personal Mobility Speech-to-Text Speech-to-Voice-Attached-Email Call-to-Pager/Email-Notification Email-to-Speech All compositions of the above! Policy-based Location-based Activity-based The ICEBERG Team, Summer 2000 Retreat

  5. ICEBERG Goals • Go beyond 3rd generation cellular • Infrastructure for hybrid services • Work in the wide-area • Ease of deployment • Robust signaling, high availability • Secure billing issues The ICEBERG Team, Summer 2000 Retreat

  6. A IAP IAP IAP IAP IAP IAP B CA PR PAC APC NMS ICEBERG Architecture: An Overview Access Network Plane PSTN GSM Pager ICEBERG Network Plane SF iPOP NY iPOP SF iPOP NY iPOP Clearing House ISP Plane ISP1 ISP2 ISP3 The ICEBERG Team, Summer 2000 Retreat

  7. Components in the Release Client IAPs Outgoing calls Call Agent (CA) ICEBERG Access Points (IAPs) Preference Registry (PR) Automatic Path Creation Service (APC) Incoming calls Name Mapping Service (NMS) Server IAPs ICEBERG Point of Presence (iPOP) The ICEBERG Team, Summer 2000 Retreat

  8. Components in the Release VAT IAP VAT GSM GSM IAP Testbed CA Jukebox IAP Ninja PR Jukebox Pref. Mgr. GUI MediaManager IAP APC Voice-Mail IAP MediaManager NMS Service Mail-push Client IAP iPOP Voice-Mail Mail-store The ICEBERG Team, Summer 2000 Retreat

  9. Requirements • Ninja 1.5 • iSpace for service platform • NinjaRMI for communication • Hardware • Linux cluster • Scaling not too good • Use of NinjaRMI • Process-per-operator-per-path model for APC The ICEBERG Team, Summer 2000 Retreat

  10. Capabilities: Any-to-Any Communication Calls from friends Anonymous callers Emails from important business associates Calls during office hours Read email through MediaManager Preference-based redirection Device-type and name independence The ICEBERG Team, Summer 2000 Retreat

  11. Capabilities: Service Handoff The ICEBERG Team, Summer 2000 Retreat

  12. Capabilities: Service Handoff The ICEBERG Team, Summer 2000 Retreat

  13. Capabilities: Adding new IAPs H.323 IAP Stock Quotes IAP Push iPOP Access Yahoo Calendar IAP The ICEBERG Team, Summer 2000 Retreat

  14. Capabilities: Adding to APC Front-end Back-end APC Operators + Connectors PCM GSM RMI MP3 PCM UDP Text PCM RTP PCM G.723 The ICEBERG Team, Summer 2000 Retreat

  15. Overview • Background • Components in the release • Feature set • Interfaces • APIs for extension • Limitations • Plans for next release The ICEBERG Team, Summer 2000 Retreat

  16. Interfaces between Components NMS1 NMS2 PR1 PR2 CA 1 CA 2 IAP 1 IAP 2 APC 1 APC 2 NinjaRMI Soft-state signaling for session maintenance The ICEBERG Team, Summer 2000 Retreat

  17. Interfaces with Specific Services • APC Service • int createPath(source, destination)  returns pathID • Source and Destination description: • Machine address • Connector specification: RMI/UDP/HTTP/RTP • void destroyPath(int pathID) • void changePath(int pathID, newSrc) • MediaManager Service • String[] getFolders(username) • MediaMessage[] getList(username, folder, num-msgs) • ContentObject getMsgContent(contentID, int type)  returns one of: • text transcript, text summary, audio summary • multiple audio formats possible The ICEBERG Team, Summer 2000 Retreat

  18. API’s for Extension: Adding IAPs Setup(), Terminate(), DTMF(), ServiceHandoff() CA Setup(), Terminate(), DTMF() APC Generic part Device- or service-specific part StartConnection(), CleanUp() Extend IAPWithCA Implement IAPIF The ICEBERG Team, Summer 2000 Retreat

  19. API’s for Extension: Adding Operators • Specify I/O types • Specify ADU size • For process-based operators: • Java-wrapper around executable • I/O in STDIN/STDOUT • Specify executable • G.723 codec added in 2hrs APC Operator 1 New Operator Operator 2 Operator 3 Extend Operator Implement OperatorIF The ICEBERG Team, Summer 2000 Retreat

  20. Overview • Background • Components in the release • Feature set • Interfaces • APIs for extension • Limitations • Plans for next release The ICEBERG Team, Summer 2000 Retreat

  21. UDP Any UDP Any Limitations in v0 • No heart-beat between IAP and CA • require iPOP in a vSpace cluster • IAP stub communicates with periodic state updates (keep-alive messages) • APC supports only UDP connectors between operators The ICEBERG Team, Summer 2000 Retreat

  22. Limitations in v0 (Continued) • APC issues • ties operators to specific connectors • process per operator model (scaling problems) • pipes for communication (huge delays due to buffering) • path restricted within a cluster • Issues with path control • hard-state protocol for setup and tear-down (easy to fix) • no flow control (more difficult to fix) The ICEBERG Team, Summer 2000 Retreat

  23. CA 2 IAP 1 CA 1 IAP 2 Limitations in v0 (Continued) • Naming service not distributed • Soft-state update not enough for user-level signaling between end-points • need reliable propagation • need instantaneous propagation • e.g., DTMF The ICEBERG Team, Summer 2000 Retreat

  24. Plans for Next Release • Port to vSpace • fault-tolerant communication between the IAP and the CA • inherit scaling features • Fix (some of) APC issues • remove process-per-operator model • remove coupling between operators and connectors • soft-state for path maintenance The ICEBERG Team, Summer 2000 Retreat

  25. Feedback • Evaluation strategy • Security issues • Things to fix in next release • Thoughts on more IAPs • Deployment issues Questions... http://iceberg.cs.berkeley.edu/release/ The ICEBERG Team, Summer 2000 Retreat

More Related