1 / 48

What is ICEBERG About? Anthony D. Joseph Randy H. Katz

Bridge to the Future. What is ICEBERG About? Anthony D. Joseph Randy H. Katz. S. S. 7. ICEBERG/Ericsson Review 21 August 2000 http://iceberg.cs.berkeley.edu/. Cellular “Core” Network. Agenda. Motivation: Need for an IP-based Core ICEBERG Project Strategy and Goals

jada-chandler
Download Presentation

What is ICEBERG About? Anthony D. Joseph Randy H. Katz

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. Bridge to the Future What isICEBERG About?Anthony D. JosephRandy H. Katz S. S. 7 ICEBERG/Ericsson Review 21 August 2000 http://iceberg.cs.berkeley.edu/ Cellular “Core” Network

  2. Agenda • Motivation: Need for an IP-based Core • ICEBERG Project • Strategy and Goals • Architectural Overview • Platform Components • Applications • Testbed/Infrastructure • Status and Directions

  3. Agenda • Motivation: Need for an IP-based Core • ICEBERG Project • Strategy and Goals • Architectural Overview • Platform Components • Applications • Testbed/Infrastructure • Status and Directions

  4. An Internet-basedOpen Services Architecture “Today, the telecommunications sector is beginning to reshape itself, from a vertically to a horizontally structured industry. … [I]t used to be that new capabilities were driven primarily by the carriers. Now, they are beginning to be driven by the users. … There’s a universe of people out there who have a much better idea than we do of what key applications are, so why not give those folks the opportunity to realize them. … The smarts have to be buried in the ‘middleware’ of the network, but that is going to change as more-capable user equipment is distributed throughout the network. When it does, the economics of this industry may also change.” George Heilmeier, Chairman Emeritus, Telcordia

  5. Local Switch Local Switch Interexchange Network (IXC) PSTN Voice Traffic Connection-Oriented Local Switch IWF + Router Local Switch IWF + Router Local Exch Net (LEC) Local Exch Net (LEC) Local Exch Local Exch Data Traffic Packet-Oriented IP-Based WAN Access Network Access Network Local Gateway Local Gateway Core Network Core Network BecomesData-Oriented

  6. Core Network BecomesData-Oriented • Appl-specific routing overlays, e.g., info dissemination • Routing infrastructure with DiffServ support • Service-level agreements spanning multiple ISPs • Services running on servers in the infrastructure VoIP Gateway VoIP Gateway Packet-Oriented IP-Based WAN Router Router Access Network Access Network Core Network

  7. PDA PCS Qualcomm PDQ Phone Smart Appliances/Thin Clients

  8. Top Gun MediaBoard • Participates as a reliable multicast client via proxy in wireline network • Top Gun Wingman • “Thin” presentation layer in PDA with full rendering engine in wireline proxy

  9. Critical Trends • Multimedia / Voice over IP networks • Lower cost, more flexible packet-switching core network • Simultaneous support for delay sensitive and delay insensitive flows via differentiated services • Intelligence shifts to the network edges • Third-party functionality downloaded into Information Appliances like PalmPilots • Programmable intelligence inside the network • Proxy servers intermixed with switching infrastructure • Mobile/extensible code, e.g., JAVA: “write once, run anywhere” • Rapid new service development • Speech-based services

  10. Agenda • Motivation: Need for an IP-based Core • ICEBERG Project • Strategy and Goals • Architectural Overview • Platform Components • Applications • Testbed/Infrastructure • Status and Directions

  11. ICEBERG: Internet-based core for CEllular networks BEyond the thiRd Generation • 3G+ networks will enable many communications devices and networks • Project Goals: • From specific devices/networks to universal endpoint access • Access to people and services across diverse networks • Service level mobility (Cross device/network service handoff) • Leverage infrastructure to “track” users’ activities/location • Rapid easy development/deployment of novel, innovative, composable services and new devices • Develop services on Internet (not Telco) time • Scalable, robust, secure architecture • Support third-party service providers

  12. Universal Inbox Motivation: System Support for Transparent Information Access 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 Empower users!

  13. Transducer Agent iPOP IAP iPOP iPOP iPOP Redirection Agent Transformation and Redirection Pager IP Core GW Cellular Network WLAN GW GW H.323 GW PSTN

  14. ICEBERG’s Strategy • Make it real: build a large-scale testbed • Time travel: bring the future to the present • Collect “real” information about systems • On-going VoIP, cellular experiments • Prototype release • Users (students) develop new/interesting applications • Understanding several key research areas • Core signaling protocol, Personal Activity Coordinator • Multi-modal services: Speech control / Information dissemination • Service mobility: Location-based services, Universal Inbox • Scheduling and multi-layer wireless link issues

  15. ICEBERG’s Design Goals • Potentially Any Network Services (PANS) • Any service can from any network by any device; network/device independence in system design • Personal Mobility • Person as communication endpoint with single identity • Service Mobility • Retain services across networks • Easy Service Creation and Customization • Allow callee control & filtering • Scalability, Availability, Fault Tolerance • Security, Authentication, Privacy

  16. Service Mobility as aFirst-Class Object Universal Names: Globally unique IDs “Anthony@Berkeley” OfficePSTN: 510-643-7212 FaxPSTN: 510-643-7352 DeskIP: rover.cs.berkeley.edu:555 LaptopIP: fido.cs.berkeley.edu:555 PCS: 510-388-7212 E-mail: adj@cs.berkeley.edu Home: 510-555-1212 An Entity has a universal name and a profile; Entities are people or processes Profile: set of domain-specific names

  17. Focus on Support for Compelling New Services • Encapsulating complex data transformations • Speech-to-text, text-to-speech • Composition of services • Voice mail-to-email, email-to-voice mail • Location-aware information services • E.g., traffic reports • Multicast-enabled information services • Multilayered multicast: increasing level of detail as number of subscribed layers increase

  18. Bases (1M’s) • scalable, highly available • persistent state (safe) • databases, agents • “home” base per user • service programmingenvironment Wide-Area Path • Active Proxies (100M’s) • not packet routers, may beactive networking nodes • bootstrap thin devices into infrastructure • soft-state and well-connected • Units (1B’s) • sensors / actuators • PDAs / smartphones / PCs • heterogeneous • Minimal functionality: “Smart Clients” Jini devices NINJA Distributed Computing Platform

  19. ICEBERG Components • Releases: http://iceberg.cs.berkeley.edu/release/ • June 2000 v0.0 alpha “reading” release • October 2000 v1.0 first true release • Execution platform • Operational software/middleware • Control model (protocol, resource allocation/management) • Data transcoding model • Service creation environment • Applications • Universal Inbox, Media Manager • IP-telephony • Networking infrastructure • Testbed/simulation and tracing • Video coding and transport

  20. Architectural Elements • ICEBERG Access Point (IAP) • Encapsulates network specific gateway (control and data) • ICEBERG Point of Presence (iPOP) • Performs detailed signaling • Call Agent: per communication device per call party • Call Agent Dispatcher: deploy call agent • Name Mapping Service • Mapping between iUID (Iceberg Unique ID) and service end point • Preference Registry • Contains user profile including service subscription, configuration and customization • Person Activity Coordinator (PAC) • Tracks dynamic information about user of interest • Automatic Path Creation Service • Creates datapath among participants’ communications devices

  21. IAP IAP iPOP iPOP IAP IAP iPOP iPOP IAP IAP Naming Server Preference Registry Personal Activity Tracker APC Server Architectural Overview GSM PSTN WaveLAN Pager Iceberg Network Cal GSM PSTN Stanford

  22. PSTN GSM Pager A NY iPOP IAP IAP IAP IAP IAP SF iPOP IAP B NY iPOP SF iPOP Administrative Relationships Access Network Plane ICEBERG Network Plane

  23. Connectors Data Plane Operators APC Paths IAP PAC Pref Reg ActiveProxies Naming Svc Bases Control Plane Ninja Execution Environment Units Control/Data Planes

  24. Agenda • Motivation: Need for an IP-based Core • ICEBERG Project • Strategy and Goals • Architectural Overview • Platform Components • Applications • Testbed/Infrastructure • Status and Directions

  25. ICEBERG Control Plane • Control Signaling + Automatic Path Compilation • Name Lookup/Preference Registry • Clearinghouse

  26. Announce Announce Listen Listen Data Path Data Path Announce Listen HB HB iPOP HB iPOP HB HB Data Path Iceberg Signaling Protocol: Capturing Session State with Soft State Call Agent Call Agent Session state Session state Comm Session iPOP iPOP IAP IAP Call Agent Session state IAP iPOP iPOP HB

  27. Bhaskar’s PSTN Phone Naming Service 800-MEDIA-MGR UID: mediamgr@cs.berkeley.edu 510-642-8248 UID: hohltb@cs.berkeley.edu 2 PreferenceRegistry Barbara’s Desktop 1 3 hohltb: Prefers Desktop mediamgr: Cluster locn. Bhaskar’s Cell-Phone 3’ Automatic Path Creation Service MediaManager Mail Access Service

  28. 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 Name Lookup/PreferenceRegistry IF (9AM < hour < 5 PM) THEN Preferred-End-Point = Office-Phone IF (5 PM < hour < 11 PM) THEN Preferred-End-Point = Home-Phone IF (11 PM < hour < 9 AM) THEN Preferred-End-Point = Voice-Mail Personal Activity Coordinator Other Personal State Callee location Callee state Preference Registry Per Call State e.g., Caller ID Time of Day Caller End Point Type Callee’s Preferred End Point User Preference Profiles

  29. SLA SLA ? ? • In practice:SLAs are not precise • Also, how to provision across multiple domains? Quality of Service Issues Alice ISP2 Bob • How to support QoS for real-time applications over IP-networks? • SLAs describe acceptable traffic volume/rate, and expected performance assurance ISP1 ISP3 Resource Reservation Charlie

  30. LD1 LCH LCH LCH CH1 CH1 LD2 CH2 Clearing House Architecture Bob Alice Edge Router BD n BD2 • Introduce logical hierarchy • Dist db (reservations, link utilization, net performance) • Separate reservation and call-setup • Aggregation of reservation requests BD1

  31. Agenda • Motivation: Need for an IP-based Core • ICEBERG Project • Strategy and Goals • Architectural Overview • Platform Components • Applications • Testbed/Infrastructure • Status and Directions

  32. IBM or ICSI Speech Recognizer Natural Language Parser Text Control/Metadata Data Transcoding Model • Dynamic data transcoding • Source and target data format independence / isolation • Rapid support for new devices (new device in 2 hrs!) E-Mail Automatic Path Creation Universal Inbox Cmd Audio Microphone Cell phone Response to Client

  33. Media Manager Client Client Folder Store Client Media Manager Interface • Transcoder Services • Voicemail -> Text Transcript • Voicemail -> Text Summary • Voicemail ->Text Outline • Email -> Plain Audio • Email -> GSM Audio • Voicemail -> GSM Summary • Voicemail -> Audio Summary • Voicemail -> Skimmed Audio Media Manager Service Mail Access Interface Mail Access Interface Mail Access Interface NinjaMail POP IMAP

  34. IP Telephone • Need overview slide

  35. Price-Based Resource Allocation Example User Web Interface • IP telephony application • Price based on load • Congestion-based model • Exploring userreactions to pricing • Status: • 23 phone lines • 50 ugrad users (Sp’00) • ~700 ugrads (Fa’00) Current Price for Using Your Computer: 10 Tokens/min Next Minute Price for Using Your Computer: 20 Tokens/min Current Price for Using Your Telephone: 15 Tokens/min Next Minute Price for Using Your Telephone: 35 Tokens/min Packet Loss Rate When Using Your Computer: 3% Handoff the Current Call to Your Telephone: (510) 642-8919 Yes? H.323 Gateway PSTN Internet Handoff the Current Call to Your Computer: center.cs.berkeley.edu Yes?

  36. Agenda • Motivation: Need for an IP-based Core • ICEBERG Project • Strategy and Goals • Architectural Overview • Platform Components • Applications • Testbed/Infrastructure • Status and Directions

  37. Wireless Link Management • Modeling GSM media access, link, routing, and transport layers • Validated ns modeling suite and BONES simulator • GSM channel error models from Ericsson • QoS and link scheduling for next generation links • High Speed Circuit Switched Data (HSCSD), General Packet Radio System (GPRS), and Wideband CDMA (W-CDMA) • RSVP signaling integration with bottleneck link scheduling • Reliable Link Protocols • Wireless links have high error rates (> 1%) • Reliable transport protocols (TCP) interpret errors as congestion • Solution is ARQ protocol, but retransmissions introduce jitter

  38. RLP-TCP Collection & Analysis Tools • RLP and TCP interaction measurement / analysis • Both are reliable protocols (link and transport layers) • Trace analysis tool to determine current interaction effects • Trace collection/analysis for design of next generation networks TCP: End-to-End Reliability RLP: Wireless Reliability GSM Network BTS BSC MSC RLP stats TCP / RLP stats TCP stats Post-processing tool (120 bytes/s)

  39. TCP and RLP Data PlotSent 30,720 bytes from mobile host to stationary host

  40. Wireless Video Streaming • Goal: Flexible networking protocols in support of error resilient video codecs • GSM RLP: reliable data delivery on radio link • Issue: reliability versus delay • UDP Lite (existing protocol) • Flexible checksum allows app to receive corrupted data • RLP Lite (new protocol) • Same as UDP Lite, but for radio link • Simulation/experimental results: UDP Lite/RLP lite • less E2E delay, constant jitter, higher throughput, lower packet loss • … than UDP (with or without RLP) • Collecting radio traces is time consuming • MTA – Markov-Based Trace Analysis Algorithm • Mathematical channel models based on empirical trace measurements • Enables generation of artificial traces with same statistical characteristics as real traces (BER, burst error length, etc)

  41. GSM BTS-IP Integration Interactive Voice Response Uses OM & TRAFFIC to simulate BSC, MSC, and HLR functionality Infocaster NetMeeting VAT PC 2 TRX Control Signaling Internet IP-PAD Signaling UPSim RBS 2202 Thor-2 E1 GPC board Ethernet Traffic E1: Voice @ 13kb/s Data @ 12kb/s GSM Phone Performs rate adaptation function of ZAK/TRAU PSTN H.323 GW

  42. IBM WorkPad Velo Nino MC-16 Motorola Pagewriter 2000 CF788 Pager WLAN / Bluetooth 306 Soda 405 Soda @Home, DSL H.323 GW 326 Soda “Colab” 2 GSM BTS Smart Spaces SimMillennium Network Infrastructure Millennium Cluster DAB BTS Millennium Cluster Experimental HW/SW Testbed Simulation and monitoring software

  43. Agenda • Motivation: Need for an IP-based Core • ICEBERG Project • Strategy and Goals • Architectural Overview • Platform Components • Applications • Testbed/Infrastructure • Status and Directions

  44. Implementation and Current Status • Version 0 Release: June 2000 • Functional implementations of major architectural components: Call Agent, Preference Registry, Preference Manager, Automatic Path Creation, Name Mapping Service • Support for VAT IPphones, GSM cell phones, instant messaging, Ninja Jukebox, multimodal email access • Service handoff between IPphones and GSM cell phones • Callee preferences via GUI or script • Ninja ISpace implementation limits performance; Version 1 Release on VSpace 2, with better fail over/scalability features & reduced IPC latencies • Release information: • http://iceberg.cs.berkeley.edu/release/ • iceberg-devel@iceberg.cs.berkeley.edu

  45. Current Status and Directions • Iceberg testbed development • Alpha release June 2000 (http://iceberg.cs.berkeley.edu/release/) • Installed indoor 1900MHz GSM network in Soda Hall • Installing outdoor 1800MHz GSM and 900MHz 2-way paging • H.323 VoIP and billing experiments: 50 users  700 in fall • Universal Inbox prototype using Media Manager: GSM, VAT, Voicemail • Call signaling prototype built on Ninja iSpace using Java (~5000 lines) • Clearinghouse simulations • Day-to-day use and project platform for several classes • Current focus • Public software Version 1 Release: 1 October 2000 • Call-setup protocols • Billing, authentication, security, and operations & maintenance • Automatic path creation: Placing operators

  46. Current Status and Directions • Large-scale testbed deployment is progressing well • Lots of work by the students during the summer • BTS-IP integration progressing • Iceberg testbed will be mostly completed this fall • Testbed will enable development of new protocols • Lots of on-going design work • Automatic path creation • Service handoff: Passing metadata across/through networks • IVR: More applications and devices (WindowsCE) • Service location and discovery • Query model and security • RLP implementation in IP-PAD

  47. Conclusions • Emerging Network-centric Distributed Architecture spanning processing and access • Open, composable services architecture--the wide-area “operating system” of the 21st Century • Beyond the desktop PC: information appliances supported by infrastructure services--multicast real-time media plus proxies for any-to-any format translation and delivery to diverse devices • Common network core: optimized for data, based on IP, enabling packetized voice, supporting user, terminal, and service mobility

  48. Plan for the Review Monday 21 August 2000 10:00 - 12:00 Design Decisions/Lessons Learned (UCB students) 13:00 - 15:00 Design Decisions/Lessons Learned (UCB students) Tuesday 22 August 2000 10:00 - 12:00 Developers WorkshopICEBERG Control Plane: Control Signaling + Automatic Path Compilation; Name Lookup/Preference Registry; ClearinghouseICEBERG Applications: Universal Inbox/Media Manager;ICEBERG Infrastructure & User Plane: IP Telephony/Testbed; Transport/Video; Analysis Tools 13:00 - 14:30 Brainstorming on Future Directions

More Related