A Scalable Service Architecture for Computer-Telephony Integration R. Katz, A. Joseph, S. Czerwinski, T. Hodes, B. Hohlt, E. Kiciman, R. Ludwig*, S. Mukkamalla, K. Oden, A. Ordonez, B. Raman, J. Shih, H. Wang, B. Zhao Computer Science Division Department of Electrical Engineering and Computer Science University of California at Berkeley, Berkeley, CA, USA 94720-1776 * affiliated with Ericsson Radio Systems
Abstract
them to the local environment. Once connectivity and the local control interface is established, your device asks the infrastructure to establish a secure “path” from the local environment to your personal information space of preferences, address book, messages, agents processing on your behalf, etc. The device creates the path by exchanging network- and service-specific authentication information with the local access network (e.g., communicating the user’s Caller ID information from a cellular phone). The gateways along the path transcode the information to the appropriate format for each network.
The convergence of traditional voice-oriented telecommunications networks and data-oriented computer communications networks is yielding new challenges for building systems equally adept at handling voice and data applications. While there is much discussion about packetized voice over IP networks, a little explored opportunity is the ability to more easily deploy innovative new services based on the Internet’s client-server paradigm and the ease with which software agents can be introduced and migrated around the network. We discuss our new architecture for middleware services that more effectively enables the integration of telephone and data application. This horizontally-integrated architecture supports competition between interchangeable service implementations, based upon features, cost, etc. It is characterized by pervasive and seamless access across multiple cascaded networks. We describe our experiences in integrating an Internet-based core with cellular and other access networks, and our analysis of IP performance in this testbed using a graphical multi-layer protocol analysis tool. Based on our architecture, we have developed prototype converged applications for voice-actuated room control and personal “universal in-box” information management.
Agents in your personal information space are processing email, voice-mail, faxes, and paging messages for you. Based on your preferences and user- and service-specified policies, any communications (including two or more way conversations) directed at you can be intercepted, translated to the desired form, and delivered on your preferred device. Using this Universal In-box Service, your e-mails can be processed and summarized, and converted into text for delivery via the Short Message Service to your cell phone. A more sophisticated example is capturing a voice message, directing it to a speech recognition service, passing the resulting text to a natural language service to intelligently extract headers, and delivering the summary to your e-mail in-box.
Key Words and Phrases: Computer-telephony integration; middleware; data and voice convergence; hybrid network architectures;
1. Introduction
We call these services and capabilities Potentially Any Network Services (PANS), as they are accessible from multiple networks. These PANS services are enabled by the convergence of telecommunications and data networks. This paper presents an architecture that provides the necessary tools and framework for building the applications in this scenario
1.1. A Motivating Scenario Imagine that you walk into a room with a multi-network communicator device that operates over several wireless networks: IR, Wireless LAN, cellular (alternatively, you might be carrying several devices: a cell phone, pager, PDA, and laptop, each with its own options for network connectivity).
1.2. The Opportunity: An End-to-End Digital Network based on IP
Your communicator (or preferred device) connects to the local infrastructure and dialogs with it to build a custom User Interface (UI) for controlling the room’s environment. This control UI could be device-specific (e.g., a cell phone might use a speech-based interface, while a laptop a Graphical UI). Using a cell phone, you could speak the phrase “dim the lights,” and the lights in your room would be dimmed. Step into another room, and utter the phrase “lights on,” and the lights in that room would come on. Location information provided by the end-device or access network would be used to specialize the speech-recognized commands and apply
There is much discussion about the convergence of telecommunications and data networks. The fastest growing sectors of the telecommunications market are cellular/mobile access networks on the one hand, and the Internet/World Wide Web on the other (Figure 1). The growth of mobile phone subscribers has been so rapid that the number of mobile phones may soon exceed the number of wireline phones in some parts of the world (Figure 2). These trends suggest an emerging pervasive capability for access to information on the
1
Millions
Millions of Subscribers
Source: Ericsson Radio Systems
700
Mobile Telephone Users
600 500
700 600
Internet Users
400
Source: Ericsson Radio Systems
500
300
400
200
Digital
300
100
200 0 1993
1994
1995
1996
1997
1998
1999
2000
2001
Year
100
Figure 1. Rapid Growth of Mobile Telephone Subscribers and Internet Users World Wide
1993
1994
1995
1996
1997
1998
1999
2000
2001
Year
Figure 3. Second Generation Cellular Networks Represent the Largest Base of Digital Access to the Subscriber
Source: Pyramid Research in The Economist, 31 Oct 98
Millions of Telephone Lines
Analog
0
4.5 Wired
4
Mbps
100
3.5 3
10
2.5
60 GHz
Systems
100 m range
Wireless
F ixed
2
Mobile Broadband
Local Area
M o b ile
Networks
1
Universal Mobile Telecomms Systems
1.5
(UMTS)
Cordless
1
0.1
0.5 Cellular
0
0.01
1996
1997
1998
1999
Office or
2000
Building
Stationary
Walking
Vehicle
Room
Figure 2. Growth of Cellular Subscribers in Hong Kong: Mobile Access Reaching Parity with Fixed Services
Indoors
Outdoors
Figure 4. Expected Bandwidths in Third Generation Systems
move, enabled by portable access devices that combine some of the capabilities of a telephone with those of a personal digital assistant (PDA) (e.g., communicator devices like the Nokia 9000 and the new Qualcomm PdQ).
cations like packet voice. Nevertheless, the technology for voice over IP is progressing rapidly, and its usage will accelerate. Exploitation of voice, and services that enable more effective use of voice, will be important in the converged network. This is especially true in the context of small, portable access devices with limited user interface support.
That these networks would become converged is inevitable. While the core of the public-switched telephone network (PSTN) has been digital for several decades, it is only recently that full end-to-end digitization of the phone network has become more real. The rapid growth of digital cellular access networks has led the way, providing a pervasive digital infrastructure supporting mobile users, albeit at low data rates (Figure 3). Third generation systems offer the promise of hundreds of Kbit/s to small Mbit/s in the wide area (Figure 4). These developments are being followed by accelerating deployments of broadband access to the home, via such technologies as cable modem and xDSL, driven by the exploding demand for Internet access (Figure 5).
In fact, World Wide Web access is overtaking voice as the “killer” application of future networks. In places like the San Francisco Bay Area, data is already represents the dominate data type of the network. Marketing studies predicate that the fastest growing applications of the integrated network Forecast American Households with Internet Connections (millions)
Source: Forrester Research in the Economist, 7 Nov 98
35 30 25
With the rollout of digital broadband “last mile” extensions, momentum is building for a universal IP-based core network. IP networks have advantages in terms of low deployment cost, support for heterogeneous link, network, and access device technologies, and ease of deploying networkbased services around well-understood structuring methods such as Remote Procedure Call [Nelson84] and Active Messages [Culler92]. But IP networks also face challenges in achieving adequate performance for critical real-time appli-
20 B ro ad b an d 15
N arro w b an d
10 5 0 1998
1999
2000
2001
2002
Figure 5. Broadband Digital Access to the Home Will Grow Rapidly But Not Completely Displace Narrowband Modem Access in the Next Few Years
2
Local Switch
Interexchange
1.3. The Challenge: Services for Multi-Networks and Diverse End Devices
Local Switch
We assume the continuation of diverse access networks integrated around an IP-based core, with deployment of voice over IP. Our focus is on new services and their rapid deployment in the core. The challenge is to develop a service architecture that achieves seamless access across networks (PSTN and IP), devices (telephones, pagers, computers), types of communications media (speech, message, Web), and userinterfaces (hands-free, keyboard-free, keyboard and mouse).
Network (IXC) Local Exch
Local Exch
Net (LEC)
Net (LEC)
Local Switch IWF + Router
Voice Traffic Connection-Oriented
Local Switch IWF + Router
PSTN Local Exch
Local Exch
Data Traffic Packet-Oriented
Access Network
IP-Based WAN
Local Gateway
Core Network
Local Gateway
How can I best reach you if you have a mobile phone and a wireless laptop computer? It should be easy for you to receive calls or access your e-mail whether you choose the phone or the laptop. Consider the mobility service available for telephones, via the cellular network, and for portable computers, via the Mobile IP protocols. These are networkand device-specific. There is no existing service that allows you to move easily between telephones and computers, continuing to access your calls and e-mails as you do so. We explore these questions as challenges for the architecture.
Access Network
Figure 6. Migration of the Network Towards an IP-Based Core
will not be voice, but rather web-based transactions [Nelson98]. A network for excellent end-to-end data transaction performance is important, perhaps more so than support for real-time applications like voice and video. A by-product of these developments is that the circuitswitched PSTN infrastructure has become overloaded. This marvelously engineered system was never designed for the long duration connections of computer dial-up sessions. Local operators are being driven to integrate a packet switched infrastructure with the circuit switched PSTN, e.g., by integrating an IP router into a switch. Hence, the forces are already driving the operators towards an IP-based core.
What is the “best” network to reach you (network transparency)? Individuals should be “connected” irrespective of the access network they currently choose or their preferences for how to be reached. The service architecture must enable the use of service- and user-specific policies for routing (and transcoding) streams between networks: policies that allow the services layer to determine the “best” network to use.
Figure 6 illustrates how this migration is taking place. In today’s PSTN, data is converted from digital to analog to digital form several times and transported through the infrastructure as though it were voice traffic (top part of figure). The first step in the migration is to capture the data streams in the access network and route them through an IP-based wide area network to their destination. This could be through a local router/switch for modem terminated traffic or via gateways directly to a corporate LAN. Interworking functions (IWFs) manage the necessary conversions between formats1. The second step is to deploy voice over IP gateways in the local area, and use the WAN rather than the PSTN as the wide area transport. Bypassing the local exchange with direct access to the Internet is a major advantage for broadband access networks like cable modems.
If I send you an e-mail message, can you access it on your cell phone (device- and type-independence, device-transparency)? Type-independence means an individual can receive any communications medium, irrespective of type. An email can be speech-synthesized for a user on a telephone, while an e-mail can be composed via speech recognition and dictation. Type-independence enables device-transparency: e-mail can be delivered to telephones and voice-streams can be delivered to electronic mailboxes. Device transparency and network transparency yield device independence: the user chooses to accept communications in any form and manner, irrespective of originating device, network, or media type. Likewise, they can access services in other networks, regardless of the format of that service’s data. Can you easily move from listening to your e-mail on a cell phone to reading it on a laptop (service mobility)? Services, including those in use, should be accessible even as the user moves from one network to another. The ability to pass an active service across network boundaries is service handoff. Providing support for service handoff is challenging. It requires separating control (signaling, semantic information, and service metadata) and data information for each network, and propagating such information across each network boundary. For example, when a VoIP user using a laptop and a wireless LAN dials Enhanced 9112 (E911), what location is passed to the emergency services operator?
While existing access networks for wireline voice, cellular, paging, etc., will not soon disappear, the notion of an integrating “IP Dialtone”--a single network for wireless, Internet, and voice access--is becoming a reality (e.g., Sprint’s Integrated On-demand Network, MCI/Worldcom’s On-Net, Qwest Communications, Level 3 Communications, etc.).
1. The GSM cellular network deploys IWFs to eliminate the need for modems in end devices, since the GSM digital airlink can support data frames as well as digitized voice frames. Amazingly enough, the IWF converts data back to an analog for transmissions over the PSTN.
3
Multi-modal Interfaces: Telephones are designed for voice, with a limited UI provided by the handset. Computers are designed for data (voice is a kind of data), and are difficult to use without a keyboard and pointing device. How can applications be built once, but used on such different devices? Support for access from any kind of end-device, irrespective of the communications media it accepts, requires pervasive support for strongly-typed device interfaces and data formats and any-to-any format conversion. The architecture must provide application-level tools for describing and constructing interface components, and system-level tools for automatically composing these. Given such tools, UI developers can implement transcoding/transformational operators along with multi-modal interfaces. The environment then dynamically composes operators and interfaces to serve new devices. This work has been examined initially in BARWAN [Brewer98], but not in the context of the huge heterogeneity spanning voice and data networks.
one component with another, perhaps implementing an enhanced functionality or offering a lower cost solution. “Wide-Area” means the components are distributed across the network, and can execute on heterogeneous underlying systems embedded in the switching fabric. For example, computationally-intensive services, such as voice recognition, could be provided by third-party service providers each with different tradeoffs between quality and speed of recognition, with different charging models for their use. Automatic Discovery, Composition, and Use: We envision an environment where alternative implementations of components exist. An essential ability is to automatically discover or locate these services or components capable of providing the desired functionality. If there are no available components providing the needed functionality, the environment automatically synthesizes it by composing more primitive components. For example, if a speech-to-email conversion component cannot be discovered, then the service environment dynamically constructs one by composing a speech-totext component with a text-to-email component.
1.4. Technical Capabilities of the ICEBERG and Ninja Service Architectures
Powerful Operators: Clusters, Databases, and Agents: Components should be based on powerful operators. The runtime environment should exploit a cluster computer base for providing incrementally scalable computation, memory, and storage. It should leverage database technology for the persistent and efficiently organized storage of large amounts of information. It should exploit “agents:” major pieces of software functionality that can move through the network.
Our work is being developed within the context of two interrelated projects at Berkeley: ICEBERG3 and Ninja4. ICEBERG is developing architectures for combining voice and data services in third generation digital cellular networks. These are used by two types of entities: users (callers and callees) and agents acting on their behalf. Ninja provides the distributed run-time environment that supports service creation and manages its execution. We are constructing a testbed incorporating current and prototype access nets, spanning GSM cellular, wireless LAN (WaveLAN and Bluetooth), two-way pager (ReFLEX), and integrated by a high bandwidth IP-based core (gigabit Ethernet). This testbed provides a rich proving ground for experimenting with ubiquitous access to information, anywhere, anyplace, anytime, using any service and any I/O device.
Viable Component Economics via Subscription, Pay Per Use: Enabling a component economy is essential to incentivize new services deployment. Users could be charged each time the service is used. Or they could subscribe, offering payment for a usage period. The service environment provides mechanisms for accounting, billing, and payment (just like the existing PSTN service infrastructure!). Supports Diverse Devices, Sensors, Actuators: The environment must support a wide selection of access and display devices beyond traditional computer and telephone-based artifacts. These may include thin clients like wall displays, devices with speech- or gesture-based interfaces, environmental sensors for detecting heat, light, and motion, and controls like building HVAC. Even the thinnest of devices can leverage the infrastructure’s computational resources to deliver functionality that is beyond their local abilities.
ICEBERG and Ninja simpilfy the construction of services by providing plug-and-play wide-area components; automatic discovery, composition, and use of components; powerful data transformation operators; support for e-commerce; support for very diverse devices, sensors, and actuators; and the ability to combine components to provide ubiquitous support for access and mobility. We describe each in more detail: Plug-and-Play Wide-Area Software Components: A distributed component architecture is essential for the kind of service model we envision. “Plug-and-play” implies that components are horizontally organized, rather than vertically and tightly integrated. This permits the easy replacement of
Connects Everything via Ubiquitous Support for Access and Mobility: To achieve “big infrastructure, small clients,” all client devices must be connected, though the connection quality may vary. Thus, the environment must provide capabilities for continuous access and mobility. This includes: providing the necessary interworking functions and the tools for appropriately provisioning the IP transport network and its resources to insure adequate performance for delay sensitive real-time streams (e.g., soft quality of services support
2. An emergency services operator in an Enhanced 911 system receives information about the caller’s identity (the owner of the telephone line) and the location of the telephone line. 3. http://iceberg.cs.Berkeley.edu/ 4. http://ninja.cs.Berkeley.edu/
4
and RSVP and class-based queuing for bottleneck links).
capable user equipment is distributed throughout the network. When it does, the economics of this industry may also change.”
Structure of this Paper
The transparency and independence attributes described in Section 1.3 are enabled by an IP core network, with gateways to other networks. This enhances flexibility and performance because media sources and destinations become software components communicating over high speed networks. The IP core provides a common routing and computational overlay structure to diverse networks that are otherwise closed to external modification control.
This paper presents an open services architecture for managing heterogeneity in the converged network. It is a middleware layer of applications building blocks that make it easier to develop new kinds of converged applications that combine elements of data and voice support. The rest of the paper is organized as follows. We develop the set of requirements for the Services architecture in Section 2. Section 3presents our new Services architecture. The run-time environment is called Ninja while the set of services it supports tailored for computer-telephony integration is called ICEBERG. Section 4 illustrates how an application makes use of the underlying services. We present integration and performance issues in Section 5. Section 6 discusses related work. Finally, Section 7 provides a summary and future work.
Another enabler is the shift in the locus of control from centralized service providers to distributed third-party service providers and end-users. This shift means providing external access to the control flow of information and to computational resources that are located in the core of the network. 2.1.1 Computation in the Infrastructure
2. A New Services Architecture
The service architecture must support scalable, highly available and customizable services. Exploiting processing in the infrastructure makes it possible to give access to very powerful services, like speech recognition, to even the simplest “thin client” PDA. Thus, processing in the infrastructure is a key ingredient in delivering functionality to thin clients, including encapsulating legacy servers that have been designed for more powerful access devices. Infrastructure processing must also be highly available, reliable, and incrementally scalable. In the San Francisco Bay region, it is not outlandish to think in terms of hundreds of thousands of users simultaneously using the infrastructure. Using an architecture based upon distributed processing greatly simplifies the task of providing high availability and reliability.
2.1. Horizontally Integrated Service Architecture for Multiple Networks In today’s networks, the network, access devices, communications media types, and services are tightly bundled, e.g., the telephone handset is bundled to the voice service and the device’s phone number ties it to a particular wireline or cellular network. One of ICEBERG’s goals is to decouple these components. In doing so, the architecture enables the dynamic composition of devices, media types, and services to create new integrated services. As discussed in Section 1.4, the key challenges are how to create a communications environment that supports transparent and optimized access across multiple networks (network transparency), providing any-to-any format conversion for access to media types (type-independence) from any devices (device transparency and device-independence), while retaining access to services as users move across networks (service mobility).
2.1.2 Interchangeable Component Services A key application will be enabling the dynamic creation and composition of software agents in the infrastructure. These will include agents for mobility, redirection, translation, and other forms of automatic adaptation of the network to enddevice characteristics and network connectivity. The network uses agents to support emerging information appliances that are neither handsets nor personal computers but combine elements of both in a portable/handheld package.
Implementing user-driven transparency and independence requires a shift from a traditional vertically integrated service architecture to one that is horizontally organized. The architecture must enable interchangeable component services and pervasive access. Dr. George Heilmeier, Chairman Emeritus of Bellcore, is among the first to observe the need for a horizontal service organization [Heilmeier98]:
Dynamic composition is enabled by strongly-typed interfaces for individual service components, data types, and enddevices. With such interfaces, automatically composing a transformation path from a source device or data type to a destination device or data type becomes a simple matter of searching for the shortest path in a graph of operators.
“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
2.1.3 Pervasive Access Access networks are not likely to disappear soon, nor are they likely to become homogenous. They will continue to differ in coverage, bandwidth, latency, and cost. New access
5
technologies are continuously being brought to market, such as third generation cellular systems (UMTS/IMT2000), next generation wireless LANs (Bluetooth, HomeRF), and broadband wired access networks (xDSL, cable modems). To realize pervasive access, the infrastructure must integrate these via a common IP overlay. The universal overlay was the PSTN: dialing a phone number caused a page to be sent to a pager. Today’s alphanumeric pagers make it compelling to be able to send e-mail to the pager. The data network provides the requisite common overlay, with gateways to the other networks. With the improved ability to handle voice in IP networks, coupled with H.323 gateways, it is conceivable that the PSTN will be replaced as the overlay.
A similar problem occurs if the emergency request is from a user using a VoIP gateway. The appropriate location is not the one associated with the site of the VoIP gateway itself. For a fixed machine, determining the location requires a geographic database that maps callers’ IP addresses to locations. For mobile users, the location of a nearby wireless basestation may be sufficient. However, for dialup users, it would be necessary to use caller identification and propagate the location based upon the dialup user’s telephone number. For each situation, the architecture must support the propagation of information across each network interface and, in some cases, more than one cascaded networks. The solution here is to leverage local network support for locating callers and to provide an architecture that supports the passing of service-specific metadata between networks.
2.1.4 Software Agents The infrastructure supports software agents. These include redirection agents, intercepting real-time streams to direct them to a new destination. This is for terminal mobility, as well as type-specific redirection based on user policy (typeand device-independence) and forms of service mobility.
Multi-modal Information Access and Smart Spaces Control These allow any-to-any (multi-modal) access to information services and resources and smart spaces through a variety of end devices. Users can use any device and combination of cascaded networks to reach interfaces designed for the particular device/network combination. A number of issues arise when networks are cascaded.
Another class are those performing on-the-fly transformation of data streams. We call these transduction agents. An example is an agent that converts a voice stream to text by invoking speech recognition. Agents can be cascaded. Combining transduction with redirection, for example, makes it possible to redirect a voice message destined for a PSTN end point into a text message delivered to a pager.
For example, an Interactive Voice Response (IVR) service may be located within the IP network or in the PSTN network. The user may have a preference for how to reach the IVR service, and the best network (or mode) must be selected to meet the service’s voice quality requirements.
2.1.5 Examples of Services
Using a VoIP service in the wide-area is an issue. VoIP may introduce unacceptable jitter into touch tones or speech, making tone detection or speech conversion difficult. A decision must be made for the best route to an IVR service, or where to perform touch tone detection or speech recognition. For example, in the GSM network, touch tones are transported as separate control signals. They are not sent through the lossy voice codec, which would render them useless.
This section provides examples of the types of multi-network services that the ICEBERG architecture supports. Cross-network Access to Emergency 911 (E911) Services E911 services provide the caller’s telephone number and location to emergency personnel. In the PSTN, identification and location information are determined by the user’s “line,” a customer information database that maps lines to users, and a geographic database that maps lines to locations. This is important when a user becomes incapacitated after contacting an E911 service. The information is also useful in dealing with false calls. At a minimum, cross-network access to E911 must include identification and location information.
Routing and action location decisions are service- and userspecific, and differ among environments. Acceptable results are achieved by choosing a particular network, or performing an action close to the source. The architecture must provide the means to manage the routing of control and data within cascaded networks.
Consider a user who presses a button on her 2-way pager to send an emergency message to an E911 operator. It is trivial to convert the paging message from a text message into a speech message that can be played for an operator. Providing the location information is not so simple.
3. ICEBERG Architecture ICEBERG5 provides a service architecture for integrating voice and data services in many, diverse, interconnected networks: third-generation digital cellular (GSM, CDMA, and
Using triangulation, the paging network could determine the user’s location. However, there is no mechanism for passing this service-specific information through a paging gateway to the operator located in a telephony network.
5. ICEBERG stands for “Internet-Core nEtwork BEyond the Third Generation.” This captures ICEBERG’s technical approach, which builds a multinetwork capability around an IP-based overlay or core network.
6
UMTS / IMT2000), IP, PSTN, wireless IP, and 2-way pager networks [Goodman97, Kuruppillai97]. These cover a range of transports, input/output interfaces, and user interfaces, yielding many challenges in managing heterogeneity and providing transparency across networks, devices, communications media, and services. ICEBERG is implemented on Ninja, an infrastructure for building reliable, incrementally scalable, highly-available, persistent distributed services on distributed clusters of commodity processors.
in different networks. Interoperability requires converting to the appropriate format (e.g., performing speech-totext to map voicemail to pages or e-mail; or performing text-to-speech to convert pages or e-mail to voicemail). To implement one of these services, the service provider provides an IWF by providing transcoders between data formats or through a single universal format. When there are few formats, implementing all conversions is a better choice. This allows the provider to better map the special features of the data format of one network onto another.
3.1. New Service Architecture
Another task is the control IWF. This functionality is critical because it provides the underlying mechanism for content/operator negotiation and service mobilty.
Potentially Any Network Services (PANS) To illustrate PANS, consider the following. While talking on your mobile phone, you enter your office. Hitting a key sequence on your handset, you redirect the in-progress call to your desktop PSTN telephone (to save money or improve the voice quality). Or perhaps you redirect your call to your LAN’s VoIP gateway, and continue your call while sitting at your computer, checking some account data while speaking with the other party. Service mobility supports movement between networks while maintaining the same service.
•
These exist in multiple networks and need to be mapped or instantiated in a new network using existing services. Consider billing services in the PSTN and digital cellular networks. In the former, billing is on a “line” basis, while in the latter, it is based upon a Subscriber Identification Module (SIM) card. The challenge is to map these services onto IP networks where there are multiple authentication mechanisms (e.g., PGP, X.509, Kerberos, etc.).
Making service mobility a first-class entity means that routing and control information must be passed across network boundaries. Within a single network, information flow can easily be controlled. But complications arise when spanning networks. The challenge is to dynamically change and optimize routing. This is accomplished via a control path associated with the data path. The infrastructure monitors the performance of operators along the path, moves operators when possible, and controls the overall flow of information. Data path changes may be made by the infrastructure, the services along the path, or agents acting on a user’s behalf.
Another multinetwork service is E911 (PSTN and digital cellular networks). E911 calls have priority over other traffic. That same priority must be conveyed across gateways and interfaces between networks (e.g., other calls or traffic must be dropped if necessary). Also, semantic information like the identity and location of the caller must also be conveyed to emergency services operators. As with the previous class of service, the tasks here are to provide data and control IWFs to handle the transcoding of data and control information.
ICEBERG Access Points (IAP) interwork among networks, transcoding the format/signaling used by the control path into compatible protocols for the underlying networks. For example, an IAP between IP and GSM networks adapts the SS7 signaling protocol used by GSM to the MBone routing/ session control protocols used by the IP network.
•
New services Cross-network access enables new services, like services for concierge or assistance, location-dependency, bestmode information routing, and information push. Consider one that allows a user to dial *HOTEL on a phone to have a list of local hotels (customized to the user’s requirements) and rates read back, with the option of being connected to a reservation desk.
Classes of Services Cascaded services described above can be generalized as: •
Mapping an existing service in one network into another
Implementation of an existing service on a new network
Services may be agent-based (e.g., the infrastructure monitoring your location, perhaps by intercepting location update messages in a cellular network, alerting you of changes in traffic conditions for your area). Other agent-based services include: customized news headline clipping, stock market symbol tracking and alerting, etc.
Services offering similar functions in different networks are mapped. For example, all networks have directory services: 411 (PSTN), LDAP and DNS (IP), HLR/VLR (digital cellular), and HA/FA (mobile IP [Perkins97]). These would be used as a part of a universal name to network-specific name resolution process.
A primary task is the implementation of data and control IWFs, coupled with access network-specific information in the development of these services.
Another example service is voicemail (PSTN), E-mail (IP), and pages (pager networks and cellular’s Short Message Service). These offer similar messaging capabilities
7
work from call set-up and control information (SS-7).
3.2. Problems with Services on Multiple Cascaded Networks
The metadata may be passed across the same network interface as the data, or it may be passed to the new network through an alternate route. Once the metadata has been received by the new network, it is used to negotiate and optimize a path through that network, to setup the appropriate routing and transcoding, and to specify billing, authentication, and any other service- or network-specific information.
Cascaded networks introduce several problems that complicate service handoff: Multiple Endpoints in Multiple Networks The complexity of cascaded networks is that users have multiple end devices, some which have multiple network interfaces (e.g., a PDA with cellular, pager, and wired network interfaces). The choice of device or interface may be a function of: connectivity (i.e., users and devices are mobile, so connectivity and reachability changes dynamically), quality of service, cost, etc. The important consideration is that the user should be able to specify their desired choices for routing (see Section 4.3). Mobility in cascaded networks takes the form of terminal mobility and user/personal mobility. •
•
Service Transformations End-to-end cross-domain services raise the question of where to perform data conversions, which may be computationally intensive. Gateway choice and transcoder placement will affect the performance of later operations. Alternatively, computation may take place at servers within the network. With cascaded services, the service may need to negotiate with the underlying network for resources (e.g., computational, call admission, QoS, etc.). It is important that they control where and how conversions occur. Similarly, it is important that services be given control when crossing a network boundary. Here the services negotiate service- and network-specific attributes (e.g., negotiating with the network’s call admission policy or negotiating for a specific QoS).
Terminal mobility may be intra- and inter-network. Intranetwork mobility is movement within a network (e.g., handoff between wireless IP basestations or handover between cellular basestations). The underlying network controls this movement type. It will be internally or externally visible in some networks, while in others it is hidden. Control over handoff may reside with the mobile device (i.e., mobile IP) or with the network (i.e., GSM). Inter-network movement, e.g., handoff between a cellular interface and a wireless IP interface, requires coordination between the two (more details below).
ICEBERG supports both models, including services that span gateways and the infrastructure’s computational resources, while passing of metadata between operators. Example: Cross-system service handoff
User/personal mobility involves users switching among multiple devices. Users switch for many reasons (e.g., location, cost, quality of service, etc.). Some of movements will be within a network, like moving from one workstation to another or from one office phone to another, while others will be cross-network, like switching between a wireless IP phone and an office phone.
Consider a user with a cordless handset capable of wireless PSTN and wireless IP. As the user walks out of range of the PSTN cradle, the handset negotiates with the VoIP network to admit the call and for the appropriate bandwidth and QoS. A PSTN core network component is contacted to bridge/ move the call to the appropriate PSTN-to-VoIP gateway, which then relays the call to the handset’s wireless IP interface. When the user leaves the PSTN, the link is dropped and the call seamlessly continues on the wireless IP network. When the user re-enters PSTN coverage, the process is reversed and the call is restored to the handset’s PSTN interface. These actions require that metadata be passed to the appropriate gateways and resources in each network.
ICEBERG uses indirection to hide both terminal and user/ personal mobility. The architecture associates a globally unique, non-domain-specific Universal Name with users and agents. Universal names with an inter-domain naming protocol provide the reference mechanisms (see Section 3.4.1). Service Handoff Across Cascaded Networks Service handoff requires passing metadata across network boundaries. Such metadata is service- or network-specific and includes, e.g., the caller’s identity, authentication rights, and billing or cost information. It may include the target service in use, since this affects transcoder choice and placement, the requested QoS, or the chosen network path.
3.3. Ninja Distributed Component System
The key to service handoff is to separate control (metadata) from data, and allow each to follow a separate logical path between the source and destinations. The physical paths may be the same or physically distinct, as in the long-distance PSTN network, where call data is sent over a separate net-
Ninja is a software infrastructure supporting the next generation of Internet-based applications. Central to its approach is the concept of a service, an Internet-accessible application or set of applications that are scalable (supports thousands of concurrent users), fault-tolerant (masks faults in the server or
ICEBERG relies upon the Ninja distributed components system to manage computational tasks and resources. 3.3.1 Ninja’s Goals and Objectives
8
network), and highly-available (resilient to outages). Examples of constructed Ninja services include: a stock trading application using any end-device; a Jukebox, providing realtime streaming audio data from music CDs scattered around the network; and Keiretsu, an ICQ-like, multi-modal, instant messaging service for one-way and two-way pagers.
Units
Active Proxies
Ninja services are enabled by a new architecture for service creation and wide-area service deployment that supports the development and evolution of powerful, flexible services across a huge range of computational and networking scale. This is described in Section 4.1.2.
Bases
Ninja’s service requirements are like those for ICEBERG. They are composable (automatically aggregating multiple services into a single entity), customizable (users injecting code to customize a service’s behavior), and widely accessible (accessing the service from a wide range of devices).
Figure 7. Ninja Physical Elements: Units, Active Proxies, Bases
soft-state on Active Proxies. It provides automatic resource discovery using a query language for service location, initiation, and automatic creation of wide-area paths. Wide-area paths are a new concept providing a framework for authentication, resource allocation, privacy, feedback, and dynamic extension and optimization. A path is a sequence of Connectors spanning the network and Operators residing on an architectural component. Paths are realized by a data channel and control channel pair (both described in a scripting language) and are strongly typed, so static semantic analysis is used to ensure that component compositions are meaningful. We describe these next.
Service composability is the basis for automatic path creation, which supports device-independence, device-transparency, type-independence, and wide accessibility in ICEBERG. Reformating and translation operations are composed with the conventional application’s processing step to achieve independence and transparency. Similarly, customizability provides the leverage necessary for end-user control. ICEBERG constructs the components for converged computer and telephony applications, such as those managing cascaded network gateways, speech-enabled applications, any-to-any message format translation, support for mobility and redirection, etc. From ICEBERG’s perspective, Ninja is its service programming environment. The ICEBERG Universal In-Box is an example of an ICEBERG service implemented on Ninja (see Section 4.2).
Structured Architecture Units are simple, low cost, usually mobile, network-connected access devices with little computational or storage ability. Connectivity is likely of low quality: low bandwidth, high error rate, etc. Units include sensors, actuators, PDA, pagers, smartphones, communicators, palmtop, laptop, and personal computers. Units are heterogeneous in their display, processing, and remote programming capabilities (Figure 7).
3.3.2 Ninja Service Model Ninja provides the execution environment to automatically generate and compose services from strongly typed components distributed across the wide-area. Its key elements are: •
A structured architecture with a careful partitioning of state among Bases, Active Proxies, and Units;
•
Wide-area paths, described as operators and connectors, and interconnecting strongly-typed components;
•
An execution environment with efficient communications primitives, based on active messages (i.e., moving executable code to the message destination where it can execute on the remote data).
Active Proxies are connection points for Units supporting bootstrapping, resource discovery, agents and transformation. Their state is not persistent, though soft-state and caches can improve local performance. Active Proxies might be located on the users’ premises, in wiring cabinets, basements, or car trunks. They have good network connectivity, and can execute localization services (e.g., specialized solutions for improving reliable delivery of information, on-thefly data reformatting and translation, etc.). A wireless LAN basestation with local computation is an active proxy. Bases are large, highly available computation and storage centers, providing safe and persistent state. A base might be a cluster of workstations in a machine room managed by an infrastructure provider. It is the place to run certain services that demand high scalability or are processing intensive. A base is where a subscriber account database should reside. Users also have home bases, the locations within the network infrastructure where their preferences and persistent state (e.g., mail archives) are maintained.
A wide-area service operation consists of a Path through bases, active proxies, and units, with each hop potentially being a separate service (involving resource discovery, transformation, or information gathering). Ninja provides a clean solution to state management by maintaining persistent state on highly available bases, and
9
Operator, Connector, and Path Model
same or different networks. Entities are users, callers/callees, or agents acting on their behalf. Associated with each is a unique, non-domain-specific Universal Name that provides a mechanism for entities to refer to others in an abstract way. Services are the Ninja concept of service as an application or set of applications. ICEBERG’s services are focused on those needed to integrate computer and telephony applications, and to make it easier to deploy new services.
Operators are software components that perform operations like transformation and aggregation. All of Microsoft’s COM objects, implementing desktop applications like word processors, spreadsheets, etc., can be operators. An operator can be a simple agent. A more complex agent is constructed by composing multiple operators using connectors. Connectors are abstract “wires” that logically interconnect operator outputs to inputs. Connectors can have varying semantics. Connectors can be unicast, multicast, or anycast.
3.4.1 ICEBERG Service Architecture Finding Services: The Service Discovery Service
Outputs must match the inputs to which they are connected. This is accomplished by interfaces, which are strongly typed, language independent, and mapped to an operator’s access methods. Strongly typed interfaces makes it possible for the infrastructure to dynamically compose operators (e.g., composing speech-to-text and text-to-email operators to create a speech-to-email operator).
A key component of ICEBERG is the Service Discovery Service (SDS). SDS acts as a repository for information about services in the system, and provides to clients directory-style access to this information. The SDS maintains descriptions of services that are available for allocation at Active Proxies or Bases via path instantiation (unpinned services) and services that are already running.
iSpace Execution Environment
The SDS supports both push- and pull-based access, allowing proactive announcement of the existence of a service as well as queries against cached announcements. The former enables passive discovery of new capabilities (e.g., to discover a local smart space) and simplifies state management. The latter allows clients to explicitly query for services while ignoring any dynamic SDS announcements.
Ninja’s run-time is based on Java, but it can support operators in other languages. The environment on a single node (e.g., an Active Proxy) is called iSpace. iSpace allows a service developer to concentrate on service functionality without having to worry about the availability, persistence, reliability, or scalability aspects of the service. The parallel version of iSpace, used on bases is multiSpace, a parallel application development framework for intra-Base execution that has evolved from the run-time environment developed for the Berkeley Network of Workstations (NOW) Project (Figure 8). iSpace and multiSpace are based on Ninja Remote Method Invocation, a customizable service Virtual Machine called iS-box, and a Redirector to balance execution threads among the multiple processors of a Base. iS-Box is the Java Virtual Machine (JVM) extended with a Security Manager and Trusted Services. The latter provide a safe “sandbox” permitting the downloading and execution of foreign code extending the JVM functionality.
The query model enables clients to search for a specific services necessary to complete a path (for automatic path creation), or to allow a user to manually determine path endpoints by browsing available services (for example, to discover a stock trading service or a information dissemination source [Wong98]). Service descriptions and queries are specified in XML. The query language gives agents the ability to perform searches based on varying criteria, allows the set of attributes to evolve as services evolve while still maintaining backwardcompatibility, and provides a clean way to mix data and meta-data. The latter is especially important, because one service’s meta-data is another’s data.
3.4. Design of the ICEBERG Architecture
As an example of a globally-distributed, wide-area service, the SDS exhibits design challenges beyond those living inside a single Base. It must handle network partitions, bandwidth limitations between remote SDS entities, “localization” (i.e., differentiate between service that are “local” to a client and those that are not), and provide application-level query routing between components.
The key concepts in ICEBERG are entities and services. ICEBERG provides services between entities located in the
Managed RMI++
Persistent Storage
iS-Loader
service threads
Trusted-Services
operator upload
Service request
New service
The search problem is more difficult here than in systems like DNS or CORBA’s Globe, because the SDS accepts queries as a complex set of hierarchical attribute-value pairs, rather than in a form where the resolution path is embedded.
Security MGR
Physical processor Caches
Operators
JVM
Figure 8. Ninja Architecture and Run-Time Environment The elements of the run-time environment are the Service API (RMI), SDS, JAVA RMI, and Processor Resource.
10
Unlike techniques designed only to work in the local-area, such as the IETF Service Location Protocol, the SDS must
address scaling discovery to the wide-area. The SDS components are arranged in an adaptive hierarchy managed by the service itself. The hierarchy can be based on service scope, the underlying topology, manually configured administrative domains, or a combination of these.
Iceberg Access Point (One per network) Policy Engine, Routing, Security
IAP Call(Randy@Berkeley, Caller’s network, Interactive, CallerID certificate)
For fault-tolerance, the SDS uses soft-state and relies on multicast to propagate service descriptions, like the approach used by the MBone’s Session Announcement Protocol. State is rebuilt by listening for the service-existence multicasts. It also enables clients, such as service announcers and client agents, to adjust to changes in the underlying hierarchy.
If IAPs can’t be embedded in networks, then resides in IP core
Iceberg Domain IDNP Name Policy Servers Server Profile weeks/months Policy days/weeks System State
Stored in Bases
For security concerns, the SDS controls the agents that can discover services, allowing capability-based access limitations, i.e., to hide the existence of services rather than (or in addition to) disallowing access to a found service.
Figure 9. ICEBERG Access Points
Service Transformation
IAPs execute on Active Proxies or Bases. They provide inter-network access and policy enforcement.
minutes/hours
IAPs are gateways that provide the interconnection between networks. An IAP may be as simple as an H.323 gateway or it may be more complicated, e.g., providing metadata as well as data transport. IAPs perform the link layer and bit transformations, and perform service-level transcoding. In most cases, these operations take place on Active Proxies, while computationally intensive operations execute on Bases.
IDNP Server
This policy is a difference between ICEBERG and the PSTN. Entities can provide code to evaluate variables to make dynamic routing decisions at call setup or when system state changes. It varies on the scale of days to weeks. Typical variables that are used include the caller’s network, the cost for using each of the available end devices, the available QoS or bandwidth, the caller, interactive vs. non-interactive service, and other entity- or service-specific information.
The IAP is the point where cross-domain (network-specific) signaling information or metadata is collected from an incoming network and from the outgoing network. Such information includes authentication and identification information (e.g., a PSTN caller’s telephone number).
Entity-specific policies provide dynamic control over how an IDNP server maps Universal Names to domain-specific names. Figure 10 provides an example of such a mapping. Privacy is important. The exposure of domain-specific names is under entity control. Its policy can specify that a domain-specific name should be returned to a caller or it can specify that the name should be hidden, in which case, the IDNP server informs the IAP that it should forward the call or message to the domain-specific name. The IDNP executes on servers located in each network using portals into the network’s IDNP servers. For example, a special telephone number would be used in PSTN and digital cellular networks.
Cross-domain Name Resolution Service handoff requires cross-domain name resolution. This allows users to provide a single globally unique name (Universal Name) which is dynamically resolved in any network to a domain-specific name using entity- or service-specific policies. This is handled by servers using the ICEBERG Inter-Domain Naming Protocol (IDNP). ICEBERG Inter-Domain Naming Protocol (IDNP) servers map Universal Names to domain-specific names using: an entity profile that specifies the entity’s domain-specific names, system state (for reachability information about an entity), and the entity’s policy for mapping Universal Names to domain-specific names (Figure 9).
The rate of change depends on the type of information. Entity profiles change on the slowest time scale, followed by “Randy@Berkeley”
Universal Names: Globally unique IDs
The entity profile is a list of domain-specific names for the entity’s end devices. It changes on the order of weeks to months--whenever the entity acquires a new device. System state or reachability information is associated with domain-specific names. For example, a PCS phone entry includes network cost and reachability. For a wireless LAN, it includes registration information and available QoS and bandwidth. System state varies from minutes to hours, depending upon the entity’s activities.
An Entity has a universal name and a profile; Entities are people or processes
OfficePSTN OfficePSTN(Teaching): (Teaching):510-642-8778 510-642-8778 OfficePSTN OfficePSTN(Chair): (Chair):510-642-0253 510-642-0253 DeskIP: dreadnaught.cs.berkeley.edu:555 DeskIP: dreadnaught.cs.berkeley.edu:555 LaptopIP: LaptopIP:polo.cs.berkeley.edu:555 polo.cs.berkeley.edu:555 PCS: PCS:510-555-8778 510-555-8778 Cellular: Cellular:510-555-1998 510-555-1998 E-mail: E-mail:
[email protected] [email protected] Home: Home:415-555-5555 415-555-5555
Profile: set of domain-specific names
Figure 10. Multiple Identities for an Individual
11
entity policies. System state or domain-specific reachability may change rapidly over the course of a few minutes or hours, as a function of user and terminal mobility.
Speech-to-Text Speech-to-Voice Attached-Email Call-to-Pager/Email Notification Email-to-Speech All compositions
IDNP servers cache information elements so that they can reduce decision making latency. The information may be replicated and cached at multiple IDNP servers, and changes need to be propagated in a timely and secure manner. Wherever possible, duplication of effort by IDNP is avoided. In particular, name resolution leverages each network’s existing infrastructure. This means, for example, that the profile should contain a device’s mobile IP home address rather than its current wireless IP address.
of the above!
Universal In-box Policy-based Location-based Activity-based
Figure 12. Universal In-Box It provides any-to-any document routing and formating.
4. Testbed and Prototype Service-Enabled Applications
pus, spanning several “smart” classrooms. The toolkit is being used to build collaborative learning services for student use. These include instant messaging and access to web information, shared class repositories, and personal information management applications.
4.1. Campus-Wide Testbed ICEBERG is deploying a testbed consisting of GSM digital cellular, wired and wireless IP, and PSTN networks to experiment with services across cascaded networks and new kinds of services like smart spaces. The ICEBERG architecture and toolkit allow developers to build services across networks more rapidly. The ICEBERG testbed, and the prototype services we are developing on it, will help demonstrate ease of service construction and deployment.
4.2. Transparent Information Access Service: The Universal In-Box The Universal In-Box Service is an early ICEBERG service (Figure 12). Users can manage their incoming and outgoing communications modes. The service drives ICEBERG’s support for cascaded networks that span cellular (using the BTS gateway described in Section 4.2.2), the PSTN (via an H.323 gateway), paging (with the deployment of a two-way ReFLEX basestation from Motorola), and Internet-based electronic mail and real-time streams. It also provides a specific context for any-to-any format conversion services.
ICEBERG/Ninja builds on existing research projects which provide the campus-area processing clusters and high bandwidth network interconnect. The campus-wide testbed encompasses the latest networking technologies, including wired and wireless telephony and early prototypes of digital cellular and high-density wireless LAN technologies (see Figure 11).
This illustrates how the infrastructure can be leveraged to route information in a dynamic, timely, and user- or servicespecific fashion. The service architecture controls routing, within the infrastructure (e.g., agents acting behalf of users) and externally (e.g., service- or user-specific control).
The testbed is being deployed throughout the Berkeley camIBM WorkPad MC-16 Ericsson CF788
WLAN
Motorola Pagewriter 2000 Pager
GSM BTS Network Infrastructure
Millennium Cluster
Smart Spaces Personal Information Management
Millennium Cluster
Figure 11. ICEBERG/Ninja Testbed The Testbed includes GSM wireless, wireless LAN, and Reflex two-way pager access networks. It is being built on a gigabit campus-scale network backbone that will be interconnected to Internet-2 as well as xDSL and cable modem “last mile” technologies. The testbed incorporates considerable processing resources and diverse access devices, including telephone handsets.
12
The Universal In-Box provides user-specific information collection and aggregation, simplifying the task of data delivery and dissemination. Coupled with the automatic creation of transformational paths, the Universal In-Box allows users and services to disseminate information without regard to its format or end-device capabilities. This attribute is an important decoupling of the source of the data and its destination. A user specifies the format of their choice when accessing information sent to them or in interacting with other users. This is an important distinction between our work and related work in universal messaging applications. An example of this service is distributing the same information to multiple users across multiple networks (e.g., sending one message to users with cellular phones, pagers, voicemail, E-mail, etc.). Consider being able to type a message and have it delivered to a list of users, where the list not only
contains e-mail addresses, but also cellular phone numbers, office numbers, pager numbers, voice mail numbers, etc. The infrastructure transparently converts the message to the appropriate format for each recipient. This simplifies and optimizes information delivery for senders and recipients.
Path Audio Microphone Cell phone
4.3. Multi-Modal Interfaces and Smart Spaces Traditional computer applications provide processing (word processing, spreadsheet), storage (databases), and communications (e-mail, Web browsing). Smart spaces is new kind of application that adds end-user control to the list of computer capabilities. These are environments that contain computercontrollable sensors, actuators, and I/O devices (e.g., cameras, microphones, thermostats, etc.). They are an extension of today’s office environments, which contain a variety of computer-controlled devices (e.g., HVAC: Heating/Ventilation and Cooling systems, door locks, elevators, slide projectors, TV monitors, A/V devices, etc.), many of which cannot be directly controlled by users. Cost reductions are making it possible to extend computer control to the home environment, where users are building spaces that contain cameras, microphones, movable blinds, DVD players, and other A/V devices. Users want to be able to access and control these devices using their mobile devices and their new communications networks. A complication is that every smart space is unique--no two have the same devices or interfaces.
IP-Pad (BTS)
The SSC server is based on the Ninja run-time technology to transcode information from any input to any output format. It combines operators, each performing a single, specific transcoding, into a path to perform more complex transcodings. The SSC server uses SDS to discover the operators and creates the paths automatically and dynamically. The steps taken when a user sends a command to a smart spaces room are (Figure 14): •
The user provides speech input through a local microphone, wired or wireless IP using Mbone audio conferencing tools (VAT), GSM voice, or by directly typing.
•
Voice input is converted to Pulse Code Modulation (PCM) audio and a speech recognition operator converts it to text. This requires the selection of a language and an N-gram, an application- or service-specific grammar. If the user typed the commands, this step is skipped.
•
A Natural Language Processing (NLP) operator converts the text into device commands. This also requires the selection of a grammar specific to the target services. Our current NLP engine uses simple word-spotting.
•
The command is delivered to the room entitiy, which forwards the command to the appropriate device. It then sends a response to the user. This is converted to the user’s preferred format via a reverse-path of operators.
Room Control UDP Room (MASH)
Entity
Entity
Barbara
Emre
Response to Client
Users use graphical, text, or speech-based user interfaces to interact with one another and to control the devices in the smart space. For example, Barbara can speak a message into her computer and send it to Emre. He can choose to receive it as audio or as a text popup message. The SSC server automatically performs the transcodings. The source entity does not know the target entity’s output format.
Service Entity
Simja Server
RTP
Room Entity
sending and receiving messages to and from each other. The SSC server’s operation involves the multi-stage transformation of messages being sent between entities.
Figure 13 provides an overview of the SSC environment: an SSC server, remote users of the environment, Java-based services, and gateways to non-Java services and devices. Remote users, services, and devices are entities, capable of
Cell Phone
Text to Cmd Command
Each of the boxes represents an operator in the service, while the ovals are target devices. ICEBERG uses the operator interface specification information passed along the metadata/control to dynamically construct the path from an input source to a destination device.
We have implemented a complex composed service for multi-modal control of smart spaces through cascaded networks: the Interactive Voice Response (IVR) to Smart Spaces Control (SSC) service. It implements speaker-independent IVR to control A/V resources in several classrooms and conference rooms in Soda Hall.
RMI
Text
Figure 14. IVR/Smart Spaces Control Service
4.3.1 Interactive Voice Response to Smart Spaces Control Service
Gateway
ICSI
Speech Recognizer
A/V Devices
We have implemented complex operators using wrappers around large programs: audio format conversion tools, speech-to-text recognition based upon the International Computer Science Institute’s speech-to-text recognition project [ICSI98], text-to-speech generation using the Uni-
Figure 13. The Smart Spaces Control (SSC) Environment This figure shows an SSC server, two local users of the environment (entities), an Mbone RTP gateway to remote users and devices, and a room control gateway. The server provide routing and transformational/transcoding services between the various components.
13
versity of Edinburgh’s Festival project [Festival98], and various existing room control programs [Hodes98].
speaker-independent speech recognition can be slow and inaccurate. However, if the recognizer N-gram is constrained, the result is rapid and more accurate speech recognition. The selection information may come from speaker identification (e.g., caller line identification from a phone) or from knowing the target application or device (e.g., controlling the devices in a smart space).
4.3.2 SSC Architectural Issues “Smart spaces” built on the protocol and middleware underpinnings that allow client devices to act as “universal remote controls” [Hodes97]. One of the key challenges for the SSC service was providing a means for developers to rapidly add new devices and communications networks. The SSC provides strongly-typed transcoding components, automatic path creation (APC), and channels for control or metadata information. We have deployed our control architecture in two seminar rooms in Soda Hall, providing support for a group of participants in a conference room taking part in a lightweight-sessions collaboration [Hodes99].
Ninja provides a control/metadata information channel to convey information between operators, streams, and I/O devices during APC. It is used during operator execution as a mechanism for state information. The channel allows a service to specify requirements such as “target service is room control.” The speech recognition and NLP operators monitor this using a variable like “targetService = RoomControl” and use this to select the appropriate N-gram and grammar.
Strongly-Typed Interfaces
Rapid Extensibility
Operator interfaces describe the input and output data types. They also contain information about how to load and run the operator code. These interfaces are used to enable the automatic composition of operators into paths, and to check the correctness of manually created paths. Interfaces are specified using eXtensible Markup Language (XML) documents.
Adding support for new devices is simple. We added an interface for GSM cellphones to the room control application within a few hours. We are extending the system to support other services, such as multi-modal access to web-based services like headline new and stock reports. Some of these require different transcoding steps from the ones in the basic room control service. However, the environment allow developers to rapidly add support for such services by simply specifying the interface to the new services and devices.
An example data type description in XML for a 44Khz 16bit WAV audio stream is the following: audio WAV 44000 16
5. Performance and Integration Issues 5.1. GSM Cellular/IP Interworking We have implemented an InterWorking Function (IWF) between the GSM basestation (BTS) and an IP core. The IWF converts GSM circuit-switched voice and data calls into IP packet streams. Using our GSM-IP IWF, GSM voice and data calls can be terminated directly by hosts connected to the IP network, including our in-building wireless LAN (WaveLAN).
The Service Discovery Service is the repository for operator interfaces (Section 3.4.1). Automatic Path Creation Given a set of typed input and output devices, operators, and data streams, Ninja automatically creates a path from the input device to the output device. Automatic Path Creation (APC) first chooses the operators for the path, and then instantiates and connects them. It attempts to find the shortest path between inputs and outputs. However, other “operator cost” functions than path length in can be considered, such as total computational cost (e.g., perhaps a longer sequence of operators yields a lower number of computations). If the operators are on separate machines, there are additional “communications costs.” ICEBERG will eventually support developer- and user-specified cost functions.
Design of the GSM-IP IWF Our IWF operates between an Ericsson RBS 2202 basestation (supporting 15 active mobile handsets) and the IP core (Figure 15). The Ericsson User Part Simulator (UPSim) simulates the GSM networks’ control components and provides a high-level control interface to the BTS, such as “establish a call to Mobile Subscriber # on time slot #”. The IP Packet Assembler and Disassembler (IP-Pad) converts the circuitswitched data frames from the BTS into Mbone packets, and vice versa. In the near future, the IP-Pad will include support for H.323-based applications and gateways.The IP-Pad serves as the overall controller for the GSM-IP gateway, controlling call initiation, configuration, and tear-down.
Control/Metadata Channels The choice of operator is not solely a function of the XML interface, but rather of the input/output devices and users. For example, we have found that generic (large vocabulary),
Figure 16 shows the mapping between the GSM time slots
14
I nf o caster
s im u la t e B S C , M S C , a n d H L R f u n c t io n a lit y
N etM ee ting
VAT
2 TRX
C ontr ol S ign aling S ig na lin g E1
RBS 2202
to a local address for each access network cell or segment. Each network implements its own functionality for mobility. IP nets use Mobile IP with its home agent/foreign agentbased approach, while GSM uses a Home Location Register/ Visiting Location Register. Both systems provide the same functionality--indirection for location independence--yet they use different mechanisms.
I nte ractive V o ice R es po nse
Uses OM & TRAFFIC to
U PS im
GPC board
PC
Internet
IP-PAD
Thor-2 E ther ne t
T r aff ic E 1 : V oice @ 1 3 k b /s D ata @ 1 2 kb /s
GSM Phone
We are investigating how to provide interworking between these, so users can freely roam between these networks. This is a service handoff view of vertical handoff [Stemm98, Wang99]. It involves moving the call-setup state to a new network (i.e., changing the routing of the call) or forwarding the call data to the new network (i.e., similar to the way MSC-to-MSC handover is performed in cellular networks).
P e r f o rm s ra t e a d a p t a t io n f u n c tio n o f Z A K / T RA U
H .3 2 3 G W
PSTN
Figure 15. ICEBERG GSM-IP InterWorking Function (IWF)
2 bits from an E1 time slot = one 16kbps stream
0 1 2 32 E1 time slots per E1 frame
Related to mobility management are Generalized Redirection Agents. These are user- or service-specified dynamic policy-based redirections (1-800 service, email-to-pagers, etc.), and are required for service mobility.
8 bits per E1 time slot
5.2. Graphical Multi-Layer Protocol Analysis Cascaded networks result in multiple communications protocols executing at different layers (i.e., link, transport, network, etc.). Each layer is designed and implemented independently. However, it is important to understand the effects of inter-layer interactions.
31 Figure 16. Time Slot Mapping
and the timing structure expected by the PSTN. E1 timeslots, each of which provides 8 bits at 8 Khz or 64 Kbit/second, on the link between the RBS and the IPPad. GSM voice requires only a 13 Kbit/second data stream, so to save bandwidth, the audio from four mobile subscribers is interleaved, using two bits from each call at a time, into a single timeslot.
This requires tools that allow developers to quickly evaluate protocol performance using experimental measurements and simulation tools. The former are critical because they expose effects that are not visible using simulation (e.g., errors or differences between the implementations used for experiments and simulations). Tracing protocols, even for short periods of time, results in a large amount of trace data (300 bytes/s of trace data for a 10 kbyte/s connection).
Figure 17 illustrates the process by which the time sequence voice data is mapped into the IP packet format. The IP-Pad extracts GSM audio frames from the bit stream from the BTS, prepends the appropriate headers, and injects the packet into the Internet. The frame format is compatible with standard Mbone conferencing tools (e.g., VAT).
To provide a platform for rapid performance analysis, we have developed a graphical, multi-layer protocol tracing tool, MultiTracer. The tool is part of a testbed for collecting trace data at multiple protocol levels. Figure 18 illustrates where trace collection resides within our testbed. MultiTracer post-processes trace data by automatically performing the customized correlations and representation conversions. The resulting data is presented in a comprehensive, interactive graphical manner (Figure 19).
Mobility Management Interworking An important consideration for mobile users is providing a single access network address (e.g., phone number or IP address). This is accomplished by mapping a unique address 320 bits (40 bytes) from
flag
We are examining the performance of TCP over GSM circuit-switched digital cellular links, where the radio link is protected by a reliable link layer protocol (RLP). We are interested in understanding whether retransmissions at the link layer due to high error rates are misinterpreted by TCP as congestion related losses. Initial measurements show that TCP throughput over GSM is optimal in over 60 percent of the traces. These results are surprising, given that our trace set includes a disproportionate amount of results from poor coverage areas. They confirm earlier work [Baucke97] and
flag
a 16kbps stream
260 bit (32.5 byte) GSM audio frame
IP packet IP header
RTP header
RTP payload : 33 byte GSM frame
UDP header
Figure 17. Mapping onto IP Packets
15
Traffic Source/Sink (e.g. sock)
6. Related Work
Traffic Source/Sink (e.g. sock)
6.1. Internet Technology
TCP RLP
ICEBERG is assumes as it foundation several critical aspects of Internet technology that are influencing the evolution of future converged networks. The first is that intelligence and control are migrating to the network edges. Packet audio is enabled, in part, by software-based audio and video codecs in powerful end-devices. This is now migrating to relatively inexpensive hand-held devices. Internet protocols like Real Time Protocol (RTP) make no assumptions about the quality of the underlying network, but rather adapt the sending rates to what the network can support [Schulzrinne95]. These protocols form the foundation of the H.323 gateway architecture for integrating the PSTN with the Internet [ITU98].
BTS IP Backend Fixed Host UNIX (BSDi 3.0)
Mobile Host UNIX (BSDi 3.0)
GSM Basestation
TCPDUMP
TCPDUMP
TCPSTATS
TCPSTATS RLPDUMP
RLPDUMP
MultiTracer
Plotting Tool (e.g. xgraph)
The second is the placement of a computing “utility” in the core of the network. Today, computers are at the network edges, administered by end organizations. We expect to see more processing and storage in the core, deployed by service providers and offering capabilities for the deployment of services valuable for end users. One such service is the transcoders used to adapt web content for display on handheld devices [Fox98]. An impediment to such service deployment has been an inability to charge for it. This may change in the converged network. Even if it does not, the ability to deploy new services on top of computers embedded in the switching infrastructure could serve to differentiate service providers from their competitors through more comprehensive and sophisticated service offerings. This is also part of the motivation for the Advanced Intelligent Network, but that effort is tightly integrated with the call-oriented structure of the PSTN. It cannot harness the huge developer community familiar with Internet technology.
Trace Replay in Simulator (e.g. ns, BONeS)
Figure 18. Multi-layer Tracing Environment
[Kojo97]. However, our setup gave us the opportunity to determine the throughput that TCP provided to the application relative to what RLP provided to TCP. Without insight into link layer performance, it is impossible to infer whether low throughput above TCP was due to a bad radio channel or inefficient interactions between TCP and RLP. Our results reveal that spurious TCP timeouts are rare and do not significantly affect throughput, contradicting previous claims [DeSimone93, Balakrishnan95, Kojo97]. These mention the problem of competing retransmissions between TCP and a reliable link layer protocol resulting from spurious timeouts at the TCP sender. [Kojo97] even claims that this is the main reason for those cases where the throughput of TCP running over RLP is not optimal. However, we could not confirm this explanation with our measurements.
IP will emerge as the common routing glue to interconnect diverse access networks and access devices. Because of the closed nature of many of the existing access networks, including the PSTN, the IP core is also the most attractive location for deploying new services.
We are just beginning to use MultiTracer for network performance. However, it already demonstrates a powerful ability to experiment with protocol simulations across layers.
6.2. Integrated Services Packet Network
Bytes
416000
412000 410000
The Next Generation Internet will likely borrow ideas from more traditional telecommunications networks, such as reservations. It will also includes features not well supported in the existing PSTN: multipoint-to-multipoint multicast communications, mobility, and mobile route optimization.
TcpRcv_ack
TcpRcv_data
414000
13 Segments dropped at TCP receiver
5 Segments lost due to RLP Reset
TcpSnd_ack
408000
TcpSnd_data
406000 404000
To provide better support for differentiated services, the Internet community has defined mechanisms for reservationbased resource allocation, using protocols such as RSVP [Zhang93]. Reservations are “promises” rather than guarantees, and applications must be written to adapt to varying network performance conditions. The protocols have been designed to scale by being receiver-directed and integrated
18 Segments
402000 400000 398000 480
RlpSnd_rst
485
490
495
500
505
510
515 520 Time of Day (sec)
Figure 19. Example MultiTracer Plot
16
with the network’s multicasting routing protocols (a soft/ dynamic form of connection-orientation). They are based on soft state in the network to allow robust recovery to failure.
an inexpensive, portable terminal. It was an early effort to implement the concept of “big infrastructure, small client,” motivating primarily by moving power and computing intensive processing to the wireline infrastructure [Narayanaswamy96]. An InfoPad was a “network terminal,” but with the additional capability of portability.
Software-based codecs for real-time audio and video streams are widely used. Rather than use the PSTN’s 64 kbps pulse code modulation (PCM) coding, numerous software codecs exist for 36 kbps adaptive pulse code modulation (ADPCM), 17 kbps GSM (used in the international digital cellular standard), and even 9 kbps linear predictive coding (LPC). “Adequate” conferencing video can be achieved at 28.8 kbps to 128 kbps (entertainment video requires higher data rates).
Xerox PARC Ubiquitous Computing Projects In the early 1990s, the Xerox Palo Alto Research Center built a variety of access devices, called tabs, pads, and boards, as part of its ubiquitous computing initiative. The concept was that traditional computers would disappear. While the effort did not develop a comprehensive service architecture, it did develop many innovative applications related to smart spaces and collaborative environments [Want95].
Another key component is the Real Time Protocol (RTP). In RTP and its associated control protocol RTCP, the ends adapt audio/video streaming rates to what the network can support. This has been integrated into the International Telecommunication Union’s specifications for the H.323 protocols for integrating the Internet and PSTN for real time streams.
Daedalus/GloMop
An especially important point is that the Next Generation Internet admits of the easy integration of new services like transcoder proxies.
The Daedalus/GloMop project at Berkeley developed a networking and applications support model for diverse wireless access networks and heterogeneous end devices [Brewer98]. A key element of the approach was the client-proxy-server model, which placed software functionality in the path between server and client to adapt content to the capabilities of the end. Thus a large-format, full color web image could be transcoded on the fly to a format suitable for display on a PalmPilot PDA screen. Related to proxies is the ability to deploy them on a Networks of Workstations computing platform, which yields a service that is both scalable and highly available. The TACC (Transformation, Aggregation, Caching, and Customization) model makes it possible for userwritten services to be embedded in the run-time environment. The system supported only limited customization of services and persistence of data, and was not designed for wide-area execution.
6.3. Voice over IP Voice over IP is developing rapidly. Quality issues remain, especially in terms of high latencies and packet losses. However, these issues will be migrated by the deployment of appropriately provisioned (virtual) private networks, faster/ scalable hardware to reduce gateway latencies, the pervasive use of RSVP, H.323, and more sophisticated techniques for the reconstruction of lost packets using smarter forward error correction as well as interpolation between voice packets, and better voice coding at lower data rates such as 8 kbps. While it may be inelegant to solve performance problems simply by adding more bandwidth, the fact remains that at least in the wide area, bandwidth is a commodity. Several n e w g en e r a t i o n s e r v i ce p r o v i d e r s , s u c h a s Q we s t (www.qwest.com) and Level 3 (www.level3.com), are deploying SONET-based fiber optic, packet switched, national and international backbones with very high available bandwidth. These support Voice over IP with dial-in gateways and direct conversion into 64 kbps data streams. Note however, that bandwidth in the local loop is not a commodity, at least at this time, and must still be carefully managed, perhaps through such mechanisms as policy-based queue management across bottleneck links [Floyd95].
6.5. Object Systems for Applications Development Object-oriented systems are of considerable importance for the next generation of applications. They are often called middleware, because they provide building blocks that bridge between the networking and applications layers. CORBA The Common Object Request Broker Architecture, or CORBA, defines a set of mechanisms based on interface specifications (defined in a standardized Interface Definition Language, or IDL) and Applications Programming Interfaces (APIs) that allow location transparency among communicating applications components. An Object Request Broker, or ORB, provides the linkage between clients and servers, by supporting client invocation of server objects across the network. An ORB intercepts the call, finds a suitable object that can service the request based on discovering matching APIs through a process called introspection, passes
6.4. Major Systems Projects InfoPad InfoPad was an ambitious research project at Berkeley whose goal was to develop the hardware, software, and mobile network support for ubiquitous, wireless access of real-time multimedia data from high speed networks using
17
the found server object the necessary parameters, invokes the appropriate method, and finally returns the results to the client. This is accomplished in a manner that is transparent to object location, implementation language, or operating system on the client or server machines. Client and server objects communicate across a network using CORBA’s Internet InterORB Protocol, or IIOP.
that environment. It provides standard protocols to allow service providers to register their capabilities and service clients to find and use these capabilities. Devices announce the services they can provide, as well as their attributes and capabilities, allowing the services they invoke to be customized for their needs. In JINI’s terminology, a service is any entity that can be used by another person, program, or service. Services include computation, storage, communications, filtering, hardware devices, or even another user. A service protocol is a set of Java APIs. A JINI Federation is a dynamic composition of services to accomplish a specific task.
Java and JavaBeans Java is a strongly typed, C++ like object-oriented programming language that is network-aware, interpretive (with justin-time compilation and dynamic run-time checking), highly portable, and multithreaded. Its strong typing and interpretive architecture significantly reduce commonly encountered bugs, thereby enhancing the safety of program execution while also enabling applications that are “write once, run anywhere.” Because it was designed to make it easier to develop applications on networks, Java is particularly wellsuited as a programming language for developing services in the kind of heterogeneous environment of converged networks. Java is used in ICEBERG and Ninja.
JINI’s run-time environment depends on two critical operations. The first is Discovery/Join, which provides the mechanisms for a device to register with the network for the first time, without knowing anything about the network. The device uses broadcast mechanisms to announce its presence. The second is the Lookup Service. This is a bulletin board for network services. The service provider can deposit its executable invocation specification into the Lookup Service. A client can then obtain this invocation code (in essence, a dynamically downloaded driver) from the Lookup Service, thereby enabling service invocation through a JAVA Remote Method Invocation (RMI) call. Services can also be implemented through combinations of local and remote processing. Such implementations are called smart proxies.
JavaBeans is a platform-independent, portable component model for use with Java. Its design goals are very similar to CORBA: software developers provide components that can be composed by end users to form applications. Beans are software components with specified interfaces (discoverable through introspection), are customizable for the usage at hand, support an event model based on source/listeners that supports bean interconnection, expose properties such as methods and events, and provide mechanisms for persistence so they can be easily halted and restarted. Beans span the range from simple applications building blocks (e.g., special functionality buttons, graphical user interface components, or other small to medium sized control functionality) to full blown applications (e.g., a word processor or spreadsheet application) that can be composed to form compound documents. JavaBeans bridges to other component models.
Other elements of JINI run-time environment include Leasing (timeouts on registrations), Distributed Transactions (undo/redo mechanisms), and Distributed Events (reliable delivery of events layered onto the event model).
6.6. Telecommunications-oriented Intelligent Network A desire to more rapidly deploy new services in the telecommunications network has driven the development of the Advanced Intelligent Network (AIN). This is achieved by creating a standardized service creation environment independent of the underlying vendor-specific switch platforms. A critical enabling technology for AIN is Signaling System 7 (SS7), an internationally standardized channel signaling system for controlling switches and databases throughout the phone network. Service Switching Points (SSPs) intercept certain patterns of call processing steps to invoke service logic in Service Control Points6 (SCP). The service logic then influences the subsequent call processing steps. It is through such mechanisms that 800 number and call forwarding services are deployed in the PSTN. AIN is intimately coupled to the hierarchical switching structure of the phone network and the logical sequencing of call processing.
Beans run in containers, which may be Java or non-Java applications. A Java RMI (Remote Method Invocation) has been defined for communications with Java-based servers. There is also a Java IDL to allow Java clients to communicate with CORBA-based servers. CORBA and Java are orthogonal in concept. While CORBA addresses network location transparency, Java solves the problem of implementation transparency to allow components to run anywhere in the network. JavaBeans is being designed so as to allow interoperation with CORBA objects. JINI JINI is a recent development in distributed computing architectures. Based on Java, JINI’s goal is to support “spontaneous networking,” allowing new devices to discover their network environment and configure themselves to operate in
6. An SCP is essentially the hardware/software support for a database. SCPs use the database to support such operations as phone number remapping for 800 services and call forwarding.
18
TINA, Telecommunications Information Networking Architecture, is a recent research effort to open up the telecommunications service architecture to allow end users to access and customize their own services. Building on CORBA technology, TINA is developing the cooperating object components needed to implement telecommunications services using such advanced techniques as object orientation, distributed processing environments, intelligent agents, and multi-service networks.
This proxy agent approach is particularly crucial, because it is through ubiquitous support for transcoding and translation that we can provide sophisticated services for a broad diversity of access devices. These will go well beyond handsets or computers, to include combinations of both as well as new controllable “smart space” environments. Our approach, a telecommunications service architecture called ICEBERG, is based on the Ninja execution platform. Ninja provides infrastructure, in the form of Units, Active Proxies, and Bases, and Services, in the form of operators, typed connectors, and paths, to provide powerful and dynamic software functionality in the network core. We have ICEBERG and Ninja to implement innovative applications like Interactive Voice Recognition to control computer-based devices in a smart room. We are extending these ideas to the next level of device and network independence and transparency by implementing a Universal In-Box service on top of ICEBERG/Ninja. ICEBERG contains several novel ideas:
6.7. Comparisons with ICEBERG/Ninja ICEBERG and Ninja, though developed independently, contain many of the same concepts described in the systems above. If TINA is a telephony-oriented service architecture built on top of CORBA’s object-oriented model and distributed execution environment, then ICEBERG is to TINA as Ninja is to CORBA. Ninja provides service discovery services like JINI and an object composition framework like JavaBeans and CORBA. Ninja supports service migration through its foundation on the Java programming model. It also supports wide-area object execution similar to CORBA. A key difference is Ninja’s concept of an operator path, its focus on automated path compilation, and its approach to optimization based on careful placement of services within the network. With respect to the latter, Ninja has full knowledge of how to exploit networks of workstation as a processing base for services, providing a critical element of the solution to scalability in the service architecture. ICEBERG focuses on services to provide network, device, communications-type, and user interface transparency and independence. In addition to Ninja’s support for cluster processing and visibility into the underlying network topology, another advantage is that ICEBERG can exploit Ninja’s ability to compose object dynamically. Such dynamic composition is not supported in CORBA to our knowledge. The InfoSpheres project at CalTech is researching the composition of distributed active mobile objects that communicate using messages [Caltech98]. This has some similarities with our own approach.
Services Across Cascaded Networks ICEBERG supports cascaded networks, where there are multiple paths between networks, and multiple places for services to execute. Core services and resources are exposed to end users. ICEBERG provides secure, authenticated mechanisms for allowing service- and entity-specific policies to be injected into the network infrastructure. Injecting code into the network requires secure execution and authentication of policies and entities. It requires careful structuring of resource interfaces. ICEBERG gives entities control over the paths of their data as well as resource usage. It supports network-specific resource management, authentication, policies, and billing, to allow policies to be enforced. Not Just Bit Transformations, but Service Transformation ICEBERG addresses service transformations involving decision making about bit-level transformations and where to perform them, high-level transformations to address deficiencies, and routing data across multiple networks. Entities in the system provide contextual information about themselves: who they are, what services they are using, where they are, and the capabilities/limitations of end devices and networks. This affects bit-level transformation choice and placement.
7. Summary and Conclusions We claim that future telecommunications networks will be founded on a common network core: optimized for data, based on IP, enabling packetized voice, and supporting user, terminal, and most importantly, service mobility. Voice over IP technology is already developing rapidly. The major research challenge will be to develop an open and composable telecommunications services architecture. In many ways, this represents the wide-area “operating system” of the 21st Century. The existing PSTN architecture, even with the Advanced Intelligent Network architecture, is not the best structure for realizing this vision. A better approach is one founded on client-proxy-server architectures so successfully deployed in the Internet.
Users may have specific requirements (e.g., cost, delivery latency, or QoS) for cross-network information. The network gateways and end devices may only support limited bit-level transformations. End-devices, services, and network gateways may need to negotiate a transformation to use. This process may transverse cascaded networks. Routing must be considered as a cascaded network function. The locally optimal choice of routing may not be globally optimal. Consider a call being placed between a VoIP user on
19
a computer in San Francisco and GSM user London. Routing the call over IP might be optimal locally, but could introduce excessive jitter and delay in the wide-area.
Thesis, CS-Dept. 4, Aachen University of Technology, Germany, April 1997. [Brewer98] Brewer, E., et al., “A Network Architecture for Heterogeneous Mobile Computing,” IEEE Personal Communications Magazine, V 5, N 5, (October 1998), pp. 8-24.
ICEBERG is not reinventing bit-level transformations or routing protocols. The architecture leverages existing services and management functionality in each network. Our concern is with the level of operation and scope of decisionmaking.
[Caltech98] Caltech Infospheres Project, California Institute of Technology, Pasadena, CA, 1998. http://www.infospheres.caltech.edu/.
Many of networks are multi-modal, carrying different forms of information. This can be used to determine where transformations should be located. Reaching a global optimum in cascaded networks requires cooperation and communication between routing entities across the underlying networks.
[Cohen97] Cohen, P. R., M. Johnston, D. McGee, S. Oviatt, J. Pittman, I. Smith, L. Chen, J. Chow, “Quickset: Multimodal Interaction for Distributed Applications,” Proc. of ACM Multimedia 97, Seattle, WA, (November 1997), pp. 3140.
Networks contain many of the resource needed by services, but not in a generic form. For example, all networks have some form of naming and authentication. ICEBERG unifies mechanisms across the networks by providing abstract naming and authentication that resolves to and relies upon network-specific mechanisms at the lowest level.
[Culler92] von Eicken, T., D. Culler, D., S. Goldstein, K. Schauser, “Active Messages: A Mechanism for Integrated Communication and Computation,” Proc. 19th Annual Symposium on Computer Architecture, Gold Coast, Australia, (May 1992), pp. 256-266. [DeSimone93] DeSimone A., Chuah M. C., Yue O.-C., “Throughput Performance of Transport-Layer Protocols over Wireless LANs,” Proceedings of the IEEE Globecom 93, 1993.
Propagation of Service- and Entity-Specific Metadata Across Cascaded Networks Service handoff propagates service- and entity-specific metadata across cascaded networks. This propagates to the computational resources in each network carrying the data associated with the particular service. ICEBERG provides these propagation paths by providing logically or physically separate bi-directional metadata and data paths.
[Festival98] Centre for Speech Technology Research, “The Festival Speech Synthesis System,” University of Edinburgh, Edinburgh, Scotland, 1998. http://www.cstr.ed.ac.uk/ projects/festival/festival.html. [Floyd95] Floyd, S., V. Jacobson, “Link-sharing and Resource Management Models for Packet Networks,” IEEE/ACM Transactions on Networking, Vol. 3 No. 4, (August 1995), pp. 365-386.
ICEBERG provides infrastructure for specifying metadata as XML descriptions. These are used for the creation or modification of a path (e.g., during service handoff) among requestors and services to select, place, and route transcoders.
[Fox98] Fox, A., S. Gribble, Y. Chawathe, E. Brewer, “Adapting to Network and Client Variation Using Infrastructural Proxies: Lessons and Perspectives,” IEEE Personal Communications Magazine, V 5, N 4, (August 1998), pp. 10-19.
Acknowledgments We wish to acknowledge our colleagues on the Ninja Project, Eric Brewer and David Culler. We especially thank Professor B. R. “Badri” Badrinath, who played a major intellectual role in developing the ICEBERG service architecture while on sabbatical at Berkeley during 1997-1998.
[Goodman97] Goodman, D., Wireless Personal Communication Systems, Addison-Wesley Longman, Berkeley, CA, 1997. [Heilmeier98] Heilmeier, G., “POTS to PANS: Telecommunications in Transition,” Keynote Address, UC Berkeley EECS Industrial Liason Conference, Berkeley, CA, (February 1998).
The ICEBERG/Ninja testbed has been enabled by the support of Ericsson, IBM, Intel, Motorola, Nortel Networks, and the financial support of the Defense Advanced Research Projects Agency and the California MICRO Program.
[Hodes97] T. D. Hodes, R. H. Katz, E. Servan-Schreiber, L. A. Rowe, “Composable Ad hoc Mobile Services for Universal Interaction,” Proceedings of The Third ACM/IEEE International Conference on Mobile Computing. Budapest, Hungary, (Sept. 1997).
8. References
[Hodes98] Hodes, T., R. Katz, “Enabling Smart Spaces: Entity Description and User Interface Generation for a Heterogeneous Component-Based Distribution System,” UCB Technical Report CSD-98-1008, Computer Science Division, University of California, Berkeley, Berkeley, CA, (July 1998). DARPA/NIST Smart Spaces Workshop, Gaithersburg, MD.
[Balakrishnan95] Balakrishnan H., Seshan S., Katz R. H., “Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks,” Wireless Networks, Vol. 1, No. 1, (February 1995), pp. 469-481. [Baucke97] Baucke S., Leistungsbewertung und Optimierung von TCP für den Einsatz im Mobilfunknetz GSM, Diploma
20
[Hodes99] T. Hodes, M. Newman, S. McCanne, R. H. Katz, J. Landay, “Shared Remote Control of a Videoconferencing Application: Motivation, Design, and Implementation,” Proceedings of SPIE Multimedia Computing and Networking 1999, San Jose, CA, (Jan. 1999). [ICSI98] International Computer Science Institute, “Speech Research in the Realization Group at ICSI,” Berkeley, CA, 1998. http://www.icsi.berkeley.edu/real/speech.html. [ITU98] International Telecommunications Union, Recommendation H.323, Packet Based Multimedia Communications Systems, (February 1998). [Kojo97] Kojo M., et. al., “An Efficient Transport Service for Slow Wireless Telephone Links,” IEEE JSAC, Vol. 15, No. 7, (September 1997), pp. 1337-1348. [Kuruppillai97] Kuruppillai, R., M. Dontamsetti, F. Cosentino, Wireless PCS, McGraw Hill, San Francisco, CA, 1997. [Narayanaswamy96] Narayanaswamy, S., et al., “Application and Network Support for InfoPad,” IEEE Personal Communications Magazine, V 3, N 2, (April 1996), pp. 4-17. [Nelson84] Nelson, B., A. Birrell, “Implementing Remote Procedure Calls,” ACM Transactions on Computer Systems, 2(1), February 1984. [Nelson98] Nelson, B., “IP Dialtone, Telco Evolution, and the Internet Economy,” Keynote Address at IEEE Globecomm Conference, Sydney, Australia, (November 1998). [Schulzrinne95] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” Internet Engineering Task Force, Audio-Video Transport Working Group, (March 1995). [Stemm98] Stemm, M., R. Katz, “Vertical Handoffs in Wireless Overlay Networks,” ACM/Balzer Mobile Networking and Applications (MONET), Special Issue on “Mobile Networking in the Internet,” (December 1998). [Wang99] Wang, H., R. Katz, “Policy-Driven Handoffs Across Heterogeneous Wireless Networks,” 2nd IEEE Workshop on Mobile Computing and Applications (WMCSA’99), New Orleans, LA, (Feb. 1999). [Want95] Want, R., B. Schilit, N. Adams, R. Gold, K. Petersen, D. Goldberg, J. Ellis, M. Weiser, “An Overview of the ParcTab Ubiquitous Computing Experiment,” IEEE Personal Communications Magazine, V. 2, N. 6, (December 1995), pp. 28-43. [Wong98] T. Wong, T. Henderson, S. Raman, A. Costello, and Randy Katz, “Policy-Based Tunable Reliable Multicast for Periodic Information Dissemination”, WOSBIS'98, Dallas, TX, (October 1998). [Zhang93] Zhang, L., S. Deering, D. Estrin, S. Shenker, D. Zappala, “RSVP: A New Resource ReSerVation Protocol,” IEEE Network Magazine, (September 1993), pp 8-18.
21
