what is iceberg about? anthony d. joseph randy h. katz
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
ICEBERG/Ericsson Review
21 August 2000
http://iceberg.cs.berkeley.edu/Cellular “Core” Network
Bridge to theFuture
S. S. 7
What is
ICEBERG About?
Anthony D. JosephRandy H. Katz
Agenda
• Motivation: Need for an IP-based Core• ICEBERG Project
– Strategy and Goals– Architectural Overview
• Platform Components• Applications• Testbed/Infrastructure• Status and Directions
Agenda
• Motivation: Need for an IP-based Core• ICEBERG Project
– Strategy and Goals– Architectural Overview
• Platform Components• Applications• Testbed/Infrastructure• Status and Directions
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
Core Network BecomesData-Oriented
IP-Based WAN
Local Exch Local ExchPSTN
Local SwitchIWF + Router
Local SwitchIWF + Router
Voice TrafficConnection-Oriented
Data TrafficPacket-Oriented
Local Gateway Local GatewayCore Network
AccessNetwork
AccessNetwork
Local ExchNet (LEC)
Local ExchNet (LEC)
InterexchangeNetwork (IXC)
Local Switch Local Switch
IP-Based WAN
Packet-OrientedVoIP Gateway VoIP Gateway
Core NetworkAccessNetwork
AccessNetwork
Router Router
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
• 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
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
Agenda
• Motivation: Need for an IP-based Core• ICEBERG Project
– Strategy and Goals– Architectural Overview
• Platform Components• Applications• Testbed/Infrastructure• Status and Directions
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
Policy-basedLocation-basedActivity-based
Empower users!
Speech-to-TextSpeech-to-Voice Attached-EmailCall-to-Pager/Email Notification
Email-to-SpeechAll compositions
of the above!
Universal Inbox
Motivation: System Support for Transparent Information
Access
Transformation and Redirection
IP CoreIP Core
PSTNPSTN
PagerPager
WLANWLANCellularNetwork
CellularNetwork
H.323GW
GW
GW
GW
iPOP
iPOP
iPOP
iPOPIAPTransducer
Agent
RedirectionAgent
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
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
OfficePSTN: 510-643-7212FaxPSTN: 510-643-7352DeskIP: rover.cs.berkeley.edu:555LaptopIP: fido.cs.berkeley.edu:555PCS: 510-388-7212E-mail: [email protected]: 510-555-1212
OfficePSTN: 510-643-7212FaxPSTN: 510-643-7352DeskIP: rover.cs.berkeley.edu:555LaptopIP: fido.cs.berkeley.edu:555PCS: 510-388-7212E-mail: [email protected]: 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 ofdomain-specific names
Service Mobility as aFirst-Class Object
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
• 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”
Jinidevices
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
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
Architectural Overview
Iceberg Network
PSTN GSM
PagerWaveLAN
GSM PSTN
IAP
IAP
IAP
IAP
IAP
IAP
iPOP iPOP
iPOP iPOP
Cal
StanfordNaming ServerPreference RegistryPersonal Activity TrackerAPC Server
Administrative Relationships
PSTN GSM PagerAccess Network
Plane
ICEBERG Network
Plane
A
B
IAP IAP
IAP
SF iPOP
NY iPOP
NY iPOP
SF iPOP
IAP IAP IAP
BasesActiveProxies
UnitsNinja ExecutionEnvironment
Control/Data Planes
Data PlaneOperators
Connectors
Paths
ControlPlane
IAP
PAC
APC
Pref
Reg
Namin
g Sv
c
Agenda
• Motivation: Need for an IP-based Core• ICEBERG Project
– Strategy and Goals– Architectural Overview
• Platform Components• Applications• Testbed/Infrastructure• Status and Directions
ICEBERG Control Plane
• Control Signaling + Automatic Path Compilation
• Name Lookup/Preference Registry • Clearinghouse
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
DataPath
DataPath
DataPath
Listen
Listen
Listen
IAP
IAP
IAP
iPOP HB
iPOP HBiPOP HB
HB
HBHB
Announce Announce
Announce
800-MEDIA-MGR UID: [email protected] 510-642-8248 UID: [email protected]
hohltb: Prefers Desktopmediamgr: Cluster locn.
Bhaskar’s Cell-Phone
Bhaskar’s PSTN Phone
Barbara’s Desktop
Naming Service
PreferenceRegistry
Automatic Path Creation Service
1122
33
MediaManager Mail Access Service
3’3’
Name Lookup/
PreferenceRegistry
Home Phone
Voice MailPager
Cell Phone Office Phone
Calls during business hours
Calls in theevening
AnonymousCalls
Friends & family calls
E-MailImportant
e-mail headers
E-mail accessvia 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 locationCallee state
PersonalActivity
Coordinator
Preference Registry
UserPreference
Profiles
OtherPersonal
State
Per Call Statee.g., Caller ID
Time of DayCaller End Point Type
Callee’s Preferred
End Point
Quality of Service Issues
Resource Reservation
ISP1ISP3
• 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
SLA
• In practice: SLAs are not precise• Also, how to provision across multiple domains?
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 LCHLCH
CH2
BD2
CH1CH1
LD2
LD1
Agenda
• Motivation: Need for an IP-based Core• ICEBERG Project
– Strategy and Goals– Architectural Overview
• Platform Components• Applications• Testbed/Infrastructure• Status and Directions
Data Transcoding Model
• Dynamic data transcoding– Source and target data format independence /
isolation
• Rapid support for new devices (new device in 2 hrs!)
UniversalInbox
MicrophoneCell phone
Response to Client
Automatic Path Creation
AudioIBM or
ICSISpeech
Recognizer
TextNatural
LanguageParser
Cmd
Control/Metadata
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 InterfaceMedia Manager
Service
Client
Client
Client
Folder Store
Mail Access Interface
POP
Mail Access Interface
IMAP
Price-Based Resource Allocation
• 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
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 PSTNH.323 Gateway
Example User Web Interface
Agenda
• Motivation: Need for an IP-based Core• ICEBERG Project
– Strategy and Goals– Architectural Overview
• Platform Components• Applications• Testbed/Infrastructure• Status and Directions
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
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
BSC MSC
GSM Network
TCP statsRLP statsTCP / RLP stats
Post-processing tool(120 bytes/s)
TCP and RLP Data PlotSent 30,720 bytes from mobile host to stationary
host
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
0 5 10 15 20 25 30 35 40
Seconds
By
tes
TCP Bytes
TCP Acks
RLP Bytes
RLP Ack
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)
GSM BTS-IP Integration
RBS2202
UPSim
Ethernet
IP-PAD
Traffic
SignalingE1
Control Signaling
GSM Phone
E1: Voice @ 13kb/s Data @ 12kb/s
VAT
Internet
PC
Interactive Voice Response
Infocaster
H.323 GW
NetMeetingUses OM & TRAFFIC to simulate BSC, MSC, and HLR functionality
PSTN
2 TRX
GPC boardThor-2
Performs rate adaptation function of ZAK/TRAU
H.323GW
Experimental HW/SW Testbed
SimMillenniumNetwork
Infrastructure
Millennium Cluster
Millennium Cluster
WLAN /Bluetooth
IBMWorkPad
2 GSM BTS
CF788
Pager
MotorolaPagewriter 2000306 Soda
326 Soda “Colab”
405 Soda
Smart Spaces
@Home, DSL
MC-16
VeloNino
DAB BTS
Simulation and monitoring software
Agenda
• Motivation: Need for an IP-based Core• ICEBERG Project
– Strategy and Goals– Architectural Overview
• Platform Components• Applications• Testbed/Infrastructure• Status and Directions
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/– [email protected]
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
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
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
Plan for the Review
Monday 21 August 200010:00 - 12:00 Design Decisions/Lessons Learned (UCB students)
13:00 - 15:00 Design Decisions/Lessons Learned (UCB students)
Tuesday 22 August 200010: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