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

Smart Appliances/Thin Clients

Qualcomm PDQ Phone

PDA

PCS

• 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: adj@cs.berkeley.eduHome: 510-555-1212

OfficePSTN: 510-643-7212FaxPSTN: 510-643-7352DeskIP: rover.cs.berkeley.edu:555LaptopIP: fido.cs.berkeley.edu:555PCS: 510-388-7212E-mail: adj@cs.berkeley.eduHome: 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: mediamgr@cs.berkeley.edu 510-642-8248 UID: hohltb@cs.berkeley.edu

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

E-Mail

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

IP Telephone

• Need overview slide

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/– 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 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