CA2442676C - 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

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,

2 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 statiohs 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 Comments ) ci-dessus. Ces conférences multimédia sont fondées sur la mise en oeuvre d'un équipement de vidéoconférence multimédia ou MCU (de 4'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éo-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 oeuvre 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'ii s'agisse de communications individuelles ou de communications de groupe.
Ce but est atteint grâce à un procédé de gestion de I'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

3 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 ledifi é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. Schuizrinne, 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 Controi 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 individuielles 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 oruvre du procédé en tant qu'équipement d'extrémité du réseau et dans lequel

4 ledit équipement de réseau comprend des moyens pour la mise en oruvre 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 3: 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 oruvre 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

5 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 10 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. II 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

6 PCT/FR02/01037 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 Also , 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).

7 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 Also 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 efi 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 Also , 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

8 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 Also 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

9 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 ( Sequence 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 5 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

10 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 nombré 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 ;

11 - 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 ( codec 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=O, à 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 oeuvre 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

12 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=O). 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 ('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 stâtion 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.

13 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

14 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é
5 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 10 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 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

15 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

16 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 mobile 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 base20l 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

17 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 canai radio), dont le bit M
aurait aussi la valeur logique 0, et dont le champ CSRC contiendrait le même identificateur de 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=O.

18 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).

19 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 çours) elle est prête à accepter une demande d'émission d'une stâtion 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 stâtion 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=O, 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 5 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).
10 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 15 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

20 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

21 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 (15)

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, pue 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 1 à 5, suivant lequel le réseau de transport à commutation de paquets en mode non connecté (300) est un réseau IP

(lnternet 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 des 1 à
9, 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 (201203) 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 oeuvre 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 oeuvre 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. Équipement de vidéoconférence multimédia destiné à être utilisé en tant qu'équipement central dans un système selon l'une des quelconque revendications 11 à
13.