ES2385521B1 - Multi-conference system - Google Patents

Abstract

The OBP Multivideoconference (On Board Processing) consists of the deployment of a multivideoconferencing system (V {sup, 2} oIP, Voice and Video over IP) in satellite networks with onboard processing capability. This system will allow N users to establish videoconferencing sessions with other users, whether they are located on the Internet or in the satellite network. # Through the designed system it is possible to establish multi-conference calls (videoconferences between several participants) over IP networks, using as transport multi-beam geostationary satellites with OBP capability, offering signal quality comparable to that of ISDN multivideoconferences (Integrated Services Digital Network).

Description

Multi-conference system

FIELD OF THE INVENTION

This invention has its application in the field of telecommunications, specifically in the field of satellite communications networks. At the same time, the application can also be deployed in terrestrial networks, allowing coexistence and interaction between both networks.

BACKGROUND OF THE INVENTION

Multivideoconferencing systems exist for several years (ISDN, ATM –Asynchronous Transfer Mode-, etc.). In recent years, IP multivideoconferencing systems have also appeared coinciding with the rise of IP and Internet networks in the 1990s.

On the other hand, as with other wireless communications, there is a revolution in satellite communications. Traditionally, communication satellites have been defined as radio repeaters located in space, capable of receiving signals generated on the ground and amplifying them, and then returning them to the terrestrial communications segment. Due to the advances produced in the space sector, satellites have been acquiring a greater processing capacity, transforming from simple repeaters into systems endowed with a degree of intelligence that is facilitating the provision of a new range of real-time services through satellite networks.

The importance of the appearance in satellite communications of this type of interactive broadband applications is a key factor in the expansion of the information society, especially in rural areas. In this regard, the development and implementation of satellite-based broadband technologies is being promoted, in order to cover the needs of existing communications in unpopulated or hard-to-reach areas in which terrestrial connections are non-existent or have serious deficiencies in terms of to the quality and capacity supplied. While satellite communications represent an alternative for access to broadband services, especially in remote or disadvantaged areas, it should not be forgotten that the services offered must incorporate at least the same levels of excellence provided by terrestrial networks in key aspects such as safety and quality.

The main problem facing satellite-based systems for the provision of real-time multimedia services is end-to-end delay, also called latency. The transmission time in a sense has a direct impact on the quality that a user perceives from a conversational service. Said global delay, the result of the delays produced both in the terminals and in the different elements that make up the system, has two clearly differentiated effects. In the first place it causes the appearance of echo, which depending on the magnitude of the delay may require control measures such as echo cancellers, etc. The second effect occurs when the delay increases to a point where the interactivity of the communication is affected causing simultaneous starts and awkward pauses. Due to the difference in the rhythm that is perceived in the extremes of the communication, it is difficult to interrupt the interlocutor, even influencing the personal appreciation of the other participant. This situation occurs with delays of the order of several hundred milliseconds. In this sense, the International Telecommunications Union establishes 150 ms and 400 ms for the transmission time as the preferred threshold and limit respectively.

This situation is drastically aggravated in satellite communications, in which a connection through a geostationary satellite adds approximately 250 ms of propagation in each jump. Each complete cycle from earth station to earth station is called a jump, comprising the uplink of the transmitting earth station to the satellite as well as the downlink from the satellite to the receiving earth station. This high and inevitable delay associated with the space segment greatly reduces the allowed latency in the land segment.

In addition, it must be taken into account that there are several satellite systems, mainly differentiated by the height at which they are located, distinguishing geosynchronous Earth orbit satellites (GEO, Geosynchronous Earth Orbit), medium earth orbit (MEO, Medium Earth Orbit) , and low-altitude Earth orbit (LEO, Low Earth Orbit). GEO satellites orbit about 36,000 kilometers above the Earth's equator, while MEO satellites are at heights between 10,000 and 20,000 kilometers, and finally LEO satellites generally orbit below 5,000 kilometers. In this context, and considering the support of multivideoconferencing applications as an objective, GEO satellites are shown as the most appropriate alternative due, on the one hand, to their simplicity in the management of the system compared to MEO and LEO satellite systems. , but especially for its economic viability, by requiring a smaller number of satellites to cover the entire earth's surface than the rest of the satellite systems (MEO and LEO).

On the other hand, satellites have recently evolved to more modern systems: the so-called new generation satellites, which incorporate on-board processing capabilities (as opposed to traditional transparent type). The first satellite launched into space with these characteristics is the Amazon of Hispasat.

In terms of architecture, traditional multivideoconferencing systems are based on a central node, commonly known as a multipoint conferencing unit (MCU), which receives all multimedia streams (voice and video) to process and send them from New to all participants. If this architecture were applied to a geostationary satellite environment, with a centralized node, a double satellite jump would be required, a first jump to send the information from the sending source to the MCU, usually located in the backbone network of the segment terrestrial, and a second to send the mixed multimedia streams of the MCU to the rest of the participants. In this way, this double jump (approximately a quarter of a second of propagation per jump), would practically make communications impossible due to the high delay (almost half a second). In addition, traffic is traditionally sent in broadcast / multicast mode, using a high bandwidth, low resource on a satellite, especially in the case of high quality video conferences / definition.

In addition to avoiding the double satellite jump, and in order to optimize the bandwidth used, the proposed OBP Multivideoconferencing system includes an architecture of distributed MCUs as well as new generation satellites that, in addition to the on-board processing capacity, have of several beams (multi-beam satellites) that allow dynamic routing between the different beams through OBP capabilities. Multi-beam satellites divide their coverage area into different sub-regions, associated with their different beams, using directive antennas. In this way it is possible to intelligently direct the multicast traffic only to the terrestrial nodes that give access to the participants in the multi-conference call. That is, the bandwidth used in the multicast distribution tree is drastically reduced, maintaining a single satellite jump essential to support this type of real-time multimedia traffic.

Two patents related to the scope of application considered, WO20033997 and EP1088452 have been identified.

WO20033997 presents a two-way satellite communications system that uses dual configurable communication channels in order to reduce the bandwidth used. To do this, these channels include a dedicated unicast channel for each remote terminal and a dedicated multicast channel that will be shared between all remote terminals. With this provision, duplication of the transmission of multicast information across all channels is avoided, achieving an optimization of the bandwidth used. However, the proposed architecture does not prevent double satellite jumping for multivideoconferencing systems.

For its part, EP1088452 presents a multipoint satellite videoconference scenario. The proposed solution includes, in addition to the typical elements of a satellite communications system, an assembly server responsible for mixing the different media (audio, video, etc.), as well as an association between the transmitters and receivers involved In communication. In this way, through the use of a multicast IP protocol and such association, a reduction in the bandwidth used is achieved. However, using a centralized server does not prevent double satellite skipping. In addition, owning to a single beam in the entire coverage area does not present the advantages derived from operating with several beams, that is, great coverage and high profits.

DESCRIPTION OF THE INVENTION

The proposed OBP multivideoconferencing system is capable of providing support for multivideoconferencing services through a single satellite jump using a multicast hybrid architecture in the satellite segment and based on MCUs distributed in the terrestrial segment.

The multivideoconferencing system proposed incorporates multivideoconference nodes from different networks. Each node can individually receive (unicast) data streams from a plurality of user terminals of the same network and can also collectively receive / receive (multicast) data streams from a plurality of nodes of different networks through a multi-beam satellite with a routing table The system also incorporates a network control center to manage the satellite routing table by updating the addresses of the plurality of the conference nodes existing in each conference call session and associating the beam corresponding to each one.

This is a solution to real-time communications over satellite networks. It allows offering the same traditional communications services (voice, video, messaging, etc.) that currently exist in terrestrial networks. In addition, users can enjoy videoconference sessions with one or more users (multi-conference), a service that is currently very limited in satellite communications.

Therefore, the architecture will be physically formed by a multi-beam geostationary satellite with OBP capability, the user's terminals (whether hardware or software), a multi-conference nodes or multicast traffic servers (MCU), a Proxy in charge of the signaling plane associated to the calls between the different users, a network control center (CCR), in charge of the control of the satellite from the terrestrial segment, and specially destined to the management of the routing table of the satellite, which contains the multicast group addresses as well as the source and receiver beams associated with the different transmitters and receivers involved in the various multi-conference sessions supported by the satellite.

Multicast traffic servers, known as MCUs, are responsible for generating multicast traffic itself. The MCUs receive traffic sent by the users' terminals (unicast), transform them into multicast and send said traffic through other satellite to other MCUs (Fig. 2 and 3). Through this operation it is possible to send a single data flow through the antennas (thus avoiding multiple satellite hops), considerably reducing the delays caused in the network.

The application of this solution is not only valid for videotelephony (voice and video), but also for any other type of real-time communication (voice, video, text messages, etc.), since in IP networks there is no difference between the operation of these types of communication, although within the proposed architecture the model based on distributed MCUs is specific for multi-conference applications, requiring the existence of an MCU in each land network domain that requires connectivity through the satellite with another land network domain.

The objective of the proposed system is to provide a solution in real-time communications, including multivideoconferencing, in satellite networks. So that users located in this type of networks can enjoy these services with the same quality guarantees as users located in terrestrial networks (Internet).

DESCRIPTION OF THE DRAWINGS

By way of illustration, a series of figures are attached where the operation and the elements that make up an OBP Multivideoconference are detailed.

Figure 1 shows a typical OBP Multivideconference scenario in different telecommunications networks such as Internet 18, a LAN 20 or ISDN / PSTN 19. The main elements involved in said multivideoconference are indicated: geostationary satellite 10 multibeam with OBP capability , user terminals 11 (hardware or software), multicast traffic servers, MCU 12, network control center, CCR 22, Proxy server 15.

Figure 2 summarizes how the MCUs 12 collect the unicast traffic generated by terminals 11 and transform it into multicast.

Figure 3 details this process of multiplexing the multimedia data streams carried out in the MCUs 12.

Figure 4 shows the process for establishing a multi-conference call using a single satellite jump.

PREFERRED EMBODIMENT OF THE INVENTION

The OBP Multivideconference consists of several elements mentioned above: multi-beam geostationary satellite with OBP 10 capability, videoconferencing clients 11, MCUs 12, Proxy 15 servers for voice and video over IP (for example, SIP Proxy with the SIP protocol or gatekeeper with H. 323), as well as a network control center 22.

The description of an OBP Multivideoconference is detailed as follows:

one.

Before a user 11 can make a videoconference for the first time, a registration process is recommended in which the user obtains a valid unique identifier (for example, a telephone number) and / or some type of credentials. This registration is done in what has been called Proxy 15 server. This is also applicable to MCUs 12 (since in the face of Proxies, MCUs will also be treated as users).

2.

When one or more users want to make a videoconference, there are 2 options:

to.

Simple videoconferencing: When a call is established between 2 users only. Before starting the videoconference, the connection between both users is negotiated. Once accepted, the videoconference is done point to point (the point-to-point case is outside the object of the invention).

b.

Multiple videoconferencing (Multi-conference): When a call is established between 3 or more users. The host must create, through MCU 12, a virtual videoconference room, an application that allows simultaneous reception of both audio and video of all videoconference participants. This room can be created and managed through a Web interface. Users 11 will join the videoconference through the MCU 12 located in their area (Fig. 1). Although there are physically N MCUs, all MCUs work as one due to their distributed configuration capabilities that allow the creation of a “virtual MCU”, so there are no difficulties for users. Said MCUs 12 will be responsible for managing the information between them.

3.

The protocol or type of messages exchanged for this establishment and multimedia exchange can be any, the most common being SIP (Session Initiation Protocol) or H.323 for the establishment, and RTP (Real Time Protocol) for multimedia traffic.

Considering that the system has a main MCU for each of the satellite beams, said MCU will act as a meeting point (PE), that is, in charge of processing all the multimedia flows of users served by said satellite beam.

Each of the satellite beams has a main MCU (Haz1 31 with MCU1 12a; Haz2 32 with MCU2 12b; Haz3 33 with MCU3 12c), which acts as a meeting point.

The process for establishing a multi-conference call using a single satellite jump can be implemented as follows (see Fig. 4):

1. Establishment of a new session or connection capable of supporting multi-conference communications:

C.

 Source (S, Source) 1 23 generates a new session by registering it at a meeting point (PE) 12a [1F].

d.

PE 12a informs [2F], [3F] to CCR 22, so that the CCR adds a new entry in the satellite routing table, including the address of the multicast group, as well as the source beam 31 in which it is located located PE 12a [4F], and indicates to source (S) 23 the result of the process [5F], [6F].

2. Inclusion of a new receiver:

to.

Receiver 24b (R, Receiver) sends a request to PE 12b [7F].

b.

If the invoked multicast group has already been requested by other receivers (R’s) belonging to the same domain, PE 12b does not have to act on satellite 10, directly connecting the multicast distribution tree with the corresponding MCU.

C.

If the multicast group is new to PE 12b, it will have to communicate it to CCR 22 in order to introduce it into the column of receiving beams 32 in the satellite routing table [8F] [3F] [4F] [9F] [ 10F]. This table will be of the form:

Multicast Group Management

Make Source Beam Receiver

IP Address 1

Do1 31 Do2 32

3. Inclusion of a new source (S):

10 a. Both a receiver (R) that wishes to send information and a new source (S) that wants to join a multicast group must first authenticate before registering with the local PE.

b. The PE stores the information of the source (S) including its IP address as well as the multicast group you wish to join.

4. Elimination of a receiver (R):

15 a. When a receiver (R) 24b wishes to leave a multicast group, he must notify PE 12b [7F].

b.

The PE 12b checks if after the removal of this receiver (R) 24b active receptors (R’s) 24b still remain.

C.

If no other receiver (R) 24b is active, PE 12b informs CCR 22 in order to

20 delete the corresponding beam 32 in the satellite routing table [8F], [3F], [4F], [9F], [10F].

d. If, on the contrary, there are still active 24b (R’s) receivers, PE 12b will not act on the satellite.

5. Elimination of a source (S): 25 a. Source 23 (S) indicates to PE 12a its intention to leave the multicast group [1F].

b.

The EP 12a checks if after the elimination of this source 23 (S) other sources 23 (S’s) still remain active in that beam 31.

C.

If there is no other active source (S) 23, PE 12a informs CCR 22 in order to eliminate its beam 31 in the satellite routing table [2F], [3F], [4F], [5F], [ 6F].

30 d. If there is no other beam in the multicast group, the CCR 22 proceeds to remove the group from the satellite routing table [4F], [3F].

and. If there are other sources (S’s) in beam 31 then PE 12a does not act on the satellite.

Claims (6)

1. Multivideoconferencing system comprising:

-

 a plurality of multivideoconference nodes (12,12a, 12b, 12c) of different networks (18,19,20), with each node configured to individually receive (unicast) data streams from a plurality of terminals (23,24,24b, 24c) of the user of the same network, where each node is also configured to collectively send (multicast) and collectively receive (multicast) data streams from a plurality of nodes (12,12a, 12b, 12c) of different networks through of a multi-beam satellite (10) with a routing table, characterized in that it also includes:

-

 a network control center (22) configured to manage the satellite routing table by updating the addresses of the plurality of the conference nodes (12,12a, 12b, 12c) existing in each conference call session and to associate the beam ( 31,32,33) that corresponds to each one.

2.

 System according to claim 1, characterized in that the control center (22) is configured to modify the routing table so that the source and receiver beams (31,32,33) are associated with the different user terminals (23,24 , 24b, 24c) of each multi-conference session.

3.

 System according to claim 1 or 2, characterized in that the control center (22) is configured to modify the routing table so that the source and receiver beams (31,32,33) are associated with the different multivideoconference nodes (12, 12a, 12b, 12c) of each multi-conference session.

Four.

 System according to claim 1 or 2, characterized in that it implements a communications protocol selectable at least between:

-

SIP (Session Initiation Protocol),

-

H.323 for establishment,

-

 RTP (Real Time Protocol).

System according to any one of the preceding claims, characterized in that the multivideoconference node (12,12a, 12b, 12c) has a multivideoconference session administration interface. SPANISH OFFICE OF THE PATENTS AND BRAND Application no .: 201230518 SPAIN Date of submission of the application: 04.04.2012 Priority Date: REPORT ON THE STATE OF THE TECHNIQUE 51 Int. Cl.: H04N7 / 15 (2006.01) H04B7 / 185 (2006.01) RELEVANT DOCUMENTS

Category

56 Documents cited Claims Affected

Y

LIANG et al. "Multimedia Conference over Satellite". Proceedings of the 21st AIAA International Communication Satellite Systems Conference and Exhibit. April 2003. Document retrieved from the internet [Recovered on 13.07.2012] <http://www.ee.surrey.ac.uk/CCSR/output/projects/satlife/docs/papers/icebergs1_aiaa21_2003.pdf>. Whole document. 1-5

Y

US 2008 216 266 A1 (AGARWAL ANIL et al.) 11.09.2008, figures 17A-18; paragraphs [0002-0007], [0029-0043], [0122-0134], [0140]. 1-5

TO

WO 9967953 A1 (HC et al.) 29.12.1999, summary. 1-5

Category of the documents cited X: of particular relevance Y: of particular relevance combined with other / s of the same category A: reflects the state of the art O: refers to unwritten disclosure P: published between the priority date and the date of priority submission of the application E: previous document, but published after the date of submission of the application

This report has been prepared • for all claims • for claims no:

Date of realization of the report 13.07.2012

Examiner M. Rivas Sáiz Page 1/4

REPORT OF THE STATE OF THE TECHNIQUE Application number: 201230518 Minimum documentation sought (classification system followed by classification symbols) H04N, H04B Electronic databases consulted during the search (database name and, if possible, search terms used) INVENES, EPODOC State of the Art Report Page 2/4  WRITTEN OPINION Application number: 201230518 Date of Written Opinion: 13.07.2012 Statement

Novelty (Art. 6.1 LP 11/1986)

Claims Claims 1-5 IF NOT

Inventive activity (Art. 8.1 LP11 / 1986)

Claims Claims 1-5 IF NOT

The application is considered to comply with the industrial application requirement. This requirement was evaluated during the formal and technical examination phase of the application (Article 31.2 Law 11/1986).  Opinion Base.- This opinion has been made on the basis of the patent application as published. State of the Art Report Page 3/4  WRITTEN OPINION Application number: 201230518  1. Documents considered.- The documents belonging to the state of the art taken into consideration for the realization of this opinion are listed below.

Document

Publication or Identification Number publication date

D01

LIANG et al. "Multimedia Conference over Satellite". Proceedings of the 21st AIAA International Communication Satellite Systems Conference and Exhibit. April 2003. Document retrieved from the internet [Recovered on 13.07.2012] <http://www.ee.surrey.ac.uk/CCSR/output/projects/satlife/docs/papers/icebergs1_aiaa21_2003.pdf>. Whole document.

D02

US 2008 216 266 A1 (AGARWAL ANIL et al.) 11.09.2008

 2. Statement motivated according to articles 29.6 and 29.7 of the Regulations for the execution of Law 11/1986, of March 20, on Patents on novelty and inventive activity; quotes and explanations in support of this statement Document D01 is considered the closest in the state of the art to the requested invention. With regard to claim 1, D01 describes a multivideoconferencing system comprising (see "System Architecture"):

-

a plurality of multivideoconference nodes (MCU figures 1 and 2) of different networks, with each node configured to individually receive (unicast) data streams from a plurality of user terminals (EU figure 1) of the same network, where in addition each node It is configured to collectively send (multicast) and to collectively receive (multicast) data streams from a plurality of nodes (MCU Figures 1 and 2) of different networks through a multibeam satellite with a routing table (this last element is implicit on the satellite), characterized in that it also includes: -a network control center (NOC figure 1) that configures the satellite.

The difference between D01 and claim 1 is that D01 does not indicate that the control center is configured to manage the satellite routing table by updating the addresses of the plurality of the conference nodes existing in each conference call session and to associate the one that corresponds to each one. The technical effect of this difference is to intelligently direct multicast traffic only to terrestrial nodes that give access to the participants of the multivideo conference and as a consequence reduce the bandwidth used in the multicast distribution tree. The technical problem is how to reduce the bandwidth used in the multicast distribution tree. Document D02 describes a satellite routing system with OBP capability, in this document the control center updates the satellite routing tables and sends them to the satellite so that the satellite routes the information to the corresponding beam for transmission to the user terminal . (Figures 17a and 18, paragraph 0036, 0038, 0039, 0043, 0140). In view of the foregoing, a person skilled in the art would combine the system described in D01 with the routing system of D02 to obtain claim 1 without making use of the inventive activity. Therefore, it is concluded that claim 1 does not imply inventive activity (Article 8 LP.). Claims 2 and 3 propose two different alternatives, modifying the routing table to associate the beams with the different user terminals or the different conference nodes. The first one is described in D02 and the second one is a design alternative taking into account that to the D02 terminals, as indicated in paragraph 0043, one more switching devices are connected. Therefore, claims 2 and 3 do not imply inventive activity (Article 8 LP.). The same applies to claim 4 described in D01 where the SIP protocol is used and therefore does not meet the requirement of inventive activity (Article 8 LP.). Claim 5 is implicit in D01 since, since the D01 MCU devices manage the multivideo conference, the existence of a multivideo conference session management interface is implied. Therefore claim 5 does not imply inventive activity (Article 8 LP.). State of the Art Report Page 4/4