1. ICEBERG/Ericsson Review 21 August 2000 http://iceberg.cs.berkeley.edu/ Cellular “Core” Network Bridge to the Future S. S. 7 What is ICEBERG About? Anthony D. Joseph Randy H. Katz

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-based Open 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. Core Network Becomes Data-Oriented IP-Based WAN Local Exch PSTN Local Switch IWF + Router Local Switch IWF + Router Voice Traffic Connection-Oriented Data Traffic Packet-Oriented Local Gateway Core Network Access Network Access Network Local Exch Net (LEC) Local Exch Net (LEC) Interexchange Network (IXC) Local Switch

6. IP-Based WAN Packet-Oriented VoIP Gateway Core Network Access Network Access Network Router Core Network Becomes Data-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

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

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. Policy-based Location-based Activity-based Empower users! Speech-to-Text Speech-to-Voice Attached-Email Call-to-Pager/Email Notification Email-to-Speech All compositions of the above! Universal Inbox Motivation: System Support for Transparent Information Access

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

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. 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 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 “Anthony@Berkeley” An Entity has a universal name and a profile; Entities are people or processes Universal Names: Globally unique IDs Profile: set of domain-specific names Service Mobility as a First-Class Object

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 programming environment Wide-Area Path Active Proxies (100M’s) –not packet routers, may be active networking nodes –bootstrap thin devices into infrastructure –soft-state and well-connected NINJA Distributed Computing Platform Units (1B’s) –sensors / actuators –PDAs / smartphones / PCs –heterogeneous –Minimal functionality: “Smart Clients” Jini devices

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. Architectural Overview Iceberg Network PSTN GSM Pager WaveLAN GSMPSTN IAP iPOP Cal Stanford Naming Server Preference Registry Personal Activity Tracker APC Server

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

23. Control/Data Planes Bases Active Proxies Units Ninja Execution Environment Data Plane Operators Connectors Paths Control Plane IAP PAT PRLS APC Pref Reg Name Svc

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. Iceberg Signaling Protocol: Capturing Session State with Soft State iPOP Call Agent Session state iPOP Session state iPOP Call Agent Session state Comm Session Call Agent Data Path Data Path Data Path Listen IAP iPOP HB HB Announce

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

28. Name Lookup/ Preference Registry 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 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 Callee location Callee state Personal Activity Coordinator Preference Registry User Preference Profiles Other Personal State Per Call State e.g., Caller ID Time of Day Caller End Point Type Callee’s Preferred End Point

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

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

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

33. Media Manager 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 Mail Access Interface NinjaMail Media Manager Interface Media Manager Service Client Folder Store Mail Access Interface POP Mail Access Interface IMAP

34. IP Telephone Need overview slide

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

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 BTS TCP: End-to-End Reliability RLP: Wireless Reliability BSCMSC GSM Network TCP stats RLP stats TCP / RLP stats Post-processing tool (120 bytes/s)

39. TCP and RLP Data Plot Sent 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 RBS 2202 UPSim Ethernet IP-PAD Traffic Signaling E1 Control Signaling GSM Phone E1: Voice @ 13kb/s Data @ 12kb/s VAT Internet PC Interactive Voice Response Infocaster H.323 GW NetMeeting Uses OM & TRAFFIC to simulate BSC, MSC, and HLR functionality PSTN 2 TRX GPC board Thor-2 Performs rate adaptation function of ZAK/TRAU

42. H.323 GW Experimental HW/SW Testbed SimMillennium Network Infrastructure Millennium Cluster WLAN / Bluetooth IBM WorkPad 2 GSM BTS CF788 Pager Motorola Pagewriter 2000 306 Soda 326 Soda “Colab” 405 Soda Smart Spaces @Home, DSL MC-16 Velo Nino DAB BTS 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 Workshop ICEBERG Control Plane: Control Signaling + Automatic Path Compilation; Name Lookup/Preference Registry; Clearinghouse ICEBERG Applications: Universal Inbox/Media Manager; ICEBERG Infrastructure & User Plane: IP Telephony/Testbed; Transport/Video; Analysis Tools 13:00 - 14:30 Brainstorming on Future Directions