The Iceberg Project Project Overview

ICEBERG System Introduction and Overview

Telecommunications networks are migrating towards Internet technology, with voice over IP maturing rapidly. We believe that the key open challenge for the converged network of the near future is its support for diverse access technologies (such as the Public Switched Telephone Network, digital cellular networks, pager networks, and IP-based networks) and innovative applications seamlessly integrating data and voice. The ICEBERG Project at U. C. Berkeley is seeking to meet this challenge with an open and composable service architecture founded on Internet-based standards for flow routing and agent deployment. This enables simple redirection of flows combined with pipelined transformations. These building blocks make possible new applications, like the Universal Inbox. Such an application intercepts flows in a range of formats, originating in different access networks (e.g., voice, fax, e-mail), and delivers them appropriately formatted for a particular end terminal (e.g., handset, fax machine, computer) based on the callee's preferences.

The design of the ICEBERG architecture is driven by the following types of services:

• Any-to-any communication services:
  Any-to-any communication refers to the ability to support communication between all types of devices effectively. For this purpose, we employ the Automatic Path Creation service (APC) which composes the data path between the endpoints of any type through mix-matching operators (units of computation) and connectors (transportation abstraction between operators). transport between operators. The use of the APC simplifies extending ICEBERG to new devices, which is merely a matter of introducing new codecs or data transformation operators. By encapsulating the data flow/path management within the APC service, it reduces the complexity of the signaling protocol (the protocol for establishing and maintaining communication sessions).

  To enable any-to-any communications, integrated communication systems also need a component that inter-works with various networks for signaling translation and packetization. In our control architecture, this component is called an ICEBERG Access Point (IAP).

  The MediaManager Service provides multi-modal access to the user's different mail repositories. It can do intelligent transformations such as summarizing a voice-mail. It uses a Transcoder Service for the data transformation.

• Personal mobility services:
  Personal mobility means treating people, rather than devices, as communication endpoints. Every person using ICEBERG has an ICEBERG unique ID. The mapping between the specific device ID and unique ID is done through the Name Mapping Service (NMS). For this release, we use the Open LDAP directory service.

• Communication service customization:
  To allow end users to customize their communication service (such as when they want to be called, on what device, under what condition, and by whom), we use a Preference Registry (PR) to store and manage user preferences. Our philosophy here is that callee has the total control on how they can be reached.

• User activity-driven services: ICEBERG also aim to support a new kind of communication service based on user activity. This type of service generalizes the location-based services that have appeared in many other systems. Instead of customizing the communication service based on the current user location, we allow the current user behavior (such as "I am talking to an important person") to be tracked and used for customization. Users control what behaviors are tracked as a way to control privacy. The Personal Activity Coordinator (PAC) performs the tracking. We did not incorporate the PAC in this release.

Another important decision in our architecture design is to leverage cluster computing platforms for processing scalability and local-area robustness. Our control architecture requires processing scalability to a large call volume, continuous availability through fault masking, and cost-effectiveness. Clusters of commodity PCs interconnected by a high-speed System Area Network (SAN), acting as a single large-scale computer [NOW], are especially well-suited to meeting these challenges. Cluster computing platforms, such as [Ninja], provide an easy service development environment for service developers and mask them from cluster management problems of load-balancing, availability, and failure management. We plan to build the ICEBERG system on Ninja for these benefits. Our current release is built on Ninja iSpace computing platform which has not yet provided the above desirable cluster characteristics. Thus, this release does not have a full-fledged fault tolerance and load balancing mechanisms. In addition, this ICEBERG release heavily uses Remote Method Invocation for communication, which does not scale to large number of simulateneous invocations. For these reasons, this release serves as a prototype for people to read and run in a small scale. The following figure shows a 5,000 feet view of how ICEBERG system could be used in the real world. The ICEBERG network plane shows two ICEBERG Service Providers representing two different administrative domains: A and B. The services they provide are customizable integrated communication services on top of the Internet. Similar to the way that Internet Service Providers (ISP) provide Internet services through the use of Points of Presence (POPs) at different geographic locations, ICEBERG Service Providers consist of ICEBERG Points of Presence (iPOPs). Both A and B have iPOPs in San Francisco (SF) and New York (NY). Each iPOP contains Call Agents (CAs) which perform call setup and control, an Automatic Path Creation Service (APC) which establishes data flow between communication endpoints, a Preference Registry (PR) for users' call receiving preference management, a Personal Activity Coordinator (PAC) for user location or activity tracking, and a Name Mapping Service (NMS) which resolves user names in various networks. iPOPs must scale to a large population and a large call volume, be highly available, and be resilient to failures. This leads us to build the iPOP on the Ninja cluster computing platform. The ICEBERG network can be viewed as an overlay network of iPOPs on top of the Internet.

Individual Research Topics

• The Signaling Protocol -- This aspect of the project looks into the issues in achieving scalable and fault-tolerant wide-area signaling in the context of the above architecture. [Helen J. Wang]
• The Universal Inbox provides extensible and scalable personal mobility and service mobility in a hybrid network. [Bhaskaran Raman]
• The MediaManager Service provides access to mail related mime types through the use of transcoding operators, the Transcoder Service, for multi-modal information access. It can intelligently handle regular mail as well as voicemail encoded in MIME. [Barbara Hohlt]
• Automatic Path Creation Service -- This provides generic data transformation in the wide-area Internet. We are looking at the issues of composability of such services and their optimal placement in the Internet. [Z. Morley Mao]
• Clearing House -- This is an architecture for scalable resource provisioning in the wide-area Internet. [Chen-Nee Chuah, Lakshminarayanan Subramanian]
• Congestion Pricing -- Here we explore novel ways to provision and avoid congestion on constrained resources such as a H.323 gateway. We are looking at how pricing can be used as a mechanism to achieve this. [Jimmy Shih]
• Video Over Wireless -- Here we look at transport and link level performance issues for video services on wireless links. [Almudena Konrad, Amoolya Singh]

Overview Papers

• ICEBERG: An Internet-core Network Architecture for Integrated Communications [ ps.gz ] [ pdf ], IEEE Personal Communications, August 2000.
• A Signaling System Using Lightweight Call Sessions [ ps.gz ], Proceedings of IEEE INFOCOM 2000, Tel-Aviv, Israel. March 2000.
• Personal Mobility in the ICEBERG Integrated Communication Network [.ps], UCB EECS Technical Report, UCB/CSD-99-1048, May 1999

Overview Presentations

The ICEBERG Project Update presentation given at the recent Endeavour retreat (June 2000) describes the latest research directions.

Here is a presentation on ICEBERG goals. The presentation was given on 9/16/98 at the BMRC MIG seminar series.

Here is an HTML powerpoint presentation that outlines the goals and strategy of the project.