WO1998053578A1 - Method and system for providing multimedia service in an atm communications network - Google Patents

Abstract

A multimedia interface (G) for interfacing between a broadband network (R) and a service-and-applications network (B) is provided. The model (G) includes an organized collection of interfaces (121-125) designated as binding interface base (BIB). The interfaces include resource control (124) for routing, admission control and the like; the management services (125); connection management (122); and the information transport (121). The Kernel forms a distributed operating system for managing and controlling multimedia networking resources to provide services with quality of services (QOS) guarantees.

Description

METHOD AND SYSTEM FOR PROVIDING MULTIMEDIA SERVICE IN AN ATM COMMUNICATIONS NETWORK

Technical Field

This invention relates to asynchronous transfer mode (ATM) network service and, more particularly, to the creation, deployment and management of multimedia service in an ATM network.

Background of the Invention

Most communications networks operate either in a connection-oriented mode in which communication is maintained through pre-established channels having long lifetimes, or in a connectionless mode where data packets are routed hop-by-hop through the network. In both types of networks, service to customer premise equipment (CPE) has been provided by a small number of computationally powerful processors in the network, called service controllers (SC) or service control points (SCP) .

Connectionless mode includes ATM which has been adopted as a standard for packet-based communications.

Summary of the Invention

We have recognized that distributed computational capability, e.g. of customer premise equipment (CPE) can be used to advantage in service provisioning in an ATM network. An open and programmable software platform or kernel is included in the network for building, deploying and managing multimedia services. The kernel is open in that it supports functional application programming interfaces for developing useful services, and it is programmable in that these APIs allow service specification and creation in a high-level programming language . The kernel forms a distributed operating system for managing and controlling multimedia networking resources to provide services with quality of service (QOS) guarantees. The system includes an organized collection of interfaces designated as binding interface base (BIB) , and an overlying set of processing capabilities.

Brief Description of the Drawing

Fig. 1 is schematic depiction of a broadband kernel in accordance with a preferred embodiment of the invention. Fig. 2 is a diagram of interface hierarchy of the binding interface base (BIB) of the broadband kernel . Fig. 3 is a schematic depiction of the four types of primary interfaces provided by broadband kernel services . Fig. 4 is a schematic depiction of interaction between broadband kernel services in setting up a high- level teleconferencing service.

Detailed Description of Preferred Embodiments

The broadband kernel operates on two primary principles, namely separation between control and transport, and information abstraction. In the former, the broadband kernel uses the Internet protocol (IP) as the primary messaging system for control messages, while retaining support of native ATM protocols for high performance. In the latter, the broadband kernel relies on the use of the CORBA (Common Object Request Broker Architecture) distributed object-oriented standard for support in defining and implementing open distributed object interfaces. The broadband kernel architecture recognizes two layers of abstractions in a multimedia network. The first layer hides away details of the network hardware via a set of interfaces called QOS abstractions . These interfaces allow resource capacity in the network to be precisely characterized and managed in real-time. Various resource allocation and control algorithms operate on these abstractions to realize a set of low- level services called broadband kernel services that provide the fundamental communication facility of the network.

The second layer of abstractions exists above the broadband kernel services to hide away the complexity of these algorithms. These abstractions provide a clean interface for building higher-level network services, e.g. virtual chains, virtual paths and virtual networks that are typically used by a service provider. Collectively, these interfaces form the service interface base (SIB) .

All interfaces in the architecture are specified in CORBA interface definition language (IDL) which is an open-platform neutral format. The architecture is open, defining interfaces that allow open third party access to key functionality at two levels in the network. In the first level, third party software developers can extend the broadband kernel services in the architecture by building additional algorithms on top of the BIB. At the second level, the SIB provides third party software developers a set of platform-independent APIs for building user-level services.

Major components of the broadband kernel include (A) the BIB, (B) the broadband kernel service modules, and (C) the network service modules.

A. Binding Interface Base (BIB)

This is a collection of IDL interfaces that model multimedia logical or physical networking resources in a network. Shared resources have a finite capacity which may be allocated out for use. The interfaces in the BIP can be divided into two main categories, namely: a. interfaces of resources which represent hardware that processes, generates or switches multimedia streams, including interfaces to virtual devices, central processor units (CPU) , transport protocols (TP) , switches and links,- and b. interfaces to software entities or modules that represent the processing, transporting and name space capacities of the hardware of category (a) , including interfaces to virtual name space and virtual capacity region.

Virtual Device Interface models producers and consumers of multimedia streams. The interface specifies generic operations on streams including methods for adding, deleting, pausing, resuming and changing the attribute streams . The Virtual Device Interface is typically used to model multimedia devices that generate or process multimedia streams including cameras, speakers, microphones and displays. Two subclasses of the Virtual Device interface exist, representing source and sink devices. A third interface derives from both classes and is used to specify devices that act as both source and sink, e.g. , software filters.

Virtual CPU Interface models the scheduler and a multitasking CPU for processing media streams. The interface allows scheduling policies and parameters to be set so that quality of service (QOS) constraints of the media are met .

Virtual TP Interface models control interface to a transport stack. The interface allows control over transport parameters such as window size, rate, delay and protocol parameters to be monitored and set externally. Virtual Switch interface models an abstract ATM switch. Methods allow setup, tear-down, and renegotiation of virtual circuits and virtual paths for point-to-point or multicast connections. Additional functionality includes methods for simple switch and port management and adjacency protocol operation.

Virtual Link Interface models the multiplexing functionality of a switch port. Methods in the interface allow tuning of scheduling policies as well as scheduler specific parameters for guaranteeing cell-level QOS in the network.

Virtual Name Space Interface models the capacity of a finite naming resource like virtual channel and virtual path identifiers (VCI/VPI) . These resources are usually associated with the VCI/VPI translation table of an ATM switch.

Virtual Capacity Region Interface models the processing or transport capacity of a resource.

Specifically, when associated with a Virtual Link, the interface models the switching capacity of the link. Or, when associated with a virtual CPU, the interface models the processing capacity of the media processor. Methods in the interface allow the size of the capacity as well as its dimensions to be changed.

B. Broadband Kernel Services

These are defined as basic enabling services that allow the construction of higher-level network services. Included are: connection management service for connection setup, resource control and renegotiation; transport control (TC) or management service for real-time QOS monitoring and control of transport streams; route management service for determining the best physical route between source and destination endpoints during the connection setup process;

QOS mapping service for translating between user- or application-level QOS parameters and network level QOS; device management service for managing the capabilities and verifying the compatibility of media formats supported by communicating multimedia devices.

Connection Management Service. The connection manager is responsible for the setup, tear-down and renegotiation of resources for a connection request. The scope of the connection manager is end-to-end, in the sense that it communicates with the host machines on both ends of a connection during setup. The successful completion of a connection setup returns a transport connection data structure that contains a file descriptor that can be used by the transport. A connection manager can reside on any host computer.

In this design, both "stateful" and "stateless" variants of the connection manager are possible. Addition, removal or renegotiation of a connection by different connection managers are possible also. Transport Controller (TO . The TC implements

QOS monitoring on the slow-time scale. There is one TC per end system. At regular intervals, it polls every connection it is responsible of monitoring and gathers network management statistics . Upon a continuous QOS violation, it notifies the appropriate service manager of the event . The service manager can then decide to initiate QOS renegotiation or to ignore the notification based on the control rules it has . TC also monitors each connection to see whether it is active or not. If it has been inactive for more than a pre-specified interval, it stores it, assuming that the application has "crashed". Route Management Service . The route manager implements minimum-weight routing with delay constraints . The route manager keeps a data structure that contains the network topology and, for each link, its weight and delay. Various weight parameters have been experimented with on a prototype implementation, such as hop count, bandwidth, and utilization. If there is no route between two hosts where the sum of link delays is less than the delay constraint, the two hosts are considered unreachable from each other, even though link bandwidth may be available. The route manager implemented is passive in the sense that it only recomputes a new set of routes on request. There can be multiple instances of route managers running simultaneously.

QOS Mapping Service . The QOS mapper maps the application level QOS into network level QOS. In terms of COMET classes, all the video services are mapped into class 1, audio into class 11 and reliable data into class 111. In the context of user-to-application and application-to-transport QOS mapping, the QOS parameters specified by the user (quality, type of audio, size and compression algorithm for the video) are mapped to the transport QOS parameters (delay, loss, etc.), measured per frame. The network QOS parameters are the same as those for transport, but they are measured on a per cell basis .

Device Manager. The device manager tracks the capabilities of all multimedia devices on a particular host. Each of these devices in turn may support a number of media formats, rates or options. When a device initializes during the boot-up process, it registers with the device manager and passes to it a sequence of data structures describing all the formats, rates and options it supports. Thus, at any time, the device manager is aware of all the details of each device available on its host . When a device terminates due to an error or is "killed", it also attempts to unregister itself from the device manager. The device manager of its own accord polls the devices on a regular basis to ascertain their continued availability.

C. Network Services

Network services are higher-level services built on top of the interface of broadband kernel services. Here, network services specifically include switched virtual circuits, virtual paths, and multicast.

Switched Virtual Circuit service provides the facility of setting up point-to-point virtual circuits with on-demand bandwidth renegotiation, management, and transport binding, monitoring and control capabilities.

Virtual Path service allows the reservation and setup of whole virtual paths with programmable rerouting and virtual circuit allocation parameters.

Multicast service extends the switched virtual circuit service to deal with point-to-multipoint connections and multicast group management.

The above-described modules or services interact during the service creation process . For example, for teleconference service, binding algorithms used for connection set up, distributed systems implementing synchronization protocols, resource allocation protocols such as routing, etc., interact cooperatively for realizing the service. The structure of this interaction depends on the higher-level service to be constructed. However, sufficient similarities exist between high level services, especially network services so that a generalized model of service creation can be applied.

The service generation process is executed by a service provisioning entity. Multiple such entities execute in parallel and in a distributed fashion. The service creation process includes five steps:

1. Creation of a service skeleton for an application (e.g., virtual circuit, virtual path, virtual network or multicast) . For example, the skeleton for a virtual circuit consists of a graph from a source node to a destination node. 2. Mapping of the skeleton into the appropriate name and resource space, thereby creating a network application.

3. Association (or binding) to the application of a media transport protocol, thereby creating a transport application.

4. Binding of the transport application to resources, creating a network service.

5. Binding of the service management system to the network service, thereby creating a managed service. The skeleton is created using name and resource mapping services. The resulting network application is bound to a transport protocol , resources and service management. When a service is required, the application process issues a ^"service request to the responsible service provisioning entity that in response will invoke the corresponding broadband kernel services to create the service .

Services are created within the context of servers which are specialized software processes or modules that provide the necessary support (memory and processing power) for a service to be created. Within a server, a service can be viewed as being composed of an algorithmic component and a data component . The algorithmic component expresses the execution logic of the service instance, and the data portion is an abstraction of its state. In order for services to interact with each other, several types of service interfaces are also defined. These interfaces reflect the roles that a service might play in the process of its execution. Typically these include creation, operation, management and programming.

The service creation interface is like a constructor of a class. It is the primary entry point of execution or instantiation of a service and is called by the server once the service template has been completely downloaded. The service operation interface defines the operational functionality of the service and is usually the primary interface through which services interact. The programming interface allows manipulation of the service logic to be performed while a service is in execution. The service management interface allows for monitoring of service states and manipulation of service parameters .

Fig. 1 depicts the conceptual model of the broadband kernel. The broadband network is defined as the physical network 11 (also known as the R model) that consists of switching and communication equipment and multimedia end-devices. Superimposed on this physical infrastructure, the multimedia network 12 is also known as the G model and primarily serves to provide the middleware support for the higher services, in the services and applications network, to realize end-to-end QOS guarantees. The multimedia network 12 achieves this by first extracting, from the broadband network 11, QOS abstractions that define the resource management and control space of elements in the physical network. Then, the multimedia network 12 realizes a fundamental set of system-wide services through the execution and operation of various resource control and management algorithms on these QOS abstractions. These services are the broadband kernel services and include many of the rudimentary communication services like connection management, resource reservation and the like. The services and applications network 13 is also known as the B model and realizes user-level services by building upon service abstractions of the broadband kernel services.

This RGB decomposition represents detailed viewpoints of the broadband network, the multimedia network and the services and applications network, respectively. The interface between R- , and G-models is a set of QOS abstractions typically structured as graphs that quantitatively represent various resources in the physical network. The G-model uses these graphs for creating service abstractions that are provided to the B- model for building more complex services. Thus, the interface between the R- and G-models and the interface between the G- and B-models provide abstractions which are similar in structure, but differ in usage.

The role of the G-model is to create services, including network services such as virtual networks, as well as the low-level support functions for realizing such a service. High level network services are realized within the resource management and control space of the R-model . Fig. 1 illustrates some examples of services provided by the G-model. These services are realized as objects, i.e. algorithms and data structures, and represent the "broadband kernel service" of multimedia networks . They can be used as building blocks by an application in the B-model to create multimedia services.

As illustrated in Fig. 1, the G-model is divided into five conceptual planes 121-125. The states of the broadband kernel are stored in plane 123, the D- plane. The algorithms acting upon them reside in planes 125, 124, 122 and 121, the N- , M- , C- and U-planes, respectively.

While resource control (M-plane) services such as routing, admission control and the like, and management (N-plane) services are important for the deployment of broadband networks, the following is more specifically concerned with the realization of the C- plane, i.e. with connection management, and the U-plane, i.e. with information transport.

The connection manager is the coordinator that enables the creation of connection services. The following functionalities are required by any connection manager to perform its task: route selection, resource reservation, states saving, and renegotiation. Multiple connection schemes may run simultaneously in the network. The route selection approach used depends on the routing strategy. Routing is a control algorithm running on the M-plane . The path of a connection is provided by route objects in the BIB, whose routes are updated by the router objects. There are two extreme route selection approaches: source routing and hop-by- hop routing. In source routing, the route object completely specifies a route at once. In hop-by-hop routing, the route object provides sufficient information to progress to the next hop only. In-between these two approaches, any combination is possible. Domain routing falls under this hybrid category, where a number of routers are needed to completely specify a route .

Resource reservation performed by a connection manager can be divided into two groups : reserving system resources such as buffer, bandwidth, CPU cycles and the like, and reserving and setting of identifiers in the network fabric for cell transport. The reservation of system resources should be based on abstractions that are independent of the details of the system hardware and that provide QOS guarantees. For manipulation of switching identifiers, the primitive should be as close as possible to the hardware abstractions so that maximum flexibility is maintained. For reserving and setting resources, the state of the hardware can be made accessible, to allow its modification through a set of generic ATM switch interfaces. The requests received by the connection manager can be specified in terms of application level terminology. In order to reserve or change resource usage, the connection manager specifies these requirements in the appropriate terminology. For example, QOS abstractions for the network resources can be defined in terms of calls of a predefined class of service, where each of such classes is defined with specific cell loss, cell delay and the like. The multimedia network service abstractions are specified in terms of frame rate, frame loss and the like. Here, a QOS mapper translates QOS specifications between the various abstractions.

In the interest of system robustness, once a connection has been set up its state is kept, e.g. the bandwidth reserved and the route. Then, e.g. if the connection manager "crashes", the manager can be restarted, and requested to find out all the routes it had established. Each switch keeps sufficient information so that a connection manager can discover the entire route of a connection by tracing forward and/or backward starting from any hop in the connection. As this causes heavy interactions among objects during setup, renegotiation and deletion, in order to improve the signalling performance, connection managers can cache the connections state information. In this case, connection managers must assume that the cached information can become invalid. This might arise, for example, if a connection is released by another connection manager.

Renegotiating means asking for more or less system resources for a connection than the one currently committed. Renegotiation may be performed either when the application using the connection explicitly requests it or when it is triggered by the QOS monitoring system due to sustained QOS violations . Renegotiation can be performed also during the connection setup phase. In order to efficiently perform renegotiations, resource interfaces must allow immediate changes in resource reservation, i.e., without releasing the resource first. The information transport, or U-plane, focuses on QOS-aware transport protocols. These contain mechanism for the processing of media streams, i.e., in flow and on a fast-time scale. For guaranteeing end-to- end QOS, QOS-based transport APIs (for provisioning, QOS control and media transfer) are used.

The U-plane offers media stream services such as motion JPEG, MPEG video and CD quality audio for realtime multimedia applications. For non-real time applications, services such as reliable (i.e. error free) and best effort are offered. At the G-B interface, the QOS is specified in the application level terminology and per session. The QOS parameters are expressed in terms of frames or packets, i.e., for real-time services, the frame loss rate, frame gap loss, frame delay, frame peak rate and the maximum frame size, and for non real-time services, the average throughput, average packet delay, maximum packet rate and maximum packet size . Only losses and delays represent QOS parameters . These are monitored by the receivers. The other parameters are traffic descriptors used for regulating the media flows at the senders .

To support applications with QOS requirements, QOS-aware transport protocols are used. In particular, the transport protocols provide mechanisms to support flow and rate control for real-time and non-real-time media streams, as well as mechanisms to handle error control. The transport protocols should also have the capability to perform in-flow QOS monitoring such as measuring, frame delay, frame rate, frame loss and the like. When fast-time-scale QOS violations are detected, the protocol should have the capability to adapt, e.g., by changing the size of the transport protocol data unit or by reducing its peak rate. Furthermore, the transport protocol should have the capability to the notify network management system or the application if the network does not provided the guaranteed QOS or if a connection is lost.

A QOS-based transport API is used for provisioning, control and media transfer. Provisioning takes into account multicast as well as unicast connections. Control APIs are for renegotiation and monitoring. These should permit the network monitoring service to retrieve the in-flow QOS measurements and allow kernel services to set new parameters for flow control, monitoring or violation detection. Preferably, the media transfer APIs provide the transport protocol with the type of information it carries .

QOS monitoring is used for ensuring that the QOS associated with a service is as guaranteed at admission time, for collecting data for management, and for detecting QOS violations and initiating renegotiations. Monitoring is performed on a fast-time scale or in flow, for flow control mechanisms to adapt to rapid network fluctuations, and on a slow-time scale for renegotiations and management purposes. In-flow monitoring is performed in the transport protocol, since it is tightly coupled with the media stream. This is a U-plane functionality. Slow-time scale monitoring, which is an M-plane service, can be performed by polling the transport protocol of each active connection for their current measurements or by waiting for transport protocols to forward their measurements. The monitored data is stored and/or processed, and is accessible for management. If QOS violations are detected, e.g., if sustained violations occur, the monitoring service should have the ability to trigger renegotiation.

To satisfy the above requirements in a prototype system, several components were designed and implemented: qStack, a transport protocol for real-time communications that performs in- flow QOS monitoring on a fast-time scale,- TP, a transport class with a QOS-based API that supports multiple transport protocol suites; and TC, a transport controller responsible for the slow- time scale operations such as long-term QOS monitoring, QOS violation detection and QOS renegotiation.

The U- and C-plane modules and kernel services lie at the heart of an extended machine, namely a broadband operating system, that extends in the network rather than residing on a single host. In the process of service creation, multiple such services are composed for creating higher level services .

Fig. 2 depicts the interface hierarchy of the BIB. At the root of the interface tree is the base class interface, Bindinglnterface, which derives directly from CORBA::Object . The Bindinglnterface class defines generic methods for event registration and notification, and ownership specification and verification that all classes derive from. Fig. 3 depicts the 4 types of primary interfaces that services must provide. These include the service creation interface, the service operation interface, the service programming interface and the service management interface. As an example, Fig. 4 depicts the interaction between broadband kernel services in setting up a high- level teleconferencing service. Upon receiving a session setup request from a user, the teleconferencing service object (TM) creates an instance of the service skeleton. It then queries the device manager (DM) of each host involved in the conference to see if any devices capable of supporting the requested type of media stream exist. If successful, a connection setup request is made to the connection manager (CM) who in turn queries the QOS mapping service (QOSM) for a translation between the transport level QOS specified by the BIB components and the network level QOS understood by the Virtual Switch and Virtual Link interfaces. The CM gets its route from the Route object that contains the latest set of routes computed by the route manager (RM) . Once a route has been obtained, the CM proceeds to each host (Virtual Switches/Virtual Links) along the route and reserves the required resources . The connection setup process ends with the CM returning back to the TM a pair of VPI/VCIs representing the entry and address points to the connection that it has established. At this point, the TM proceeds to inform the two transport interfaces (TPs) at both endpoints to open the associated network interface device using the VPI/VCI pair and transport protocol of choice, and gets in return a unique connection identifier that it then passes to the Virtual Devices (VDs) . The connection identifier serves to abstract away any details about the transport protocol (such as the actual VPI/VCI pair or transport stack in use) from devices so that different simultaneous transport protocol stacks can be used by the same device without any chance required. Once this is completed, a session has been established and a multimedia stream generated at the source device can be carried over the network to the destination device. During the lifetime of the connection, the transport controller (TC) monitors the QOS obtained in the end system for any violation of QOS. In the situation where sustained QOS violations occur, the TC may initiate a renegotiation request to the TM who would in turn request the TP of the transmitting device to reduce its rate. The TP in turn can interact with the device to effect the rate control.

Alternatively, if a feedback channel to the transmitting device is available, as may be required by some protocols, the TP of the receiving device can directly notify the TP of the transmitting device of the violations. Still another alternative is when the user requests for a change in the grade of service. In this case, the TM issues a renegotiation request to the CM who then attempts to renegotiate for new resources via the RM and QOSM on the respective hosts. The other interfaces (management and programmability) of the TM exist so that other B::N-plane applications can monitor and control service creation policies of the TM.

Claims

CLAIMS :

l. A multimedia interface for interfacing between a broadband network and a service-and-applications network, comprising: a binding interface base for interfacing to communications resources and processing modules; a broadband kernel for providing higher-level network services,- and a network service module for providing communications paths .

2. The interface according to claim 1, wherein the binding interface base comprises interfaces of resources which represent hardware for multimedia communications streams .

3. The interface according to claim 2, wherein the binding interface base comprises an interface to a software module that represents processing capacity of the hardware.

4. The interface according to claim 2, wherein the binding interface base comprises an interface to a software module that represents transport capacity of the hardware .

5. The interface according to claim 2, wherein the binding interface base comprises an interface to a software module that represents name space capacity of the hardware .

6. The interface according to claim l, wherein the broadband kernel comprises a connection management module.

7. The interface according to claim 1, wherein the broadband kernel comprises a transport control module.

8. The interface according to claim 1, wherein the broadband kernel comprises a route manager.

9. The interface according to claim 1, wherein the broadband kernel comprises a QOS mapper.

10. The interface according to claim 1, wherein the broadband kernel comprises a device manager.

11. The interface according to claim 1, wherein the network service module comprises a switched virtual circuit service module.

12. The interface according to claim 1, wherein the network service module comprises a virtual path service module .

13. The interface according to claim 1, wherein the network service module comprises a multicast service module.

14. In ATM communications, a method for providing multimedia service through a multimedia interface between a broadband network and a service-and-applications network, the method comprising interfacing to communications resources and processing modules using a binding interface base; providing higher-level network services using a broadband kernel ,- and providing communications paths using a network service module.