Dynamically scalable conference system

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates generally to communications, and more specifically to multipoint bridging or multipoint conferencing systems.

【0002】

[Conventional technology]

Generally speaking, multipoint conferencing is implemented in various forms through packet networks, switching telephone networks, and various other different types of networks. For example, there are multipoint data conferencings where users can discuss materials and share data. To support multipoint data conferencing, the International Telecommunications Union (ITU) standard T.120 defines, for example, an umbrella set of protocols for use on packet-based networks. On the other hand, there are also multimedia conferences where users can participate in audiovisual conferences using, for example, NetMeeting commercially available from Microsoft®. Similar to ITU T.120, multimedia conferencing is defined in ITU H.323, which is another protocol that covers transmission control protocol / Internet Protocol (TCP / IP) connections over packet-based networks. Make up an umbrella set.

【0003】

In multipoint bridging, facilities from bridging service providers are typically used to connect users (conference participants) to each other (to support the user's conference). This facility is typically referred to as a bridge or multipoint control unit (MCU), which supports the required standards for multimedia, such as ITU H.323. This type of facility is referred to herein as a "multipoint server". (For simplicity, this multipoint server is not only expected to support industrial standards for interoperability with other facilities, but this facility is also expected to support company-owned signaling schemes. ).

【0004】

A multipoint server is modeled as having a server capacity of N, where N represents the total number of conference participants (users) that the server can or should support at any time. .. This capacity can be considered in relation to any one or more server characteristics. For example, the server capacity can be thought of as something as simple as the total number of server ports, in which case the server capacity is treated as fixed. That is, the server cannot support more than N users. As another example, server capacity can also be considered in relation to a particular quality of service (QoS) such as response time, in which case the server can support up to N users. Guarantee maximum response time. However, even in this background, the server does not guarantee the promised QoS when N or more users access the server. In other words, once an a priori defined capacity for a multipoint server is full, if an additional user subsequently requests to join a conference on that server, the request will be , Rejected, or even if allowed, causes performance degradation for all users.

【0005】

For this reason, it is desired (if not necessary) to increase the capacity of existing multiservers when the demand for conferencing (traffic) increases (especially during peak loads). One alternative is to simply replace the server with a larger, more powerful one, but this method also increases the cost of the server. In addition, if the traffic is predictable, another alternative would be to a priori cascade the servers to each other to support larger capacity. FIG. 1 shows an example of a cascade bridging configuration.

【0006】

[Problems to be Solved by the Invention]

In this cascading bridging configuration, the total capacity required is a priori divided among multiple servers 10-1 to 10-n, with each server supporting multiple users. However, this cascading bridging configuration, or bridge tree, is primarily designed for users on the same server to communicate with each other, with one server, eg, a user on multipoint server 10-1, on another server. For example, in situations where it is necessary to communicate with a user on the multipoint server 10-n, the communication is provided via the multipoint server 20.

【0007】

[Means for solving problems]

In contrast to the approach described above, that is, an a priori (pre-) designed cascade bridging configuration, we allow multiple multipoint servers to dynamically cascade to each other to increase system capacity. Designed the system. In one embodiment, the bridging system includes one router and multiple multipoint servers. For each user requesting to attend a particular conference, the router routes the call to a particular server and, if necessary, adds an additional server to increase the capacity for that conference. To command. For example, upon receiving a request from a user to join a conference associated with Server A, the Router first queries Server A for the current spare capacity. If Server A has additional capacity, the router routes the user to Server A. However, if Server A cannot accommodate the user, the router directs Server A to invite an additional server, such as Server B, to the conference. After Server B joins the conference, the router routes the user to Server B.

【0008】

BEST MODE FOR CARRYING OUT THE INVENTION

FIG. 2 shows one embodiment of the present invention. Except for the concept of the present invention, the elements of FIG. 2 are well known and will not be described in detail. For example, illustrated as a single block element, each multipoint server is a multipoint control unit (MCU), including a storage program control processor, memory, and a suitable interface card. Similarly, except for the concepts of the present invention, the connecting router 105 routes packet-based traffic in a manner well known in the art. For the purposes of this description, the bridging system 100 has TCP / IP packet-based traffic and ITU (as described above). It is expected to support both H.323 and provide audiovisual conferencing capabilities among users accessing this system. The configuration of user endpoints (not shown) is not particularly relevant to the concepts of the present invention, but in the context of this description, it is assumed that each user endpoint is running a NetMeeting type application. .. Further, for the purposes of this description, the concepts of the present invention are described in the context that one particular conference is supported by all three multipoint servers illustrated, provided that the present invention provides. The concept of dynamically adding conferencing resources is applicable to situations where the bridging system 100 supports one or more conferencing. In addition, as will be appreciated by those skilled in the art, the concepts of the invention are described herein in the context of packet-based networks, but the concepts of the invention apply similarly to other types of networks. it can.

【0009】

As shown in FIG. 2, bridging system 100 includes two or more multipoint servers represented by multipoint servers 110, 115, 120 (these may be geographically separated from each other). ). In addition, bridging system 100 includes connecting router 105. As shown in the figure, the connection router 105 receives connection requests from a plurality of users. These connection requests are expected to be delivered via one or more facilities (not shown) that support TCP / IP packet-based traffic. The connecting router 105 is also further coupled to the respective multipoint servers 110, 115, 120 via signaling paths 101, 102, 106, 107. Although these signaling routes are shown here as separate signaling routes, they can also be configured using facilities that carry TCP / IP packet-based traffic and represent Internet connectivity. For example, a plurality of TCP / IP connections 101 and 102 can be set up between the connection router 105 and the multipoint server 110 using the same physical facility. Similarly, the multipoint server 110 is coupled to the multipoint servers 120 and 115, respectively, via signaling paths 110 and 112. (Solid lines 101, 106, 107, 111, 112 represent signaling including ITU H.323, and dotted line 102 represents private channels (discussed below)).

【0010】

In this embodiment of the concept of the present invention, the connecting router 105 serves as a central distribution point. In this context, connecting router 105 dynamically routes traffic as a function of available system resources (as described in detail later). (As will be clear from the discussion below, this behavior is transparent to other endpoints, such as the end user). As shown in FIG. 3, the connecting router 105 has a storage program control-based processor architecture, one or more communications represented by a processor 150, a memory 160 for storing program instructions and data, and a path 116. Includes communication interface 165 for coupling to the facility.

【0011】

Returning to Figure 2, it is assumed that a single IP address is associated with the connecting router 105. As shown, this IP address is represented by the HyperText Transport Protocol (http) address www.bridge.lucent.com. According to the concept of the present invention, the connecting router 105 routes a new endpoint connection to a particular bridge, a multipoint server, as a function of available system resources. As an example, these resources can be CPU usage, connection loading, bridge availability and / or type of distribution algorithm, and so on. For this description, it is assumed that the connecting router 105 uses the available capacity of each multipoint server as an example resource in performing the routing function.

【0012】

See also FIG. 4, which shows a flow diagram as an example of the method used in the system of FIG. It is assumed that the connecting router 105 and each multipoint server are properly programmed to perform the methods described below using conventional programming techniques (programming is well known and will be described in detail here). do not). For the purposes of this description, it is assumed that the conference initially started on the multipoint server 110 and is in progress here, and that the bridge tree initially consists only of the multipoint server 110. Will be done. The first server of the conference is also called the "host server" or the "current server", both of which are stored as variables by the connecting router 105, for example, in the memory of FIG. Further, for the purposes of this description, it is assumed that the connecting router 105 maintains a table of server information, which is also stored, for example, in the memory 160 of FIG. A table as an example is shown below.

[table 1]

<img file="JP2000036813A_D0001.tif" />【0013】

Table 1 contains a list of servers, the address of each server, the total capacity, and the available capacity. (Although not shown, additional information, such as information that identifies the conference currently supported by the server, that is, the conference name or conference identification (ID), can also be stored in Table 1). For simplicity, the values in Table 1 are assumed to be set a priori (in advance), eg, by a system administrator (not shown), but are not limited to this. ..

【0014】

In step 305 of FIG. 4, connecting router 105 receives a request from user X to join the conference. (As mentioned above, the connecting router 105 is one of the standards mentioned above, eg, ITU. Receive H.323 compliant requests. As part of submitting this request, the user is assumed to know (in advance) the htt address of the connecting router 105 a priori. Further, as described above, the present invention is described in the context of one conference, provided that the connecting router 105 may also receive a conference ID that identifies the conference the user wants to attend. ). Next, in step 310, the connecting router 105 identifies the current server using the variables described above. As mentioned above, at this point, the current server is the multipoint server 110. Next, in step 315, the connecting router 105 determines whether the current server has already reached its full capacity. If the current server has not reached its full capacity, connecting router 105 routes the user to the current server via signaling path 101 in step 320, and then the available capacity in Table 1. Update the information. For example, subtract that value by one. However, as can be seen from Table 1, the available capacity of the multipoint server 110 is 0. Therefore, in step 325, the connecting router 105 selects a new server (to support the conference) to join the conference. In this example, connecting router 105 proceeds to the next column item in table 1. (Other selection techniques can be used, for example, a new server that is physically close to the user can be selected using the geographic information associated with the user's IP address, for this purpose. Stores information that associates the user's sub-network address with the country's area, as well as additional information such as the geographic location of each server, and inserts this information into requests for users to join the conference. It is necessary to submit it).

【0015】

In this example, connecting router 105 selects server 115 as the new server (to support the conference) to join the conference in step 325. (Although not shown, connecting router 105 may perform additional checks at this point regarding the available capacity of this new server). Then, in step 330, the connecting router 105 instructs the host server (here, the multipoint server 110) via the signaling path 102 to request the new selected server to join the conference. .. (This will be explained in detail later). In step 335, connecting router 105 determines whether a new server has joined the conference (also described in detail later). Should the new server not join the conference, connecting router 105 returns to step 325 and selects the next server in the table as the new server. (In the unlikely event that all servers are not available, connecting router 105 will prevent users from joining the conference and the ITU Send an appropriate error message to the user according to H.323). On the other hand, if it is determined that a new server is participating, the connecting router 105 associates (associates) the new server with the current server in step 340 and uses the newly added server. Update the available capacity information, for example, decrement the corresponding value by 1, and then route the user to the new server. In this example, the multipoint server 115 is added to the bridge tree via signaling route 112 (previously composed only of multipoint server 110), and user X is added to the multipoint server via internet route 106. Routed to 115. Thus, according to the concept of the present invention, the conference capacity is dynamically increased by adding the multipoint server 115 to the conference hosted by the multipoint server 110.

【0016】

Continuing with reference to FIGS. 5, 6, and 7, these show flow diagrams as examples of methods used within the connecting router 105, the host server, and the new server, respectively. More specifically, the flow diagram of FIG. 5 shows an example flow diagram used by the connecting router 105 to perform steps 330 and 335 of FIG. 4, with FIGS. 6 and 7 being the host server and the new, respectively. Shows the interpolated steps performed by a server. In this example, it is assumed that the connecting router 105 and the host server (here, the multipoint server 110 functions as the host server) communicate using a private channel via the Internet. This private channel, the proprietary signaling (PS) scheme, is represented in FIG. 2 by signaling pathway 102. To achieve this proprietary signaling, the connecting router and host server should be sokets, Microsoft's Distributed Component Object Model (DCOM), Common Object Request Broker. Any one of a variety of different protocols, such as Architecture (CORBA), can be used. In the background of this example, it is assumed that DCOM is used to realize this private channel. The use of DCOM to support communication between objects (programs) on different computers is well known in the art, except for the concepts of the present invention. A preferred transport layer for DCOM is the Connectionless User Datagram Protocol (UDP) subset of the TCP / IP protocol suit. (Although shown as a separate signaling pathway in Figure 2, for this reason this private channel can also be carried over the Internet on the same physical channel as the user traffic). Information about DCOM can be found on the Internet by visiting Microsoft's web page "http://www.microsoft.com". In addition, additional information can be found at "http://dsl.internic.net/internet-drafts/draft-brown-dcom-vl-spec-00.txt".

【0017】

Starting with the description of FIG. 5, in step 405, the connecting router 105 sends a predetermined PS invite message to the host server via the signaling path 102 according to the principles of the present invention. This PS invite message contains at least three predetermined data fields. One field indicates to the host server the type of PS message (in this example, the "invitation" message) and the other data field is the internet address of the new server (from Table 1 above above). ), And the third data field represents the conference identifier or conference name. Thus, connecting router 105 directs the host server to invite the new server to join the identified conference. Next, in step 410, the connecting router 105 waits for a PS acquisition message from the host server. (Similar to the "invitation" message above, this knowledge message contains at least one predetermined data field, which is positively acknowledged to indicate that the new server has already joined the meeting. Alternatively, specify whether the new server is a negative acknowledge that has not yet joined the meeting). If a positive acknowledgement message is received, connecting router 105 proceeds to step 340. Conversely, if a negative acknowledgement message is received, connecting router 105 proceeds to step 325. (The connecting router 105 can also "time-out" if the acquisition message is not received within a predetermined time period).

【0018】

Next, moving on to the description of FIGS. 6 and 7, the interpolating steps are performed by the host server and the new server, as illustrated. In step 505 of FIG. 6, the host server receives the PS invite message from the connecting router 105. In step 510, the host server invites the server (specified by the IP address in the PS invite message), eg, through signaling path 112, eg, according to ITU H.323. In other words, the new server looks like a conference endpoint to the host server. Then, in step 515, the host server asks whether the new server has accepted the invitation. Determined according to H.323. If the new server accepts the invitation, the host server sends a predetermined PS "acknowledgement" message indicating that the acquisition is positive in step 520. Conversely, if the new server declines the invitation (or if a well-defined timeout occurs), the host server will indicate in step 525 that the acquisition is negative with a given PS acknowledgement. Send a message. In step 605 of FIG. 7, the new server receives the invitation message from the host server and in step 610 joins the conference according to ITU H.323, eg, via signaling path 112. (In this example, this new server is assumed to join the conference by default).

【0019】

Later, when more users join the conference, the capacity of the multipoint server 115 will eventually fill up. For example, it is assumed that the multipoint server 115 no longer has free space when user Y in FIG. 2 requests to join the conference. At this point, the connection server 105 dynamically connects the multipoint server 120 to the bridge tree composed of the multipoint servers 110 and 115 according to the flow charts of FIGS. 4-7. (The multipoint server 120 is attached to this bridge tree via signaling path 111). Similarly, the connecting router 105 requests that more users join this conference, for example, user Z joins this conference, but the capacity of the multipoint server 120 is also full. Add an additional multipoint server to the bridge tree.

【0020】

As can be seen from the above description, the concept of the present invention adversely affects the performance of end-user conferencing applications by dynamically distributing the load resulting from a large number of participants across multiple data conferencing bridges. Provide a way to maintain without. Thus, the concept of the present invention provides a scalable solution for adding (expanding) bridge capacitance. In fact, this dynamic cascading of multipoint servers appears to the end user as if they had a single bridge and almost infinite capacity.

【0021】

As mentioned above, the connecting router (or equivalent facility) dynamically connects multiple servers as a function of measuring system resources. In this example, the server capacity value entered in the table was used as an example as a measure of system resources. However, keep in mind that each multipoint server also handles other conferences that the connecting router is unaware of. Therefore, it is conceivable to use another type of resource measure. For example, the connecting router queries each current multipoint server using the PS described above for the actual load of that multipoint server, for example the CPU load, and if sufficient CPU capacity is available. If you route the user to the current server and the CPU capacity is not enough, you can add a new multipoint server to the bridge. (In this variation, the current server itself evaluates its own CPU load and either responds with its consent in the response PS message, or the current server simply connects the current CPU load. Report to the router and the connecting router compares this to a given value to determine if the user should be routed to the current server or if a new multipoint server should be dynamically added to its bridge tree. You can also do it.

【0022】

As mentioned above, the above description is merely for explaining the principle of the present invention, and therefore, although not specified here by those skilled in the art, it embodies the principle of the present invention and of the present invention. It is believed that a number of other alternative configurations that can be considered to fall within range can be devised. For example, although the concept of the present invention was described above in the context of connecting routers, one of these multipoint servers could also be made to act as a central distribution point for dynamically adding conference resources. .. Similarly, although the concept of the invention was described above in the context of ITU H.323, the concept of the invention is defined by other multipoint conferencing systems, such as ITU T.120. It can be applied to the system as well. In addition, private channels for communicating control information were implemented above using TCP / IP-based DCOM as an example, but for this reason other forms of private channels, such as direct circuit exchange connections, are used. , Private line, etc. can also be used.

[Simple explanation of drawings]

[Figure 1]

It is a figure which shows the cascade type bridging composition defined in advance by the prior art.

[Figure 2]

It is a figure which shows one Example of the bridging system by the principle of this invention.

[Fig. 3]

It is a figure which shows the upper block diagram of the connection router 105 of FIG.

[Fig. 4]

It is a figure which shows the method by the principle of this invention used in the system of FIG. 2 in a flow diagram.

[Fig. 5]

It is a figure which shows the method by the principle of this invention used in the system of FIG. 2 in a flow diagram.

[Fig. 6]

It is a figure which shows the method by the principle of this invention used in the system of FIG. 2 in a flow diagram.

[Fig. 7]

It is a figure which shows the method by the principle of this invention used in the system of FIG. 2 in a flow diagram.

[Explanation of symbols]

100 bridging system 105 Connection router 110, 115, 120 multipoint server 101, 102, 106, 107 signaling pathways 150 processor 160 memory 165 Communication interface