ICEBERG Design

Tuesday, Feb 9 1999

ICEBERG Architecture

The ICEBERG Architecture for Computer-Telephony Inetgration is shown in Figure 1 (copied from Anthony's BMRC talk). Iceberg Access Points (IAPs) are placed between an existing network and the IP-Core. IAPs are not only protocol level gateways but also service level transformation agents.

Figure 1: ICEBERG Architecture

Communication through the ICEBERG network is device and end-point independent. Services are accessible to users across all access networks and end-devices. The IAPs do the transformations to provide this transparency.

The Issue of Naming

Definition:

Our requirement is that a user should be able to access services through multiple devices that she may possess. For example, she should be able to receive phone calls on her cell-phone or laptop or POTS phone. And this redirection should be transparent to the caller. This requires that the network specific ids of the different devices should map to a unique-id that identifies the user. Also, the redirection should depend on a set of user-specified preference rules.

Proposed Solution:

• Each user has a unique-id. Following the style of e-mail ids, this could be something like bhaskar@cs.berkeley.edu.
• There are two architectural components: a name mapping service and a user-preference registry. These two components were clubbed together earlier under the name of "directory service".
• The name mapping service maps the unique-id to a set of network-specific ids. For example, if you ask for the cell-phone number of bhaskar@cs.berkeley.edu, the name mapping service will provide it. We'll also need a reverse name mapping service (a user may dial my office phone number from a POTS-phone and I may wish to receive it on my laptop).
• The user-preference registry has the users' preferences stored in some form. The preference rules specify the preferred end-point on a call-by-call basis. (We call this a registry and not a database - following the LDAP terminology).

Another level of refinement:

• How to implement the name mapping service? A unique-id looks like an e-mail id. This suggests that the name mapping service can be implemented just like mail servers. Name servers are located using a mechanism similar to DNS MX record lookups. And a name server maintains the mappings for a particular domain.
• How to implement the reverse name mapping service? The mechanism to distribute the reverse name mapping is not fully clear yet. The current thought is that it would be something like this: for reverse mapping phone numbers, there would be a server for each area code. And there would be a separate service to locate the appropriate server given an area code.
• How to distribute the preference registry? The preference registry can be distributed in the same way as the name mapping server. There is a preference registry for each domain.
• How to store information in the preference registry? We need a mechanism to specify user preferences. The preferred end-point could depend on a number of per-call factors as well as mid-call state. Since this is a complicated issue, it is discussed separately below.

User Preference Registry

Seen as a black box, the user preference registry is the component of the system that decides the preferred end-point on a per-call basis. The current list of variables that can decide the preferred end-point fall into 2 categories:

1. Per-call information
   • Caller-id
   • Time-of-day
   • Caller's end-point type (cell-phone or pager or VoIP)
2. Mid-call state
   • Network Reachability (for cell-phones)
   • Busy or ringing

The IN-Architecture also has call handling based on some of these parameters. But I think the differences are:

• In the IN-Architecture, the preference storage mechanism is not flexible enough - it is tightly coupled with the telephone network design.
• In the IN-Architecture, the "intelligence" that stores the preferences presents an interface that is closely tied with the call-signaling protocol. Ideally, this should not be the case with ICEBERG. But I dont know if that's possible. With this current design, the interface to the preference registry is not tied to the call-signaling protocol - but this may change.

We should look at how this is handled in the recent efforts on personal mobility standardization in the telecomm world (UMTS/FPLMTS).

Current Design

• User preferences are stored as XML documents.
• The interface presented by the preference registry is: XML queries that return the preferred end-point for a given set of call parameters.

Coming up

• Examples of XML documents specifying user's preferences.
• Example of a scenario where a call across the wide-area is handled according to user's preferences