Transcript randy-iceberg00

Bridge to the
Future
What is
ICEBERG About?
Anthony D. Joseph
Randy H. Katz
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
– 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-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
Core Network Becomes
Data-Oriented
Local Switch
Local Exch
Net (LEC)
Local Switch
IWF + Router
Interexchange
Network (IXC)
Local Exch
Net (LEC)
Voice Traffic
Connection-Oriented
Local Exch
Local Switch
PSTN
Local Switch
IWF + Router
Local Exch
Data Traffic
Packet-Oriented
Access
Network
IP-Based WAN
Local Gateway
Core Network
Local Gateway
Access
Network
Core Network Becomes
Data-Oriented
VoIP Gateway
Packet-Oriented
VoIP Gateway
IP-Based WAN
Router
Access
Network
•
•
•
•
Router
Core Network
Access
Network
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
Smart Appliances/Thin Clients
PDA
PCS
Qualcomm PDQ Phone
• Top Gun Wingman
– “Thin” presentation layer in PDA
with full rendering engine in
wireline proxy
• Top Gun MediaBoard
– Participates as a reliable
multicast client via proxy in
wireline network
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
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!
Universal Inbox
Policy-based
Location-based
Activity-based
Empower users!
Transformation and Redirection
Pager
GW
Cellular
Network
iPOP
IAP
Transducer
Agent
iPOP
GW
iPOP
IP Core
Redirection
iPOP
Agent
H.323
GW
PSTN
WLAN
GW
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
Service Mobility as a
First-Class Object
“Anthony@Berkeley”
Universal Names: Globally unique IDs
An Entity has a universal
name and a profile; Entities
are people or processes
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: [email protected]
Home: 510-555-1212
Profile: set of
domain-specific names
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
NINJA Distributed Computing Platform
• 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
• Units (1B’s)
–
–
–
–
sensors / actuators
PDAs / smartphones / PCs
heterogeneous
Minimal functionality:
“Smart Clients”
Jini
devices
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
PSTN
IAP
IAP
Pager
IAP
GSM
iPOP
iPOP
IAP
Iceberg Network
iPOP
iPOP
IAP
GSM
WaveLAN
IAP
PSTN
Naming Server
Preference Registry
Personal Activity Tracker
APC Server
Cal
Stanford
Administrative Relationships
Access Network
Plane
PSTN
GSM
IAP IAP IAP
ICEBERG
Network
Plane
IAP
A
SF iPOP
Pager
IAP
NY iPOP
IAP
SF iPOP
B
NY iPOP
Control/Data Planes
Data Plane
Operators
Connectors
APC
Paths
IAP
PAC
Ninja Execution
Environment
Bases
Active
Proxies
Units
Control
Plane
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
Call
Agent
Announce
Announce
Call
Agent
Session state
Session state
Listen
Data
Path
iPOP
HB
iPOP HB
IAP
Comm Session Listen
Announce
Listen
Call
Agent
Session state
iPOP
Data
Path
Data
Path
HB
iPOP
iPOP HB
IAP
HB
IAP
iPOP HB
Naming Service
800-MEDIA-MGR
UID: [email protected]
510-642-8248
UID: [email protected]
1
Preference
Registry
2
Barbara’s
Desktop
3
hohltb: Prefers Desktop
mediamgr: Cluster locn.
Bhaskar’s
Cell-Phone
3’
Automatic
Path
Creation
Service
Bhaskar’s
PSTN Phone
MediaManager
Mail Access
Service
Friends &
family calls
Calls during
business hours
Cell Phone
E-mail access
via phone
Office Phone
Name Lookup/
Preference
Registry
Home Phone
Calls in the
evening
E-Mail
Important
e-mail headers
Pager
Voice Mail
Anonymous
Calls
Personal
Activity
Coordinator
Callee location
Callee state
Per Call State
e.g., Caller ID
Other
Personal
State
Preference
Registry
User
Time of Day
Caller End Point Type Preference
Profiles
IF (9AM < hour < 5 PM)
THEN Preferred-EndPoint = Office-Phone
IF (5 PM < hour < 11 PM)
THEN Preferred-EndPoint = Home-Phone
IF (11 PM < hour < 9 AM
THEN Preferred-EndPoint = Voice-Mail
Callee’s Preferred
End Point
Quality of Service Issues
Alice
ISP2
SLA
?
?
SLA
ISP1
Charlie
Bob
Resource
Reservation
ISP3
• How to support QoS for real-time applications
over IP-networks?
• SLAs describe acceptable traffic volume/rate,
and expected performance assurance
• In practice: SLAs are not precise
• Also, how to provision across multiple domains?
Clearing House Architecture
Alice
Bob
LD1
Edge Router
BD n
BD2
LCH
LCH
LCH
BD1
CH1
CH1
CH2
•
•
•
•
LD2
Introduce logical hierarchy
Dist db (reservations, link utilization, net performance)
Separate reservation and call-setup
Aggregation of reservation requests
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!)
Automatic Path Creation
Audio
Microphone
Cell phone
IBM or
ICSI
Speech
Recognizer
Text
Natural
Language
Parser
Control/Metadata
Cmd
E-Mail
Universal
Inbox
Response
to Client
Media Manager
Client
Client
Client
Folder
Store
Media Manager
Interface
Transcoder Services
• Voicemail -> Text Transcript
Media Manager
Service
• Voicemail -> Text Summary
• Voicemail ->Text Outline
Mail Access
Interface
Mail Access
Interface
Mail Access
Interface
NinjaMail
POP
IMAP
• Email -> Plain Audio
• Email -> GSM Audio
• Voicemail -> GSM Summary
• Voicemail -> Audio Summary
• Voicemail -> Skimmed Audio
IP Telephone
• Need overview slide
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)
Example User Web Interface
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?
Internet
H.323 PSTN
Gateway
Handoff the Current Call to Your Computer:
center.cs.berkeley.edu Yes?
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
TCP: End-to-End Reliability
RLP: Wireless Reliability
GSM Network
BTS
TCP / RLP stats
BSC
MSC
RLP stats
Post-processing tool
(120 bytes/s)
TCP stats
TCP and RLP Data Plot
Sent 30,720 bytes from mobile host to stationary host
Bytes
45000
40000
TCP Bytes
35000
TCP Acks
30000
RLP Bytes
25000
RLP Ack
20000
15000
10000
5000
0
0
5
10
15
20
Seconds
25
30
35
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)
GSM BTS-IP Integration
Uses OM & TRAFFIC to
simulate BSC, MSC, and
HLR functionality
2 TRX
RBS
2202
Signaling UPSim
E1 GPC board
Traffic
GSM Phone
Interactive Voice Response
Infocaster
VAT
Control
Signaling
NetMeeting
PC
IP-PAD
Internet
Thor-2
Ethernet
E1: Voice @ 13kb/s
Data @ 12kb/s
Performs rate adaptation
function of ZAK/TRAU
H.323 GW
PSTN
Experimental HW/SW Testbed
Simulation and monitoring software
Velo
Nino
IBM
WorkPad
MC-16
Motorola
Pagewriter 2000
CF788
306 Soda
405 Soda
326 Soda “Colab”
WLAN /
Bluetooth
@Home, DSL
Pager
H.323
GW
2 GSM BTS
Smart Spaces
SimMillennium
Network
Infrastructure
Millennium Cluster
DAB BTS
Millennium Cluster
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 widearea “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 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