EP1374607A1 - Procede de gestion de l'alternat pour une communication en mode semi-duplex a travers un reseau de transport a commutation de paquets - Google Patents

Procede de gestion de l'alternat pour une communication en mode semi-duplex a travers un reseau de transport a commutation de paquets

Info

Publication number
EP1374607A1
EP1374607A1 EP02722377A EP02722377A EP1374607A1 EP 1374607 A1 EP1374607 A1 EP 1374607A1 EP 02722377 A EP02722377 A EP 02722377A EP 02722377 A EP02722377 A EP 02722377A EP 1374607 A1 EP1374607 A1 EP 1374607A1
Authority
EP
European Patent Office
Prior art keywords
equipment
network
packet
rtp
mcu
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02722377A
Other languages
German (de)
English (en)
Inventor
Gérard Marque-Pucheu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EADS Secure Networks SAS
Original Assignee
EADS Telecom SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by EADS Telecom SAS filed Critical EADS Telecom SAS
Publication of EP1374607A1 publication Critical patent/EP1374607A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10—Push-to-Talk [PTT] or Push-On-Call services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H04W76/45—Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections

Definitions

  • 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.
  • IP Internet Protocol
  • radiocommunication systems in particular private professional radiocommunication systems, such as those intended for the police or firefighters.
  • GSM public switched telephone network
  • a mobile station can transmit or receive, but cannot do these two operations at the same time.
  • only one mobile station must be authorized to transmit at a given time, the data stream transmitted by this mobile station being retransmitted towards the mobile station (s) participating in the communication (also called call or " call "in English), that is to say to the mobile station concerned if it is an individual call or to all mobile stations participating in the call if it is a call from group.
  • multimedia conference mechanisms defined within the framework 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 RFC ("Request For Comment") above.
  • IP protocol J. Postel, "Internet Protocol", RFC 791, IETF, September 1981
  • IETF Internet Engineering Task Force
  • RFC Real-Request For Comment
  • MCU from the English “Multimedia Conferencing Unit”
  • the main Internet protocols have been designed for conventional multimedia applications and do not take into account the specificities of certain applications of professional radiocommunication networks, and in particular the management of the alternation for communications in half-duplex mode.
  • 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 present with a first determined value in packets transmitted from one of said end devices to a central device ensuring communication management, 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, that it requests that this right to broadcast be maintained.
  • This indication element can also have the function, when 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 ask for the right to broadcast.
  • the central equipment can be an MCU, and the frames transmitted on the network can be RTP (Real time Transport Protocol) packets.
  • RTP Real time Transport Protocol
  • the communication then being established as an RTP / RTCP session (from the English “Real time Transport Control Protocol” ").
  • 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 indication element being the logical value 0 or 1, respectively.
  • the invention also provides a radiocommunication system, in particular a private professional radiocommunication 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 network end equipment and in which said network equipment comprises means for implementing the method as central equipment.
  • a radiocommunication system in particular a private professional radiocommunication 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 network end equipment and in which said network equipment comprises means for implementing the method as central equipment.
  • the invention also provides a base station intended to be used as end equipment in a system as defined above.
  • the invention finally provides multimedia videoconferencing equipment intended to be used as central equipment in a system as defined above.
  • Figure 2 a diagram showing a protocol for establishing an individual call involving two base stations of a system according to Figure 1;
  • Figure 3 a diagram illustrating the topology of an RTP / RTCP session in the case of an individual communication
  • Figure 4 a diagram showing a protocol for establishing a group communication involving three base stations of a system according to Figure 1;
  • Figure 5 a diagram illustrating the topology of an RTP / RTCP session in the case of group communication
  • - in Figure 8 a flowchart illustrating steps of the method of operating a base station comprising means for implementing the method according to the invention as end equipment; - in Figure 9: a flowchart illustrating steps in the operation of a multimedia video conference equipment (MCU) for the implementation of the method according to the invention as central equipment; and, - in Figure 10: a diagram illustrating the topology of an RTP / RTCP session in the case of a group communication involving several levels of MCU.
  • MCU multimedia video conference equipment
  • mobile stations 101, 102 and 103 are in the coverage area of base stations 201, 202 and 20 respectively. It will be recalled that the base stations are fixed items of equipment of the radio subsystem of the communication 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.
  • an IP network such as an IP network.
  • 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.
  • 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 cover of which the called mobile station is located, thus allowing correct routing of calls.
  • Equipment other than that shown in FIG. 1 can naturally form part of the radiocommunication 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.
  • the different equipment base stations, MCU, call server, etc.
  • base stations, MCU, call server, etc. although represented here in the form of separate physical entities for the sake of clarity, can be duplicated, combined or distributed in various ways without departing from the scope of the invention.
  • the diagram in FIG. 2 presents a procedure for establishing an individual communication between mobile station 101 and mobile station 102 (here on the initiative of 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 Session Initiation Protocol
  • SIP addresses are similar to e-mail addresses, that is, they are of the form "user @ host", where the field "user” designates, for example, a user name or a 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 messages sent within the framework of these methods are defined by code classes.
  • 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 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 a “AIso” field, the SIP address of the mobile station 102 under the cover of 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 in addition mentioning in the "AIso" field the address "mob102 @ st202" of the mobile station 102 under the cover of the base station 202.
  • the MCU 400 then sends an INVITE message to the base station 202, mentioning as part of the call the mobile station 102 designated by its address "mob102 @ st202".
  • the base station 202 sends as response to the MCU a validation message (code "200 OK") which is acknowledged by the MCU 400 with the aid of an acknowledgment message ACK.
  • the call server 500 can also propose an identifier of the mobile stations corresponding, for example, to a temporary number acquired during registration.
  • the RTP packets comprise an HD header, and a body of data PL containing the payload (“Payload” in English), that is to say the audio or video data proper.
  • FIG. 6 shows the format of the header of a packet according to the RTP protocol (see RFC 1889, mentioned above).
  • This header includes the following fields:
  • Padding a bit P (“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 the purposes of cryptography;
  • Extension a bit X (Extension), which indicates when it has logic value 1, the presence of an extension header
  • CSRC Count a CC field
  • 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;
  • Payload Type a field PT
  • IANA Internet Assigned Numbers Authority
  • 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 or other end devices of the RTP session to reorder the packets or to detect missing packets in the event of loss of RTP packets during their transport through the IP network;
  • Time stamp a time stamp
  • the time stamp is obtained from a clock whose resolution is sufficient to allow synchronization and jitter calculation (“Jitter” in English).
  • the initial value of the time stamp is determined randomly, as for the sequence number;
  • Synchronization Source identifier an SSRC synchronization source identifier
  • This source can be the end device which generates the RTP packet, but it can also be an intermediate 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 the synchronization.
  • the SSRC identifier designates the mixing entity
  • variable length field containing a list of CSRC contributing source identifiers, each coded on 32 bits, and the number of which is indicated in the CC field mentioned above (there can be between 0 and 15 such codes in the listing).
  • These contributing sources are the end devices which 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 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.
  • the format of the payload of an RTP packet conforms to the diagram in FIG. 7.
  • the payload of the RTP packet corresponds to the following fields: - an NF field (" Number of Frames ”), coded on 2 bits, which contains a value from which the number of speech frames which are contained in the RTP packet is determined; - a bit C (“Encrypted”), which is set to logical value 1 when information relating to encryption (comprising an algorithm identifier and a key identifier, see below) is contained in the RTP packet;
  • Priority field the length of which is equal to 3 bits, which indicates a priority level associated with the speech frames contained in the RTP packet;
  • Source Address a source address
  • the contributing source code CSRC identifies the end equipment (that is to say here the base station) which generates the RTP packet and not this user;
  • Key ID an encryption key identifier
  • the base stations are both equipment of the radio subsystem of the radiocommunication system (which provides the radio interface with the mobile stations), and end equipment of the transport network. 300, which send and receive RTP packets.
  • the mobile stations 101, 102 and 103 are part of a group communication in half-duplex mode, established according to the SIP session initialization protocol illustrated by the diagram in FIG. 4. More particularly, suppose by example that the mobile station 101 has the right to transmit for the current alternation and is in the process of transmitting.
  • the speech 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 alternation in progress.
  • the base stations 202 and 203 in turn transmit them, via respective radio channels, to the mobile stations 102 and 103 respectively.
  • the MCU 400 as central equipment, performs arbitration in the event of a 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 notify without delay the mobile stations in 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 obtained the right to transmit for the work-study program in progress. In this way, these mobile stations in 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 managing the half-day course.
  • 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 to it.
  • the indication element indeed 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.
  • 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 broadcast.
  • 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 broadcast.
  • the indication element also 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 ask for the right to broadcast. The one of them which will be selected by the MCU, will then take control of the next alternation.
  • the indication element finally has the function, 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 to the MCU that said base station renounces its right to transmit. This occurs when the current alternation is finished, that is to say when the mobile station which had obtained the right to transmit for the current alternation, stops transmitting speech frames.
  • the indication element can be a field of any length, which codes the aforementioned determined values.
  • 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 determined different values), and two distinct functions when it is present in an RTP packet transmitted from a base station to the MCU (again depending on its value among said second. and said third values determined different).
  • bit M 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 said third and said determined fourth values are logical value 0.
  • the flow diagram of FIG. 8 illustrates the operation of a base station as end equipment according to the invention.
  • the base station 201 suppose more particularly the example of the base station 201.
  • the mobile station 101 manifests its intention to transmit by appropriate signaling to the base station 201. In practice, this occurs when the mobile station user 101 presses the PTT (Push-To-Talk) button and speaks into the microphone of the mobile station.
  • PTT Push-To-Talk
  • the base station 201 continues to transmit the frames on the air interface. of voice 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 above-mentioned signaling or be calculated by the base station 201 according to an ad-hoc method. In addition, the priority associated with the current alternation is indicated in the RTP packets received by the base station 201 (in the aforementioned PRIO field).
  • step 302 the base station 201 deduces from this that it can grant (at least temporarily) the right to transmit to the mobile station 101 which has started to transmit speech frames.
  • M the logical value 0
  • the identifier CSRC is different from the identifier of the base station 201, the latter deduces therefrom, in a step 305, that it has not been selected by the MCU, that is to say that the right to transmit was not granted to it by the MCU, or, in other words, that control of the half-day was granted by the MCU to another base station.
  • a step 306 it interrupts the transmission of RTP packets to the MCU and notifies the base station 101 that it has no right to transmit.
  • Step 306 is equivalent to the aforementioned step 303.
  • the identifier CSRC 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 the transmission to the MCU of the RTP packets containing the speech frames transmitted by the mobile station 101 on the radio channel.
  • 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 continues by repeating the above-mentioned step 305. If, conversely, 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 logic value 0 These latter packets contain the last speech frames transmitted by the mobile station 101 (and timed by passing through a buffer memory of the base station).
  • the bit M with the logical value 0 then has the function of indicating to the MCU that the base station 201 renounces its right to transmit. In this way, the MCU is informed of the forthcoming cessation of the transmission of RTP packets by the base station 201 even before these packets are not issued.
  • the MCU can then alert the other base stations by transmitting these latter RTP packets with the bit M set to the logical value 0 to indicate that the end of the half-cycle in progress is near, and that it will soon be able to request (and, for one of them, obtain) the right to broadcast.
  • the base station 201 when it has transmitted the last speech frames in RTP packets with the bit M set to zero (step 309), it transmits, in a step 310, a certain number (for example three) of RTP packets empty, that is to say without payload, and whose bit M is at logical value 0. It transmits several such packets in order to minimize the risks of non-reception by the MCU, which can occur if the network lose packets due to overloaded routers. It is recalled that empty packets are characterized by an NF field containing the value zero. These empty packets have the function of really signaling the end of the current alternation.
  • the MCU receives these packets, it selects, in a step 702, one of the base stations according to an ad-hoc selection algorithm.
  • this algorithm selects this source.
  • the selection algorithm can involve, for example, the priority, the identity of the sender or any other criterion.
  • the MCU transmits the received RTP packets to all the base stations participating in the group communication (namely, in the example, the base stations 201, 202 and 203) of the selected base station (namely, in the example, the base station 201), after having set the bit M to the logical value 1 and having placed its own identifier in the field SSRC and that of the selected source in the CSRC field (the value of the CC field of the RTP packet is then equal to
  • the MCU When, in a step 711, the MCU then receives a new packet
  • the MCU first checks, in a step 704, that this packet indeed comes from the selected source. For this purpose the CSRC identifier of the packet is used.
  • the MCU verifies, in a step 705, if 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 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 speech frame), it means that the source indicates the end of the alternation.
  • the last RTP packets (those which remain in the buffer of the MCU) are transmitted as indicated above (with reference to step 703 above) but with the bit M set to the value logic 0, in order to indicate to the base stations the end of the alternation.
  • the MCU then returns to the standby state 700. If, on the contrary, the packet is not empty (that is to say that it contains at least one speech frame), the RTP packet is transmitted with the bit M in logic state 1 (we return to step 703). If, contrary to the assumption made above for the test of step 704, the RTP packet received in step 711 does not come from the selected source, two cases can arise. They are examined in a step 708.
  • 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 selected source. Otherwise, the packet is purely and simply rejected, in a step 710, and the MCU waits for the reception of a new packet (return to step 711).
  • step 709 when, at 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 speech frames by the mobile station concerned.
  • the technique presented above therefore makes it possible both to ensure an arbitration of the work-stay 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 alternation as soon as the end of the current alternation is announced by the transmission by the selected base station of empty RTP packets with the bit M set to logic value 0.
  • the terms “previous” and “first” used above obviously refer to the order of RTP packets as indicated by the sequence number contained in the header of RTP packets (see Figure 6) .
  • the operation described by the flowcharts in FIGS. 8 and 9 may require guard times for the equipment of the IP network, namely the end equipment (base stations ) and the central equipment (MCU), are protected against connection cuts, whether these have a physical origin or come from a failure or overload of the routers.
  • an MCU 801 (or master MCU) ensures the connection and arbitration of the half-cycles between sub-conferences managed by the MCU 802 and 803 (or slave MCUs), the latter performing the alternation arbitration and the connection of base stations respectively 804 to 806, and 807 to 809.
  • MCU 801 master MCU
  • the flowcharts of. operation of the base stations and the master MCU are identical to those presented previously with regard to FIGS. 8 and 9 respectively, while the operation of the slave MCUs 802 or 803 is in accordance with the flow diagram of FIG.
  • the slave MCU 802 transmits at the start of the half-day 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 logic value 0 for RTP packets transmitted to the master MCU, while the M bit is set to logical value 1 for the RTP packets retransmitted to the various base stations 804 to 806 participating in the communication.
  • the respective logical values of the marking bit M assigned to the different functions of this bit according to the invention can naturally be inverted.

Abstract

L'invention propose un procédé de gestion de l'alternat pour une communication en mode semi-duplex entre au moins deux équipements d'extrémité (201-203) d'un réseau de transport à commutation de paquets en mode non connecté (300), dans lequel un élément d'indication (M) a pour fonction, lorsqu'il est présent avec une première valeur déterminée dans des paquets transmis depuis un (201) desdits équipements d'extrémité (201-203) vers un équipement central (400) assurant la gestion de la communication, d'indiquer audit équipement central (400), d'une part, que ledit équipement d'extrémité (201) accuse réception du droit d'émettre qui lui est accordé par ledit équipement central (400) et, d'autre part, qu'il demande le maintien de ce droit d'émettre.

Description

PROCEDE DE GESTION DE L'ALTERNAT POUR UNE COMMUNICATION EN MODE SEMI-DUPLEX A TRAVERS UN RESEAU DE TRANSPORT A
COMMUTATION DE PAQUETS
La présente invention concerne un procédé de gestion d'une communication de groupe en mode semi-duplex entre différents équipements d'extrémité d'un réseau à commutation de paquets.
Elle se rapporte au domaine des réseaux de transport à commutation de paquets en mode non connecté, en particulier les réseaux IP (Internet Protocol).
Elle trouve des applications, en particulier dans les systèmes de radiocommunications, notamment les systèmes privés de radiocommunications professionnelles, tels que ceux destinés à la police ou aux pompiers. Ces systèmes ont un mode de communication particulier, dit mode semi- duplex, qui a depuis longtemps disparu des systèmes publics (réseau téléphonique commuté public, ou systèmes de radiocommunications publics tels que le GSM). Dans le mode semi-duplex, une station mobile peut émettre ou recevoir, mais ne peut pas faire ces deux opérations à la fois. De plus, une seule station mobile doit être autorisée à émettre à un instant donné, le flux de données émis par cette station mobile étant retransmis vers la ou les station(s) mobile(s) participant à la communication (aussi appelée appel ou « call » en anglais), c'est-à-dire vers la station mobile concernée s'il s'agit d'une communication individuelle ou vers toutes les stations mobiles participant à la communication s'il s'agit d'une communication de groupe.
Un équipement de réseau particulier, appelé équipement central dans la suite, effectue un arbitrage en cas de conflit entre des demandes du droit d'émettre lui parvenant de stations mobiles différentes par l'intermédiaire de stations de base correspondantes. Cet arbitrage se fonde sur un niveau de priorité et/ou sur l'identité des stations mobiles. L'équipement central notifie aux différentes stations mobiles le résultat de cet arbitrage, c'est-à-dire qu'il indique quelle est la station mobile à qui le droit d'émettre a été accordé. Il doit également, le cas échéant, prévenir les autres stations mobiles de la fin de l'alternat en cours, c'est-à-dire de la cessation de l'émission par la station mobile qui avait auparavant obtenu le droit d'émettre, afin que ces autres stations mobiles puissent à leur tour demander le droit d'émettre. Il doit encore, le cas échéant, permettre la préemption d'alternat par une station mobile ayant une priorité supérieure à celle qui bénéficie du droit d'émettre pour l'alternat en cours.
L'important développement des réseaux de transport à commutation de paquets en mode non connecté permet d'envisager la gestion d'une communication entre au moins deux stations de base d'un système de radiocommunications, considérées en tant qu'équipements d'extrémité d'un tel réseau.
En particulier, on peut utiliser les mécanismes des conférences multimédia définies dans le cadre des protocoles Internet, c'est à dire des protocoles pour les réseaux fonctionnant selon le protocole IP (J. Postel, « Internet Protocol », RFC 791, IETF, septembre 1981) qui a été normalisé par l'organisation IETF (« Internet Engineering Task Force ») dans la RFC (« Request For Commente ») ci-dessus. Ces conférences multimédia sont fondées sur la mise en œuvre d'un équipement de vidéoconférence multimédia ou MCU (de l'anglais « Multimedia Conferencing Unit »), et offrent un support avantageux pour la réalisation de nombreux types de services de téléphonie et de vidéσ-phonie par exemple. Toutefois, les principaux protocoles Internet ont été conçus pour des applications multimédia classiques et ne prennent pas en compte les spécificités de certaines applications des réseaux de radiocommunications professionnels, et en particulier la gestion de l'alternat pour les communications en mode semi-duplex.
L'objet de cette invention est de proposer une adaptation des protocoles mis en œuvre dans les réseaux de transport à commutation de paquets en mode non connecté, permettant la gestion de l'alternat pour les communications en mode semi-duplex, qu'il s'agisse de communications individuelles ou de communications de groupe.
Ce but est atteint grâce à un procédé de gestion de l'alternat pour une communication en mode semi-duplex entre au moins deux équipements d'extrémité d'un réseau de transport à commutation de paquets en mode non connecté, dans lequel un élément d'indication a pour fonction, lorsqu'il est présent avec une première valeur déterminée dans des paquets transmis depuis un desdits équipements d'extrémité vers un équipement central assurant la gestion de la communication, d'indiquer audit équipement central, d'une part, que ledit équipement d'extrémité accuse réception du droit d'émettre qui lui est accordé par ledit équipement central et, d'autre part, qu'il demande le maintien de ce droit d'émettre. Cet élément d'indication peut en outre avoir pour fonction, lorsqu'il est présent avec une seconde valeur déterminée dans des paquets transmis par l'équipement central vers les équipements d'extrémité, d'indiquer audits équipements d'extrémité qu'ils peuvent demander le droit d'émettre.
Lorsque le réseau de transport à commutation de paquets en mode non connecté est un réseau IP, l'équipement central peut être un MCU, et les trames transmises sur le réseau peuvent être des paquets RTP (de l'anglais « Real time Transport Protocol », voir H. Schulzrinne, « RTP : a Transport Protocol for Real-Time Applications », RFC 1889, IETF, janvier 1996), la communication étant alors établie en tant que session RTP/RTCP (de l'anglais « Real timeTransport Control Protocol »).
Selon une caractéristique avantageuse de l'invention, l'élément d'indication peut alors être le bit de marquage M de l'entête des paquets RTP, ladite première valeur de l'élément d'indication étant la valeur logique 1 ou 0, et ladite seconde valeur de l'élément d'indication étant la valeur logique 0 ou 1 , respectivement.
L'invention propose également une application du procédé ci-dessus à un système de radiocommunications, notamment un système privé de radiocommunications professionnelles. Le procédé permet alors la gestion de l'alternat pour des communications individuelles ou des communications de groupe entre des stations mobiles lorsque au moins certains des équipements d'extrémité du réseau de transport à commutation de paquets sont également des stations de base dudit système de radiocommunications.
L'invention propose aussi un système de radiocommunications, notamment un système privé de radiocommunications professionnelles, comprenant des stations de base et un équipement de réseau reliés par un réseau de transport à commutation de paquets en mode non connecté, dans lequel lesdites stations de base comprennent des moyens pour la mise en œuvre du procédé en tant qu'équipement d'extrémité du réseau et dans lequel ledit équipement de réseau comprend des moyens pour la mise en œuvre du procédé en tant qu'équipement central.
L'invention propose encore une station de base destinée à être utilisée en tant qu'équipement d'extrémité dans un système tel que défini ci-dessus. L'invention propose enfin un équipement de visioconférence multimédia destiné à être utilisé en tant qu'équipement central dans un système tel que défini ci-dessus.
D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels on a représenté :
- à la figure 1 : le schéma d'un système de radiocommunications selon l'invention ;
- à la figure 2 : un diagramme présentant un protocole d'établissement d'une communication individuelle impliquant deux stations de base d'un système selon la figure 1 ;
- à la figure 3 : un schéma illustrant la topologie d'une session RTP/RTCP dans le cas d'une communication individuelle ;
- à la figure 4 : un diagramme présentant un protocole d'établissement d'une communication de groupe impliquant trois stations de base d'un système selon la figure 1 ;
- à la figure 5 : un schéma illustrant la topologie d'une session RTP/RTCP dans le cas de la communication de groupe ;
- à la figure 6 : un diagramme illustrant le format de l'entête d'un paquet RTP ; - à la figure 7 : un diagramme illustrant le format de la charge utile d'un paquet RTP ;
- à la figure 8 : un organigramme illustrant des étapes du procédé de fonctionnement d'une station de base comprenant des moyens pour la mise en oeuvre du procédé selon l'invention en tant qu'équipement d'extrémité ; - à la figure 9 : un organigramme illustrant des étapes du fonctionnement d'un équipement de vidéoconférence multimédia (MCU) pour la mise en œuvre du procédé selon l'invention en tant qu'équipement central; et, - à la figure 10 : un schéma illustrant la topologie d'une session RTP/RTCP dans le cas d'une communication de groupe impliquant plusieurs niveaux de MCU.
A la figure 1 , on a représenté de façon schématique un système de radiocommunications selon l'invention.
Dans l'exemple représenté, des stations mobiles 101 , 102 et 103 sont dans la zone de couverture de stations de base respectivement 201, 202 et 203. On rappelle que les stations de base sont des équipements fixes du sous- système radio du système de radiocommunications, qui assurent l'interface . radio avec les stations mobiles.
Les stations de base sont raccordées à un réseau de transport à commutation de paquets en mode non connecté 300, tel qu'un réseau IP. Dit autrement, les stations de base 201 , 202 et 203 sont également des équipements d'extrémité d'un réseau IP. La commutation des paquets est assurée par des routeurs 301 , 302 et 303.
Un équipement de réseau 400 est raccordé au réseau 300. Il s'agit de préférence d'un MCU, dont la fonction habituelle consiste à regrouper ou à commuter plusieurs flux de données temps réel (par exemple, un flux de données pour la voix et/ou un flux de données pour la vidéo) pour constituer un flux distribué vers plusieurs récepteurs, réalisant une configuration de conférence multimédia.
Un serveur d'appel 500 est également raccordé au réseau 300. Cet équipement analyse des appels et établit de communications multimédia sur le réseau 300. Il coopère avec une base de données de localisation 600, qui est également raccordée au réseau 300, et qui contient des informations indiquant, entre autres, la cellule sous la couverture de laquelle se trouve la station mobile appelée, permettant ainsi un routage correct des appels.
D'autres équipements que ceux représentés sur la figure 1 peuvent naturellement faire partie du système de radiocommunication. Ces équipements ne participant pas aux mécanismes du procédé selon l'invention, il n'est pas utile de les décrire ici. De plus, les différents équipements (stations de base, MCU, serveur d'appel, etc.), bien que représentés ici sous la forme d'entités physiques distinctes pour la clarté de l'exposé, peuvent être dupliqués, réunis ou répartis de diverses manières sans sortir du cadre de l'invention.
Le diagramme de la figure 2 présente une procédure pour l'établissement d'une communication individuelle entre la station mobile 101 et la station mobile 102 (ici à l'initiative de la station mobile 101 ), qui utilise un protocole de signalisation de couche application tel que le protocole SIP (M. Handley et al., « SIP : Session Initiation Protocol », RFC 2543, IETF, mars 1999).
Les adresses SIP sont similaires à des adresses de messagerie électronique, c'est-à-dire qu'elles sont de la forme « user@host », où le champ « user » désigne par exemple un nom d'utilisateur ou un numéro de téléphone, et où le champ « host » désigne par exemple un nom de domaine ou une adresse sous forme numérique. Le protocole SIP prévoit des méthodes, notamment des méthodes appelées INVITE et ACK, utilisées pour initialiser une session d'appel entre deux utilisateurs SIP. Les réponses aux messages émis dans le cadre de ces méthodes sont définies par des classes de codes.
Ainsi, sur demande de la station mobile 101 , la station de base 201 génère un message d'invitation INVITE adressé au serveur d'appels 500. Ce message INVITE mentionne comme destinataire la station mobile 102, dont l'adresse SIP est par exemple « mob102@home », où « mob102 » est le nom d'utilisateur de la station mobile 102 et où « home » est l'adresse d'un registre de localisation nominal appelé HLR (de l'anglais « Home Location Register ») qui abrite la base de données de localisation 600.
Dans l'exemple représenté, le serveur d'appels 500 répond, après consultation de la base de données de localisation 600, par un message indiquant un code « 302 » qui signifie que la station mobile est momentanément sous la couverture d'une autre station de base (le code 302 signifie « Moved temporarely »). Ce message indique en outre dans un champ « Contact » l'adresse du MCU traitant la communication (ici le MCU désigné par l'adresse « MCU400 ») et, dans un champ « AIso », l'adresse SIP de la station mobile 102 sous la couverture de la station de base 202 (dont l'adresse est « st202 » dans l'exemple). La station de base 101, conformément au protocole SIP, réitère son message INVITE en l'adressant cette fois-ci au MCU 400, et en mentionnant en outre dans le champ « AIso » l'adresse « mob102@st202 » de la station mobile 102 sous la couverture de la station de base 202. Le MCU 400 émet alors un message INVITE à destination de la station de base 202, mentionnant comme partie à l'appel la station mobile 102 désignée par son adresse « mob102@st202 ».
Lorsque la station mobile 102 a décroché, la station de base 202 émet comme réponse vers le MCU un message de validation (code « 200 OK ») qui est acquitté par la MCU 400 à l'aide d'un message d'acquittement ACK.
Le MCU 400 émet alors vers la station de base 201 un message de validation « 200 OK », qui est acquitté par un message d'acquittement ACK. La communication est alors établie, par exemple sous la forme d'une session RTP/RTCP, et la conversation peut alors commencer. La figure 3 donne la topologie de la session RTP/RTCP pour la communication individuelle initialisée selon la procédure décrite ci-dessus en regard de la figure 2. Les paquets RTP 10 reçus par le MCU 400 de la station de base 201 sont retransmis vers les stations de base 201 et 202, après un traitement éventuel, sous la forme de paquets RTP 11 et 12. En outre, des paquets RTCP (non représentés) sont transmis en réponse à la transmission des paquets RTP afin d'assurer le contrôle du service de transport.
L'établissement d'une communication de groupe entre plus de deux stations mobiles peut naturellement se fonder sur une adaptation du protocole SIP. L'initialisation d'une communication de groupe entre les stations mobiles 101 , 102 et 103, qui sont sous la couverture des stations de base respectivement 201, 202 et 203, est illustrée par le diagramme de la figure 4. La session RTP/RTCP est ici établie à l'initiative de la station mobile 101.
Dans un tel cas, plusieurs champs « AIso », suivis des adresses SIP respectives de toutes les stations mobiles parties à la communication de groupe traitée par le MCU 400 (ici les adresses « mob102@st202 » et « mob103@st203 » des stations mobiles 102 et 103 respectivement, sont inclus dans les messages INVITE transmis par la station de base 201 au serveur d'appel 500 ou au MCU 400. Le MCU 400 transmet alors un message INVITE à destination de chacune des autres stations de base 202 et 203 qui sont parties à la communication de groupe.
Dans ce cas, en outre, chacun des messages INVITE comprend par ailleurs, dans le corps du message, une description de la session RTP/RTCP conformément au protocole SDP (M. Handley et al., « SDP : Session Description Protocol », RFC 2327, IETF, avril 1998). Cette description est par exemple notée « Ses1 » sur le diagramme de la figure 4. L'utilisation de cette description permet l'échange d'informations entre les équipements participant à la communication de groupe, sur le choix des ports UDP, c'est-à-dire des ports des équipements utilisés par le protocole UDP (J. Postel, « User Datagram Protocol », RFC 768, IETF, août 1980), qui doivent être utilisés pour l'établissement des sessions RTP/RTCP, ainsi que sur la nature du profil des données échangées au cours de la session (audio ou vidéo, type de codage, fréquence d'échantillonnage, etc.). On notera que, dans le champ « AIso » du message de réponse transmis par le serveur d'appel 500 à la station de base
201 ayant envoyé le premier message INVITE, le serveur d'appel 500 peut également proposer un identificateur des stations mobiles correspondant, par exemple, à un numéro temporaire acquis lors de l'inscription.
A la figure 5, on a représenté la topologie de la session RTP/RTCP pour la communication de groupe initialisée selon la procédure décrite ci-dessus en regard du diagramme de la figure 4. Les paquets RTP 10 reçus par le MCU
400 de la station de base 201 , sont retransmis vers les stations de base 201,
202 et 203, après un traitement éventuel, sous la forme de paquets RTP 11, 12 et 13 respectivement. Par souci de clarté, les paquets RTCP qui sont transmis en réponse à la transmission des paquets RTP, ne sont pas représentés.
Les profils audio classiques définis dans la RFC 1889 mentionnée plus haut, ne permettent pas de traiter certaines opérations particulières des systèmes privés de radiocommunications professionnelles, comme la gestion de l'alternat dans les communications en mode semi-duplex. C'est pourquoi l'invention propose une adaptation de RTP permettant la gestion de l'alternat dans une communication en mode semi-duplex, individuelle ou de groupe.
Ainsi qu'il est représenté sur les schémas de la figure 3 et de la figure 5, les paquets RTP comprennent un entête HD, et un corps de données PL contenant la charge utile (« Payload » en anglais) c'est-à-dire les données audio ou vidéo proprement dites.
Le diagramme de la figure 6 représente le format de l'entête d'un paquet selon le protocole RTP (voir la RFC 1889, mentionnée plus haut). Cet entête comprend les champs suivant :
- un champ V (« Version »), dont la longueur est égale à 2 bits, qui contient un numéro de version du protocole (V=2 dans le cas représenté) ;
- un bit P (« Padding »), qui indique, lorsqu'il a la valeur logique 1 , la présence d'octets complémentaires à la fin du paquet RTP. Ces octets complémentaires permettent d'obtenir une longueur présentant certaines caractéristiques, par exemple à des fins de cryptographie ;
- un bit X (« Extension »), qui indique lorsqu'il a la valeur logique 1 , la présence d'un entête d'extension ;
- un champ CC (« CSRC Count »), d'une longueur égale à 4 bits, dont la valeur définit le nombre d'identificateurs de type CSRC (« Contributing Source
Identifiers », voir plus loin) suivant l'entête fixe.
- un bit M (« Marker »), qui est un bit de marquage défini par le profil, c'est-à-dire qu'il peut être utilisé en fonction des besoins de l'application ;
- un champ PT (« Payload Type »), d'une longueur égale à 7 bits, qui identifie le type de la charge utile (audio ou vidéo). Ce champ contient une valeur qui est soit un nombre enregistré auprès de l'IANA (« Internet Assigned Numbers Authority »), soit un nombre choisi dynamiquement dans une liste de valeurs utilisables et dont la signification peut être choisie par les équipements qui sont parties à la communication. - un numéro de séquence (« Séquence Number »), dont la longueur est égale à 16 bits, qui est initialisé avec une valeur aléatoire lors du début de l'émission d'un flux de paquets RTP par un équipement d'extrémité, et qui est incrémenté de une unité pour chaque paquet envoyé. Ce numéro permet à l'autre ou aux autres équipements d'extrémité de la session RTP de réordonner les paquets ou de détecter les paquets manquants en cas de perte de paquets RTP lors de leur transport à travers le réseau IP ;
- une estampille temporelle (« Timestamp »), dont la longueur est égale à 32 bits, et qui date l'instant de génération de la charge utile de chacun des paquets. Cette estampille permet ainsi aux équipements d'extrémité de calculer les fluctuations du temps de transport dans le réseau et ainsi, de prévoir les mémoires tampon nécessaires à la garantie d'une qualité de service optimale. L'estampille temporelle est obtenue à partir d'une horloge dont la résolution est suffisante pour permettre la synchronisation et le calcul de gigue (« Jitter » en anglais). La valeur initiale de l'estampille temporelle est déterminée de façon aléatoire, comme pour le numéro de séquence ;
- un identificateur de source de synchronisation SSRC (« Synchronisation Source identifier »), dont la longueur est égale à 32 bits, et qui désigne la source de la synchronisation des paquets RTP. Cette source peut être l'équipement d'extrémité qui génère le paquet RTP, mais elle peut également être un dispositif intermédiaire du réseau appelé entité de mixage (ou « mixer », en anglais), qui créé un nouveau flux de paquets RTP à partir de paquets RTP reçus des sources proprement dites, après en avoir modifié la synchronisation. Dans ce dernier cas, l'identificateur SSRC désigne l'entité de mixage ;
- un champ de longueur variable, contenant une liste d'identificateurs de sources contributives CSRC, chacun codé sur 32 bits, et dont le nombre est indiqué dans le champ CC mentionné plus haut (il peut y avoir entre 0 et 15 tels codes dans la liste). Ces sources contributives sont les équipements d'extrémité qui génèrent la charge utile du paquet RTP. Les codes CSRC sont insérés par les équipements de mixage, à partir des codes SSRC des sources contributives.
Les douze premiers octets sont présents dans tous les paquets RTP, alors que la liste des identificateurs CSRC n'est présente que si elle est insérée par une ou plusieurs entités de mixage.
Pour une charge utile constituée par des données codant de la voix, le format de la charge utile d'un paquet RTP est conforme au schéma de la figure 7. Les données utiles du paquet RTP correspondent aux champs suivant : - un champ NF (« Number of Frames »), codé sur 2 bits, qui contient une valeur à partir de laquelle est déterminé le nombre de trames de phonie qui sont contenues dans le paquet RTP ; - un bit C (« Encrypted »), qui est mis à la valeur logique 1 lorsque des informations relatives au cryptage (comprenant un identificateur d'algorithme et un identificateur de clé, voir plus bas) sont contenues dans le paquet RTP ;
- un bit P (« Protected »), qui indique que les trames sont protégées ; - un bit E (« Emergency »), qui, lorsqu'il est mis à la valeur logique 1, permet d'assurer un traitement spécifique au niveau de l'équipement d'extrémité qui reçoit le paquet RTP ;
- un champ PRIO (« Priority »), dont la longueur est égale à 3 bits, qui indique un niveau de priorité associé aux trames de phonie contenues dans le paquet RTP ;
- une adresse de source (« Source Address »), codée sur 24 bits, qui identifie l'adresse de source de l'utilisateur (c'est-à-dire ici la station mobile) qui émet les trames de phonie contenues dans le paquet RTP, étant observé que le code de source contributive CSRC identifie l'équipement d'extrémité (c'est-à- dire ici la station de base) qui génère le paquet RTP et non cet utilisateur ;
- un champ contenant, le cas échéant, les trames de phonie contenues dans le paquet RTP (« codée Frames »). Le nombre de ces trames dépend de la valeur du champ NF (voir ci-dessus). La longueur de ce champ est égale à 88 bits (11 octets). Chaque trame est alignée avec des bits de remplissage (« Padding ») mis à la valeur logique 0, si nécessaire. De plus, le champ complet est aligné avec des bits de remplissage, si nécessaire. Dans un exemple où les trames de phonie sont codées sur 11 octets, la longueur totale du champ est égale à 0 octets si NF=0, à 12 octets si NF=1 (avec un octet de remplissage), à 24 octets si NF=2 (avec deux octets de remplissage), ou à 36 octets si NF=3 (avec trois octets de remplissage) ;
- le cas échéant, un identificateur d'algorithme (« Algorithm ID »), codé sur 8 bits, qui identifie l'algorithme de cryptage mis en œuvre pour le cryptage des données ; et,
- le cas échéant, un identificateur de clé de cryptage (« Key ID »), codé sur 24 bits, qui contient la valeur d'une clé de cryptage utilisée par l'algorithme de cryptage.
On notera que l'identificateur d'algorithme et l'identificateur de clé ne sont contenus dans le paquet RTP que si le bit C a la valeur logique 1. Par ailleurs, d'autres champs que ceux décrits ci-dessus peuvent être contenus dans le paquet RTP. Ces champs n'apportant rien à la compréhension de l'invention, ils ne sont ni représentés à la figure 7, ni explicités dans la présente description. Ainsi qu'on l'a compris, des paquets RTP peuvent être transmis sans charge utile, lorsque la valeur contenue dans le champ NF est nulle (NF=0). On parle alors de paquets « vides » car ils ne contiennent aucune trame de phonie.
Le procédé selon l'invention va maintenant être décrit en référence aux organigrammes des figures 8 et 9, dans le cas d'une communication de groupe entre trois stations mobiles.
On rappelle que selon l'invention, les stations de base sont à la fois des équipements du sous-système radio du système de radiocommunications (qui assurent l'interface radio avec les stations mobiles), et des équipements d'extrémité du réseau de transport 300, qui émettent et reçoivent des paquets RTP.
A cet effet, considérons la configuration représentée à la figure 1 , où la station mobile 101 est sous la couverture de la station de base 201, la station mobile 102 est sous la couverture de la station de base 202 et la station mobile 103 sous la couverture de la station de base 203.
De plus, supposons que les stations mobiles 101 , 102 et 103 sont parties à une communication de groupe en mode semi-duplex, établie selon le protocole d'initialisation de session SIP illustré par le diagramme de la figure 4. Plus particulièrement, supposons par exemple que la station mobile 101 dispose du droit d'émettre pour l'alternat en cours et soit en train d'émettre. Les trames de phonie émises par la station mobile 101 sur le canal radio sont captées par la station de base 201. De là, elles sont transmises vers le MCU 400, à travers le réseau IP, dans des paquets RTP. Le MCU transmet ces paquets RTP vers les stations de base 201 , 202 et 203. Ces paquets RTP contiennent le code CSRC de la station de base 201 , qui est la source sélectionnée par le MCU pour contrôler l'alternat en cours. Les stations de base 202 et 203 les transmettent à leur tour, par l'intermédiaire de canaux radios respectifs, vers les stations mobiles respectivement 102 et 103. Le MCU 400, en tant qu'équipement central, effectue un arbitrage en cas de conflit entre des demandes du droit d'émettre provenant de différentes stations mobiles par l'intermédiaire des stations de base correspondantes, et notifie aux différentes stations de base le résultat de cet arbitrage. Il doit également pouvoir prévenir sans tarder les stations mobiles en phase de réception de la fin de l'alternat en cours, qui correspond à la cessation de l'émission de trames de phonie par la station mobile qui avait obtenu le droit d'émettre pour l'alternat en cours. De cette manière, ces stations mobiles en phase de réception ont la possibilité de demander le droit d'émettre; Pour ce faire, l'invention propose qu'un élément d'indication, inclus dans les paquets RTP, remplisse un certain nombre de fonctions pour la gestion de l'alternat.
Dans un exemple, l'élément d'indication peut avoir pour fonction, en combinaison avec le code CSRC, d'indiquer à la station de base sélectionnée par le MCU que le droit d'émettre lui a été accordé. Dans un exemple, l'élément d'indication a en effet cette fonction lorsqu'il est présent, avec une première valeur déterminée, dans les paquets RTP émis par le MCU vers les stations de base 201 , 202 et 203.
En outre, selon l'invention, l'élément d'indication a également pour fonction, lorsqu'il est présent avec une deuxième valeur déterminée, dans les trames RTP transmises vers le MCU depuis la station de base disposant du droit d'émettre, (i.e., celle dont le code CSRC est indiqué dans les paquets RTP transmis par le MCU) d'indiquer au MCU, d'une part que ladite station de base accuse réception du droit d'émettre qui lui a été accordé par le MCU, et d'autre part qu'elle demande le maintien de ce droit d'émettre.
En outre, l'élément d'indication a encore pour fonction lorsqu'il est présent, avec une troisième valeur déterminée, dans un paquet RTP transmis par le MCU vers les stations de base, d'indiquer aux stations de bases qu'elles peuvent demander le droit d'émettre. Celle d'entre elles qui sera sélectionnée par le MCU, prendra alors le contrôle du prochain alternat.
De préférence, l'élément d'indication a enfin pour fonction, lorsqu'il est présent avec une quatrième valeur déterminée dans un paquet RTP vide qui est transmis vers le MCU depuis la station de base disposant du droit d'émettre, d'indiquer au MCU que ladite station de base renonce à son droit d'émettre. Cela se produit lorsque l'alternat en cours est terminé c'est-à-dire lorsque la station mobile qui avait obtenu le droit d'émettre pour l'alternat en cours, cesse d'émettre des trames de phonie. Ces fonctions de l'élément d'indication apparaîtront plus clairement à la lecture d'un exemple de réalisation de l'invention qui va suivre. Dans un exemple, la première et la deuxième valeurs déterminées de l'élément d'indication sont identiques. De même, la troisième et la quatrième valeurs déterminées de l'élément d'indication sont identiques, et différentes des première et deuxième valeurs.
Concrètement, l'élément d'indication peut être un champ de longueur quelconque, qui code les valeurs déterminées précitées. Dans un mode de réalisation préféré, cet élément d'indication peut avantageusement être réduit à un bit, puisqu'il possède deux fonctions distinctes lorsqu'il est présent dans un paquet RTP transmis vers les stations de base depuis le MCU (en fonction de sa valeur parmi ladite première et ladite troisième valeurs déterminées différentes), et deux fonctions distinctes lorsqu'il est présent dans un paquet RTP transmis depuis une station de base vers le MCU (en fonction là encore de sa valeur parmi ladite deuxième . et ladite troisième valeurs déterminées différentes).
Dans un mode de réalisation préféré, il est proposé d'utiliser à cet effet le bit M de l'entête des paquets RTP en relation avec les mécanismes fondamentaux de fonctionnement de la MCU en tant qu'entité de mixage RTP. Ladite première valeur et ladite deuxième valeur de l'élément d'indication sont alors, par exemple, la valeur logique 1, alors que ladite troisième et ladite quatrième valeurs déterminées sont la valeur logique 0.
L'organigramme de la figure 8 illustre le fonctionnement d'une station de base en tant qu'équipement d'extrémité selon l'invention. On considère plus particulièrement l'exemple de la station de base 201. Supposons que, dans une étape 301 , la station mobile 101 manifeste son intention de transmettre par une signalisation appropriée à la station de base 201. En pratique, ceci se produit lorsque l'utilisateur de la station mobile 101 presse le bouton PTT (de l'anglais « Push-To-Talk ») et parle dans le microphone de la station mobile.
Si la station de base 201 reçoit déjà du MCU, à travers le réseau IP, des paquets RTP avec M=1 (ce qui signifie que le droit d'émettre est déjà accordé par le MCU à une autre station de base qui émet des paquets RTP qui sont ceux retransmis par le MCU avec M=1), et si la priorité associée à l'alternat en cours n'est pas inférieure à la priorité associée à la demande de la station mobile 201 , alors, dans une étape 302, elle en déduit que le droit d'émettre doit être refusé à la station mobile 101. En d'autres termes, la station de base 201 décide que la station mobile 101 ne peut pas prendre le contrôle de l'alternat. Dans une étape 303, la station de base 201 notifie alors à la station mobile 101 que le droit d'émettre lui est refusé. En pratique, ceci est indiqué à l'utilisateur par l'extinction d'un voyant lumineux de la station mobile 101 qui avait été allumé à l'étape 301. La station de base 201 continue d'émettre sur l'interface air les trames de phonie reçues dans les paquets reçus du MCU et la station mobile 101 reste en phase de réception. On notera que la priorité associée à la demande de la station mobile 101 peut être transmise par la signalisation précitée ou être calculée par la station de base 201 selon une méthode ad-hoc. De plus, la priorité associée à l'alternat en cours est indiquée dans les paquets RTP reçus par la station de base 201 (dans le champ PRIO précité).
Si, ce n'est pas le cas, soit que la station de base 201 ne reçoive aucun paquet RTP du MCU, soit que la priorité associée à la demande de la station mobile 101 soit supérieure à celle associée à l'alternat en cours, alors, à l'étape 302, la station de base 201 en déduit qu'elle peut accorder (au moins provisoirement) le droit d'émettre à la station mobile 101 qui a commencé à émettre des trames de phonie. La station de base 201 commence donc, dans une étape 304, à émettre des paquets RTP contenant ces trames de phonie, avec un bit M égal à la valeur logique 0 (M=0). Cette valeur a pour fonction d'indiquer au MCU que la station de base 201 demande le droit d'émettre. A partir de là, la station de base 201 commence à (ou continue à) recevoir des paquets RTP avec M=1. Comme indiqué plus haut, ces paquets contiennent un identificateur de source de synchronisation SSRC, qui correspond à l'identificateur de la MCU et un identificateur de source contributive CSRC, qui correspond à l'identificateur de la station de base qui dispose du droit d'émettre pour l'alternat en cours.
Si l'identificateur CSRC est différent de l'identificateur de la station de base 201 , celle-ci en déduit, dans une étape 305, qu'elle n'a pas été sélectionnée par le MCU, c'est à dire que le droit d'émettre ne lui a pas été accordé par le MCU, ou, en d'autres termes, que le contrôle de l'alternat a été accordé par le MCU à une autre station de base. Dans ce cas, dans une étape 306, elle interrompt l'émission de paquets RTP vers le MCU et notifie à la station de base 101 qu'elle n'a pas le droit d'émettre. L'étape 306 est équivalente à l'étape 303 précitée.
Si, à l'inverse l'identificateur CSRC des paquets RTP transmis par le MCU est celui de la station de base 201 , celle-ci en déduit, à l'étape 305, qu'elle peut continuer l'émission vers le MCU des paquets RTP contenant les trames de phonie émise par la station mobile 101 sur le canal radio. Toutefois, dans une étape 307, elle émet désormais ces paquets RTP avec le bit M mis à la valeur logique 1 (M=1 ), de manière à indiquer au MCU qu'elle accuse réception du droit d'émettre qui lui a été accordé par le MCU, et à indiquer qu'elle demande le maintien de ce droit d'émettre.
A tout moment, la station mobile 101 peut cesser d'émettre des trames de phonie sur le canal radio la reliant à la station de base 201 , si l'utilisateur relâche le bouton PTT. Cet événement est surveillé par la station de base 201 dans une étape 308. Si la station mobile 101 continue d'émettre des trames de phonie, des paquets RTP contenant ces trames sont générés par la station de base 201 et émis vers le MCU. Le procédé se poursuit en répétant l'étape 305 précitée. Si, à l'inverse, la station mobile cesse d'émettre des trames de phonie, alors, dans une étape 309, la station de base émet, vers le MCU, des derniers paquets RTP avec le bit M mis à la valeur logique 0. Ces derniers paquets contiennent les dernières trames de phonie émises par la station mobile 101 (et temporisées par passage dans une mémoire tampon de la station de base). Le bit M avec la valeur logique 0 a alors pour fonction d'indiquer au MCU que la station de base 201 renonce à son droit d'émettre. De cette manière, le MCU est informé de la cessation prochaine de l'émission des paquets RTP par la station de base 201 avant même que ces derniers paquets ne soient émis. Le MCU, ainsi qu'il apparaîtra plus loin en regard de la figure 9, peut alors alerter les autres stations de base en transmettant ces derniers paquets RTP avec le bit M mis à la valeur logique 0 pour indiquer que la fin de l'alternat en cours est proche, et qu'elle pourront bientôt demander (et, pour l'une d'entre elles, obtenir) le droit d'émettre.
Enfin, lorsque la station de base 201 a émis les dernières trames de phonie dans des paquets RTP avec le bit M mis à zéro (étape 309), elle émet, dans une étape 310, un certain nombre (par exemple trois) de paquets RTP vides, c'est-à-dire sans charge utile, et dont le bit M est à la valeur logique 0. Elle émet plusieurs tels paquets afin de minimiser les risques de non-réception par le MCU, qui peut se produire si le réseau perd des paquets en raison de la surcharge des routeurs. On rappelle que des paquets vides sont caractérisés par un champ NF contenant la valeur zéro. Ces paquets vides ont pour fonction de signaler réellement la fin de l'alternat en cours. Ils permettent au MCU de ne pas confondre la fin de l'alternat en cours avec une demande du droit d'émettre qui proviendrait d'une autre station mobile se situant sous la couverture de la même station de base 201 que la station mobile 101 qui contrôle l'alternat en cours. En effet, une telle demande aurait également la forme de paquets RTP contenant des trames de phonie (celles émises par cette autre station mobile et reçues par la station de base 201 via un autre canal radio), dont le bit M aurait aussi la valeur logique 0, et dont le champ CSRC contiendrait le même identificateur dé source (celui de la station de base 201 , qui serait la même source vue du MCU).
L'organigramme de la figure 9 illustre quant à lui le fonctionnement du MCU en tant qu'équipement central selon l'invention.
Le MCU est initialement dans un état de veille 700, dans lequel il ne reçoit aucun paquet RTP (on suppose que tous les participants à la conversation de groupe sont silencieux). On rappelle que, lorsqu'une station de base demande le droit d'émettre, elle émet vers le MCU des paquets RTP contenant des trames de phonie (paquets non vides) et avec le bit M à la valeur logique 0 (M=0).
Supposons qu'au moins une et peut-être plusieurs stations de base (aussi appelées sources) émettent de tels paquets RTP non vides avec M=0. Lorsque, dans une étape 701 , le MCU reçoit ces paquets il sélectionne, dans une étape 702, l'une des stations de base selon un algorithme de sélection ad- hoc. Lorsqu'une seule source émet des paquets RTP, cet algorithme sélectionne cette source. Lorsque plusieurs sources émettent des paquets RTP simultanément, l'algorithme de sélection peut faire intervenir, par exemple, la priorité, l'identité de l'émetteur ou tout autre critère.
Une fois la sélection effectuée, le MCU, dans une étape 703, transmet vers toutes les stations de base participant à la communication de groupe (à savoir, dans l'exemple, les stations de base 201 , 202 et 203) les paquets RTP reçus de la station de base sélectionnée (à savoir, dans l'exemple, la station de base 201), après avoir mis le bit M à la valeur logique 1 et avoir placé son propre identificateur dans le champ SSRC et celui de la source sélectionnée dans le champ CSRC (la valeur du champ CC du paquet RTP est alors égale à
1). Lorsque, dans une l'étape 711 , le MCU reçoit alors un nouveau paquet
RTP, le MCU vérifie d'abord, dans une étape 704, que ce paquet provient bien de la source sélectionnée. A cet effet l'identificateur CSRC du paquet est utilisé.
Si c'est le cas, alors le MCU vérifie, dans une étape 705, si la station de base demande le maintien de son droit d'émettre. C'est le cas si le paquet RTP a un bit M avec la valeur logique 1. Dans l'affirmative, ce paquet est transmis comme indiqué ci-dessus (retour à l'étape 703 ci-dessus). Si au contraire le bit M a la valeur logique 0, alors, dans une étape 706, le MCU vérifie s'il s'agit d'un paquet vide. Si le paquet est vide (c'est-à-dire s'il ne contient aucune trame de phonie), c'est que la source indique la fin de l'alternat. Alors, dans une étape 707, les derniers paquets RTP (ceux qui restent dans la mémoire tampon du MCU) sont transmis comme indiqué ci-dessus (en référence à l'étape 703 ci-dessus) mais avec le bit M mis à la valeur logique 0, afin d'indiquer aux stations de base la fin de l'alternat. Le MCU retourne ensuite dans l'état de veille 700. Si au contraire le paquet n'est pas vide (c'est-à-dire qu'il contient au moins une trame de phonie), le paquet RTP est émis avec le bit M à l'état logique 1 (on retourne à l'étape 703). Si, au contraire de l'hypothèse faite ci-dessus pour le test de l'étape 704, le paquet RTP reçu à l'étape 711 ne provient pas de la source sélectionnée, deux cas peuvent se présenter. Ils sont examinés dans une étape 708. Si la priorité de la source du paquet RTP reçu est supérieure à celle de la source sélectionnée, alors, dans une étape 709, la source du paquet RTP reçu est sélectionnée en tant que nouvelle source sélectionnée. Le paquet RTP reçu est alors transmis, en repassant à l'étape 703 avec, dans le champ CSRC, l'identificateur de la nouvelle source sélectionnée. Dans le cas contraire, le paquet est purement et simplement rejeté, dans une étape 710, et le MCU attend la réception d'un nouveau paquet (retour à l'étape 711).
Si l'on se reporte à la figure 8, on voit que lorsque, à l'étape 709, le MCU sélectionne une nouvelle source alors qu'une source est déjà en train d'émettre des paquets RTP, le test de l'étape 305 est vérifié pour cette dernière source, en sorte qu'elle cesse d'émettre vers des paquets RTP sur le réseau IP et fait cesser l'émission de trames de phonie par la station mobile concernée.
On voit également que dès qu'une station de base reçoit des paquets RTP avec le bit M à la valeur logique 0 (indiquant la fin prochaine de l'alternat en cours) elle est prête à accepter une demande d'émission d'une station mobile car le test de l'étape 302 ne sera pas vérifié, en sorte que, à l'étape 304, la station de base émettra des paquets RTP avec le bit M mis à la valeur logique 0.
La technique présentée ci-dessus permet donc à la fois d'assurer un arbitrage des demandes d'alternat par les stations de base, une préemption de la communication lorsque le droit d'émettre est demandé par une station de base avec une priorité supérieure, et une anticipation de la fin de l'alternat en cours, afin de préparer l'alternat suivant dès que la fin de l'alternat en cours est annoncée par l'émission par la station de base sélectionnée de paquets RTP vides avec le bit M mis à la valeur logique 0.
Une variante de la technique présentée ci-dessus permet de rendre plus rapide la détection de la fin de l'alternat en cours sans risque de fausse détection en cas de perte de paquets RTP. Le test de l'étape 706 qui se lit « Paquet vide avec M=0 ? », peut être remplacé par le test suivant : « (Paquet vide avec M=0) ou (paquet avec M=0, les trois paquets précédents n'ayant pas été tous perdus) ? ». Ainsi, le MCU détecte la fin de l'alternat en cours dès la réception du premier paquet avec le bit M mis à la valeur logique 0 et le MCU ne peut pas confondre un début d'alternat avec la fin de l'alternat en cours car, si les trois paquets vides avec M=0 émis par la station de base en fin d'alternat ont été perdus, un paquet non vide avec M=0 ne sera pas considéré comme indiquant la fin de l'alternat en cours. Les termes « précédent » et « premier » employés ci-dessus se réfèrent bien entendu à l'ordre des paquets RTP tel qu'il est indiqué par le numéro de séquence contenu dans l'en-tête des paquets RTP (voir figure 6). Ainsi que cela n'échappe pas à l'homme du métier, le fonctionnement décrit par les organigrammes des figures 8 et 9 peut requérir des temporisations de garde pour que les équipements du réseau IP, à savoir les équipements d'extrémité (stations de base) et l'équipement central (MCU), soient protégés contre les coupures de liaisons, que celles-ci aient une origine physique ou proviennent d'une défaillance ou d'une surcharge des routeurs.
La technique présentée ci-dessus peut s'étendre sans peine à des topologies de conférences multimédia plus complexe que celle présentée ci- dessus à titre d'exemple, et en particulier à une topologie telle que représentée à la figure 10. Dans cette topologie, un MCU 801 (ou MCU maître) assure le raccordement et l'arbitrage des alternats entre des sous-conférences gérées par les MCU 802 et 803 (ou MCU esclaves), ces derniers effectuant quant à eux l'arbitrage de l'alternat et le raccordement des stations de base respectivement 804 à 806, et 807 à 809. L'homme du métier perçoit que les organigrammes de. fonctionnement des stations de base et de la MCU maître sont identiques à ceux présentés précédemment en regard des figures 8 et 9 respectivement, tandis que le fonctionnement des MCU esclaves 802 ou 803 est conforme à l'organigramme de la figure 8 pour ce qui concerne leur liaison avec la MCU maître 801 , et à celui de la figure 9 pour ce qui concerne ses liaisons avec les stations de base 804-806 ou 807-809 respectivement. Ainsi, pour donner un simple exemple, le MCU esclave 802 émet en début d'alternat les paquets RTP reçus d'une station de base telle que 804 avec le bit M à la valeur logique 0, en laissant le bit M à la valeur logique 0 pour les paquets RTP transmis à destination de la MCU maître, tandis que le bit M est mis à la valeur logique 1 pour les paquets RTP retransmis vers les différentes stations de base 804 à 806 participant à la communication.
L'invention a été décrite ci-dessus dans un mode de réalisation préféré mais non limitatif. L'homme du métier appréciera que des variantes de réalisation sont envisageables sans s'écarter du principe de l'invention.
En particulier, les valeurs logiques respectives du bit de marquage M attribuées aux différentes fonctions de ce bit selon l'invention, peuvent naturellement être inversées. En outre, et notamment dans le cas où davantage de fonctions doivent être attribuées à cet élément d'indication, il est possible de remplacer le bit de marquage M par un mot de plusieurs bits, ou de l'associer à un ou plusieurs autres bits de manière que l'élément d'indication puisse avoir plus de deux valeurs distinctes.

Claims

REVENDICATIONS
1. Procédé de gestion de l'alternat pour une communication en mode semi-duplex entre au moins deux équipements d'extrémité (201-203) d'un réseau de transport à commutation de paquets en mode non connecté (300), dans lequel un élément d'indication (M) a pour fonction, lorsqu'il est présent avec une première valeur déterminée dans des paquets transmis depuis un (201) desdits équipements d'extrémité (201-203) vers un équipement central (400) assurant la gestion de la communication, d'indiquer audit équipement central (400), d'une part, que ledit équipement d'extrémité (201) accuse réception du droit d'émettre qui lui est accordé par ledit équipement central (400) et, d'autre part, qu'il demande le maintien de ce droit d'émettre.
2. Procédé selon la revendication 1 , suivant lequel ledit élément d'indication (M) a en outre pour fonction, lorsqu'il est présent avec une seconde valeur déterminée dans des paquets transmis par ledit équipement central (400) vers lesdits équipements d'extrémité (201-203), d'indiquer audits équipements d'extrémité que l'alternat en cours est terminé.
3. Procédé selon la revendication 1 ou la revendication 2, suivant lequel ledit élément d'indication (M) a en outre pour fonction, lorsqu'il est présent avec la seconde valeur déterminée dans au moins un paquet vide transmis vers ledit équipement central (400) depuis un équipement d'extrémité (201) disposant du droit d'émettre, d'indiquer audit équipement central (400) que l'alternat en cours est terminé.
4. Procédé selon la revendication 1 ou la revendication 2, suivant lequel ledit élément d'indication a en outre pour fonction, lorsqu'il est présent avec la seconde valeur déterminée dans au moins un paquet transmis vers ledit équipement central depuis un équipement d'extrémité disposant du droit d'émettre, d'indiquer audit équipement central (400), lorsqu'un nombre déterminé de paquets précédents n'ont pas tous été perdus par le réseau (300), que l'alternat en cours est terminé.
5. Procédé selon l'une quelconque des revendications 1 à 4, suivant lequel l'équipement central (400) retransmet, vers lesdits équipements d'extrémité (201-203), les paquets reçus dudit équipement d'extrémité (201) disposant du droit d'émettre et contenant l'élément d'indication (M) avec ladite première valeur déterminée aussi longtemps qu'il maintient le droit d'émettre accordé audit équipement d'extrémité.
6. Procédé selon l'une quelconque des revendications précédentes, suivant lequel le réseau de transport à commutation de paquets en mode non connecté (300) est un réseau IP (Internet Protocol).
7. Procédé selon la revendication 6, suivant lequel les paquets transmis sur le réseau (300) sont des paquets RTP (Real time Transport Protocol), la communication étant établie en tant que session RTP/RTCP (Real time Transport Control Protocol).
8. Procédé selon la revendication 7, suivant lequel l'élément d'indication est le bit de marquage (M) de l'entête des paquets RTP, ladite première valeur de l'élément d'indication étant la valeur logique 1 ou 0, et ladite seconde valeur de l'élément d'indication étant la valeur logique 0 ou 1 , respectivement.
9. Procédé selon la revendication 7 ou la revendication 8, suivant lequel la session RTP/RTCP est initiée selon le protocole d'initialisation de session SIP (Session Initialization Protocol).
10. Application d'un procédé selon l'une quelconque des revendications 1 à 9 à un système de radiocommunications pour la gestion de l'alternat pour des communications individuelles ou des communications de groupe entre des stations mobiles (101-103), suivant laquelle au moins certains desdits équipements d'extrémité (201-203) du réseau de transport à commutation de paquets en mode non connecté (300) sont des stations de base dudit système de radiocommunications.
11. Système de radiocommunications, notamment système privé de radiocommunications professionnelles, comprenant des stations de base (201- 203) et un équipement de réseau (400) reliés par un réseau de transport à commutation de paquets en mode non connecté (300), dans lequel lesdites stations de base comprennent des moyens pour la mise en œuvre d'un procédé selon l'une quelconque des revendications 1 à 9 en tant qu'équipement d'extrémité du réseau, et dans lequel ledit équipement de réseau comprend des moyens pour la mise en œuvre d'un procédé selon l'une quelconque des revendications 1 à 9 en tant qu'équipement central.
12. Système selon la revendication 11 , dans lequel ledit équipement de réseau (400) est un équipement de vidéoconférence multimédia.
13. Système selon la revendication la revendication 11 ou la revendication 12, dans lequel ledit réseau de transport à commutation de paquets en mode non connecté (300) est un réseau IP (Internet Protocol).
14. Station de base destinée à être utilisée en tant qu'équipement d'extrémité dans un système selon l'une des quelconque revendications 11 à
13.
15. Equipement de visioconférence multimédia destiné à être utilisé en tant qu'équipement central dans un système selon l'une des quelconque revendications 11 à 13.
EP02722377A 2001-03-29 2002-03-26 Procede de gestion de l'alternat pour une communication en mode semi-duplex a travers un reseau de transport a commutation de paquets Withdrawn EP1374607A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0104241A FR2823038B1 (fr) 2001-03-29 2001-03-29 Procede de gestion de l'alternat pour une communication en mode semi-duplex a travers un reseau de transport a commutation de paquets
FR0104241 2001-03-29
PCT/FR2002/001037 WO2002080596A1 (fr) 2001-03-29 2002-03-26 Procede de gestion de l'alternat pour une communication en mode semi-duplex a travers un reseau de transport a commutation de paquets

Publications (1)

Publication Number Publication Date
EP1374607A1 true EP1374607A1 (fr) 2004-01-02

Family

ID=8861686

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02722377A Withdrawn EP1374607A1 (fr) 2001-03-29 2002-03-26 Procede de gestion de l'alternat pour une communication en mode semi-duplex a travers un reseau de transport a commutation de paquets

Country Status (5)

Country Link
US (1) US7764633B2 (fr)
EP (1) EP1374607A1 (fr)
CA (1) CA2442676C (fr)
FR (1) FR2823038B1 (fr)
WO (1) WO2002080596A1 (fr)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6693663B1 (en) * 2002-06-14 2004-02-17 Scott C. Harris Videoconferencing systems with recognition ability
US7688764B2 (en) * 2002-06-20 2010-03-30 Motorola, Inc. Method and apparatus for speaker arbitration in a multi-participant communication session
EP1545129A1 (fr) * 2003-12-16 2005-06-22 Hutchison Whampoa Three G IP (Bahamas) Limited Pousser pour regarder : une application vidéo en continu de personne à personne
FI20031886A0 (fi) * 2003-12-22 2003-12-22 Nokia Corp Pakettipohjaisten palvelujen aloittaminen julkisessa mobiiliviestintäjärjestelmässä
CN1914876B (zh) * 2004-02-13 2011-07-20 诺基亚公司 定时体验质量的度量
DE102004009681B4 (de) * 2004-02-27 2007-05-31 Siemens Ag Verfahren zum Aufbauen einer Kommunikationsverbindung in einem Funkkommunikationssystem
US20050232241A1 (en) * 2004-03-31 2005-10-20 Geng Wu Method and apparatus for push-to-talk communications
KR20060067053A (ko) * 2004-12-14 2006-06-19 삼성전자주식회사 푸쉬투토크 오버 셀룰러 사용자 발언 시간 사용 방법 및그 시스템
KR100683339B1 (ko) * 2004-12-14 2007-02-15 엘지전자 주식회사 영상 기반 발신자 확인 시스템
US20060211383A1 (en) * 2005-03-18 2006-09-21 Schwenke Derek L Push-to-talk wireless telephony
US7536191B2 (en) * 2005-07-01 2009-05-19 Microsoft Corporation Push-to-talk communications in computing environments
WO2007131425A1 (fr) * 2006-04-26 2007-11-22 Huawei Technologies Co., Ltd. Procédé de transfert d'états de terminal utilisateur et de serveur, terminal utilisateur et serveur correspondants
CN102387149B (zh) * 2006-06-27 2014-08-06 华为技术有限公司 一种集群客户端用户状态迁移系统
US7894435B2 (en) * 2006-09-14 2011-02-22 Intel Corporation Indicator packets for process/forward decision
EP2103026B1 (fr) * 2006-12-21 2014-02-26 Thomson Licensing Procédé d'assistance de la correction aval des erreurs pour des données audio et vidéo temps réel dans des réseaux à protocole internet
US8255684B2 (en) 2007-07-19 2012-08-28 E.F. Johnson Company Method and system for encryption of messages in land mobile radio systems
US8059574B2 (en) 2007-07-19 2011-11-15 E.F. Johnson Company Method and system for peer-to-peer communication among sites
WO2010068151A1 (fr) * 2008-12-08 2010-06-17 Telefonaktiebolaget L M Ericsson (Publ) Dispositif et procédé pour synchroniser des données audio reçues avec des données vidéo
WO2011057012A1 (fr) * 2009-11-04 2011-05-12 Huawei Technologies Co., Ltd Système et procédé pour diffusion de contenus multimédias en continu
US8351896B2 (en) * 2010-01-15 2013-01-08 Research In Motion Limited Method to support emergency call through mesh network
US9252982B2 (en) 2010-10-21 2016-02-02 Marshall Jobe System and method for simulating a land mobile radio system
US8929290B2 (en) * 2011-08-26 2015-01-06 Qualcomm Incorporated In-band signaling to indicate end of data stream and update user context
CN103875261B (zh) * 2012-08-23 2018-06-05 高通股份有限公司 一种用于使用带内信令来指示数据流的结尾的方法、装置及计算机可读介质
US9774386B2 (en) 2013-03-15 2017-09-26 E.F. Johnson Company Distributed simulcast architecture
WO2014177345A1 (fr) * 2013-04-30 2014-11-06 Nokia Solutions And Networks Oy Identification des paquets d'utilisateur de liaison descendante
US9800460B2 (en) 2014-08-01 2017-10-24 E.F. Johnson Company Interoperability gateway for land mobile radio system
US9763260B2 (en) 2014-11-06 2017-09-12 E.F. Johnson Company System and method for dynamic channel allocaton
US10841357B1 (en) * 2019-09-12 2020-11-17 Dialpad, Inc. Using transport layer protocol packet headers to encode application layer attributes in an audiovisual over internet protocol (AVoIP) platform

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5170490A (en) * 1990-09-28 1992-12-08 Motorola, Inc. Radio functions due to voice compression
FI94994C (fi) * 1992-10-19 1995-11-27 Nokia Telecommunications Oy Hajapääsymenetelmä radiojärjestelmässä
US6366771B1 (en) * 1995-06-21 2002-04-02 Arron S. Angle Wireless communication network having voice and data communication capability
US5734643A (en) * 1995-10-23 1998-03-31 Ericsson Inc. Method and apparatus for transmitting data over a radio communications network
US6304567B1 (en) * 1996-11-26 2001-10-16 Lucent Technologies Inc. Methods and apparatus for providing voice communications through a packet network
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
GB2383504A (en) * 1998-06-03 2003-06-25 Orange Personal Comm Serv Ltd A video telephone for conferencing
US6301263B1 (en) * 1999-03-24 2001-10-09 Qualcomm Inc. Method and apparatus for providing fair access in a group communication system in which users experience differing signaling delays
US7203164B2 (en) * 1999-10-27 2007-04-10 Broadcom Corporation Voice architecture for transmission over a shared, contention based medium
EP1310109A2 (fr) * 2000-03-03 2003-05-14 QUALCOMM Incorporated Procede et appareil pour participer a des services de communication de groupe dans un systeme de communication existant

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO02080596A1 *

Also Published As

Publication number Publication date
FR2823038B1 (fr) 2003-07-04
US20040100987A1 (en) 2004-05-27
CA2442676A1 (fr) 2002-10-10
FR2823038A1 (fr) 2002-10-04
US7764633B2 (en) 2010-07-27
WO2002080596A1 (fr) 2002-10-10
CA2442676C (fr) 2007-09-04

Similar Documents

Publication Publication Date Title
CA2442676C (fr) Procede de gestion de l'alternat pour une communication en mode semi-duplex a travers un reseau de transport a commutation de paquets
US8249102B2 (en) Method and apparatus for session layer framing to enable interoperability between packet-switched systems
CN1985489B (zh) 在多媒体通信系统中提供不同服务的方法和装置
US8442196B1 (en) Apparatus and method for allocating call resources during a conference call
TWI239172B (en) Method and system for group communications
EP1931104B1 (fr) Procédé de contrôle de l'établissement de canaux de communication multimédia
JP4616386B2 (ja) マルチメディア・コンテンツを伝達するための方法および構成
US20080279119A1 (en) Group call capability query
JP2008541532A (ja) マルチメディアセッションのためのサービスの質（ＱｏＳ）パラメータのシグナリング
US7809843B1 (en) Globally unique identification in communications protocols and databases
FR2890818A1 (fr) Serveur de teleconference, terminal de telecommunications, procede de generation d'un message de commande de teleconference, procede de commande d'une teleconference, supports de memorisation...
KR20020081390A (ko) 그룹 통신 서비스를 제공하는 시스템 및 방법
FR3011414A1 (fr) Procede d'abonnement a des flux en provenance de clients multicast
FR2884091A1 (fr) Procede de fourniture de plusieurs services de communication en groupe, un systeme de services de communication en groupe ainsi qu'une unite de serveur de services de communication en groupe.
US10630656B2 (en) System and method of encrypted media encapsulation
EP2186290B1 (fr) Système et procédé pour identifier u n trafic multimédia de conférence crypté
US9374264B2 (en) System and method for transmitting and receiving session initiation protocol messages
WO2008046697A1 (fr) Enrichissement de la signalisation dans une session de communication de type ' push to talk ' par insertion d'une carte de visite
EP3361746B1 (fr) Systeme de gestion de flux media
WO2004100492A1 (fr) Procede et dispositif de synchronisation de flux de donnees
FR2979505A1 (fr) Procede d'insertion d'un equipement intermediaire permettant le controle a distance de la qualite d'une communication
Wild et al. Push‐to‐Talk: A First Step to a Unified Instant Communication Future

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030930

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: EADS SECURE NETWORKS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CASSIDIAN SAS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: EADS SECURE NETWORKS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20141001

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: H04Q0007220000

Ipc: H04W0084000000