Resource management system for wide band multi-point bridge

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to a system for efficiently arranging broadband bridge resources. In particular, the system allows the client application to negotiate (negotiate) with the bridge resource manager regarding service quality arrangements.

【0002】

[Conventional technology]

As the development of high-speed networks accelerates the spread to ordinary homes and offices, the epidemic of multi-user applications is expected to increase dramatically. Examples of these applications include meetings, games, collaborative work, distance learning, and the like. Multi-user applications often involve different information formats such as control data, video (video), image and audio. These are exchanged between various user terminals, that is, multipoints. Designing a system that supports these multimedia multimedia applications presents two key challenges. That is, the use of resources in a scalable (measurable) technique for managing potentially complex interactions and in an efficient and economical manner. In Narrowband ISDN (N-ISDN), these issues are addressed for multi-user calls to conferences by using a bridge, also known as a multipoint control unit (MCU). A bridge is a service centered on logical processing that executes data binding and management of meetings such as user participation / withdrawal. The bridge receives voice from each user, mixes the signals, and conversely sends the resulting signal, thereby enabling multipoint communication over point-to-point links (point-to-point links).

【0003】

Packet-based networks such as Broadband Integrated Services Digital Network (B-ISDN), for example, in high-performance terminals such as personal computers (PCs) and workstations, provide these bridging capabilities in a distributed manner, of course. It is possible. However, there is also convincing debate about the use of bridges in these scenarios. Terminals with a simple structure may remain connected to the network, and such terminals may not be able to support these features. Like telephones, directly connected ATM devices fall into this category. Providing a control center centered on logical processing simplifies many management issues, especially when it comes to maintaining accurate state information and providing secure access. When it comes to bandwidth issues, bridge-based solutions can be very efficient and avoid any unnecessary data transmission. For example, it is not necessary to receive individual (bandwidth-intensive) audio and video channels from each user.

【0004】

[Problems to be Solved by the Invention]

The design of wideband bridges is considerably more complex than that for narrowband networks and presents some issues that must be addressed to make such an approach feasible. It can be said that the core of the present invention lies in a method of efficiently managing bridge resources, that is, a problem motivated by the following four points of consideration. First, the range of applications is much broader, requiring greater flexibility in terms of bridge functionality and the resources it requires. Second, the functionality of the terminal will change, as does the form of compression and data channel processing that the terminal supports. Third, using packet networks in conjunction with variable bit rate traffic, such as compressed video, leads to problems with bridge resource management, similar to problems with the network itself. Fourth, bridge operation has important consequences for end-to-end quality of service (QOS) received by audio and video channels, especially with respect to delay and packet loss. It means that it can have.

【0005】

[Means for solving problems]

A bridge provides a collection of services that enable the efficient operation of multipoint applications. For broadband, the challenge of designing a multipoint bridge is complicated by several factors, including different media formats, asynchronous (packet) communications, and heterogeneous terminals. The present invention is directed to resource management within a broadband multipoint bridge.

【0006】

According to one aspect of the invention, an electronic bridge resource management system consists of a programmatically implemented processing system with bridge service and resource manager software. The bridge service has interfaces with multiple clients and receives quality of service (QOS) specifications from each client. The resource manager receives a quality of service (QOS) specification from the bridge service and distributes at least one quality of service (QOS) constraint associated with the quality of service (QOS) specification through the channel's flow processing module. .. In addition, the resource manager determines the resource requirements for each flow processing module and determines whether the bridge resource can be arranged to meet the quality of service (QOS) specification. As part of the quality of service (QOS) negotiation process, clients may change their quality of service (QOS) specifications and the resource manager refuses to accept them due to lack of available resources. In some cases, it can be retried.

【0007】

According to the second aspect of the present invention, there is presented a method of enforcing the bridge degradation policy when the client informs the bridge of the service degradation policy (policy for service performance degradation). ing. Degradation policy information is associated with priorities within clients, channels, and groups. Therefore, the bridge stores the data corresponding to the degradation policy information in the appropriate client, channel, or group data structure. In the event of an overload of bridge resources, the bridge enforces the specified degradation policy.

【0008】

BEST MODE FOR CARRYING OUT THE INVENTION

In the following description of the preferred embodiment, a group refers to a collection of clients participating in a multi-user application. For each group that the bridge is required to generate, the bridge maintains a data structure.

【0009】

A client is a software program that runs on a multimedia terminal and interacts with a bridge service to allow users to join a group. In order to participate in a particular multi-user application, the user is expected to select and run the corresponding client program. For example, a user could participate in a multiplayer game and a multi-user conference by running both a game client and a conference client. Client information is recorded in a bridge-maintained data structure.

【0010】

One or more channels are associated with a group, where each channel allows communication between clients within the group for a particular form of information. Examples of information formats include audio, video, and data on a whiteboard. Channels are represented by bridge-maintained data structures and are realized by connecting flows (described in detail later) using a dedicated set of flow processing modules (FPM). For example, to have a voice conference with three clients, the channel consists of a pair of flows for I / O and a voice mixed FPM in the bridge for each client.

【0011】

Each user joins a group by interacting with the bridge using their own terminal, often via a graphical user interface (GUI). Terminals can take many forms, including personal computers (PCs) and set-top boxes, with access to wideband networks and several I / Os such as displays, speakers, microphones, or cameras. It has an O device. Application software running on a terminal or its agent (eg, PC-controlled telephone access) interacts with the bridge service using signaling protocols such as remote procedure call (RPC).

【0012】

A bridge service is software that runs on a bridge and implements an application programmer's interface (API) for the services provided by the bridge. The bridge is designed to allow simultaneous access by multiple groups. Broadband networks are used to transport control information (ie, signaling) and data traffic over the virtual circuit between the bridge and the terminal. Data traffic includes continuous media (CM) such as audio and video, which can be utilized depending on the requirements of a particular application, user preferences, and terminal capabilities.

【0013】

FIG. 1 shows a typical system configuration, where the bridge 10 and various multimedia terminals 12 are interconnected by a broadband ATM network 14. The bridge is a modern server machine (eg Silicon Graphics-Silicon Graphics) A computer system designed to manipulate large internal and external data bandwidths, such as those available on Inc.'s Challenge Server). The network service provider can implement the bridge server as an exchange attached to the intelligent network. The bridge 10 can be physically realized, using a collection of networked hosts, perhaps providing media-specific equipment such as video processing (video processing). Such a distributed bridge arrangement is illustrated in FIG. 2, where the bridge service host 16, the video processing host 18, the audio processing host 20, and the data processing host 22 are interconnected by the broadband network 14 itself. ing. Moreover, the concept of the present invention can also be supported by multiple collaborative bridges.

【0014】

The bridge service API allows the user application (client) to access the equipment of bridge 10. When a request is received by the bridge service, it is processed and the response is returned to the client, indicating success or failure. As part of the processing of each request, the bridge service may initialize or modify the state information it maintains to record information about groups and clients. The interface to bridge 10 is defined by the API and associated state information. The interface can also support multiple levels of groups. (For example, enabling sub-meeting) [0015]

As already defined, a group is a collection of clients participating in a multi-user application related to Bridge 10. For each group, the bridge service maintains a data structure as part of its state information. The bridge service also maintains per-client information with a separate client data structure for each group in which one user participates. These data structures maintained by the bridge and their areas as components are as follows. That is, Group data structure 1. Group identifier 2. Current client list (ie, participants) 3. Group owner (default generator) 4. Current status (eg start, in progress, interruption, future booking) 5. Schedule (start time / date, duration) 6. Floor (minimum) control policy (eg open, coordinated by selected clients, bridge coordinates requests sequentially) 7. Access control policies (eg open, restricted client list) 8. Setup mode (active-bridge is up, passive) 9. Billing (for example, owner's burden, client's equal burden, usage base) 10. It is a media channel (number and format, eg video, audio, whiteboard) and the client data structure is Client data structure 1. Client identifier 2. User details (name, address) 3. Client address 4. Authentication key (encryption key) 5. Current group (may be none) 6. Current status (active / inactive) 7. Event report (on / off, event mask) 8. Acceptable data format (compressed, coded) 9. Available media devices (format, capability) 10. Current list of channels 11. Media channel mask 12. Presentation options (eg, window quadrant, audio-based selection).

【0016】

Some parameterized calls are provided as part of the API, including those that do the following: That is, (1) create and destroy the group, (2) create and destroy the client, (3) allow the client to join and leave the group, and (4) set the attributes of the group or client. Or get it.

【0017】

As illustrated in Figure 3, the bridge architecture contains three basic elements. That is, bridge service 24, channel processing 26, and network access 28. The bridge service 24 implements the API to allow access to the bridge to clients, groups and channels. Some of the channels used in one group may require processing by bridge 10. (The channel processing function 26 in the present invention is performed by FPM.) Among other things, continuous media (CM) can be processed to perform synchronization, join, or conversion. Synchronization is essential because the temporal relationship between CMs can be maintained. Coupling refers to functions that can be applied to a set of CMs, such as individual gain control for audio and image scaling for video. The need for conversion arises from the use of heterogeneous data formats and device features. For example, some multimedia terminals may have an MPEG compression board, while other participants only have JPEG support. In addition, the bridge must access the broadband network 14 and execute appropriate communication protocols in order to receive and transmit control and data (including CM). For example, the bridge's network access function 28 supports B-ISDN signaling, AAL / ATM processing, and data transmission / reception.

【0018】

An important requirement for operating Bridge 10 is performance. In other words, how to give clients access to the group with an acceptable and predictable level of performance. This would instead require a well-designed resource management system. In the case of narrow bandwidth, the maximum bandwidth is low, even for continuous media (CM), and this is due to the fact that current utilization is easily determined by the number of active physical network connections. The points are drastically simplified. In addition, the set of processing functions is often quite limited, statistically defined, and can be implemented using DSP banks. However, for broadband bridges, the set of processing functions will be larger and need to be dynamically updated, for example, incorporating new video compression formats. Will be. From this point, software implementation is emphasized. In addition, maximum bandwidth will have important implications, and more importantly, it can vary even for a given CM channel. Therefore, it is more difficult to determine the requirements for the current usage amount. Therefore, the present invention provides an efficient technique for managing access to bridge resources.

【0019】

In essence, Bridge 10 is a server in a large distributed computing system. The traditional way to handle resource management in such systems is to control resource access by a collection of user-level entities, often called processes or domains, that depend on the operating system. This allows the processes to share a common platform but operate independently. For broadband bridges, this could take the form of a bridge service that describes the process dealing with each new group. Such a process would also handle the client's request and perform channel processing and distribution. Each process will generate a request to the operating system to access resources such as CPU, DSP, memory, and network I / O. While this is a rational model, it makes it difficult to allocate resources in a way that can result in efficient and predictable scheduling. For broadband bridges, a finer degree of resource management is desirable. This is important to support quality of service (QOS) requirements for CM channels. Quality of service (QOS) requirements typically have constant delay, jitter, and loss tolerance.

【0020】

In general terms, a quality of service (QOS) arrangement is an agreement with a resource provider that resource utilization meets certain performance requirements. Quality of service (QOS) defines the expected performance of data transport on a flow. It is identified as a set of parameters that describe the format of quality of service (QOS) arrangements, traffic, and performance. Broadband networks are designed to support end-to-end (end-to-end) based quality of service (QOS) arrangements. In the system of the present invention, these arrangements have been extended to include the operation of bridges. [0021] [0021]

The quality of service (QOS) architecture has the following set of basic functions. That is, specifications, negotiation (negotiation), replacement, reception control, management and scheduling. User specifications include traffic characteristics (eg, average / peak bandwidth, burstiness), performance requirements (eg, delay, jitter, loss), quality of service (QOS) conventions (eg, guaranteed). Is it statistical?). Users must negotiate with a quality of service (QOS) manager to ensure that these quality of service (QOS) requirements are achievable. This involves waiting to convey information about the specification and see if access is granted or denied. The specification is replaced by a quality of service (QOS) manager with a set of requests for resources, such as memory volume and CPU cycle, and is tied to existing application knowledge to perform reception control tests. Is used. The result determines whether quality of service (QOS) arrangements can be configured as requested for use of the system. If the arrangement is approved, the management mechanism aims to ensure that certain source traffic limits are maintained, while the scheduling mechanism aims to try and meet performance requirements. ..

【0022】

To enable quality of service (QOS) -driven resource management for the Broadband Bridge 10, the system of the present invention makes arrangements for bridge access in a manner similar to that performed by clients for network access. I am trying to set it. Moreover, higher efficiency is achieved by associating resources with channel processing actions, rather than simply allocating resources based on the number of groups, clients, or channels. Such resource allocation can be achieved by introducing the so-called "flow" and "flow processing module" concepts.

【0023】

Recall that one group can contain several channels, some of which can propagate commercials. Each client will provide and receive (such as commercials) for some or all of the channels in its group. Thus, for a given channel, the bridge 10 will receive data from the client, process it, and return the resulting data. An example would be a group where each client has a single channel that sends its voice and, conversely, receives the combined signal.

【0024】

A "flow" is a connection that propagates data to or from a client, and a connection that propagates data internally between channel processing steps 26 of bridge 10. Each channel consists of a set of flows. A flow is always associated with a particular channel within a group, but not necessarily with a single client in such a group. In essence, a flow is a one-way pipe for transporting data between ports, using a network virtual circuit (VC) or, if internal to bridge 10, the memory of the bridge. It is carried out by using a buffer.

【0025】

The various functions 26 applicable to the channel are realized using the Flow Processing Module (FPM), which could be implemented as a function within a library of programming languages. Each of these performs a single distinct function and, at run time, runs as an independently scheduleable thread. A thread is a software program that exists to execute an example of FPM or process a flow in a client. Therefore, once a given FPM is selected, an example of that FPM is generated and assigned to the execution thread.

【0026】

Each FPM is designed to do the following: That is, it receives data about a particular channel on one or more input flows, processes it, performs independent functions, and transmits the resulting data on that output flow. is there. A simple example of an FPM is that it serves to receive flow data from an input network VC. A more sophisticated example is one that includes an FPM that combines audio and performs video format conversion. As part of that definition, an FPM can accept parameters that adjust its behavior. For example, JPEG video compression FPM will accept a factor for quantization.

【0027】

Each FPM performs software initialization and core processing. Once an example of FPM is generated, it performs initialization, which requires interpretation of control parameters, setting of data structures, etc. Therefore, the example of the FPM enters a loop in which the core processing occurs. In particular, this is a loop in which the FPM reads data from its input flow, processes it, and writes the result to the output flow. The core process can be performed in a different way, independent of the functional definition of the FPM. For example, voice-coupled FPM can be performed on the CPU or using a DSP. Traditionally, DSPs have been used to support audio and image manipulation, but with faster processor speeds and well-designed compression techniques, many such features are software (eg, video mixers). It can be implemented in, which makes it easy to increase and add new bridge functionality.

【0028】

The software places a bridge resource for each FPM example that is allowed to run. Such an arrangement is an important aspect of the system. By controlling how each thread accesses bridge resources, quality of service (QOS) conventions can be adhered to.

【0029】

Figure 4 shows the use of FPM to hold a conference with two clients, just with a single (voice) channel. Here, the client A30 and the client B32 are communicating via the bridge 10. The two FPMs 34 and 36 are used to receive voice information, and the two FPMs 38 and 40 are used to transmit voice information. Flow 42 propagates data to or from the bridge, interconnecting FPMs for a given channel. Data arrives from the network, travels on the flow through successive FPMs, and is processed within the pipeline.

【0030】

The FPM has one or more input and output ports. A port is an endpoint for communication over a flow. It is associated with a particular thread and runs on a bridge or multimedia terminal. Figure 5 shows four examples of multiport FPM. That is, a converted FPM44 with a single input and output port, a synchronized FPM46 with two input and two output ports, a combined FPM48 with two input and single output ports, and two input ports. And a selective FPM50 with a single output port. Each FPM also has a control port and a feedback port that interact with the bridge service (not shown).

【0031】

The FPM / flow model requires extensions to the bridge service API and state information, as presented earlier. The data structures for channels, flows, and FPM / threads are as follows. Channel data structure 1. Channel identifier 2. Channel format (eg audio, video, data, video, etc.) 3. Owner (eg group identifier) 4. List of flows (flow identifier) 5. List of FPM (module identifier) Flow data structure 1. Flow identifier 2. Owner (group by default) 3. Source (host / thread / port) 4. Sink (host / thread / port) 5. Network VC information (eg ATM address, unicast VC or multicast VC) 6. Quality of service (QOS) (arrangement format, traffic, performance) FPM / thread data structure 1. Module identifier 2. Owner (group by default) 3. Control / event port 4. List of input ports 5. List of output ports 6. Operating parameters 7. Resource handle (a so-called "ticket" that allows access to the placed resource) [0032]

Access to the above items is achieved by extending the API with parameters parameterized as follows: That is, (1) create and destroy channels, (2) join and leave channels, and (3) set and acquire channel attributes.

【0033】

The FPM / flow model aims to simplify the process of replacing client requirements for quality of service and bridging capabilities in terms of actual resource needs. As mentioned, resources are arranged so that threads can execute an example of FPM. In the bridge, these resources (represented in FIG. 6) are memory 52, DSP54, CPU56, internal and external bus / network access 58. Other resources used to transport or process data may also be deployed, such as exchanges.

【0034】

Figure 6 shows the components of the software architecture required for resource management within the bridge. Access to the bridge is via bridge service 60, which directs the request to the resource management system. There are three levels of resource management, the lowest being the individual resource scheduler 62, which allows access to resources by authorized FPMs. The resource scheduler selects from the waiting FPMs according to the scheduling policy (scheduling policy). Scheduling algorithms of the form used in high-speed packet switches are used to ensure that performance constraints are met. That is, support for priority and a deadline in time. At the medium level, there are three controllers. These are defined for each of the three forms of processing performed by the bridge, one for the FPM: synchronization 64, join 66, and transformation 68. They keep track of the available FPMs and can evaluate resource requirements for a given parameter and set of traffic. At the highest level is the Quality of Service (QOS) Manager 70. It can be seen as a high-level scheduler that performs reception control and coordinates access to resources. A resource handle is an identifier issued by a quality of service (QOS) manager 70 and used by the FPM to gain access to a particular resource. This is achieved by presenting the handle to the appropriate resource scheduler 62. At the same level as Quality of Service (QOS) Manager 70, there is Reservation Manager 72. This allows for longer periods of management by manipulating advance reservations for bridge resources.

【0035】

One example will be used to illustrate the detailed interactions of the three levels of resource management. A voice-only conference with three clients and the various interactions required to achieve it are shown in Figure 7. The owner requests the bridge service 60 to spawn a client we call client A (Figure 7 (1)), then has a whole of three clients, a single voice channel. Requests to generate a group that can be started immediately (Fig. 7 (2)). The bridge service 60 arranges the client data structure and the group data structure, initializes the client data structure, and returns a display indicating success to the client A. Therefore, client A requests that the channel should be generated and that the FPM for voice coupling should be associated with it (Fig. 7 (3)). If successful, the channel and FPM data structures (of voice-coupled FPM) are generated by the bridge service. Client A then requests to subscribe to the channel ((Figure 7 (4))) and the quality of service (QOS) parameter that the client expects (ie, QOS) so that the flow is received from the bridge. Specifications) will be supplied.

【0036】

Here, the bridge service 60 contacts the quality of service (QOS) manager 70 to determine if the client should be allowed to execute ((Fig. 7 (5)). Reception control has three basic steps. Constrained distribution, resource replacement, acceptance decision. Constrained distribution is a service from the perspective of running constraints on individual threads running FPM for that channel. Requires a software algorithm that decomposes the entire quality of service (QOS) constraint (as given in the specification). Various approaches are available to perform constrained distribution. One approach Simply means that the constraints are evenly distributed. A more sophisticated approach corresponds to the two-phase protocol used to set up virtual circuits in some wide area ATM networks. In the phase of, the quality of service (QOS) specifications of the network are communicated sequentially through each switch between the source and sink, with the aim of satisfying the overall constraints on each switch. The second phase is the reverse. Going in the direction and trying to optimize constrained distribution. As a result of such an approach, for example, a heavily loaded switch has a greater delay than other switches that can be lightly loaded. It is possible to be given the freedom to incorporate.

【0037】

After the constrained distribution, a substitution feature is implemented to determine the resource requirements for the FPM for the identified constrained distribution. Substitution is the act of determining the approximate resource requirements for each thread so that each thread can meet its assigned quality of service (QOS) constraints. In this example, the quality of service (QOS) manager 70 is requested for the FPM in what format and in what amount of resources based on the quality of service (QOS) requirements for client A's voice. It requires the coupling controller 66 to evaluate whether it is present. ((Fig. 7 (6)) Furthermore, in combination with the resource requirements for the received FPM and the transmitted FPM, this is used to reach the first reception decision. If sufficient resources are not available, the quality of service ( QOS) Manager 70 attempts different constrained distributions and repeats the replacement step. If sufficient resources are available, Quality of Service (QOS) Manager 70 checks with Reservation Manager 72 and is right now. Guarantee that the resources you are trying to deploy are not already reserved. In fact, if they are readily available, the resources will be deployed and the quality of service (QOS) manager status table. Is marked as placed.

【0038】

In addition, the quality of service (QOS) manager 70 indicates the combined FPM, received FPM, transmitted FPM, and updates the channel data structure. (Incoming FPM, Outgoing FPM are automatically generated when the client joins the channel. Similarly, any conversion required will automatically result in a conversion FPM, which is the client. It is generated and executed based on the function of the client as determined from the data structure.) Therefore, the interconnected flow is generated as follows. That is, (a) the quality of service (QOS) manager 70 sends a control message to the voice-coupled FPM to request the desired input port number, and (b) when such information is received, the quality of service (QOS) manager. 70 sends a control message to the receiving FPM (via its control port) and identifies the thread identifier and the port number of the voice-coupled FPM to which the data should be sent, (c) the receiving FPM is also its output port. Report the number, (d) where the quality of service (QOS) manager 70 can initialize the flow data structure, which provides thread and port information about the source and sink of the flow. Due to the possession of Quality of Service (QOS) Manager 70. In a similar manner, the quality of service (QOS) manager 70 interacts with the transmit FPM and, in addition, the voice-coupled FPM to obtain relevant port information and initialize the interconnected flow data structures.

【0039】

Upon performing the above steps, data structures for flows and FPM / Threads are generated and initialized. The quality of service (QOS) area in each flow data structure is filled with the results of the constrained decomposition determined by the quality of service (QOS) manager 70 during the constrained distribution. In particular, the constraints assigned to each thread determine the corresponding QoS parameters, which are stored as part of each flow data structure. Combining the QOS regions in all flows for a particular channel should be equal to the overall quality of service (QOS) specification provided by the client. Here, the FPM data structure contains handles for specific resources, these resources have been placed for that handle, and such resources are their output ports. Note that it contains resources (VC or buffer) for the flow connected to.

【0040】

There, a response ((Fig. 7 (8)) is sent to the bridge service 60, instead the bridge service 60 opens the VC for voice data to the client on the bridge port (of the receiving thread) and , Gives details about the QOS parameters (for setting the agreement with the network) requested from the network for the VC ((Fig. 7 (9))). [0041]

In a similar manner, both client B ((Fig. 7 (10))) and client C ((Fig. 7 (11)) also make requests to generate clients and join groups and channels. In response to a request to subscribe, the quality of service (QOS) manager 70 sends the client's QOS parameters (these are fed to the bridge for each channel the client wants to subscribe to) and the FPM. Performs a reception control test with the expected increase in the need for resources of. When each client joins one channel, the bridge also networks to that client via unicast VC or multicast VC. Arrange the transport (ie generate VCs for flow data). Quality of Service (QOS) Manager 70 now uses control ports on combined FPMs to manipulate additional flows for voice. Please note that any subsequent requests to modify attributes that may affect resource usage are also communicated by the Bridge Service 60 to the Quality of Service (QOS) Manager 70 for evaluation. If a request is rejected due to lack of available resources, the client can change the request and retry.

【0042】

Once the client is allowed to join the channel, data will flow between the threads and will need to be executed by the threads to process the data. The resource scheduler 62 makes a selection from among those threads that are ready to run (at any time during which the resource scheduler has a queue of threads that are eligible to run). After verifying the resource handle belonging to the waiting thread, the resource scheduler 62 selects the thread to be executed next based on a certain policy. For example, such a policy may be priority time division (time sharing) or the earliest deadline. Finally, in the case of the deployed CPU resource example, the resource scheduler 62 loads the thread state into the CPU registers and then starts execution.

【0043】

(Advance reservation) The basic QOS model corresponds to the one used in the ATM network area. A characteristic of such a model is that QOS arrangements are negotiated for immediate access to resources and unspecified lengths of time, equivalent to making a phone call. For many of the applications that Bridge supports, especially for conferencing, such a model is not always appropriate. The use of such applications is similar to real-life scenarios, where it is common to, for example, schedule meetings in advance. The ability to pre-book for the use of bridge 10 is a feature implemented by the reservation manager 72 as described in FIG.

【0044】

Two parameters are required to make an advance reservation. That is, the start time and the duration. The start time indicates whether it is an immediate start (default) or some time in the future. Duration defines the maximum duration and is required for immediate and future requests so that Bridge 10 can take advantage of resource sharing and utilization. However, if a room is available, it is similar to changing the time of the meeting or extending its length, and both of these parameters can be negotiated again. Please note that. These parameters were described as part of the group data structure. It is then transmitted as part of the call that creates the group. This is a problem that is normally dealt with when a client joins a channel, but the key issue here is to calculate how much resources will be needed. is there. The accuracy of such a process depends on how well the booker can provide the details. Reservation manager 72 uses such information to request a quote. As a minimum, bookers are expected to indicate the number of clients expected to join the group and the channels used. As a result, the transmission FPM and the reception FPM can be used as well as the interconnected flows. Estimates can be improved if the booker shows additional FPM.

【0045】

From the perspective of resource management architecture, a set of interactions is needed. When Bridge Service 60 receives the request with the identified future start time, it makes a request to Reservation Manager 72. The reservation manager 72 operates by forming a resource request based on the information provided by the reservation person. Reservation Manager 72 consults with FPM Controllers 64, 66, 68 to provide resource estimates and also checks Quality of Service (QOS) Manager 70 to determine overlaps with current deployments. Here, the response is sent to the booker to indicate if the required resources are available. Such an internal negotiation process is repeated if the booker subsequently provides additional information, such as a particular FPM. When the start time for a group arrives, the share of responsibility for it is transferred from Reservation Manager 72 to Quality of Service (QOS) Manager 70.

【0046】

(Features at a High Level) In the present invention, each user can associate the requirements of QoS with the data presented on each user's terminal. These requirements cover both the temporal and informational characteristics of the CM. For video, the informational characteristics include: (1) Number of images per second, (2) Image dimensions including pixel depth, (3) (a) Quantization factor, (b) Motion threshold, (c) Inter-frame coding Image quality, including the ratio of encoded images in (frames) to the images that have been made, (4) the amount of loss. Similar informational properties can be defined for speech. The temporal characteristics are delay and jitter.

【0047】

The user may be able to set these variables in a statistical manner or have the ability to dynamically change them while they are being displayed. Access to these variables can be fairly explicit, depending on the interface, but rather the channel may be controlled via one or two overall quality standards. Is higher. This could be in the form of a graphical slider, or in the form of a choice of high quality, medium quality, low quality. This creates a distinction between application and QOS specifications at the system level. The specifications at the system level are those recognized by the bridge or network, such as bandwidth, delay, and so on. On the other hand, the specifications at the application level must be replaced by the client application software for the display at the system level.

【0048】

The system of the present invention can be said to be driven by a sink in the sense that it empowers the user to influence the desired quality of service (QOS) for the channel being input. Such an approach allows for considerable flexibility, and the bridge service API will change the channel attributes (data structure parameters, eg, QOS). The client's request indicates a desire to change the behavior at Bridge 10, and they can be rejected due to lack of resources. Each client of Bridge Service 60 is required to maintain a callback interface. It is used to notify clients of events (eg, new client joins) and errors. It is also used, for example, by requesting a client to change its resource utilization, for example by using a smaller bandwidth. QOS-powered systems rely on statistical multiplexing for efficient resource sharing, which can result in occasional periods of resource overload. That is important. This is especially problematic when dealing with potentially large bandwidth regions for variable bitrate video.

【0049】

Quality of service requirements that lie at a higher level than for individual channels are also supported. In particular, it is useful to be able to examine QOS at each of the individual levels of channels, clients, and groups. The present invention supports the ability to handle resource allocation and overload in terms of these levels. Using the API to set attributes, authorized clients are allowed to set resource limits and have concise policies that deal with their intent. Resource limits, cost limits, degradation policies, etc. are controlled by parameters stored within various additional areas of the associated client, group, or channel data structure. For all parameters, as they are, they can be propagated along the call that creates the client, group, or channel. Optionally, they can be communicated later using attribute-setting calls.

【0050】

In general, the degradation policy can be set by the client or bridge operator and is enforced by software within the QOS Manager 70. For example, priority can be assigned to a channel so that the client can identify, for example, that the video should be degraded in preference to the audio. Similar policies can be provided at the group level. For example, a meeting of management groups can be assigned a higher priority than a group running game software. Also, when setting the priority of degradation, price-related information can be used, for example, the lowest priced service is most likely to be degraded.

【0051】

Relationships between entities (eg, channels) at the same level can also be identified in terms of quality of service, such as the degree of channel-to-channel (mutual channel) synchronization (ie, lip synchronization). Coarse resource placement is also supported, for example, so that the bridge operator can identify that 50% of the bridge resources can be placed in a particular group.

【0052】

Bridge also keeps track of billing (eg, how much CPU does Group A use?) And pricing information. These features may support some of the features at the higher levels mentioned above.

【0053】

The FPM / flow model of the present invention may also be adapted to provide QoS support on the multimedia terminal 12. Such features (of the FPM / flow model of the present invention) will allow clients to negotiate resources for multimedia terminals and set arrangements for multimedia terminals 12 and QoS. The FPM provided by the terminal 12 captures data (eg, captures video by a camera and captures audio by a microphone), displays data (eg, displays video by a CRT, and represents audio by a speaker), and further. Data compression / compression decompression (such functions may optionally be performed by bridge 10) may be included. In a similar manner, the invention may be adapted to support QoS in other forms of network-based servers (eg, video-on-demand servers).

【0054】

[Effect of the invention]

The present invention is directed to resource management within a broadband multipoint bridge. Although the design of wideband multipoint bridges is complicated by various factors, the present invention provides a way to efficiently manage bridge resources. This enables efficient operation of multipoint applications in broadband networks.

[Simple explanation of drawings]

[Figure 1]

Figure 1 is a chart showing the configuration of a typical bridge system.

[Figure 2]

Figure 2 is a chart showing an example of a distributed bridge.

[Fig. 3]

Figure 3 is a functional block diagram exemplifying the overall bridge architecture.

[Fig. 4]

Figure 4 is a diagram illustrating basic FPM and flow for a single channel (voice), two clients.

[Fig. 5]

FIG. 5 is a chart showing some examples of multiport FPM.

[Fig. 6]

Figure 6 illustrates the components of a quality of service (QOS) management bridge software architecture.

[Fig. 7]

FIG. 7 is a chart illustrating the interaction between the client and the bridge to form a three-client voice conference.

[Explanation of symbols]

10 bridge 12 Multimedia terminal 14 Broadband ATM network 16 Bridge service host 18 Video processing host 20 Speech processing host 22 Data processing host 24 Bridge service 26 channel processing 28 Network access 30 Client A 32 Client B 34, 36, 38, 40 Flow Processing Module (FPM) 42 flow 44 Conversion Flow Processing Module (Conversion FPM) 46 Synchronization Flow Processing Module (Synchronization FPM) 48 Join Flow Processing Module (Join FPM) 50 Selection Flow Processing Module (Selection FPM) 52 memory 54 DSP 56 CPU 58 Internal and external bus / network access 60 bridge service 62 Resource scheduler 64 Sync Controller (FPM) 66 Combined Controller (FPM) 68 Conversion controller (FPM) 70 Quality of Service (QOS) Manager 72 Reservation Manager