FR2957736A1 - Procedes et dispositifs de transmission et de reception d'un flux de donnees, avec gestion de retransmission de donnees de parite, produit programme d'ordinateur et moyen de stockage correspondants - Google Patents

Abstract

Il est proposé un procédé de transmission d'un flux de données par un dispositif émetteur vers un dispositif récepteur. Les données du flux de données sont transmises par utilisation d'un protocole de transport sans acquittement de données. Le dispositif émetteur étant tel qu'il effectue des étapes consistant à : - transmettre au dispositif récepteur des premières données de parité générées à partir de données sources du flux, par utilisation d'un protocole de transport avec acquittement et retransmission de données ; - recevoir (600), en provenance du dispositif récepteur, un message d'indication de non-réception par le dispositif récepteur d'au moins une parmi les premières données transmises, le message comprenant une information de non-réception d'au moins une donnée source ; - générer (601) des secondes données de parité à partir de l'information de non-réception d'au moins une donnée source ; - transmettre (602) les secondes données de parité générées au dispositif récepteur, par utilisation du protocole de transport avec acquittement et retransmission de données, en réponse au message reçu.

Description

Procédés et dispositifs de transmission et de réception d'un flux de données, avec gestion de retransmission de données de parité, produit programme d'ordinateur et moyen de stockage correspondants 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. L'invention concerne une technique de transmission d'un flux de données par un dispositif émetteur vers un dispositif récepteur via un réseau de communication. Plus précisément, l'invention concerne une technique de gestion de retransmission de données de parité dans un tel réseau. 2. ARRIÈRE-PLAN TECHNOLOGIQUE La technologie des Réseaux Privés Virtuels (RPV, ou VPN pour « Virtual Private Network » en anglais) permet de communiquer de manière transparente, en temps réel et en continu, et de manière sécurisée, entre des individus partageant un même domaine 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 non routables, les RPVs utilisent une encapsulation particulière (appelée « tunnellisation », ou « tunneling » en anglais) qui crée ce que l'on appelle un tunnel de communication (ou plus généralement lien de communication). Cette opération consiste à encapsuler un protocole de niveau A (protocole embarqué ou véhiculé ou passager) dans un protocole de niveau B (protocole de transport ou véhiculant) 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 RPV de niveau 2, c'est-à-dire dans un tunnel de niveau 2 (tunnel de niveau 2 signifie que le protocole embarqué A est un protocole de la couche 2 du modèle OSI, qui décrit les services offerts par chacune de ces couches et leurs interactions). Par exemple, les techniques de tunnellisation sont utilisées pour interconnecter deux réseaux locaux domestiques (appelés ci-après réseaux LAN, pour « Local Area Network » en anglais) afin de créer un réseau privé virtuel (ou RPV) composé de l'union des deux réseaux LAN originaux. Une configuration typique de RPV basé sur une technique de tunnellisation est illustrée sur la figure 1 (décrite en détail par la suite). Selon cette technique, le lien de communication utilisé pour interconnecter deux réseaux LAN est un tunnel. Chaque réseau LAN comprend un dispositif d'interconnexion, par exemple une tête de tunnel (TEP, pour « Tunnel End Point » en anglais), et une passerelle. Le tunnel est établi entre les têtes de tunnel, et chaque paquet (aussi appelé trame) à envoyer au réseau LAN distant est encapsulé par la tête de tunnel connectée au réseau LAN local, puis envoyé, via le tunnel, à la tête de tunnel (distante) connectée au réseau LAN distant, qui va le dés-encapsuler et l'envoyer sur le réseau LAN distant. Du point de vue des équipements des réseaux LAN interconnectés par un tunnel, ils sont virtuellement connectés à un même réseau LAN. Une communication entre deux équipements via le tunnel est appelée communication de bout en bout (« end-to-end communication » en anglais) ou communication passagère (dans le sens de « embarquée »), et l'utilisation du tunnel est transparente pour les équipements des réseaux LAN connectés.

De nos jours, il existe des RPVs disposant de tunnel formé de plusieurs porteuses (ou canaux de transmission). De tels RPVs sont notamment décrits dans le document de brevet EP 2,020,799. On appelle « tunnel multi-transport » un tunnel qui est formé de multiples porteuses ayant des protocoles de transport distincts. Chaque tête de tunnel dispose alors d'un ensemble de porteuses ayant des caractéristiques distinctes, afin 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 fédérateur (comme Internet par exemple), entre ces réseaux LAN. Dans l'état de la technique, on trouve des tunnels constitués de porteuses mettant en oeuvre un protocole de transport avec acquittement de données, tel que par exemple le protocole TCP (« Transmission Control Protocol » en anglais), et de porteuses mettant en oeuvre un protocole de transport sans acquittement de données, tel que par exemple le protocole UDP (« User Datagram Protocol » en anglais). Le protocole TCP est un protocole de type ARQ (« Automatic Repeat Request », ou demande de répétition automatique) 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 et 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 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). De 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 paquets, afin d'assurer la délivrance des données à l'autre tête de tunnel. De telles retransmissions de paquets entraîneraient des variations importantes de la latence de bout en bout du flux RTP véhiculé. De plus, il est à noter que le mécanisme de contrôle de flux et le mécanisme de 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. Ainsi, un des principaux problèmes liés à ce type de réseau, est de maintenir une latence de transmission de bout en bout constante, tout en restant robuste vis-à-vis de la perte de données, afin de garantir une qualité perçue (« QoE » pour « Quality of Experience » en anglais) constante vis-à-vis de l'utilisateur. En effet, la moindre interruption dans la transmission du flux (causée par exemple par une perte de données sur la porteuse UDP du tunnel ou par un retard de la porteuse TCP conduisant à 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. Un flux de données est constitué d'une pluralité de blocs de données et est généralement protégé contre les erreurs de transmission par un code correcteur d'erreur. Au niveau du dispositif émetteur, les blocs de données du flux sont regroupés par paquets, chaque paquet étant alors encodé de façon à générer une pluralité de blocs de parité représentant des informations redondantes. Au niveau du dispositif récepteur, les paquets de données reçus sont décodés. Le décodage consiste, par exemple, à enlever les erreurs dans les blocs de données reçus en utilisant les blocs de parité. Il existe de nombreux algorithmes de contrôle d'erreur. Ces algorithmes sont classifiés selon les techniques FEC (« Forward Error Correction » en anglais), ARQ (« Automatic Repeat Request » en anglais) ou hybrides. La technique FEC est basée sur la transmission d'information redondante grâce à des codes correcteurs d'erreur. Dans la technique ARQ, un lien de retour est utilisé pour demander la retransmission des paquets erronés ou perdus. Les deux techniques ARQ et FEC peuvent être combinées et sont alors appelées techniques hybrides. Cette combinaison permet généralement à l'émetteur d'ajuster la quantité de redondance à envoyer par rapport aux acquittements reçus. Dans l'état de la technique, on distingue deux principales familles de techniques hybrides. Une première famille, dite hybride ARQ de type I, repose sur le principe selon lequel l'émetteur envoie en plus des paquets source, des paquets de redondance (aussi appelés paquets de parité). L'envoi de paquets de parité «proactifs» aboutit à une probabilité plus faible de manque de paquets à l'arrivée. Une seconde famille, dite hybride ARQ de type II, repose sur le principe selon lequel l'émetteur n'envoie dans un premier temps que les paquets source, puis envoie dans un deuxième temps des paquets de redondances si tous les paquets source n'ont pas été reçus. Une première technique, combinant les mécanismes hybrides ARQ de type I et II, est notamment présentée dans le document Robert Rammler R et al, « Performance of Parity-Based Loss Recovery for Reliable Multicast in Third-Generation Mobile Networks », 2005-09-11 PIMRC 2005, IEEE 16th International Symposium on « Personal, Indoor and Mobile Radio Communications ». Grâce à cette technique, l'efficacité de la transmission est améliorée car un paquet de parité (ou paquet FEC) peut permettre de réparer la perte de n'importe quel paquet de données qui a servi à construire le paquet de parité, et seule la connaissance du nombre de paquets reçus est utile pour corriger la perte.

Le document de brevet US 2006/0250949 décrit une technique de communication de données, au niveau couche de transport (selon le modèle OSI), adaptée aux environnements réseaux avec perte (tels que les liens sans fil par exemple). Plus précisément, ce document de brevet décrit une seconde technique consistant à transmettre en plus de paquets de données source, des paquets de parité relatifs à ces paquets de données (appelés paquets FEC proactifs). Si tous les paquets (données source et FEC proactifs) reçus par le récepteur ne permettent pas l'obtention de l'ensemble du groupe de paquets de données, alors le récepteur émet un acquittement ACK négatif vers l'émetteur. En réponse à cet acquittement, l'émetteur transmet de nouveaux paquets de parité (dits FEC réactifs), générés en fonction des informations contenues dans l'acquittement ACK, pour corriger les effacements sur les données. Les informations contenues dans le message d'acquittement ACK sont typiquement un nombre de paquets manquants (appelé « hole size ») permettant de reconstituer les données originales. Il a été constaté que les techniques précitées ne sont pas adaptées au cas des RPVs disposant d'un lien de communication multi-transport, c'est-à-dire utilisant des protocoles de transport différents pour transmettre des données. Notamment, ces techniques connues ne sont pas adaptées au cas où le lien de communication est, par exemple, un tunnel multi-transport dans lequel les données utiles sont transportées suivant un premier protocole de transport et les données de parité (associées à ces données utiles) suivant un second protocole de transport (distinct du premier protocole de transport). Ainsi, les techniques précitées ne permettent pas d'optimiser l'utilisation de la bande passante lors de retransmissions de données. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de fournir une technique de transmission d'un flux de données par un dispositif émetteur vers un dispositif récepteur, qui permette d'améliorer l'efficacité globale de la transmission de bout en bout de ce flux. Au moins un mode de réalisation particulier de l'invention a pour objectif de fournir une technique qui permette, dans un environnement réseau de type RPV mettant en oeuvre un tunnel multi-transport, une délivrance fiable et rapide d'un flux multimédia. En d'autres termes, ce mode de réalisation de l'invention a pour objectif de fournir une réponse appropriée au phénomène de perte de données dans un tel environnement, tout en limitant l'impact sur la bande passante de la retransmission de données pour palier à cette perte. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de transmission d'un flux de données par un dispositif émetteur vers un dispositif récepteur via un lien 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 dispositif émetteur étant tel qu'il effectue des étapes consistant à : - transmettre au dispositif récepteur des premières données de parité générées à partir de données sources dudit flux, par utilisation d'un protocole de transport avec acquittement et retransmission de données ; - recevoir, en provenance du dispositif récepteur, un message d'indication de non- réception par le dispositif récepteur d'au moins une parmi les premières données transmises, le message comprenant une information de non-réception d'au moins une donnée source ; - générer des secondes données de parité à partir de ladite information de non-réception d'au moins une donnée source ; - transmettre les secondes données de parité générées au dispositif récepteur, par utilisation dudit protocole de transport avec acquittement et retransmission de données, en réponse audit message reçu. Ainsi, il est proposé de transmettre des données de parité sur une porteuse utilisant un protocole de transport avec acquittement (par exemple, le protocole TCP) pour fiabiliser le flux (de données source) transmis sur une porteuse utilisant un protocole de transport sans acquittement (par exemple, le protocole UDP). Il est de plus proposé que, sur détection d'une perte de données de parité sur la porteuse avec acquittement (c'est-à-dire en cas de non réception par le dispositif récepteur de données de parité), les données de parité normalement à retransmettre (premières données de parité) sont remises à jour en fonction des données de parité perdues sur la porteuse avec acquittement, et de données sources ayant servi à créer les données de parité perdues et qui sont effectivement perdues sur la porteuse sans acquittement. En d'autres termes, il est proposé d'encoder de nouvelles données de parité (secondes données de parité) qui sont mieux adaptées à la perte de données constatée sur la porteuse sans acquittement, que les données de parité normalement à retransmettre.

Ainsi, l'utilisation de la bande passante entre le dispositif émetteur et le dispositif récepteur est améliorée, et la robustesse de transmission du flux de données source est accrue. Selon une caractéristique avantageuse, ladite étape consistant à générer des secondes données de parité comprend des étapes consistant à : - déterminer une première fenêtre d'encodage appliquée auxdites données source utilisée pour générer ladite au moins une première donnée de parité non reçue ; - déterminer une seconde fenêtre d'encodage, à partir de ladite au moins une donnée source indiquée dans ledit message comme non-reçue ; - générer les secondes données de parité à partir de ladite seconde fenêtre d'encodage déterminée. Il est donc proposé d'établir une première fenêtre d'encodage, c'est-à-dire d'appliquer l'encodage sur K données sources, puis d'adapter cette première fenêtre d'encodage (et dans ce sens déterminer une seconde fenêtre d'encodage), c'est-à-dire de changer les K données sources, pour générer les secondes données de parité. Les secondes données de parité ainsi générées ont pour avantage d'accroître la robustesse de la transmission du flux. De façon préférentielle, ladite au moins une donnée source indiquée dans ledit message comme non-reçue est comprise dans ladite première fenêtre d'encodage. Ainsi, la relation entre données source (indiquée comme non-reçue dans le message) et données de parité (dont le message notifie la non-réception selon le protocole de transport avec acquittement et retransmission de données) étant prédéfinie, la mise en oeuvre du procédé de transmission reste simple. Selon une caractéristique avantageuse, ladite au moins une donnée source indiquée dans ledit message comme non-reçue est associée à une fenêtre d'encodage ultérieure à ladite première fenêtre d'encodage.

Ainsi, pour une fenêtre d'encodage ultérieure à la première fenêtre d'encodage, le dispositif émetteur a connaissance d'une perte de données réelle sur la porteuse du protocole de transport sans acquittement de données (mais pas encore de la perte ou non des données de parité associées véhiculées selon le protocole de transport avec acquittement et retransmission de données). On notera que l'émetteur peut alors savoir si le nombre de données de parité préalablement transmises est suffisant (en considérant qu'elles sont toutes reçues) vis-à-vis d'un taux de perte sur la porteuse du protocole de transport sans acquittement de données. Selon une caractéristique avantageuse, le dispositif émetteur effectue des étapes consistant à : - modifier ledit message reçu en modifiant ladite indication de non réception de ladite au moins une des premières données de parité, en une indication de réception de ladite au moins une des premières données de parité ; - transmettre le message modifié à un module de traitement d'acquittement selon le protocole de transport avec acquittement et retransmission de données. Ainsi, on marque comme acquittées les premières données de parité considérées préalablement comme perdues par le dispositif récepteur. De cette façon, on substitue un acquittement « négatif » (émis par le dispositif récepteur en cas de non réception de donnée via le protocole de transport avec acquittement et retransmission de données) en un acquittement « positif » (émis par le dispositif récepteur en cas de réception, en séquence, de donnée via le protocole de transport avec acquittement et retransmission de données), ce qui permet d'éviter que le dispositif émetteur ne retransmette des données de parité normalement à retransmettre. Cela permet d'améliorer les performances de communication, en termes de bande passante et de gestion de congestion selon le protocole de transport avec acquittement et retransmission de données. De façon avantageuse, ladite étape consistant à modifier (603) ledit message reçu comprend en outre une étape consistant à supprimer ladite information de non-réception d'au moins une donnée source. De cette façon, on obtient un message d'acquittement conforme au protocole de transport avec acquittement. Dans le cas du standard TCP, le message d'acquittement ainsi obtenu ne laisse paraître que la réalité de réception (par le dispositif récepteur) de données utiles, liées à d'autres applications que celle liée au transport du flux considéré (distinctes des données de parité), et véhiculées selon le protocole TCP. Dans un mode de réalisation préférentiel, le lien de communication est un tunnel de communication interconnectant des réseaux locaux, et chacun des dispositifs émetteur et récepteur est une tête de tunnel appartenant à un réseau local respectif. Les données sources sont générées par un dispositif terminal source d'un dit réseau local et sont destinées à un dispositif terminal destination d'un dit réseau local distinct. Dans un autre mode de réalisation particulier de l'invention, il est proposé un procédé de réception par un dispositif récepteur d'un flux de données transmis par un dispositif émetteur via un lien 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 dispositif récepteur étant tel qu'il effectue des étapes consistant à : - recevoir des premières données de parité générées à partir de données sources dudit flux, lesdites premières données de parité étant transmises par le dispositif émetteur par utilisation d'un protocole de transport avec acquittement et retransmission de données ; - détecter au moins une première donnée de parité non reçue parmi lesdites premières données de parité ; - déterminer une information de non-réception d'au moins une donnée source ; - transmettre vers ledit dispositif émetteur un message d'acquittement de première(s) donnée(s) de parité reçue(s) par le dispositif récepteur, contenant ladite information de non-réception déterminée. De façon avantageuse, ladite au moins une donnée source indiquée dans ledit message comme non-reçue est comprise dans une fenêtre d'encodage utilisée pour générer ladite au moins une première donnée de parité non reçue. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en oeuvre du procédé de transmission précité (dans l'un quelconque de ses différents modes de réalisation) et/ou du procédé de réception précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur.

Dans un autre mode de réalisation, l'invention concerne un 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 précité (dans l'un quelconque de ses différents modes de réalisation) et/ou le procédé de réception précité (dans l'un quelconque de ses différents modes de réalisation). Dans un mode de réalisation particulier de l'invention, il est proposé un dispositif émetteur comprenant des moyens pour transmettre un flux de données vers un dispositif récepteur via un lien 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. Un tel dispositif émetteur comprend : - des moyens pour transmettre au dispositif récepteur des premières données de parité générées à partir de données sources dudit flux, par utilisation d'un protocole de transport avec acquittement et retransmission de données ; - des moyens pour recevoir, en provenance du dispositif récepteur, un message d'indication de non-réception par le dispositif récepteur d'au moins une parmi les premières données transmises, le message comprenant une information de non-réception d'au moins une donnée source ; - des moyens pour générer des secondes données de parité à partir de ladite information de non-réception d'au moins une donnée source ; - des moyens pour transmettre les secondes données de parité générées au dispositif récepteur, par utilisation dudit protocole de transport avec acquittement et retransmission de données, en réponse audit message reçu par lesdits moyens pour recevoir.

Avantageusement, le dispositif émetteur comprend des moyens de mise en oeuvre des étapes du procédé de transmission tel que décrit précédemment, dans l'un quelconque de ses différents modes de réalisation. Dans un mode de réalisation particulier de l'invention, il est proposé un dispositif récepteur comprenant des moyens pour recevoir un flux de données transmis par un dispositif émetteur via un lien 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. Un tel dispositif récepteur comprend : - des moyens pour recevoir des premières données de parité générées à partir de données sources dudit flux, lesdites premières données de parité étant transmises par le dispositif émetteur par utilisation d'un protocole de transport avec acquittement et retransmission de données ; - des moyens pour détecter au moins une première donnée de parité non reçue parmi lesdites premières données de parité ; - des moyens pour déterminer une information de non-réception d'au moins une donnée source ; - des moyens pour transmettre vers ledit dispositif émetteur un message d'acquittement de première(s) donnée(s) de parité reçue(s) par le dispositif récepteur, contenant ladite information de non-réception déterminée. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 illustre schématiquement une configuration d'un réseau privé virtuel pour la mise en oeuvre de l'invention selon un mode de réalisation particulier ; 20 - la figure 2 illustre schématiquement un exemple de modèle en couche d'une tête de tunnel dans laquelle est mis en oeuvre le procédé selon un mode de réalisation particulier ; - la figure 3 illustre schématiquement un exemple de format d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; 25 - la figure 4 illustre schématiquement les blocs fonctionnels d'un bloc émetteur compris dans une tête de tunnel, selon un mode de réalisation particulier de l'invention ; - la figure 5 illustre schématiquement les blocs fonctionnels d'un bloc récepteur compris dans une tête de tunnel, selon un mode de réalisation particulier de 30 l'invention ; 10 15 - la figure 6A représente un organigramme d'un algorithme de transmission d'un flux de données selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc émetteur de la figure 4 ; - la figure 6B représente un organigramme d'un algorithme de réception d'un flux de données selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc récepteur de la figure 5 ; - la figure 6C représente un organigramme d'un algorithme de gestion de messages d'acquittement selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc émetteur de la figure 4 ; - la figure 7 illustre un exemple de formats de paquets de données échangés entre deux têtes de tunnel ; - la figure 8 présente un mode de réalisation particulier de l'algorithme, implémenté au sein d'un module d'interception de messages (compris dans le bloc émetteur de la figure 4) ; - la figure 9 présente un mode de réalisation particulier des algorithmes, implémentés au sein d'un module de gestion de stockage (compris dans le bloc émetteur de la figure 4) ; - la figure 10 représente un organigramme d'un algorithme de gestion de messages d'acquittement selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc émetteur de la figure 4 ; - la figure 11 présente un mode de réalisation particulier d'un algorithme, implémenté au sein d'un module d'interception de messages (compris dans le bloc récepteur de la figure 5) ; et - la figure 12 représente un organigramme d'un algorithme de gestion de segment(s) TCP selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le module d'interception de messages (compris dans le bloc récepteur de la figure 5). 6. DESCRIPTION DÉTAILLÉE Dans la suite de la description, on se place dans le cas où le réseau de communication met en oeuvre un lien de communication qui est un tunnel, permettant à des dispositifs émetteur et récepteur d'échanger des données multimédia. Bien entendu, la présente solution peut s'appliquer à tout autre type de lien de communication entre des dispositifs émetteur et récepteur, comme par exemple des dispositifs émetteur et récepteur communiquant sur un même réseau LAN (« Local Area Network » en anglais).

La figure 1 illustre schématiquement, selon un mode de réalisation particulier de l'invention, une configuration de réseau privé virtuel (VPN pour « Virtual Private Network » en anglais) mettant en oeuvre un tunnel 100 de communication entre une première tête de tunnel locale 101 et une seconde tête de tunnel distante 102, à travers un réseau de communication 107, comme Internet par exemple. Ce tunnel 100 interconnecte un premier réseau de communication 103 et un second réseau de communication 104, encore appelés respectivement LAN A 103 et LAN B 104. Le premier réseau LAN A 103 et le second réseau LAN B 104 comportent chacun un équipement d'accès Internet haut débit de type passerelle Internet domestique (ou « Home Gateway » en anglais) (référencés respectivement 105 et 106), pouvant intégrer un pare-feu (ou « Firewall » en anglais) (référencés respectivement 105a et 106a), des équipements de type PC 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage des media numériques (de type audio, vidéo, photo), ainsi que des équipements de restitution des médias numériques 108 et 112. Une tête de tunnel peut être un équipement dédié (comme illustré sur la figure 1) ou bien être intégrée dans un équipement audiovisuel comme un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un programme réalisant les fonctions associées à celle-ci. Une fois le tunnel 100 établi, les équipements 108, 109, et 110, connectés au premier réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au second réseau LAN B 104. Par exemple, le client local 108 connecté au premier réseau LAN A 103 peut communiquer, de manière transparente, avec le serveur local 113 connecté au second réseau LAN B 104. Sur cette figure 1 est représenté un réseau de communication simple avec 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 être amenée à 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 dans le réseau Internet tels que les routeurs Internet. En relation avec la figure 2, on présente maintenant le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110, connectés au premier réseau LAN A 103, et entrant dans le tunnel 100 pour y être acheminée jusqu'au second réseau LAN B 104. Pour ce faire, on utilise un modèle en couches décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100. Dans ce modèle ne sont pas représentés les éléments de protocole nécessaire aux fonctions autres que la mise en oeuvre du tunnel. Par exemple, ne sont pas représentés les éléments de protocole associés à une architecture UPnP (pour « Universal Plug and Play » en anglais) lorsqu'une première tête de tunnel 101 est intégrée dans un équipement UPnP. La première tête de tunnel 101 comporte une interface physique Ethernet 235 qui remet les trames Ethernet issues des équipements 108, 109, 110 à la couche liaison 230 pour routage : vers la couche réseau 225, pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel, ou vers la couche de pont (« bridge » en anglais) 240, pour les autres trames Ethernet. La couche de pont 240 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relai de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Sur le pont sont attachées une interface Ethernet 230 et au moins une interface virtuelle 245 simulant un contrôleur Ethernet. Une interface virtuelle 245 est créée pour chaque tunnel instancié par l'application 200 à qui elle remet les trames Ethernet qui doivent transiter sur les tunnels respectivement instanciés. 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 oeuvre de chaque tunnel, parmi lesquelles on trouvera notamment la configuration, le filtrage et l'encapsulation, c'est-à-dire la formation d'un paquet tunnel, et l'extraction d'une trame. Dans un mode de réalisation particulier, l'application 200 met en oeuvre des étapes du procédé qui sont détaillées ci-après en relation avec les figures 6 (A,B,C) à 12.

Les trames reçues de l'interface virtuelle 245, après traitement par l'application 200, sont remises sous la forme d'un paquet à travers une interface applicative 205 (ou « socket » en anglais) à un protocole de transport fiable TCP 210 ou non fiable UDP 220.

Dans le cas où le protocole de transport fiable TCP 210 est sélectionné, les trames Ethernet sont dirigées vers le protocole tunnel hybride ARQ 215, qui est détaillé ci-après en relation avec les figures 6 (A,B,C) à 12. Après traitement par un protocole de transport pour former un paquet tunnel, celui-ci est transmis à la couche réseau 225. Le datagramme IP ainsi formé avec le paquet tunnel peut ensuite être transmis sur le réseau LAN à travers les couches liaison 230 et physique 235, pour ensuite être transmis 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 101 le cheminement inverse à celui présenté ci-dessus.

On note que dans le cas où le protocole hybride ARQ est mis en oeuvre en dehors d'un contexte de tunnellisation, la couche de pont 240 et l'interface virtuelle 245 sont désactivés. Dans ce cas, la couche applicative 200 représente n'importe quelle couche applicative selon le modèle OSI, c'est-à-dire, par exemple, des applications classiques du type HTTP, FTP, etc... Ainsi, le protocole hybride ARQ 215 peut s'appliquer à toute communication depuis un premier dispositif vers un second dispositif. La figure 3 présente un exemple de format d'une trame Ethernet 360, transitant par exemple sur le premier réseau LAN A 103 de la figure 1 entre la première tête de tunnel 101 et la passerelle domestique 105. Cette trame Ethernet 360 peut être transmise vers le second réseau LAN B 104 via Internet ou être reçue du second réseau LAN B 104 via Internet. Cette trame Ethernet 360 comprend un champ d'en-tête Ethernet 361, un premier datagramme IP 362 véhiculant lui-même un paquet tunnel 350 de niveau 2, et un champ FCS 363 (pour « Frame Check Sequence » en anglais, ou « séquence de contrôle de trame » en français).

Le paquet tunnel 350 comporte quatre parties : - un champ d'en-tête du protocole de transport 351 (à savoir TCP ou UDP dans cet exemple) ; - un champ d'en-tête du protocole d'encapsulation 352 (à savoir L2TP dans cet exemple, qui est décrit notamment dans le document suivant : « IETF RFC- 3931, "Layer two tunneling protocol û version 3 (L2TPv3)", J. Lau and ail, March 2005 » ; - un champ d'en-tête du protocole embarqué 353 (à savoir Ethernet dans cet exemple) ; et - un champ de données utiles 354, qui comporte un second datagramme IP complet si aucune fragmentation n'a été opérée lors de son transit depuis l'équipement source. La figure 4 illustre schématiquement les blocs fonctionnels d'un bloc émetteur compris dans les têtes de tunnel selon un mode de réalisation de l'invention. Chaque tête de tunnel (TEP) 101 ou 102 comprend un bloc émetteur 410 permettant l'émission de données via le tunnel 100 multi-transport (c'est-à-dire via un tunnel comprenant plusieurs porteuses utilisant chacune un protocole de transport, comme par exemple une porteuse TCP et une porteuse UDP). 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 aucune donnée de correction d'erreur n'est adjointe dans le cadre du mode de réalisation particulier de l'invention, ne sont pas représentés (c'est le cas par exemple pour les flux intégralement transmis sur la porteuse UDP sans transmission de données de redondance (ou de parité) sur la porteuse TCP).

La description suivante porte uniquement sur la transmission d'un flux de données 401 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, dans le sens inverse, c'est-à-dire depuis la tête de tunnel 102 vers la tête de tunnel 101. Il convient aussi de noter qu'un seul flux 401 de données, transporté via le tunnel 100 depuis la tête de tunnel 101 vers la tête de tunnel 102, 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. Le bloc émetteur 410 de la tête de tunnel 101 reçoit en entrée un flux 401, en provenance du réseau LAN A 103, et est en charge de transporter les données de ce flux 401 via le tunnel 100, en tirant profit des porteuses TCP 100A et UDP 100B. Dans la suite de la description, le transport d'un flux 401 est effectué via la porteuse UDP 100B et le transport de données de parité associées à ce flux est effectué via la porteuse TCP 100A. Dans le mode de réalisation illustré par la figure 4, le bloc émetteur 410 de la tête de tunnel 101 comprend les éléments suivants : - 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é). Les paramètres du code correcteur d'erreur sont un nombre M de paquets de parité générés pour un nombre K de paquets du flux 401. Dans un premier mode de réalisation particulier (décrit en détail ci-après), le code correcteur d'erreur est un code de type Reed-Solomon appliqué au niveau paquet. Dans un second mode de réalisation particulier (décrit en détail ci-après), le code correcteur d'erreur est un code basé sur une utilisation de OU-EXCLUSIFs (XORs) appliqué au niveau paquet. Le module décisionnaire 412 est en charge d'aiguiller chacun des paquets du flux 401 du réseau LAN 103 vers l'une des porteuses du tunnel 100 ; - 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 ; - 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 ; - un port d'interface 411, représentant la couche réseau IP 225 ; - un module de gestion de protocole hybride ARQ 430 comprenant lui-même les éléments suivants : • un module de gestion de stockage temporaire 4154, en charge de piloter le fonctionnement de l'unité de stockage 417, destinée au stockage des données source du flux 401, et d'une table 419 de support d'indexation de numéros de séquence TCP correspondant au transport d'une donnée de parité sur la porteuse TCP 100A ; • un module d'interception de messages 4153, en charge d'intercepter les messages circulant dans la direction couche TCP 210 vers couche réseau IP 225 (pour déterminer les numéros de séquence TCP transportant une donnée de parité), et dans la direction couche réseau IP 225 vers couche TCP 210 (pour analyser les informations liées au protocole hybride ARQ dans les acquittements reçus) ; • un module générateur de messages 4152, en charge de transmettre des paquets de parité appropriés aux pertes rencontrées sur la porteuse UDP 100B, suite à la réception d'une information de perte selon le protocole hybride ARQ. Le module décisionnaire 412 comprend un récepteur de statistiques (non représenté) recevant des informations relatives à des conditions de transmission via le 15 tunnel 100 (notamment des informations de taux de perte de paquets), et permettant au module 412 de déterminer les paramètres du code correcteur d'erreur nécessaire à l'encodage des paquets de parité. Ces statistiques obtenues permettent de déterminer la proportion de données de parité à émettre pour rendre le flux a priori robuste aux pertes. Le fonctionnement d'un tel récepteur de statistiques est notamment décrit dans le 20 document de brevet EP 2,020,799. Le module d'encodage 415 effectue un encodage sur un premier ensemble de K paquets du flux 401 (appelé par la suite fenêtre d'encodage de taille K) afin d'obtenir un second ensemble de M paquets de parité. Il est à noter que, dans un mode de réalisation particulier de l'invention, le module d'encodage 415 agit au niveau paquet (« at packet 25 level » en anglais), 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 100. On obtient alors un nombre N total de paquets, tel que N = M + K, à transmettre via le tunnel 100. Le module décisionnaire 412 aiguille ensuite les M paquets de parité vers la porteuse TCP 100A via l'empaqueteur 413 et les K paquets issus du flux 401 vers la 30 porteuse UDP 100B via l'empaqueteur 414. Ainsi l'émission des paquets du flux via la 10 porteuse UDP 100B du tunnel est fiabilisée par l'émission de paquets de parité via la porteuse TCP 100A du tunnel. Dans un mode de réalisation particulier de l'invention, les paquets du flux 401 ont une taille MTU (pour « Maximum Transmission Unit » en anglais) permettant une insertion directe des paquets de données constitués dans le champ de données utiles 354 (décrit en relation avec la figure 3) lors de l'encapsulation pour transport sur la porteuse UDP 100B. Dans le cas où le module décisionnaire 412 utilise un code correcteur d'erreur de type Reed-Solomon appliqué au niveau paquet, le codage est effectué à l'aide d'une matrice. Les K paquets issus du flux 401 sont rangés de telle sorte que chacun d'eux 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 ensuite 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 le 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 d'eux forme une colonne de la matrice, chaque élément de la matrice représentant alors un symbole reçu. Un décodage de type Reed-Solomon, correspondant au code C(N,K) appliqué, est ensuite appliqué sur chaque ligne de la matrice, de manière à obtenir une matrice résultante comprenant les symboles originaux. Les K paquets de la fenêtre d'encodage forment les colonnes de la matrice résultante. Dans le cas où le module décisionnaire 412 utilise des fonctions de OUEXCLUSIFs (XORs) pour la construction d'un paquet de parité, les K paquets du flux 401 sont combinés de la manière suivante : - soit « pl,p2,...,pK » les K paquets (de taille « m ») du flux 401 et « » la valeur du ième bit du paquet « pi » (avec j=1,...,k) ; - soit « r » le paquet de parité à construire et « r' » la valeur du ième bit du paquet de parité ; - alors : K = p~ (mod 2)Vi E1,.., m} i=1 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 paquets. Une telle opération est simple à mettre en oeuvre sur du matériel (« hardware » en anglais) embarqué. Cette opération 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. La figure 5 illustre schématiquement les blocs fonctionnels d'un bloc récepteur compris dans les têtes de tunnel selon un mode de réalisation de l'invention. Chaque tête de tunnel 101 ou 102 comprend un bloc récepteur 420 permettant la réception de données via le tunnel 100.

Le bloc récepteur 420 de la tête de tunnel 102 reçoit les données depuis le tunnel 100, et restitue, sur le réseau LAN B 104, un flux 402 de données correspondant au flux 401 original (par exemple, le flux 402 est identique au flux 401 (s'il n'y a pas eu de perte sur Internet). Dans le mode de réalisation illustré par la figure 5, le bloc récepteur 420 de la tête de tunnel 102 comprend les éléments suivants : - un port d'interface 411, représentant la couche réseau IP 225, sur lequel sont reçus les paquets encapsulés émis par le dispositif émetteur 101 ; - des dé-paqueteurs 421 et 422 chacun dédié à une porteuse du tunnel 100, en charge de dés-encapsuler les données en provenance du tunnel 100 ; - une unité 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, grâce aux formats de paquets de données décrits ci-après en relation avec la figure 7 ; - un régénérateur de trame 424, en charge de reconstituer les trames du flux 402 obtenu en sortie du tunnel, à partir des données du flux 401 transmises via la porteuse UDP 100B et des données de parité transmises via la porteuse TCP 100A et stockées dans l'unité de stockage temporaire 423. Le régénérateur de trame 424 est également en charge de délivrer et de cadencer sur le réseau LAN B 104 les paquets du flux 402. Par exemple, pour des flux 401 et 402 de type RTP, le marquage temporel (« timestamp » en anglais) compris dans chaque paquet RTP est utilisé pour effectuer le cadencement du flux 402 par un séquenceur de flux (non représenté), de façon à maintenir une gigue (« jitter » en anglais) 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, en charge 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 100, et ce, en fonction de la fenêtre d'encodage déterminée par le module décisionnaire 412. Les paramètres du code correcteur d'erreur appliqué sont communs et connus du module d'encodage 415 et du régénérateur de trame 424. Ceux-ci peuvent être prédéfinis et stockés en mémoire morte, ou bien échangés entre les blocs émetteur 410 et récepteur 420, par exemple dans une session de contrôle du tunnel 100. L'unité de stockage temporaire 423 est adaptée pour stocker temporairement les paquets reçus via la porteuse UDP 100B, 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 100A a une latence plus importante que la porteuse UDP 100B. Par exemple, l'unité de stockage temporaire 423 est dimensionnée pour conserver les paquets du flux 401 sur une période égale à la valeur d'un temps d'aller retour de bout en bout dans le réseau (« RTT » pour « Round Trip Time » en anglais) plus une marge supplémentaire pour palier au déséquencement entre la porteuse UDP 100B et la porteuse TCP 100A (par exemple, 1/2 RTT). Un tel accroissement de la capacité de stockage en réception est amplement suffisant pour absorber la différence de latence entre les porteuses UDP 100B et TCP 100A. La latence induite par ce stockage temporaire supplémentaire est faible comparée à la latence globale du réseau Internet. Le bloc récepteur 420 comprend en outre un module de gestion de protocole hybride ARQ 431 comprenant lui-même les éléments suivants : - un module d'interception de messages 4251, en charge d'intercepter les messages circulant dans la direction couche réseau IP 225 vers couche TCP 210 (pour localiser les numéros de séquence TCP transportant une donnée de parité), et dans la direction couche TCP 210 vers couche réseau IP 225 (pour analyser les acquittements de la couche TCP 210 et pour y adjoindre des informations propriétaires utiles à l'émetteur pour le bon fonctionnement du protocole hybride ARQ 215); - un module générateur de messages 4252, en charge de transmettre des messages d'acquittement ACK modifiés permettant de véhiculer des informations relatives aux pertes rencontrées sur la porteuse UDP 100B selon le protocole hybride ARQ215; - un module de gestion d'une table 4253 de support d'indexation de numéros de séquence TCP correspondant au transport de donnée(s) de parité par fenêtre d'encodage sur la porteuse TCP 100A. Suite à la réception d'un message TCP (dont le format est décrit ci-après en relation avec la figure 7), la table 4253 contient les enregistrements suivants : • des associations entre numéros de séquence TCP et numéro SBN de fenêtre d'encodage ; • des associations entre numéros de séquence TCP et présence d'une donnée de parité. Dans la suite du document, les algorithmes d'un mode de réalisation de l'invention sont décrits selon une mise en place sur une tête de tunnel 101 ou 102. Le bloc émetteur 410 et le bloc récepteur 420, compris dans chaque tête de tunnel, se réalisent chacun indifféremment : • sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou • sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC). Dans le cas d'une réalisation d'un module (bloc émetteur ou récepteur) sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non amovible, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. La figure 6A représente un organigramme d'un algorithme de transmission d'un flux de données selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc émetteur 410.

Sur réception d'un flux de données 401, le bloc émetteur 410 effectue les étapes suivantes. Dans une étape 620, le module d'encodage 415 génère M paquets de parité à partir des K paquets du flux 401 (les M paquets de parité étant aussi appelées données encodées). On obtient alors un nombre N total de paquets, tel que N = M + K, à transmettre via le tunnel 100. Le module décisionnaire 412 aiguille, dans une étape 621, les M paquets de parité vers la porteuse TCP 100A via l'empaqueteur 414 et, dans une étape 622, les K paquets issus du flux 401 vers la porteuse UDP 100B via l'empaqueteur 413. Ainsi, la transmission des paquets du flux via la porteuse UDP 100B est fiabilisée par la transmission de paquets de parité via la porteuse TCP 100A. La figure 6B représente un organigramme d'un algorithme de réception d'un flux de données selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc récepteur 420. Sur réception d'un flux de paquets de données via la porteuse UDP 100B et de paquets de parité associés via la porteuse TCP 100A, le bloc récepteur 420 effectue les étapes suivantes. Sur réception d'un message d'acquittement ACK de la couche TCP 210, à destination de la tête de tunnel ayant émis le paquet à acquitter, il est procédé à la détermination (étape 630) d'une information de perte sur la porteuse TCP 100A (dans le sens de transfert bloc émetteur 410 vers bloc récepteur 420). Si une information de perte est déterminée, alors on vérifie si la perte sur la porteuse TCP 100A correspond à une perte d'un paquet de parité, c'est-à-dire si le segment TCP perdu contient tout ou partie d'un paquet de parité, noté Mi. Si aucune perte de paquet de parité n'est détectée à l'étape 630, alors le message d'acquittement ACK est transmis (étape 633) à la couche réseau IP 225 pour une émission à destination de la tête de tunnel 101. En revanche, si une perte d'un paquet de parité est détectée à l'étape 630, alors on détermine (étape 631) parmi les K paquets transmis sur la porteuse UDP 100B ceux correspondants au paquet de parité Mi de la même fenêtre d'encodage et qui n'ont pas été reçus (et donc considérés comme perdus).

Ensuite, à l'étape 632, une information de perte relative aux paquets UDP perdus de l'ensemble K constituant la fenêtre d'encodage considérée est insérée dans le message d'acquittement ACK. Ainsi, le message d'acquittement ACK véhicule une information liée à une perte ayant eu lieu sur la porteuse TCP 100A (comme classiquement), et une information liée à une perte ayant eu lieu sur la porteuse UDP 100B pour des paquets source, ayant servi à encoder le paquet (ou les paquets) perdu(s) sur la porteuse TCP 100A. Puis, le message d'acquittement ACK est transmis (étape 633) à la couche réseau IP 225 pour une émission à destination de la tête de tunnel 101. La figure 6C représente un organigramme d'un algorithme de gestion de messages d'acquittement selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc émetteur 410 de la tête de tunnel 101 ayant émis le flux. Dans une étape 600, le module de gestion de protocole hybride ARQ 430 intercepte un message d'acquittement ACK en provenance de la porteuse TCP 100A, et détermine si le message d'acquittement ACK reçu contient une information liée à une perte sur la porteuse UDP 100B. Une interception de message d'acquittement ACK est réalisée lorsque ce message indique une perte sur la porteuse TCP 100A, et que cette perte correspond à un numéro de séquence de transmission d'une donnée de parité en relation avec les données véhiculées sur la porteuse UDP 100B.

Si le message d'acquittement ACK reçu ne contient aucune information de perte sur la porteuse UDP 100B, alors le message d'acquittement ACK est transmis (étape 604) à la couche TCP 210. En revanche, si le message d'acquittement ACK reçu contient une information liée à une perte sur la porteuse UDP 100B, alors le module d'encodage 415 génère (étape 601) H nouveaux paquets de parité, en fonction de l'information liée à une perte (résultat de réception de données) sur la porteuse TCP 100A, ainsi que de celle liée à une perte sur la porteuse UDP 100B. Le mode de fonctionnement de l'étape 601 est détaillé ci-après en relation avec la Figure 10. Dans une étape 602, le module générateur de messages 4152 transmet directement les H nouveaux paquets de parité via la couche réseau IP 225, selon le format d'encapsulation de la porteuse TCP 100A. Ainsi, la transmission des paquets de parité est ignorée de la couche TCP 210. Il n'est donc pas nécessaire de modifier le protocole de transport avec acquittement et retransmission, de type ARQ, tel que le protocole de transport TCP. L'invention vient alors s'intercaler entre la couche de mise en oeuvre de ce protocole de transport (couche protocolaire supérieure) et la couche réseau (couche protocolaire inférieure). Ensuite, lors d'une étape 603, le module de gestion de protocole hybride ARQ 430 modifie le message d'acquittement ACK intercepté à l'étape 600, en supprimant l'information liée à la perte sur la porteuse UDP 100B. De plus, il est procédé à la modification, dans le message d'acquittement ACK, des numéros de séquence indiquant une perte sur la porteuse TCP 100A, afin de masquer la perte de la partie du segment TCP correspondant aux données de parité. Ainsi, la couche TCP 210 ne retransmet pas les données de parité générées selon le protocole hybride ARQ 215, qui ont été perdues sur la porteuse TCP 100A.

Enfin, lors d'une étape 604, le message d'acquittement ACK modifié (à l'étape 603) est transmis à la couche TCP 210. Ainsi, la couche TCP 210 retransmet (si besoin) uniquement des parties de segments TCP perdus dont le contenu est sans rapport avec des données de parité. Ainsi, en envoyant à la couche TCP 210 le paquet d'acquittement modifié (pour limiter la zone des données qui avaient été identifiées comme étant à retransmettre), la couche TCP 210 va générer, en réponse à cet acquittement, une retransmission qui ne concerne que des données du flux initial non associées à des données de parité. Ainsi, les performances de communication en termes d'occupation de bande passante sont améliorées. Lorsque le besoin de retransmission signifié par l'acquittement reçu est uniquement relatif à une donnée de parité présente dans le flux initial, la technique de l'invention substitue cet acquittement négatif (indiquant une perte de donnée) en acquittement positif (indiquant que les données ont été reçues) des données transmises, ce qui permet le maintien de performances de communication optimales (en termes de bande passante et de gestion de congestion selon le protocole de transport avec acquittement et retransmission).

La figure 7 illustre un exemple de 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. A titre d'exemple, une encapsulation de données selon le protocole L2TP (selon la norme RFC-3931) est utilisée. Le format des trames supportant une telle encapsulation peut être conservé pour toute communication mise en oeuvre en dehors d'un contexte de tunnellisation, c'est-à-dire que les données utiles transportées 723, 753 ne sont plus des trames Ethernet passagères mais des données applicatives locales. Comme déjà mentionné, pour pouvoir appliquer un mécanisme de correction d'erreur de type FEC, les paramètres du code correcteur d'erreur doivent être connus du bloc émetteur 410 et du bloc récepteur 420. Le module d'encodage 415 peut fournir au module correcteur 4241 les paramètres du code correcteur d'erreur utilisés (notamment les paramètres M et K, et le type de code correcteur d'erreur) lors d'une session de contrôle. Dans un mode de réalisation particulier, les informations échangées sont relatives à l'objet FEC OTI (pour « Forward Error Correction Object Transmission Information »), qui est décrit notamment dans le document de normalisation RFC-5052 (« FEC Building Block »). On présente ci-après, en relation avec la figure 7, un exemple de format d'encapsulation 720 d'un paquet de données (issu du flux 401) selon le protocole L2TP sur la porteuse UDP 100B. Le paquet de données encapsulé 720 selon un tel protocole comporte plus précisément : - une première partie d'en-tête 721 d'encapsulation de session L2TP ; - une seconde partie d'en-tête 722 d'encapsulation spécifique au transport des paquets de données, comprenant les champs suivants : * un champ « Numéro de Séquence » contenant une valeur de numéro de séquence SN propre à chaque paquet de données L2TP. Ce numéro de séquence SN est utilisé pour les besoins d'opérations effectuées à la réception des paquets de données. Par exemple, on utilise un tel numéro de séquence SN lors d'une opération de ré-ordonnancement des données. Dans le cas d'un mode de réalisation particulier de l'invention, le numéro de 25 30 séquence SN est utilisé pour regrouper les paquets du flux 401 d'une même fenêtre d'encodage (de taille K) ; * un drapeau « F » (pour « Flag ») indiquant si les données utiles encapsulées dans une troisième partie 723 ont fait l'objet d'un encodage de parité par le module d'encodage 415. On présente maintenant, toujours en relation avec la figure 7, un exemple de format d'encapsulation 750 d'un paquet de parité (généré par le module d'encodage 415) selon le protocole L2TP sur la porteuse TCP 100A. Le paquet de parité encapsulé 750 selon un tel protocole comporte plus précisément : - une première partie d'en-tête 751 d'encapsulation de session L2TP ; - une seconde partie d'en-tête 752 d'encapsulation spécifique au transport des paquets de parité, comprenant les champs suivants : * un drapeau « F » (pour « Flag FEC ») indiquant si les données utiles constituent des données de parité (F égal à 1 si les données utiles constituent des données de parité, 0 sinon) ; * un drapeau « R » (pour « Retransmit FEC ») indiquant si les données de parité transportées sont issues d'une retransmission selon le protocole hybride ARQ ; * un champ « SBN » (pour « Source Block Number ») contenant un numéro de fenêtre d'encodage, identifiant la fenêtre d'encodage de K paquets à laquelle le paquet encapsulé est associé ; * un champ « ESI » (pour « Encoding Symbol Identifier ») contenant un identifiant de symbole de codage, identifiant les paquets du flux 401 utilisés pour l'encodage des paquets de parité ; * un champ « PCL » (pour « Parity Code Localization ») contenant un marquage utilisé pour localiser des paquets/données de parité dans le flux de transport de la porteuse TCP 100A. L'unité de stockage temporaire 423 du bloc récepteur 420 est organisée sous 30 forme de liste chaînée d'éléments, appelés noeuds, où chaque noeud regroupe un 20 25 ensemble de paquets de données utiles 723 ou de données de parité 753 relatives au flux 401, estampillées par un même numéro SBN de fenêtre d'encodage. Du fait que le paramètre K de nombre de paquets source dans une fenêtre d'encodage et le paramètre M de nombre de paquets de parité générés sont connus par avance de l'émetteur et du récepteur, et du fait que la porteuse TCP 100A a une latence plus importante que la porteuse UDP 100B, alors à chaque réception d'un paquet TCP contenant une donnée de parité 753, le bloc récepteur 420 réorganise les données utiles 723 (en fonction du numéro de séquence SN que véhiculent les paquets UDP dans leur seconde partie d'en-tête 722) en relation avec le numéro SBN de fenêtre d'encodage. En d'autres termes, pour une donnée source 723, il est procédé au rattachement de cette donnée source 723 avec la donnée de parité 753 correspondante. Ensuite, il est procédé à l'identification des paquets UDP 720 perdus dans le tunnel 100. Dans le cas où le module décisionnaire 412 utilise un code correcteur d'erreur de type Reed-Solomon appliqué au niveau paquet, le champ ESI correspond à l'indice du paquet de parité généré. Pour une même fenêtre d'encodage de K paquets du flux 401, chaque paquet 750, transportant une donnée de parité Mi, a un champ ESI différent, selon l'indice i de génération, respectant i<M. La valeur du champ SBN est identique pour des paquets de parité d'une même fenêtre d'encodage. La valeur du champ SBN est incrémentée d'une unité à chaque nouvelle fenêtre d'encodage.

Dans le cas où le module décisionnaire 412 utilise des fonctions de OUEXCLUSIFs (XORs) pour la construction d'un paquet de parité, c'est-à-dire dans le cas où une opération OU-EXCLUSIF (XOR) est appliquée entre les K paquets du flux 401, le champ ESI indique la portée de l'opération OU-EXCLUSIF (XOR) sur une fenêtre d'encodage de K paquets du flux 401. Par exemple, à chaque bit de la représentation binaire de la valeur du champ ESI est 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é par le code correcteur d'erreur (bit à 1 si tel est le cas, bit à 0 sinon). Le champ PCL de la seconde partie d'en-tête 752 identifie la position des données de parité véhiculées sur la porteuse TCP 100A au regard des autres données transportées sur cette porteuse TCP 100A. Ces autres données sont liées à d'autres applications que celle liée au transport du (ou des) flux 401 (c'est-à-dire des données qui ne sont pas des données de parité générées par le protocole hybride ARQ 215). La structure 760 détaille le formatage du champ PCL. L'unité représentée par un bit correspond à un décalage de taille MSS (pour « Maximum Segment Size » en anglais, correspondant à la taille maximale de segment TCP telle que définie dans la norme RFC-793) dans les numéros de séquence TCP (par rapport au paquet reçu courant). Les bits représentés représentent des numéros de séquence TCP non assimilables à des paquets TCP. En effet, un paquet TCP peut véhiculer des retransmissions, ce qui ne permet pas de conserver un alignement entre numéro de paquet et numéro de séquence. Le champ PCL 760 se lit de droite à gauche, et comporte deux parties : - pour les bits 0 à 15, la valeur de chaque bit de ce premier sous-champ de 16 bits indique la localisation des fenêtres d'encodage (c'est-à-dire un changement de numéro SBN) dans le flux continu TCP à partir du paquet courant (représenté par le bit 15). L'index du bit à 1, dans le sens de lecture précité, donne le nombre de MSS compris entre le début de la fenêtre d'encodage considérée et le paquet courant (bit 15) ; - pour les bits 16 à 31, la valeur de chaque bit de ce second sous-champ de 16 bits indique la localisation d'un début d'une donnée de parité (c'est-à-dire le premier octet du paquet 750) dans le flux continu TCP à partir du paquet courant (représenté par le bit 31). L'index du bit à 1, dans le sens de lecture précité, donne le nombre de MSS compris entre la précédente donnée de parité transmise et le paquet courant (bit 31). La corrélation des premier et second sous-champs permet d'une part d'identifier les séquences TCP (avec une granularité de MSS octets) contenant des données de parité, et d'autre part d'identifier le numéro SBN de fenêtre d'encodage pour chacune de ces données de parité. Pour l'exemple du champ PCL 760 illustré sur la figure 7, on lit les informations suivantes : - le paquet TCP courant ne contient pas de paquet 750 transportant des données de parité (bit 31 à 0) ni de nouvelle fenêtre d'encodage (bit 15 à 0) ; - les données précédemment transmises étaient relatives à 3 fenêtres d'encodage : • le début de la fenêtre d'encodage courante (de numéro SBN = i) se situe à 4 MSS (bit 12 à 1) du paquet courant (bit 15). Dans cet exemple, il y a eu deux paquets de parité 750 transmis pour ce numéro SBN (bits 30 et 28 à 1) ; • le début de la fenêtre d'encodage précédente (de numéro SBN = i-1) se situe à 12 MSS (bit 4 à 1) du paquet courant (bit 15), et la fenêtre d'encodage précédente a une taille de 9 MSS. Il n'y a eu qu'un seul paquet de parité 750 transmis ; • on ne sait pas quand a débuté la fenêtre d'encodage de numéro SBN = i-2, mais on sait que le paquet de parité 750 qui se situe à 16 MSS du paquet courant, s'y rapporte (bit 16 à 1).

Dans un autre mode de réalisation, le champ PCL n'est pas présent dans la zone d'encapsulation 752 mais plutôt dans l'entête de chaque segment TCP sous forme d'option TCP. Ceci a pour avantage particulier d'éviter au récepteur de se synchroniser sur un début de paquet 750 pour l'obtention de ce champ PCL. On note que le mode de localisation présenté avec une granularité de MSS octets est suffisant au niveau du bloc récepteur 102 pour détecter la présence de données de parité dans des demandes de retransmission issues de la couche TCP 210 de réception. On laisse le bloc émetteur 410 choisir plus finement les données qu'il va effectivement retransmettre car il a une connaissance fine de la localisation des données de parité dans le flux continu TCP.

Dans un mode de réalisation (non présenté), le bloc émetteur 410 transmet sur le réseau des informations de localisation fine des données de parité dans le flux continu TCP, par exemple, sous la forme d'une liste de numéro de séquences TCP. La figure 8 présente un mode de réalisation particulier des algorithmes, implémentés au sein du module d'interception de messages 4153 (compris dans le bloc émetteur 410) et qui permettent de traiter les messages circulant de la couche TCP 210 vers la couche IP 225 (étapes 850 à 890), et de la couche IP 225 vers la couche TCP 210 (étapes 800 à 840). A l'étape 850, le module d'interception de messages 4153 intercepte un segment TCP (noté « tcp_seg »), provenant de la couche TCP 210, en direction de la couche IP 225. On rappelle que les paquets créés par le module décisionnaire 412 sont transmis aux couches UDP 220 et TCP 210 selon les formats d'encapsulation précédemment décrits, et sont transportés à travers les couches 215, 225, 230 et 235 selon le modèle OSI présenté à la figure 2. A l'étape 860, un test est effectué pour déterminer si le segment tcp_seg contient un paquet de parité encapsulé 750 comprenant lui-même des données de parité. Si le segment tcp_seg ne contient aucune donnée de parité (drapeau F à 0), alors on passe à une étape 890 de mise à jour du champ PCL (décrite ci-après). Si le segment tcp_seg contient des données de parité (drapeau F à 1), alors les étapes 870 et 880 sont exécutées.

A l'étape 870, il est procédé à l'obtention du numéro de séquence TCP de début de paquet 750 et du numéro SBN de fenêtre d'encodage contenu dans le paquet 750. Ensuite, ces numéros sont transmis (étape 880) vers le module de gestion de stockage temporaire 4154, pour être stockés dans la table d'index 419. A l'étape 890, il est procédé à la mise à jour du champ PCL (contenu dans le segment tcp_seg), de façon à renseigner le destinataire sur le contenu du segment TCP courant, puis, à la transmission du segment tcp_seg vers la couche IP 225. Dans un mode de réalisation particulier, le champ PCL est stocké dans une mémoire morte comprise dans le module d'interception de messages 4153. De cette façon, il est possible d'obtenir très rapidement la précédente valeur de ce champ PCL (qui est modifiée à chaque nouveau paquet 750 reçu de la couche TCP 210). A titre d'exemple, on considère que, à la mise sous tension de la tête de tunnel 101, la valeur initiale du champ PCL est O. Par exemple, à l'étape 890, le champ PCL est mis à jour de la façon suivante : - après obtention de la valeur PCL mémorisée, il est procédé à un décalage de 1 bit vers le poids faible (c'est-à-dire vers le côté gauche sur le schéma de la figure 7) de la valeur représentée par les bits 0 à 15 du champ PCL 760, et de la valeur représentée par les bits 16 à 31 du champ PCL 760 ; - le bit 31 est mis à 1 si le segment tcp_seg contient des données de parité (cas où le test de l'étape 860 est positif), 0 sinon ; - le bit 15 est mis à 1 si le segment tcp_seg contient des données de parité (cas où le test de l'étape 860 est positif) et s'il s'agit d'une nouvelle fenêtre d'encodage (c'est-à-dire si la valeur du numéro SBN du paquet 750 est supérieure à la valeur précédente stockée dans le module de gestion de stockage temporaire 4154. Sinon, le bit 15 est mis à 0.

A l'étape 800, le module d'interception de messages 4153 intercepte un paquet de données (noté « rcv_pkt »), provenant de la couche IP 225, en direction de la couche TCP 210. A l'étape 810, un test est effectué pour déterminer si le paquet rcv_pkt est de type TCP et s'il contient un message d'acquittement ACK.

Si le paquet rcv_pkt ne contient aucun message d'acquittement ACK, alors le paquet rcv_pkt est directement transmis (étape 840) vers la couche TCP 210. Si le paquet rcv_pkt contient un message d'acquittement ACK, alors un test est effectué (étape 820) pour déterminer si le message d'acquittement ACK contient des informations liées à une perte de paquet sur la porteuse UDP 100B.

Si le message d'acquittement ACK ne contient aucune information liée à une perte de paquets sur la porteuse UDP 100B, alors l'étape 821 est exécutée afin de prendre en compte le(les) segment(s) TCP acquitté(s) par ce message, et ainsi vider la zone de stockage temporaire (via le module 4154) des données source émises sur la porteuse UDP 100B. Ainsi, à cette étape 821, le(s) numéro(s) des segment(s) TCP acquitté(s) sont transmis vers le module 4154. Ensuite, ce message d'acquittement ACK est transmis (étape 840) à la couche TCP 210 pour traitement selon le protocole TCP (tel que décrit dans la norme RFC-793). Si le message d'acquittement ACK contient des informations liées à une perte de paquet sur la porteuse UDP 100B, alors les étapes 830 à 833 sont effectuées.

A l'étape 830, les informations liées à une perte de paquet sur la porteuse UDP 100B (c'est-à-dire le(s) numéro(s) de paquet(s) UDP perdu(s)) sont extraites du message d'acquittement ACK reçu. Ensuite, à l'étape 831, les informations de perte (liste des paquets UDP manquants) sont envoyées vers le module générateur de messages 4152 dans le but de transmettre des données de réaction appropriées. Puis, à l'étape 832, les informations de perte sont supprimées pour rendre le paquet rcv pkt conforme au protocole TCP (tel que décrit dans la norme RFC-793). Afin d'éviter que la couche TCP 210 ne retransmette la partie du flux TCP relative au paquet 750 de donnée de parité, il est important de lui masquer ce besoin de retransmission, qui est pris en charge selon les étapes précédentes du protocole hybride ARQ en mode « hors-bande ». Cela signifie que les retransmissions des données de parité sont gérées par le protocole hybride ARQ 215, de manière transparente vis-à-vis de la couche TCP 210: la couche TCP 210 ne gère alors pas ces nouvelles transmissions de données de parité.

Ainsi, à l'étape 833, on détermine, via la table des index 419, la position exacte dans le flux TCP (en numéro de séquence du flux TCP) du début du paquet 750 considérée (notée « num_seq_750 »), renseignée au préalable lors de l'émission du segment de donnée 'tcp_seg' du flux TCP (étape 880). En fonction de la position du début de paquet 750 vis-à-vis des données utiles (353, 354) du segment TCP, il est procédé à la détermination d'une valeur d'acquittement cumulatif comme suit : - si la valeur d'acquittement cumulatif véhiculée dans rcv_pkt (champ « ACK NUMBER » selon le protocole TCP (tel que décrit dans la norme RFC-793), noté « num_seq_ack ») indique que le contenu du paquet 'tcp_seg' d'origine perdu débutait par un paquet 750, c'est-à-dire si num_seq_ack num_seq_750 (ceci peut correspondre au cas d'un début de paquet 750 transporté par le segment TCP précédent), alors la valeur d'acquittement cumulatif est égale à num_seq_750 + MSS ; - sinon, la valeur d'acquittement cumulatif est conservée, mais des nouvelles données Selective-ACK (données « SACK » tel que décrites dans la norme RFC-2018), pour la partie « TCP option » du segment TCP, sont considérées 30 afin de rajouter un bloc SACK avec comme limite inférieure la valeur num_seq_750 et comme limite supérieure la valeur num_seq_750 + MSS pour indiquer à l'émetteur que les données dans ces bornes ont bien été reçues. Suivant le cas, il peut être plus approprié de modifier les limites de blocs contigus déjà existants dans la structure TCP SACK du segment TCP reçu. Ensuite une mise à jour de l'en-tête TCP est effectuée, par les actions suivantes : - modification de la valeur du numéro d'acquittement, par remplacement avec la nouvelle valeur déterminée (mise à jour du champ « ACK NUMBER », selon le protocole TCP, tel que décrit dans la norme RFC-793) ; - modification ou ajout des blocs SACK déterminés ; - calcul de la somme de contrôle (ou « checksum » en anglais) de l'entête TCP (noté CRC), et mise à jour du champ « TCP CHECKSUM » correspondant. On note que selon le cas où le segment TCP perdu ne transporte qu'un paquet 750 de parité, alors le paquet rcv_pkt est considéré (grâce à l'incrément de sa valeur d'acquittement cumulatif) comme un acquittement positif pour la séquence TCP considérée (et non pas comme un message d'acquittement dupliqué DUP ACK). Ceci a pour effet de masquer totalement la perte survenue sur la porteuse TCP 100A, et donc d'éviter l'affaissement de la fenêtre de congestion de la porteuse TCP 100A, selon le mécanisme de gestion de congestion de TCP.

Le fait d'acquitter (en masquant la perte à la couche TCP 210) la partie du segment TCP correspondant au paquet de parité 750 perdu permet de libérer les ressources mémoires correspondantes dans la mémoire d'émission de la couche TCP 210 (appelé communément « TCP send buffer »), et ainsi de libérer cet espace pour de nouveaux transferts.

La figure 9 présente un mode de réalisation particulier des algorithmes, implémentés au sein du module de gestion de stockage 4154 (compris dans le bloc émetteur 410). Sur réception d'un signal de génération de H nouveaux paquets de parité (étape 900), provenant du module d'encodage 415, les K paquets du flux 401 ayant servi à la génération des H nouveaux paquets de parité sont stockés (étape 901) dans l'unité de stockage 417, avec le numéro SBN de fenêtre d'encodage courant. Sur réception d'un message (étape 910), provenant du module d'interception de messages 4153 (étape 880 décrite ci-dessus), et contenant le numéro de la séquence TCP associé au(x) paquet(s) de parité, il est procédé au stockage de ce numéro de séquence TCP (étape 911) dans la table d'indexation 419. Grâce aux champs ESI et SBN, il peut être procédé à l'identification du(des) paquet(s) de parité détecté(s). A chaque réception (étape 920) de numéro de séquence TCP acquitté, provenant du module d'interception de messages 4153 (étape 821), le module de gestion de stockage 4154 effectue un test (étape 921) pour vérifier si le numéro de séquence reçu (champ « ACK NUMBER » selon le protocole TCP, tel que décrit dans la norme RFC-793) permet d'identifier des éléments de la table d'indexation 419 vérifiant un numéro de séquence inférieur au numéro de séquence reçu. En cas de test 921 négatif, on retourne directement à l'étape 920, sinon on effectue les étapes 922 à 924, avant de retourner à l'étape 920. A l'étape 922, le module de gestion de stockage 4154 détermine, pour chaque élément identifié (de la table d'indexation 419), le(s) numéro(s) SBN de fenêtre d'encodage associé(s). A l'étape 923, le module de gestion de stockage 4154 détermine la ou les données source se référant au(x) numéro(s) SBN de fenêtre d'encodage déterminé(s) à l'étape 922, puis la(les) supprime de l'unité de stockage 417. La figure 10 représente un organigramme d'un algorithme de gestion de messages d'acquittement selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc émetteur 410 de la tête de tunnel 101.

A l'étape 1000, le bloc émetteur 410 reçoit une information liée à une perte de paquet(s) sur la porteuse UDP 100B, contenant par exemple une liste de paquets UDP manquants. A l'étape 1010, le bloc émetteur 410 détermine, à partir de la table d'indexation 419, le numéro SBN de fenêtre d'encodage associé aux paquets UDP manquants.

Ensuite l'étape 1035 est effectuée.

Du fait que la ou les pertes sur la porteuse UDP 100B sont connues, il est possible d'obtenir une estimation du taux de perte (rapport entre la ou les pertes de paquets UDP notifiées et le nombre de paquets UDP source émis). De plus, grâce à cette connaissance précise des paquets UDP perdus, le module d'encodage 415 est capable de mettre à jour la fenêtre d'encodage en fonction de ces pertes. Par exemple, pour la fenêtre d'encodage considérée à partir du message d'acquittement ACK reçu, les paquets UDP source présentés comme perdus sont tous obtenus depuis l'unité de stockage 417, afin de servir de base d'encodage. Un nombre total H de paquets de parité à générer est déterminé (étape 1035) par la formule suivante : H = (1 + T) * (L û M +1), où : - L est le nombre de paquets UDP perdus ; - M est le nombre de paquets de parité déjà transmis ; et - T est le taux de perte sur la porteuse UDP 100B. Connaissant ce nombre H de paquets de parité de réaction requis, la création de ces H paquets de parité à partir de la fenêtre d'encodage déterminée permet au dispositif récepteur 420 de pallier aux L pertes encourues sur la porteuse UDP 100B. Cependant, il est inutile de créé des codes de parité à partir de données source déjà reçues (aucune fiabilisation n'est nécessaire pour des données source déjà exploitées par le récepteur). Aussi, il sera procédé à un encodage sur une nouvelle fenêtre d'encodage de K paquets à partir du numéro de séquence SN du premier paquet UDP détecté comme perdu. Ceci a pour avantage de fiabiliser à la fois le reste de la fenêtre d'encodage de numéro SBN déterminé à l'étape 1010, et le début de la fenêtre d'encodage suivante. Du fait de la conservation du paramètre taille de ladite nouvelle fenêtre d'encodage, un même code correcteur d'erreur de type Reed-Solomon peut être utilisé ici et à l'étape 620. La robustesse de la transmission du flux 401 est alors accrue. Dans un mode de réalisation particulier, il peut être avantageux d'utiliser un code correcteur d'erreur basé sur une utilisation de OU-EXCLUSIFs (XORs) appliqué au niveau paquet (c'est-à-dire qu'une opération OU-EXCLUSIF (XOR) est appliquée entre les K paquets du flux 401) du fait que le champ ESI indique très clairement la portée de l'opération OU-EXCLUSIF (XOR). Ce mécanisme de code correcteur a l'avantage d'être rapide à mettre en place et a exécuté, vis-à-vis d'une portée (nombre de paquets L) fluctuante.

Dans un autre mode de réalisation, en relation avec l'étape 1240, des numéros de paquets UDP notifiés dans le message ACK intercepté correspondent à des numéros SBN de fenêtre d'encodage suivants de celui déterminé en 1010 (ce dernier correspondant au transport de la donnée de parité sur la porteuse TCP 100A indiquée comme perdue). Ainsi, pour les fenêtres d'encodage SBN suivantes, l'émetteur 410 a connaissance d'une perte de donnée réelle sur la porteuse UDP 100B (mais pas encore de la perte ou non des données de parité associées véhiculées sur la porteuse TCP 100A). L'émetteur peut alors savoir si le nombre de paquets de parité préalablement transmis est suffisant (en considérant qu'ils sont tous reçus) vis-à-vis du taux de perte sur la porteuse UDP 100B. Le nombre H de paquets de parité à générer est déterminé comme précité en 1035, et la génération de ces paquets est effectuée à l'étape 1040. Dans ce cas, il est préférable d'utiliser le même procédé d'encodage de paquets de parité dits « proactifs » que celui utilisé à l'étape 620. Chacun des paquets de parité ainsi générés est transmis dans un segment TCP embarquant un paquet 750. Comme ces paquets de parité ne passent pas par la couche TCP 210, ceux-ci n'influencent pas le contrôle de flux du protocole TCP et ainsi il n'y a pas de limitation quant à leur nombre. Le fait de conserver un entête de type TCP présente l'avantage d'éviter que les paquets de parité soient supprimés par les routeurs qu'ils rencontrent sur leur chemin, comme cela est souvent le cas pour des données UDP lors de congestion réseau.

A l'étape 1045, le(s) paquet(s) de parité destiné(s) à transporter les H paquets de parité sont créés. Le formatage de ce(s) paquet(s) se fait comme suit : - dans le paquet 750, les champs ESI et SBN sont remplis selon le mode d'encodage utilisé pour la donnée de parité de la zone utile 753. Le champ PCL est mis à zéro car le paquet généré ne fait pas partie du flux continu TCP (il 5 10 15 20 reprend seulement le formatage de paquet selon le protocole TCP). Le bit R est mis à 1 pour indiquer qu'il s'agit d'une retransmission de paquet 750 de parité ; - l'entête TCP contient les paramètres suivants : • un numéro de séquence « SEQUENCE NUMBER » prenant pour valeur le numéro du premier octet de données TCP utilisé pour le transfert du paquet 750 initial (dont la retransmission a été demandée). Il est rappelé que la table des index 419 contient la position exact (notée « num_seq_750 ») du début du paquet 750 considéré dans le flux TCP ; • un numéro d'acquittement « ACK NUMBER » dont la valeur n'a pas d'importance, car le bit de contrôle ACK de l'entête ne doit pas être mis à 1; • une valeur de résultat de calcul du checksum de l'entête TCP (CRC), pour mise à jour du champ « TCP CHECKSUM ». • une option TCP précisant la zone dans le flux TCP qui est couverte par les données de parité (paquet 750) et qui est concernée par la perte sur la porteuse TCP 100A. Cette information sera utilisée par le récepteur pour envoyer la partie de données réellement nécessaires à la couche TCP 210 de destination, afin de combler le manque de données reçues. On rappelle que la couche TCP 210 d'émission est en charge de retransmettre les données perdues (hors paquet 750 de parité) sur la porteuse TCP 100A, alors que le protocole hybride-ARQ 215 se charge de transmettre de nouveaux paquets 750 de parité entiers. Par exemple, cette option TCP peut être de la forme suivante : Option « Hybride ARQ coverage »: Code 00001111 Longueur 00000100 attribut Max ack seg size 25 où ^ le champ « code » permet l'identification de cette option TCP, connue de du bloc émetteur 410 et du bloc récepteur 420 ; ^ le champ « longueur » prend la valeur 4 (en effet, dans cet exemple, 4 octets sont utilisés pour cette option TCP) ; ^ le champ « attribut» contient la longueur de la partie de segment TCP qui doit être transmise à la couche TCP 210 du dispositif récepteur, afin de combler le manque de données reçues (par exemple max_ack_seg_size = num_seq_ack + MSS - num_seq_750). A l'étape 1050, le(s) paquet(s) de parité crée(s) à l'étape 1045 est(sont) transmis à la couche IP 225. Après l'étape 1050, l'algorithme est terminé. La figure 11 présente un mode de réalisation particulier d'un algorithme, implémenté au sein du module d'interception de messages 4252 (compris dans le bloc récepteur 420 de la tête de tunnel 102). Sur réception (étape 1100) d'un paquet de données provenant de la couche IP 225 et à destination des couches TCP 210 ou UDP 220, un test est effectué (étape 1101) pour déterminer le type de protocole du paquet reçu. Si le paquet reçu est de type UDP, alors le paquet est transmis directement (étape 1130) à la couche UDP 220. Après l'étape 1130, l'algorithme est terminé. Si le paquet reçu est de type TCP, alors un test est effectué (étape 1102) pour déterminer si le paquet reçu contient des données utiles liées à d'autres applications que celle liée au transport du (ou des) flux 401 (c'est-à-dire des données qui ne sont pas des données de parité générées par le protocole hybride ARQ 215). Si le paquet reçu contient de telles données (test 1102 positif), alors l'étape 1103 est effectuée, sinon (test 1102 négatif) l'étape 1130 (décrite ci-dessus) est effectuée.

A l'étape 1103, on détermine la nature des données. Cette détermination dépend du mode de transfert utilisé (étape 1045). Par exemple, l'identification de données de parité en retransmission peut se faire par analyse, dans le segment TCP reçu, de la valeur du champ R (positionné à 1), et par la détection de la présence d'une option TCP telle que précisée en regard de l'étape 1045. Ainsi, à l'étape 1103, un test est effectué pour déterminer si les données du paquet TCP reçu sont des données de retransmission selon le protocole hybride ARQ, telles que celles transmises à l'issue de l'algorithme décrit en référence à la figure 10. Si les données du paquet TCP reçu sont des données de retransmission selon le protocole hybride ARQ, c'est-à-dire si la donnée utile véhiculée dans le paquet TCP reçu est de type paquet 750 de parité, alors l'étape 1110 est effectuée. Sinon, l'étape 1120 est effectuée. A l'étape 1110, il est procédé à l'extraction de la ou des donnée(s) de parité 753, ainsi que des informations ESI et SBN (champ 752), puis au stockage de ces donnée(s) et informations dans l'unité de stockage temporaire 423.

Le paquet TCP reçu n'a pas lieu d'être envoyé à la couche protocolaire TCP. Celui-ci est donc détruit (étape 1111). Il est à noter que lors de la première réception d'un paquet 750 de retransmission de données de parité, pour un numéro SBN de fenêtre d'encodage donné, il est nécessaire d'envoyer une partie des données reçues pour remplir la zone manquante dans la mémoire de réception de la couche TCP 210. En effet, en envoyant à la couche TCP 210 un paquet fictif à la place du paquet qui avait été identifié comme étant à retransmettre, la couche TCP 210 va générer en réponse un acquittement, ce qui permet le maintien des performances de communication. On entend par paquet fictif un paquet dont le numéro de séquence et la taille correspondent au paquet TCP de parité perdu, et contenant des données de bourrage. Le champ correspondant aux données utiles dans ce paquet ne sera alors pas utilisé par l'unité de stockage temporaire 423. Dans un mode de réalisation particulier, un paquet fictif est obtenu par la création d'un segment TCP ayant pour séquence de démarrage la valeur « num_seq_750 » (issue du champ numéro de séquence « SEQUENCE NUMBER » du paquet reçu), et ayant pour longueur la taille « max_ack_seg_size » indiquée dans l'option TCP de ce même paquet reçu (rcv_pkt). Dans un mode de réalisation, il peut être avantageux de réutiliser le paquet reçu (rcv_pkt), en diminuant sa taille et en supprimant l'option TCP. L'émission du paquet fictif est notifiée à l'unité de stockage temporaire 423, afin de ne pas tenir compte du contenu du paquet 750 reconstitué par la couche TCP 210 (les trames réellement exploitables étant incorporées directement dans l'unité de stockage temporaire 423 par le module de gestion de protocole hybride ARQ 431 à l'étape 1110). Lors de la réception sur la porteuse TCP 100A de données ne comportant pas de retransmission de paquets 750 selon le protocole hybride-ARQ 215, les étapes 1120 et 1122 sont effectuées. L'étape 1120 consiste à déterminer au cours du flux TCP le début de paquet 750. Pour ce faire, un compteur de numéro de séquence TCP (avec comme valeur d'initialisation la valeur de démarrage de la connexion TCP) peut être utilisé car la taille des paquets 750 est connue (par exemple, l'entête du protocole embarqué 353 indique la taille de chaque paquet). Dans le cas où le champ PCL n'est pas présent dans la zone d'encapsulation 752 mais est incorporé dans l'entête TCP via une option TCP, alors la recherche de la zone de démarrage des paquets véhiculés dans le flux TCP est grandement simplifiée. Ensuite, la récupération du champ PCL est effectuée (étape 1121). Par analyse de ce champ PCL, l'étape 1122 permet de connaître la localisation des paquets de parité 750 et surtout des changements de fenêtre d'encodage (telle qu'identifiée par leur numéro SBN) au cours du flux TCP. Ces informations de numéro de séquence TCP supportant une donnée de parité et de changement de numéro SBN de fenêtre d'encodage sont répertoriées dans la table d'index 4253. Ceci sera utile ultérieurement pour les étapes 1230 et 1240 de génération des rapports d'erreur selon le protocole hybride ARQ 215. L'extraction de ces données est particulièrement importante en cas de perte de paquet TCP sur le tunnel, car les paquets TCP suivants un paquet manquant permettent de déterminer la nature de ce qui n'a pas été reçu. La figure 12 représente un organigramme d'un algorithme de gestion de segment(s) TCP selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le module d'interception de messages 4252 (compris dans le bloc récepteur 420 de la tête de tunnel 102). Suite à l'interception (étape 1200) d'un segment TCP (noté « tcp_seg »), provenant de la couche TCP 210, en direction de la couche IP 225, le segment TCP est analysé (étape 1210) pour détecter une perte sur la porteuse TCP 100A.

On rappelle que le protocole TCP intègre un processus consistant à envoyer un message d'acquittement ACK dupliqué (même séquence d'acquittement que le message d'acquittement ACK précédent), afin de prévenir et d'informer l'autre extrémité, de la référence d'un paquet corrompu ou perdu. L'algorithme de congestion TCP pose le principe que si seulement 1 ou 2 acquittements ACK sont dupliqués, alors il s'agit d'un paquet à réordonner, en revanche si 3 acquittements ACK dupliqués ou plus sont envoyés, alors il s'agit d'un paquet corrompu ou perdu. Dans le cas où un message d'acquittement ACK positif, n'indiquant pas de perte de données, est reçu, les enregistrements trop anciens de la table des index 4253 sont supprimés (étape 1260), c'est-à-dire qu'on supprime les séquences enregistrées dont le numéro est inférieur au numéro acquitté dans le message intercepté. La taille mémoire utilisée pour cette table est alors réduite, car n'est stocké que l'encours des transmissions de données sur la porteuse TCP 100A. Puis, on passe à l'étape 1270. Dans le cas où un troisième message d'acquittement ACK dupliqué (noté DUP ACK) est reçu, un test est effectué (étape 1220) pour déterminer si le segment TCP concerné contient potentiellement des données de parité (paquet 750). Pour ce faire, la table des index 4253 est interrogée avec comme paramètre le numéro de séquence acquitté « ACK NUMBER » du segment reçu. S'il est obtenu une entrée de la table des index 4253 qui référence la présence de données de parité (paquet 750), alors l'étape 1230 est exécutée, sinon l'étape 1270 est exécutée. A l'étape 1230, la table des index 4253 est interrogée une nouvelle fois pour obtenir le numéro SBN de fenêtre d'encodage correspondant au numéro de séquence acquitté « ACK NUMBER » du segment reçu. Ensuite, à l'étape 1240, le numéro SBN obtenu est utilisé pour obtenir une indication des paquets UDP manquants parmi ceux stockés dans l'unité de stockage 423 pour la fenêtre d'encodage considérée. Puis, à l'étape 1250, la liste des paquets UDP manquants est insérée dans le segment ACK intercepté, afin de guider le dispositif émetteur 101 dans sa politique de retransmission. On rappelle que ce segment ACK modifié est intercepté au niveau du dispositif émetteur 101 à l'étape 820 de la figure 8.

Dans un mode de réalisation particulier, l'insertion de la liste des paquets UDP manquants se fait dans le champ « TCP option » de l'entête TCP. Une telle option TCP précisant la liste des pertes de paquets UDP peut être de la forme suivante : Code : Longueur : 00002222 00001010 Attribut : SN du paquet 1 SN du paquet 2 SN du paquet 3 SN du paquet 4 Plus précisément, cette option TCP contient : - un champ « code » permettant l'identification de cette option qui est connue du dispositif émetteur et du dispositif récepteur ; - un champ « longueur » de valeur variable en fonction de la taille d'un champ « attribut » (2 octets pour les champs « code » et « longueur » plus la taille d'un champ « attribut ») ; - le champ « attribut » contenant la liste des paquets UDP manquants, qui doit être transmise au dispositif émetteur 101. Dans l'exemple donné ci-dessus, 4 paquets UDP sont signifiés comme perdus, et les valeurs SN sont extrapolées à partir des numéros de séquence SN (722) des paquets UDP reçus et stockés dans l'unité de stockage 423.

Dans un autre mode de réalisation, il est possible que l'interrogation de l'unité de stockage 423 (étape 1240) concerne également les numéros SBN de fenêtre d'encodage suivants. Ceci a pour avantage d'envoyer par avance la(les) liste(s) suivante(s) de paquets UDP manquants vers le dispositif émetteur, afin de proposer une réponse encore plus rapide. En effet, du fait de l'absence de contrôle de congestion sur la porteuse UDP 100B, celle-ci achemine plus rapidement les données que ne le fait un protocole de transmission avec acquittement tel que, par exemple, TCP. Par exemple, ceci est particulièrement avantageux s'il n'y a pas de perte de paquets UDP pour le numéro SBN de fenêtre d'encodage déterminé (étape 1230), et alors une liste non vide Option « Hybride ARQ list » 5 de numéros de paquets UDP (manquants à suivre) est insérée dans le segment ACK intercepté, Ensuite, une mise à jour de l'entête IP est effectuée, par les actions suivantes : - calcul de la longueur totale du paquet au niveau IP, et mise à jour du champ « total length » correspondant ; - calcul de la somme de contrôle (« checksum » en anglais) de l'entête IP, et mise à jour du champ « HEADER CHECKSUM ». Enfin, à l'étape 1270, le segment TCP (éventuellement modifié à l'étape 1250) est transmis vers la couche IP 225 pour transmission vers le dispositif émetteur 101. 10

Claims (5)

1. REVENDICATIONS1. Procédé de transmission d'un flux de données par un dispositif émetteur (101) vers un dispositif récepteur (102) via un lien de communication (100), les données du flux de données étant transmises (622) au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données, caractérisé en ce que le dispositif émetteur effectue des étapes consistant à : - transmettre (621) au dispositif récepteur des premières données de parité générées à partir de données sources dudit flux, par utilisation d'un protocole de transport avec acquittement et retransmission de données ; - recevoir (600) selon le protocole de transport avec acquittement et retransmission de données, en provenance du dispositif récepteur, un message d'indication de non-réception par le dispositif récepteur d'au moins une parmi les premières données transmises, le message comprenant une information de non-réception d'au moins une donnée source ; - générer (601) des secondes données de parité à partir de ladite information de non-réception d'au moins une donnée source ; - transmettre (602) les secondes données de parité générées au dispositif récepteur, par utilisation dudit protocole de transport avec acquittement et retransmission de données, en réponse audit message reçu.
2. 2. Procédé selon la revendication 1, caractérisé en ce que ladite étape consistant à générer (601) des secondes données de parité comprend des étapes consistant à : - déterminer (1010) une première fenêtre d'encodage appliquée auxdites données source utilisée pour générer ladite au moins une première donnée de parité non reçue ; déterminer une seconde fenêtre d'encodage, à partir de ladite au moins une donnée source indiquée dans ledit message comme non-reçue ; - générer (1040) les secondes données de parité à partir de ladite seconde fenêtre d'encodage déterminée.
3. 3. Procédé selon la revendication 2, caractérisé en ce que ladite au moins une donnée source indiquée dans ledit message comme non-reçue est comprise dans ladite première fenêtre d'encodage.
4. 4. Procédé selon la revendication 2, caractérisé en ce que ladite au moins une donnée source indiquée dans ledit message comme non-reçue est associée à une fenêtre d'encodage ultérieure à ladite première fenêtre d'encodage.
5. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le dispositif émetteur effectue des étapes consistant à : - modifier (603) ledit message reçu en modifiant ladite indication de non réception de ladite au moins une des premières données de parité, en une indication de réception de ladite au moins une des premières données de parité ; - transmettre (604) le message modifié à un module de traitement d'acquittement selon le protocole de transport avec acquittement et retransmission de données. 8. Procédé selon la revendication 5, caractérisé en ce que ladite étape consistant à modifier (603) ledit message reçu comprend en outre une étape consistant à supprimer ladite information de non-réception d'au moins une donnée source. 9. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que le lien de communication est un tunnel de communication interconnectant des réseaux locaux, et chacun des dispositifs émetteur et récepteur est une tête de tunnel appartenant à un réseau local respectif, et en ce que les données sources sont générées par un dispositif terminal source d'un dit réseau local et sont destinées à un dispositif terminal destination d'un dit réseau local distinct. 10. Procédé de réception par un dispositif récepteur (102) d'un flux de données transmis par un dispositif émetteur (101) via un lien de communication (100), 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, caractérisé en ce que le dispositif récepteur effectue des étapes consistant à : - recevoir des données de parité, parmi des premières données de parité générées à partir de données sources dudit flux et transmises par le dispositif émetteur par utilisation d'un protocole de transport avec acquittement et retransmission de données ; - détecter (630) au moins une première donnée de parité non reçue parmi lesdites premières données de parité ;- déterminer (631) une information de non-réception d'au moins une donnée source ; transmettre (633), selon le protocole de transport avec acquittement et retransmission de données, vers ledit dispositif émetteur un message d'indication de non-réception de première(s) donnée(s) de parité, contenant ladite information de non-réception d'au moins une donnée source déterminée. 9. Procédé selon la revendication 8, caractérisé en ce que ladite au moins une donnée source indiquée dans ledit message comme non-reçue est comprise dans une fenêtre d'encodage utilisée pour générer ladite au moins une première donnée de parité non reçue. 10. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de transmission selon au moins une des revendications 1 à 7 et/ou du procédé de réception selon au moins une des revendications 8 et 9, lorsque ledit programme est exécuté sur un ordinateur. 11. 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 à 7 et/ou le procédé de réception selon au moins une des revendications 8 et 9. 12. Dispositif émetteur (101) comprenant des moyens pour transmettre un flux de données vers un dispositif récepteur (102) via un lien de communication (100), 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, caractérisé en ce que le dispositif émetteur comprend : - des moyens pour transmettre au dispositif récepteur des premières données de parité générées à partir de données sources dudit flux, par utilisation d'un protocole de transport avec acquittement et retransmission de données ; - des moyens pour recevoir selon le protocole de transport avec acquittement et retransmission de données, en provenance du dispositif récepteur, un message d'indication de non-réception par le dispositif récepteur d'au moins une parmiles premières données transmises, le message comprenant une information de non-réception d'au moins une donnée source ; - des moyens pour générer des secondes données de parité à partir de ladite information de non-réception d'au moins une donnée source ; - des moyens pour transmettre les secondes données de parité générées au dispositif récepteur, par utilisation dudit protocole de transport avec acquittement et retransmission de données, en réponse audit message reçu par lesdits moyens pour recevoir. 13. Dispositif récepteur (102) comprenant des moyens pour recevoir un flux de données transmis par un dispositif émetteur (101) via un lien de communication (100), 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, caractérisé en ce que le dispositif récepteur comprend : des moyens pour recevoir des données de parité, parmi des premières données de parité générées à partir de données sources dudit flux et transmises par le dispositif émetteur par utilisation d'un protocole de transport avec acquittement et retransmission de données ; des moyens pour détecter au moins une première donnée de parité non reçue parmi lesdites premières données de parité ; - des moyens pour déterminer une information de non-réception d'au moins une donnée source ; - des moyens pour transmettre, selon le protocole de transport avec acquittement et retransmission de données, vers ledit dispositif émetteur un message d'indication de non-réception de première(s) donnée(s) de parité, contenant ladite information de non-réception d'au moins une donnée source déterminée.