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

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037

ALTERNATE MANAGEMENT PROCESS FOR A COMMUNICATION IN SEMI-DUPLEX MODE THROUGH A TRANSPORTA NETWORK SWITCHING PACKETS

The present invention relates to a method of managing 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 unconnected mode, in particular IP (Internet Protocol) networks.

It finds applications, in particular in radiocommunications systems, in particular private professional radiocommunications systems, such as those intended for the police or firefighters.

These systems have a particular mode of communication, called semiduplex mode, which has long since disappeared from public systems (public switched telephone network, or public radiocommunications systems such as GSM). In half-duplex mode, a mobile station can transmit or receive, but cannot do both of these operations at the same time. In addition, only one 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 communication (also called a call or " call ”in English), that is to say to the mobile station concerned if it is an individual communication or to all the mobile stations participating in the communication if it is a communication of group.

A particular network item of equipment, referred to as central equipment in the following, performs an arbitration in the event of a conflict between requests for the right to transmit coming to it from different mobile stations via corresponding base stations. This arbitration is based on a level of priority and / or on the identity of the mobile stations. The central equipment notifies the various mobile stations of the result of this arbitration, ie it indicates which mobile station has been granted the right to transmit. It must also, if necessary, warn the other mobile stations of the end of the current half-duplex, that is to say of 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 transmit. He still has to,

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037 where appropriate, allow the half-duplex preemption by a mobile station having a higher priority than that which benefits from the right to transmit for the current half-duplex.

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

In particular, it is possible to use the mechanisms of multimedia conferences defined within the framework of Internet protocols, that is to say protocols for networks operating according to the IP protocol (J. Postel, “Internet Protocol”, RFC 791, IETF, September 1981) which was standardized by the Internet Engineering Task Force (IETF) in the Request For Comments (RFC) above. These multimedia conferences are based on the implementation of a multimedia videoconferencing equipment or MCU (from the English “Multimedia Conferencing Unit”), and offer an advantageous support for the realization of many types of telephony and video services. speech for example. However, the main Internet protocols have been designed for classic multimedia applications and do not take into account the specific features of certain applications of professional radiocommunications networks, and in particular the management of the half-duplex mode for communications.

The object of this invention is to provide an adaptation of the protocols implemented in packet-switched transport networks in unconnected mode, allowing the management of the half-duplex for communications in half-duplex mode, whether s 'be individual communications or group communications.

This goal is achieved by means of a half-duplex management method for communication in half-duplex mode between at least two end devices of a packet-switched transport network in unconnected mode, in which an element of 'indication has the function, when it is present with a first determined value in packets transmitted from one of said end equipment to central equipment

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037 ensuring the management of the communication, to indicate to said central equipment, on the one hand, that said end equipment acknowledges receipt of the right to transmit which is granted to it by said central equipment and, on the other hand hand, that it requests the maintenance of this right to transmit.

This indication element may also have the function, when it is present with a second determined value in packets transmitted by the central equipment to the end equipment, to indicate to said end equipment that they can. request the right to issue.

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

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 professional radiocommunications system. 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 equipments of the packet-switched transport network are also base stations of said radio communication system. .

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

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037 said network equipment comprises means for implementing the method as central equipment.

The invention also proposes a base station intended to be used 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 characteristics 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 in which there is shown:

- in Figure 1: the diagram of a radiocommunications system according to the invention;

FIG. 2: a diagram showing a protocol for setting up an individual call involving two base stations of a system according to FIG. 1;

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

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

- in Figure 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 the steps of the method of operating a base station comprising means for implementing the method according to the invention as end equipment;

FIG. 9: a flowchart illustrating the steps in the operation of a multimedia videoconferencing equipment (MCU) for the implementation of the method according to the invention as central equipment; and,

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037

FIG. 10: a diagram illustrating the topology of an RTP / RTCP session in the case of a group communication involving several levels of MOU.

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

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

The base stations are connected to an unconnected mode 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 performed by routers 301, 302 and 303.

Network equipment 400 is connected to network 300. This is preferably an MCU, the usual function of which is to group or switch several real-time data streams (for example, a data stream for voice and / or a data stream for video) to constitute a stream distributed to several receivers, realizing 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 other things, the cell under the coverage of which the called mobile station is located, thus allowing correct routing of calls.

Other equipment than those shown in FIG. 1 can naturally form part of the radiocommunication system. As these items of equipment 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 in the form of separate physical entities for the clarity of the disclosure, can be

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037 duplicated, combined or distributed in various ways without departing from the scope of the invention.

The diagram in figure 2 shows a procedure for establishing an individual communication between the mobile station 101 and the mobile station 102 (here at 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 to say they are of the form "user @ host", where the field "user" designates for example a user name or a telephone number. telephone, and where the “host” field designates for example a domain name or an address in numerical form. The SIP protocol provides methods, including methods called INVITE and ACK, used to initiate a call session between two SIP users. The responses to the messages sent within the framework of these methods are defined by classes of codes.

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 mobile station 102 and where“ home ”is the address of a nominal location register called HLR (standing for“ 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 temporarily under the coverage of another station. basic (code 302 means “Moved temporarely”). This message also indicates in a “Contact” field the address of the MCU handling the communication (here the MCU designated by the “MCU400” address) and, in an “Also” field, the SIP address of the mobile station 102 under the cover of the base station 202 (whose address is "st202" in the example).

CA 02442676 2003-09-26

WO 02/080596 PCT / FR02 / 01037

The base station 101, in accordance with the SIP protocol, reiterates its INVITE message, this time addressing it to the MCU 400, and also mentioning in the “Also” field the address “mob102 @ st202” of the mobile station 102 under the cover of base station 202.

The MCU 400 then sends an INVITE message to the base station 202, mentioning as a party to the call the mobile station 102 designated by its address “mob102 @ st202”.

When the mobile station 102 has picked up, the base station 202 sends as a response to the MCU a validation message (code “200 OK”) which is acknowledged by the MCU 400 using an ACK acknowledgment message.

The MCU 400 then sends to the base station 201 a validation message “200 OK”, which is acknowledged by an ACK acknowledgment message. The communication is then established, for example in the form of an RTP / RTCP session, and the conversation can then begin.

Figure 3 gives the topology of the RTP / RTCP session for the individual communication initiated according to the procedure described above with regard to figure 2. The RTP packets 10 received by the MCU 400 from the base station 201 are retransmitted to the base stations 201 and 202, after possible processing, in the form of RTP packets 11 and 12. Further, RTCP packets (not shown) are transmitted in response to the transmission of RTP packets to provide control of the transport service.

The establishment of a group call between more than two mobile stations can naturally be based on an adaptation of the SIP protocol. The initiation 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 in figure 4. The RTP / RTCP session is here established on the initiative of the mobile station 101.

In such a case, several “Also” fields, followed by the respective SIP addresses of all the mobile stations part of the group communication processed by the MCU 400 (here the “mob102 @ st202” and “mob103 @ st203” addresses 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 to the MCU 400. The MCU 400 then transmits a message.

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037

INVITE to each of the other base stations 202 and 203 which are parties to the group call.

In this case, moreover, each of the INVITE messages also comprises, in the body of the message, a description of the RTP / RTCP session in accordance with the SDP protocol (M. Handley et al., “SDP: Session Description Protocol”, RFC 2327, IETF, April 1998). This description is for example noted “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 UDP ports, that is to say the ports of the devices used by the UDP protocol (J. Postel, "User Datagram Protocol", RFC 768, IETF, August 1980), which should be used for establishing 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, sampling frequency, etc.). It will be noted that, in the “Also” 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 can also propose an identifier of the mobile stations corresponding, for example, to a temporary number acquired during registration.

In FIG. 5, there is shown the topology of the RTP / RTCP session for the group communication initialized according to the procedure described above with regard to the diagram of FIG. 4. The RTP packets 10 received by the MCU 400 of the station 201 base stations, are retransmitted to 201 base stations,

202 and 203, after optional processing, in the form of RTP packets 11, 12 and 13 respectively. For clarity, RTCP packets which are transmitted in response to the transmission of RTP packets are not shown.

The classic 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 the push-to-talk in half-duplex mode communications. This is why the invention proposes an adaptation of RTP allowing the management of the alternation in a communication in half-duplex, individual or group mode.

As shown in the diagrams of FIG. 3 and of FIG. 5, the RTP packets include an HD header, and a data body PL

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037 containing the payload, that is to say the audio or video data itself.

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

- a V (“Version”) field, the length of which is equal to 2 bits, which contains a version number of the protocol (V = 2 in the case shown);

- a P bit (“Padding”), which indicates, when it has the logical 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;

- an X bit (“Extension”), which indicates when it has the logic value 1, the presence of an extension header;

- a CC (“CSRC Count”) field, of a length equal to 4 bits, the value of which defines the number of CSRC (“Contributing Source Identifiers”) type identifiers following the fixed header.

- an M bit (“Marker”), which is a marking bit defined by the profile, ie it can be used according to the needs of the application;

- a PT (“Payload Type”) field, with a length of 7 bits, which identifies the type of the payload (audio or video). This field contains a value which is either a number registered with ΓΙΑΝΑ ("Internet Assigned Numbers Authority"), or a number dynamically chosen from a list of usable values ​​and whose meaning can be chosen by the devices which are parties to the communication. .

- a sequence number (“Sequence Number”), the length of which is equal to 16 bits, which is initialized with a random value at the start of the transmission of an RTP packet stream by an end device, and which is incremented by one for each packet sent. This number allows the other end equipment (s) of the RTP session to reorder the packets or to detect the missing packets in the event of loss of RTP packets during their transport through the IP network;

- a time stamp ("Timestamp"), the length of which is equal to 32 bits, and which dates the moment of generation of the payload of each of the

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037 packages. This stamp thus allows the end devices to calculate the fluctuations in the transport time in the network and thus to provide the buffer memories necessary to guarantee an optimal quality of service. The time stamp is obtained from a clock the resolution of which is sufficient to allow synchronization and the calculation of jitter (“jitter” in English). The initial value of the time stamp is determined randomly, as for the sequence number;

an SSRC synchronization source identifier (“Synchronization Source identifier”), the length of which is equal to 32 bits, and which designates the source of the synchronization of the RTP packets. This source can be the end equipment which generates the RTP packet, but it can also be an intermediary device of the network called a mixing entity (or "mixer", in English), which creates a new stream of RTP packets from RTP packets received from the sources themselves, after modifying their synchronization. In the latter case, the identifier SSRC designates the mixing entity;

- a variable length field, containing a list of CSRC contributory source identifiers, each encoded on 32 bits, and the number of which 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 twelve octets are present in all RTP packets, while the list of CSRC identifiers is only present if inserted by one or more mixing entities.

For a payload consisting of voice encoding data, the format of the payload of an RTP packet conforms to the diagram in figure 7. The payload data of the RTP packet correspond to the following fields:

an NF (“Number of Frames”) field, coded on 2 bits, which contains a value from which the number of voice frames which are contained in the RTP packet is determined;

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037

- a C (“Encrypted”) bit, which is set to the logical value 1 when information relating to the encryption (comprising an algorithm identifier and a key identifier, see below) is contained in the RTP packet;

- a P bit (“Protected”), which indicates that the frames are protected;

- an E (“Emergency”) bit, which, when it is set to the logic value 1, makes it possible to ensure specific processing at the level of the end equipment which receives the RTP packet;

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

- a source address (“Source Address”), coded on 24 bits, which identifies the source address of the user (that is to say here the mobile station) which transmits the speech frames contained in the RTP packet, it being observed that the CSRC contributory source code identifies the end equipment (ie here the base station) which generates the RTP packet and not this user;

- a field containing, where appropriate, the voice frames contained in the RTP packet (“codec Frames”). The number of these frames depends on the value of the NF field (see above). The length of this field is 88 bits (11 bytes). Each frame is aligned with “Padding” bits set to logical value 0, if necessary. In addition, the entire field is aligned with padding bits, if necessary. In an example where the voice 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);

- where appropriate, an algorithm identifier (“Algorithm ID”), coded on 8 bits, which identifies the encryption algorithm implemented for the encryption of the data; and,

- where appropriate, an encryption key identifier (“Key ID”), encoded on 24 bits, which contains the value of an encryption key used by the encryption algorithm.

Note that the algorithm identifier and the key identifier are only contained in the RTP packet if the C bit has the logical value 1. By

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037 elsewhere, other fields than those described above may be contained in the RTP packet. These fields not contributing anything to the understanding of the invention, they are neither represented in FIG. 7, nor explained in the present description.

As understood, RTP packets can be transmitted without payload, when the value contained in the NF field is zero (NF = 0). We then speak of “empty” packets because they do not contain any voice frame.

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

It will be recalled that according to the invention, the base stations are both equipment of the radio subsystem of the radiocommunications system (which provide the radio interface with the mobile stations), and end equipment of the transport network. 300, which send 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 is under the coverage of the base station. base station coverage 203.

In addition, assume that mobile stations 101, 102 and 103 are part of a group communication in half-duplex mode, established according to the SIP session initiation protocol illustrated by the diagram of Figure 4.

More particularly, suppose for example that the mobile station 101 has the right to transmit for the current PTT 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 base stations 201, 202 and 203. These RTP packets contain the CSRC code of base station 201, which is the source selected by the MCU to control the current PTT. The base stations 202 and 203 transmit them in turn, via respective radio channels, to the mobile stations 102 and 103, respectively.

CA 02442676 2003-09-26

WO 02/080596 PCT / FR02 / 01037

The MCU 400, as central equipment, performs an arbitration in case of conflict between requests for the right to transmit from different mobile stations through the corresponding base stations, and notifies 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 half-wave, which corresponds to the cessation of the transmission of voice frames by the mobile station which had obtained the right to transmit for the current alternation. In this way, these mobile stations in the reception phase have the possibility of requesting the right to transmit:

To do this, the invention proposes that an indication element, included in the RTP packets, fulfills a certain number of functions for the management of the alternation.

In one example, the indication element may have the function, in combination with the CSRC code, to indicate to the base station selected by the MCU that the right to transmit has been granted to it. In one example, the indication element indeed has this function when it is present, with a first determined value, in the RTP packets sent 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 receipt of the right to transmit which has been granted to it by the MCU, and on the other hand that it requests the maintenance of this right to transmit.

In addition, the indication element still has the function when it is present, with a third determined value, in an RTP packet transmitted by the MCU to the base stations, to indicate to the base stations that they can request the right to issue. The one that will be selected by the MCU will then take control of the next alternation.

Preferably, the indication element finally has the function, when it is present with a fourth determined value in an empty RTP packet which is transmitted to the MCU from the base station having the right

CA 02442676 2003-09-26

WO 02/080596 PCT / FR02 / 01037 to transmit, to indicate to the MCU that said base station waives its right to transmit. This occurs when the current PTT is terminated, that is to say when the mobile station which had obtained the right to transmit for the current PTT stops transmitting speech frames.

These functions of the indicating element will appear more clearly on reading an exemplary embodiment of the invention which will follow. In one example, the first and second determined values ​​of the indication element are identical. Likewise, the third and fourth determined values ​​of the indicating element are identical, and different from the first and second values.

Concretely, the indication element can be a field of any length, which codes the aforementioned determined values. In a preferred embodiment, this indication element can advantageously be reduced to one bit, since it has two distinct functions when it is present in an 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 an RTP packet transmitted from a base station to the MCU (again as a function of its value among said second and said third different determined values).

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

The flowchart of Figure 8 illustrates the operation of a base station as end equipment according to the invention. Consider more particularly the example of the base station 201.

Suppose that, in a step 301, the mobile station 101 manifests its intention to transmit by appropriate signaling to the base station 201. In practice, this occurs when the user of the mobile station

CA 02442676 2003-09-26

WO 02/080596 PCT / FR02 / 01037

101 press the PTT button and speak into the microphone of the mobile station.

If the base station 201 already receives 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 RTP packets which are those retransmitted by the MCU with M = 1), and if the priority associated with the current push-to-talk is not lower than the priority associated with the request of the mobile station 201, then, in a step 302 , it deduces from this that the right to transmit must be refused to the mobile station 101. In other words, the base station 201 decides that the mobile station 101 cannot take control of the PTT.

In a step 303, the base station 201 then notifies the mobile station 101 that the right to transmit is refused to it. In practice, this is indicated to the user by the extinction of an indicator light of the mobile station 101 which had been lit in step 301. The base station 201 continues to transmit on the interface 15 air the signals. voice frames received in the packets received from the MCU and the mobile station 101 remains in the reception phase. It will be noted that the priority associated with the request from 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-duplex 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 does not receive any RTP packet from the MCU, or the priority associated with the request from the mobile station 101 is higher than that associated with the current push-to-talk, then, in step 302, the base station 201 deduces therefrom that it can grant (at least temporarily) the right to transmit to the mobile station 101 which has started to transmit voice 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 logical value 0 (M = 0). This value has the function of indicating to the MCU that the base station 201 requests the right to transmit.

From there, base station 201 begins to (or continues to) receive RTP packets with M = 1. As noted above, these packets contain an SSRC synchronization source identifier, which corresponds to the MCU identifier and a source identifier.

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037 CSRC contributory, which corresponds to the identifier of the base station which has the right to transmit for the current PTT.

If the CSRC identifier is different from the identifier of the base station 201, the latter deduces, in a step 305, that it has not been selected by the MCU, that is to say that the right to transmit has not been granted to it by the MCU, or, in other words, the PTT control has been 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 does not have the right to transmit. Step 306 is equivalent to step 303 above.

Yes, conversely, the CSRC identifier of the RTP packets transmitted by the MCU is that of the base station 201, the latter deduces therefrom, in step 305, that it can continue sending the messages to the MCU. RTP packets containing the voice frames sent by the mobile station 101 on the radio channel. However, in a step 307, it now sends these RTP packets with the M bit set to the logical 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 transmit.

At any time, the mobile station 101 can stop transmitting voice 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 send voice frames, RTP packets containing these frames are generated by the base station 201 and sent to the MCU. The method continues by repeating the aforementioned step 305. If, conversely, the mobile station stops sending voice frames, then, in a step 309, the base station sends, to the MCU, the last RTP packets with the M bit set to the logical value 0 These last packets contain the last voice frames sent by the mobile station 101 (and timed by passing through a buffer memory of the base station). The M bit with the logical value 0 then has the function of indicating to the MCU that the base station 201 waives its right to transmit. In this way, the MCU is informed of the imminent cessation of the transmission of RTP packets by the base station 201 even before the latter.

CA 02442676 2003-09-26

WO 02/080596

PCT7FR02 / 01037 packets are not sent. The MCU, as will appear later with regard to figure 9, can then alert the other base stations by transmitting these last RTP packets with the M bit set to the logical value 0 to indicate that the end of the half-duplex in progress is near, and that they will soon be able to apply for (and, for one of them, obtain) the right to broadcast.

Finally, when the base station 201 has sent the last voice frames in RTP packets with the M bit set to zero (step 309), it sends, in a step 310, a certain number (for example three) of RTP packets. empty, that is to say without payload, and whose M bit is at the logical value 0. It sends several such packets in order to minimize the risks 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 an NF field containing the value zero. The function of these empty packets is to actually signal the end of the current PTT. They allow the MCU not to confuse the end of the current half-duplex with a request for the right to transmit which would come from another mobile station located under the coverage of the same base station 201 as the mobile station 101 which controls the current PTT. Indeed, such a request would also have the form of RTP packets containing voice frames (those sent by this other mobile station and received by the base station 201 via another radio channel), the M bit of which would also have the logical value. 0, and whose CSRC field would contain the same source identifier (that of base station 201, which would be the same source seen from the MCU).

The flowchart of FIG. 9 illustrates for its part the operation of the MCU as central equipment according to the invention.

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

Suppose that at least one and perhaps more base stations (also called sources) send such non-empty RTP packets with M = 0.

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037

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 transmits RTP packets, this algorithm selects that source. When several sources send RTP packets simultaneously, the selection algorithm can involve, for example, the priority, the identity of the sender or any other criterion.

Once the selection is made, the MCU, in a step 703, transmits to all the base stations participating in the group communication (namely, in the example, the base stations 201, 202 and 203) the received RTP packets. of the selected base station (i.e., 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 selected source 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 RTP packet, the MCU first checks, in a step 704, that this packet does indeed come 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 the logical value 1. If so, this packet is transmitted as indicated above (return to step 703 above). If, on the contrary, the M bit 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), the source indicates the end of the PTT. Then, in a step 707, the last RTP packets (those which remain in the buffer memory of the MCU) are transmitted as indicated above (with reference to step 703 above) but with the M bit set to the value logic 0, in order to indicate to the base stations the end of the PTT. The MCU then returns to the 700 standby state. If, on the contrary, the packet is not empty (i.e. it contains at least one voice frame), the RTP packet is sent with the M bit in logic state 1 (we return to l 'step 703).

CA 02442676 2003-09-26

WO 02/080596 PCT / FR02 / 01037

If, contrary to the hypothesis made above for the test of step 704, the RTP packet received in step 711 does not come from the selected source, two cases may arise, they are examined in a step 708. If the priority of the source of the received RTP packet is higher than that of the selected source, then, in a step 709, the source of the received RTP packet is selected as the 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 outright rejected, in a step 710, and the MCU waits for the reception of a new packet (return to step 711).

Referring to Figure 8, we see that when, in step 709, the MCU selects a new source while a source is already transmitting RTP packets, the test of 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 the M bit at the logical value 0 (indicating the next end of the current half-wave) 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 logical value 0.

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

A variant of the technique presented above makes it possible to make detection of the end of the current half-wave faster without risk of false detection in the event of loss of RTP packets. The test in step 706 which reads "Empty packet with M = 0?" ", Can be replaced by the following test:" (Empty packet with M = 0) or (packet with M = 0, the three preceding packets not having

CA 02442676 2003-09-26

WO 02/080596

PCT / FR02 / 01037 all been lost)? ". Thus, the MCU detects the end of the current half-wave as soon as the first packet is received with the M bit set to the logical value 0 and the MCU cannot confuse a start of the half-wave with the end of the current half-wave. because, if the three empty packets with M = 0 sent by the base station at the end of the half-duplex have been lost, a non-empty packet with M = 0 will not be considered as indicating the end of the current half-duplex. The terms “previous” and “first” used above obviously refer to the order of the RTP packets as indicated by the sequence number contained in the header of the RTP packets (see FIG. 6). .

As is well known to those skilled in the art, the operation described by the flowcharts of FIGS. 8 and 9 may require guard timings so that the equipment of the IP network, namely the end equipment (base stations ) and the central equipment (MCU), are protected against link cuts, 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 conferencing topologies than that presented above by way of example, and in particular to a topology such as represented in FIG. 10. In this topology, an 801 MCU (or master MCU) ensures the connection and the arbitration of the alternations between sub-conferences managed by the 802 and 803 MCUs (or slave MCUs), the latter performing the arbitration of the 'PTT and the connection of base stations 804 to 806, and 807 to 809 respectively. Those skilled in the art perceive that the flow charts of operation of the base stations and of the master MCU are identical to those presented previously with reference to Figures 8 and 9 respectively, while the operation of the slave MCUs 802 or 803 conforms to FIG. The flowchart of Figure 8 with respect to their link to the master MCU 801, and to that of Figure 9 for their links to base stations 804-806 or 807-809 respectively.

So, to give a simple example, the slave MCU 802 transmits at the start of the half-wave the RTP packets received from a base station such as 804 with the M bit at the logical value 0, leaving the M bit at the logical value. 0 for RTP packets transmitted to the master MCU, while the M bit

CA 02442676 2003-09-26

WO 02/080596 PCI7FR02 / 01037 is set to the logical value 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 different functions of this bit according to the invention can naturally be inverted. In addition, and in particular in the case where more functions are to be allocated to this indication element, it is possible to replace the marking bit M by a word of several bits, or to associate it with one or more other ones. bits so that the indication element can have more than two distinct values.