FR 3025382 A1 20160304 FR 1401958 A 20140903 PROCEDE ET SYSTEME DE GESTION DE LA CONVERSION UNICAST / MULTICAST POUR LES COMMUNICATIONS MULTIMEDIA DE GROUPE DANS LES RESEAUX DE TELECOMMUNICATION L'invention concerne un procédé et système de gestion de la conversion unicast - multicast pour les communications multimédia de groupe dans des réseaux de télécommunication. Elle concerne par exemple la gestion des communications voix sur IP, la gestion de flux vidéo, etc.... Les mécanismes de communication multidiffusion connus sous le terme anglo-saxon «multicast» permettent à une entité, typiquement un terminal utilisateur, d'envoyer des paquets simultanément à plusieurs autres entités, contrairement aux communications point-à-point ou en anglo-saxon « unicast ». La mise en place de communications de groupe en utilisant uniquement des communications point-à-point nécessiterait beaucoup plus de flux pour arriver à un résultat similaire à celui obtenu en utilisant le mécanisme multicast. En revanche, dans certaines configurations réseau, les terminaux ne peuvent émettre du trafic multicast eux-mêmes. C'est le cas de certains réseaux professionnels de radio mobile connus sous l'abréviation « PMR » pour Professional Mobile Radio, où différents sites d'accès du réseau mobile LTE (long Term Evolution) sont interconnectés au travers d'un réseau coeur. La figure 1 représente un exemple de réseau de communication 1 dans lequel un coeur CMN 10 permet la communication entre plusieurs sites PMR 11, 12, 13. Sur les sites d'accès LTE, le routeur de sortie de l'EPC LTE (Evolved Packet Core Long Term Evolution) A1, A2, A3, sur la figure 1 agrège le trafic unicast, venant des terminaux mobiles Ui, selon des principes connus de l'homme du métier. Les routeurs de bordure, par exemple R1, au niveau du premier site 11 communiquent avec les autres sites 12, 13, en utilisant le multicast, ils reçoivent les flux à transmettre et les mettent en forme avant transmission vers les autres sites. 3025382 2 Dans le cas de la voix sur IP (VolP) dans les communications de groupe, un utilisateur appartient à un groupe donné et les paquets provenant d'un utilisateur sont transmis à tous les membres d'un groupe de communication qu'ils soient sur le même site que l'utilisateur émetteur ou sur 5 un autre site distant. Le traitement unicast/multicast sur les routeurs d'accès au site, routeur de bordure, dépend donc de la répartition des utilisateurs sur les différents sites et de leur participation, appartenance, aux différents groupes. Les utilisateurs peuvent envoyer et recevoir du trafic sur plusieurs groupes en même temps. L'un des problèmes posés est donc pour N 10 groupes de communication de pouvoir gérer les flux des utilisateurs en unicast et de les transformer en flux multicast pour les communications entre sites. La plupart des solutions connues du demandeur traitent le problème au niveau applicatif en utilisant des serveurs multimédia sur 15 chacun des sites. Ces serveurs reçoivent les flux unicast en provenance des utilisateurs présents sur leur site, puis communiquent avec les autres sites en utilisant des flux multicast. Cette conversion de type de flux au niveau applicatif induit des traitements importants sur les serveurs multimédia et se révèle difficile à mettre en oeuvre. 20 La demande de brevet US 2013/0121133 décrit un mécanisme applicatif pour passer d'une communication multicast à une communication unicast en cas de perte de portée radio, le multicast ayant en général moins de portée pour ne pas surconsommer des ressources radio. Le brevet US 6,970,926 divulgue un procédé de conversion 25 unicast/multicast au travers d'un serveur applicatif. La demande de brevet WO 2006/11022 décrit un procédé permettant la conversion au travers d'un serveur d'adaptation. Il permet à un utilisateur de communiquer en unicast sur un groupe multicast lorsque le multicast n'est pas disponible localement ou lorsque sa qualité locale est trop 30 faible. 3025382 Le brevet US 6,259,701 décrit un système permettant à un client unicast de se connecter sur un serveur pour lister les groupes multicast disponibles dans le réseau coeur et de s'y inscrire. Le serveur peut alors donner les informations au client unicast pour recevoir les paquets et active 5 sur le routeur de bordure la conversion unicast/multicast. La plupart des solutions techniques proposées dans l'art antérieur se trouvent au niveau applicatif et sont limitées dans le cas où le volume de paquets à traiter se révèle trop important. 10 L'idée de la présente invention consiste notamment à proposer une solution de traitement des paquets d'un flux multimédia au niveau réseau et non plus au niveau applicatif comme il est réalisé dans l'art antérieur. En fonctionnement normal, les paquets contenus dans un flux multimédia sont traités sans passer par un serveur de contenu. 15 Dans la description, on utilise indifféremment les termes paquets, données, pour désigner des informations contenues dans un flux de données émis par un utilisateur à transmettre vers d'autres utilisateurs. Le mot « uplink » désigne un flux entrant sur un site et le mot « downlink » un flux sortant d'un site. 20 L'invention concerne un système de gestion de la conversion unicast/multicast pour les communications multimédia de groupe dans un réseau de communication comportant un ou plusieurs sites comprenant au moins deux utilisateurs U1, U2, les utilisateurs communiquant selon un mode unicast au sein d'un site, un ou plusieurs routeurs de bordure Ri, un réseau 25 central agencé pour distribuer les flux de données entre les différents sites caractérisé en ce qu'il comporte au moins les éléments suivants : - Au niveau d'un site et d'un routeur de bordure Ri, - Un module de gestion de présence des utilisateurs Ui présents sur le site, 30 - Un module de gestion de groupes adapté à gérer l'appartenance d'un utilisateur à un groupe de communication Gi, 3025382 4 - Un module de contrôle émettant des règles de conversion flux entrant « uplink », flux sortant « downlink », à appliquer au niveau des données d'un flux entrant ou sortant d'un site et destiné à un ou plusieurs utilisateurs appartenant à un même groupe de 5 communication Gi, - Un module adapté à appliquer les règles de conversion émises « uplink, downlink », sur des données multimédia émises par un premier utilisateur U1 avant de diffuser les données modifiées par les règles vers un ou plusieurs utilisateurs Ui appartenant au même 10 groupe de communication Gi que le premier utilisateur U1 émetteur du flux, - Au niveau du noeud de réseau central, Des moyens de transmission multicast des flux de données multimédia d'un site vers un autre site. 15 Selon un mode de réalisation, le module de contrôle est composé: - D'une interface de gestion «API », pour la communication avec le gestionnaire de présence et le gestionnaire de groupes, - D'un module de configuration exécutant l'algorithme de génération des 20 règles, - D'un module de communication adapté à communiquer avec le module de traitement et lui transmettre les règles de modification des flux, et le module de traitement est composé, 25 - D'un module de communication avec le contrôleur, - D'un module de gestion des règles de modification décrivant l'ensemble des actions à effectuer sur les flux, - D'un module de filtre et d'actions sur les flux. Les règles générées sont choisies, par exemple, parmi la liste 30 suivante: la duplication des données, la modification d'en-tête de données, la 3025382 5 suppression du flux de données, l'envoi d'un flux de données sur un port de sortie, etc. Le module de traitement comporte, par exemple, une table de règles avec des degrés de priorité. 5 Les flux traités peuvent être composés de paquets IP. Selon un mode de mise en oeuvre, le système implémente le protocole OpenFlow. L'invention concerne aussi un procédé de gestion de la conversion unicast/multicast pour les communications multimédia de groupe dans un 10 réseau de communication comportant un ou plusieurs sites, comprenant au moins deux utilisateurs U , U2 communiquant selon un mode unicast au sein d'un site, un réseau central agencé pour distribuer des flux de données multimédia entre les différents sites, les utilisateurs Ui appartenant à un instant donné à un groupe de communication Gi, les sites communiquant au 15 moyen de routeurs Ri caractérisé en ce qu'il comporte au moins les étapes suivantes : - Générer un ensemble de règles de conversion d'un flux sortant ou « uplink » d'un site et d'un flux entrant ou « downlink » au niveau d'un site j donné, 20 - Appliquer une règle de conversion « uplink » sur un flux unicast émis par un utilisateur présent sur un site j afin de dupliquer le flux en un ou plusieurs flux unicast en fonction du nombre d'utilisateurs présents sur ce même site et convertir en flux multicast le flux unicast émis par l'utilisateur pour transiter sur le coeur du réseau vers un ou plusieurs 25 utilisateurs appartenant au même groupe de communication et présents sur des sites différents du site donné, - Appliquer une règle de conversion « downlink » sur un flux multicast entrant sur le site, afin de dupliquer en un ou plusieurs flux unicast le flux multicast entrant vers un ou plusieurs utilisateurs présents sur le 30 site. 3025382 6 Pour générer la règle de conversion « downlink » et la règle de conversion « uplink » pour un groupe de communication donné Gi on exécute, par exemple, les étapes suivantes : Pour chaque groupe de communication Gi 5 a Créer la règle «downlink» du groupe : dl(Gi) b. Ajouter dans le filtre l'identifiant du groupe Gi (adresse multicast) à la règle «downlink» dl(Gi) c. Ajouter à la règle dl(Gi) une action de duplication du paquet pour chaque utilisateur du sous-ensemble présents sur le site P(Uj, Gi) 10 d. Ajouter à la règle dl(Gi) une action de modification de l'adresse IP de destination pour chaque utilisateur P(Uj, Gi) e. Ajouter à la règle dl(Gi) une action d'envoi sur le port de sortie pour chaque utilisateur P(Uj, GO f. Ajouter à la règle dl(Gi) la suppression du paquet initial 15 g. Créer la règle «uplink» du groupe : ul(Gi) h. Ajouter dans le filtre l'identifiant local du groupe Gi (adresse unicast du terminal ou d'une passerelle ou « gateway » fictive, numéro de port) à la règle ul(Gi) S'il y a plus d'un membre du groupe Gi sur le même site: 20 i. Ajouter à la règle ul(Gi) une action de duplication pour chaque utilisateur P(Uj, GO j. Ajouter à la règle ul(Pi) une action de modification de l'adresse IP de destination pour chaque utilisateur P(Uj, Gi) k. Ajouter à la règle ul(Gi) une action d'envoi sur le port de sortie pour 25 chaque utilisateur P(Uj, GO Fin du si S'il y a des abonnés au groupe Gi sur d'autres sites : I. Ajouter une application de duplication sur le groupe multicast ul(Gi) m. Ajouter à la règle ul(Gi) une action de modification de l'adresse IP de 30 destination (multicast) pour le groupe Gi 3025382 7 n. Ajouter à la règle ul(Gi) une action d'envoi sur le port de sortie du groupe multicast Fin du si o. Ajouter à la règle ul(Gi) la suppression du paquet initial. 5 Le procédé peut comporter une étape où l'on utilise la règle « uplink » uniquement sur le site où un utilisateur possède le jeton permettant la prise de parole dans un réseau de communication « appuyer pour parler » Les flux de données multimédia sont, par exemple, des paquets 10 IP. Pour mettre en oeuvre le procédé, on utilise, par exemple, le protocole OpenFlow. D'autres caractéristiques et avantages de la présente invention 15 apparaîtront mieux à la lecture de la description d'exemples de réalisation donnés à titre illustratif et nullement limitatif, annexée des figures qui représentent : - La figure 1, un exemple de réseau de communication comprenant plusieurs sites communiquant entre eux grâce à la présence d'un 20 réseau de coeur multicast, - La figure 2, un diagramme représentant les modules présents sur un site et leur interconnexion, - La figure 3, un exemple d'interactions entre un processeur de traitement de paquets et un contrôleur pour la mise en oeuvre de 25 l'invention, - La figure 4 et la figure 5, un schéma de conversion de flux, et - La figure 6, une application qui utilise le protocole OpenFlow. La description qui suit est donnée à titre d'exemple illustratif pour 30 des paquets de données voix sur IP. 3025382 8 La figure 1 schématise un exemple de réseau comprenant trois sites 11, 12, 13, contenant chacun plusieurs utilisateurs Ui, interconnectés par un réseau de coeur multicast 10 comprenant des moyens 151, 152, 153, de réception et de transmission des flux entrant et sortant. 5 Le premier site 11 comprend par exemple trois utilisateurs Ui, U2, U3; Ul, U2 qui appartient à un premier groupe de communication G1, U3 est affilié à un deuxième groupe de communication G2. Le premier site 11 comprend un routeur de bordure R1 et une station de base Al. Le routeur de bordure a notamment pour fonction de recevoir les flux de données, les 10 mettre en forme pour leur transmission vers des utilisateurs appartenant au même groupe de communication, que ces utilisateurs appartiennent au même site ou à un site distant. Le deuxième site 12 comporte un utilisateur U4 affilié au deuxième groupe G2, une station de base A2, un routeur de bordure R2. 15 Le troisième site 13 comporte trois utilisateurs U5, U6, U7 ; U6 est affilié au groupe de communication G1, alors que les utilisateurs U5 et U7 sont affiliés à un troisième groupe de communication G3. Le site 13 comporte aussi une station de base A3 et un routeur de bordure R3. Un routeur de bordure est par exemple adapté à réaliser la 20 conversion unicast/multicast selon des étapes du procédé selon l'invention qui vont être détaillées ci-après. Au niveau de chaque routeur de bordure, pour un site donné, on trouve, selon l'exemple de la figure 2: - Un processeur de paquets 20, adapté à traiter les paquets de données 25 pour mettre en oeuvre une action nécessaire à leur transmission vers d'autres utilisateurs, par exemple, la duplication de paquets vers des utilisateurs appartenant au même groupe de communication ou la modification de leur contenu afin qu'ils puissent être reçus par des utilisateurs d'autres groupes de communication, etc.; 30 - Un contrôleur 21, ayant notamment pour rôle d'implémenter la logique, les règles de traitement des paquets en fonction de leur appartenance 3025382 9 au groupe de communication et de leur présence ou non sur le site d'un utilisateur émetteur, afin de configurer le processeur de paquets 20, en fonction d'informations et d'évènements qu'il reçoit des modules suivants; 5 - Un module de gestion de présence 22 des utilisateurs qui comporte et maintient à jour une liste des utilisateurs présents sur le site ainsi que leurs identifiants, leurs adresses IP unicast par exemple. Ces informations peuvent être fournies par le système LTE et sont collectées lors de l'entrée d'un utilisateur ou terminal dans le réseau 10 ou de son transfert via une procédure d'entrée connue sous l'expression anglo-saxonne hand-over et selon des étapes classiques ; - Un module de gestion de groupe 23 qui maintient la liste des utilisateurs participants aux différents groupes de communication. 15 Ces deux modules gestion de présence 22 et gestion de groupe 23 sont, par exemple, remis à jour au fur et à mesure du fait de la mobilité des utilisateurs dans le réseau de communication, appartenance à un groupe, changement de site, etc. Le flux de données F(Lii, Gk) à redistribuer d'un utilisateur émetteur 20 U1 vers les autres utilisateurs Ui qui appartiennent à un même groupe Gk de communication et qui peuvent être sur le même site de l'utilisateur émetteur ou non est transmis directement vers le processeur de paquets 20 comme il va être décrit en relation avec la figure 3. Le processeur de paquets a reçu préalablement des règles de traitement des paquets. 25 La figure 3 explicite la composition et le fonctionnement des différents modules du contrôleur et du processeur de paquets. Le contrôleur 21 est composé par exemple d'une interface de gestion, en anglo-saxon « management API » 210, qui permet de communiquer avec le gestionnaire de présence 22 et le gestionnaire de 30 groupes 23, d'un agent du protocole de configuration 211 (connu sous l'abréviation anglo-saxonne « CPA » pour Configuration Protocol Agent) 3025382 10 exécutant l'algorithme de génération de la configuration du processeur de paquets, par exemple des règles « OpenFlow », et d'un module 212 permettant la communication du contrôleur avec le processeur de paquets 20 et la transmission des configurations du système (utilisateurs, appartenance 5 au groupe, règles...). Le processeur de paquets 20 est composé, par exemple, d'un module de communication 202 (CPA) avec le contrôleur 21, d'un module de gestion des règles 201 décrivant l'ensemble des actions à effectuer sur les paquets de données entrant et qui correspondent à certains critères, et d'un 10 module 200 de filtre et d'actions sur les paquets. Les actions à exécuter sur les paquets entrants sont, par exemple, la duplication d'un paquet, la modification éventuelle d'en-tête d'un paquet, la suppression de paquets, l'envoi d'un paquet sur un port de sortie, etc. Le processeur de paquets reçoit sur une entrée 205 les paquets à transmettre et réémet ces paquets modifiés 15 ou dupliqués sur une sortie 206. Les règles élaborées pour la conversion de flux de données sont schématisées sur les figures 4 et 5. Elles sont définies pour chaque site j, pour chaque communication de groupe Gi, au niveau du routeur du site et impliquent le contrôleur et le processeur de paquets. 20 La figure 4 schématise les opérations 40 pour convertir du trafic ou flux sortant d'un site, ou trafic « uplink », pour chaque communication de groupe. Un flux unicast Fue émis par un utilisateur Ui sur un site j et appartenant à un groupe Gk est dupliqué en plusieurs flux unicast Fut, Fui 25 vers les utilisateurs U2, U3, présents sur ce même site j et appartenant à un groupe Gk et converti en flux « multicast » Fm afin de transiter sur le coeur de réseau et être distribué à d'autres utilisateurs présents sur d'autres sites du réseau de communication et appartenant à un groupe Gk. La conversion « uplink » est traduite dans le procédé selon 30 l'invention par une règle dite règle « uplink ». 3025382 11 La figure 5 schématise un exemple d'opérations 50 pour convertir du trafic entrant, flux entrants, sur un site ou « dowlink » au niveau du contrôleur 21 et du processeur de paquets 20. La règle associée est appelée « règle downlink ». Le flux multicast Fme appartenant à un groupe Gk entrant 5 sur un site j est dupliqué en plusieurs flux unicast Fui vers les utilisateurs Ui présents sur le site j et appartenant à un groupe Gk. Le contrôleur peut être co-localisé avec le routeur/switch, mais par obligatoirement. Le contrôleur 21 a notamment pour fonction d'utiliser la connaissance fournie par le gestionnaire de présence 22 ainsi que la 10 connaissance du gestionnaire de groupe 23 afin de créer, modifier, supprimer et envoyer les règles « uplink » et « downlink » de conversion des flux au processeur de traitement 20 des paquets. L'algorithme implémenté au niveau d'un routeur de bordure et décrit ci-dessous est exécuté à chaque fois qu'il y a une mise à jour des 15 informations de présence ou de groupe de communications dans le système; lorsque, par exemple, un utilisateur a changé de groupe, ou que son abonnement à un groupe a changé (inscription, désinscription). Les variables utilisées en entrée de l'algorithme sont les suivantes: 20 - les groupes Gi ainsi que leurs identifiants (ex : adresse multicast, port...), - les utilisateurs Uj présents sur le site j, - P(Uj, Gi) le sous-ensemble des utilisateurs présents sur un site j et participant aux groupes Gi. 25 Génération des règles « uplink » et « downlink » sur le site j Pour chaque groupe de communication Gi a. Créer la règle «downlink» du groupe : dl(Gi) b. Ajouter dans le filtre l'identifiant du groupe Gi (adresse multicast) à la règle «downlink» dl(Gi) 30 c. Ajouter à la règle dl(Gi) une action de duplication du paquet pour chaque utilisateur du sous-ensemble présents sur le site P(Uj, Gi) 3025382 12 d. Ajouter à la règle dl(Gi) une action de modification de l'adresse IP de destination pour chaque utilisateur P(Uj, Gi) e. Ajouter à la règle dl(Gi) une action d'envoi sur le port de sortie pour chaque utilisateur P(Uj, GO 5 f. Ajouter à la règle dl(Gi) la suppression du paquet initial g. Créer la règle «uplink» du groupe : ul(Gi) h. Ajouter dans le filtre l'identifiant local du groupe Gi (adresse unicast du terminal ou d'une gateway fictive, numéro de port) à la règle ul(Gi) S'il y a plus d'un membre ou utilisateur du groupe Gi sur le même site: 10 i. Ajouter à la règle ul(Gi) une action de duplication pour chaque utilisateur P(Uj, Gi) j. Ajouter à la règle ul(P0 une action de modification de l'adresse IP de destination pour chaque utilisateur P(Uj, Gi) k. Ajouter à la règle ul(Gi) une action d'envoi sur le port de sortie pour 15 chaque utilisateur P(Uj, Gi) Fin du si S'il y a des abonnés au groupe Gi sur d'autres sites : L Ajouter une application de duplication sur le groupe multicast ul(Gi) m. Ajouter à la règle ul(Gi) une action de modification de l'adresse IP de 20 destination (multicast) pour le groupe Gi n. Ajouter à la règle ul(Gi) une action d'envoi sur le port de sortie du groupe multicast Fin du si o. Ajouter à la règle ul(Gi) la suppression du paquet initial. 25 Les règles « uplink » et « downlink » élaborées au niveau du contrôleur 21 sont transmises au module processeur de paquets 20 qui va les appliquer sur les paquets entrant en fonction de la situation des utilisateurs participant au groupe de communication, situation qui est connue par le module de gestion des règles 201. 3025382 13 Selon une variante du procédé, les étapes h, i, j et k peuvent être répétées pour les différents utilisateurs P(Uj, Gi) afin que le trafic émis par un utilisateur du site ne soit pas dupliqué vers lui-même. Dans ce cas : - le filtre de la règle établie à l'étape h sera complété avec l'identifiant de 5 l'utilisateur Ui ; - la duplication concernant l'utilisateur à l'étape i est retirée. Cette variante aboutit à un nombre N de règles « uplink » pour chaque groupe Gi, N étant le nombre d'utilisateurs Ui présents sur le site et participant aux groupes Gi. 10 Pour connaître le nombre d'utilisateurs pour un groupe de communication présents sur les autres sites du réseau, (e.g. pour savoir s'il doit dupliquer les paquets sortant vers le coeur), plusieurs solutions sont possibles : sonder le protocole multicast pour savoir si la session du groupe est 15 active, interroger le gestionnaire de groupe, par exemple l'applicatif implémentant le plan de contrôle de l'application voix sur IP, VolP L'appartenance d'un paquet à un groupe de communication Gi peut être identifiée en utilisant, par exemple : 20 - l'adresse multicast pour les paquets entrants, - l'adresse unicast et le port pour les paquets sortants. Les utilisateurs sont identifiés, par exemple, grâce à leur adresse IP dans les paquets unicast : IP source pour les paquets émis par les utilisateurs, IP destination pour ceux qui sont reçus. 25 La figure 6 décrit une solution utilisant le protocole OpenFlow implémenté au niveau du module de communication permettant de pousser des règles de traitement de paquets d'un contrôleur 61 à un commutateur 60. La Figure 6 illustre la structure des règles OpenFlow stockées dans la table de commutation 63. Ces règles 62 comprennent des filtres sur les en-têtes 30 des paquets, 64, des actions 65 (envoi vers un port de sortie, modification d'un champ d'un en-tête, supression du paquet etc.) et des statistiques 66. 3025382 14 Pour mémoire le protocole OpenFlow est un protocole permettant l'administration à distance de la table de traitement de flux d'un commutateur ou « switch ». Cette table de traitement contient des règles qui sont appliquées sur chacun des paquets entrant dans le switch. 5 Une règle « uplink » ou « downlink » contient pour un flux, les actions à appliquer sur les paquets du flux et est constituée de deux parties : - Un filtre d'en-têtes des paquets permettant de préciser les caractéristiques des paquets de données appartenant au flux, port réseau de provenance, valeurs des différents champs dans les entêtes, 10 - Une liste des actions à appliquer sur les paquets du flux, par exemple, la modification des champs des en-têtes du paquet, la duplication, la suppression, l'envoi sur un port réseau, les actions étant enchaînées les unes à la suite des autres. Il est possible d'associer une priorité à chaque règle de la table. 15 Lorsqu'un paquet entre dans le processeur de paquets, ce dernier recherche la règle correspondant au flux contenant le paquet en parcourant par exemple les règles de la table par ordre de priorité décroissante. Un exemple de mise en oeuvre du protocole OpenFlow est détaillé ci-après. Le paquet traité par une règle sera dupliqué deux fois au sein du 20 site (avec les modifications d'en-tête requises) ainsi que vers l'extérieur : rname":"group-1-MC-rule ", "cookie":"0", "priority":"3","ingress-port":"1", "ether-type":"Ox0800", "dst-ip":"15.16.23.42","dst-port":"1987" ,"active":"true", "actions":"set-src-mac=4:8:15:16:23:42,set-src-ip=15.16.23.42, set-dst-mac=BC:F6:85:D7:7A:76,set-dst-ip=4.8.15.16,set-dst- 25 port=5001,output=65529, set-src-mac=4:8:15:16:23:42,set-src- ip=15.16.23.42,set-dst-mac=BC:F6:85:D7:7A:76,set-dst-ip=4.8.15.17, set-dst-port=5001,output=65529, set-src-mac=4:8:15:16:23:42,set-src-ip=15.16.23.42,set-dst-mac=BC:F6:85: D7:7A:76,set-dst-ip=224.0.0.42,output=2} 30 La première partie correspond au groupe de communication auquel la règle s'applique (group-1-MC-rule) ainsi que la correspondance à retrouver dans les en-têtes du paquet (adresse IP, port, ...). La seconde 3025382 15 partie correspond aux actions à effectuer sur le paquet; il s'agit des modifications de l'en-tête (set-*) et d'envoi sur un port de sortie (output=*). Dans le protocole OpenFlow, il n'y a pas besoin d'indiquer explicitement une action de duplication : le paquet initial est dupliqué avant chaque envoi sur 5 l'interface de sortie (action output). De même, le paquet initial est automatiquement supprimé. Selon une variante de réalisation, le procédé propose une gestion fine de l'alternat. Les systèmes gérant les communications de groupe utilisent un canal de contrôle pour organiser les interactions entre les 10 usagers. Par exemple, pour la communication « appuyer pour parler » connue sous l'expression anglo-saxonne « push-to-talk », un jeton ou token est utilisé pour s'assurer qu'un seul utilisateur peut parler à la fois. Sur pression d'un bouton, par exemple, le terminal utilisateur demande le token au système de gestion. En fonction de ses droits et de son importance, le 15 token lui est attribué ou non. Le procédé selon l'invention comporte, par exemple, une étape supplémentaire au niveau du processeur de paquets qui permet de bloquer le trafic unicast des utilisateurs n'ayant pas le token. Pour cela, la règle « uplink » est mise en place uniquement pour 20 l'utilisateur ayant le token et sera mise en place uniquement sur le site où se trouve l'utilisateur qui possède le token. Une règle « uplink » de filtrage avec une priorité plus basse est mise en place afin que tout le trafic entrant en unicast et n'ayant pas déjà été traité par la règle précédente soit détruit. L'invention permet également, si l'administrateur le souhaite, de 25 dupliquer le trafic sur un port dit miroir. Cela peut être utilisé pour enregistrer le trafic. Pour la mise en oeuvre avec le protocole OpenFlow, il suffit par exemple de rajouter aux règles obtenues par le procédé selon l'invention une action supplémentaire afin de dupliquer le trafic vers ce port miroir. 30 L'invention fournit un mécanisme de traitement de paquets, configuré en fonction de la connaissance de la présence des utilisateurs sur REVENDICATIONS1 - Système de gestion de la conversion unicast/multicast pour les communications multimédia de groupe dans un réseau de communication (1) comportant un ou plusieurs sites (11, 12, 13) et comprenant au moins deux utilisateurs (U1, U2), les utilisateurs communiquant selon un mode unicast au sein d'un site, un ou plusieurs routeurs de bordure (R), un réseau central (10) agencé pour distribuer les flux de données entre les différents sites caractérisé en ce qu'il comporte au moins les éléments suivants : / Au niveau d'un site (11, 12, 13) et d'un routeur de bordure (R1), - Un module de gestion de présence (22) des utilisateurs (Ui) présents sur le site, - Un module de gestion de groupes (23) adapté à gérer l'appartenance d'un utilisateur à un groupe de communication Gi, - Un module de contrôle (21) émettant des règles de conversion flux entrant « uplink », flux sortant « downlink », à appliquer au niveau des données d'un flux entrant ou sortant d'un site et destiné à un ou plusieurs utilisateurs appartenant à un même groupe de communication Gi, - Un module (20) adapté à appliquer les règles de conversion émises « uplink, downlink », sur des données multimédia émises par un premier utilisateur (U1) avant de diffuser les données modifiées selon les règles vers un ou plusieurs utilisateurs (Ui) appartenant au même groupe de communication Gi que le premier utilisateur (U1) émetteur du flux, / Au niveau du noeud de réseau central (10), De moyens de transmission multicast (15) des flux de données multimédia d'un site vers un autre site. 2 - Système selon la revendication 1 caractérisé en ce que : / le module de contrôle (21) est composé: 3025382 18 - D'une interface de gestion «API » (210), pour la communication avec le gestionnaire de présence (22) et le gestionnaire de groupes (23), - D'un module de configuration (211) exécutant l'algorithme de génération des règles, 5 - D'un module de communication (212) adapté à communiquer avec le module de traitement (20) et lui transmettre les règles de modification des flux, et en ce que ,( le module de traitement (20) est composé : - D'un module de communication (202) avec le contrôleur, 10 - D'un module de gestion des règles de modification (201) décrivant l'ensemble des actions à effectuer sur les flux, - D'un module (200) de filtre et d'actions sur les flux. 3 - Système selon l'une des revendications précédentes caractérisé en ce 15 que les règles générées sont choisies parmi la liste suivante : la duplication des données, la modification d'en-tête de données, la suppression du flux de données, l'envoi d'un flux de données sur un port de sortie, etc. 4 - Système selon l'une des revendications précédentes caractérisé en ce 20 que le module de traitement (20) comporte une table de règles avec des degrés de priorité. 5 - Système selon l'une des revendications précédentes caractérisé en ce que les flux sont composés de paquets IP. 25 6 - Système selon l'une des revendications précédentes caractérisé en ce qu'il implémente le protocole OpenFlow. 7 - Procédé de gestion de la conversion unicast/multicast pour les 30 communications multimédia de groupe dans un réseau de communication (1) comportant un ou plusieurs sites, comprenant au moins deux utilisateurs (U1, 3025382 19 U2) communiquant selon un mode unicast au sein d'un site, un réseau central (10) agencé pour distribuer des flux de données multimédia entre les différents sites (11, 12, 13), les utilisateurs (Ui) appartenant à un instant donné à un groupe de communication Gi, les sites communiquant au moyen 5 de routeurs (Ri) caractérisé en ce qu'il comporte au moins les étapes suivantes : - Générer un ensemble de règles de conversion d'un flux sortant ou « uplink » d'un site et d'un flux entrant ou « downlink » au niveau d'un site j donné, 10 - Appliquer une règle de conversion « uplink » sur un flux unicast émis par un utilisateur présent sur un site j afin de dupliquer le flux en un ou plusieurs flux unicast en fonction du nombre d'utilisateurs présents sur ce même site et convertir en flux multicast le flux unicast émis par l'utilisateur pour transiter sur le coeur du réseau vers un ou plusieurs 15 utilisateurs appartenant au même groupe de communication et présents sur des sites différents du site donné, - Appliquer une règle de conversion « downlink » sur un flux multicast entrant sur le site, afin de dupliquer en plusieurs flux unicast le flux multicast entrant vers un ou plusieurs utilisateurs présents sur le site. 20 8 - Procédé selon la revendication 7 caractérisé en ce que pour générer la règle de conversion « downlink » et la règle de conversion « uplink » pour un groupe de communication donné Gi on exécute les étapes suivantes : Pour chaque groupe de communication Gi 25 a. Créer la règle « downlink » du groupe : dl(Gi) b. Ajouter dans le filtre l'identifiant du groupe Gi (adresse multicast) à la règle «downlink» dl(Gi) c. Ajouter à la règle dl(Gi) une action de duplication du paquet pour chaque utilisateur du sous-ensemble présents sur le site P(Uj, Gi) 30 d. Ajouter à la règle dl(Gi) une action de modification de l'adresse IP de destination pour chaque utilisateur P(Uj, Gi) 3025382 20 e. Ajouter à la règle dl(Gi) une action d'envoi sur le port de sortie pour chaque utilisateur P(Uj, Gi) f. Ajouter à la règle dl(Gi) la suppression du paquet initial g. Créer la règle «uplink» du groupe : ul(Gi) 5 h. Ajouter dans le filtre l'identifiant local du groupe Gi (adresse unicast du terminal ou d'une gateway fictive, numéro de port) à la règle ul(Gi) S'il y a plus d'un membre du groupe Gi sur le même site: i. Ajouter à la règle ul(Gi) une action de duplication pour chaque utilisateur P(Uj, Gi) 10 j. Ajouter à la règle ul(P0 une action de modification de l'adresse IP de destination pour chaque utilisateur P(Uj, Gi) k. Ajouter à la règle ul(Gi) une action d'envoi sur le port de sortie pour chaque utilisateur P(Uj, Gi) Fin du si 15 S'il y a des abonnés au groupe Gi sur d'autres sites : I. Ajouter une application de duplication sur le groupe multicast ul(Gi) m. Ajouter à la règle ul(Gi) une action de modification de l'adresse IP de destination (multicast) pour le groupe Gi n. à la règle ul(Gi) une action d'envoi sur le port de sortie du groupe 20 multicast Fin du si o. Ajouter à la règle ul(Gi) la suppression du paquet initial. 9 - Procédé selon l'une des revendications 7 et 8 caractérisé en ce qu'il 25 comporte une étape où l'on utilise la règle « uplink » uniquement sur le site où un utilisateur possède le jeton permettant la prise de parole dans un réseau de communication « appuyer pour parler » PTT. 10 - Procédé selon l'une des revendications 8 à 9 caractérisé en ce que les 30 flux de données multimédia sont des paquets IP. 3025382 21 11 - Procédé selon l'une des revendications 8 à 10 caractérisé en ce que l'on utilise le protocole OpenFlow. 5