FR2949931A1 - Procedes et dispositifs de transmission d'un flux de donnees, produit programme d'ordinateur et moyen de stockage correspondants. - Google Patents

Abstract

La présente invention concerne un procédé de transmission d'un flux de données par un dispositif émetteur vers un dispositif récepteur via un réseau de communication, les données du flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données. Le procédé est tel que le dispositif émetteur effectue des étapes consistant à : - déterminer des paramètres d'encodage de parité d'un ensemble de données dudit flux ; - générer des données de parité à partir dudit ensemble de données en utilisant lesdits paramètres d'encodage de parité déterminés ; - transmettre les données de parité générées audit dispositif récepteur via ledit réseau de communication, par utilisation d'un protocole de transport avec acquittement de données.

Description

. OMA NE DE L'INVENTION La présente invention concerne un procédé et un dispositif de transmission d'un flux de données, un produit programme d'ordinateur permettant la mise en oeuvre des étapes du procédé de transmission lorsqu'il 5 est exécuté par un processeur, ainsi qu'un moyen de stockage d'informations stockant le programme d'ordinateur. L'invention se situe dans le domaine technique des réseaux de communication. La présente invention trouve une application. particulière dans la mise en 10 oeuvre de tunnels de communication pour la création de réseaux privés virtuels via le réseau Internet. 2. ARRIERE-PLAN TECHNOLOGIgU La technologie des réseaux de type VPN (pour Réseaux Privés Virtuels en français, ou Virtual Private Networks en anglais) offre une 15 solution intéressante pour communiquer de manière transparente en temps réel et en continu, de manière sécurisée entre des individus partageant un même centre d'intérêt tout en utilisant l'infrastructure réseau Internet, peu sûre mais bon marché. Pour communiquer de manière transparente et s'affranchir des adresses 20 non routables, les réseaux de type VPN utilisent une encapsulation particulière (appelée tunnellisation en français, ou tunneling en anglais) mettant en ceuvre un tunnel de communication. Cette opération consiste à encapsuler un protocole de niveau A (appelé protocole embarqué ou véhiculé ou passager) dans un protocole de niveau B (appelé protocole de transport ou véhiculant) 25 grâce à un protocole d'encapsulation C. Ainsi, le protocole de transport B traite le protocole embarqué A comme s'il s'agissait de données utiles. La Figure 3, décrite en détail par la suite, présente un exemple d'encapsulation de paquets dans un réseau de type VPN de niveau 2. Le protocole embarqué A est un protocole de la couche 2 du modèle OSI. On parle 30 aussi de tunnel de niveau 2. De tels tunnels de communication sont utilisés pour interconnecter deux réseaux LAN (pour Local Area Networks en anglais, ou réseaux locaux en français) afin de créer un réseau LAN virtuel comprenant les deux réseaux LAN originaux. Une illustration de configuration de réseau de type VPN basée sur une technique de tunnellisation est illustrée sur la Figure 1 (décrite en détail par la suite). Le tunnel est établi entre deux têtes de tunnel 101 et 102, et chaque paquet (aussi appelé trame) issu d'un premier réseau LAN 103 est envoyé à un second réseau LAN 104 après avoir été encapsulé par la tête de tunnel 101 située sur le premier réseau LAN 103 la tête de tunnel 102 sur le second réseau LAN 104 reçoit le paquet via le tunnel, dés-encapsule le paquet et l'envoie sur le second réseau LAN 104. Les équipements 108-113 connectés à chacun des premier et second réseaux LAN sont virtuellement connectés à un même réseau LAN. Dans cet exemple, les têtes de tunnel (ou TEP pour Tunnel End Point en anglais) ne sont pas intégrées aux passerelles. La demande de brevet publiée sous le numéro EP 2 020 799 décrit un réseau de type VPN comportant plusieurs porteuses, chacune de ces porteuses utilisant un protocole de transport distinct. Dans la suite de la description, on désigne ce type de tunnel sous le terme de tunnel multi-transport. Chaque tête de tunnel dispose alors d'un ensemble de porteuses aux caractéristiques distinctes. Afin de transmettre des données d'un réseau LAN à un autre, il est nécessaire d'adapter la transmission des données d'un réseau LAN à l'autre aux besoins applicatifs ainsi qu'aux variations de conditions de transmission sur le réseau Internet. La demande de brevet publiée sous le numéro EP 2 020 799 décrit un tunnel constitué de manière préférentielle d'une porteuse de type TCP (pour Transmission Control Protocol ) et une porteuse de type UDP ( User Datagram Protocol ). Le protocole TCP est un protocole de transmission avec demande de répétition automatique (ou ARQ pour Automatic Repeat Request en anglais) qui est basé sur des mécanismes de contrôle de congestion et de retransmission, et assure ainsi la délivrance de chaque paquet vers la destination. Le protocole UDP est un protocole beaucoup plus simple à mettre en oeuvre et plus rapide, qui ne tient pas compte de l'ordre des trames et ne gère pas d'acquittement.

Le protocole UDP permet alors une délivrance des données avec une latence maîtrisée, cependant sans aucune garantie vis-à-vis de la perte de données. Dans un tunnel, la porteuse UDP est donc utilisée pour convoyer des données (flux passager) à forte contrainte temporelle, comme par exemple des données audiovisuelles. Ces données audiovisuelles sont par exemple transmises sur un réseau LAN selon le protocole RTP (pour Real-Time Transport Protocol , tel que défini par la norme RFC-3550). Des telles données ne sauraient être transmises via la porteuse TCP du tunnel, car en cas de taux d'erreur élevé sur le réseau Internet, la porteuse TCP générerait de nombreuses retransmissions de paquet, afin d'assurer la délivrance des données à l'autre tête de tunnel. Un tel comportement est catastrophique pour la latence de bout en bout du flux RTP véhiculé. De plus, il est à noter que le contrôle de flux et le contrôle de congestion mis en oeuvre par le protocole TCP provoquent, selon l'évolution de la charge du réseau, des variations brutales dans le cadencement de la transmission des données. Maîtriser la latence de transmission de bout en bout, tout en restant robuste vis-à-vis de la perte de données, a une influence significative sur la qualité perçue ( QoE pour Quality of Experience en anglais) par l'utilisateur. En effet, la moindre interruption dans la transmission du flux (c'est- à-dire une perte sur la porteuse UDP du tunnel, un retard de la porteuse TCP amenant à une obsolescence des données véhiculées) se traduit par une dégradation du flux passager. Ceci se traduit par exemple au niveau de l'utilisateur par une coupure du morceau musical écouté ou de la vidéo affichée. Il n'existe pas de méthode satisfaisante de transport adapté aux applications multimédia temps réel ( streaming en anglais), permettant de maintenir la qualité perçue (QoE) par l'utilisateur malgré les variations des conditions de transmission dans le cadre de la mise en oeuvre de réseaux de type VPN. La norme RFC-2198 ( RTP Payload for Redundant Audio Data ) propose d'insérer dans un flux de type RTP des copies redondantes de données audio présentes dans ce flux RTP, afin que le récepteur du flux puisse corriger les perturbations liées à des pertes occasionnées lors du transport du flux RTP. La norme RFC-2198 propose donc d'appliquer un mécanisme de type FEC (pour Forward Error Correction en anglais), c'est-à-dire un code correcteur d'erreur (ou code de parité), pour lutter contre les pertes de paquets lors de la transmission. Ainsi, chaque paquet RTP contient une donnée audio pour un intervalle de temps donné, et une copie (plus compressée) de la donnée audio d'un intervalle de temps précédent. Ceci permet la recomposition approximative des échantillons audio perdus à partir du décodage du paquet suivant. Cependant cette solution crée une large sur-occupation ( overhead en anglais) de la bande passante afin de transporter les données en doublon ; et est donc plus adaptée aux environnements sans-fil WLAN (pour Wireless Local Area Network en anglais) sujets à des pertes de données qu'aux environnements WAN (pour Wide Area Network en anglais) où la non-délivrance d'un paquet résulte d'une congestion sur le chemin de transmission. En effet, dans des environnements WAN, une telle solution peut aggraver les phénomènes de congestion rencontrés sur le chemin de transmission. La redondance des informations ne fait qu'aggraver le phénomène de congestion sur le réseau global WAN où la bande passante est limitée. 3. OBJECTIFS DI L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. En particulier, l'invention vise à maintenir la qualité perçue (QoE) par l'utilisateur dans le cadre de la transmission d'un flux de données (par exemple de type multimédia), malgré les variations des conditions de transmission. Un objectif de l'invention est plus particulièrement de fournir une classe de service de transport, dans un environnement réseau de type VPN, orientée qualité et latence , c'est-à-dire qui permette une délivrance fiable et rapide d'un flux multimédia. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant de minimiser les effets indésirables sur 30 d'autres flux en cours de transmission.

Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant de limiter les ressources mémoire nécessaires en réception. Au moins un mode de réalisation de l'invention a également pour objectif 5 de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4, EXPOSE DE L'INVENTION Selon un premier aspect, dans au moins un mode de réalisation, l'invention concerne un procédé de transmission d'un flux de données par un 10 dispositif émetteur vers un dispositif récepteur via un réseau de communication, les données du flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données. Le procédé est tel que le dispositif émetteur effectue des étapes consistant à : déterminer des paramètres d'encodage de parité d'un ensemble de 15 données dudit flux générer des données de parité à partir dudit ensemble de données en utilisant lesdits paramètres d'encodage de parité déterminés ; transmettre les données de parité générées audit dispositif récepteur via ledit réseau de communication, par utilisation d'un protocole de 20 transport avec acquittement de données. Ainsi, dans au moins un mode de réalisation, l'invention tire avantage de la faible latence du protocole de transport sans acquittement de données, tel que le protocole UDP par exemple, ainsi que de la robustesse du protocole de transport avec acquittement de données, tel que le protocole TCP par exemple. 25 Avantageusement, les paramètres d'encodage de parité sont déterminés en fonction d'une information de congestion dudit réseau de communication. Ainsi, en prenant en compte l'état de la transmission entre le dispositif émetteur et le dispositif récepteur pour définir les paramètres d'encodage de parité, le supplément de bande passante nécessaire pour introduire la 30 redondance visant à accroître la robustesse. de la transmission du flux est maîtrisé et n'amplifie pas un phénomène de perte de données sur le réseau de communication.

Avantageusement, lesdits paramètres d'encodage de parité sont déterminés en fonction d'une fenêtre de congestion dudit protocole de transport avec acquittement de données. Ainsi, la quantité de données de parité transmises en utilisant le protocole 5 de transport par acquittement est contrôlée de manière à ne pas perturber d'autres flux en cours sur le réseau de communication. De manière préférentielle, la quantité des données de parité générées à partir desdits paramètres d'encodage de parité est égale à une marge restante dans ladite fenêtre de congestion. 10 Ainsi, la marge restante, donc inutilisée dans la fenêtre de congestion du protocole par acquittement, est intégralement utilisée à la transmission de données de parité, apportant un maximum de robustesse à la transmission du flux de données, sans dégrader les conditions de transmission sur le réseau de communication. 15 Avantageusement, une fenêtre d'encodage est définie sur ledit flux et un desdits paramètres d'encodage de parité déterminé correspond à une sélection dudit ensemble de données parmi ladite fenêtre d'encodage. Ainsi, la quantité de données de parité est maîtrisée et peut être rendue constante. Un ajustement peut alors s'opérer sur la quantité de données du flux 20 servant a générer (ou encoder) les données de parité. Ceci permet donc de pouvoir rendre robuste de manière partielle, c'est-à-dire sur une portion seulement du flux de données, la transmission de ce flux de données via le réseau de communication. Ainsi, le dispositif émetteur est apte à réagir rapidement à des changements de conditions de transmission sur le réseau de 25 communication, sans avoir à adapter la fenêtre d'encodage, c'est-à-dire en contrôlant la quantité de données de parité transmises de manière à ne pas aggraver des conditions de transmission déjà perturbées. Selon un mode de mise en oeuvre avantageux de l'invention, le dispositif émetteur fournit au dispositif récepteur une indication de ladite fenêtre 30 d'encodage et des données de ladite fenêtre d'encodage utilisées pour générer lesdites données de parité Ainsi, le dispositif récepteur est informé des modifications effectuées par le dispositif émetteur. Ceci permet donc au dispositif récepteur de réagir de manière synchronisée avec le dispositif émetteur aux changements de conditions de transmission sur le réseau de communication, sans que la fenêtre d'encodage ne soit modifiée, c'est-à-dire tout en contrôlant la quantité de données de parité transmises de manière à ne pas aggraver des conditions de transmission déjà perturbées. Avantageusement, le dispositif émetteur effectue des étapes consistant à : déterminer une valeur de marge restante dans une fenêtre de congestion dudit protocole de transport avec acquittement ; ajuster la taille de ladite fenêtre d'encodage en fonction de la valeur de marge restante déterminée. La valeur de marge restante est par exemple déterminée grâce à une valeur de fenêtre de congestion d'une session utilisant le protocole par acquittement et une valeur de débit de données transmises par le dispositif émetteur en utilisant cette session. De manière avantageuse, la taille de ladite fenêtre d'encodage est en outre modifiée en fonction d'une évolution de taux de perte de transmission entre le dispositif émetteur et le dispositif récepteur.

Ainsi, si les conditions de transmission entre le dispositif émetteur et le dispositif récepteur s'améliorent, la redondance apportée par les données de parité peut être diminuée. Avantageusement, le procédé comprend en outre des étapes consistant à déterminer de nouveaux paramètres d'encodage de parité dudit ensemble de données dudit flux, en fonction d'une nouvelle information de congestion dudit réseau de communication ; - générer des données de parité à partir dudit ensemble de données en utilisant des paramètres d'encodage de parité précédents.

De plus, dans le cas où une nouvelle quantité de données de parité générées selon les nouveaux paramètres d'encodage de parité est inférieure à une précédente quantité de données de parité résultant d'un encodage selon les paramètres d'encodage de parité précédents, le procédé comprend en outre des étapes consistant à séléctionner des données de parité générées selon lesdits paramètres d'encodage de parité précédents pour une quantité égale à ladite nouvelle quantité de données de parité ; - transmettre lesdites données sélectionnées audit dispositif récepteur via ledit réseau de communication, par utilisation dudit protocole de transport avec acquittement de données. Ainsi, cela évite de modifier intempestivement les paramètres d'encodage 10 et de devoir reconfigurer le module d'encodage permettant de générer les données de parité. Ceci est particulièrement avantageux dans le cas où les conditions de transmission se sont améliorées pour une courte durée. De plus, l'application des paramètres d'encodage précédents selon le procédé de l'invention permet de conserver la robustesse nécessaire à la communication 15 tout en permettant de déterminer l'évolution des conditions de transmission, de manière à évaluer la nécessité de basculer vers de nouveaux paramètres d'encodage. De manière préférentielle, l'étape consistant à générer lesdites données de parité comprend une des étapes du groupe suivant : 20 appliquer un code correcteur de type Reed-Solomon sur ledit ensemble sélectionné appliquer une opération ou-exclusif sur les données dudit ensemble sélectionné. Ainsi, l'invention est applicable avec divers codes correcteur d'erreur pour 25 encoder les données de parité, comme les plus communs, tel qu'un code de type Reed-Solomon, ou les plus simples, tel qu'un code basé sur une utilisation de OU-EXCLUSIFS. De manière préférentielle, un tunnel est mis en oeuvre entre le dispositif émetteur et le dispositif récepteur, les données dudit flux sont transportées via 30 une porteuse sans acquittement dudit tunnel, et les données de parité sont transportées via une porteuse avec acquittement dudit tunnel. 2949931 '9 Ainsi, une tête de tunnel peut mettre en oeuvre l'invention afin de gérer, avec une latence réduite et une robustesse de transmission à coût (en termes de ressources de transmission) maîtrisée, des transmissions de flux de données entre deux réseaux LAN.

De plus, l'invention concerne un procédé de transmission d'un flux de données par un dispositif émetteur vers un dispositif récepteur via un réseau de communication, les données dudit flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données. De plus, le dispositif récepteur effectue des étapes consistant à : - obtenir des paramètres d'encodage de parité d'un ensemble de données dudit flux ; recevoir des données de parité via ledit réseau de communication, par utilisation d'un protocole de transport avec acquittement de données; - obtenir ledit ensemble de données dudit flux à partir de données du flux reçues par utilisation du protocole de transport sans acquittement de données et des données de parité reçues par utilisation du protocole de transport avec acquittement de données. Ainsi, dans au moins un mode de réalisation, l'invention tire avantage de la faible latence du protocole de transport sans acquittement de données, tel que le protocole UDP par exemple, ainsi que de la robustesse du protocole de transport avec acquittement de données, tel que le protocole TCP par exemple, de manière à permettre la reconstruction du flux de données. Selon un second aspect, dans au moins un mode de réalisation, l'invention concerne un dispositif émetteur d'un flux de données vers un dispositif récepteur via un réseau de communication, les données dudit flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données. De plus, le dispositif émetteur comprend - des moyens de déterminer des paramètres d'encodage de parité d'un ensemble de données dudit flux ; - des moyens de générer des données de parité à partir dudit ensemble sélectionné en utilisant lesdits paramètres d'encodage de parité déterminés ; - des moyens de transmettre les données de parité générées audit dispositif récepteur via ledit réseau de communication, par utilisation d'un protocole de transport avec acquittement de données. Avantageusement, lesdits paramètres d'encodage de parité sont déterminés en fonction d'une information de congestion dudit réseau de communication.

Ainsi, en prenant en compte l'état de la transmission entre le dispositif émetteur et le dispositif récepteur pour définir les paramètres d'encodage de parité, le supplément de bande passante nécessaire pour introduire la redondance visant à accroître la robustesse de la transmission du flux est maîtrisé et n'amplifie pas un phénomène de perte de données sur le réseau de communication. Préférentiellement, un tunnel est mis en oeuvre entre le dispositif émetteur et le dispositif récepteur, et le dispositif émetteur comprend des moyens de transmettre les données dudit flux via une porteuse dudit tunnel utilisant ledit protocole de transport sans acquittement de données - des moyens de transmettre les données de parité via une porteuse dudit tunnel utilisant le protocole de transport avec acquittement de données." Selon un troisième aspect, dans au moins un mode de réalisation, l'invention concerne un dispositif récepteur d'un flux de données en provenance d'un dispositif émetteur via un réseau de communication, les données dudit flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données. De plus, le dispositif récepteur comprend des moyens d'obtenir des paramètres d'encodage de parité d'un ensemble de données dudit flux ; des moyens de recevoir des données de parité via ledit réseau de communication, par utilisation d'un protocole de transport avec acquittement de données ; des moyens d'obtenir ledit ensemble de données dudit flux à partir de données du flux reçues par utilisation du protocole de transport sans acquittement de données et des données de parité reçues par utilisation du protocole de transport avec acquittement de données. Selon un quatrième aspect, dans au moins un mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur. Ce produit programme d'ordinateur comprend des instructions pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur.

Selon un cinquième aspect, la présente invention propose également un moyen de stockage, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque les informations stockées sont lues par l'ordinateur.

Dans un mode de réalisation, ce moyen de stockage est totalement amovible. Les caractéristiques et avantages particuliers de ce dispositif émetteur, de ce dispositif récepteur, de ce produit programme d'ordinateur et de ce moyen de stockage d'informations étant similaires à ceux des procédés de transmission de données correspondant, ne sont pas répétés ici. 5, LISTE DES FIGURES D'autres particularités et avantages de l'invention apparaîtront encore dans la description illustrative et non limitative ci-après, illustrée par les dessins ci-joints, dans lesquels - la Figure 1 illustre schématiquement une configuration d'un réseau privé virtuel (VPN) mettant en oeuvre un tunnel de communication ; - la Figure 2 illustre schématiquement un modèle en couches protocolaires d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon un mode de réalisation de l'invention ; la Figure 3 illustre schématiquement, un format de trame Ethernet dans le cadre de la mise en oeuvre d'un tunnel de niveau 2 ; la Figure 4 illustre schématiquement les blocs fonctionnels compris dans les têtes de tunnel selon un mode de réalisation de l'invention ; - la Figure 5 présente un organigramme d'algorithme mis en oeuvre par une tête de tunnel émettrice d'un flux de données multimédia, selon un mode de réalisation de l'invention ; la Figure 6 illustre schématiquement les formats de paquets de données échangés via un tunnel, selon un mode de réalisation de l'invention ; la Figure 7 illustre schématiquement le stockage, par une tête de tunnel, des données reçues des différentes porteuses d'un tunnel multi-transport, selon un mode de réalisation de l'invention ; la Figure 8 présente un organigramme d'algorithme mis en oeuvre par un module d'encodage d'une tête de tunnel émettrice d'un flux de données multimédia, selon un mode de réalisation de l'invention ; la Figure 9 présente un organigramme d'algorithme mis en oeuvre par un module décisionnaire d'une tête de tunnel émettrice d'un flux de données multimédia, selon un mode de réalisation de l'invention. 6. DESCRIPTION DETAILLEE Dans la suite de la description, des exemples de procédé et de dispositif selon l'invention sont plus amplement décrits dans le cadre d'une mise en oeuvre de tunnel de communication entre deux réseaux de type LAN, afin d'échanger des données multimédia. Néanmoins, l'application de la présente invention n'est nullement limitée à ce scénario de mise en oeuvre. En effet, la présente invention s'applique de manière générale à toute transmission d'un flux de données de type temps réel (ou streaming en anglais) depuis un premier dispositif (émetteur) vers un second dispositif (récepteur).

La Figure 1 illustre schématiquement une configuration d'un réseau privé virtuel (VPN) mettant en oeuvre un tunnel de communication (appelé aussi plus simplement tunnel ). Un tunnel 100 est établi entre une première tête de tunnel 101 et une seconde tête de tunnel distante 102 via un réseau de communication 107, tel qu'Internet par exemple. Le tunnel 100 interconnecte un réseau LAN A 103 et un autre réseau LAN B 104. Chaque réseau LAN 103 ou 104 comporte un équipement d'accès Internet haut débit de type passerelle domestique (ou Home Gateway en anglais) 105 ou 106. Chaque passerelle 105 ou 106 peut intégrer un pare-feu (ou Firewall en anglais) 105a ou 106a. Chaque réseau LAN 103 ou 104 comporte en outre des équipements de type ordinateur (ou PC pour Personal Computer en anglais) 109 ou 111, des serveurs 110 ou 113 permettant le stockage et le partage de données multimédia numériques (de type audio, vidéo, photo), ainsi que des équipements de restitutions des données numériques 108 ou 112. Une tête de tunnel peut être un équipement dédié (comme représenté sur la Figure 1), ou bien intégrée dans un équipement à vocation audiovisuelle, comme par exemple un téléviseur numérique. II est aussi possible pour un équipement de type PC 109 ou 111de mettre en oeuvre les fonctions d'une tête de tunnel, que ce soit sous forme logicielle ( software en anglais) ou matérielle ( hardware en anglais). Une fois que le tunnel 100 est établi, les équipements 108, 109, et 110, connectés au réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au réseau LAN B 104. Par exemple, le client 108 connecté au réseau LAN A 103 peut communiquer, de manière transparente, avec le serveur 113 connecté au réseau LAN B 104. Sur la Figure 1 est représenté un réseau de communication ne comportant qu'un seul tunnel, mais il est bien entendu qu'un même réseau LAN peut comporter plusieurs têtes de tunnel et/ou qu'une même tête de tunnel peut gérer plusieurs tunnels (à destination d'autant de têtes de tunnel) pour interconnecter un premier réseau LAN à plusieurs autres réseaux LAN. En outre, dans un souci de simplification, n'ont pas été représentés les équipements d'infrastructure (routeurs,...) du réseau Internet. La Figure 2 illustre schématiquement un modèle en couches protocolaires d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon un 5 mode de réalisation de l'invention. La description suivante propose un modèle en couches protocolaires nécessaires à la mise en oeuvre du tunnel 100 par la tête de tunnel 101. Une description analogue s'applique à la tête de tunnel 102. Dans le modèle présenté à la Figure 2 ne sont pas représentés les 10 éléments protocolaires nécessaires aux fonctions autres que la mise en oeuvre du tunnel, comme par exemple les éléments protocolaires associés au standard UPnP (pour Universal Plug and Play en anglais). La transmission d'une trame Ethernet issue d'un des équipements 108, 109, 110 (connectés au réseau LAN A 103) via le tunnel 100 jusqu'au réseau 15 LAN B 104, s'effectue comme suit. La tête de tunnel 101 comporte une interface physique Ethernet 208 qui reçoit les trames Ethernet issues des équipements 108, 109, 110 et les remet à la couche liaison 207. Les trames Ethernet à destination de l'équipement comportant la tête de tunnel .sont remises à une couche réseau 206. Les autres 20 trames Ethernet sont remises à une couche de pont ( bridge layer en anglais) 209. La couche de pont 209 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relais de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Sur le pont sont attachées une interface Ethernet 207 et au moins une interface virtuelle 210 émulant un 25 contrôleur Ethernet. Une interface virtuelle 210 est créée pour chaque tunnel instancié par l'application 200. Les trames Ethernet qui doivent être diffusées dans l'ensemble du réseau privé virtuel sont remises à chaque interface virtuelle 210. D'une manière générale, le protocole d'encapsulation du tunnel représenté par l'application 200 réalise les opérations nécessaires à la mise en 30 oeuvre de chaque tunnel, parmi lesquelles on trouvera notamment la configuration, le filtrage et l'encapsulation (formation d'un paquet tunnel) et l'extraction d'une trame. Dans un mode de réalisation préféré s'y trouvent aussi les mécanismes spécifiques à l'invention, tels que plus amplement décrits par la suite, en particulier en relation avec la Figure 4. Les trames reçues de l'interface virtuelle 210, après traitement par l'application 200, sont remises sous la forme de paquets à travers une interface applicative ( socket en anglais) 201 à un protocole de transport fiable TCP 203 ou non fiable UDP 205, respectivement sécurisés par les protocoles SSL 202 et DTLS 204. Après traitement par un protocole de transport pour former un paquet tunnel 250 (Figure 3), celui-ci est passé à la couche réseau 206. Le datagramme IP ainsi formé avec le paquet tunnel peut maintenant être transmis sur le réseau LAN à travers les couches liaison 207 et physique 208, pour être ensuite propagé sur le réseau Internet via la passerelle 105. La réception d'une trame en provenance du tunnel 100 suivra dans la tête de tunnel le cheminement inverse à celui présenté ci-dessus. La Figure 3 illustre schématiquement un format de trame Ethernet dans le 15 cadre de la mise en oeuvre d'un tunnel de niveau 2, tel que le tunnel 100 de la Figure 1. La trame Ethernet 260 véhicule un paquet tunnel de niveau 2. La trame Ethernet 260 est une trame transitant par exemple sur le réseau LAN A 103 de la Figure 1 entre la tête de tunnel 101 et la passerelle 105. La trame 260 20 transporte les données en provenance ou à destination du réseau LAN B 104. La trame Ethernet 260 comporte un champ d'en-tête Ethernet 261, un premier datagramme IP 262 véhiculant lui-même un paquet tunnel 250 de niveau 2, et 25 - un champ séquence de contrôle de trame FCS 263 (pour Frame Check Sequence en anglais). Le paquet tunnel 250, contenu dans le datagramme IP 262, comporte : un champ d'en-tête du protocole de transport 251 (à savoir TCP ou UDP dans l'exemple décrit en détail ici) ; 30 - un champ d'en-tête du protocole d'encapsulation 252, à savoir L2TP ou TLS ( Transport Layer Security ) dans l'exemple décrit ici ; de tels protocoles d'encapsulation sont notamment décrits dans la norme RFC-3931 ( Layer two tunneling protocol û version 3 (L2TPv3) , J. Lau et al, March 2005) et la norme RFC-2246 ( The TLS Protocol Version 1.0 ), un champ d'en-tête du protocole embarqué 253 (à savoir Ethernet dans l'exemple ici, car sont transportées via le tunnel les trames Ethernet émises par les dispositifs connectés au réseau LAN A 103 ou B 104, et - un champ de données utiles 254 (aussi appelées données utilisateur ou données applicatives), qui lui-même comporte un second datagramme IP complet si aucune fragmentation n'a été opérée lors de son transit depuis le dispositif l'ayant généré. La Figure 4 illustre schématiquement les blocs fonctionnels compris dans une tête de tunnel selon un mode de réalisation de l'invention. Les différentes couches protocolaires présentées en relation avec la Figure 2 sont représentées ici de manière simplifiée, dans un souci de lisibilité de la représentation. De même, les passerelles 105 et 106 sont omises. De plus, les flux de données transportés via le tunnel 100, mais auxquels aucun code correcteur d'erreur n'est appliqué dans le cadre de la présente invention, ne sont pas représentés.

II convient aussi de noter qu'un seul flux 401 est considéré pour les besoins illustratifs. Cependant, plusieurs flux semblables au flux 401 peuvent simultanément bénéficier des avantages de la présente invention. La tête de tunnel 101 comporte un bloc émetteur 410 et la tête de tunnel 102 comporte un bloc récepteur 420, permettant respectivement l'émission et la 25 réception de données via le tunnel 100. La description suivante s'appuie sur une transmission de flux de données via le tunnel 100 depuis la tête de tunnel 101 vers la tête de tunnel 102. Une description analogue s'applique pour une transmission de flux depuis la tête de tunnel 102 vers la tête de tunnel 101. 30 Le bloc émetteur 410 reçoit en entrée un flux 401 en provenance du réseau LAN 103 et est en charge de transporter les données de ce flux via le tunnel 100, en utilisant deux porteuses 100A (porteuse TCP) et 1008 (porteuse UDP). Le bloc récepteur 420 reçoit les données depuis le tunnel 100, et reconstitue un flux 402 de données correspondant au flux 401 original.

Dans le cadre d'un mode de réalisation de l'invention, le flux 401 est formaté selon le protocole de transport RTP sur UDP car il s'agit d'une solution privilégiée de l'état de la technique pour le transport temps réel ( streaming en anglais). Dans une variante de réalisation, le flux 401 peut être un ensemble de données, généré par une couche applicative de la tête de tunnel 101, et qui doit être transmis à une couche applicative de la tête de tunnel 102. D'une façon générale, le flux 401 peut être formaté selon tout protocole de transport adapté, autre que RTP sur UDP (tel que HTTP par exemple). Le bloc émetteur 410 comprend les éléments suivants : un module d'identification de flux 411, en charge de détecter et sélectionner les flux temps réels (de type RTP) reçus du réseau LAN 103; un module décisionnaire 412, en charge de déterminer des paramètres d'un code correcteur d'erreur (ou paramètres d'encodage de parité). Dans ce mode de réalisation, les paramètres sont un nombre M de paquets de parité générés pour un nombre K de paquets du flux 401 ; un module d'encodage 415, en charge de générer (ou encoder) des paquets de parité à partir du flux 401 selon les paramètres du code correcteur d'erreur déterminés par le module décisionnaire 412, et d'aiguiller les paquets vers l'une ou l'autre des porteuses du tunnel 100 ; et - des empaqueteurs 413 et 414, chacun dédié à une porteuse du tunnel 100, en charge d'encapsuler les données issues du module d'encodage 415.

Le module d'identification de flux 411 peut effectuer une sélection des flux à fournir au module d'encodage 415, et sur lesquels le procédé selon l'invention est appliqué. Les flux non-sélectionnés sont alors routés vers l'une ou l'autre des porteuses, par exemple en fonction du protocole de transport selon lequel ils sont formatés. Des exemples d'aiguillage possible de flux de données vers les porteuses d'un tunnel multi-transport sont décrits dans la publication de demande de brevet EP 2 020 799. Le module d'identification de flux 411 effectue par exemple une sélection en fonction de la classe de service des flux détectés. Le module décisionnaire 412 comprend un récepteur de statistiques 4121 recevant des informations 430 relatives à des conditions de transmission via le tunnel 100. Le module décisionnaire 412 est adapté à déterminer les paramètres du code correcteur d'erreur nécessaires à l'encodage des paquets de parités par le module d'encodage 415. De plus, le module décisionnaire 412 dispose d'une interface 431 avec l'empaqueteur 413 afin de pouvoir échanger des paramètres avec le bloc récepteur 420 dans le cadre d'une session de contrôle établie sur la porteuse TCP 100A.

Le module d'encodage 415 effectue un encodage sur un premier ensemble de K paquets du flux 401 (dénommé fenêtre d'encodage de taille K) afin d'obtenir un second ensemble de M paquets de parité. II est à noter que, dans un mode de réalisation préféré, le module d'encodage 415 agit au niveau paquet (en anglais, packet level ), c'est-à-dire que la taille considérée pour l'encodage et le décodage de parité correspond à la taille des données utiles véhiculées via les porteuses du tunnel Le module d'encodage 415 est en outre en charge d'aiguiller les paquets du flux 401 vers la porteuse UDP 1008 et les paquets de parité vers la porteuse TCP 100A. Ce mécanisme est plus amplement décrit par la suite, notamment en relation avec les Figures 5 et 8. Dans un mode de réalisation préféré, les paquets du flux 401 ont une taille MTU (pour Maximum Transmission Unit en anglais) permettant une insertion directe des paquets tunnel constitués dans le champ de données 254 de la Figure 3.

Le bloc récepteur 420 comprend les éléments suivants des dé-paqueteurs 421 et 422 chacun dédié à une porteuse du tunnel 100, en charge de désencapsuler les données en provenance du tunnel 100 une mémoire de stockage temporaire 423 en charge de réordonner les données du flux 401 et d'y associer les données de parité reçues, en fonction d'un marquage de fenêtrage (décrit plus en détail en relation avec la Figure 6) ; - un régénérateur de trame 424, permettant la reconstitution des trames du flux 402 à partir des données du flux 401 et des données de parité, reçues du tunnel 100 et stockées dans la mémoire de stockage temporaire 423 ; - un séquenceur de flux 425 en charge de délivrer et de cadencer sur le réseau LAN B 104 les paquets du flux 402 après reconstitution ; par exemple, pour des flux 401 et 402 de type RTP, le marquage temporel ( timestamp en anglais) compris dans le paquet,RTP est utilisé afin d'effectuer le cadencement du flux 402 par le séquenceur de flux 425, pour maintenir une gigue quasi-nulle, c'est-à-dire un délai inter-paquet quasi-constant. Le régénérateur de trame 424 comprend un module correcteur 4241, afin de reconstituer les paquets de données originaux du flux 401 malgré les pertes de données survenues lors de la transmission via le tunnel, et ce, en fonction du fenêtrage déterminé par le module décisionnaire 412. Le régénérateur de trame 424 obtient les paramètres 432 du code correcteur d'erreur employé par le module d'encodage 415 par le biais du dé-paqueteur 422, comme décrit ultérieurement en relation avec la Figure 6. La Figure 5 représente un organigramme d'algorithme mis en oeuvre par le bloc émetteur 410, selon un mode de réalisation de l'invention. Toutes les étapes de l'algorithme représentées sur la Figure 5 peuvent être mises en oeuvre sous forme logicielle par exécution d'un ensemble d'instructions, ou programme, par une machine de calcul programmable, tel qu'un PC ( Personal Computer en anglais), un DSP ( Digital Signal Processor en anglais) ou un microcontrôleur ; ou bien mises en oeuvre sous forme matérielle par une machine ou un composant dédié, tel qu'un FPGA ( Field-Programmable Gate Array en anglais) ou un ASIC ( Application-Specific Integrated Circuit en anglais). Dans une étape 500, le module décisionnaire 412 obtient des informations relatives à une congestion sur le réseau reliant les têtes de tunnel 101 et 102. Une marge disponible dans la porteuse TCP du tunnel peut être déterminée selon plusieurs méthodes. Autrement dit, on obtient un fenêtrage instantané FWS (pour Free Window Space en anglais) indiquant la différence entre la valeur de référence de la fenêtre de congestion TCP (appelée cwnd selon le protocole TCP) et la valeur de fenêtre de congestion réellement utilisée pour l'émission de données sur la porteuse TCP (appelée send_wnd ). Selon une premier méthode de détermination, la valeur send_wnd est obtenue en mesurant régulièrement le débit (appelé passenger_flows bitrate ) des paquets de données reçus du réseau LAN 103 et transmis sur la porteuse TCP du tunnel, et en s'appuyant sur la valeur temporelle RTT (pour Round Trip Time selon le protocole TCP). La valeur send_wnd peut alors être obtenue selon la formule suivante : send_wnd = passenger_flows_bitrate *-RU / 2 La capacité mémoire des équipements, tels que les dispositifs 108 à 113 est dimensionnée de manière à supporter une transmission de flux sur un réseau LAN, c'est-à-dire une transmission à latence faible (quelques millisecondes). Par exemple, pour un débit de l'ordre de 100 Mbps et une valeur RTT de 5 millisecondes, la fenêtre de congestion des serveurs TCP sera limitée-à 65 kilo-octets. Grace au tunnel 100, les flux sont transportés sur le réseau Internet en toute transparence pour les dispositifs 108 à 113. La capacité mémoire des têtes' de tunnel est dimensionnée de manière à supporter une transmission de flux sur le réseau Internet, c'est-à-dire une transmission avec un débit bien plus faible (par exemple 10 Mbps) et une latence plus élevée (par exemple supérieure à 100 millisecondes). Ainsi, le produit débit*délai, qui indique la valeur de mémoire nécessaire (selon l'exemple, 125 kilo-octets), est bien plus important sur une tête de tunnel. Il est ainsi possible de disposer de place libre, c'est-à-dire d'une marge dans la fenêtre de congestion, pour une émission de données via la porteuse TCP du tunnel 100. On obtient alors un fenêtrage instantané FWS de la façon suivante : FWS = cwnd - senti wnd (en nombre d'octets) ou FWS = (cwnd - send_wnd ) / MSS (en nombre de paquets) où MSS représente le paramètre Maximum Segment Size, du protocole TCP. 10 Selon une second méthode de détermination, le fenêtrage instantané FWS est déterminé à partir d'un paramètre interne à la pile protocolaire TCP ( TCP protocol stack en anglais) indiquant le nombre de données pouvant être transmises (communément dénommée usable window selon le protocole de gestion de fenêtrage du protocole TCP). La valeur du fenêtrage 15 instantané FWS est alors obtenue à partir de la formule suivante : FWS "usable window" - TCP_Tx_buffer (en nombre d'octets), c'est-à-dire : FWS = (min(cwnd, rwnd) - (snd_nxt - snd_una)) TCP_Tx_buffer où TCP Tx buffer représente le nombre de données dans la zone mémoire 20 d'émission, c'est-à-dire en attente de transmission sur la porteuse TCP (en nombre d'octets), cwnd et rwnd représentent respectivement la fenêtre de congestion TCP (au niveau du bloc émetteur 410) et la fenêtre de réception offerte par le bloc récepteur 420 ( advertized window du protocole TCP), snd_una représente le numéro de séquence de la plus ancienne donnée non 25 encore acquittée selon le protocole TCP (en nombre d'octets), et snd_nxt représente le numéro de séquence de la prochaine donnée à transmettre. Selon l'une quelconque des méthodes précités de détermination de la marge disponible, une valeur FWS positive indique la place libre permettant la transmission des paquets de parité via la porteuse TCP du tunnel 100 sans 30 engorgement de la porteuse TCP. Ensuite, lors d'une étape 501, mise en oeuvre par le module décisionnaire 412, des paramètres du code correcteur d'erreur à appliquer au flux 401 sont déterminés en fonction des informations de congestion (c'est-à-dire relatives aux conditions de transmission via le tunnel 100) obtenues. Cette étape vise notamment à déterminer les paramètres K (nombre de paquets sélectionnés du flux 401 sur lesquels s'applique le code correcteur d'erreur) et M (nombre de paquets de parité, résultant de l'application du code correcteur d'erreur sur les paquets sélectionnés du flux 401). Dans ce mode de réalisation, le nombre M est directement lié à la valeur de fenêtrage instantané FWS. Ceci sera plus amplement adressé par la suite en relation avec la Figure 9. Dans une étape 502, le module d'encodage 415 génère les M paquets de parité à partir des K paquets du flux 401. On dit aussi qu'il encode les M paquets de parité à partir des K paquets du flux 401 (les M paquets de parité étant donc des données encodées, selon cette terminologie). On obtient alors un nombre N total de paquets, tel que N = M + K, à transmettre via le tunnel. Le module d'encodage 415 aiguille, dans une étape 503, les M paquets de parité vers la porteuse TCP via l'empaqueteur 413 et, dans une étape 504, les K paquets issus du flux 401 vers la porteuse UDP via l'empaqueteur 414. Ainsi l'émission des paquets du flux via la porteuse UDP du tunnel est fiabilisée par l'émission de paquets de parité via la porteuse TCP du tunnel, tout en évitant l'engorgement de la porteuse TCP.

La Figure 6 illustre schématiquement les formats de paquets de données échangés entre la tête de tunnel 101 et la tête de tunnel 102 via le tunnel 100, selon un mode de réalisation de l'invention. A titre d'exemple illustratif, une encapsulation tunnel selon le protocole L2TP, décrit notamment dans la norme RFC-3931 déjà mentionnée, est utilisée.

Une structure 600 représente un format de paquets tels qu'échangés entre la tête de tunnel 101 et la tête de tunnel 102 dans le cadre d'une session de contrôle du tunnel. De manière illustrative, il est considéré que la session de contrôle du tunnel multi-transport est établie sur la porteuse TCP 100A. En effet, afin de pouvoir appliquer un mécanisme de correction d'erreur de type FEC ( pour Forward Error Correction en anglais), le module d'encodage 415 doit informer le module correcteur 4241 des paramètres du code correcteur d'erreur (notamment les paramètres M et K) utilisés. Comme décrit par la suite, le paramètre K est préférentiellement transmis via un message de structure 600. En variante, il peut être transmis via des messages de structure 620 (détaillée ci-après). Le paramètre M est quant à lui déterminé par le récepteur 420 grâce à un symbole ESI (pour Encoding Symbol ID en anglais) d'un message de structure 650 (détaillée ci-après). La structure 600 est de type AVP ( Attribute Value Pair en anglais) selon le protocole L2TP et est utilisée pour communiquer les paramètres du code correcteur d'erreur employé par le module d'encodage 415. Le dé-paqueteur 422 analyse les paquets reçus de la porteuse TCP pour retrouver les paramètres et fournit alors les paramètres retrouvés au régénérateur de trame 424. L'entête 601 permet de préciser un code d'attribut afin que le bloc récepteur 420 reconnaisse le type de la structure communiquée. Un champ données utiles fournit des informations contrôlant les opérations du mécanisme de correction d'erreur, qui doivent être partagées entre le module d'encodage 415 et le module correcteur 4241. Dans un mode de réalisation préféré, ces informations sont relatives à l'objet FEC OTI (pour Forward Error Correction Object Transmission Information ), objet précisé par la norme RFC-5052 ( FEC Building Block ).

La norme RFC-5052 précise qu'un objet FEC OTI contient un identifiant, appelé FEC Encoding ID , du type de code correcteur d'erreur utilisé. Une telle information permet au régénérateur de trame 424 de choisir l'algorithme de correction d'erreur adéquat. Certains de ces identifiants sont enregistrés auprès de l'autorité IANA ( Internet Assigned Numbers Authority en anglais) pour les codes correcteurs d'erreur courants ; par exemple pour un code correcteur d'erreur de type Reed-Solomon, la valeur est 2 . Un objet OTI peut aussi contenir des paramètres additionnels, tels que par exemple FEC Instance ID : un nombre entier indiquant une instance 30 particulière liée au type d'encodage précité Encoding-Symbol-Length : un nombre entier indiquant la longueur (en octets) d'un paquet après application du code correcteur d'erreur, l'encodage étant (comme déjà mentionné) appliqué au niveau paquet (c'est-à-dire qu'un symbole équivaut à un paquet) Maximum-Source-Block-Length : un nombre entier indiquant une taille de fenêtre d'encodage (équivalent à une valeur maximale du paramètre K déjà mentionné) ; Max-Number-of-Encoding-Symbols : un nombre entier indiquant un nombre total maximal de paquets à transmettre pour une fenêtre d'encodage donnée (équivalent à une valeur maximale du paramètre N déjà mentionné). ll convient de noter que la structure 600 supporte toute extension 'propriétaire, et peut par exemple permettre l'envoi des coefficients d'une matrice de codage. Dans un mode de réalisation préféré, ces éléments sont transmis sous forme de valeurs séparées par des virgules selon le format informatique ouvert en mode texte appelé CSV (pour Comma-Separated Values en anglais), tel que par exemple décrit dans la norme RFC-4180 sous le type MIME (pour Multipurpose Internet Mail Extensions en anglais) "text/csv". Ce format peut être remplacé par tout format adapté à la description de 20 listes d'éléments, comme par exemple un format semblable à XML (pour eXtensible Markup Language en anglais). La structure 620 représente un format de paquet de la porteuse UDP 100B du tunnel 100, encapsulant les paquets du flux 401. Ce format suit les recommandations du protocole L2TP. 25 Un champ 622 représente, selon le protocole L2TP, une sous-couche spécifique au transport, permettant l'insertion d'un numéro de séquence SN utile pour des opérations effectuées à la réception des paquets, comme par exemple le réordonnancement des données. Ce numéro de séquence SN permet, dans le cadre du mode de réalisation préféré, de regrouper les paquets 30 du flux 401 d'une même fenêtre d'encodage (de taille K). De plus, un champ F (pour Flag en anglais) permet au récepteur du paquet de déterminer si le contenu 623 a fait l'objet d'un encodage de parité par le module d'encodage 415. La structure 650 représente un format de paquet de la porteuse TCP 100A du tunnel 100, encapsulant les paquets de parité constitués par le module 5 d'encodage 415 à partir des paquets du flux 401. Un champ 652 représente une sous-couche spécifique au transport des paquets de parité, permettant l'insertion : d'un marquage de fenêtrage (dénommé SBN, pour Source Block Number ), utile à l'identification de la fenêtre d'encodage de K 10 paquets à laquelle le paquet encapsulé est associé ; d'un identifiant de symbole de codage ESI, apportant des informations complémentaires permettant d'identifier les paquets du flux 401 utilisés pour l'encodage des paquets de parité. Ainsi, les informations du champ 652 identifient la fenêtre d'encodage de 15 K paquets du flux 401 concernée et la relation (via ESI) entre les données de parité véhiculées dans la zone 653 et les K paquets du flux 401 concernés. Dans l'exemple suivant, le module d'encodage 415 construit M=3 paquets de parité à partir de K=10 paquets du flux 401. Le premier paquet du flux 401 considéré a un numéro de séquence SN=500 pour le transport sur la porteuse 20 UDP 100B. Dans ce cas, les paquets de type 650 véhiculant les paquets de parité sur la porteuse TCP 100A sont construits avec les paramètres suivants pour une fenêtre d'encodage courante (i) : 1 er 2ème Sème 10ème paquet paquet paquet paquet SN=500 SN=501 SN=502 SN=509 SBN=500 SBN=500 SBN=500 x x ESI=1 ESI=2 ESI=3 pour la fenêtre d'encodage suivante (i+1 (K=10,M=3) UDP (620): TCP (650) ter 2eme 3eme ... 10eme paquet paquet paquet paquet SN=510 SN=511 SN=512 SN=519 SBN=510 SBN=510 SBN=510 x x ESl=1 ESI=2 . ESI=3 Dans l'exemple précédent, le champ ESI correspond à l'indice du paquet de parité généré. Ceci convient particulièrement au cas d'usage d'un code correcteur de type Reed-Solomon. Le champ ESI ainsi utilisé permet au décodeur de déterminer les paramètres du code correcteur d'erreur liés à chaque paquet, par exemple en indiquant de quelle ligne de la matrice de codage le paquet de parité est issu. Les paquets de structure 650 véhiculant les paquets de parité ont un numéro de séquence (ou marquage de fenêtrage) identique pour une même fenêtre d'encodage, et le recyclage de la valeur du champ SBN (incrémentée d'une unité à chaque nouvelle fenêtre d'encodage de K paquets du flux 401) doit être suffisamment espacé afin qu'aucun marquage de fenêtrage ne soit réutilisé avant que toutes les données d'une fenêtre d'encodage précédente de même marquage de fenêtrage ne soient traitées par le régénérateur de trame 424.

Dans le cadre d'une utilisation d'un code correcteur d'erreur de type Reed-Solomon appliqué au niveau paquet, le codage peut être effectué à l'aide d'une matrice. Les K paquets de la fenêtre d'encodage sont rangés de manière à ce que chacun forme une colonne de la matrice, chaque élément de la matrice représentant alors un symbole. Un code correcteur d'erreur de type Reed- Solomon C(N, K) est alors appliqué sur chaque ligne de la matrice pour gérer au moins un symbole (selon le code C(N,K) appliqué) de parité. On obtient alors une matrice (ou un vecteur selon code C(N,K) appliqué) de symboles de parité, chaque colonne formant un paquet de parité. De manière réciproque, l'opération de décodage s'effectue en rangeant les paquets reçus de manière à ce que chacun forme une colonne de la matrice, chaque élément de la matrice représentant alors un symbole reçu. Un décodage de Reed-Solomon correspondant au code C(N,K) est alors appliqué par ligne de cette matrice, de (K=10,M=3) UDP (620): TCP (650) : manière à obtenir une matrice résultante comprenant les symboles originaux. Les K paquets de la fenêtre d'encodage forment alors les colonnes de cette matrice résultante. La description suivante détaille un code correcteur d'erreur basé sur une 5 utilisation de OU-EXCLUSIFs (XORs), c'est-à-dire qu'une opération OU- EXCLUSIF (XOR) est appliquée entre les K paquets du flux 401. Dans ce cas, le champ ESI a une utilisation différente de celle de l'exemple précédent. Le champ ESI indique alors la portée de l'opération OU-EXCLUSIF (XOR) sur une fenêtre d'encodage de K paquets du flux 401. Par exemple, si un paquet de 10 parité est créé à partir des 5 premiers paquets (du flux 401) d'une fenêtre. d'encodage de 10 paquets (K = 10), la valeur binaire du champ ESI est : ESI `11111000000000', chaque bit étant associé à un paquet de la fenêtre d'encodage, et la valeur de ce bit indique si le paquet associé (parmi les K paquets) a été utilisé 15 par le code correcteur d'erreur (bit à 1 si tel est le cas, bit à 0 sinon). Dans le cadre d'une utilisation de OU-EXCLUSIFs (XORs) pour la construction d'un paquet de parité, les K paquets du flux 401 sont combinés de la manière suivante - soit p1,p2,...,PK les K paquets (de taille m ) du flux 401 et 20 R' la valeur du ième bit du paquet pi (j=1,...,k) ; - soit r le paquet de parité à construire et r' la valeur du dème bit du paquet de parité - alors K r` = p (mod 2)`di E .,ml >=1 25 Ainsi, il suffit d'effectuer la somme bit à bit sur les K paquets reçus pour récupérer le paquet perdu parmi les K+1: Cette opération, très facile à mettre en oeuvre sur du matériel ( hardware en anglais) embarqué, nécessite un cycle de traitement (ou cycle CPU pour Central Processing Unit en anglais) par mot de code émis, ce qui induit un temps de traitement très faible. 30 La taille du champ ESI est au moins K bits, de manière à pouvoir associer un bit par paquet d'une même fenêtre d'encodage. Cette utilisation du champ ESI sera plus particulièrement détaillée en relation avec l'étape 805 de la Figure 8. La sélection d'un sous-ensemble de paquets parmi les paquets de la fenêtre d'encodage est exprimée par la suite par le paramètre K'. Une telle sélection d'un sous-ensemble de paquets est particulièrement avantageuse lorsque le flux 401 est un flux RTP multiplexé, le multiplexage des données facilitant la sélection de ce sous-ensemble parmi les K paquets de la fenêtre d'encodage. Selon un premier exemple, le flux 401 transporte des données multimédia de type JPEG 2000, tel que défini par la norme RFC-5371. Chaque paquet RTP véhicule alors une sous-partie de ces données multimédia, chaque sous-partie disposant d'une importance (ou priorité) propre. Une sélection de K' paquets peut alors être effectuée parmi les données les plus importantes sur une fenêtre globale d'encodage de K paquets.

Selon un second exemple, le flux 401. est composé de sous-programmes (ou sous-flux) indépendants, comme par exemple tel que défini par la norme RFC-4598 pour le transport de données audio de type E-AC-3 (pour Enhanced AC-3 en anglais), ou la norme RFC-3640 pour le transport de flux élémentaires de type MPEG-4). Une sélection de K' paquets peut alors être effectuée sur une fenêtre global de K paquets de manière à appliquer l'encodage de parité sur les données d'un ou plusieurs sous-programmes) (ou sous-flux) donné(s). La Figure 7 illustre schématiquement le stockage, par la tête de tunnel 102, des données reçues des différentes porteuses du tunnel 100, selon un 25 mode de réalisation de l'invention. La mémoire de stockage temporaire 423 permet de stocker temporairement les paquets reçus via la porteuse UDP 1008, afin de laisser du temps aux paquets de parité associés d'être reçus via la porteuse TCP 100A. En effet, la porteuse TCP a une latence plus importante que la porteuse UDP. 30 Par exemple, la mémoire de stockage temporaire 423 est dimensionnée pour conserver les paquets RTP du flux 401 sur une période allongée de la moitié de la valeur RTT de plus par rapport à un stockage temporaire classique de tête de tunnel. Un tel accroissement de la capacité mémoire en réception est amplement suffisant pour absorber la différence de latence entre les porteuses UDP et TCP. La latence induite par ce stockage temporaire supplémentaire est minimale comparée à la latence globale du réseau Internet.

La mémoire de stockage temporaire 423 est représenté ici sous forme de liste chainée d'éléments 710, appelés `noeuds'. Chaque noeud 710 correspond à un ensemble de paquets de données 623 ou de parité 653 relatives au flux 401, estampillées par un même numéro de marquage de fenêtrage SYNC 711 (correspondant au champ SBN tel que décrit en relation avec la Figure 6).

Un noeud 710 comprend : - des pointeurs vers les noeuds 710 suivant et précédent afin de former la liste chainée ; un numéro de marquage de fenêtrage SYNC 711 propre à l'identification d'une fenêtre d'encodage de K paquets, et permettant d'ordonner les noeuds 710 entre eux ; un pointeur vers une structure commune 730, associée à l'ensemble des paquets du flux 401 et des paquets de parité résultant, regroupant les données invariantes relative au flux 401, comme par exemple celles liées au protocole RTP ; un nombre 712 de paquets du flux 401 reçus par le dé-paqueteur 422 pour la fenêtre d'encodage identifiée par le numéro SYNC 711 ; un tableau de paquets du flux 401 pointant sur une liste chainée et ordonnée de descripteurs 720 de paquets issus du flux 401 ; un nombre 713 de paquets de parité reçus par le dé-paqueteur 421 pour la fenêtre d'encodage identifiée par le numéro SYNC 711 ; un tableau de paquets de parité pointant sur une liste chainée et ordonnée de descripteurs 740 de paquets de parité. La structure commune 730 comprend les informations suivantes les adresses MAC des dispositifs client et serveur entre lesquels le flux 401 (et le flux régénéré 402) est transmis ; les adresses IP de ces dispositifs client et serveur ; les ports utilisés pour la connexion RTP de ces dispositifs client et serveur les informations de l'entête RTP : la version courante du protocole RTP ( Ver , pour Version) ; o le format des données transportées ( PT , pour Payload Type en anglais) ; o l'identifiant de la source de synchronisation SSRC (pour Synchronization Source en anglais) et l'identifiant de la source de contribution CSRC (pour Contributing Source en anglais), conformément au protocole RTP ; Le descripteur 720 de paquet du flux 401 comprend : - des pointeurs vers des descripteurs 720 suivant et précédent afin de former une liste chainée ; - un numéro de séquence 722, mémorisant la valeur de séquence SN du champ 622 du paquet du flux 401 décrit par le descripteur 720 - un pointeur sur une zone mémoire 721 stockant le paquet du flux 401 décrit par le descripteur 720. Le descripteur 740 de paquet de parité comprend : des pointeurs vers les descripteurs 740 suivant et précédent afin de 20 former une liste chainée ; un numéro de séquence 742, mémorisant l'information ESI du champ 652 du paquet de parité décrit par le descripteur 740 ; un pointeur sur une zone mémoire 741 stockant le paquet de parité décrit par le descripteur 740. 25 Ainsi, sur réception de données en provenance des porteuses TCP 100A et/ou UDP 100B du tunnel, les dé paqueteurs 421 et 422 sont aptes à insérer chaque donnée reçue 623 ou 653 (Figure 6) au bon emplacement dans les listes chaînées décrites ci-dessus, et à remplir les champs des noeuds 710, descripteurs 720 et 740, et structures communes 730. 30 Le dé-paqueteur 421, sur réception d'un paquet via la porteuse UDP 1008, recherche le noeud 710 auquel associer le paquet 620 reçu, en fonction de l'information SN que celui-ci véhicule dans son champ 622. Si la valeur de la somme {SN + K} est supérieure à la valeur du champ SYNC 711 du dernier noeud 710 de la liste chaînée, alors un nouveau noeud 710 est créé, et la valeur de la somme {SN + K} est affectée à son champ SYNC 711. Dans le cas contraire, le dernier noeud 710 de la liste chaînée est sélectionné.

Pour le noeud sélectionné, un descripteur 720 de paquet du flux 401 est créé, l'information SN est affectée au champ 722, et les données 623 du paquet reçu sont stockées dans la zone mémoire 721 associée. Le descripteur 720 est ensuite inséré dans le tableau de paquets du flux 401 du noeud 710 : le nombre de trame (ou paquets) 712 est incrémenté, et le descripteur 720 est inséré à la liste chaînée de manière ordonnée en fonction de la valeur du numéro de séquence stocké dans le champ 722. Dans un mode de réalisation préféré, la présence d'une étiquette positive positionnée dans le champ F du paquet reçu via la porteuse UDP 100B, indique que ce paquet ne fait pas partie d'une fenêtre d'encodage sur laquelle un code correcteur d'erreur à été appliqué , ce paquet est donc un élément isolé et est donc inséré dans un nouveau noeud 710 (qui se limite alors à ce seul paquet). Le dé-paqueteur 422, sur réception d'un paquet via la porteuse TCP 100A, recherche le noeud 710 auquel associer le paquet 650 reçu, en fonction de l'information SBN que celui-ci véhicule dans son champ 652. Dans le cas (très rare) où la valeur SBN est supérieure à la valeur du champ SYNC 711 du dernier noeud 710 de la liste, un nouveau noeud 710 est créé, et la valeur SBN est affectée au champ SYNC 711. Un tel cas correspond à la perte totale des paquets du flux 401 qui ont été transmis via la porteuse UDP et qui ont été utilisés par le module d'encodage 415 pour créer les données de parité reçues.

Sinon, le noeud 710 identifié grâce à l'information SBN est sélectionné. Pour le noeud sélectionné, un descripteur 740 de paquet de parité est créé, l'information ESI est affectée au champ 742, et les données 653 du paquet reçu sont stockées dans la zone mémoire 741 associée. Le descripteur 740 est ensuite inséré dans le tableau de paquets de parité du noeud 710: le nombre de trames (ou paquets) 713 est incrémenté, et le descripteur 740 est inséré à la liste chaînée. Cette insertion s'effectue de manière ordonnée en fonction de la valeur du numéro de séquence stocké dans le champ 742, lorsque le champ ESI représente un indice de paquet de parité généré. L'ordonnancement de la liste suite à l'insertion du descripteur 740 n'a pas d'importance dans le cas lorsque le champ ESI représente la portée de l'opération OU-EXCLUSIF (XOR) sur la fenêtre d'encodage de K paquets.

Ainsi, grâce aux descripteurs 720 et 740, le régénérateur de trame 424 est capable d'obtenir les données nécessaires à la reconstruction d'un ensemble de K paquets de données pour chaque noeud 710, permettant ainsi la génération du flux 402. Selon les pertes subies sur la porteuse UDP 100B du tunnel 100 et le nombre de paquets de parité reçus à temps pour une fenêtre d'encodage donnée, le flux 402 peut n'être qu'un sous-ensemble du flux 401, l'objectif étant de rendre le flux 402 le plus fidèle possible au flux 401. Si aucun paquet de parité n'a été reçu (valeur nulle dans le champ 713) pour une fenêtre d'encodage donnée, les paquets du flux 401 reçus sont directement exploités par le séquenceur de flux 425 sans être décodés (pas de correction d'erreur) par le module correcteur 4241. Par exemple, selon l'illustration de la Figure 7, trois noeuds 799 sont disponibles pour extraction et envoi vers le réseau LAN B 104. A partir des descripteurs 720 et 740, le régénérateur de trame 424 décide de fournir ces éléments au module correcteur 4241. Ensuite, le module correcteur 4241 fournit un ensemble de K paquets, chaque paquet étant soit un paquet 623 tel que reçu via la porteuse UDP, soit un paquet reconstitué à partir des paquets de parité 653. Une fois qu'un noeud 710 a été utilisé par le régénérateur de trame 424, ce noeud est supprimé de la mémoire de stockage temporaire 423, et le noeud 25 suivant est sélectionné pour plus ample traitement. La Figure 8 représente un organigramme d'algorithme mis en oeuvre par le module d'encodage 415 de la tête de tunnel 410 émettrice du flux 401 de données multimédia, selon un mode de réalisation de l'invention. Toutes les étapes de l'algorithme représentées sur la Figure 8 peuvent 30 être mises en oeuvre sous forme logicielle par exécution d'un ensemble d'instructions, ou programme, par une machine de calcul programmable, tel qu'un PC ( Personal Computer en anglais), un DSP ( Digital Signal Processor en anglais) ou un microcontrôleur; ou bien mises en oeuvre sous forme matérielle par une machine ou un composant dédié, tel qu'un FPGA ( Field-Programmable Gate Array en anglais) ou un ASIC ( Application-Specific Integrated Circuit en anglais).

Dans une étape 800, le module d'encodage 415 reçoit un ou plusieurs paquets du flux 401, en provenance du module d'identification de flux 411. Dans une étape 801, le module d'encodage 415 interroge le module décisionnaire 412 pour obtenir les paramètres M (nombre de paquets de parité) et K (nombre de paquets du flux 401 pour générer les M paquets de parité) du code correcteur d'erreur à appliquer. Selon un mode de réalisation préféré, décrit en détail en relation avec la Figure 9, le module d'encodage 415 reçoit en outre éventuellement une consigne K'. Il esta rappelé que le paramètre K représentatif d'une taille de fenêtre 15 d'encodage est préférentiellement transporté via un message de structure 600 dans une session de contrôle du tunnel 100. Selon un mode de réalisation préféré, l'étape 801 est mise en oeuvre périodiquement. Ainsi, un ensemble de H fenêtres d'encodage consécutives de K paquets du flux 401 utilise les mêmes paramètres de code correcteur 20 d'erreur. Un message est donc envoyé dans une session de contrôle du tunnel 100 par le bloc émetteur 410 au bloc récepteur 420 à chaque modification de la taille K de fenêtre d'encodage ou pour un ensemble de H fenêtres d'encodage consécutives. Dans le cas de variations fréquentes de la taille K de fenêtre d'encodage, 25 il est plus approprié de transporter le paramètre K via un message de structure 620. Dans une étape 802, le module d'encodage 415 attend que le module d'identification de flux 411 ait fourni les paquets du flux 401 manquants pour former une fenêtre d'encodage complète de K paquets. 30 Dans une étape 803, le module d'encodage 415 vérifie si les paramètres fournis par le module décisionnaire 412 indiquent qu'aucun paquet de parité n'est nécessaire ou qu'aucun paquet ne peut être transmis. En cas de vérification positive (M = 0), une étape 804 est exécutée et l'ensemble des K paquets du flux 401 sont fournis à l'empaqueteur 414 pour un envoi ultérieur vers la porteuse UDP 1008. En cas de vérification négative (M > 0), dans une étape 805, le module d'encodage 415 procède à la génération des M paquets de parité à partir des K paquets du flux 401. Comme déjà mentionné en relation avec la Figure 6, selon le code correcteur d'erreur choisi, une valeur ESI est associée à chaque paquet de parité construit. Selon un mode de réalisation préféré décrit en détail en relation avec la Figure 9, un paramètre additionnel K' est fourni par le module décisionnaire 412 ; si ce paramètre K' est non nul, alors le code correcteur d'erreur est appliqué sur K' paquets du flux 401 au lieu de K. Cela signifie que la fenêtre d'encodage reste de K paquets, mais que seulement K' paquets servent à encoder les M paquets de parité. La valeur ESI, représentant la portée de l'opération OU-EXCLUSIF (XOR), indique ainsi les K' paquets du flux 401 sur lesquels est appliqué le code correcteur d'erreur. Ces M paquets de parité, et les valeurs ESI associées, sont envoyés (étape 806) à l'empaqueteur 413 pour émission sur la porteuse TCP 100A. Les K paquets du flux 401 sont mis à jour avec une étiquette indiquant que ces paquets ont été soumis à un encodage de parité. Dans une étape 807 les paquets sont ensuite fournis à l'empaqueteur 414 afin d'être émis via la porteuse UDP 1008. Dans un mode de réalisation préféré, cette étiquette se retrouve indiquée dans le champ F de chaque paquet de structure 620 encapsulant les K paquets du flux 401.

Dans un mode de réalisation préféré, l'empaqueteur 414 informe l'empaqueteur 413 du numéro de séquence (SN) utilisé dans le champ 622 du paquet UDP encapsulant le premier des K paquets de la fenêtre d'encodage. Ainsi, les paquets de parité, associés à cette fenêtre d'encodage, sont émis sur la porteuse TCP 100A avec un champ SBN égal à la valeur SN fournie par l'empaqueteur 414. Ensuite, l'empaqueteur 413 met à jour le champ ESl pour chaque paquet de parité encapsulé.

La Figure 9 représente un organigramme d'algorithme mis en oeuvre par le module décisionnaire 412 de la tête de tunnel 101 émettrice du flux 401 de données multimédia, selon un mode de réalisation de l'invention. Toutes les étapes de l'algorithme représentées sur la Figure 9 peuvent être mises en oeuvre sous forme logicielle par exécution d'un ensemble d'instructions, ou programme, par une machine de calcul programmable, tel qu'un PC ( Personal Computer en anglais), un DSP ( Digital Signal Processor en anglais) ou un microcontrôleur ; ou bien mises en oeuvre sous forme matérielle par une machine ou un composant dédié, tel qu'un FPGA ( Field-Programmable Gate Array en anglais) ou un ASIC ( Application-Specific Integrated Circuit en anglais). Lors de l'initialisation de la tête de tunnel 101, une valeur nominale Knom de la taille K de fenêtre d'encodage à considérer pour le code correcteur d'erreur est déterminée. Cette valeur nominale peut être définie de manière arbitraire ou peut être déterminée en fonction de la taille de la mémoire de stockage temporaire 423 (qui peut être prédéfinie ou reçue de la tête de tunnel 102 pendant l'initialisation) : Max_recv_buffer = min(rate_401 * (1 + coef)* RU , size_423) où: - rate 401 est la somme de la bande passante de l'ensemble des flux véhiculés par le tunnel 100, y compris le flux 401 ; coef définit une marge acceptable pour absorber la différence de latence entre les porteuses UDP 100B et TCP 100A (en relation avec la description de la Figure 7, une valeur de'/2 est utilisée) ; size 423 est la taille de la mémoire de stockage temporaire 423. La valeur nominale Knom peut alors être déterminée en fonction du débit moyen relatif entre les données transmises sur la porteuse UDP 100B et les données transmises sur la porteuse TCP 100A : Knom = (Max_recv_buffer / MSS) * (rate_TCP /rate 401) 30 où: rate_TCP est le débit moyen des données transmises sur la porteuse TCP 100A.

Une étape 910 est effectuée en réponse à une requête du module d'encodage 415. Cela démarre l'algorithme de détermination des paramètres pour une fenêtre d'encodage donnée de paquets du flux 401. Dans une étape 911, le récepteur de statistiques 4121 récupère les statistiques 430 de transmission via le tunnel 100 via les informations des interfaces de connexion ( sockets en anglais) TCP et UDP du tunnel 100. Par exemple, dans un système Linux 2.6, une interface API (pour Application Programming Interface en anglais) appelée TCP_INFO socket option permet de demander des informations sur l'état de la connexion TCP (pertes, RTT, fenêtre de congestion,...). De plus, le bloc émetteur 410 peut obtenir certaines statistiques de transport sur sa porteuse UDP 100B par échange d'informations avec le bloc récepteur 420 (nombre de paquets reçus, RTT équivalent sur UDP, désordonnancement,...). Ensuite, dans une étape 912, les actions présentées en relation avec l'étape 500 de la Figure 5 sont exécutées, afin de déterminer le nombre de paquets pouvant être insérés dans la porteuse sans dégradation du débit boutà-bout des applications passagères du tunnel. Cette marge restante, c'est-à-dire non utilisée par les flux en cours de transmission sur la porteuse TCP 100A), sera notée par la suite Minst et est telle que : Minst = FWS / MSS Dans un mode de réalisation de l'invention pour lequel plusieurs flux sont transmis selon le principe de l'invention depuis le bloc émetteur 410 jusqu'au bloc récepteur 420, la marge restante Minst est alors partagée entre ces différents flux. Diverses règles de répartition de la marge restante Minst entre ces différents flux peuvent être mise en oeuvre. Par exemple, la marge restante Minst peut être répartie de manière équitable entre les différents flux. D'autres répartitions, par exemple selon des critères d'importance de flux du point de vue utilisateur, peuvent être aussi appliquées. De manière classique, un code correcteur doit être tel que le pourcentage de paquets de parité par rapport au nombre de paquets du flux 401 est au moins égal au pourcentage de perte sur le réseau, tel que représenté par un taux d'erreur paquet (ou PER pour packet error rate en anglais). Ainsi, un test 913 est appliqué pour vérifier que la valeur K de taille de fenêtre d'encodage, au vu du nombre Minst identifiant la marge restante dans la fenêtre de congestion de la porteuse TCP 1OOA, est adapté à corriger les pertes instantanées.

En cas de vérification positive, un test 914 est conduit afin de déterminer si le taux de perte PER (pour Packet Error Rate en anglais) sur le tunnel 100 a diminué. Si tel est le cas, cela signifie que les conditions de transmission via le tunnel 100 se sont améliorées, et que la redondance apportée par les paquets de parité peut être diminuée. Dans une étape 915, les paramètres K et M sont choisis de manière compenser le taux de perte sur le tunnel 100: K doit être inférieur ou égal à Knom et M doit être inférieur à la marge restante Minst dans la fenêtre de congestion cwnd de la porteuse TCP 100A. Si le test 914 est négatif, dans une étape 916, la nouvelle valeur Minst est affectée au paramètre M.

Si le test 913 montre que les paramètres actuels de K et Minst ne permettent pas de corriger les pertes sur le tunnel 100, alors la valeur Minst est affectée au paramètre -M dans une étape 917, car Minst correspond au nombre maximum de paquets supplémentaires autorisés sur la porteuse TCP 100A sans dégradation du transport des autres flux passagers véhiculés par la porteuse TCP 100A. Il est ensuite testé, dans une étape 918, si M est nul. Si tel est le cas, cela signifie qu'aucun paquet de parité ne peut être transporté via la porteuse TCP, alors l'algorithme s'arrête. Dans le cas contraire, une étape 919 est exécutée afin de modifier le paramètre K de manière à compenser le taux de perte sur le tunnel 100 en fonction de la marge restante Minst dans la fenêtre de congestion cwnd de la porteuse TCP 100A. Le paramètre K est choisi de telle sorte que (M/K)PER De manière préférentielle, il ne faut pas que la valeur du paramètre K soit trop faible par rapport à la latence de transmission sur la porteuse TCP. En effet, il convient de s'assurer que les M paquets transmis sur la porteuse TCP 100A parviennent à la tête de tunnel 102 peu de temps après les K paquets (correspondant aux M paquets de parité) émis sur la porteuse UDP 100B. Plus la valeur du paramètre K est faible, plus il y a de paquets de parité transmis sur la porteuse TCP 100A. La porteuse TCP 100A doit donc supporter un débit d'émission des M paquets de parité proche du débit des K paquets du flux 401 transmis sur la porteuse UDP 1008. Ceci amène à définir une valeur minimale Kmin du paramètre K Kmin = M * rate 401 / (rate TCP * PER) Si la détermination du paramètre K conduit à une valeur inférieure à Kmin, alors aucune correction n'est possible avec les conditions actuelles. Dans ce 10 cas, le paramètre K est conservé, et le paramètre M est mis à 0 pour indiquer qu'il n'y a pas d'application de code correcteur. Dans un premier mode de réalisation préféré approprié plus particulièrement à un code correcteur d'erreur basé sur une utilisation de OUEXCLUSIFs (XORs), si la valeur du paramètre K est déterminée plus faible que '15 la valeur Kmin, on notera K' cette valeur déterminée, la valeur Kmin est affectée au paramètre K. La valeur K' est utilisée à l'étape 805 de la Figure 8 pour appliquer le code correcteur d'erreur uniquement sur un nombre limité K' de paquets parmi les K paquets de la fenêtre d'encodage (K' < K). Dans un second mode de réalisation préféré approprié plus 20 particulièrement à un code correcteur d'erreur de type Reed-Solomon, si la valeur du paramètre K est déterminée plus faible que la valeur Kmin, la valeur Kmin est affectée au paramètre K., et un nouveau nombre M de paquets de parité pour assurer la correction est déterminé. Sachant alors que M > Minst, il est décidé ici d'occuper plus de place sur la porteuse TCP 100A pour assurer 25 une correction des erreurs subies sur la porteuse UDP 100B. Dans une étape 920, les paramètres M, K, et éventuellement K', sont fournis au module d'encodage 415. Dans le cas où le paramètre M et K évoluent au fil du temps, il devient nécessaire de changer de matrice de parité, notamment dans le cadre d'une 30 utilisation d'un code correcteur de type Reed-Solomon. Ces matrices peuvent être déterminées de manière dynamique en fonction de l'évolution des conditions de transmission, ou prédéfinies et stockées en mémoire dans les têtes de tunnel 101 et 102, avec en correspondance, les conditions de transmission auxquelles chacune des matrices prédéfinies correspond. Il est alors avantageux de ne pas modifier intempestivement les paramètres d'encodage de parité. Ainsi, dans un mode de réalisation en variante des étapes 915 et 919, une valeur M légèrement supérieure à Minst est prise en compte: Ce cas de figure offre une marge de fonctionnement qui permet de répondre rapidement à un accroissement du taux de perte sur le tunnel 100, sans modifier les paramètres du code correcteur d'erreur (particulièrement avantageux dans le cas d'un code correcteur d'erreur de type 10 Reed-Solomon). Une valeur notée M' (M' > M) est fournie comme consigne supplémentaire au module d'encodage 415 et est utilisée pour l'application du code correcteur d'erreur. Seulement M paquets de parité sont alors transmis via la porteuse TCP 100A sur le nombre M' de paquets de parité créés. Cela permet de 15 conserver les paramètres actuels (ou précédents) du code correcteur d'erreur et cela évite ainsi de devoir reconfigurer, le module d'encodage 415 (ce qui nécessiterait une nouvelle matrice de parité, dans le cadre d'un code correcteur d'erreur de type Reed-Solomon par exemple). Ainsi, s'il y a un accroissement du taux de perte sur le tunnel (c'est-à-dire sur le réseau Internet), les 20 paramètres actuels du code correcteur d'erreur restent adaptés aux nouvelles conditions de transmission. Il est aussi possible de définir le paramètre M' comme étant une valeur`du paramètre M déterminée. à un instant donné et selon des conditions de transmission données, auquel est appliqué une marge de sécurité, autorisant ainsi des fluctuations dans les conditions de 25 transmission sans changement des paramètres effectifs appliqués par le module d'encodage 415.

Claims (18)

1. REVENDICATIONS1. Procédé de transmission d'un flux (401) de données par un dispositif émetteur (410) vers un dispositif récepteur (420) via un réseau de communication, les données dudit flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données, caractérisé en ce que ledit dispositif émetteur effectue des étapes consistant à - déterminer (501) des paramètres d'encodage (K, M) de parité d'un 10 ensemble de données dudit flux ; - générer (502) des données de parité à partir dudit ensemble de données en utilisant lesdits paramètres d'encodage de parité déterminés ; transmettre (503) les données de parité générées audit dispositif récepteur via ledit réseau de communication, par utilisation d'un protocole 15 de transport avec acquittement de données.
2. 2. Procédé de transmission selon la revendication 1, caractérisé en ce que lesdits paramètres d'encodage de parité sont déterminés en fonction d'une information de congestion dudit réseau de communication.
3. 3. Procédé de transmission selon la revendication 2, caractérisé en ce que 20 lesdits paramètres d'encodage de parité sont déterminés en fonction d'une fenêtre de congestion dudit protocole de transport avec acquittement de données.
4. 4. Procédé de transmission selon la revendication 3, caractérisé en ce que la quantité des données de parité générées à partir desdits paramètres 25 d'encodage de parité est égale à une marge restante dans ladite fenêtre de congestion.
5. 5. Procédé de transmission selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'une fenêtre (K) d'encodage est définie sur ledit flux et en ce qu'un desdits paramètres d'encodage de parité déterminé correspond à une 30 sélection (K') dudit ensemble de données parmi ladite fenêtre d'encodage.
6. 6. Procédé de transmission selon la revendication 5, caractérisé en ce que ledit dispositif émetteur fournit au dispositif récepteur une indication (ESI) deladite fenêtre d'encodage et des données de ladite fenêtre d'encodage utilisées pour générer lesdites données de parité.
7. 7. Procédé de transmission selon l'une quelconque des revendications 5 et 6, caractérisé en ce que ledit dispositif émetteur effectue des étapes consistant à: déterminer (912) une valeur (Minst) de marge restante dans une fenêtre de congestion dudit protocole de transport avec acquittement ; - ajuster (915, 919) la taille (K) de ladite fenêtre d'encodage en fonction de la valeur de marge restante déterminée. 10
8. 8. Procédé de transmission selon la revendication 7, caractérisé en ce la taille (K) de ladite fenêtre d'encodage est en outre modifiée en fonction d'une évolution de taux de perte de transmission entre le dispositif émetteur et le dispositif récepteur.
9. 9. Procédé de transmission selon l'une quelconque des revendications 1 à 15 8, caractérisé en ce qu'il comprend en outre des étapes consistant à - déterminer de nouveaux paramètres (K, M') d'encodage de parité dudit ensemble de données dudit flux, en fonction d'une nouvelle information de congestion dudit réseau de communication ; - générer des données de parité à partir dudit ensemble de données en 20 utilisant des paramètres d'encodage de parité précédents ; et en ce que, dans le cas où une nouvelle quantité de données de parité (M') générées selon les nouveaux paramètres d'encodage de parité est inférieure à une précédente quantité de données de parité (M) générées selon les paramètres d'encodage de parité précédents, le procédé comprend en outre 25 des étapes consistant à sélectionner des données de parité générées selon lesdits paramètres d'encodage de parité précédents pour une quantité égale à ladite nouvelle quantité de données de parité ; - transmettre lesdites données sélectionnées audit dispositif récepteur via 30 ledit réseau de communication, par utilisation dudit protocole de transport avec acquittement de données.
10. 10. Procédé de transmission selon l'une quelconque des revendications 1 à 9, caractérisé en ce que l'étape consistant à générer lesdites données de parité comprend une des étapes du groupe suivant : appliquer un code correcteur de type Reed-Solomon sur ledit ensemble 5 sélectionné ; - appliquer une opération ou-exclusif sur les données dudit ensemble sélectionné.
11. 11. Procédé de transmission selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'un tunnel (100) est mis en oeuvre entre le dispositif 10 émetteur et le dispositif récepteur, en ce que les données dudit flux sont transportées via une porteuse (100B) sans acquittement dudit tunnel, et en ce que les données de parité sont transportées via une porteuse (100A) avec acquittement dudit tunnel.
12. 12. Procédé de transmission d'un flux (401) de données par un dispositif 15 émetteur (410) vers un dispositif récepteur (420) via un réseau de communication, les données dudit flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données, caractérisé en ce que ledit dispositif récepteur effectue des étapes consistant 20 à: - obtenir des paramètres d'encodage (K, M) de parité d'un ensemble de données dudit flux - recevoir des données de parité via ledit réseau de communication, par utilisation d'un protocole de transport avec acquittement de données ; 25 - obtenir ledit ensemble de données dudit flux à partir de données du flux reçues par utilisation du protocole de transport sans acquittement de données et des données de parité reçues par utilisation du protocole de transport avec acquittement de données.
13. 13. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des 30 instructions de code de programme pour mettre en oeuvre du procédé selon au moins une des revendications 1 à 11 et/ou le procédé selon la revendication 12, lorsque ledit programme est exécuté sur un ordinateur.
14. 14. Moyen. de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé de transmission selon au moins une des revendications 1 à 11 et/ou le procédé selon la revendication 12.
15. 15. Dispositif émetteur (410) d'un flux (401) de données vers un dispositif récepteur (420) via un réseau de communication, les données dudit flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données, caractérisé en ce que ledit dispositif émetteur comprend : des moyens de déterminer des paramètres (K,M) d'encodage de parité d'un ensemble de données dudit flux ; - des moyens de générer (415) des données de parité à partir dudit ensemble de données en utilisant lesdits paramètres d'encodage de parité déterminés ; des moyens de transmettre (413) les données de parité générées audit dispositif récepteur via ledit réseau de communication, par utilisation d'un protocole de transport avec acquittement de données.
16. 16. Dispositif émetteur selon la revendication 15, caractérisé en ce que lesdits paramètres d'encodage de parité sont déterminés en fonction d'une 20 information de congestion dudit réseau de communication.
17. 17. Dispositif émetteur selon l'une quelconque des revendications 15 et 16, caractérisé en ce qu'un tunnel (100) est mis en ceuvre entre le dispositif émetteur et le dispositif récepteur et en ce que ledit dispositif émetteur comprend 25 - des moyens (414) de transmettre les données dudit flux via une porteuse (1008) dudit tunnel utilisant ledit protocole de transport sans acquittement de données - des moyens (413) de transmettre les données de parité via une porteuse (100A) dudit tunnel utilisant le protocole de transport avec acquittement de 30 données.
18. 18. Dispositif récepteur (420) d'un flux (401) de données en provenance d'un dispositif émetteur (410) via un réseau de communication, les données duditflux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données, caractérisé en ce que ledit dispositif récepteur comprend : des moyens d'obtenir des paramètres d'encodage (K, M) de parité d'un ensemble de données dudit flux ; des moyens de recevoir des données de parité via ledit réseau de communication, par utilisation d'un protocole de transport avec acquittement de données ; des moyens d'obtenir ledit ensemble de données dudit flux à partir de 10 données du flux reçues par utilisation du protocole de transport sans acquittement de données et des données de parité reçues par utilisation du protocole de transport avec acquittement de données.