1. ICEBERG: An Internet-Based, Integrated Communication System
Helen J. Wang
ICEBERG Project, U C Berkeley
August 1, 2000

2. Motivation Cellular Pager PSTN Internet Lack support for:
First of all, I’d like to talk about what motivates the ICEBERG project.
Today, we see rapid advances in the telecommunications and Internet techologies which have enabled people with powerful means of communications. People can communicate through heterogeneous devices such as telephone, PC, pager, cellular phone, PDAs. All these devices access different networks such as PSTN, Cellular networks, pager network and the Internet. However, the existing communication systems such as the PSTN telephone network and the cellular network, as well as the newly emerged Internet telephony systems, are limited in providing support for the integrated and highly personalized use of these heterogeneous devices and diverse network services.
For example, when I walk into my office talking on the cell phone, I cannot switch to my PC to continue the conversation. And I am unable to freely express my incoming communication preference such as "if I am talking with an important person, direct all calls to my s."
Lack support for:
Integrated use of heterogeneous devices (old & new)
Rapid arbitrary communication service customization

3. Limitations of Existing Systems
Telecommunications network:
engineered with one app and device in mind
Existing Internet Telephony systems:
potential of easy service creation
scalability, availability and fault tolerance not fully addressed
It is very difficult for telecommunication networks to support such services due to its complexity, inflexibility, and lack of support for heterogeneity.
Why? (designed for telephone calls only. different functionalities are designed all together rather than in a modular fashion, which leads to complexity, inflexility, it only efficiently supports one media that is voice). The process of introducing new services is complex (understand sections of the codes or some database), cycles of introducing new services is also lengthy (6 month to 1 year for a software release ) and political. Each telephone switch is loaded with a software release that can only support a fixed number of services such as call forwarding. This is a very coarse grained and limited way for end users to have advanced communication services.
Some Internet Telephony systems have improved the ease of user level service introduction and creation. However, not all the services have been considered. For example, one of the services we mentioned earlier (user-behavior based services) has not been seen in any systems.
what is Internet Telephony systems? the control and transport of the commication is primarily done in the Internet, while it also inter-operates with other networks through the use of gateways.
Although the current telephone networks cannot easily support innovative and highly customizable communication services, it is still the most successful network out there because it truly scaled to the whole globe and is a highly reliable network. On the contrary, the existing Internet Telephony systems have hardly addressed the fundamental issues of scalability and robustness.

4. How good is a communication system?
Functionality: communication services it can support, and the ease of creating them
Viability: scalability, robustness, wide-area operable
ICEBERG: a viable Internet-core communication system and infrastructure that supports heterogeneity and rapid, arbitrary communication service customization and creation
There are two aspects of a system, the control aspect and the media transport aspect. The control aspect refers to setting up, tearing down and maintaining the communication sessions. During this process, there are interactions among system components. A control architecture consists of system components and a signaling protocol. The design of the control architecture is essential to enabling powerful services, and it must be able to scale to large population and tolerate faults. The design of such a control archiecture is the focus of my
thesis.

5. Architecture: Goals Any-to-any communication Personal mobility
inter-working (ICEBERG Access Point), composition of data transformation (Automatic Path Creation Service)
Personal mobility
unique ID, name mapping (Name Mapping Service)
Personalized communication services
preference storage and management (Preference Registry)
Enable user-activity driven services
activity tracking (Person Activity Coordinator)
Our control architecture is driven by four type of services:
- any to any communication services refers to the ability of having two arbitary heterogeneous devices communicating with each other. It involves determining what kind of data transformation operations are necessary, and how to place them in order. To simplify the system, our approach is to isolate such kind of data flow management from the rest of system. details later.
simple example: telephone to chat session: packetization, voice-to-text
- Personal mobility refers to the idea of the person is the communication endpoint rather than the device they.
- unique identity to each individual
- mainmain the name mapping between device ID (such as
a telephone number to a person's unique ID).
- communication customization services: when I want to called,
on what device, by whom, and under what condition
- user-behavior driven service:
my current behavior is I am eating dinner with my family,
and I don't want my phone to ring.

6. Control Architecture Components and Their Operations
iPOP
iPOP
IAP
dialed
Call
Agent
Call
Agent
IAP
NMS PR
Pick up
APC
PAC PR
PAC
NMS
I will illustrate the components in our architecture through a scenario. I will describe their functionalities and the properties, but the actual mechanisms to achieve those functionalities and properties are not the focus here.
- Each individual is identified by a unique ID in our system to enable personal mobility, format is the current representation of it.
- Each person is associated with a home ICEBERG Point of Presence (iPOP). Similar to the way the Internet Service Providers provide internet service through the use of Point of Presences at different geographic locations, ICEBERG Point of Presence (iPOP) provides ICEBERG communication services to users.
- Name mapping service maintains the mapping between the users’ various communication endpoints and their unique IDs
- The user's preferences such as when he wants to be called on what device are kept in the preference registry. His activity such as "He is talking with an important person" is tracked in the Personal Activity Coordinator. A person's home iPOP maintains the master copy of his preference and current activity.
what is an iPOP:
The set of ICEBERG components running on a cluster is an ICEBERG
Point of Presence
Data Path

7. ICEBERG Architecture: An Overview
Access Network
Plane
GSM
PSTN
Pager
IAP
IAP
IAP A
SF iPOP
NY iPOP
ICEBERG
Network
Plane
First, we begin with a 10, 000 feet view of the ICEBERG network
We envision a number of ICEBERG Service Provider, they provide integrated
communication services
For each ICEBERG Service Provider, there are Point of Presences at different
geographical locations. B PR CA
PAC
APC
NMS
SF iPOP
NY iPOP
Clearing House
ISP Plane
ISP1
ISP2
ISP3

8. Acronyms Lookup APC: Automatic Path Creation CA: Call Agent
IAP: ICEBERG Access Point
iPOP: ICEBERG Point of Presence
NMS: Name Mapping Service
PAC: Personal Activity Coordinator
PR: Preference Registry

9. Leverage Cluster Computing Platforms
iPOP must be scalable and robust: leverage cluster computing platforms such as Ninja, AS1
Our requirements:
highly available service invocation: Ninja
fault tolerant service session: AS1
session state maintained on client (IAP)
iPOP on Ninja augmented with client heartbeat support from AS1
Another important decision I made in this architecture is to leverage the cluster computing platforms. The iPOP must be able to scale to support a large number of communication sessions, be available 24 hours a day, 7 days a week, and be tolerant of component failures. A cluster of commodity PCs interconnected by
a high-speed system area network is well suited for this purpose. Cluster computing platforms, such as Ninja Base and AS1 takes care of the cluster management such as load balancing, availability and failure management. The increasing demand is met by adding new PCs into the cluster. This yields incremental scalability.
There are two type of services out there:
- web server like services: each request is followed by a short service period (Name Mapping, Preference Registry and Personal Activity Coordinator fall into this category). We require such services to have highly available service invocation. This is well supported by the Ninja Base through the technique of redirector stub, which is dynamically generated at run-time and contains the logic for clients to select one of many service instances of a service.
- session-based services: service request is followed by a rather long service period (Call agent provides the communication session service). For this kind of service, we require fault tolerant service session, meaning the transient component failures and network partitions must be tolerated. AS1 has a good support for this through the technique of client stateful heartbeat. client maintains the session state, and the heartbeat includes the session state and keeps the service agent alive.
- Our decision is to build iPOP on top of Ninja Base which is augumented by the client stateful heartbeat support from AS1
- from this point on, I will refer to iPOP as the ICEBERG-capable Ninja Base.