The Design of ICEBERG: An Integrated Communication Architecture

Bhaskaran Raman, Helen J. Wang, Jimmy Shih, Anthony D. Joseph, Randy H. Katz
fbhaskar,

helenjw, jshih, adj, randyg@cs.berkeley.edu

Computer Science Division, U. C. Berkeley

Abstract
In the last decade, communication technology has seen a rapid advance in the Internet as well as in wireless telephony. New and enhanced access networks, end-devices (e.g., 22]) and services (e.g., 21]) are now becoming commercially viable. Simultaneously, there are many commercial e orts to provide integration among the di erent networks and services 23, 24]. However, there is little or no support for seamless and personalized integration of services across heterogeneous networks. Moreover, there is poor support for scaling these services to a large user-base or for deploying them in the wide-area. The Iceberg (Internet-based CorE BEyond the ThiRd Generation) Project proposes an Internet based integration of telephony and data services across di erent access networks. Extensibility, scalability and personalized communication are the prime design goals of Iceberg. We leverage the Internet's low cost of entry to achieve easy service creation, deployment and integration. In this paper, we present the initial design of the Iceberg architectural components and we discuss how these components implement the functionalities required to build an integrated wide-area network.

1 Introduction
Today, people have adopted a wide range of communication devices for e cient and timely communication: telephones, cellular phones, pagers, PCs, etc. Many people own multiple devices for
Supported by NSF fellowship

communication over diverse networks (the PSTN, cellular networks, pager networks, Internet, etc.). It is unlikely that these heterogeneous devices will converge into a single device, for people are inherently diverse in their needs, interests and tastes. Reaching someone with multiple devices is a challenge since it is not obvious which one of the callee's devices to call. Also, people may be annoyed when reached via a particular device at an inconvenient time. People use their devices with di erent preferences for privacy, (e.g., giving di erent phone numbers to di erent people). For cost saving, a person may leave her cell phone always powered down, etc. Although having multiple devices is often more convenient than having only one device, users are left with the responsibility of manually managing them. With no additional support, this is very crude, limited and unsatisfactory. The fundamental problem here is a lack of support for integrating services from heterogeneous networks. This is the primary motivation for the Iceberg project. We aim to enable Potentially Any
Network Services (PANS), meaning that any service can be accessed from any device via any net-

work ?] (e.g. accessing e-mail via cell-phone). The Internet Protocol (IP) provides a simple service model of packet delivery, and can serve as a spanning layer across heterogeneous access networks. In Iceberg, we treat di erent communication networks (i.e., the PSTN, GSM network or pager network) as access networks. When these networks rendezvous at the Internet (hence the name \Internetcore"), we can build innovative applications on top of the Internet, integrating di erent services from heterogeneous networks. Another key advantage of an Internet-core is the easy and low cost deployment of network-based services using the client-proxy-server model 3]. This is proved by the explosive growth of web services and wide adoption of E-commerce. In Iceberg, we want to leverage this characteristic of the Internet to provide creative, highly customizable communication services. In this paper, we present our initial design of the control architecture and the service infrastructure for the Iceberg network. We treat the Internet as the switch that routes information (e.g., telephone calls), provides all kinds of Internet- and telephony-like services and beyond, integrates diverse networks and devices, and enables easy user level service creation and customization. In the rest of the paper, we rst discuss our design goals in Section 2. In Section 3, we give an overview of the Iceberg architecture. We discuss detailed design of the main components of our

system in Section 4. We present related work in Section 5. Finally, in Section 6 we summarize the novel aspects of our architecture, present our implementation status, and discuss our immediate future plans.

2 Design Goals
Our design is driven by the following seven goals:
Potentially Any Network Services (PANS). This means that any service can be accessed transparently

from any end-device via any access network. To achieve this goal, we make our system design and implementation network and device independent, which allows new networks and their access devices to be plugged into the Iceberg architecture without any changes to our system.
Personal Mobility. This is the concept of having the person (and not the communication device) as

the communication end-point1 . By using a single identity for an individual, we can implement a level of indirection to the desired end-point for communication. Personal mobility is the key motivation for integrating services across diverse devices from heterogeneous networks.
Service Mobility. This goal refers to seamless mobility across di erent devices in the middle of a service

session (for example, switching from a cell-phone to an IP-Phone in the middle of a conversation). This goal requires the separation of control (signaling, semantic information and service meta-data) and data information for each network, and the propagation of such information across each network boundary.
Giving control to the callee. In current communication networks, a caller chooses how (and when) to

reach a callee. One of the important goals of Iceberg is to shift the locus of control from callers to the person being called. To enable this, our system must provide mechanisms for users to customize their communication services such as call forwarding, call waiting, service transformation, etc.
Scalability. We aim to be able to incrementally scale to operate in the wide-area and support a large

user base (i.e., large geographic regions and hundreds of thousands of simultaneous calls).
1

The concept originally comes from Personal Communication Services 33]. The Mobile People Architecture 4] also

identi es this principle.

High availability and Fault tolerance. Communication plays a very important (and sometimes critical)

role in users' lives. The components of the network should be available 24 hours a day and 7 days a week. We strive for the ve nines availability found in traditional telecommunication networks (i.e., 99.999% availability). As such, the architecture should be able to tolerate failures gracefully and hide them from end-users.
Security, Authentication and Privacy. Unlike in the telecommunication networks, many of Iceberg's

components are part of the untrusted Internet. Thus, a carefully designed trust model and security mechanism is critically important.

3 The Design of Iceberg

As suggested by the (expansion of the) name of the project, a fundamental design decision in Iceberg is the use of the Internet as the glue for integrating the various networks. In this section, we present the architecture of the Iceberg components that exist in the core IP network. The overall architecture is shown in Figure 1.
IAP
Pager GSM PSTN

Legend
GSM Naming Server PRLS Server Preference Registry Person Activity Tracker APC Server

IAP IAP

IAP

Internet-Core

IAP

PSTN

IAP IAP
WaveLAN PSTN

Figure 1: Iceberg Architecture.

Iceberg Access Points (IAPs): The rst crucial component in our design is the interface between an

access network and the Internet-core network. This component acts as the service transformation agent and enables the access of services across networks (an important step towards implementing our goal of PANS). We call these components Iceberg Access Points.
Preference Registry: To achieve the goal of personalized communication, we need to have a mechanism

for storing and processing user preferences. The Preference Registry component of our architecture provides this functionality. The preference registry can be queried to get the user's current preferences (e.g., the current preferred end-point at which to receive calls).
Preference Registry Location: Given a user's identity, we need to locate the user's preference reg-

istry. To satisfy our wide-area goal, we need to be able to do this in a location independent manner.

We capture this functionality in the Preference Registry Location Service (PRLS) component of our architecture.
Person Activity Tracker (PAT): The PAT is a component that inter-operates with the user's preference

registry. It tracks dynamic information such as the user's current location information or the call state at a particular end-point (e.g., o ce phone is busy or the user is out of GSM coverage). These are used by the preference registry as additional inputs in processing the user pro le.
Naming Service: To achieve the goal of personal mobility, we need to map the user's di erent end-

points onto the user's identity. This mapping needs to be maintained by the Iceberg communication network. The component that does this in our architecture is the Naming Service.
Data-Path Creation: To integrate services across heterogeneous end-devices, we need to have a mecha-

nism for performing any-to-any data transformation and transport (e.g., converting from GSM encoded audio to ASCII text). We use the concept of paths and Automatic Path Creation (APC) from the Ninja project 14]. The APC Service component of our architecture creates paths to handle the data ow and conversion between any two end-points. We elaborate more on this in Section 3.2.

3.1 An Illustration
We provide a short illustration of how the di erent Iceberg components work together to provide a personalized call-handling service: Alice uses her cell-phone to dial Bob's home phone number. Bob currently prefers to receive phone calls from Alice on his desktop PC via Voice-over-IP. The call proceeds as follows. It is intercepted at an IAP that links the GSM network and the Internet. This IAP gets Bob's identity from the dialed home phone number using the Naming Service. Next, this IAP locates Bob's preference registry using the PRLS. The preference registry uses the caller identi cation from the calling GSM IAP in combination with Bob's preference information (from his preference registry) to determine Bob's current preferred end-point. Then the calling IAP contacts the corresponding IAP at the other end to establish a phone call. During the call setup process, it also uses the APC Service to establish a data-path for performing any codec transformation.

3.2 Ninja: Iceberg's Execution Environment

The Ninja project 14] aims to provide a software infrastructure for easy, reliable, and scalable distributed service creation and execution in the Internet. Ninja provides a model for making these services fault-tolerant, highly available and incrementally scalable2 . The Ninja execution environment consists of three kinds of components: Bases, Units and Active
Proxies. A Base is an execution environment on a cluster of commodity workstations located in the

network infrastructure 6]. Bases are meant for running services that have to maintain persistent state (e.g., users' preference pro les). At the other end of the spectrum are a large number of Units: the clients of the services running on Bases (e.g., a laptop, a pager, Personal Digital Assistant or a cell-phone is a Unit). In the case where a Unit does not have the intelligence to talk directly with a service on a Base (e.g., a cell-phone which does not know about Bases), an Active Proxy is used to reach the Base. In the Ninja model, an Active Proxy has only session state (soft state) which can be restored in the event of a failure. Persistent state exists only at the Bases.
Iceberg Control Plane Data Plane
Connectors Operators Paths

The relation between Iceberg components and the Ninja execution environment is shown in Figure 2. The Iceberg components run as services in the execution environment provided by Ninja. We leverage the scalability and fault-tolerance provided by Ninja's execution environment for our components.

Preference Registry Naming Service

IAPs PAT PRLS APC Active Proxies Bases Units

Ninja Execution Environment

Figure 2: Mapping Between Iceberg Components and the Ninja Execution Environment.

In addition to the execution environment, Ninja strives to provide easy service composability. We use this concept in the data-plane as shown in Figure 2. Operators are unit of computation that have wellde ned interfaces. For example, software that converts PCM encoded speech into ASCII text through a Java RMI interface is an operator. A Connector is an abstraction of the data- ow mechanism between two operators. For instance, we can have Java RMI connectors or UDP/IP connectors. A Path is a set of operators strung together using connectors ? an abstraction of a data ow. For instance, a
2

Although we leverage a lot of crucial features from the Ninja service environment, our control architecture is quite

independent of Ninja. We could as well use any other service environment that provides similar features.

series of codec operators followed by a speech-to-text operator is a path. We use the concept of Automatic Path Creation (APC) extensively in our data-path to achieve the goal of any-to-any data transformation and transport. The well de ned operator and connector interfaces make it possible to compose paths easily. APC is the process of doing this composition automatically by choosing the right subset of operators and connectors to connect any two end-points. In Figure 2, the Iceberg control components are instantiated on the Ninja execution environments. The control components also instantiate the data-path components on top the appropriate execution environments.

4 Iceberg Functional Architecture

In this section, we present the design of the Iceberg components in the more detail.

4.1 Iceberg Access Point - IAP

Iceberg Access Points (IAPs) are software agents within the Iceberg network that o er the services of call establishment and control on behalf of communication end devices. IAPs serve as Ninja Active
Proxies assisting end devices in carrying out these Iceberg functions.

In our design, we separate an IAP's functionality from that of a gateway. Network-speci c gateway hardware interconnects an access network with the Internet-core. The gateway's software gathers call signaling and data ow information from the access network, and relays them to the IAP (using a much less device-speci c interface). This decoupling of functionality not only makes the design and implementation of the IAP access-network-independent, but also yields better fault tolerance. When a gateway fails, a call is usually lost. In contrast, when an IAP fails, another IAP can take over for the failed one and continue serving the ongoing phone call. This separation will help reduce/prevent call drops (a particularly important requirement for telecommunication networks). In the next subsection (4.1.1), we discuss how we achieve IAP fault tolerance. Then, we present our design of call control on IAP (Section 4.1.2). Finally, in Section 4.1.3, we show how we enable service hando using our call control protocol.

4.1.1 IAP Fault Tolerance

To simplify IAP fault tolerance, we maintain only soft state on IAPs. As such, when an IAP crashes, it can be simply restarted without any sophisticated state restoration 1]. In this section, we present our solution for how IAPs are monitored and restarted after faults. One approach is to have the IAPs3 in the same call session monitor one another and restart failed IAPs. However, if all the IAPs in a call session failed simultaneously, the call would be dropped. In addition, IAPs may belong to di erent administrative domains. We do not believe that it is appropriate to allow one IAP to start another IAP in a di erent administrative domain. Hence, we take a di erent approach. We require that each administrative domain has at least one Ninja Base, which is an ideal place for IAP monitoring and restart. Then, IAPs can periodically send the complete call state of their call session to the Base. If the Base fails to receive these announcements from an IAP (for some timeout period), then the Base assumes the IAP has failed, it starts a new IAP, and it supplies the IAP with the call state.

4.1.2 Call Control

We think of call control as a protocol that alters the call state in a call session. Call state includes calling party identi cation, current call status (active or on-hold), data ow information (IP address and port number of the data stream end points, location of transformation agents if any exist, etc.) and the identity of serving IAPs4. The complexity in call control is usually in the reliable propagation of call state changes to all the IAPs in a call session. The dynamic characteristic of a call session exacerbates this di culty, for IAPs may be restarted upon failure, or new IAPs may be added to an existing call session to serve new call parties. What is required here is an abstraction of a call session that is independent of the locations of the participating IAPs, and is responsible for reliably delivering call state changes to all involved IAPs. A multicast channel can serve as a mechanism for the abstraction of a call session. It provides us with the property of allowing IAP location to be independent of call sessions. Since multicast group membership is maintained at the network layer, sending to a multicast channel does not require the
3 4

A call session may involve many call parties, and therefore many serving IAPs. The call setup process (see Section 3.1) establishes the call states on both serving IAPs.

knowledge of who is in the multicast group. This way, IAPs can join and leave a call session without any special session membership handling. Next, we address our solution to the issue of reliably propagating call state changes to all IAPs in a call session. The soft state requirement for IAPs (see Section 4.1.1) makes it inappropriate to design a hard state reliable transport protocol for call state changes. Instead, each IAP periodically announces its portion of the call state to the multicast channel. Its portion is the the set of rows in Table 1 for which it is the \serving IAP". The IAP also listens to the multicast channel and gathers the other call states from other IAPs. In this model, each IAP maintains the complete call state for a call session (the entire Table 1). This is essentially the announce-listen model that was introduced in 1]. Call state changes are made by IAPs through the announcement of the new call state to the multicast channel. The reliability of new call state propagation is ensured simply through the periodic retransmission over the lifetime of the call. Despite the simplicity in design, this scheme handles simultaneous call state changes at multiple IAPs gracefully. In addition, no special handling for multiparty calls is necessary under this design. In contrast, traditional telecommunication systems handle call transfer and multiparty call conferencing through the installation of new \trigger points" for these services in the basic call processing state machine ? a signi cantly more di cult and complicated process.
Call party 1 ID Serving IAP Data path endpoint info Call party 2 ID Serving IAP Data path endpoint info ... ... ...

Table 1: Call state in a call session Using a single multicast address per call session does pose a scalability problem due to the at IPv4 multicast address space. The advent of IPv6 2] or Simple Multicast 10] would make this problem go away. On the other hand, if multicast does not succeed in the future, Iceberg will require an application-level call session maintenance agent that is independent of IAP locations and maintains the group membership of the participating IAPs5. Other unresolved issues in our design include allocating multicast addresses and choosing the appropriate call state time-out values and announcement periods.
5

Basically, it would implement multicast at the application layer.

4.1.3 Service Hando : Enabling Service Mobility

Service hando enables users to switch between their communication devices in the middle of a phone call. Service mobility, refers to the ability to perform service hando and is a powerful new concept. In telecommunication, the term \service mobility" usually means \service portability," the ability for diverse networks to share user service pro les and carry out the same set of services in each network 12]. However, when one crosses the network boundary in the middle of a service, that service is terminated, and the user must restart the service in the new network. In contrast, service mobility provides seamless integration of heterogeneous devices from diverse networks, as if they are accessing the same network, achieving the goal of potentially any network service (PANS). Service hando is also a demonstration of \personal mobility" ? a call session is identi ed by the people involved in the call, not by the devices in use. Therefore, switching to a new device does not imply switching to a new call session.
(1) handoff to IP phone cell phone turned off start (5) (3) new IAP (2) getEndPoint (uniqueID, EndPointType) (6) Announce Listen Multicast Channel Listen Announce IAP (4) Announce Listen Preference Registry IAP

IAP

Figure 3: Service Hando

To support service hando , we separate control from data. IAPs may fail and be restarted. However, this change in the control path does not a ect the data path. In this section, we present our scheme for service hando . Figure 3 depicts a service hando scenario. Initially, a call session is been established between a cellular phone and a PSTN phone: the two serving IAPs are periodically announcing and listening to the multicast channel. Next, the person on the cellular phone walks into her o ce, and wants to use an IP phone to continue her conversation. She presses some keys on her cellular phone indicating the intent and target of a service hando (e.g., \*SHIP" { Service Hando to IP phone). The serving IAP receives this hando request relayed by the cellular gateway (step 1). It looks up the preferred endpoint (IP phone in this case) in the preference registry with the input of the call party ID and endpoint type - step 2. With the endpoint information and the multicast address of the call session, the IAP launches a new IAP serving the IP phone (step 3). The new IAP creates a new data path

between the IP phone and PSTN phone (perhaps using multicast for data transport). This IAP starts participating in the multicast session for the call session management (step 4). When the cellular phone user turns o her cell phone, this information is passed to the original serving IAP (step 5). This IAP tears down the original data path, and stops announcing and listening to the multicast session (step 6). This completes the service hando .

4.2 Handling User Preferences

The preference registry captures user-speci c personalization parameters. In this section, we describe the issues associated with the design of the preference registry and our initial approach. There are two separate but related issues with user-preference speci cation: (1) the issue of how the system represents, stores and processes user preferences and (2) the issue of building a reasonable user-interface for the user to specify personal preferences.
Caller-id Time-of-day Caller end-point type Person Activity Tracker Callee location Callee state (e.g., who shes talking to) Preference Registry
User Preference Profiles

Other personal state

Per-Call State

Callees preferred end-point

Figure 4: Preference Registry and Person Activity Tracker

Although we focus on the rst issue in this paper, we stress that the user-interface issue is a very important one, especially when we are talking about complicated services6.
Inputs to the Preference Registry

User preference is essentially a function of several inputs such as caller-id, time-of-day or user location. The function's output is the preferred endpoint (e.g. user's cell-phone or email-id). We classify the inputs to the preference registry into two main categories. The rst category is percall information like caller-id, caller endpoint type, etc. The second input category is more dynamic information such as the user's location or call state (who the callee is currently talking to). The collection of inputs of the second category is done by the Person Activity Tracker (PAT). Figure 4 illustrates the conceptual functionality of the preference registry and the PAT.
6

This issue has been faced in the form of feature interactions (where users don't understand the implications of

subscribing to multiple services) even in the limited service model of the Intelligent Network (IN) 31]

Preference Pro les: The preference registry is a user-speci ed function. A natural way to model it is

using a (restricted) scripting language. Given our experiences so far, we believe that a rule-based or procedural scripting language can model a wide range of user preferences in a straight-forward manner. Figure 5 shows a rather simplistic example script where the user wishes to redirect communication to her o ce-phone (9am-5pm), home-phone (5pm-12midnight), or her voice-mail (sleeping time) based upon the time of day.
IF (9AM < hour < 5PM) THEN Preferred-End-Point = O ce-Phone; // At O ce IF (5PM < hour < 11PM) THEN Preferred-End-Point = Home-Phone; // At Home IF (11PM < hour < 9AM) THEN Preferred-End-Point = Voice-Mail; // Sleeping

Figure 5: A Simplistic Example Preference Script

Preference Registry Service on a Ninja Base: The service that implements the preference registry

functionality is a crucial piece of the service framework. It could be shared by multiple users in an administrative domain. It needs to be highly available and fault tolerant. Further, it has persistent state: the users' preference pro les. Hence a Ninja Base (see Section 3.2) is an ideal execution environment for this service.

4.3 The Naming Service

The Naming Service maps the Iceberg user's7 multiple devices onto the same logical entity. Each of the user's service end-points (or devices) is associated with a service-speci c-id. For instance, a user could have a telephone number, a pager number and an email-id8 . To achieve the goal of personal
mobility, we map all the service-speci c-ids of a user to a unique-id ? which is used to uniquely

identify the user in the Iceberg network.

Name mapping refers to the mapping from any given service-speci c-id to the user's unique-id. This is

shown in Figure 6 (we have chosen to have an email-id like name space for unique-ids in this example; however, this choice is not very crucial). To satisfy our wide-area requirement, the name mapping
7

The term \user" could refer to a human user or any abstract entity in real life { for example, an airline company's

customer service number. 8 We call these \service-speci c-ids" and not \network-speci c-ids" since a user could have multiple ids for di erent services in the same network. For instance: an e-mail-id, a Voice-over-IP end-point and an ICQ ID in the Internet.

should be done in a distributed fashion (similar to how DNS handles name mapping 28]). We need to have a mechanism to locate and retrieve a particular mapping in a location independent manner (any lookup from anywhere). An important point to note is that name mapping is required only when dealing with devices that do not know about Iceberg unique-ids (e.g., the scenario where Alice uses her cell-phone to dial Bob's home phone number). If the calling device is capable of providing the callee's unique-id directly, this mapping is not required. Also note that in some cases, this mapping may result in more than one unique-id (e.g., when the service-speci c-id is a shared telephone in an o ce). The mapping in the other direction: unique-id to service-speci c-id for a particular user, is done at the user's preference registry. This is because the set of devices the user owns and the corresponding servicespeci c-ids are ideally stored as part of the user's personal pro le.
Distributing the Naming Service
Tel Numbers: A IP Addresses: B

<Ofc Phone No> +1-510-642-9076 <Pager No> 1234321 <Desktop IP Addr> 128.32.37.162 <Unique-id> bhaskar@cs.berkeley.edu

Figure 6: Examples of Name mappings

We use the principle of hierarchy to distribute the name-mapping functionality. We take an approach similar to DNS: (a) a distributed hierarchical tree of the name space, (b) multiple name servers controlling di erent portions (sub-trees) of the name tree, and (c) a distributed tree traversal across name servers for name mapping.

ccode=1

l1=edu ccode=91 ccode=... l2=berkeley

l1=com

acode=510 excode=642

acode=044

l2=...

excode=644 excode=489

l3=cs

l3=eecs

phnum=3359 phnum=9076 phnum=1906

host=jake

host=fermi

(a)
Pager Numbers: C type=tel pager=... pager=1234567 pager=1122334 pager=7654321

(b)
Combining the Trees

type=pager type=ipaddr

type=new

Tree A

Tree B

Tree C

Tree D

(c)

(d)

Figure 7: The Hierarchical Name Tree

However, we cannot adopt a DNS-like solution directly since, unlike with DNS, we have multiple name spaces: telephone number space, e-mail address space, pager number space, etc. Furthermore, Iceberg must be capable of handling new name spaces as new services are introduced (e.g., adding a service like ICQ 18] adds a new name space of ICQ IDs).

To handle these issues, we rst arrange each of the name spaces of the service-speci c-ids into a separate tree. How this hierarchical arrangement is done for each name space is orthogonal to the rest of the solution. An example is shown for the case of three service-speci c-ids: Telephone numbers, IP Addresses and Pager numbers, in Figure 7(a), (b) & (c). We use a tag for each of the levels in the hierarchy in each tree. We can then describe a tree using its schema (an idea borrowed from LDAP 32]). This gives a uniform view across all name spaces and allows us to have a single tree traversal mechanism. Next, to provide a single conceptual tree, we join these trees together at a common root (Figure 7 (d)). Using a single conceptual tree allows us to add new name spaces by simply adding a new tagged entry to the root (without the common root, there is no good way to dynamically \learn" about a new name space). The addition of a new name space (Tree D) is illustrated with dotted lines in Figure 7 (d). Given this structure, performing a name mapping involves walking the tree (possibly through multiple name servers) to the leaf corresponding to the service-speci c-id9. The leaves (shown as small circles in Figure 7) store the unique-id corresponding to the service-speci c-id. As with DNS, the distributed tree enables the use of a distributed and location-independent tree-traversal name mapping mechanism.
Name Server on a Ninja Base: A naming service is a critical component of any system. It needs to

be available 24 hours a day, 7 days a week (anyone who has experienced a DNS server crash would readily agree with this). The name server needs to maintain persistent state (across failures). As with the preference registry server, these requirements make it ideal to run a name server on a Ninja Base.

4.4 Preference Registry Location Service

To establish a call session with a callee, Iceberg needs a mechanism for locating the callee's preference registry given the callee's unique-id. If only a service-speci c-id is known, the naming service is used rst to get the callee's unique-id. Locating the preference registry given the unique-id (in Iceberg), is similar to the operation of locating a mail server given a user's e-mail address (in DNS). This service is very similar to the naming service: (a) the lookup is based on the unique-id rather than on a service-speci c-id and (b) the location of the preference registry is returned rather than the
9

The bootstrap name server can be a con guration option or could be dynamically learned using techniques such as

the one in 11].

unique-id. Distributing this service is similar to distributing the naming service: we have a hierarchical tree of the unique-id space. The leaves of the tree store the location of the preference registry of the respective user. And as with the Naming Service, there are availability and persistence requirements that require that this service also run on a Ninja Base's execution environment.

5 Related work
A wide assortment of commercial products that attempt to provide integration across services and communication devices are becoming available. A few examples are: e-mail-to-fax services 13, 17], voice-e-mail-fax integration services 15, 23], and enhanced telephony services 24]. These commercial services show the strong desirability to have personalized integrated communication. The TOPS architecture 9] uses a \directory service" component for personalization. However, the commercial e orts, as well as TOPS, are limited in terms of any-to-any service integration and dynamic service composition. They also lack models for scaling to the wide-area or to a large user base. The Mobile People Architecture (MPA) 4] has some goals similar to Iceberg. Both projects try to provide any-to-any integration and personalized call handling. However, there are many enhanced features of our design that are missing in MPA: service hando , seamless service integration and a model for scalable and incremental service deployment (a feature that we leverage from Ninja). The telecommunication industry's Intelligent Network (IN) is a service architecture that intends to provide easy service creation and customization. IN follows the principle of separating service execution from the basic call processing at the switch, so that services can be created as separate pieces of software running at other places 8]. This separation is designed to relieve service developers of the need to know the intricate details of call processing at switches, and help them focus solely on service implementation. However, IN has completely failed to provide service inter-operability across switches from di erent vendors because of non-standardized call processing models. Also, service customization is very coarse-grained. In addition, there is no elegant integration between xed and mobile telephony services, let alone integration with other types of networks. Finally, service creation in IN has a high cost-of-entry and is limited to a relatively small number of network operators 8] (more speci cally, telecommunications service providers and not end users).

Many 27] 7] have identi ed the di culty of service creation in IN, and have proposed xes by having call handling services running on the Internet. However, the service inter-operability problem still exists. Although some of the Internet service components can be re-used, the service logic that interconnects the Internet service components and the IN cannot be re-used across di erent switch platforms due to the switches' di erent call processing models. Thus, the service inter-operability problem remains. Based on this argument, we believe extending IN for service creation and integration is a awed approach. SIP 30] and H.323 16] are Internet signaling protocols for Internet Telephony. As our architecture evolves, we expect to build upon these protocols for Iceberg control signaling.

6 Discussion
Our Contribution
We are developing Iceberg to go beyond the service model of the third generation cellular10 and PCS (Personal Communication Services) e orts 12, 33]. Its main strength: ease of service creation and deployment comes from the fact that it is designed with the Internet as the core. The Iceberg functional components are built on top of Ninja's service architecture and execution environment. Ninja provides Iceberg components with the critical properties of high availability and scalability required by telecommunication environments. The concept of personal mobility as achieved in Iceberg is much richer than the notion of personal mobility as achieved by PCS. Iceberg provides a framework for cross-network and cross-device mobility of services. Using the exible personalization model, it is trivial to build common IN and PCS services such as call redirection, personal numbering, 800-number service, etc. Commercial service integration e orts such as voice-to-email, email-to-fax, etc. are easy to build, deploy, and incrementally scale in Iceberg. Iceberg is not meant to replace the current telecommunication infrastructure. On the contrary, one of our prime goals is to allow existing as well as newly emerging networks and services to be integrated easily. The Iceberg components are designed for incremental deployment. For instance, the Iceberg
10

That's where the phrase \Beyond the Third Generation" in the expansion of \Iceberg" comes from.

network could start out just with a few IAPs and other components deployed in a local administrative domain. More IAPs could be added incrementally to accommodate more users and expand to the wide-area.

Implementation Status
To gain rst hand experience and to better re ne the design of our architecture, we have been implementing the Iceberg components in a testbed setting. In this section, we discuss the status of our testbed implementation.
The Testbed: Currently, the testbed consists of a GSM network and a WaveLAN network. We are still

in the process of adding functionality to our testbed: building IAPs to interface to the PSTN through a H.323 gateway 16] and to interface to the paging network through a 2-way paging gateway. Our testbed is shown in Figure 8. The components that we are working on currently are shown with dotted lines. Our immediate plans also include extending the testbed to the wide-area (we are working on deploying Iceberg components at other academic and industrial locations).
The Components IAPs: We have interfaced IAPs with four di erent

kinds of services and networks: the GSM cell-phone network, the vat 25] Mbone audio conferencing tool, a voice-mail service, and an e-mail service. It is now possible to have personalized redirection to any of these end-points in our system. These IAPs currently use a simple request-response protocol for call signaling. Our mechanism for call session management is yet to be implemented.
Cell-Phone IAP

Laptop (WaveLAN)

1 0 1 0 11 00 1 0 1 0 11 00 11 00 1 0 1 0 11 00 1 0 1 0 11 00 1 0 1 0 1 0 1 0 11 00 1 0 1 0 11 00 1 0 1 0 11 00

IAP

IAP

Internet Core
IAP H.323 Gateway

Pager Network Pager-Gateway

GSM GSM-Gateway Base-Station

PSTN Network

Figure 8: Our Current Testbed

Preference Registry: For rapid prototyping, the internal representation of user's preference scripts uses

a subset of Perl 20]. We are in the process of making the preference registry run on a Ninja Base. We have not yet investigated user interfaces for specifying preferences.
Naming Servers & PRLS Servers: Although the two services are conceptually di erent, they are very

similar in functionality (as explained earlier). The prototype implementation merges the services into

a single one11 . We borrowed the idea of a tagged hierarchical tree from LDAP 32]. We are using an existing LDAP server implementation 19] (con gured with the schema of our name trees) for quick prototyping of these two services. We plan to move this implementation to one running on top of a Ninja Base.
APC: We have an implementation of the Ninja concepts of operators and paths that is currently

capable of supporting the (

GS M

06 10
:

voice

text

conversion) and vice-versa.

PAT: We are in the process of de ning the interface to the PAT in the next level of detail. Although it

is not completely speci ed yet, we can currently capture reachability information of users' cell-phones in our GSM testbed by capturing the Location Update, IMSI-Attach, and IMSI-Detach messages from the cell-phones 29].

Further Issues
In this paper, we have presented our rst-cut design of the Iceberg architecture. There are still many unresolved issues that we plan to look into in the near future.
Security & Privacy Issues: In a communication network that spans multiple, mutually untrusted

administrative domains there are several authentication and privacy issues that arise. Services such as the naming service, preference registry location service, and the preference registry lookup must be authenticated since they are wide-area services. Caller authentication is important when the callee's preferences are dependent on the caller's identity. We also need mechanisms for handling special cases, like unlisted numbers. For instance, a user may wish to keep her cell-phone number secret but still receive calls on it at particular times of the day. Our current mechanism where the preference registry just returns the preferred service-speci c-id would not directly apply to this scenario (the cell-phone number would be revealed). Similarly, we also need roaming mechanisms to allow service through foreign-IAPs (e.g., when a user is traveling, she may wish to use a hotel's IAP for service access).
Billing Issues: \Enhanced services aren't worth doing unless there is a way to bill for them"12 . We

plan to look at billing issues in the context of our integrated service framework. 11 In fact, this is what is done in DNS ? the same service is used for domain name mapping as well as mail server
location. 12 John Coons, Dataquest analyst. Quote appeared in \The Next Net", Wired, April 1999.

Usability & UI Issues: When we talk about user customization, we raise the important issues of

usability and user-interface design. We're currently looking at these issues in the context of user preference speci cations in the preference registry.
Performance Evaluation: We've been moving forward with the implementation of the Iceberg archi-

tecture in the spirit of the \Plan to throw one away" system design principle 26]. In the next phase of the project, we intend to perform performance and usability evaluations of the design; especially with respect to scaling, wide-area latency, ease of new service development, and user satisfaction. We expect that the results will drive the next iteration of design.

Acknowledgments
We thank Chen-Nee Chuah, Adam Costello, Tom Henderson, Sreedhar Mukkamalla, Angela Schuett and Tina Wong for their insightful comments on the paper. We thank Emre Kiciman, Ben Zhao and the Ninja group for the lively discussions on many of the design issues.

References

1] Elan Amir, Steven McCanne, and Randy H. Katz. An active service framework and its application to real-time multimedia transcoding. In Proceedings of ACM SIGCOMM 98. ACM, August 1999. Vancouver, British Columbia. 2] W. Biemolt, M. Kaat, and H. Steenman. A Guide to the Introduction of IPv6 in the IPv4 World. Internet Engineering Task Force, April 1999. 3] E. Brewer et. al. A network architecture for heterogeneous mobile computing. In IEEE Personal Communications Magazine, October 1998. 4] Guido Appenzeller et. al. The Mobile People Architecture. In Technical Report of Stanford Computer Science Lab CSL-TR-99-777, January 1999. 5] R. Katz et. al. A scalable service architecture for computer-telephony integration. In preparation; To be submitted, 1999. 6] Steven D. Gribble et. al. The MultiSpace: an evolutionary platform for infrastructural services. In Usenix Annual Technical Conference, June 1999. Monterey, CA. 7] C. Gbaguidi et.al. An architecture for the integration of Internet and telecommunication services. In IEEE Infocom '99, New York, March 1999. IEEE. 8] Jean-Pierre Hubaux et.al. The impact of the internet on telecommunication architectures. In The International Journal of Computer and Telecommunication Networking, 1999. 9] N. Anerousis et.al. The TOPS architecture for signaling, directory services and transport for packet telephony. In The 8th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV), 1998. 10] R. Perlman et.al. Simple Multicast: A Design for Simple, Low-Overhead Multicast. Internet Engineering Task Force, December 1998. 11] Steven Czerwinski et.al. An architecture for a secure service discovery service. In (To Appear) Fifth Annual International Conference on Mobile Computing and Networks, August 1999.

12] Nadege Faggion and Cegetel Thierry Hua. Personal communications services through the evolution of xed and mobile communications and the intelligent network concept. IEEE Network, Jul/Aug 1998. 13] http://info.ox.ac.uk/fax/. Email to Fax at Oxford University. 14] http://ninja.cs.berkeley.edu/. The Ninja Project. 15] http://planetarymotion.com/. Planetary Motion's CoolMail Service. 16] http://www.databeam.com/h323/h323primer.html. A Primer on the H.323 Series Standard. 17] http://www.fax away.com/. Faxaway: The Premier Email to Fax Service. 18] http://www.icq.com/. The ICQ Internet Chat Service. 19] http://www.openldap.org/. OpenLDAP. 20] http://www.perl.com/. The Perl Scripting Language. 21] http://www.pocketmail.com/. The PocketMail E-Mail Service. 22] http://www.qualcomm.com/cdma/phones/. Qualcomm CDMA Phones. 23] http://www.thinklink.com/. ThinkLink. 24] http://www.wild re.com/. Wild re. 25] Van Jacobson and Steven McCanne. Vat mbone audio conferencing software. ftp://ftp.ee.lbl.gov/conferencing/vat. 26] Butler W. Lampson. Hints for computer system design. In Proceedings of the 9th ACM Symposium on Operating Systems Principles, October 1983. 27] Colin Low. The internet telephony red herring. In Proceedings of Global Internet, November 1996. London, England. 28] P. Mockapetris. Domain Names - Implementation and Speci cation. IETF. Request for Comments: 1035, Nov 1987. 29] Moe Rahnema. Overview of the GSM system and protocol architecture. IEEE Communications Magazine, April 1993. 30] Henning Schulzrinne. A comprehensive multimedia control architecture for the Internet. In Proceedings of International Workshop on Network and Operating System Support for Digital Audio and Video, May 1997. 31] S. Srinivasan. Impact of enhanced feature interactions. IEEE Communications Magazine, Jan 1995. 32] M. Wahl, T. Howes, and S. Kille. Lightweight Directory Access Protocol (v3). IETF, Request For Comments 2251, Dec 1997. 33] Mohammed Zaid. Personal mobility in PCS. IEEE Personal Communications, Fourth Quarter 1994.