ICEBERGEricsson Review

1
What isICEBERG About?Anthony D. JosephRandy
H. Katz
Bridge to the Future
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. It used
  to be that new capabilities were driven primarily
  by the carriers. Now, they are beginning to be
  driven by the users. Theres 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 BecomesData-Oriented
6
Core Network BecomesData-Oriented
VoIP Gateway
VoIP Gateway
Packet-Oriented
IP-Based WAN
Router
Router
Access Network
Access Network
Core 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

7
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
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
Transformation and Redirection
Pager
IP Core
GW
Cellular Network
WLAN
GW
GW
H.323 GW
PSTN
14
ICEBERGs 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
ICEBERGs 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_at_Berkeley
OfficePSTN 510-643-7212 FaxPSTN
510-643-7352 DeskIP rover.cs.berkeley.edu555 Lap
topIP fido.cs.berkeley.edu555 PCS
510-388-7212 E-mail adj_at_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
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
Architectural Overview
GSM
PSTN
WaveLAN
Iceberg Network
Pager
Cal
GSM
PSTN
Stanford
22
Administrative Relationships
Access Network Plane
ICEBERG Network Plane
23
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
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
Naming Service
800-MEDIA-MGR UID mediamgr_at_cs.berkeley.edu
510-642-8248 UID hohltb_at_cs.berkeley.edu

2
PreferenceRegistry
Barbaras Desktop
1
3
hohltb Prefers Desktop mediamgr Cluster locn.
Bhaskars Cell-Phone
3
Automatic Path Creation Service
MediaManager Mail Access Service
28
Name Lookup/PreferenceRegistry

• IF (9AM lt hour lt 5 PM) THEN Preferred-End-Point
  Office-Phone
• IF (5 PM lt hour lt 11 PM) THEN Preferred-End-Point
  Home-Phone
• IF (11 PM lt hour lt 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
Callees Preferred End Point
User Preference Profiles
29
Quality of Service Issues
Alice
ISP2
Bob
ISP1
ISP3
Resource Reservation
Charlie

• How to support QoS for real-time applications
  over IP-networks?
• SLAs describe acceptable traffic volume/rate, and
  expected performance assurance

30
Clearing House Architecture
Bob
Alice
Edge Router
BD n
BD2
BD1

• Introduce logical hierarchy
• Dist db (reservations, link utilization, net
  performance)
• Separate reservation and call-setup
• Aggregation of reservation requests

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!)

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 -gt Text Transcript
• Voicemail -gt Text Summary
• Voicemail -gtText Outline
• Email -gt Plain Audio
• Email -gt GSM Audio
• Voicemail -gt GSM Summary
• Voicemail -gt Audio Summary
• Voicemail -gt 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

• IP telephony application
• Price based on load
• Congestion-based model
• Exploring userreactions to pricing
• Status
• 23 phone lines
• 50 ugrad users (Sp00)
• 700 ugrads (Fa00)

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
[phone] 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 (gt 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 _at_ 13kb/s Data _at_ 12kb/s
GSM Phone
Performs rate adaptation function of ZAK/TRAU
PSTN
H.323 GW
42
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_at_iceberg.cs.berkeley.edu

45
Current Status and Directions

• Iceberg testbed development
• Alpha release June 2000 (http//iceberg.cs.berkele
  y.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
• 1000 - 1200 Design Decisions/Lessons Learned
  (UCB students)
• 1300 - 1500 Design Decisions/Lessons Learned
  (UCB students)
• Tuesday 22 August 2000
• 1000 - 1200 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
• 1300 - 1430 Brainstorming on Future Directions