FR2939993A1 - 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 au moins une première porteuse (431) supportant un protocole de transport avec acquittement et au moins une seconde porteuse (432) supportant un protocole de transport sans acquittement. Plus précisément, l'invention propose d'introduire un retard à l'émission de données ("de haute importance") via la première porteuse par rapport à l'émission de données (« de plus faible importance ») via la première porteuse. Ainsi, l'invention permet de garantir l'ordre d'arrivée de canaux associés à une même information de synchronisation mais transmis sur des première et seconde porteuses distinctes et issus de la séparation d'une même trame de données multi-canal.

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 multi-transport permettant, tout en conservant une latence minimale, de garantir une transmission d'un flux de données multi-canal avec une qualité minimale garantie en cas de congestion temporaire sur Internet. 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 franaç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 de l'IETF (pour Internet Engineering Task Force ) 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. En particulier, la gigue (ou jitter en anglais) qui décrit la variation du temps de transmission d'une trame, ainsi que le taux de perte (qui décrit le nombre de trames perdues lors de la transmission), sont deux paramètres très fortement perturbés sur Internet en cas de congestion du réseau 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. Depuis peu, 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 une latence faible et avec un minimum d'erreur ou de perte.

Or lors d'une congestion sur le réseau Internet, les routeurs intermédiaires peuvent décider de supprimer certains paquets en transit afin de réduire la congestion et il est impossible de prévoir quels seront les paquets supprimés, et ceux effectivement transmis. Ceci peut avoir un réel impact négatif sur la restitution sonore.

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 le faire 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, norme RFC-2661) permettant la création de tunnel de "niveau 2", et supportant des sessions établies au niveau des couches 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). Il n'existe pas de système de transport à travers un tunnel permettant tout en conservant une latence minimale, de garantir une transmission d'un flux multi-canal avec une qualité minimale garantie en cas de congestion temporaire sur Internet. 2. ARRIÈRE-PLAN TECHNOLOGIQUE L'état de la technique le plus proche de l'invention, concerne un système de synchronisation de flux multimédia en temps réel. Un document de brevet EP 1775964 Al (Huawei Technologies Co. Ltd. Method and device for stream synchronization of real-time multimedia transport over packet network ) décrit un tel système de l'état de la technique. Ce document de brevet présente une solution pour synchroniser deux flux multimédia (en l'occurrence, un flux audio et un flux vidéo) qui transitent via Internet.

La solution proposée repose sur l'ajout de deux tampons mémoire de réception (ou biffer en anglais), un pour le flux audio, et un pour le flux vidéo. L'invention présentée dans ce brevet permet une évaluation dynamique de la taille de ces tampons. Pour ce faire, l'invention évalue le temps de transfert de chaque flux (par différence entre l'instant d'émission et l'instant de réception, et en déduit une différence de temps de transfert. Cette différence est alors utilisée pour définir la taille des différents tampons.

Cependant, cette technique présente plusieurs inconvénients. Un premier inconvénient réside dans le fait que le mécanisme décrit dans ce document utilise deux tampons mémoire (ou buffers ) de taille variable, ce qui nécessite un espace de stockage temporaire pour la gestion de ces tampons assez important. Un deuxième inconvénient réside dans le fait que la solution décrite dans ce document nécessite la mise en oeuvre d'un stockage temporaire systématique de toutes les trames reçues. Celui-ci induit alors l'ajout d'une latence supplémentaire à celle inévitablement induite par la traversée d'Internet Un troisième inconvénient réside dans le fait que la mesure de la différence de temps de propagation est effectuée par la différence des temps de propagation moyens mesurés pour chaque flux (par différence entre l'instant d'émission et l'instant de réception). Cette technique nécessite la transmission d'un horodatage (ou timestamp en anglais) généralement codé sur 4 octets, introduisant ainsi un surdébit (ou overhead en anglais) supplémentaire. 3. OBJECTIFS DE L'INVENTION Dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de transmission d'un flux multi-canal synchronisé permettant, en cas de congestion sur un réseau présent sur un chemin emprunté (tel que le réseau Internet) de garantir la transmission des données importantes pour restitution d'un flux multi-canal au dépend de données moins importantes. Ce mécanisme permet d'obtenir une restitution du flux multi-canal avec une qualité supérieure aux systèmes de l'état de l'art, tout en garantissant une latence minimale. Cette méthode sera plus précisément décrite dans le cadre d'une application multi-canal audio, mais est applicable à tout flux mufti- 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 dont la consommation de ressources de stockage temporaire est très faible. 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 au moins une première porteuse supportant un protocole de transport avec acquittement et au moins une seconde porteuse supportant un protocole de transport sans acquittement. Ce procédé est remarquable en ce qu'il est mis en oeuvre par la première tête de tunnel effectuant des étapes consistant à : - 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 d'au moins un critère d'aiguillage prédéterminé ; - associer une même information de synchronisation auxdits canaux ; - obtenir une première information de rétroaction représentative d'une gigue relative de transmission entre lesdites première et seconde porteuses ; - appliquer un retard avant transmission sur la première porteuse desdits canaux aiguillés vers la première porteuse, ledit retard étant déterminé en fonction de ladite première information de rétroaction. Ce procédé de transmission repose sur l'hypothèse que le temps de transmission de données émises sur une première porteuse supportant un protocole de transport avec acquittement est plus long que le temps de transmission de données émises sur une seconde porteuse supportant un protocole de transport sans acquittement. Cette hypothèse est d'autant plus vraie en période de congestion. Toutefois, pour garantir que cette hypothèse de base est toujours vraie, l'invention repose sur une approche tout à fait nouvelle et inventive consistant à introduire un retard à l'émission de données ("de haute importance") via la première porteuse par rapport à l'émission de données ("de plus faible importance ) via la première porteuse, ces données devant être restituées de manière synchronisée malgré des chemins empruntés et des protocoles de transfert différents. La présente invention permet alors de garantir l'ordre d'arrivée de canaux associés à une même information de synchronisation mais transmis sur des première et seconde porteuses distinctes et issus de la séparation d'une même trame de données multi-canal.

Ainsi, en cas de congestion sur un réseau emprunté par la transmission du flux de données, tel qu'Internet par exemple, la présente invention permet notamment de garantir la transmission des données importantes pour restitution d'un flux multi-canal au dépend de données moins importantes transmises sur la seconde porteuse.

Egalement, grâce à ce retard appliqué sur chaque canal transporté au moyen de la première porteuse, ce procédé permet, sur réception par un module récepteur (de la seconde tête de tunnel) des canaux transmis sur les premières et secondes porteuses, de s'affranchir d'un stockage temporaire systématique des canaux reçus sur la première porteuse. La latence s'en trouve donc diminuée.

En effet, comme détaillé par la suite, dans le module récepteur, un stockage temporaire est effectué seulement sur les canaux reçus sur la seconde porteuse. De façon avantageuse, ladite première information de rétroaction est une information de délai entre un instant de réception par la seconde tête de tunnel via la seconde porteuse d'un premier ensemble de canaux et un instant de réception par la seconde tête de tunnel via la première porteuse d'au moins un second ensemble de canaux, les canaux desdits premier et second ensembles étant associés à une même information de synchronisation. Ainsi, la première tête de tunnel peut ajuster dynamiquement le retard appliqué aux canaux transmis sur la première porteuse de façon à garantir que ces canaux soient reçus après les canaux associés à une même information de synchronisation qui sont transmis sur la seconde porteuse, pour ensuite reconstituer le flux de données multicanal côté récepteur (seconde tête de tunnel). Dans une variante, la première information de rétroaction est relative à une gigue mesurée indépendamment des canaux qui sont reçus par la seconde tête de tunnel. Par exemple, la gigue est mesurée par une passerelle. Avantageusement, si ledit délai est supérieur à un seuil prédéterminé, le retard avant transmission à appliquer est nul et si le délai est inférieur ou égal audit seuil prédéterminé, le retard avant transmission à appliquer est égal à la somme de la valeur absolue dudit délai et dudit seuil prédéterminé.

Ainsi, on garantit de manière simple et systématique un retard minimum entre les canaux transmis sur les première et seconde porteuses, permettant ainsi de toujours respecter l'hypothèse selon laquelle le temps de transmission de données émises sur une première porteuse supportant un protocole de transport avec acquittement est plus long que le temps de transmission de données émises sur une seconde porteuse supportant un protocole de transport sans acquittement. Selon un mode de mise en oeuvre avantageux de l'invention, ce procédé comprend en outre des étapes consistant à : - obtenir une seconde information de rétroaction représentative d'un taux de perte sur la seconde porteuse ou d'un taux de retransmission sur la première porteuse ; - supprimer des trames aiguillées vers la seconde porteuse, en fonction de ladite seconde information de rétroaction. Ainsi, on favorise l'émission des données importantes au détriment des données moins importantes, afin de limiter l'impact de la congestion sur la restitution ultérieure du flux de données. Selon une caractéristique avantageuse de l'invention, l'information de synchronisation associée à un canal est une information d'horodatage extraite dudit flux de données multi-canal.

Ainsi, en utilisant des données d'horodatage déjà existantes, il n'est pas nécessaire d'introduire de nouvelles données. La bande passante et le temps de traitement à l'émission des données s'en trouve améliorée. L'invention concerne également 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 au moins une première porteuse supportant un protocole de transport avec acquittement et au moins une seconde porteuse supportant un protocole de transport sans acquittement. Ce procédé est remarquable en ce qu'il est mis en oeuvre par la seconde tête de tunnel effectuant des étapes consistant à : - recevoir, via les première et seconde porteuses, des canaux dudit flux de données multi-canal ainsi que des informations de synchronisation associées auxdits canaux, les canaux d'une même trame dudit flux de données multi-canal étant associés à une même information de synchronisation ; - stocker dans une mémoire tampon les canaux et les informations de synchronisation reçus via la seconde porteuse ; - et sur réception, via la première porteuse, d'un premier ensemble de canaux associés à une information de synchronisation donnée : * extraire de ladite mémoire tampon un second ensemble de canaux associés à ladite information de synchronisation donnée ; * reconstruction d'une trame dudit flux de données multi-canal, à partir desdits premier et second ensembles.

Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive consistant à cadencer, par la première porteuse, l'envoi de données importantes vers la seconde tête de tunnel. Ce cadencement associé à l'information de synchronisation permet de s'affranchir d'un stockage temporaire systématique à la réception des canaux transmis sur la première porteuse. La latence s'en trouve donc diminuée. La présente invention permet donc de s'affranchir d'un espace de stockage temporaire supplémentaire sur la seconde tête de tunnel. Avantageusement, ce procédé comprend des étapes consistant à : - déterminer une première information de rétroaction représentative d'une gigue relative de transmission entre lesdites première et seconde porteuses ; - transmettre ladite première information de rétroaction à ladite première tête de tunnel. Ainsi, la première tête de tunnel est renseignée en permanence de la gigue entre la première et la seconde porteuse. En fonction de cette gigue, la première tête de tunnel ajuste dynamiquement le retard des canaux transmis sur la première porteuse par rapport aux canaux de la seconde porteuse de façon à garantir que les canaux transmis sur la première porteuse soient reçus après les canaux associés à un même information de synchronisation et qui sont transmis sur la seconde porteuse. De façon avantageuse, ladite première information de rétroaction est une information sur un délai entre un instant de réception par la seconde tête de tunnel dudit premier ensemble de canaux et un instant de réception par la seconde tête de tunnel dudit second ensemble de canaux. Ainsi, en fonction de la valeur de l'écart temporel obtenu entre les canaux reçus via la première porteuse et les canaux reçus via la seconde porteuse (et associés à une même information de synchronisation), la première tête de tunnel ajuste dynamiquement le retard entre les canaux transmis sur la première porteuse et les canaux transmis sur la seconde porteuse (et associés à une même information de synchronisation), de façon à garantir que les canaux transmis sur la première porteuse soient réceptionnés après les canaux transmis sur la seconde porteuse (pour des canaux de même information de synchronisation). Selon une autre caractéristique particulière, ce procédé comprend en outre des étapes consistant à : - déterminer une seconde information de rétroaction relative à un taux de perte sur la seconde porteuse par comparaison d'un nombre de portions de trame du flux multi-canal reçues via la première porteuse et un nombre de portions de trame du flux multi-canal reçues via la seconde porteuse ; - transmettre ladite seconde information de rétroaction à ladite première tête de tunnel. Ainsi, on permet à la première tête de tunnel, en fonction de cette seconde information de synchronisation, de supprimer certains canaux devant être transmis sur la seconde porteuse afin de limiter le débit sur le tunnel et d'accélérer la résorption de la congestion (dont dépend le taux de perte).

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 au moins une première porteuse supportant un protocole de transport avec acquittement et au moins 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 pour 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 d'au moins un critère d'aiguillage prédéterminé ; - des moyens d'association d'une même information de synchronisation auxdits canaux ; - des moyens d'obtention d'une première information de rétroaction représentative d'une gigue relative de transmission entre les première et seconde porteuses ; - des moyens d'application d'un retard avant transmission sur la première porteuse desdits canaux aiguillés vers la première porteuse, ledit retard étant déterminé en fonction de ladite première information de rétroaction. De manière avantageuse, ladite première information de rétroaction est une information de délai entre un instant de réception par la seconde tête de tunnel via la seconde porteuse d'un premier ensemble de canaux et un instant de réception par la seconde tête de tunnel via la première porteuse d'au moins un second ensemble de canaux, les canaux desdits premier et second ensembles étant associés à une même information de synchronisation. Avantageusement, la première tête de tunnel comprend des moyens de comparaison dudit délai (Rr) à un seuil prédéterminé et permettant auxdits moyens d'application d'un retard : de ne pas appliquer un retard avant transmission, si ledit délai (Rr) est supérieur audit seuil prédéterminé ; d'appliquer un retard avant transmission égal à la somme de la valeur absolue dudit délai (Rr) et dudit seuil prédéterminé, si le délai (Rr) est inférieur ou égal audit seuil prédéterminé. De manière intéressante, la première tête de tunnel comprend en outre : - des moyens d'obtention d'une seconde information de rétroaction représentative d'un taux de perte sur la seconde porteuse ou d'un taux de retransmission sur la première porteuse ; - des moyens de suppression des trames aiguillées vers la seconde porteuse en fonction de ladite seconde information de rétroaction.

Suivant une autre caractéristique, l'information de synchronisation associée à un canal est une information d'horodatage extraite dudit flux de données multi-canal. L'invention concerne également une seconde 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 au moins une première porteuse supportant un protocole de transport avec acquittement et au moins une seconde porteuse supportant un protocole de transport sans acquittement.

Selon l'invention, la seconde tête de tunnel est remarquable en ce qu'elle comprend : - des moyens de réception, via les première et seconde porteuses, des canaux dudit flux de données multi-canal ainsi que des informations de synchronisation associées auxdits canaux, les canaux d'une même trame dudit flux de données multi-canal étant associés à une même information de synchronisation ; - des moyens de stockage permettant de stocker, dans une mémoire tampon, les canaux et les informations de synchronisation reçus via la seconde porteuse; - des moyens d'extraction de ladite mémoire tampon d'un second ensemble de canaux associés à ladite information de synchronisation donnée , sur réception, via la première porteuse, d'un premier ensemble de canaux associés à une information de synchronisation donnée ; - des moyens de reconstruction d'une trame dudit flux de données multi-canal, à partir desdits premier et second ensembles. Selon un mode de réalisation de l'invention, la seconde tête de tunnel comprend : - des moyens de détermination d'une première information de rétroaction représentative d'une gigue relative de transmission entre lesdites première et seconde porteuses ; - des moyens de transmission de ladite première information de rétroaction à ladite première tête de tunnel.

Avantageusement, ladite première information de rétroaction est une information sur un délai entre un instant de réception par la seconde tête de tunnel dudit premier ensemble de canaux et un instant de réception par la seconde tête de tunnel dudit second ensemble de canaux..

De manière avantageuse, la seconde tête de tunnel comprend en outre : - des moyens de détermination d'une seconde information de rétroaction relative à un taux de perte sur la seconde porteuse par comparaison d'un nombre de portions de trame du flux multi-canal reçues via la première porteuse et un nombre de portions de trame du flux multi-canal reçues via la seconde porteuse ; - des moyens de transmission de ladite seconde information de rétroaction à ladite première tête de tunnel. 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 typique d'un réseau privé virtuel (VPN) mettant en oeuvre un tunnel de communication entre deux réseaux locaux ; - 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és par les mécanismes de la présente invention, selon un mode de réalisation particulier de l'invention ; - la figure 6 est une vue schématique illustrant une structure de données selon un mode de réalisation particulier de l'invention ; - la figure 7 est une vue schématique lors de l'émission d'une trame sur le réseau WAN (tel qu'Internet) selon un mode de réalisation particulier de l'invention ; - la figure 8 est une vue schématique lors de la réception d'une trame en provenance du réseau WAN selon un mode de réalisation particulier de l'invention ; - la figure 9 est une vue schématique lors de la réception d'une trame de rétroaction selon un mode de réalisation particulier de l'invention ; - la figure 10 est une vue schématique d'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 Personnal 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. Pour la mise en oeuvre de l'invention, un module optimisé pour le transport des flux multi-canal 114 ou 115 est respectivement ajouté dans les têtes de tunnel 101 ou 102.

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 la mise en oeuvre de l'invention au sein des modules de transport multi-canal 114 et 115 de la figure 1.

Elle illustre la mise en oeuvre d'un module émetteur 410 et d'un module récepteur 420 reliés entre eux par un tunnel utilisant deux porteuses de nature différentes, c'est-à-dire une porteuse 431 disposant d'un protocole de transport avec acquittement (que l'on appellera par la suite porteuse fiable ) qui peut être par exemple TCP, et une porteuse 432 disposant d'un protocole de transport sans acquittement (que l'on appellera par la suite porteuse non fiable ) qui peut être par exemple 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 par 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 ). Pour expliquer un mode de réalisation particulier de l'invention, cette figure 4 sera décrite dans le cadre d'un scénario dans lequel un flux de données multi-canal constitué de trames de flux multi-canal 401 (par exemple, des trames RTP d'un flux audio 5.1) est émis par l'équipement émetteur 109 connecté au LAN 103 de la figure 1 et à destination de l'équipement récepteur 112 connecté au LAN 104 de la figure 1. On prendra bien soin de ne pas confondre les trames de flux de niveau supérieur à 4 (niveau transport) du modèle OSI, avec des trames de transport TCP ou UDP de niveau 4. En effet, une trame de flux peut être fragmentée et transportée par plusieurs trames de transport . Dans le cadre de ce scénario, chaque trame de flux multi-canal 401 est reçue par un module démultiplexeur de canaux 411 qui va ensuite les analyser. Les différentes parties de la trame de flux correspondant aux différents canaux du flux multi-canal 401 vont être présentées à un module de routage des canaux 412 grâce au module démultiplexeur de canaux 411. Notamment, ce module démultiplexeur de canaux 411 présente chaque bloc de données audio 553 (ces blocs de données seront plus amplement décrits en relation avec la figure 5) au module de routage 412 en indiquant pour chacun le numéro du canal audio auquel il est associé. Il est à noter que la réception d'une trame de flux peut nécessiter le stockage temporaire de plusieurs trames de transport dans le cas où la taille d'une trame de flux serait trop importante pour être transportée par une seule trame de transport (c'est le cas par exemple de certains flux de haute définition). Une trame de flux 401 serait alors fragmentée sur plusieurs trames de transport sur le réseau LAN. En plus des informations concernant les blocs audio, le module démultiplexeur de canaux 411 fournit les entêtes IP, UDP, et RTP de la première trame de transport reçue parmi les trames utilisées sur le réseau LAN pour transporter les différents fragments de la trame de flux courante. Ces informations que l'on dénommera par la suite sous le terme de informations de flux seront précieuses pour un module régénérateur de trames 423 lors de la transmission de la trame RTP régénérée à destination de l'équipement récepteur 112 connecté au LAN 104 de la figure 1. Selon un mode de réalisation particulier de l'invention, le module de routage de canaux 412 utilise, par exemple, une table statique 640 telle que présente sur la figure 6 (plus amplement décrite dans la suite de la description). Grâce à cette table, le module de routage 412 détermine s'il est important qu'un canal donné du flux multicanal soit transmis sans perte. Si c'est le cas, les informations de ce canal seront transportées via un tunnel avec retransmission sur une porteuse fiable 431 (avec acquittement et retransmission si nécessaire, comme TCP par exemple). Sinon, c'est-à-dire la transmission d'un canal donné du flux multi-canal peut subir des pertes, celle-ci est effectuée sur une porteuse non fiable 432 (sans acquittement ni retransmission, comme UDP par exemple). Cet algorithme est plus amplement décrit par la suite en relation avec la figure 7A.

En sortie du module de routage 412, et pour une retransmission sur une porteuse fiable 431, un empaqueteur 413 fabrique une trame 610 telle que décrite en relation avec la figure 6. Cette trame 610 peut éventuellement être encryptée si l'utilisateur souhaite une transmission sécurisée. En sortie du module de routage 412 et après passage dans un sélecteur 416 (plus amplement décrit par la suite), pour une retransmission sur une porteuse non fiable 432, un empaqueteur 417 fabrique une trame 620 telle que décrite en relation avec la figure 6. Cette trame peut éventuellement être encryptée si l'utilisateur souhaite une transmission sécurisée, puis l'émet sur la porteuse non fiable 432. Les mécanismes des modules 416 et 417 seront décrits plus en détail en relation avec la figure 7C.

Puis un retardateur 414 temporise, puis envoie (sur la porteuse fiable 431, par exemple TCP) la trame 610 fabriquée par l'empaqueteur 413 afin de garantir que la réception de la trame 610 par la tête de tunnel distante 102 interviendra après la réception d'une trame 620 de même index de synchronisation (cette trame 620 ainsi que l'index de synchronisation est plus amplement décrit dans la suite de la description). La valeur de l'éventuel retard à appliquer par le retardateur 414 est fournie par un moteur de décision 415 dont le fonctionnement est plus amplement décrit par la suite. Les mécanismes des modules 413 et 414 seront décrits plus en détail en relation avec la figure 7B.

Selon un mode de réalisation particulier de l'invention, un sélecteur 416 utilise le taux de suppression fourni par le moteur de décision 415 afin de supprimer certaines trames 620 qui auraient dû être transmises via la porteuse non fiable, afin de limiter le débit sur le lien Internet, et ainsi accélérer la résorption de la congestion, lorsqu'une telle congestion est détectée. Selon une caractéristique de l'invention, le moteur de décision 415 reçoit les trames 630 émises par un ordonnanceur 422 du module de réception 420. En utilisant les informations de gigue et de taux de perte contenues dans la trame 630, le moteur de décision 415 détermine les nouvelles valeurs du retard à appliquer par le retardateur 414, et du taux de suppression à prendre en compte par le sélecteur 416. Du côté du module récepteur 420, les trames reçues sur la porteuse non fiable 432 sont stockées dans un tampon de synchronisation 421 dont la structure 600 est décrite en relation avec la figure 6. Les trames reçues sur la porteuse fiable 431 sont quant à elle envoyées à l'ordonnanceur 422. Cet ordonnanceur a deux rôles importants. Le premier est de récupérer, pour chaque trame 610 reçue, la trame 620 correspondante dans le tampon de synchronisation 421 (c'est-à-dire une trame de même index de synchronisation), et de nettoyer le tampon de synchronisation 421 des trames 620 périmées. L'autre rôle de l'ordonnanceur 422 concerne la rétroaction. En effet, l'ordonnanceur 422 est en charge de la détermination d'un taux de perte Tp sur la porteuse non fiable (c'est-à-dire le taux de trames 620 perdues), ainsi que du retard de transmission Rt (c'est-à-dire la gigue relative des deux porteuses). Enfin, l'ordonnanceur 422 génère une trame 630 à destination de la tête de tunnel émettrice 101. Le fonctionnement du tampon de synchronisation 421 et de l'ordonnanceur 422 est décrit plus précisément en relation avec la figure 8. Les deux trames 610 et 620 récupérées par l'ordonnanceur 422 sont ensuite envoyées à un régénérateur de trame RTP 423 possédant deux fonctions. Premièrement, l'ordonnanceur 422 utilise une information de flux 614 (plus amplement décrite par la suite en relation avec la figure 6) de la trame 610 reçue de l'ordonnanceur 422 afin de générer une trame RTP 402 valide à destination de l'équipement récepteur 112. Cette information de flux 614 contient notamment les adresses MAC source et destination, les adresses IP source et destination, le port UDP source et destination, et l'entête RTP.

Deuxièmement, il utilise des blocs audio 615 et éventuellement 624 (figure 6) respectivement transportés par les trames 610 et 620 pour régénérer la partie dite utile ( payload en anglais) de la trame RTP 402 régénérée (figure 5). Dans le cas où les blocs de données 624 seraient absents, un module d'insertion de silence 424 insère des données synthétiques (comme par exemple des données représentatives d'un silence) en lieu et place des blocs 624 absents. Evidemment d'autres mécanismes de régénération des blocs de données manquants sont possibles, comme par exemple l'insertion de bruit blanc, ou encore la fabrication des bloc de données par combinaison des blocs correctement reçus. Cette liste présente à titre d'exemple n'est nullement limitative. La figure 5 illustre schématiquement un exemple de flux multi-canal 401 supporté par les mécanismes de l'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 ou COdage-DECodage ) audio AC-3, ou 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 1'ATSC ( Advanced Television Standards Committee ), pour la diffusion en continu (ou streaming en anglais) sur un réseau local par l'alliance DLNA ( Digital Living Network Alliance ) Il existe plusieurs versions d'encodage de type AC-3 : 1.0 (mono) très rare, 2.0 (stéréo), 5.1 (5 canaux pour les haut-parleurs satellites et 1 canal pour le caisson de basse) et la 7.1 (7 canaux 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) . Une enceinte centrale, généralement placée sur ou au-dessus de l'écran, servant à diffuser les dialogues.

Deux pistes audio pour les enceintes avant permettant d'accentuer le contexte sonore provenant de l'enceinte centrale. Deux canaux pour les enceintes arrière, permettant de diffuser les bruits et l'environnement sonore afin de créer une ambiance.

Un canal pour les fréquences basses (caisson de basses) servant à amplifier les effets spéciaux (explosions, tremblement, etc.) (aussi nommé low-frequencyeffects ou LFE) La recommandation RFC-4184 ( RTP Payload for AC-3 ) stipule le format d'encapsulation dans un flux de diffusion selon le protocole RTP. Un format d'une trame RTP 500 véhiculant des trames de données AC-3 est représenté sur la figure 5. 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 de 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), de la norme RFC-2327).

Le flux 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 AC-3. 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'origines (déterminer le nombre de voies utilisées en plus ce celle du caisson de basse). Des informations moins importantes sont aussi transportées, comme la langue, l'heure, le type de service (dialogue, commentaire, musique, etc.). Un ensemble 553 de blocs `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 dans 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 module démultiplexeur de canaux 411 devra recevoir plusieurs paquets RTP avant d'obtenir chacun des canaux du flux multi-canal AC-3. Le module démultiplexeur de canaux 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 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 module 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 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 du régénérateur de trames 423 (1 à 2 fois la valeur du RTT) n'est pas critique à la conversation. Au contraire, la qualité de la conversation dans ce contexte en sera augmentée. La figure 6 illustre les différentes structures des données mise en oeuvre pour l'invention. Une première table 600 décrit une structure adaptée au stockage temporaire des trames UDP 620 reçues par une tête de tunnel. Pour chaque trame 620 reçue, une ligne est ajoutée à la table 600. Cette ligne étant supprimée à réception de la trame 610 possédant le même index de synchronisation. Une colonne 601 contient l'index de synchronisation 623 de la trame 620 reçue.

Une colonne 602 contient un horodatage indiquant à quel instant a été reçue la trame 620. L'horodatage 602 (ou timestamp en anglais) doit être suffisamment précis pour permettre une estimation fine de l'écart de transmission Rt de deux trames (une 610 et une 620) de même index de synchronisation, la trame 610 étant transmise sur le canal TCP 431, et l'autre trame 620 étant transmise sur le canal UDP 432. Typiquement, une précision de l'ordre de la milliseconde peut être suffisante pour une transmission via Internet. Une colonne 603 contient les blocs audio (champ 624) ou un pointeur sur les blocs audio de la trame 620 reçue.

La structure d'une trame de tunnel envoyée par le module 410 sur le canal de transport TCP 431, par exemple par la tête de tunnel 101, est représentée par l'élément 610. Un champ 612 contient l'entête du protocole d'encapsulation du tunnel. Un champ 613 contient un index de synchronisation (typiquement, il peut s'agir d'un compteur incrémenté à chaque réception de trame de flux RTP 401). Cet index doit être le même dans deux trame 610 et 620 transportant les blocs audio d'une même trame RTP de flux 401.

Un champ 614 contient les informations indispensables à la régénération d'une trame de niveau 2 (Ethernet) par le régénérateur RTP 423. Ce champ 614 contient le début de la trame 500 reçue par le module démultiplexeur de canaux 411 jusqu'à l'entête de données utiles RTP 560 incluse.

Un champ 615 contient une partie des données utiles 502 (les blocs audio importants). La trame 610 une fois encapsulée dans une trame TCP est donc une trame de tunnel 260 de niveau 2 classique, mis à part qu'une partie des données utiles (blocs audio) de la trame de flux RTP 401 a été ôtée pour être transmise sur une autre porteuse. Cette suppression d'une partie des blocs audio offre également un avantage puisque cela permet d'éviter la fragmentation au niveau IP de trame 260, le surdébir (ou overhead en anglais) lié à la tunnelisation étant compensé par la suppression des blocs audio. Il est à noter qu'il est possible de crypter les champs 613 à 615 si le protocole d'encapsulation 622 possède une partie de sécurisation des données (comme l'utilisation de TLS par exemple). La structure d'une trame de tunnel envoyée par le module 410 sur le canal de transport UDP 432, par exemple par la tête de tunnel 101, est représentée par l'élément 620.

Un champ 622 contient l'entête du protocole d'encapsulation du tunnel. Un champ 623 contient le même index de synchronisation que le champ 613 de la trame 610. Un champ 624 contient les blocs audio non important de la trame RTP de flux 401.

Il est à noter qu'il est possible de crypter les champs 623 et 624 si le protocole d'encapsulation 622 possède une partie de sécurisation des données (comme l'utilisation de TLS par exemple). La structure d'une trame de tunnel envoyée par le module 420 sur le canal de transport TCP 431, par exemple par la tête de tunnel 102, est représentée par l'élément 630. Cette trame de tunnel est utilisée par le module 420 pour informer le module 410 du retard de transmission Rt, et du taux de perte Tp constaté. Un champ 632 contient l'entête du protocole d'encapsulation du tunnel.

Un champ 633 contient le taux de perte Tp mesuré (ou constaté) sur la porteuse non fiable 432 (par exemple UDP). Un champ 634 contient le retard de transmission Rt. La détermination des valeurs de Rt et Tp est décrite plus précisément en relation avec la figure 8 Une deuxième table 640 contient les informations nécessaires au routage statique des différents canaux d'un flux de type donné (par exemple AC-3 5.1). Une colonne 641 contient une indication du type de flux multi-canal considéré (par exemple est utilisé la codification IANA pour les types de contenu tel que décrit dans la norme RFC 3555 pour les codes MIME correspondant). Par exemple, dans le cas d'un flux multi-canal AC3, le type MIME est audio , et le sous type AC3 . Une colonne 642 contient le mode audio. Ce mode détermine le nombre de canaux utilisés ainsi que leur ordre d'apparition dans une trame multi-canal. Ce mode permettra donc d'identifier l'affectation de chaque canal (canall pour le haut-parleur avant-droit, canal 2 pour le haut-parleur avant-gauche, etc....). Dans le cas d'un flux multi-canal AC3, cette information est contenue dans le champ BSI 552 de la trame 550 (cette information est la concaténation des champs acmod et lffeon correspondant respectivement au mode de codage au sens AC3, et à un booléen indiquant si le canal LFE est actif ou pas. Le codage des champs acmod et lfeon du BSI 552 est décrit dans un document ATSC (pour Advanced Television Systems Comitee en anglais) : Digital Audio Compression Standard (AC-3, E-AC-3) Une colonne 643 correspond au codage de l'importance de chaque canal. Cette information étant de nature binaire (important ou pas), il est avantageux de la coder sur un bit. La colonne 643 représente donc un ensemble de bits indiquant si un canal est important (valeur=l) ou non (valeur=0). La définition de l'importance d'un canal est faite selon au moins un critère prédéterminé. Ce critère peut être dépend de l'application visée. Par exemple dans une application home cinéma de type 5.1, il peut être par exemple défini que les canaux correspondants à la voie centrale, à la voie avant gauche et à la voir avant droite sont importants (valeur=l) et que les autres ne le sont pas (valeur=0). Cela peut aussi être défini en fonction de préférences utilisateur, par exemple sélectionnées de manière dépendante au contenu diffusé. En effet, les canaux considérés comme importants peuvent par exemple différer du point de vue de l'utilisateur selon que le contenu soit l'audio d'un film diffusé en continu ( streaming ) ou un contenu audio (musical) indépendant. Par exemple, dans le cas de d'un flux multi-canal AC-3 en mode 5.1, il est possible d'indiquer que seuls les trois premiers canaux sont importants (ces canaux correspondent respectivement aux voies avant-gauche, avant-droite et centrale). Le codage correspondant est 11100000 Si l'on code sur 8 bits. Bien évidemment, il s'agit ici d'un exemple illustratif et non limitatif, d'autres choix quant à l'importance des canaux en fonction de l'utilisation étant possibles.

Une troisième table 650 contient l'horodatage de réception des N dernières trames 610 reçues par le module de réception 420 (N étant une valeur fixe typiquement égale à 10). Cette table 650 peut avantageusement être une liste chaînée circulaire, les nouvelles entrées remplaçant ainsi les plus anciennes. Un champ 651 contient l'index de synchronisation 613 d'une trame 610 reçue, et le champ 652 contient l'horodatage correspondant à l'instant de réception de cette même trame 610. Un champ 653 quant à lui indique si la trame 620 de même index a été reçue. Une valeur de ce champ à 0 indique que la trame 620 n'a pas été reçue. Une valeur de ce champ à 1 indique que la trame 620 a été reçue.

Dans la suite de la description, les étapes 412a, 413a, 414a, 415a, 416a, 417a, 421a, 422a et 423a des figures 7 à 9 illustrent chacune un algorithme mis en oeuvre respectivement dans les blocs 412, 413, 414, 415, 416, 417, 421, 422 et 423 de la figure 4. Les figures 7A à 7C illustrent schématiquement l'émission d'une trame sur le réseau WAN (tel qu'Internet). Ces figures décrivent les mécanismes mis en oeuvre lors de l'émission d'une trame de flux 401 sur le tunnel. La figure 7A détaille le fonctionnement du module de routage des canaux 412. La figure 7B détaille le fonctionnement de l'empaqueteur 413 et du retardateur 414. Enfin, la figure 7C détaille le fonctionnement du sélecteur 416 et de l'empaqueteur 417.

Les relations entre les éléments 412, 413, 414, 416 et 417 sont décrites en relation avec la figure 4. Sur la figure 7A, une étape 4121 permet d'attendre que des drapeaux Dl et D2 (non représentés) soient baissés, indiquant respectivement ainsi que les mémoires tampons associées aux porteuses TCP et UDP sont prêts à recevoir une nouvelle donnée. Puis le module démultiplexeur de canaux 411 ajoute à la mémoire tampon associée à la porteuse TCP les informations de flux communiquées. Une étape 4122 sélectionne ensuite les blocs audio 553 un par un, et tant qu'il en reste, exécute une étape 4123. Lorsque l'étape 4122 détermine qu'il n'y a plus de bloc audio à traiter, une étape 4126 est exécutée. L'étape 4123 détermine si le canal audio encodé dans le bloc audio sélectionné à l'étape 4122 est important. Pour cela, elle examine la table 640 et en particulier le champ 643. La valeur du Qième bit du champ 643 (Q étant le numéro du bloc audio courant dans la trame de flux 401, donc du canal audio) indique si ce bloc est important ou pas. Si le test de l'étape 4123 est positif (c'est-à-dire si le bloc est considéré comme important), le bloc est ajouté à la mémoire tampon associée à la porteuse TCP dans une étape 4125. Sinon, le bloc est ajouté à la mémoire tampon associée à la porteuse UDP 4124. A l'issu des étapes 4124 ou 4125, l'étape 4122 est de nouveau exécutée. L'étape 4126 détermine un index de synchronisation (par exemple, en incrémentant un compteur), puis ajoute cet index au deux mémoires tampons associées aux porteuses TCP et UDP. Enfin, l'étape 4126 positionne les deux drapeaux Dl et D2 (non représentés) pour indiquer respectivement aux modules 413 et 416 qu'ils ont une nouvelle donnée à traiter. Sur la figure 7B, des étapes 4131 à 4133 détaillent les algorithmes réalisés par le module 413.

Une étape 4131 détecte si le drapeau Dl a été levé à l'étape 4126, indiquant que la mémoire tampon associée à la porteuse TCP contient une nouvelle donnée. Une étape 4132 utilise les données contenues dans la mémoire tampon associée à la porteuse TCP, pour fabriquer une trame 610. Pour cela, il suffit éventuellement d'encrypter le contenu de la mémoire tampon associée à la porteuse TCP, et d'y d'ajouter l'entête de tunnel 612. Une étape 4133 ajoute la trame fabriquée à l'étape 4132 à une mémoire tampon de retard. La mémoire tampon de retard est une FIFO qui contient également pour chaque trame un horodatage indiquant quand la trame a été insérée dans la mémoire tampon de retard. L'horodatage associé à une trame de la mémoire tampon de retard est notamment utilisé pour déterminer si la trame a été suffisamment retardée. L'étape 4133 baisse ensuite le drapeau Dl indiquant ainsi que la mémoire tampon associée à la porteuse TCP est à nouveau prête à recevoir de nouvelles données. Suite à l'exécution de l'étape 4133, une étape 4141 est exécutée. Les étapes 4141 à 4146 décrivent en détail l'algorithme appliqué par le retardateur 414. Une étape 4141 sélectionne la première trame dite trame courante de la mémoire tampon de retard.

Ensuite, une étape 4142 détermine si la trame courante doit être transmise immédiatement ou retardée. On définit un retard courant Rc de la trame courante comme la différence entre son instant d'insertion dans la mémoire tampon de retard (horodatage associé à la trame courante lors de son insertion dans la mémoire tampon de retard) et l'instant courante. Pour cela, une étape 4142 compare le retard courant Rc de la trame courante à un retard R à appliquer à la trame courante (le retard R est déterminé par le moteur de décision 415 grâce aux informations de rétroaction fournies par l'ordonnanceur 422 de la tête de tunnel distante). Si le retard courant Rc est supérieur ou égal au retard R , le délai est expiré. Le test de l'étape 4142 est alors positif. Si le test de l'étape 4142 est négatif, l'algorithme doit attendre avant de réévaluer la valeur de du retard courant Rc de la trame courante. Pour cela, une étape d'attente 4143 est exécutée, puis l'étape 4142 est à nouveau exécutée. Si le test de l'étape 4142 est positif, la trame courante doit être émise immédiatement lors d'une étape 4144. L'étape 4144 émet la trame 610 courante sur la porteuse fiable 431 (par exemple TCP) à destination de l'ordonnanceur 422 de la tête de tunnel distante 102. 30 Une étape 4145 supprime alors la trame courante de la mémoire tampon de retard. Puis, une étape 4146 détermine si la mémoire tampon de retard est vide. Si le test de l'étape 4146 est négatif, l'étape 4141 est de nouveau exécutée.

Sinon, l'algorithme s' arrête. Sur la figure 7C, les étapes 4161 à 4165 détaillent l'algorithme exécuté par le sélecteur 416. On définit ici un compteur de trame Ct qui correspond au nombre de trames 620 émises sur la porteuse non fiable 432. Ce compteur de trame Ct est initialisé à 0 lors de l'ouverture du tunnel. Cette valeur Ct va permettre au sélecteur 416 de déterminer si une trame doit être émise ou supprimée afin de respecter une valeur Ts déterminé par le moteur de décision 415 et reflétant le taux de suppression à appliquer. La valeur Ts est un nombre entier correspondant au nombre de trames consécutives que peut transmettre le sélecteur 416. Par exemple, pour un taux de suppression d'une trame sur 10 (10% de perte), la valeur de Ts sera 10. Le sélecteur 416 laissera donc passer 10 trames, la onzième sera supprimée, puis le compteur Ct repassera à 0. Il est à noter qu'une valeur de Ts égale à 0 indique qu'aucune trame ne doit être supprimée, ce qui correspond au cas normal. Une première étape 4161 détecte si le drapeau D2 a été levé à l'étape 4126, indiquant que la mémoire tampon associée à la porteuse UDP contient une nouvelle donnée. Une étape 4162 détermine si le compteur Ct est strictement inférieur à Ts. Si le test de l'étape 4162 est positif, la trame peut être émise, et le compteur Ct est incrémenté de 1 dans une étape 4165. Suite à l'exécution de l'étape 4165, une étape 4171 est exécutée. Si le test de l'étape 462 est négatif, la trame contenue dans la mémoire tampon associée à la porteuse UDP est supprimée dans une étape 4163, et ne sera donc pas émise. Puis le compteur Ct est remis à zéro grâce dans une étape 4164. Les étapes 4171 à 4172 décrivent en détail l'algorithme appliqué par l'empaqueteur 417. L'étape 4171 utilise les données contenues dans la mémoire tampon associée à la porteuse UDP, pour fabriquer une trame 620. Pour cela, il suffit éventuellement d'encrypter le contenu de la mémoire tampon associée à la porteuse UDP, et d'y d'ajouter l'entête de tunnel 622. Enfin, une étape 4172 émet la trame 620 courante sur la porteuse non fiable 432 à destination du tampon de synchronisation 421 de la tête de tunnel distante 102, et baisse ensuite le drapeau D2 indiquant ainsi que la mémoire tampon associée à la porteuse UDP est à nouveau prête à recevoir de nouvelles données.. La figure 8 illustre un algorithme de réception d'une trame en provenance du réseau WAN (tel qu'Internet). La figure 8 décrit en détail les traitements appliqués par les différents composants du module de réception 420 lors de la réception d'une trame 610 ou 620 sur l'une des porteuses 431 ou 432 du tunnel. Une première étape 425 détermine le type de la trame reçue depuis Internet dénommée trame courante dans la suite de la description. Si la trame courante est une trame 620, une étape 4211 est exécutée.

Si la trame courante est une trame 610, une étape 4221 est exécutée. Les étapes 4211 et 4212 décrivent l'algorithme réalisé par le tampon de synchronisation 421 sur réception d'une trame 620. Après un éventuel décryptage de la trame courante, l'étape 4211 insère une ligne dans la table 600, et renseigne les champs 601 et 603 avec respectivement les champs 623 et 624 de la trame 620 courante. L'étape 4212 valorise le champ 602 (de la ligne ajoutée à la table 600 à l'étape 4211) avec une valeur d'horodatage représentative de l'instant courant. Suite à l'exécution de l'étape 4212, l'algorithme se termine. Les étapes 4221 à 4225 détaillent l'algorithme réalisé par l'ordonnanceur 422 lors de la réception d'une trame 610. L'étape 4221 parcourt la table 600 à la recherche d'une trame 620 stockée dont l'index de synchronisation 601 est identique à l'index 613 de la trame courante. Si c'est le cas, le champ 603 de la table 600 est ajouté à la trame courante complétant ainsi le nombre de canaux audio. Le champ 653 de la table 650 correspondant à l'index de la trame courante est également passé à 1 pour indiquer que cette trame est complète.

Puis une étape 4222 détermine le retard maximum constaté entre la réception des trames 610 et 620 pour un même index. Pour cela, on définit le retard R suivant la formule suivante : R = TSTCP (Min (received UDP)) - TSudp (Min (received UDP)).

Le terme Min (received UDP) indique le plus petit index de synchronisation Ism présent dans le tampon 600. Cet index peut correspondre à une trame 620 déjà arrivée, et dont la trame 610 de même index n'est pas encore arrivée, ou au contraire à une trame 620 arrivée trop tard c'est-à-dire après que la trame 610 de même index ait été traitée.

Le terme TSTCP(In) correspond à l'horodatage (ou TimeStamp en anglais) de la trame TCP dont l'index de synchronisation In est passé en paramètre. Cette valeur est obtenue en parcourant la table 650 des dernières trames TCP reçues. Le terme TSudp(In) correspond à l'horodatage de la trame UDP dont l'index de synchronisation In est passé en paramètre. Cette valeur est obtenue en parcourant la table 600. Si le parcours de la table 650 ne permet pas de trouver l'index Ism , cela signifie que la trame 610 d'index Ism n'a pas encore été reçue. La valeur de R est alors inchangée (on conserve la précédente valeur déterminée lors de l'arrivée de la trame 610 précédent la trame 610 courante). Sinon, la valeur de R est réévaluée selon la formule citée plus haut. Si la valeur de R est positive, cela signifie que la trame 620 correspondant à l'index Ism à été reçue avant la trame 610 correspondant à ce même index. Dans ce cas, tout va bien puisque l'hypothèse de base est respectée. Si la valeur de R est négative, cela signifie que la trame 620 d'index Ism est arrivée après la trame 610 de même index. La trame 620 d'index Ism est donc en retard de la valeur R . Une étape 4223 purge alors la table 600 en supprimant l'ensemble des lignes dont l'index est inférieur au plus grand index de la table 650 des dernières trames 610 reçues. Ces lignes correspondent à des trames 620 arrivées après le traitement de la trame 610 de même index. L'étape 4223 supprime également de la table 600 la trame 620 de même index que la trame courante si elle existe. De plus, lors de la suppression d'une ligne de la table 600 lors de l'étape 4223, la valeur du champ 653 de la ligne de la table 650 dont l'index est le même que celui de la ligne supprimée, est passé à 1 indiquant que la trame 620 correspondante a été reçue (même si elle est en retard). Une étape 4224 détermine le taux de perte. Ce nombre correspond à la somme des valeurs de tous les champs 653 de la table 650, c'est-à-dire le nombre de trames 620 reçues sur les N dernières trames 610 reçues (N étant déjà défini en relation avec la figure 6). Une étape 4225 fabrique une trame 630 en valorisant respectivement les champs 633 et 634 avec les valeurs courantes de Tp et R . Suite à l'exécution de l'étape 4225, une étape 4231 est exécutée.

Les étapes 4231 à 4233 détaillent l'algorithme réalisé par le régénérateur de trame 423. L'étape 4231 détermine si une trame 620 à été reçue avec un index égal à celui de la trame 610 courante. Pour cela, l'étape 4231 examine le champ 653 de la table 650 pour la ligne d'index égal à l'index de la trame courante.

Si le test de l'étape 4231 est négatif, il manque des canaux audio, et le module 424 d'insertion de silence (ou plus généralement de données synthétiques) est mis en oeuvre pour compléter les canaux audio manquant. Des possibilités de mise en oeuvre de ce module 424 sont décrites en relation avec la figure 4. Si le test de l'étape 4231 est positif, ou à l'issue de la mise en oeuvre du module 424, une étape 4232 est exécutée. L'étape 4232 fabrique une trame de flux valide en utilisant le contenu de la trame 610 courante et de l'éventuelle trame 620 correspondante, ou du complément fabriqué par le module 424. L'étape utilise en particulier les champs 614, 615 et 624. Grâce aux informations contenues dans les champs 614, 625 et 624, l'étape 4232 génère une trame de flux RTP valide 402. Une étape 4233 utilise les informations du champ 614 de la trame courante (en particulier les adresses MAC source et destination, mais aussi les adresses IP source et destination, ainsi que les ports UDP source et destination) pour envoyer à l'équipement récepteur 112 la trame de flux générée à l'étape 4232.

La figure 9 illustre un algorithme de réception d'une trame de rétroaction par le moteur de décision 415.

Le but du moteur de décision 415 est de fournir les valeurs de R (retard à appliquer par le retardateur 414), et de Ts (valeur relative à un taux de suppression à appliquer par le sélecteur 416). Sur réception d'une trame de rétroaction 630 envoyée par l'ordonnanceur 422 de la tête de tunnel distante, une étape 4151 est exécutée. Une étape 4151 détermine si la valeur Rr du retard reçu est supérieure à un seuil S . Cette valeur Rr correspond au champ 634 de la trame de rétroaction 630 courante. Le seuil S correspond à une valeur fixe de sécurité permettant d'éviter que les trames 620 arrivent en retard par rapport aux trames 610 de même index. Typiquement, cette valeur peut être égale à quelque milliseconde (par exemple 5 ms). Lors de l'étape 4151, si la valeur Rr est inférieure à l'avance minimale S , cela signifie que : - soit l'avance des trames 620 sur les trames 610 est très faible, c'est-à-dire le cas où la valeur de Rr est positive ; - soit les trames 620 sont en retard sur les trames 610, c'est-à-dire le cas où la valeur de Rr est négative. Dans le cas où le test de l'étape 4151 est positif (c'est-à-dire lorsque la valeur de Rr est supérieure à l'avance minimale S ), il n'y a pas lieu d'appliquer un retard à l'émission des trames 610. L'étape 4153 est alors exécutée, pour positionner la valeur du retard R à 0. Si le test de l'étape 4151 est négatif, une étape 4152 est exécutée. L'étape 4152 positionne la nouvelle valeur du retard R suivant la formule suivante : R = Abs(Rr) + S, où Abs(Rr) désigne la valeur absolue de Rr. Le retard R est donc positionné avec une marge supplémentaire S . A l'issue de l'exécution des étapes 4152 ou 4153, une étape 4154 est exécutée. L'étape 4154 détermine s'il y a une congestion en cours sur le canal fiable 431. Pour cela, elle peut par exemple examiner le taux de retransmission sur la porteuse fiable. Si ce taux dépasse un seuil donné (par exemple 1%), l'étape 4154 est positive et une étape 4155 est exécutée. Sinon, une étape 4156 est exécutée. Dans une variante, elle peut par exemple examiner le taux de perte constaté par la tête de tunnel distante et fourni par la tête de tunnel distante dans le champ 633 du message 630. La différence entre ces deux taux fournit la taux de perte réel sur la seconde porteuse (la première porteuse disposant d'un protocole avec acquittements et retransmissions si nécessaire). L'étape 4155 exécutée en cas de congestion de la porteuse fiable va augmenter le taux de suppression à appliquer par le sélecteur 416, réduisant ainsi le débit sur le lien Internet, favorisant donc la résorption de la congestion (car les deux porteuses 431 et 432 partagent le même lien Internet). L'augmentation du taux de suppression est proportionnelle à un coefficient fixe C qui peut par exemple être de 1% (à chaque réception d'une trame de rétroaction, et en cas de congestion, le taux de suppression sera augmenté de 1%). Le terme Ts correspond au nombre de trames successives qui peuvent être émises par le sélecteur 416 sans suppression. Si le taux de suppression augmente de 1%, Ts doit diminuer de 1%. En conséquence, l'étape 4155 applique la formule suivante pour la détermination de la nouvelle valeur Ts à partir de la valeur précédente deTs: Ts = Ts - Ts/C (la valeur minimale de Ts étant égale à 0) Si le test de l'étape 4154 est négatif, il n'y a pas ou plus de congestion, et la valeur de Ts peut alors être augmentée progressivement. Une étape 4156 applique donc la formule suivante pour la détermination de la nouvelle valeur de Ts : Ts = Ts + Ts/C (la valeur maximale de Ts étant par exemple égale à deux fois la fenêtre de congestion de la porteuse fiable). D'autres méthodes de progression de la valeur Ts sont possibles et à la portée de l'Homme du Métier. A l'issue des étapes 4155 ou 4156, une étape 4157 est exécutée.

L'étape 4157 détermine si le compteur Ct de trames 620 consécutives émises sans perte est supérieur à la nouvelle valeur de Ts . Si c'est le cas, une étape 4158 position le compteur Ct à la nouvelle valeur de Ts. Si le test de l'étape 4157 est négatif, ou a l'issu de l'étape 4158, l'algorithme s'arrête.

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é 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 de traitement graphique ou sonore 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 programme précité et référencé 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 du programme précité. - 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 programme "Prog" précité.

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 du programme précités permettant au dispositif générique 1000 de mettre en oeuvre le procédé 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 logiciel du programme selon l'invention. Lors de la mise sous tension, le programme stocké 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 programme selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre du procédé 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 programme informatique par exemple figé dans un circuit intégré à application spécifique (ASIC).15

Claims (1)

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 au moins une première porteuse (431) supportant un protocole de transport avec acquittement et au moins une seconde porteuse (432) supportant un protocole de transport sans acquittement, caractérisé en ce que la première tête de tunnel effectue des étapes consistant à : 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 d'au moins un critère d'aiguillage prédéterminé ; associer une même information de synchronisation (613, 623) auxdits canaux ; obtenir une première information de rétroaction (634) représentative d'une gigue relative de transmission entre lesdites première et seconde porteuses ; appliquer (4142, 4143) un retard avant transmission sur la première porteuse desdits canaux aiguillés vers la première porteuse (431), ledit retard étant déterminé en fonction de ladite première information de rétroaction (634). Procédé selon la revendication 1, caractérisé en ce que ladite première information de rétroaction est une information de délai (Rr) entre un instant de réception 20 par la seconde tête de tunnel via la seconde porteuse d'un premier ensemble de canaux et un instant de réception par la seconde tête de tunnel via la première porteuse d'au moins un second ensemble de canaux, les canaux desdits premier et second ensembles étant associés à une même information de synchronisation. Procédé selon la revendication 2, caractérisé en ce que : si ledit délai (Rr) est supérieur à un seuil prédéterminé, le retard avant transmission à appliquer est nul ; si le délai (Rr) est inférieur ou égal audit seuil prédéterminé, le retard avant transmission à appliquer est égal à la somme de la valeur absolue dudit délai (Rr) et dudit seuil prédéterminé. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la première tête de tunnel effectue en outre des étapes consistant à : - - - -2. 3. 25 - - 30 4.- obtenir une seconde information de rétroaction (633) représentative d'un taux de perte sur la seconde porteuse ou d'un taux de retransmission sur la première porteuse ; - supprimer (4163) des trames aiguillées vers la seconde porteuse (432), en fonction de ladite seconde information de rétroaction (633). 5. Procédé selon l'une quelconque des revendications 1 à 4, 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. 6. 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 au moins une première porteuse (431) supportant un protocole de transport avec acquittement et au moins une seconde porteuse (432) supportant un protocole de transport sans acquittement, caractérisé en ce que la seconde tête de tunnel effectue des étapes consistant à : - recevoir, via les première et seconde porteuses, des canaux dudit flux de données multi-canal ainsi que des informations de synchronisation associées auxdits canaux, les canaux d'une même trame dudit flux de données multi-canal étant associés à une même information de synchronisation ; - stocker (4211) dans une mémoire tampon (421) les canaux et les informations de synchronisation reçus via la seconde porteuse (432) ; - et sur réception, via la première porteuse, d'un premier ensemble de canaux associés à une information de synchronisation donnée : * extraire de ladite mémoire tampon (421) un second ensemble de canaux associés à ladite information de synchronisation donnée ; * reconstruction d'une trame dudit flux de données multi-canal, à partir desdits premier et second ensembles ; - déterminer une première information de rétroaction (634) représentative d'une gigue relative de transmission entre lesdites première et seconde porteuses ; - transmettre ladite première information de rétroaction à ladite première tête de tunnel.7. Procédé selon la revendication 6, caractérisé en ce que ladite première information de rétroaction est une information sur un délai (Rr) entre un instant de réception par la seconde tête de tunnel dudit premier ensemble de canaux et un instant de réception par la seconde tête de tunnel dudit second ensemble de canaux.. 8. Procédé selon l'une quelconque des revendications 6 et 7, caractérisé en ce que la seconde tête de tunnel effectue des étapes consistant à : - déterminer une seconde information de rétroaction (633) relative à un taux de perte sur la seconde porteuse par comparaison d'un nombre de portions de trame du flux multi-canal reçues via la première porteuse et un nombre de portions de trame du flux multi-canal reçues via la seconde porteuse ; - transmettre ladite seconde information de rétroaction à ladite première tête de tunnel. 9. 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 à 5 et/ou le procédé selon au moins une des revendications 6 à 8, lorsque ledit programme est exécuté sur un ordinateur. 10. 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é selon au moins une des revendications 1 à 5 et/ou le procédé selon au moins une des revendications 6 à 8. 11. Première tête de tunnel participant à une transmission d'un flux de données mufti- 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 au moins une première porteuse (431) supportant un protocole de transport avec acquittement et au moins une seconde porteuse (432) supportant un protocole de transport sans acquittement, ladite la première tête de tunnel étant caractérisé en ce qu'elle comprend :des moyens pour aiguiller les 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 d'au moins un critère d'aiguillage prédéterminé ; des moyens d'association d'une même information de synchronisation (613, 623) auxdits canaux ; - des moyens d'obtention d'une première information de rétroaction (634) représentative d'une gigue relative de transmission entre lesdites première et seconde porteuses ; - des moyens d'application d'un retard avant transmission sur la première porteuse desdits canaux aiguillés vers la première porteuse (431), ledit retard étant déterminé en fonction de ladite première information de rétroaction (634). 12. Première tête de tunnel selon la revendication 11, caractérisé en ce que ladite première information de rétroaction est une information de délai (Rr) entre un instant de réception par la seconde tête de tunnel via la seconde porteuse d'un premier ensemble de 15 canaux et un instant de réception par la seconde tête de tunnel via la première porteuse d'au moins un second ensemble de canaux, les canaux desdits premier et second ensembles étant associés à une même information de synchronisation. 13. Première tête de tunnel selon la revendication 12, caractérisé en ce qu'elle comprend des moyens de comparaison dudit délai (Rr) à un seuil prédéterminé et 20 permettant auxdits moyens d'application d'un retard : de ne pas appliquer un retard avant transmission, si ledit délai (Rr) est supérieur audit seuil prédéterminé ; d'appliquer un retard avant transmission égal à la somme de la valeur absolue dudit délai (Rr) et dudit seuil prédéterminé, si le délai (Rr) est inférieur ou égal audit 25 seuil prédéterminé. 14. Première tête de tunnel selon l'une quelconque des revendications 11 à 13, caractérisé en ce qu'elle comprend : - des moyens d'obtention d'une seconde information de rétroaction (633) représentative d'un taux de perte sur la seconde porteuse ou d'un taux de 30 retransmission sur la première porteuse ; - des moyens de suppression des trames aiguillées vers la seconde porteuse (432), en fonction de ladite seconde information de rétroaction (633). 1015. Première tête de tunnel selon l'une quelconque des revendications 11 à 14, 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. 16. Seconde tête de tunnel participant à une transmission d'un flux de données mufti- 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 au moins une première porteuse (431) supportant un protocole de transport avec acquittement et au moins une seconde porteuse (432) supportant un protocole de transport sans acquittement, ladite seconde tête de tunnel étant caractérisé en ce qu'elle comprend : des moyens de réception, via les première et seconde porteuses, des canaux dudit flux de données multi-canal ainsi que des informations de synchronisation associées auxdits canaux, les canaux d'une même trame dudit flux de données multi-canal étant associés à une même information de synchronisation ; des moyens de stockage permettant de stocker, dans une mémoire tampon (421) ,les canaux et les informations de synchronisation reçus via la seconde porteuse (432) ; des moyens d'extraction de ladite mémoire tampon (421) d'un second ensemble de canaux associés à ladite information de synchronisation donnée , sur réception, via la première porteuse, d'un premier ensemble de canaux associés à une information de synchronisation donnée ; des moyens de reconstruction d'une trame dudit flux de données multi-canal, à partir desdits premier et second ensembles ; des moyens de détermination d'une première information de rétroaction (634) représentative d'une gigue relative de transmission entre lesdites première et seconde porteuses ; des moyens de transmission de ladite première information de rétroaction à ladite première tête de tunnel. Seconde tête de tunnel selon la revendication 16, caractérisé en ce que ladite première information de rétroaction est une information sur un délai (Rr) entre un instant - - - - - - 17.• 44 de réception par la seconde tête de tunnel dudit premier ensemble de canaux et un instant de réception par la seconde tête de tunnel dudit second ensemble de canaux. 18. Seconde tête de tunnel selon l'une quelconque des revendications 16 à 17, caractérisé en ce qu'elle comprend en outre : - des moyens de détermination d'une seconde information de rétroaction (633) relative à un taux de perte sur la seconde porteuse par comparaison d'un nombre de portions de trame du flux multi-canal reçues via la première porteuse et un nombre de portions de trame du flux multi-canal reçues via la seconde porteuse - des moyens de transmission de ladite seconde information de rétroaction à ladite première tête de tunnel.