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/

7
S.
S.

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. 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

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

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

Access
Network

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
Pager
GW
Cellular
Cellular
Network
Network

iPOP

IAP
Transducer
Agent
iPOP
GW

iPOP
IP Core

Redirection
iPOP
Agent

H.323
GW
PSTN
PSTN

WLAN
WLAN
GW

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

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

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:
OfficePSTN:510-643-7212
510-643-7212
FaxPSTN:
FaxPSTN:510-643-7352
510-643-7352
DeskIP:
DeskIP:rover.cs.berkeley.edu:555
rover.cs.berkeley.edu:555
LaptopIP:
LaptopIP:fido.cs.berkeley.edu:555
fido.cs.berkeley.edu:555
PCS:
PCS:510-388-7212
510-388-7212
E-mail:
E-mail:adj@cs.berkeley.edu
adj@cs.berkeley.edu
Home:
Home:510-555-1212
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 (1Ms)

scalable, highly available

persistent state (safe)
databases, agents
home base per user
service programming
environment

Wide-Area Path

Active Proxies (100Ms)

not packet routers, may be

active networking nodes
bootstrap thin devices into
infrastructure
soft-state and well-connected

Units (1Bs)

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

IAP

PSTN

Naming Server
Preference Registry
Personal Activity Tracker
APC Server

WaveLAN

Cal
Stanford

Administrative Relationships
Access Network
Plane

PSTN

GSM

IAP IAP IAP

ICEBERG
Network
Plane

IAP

SF iPOP

Pager
IAP
NY iPOP

IAP
SF iPOP

NY iPOP

Control/Data Planes
Data Plane

Operators

Connectors
APC

Paths
IAP

PRLS

PAT

Ninja Execution
Environment

Bases

Active
Proxies
Units

eg
R
ef
r
P
c
Sv
e
m
a
N

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
Session state

iPOP

Announce

Listen

Data
Path
HB

iPOP HB

IAP

Announce

Session state

Comm Session Listen

Announce

Data
Path

Data
Path

Listen

Call
Agent
Session state
iPOP

Call
Agent

HB

iPOP
iPOP HB

IAP
HB

IAP
iPOP HB

Naming Service
800-MEDIA-MGR
UID: mediamgr@cs.berkeley.edu
510-642-8248
UID: hohltb@cs.berkeley.edu

11

Preference
Registry

22

hohltb: Prefers Desktop

mediamgr: Cluster locn.

Bhaskars
Cell-Phone

Barbaras
Desktop

33

33
Automatic
Path
Creation
Service
Bhaskars
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
Callees 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

E-Mail

Cmd 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

NinjaMail

Mail Access
Interface

POP

Mail Access
Interface

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 (Sp00)
~700 ugrads (Fa00)

Example User Web

Interface
Current Price for Using Next Minute Price for
Your Computer:
10 Using Your Computer:
Tokens/min
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

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

306 Soda

405 Soda

Motorola
Pagewriter 2000

CF788

326 Soda Colab

WLAN /
Bluetooth

@Home, DSL

Pager

2 GSM BTS

Smart Spaces

SimMillennium
Network
Infrastructure

H.323
GW

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/
iceberg-devel@iceberg.cs.berkeley.edu

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