FR2939994A1 - Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes - Google Patents

Abstract

Il est proposé un procédé de transmission d'un flux de données multi-canal (401) comprenant des trames comprenant une pluralité de canaux, la transmission étant effectuée via un tunnel multi-transport (100) depuis une première tête de tunnel (101) vers une seconde tête de tunnel (102), ledit tunnel mettant en oeuvre une première porteuse (100A) supportant un protocole de transport avec acquittement et une seconde porteuse (100B) supportant un protocole de transport sans acquittement. Plus précisément, l'invention a pour objectif d'éviter ou de limiter les phénomènes de coupure du rendu d'un flux multi-canal en transit sur un tunnel, et plus particulièrement de fournir une technique de transport permettant une délivrance régulière du flux multi-canal sans coupure, tout en réduisant les ressources mémoire nécessaires en réception.

Description

Procédé de transmission d'un flux de données multi-canal sur un tunnel multitransport, produit programme d'ordinateur, moyen de stockage et têtes de tunnel correspondantes. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. Plus précisément, l'invention concerne une technique de transmission de paquets de données (aussi appelés datagrammes) sur un tunnel traversant un réseau de communication. La démocratisation d'Internet haut débit d'une part et l'apparition d'équipements audiovisuels grand public ayant une connectivité réseau d'autre part vont créer de nouveaux comportements des utilisateurs. Parmi ces nouveaux comportements, il fait peu de doute que nous verrons apparaître des individus appartenant à des groupes de personnes ayants des domaines d'intérêts communs (loisirs, famille...) que nous pourrions appeler en liaison permanente . Ceux-ci établiront des connections quasi permanentes avec les autres individus d'un même domaine d'intérêt en établissement des communications audio et/ou vidéo et partageant des informations de tout type (audio, vidéo, photo, texte ...). La technologie des RPV (pour Réseaux Privés Virtuels en français ou VPN pour Virtual Private Network en anglais) offre une solution intéressante pour répondre à cette attente. En effet, elle permet de communiquer de manière transparente en temps réel, 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ûr 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 en français, ou tunneling en anglais) qui crée ce que l'on appelle un tunnel. 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). La tunnellisation peut être utilisée pour transporter un protocole réseau sur un réseau qui ne le supporte pas. Elle peut aussi être utilisée pour fournir différents types de fonctionnalités RPV, comme par exemple l'adressage privé. Les techniques de tunnel sont aujourd'hui de plus en plus utilisées par des fonctionnalités client d'accès à distance, et des interconnexions de réseaux locaux domestiques (appelés ci-après réseaux LAN pour Local Area Network en anglais). Dans la suite de la description, on considère, à titre d'exemple uniquement, les tunnels de niveau 2 ou 3, pour lesquels le niveau du protocole de transport B dans le modèle OSI est égal à celui de la couche de transport (couche de niveau 4 dans le modèle OSI). Les RPVs (ou VPN) sont fréquemment utilisés pour interconnecter deux réseaux LAN afin de créer un réseau local virtuel composé de l'union des deux réseaux LAN originaux. Les RPVs sécurisés incluent un algorithme de cryptographie et d'authentification pour garantir le secret des données transportées. 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). Dans cet exemple, les têtes de tunnel (ou TEP pour Tunnel End Point en anglais) ne sont pas intégrées aux passerelles. Le tunnel est établi entre deux têtes de tunnel, et chaque paquet (aussi appelé trame) envoyé à un équipement connecté au réseau LAN distant est encapsulé par la tête de tunnel locale, puis envoyé à la tête de tunnel distante qui va la dés-encapsuler et l'envoyer sur le réseau LAN distant. Pour les équipements, 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 (ou end-to-end communication en anglais). De nos jours, on voit émerger des RPVs disposant de techniques de connexions multiples, c'est-à-dire un tunnel formé de plusieurs porteuses ou canaux. Cette technique permet de choisir un premier protocole de transport, par exemple pour les données de contrôle, et un second protocole de transport, par exemple pour les données utiles, les deux types de données passant dans la même tête de tunnel. Il existe de multiples autres possibilités quant au choix du protocole de transport pour les flux applicatifs passagers (par exemple en fonction des priorités des flux passagers). On parle alors de canal virtuel d'un tunnel qui est formé de multiples canaux ayant chacun un protocole de transport propre, sachant que seule la tête de tunnel a connaissance de ces canaux. Le choix du protocole de transport peut donc être optimisé sur chacun des canaux.

Dans la suite de la description, on désigne ce type de tunnel sous le terme de tunnel multi-transport. Dans l'état de la technique, le protocole internet IP (pour Internet Protocol en anglais) de la couche 3 du modèle OSI ou les protocoles TCP/UDP (pour Transmission Control Protocol / User Datagram Protocol en anglais) de la couche 4 du modèle OSI sont principalement utilisés. Les technologies de tunnellisation basées sur IP ne pouvant pas prendre en compte de mécanisme de traduction d'adresse réseau (ou NAT pour Network Address Translation en anglais), et n'étant pas entièrement compatibles avec la configuration de tunnellisation typique de la figure 1, on considère (à titre d'exemple uniquement) dans la suite de la description des solutions basées sur la couche 4 (couche de transport), c'est-à-dire sur le protocole TCP ou UDP. Le protocole TCP qui est défini par la norme RFC-793 (RFC pour request for comment en anglais ou demande de commentaires en français) de l'IETF (pour le groupe international Internet Engineering Task Force produisant la plupart des nouveaux standards d'Internet) est un protocole de transmission avec demande de répétition automatique (ou ARQ pour Automatic repeat request en anglais) qui est basé sur des mécanismes de contrôle de congestion et de retransmission, et assure ainsi la délivrance de chaque paquet vers la destination. Le protocole UDP est un protocole beaucoup plus simple et rapide, qui ne tient pas compte de l'ordre des trames, et ne gère pas d'acquittement.

Comme précisé précédemment, le protocole TCP a été conçu pour être flexible et fonctionner dans une large variété d'environnement de communication réseau, incluant des liens lents et rapides, avec une latence élevée ou des liens avec des taux d'erreurs variables. Bien que le protocole TCP fonctionne pour différents environnements, ces performances (en particulier la bande passante) sont affectées par les caractéristiques de chaque lien de communication utilisé. Les performances du protocole TCP en termes de bande passante souffrent dans des environnements avec des délais d'acheminement longs et/ou possédant un taux d'erreur élevé.

Dans le cas de l'Internet, les connexions normalement sont de type best effort , c'est à dire que ces connexions font tout ce qui est possible pour acheminer les informations jusqu'à leur destination, mais sans garantir un certain niveau de qualité de service (ou QoS pour Quality of Service en anglais). Ainsi, dans le cadre de communication RPV, la couche de transport du tunnel est soumise à de fortes fluctuations de ses capacités de transmission. Le son multi-canal est un format audio qui vise à s'approcher de l'écoute naturelle. Il apporte au son une notion d'espace et permet ainsi l'enveloppement ainsi que l'immersion de l'auditeur. Il permet tout simplement de reproduire l'évènement, en salle de cinéma et chez soi, avec toutes les émotions fortes de la salle de concert, du stade, d'un extérieur ou du théâtre. Des formats audio multi-canal, tels que Dolby Digital et DTS (pour Digital Theater System en anglais) sont devenus prédominants pour les systèmes de cinéma chez soi (ou home cinéma en anglais). Des formats typiquement reconnus sont les formats 4.0, 5.1 et plus récemment 7.1. Par exemple, le format Dolby Digital 5.1 supporte deux haut-parleurs avant (ou front speakers en anglais), deux haut-parleurs arrière (ou rear speakers en anglais), un haut-parleur central (ou center speaker en anglais) et un haut-parleur à basse fréquence (ou LFE pour low frequency effects en anglais). Le format 7.1 ajoute encore deux canaux supplémentaires permettant de supporter deux haut-parleurs latéraux ( side speakers en anglais). Comme un flux multi-canal (tel que l'audio) doit être transmis et rendu en temps réel, le protocole de transport de ce flux doit assurer une délivrance avec un minimum d'erreur ou de perte, sans discontinuité et de manière préférentielle avec une latence faible. L'absence de discontinuité est un critère prédominant de qualité perçue (ou QoE pour Quality of Experience en anglais) par l'utilisateur, car la moindre interruption dans la transmission du flux (perte ou retard) se traduit par une coupure perceptible (par exemple une coupure du morceau musical écouté). En effet, tel que décrit précédemment, le protocole TCP n'étant pas conçu pour le transport de données en temps réel, le protocole UDP serait plus à même de répondre à ce besoin si ce n'est qu'il n'apporte pas de mécanisme de contrôle de flux. Aussi, le protocole RTP (pour Real-Time Transport Protocol , norme RFC-3550), se situant au niveau de l'application selon la couche OSI, utilise le protocole sous-jacent de transport UDP afin de fournir une fonction de transport de bout en bout pour les applications temps réel sur des services réseaux de type multicast (c'est-à-dire le fait d'émettre un message vers plusieurs destinataires simultanément) ou unicast (c'est-à-dire le fait d'émettre un message vers un destinataire unique).

Classiquement, le protocole RTP est particularisé selon les applications visées et divers formats existent. Par exemple, pour des conférences audio et vidéo, le format est défini par la norme RFC-3551, pour le transport de flux vidéo MPEG1/2, il s'agit de la norme RFC-2250 et pour transport de flux audio AC-3, il s'agit de la norme RFC-4184. Cependant, il est prévu que pour des sessions multi-canal, les échantillons d'un même instant doivent être dans le même paquet RTP. Ainsi, la perte d'un paquet RTP se traduit en la perte d'un échantillon de temps pour tous les canaux du flux multi-canal transporté. Afin d'optimiser la bande passante pour les applications temps réel à transmettre sur l'Internet, le protocole TCRTP (pour Tunneling Multiplexed Compressed Real- Time Transport Protocol défini par la norme RFC-4170 est utilisé pour la compression et le multiplexage de flux multimédia RTP. C'est un protocole qui ne nécessite aucune modification des applications RTP existantes, car les mécanismes de tunnelisation sont incorporés sur les dispositifs externes de concentration tels que des passerelles Internet. Ce protocole TCRTP n'exige aucun traitement additionnel des routeurs du réseau global traversé et s'appuie sur différents protocoles standardisés comme : - le protocole de compression d'en-tête ECRTP ((pour Enhanced Compressed Real Time Protocol , norme RFC-3545), pour la compression d'en-têtes IP/UDP/RTP ; - le protocole de Multiplexage de la couche PPP (pour Point-to-Point Protocol ), c'est-à-dire (PPP-MUX, norme RFC-3153), permettant l'agrégation de multiples flux RTP ; - le protocole de Tunneling L2TP (pour Layer Two Tunneling Protocol en anglais, RFC-2661) permettant la création de tunnel de "niveau 2", et supportant des sessions PPP. Le tunneling L2TP sur les réseaux IP emploie le protocole UDP et une série de messages L2TP pour la gestion du tunnel.

Ainsi, lors d'une congestion temporaire sur l'Internet du tunnel RPV selon le protocole TCRTP, la perte d'un paquet du tunnel se traduit en la perte d'un échantillon de temps de tous les flux RTP multiplexés, et ceci pour tous les canaux de chacun des flux. En conclusion, la moindre perte sur un tunnel TCRTP a une incidence encore plus grande que si chaque flux RTP avait été transmis isolement (hors tunnel RPV).

A ce jour, il n'existe pas de méthode de transport à travers un réseau global (Internet) pour des applications multi-canal véhiculées selon le protocole RTP sur un réseau local (de type LAN), garantissant la délivrance sans interruption perceptible à l'équipement multimédia destinataire. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Il existe deux catégories de principes connus pour l'amélioration de l'acheminement de flux dits temps réels (ou streaming en anglais) dans un environnement instable (tels que l'Internet ou des liens sans-fil). Un premier principe consiste à agir sur le protocole de transport lui-même tel que décrit dans le document de brevet US2006/0198300A1 (EPSON Research & Development Inc, Multi-channel TCP connections ) Ce document de brevet décrit un exemple de fonctionnement du principe où de multiples connexions TCP (ou Multi-TCP ) sont établies entre deux équipements distants (tels que des têtes de tunnel ou des passerelles Internet), et sur lesquelles seront transmis les flux applicatifs.

En partant du constat que le protocole TCP est fiable mais ne garantit pas un débit constant et temps réel lors de pertes, l'idée consiste à utiliser une agrégation de connexions TCP afin d'obtenir un débit global plus régulier. Le présent document de brevet divulgue une technique de sélection d'une des porteuses TCP pour transmettre chaque paquet passager en fonction de l'état de congestion des connexions TCP.

Lorsqu'une connexion TCP voit sa fenêtre de congestion (nommée cwnd selon le protocole TCP) diminuer fortement, c'est qu'il s'agit d'une congestion momentanée. Alors, une autre congestion TCP avec la plus grande fenêtre de congestion disponible est choisie. Ainsi, si un paquet est perdu et en retransmission sur la première connexion, les paquets suivants ne seront pas sujets à cette congestion sur l'autre porteuse TCP. L'avantage de cette solution concerne la fiabilité du transport. Mais le flux passager véhiculé à travers les multiples connexions TCP est tout de même perturbé. Il n'existe plus de pertes mais des retards de délivrance sur les paquets en retransmission sur chacune des connexions TCP.

Selon le principe Multi-TCP , la multiplicité des connexions TCP augmente d'autant la probabilité de perte ou retransmission. Ainsi, le dé-séquencement à l'arrivée des données (non décrit dans le document de brevet cité) demande alors une latence d'autant plus longue pour être corrigée.

Ainsi, la solution de ce document de brevet répond partiellement au problème de la perte de données mais ne permet pas une délivrance régulière du flux RTP sans coupure. Un second principe consiste à agir sur le contenu transporté tel que décrit dans la norme RFC-2198 RTP Payload for Redundant Audio Data .

Un mécanisme de type FEC (pour Forward Error Correction en anglais) est un mécanisme de protection contre les erreurs, qui est utilisé lors de la transmission de données. L'émetteur ajoute de la redondance afin de permettre au destinataire de détecter et de corriger au moins une partie des erreurs. Cela permet d'éviter la retransmission, et donc de faire des économies de bande passante, voire d'assurer la transmission dans certaines situations où il n'y a pas de voie de retour. La RFC-2198 pose le principe par lequel des copies redondantes de données audio sont transmises dans un flux RTP unique, afin de corriger les perturbations liées à des pertes dans le transport du flux RTP. Ainsi, chaque paquet RTP contient une donnée audio pour un même intervalle de temps, et une copie (plus compressée) de la donnée audio d'un intervalle de temps précédent. Ceci permet la recomposition approximative des échantillons perdus à partir du décodage du paquet suivant. Cette solution nécessite une large sur-occupation de la bande passante disponible afin de transporter les données en doublon, et est donc plus adaptée aux environnements sans-fil WLAN (pour Wireless Local Area Network en anglais) sujets à des pertes de données qu'aux environnements WAN où la non-délivrance d'un paquet résulte d'un phénomène de congestion sur le chemin. Ainsi, dans cette seconde solution, la redondance des informations ne fait qu'aggraver le phénomène de congestion sur le réseau global WAN où la bande passante est limitée. 3. OBJECTIFS DE L'INVENTION Dans au moins un mode de réalisation de l'invention, un objectif est d'éviter ou de limiter les phénomènes de coupure du rendu d'un flux multi-canal en transit sur un tunnel, et plus particulièrement de fournir une technique de transport permettant une délivrance régulière du flux multi-canal sans coupure. Cette méthode sera plus précisément décrite dans le cadre d'une application multi-canal audio, mais est applicable à tout flux multi-canal en général. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant de réduire les ressources mémoire en réception. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant d'améliorer la bande passante du tunnel pour les données utiles. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique 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 multi-canal comprenant des trames comprenant une pluralité de canaux, la transmission étant effectuée via un tunnel multi-transport depuis une première tête de tunnel vers une seconde tête de tunnel, ledit tunnel mettant en oeuvre une première porteuse supportant un protocole de transport avec acquittement et une seconde porteuse supportant un protocole de transport sans acquittement, Ce procédé est remarquable en ce que la première tête de tunnel effectue des étapes consistant à, pour une trame donnée dudit flux : - obtenir au moins une information relative à des quantités de données dudit flux de données multi-canal reçues par la seconde tête de tunnel ; - aiguiller les canaux d'une trame dudit flux de données multi-canal reçue par la première tête de tunnel vers l'une desdites porteuses du tunnel, en fonction de ladite au moins une information obtenue ; - associer une même information de synchronisation auxdits canaux ; - transmettre vers la seconde tête de tunnel chacun des canaux de ladite trame donnée via la porteuse vers laquelle ledit canal a été aiguillé, ainsi que leur information de synchronisation associée. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive consistant à utiliser des informations relatives aux quantités de données dudit flux de données multi-canal reçues par la seconde tête de tunnel pour aiguiller les canaux individuels du flux multi-canal, et ainsi faciliter la recomposition du flux original. Egalement, ce procédé permet une délivrance régulière du flux multi-canal sans coupure.

De façon avantageuse, l'information de synchronisation associée à un canal est une information d'horodatage extraite dudit flux de données multi-canal. Ainsi, on utilise une information déjà contenue dans la trame initiale pour synchroniser chaque canal et les classer à la réception. Il n'est donc pas nécessaire d'utiliser une information supplémentaire. La bande passante est ainsi optimisée. Avantageusement, ce procédé comprend une étape consistant à obtenir au moins une information relative à une information de congestion de la première porteuse. De plus ladite étape consistant à aiguiller chacun des canaux est également fonction de ladite information de congestion obtenue.

Ainsi, en cas de congestion sur la première porteuse, on optimise la répartition des canaux sur les première et seconde porteuses, de façon à conserver une activité optimale, sans la surcharger. L'aiguillage est notamment ajustable en permanence pour répartir de manière dynamique les canaux sur les première et seconde porteuses. Selon un mode de mise en oeuvre avantageux de l'invention, ladite ou lesdites information(s) relative(s) à des quantités de données dudit flux de données multi-canal reçues par la seconde tête de tunnel appartient (appartiennent) au groupe comprenant : * des informations relatives à une occupation d'une mémoire en réception comprise dans ladite seconde tête de tunnel ; * des informations relatives à un taux de perte de données dudit flux transmises sur ladite au moins une seconde porteuse. Selon l'invention, il est proposé de corriger la politique d'aiguillage des canaux individuels du flux multi-canal en fonction des difficultés rencontrées et/ou anticipées par la seconde tête de tunnel pour recomposer le flux. On réagit ainsi par anticipation des problèmes à venir tels que par exemple la congestion du réseau.

Selon une caractéristique avantageuse de l'invention, les informations relatives à une occupation d'une mémoire tampon de réception appartiennent au groupe comprenant : - une première information de différence entre une valeur instantanée de remplissage et une valeur de référence de remplissage, le remplissage faisant référence à une partie de ladite mémoire en réception associée à la réception de données en provenance de la première porteuse ; - une seconde information de différence entre une valeur instantanée de remplissage et une valeur de référence de remplissage, le remplissage faisant référence à une partie de ladite mémoire en réception associée à la réception de données en provenance de la seconde porteuse ; - une troisième information de différence entre un nombre de données utiles dudit flux de données multi-canal et une valeur de référence de remplissage, une donnée utile étant une trame disposant de canaux présents dans une partie de ladite mémoire en réception associée à la réception de données en provenance de la première porteuse ainsi que de canaux présents dans une partie de ladite mémoire en réception associée à la réception de données en provenance de la seconde porteuse.

Ainsi, ces informations permettent une mise à jour régulière de l'algorithme d'aiguillage des canaux sur les première et seconde porteuses. Selon une autre caractéristique avantageuse, ledit procédé comprend une étape parmi le groupe d'étapes consistant à : - si la troisième information de différence est positive, et si la première information de différence est supérieure d'au moins un premier écart prédéterminé par rapport à la seconde information de différence, aiguiller vers la première porteuse un nombre de canaux d'une trame courante supérieur à un nombre de canaux d'une trame précédente aiguillés vers ladite première porteuse ; - si la troisième information de différence est positive, et si la première information de différence n'est pas supérieure d'au moins ledit premier écart prédéterminé par rapport à la seconde information de différence, aiguiller certains canaux d'une trame courante vers aucune desdites première et seconde porteuses ; - si la troisième information de différence est négative, si la première information de différence est supérieure à une portion prédéfinie de ladite valeur de référence, et si une congestion de la première porteuse est détectée, aiguiller vers la première porteuse un nombre de canaux d'une trame courante inférieur à un nombre de canaux d'une trame précédente aiguillés vers ladite première porteuse ; - si la troisième information de différence est négative, si la première information de différence est supérieure à une portion prédéfinie de ladite valeur de référence, et si aucune congestion de la première porteuse est détectée, aiguiller vers la première et la seconde porteuse des canaux d'une trame courante qui étaient aiguillés pour une trame précédente uniquement vers ladite première porteuse ; - si la troisième information de différence est négative, si la seconde information de différence est supérieure à une portion prédéfinie de ladite valeur de référence, aiguiller vers la première porteuse un nombre de canaux d'une trame courante supérieur à un nombre de canaux d'une trame précédente aiguillés vers ladite première porteuse. Ainsi, grâce à ces informations, l'invention permet d'optimiser la répartition des données sur les première et seconde porteuses. De façon avantageuse, ledit procédé comprend une étape consistant à associer une information de priorité à chacun des canaux, en fonction d'un profil prédéterminé d'une application véhiculée par ledit flux, ladite étape consistant à aiguiller chacun des canaux étant également fonction des informations de priorité associées aux canaux.

Ainsi, l'invention permet d'adapter le mode de transport par défaut de la porteuse tunnel selon le type du flux de données multi-canal à transmettre. Par exemple, suivant l'application véhiculée, le classement des canaux diffère selon que l'application est de type audio streaming ou de type vidéoconférence. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur. Ce produit programme d'ordinateur comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur.

Dans un autre mode de réalisation, l'invention concerne un moyen de stockage lisible par ordinateur, éventuellement totalement ou partiellement amovible, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation).

L'invention concerne également une première tête de tunnel participant à une transmission d'un flux de données multi-canal comprenant des trames comprenant une pluralité de canaux, la transmission étant effectuée via un tunnel multi-transport depuis une première tête de tunnel vers une seconde tête de tunnel, ledit tunnel mettant en oeuvre une première porteuse supportant un protocole de transport avec acquittement et une seconde porteuse supportant un protocole de transport sans acquittement, Selon l'invention, la première tête de tunnel est remarquable en ce qu'elle comprend : - des moyens d'obtention d'au moins une information relative à des quantités de données dudit flux de données multi-canal reçues par la seconde tête de tunnel ; - des moyens d'aiguillage desdits canaux d'une trame dudit flux de données multicanal reçue par la première tête de tunnel vers l'une desdites porteuses du tunnel, en fonction de ladite au moins une information obtenue ; - des moyens d'association d'une même information de synchronisation auxdits canaux ; - des moyens de transmission vers la seconde tête de tunnel de chacun des canaux de ladite trame donnée via la porteuse vers laquelle ledit canal a été aiguillé, ainsi que leur information de synchronisation associée. De manière avantageuse, l'information de synchronisation associée à un canal est une information d'horodatage extraite dudit flux de données multi-canal. Avantageusement, la première tête de tunnel comprend des moyens d'obtention d'au moins une information relative à une information de congestion de la première porteuse. Selon une caractéristique avantageuse, ladite ou lesdites information(s) relative(s) à des quantités de données dudit flux de données multi-canal reçues par la seconde tête de tunnel appartient (appartiennent) au groupe comprenant : * des informations relatives à une occupation d'une mémoire en réception comprise dans ladite seconde tête de tunnel ; * des informations relatives à un taux de perte de données dudit flux transmises sur ladite au moins une seconde porteuse. Selon une autre caractéristique avantageuse, les informations relatives à une occupation d'une mémoire tampon de réception appartiennent au groupe comprenant : - une première information de différence entre une valeur instantanée de remplissage et une valeur de référence de remplissage, le remplissage faisant référence à une partie de ladite mémoire en réception associée à la réception de données en provenance de la première porteuse ; - une seconde information de différence entre une valeur instantanée de remplissage et une valeur de référence de remplissage, le remplissage faisant référence à une partie de ladite mémoire en réception associée à la réception de données en provenance de la seconde porteuse ; - une troisième information de différence entre un nombre de données utiles dudit flux de données multi-canal et une valeur de référence de remplissage, une donnée utile étant une trame disposant de canaux présents dans une partie de ladite mémoire en réception associée à la réception de données en provenance de la première porteuse ainsi que de canaux présents dans une partie de ladite mémoire en réception associée à la réception de données en provenance de la seconde porteuse. Egalement, la première tête de tunnel comprend des moyens d'association d'une information de priorité à chacun des canaux, en fonction d'un profil prédéterminé d'une application véhiculée par ledit flux, lesdits moyens d'aiguillage de chacun des canaux prenant en compte également ces informations de priorité associées aux canaux. 5. LISTE DES FIGURES D'autres objets, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui va suivre à titre d'exemple non limitatif, et à l'examen des dessins annexés dans lesquels : - la figure 1 est une vue schématique d'une configuration classique d'un réseau privé virtuel (VPN) mettant en oeuvre un tunnel ; - la figure 2 est une vue schématique d'un modèle en couche classique d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon un mode de réalisation particulier de l'invention ; - la figure 3 est une vue schématique illustrant un exemple de format classique d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; - la figure 4 est une vue schématique illustrant une tête de tunnel mettant en oeuvre la présente invention selon un mode de réalisation particulier de l'invention ; - la figure 5 est une vue schématique illustrant un exemple de flux multi-canal supporté par les mécanismes de la présente invention, selon un mode de réalisation particulier de l'invention ; - la figure 6a est une vue schématique illustrant un exemple de format d'une trame Ethernet véhiculant un paquet tunnel selon un mode de réalisation particulier de l'invention ; - la figure 6b est une vue schématique illustrant un exemple de structure AVP selon le protocole L2TP et selon un mode de réalisation particulier de l'invention ; - la figure 7 est une vue schématique illustrant un système de stockage des données reçues des différentes porteuses du tunnel multi-protocole selon un mode de réalisation particulier de l'invention ; - la figure 8 est une vue schématique illustrant un algorithme de construction, par la tête de tunnel, d'un rapport de boucle selon un mode de réalisation particulier de l'invention ; - la figure 9 est une vue schématique illustrant un algorithme de mise en oeuvre, par un moteur de décision, pour les canaux d'un flux multi-canal 401 ; - la figure 10 est une vue schématique illustrant un dispositif selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE Dans la suite de la description, le procédé selon l'invention est plus amplement décrit dans le cadre d'une application multi-canal audio, mais est également applicable à tout flux multi-canal en général. La figure 1 illustre schématiquement, selon un mode de réalisation particulier de l'invention, une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel 100 entre une tête de tunnel locale 101 et une tête de tunnel distante 102, à travers un réseau de communication 107 (Internet par exemple). Ce tunnel 100 interconnecte un réseau LAN A 103 et un autre réseau LAN B 104. Chacun des réseaux LAN 103 et 104 comporte un équipement d'accès Internet haut débit de type passerelle domestique (ou Home Gateway en anglais), pouvant intégrer un pare-feu (ou Firewall en anglais) 105 et 106, des équipements de type ordinateur (ou PC pour Personal Computer en anglais) 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 restitutions des médias numériques 108 et 112.

Une tête de tunnel peut ê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 que le tunnel 100 est établi, les équipements 108, 109, et 110, connectés au réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au réseau LAN B 104. Par exemple, le client local 108 connecté au réseau LAN A 103 peut communiquer avec le serveur local 113 connecté au 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'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.

La figure 2 illustre schématiquement un exemple de modèle en couche classique mis en oeuvre par une tête de tunnel et dans laquelle l'invention peut être mise en oeuvre. Cette figure 2 décrit le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110 (connectés au réseau LAN B 103) et qui va entrer dans le tunnel 100. Un modèle en couche décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100 permet de décrire ce cheminement. 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 (ou Universal Plug and Play en anglais) lorsqu'une tête de tunnel 101 est intégrée dans un équipement UPnP. La tête de tunnel 101 comporte une interface physique Ethernet 208 qui remet les trames Ethernet issues des équipements 108, 109, 110 à la couche liaison 207 pour routage vers la couche réseau 206 (pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel) ou vers la couche de pont ( bridge ) 209, pour les autres trames Ethernet. La couche de pont 209 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relais de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Sur le pont sont attachées une interface Ethernet 207 et au moins une interface virtuelle 210 simulant un contrôleur Ethernet. Une interface virtuelle 210 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 (formation d'un paquet tunnel) et l'extraction d'une trame. Les trames reçues de l'interface virtuelle 210, après traitement par l'application 200, sont remises sous la forme d'un paquet à travers une interface applicative ( socket en anglais) 201 à un protocole de transport fiable TCP 203 ou non fiable UDP 205, respectivement sécurisés par les protocoles SSL 202 et DTLS 204. Après traitement par un protocole de transport pour former un paquet tunnel 250 (figure 3), celui-ci est passé à la couche réseau 206. Le datagramme IP ainsi formé avec le paquet tunnel peut maintenant être transmis sur le réseau LAN à travers les couches liaison 207 et physique 208.

La réception d'une trame en provenance du tunnel 100 suivra dans la tête de tunnel le cheminement inverse à celui présenté ci-dessus. La figure 3 présente un exemple de format classique d'une trame Ethernet 260 véhiculant un paquet tunnel de niveau 2, transitant par exemple sur le réseau LAN A 103 de la figure 1, et qui comporte : un champ d'en-tête Ethernet 261, un premier datagramme IP 262 véhiculant lui-même un paquet tunnel 250 de niveau 2, et un champ FCS 263 (pour Frame Check Sequence en anglais ou séquence de contrôle de trame en français). Le paquet tunnel 250 comporte quatre parties : - un champ d'en-tête du protocole de transport 251 (à savoir TCP ou UDP dans cet exemple) ; - un champ d'en-tête du protocole d'encapsulation 252 (à savoir L2TP ou TLS dans cet exemple, qui sont décrits notamment dans les documents suivants : IETF RFC-3931, "Layer two tunneling protocol ù version 3 (L2TPv3)", J. Lau and ail, March 2005 et IETF RFC-2246, "The TLS Protocol Version 1.0" ), - un champ d'en-tête du protocole embarqué 253 (à savoir Ethernet dans cet exemple), et enfin - un champ de données utilisateurs 254, qui lui-même 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 un scénario d'application de l'invention en relation avec l'environnement décrit en relation avec la figure 1, où sont représentées les structures fonctionnelles d'un émetteur 410 et d'un récepteur 420 selon la présente invention.

Les algorithmes de l'invention sont décrits selon une mise en place sur les têtes de tunnel 101 et 102 de la figure 1. Ainsi, chaque tête de tunnel 101 ou 102 embarque les blocs émetteur 410 et récepteur 420 particuliers de l'invention vers/depuis un tunnel VPN multi-transport. Selon le schéma de la figure 4, le module 410 est implémenté sur une première tête de tunnel (par exemple 101), et le module 420 sur la seconde tête de tunnel (par exemple 102), reliées entre elles par les différentes porteuses du tunnel multi-transport (ici 100A pour le protocole TCP et 100B pour le protocole UDP).

Il est clair cependant que l'invention ne se limite pas à ces deux types particuliers de protocole et concerne d'autres types de protocole pouvant être mis en oeuvre pas l'invention. Par exemple, le protocole avec acquittement est du type SCTP ( Stream Control Transport Protocol ) et le protocole sans acquittement est du type DCCP ( Datagram Congestion Control Protocol ). Le module 410 reçoit en entrée un flux RTP multi-canal 401 et est en charge de le manipuler afin de transporter au mieux les données de ce flux RTP à travers le tunnel multi-transport 100.

Le module 420 reçoit ces données depuis le tunnel 100, et va reconstituer un flux 402 RTP multi-canal aussi conforme que possible au flux multi-canal 401 original. On rappelle que la description se focalise sur des flux multi-canal véhiculés sur le protocole de transport RTP car il s'agit d'une solution privilégiée de l'état de la technique pour le transport de flux de diffusion en temps réel . Mais selon un mode de réalisation optionnel (non décrit), tout autre mode de transport (tel que HTTP par exemple) est compatible avec les moyens de la présente invention. Le module émetteur 410 est composé des éléments suivants : - un démultiplexeur de canaux 411, en charge d'extraire les canaux audio véhiculés dans un flux RTP multi-canal 401 applicatif et reçu du réseau local (par exemple le réseau LAN A 103) ; - un moteur de décision 412, en charge d'aiguiller le routage de chacun des canaux audio identifiés par 411 sur au moins une des porteuses du tunnel multitransport ; - des empaqueteurs 413 et 414 propres à chaque porteuse du tunnel mufti- transport, supportant l'encapsulation des canaux identifiés par le module 411 et aiguillés vers eux. Le module récepteur 420 est composé des éléments suivants : - des dé-paqueteurs 421 et 422 propres à chaque porteuse du tunnel multitransport, supportant la désencapsulation des données véhiculées via leur porteuse réciproque du tunnel, et permettant la recomposition (ou réassociation) des canaux audio passagers correspondant à une même identification de synchronisation (plus amplement décrite dans la suite de la description) ; - une zone de stockage 423 en charge de réordonner les données applicatives (canaux individuellement reçus et réordonnés selon leur marquage de synchronisation) ; - un régénérateur de trame RTP 424, permettant la reconstitution d'une trame multi-canal selon le format applicatif véhiculé dans le paquet RTP 401, et à partir des informations reçues de l'émetteur 410 et conservées dans le stockage 423 ; - un séquenceur de flux 425 en charge de délivrer sur le réseau local (par exemple le réseau LAN B 104) les paquets (ou trames) RTP selon le marquage temporel (ou timestamp en anglais) indiqué dans les paquets (ou trames) RTP originels 401. Du fait de la zone de stockage temporaire 423 permettant une absorption des fluctuations de latence de l'Internet, et selon les procédés mis en place dans le module régénérateur 424, le séquenceur 425 est alimenté continuellement et est capable de transmettre sur son réseau local un flux RTP multi-canal 402 avec une gigue quasi nulle. Ceci est particulièrement avantageux dans le cas du transport de flux multi-canal en continu ( streaming en anglais) sur RTP tel que pour des applications de diffusion audio ou vidéo non-interactives, c'est-à-dire que les récepteurs de ces types de flux se soucient peu de la latence inhérente à l'Internet pour le transport de la donnée multi-canal depuis la source (connectée au réseau distant). Selon l'invention, ces récepteurs sont architecturés pour recevoir un flux multicanal 401 de manière régulière comme si la source était sur le même sous-réseau local de type LAN (délai inter-paquet quasi constant, ce qui n'est pas possible lors d'une transmission sur l'Internet selon les mécanismes de l'état de la technique).

La figure 5 (plus amplement décrite par la suite) illustre schématiquement et à titre indicatif, des exemples de flux multi-canal 401 véhiculés selon le protocole RTP. La présente invention est capable de véhiculer ces exemples de flux sur le tunnel de manière à répondre aux problèmes précédemment exposés. Un exemple de flux audio multi-canal est un flux multi-canal au format AC-3, qui comprend par exemple 6 canaux audio séparés (dans le cas du format AC-3 de type 5.1). Ce type de flux est utilisé par la suite dans la description, à titre d'exemple uniquement, car la présente invention supporte tout format multi-canal (audio seule, audio/vidéo, ou vidéo seule). Une fois les canaux du flux multi-canal identifiés, le démultiplexeur de canaux 411 propose une liste de canaux au moteur de décision de routage 412. Cette liste est composée de canaux correspondant à des informations extraites telles quelles du flux 401 (par exemple, pour un flux RTP AC-3, les différents blocs ABi 553 de la figure 5 décrits plus en détail par la suite) mais aussi d'un canal de donnée virtuel (représentant un jeu de données utiles à la reconstruction du flux multi-canal 402 par la tête de tunnel destinataire, noté `CBO' (pour Control Bloc en anglais, ou Bloc de Contrôle en français, d'indice 0) et non représenté). Selon un mode de réalisation particulier de l'invention, une information de criticité est associée à chaque canal ABi ou CB0 afin d'indiquer si le canal doit être transmis de manière fiable ou non. Cette information de rang est notamment utile au moteur de décision 412 pour sélectionner les canaux dans le but de modifier leur aiguillage selon les résultats du transport sur le tunnel (typiquement, on préférera dégrader la qualité des canaux audio considérés comme moins importants en faveur des autres). L'algorithme de fonctionnement du moteur de décision 412 est plus amplement décrit dans la suite de la description en relation avec la figure 9. Ainsi, certains canaux sont dirigés vers l'empaqueteur 413, d'autres vers l'empaqueteur 414. Les mécanismes d'encapsulation mis en oeuvre par les empaqueteurs 413 et 414 et les mécanismes de désencapsulation mis en oeuvre par les dé-paqueteurs 421 et 422 véhiculent les données selon le protocole décrit en relation avec la figure 6 plus amplement décrite par la suite. Ainsi, un élément de synchronisation est inséré dans le protocole d'encapsulation/désencapsulation pour être véhiculé en accompagnement de chaque élément du flux multi-canal, afin de permettre une identification fine de l'échantillon de canal par les dé-paqueteurs 421 et 422 et pour permettre une réassociation des échantillons de canaux du flux qui étaient originellement dans la même trame de flux 401 et qui ont été séparés sur chacune des porteuses 100A et 100B du tunnel. Les mécanismes et l'architecture du stockage temporaire 423 sont décrits en relation avec la figure 7, et effectuent le réordonnancement des divers échantillons de canaux du flux 401 reçus par les dé-paqueteurs.

Le régénérateur de trame 424 est apte à obtenir les informations préservées dans le stockage 423 pour les divers canaux audio reçus, et ainsi reconstituer une trame multi-canal selon le format du flux 401 d'origine. Par exemple, les canaux de données ABi et le canal virtuel CBO sont considérés pour reconstituer une trame selon le format AC-3.

Selon un mode de réalisation particulier de l'invention, un signal d'information 430 est véhiculé entre le régénérateur de trame 424 (plus particulièrement son émetteur de rapport 4242) et le moteur de décision 412. Ce signal d'information 430 indique la capacité du régénérateur de trame 424 à recréer des trames multi-canal selon la disponibilité des informations dans le stockage 423. Cette information est particulièrement utile au moteur de décision 412 du module 410 pour corriger la politique d'aiguillage des canaux individuels du flux multi-canal 401 vers les porteuses TCP ou UDP du tunnel multi-transport. Au cas où des données applicatives manqueraient pour la reconstruction des trames pour le flux 402, le régénérateur de trame 424 possède un système de correction 4241 apte à remplacer les données manquantes selon une technique de substitution adéquate. Par exemple, pour un flux audio, une méthode peu coûteuse, simple et largement répandue consiste à insérer du silence (ou plus généralement des données synthétiques) ou du bruit. Une technique de répétition peut aussi être mise en pratique. Le séquenceur de flux 425 est quant à lui en charge de transmettre de manière régulière les trames multi-canal (obtenues par le régénérateur de trame 424) grâce au protocole RTP (flux 402). Ce séquencement est dépendant de l'horodatage ( timestamp en anglais) RTP originel du flux 401 dont l'information a été véhiculée à travers le tunnel. Le séquenceur de flux 425 ne sera pas décrit plus en détail car il existe une multitude d'implémentations dans l'état de la technique permettant de séquencer une transmission de flux RTP. Le serveur à l'origine du flux multi-canal 401 du sous-réseau distant fonctionne notamment sur ce principe.

La figure 5 illustre schématiquement un exemple de flux multi-canal 401 supportés par les mécanismes de la présente invention. L'IETF a définit plusieurs méthodes d'encapsulation de contenu multimédia multi-canal dans le protocole RTP. Parmi ces méthodes, on notera : - le codec (pour COmpression-DECompression en anglais ou COdage- DECodage en français) audio AC-3 ; ou - le Dolby digital, anciennement appelé Dolby AC3, qui est notamment le format le plus utilisé pour les disques DVD-video, et est adopté pour la diffusion de télévision terrestre par l'ATSC (pour Advanced Television Standards Committee en anglais), pour la diffusion en continu ( streaming en anglais) sur un réseau de type LAN par l'alliance DLNA ( Digital Living Network Alliance en anglais). Il existe plusieurs versions d'encodage de type AC-3 : 1.0 (mono) très rare, 2.0 (stéréo), la 5.1 (5 canaux pour les haut-parleurs satellites et 1 canal pour le caisson de basse) et la 7.1 (7canaux pour les haut-parleurs satellites et 1 canal pour le caisson de basse). C'est un système de codage numérique avec compression de données audio qui utilise les limites de perception de l'oreille pour compresser efficacement un signal et restituer le son sur 6 canaux indépendants (dans le cas d'un encodage de type 5.1).

La recommandation RFC-4184 ( RTP Payload for AC-3 ) stipule le format d'encapsulation dans un flux de diffusion selon le protocole RTP. La figure 5 représente le format d'une trame RTP 500 véhiculant des trames de données AC-3. Une entête RTP 501 sert à identifier le type de données véhiculées, avec notamment un champ d'horodatage Timestamp relatif au premier échantillon (ou trame) de données AC-3 véhiculé, et avec un champ Payload Type identifiant le format des données véhiculées (permettant d'interpréter les blocs 560 et 502). On rappelle qu'une valeur du champ payload type dans la fourchette 96-127 indique une définition dynamique, associée à une déclaration par un protocole tiers (tel que Session Description Protocol (SDP), norme RFC-2327). Le flux de données de type AC-3 est constitué de trames de synchronisation 550 successives dans lesquelles chaque partie représente des informations importantes pour la décompression et la récupération des données. Un bloc `SI' 551 représente les informations sur la synchronisation. Le bloc SI contient un mot de 40 bits de synchronisation permettant d'indiquer le début de la trame AC3. Ce mot est au début de chaque trame. Un bloc `BSI' 552 contient les informations sur le type de données transportées dans le flux. Ce n'est qu'à partir de ces données qu'il est possible de reconstituer les échantillons d'origine (déterminer le nombre de voies utilisées en plus du caisson). Des informations moins importantes sont aussi transportées, comme la langue, l'heure, le type de service (dialogue, commentaire, musique, etc.). Un ensemble de blocs 553 `ABi' (i=1...n) dont chaque bloc renferme les données audio des différentes voies. Chaque bloc est constitué de 256 échantillons sonores.

Un bloc `Aux' 554 contenant des informations supplémentaires sur les blocs 'ABi', et utilisées en cas de besoin de donnée de secours. Un bloc `CRC' 555 permettant le contrôle d'erreur afin de vérifier que les informations ne sont pas erronées.

Cette trame 550 est encapsulée par un entête 560 de deux octets, spécifique à l'encapsulation de données AC-3 (encore appelée Payload-Specific Header selon le protocole RTP). Ainsi, la zone de données utiles ( payload en anglais) de l'entête 560 comprend un bloc 561 `MBZ' formé de bits mis à zéro, un bloc 562 `FT' (pour Frame Type en anglais) indiquant le type de trame véhiculée (complète ou fragmentée), et un bloc 'NF' 563 indiquant le nombre de trames AC-3 550 présentes dans la zone de données utiles 502. Si la taille d'une trame AC-3 dépasse la taille MTU (pour Maximum Transmission Unit tel que défini dans le cadre du protocole TCP), cette trame peut être fragmentée au niveau transport RTP. Selon les recommandations de mise en oeuvre du protocole RTP, les fragments de cette trame sont véhiculés en ordre. Ainsi, le démultiplexeur 411 devra recevoir plusieurs paquets RTP avant d'obtenir chacun des canaux du flux multi-canal AC-3. Le démultiplexeur 411 décompose les canaux du flux applicatif 401 et propose ainsi les canaux identifiés au moteur de décision 412 (par exemple, les 6 canaux audio 553 s'il s'agit d'un flux 401 selon le format audio AC-3 de type 5.1). Un canal virtuel complémentaire (non représenté) est considéré en regroupant les données nécessaires à la reconstruction du flux RTP originel par le régénérateur 424 (ce canal peut notamment être composé des données 560, 551, 552, 554 pour un flux audio AC-3 en plus de l'information d'horodatage timestamp RTP de l'entête 501).

Le démultiplexeur de canaux 411 peut gérer d'autres méthodes d'encapsulation de contenu multimédia multi-canal dans le protocole RTP, telles que celles pour les flux: - MPEG2-TS, dont la recommandation RFC-2250 ( RTP Payload Format for MPEG1/MPEG2 Video and Audio ) décrit la méthode de transport sur RTP ; - MPEG4, dont la recommandation RFC-3016 ( RTP Payload Format for MPEG-4 Audio/Visual Streams ) décrit la méthode de transport sur RTP. Le type de flux supporté par ces recommandations peut être considéré comme bi-canal dans le sens où les parties vidéo et audio correspondant à des canaux séparés (voire multi-canal si la partie audio au format multi-canal AC3, et non pas monocanal AAC ou MP3). On notera aussi un profil RTP plus appliqué aux systèmes interactifs, tels que la vidéoconférence selon la RFC-3551 ( RTP Profile for Audio and Video Conferences with Minimal Control "). Bien que la présente invention ne soit pas adaptée au transport de flux interactifs stricts, dans le cadre d'un transport sur de 1'Internet avec une faible latence (par exemple un temps d'aller-retour Round Trip Time RTT inférieur à 50ms), la durée de rétention dans la zone de stockage 423 (1 à 2 fois le RTT) n'est pas critique à la conversation. Au contraire, la qualité de la conversation dans ce contexte en sera augmentée. La figure 6a présente un exemple de format d'une trame Ethernet 600 véhiculant un paquet tunnel 601 selon l'invention et transitant par exemple sur le réseau LAN A 103 de la figure 1 entre la tête de tunnel 101 et la passerelle 105, et qui comporte : un champ d'en-tête Ethernet 261, un premier datagramme IP véhiculant lui-même un paquet tunnel 601 selon l'invention (référencé 601), et un champ FCS ( Frame Check Sequence , ou séquence de contrôle de trame ). Le paquet tunnel 601 comporte quatre parties : - un champ d'en-tête du protocole de transport 251 (à savoir TCP ou UDP dans cet exemple), - un champ d'en-tête du protocole d'encapsulation 252 (à savoir L2TP ou TLS dans cet exemple, qui sont décrits notamment dans les documents suivants : IETF RFC-3931, "Layer two tunneling protocol ù version 3 (L2TPv3)", J. Lau and ail, March 2005 et IETF RFC-2246, "The TLS Protocol Version 1.0" ), - un champ d'en-tête du protocole embarqué 253 (à savoir un code d'identification propre au format d'encapsulation des données selon l'invention est défini pour prévenir le récepteur du format des données utiles 603 selon l'invention), et enfin - un champ de données utiles 603, qui lui-même comporte un jeu de canaux à transmettre dans le tunnel vers la tête de tunnel destinataire.

Chaque canal 611 est précédé d'un entête 610 comportant des informations relatives à l'identification du canal transporté. Par exemple, si le canal 611 correspond à un canal de donnée 'ABi' 553, celui-ci doit être référencé par un entête 610 composé d'un numéro d'ordre 620 (tel que spécifié selon le format du flux multi-canal) ainsi que d'un indice ou marquage de synchronisation 621 (permettant le regroupement des canaux de données 'ABi' pour un échantillon de temps donné). Pour un canal virtuel CBO (non représenté), l'entête 610 comporte un numéro de canal 620 non significatif (car les données de ce canal CBO ne sont pas des données au sens échantillon de données d'une trame du flux multi-canal (dans le cas du format de trame AC-3, il ne s'agit pas d'un échantillon audio), mais ce sont des données servant à la recomposition du paquet RTP 501 et de l'entête de la trame multi-canal 560). L'indice de synchronisation 621 est le même que celui des canaux de donnée ABi (553).

L'indice de synchronisation 621 est par exemple issu de la valeur d'horodatage timestamp de chaque paquet RTP du flux 401, dont le format modulo 32 bits (entier non signé) peut être réduit très fortement. Il ne s'agit pas ici d'avoir un élément de synchronisation distinct pour plusieurs méga octets du flux RTP comme le permet le timestamp RTP (pour un flux vidéo, échantillonné à 90kHz, le modulo est de 13 heures ; pour un flux audio échantillonné à 8 KHz, l'intervalle est d'environ 6 jours), mais cet indice de synchronisation 621 sert à réordonner les données émises sur des porteuses différentes du tunnel multi-transport, dont le RTT est de quelques centaines de millisecondes. De manière optimisée, on utilise un entête 610 unique pour plusieurs blocs 611 d'un même indice de temps 621, ces blocs 611 étant mis à la suite de l'entête 610 commun. Ainsi, selon un mode de réalisation particulier de l'invention, le champ 620 est un octet dont chaque bit à 1 indique la présence par la suite des échantillons de canal de données 611 pour une même trame applicative selon le format transporté, les échantillons étant ordonnés selon leur numéro de canal (par exemple selon le format 550 dans le cas du format audio AC-3 de la figure 5), Selon un autre mode de réalisation particulier de l'invention, l'entête 610 supporte une liste de canaux 611 pris parmi des trames d'échantillonnage successives, mais concaténées à l'origine dans le même paquet RTP (le paquet RTP comporte plusieurs échantillons de données pour une information d'horodatage (ou timestamp ) identique). Dans le cas du transport de canaux de format audio AC-3 selon la description de la figure 5, l'entête 560 est commun à diverses trames 553 audio AC-3. Ainsi, le champ 620 embarque une indication (non représentée) du nombre de trames successives (de 1 à la valeur de 'NF' 563) permettant de connaitre la longueur de la liste décrite ci-après, suivie d'une liste d'octets de représentation des indices de canal de dimension égale au nombre de trames successives (il s'agit du même type d'octets que le mode de réalisation précédent, dont chaque bit à 1 indique la présence du bloc audio correspondant). Ensuite, les canaux 611 sont convoyés à la suite dans l'ordre : par exemple, trame 0 / bloc canal 0, trame 0 / bloc canal 1, trame 1 / bloc 0, etc... Il y a donc autant de blocs audio successifs que la somme de bits à 1 dans la liste d'octets de représentation précitée du champ 620. La figure 7 illustre schématiquement une structure du stockage temporaire 423 en charge d'ordonnancer les données reçues en provenance du tunnel multi-transport, sachant que ces données sont dynamiquement aiguillées par le dispositif tête de tunnel émetteur sur des porteuses indépendantes du tunnel, et que chaque porteuse a pu subir des pertes sur l'Internet. Le stockage 423 est représenté ici sous forme de liste chaînée d'éléments (aussi appelés noeuds) 710, chaque élément 710 représentant un ensemble de trames de données 550 du flux 401, estampillées par le même indice de synchronisation SYNC 621 (c'est-à-dire des trames de données véhiculées dans le même paquet RTP 401, et donc sujettes à la même information d'horodatage (ou timestamp ) RTP). L'élément (ou noeud) 710 comprend : - des pointeurs vers les éléments (ou noeuds) 710 suivant et/ou précédent afin de former la liste chainée 423 ; - l'information de synchronisation SYNC 621 propre au transport sur le tunnel, et permettant d'ordonner les éléments (ou noeuds) 710 entre eux ; - l'information d'horodatage (ou timestamp ) RTP correspondant à l'information de synchronisation SYNC 621 (véhiculée dans le canal 611 représentatif du canal virtuel CBO) ; - un pointeur vers une structure 730, commune et permanente à la durée de vie du flux 401, regroupant les données invariantes pour le protocole RTP ; - le nombre de trames applicatives (typiquement nombre de trames 550 dans le cas du transport de flux multi-canal AC-3) pour un même échantillon de temps (véhiculée dans le bloc 620 de l'entête 610 selon la figure 6) ; - un tableau de trames, de dimension 1 et de longueur de la valeur du nombre de trames précitée, et dont chaque élément pointe sur une liste chaînée et ordonnée de canaux 720 (le premier élément 720 de la liste est de préférence un canal virtuel de type CBO, et les suivants sont des canaux données de type ABi ordonnés par leur indice (ou numéro d'ordre)). L'élément 730 sauvegarde les informations relatives au flux 401 véhiculé à travers le tunnel pour un client et un serveur de chaque réseau LAN distinct 103 et 104. L'élément 730 comprend notamment les informations suivantes : - les adresses MAC des dispositifs client-serveur ; - les adresses IP des dispositifs client-serveur ; - les ports utilisés pour la connexion RTP de chaque dispositif client et serveur ; - les informations de l'entête RTP, communes pour tous les paquets RTP, comprenant la version courante du protocole RTP (`Ver'), l'identification du format des données transportées (Payload-type ou `PT') et les identifiants CSRC et SSRC du flux RTP. L'élément canal 720 comprend : - des pointeurs vers les éléments canaux 720 suivant et/ou précédent afin de former une liste chaînée ; - une référence 'ChannelNb' indiquant l'indice de canal représentant l'élément courant (typiquement l'indice i du bloc 553 ABi, ou un indice -1 pour un bloc CBO, qui est le premier indice de la chaîne) ; - une référence `QueueNB' permettant d'identifier le dé-paqueteur 421 ou 422 à l'origine de la réception de la donnée du réseau, c'est-à-dire que cela revient à savoir si la donnée a été reçue par une porteuse fiable (TCP 100A) ou non fiable (UDP 100B) du tunnel multi-transport ; - un pointeur sur une zone de stockage mémoire 721 hébergeant la donnée reçue. Ainsi, dès l'arrivée de données en provenance des porteuses 100-A ou 100-B du tunnel, les dé-paqueteurs 421 ou 422 sont aptes à insérer chaque donnée reçue (ensemble 610-611) au bon emplacement selon les étapes suivantes consistant à : - rechercher l'élément (ou noeud) 710 selon l'information SYNC 621 véhiculée dans le paquet tunnel, avec création de l'élément (ou noeud) 710 si absent (on remarquera que seule l'information SYNC 621 est nécessaire pour la création d'un élément (ou noeud) 710, et que cette valeur est présente dans tous les paquets du tunnel. Peu importe l'ordre d'arrivée des paquets TCP ou UDP, il est toujours possible de créer un élément (ou noeud) 710 dès le premier paquet et de l'enrichir ensuite avec les données du ou des paquets suivants) ; puis - rechercher, à partir du bloc 620 du paquet tunnel, la trame 550 applicative correspondante dans le tableau des trames de 710, et - insérer l'échantillon canal 611 dans la zone mémoire correspondant au bon indice de canal parmi les éléments 720 (CBO ou ABi).

Ainsi, le régénérateur de trame 424 est capable d'obtenir aisément à partir du stockage 423 les données nécessaires à la recomposition d'une trame de données pour chaque noeud 710. Par exemple, selon l'illustration de la figure 7, trois éléments noeuds 710 sont disponibles (avant la date `T') pour extraction et envoi vers le réseau local. A partir des liens entre 710 et chacun des éléments 720, le système 424 peut proposer une trame de données (par exemple trame audio AC-3 553 avec son entête 560) au séquenceur de flux 425 pour encapsulation dans un paquet RTP et émission sur le réseau. Le séquenceur de flux 425 est classique et ne fera donc pas l'objet d'une description détaillée. Selon l'invention, le régénérateur de trame 424 est capable de déterminer le comportement des transmissions effectuées via les porteuses du tunnel sur l'Internet à la vue du remplissage du stockage temporaire 423. Par exemple, cette détermination est régulièrement effectuée à chaque extraction d'un élément (ou noeud) 710.

Une valeur nominale ou de référence `Thom' (référencée 756) du moyen de stockage 423 est typiquement de l'ordre de 2 à 3 fois le RTT entre les modules 410 et 420, afin de permettre au moins une retransmission lors d'une perte sur l'Internet (pour la porteuse TCP). A partir du nombre d'échantillons de données par seconde contenus dans les trames du flux passager 401 (par exemple 30 images/sec pour une vidéo), ou de la connaissance de la durée d'un échantillon (par exemple, 32ms pour une trame audio AC-3 selon une fréquence d'échantillonnage à 48KHz, ou 20 ms pour de l'audioconférence), il est aisé de connaître le nombre d'éléments 710 permettant la retransmission des données perdues sur l'Internet sans coupure (ou absence de donnée à lire) dans l'extraction de données du moyen de stockage 423 par le module 424..

Tout particulièrement, les informations suivantes sont extraites de l'analyse du remplissage du moyen de stockage 423 : - le remplissage utile du moyen de stockage 423 de valeur `Tutile' (en nombre d'éléments 710 disposant d'un élément canal virtuel 720 dit de type CBO) et référencé 750 ; - le dépassement de remplissage 'AT' global (référencé 754) par rapport à la valeur nominale (en nombre d'éléments 710), et individuel pour chaque porteuse TCP 100A et UDP 100B. Le dépassement global AT est la différence entre les données exploitables (`Tutile') présentes dans le moyen de stockage 423 et la valeur nominale (`Thom'), le dépassement de remplissage de la porteuse TCP (AT_TCP) est la différence entre les données présentes en provenance de la porteuse TCP présentes dans le moyen de stockage 423 et la valeur nominale (`Thom'), et le dépassement de remplissage de la porteuse UDP (AT_UDP) est la différence entre les données présentes en provenance de la porteuse UDP présentes dans le moyen de stockage 423 et la valeur nominale (`Thom'). On notera par ailleurs que le nombre maximal d'éléments 710 (noté `Tmax', référencé 755) correspond à la valeur `Thom' à laquelle on ajoute la plus grande des valeurs entre le dépassement de remplissage de la porteuse TCP (AT_TCP) et celui de la porteuse UDP (AT_UDP). - le taux de perte `Pi' pour chacun des éléments canaux 720 des éléments (ou noeuds) 710 compris dans la zone de remplissage nominal. Les différents cas possibles de remplissage du stockage 423 seront étudiés par la suite en relation avec la figure 8 (l'exemple d'agencement des valeurs 750, 754 et 755 de la figure 7 correspondrait aux cas CA ou présentés sur la figure 8). L'émetteur de rapport 4242 est en charge de récupérer ces valeurs et de les transmettre sur un canal de retour 430 au module 410, afin que ce dernier puisse, par le biais du moteur de décision 412, mettre en oeuvre son algorithme de routage (ou d'aiguillage) des canaux données sur les porteuses du tunnel. Ainsi le routage (ou aiguillage) des canaux applicatifs selon l'invention est asservi aux difficultés rencontrées et/ou anticipées par la tête de tunnel (tel que le module 420) destinataire du flux applicatif 401. L'algorithme mise en oeuvre par l'émetteur de rapport 4242 est plus amplement décrit par la suite en relation avec la figure 8. Le canal de retour d'information 430 peut indifféremment être réalisé : - grâce à une nouvelle porteuse dédiée du tunnel dans la direction du module 420 vers le module 410 ; ou - grâce à l'utilisation de la voie de retour d'une porteuse bidirectionnelle du tunnel déjà ouverte pour le transfert de données du module 410 vers le module 420 (par exemple la porteuse TCP 100A) ; ou - par une session de contrôle du tunnel selon le protocole du tunnel (par exemple selon le protocole L2TP). Afin de maximiser l'extensibilité dans le protocole L2TP, une méthode d'encodage uniforme des informations de contrôle et de données est proposée par ce protocole et est dénommée Attribute Value Pair (AVP). Cette structure AVP consiste en une association entre un type d'attribut et la valeur de cet attribut, qui peut être réutilisable pour la transmission de toute information entre les deux têtes de tunnel. Ainsi, le schéma 650 de la figure 6b présente un exemple de structure AVP 650 selon le protocole L2TP pour envoyer une liste de statistiques relevées pour le remplissage du stockage 423 à la tête de tunnel distante. L'entête 651 est classique, et un code d'attribut doit être choisi afin que la tête de tunnel destinataire reconnaisse le type de la structure envoyée. En données utiles, il est possible d'indiquer le nombre d'éléments de statistiques précitées ( Nombre d'entrées ou Number of Entries en anglais), suivi de la liste des statistiques précitées. Selon un mode de réalisation particulier de l'invention, cette liste est formée des valeurs de dépassement de remplissage de la porteuse TCP (AT_TCP), dépassement de remplissage de la porteuse UDP (AT_UDP) et de la valeur 754 transmises sous forme de valeurs séparées par des virgules selon le format informatique ouvert en mode texte appelé Comma-separated values (CSV). Ce format n'a jamais vraiment fait l'objet d'une spécification formelle mais, la norme RFC-4180 décrit la forme la plus courante et établit son type MIME "text/csv", enregistré auprès de l'IANA. Il aurait tout aussi bien pu être remplacé par un format XML pour les besoins du mode de réalisation particulier ou de tout format adapté à la description de listes. Une fois qu'un élément (ou noeud) 710 a été utilisé par le régénérateur de trame 424, cet élément (ou noeud) est supprimé du stockage 423. L'élément (ou noeud) 710 suivant sera le prochain pris en charge pour la suite de la transmission du flux 402. La figure 8 illustre schématiquement un algorithme de l'invention implémenté dans l'émetteur de rapport 4242 de la tête de tunnel 102 en vue de l'envoi du rapport de réception 650 via le canal d'information 430, à destination de la tête de tunnel 101. L'émetteur de rapport 4242 de la tête de tunnel 102 est régulièrement réveillé dans une étape 800 pour analyse du remplissage du moyen de stockage 423 et obtention des données d'information à rapporter au moteur de décision 412 de la tête de tunnel distante. Une étape 801 consiste à recalculer la valeur `Thom' du fait de la fluctuation du RTT moyen.

Une étape 802 consiste à déterminer le nombre de données exploitables (noté `Tutile') dans le moyen de stockage 423, c'est-à-dire le nombre d'éléments 710 disposant à la fois d'éléments 720 correspondants à des canaux transmis via la porteuse TCP dont l'élément `CBO' (avec QueueNB = `TCP') et d'éléments 720 correspondants à des canaux transmis via la porteuse UDP (avec QueueNB = `UDP').

Une étape 803 suivante consiste à déterminer le nombre maximal d'éléments 710 (noté `Tmax' et référencé 755) contenus dans le moyen de stockage 423. On notera que `Tmax' peut théoriquement être égal à `Tutile' s'il n'y a pas de déséquencement entre les porteuses TCP et UDP, mais le cas est rare. Une étape 804 consiste à calculer la différence AT entre les données exploitables (`Tutile') présentes dans le moyen de stockage 423 et la valeur nominale (`Thom'). Dans une étape 805, s'il y a suffisamment des données exploitables (test de l'étape 805 positif), des étapes 806 et 807 sont exécutées. Ceci correspond aux deux cas de remplissage du moyen de stockage 423 notés 0 et sur la figure 8. Dans l'étape 806, une indication des pertes relevées pour les données exploitables est recherchée sur les canaux véhiculés par la porteuse UDP, et compris entre le premier élément de la liste et l'élément correspondant à l'indice `Thom'. Par exemple, une valeur de taux de perte `Pi', sur un nombre d'échantillons égal à la valeur Tnom, correspond au pourcentage de perte (ou absence) du canal de données 720 d'indice `i'. Par exemple, pour un flux multi-canal audio AC-3, la valeur P5 (pour le canal audio 5) serait de 5% si le nombre d'éléments 710 dans le temps `Thom' est 100, et qu'il manque 5 éléments 720 correspondant à l'indice de canal 5 (ChannelNb = 5) parmi les 100 éléments 710. Dans l'étape 807 est recherché le déséquencement (par extrapolation de la différence entre les deux informations de dépassement de remplissage) entre les éléments véhiculés par les porteuses TCP 100A et UDP 100B relativement la valeur nominale Tnom, notés respectivement AT TCP et AT UDP.

S'il manque des données exploitables par rapport à la consigne nominale Tnom (test de l'étape 805 négatif), des étapes 808 et 809 sont exécutées. Ceci correspond aux deux cas notés et sur la figure 8. Dans l'étape 808, les différences AT_TCP et AT_UDP sont calculées pour les cas et (D. Typiquement, le test consiste à regarder l'élément (ou noeud) 710 correspondant à Tmax (c'est-à-dire le dernier élément de la liste chaînée) : si celui-ci contient un élément canal CBO (véhiculé par TCP), alors on se trouve dans le cas et on applique les formules suivantes : AT TCP = Tnom ù Tmax AT UDP = Tnom ù Tutile Sinon, on se trouve dans le cas et on applique les formules suivantes : AT TCP = Tnom ù Tutile AT UDP = Tnom ù Tmax L'étape 809 est identique à l'étape 806 sauf que les bornes de recherche sont différentes (c'est-à-dire entre 1 et Tutile (cas ^), ou entre 1 et Tmax (cas D)). Ensuite, dans une étape 810, l'émetteur de rapport 4242 est apte à émettre un rapport de remplissage (ou d'occupation) du stockage 423 vers la tête de tunnel distante 101. La figure 9 illustre schématiquement un algorithme mis en ouvre par le moteur de décision de routage 412 de la tête de tunnel 101 pour les canaux d'un flux multicanal 401. Une première étape 900 est activée lors de la réception d'un nouveau rapport 650 d'information émis depuis par l'émetteur de rapport 4242 de la tête de tunnel distante 102, via le canal d'information 430.

Selon un mode de réalisation particulier de l'invention, une mémorisation du rapport précédant est effectuée afin de ne pas appliquer de multiples mesures correctives pour un phénomène déjà préalablement reporté. Dans une étape 901, la table de routage concernant le flux multi-canal 401 est obtenue depuis une mémoire morte locale à la tête de tunnel 101 (et plus amplement décrite en relation avec la figure 10). Une table par défaut peut être associée pour chaque type de format véhiculé dans le flux 401. Par exemple, si le contenu multimédia multi-canal est au format audio AC-3, la table de routage peut être la table 980 de la figure 9. Cette table indique une répartition en pourcentage de chacun des 6 canaux de données 553 (précédemment identifiés 'ABi' pour l'exemple du flux AC-3 de la figure 5) sur l'une ou l'autre des porteuses du tunnel (TCP 100A ou UDP 100B). S'il existe, pour un canal audio, une valeur non nulle de répartition pour chaque porteuse, cela signifie que les données de ce canal audio sont réparties sur les deux porteuses (voire transmises en doublon si la somme des valeurs est supérieure à 100%, comme c'est le cas dans l'exemple pour un premier canal Chl de la table 980). Selon un mode particulier de l'invention, à la table 980 est associé un comportement pour la répartition des données sur les deux porteuses (par exemple, un canal ayant 50/50 peut avoir une consigne de comportement un sur deux , c'est-à-dire qu'une donnée sur deux est transmise sur TCP et l'autre sur UDP). Les canaux de données virtuels , dénommés `CBO' sont toujours transmis au moins sur la porteuse TCP. Une étape 902 consiste à vérifier si le moyen de stockage 423 n'a pas reçu un nombre d'échantillons de données exploitables (information AT 754 positive) supérieur au remplissage nominal de ce moyen de stockage 423. Si le moyen de stockage 423 a reçu un nombre d'échantillons de données exploitables (information AT 754 positive) supérieur au remplissage nominal, l'ensemble des étapes 910 à 915 est exécuté.

S'il y a trop de données reçues pour les éléments transmis sur la porteuse TCP (test 910 positif, c'est-à-dire AT_TCP est nettement supérieur à AT_UDP (par exemple 20% supérieur), ce qui correspond au cas de la figure 8), alors une étape 911 permet de calculer le nombre d'éléments canaux à transférer depuis la porteuse UDP vers la porteuse TCP. Ceci permet de profiter d'une porteuse TCP disposant actuellement de bonnes performances (peu de retransmissions) pour lui ajouter des canaux de données ABi supplémentaires. On réduit ainsi le nombre moyen d'échantillons de trames 550, mais ces échantillons sont plus complets (c'est-à-dire qu'ils contiennent plus d'éléments canaux 553). Ainsi, en décidant par exemple de ne prendre que la moitié de la différence de nombre d'échantillons entre TCP et UDP : t = (AT_TCP - AT_UDP) / 2 et en prenant connaissance, grâce à la table de routage (ou d'aiguillage) actuelle, du nombre N de canaux pour le convoyage via UDP (N est le prorata de canaux transmis sur UDP pour une trame 550), on obtient un nombre de canaux C (C = t*N) à dérouter depuis la porteuse UDP vers la porteuse TCP. Dans une étape 912, il est procédé à la sélection du nombre de canaux C à dérouter de la porteuse UDP vers la porteuse TCP. Tout algorithme de sélection est envisageable (répartition uniforme entre les canaux, ou sélection en priorité des canaux les plus importants). Par exemple, pour le format audio AC-3 dans une application de type home cinema , les canaux stéréo seront privilégiés par rapport aux canaux arrière. De manière préférentielle, seront sélectionnés les canaux selon l'information de perte reçue (en général, il s'agit des canaux avec la perte la plus importante). La table de routage (ou d'aiguillage) est alors mise à jour dans une étape 950. Si test de l'étape 910 est négatif, une étape 913 permet de tester s'il y a trop de données reçues pour les éléments transmis sur la porteuse UDP (c'est-à-dire AT_UDP est nettement supérieur à AT_TCP (par exemple 20% supérieur), ce qui correspond au cas (D de la figure 8). Si c'est le cas, une étape 914 permet de diminuer l'émission de données sur la porteuse UDP afin de laisser le temps aux données émises sur la porteuse TCP de parvenir à la tête de tunnel destinataire. Si le test de l'étape 913 est négatif, Ce qui correspond à une émission trop rapide sur les deux porteuses à la fois, ce qui amène le moyen stockage 423 à saturation. Alors dans une étape 915, le débit d'émission global est réduit afin de ne pas engorger le moyen de stockage 423. Dans les deux cas, la table de routage est alors mise à jour dans une étape 950. Si le moyen de stockage 423 n'est pas sur-occupé (test de l'étape 902 négatif), on vérifie (test 903) si le moyen de stockage 423 n'est pas sous-occupé : c'est-à-dire s'il ne lui manque pas trop de données (par exemple, les données exploitables remplissent moins de 90% du moyen de stockage 423). Si le moyen de stockage 423 est sous-occupé (test de l'étape 903 positif), un ensemble d'étapes 920 à 923 est exécuté afin de connaître les causes de cette sous- occupation. Dans une étape 920, les capacités de transmission de la porteuse TCP sont obtenues par obtention de la valeur de la fenêtre de congestion appelée communément CWND (taille de mémoire d'émission en octets), et d'une statistique d'état de la connexion TCP (typiquement selon la norme TCP, en période slow-start indiquant un démarrage ou une reprise après congestion de la connexion, ou selon le mode congestion avoidance en fonctionnement normal sans perte). Une étape 921 permet de déterminer s'il y a une congestion sur la porteuse TCP (par exemple par analyse des retransmissions opérées sur la porteuse TCP). Si une congestion a lieu sur TCP (étape 921), une étape 922 va dérouter des canaux 553 de la porteuse TCP vers la porteuse UDP. A partir de la capacité d'envoi disponible par l'information CWND, et de la taille individuelle de chaque élément 553, on connaît le nombre maximal d'éléments 553 pouvant être émis. Selon les mêmes critères d'importance des canaux du flux applicatifs que ceux cités à l'étape 912, on choisit les canaux à envoyer sur la porteuse UDP (donc en mode non fiable). Comme le rétablissement de la connexion TCP sur la section WAN prend du temps (en fonction du RTT entre les deux réseaux distants), la table de routage (ou d'aiguillage) 980 peut la aussi être mise à jour car la situation est durable.

Si le taux de perte Pi est important (supérieur à un seuil prédéterminé), on peut être amené à ne plus véhiculer sur le tunnel certains des canaux (par exemple les moins prioritaires 5 ou 6, dont la table de routage indiquerait 0% pour TCP et 60% pour UDP, on a choisit de perdre 40 % des données de ces canaux 553). S'il n'y a pas de congestion sur la porteuse TCP, l'étape 923 consiste à conserver le routage par défaut des canaux sur TCP et à dupliquer certains de ces canaux (sélection identique à l'étape 922) sur la porteuse UDP. Car en principe, une émission sur la porteuse UDP est plus rapide et cela peut permettre de combler progressivement le manque de données présentes dans le moyen de stockage 423. Si le nombre d'éléments 710 exploitables est correct (bon remplissage des informations en provenance de la porteuse TCP selon le remplissage nominal souhaité) dans le moyen de stockage 423 (test 903 négatif), cela signifie que les données véhiculées par la porteuse TCP sont transmises de manière adaptée à la situation de transmission courante. Alors, une étape 904 permet de vérifier si les données véhiculées via la porteuse UDP sont elles aussi correctement transmises. Ainsi, une sous-charge de la porteuse UDP (test positif à l'étape 904) est révélatrice d'un taux de perte plus important que précédemment. C'est pourquoi, dans une étape 908, est tenté, dans la limite des possibilités de transport de la porteuse TCP (c'est-à-dire sa fenêtre CWND), de dérouter les canaux les plus atteints par les pertes (information Pi) sur la porteuse TCP. Si le test de l'étape 904 est négatif, on est alors dans le cas révélateur d'une bonne transmission globale (sur les deux porteuses du tunnel), et il n'y a pas lieu d'avoir d'action corrective sur la table de routage 980. Dans ce cas, une étape 905 permet de vérifier si des canaux 553 avaient au préalable été omis de la transmission vers la tête de tunnel distante. Si c'est le cas, une étape 907 réinsère progressivement ces canaux omis sur les deux porteuses selon leur degré de criticité (en principe, il n'y a majoritairement que des canaux applicatifs non prioritaires qui n'ont pas été transmis, et donc la réinsertion se réalise sur la porteuse UDP). Sinon, dans une étape 906, des canaux sont progressivement déroutés de la porteuse UDP vers la porteuse TCP afin de charger au maximum la porteuse TCP qui assure un transport fiabilisé des données, et ce jusqu'à ce qu'un prochain rapport avertisse d'une éventuelle surcharge de la porteuse TCP. La figure 10 illustre schématiquement un dispositif selon un mode de réalisation particulier de l'invention. Un appareil mettant en oeuvre l'invention est par exemple un dispositif de communication générique 1000.

Par exemple, la tête de tunnel 101 ou 102 précitée en relation avec la figure 1 est identique au dispositif générique 1000. Ce dispositif générique 1000 peut notamment être connecté à tout moyen de stockage d'image, de vidéos, ou de sons reliés à une carte graphique et délivrant au dispositif générique 1000 des données multimédia.

Ainsi, le dispositif générique 1000 comporte un bus de communication 1002 auquel sont reliés : - une unité centrale de traitement 1003 (qui est par exemple un microprocesseur référencé CPU pour Central Processor Unit en anglais) ; - une mémoire morte 1004 référencée ROM (pour Read Only Memory en anglais), pouvant comporter le ou les programme(s) précité(s) et référencé(s) Prog ; - une mémoire vive 1006 (mémoire cache référencée RAM pour Random Access Memory en anglais), comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités. - une interface de communication 1018 reliée à au moins deux réseaux de communication 1020, par exemple le réseau local 103/104 et l'Internet 107, l'interface étant apte à transmettre et à recevoir des données avec ces réseaux. Le dispositif générique 1000 comprend également (mais ceci est optionnel) : - un écran 1008 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 1010 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 1011 ou un crayon optique, - un disque dur 1012 pouvant comporter le ou les programmes "Prog" précités.

Le bus de communication 1002 permet la communication et l'interopérabilité entre les différents dispositifs inclus dans le dispositif générique 1000 ou reliés à cet équipement. De manière plus générale, grâce au bus de communication 1002, l'unité centrale 1003 est susceptible de communiquer des instructions à tout dispositif inclus dans le dispositif générique 10200 directement ou par l'intermédiaire d'un autre dispositif du dispositif générique 1000. Le code exécutable de chacun du ou des programme(s) précités permettant au dispositif générique 1000 de mettre en oeuvre les procédés selon l'invention, peut être stocké, par exemple, dans le disque dur 1012 ou dans la mémoire morte 1004.

L'unité centrale 1003 commande et dirige l'exécution des instructions ou portions de code exécutable du ou des programme(s) selon l'invention. Lors de la mise sous tension, le ou les programme(s) qui sont stockés dans une mémoire non volatile (par exemple le disque dur 1012 ou la mémoire morte 1004), sont transférés dans la mémoire vive 1006 qui contiendra alors le code exécutable du ou des programme(s) selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre des procédés selon l'invention. Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC).

Claims (15)

1. REVENDICATIONS1. Procédé de transmission d'un flux de données multi-canal (401) comprenant des trames comprenant une pluralité de canaux, la transmission étant effectuée via un tunnel multi-transport (100) depuis une première tête de tunnel (101) vers une seconde tête de tunnel (102), ledit tunnel mettant en oeuvre une première porteuse (100A) supportant un protocole de transport avec acquittement et une seconde porteuse (100B) supportant un protocole de transport sans acquittement, caractérisé en ce la première tête de tunnel effectue des étapes consistant à, pour une trame donnée dudit flux : obtenir (900) au moins une information relative à des quantités de données dudit flux de données multi-canal reçues par la seconde tête de tunnel ; - aiguiller les canaux d'une trame dudit flux de données multi-canal reçue par la première tête de tunnel vers l'une desdites porteuses du tunnel, en fonction de ladite au moins une information obtenue ; - associer une même information de synchronisation (621) auxdits canaux ; 15 - transmettre vers la seconde tête de tunnel (102) chacun des canaux de ladite trame donnée via la porteuse vers laquelle ledit canal a été aiguillé, ainsi que leur information de synchronisation associée.
2. 2. Procédé selon la revendication 1, caractérisé en ce que l'information de synchronisation associée à un canal est une information d'horodatage extraite 20 dudit flux de données multi-canal (401).
3. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que la première tête de tunnel effectue une étape consistant à : - obtenir (900) au moins une information relative à une information de congestion de la première porteuse (100A) ; 25 et en ce que ladite étape consistant à aiguiller chacun des canaux est également fonction de ladite information de congestion obtenue.
4. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite ou lesdites information(s) relative(s) à des quantités de données duditflux de données multi-canal reçues par la seconde tête de tunnel appartient (appartiennent) au groupe comprenant : * des informations relatives à une occupation d'une mémoire en réception (423) comprise dans ladite seconde tête de tunnel (102) ; * des informations relatives à un taux de perte de données dudit flux transmises sur ladite au moins une seconde porteuse (100B).
5. 5. Procédé selon la revendication 4, caractérisé en ce que les informations relatives à une occupation d'une mémoire tampon de réception appartiennent au groupe comprenant : - une première information de différence (AT_TCP) entre une valeur instantanée de remplissage et une valeur de référence (Tnom) de remplissage, le remplissage faisant référence à une partie de ladite mémoire en réception associée à la réception de données en provenance de la première porteuse ; une seconde information de différence (AT_UDP) entre une valeur instantanée de remplissage et une valeur de référence (Tnom) de remplissage, le remplissage faisant référence à une partie de ladite mémoire en réception associée à la réception de données en provenance de la seconde porteuse ; une troisième information de différence (AT) entre un nombre (Tutile) de données utiles dudit flux de données multi-canal et une valeur de référence (Tnom) de remplissage, une donnée utile étant une trame disposant de canaux présents dans une partie de ladite mémoire en réception associée à la réception de données en provenance de la première porteuse ainsi que de canaux présents dans une partie de ladite mémoire en réception associée à la réception de données en provenance de la seconde porteuse.
6. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comprend une étape parmi le groupe d'étapes consistant à :10 15 20 25 39 si la troisième information de différence est positive, et si la première information de différence est supérieure d'au moins un premier écart prédéterminé par rapport à la seconde information de différence, aiguiller vers la première porteuse un nombre de canaux d'une trame courante supérieur à un nombre de canaux d'une trame précédente aiguillés vers ladite première porteuse ; si la troisième information de différence est positive, et si la première information de différence n' est pas supérieure d'au moins ledit premier écart prédéterminé par rapport à la seconde information de différence, aiguiller certains canaux d'une trame courante vers aucune desdites première et seconde porteuses ; si la troisième information de différence est négative, si la première information de différence est supérieure à une portion prédéfinie de ladite valeur de référence, et si une congestion de la première porteuse est détectée, aiguiller vers la première porteuse un nombre de canaux d'une trame courante inférieur à un nombre de canaux d'une trame précédente aiguillés vers ladite première porteuse ; si la troisième information de différence est négative, si la première information de différence est supérieure à une portion prédéfinie de ladite valeur de référence, et si aucune congestion de la première porteuse est détectée, aiguiller vers la première et la seconde porteuse des canaux d'une trame courante qui étaient aiguillés pour une trame précédente uniquement vers ladite première porteuse ; si la troisième information de différence est négative, si la seconde information de différence est supérieure à une portion prédéfinie de ladite valeur de référence, aiguiller vers la première porteuse un nombre de canaux d'une trame courante supérieur à un nombre de canaux d'une trame précédente aiguillés vers ladite première porteuse.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la première tête de tunnel effectue une étape consistant à : - associer une information de priorité à chacun des canaux, en fonction d'un profil prédéterminé d'une application véhiculée par ledit flux ; et en ce que ladite étape consistant à aiguiller chacun des canaux est également fonction des informations de priorité associées aux canaux.
8. 8. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 7, lorsque ledit programme est exécuté sur un ordinateur.
9. 9. Moyen de stockage lisible par ordinateur, éventuellement totalement ou partiellement amovible, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé de selon au moins une des revendications 1 à 7.
10. 10. Première tête de tunnel participant à une transmission d'un flux de données multi-canal (401) comprenant des trames comprenant une pluralité de canaux, la transmission étant effectuée via un tunnel multi-transport (100) depuis une première tête de tunnel (101) vers une seconde tête de tunnel (102), ledit tunnel mettant en oeuvre une première porteuse (100A) supportant un protocole de transport avec acquittement et une seconde porteuse (100B) supportant un protocole de transport sans acquittement, ladite première tête de tunnel étant caractérisée en ce qu'elle comprend : des moyens d'obtention d'au moins une information relative à des quantités de données dudit flux de données multi-canal reçues par la seconde tête de tunnel ; - des moyens d'aiguillage desdits canaux d'une trame dudit flux de données multi-canal reçue par la première tête de tunnel vers l'une desdites porteuses du tunnel, en fonction de ladite au moins une information obtenue ;- des moyens d'association d'une même information de synchronisation (621) auxdits canaux ; - des moyens de transmission vers la seconde tête de tunnel (102) de chacun des canaux de ladite trame donnée via la porteuse vers laquelle ledit canal a été aiguillé, ainsi que leur information de synchronisation associée.
11. 11. Première tête de tunnel selon la revendication 10, caractérisé en ce que l'information de synchronisation associée à un canal est une information d'horodatage extraite dudit flux de données multi-canal (401).
12. 12. Première tête de tunnel selon l'une quelconque des revendications 10 et 11, caractérisé en ce qu'elle comprend des moyens d'obtention d'au moins une information relative à une information de congestion de la première porteuse (100A).
13. 13. Première tête de tunnel selon l'une quelconque des revendications 10 à 12, caractérisé en ce que ladite ou lesdites information(s) relative(s) à des quantités de données dudit flux de données multi-canal reçues par la seconde tête de tunnel appartient (appartiennent) au groupe comprenant : * des informations relatives à une occupation d'une mémoire en réception (423) comprise dans ladite seconde tête de tunnel (102) ; * des informations relatives à un taux de perte de données dudit flux transmises sur ladite au moins une seconde porteuse (100B).
14. 14. Première tête de tunnel selon la revendication 13, caractérisé en ce que les informations relatives à une occupation d'une mémoire tampon de réception appartiennent au groupe comprenant : une première information de différence (AT_TCP) entre une valeur instantanée de remplissage et une valeur de référence (Tnom) de remplissage, le remplissage faisant référence à une partie de ladite mémoire en réception associée à la réception de données en provenance de la première porteuse ;une seconde information de différence (AT_UDP) entre une valeur instantanée de remplissage et une valeur de référence (Tnom) de remplissage, le remplissage faisant référence à une partie de ladite mémoire en réception associée à la réception de données en provenance de la seconde porteuse ; une troisième information de différence (AT) entre un nombre (Tutile) de données utiles dudit flux de données multi-canal et une valeur de référence (Tnom) de remplissage, une donnée utile étant une trame disposant de canaux présents dans une partie de ladite mémoire en réception associée à la réception de données en provenance de la première porteuse ainsi que de canaux présents dans une partie de ladite mémoire en réception associée à la réception de données en provenance de la seconde porteuse.
15. 15. Première tête de tunnel selon l'une quelconque des revendications 10 à 14, caractérisé en ce qu'elle comprend des moyens d'association d'une information de priorité à chacun des canaux, en fonction d'un profil prédéterminé d'une application véhiculée par ledit flux. et en ce que lesdits moyens d'aiguillage de chacun des canaux prend en compte également ces informations de priorité associées aux canaux.