Method for managing two-way alternate communication in semi-duplex mode through a packet switching transport network

METHOD OF ALTERNATE MANAGEMENT FOR SEMI-DUPLEX MODE COMMUNICATION THROUGH A TRANSPORT NETWORK

PACKET SWITCHING

The present invention relates to a method for managing a group communication in half-duplex mode between different end devices of a packet-switched network.

It relates to the field of packet-switched transport networks in non-connected mode, in particular IP (Internet Protocol) networks.

It finds applications, particularly in radiocommunication systems, especially private radio systems such as those intended for police or firefighters. These systems have a particular mode of communication, called semi-duplex mode, which has long since disappeared from public systems (public switched telephone network, or public radio systems such as GSM). In the half-duplex mode, a mobile station can send or receive, but can not do both of these operations at once. In addition, a single mobile station must be authorized to transmit at a given time, the data stream transmitted by this mobile station being retransmitted to the mobile station (s) participating in the call (also called call or "call"). call "in English)

A particular network equipment, called central equipment in the following, arbitrates in the event of a conflict between requests for the right to transmit to it from different mobile stations via corresponding base stations. This arbitration is based on a priority level and / or the identity of the mobile stations. The central equipment notifies to the different mobile stations the result of this arbitration, that is to say it indicates which is the mobile station to which the right of emission has been granted. It must also, if necessary, notify the other mobile stations of the end of the current alternation, ie the cessation of transmission by the mobile station which had previously obtained the right to transmit , so that these other mobile stations can in turn request the right to broadcast. It must still, if necessary, allow the preemption of alternates by a mobile station having a priority higher than that which has the right to emit for the current alternation.

The significant development of packet-switched transport networks in non-connected mode makes it possible to consider the management of communication between at least two base stations of a radio communication system, considered as end-of-pipe equipment. such a network.

In particular, it is possible to use the mechanisms of multimedia conferences defined in the context of Internet protocols, ie protocols for networks operating according to the IP protocol (J. Postel, "Internet Protocol", RFC 791, IETF, September 1981) which has been standardized by the Internet Engineering Task Force (IETF) in the Request for Comment (RFC) above. These multimedia conferences are based on the implementation of Multimedia Conferencing Unit (MCU), and offer an advantageous support for the realization of many types of telephony and videogaming services. voice, for example. However,

The object of this invention is to propose an adaptation of the protocols implemented in the packet-switched transport networks in non-connected mode, allowing the management of the half-duplex communications for half-duplex act as individual communications or group communications.

This goal is achieved by an alternate management method for half-duplex communication between at least two end devices of an unconnected mode packet-switched transport network, wherein indication, when present with a first determined value in packets transmitted from one of said end equipment to a central equipment providing the management of the communication, to indicate to said central equipment, on the one hand, that said end equipment acknowledges the right to broadcast granted to it by said central equipment and that it requests the maintenance of this right to broadcast. This indication element may furthermore have the function, when

When the non-connected mode packet-switched transport network is an IP network, the central equipment may be an MCU, and the frames transmitted over the network may be RTP (Real Time Transport Protocol) packets. , see H. Schulzrinne, "RTP: a Transport Protocol for Real-Time Applications", RFC 1889, IETF, January 1996), the communication then being established as a RTP / RTCP (Real TimeTransport Control Protocol) session. ").

According to an advantageous characteristic of the invention, the indication element can then be the marking bit M of the header of the RTP packets, said first value of the indication element being the logical value 1 or 0, and said second value of the indicating element being the logical value 0 or 1, respectively.

The invention also proposes an application of the above method to a radiocommunications system, in particular a private system of professional radiocommunications. The method then allows the management of the alternation for individual communications or group communications between mobile stations when at least some of the end equipment of the packet-switched transport network are also base stations of said radio system .

The invention also proposes a radio communication system, in particular a private professional radiocommunications system, comprising base stations and network equipment connected by an unconnected mode packet-switched transport network, in which said base stations comprise means for implementing the method as end equipment of the network and wherein said network equipment comprises means for implementing the method as a central equipment.

The invention further provides a base station for use as end equipment in a system as defined above. The invention finally proposes multimedia videoconferencing equipment intended to be used as central equipment in a system as defined above.

Other features and advantages of the invention will become apparent on reading the description which follows. This is purely illustrative and should be read in conjunction with the accompanying drawings which show:

in FIG. 1: the diagram of a radio communication system according to the invention;

in FIG. 2: a diagram presenting a protocol for establishing an individual communication involving two base stations of a system according to FIG. 1;

in FIG. 3: a diagram illustrating the topology of a RTP / RTCP session in the case of an individual communication;

FIG. 4 is a diagram showing a protocol for establishing a group communication involving three base stations of a system according to FIG. 1;

in FIG. 5: a diagram illustrating the topology of an RTP / RTCP session in the case of group communication;

in FIG. 6: a diagram illustrating the format of the header of an RTP packet; in FIG. 7: a diagram illustrating the format of the payload of an RTP packet;

in FIG. 8: a flowchart illustrating steps of the operating method of a base station comprising means for implementing the method according to the invention as end equipment; FIG. 9 is a flowchart illustrating steps in the operation of a multimedia videoconferencing equipment (MCU) for implementing the method according to the invention as a central piece of equipment; and, in FIG. 10: a diagram illustrating the topology of an RTP / RTCP session in the case of a group communication involving several levels of MCU.

In Figure 1, there is shown schematically a radio system according to the invention.

In the example shown, mobile stations 101, 102 and 103 are in the base station coverage area respectively 201, 202 and 203. It is recalled that the base stations are fixed equipment of the radio subsystem of the radio system. radiocommunications, which provide the interface. radio with mobile stations.

The base stations are connected to an unconnected packet-switched transport network 300, such as an IP network. In other words, the base stations 201, 202 and 203 are also end devices of an IP network. Packet switching is provided by routers 301, 302 and 303.

A network equipment 400 is connected to the network 300. It is preferably an MCU, the usual function of which is to group or switch several streams of real-time data (for example, a data stream for the voice and / or a data stream for the video) to constitute a stream distributed to several receivers, performing a multimedia conference configuration.

A call server 500 is also connected to the network 300. This equipment analyzes calls and establishes multimedia communications on the network 300. It cooperates with a location database 600, which is also connected to the network 300, and which contains information indicating, among others, the cell under the cover of which is the called mobile station, thus allowing a correct routing of calls.

Other equipment than those shown in Figure 1 may of course be part of the radio system. Since these devices do not participate in the mechanisms of the method according to the invention, it is not useful to describe them here. In addition, the different equipment (base stations, MCU, call server, etc.), although represented here as separate physical entities for the sake of clarity, can be duplicated, joined or various ways without departing from the scope of the invention.

The diagram of FIG. 2 presents a procedure for the establishment of an individual communication between the mobile station 101 and the mobile station 102 (here on the initiative of the mobile station 101), which uses an application layer signaling protocol. such as the SIP protocol (M. Handley et al., "SIP: Session Initiation Protocol", RFC 2543, IETF, March 1999).

SIP addresses are similar to e-mail addresses, that is, they are of the form "user @ host", where the "user" field designates for example a user name or a number of phone, and where the field "host" for example a domain name or an address in digital form. The SIP protocol provides methods, including methods called INVITE and ACK, used to initiate a call session between two SIP users. Responses to messages issued as part of these methods are defined by code classes.

Thus, at the request of the mobile station 101, the base station 201 generates an invitation message INVITE addressed to the call server 500. This INVITE message mentions as recipient the mobile station 102, whose SIP address is for example " mob102 @ home ", where" mob102 "is the user name of the mobile station 102 and where" home "is the address of a home location register called HLR (Home Location Register) which houses the 600 location database.

In the example shown, the call server 500 responds, after consulting the location database 600, with a message indicating a code "302" which means that the mobile station is momentarily under the cover of another station basic (code 302 means "Moved temporarely"). This message also indicates in a "Contact" field the address of the MCU processing the communication (here the MCU designated by the address "MCU400") and, in an "AIso" field, the SIP address of the mobile station 102 under the coverage of the base station 202 (whose address is "st202" in the example). The base station 101, in accordance with the SIP protocol, repeats its INVITE message by addressing it this time to the MCU 400, and further mentioning in the "AIso" field the

When the mobile station 102 has gone off-hook, the base station 202 transmits as response to the MCU a validation message (code "200 OK") which is acknowledged by the MCU 400 by means of an acknowledgment message ACK.

The MCU 400 then transmits to the base station 201 a validation message "200 OK", which is acknowledged by an acknowledgment message ACK. The communication is then established, for example in the form of a RTP / RTCP session, and the conversation can then begin. FIG. 3 gives the topology of the RTP / RTCP session for the individual communication initialized according to the procedure described above with reference to FIG. 2. The RTP packets 10 received by the MCU 400 of the base station 201 are retransmitted to the base stations 201 and 202, after eventual processing, in the form of RTP packets 11 and 12. In addition, RTCP packets (not shown) are transmitted in response to the transmission of RTP packets to provide service control. transport.

Establishing a group call between more than two mobile stations can naturally be based on an adaptation of the SIP protocol. The initialization of a group communication between the mobile stations 101, 102 and 103, which are under the coverage of the base stations 201, 202 and 203 respectively, is illustrated by the diagram of FIG. 4. The RTP / RTCP session is here established at the initiative of the mobile station 101.

In such a case, several "AIso" fields, followed by the respective SIP addresses of all the mobile stations part of the group communication processed by the MCU 400 (here the addresses "mob102 @ st202" and "mob103 @ st203" of the mobile stations 102 and 103 respectively, are included in the INVITE messages transmitted by the base station 201 to the call server 500 or the MCU 400. The MCU 400 then transmits an INVITE message to each of the other base stations 202 and 203 which are party to the group communication.

In this case, furthermore, each of the INVITE messages further comprises, in the body of the message, a description of the RTP / RTCP session according to the SDP protocol (M. Handley et al., "SDP: Session Description Protocol", RFC 2327, IETF, April 1998). This description is for example denoted "Ses1" in the diagram of FIG. 4. The use of this description allows the exchange of information between the devices participating in the group communication, on the choice of the UDP ports, it is ie the ports of the equipment used by the UDP protocol (J. Postel, "User Datagram Protocol", RFC 768, IETF, August 1980), which must be used for the establishment of RTP / RTCP sessions, as well as on the nature of the profile of the data exchanged during the session (audio or video, type of coding, frequency of sampling, etc.). It will be noted that in the "AIso" field of the response message transmitted by the call server 500 to the base station

201 having sent the first INVITE message, the call server 500 may also propose an identifier of the mobile stations corresponding, for example, to a temporary number acquired during registration.

In FIG. 5, the topology of the RTP / RTCP session for the initialized group communication is represented according to the procedure described above with regard to the diagram of FIG. 4. The RTP packets received by the MCU

400 of the base station 201, are retransmitted to the base stations 201,

202 and 203, after a possible treatment, in the form of RTP packets 11, 12 and 13 respectively. For the sake of clarity, the RTCP packets that are transmitted in response to the transmission of the RTP packets are not represented.

The conventional audio profiles defined in RFC 1889 mentioned above, do not allow to deal with certain particular operations of private professional radiocommunications systems, such as the management of half-duplex communications. This is why the invention proposes an adaptation of RTP allowing the management of the half-duplex in a half-duplex, individual or group communication.

As shown in the diagrams of FIG. 3 and FIG. 5, the RTP packets comprise a header HD, and a PL data body containing the payload ("payload" in English), i.e. say the audio or video data itself.

The diagram in Figure 6 represents the header format of a packet according to the RTP protocol (see RFC 1889, mentioned above). This header includes the following fields:

a field V ("Version"), whose length is equal to 2 bits, which contains a version number of the protocol (V = 2 in the case represented);

a P bit ("Padding"), which indicates, when it has the logic value 1, the presence of additional bytes at the end of the RTP packet. These additional bytes make it possible to obtain a length having certain characteristics, for example for cryptographic purposes;

a bit X ("Extension"), which indicates when it has the logical value 1, the presence of an extension header;

a CSRC ("CSRC Count") field, of a length equal to 4 bits, the value of which defines the number of CSRC type identifiers ("Contributing Source"

Identifiers ", see below) following the fixed heading.

a bit M ("Marker"), which is a marking bit defined by the profile, that is to say that it can be used according to the needs of the application;

- a Payload Type (PT) field, of a length equal to 7 bits, which identifies the type of the payload (audio or video). This field contains a value that is either a number registered with the Internet Assigned Numbers Authority (IANA), or a dynamically selected number in a list of usable values, the meaning of which can be chosen by devices that are parties to Communication. a sequence number ("Sequence Number"), whose length is equal to 16 bits, which is initialized with a random value at the beginning of the transmission of a RTP packet stream by an end device, and which is incremented by one for each packet sent. This number allows the other or other equipment to

a time stamp ("Timestamp"), whose length is equal to 32 bits, and which dates the generation time of the payload of each of the packets. This stamp thus allows the end equipment to calculate the fluctuations of the transport time in the network and thus to provide the buffers necessary to guarantee an optimal quality of service. The time stamp is obtained from a clock whose resolution is sufficient to allow synchronization and calculation of jitter ("Jitter" in English). The initial value of the time stamp is determined randomly, as for the sequence number;

- Synchronization Source Identifier (SSRC), 32 bits long, which indicates the source of RTP packet synchronization. This source can be the end device that generates the RTP packet, but it can also be an intermediate device of the network called mixing entity (or "mixer", in English), which creates a new RTP packet stream from RTP packets received from the actual sources, after changing the synchronization. In the latter case, the SSRC identifier designates the mixing entity;

- a variable length field, containing a list of CSRC contributory source identifiers, each coded on 32 bits, and whose number is indicated in the CC field mentioned above (there may be between 0 and 15 such codes in the listing). These contributing sources are the end devices that generate the payload of the RTP packet. The CSRC codes are inserted by the mixing equipment, from the SSRC codes of the contributing sources.

The first 12 bytes are present in all RTP packets, while the list of CSRC identifiers is only present if it is inserted by one or more mixing entities.

For a payload consisting of data encoding the voice, the payload format of an RTP packet is in accordance with the diagram of FIG. 7. The payload data of the RTP packet correspond to the following fields: an NF field ( Number of Frames "), coded on 2 bits, which contains a value from which is determined the number of speech frames that are contained in the RTP packet; a bit C (Encrypted), which is set to logic value 1 when encryption information (including an algorithm identifier and a key identifier, see below) is contained in the RTP packet;

- a bit P ("Protected"), which indicates that the frames are protected; an E bit ("Emergency"), which, when set to logical value 1, makes it possible to ensure specific processing at the end equipment that receives the RTP packet;

a PRIO field ("Priority"), the length of which is equal to 3 bits, which indicates a priority level associated with the voice frames contained in the RTP packet;

a source address ("Source Address"), encoded on 24 bits, which identifies the source address of the user (ie here the mobile station) which transmits the voice frames contained in the RTP packet, being observed that the CSRC contributive source code identifies the end device (i.e., the base station) that generates the RTP packet and not this user;

a field containing, if necessary, the voice frames contained in the RTP packet ("encoded Frames"). The number of these frames depends on the value of the NF field (see above). The length of this field is equal to 88 bits (11 bytes). Each frame is aligned with padding bits set to the logical value 0, if necessary. In addition, the entire field is aligned with fill bits, if necessary. In an example where the speech frames are coded on 11 bytes, the total length of the field is equal to 0 bytes if NF = 0, to 12 bytes if NF = 1 (with a padding byte), to 24 bytes if NF = 2 (with two padding bytes), or 36 bytes if NF = 3 (with three padding bytes);

- if applicable, an algorithm identifier ("Algorithm ID"), coded on 8 bits, which identifies the encryption algorithm implemented for data encryption; and,

- if applicable, a 24-bit encrypted key identifier ("Key ID") that contains the value of an encryption key used by the encryption algorithm.

It should be noted that the algorithm identifier and the key identifier are contained in the RTP packet only if the C bit has the logic value 1. Moreover, other fields than those described above can be contained in the RTP packet. These fields providing nothing to the understanding of the invention, they are not shown in Figure 7, nor explained in this description. As has been understood, RTP packets can be transmitted without payload, when the value contained in the NF field is zero (NF = 0). These are called "empty" packets because they do not contain any voice frames.

The method according to the invention will now be described with reference to the flow charts of FIGS. 8 and 9, in the case of a group communication between three mobile stations.

Recall that according to the invention, the base stations are both equipment of the radio subsystem of the radio system (which provide the radio interface with the mobile stations), and end equipment of the transport network. 300, which transmit and receive RTP packets.

For this purpose, consider the configuration shown in Figure 1, where the mobile station 101 is under the coverage of the base station 201, the mobile station 102 is under the coverage of the base station 202 and the mobile station 103 under the coverage of the base station 203.

In addition, assume that the mobile stations 101, 102 and 103 are party to a half-duplex group call, established according to the SIP session initialization protocol illustrated by the diagram of Figure 4. More particularly, let's assume example that the mobile station 101 has the right to transmit for the current half-way and is in the process of transmitting. The voice frames transmitted by the mobile station 101 on the radio channel are picked up by the base station 201. From there, they are transmitted to the MCU 400, through the IP network, in RTP packets. The MCU transmits these RTP packets to the base stations 201, 202, and 203. These RTP packets contain the CSRC code of the base station 201, which is the source selected by the MCU to control the current alternate. The base stations 202 and 203 transmit them in turn, via respective radio channels, to the mobile stations respectively 102 and 103. The MCU 400, as a central equipment, arbitrates in case of conflict between requests for the right to transmit from different mobile stations through the corresponding base stations, and notify the different base stations of the result of this arbitration. It must also be able to warn without delay the mobile stations in the reception phase of the end of the current alternation, which corresponds to the cessation of the transmission of speech frames by the mobile station which had been granted the right to transmit for the alternation in progress. In this way, these mobile stations in the reception phase have the possibility to request the right to transmit; To do this, the invention proposes that an indication element, included in the RTP packets, fulfill a certain number of functions for managing the alternation.

In one example, the indication element may have the function, in combination with the CSRC code, of indicating to the base station selected by the MCU that the right to transmit has been granted. In one example, the indication element has this function when it is present, with a first determined value, in the RTP packets transmitted by the MCU to the base stations 201, 202 and 203.

In addition, according to the invention, the indication element also has the function, when it is present with a second determined value, in the RTP frames transmitted to the MCU from the base station having the right to transmit, (ie, the one whose CSRC code is indicated in the RTP packets transmitted by the MCU) to indicate to the MCU, on the one hand, that said base station acknowledges the right of transmission which has been granted by the MCU, and on the other hand that it requests the maintenance of this right to emit.

In addition, the indication element also functions when it is present, with a third determined value, in a RTP packet transmitted by the MCU to the base stations, to indicate to the base stations that they can ask for the right to broadcast. Which of them will be selected by the MCU, will then take control of the next alternation.

Preferably, the indication element is finally operative, when it is present with a fourth value determined in an empty RTP packet which is transmitted to the MCU from the base station having the right to transmit, to indicate at the MCU that said base station waives its right to transmit. This occurs when the current alternation is over, that is, when the mobile station which has been granted the right to transmit for the current half-time, stops transmitting speech frames. These functions of the indication element will appear more clearly on reading an exemplary embodiment of the invention which follows. In one example, the first and second determined values ​​of the indication element are identical. Similarly,

Concretely, the indication element can be a field of any length, which encodes the determined values ​​mentioned above. In a preferred embodiment, this indication element may advantageously be reduced to one bit, since it has two distinct functions when it is present in a RTP packet transmitted to the base stations from the MCU (depending on its value among said first and said third different determined values), and two distinct functions when present in a RTP packet transmitted from a base station to the MCU (again depending on its value among said second and said third values). determined differently).

In a preferred embodiment, it is proposed to use for this purpose the bit M of the header of the RTP packets in relation to the fundamental mechanisms of operation of the MCU as a mixing entity RTP. Said first value and said second value of the indication element are then, for example, the logic value 1, while said third and fourth determined values ​​are the logical value 0.

The flowchart of FIG. 8 illustrates the operation of a base station as end equipment according to the invention. The example of the base station 201 is more particularly considered. Suppose that, in a step 301, the mobile station 101 expresses its intention to transmit by appropriate signaling to the base station 201. In practice, this occurs when the the user of the mobile station 101 presses the PTT button (of the English "Push-To-Talk") and speaks in the microphone of the mobile station.

If the base station 201 is already receiving from the MCU, through the IP network, RTP packets with M = 1 (which means that the right to transmit is already granted by the MCU to another base station which transmits packets RTP which are those retransmitted by the MCU with M = 1), and if the priority associated with the current alternation is not lower than the priority associated with the request of the mobile station 201, then, in a step 302, it infers that the right to transmit must be denied to the mobile station 101. In other words, the base station 201 decides that the mobile station 101 can not take control of the alternating. In a step 303, the base station 201 then notifies the mobile station 101 that the right to broadcast is denied. In practice, this is indicated to the user by the extinction of an indicator light of the mobile station 101 which had been turned on in step 301. The base station 201 continues to transmit on the air interface the speech frames received in the packets received from the MCU and the mobile station 101 remains in reception phase. It will be noted that the priority associated with the request of the mobile station 101 can be transmitted by the aforementioned signaling or be calculated by the base station 201 according to an ad-hoc method. In addition, the priority associated with the current half cycle is indicated in the RTP packets received by the base station 201 (in the aforementioned PRIO field). the voice frames received in the packets received from the MCU and the mobile station 101 remains in reception phase. It will be noted that the priority associated with the request of the mobile station 101 can be transmitted by the aforementioned signaling or be calculated by the base station 201 according to an ad-hoc method. In addition, the priority associated with the current half cycle is indicated in the RTP packets received by the base station 201 (in the aforementioned PRIO field). the voice frames received in the packets received from the MCU and the mobile station 101 remains in reception phase. It will be noted that the priority associated with the request of the mobile station 101 can be transmitted by the aforementioned signaling or be calculated by the base station 201 according to an ad-hoc method. In addition, the priority associated with the current half cycle is indicated in the RTP packets received by the base station 201 (in the aforementioned PRIO field).

If this is not the case, either the base station 201 receives no RTP packet from the MCU, or the priority associated with the request of the mobile station 101 is greater than that associated with the current half-board, then, in step 302, the base station 201 deduces that it can grant (at least temporarily) the right to transmit to the mobile station 101 which has begun transmitting speech frames. The base station 201 therefore begins, in a step 304, to send RTP packets containing these speech frames, with a bit M equal to the logic value 0 (M = 0). This value serves to indicate to the MCU that the base station 201 requests the right to transmit. From there, base station 201 begins (or continues to receive) RTP packets with M = 1. As mentioned above,

If the identifier CSRC is different from the identifier of the base station 201, it deduces, in a step 305, that it has not been selected by the MCU, that is to say that the right it was not granted by the MCU, or, in other words, that the alternate control was granted by the MCU to another base station. In this case, in a step 306, it interrupts the transmission of RTP packets to the MCU and notifies the base station 101 that it is not allowed to transmit. Step 306 is equivalent to the aforementioned step 303.

If, conversely, the CSRC identifier of the RTP packets transmitted by the MCU is that of the base station 201, the latter deduces, at the step 305, that it can continue the transmission towards the MCU of the RTP packets containing the voice frames transmitted by the mobile station 101 on the radio channel. However, in a step 307, it now transmits these RTP packets with the bit M set to logic value 1 (M = 1), so as to indicate to the MCU that it acknowledges receipt of the right to transmit which has been granted to it. by the MCU, and to indicate that it requests the maintenance of this right to issue.

At any time, the mobile station 101 can stop transmitting speech frames on the radio channel connecting it to the base station 201, if the user releases the PTT button. This event is monitored by the base station 201 in a step 308. If the mobile station 101 continues to transmit speech frames, RTP packets containing these frames are generated by the base station 201 and transmitted to the MCU. The process is continued by repeating step 305 above. If, on the other hand, the mobile station stops transmitting speech frames, then, in a step 309, the base station transmits, to the MCU, the last RTP packets with the bit M set to the logical value 0 . These latter packets contain the last speech frames transmitted by the mobile station 101 (and timed by passing through a buffer of the base station). The bit M with the logic value 0 then serves to indicate to the MCU that the base station 201 waives its right to transmit. In this way, the MCU is informed of the impending termination of the transmission of RTP packets by the base station 201 even before these packets are issued. The MCU, as will appear later with reference to FIG. 9, can then alert the other base stations by transmitting these last RTP packets with the bit M set to the logical value 0 to indicate that the end of the alternation is near, and that it will soon be able to ask (and, for one of them, obtain) the right to

Finally, when the base station 201 has sent the last speech frames in RTP packets with the bit M set to zero (step 309), it transmits, in a step 310, a number (for example three) of RTP packets. empty, that is to say without payload, and whose bit M is at logic value 0. It emits several such packets to minimize the risk of non-reception by the MCU, which can occur if the network loses packets due to overloading routers. It is recalled that empty packets are characterized by a NF field containing the value zero. These empty packets have the function of actually signaling the end of the current alternation. They allow the MCU not to confuse the end of the current alternation with a request for the right to issue which would come from another mobile station lying under the cover of the same base station 201 as the mobile station 101 which controls the alternating current. Indeed, such a request would also have the form of RTP packets containing speech frames (those transmitted by this other mobile station and received by the base station 201 via another radio channel), whose bit M would also have the logical value 0, and whose CSRC field would contain the same source identifier (that of the base station 201, which would be the same source view of the MCU).

The flowchart of Figure 9 illustrates the operation of the MCU as central equipment according to the invention.

The MCU is initially in a standby state 700, in which it does not receive any RTP packets (it is assumed that all participants in the group conversation are silent). Remember that when a base station requests the right to transmit, it transmits to the MCU RTP packets containing speech frames (non-empty packets) and with the M bit to the logical value 0 (M = 0). .

Suppose that at least one and perhaps several base stations (also called sources) issue such non-empty RTP packets with M = 0. When, in a step 701, the MCU receives these packets, it selects, in a step 702, one of the base stations according to an ad hoc selection algorithm. When a single source sends RTP packets, this algorithm selects that source. When multiple sources transmit RTP packets simultaneously, the selection algorithm may involve, for example, priority, issuer identity, or any other criteria.

Once the selection is made, the MCU, in a step 703, transmits to all the base stations participating in the group communication (i.e., in the example, the base stations 201, 202 and 203) the received RTP packets. of the selected base station (ie, in the example, the base station 201), after setting the M bit to the logical value 1 and placing its own identifier in the SSRC field and that of the source selected in the CSRC field (the value of the CC field of the RTP packet is then equal to

1). When, in a step 711, the MCU then receives a new packet

RTP, the MCU first checks, in a step 704, that this packet comes from the selected source. For this purpose the CSRC identifier of the packet is used.

If this is the case, then the MCU checks, in a step 705, whether the base station requests the maintenance of its right to transmit. This is the case if the RTP packet has an M bit with logical value 1. If so, this packet is transmitted as indicated above (return to step 703 above). If on the contrary the bit M has the logical value 0, then, in a step 706, the MCU checks whether it is an empty packet. If the packet is empty (that is to say if it does not contain any voice frame), it is because the source indicates the end of the alternation. Then, in a step 707, the last RTP packets (those remaining in the MCU buffer) are transmitted as indicated above (with reference to step 703 above) but with the M bit set to the value logical 0, in order to indicate to the base stations the end of the alternation. The MCU then returns to standby state 700. If instead the packet is not empty (i.e. it contains at least one voice frame), the RTP packet is transmitted with the bit M in logic state 1 (return to step 703). If, contrary to the assumption made above for the test of step 704, the RTP packet received at step 711 does not come from the selected source, two cases may occur. They are examined in a step 708. If the priority of the source of the received RTP packet is greater than that of the selected source, then, in a step 709, the source of the received RTP packet is selected as a new selected source. The received RTP packet is then transmitted, going back to step 703 with, in the CSRC field, the identifier of the new source selected. Otherwise, the packet is simply rejected in a step 710, and the MCU waits for the reception of a new packet (return to step 711).

Referring to FIG. 8, it can be seen that when, in step 709, the MCU selects a new source while a source is already transmitting RTP packets, the test of the step 305 is checked for the latter source, so that it stops transmitting to RTP packets on the IP network and stops the transmission of voice frames by the mobile station concerned.

It can also be seen that as soon as a base station receives RTP packets with bit M at logical value 0 (indicating the next end of the current half-cycle), it is ready to accept a transmission request from a station mobile because the test of step 302 will not be verified, so that in step 304, the base station will send RTP packets with the M bit set to logic 0.

The technique presented above thus makes it possible both to ensure an arbitration of the requests for alternation by the base stations, a preemption of the communication when the right to send is requested by a base station with a higher priority, and anticipating the end of the current alternation, in order to prepare the next half-turn as soon as the end of the current half-cycle is announced by the transmission by the selected base station of empty RTP packets with the bit M set to the logical value 0.

A variant of the technique presented above makes it possible to make the detection of the end of the current alternation faster without risk of false detection in the event of loss of RTP packets. The test of step 706 which reads "Empty package with M = 0? ", Can be replaced by the following test:" (Empty package with M = 0) or (package with M = 0, the three previous packages have not all been lost)? ". Thus, the MCU detects the end of the current alternation upon receipt of the first packet with the M bit set to the logical value 0 and the MCU can not confuse a start of alternation with the end of the current half-cycle. for, if the three empty packets with M = 0 emitted by the base station at the end of alternating were lost, a non-empty packet with M = 0 will not be considered as indicating the end of the current alternation. The terms "previous" and "first" employees above refer, of course, to the order of the RTP packets as indicated by the sequence number contained in the header of the RTP packets (see Figure 6). . As is not beyond the control of the person skilled in the art, the operation described by the flow charts of FIGS. 8 and 9 may require guard delays for the IP network equipment, namely the end equipment (base stations ) and the central equipment (MCU), are protected against link interruptions, whether these have a physical origin or come from a failure or overload of the routers. it is indicated by the sequence number contained in the header of the RTP packets (see Figure 6). As is not beyond the control of the person skilled in the art, the operation described by the flow charts of FIGS. 8 and 9 may require guard delays for the IP network equipment, namely the end equipment (base stations ) and the central equipment (MCU), are protected against link interruptions, whether these have a physical origin or come from a failure or overload of the routers. it is indicated by the sequence number contained in the header of the RTP packets (see Figure 6). As is not beyond the control of the person skilled in the art, the operation described by the flow charts of FIGS. 8 and 9 may require guard delays for the IP network equipment, namely the end equipment (base stations ) and the central equipment (MCU), are protected against link interruptions, whether these have a physical origin or come from a failure or overload of the routers.

The technique presented above can easily be extended to more complex multimedia conference topologies than that presented above by way of example, and in particular to a topology as represented in FIG. 10. In this topology, an MCU 801 (or MCU master) provides connection and arbitration alternates between sub-conferences managed by the MCUs 802 and 803 (or MCU slaves), the latter performing the arbitration of the alternat and the connecting the base stations respectively 804 to 806, and 807 to 809. Those skilled in the art perceive that the flowcharts of. The operation of the base stations and the master MCU are identical to those previously presented with reference to FIGS. 8 and 9 respectively, while the operation of the slave MCUs 802 or 803 is in accordance with FIG. Fig. 8 for their connection to master MCU 801, and Fig. 9 for links with base stations 804-806 or 807-809 respectively. Thus, to give a simple example, the slave MCU 802 transmits, at the beginning of the alternat, the RTP packets received from a base station such as 804 with the bit M at the logic value 0, leaving the bit M at the logical value 0 for the RTP packets transmitted to the master MCU, while the M bit is set to logic 1 for the RTP packets retransmitted to the various base stations 804 to 806 participating in the communication. and to that of Figure 9 for its links with base stations 804-806 or 807-809 respectively. Thus, to give a simple example, the slave MCU 802 transmits, at the beginning of the alternat, the RTP packets received from a base station such as 804 with the bit M at the logic value 0, leaving the bit M at the logical value 0 for the RTP packets transmitted to the master MCU, while the M bit is set to logic 1 for the RTP packets retransmitted to the various base stations 804 to 806 participating in the communication. and to that of Figure 9 for its links with base stations 804-806 or 807-809 respectively. Thus, to give a simple example, the slave MCU 802 transmits, at the beginning of the alternat, the RTP packets received from a base station such as 804 with the bit M at the logic value 0, leaving the bit M at the logical value 0 for the RTP packets transmitted to the master MCU, while the M bit is set to logic 1 for the RTP packets retransmitted to the various base stations 804 to 806 participating in the communication.

The invention has been described above in a preferred but non-limiting embodiment. Those skilled in the art will appreciate that alternative embodiments are possible without departing from the principle of the invention.

In particular, the respective logic values ​​of the marking bit M allocated to the various functions of this bit according to the invention can naturally be reversed. In addition, and particularly in the case where more functions must be assigned to this indication element, it is possible to replace the marking bit M with a word of several bits, or to associate it with one or more other bits. so that the indication element can have more than two distinct values.