FR2895181A1

FR2895181A1 - Procede et systeme de transmission d'un flux de donnees multimedia

Info

Publication number: FR2895181A1
Application number: FR0512786A
Authority: FR
Inventors: Denis Vergnaud
Original assignee: MEDIATVCOM SARL
Current assignee: MEDIATVCOM SARL
Priority date: 2005-12-16
Filing date: 2005-12-16
Publication date: 2007-06-22
Anticipated expiration: 2025-12-16
Also published as: FR2895181B1; US20080267216A1; WO2007080284A2; EP1961165A2; WO2007080284A3

Abstract

Procédé de transmission d'un flux de données multimédia (F) depuis au moins un émetteur vers au moins un récepteur au travers d'une liaison comprenant un réseau (14) de communication de type Internet utilisant le protocole IP, ledit procédé comprenant les étapes suivantes :- mise en paquet, à l'émission, d'au moins une partie des données du flux de données multimédia (F) conformément à un format prédéfini,- transmission des paquets (22) ainsi formés de l'émetteur vers le récepteur, au moins une partie de ladite liaison entre l'émetteur et le récepteur étant constituée par une pluralité de chemins (21) physiques distincts prédéfinis.L'invention permet de dépasser les limites de débit imposées par une seule ligne de transmission. L'utilisateur peut donc atteindre le débit qu'il souhaite en multipliant le nombre de chemin physique au moins entre l'émetteur et le réseau ou entre le réseau et le récepteur.

Description

-1- <<Procede et systeme de transmission d'un flux de donnees

multimedia

La presente invention concerne un procede et un systeme de transmission d'un flux de donnees multimedia d'un ou plusieurs emetteurs vers un ou plusieurs recepteurs, au travers d'un reseau de transmission. Ce procede vise en particulier un procede et un systeme de transport de donnees video sur un reseau de communication en utilisant le protocole IP (Internet Protocol). Le domaine de ('invention est le domaine des telecommunications et en particulier les telecommunications appliquees au domaine du multimedia. L'invention s'applique plus particulierement au transport de donnees multimedia sur un reseau de communication de type Internet utilisant le protocole IP. Les donnees multimedia concernees sont notamment le son et/ou ('image animee.

En effet, Les liaisons haut debit sur IP se generalise en Europe, en Asie, en Amerique du Nord et en Afrique. Celles-ci sont rendues possibles par des methodes d'acces economiques comme I'ADSL (Asymmetric Digital Subscriber Line) ou VIP par satellite par exemple. On assiste, de manure plus ou moins rapide selon les marches a une augmentation des debits d'acces. En parallele, la qualite de service (QoS ou Quality of Service) sur les reseaux IP s'ameliore, permettant de vehiculer des flux a caractere isochrone comme de la voix ou de la video. Ceci est particulierement vrai dans des reseaux prives ou prives virtuels (VPN ou Virtual Private Networks) basees sur les technologies IP et MPLS (Multiprotocol label switching).

D'autre part, les mecanismes de QoS prevus dans IPv4 (Internet Protocol version 4) seront generalises et etendus en IPv6 (Internet Protocol version 6). RTP veut dire Real-time Transport Protocol, protocole de niveau transport (niveau 4 dans le modele OSI). Bien que protocole de la couche transport, ce protocole ajoute un certain nombre de fonctions applicatives, comme le transport de I'horloge de reference par exemple. II a ete concu pour transporter des flux temps-reel, typiquement de ('audio et de la video, sur des reseaux IP. -2- Flux RTP / RTP Stream : C'est une notion equivalente a la session RTP definie dans [RTP]. II s'agit d'un flux RTP defini par un couple d'adresses de transport source / destination definies chacune par un couple adresse IP/port UDP.

Adresse de Transport / Transport Address : Origine ou destination d'un flux de donnees UDP ou RTP dans notre environnement. Defini par le couple adresse IP / port (UDP, User Datagram Protocol ou TCP, Transmission Control Protocol). Transport Stream ou TS : c'est le format communement utilise dans le domaine de la television numerique pour le transport de flux de donnees audiovisuelles multiplexees. Le format TS est defini dans [ISO 13818-1]. Codeur : Equipement de numerisation (si necessaire), de compression et de codage des donnees audio et video. Decodeur : Equipement de decodage, de decompression et de 15 formatage (analogique par exemple) des flux audio et video compresses. RTT : Round Trip Time : le temps de traverse d'un paquet a travers le reseau pour atteindre sa destination. Par ailleurs le mot << flux >> designe par extension tout flux de donnees ou flux de paquets si ces donnees sont paquetisees. Le mot 20 << fragment de flux > designe une partie des donnees ou des paquets d'un flux d'origine, eventuellement encapsule dans un autre format de donnees ou de paquets. Actuellement les editeurs de programmes televisuels, les diffuseurs, les producteurs et post-producteurs sont restes majoritairement refractaires 25 aux technologies IP pour le transport de leurs flux audiovisuels de contribution (studio vers studio typiquement) et de contribution de diffusion (regie finale vers emetteur par exemple), preferant rester sur des technologies satellitaires ou sur des technologies telecom d'ancienne generation ou tres proches du signal physique (modulation directe sur fibre 30 noire, SDH ou Synchronous Digital Hierarchy, PDH ou Plesiochronous Digital Hierarchy par exemple). Leur reticence est en partie justifiee par I'incapacite d'IP a gerer Ies problematiques de gigue (jitter), de taux de perte de paquets faible, de redondance en temps reel. -3- Cependant ('augmentation des debits de telecommunication sur IP,la diminution des coOts des installations IP engendree par la generalisation des equipements IP, I'offre d'une veritable qualite de service par les operateurs de services sur IP et ('integration dans les equipements d'extremites du traitement des problematiques de gigue permet aux acteurs de ce domaine de se tourner vers les technologies IP. Plusieurs problematiques persistent cependant. D'une part le debit des liens d'acces, en particulier xDSL (xDSL : tout type de DSL) dans le sens << upload >> (utilisateur vers reseau) est en general tres limite. Les nouvelles technologies VDSL permettront dans leur deploiement le plus commun un debit de 2Mb/s uniquement pour << ('upload >>. D'autre part, les reseaux IP, en particulier xDSL, ont toujours des taux de pertes de paquets superieurs a ce qui est communement observe sur les reseaux Telecom, en particulier si on parle d'Internet et ses taux de perte de paquets restent trop important pour le transport professionnel de video. Un objectif de ('invention est ainsi de proposer un procede et un systeme permettant d'augmenter les debits de transmissions de signaux multimedias sur IP. Un autre objectif de ('invention est de proposer une methode 20 permettant d'assurer une plus grande garantie d'acheminement et une plus grande continuite de fonctionnement que les systemes actuels. L'invention propose de remedier aux problemes pi-kites et d'atteindre les objectifs notes ci-dessus, par un procede de transmission d'un flux de donnees multimedia depuis au moins un emetteur vers au 25 moins un recepteur au travers d'au moins une liaison comprenant au moins un reseau de communication de type IP, ledit procede comprenant les etapes suivantes : mise en paquet, a ('emission, d'au moins une partie des donnees du flux de donnees multimedia conformement a au 30 moins un format predefini ; et transmission des paquets ainsi formes de I'emetteur vers le recepteur, au moins une partie de ladite liaison entre I'emetteur et le recepteur etant constituee par une pluralite de chemins physiques distincts predefinis. -4- Avantageusement, grace au procede selon ('invention, la liaison entre I'emetteur et le reseau de communication, ou entre le reseau de communication et le recepteur comprend une pluralite de chemins physiques. Ces chemins peuvent vehiculer des paquets en parallele. La connexion de chaque chemin physique au reseau peut etre realisee grace, par exemple, a des moyens de type modem. L'invention permet ainsi de depasser les limites de debit imposees par une seule ligne de connexion. L'utilisateur peut donc atteindre le debit quill souhaite en multipliant le nombre de chemin physique entre I'emetteur et le 10 reseau ou entre le reseau et le recepteur. Dans un mode de realisation prefere de ('invention, le procede peut etre mis en ceuvre pour realiser une transmission d'un flux de donnees multimedia en temps reel, avec un traitement de gigue integre et des temps de latence tres faibles. 15 De plus, le fait que la connexion entre le recepteur et le reseau ou entre I'emetteur et le reseau soit constituee d'une pluralite de chemins physiques permet, en particulier, d'utiliser au moins une partie du debit disponible des lignes comme secours les unes des autres, ce qui permet d'augmenter la garantie d'acheminement et la continuite de fonctionnement 20 du systeme agence pour mettre en oeuvre le procede selon l'invention. Le procede selon ('invention peut de plus comprendre un fractionnement (I) du flux de donnees multimedia (F) constituant une partition des paquets dudit flux dans au moins un ensemble dit fragment contenant au moins un paquet. 25 Avantageusement, le fractionnement du flux est effectue a un debit ajuste en fonction d'au moins un parametre, dit poids, determine en fonction d'au moins une donnee choisie dans la Iiste suivante: parametre d'initialisation, indicateur de qualite de transmission, debit relatif a une autre operation. 30 Le procede selon ('invention peut, en particulier, comprendre une distribution du flux de donnees sur une pluralite de chemins physiques de transmission, en fonction d'informations relatives a au moins un chemin de transmission. L'objectif de cette distribution est de repartir le flux de -5- donnees multimedia entre une pluralite de chemins physiques en fonction de contraintes de repartitions. En particulier, la distribution peut prendre en compte le debit total a acheminer et les debits de transmission sur chaque ligne de transmission, pour ensuite repartir le flux de donnees multimedia a transmettre entre les differentes lignes de transmission. D'autres contraintes, telles que des debits minimaux ou maximaux fixes par un utilisateur, peuvent etre prises en compte lors de cette distribution. Le fractionnement du flux de donnees multimedia en une pluralite de fragments de flux et/ou la distribution de paquets de donnees sur une pluralite de chemins peuvent par exemple etre realises par un ordonnanceur utilisant un ordonnancement de type Round Robin ponders. Cet ordonnancement est bien connu de I'homme du metier. Pour plus d'informations voir les sections 2.3.2 et 2.3.2.1 de << Etude des algorithme d'attribution de priorites dans un Internet a Differentiation de Services >>, Octavio Napoleon MEDINA CARJAVAL, Mars 2001, ou http://www.rennes.enst-bretagne.fr/Nmedina/these/these-medina.pdf ou encore http://www.linuxvirtualserver.org/docs/scheduling.html. Le fractionnement de paquets de donnees peut etre ajuste dynamiquement en fonction essentiellement d'au moins un debit effectif fixe ou variable de transmission sur au moins un chemin. En effet, les debits effectifs de transmission peuvent varier au niveau de chaque ligne. Cette variation peut entrainer un ajustement du fractionnement en fonction de nouvelles valeurs de debits obtenues apres variation.

Le fractionnement de paquets de donnees peut etre ajuste dynamiquement en fonction essentiellement d'au moins une valeur de gigue de transmission sur au moins un chemin. D'autres valeurs peuvent de maniere avantageuse venir completer la Iiste des valeurs permettant ('ajustement dynamique du fractionnement. II peut par exemple s'agir du taux de perte de paquets ou du taux de reordonnancement de paquets. Dans une version avantageuse de !'invention, I'etape de mise en paquet peut comprendre au moins une encapsulation des donnees dans un paquet conforme au Real Time Protocole (RTP) sur au moins un chemin. -6- Cette encapsulation peut titre propre a chaque chemin. Le fait de recourir a ce format permet de : conserver, le cas echeant, un flux de donnees conforme a RTP et sans erreur. Si les paquets avaient ete inseres dans le reseau sans modification, le flux de donnees multimedia incident n'aurait pas ete conforme a RTP car it aurait presente des discontinuites au niveau du SN << Sequence Number . Cette etape est realisee si les donnees en entree sont deja inserees dans des paquets conformes au format RTP mesurer la qualite de chaque lien de transmission independamment, en utilisant les mecanismes propres a une couche RTP standard, transporter des informations d'horodatage < timestamp independantes du flux de donnees multimedia d'origine, genere par I'emetteur et eventuellement propres a chaque chemin. Ceci permet d'assurer une regeneration du flux de donnees multimedia a la reception en supprimant I'effet de la gigue induite par le reseau sur chaque chemin, preserver les informations originates du flux de donnees multimedia d'origine pour les restituer a la reception, et assurer un reassemblage tres performant. Dans une version avantageuse de ('invention, le procede peut comprendre un envoi des paquets de donnees depuis I'emetteur vers le recepteur au travers d'au moins un chemin physique de transmission, 25 I'envoi etant effectue en fonction d'un debit variable de transmission de donnees sur ledit chemin de transmission. En effet, ('envoi des paquets depuis I'emetteur vers un recepteur au travers du reseau de transmission, peut titre realise avec un lissage de debit d'envoi. Ce lissage de debit ou traffic shaping pourra titre realise sur la base d'atgorithmes classiques, 30 par exemple << token bucket filter , bien connues de I'homme du metier. Avantageusement, le procede selon ('invention peut comprendre une emission de paquets de donnees de I'emetteur vers le recepteur, au travers d'une pluralite de chemins physiques, chacun des ces chemins physiques etant adresse par I'emetteur au moyen d'une ou plusieurs adresses IP 10 15 20 -7- (Internet Protocole). Une fois que les paquets de donnees sont prets pour titre envoyes vers le reseau de transmission pour titre transmis au recepteur, ils sont envoyes par I'emetteur sur une pluralite de chemins physiques qui font la liaison entre I'emetteur et au moins un reseau de transmission. Ces chemins physiques qui peuvent vehiculer en parallele des paquets de donnees, sont adresses par I'emetteur au moyen d'une adresse IP de destination, d'un port UDP, d'une interface reseau et d'une adresse IP de passerelle d'acces au reseau si necessaire (selon ('architecture reseau). Grace a ces adresses, I'emetteur envoi sur chaque chemin physique les paquets qui doivent titre vehicule par ces chemins pour quills soient injectes dans au moins un reseau de transmission. Dans une version avantageuse, le procede selon I'invention peut comprendre en outre une reception, par le recepteur, de paquets de donnees sur une pluralite de chemins physique, chacun de ces chemins physique debouchant sur un couple (adresse IP, port UDP). En effet, les paquets de donnees qui sont envoyes par l'emetteur sur une pluralite de chemins physiques au moyen d'une pluralite d'interfaces reseau, vers le recepteur au travers du reseau de transmission, sont regus au niveau du recepteur sur un ou plusieurs chemins comportant chacun au moins une interface reseau. Chaque chemin se termine, en particulier, sur un couple (adresse IP, port UDP). C'est ce qui permet de differencier les differents chemins a la reception. Selon une particularite avantageuse du procede selon ('invention une reception d'un nouveau paquet est suivie par un ordonnancement de ce paquet dans une file d'attente en fonction d'informations relatives au nouveau paquet regu et/ou a au moins un paquet precedemment regu. Les informations prises en compte Tors d'un tel ordonnancement peuvent par exemple titre le SN < Sequence Number ou le TS Timestamp du paquet RTP. Les paquets peuvent titre ordonnances dans une fille d'attente qui est specifique a chaque chemin physique de reception ou sur une file d'attente commune a un ou plusieurs chemins de reception. Lors de cette ordonnancement on peut assister a des operations de corrections sur les paquets de donnees regus, telle que la suppression de paquets en doublon par exemple. -8- De plus, les latences sur tous les chemins n'etant pas necessairement les memes, la ou les files d'attente dans lesquelles les paquets sont ordonnances peuvent compenser une eventuelle latence et permettre ainsi de remettre en phase les flux de donnees des differents chemins pour faciliter la recomposition du flux original. Les informations contenues dans les paquets de donnees (information TS de < Timestamp > peuvent etre utilisees en reception pour, par exemple, synthetiser une horloge locale, image de I'horloge en emission. L'horloge synthetisee peut servir a asservir le debit de sortie du recepteur et a supprimer la gigue. Dans une version avantageuse, le procede selon I'invention peut comprendre un reassemblage d'une pluralite de paquets regus sur une pluralite de chemins physiques de liaison entre le reseau de transmission et le recepteur, lesdits paquets etant selectionnes sur ladite pluralite de chemins en fonctions d'informations qu'ils contiennent. La selection d'un paquet, par exemple dans une file de paquets ordonnes specifique a un chemin, peut se faire en fonction du numero d'ordre (SN dans le cas RTP) original du paquet de donnees. Pour palier aux phenomenes de latence entre Ies chemins, le procede selon ('invention permet de ne pas prendre en compte instantanement le SN du paquet. Ceci permet aussi de palier a certains problemes, tels que des problemes de perte de paquets par exemple. De plus, ('invention peut d'une maniere avantageuse comprendre une extraction de donnees multimedia d'au moins un paquet regu. Cette extraction permet d'extraire les donnees du flux de donnees multimedia d'origine, d'un paquet dans Iequel ces donnees multimedia ont pu eventuellement etre encapsulees. Les donnees originales peuvent alors avantageusement etre inserees dans une queue de sortie, pour reconstituer le flux de donnees multimedia d'origine.

Au moment de ('insertion des donnees originales dans une queue de sortie, le procede selon ('invention peut comprendre un reordonnancement de ces donnees dans la queue de sortie. Le procede selon ('invention peut avantageusement comprendre une sortie des donnees du flux de donnees multimedia d'origine vers un autre -9- equipement. A ce stade, les donnees peuvent par exemple, titre extraites d'une queue de sortie et titre envoyees vers I'equipement en question. Cette operation peut, dans un mode de realisation particulier, titre realisee par un module permettant une suppression de gigue et un controle de debit de sortie. Avantageusement, le procede selon ('invention peut comprendre une adaptation permettant un formatage des donnees du flux de donnees multimedia a transmettre selon au moins un format predefini. Cette adaptation peut titre realisee en entree de I'emetteur pour formater le flux de donnees multimedia original a transmettre conformement a un format predefini et/ou en sortie du recepteur pour formater le flux de donnees multimedia en sortie du recepteur pour I'envoyer vers un equipement necessitant un formatage particulier en reception. En particulier, le formatage des donnees peut titre effectue a un debit ajuste en fonction d'au moins un parametre choisi dans la Iiste suivante : parametre d'initialisation, un indicateur (1002) de qualite de transmission, un debit quelconque. Par exemple, on pourra piloter le debit d'encodage d'un codeur (MPEG2 par exemple) en fonction des parametres mentionnes au dessus. 20 Ce codeur pourra titre integre ou pas dans I'emetteur. Dans une particularite avantageuse, le procede selon ('invention peut comprendre en reception une correction d'au moins une erreur de transmission de paquets de donnees multimedia recus grace a des donnees de redondance. Cette correction peut, en particulier titre realise par une 25 technique de correction comparable au FEC (<< Forward Error Correction >>). Les erreurs qui peuvent titre corrigees sont, par exemple, une perte de paquet ou une reception de donnees degradees tors de la transmission. Pour ce faire, la transmission de donnees de I'emetteur vers le recepteur peut avantageusement comprendre un envoi de I'emetteur vers le 30 recepteur, de paquets de redondance du flux multimedia a transmettre. Ces donnees de redondance peuvent titre encapsulees dans des paquets conformement a un format predefini. Ces paquets de donnees de redondance, peuvent titre une combinaison quelconque des paquets de donnees du flux de donnees multimedia original avant I'etape de - 10 - fractionnement ou des flux obtenus apres I'etape de fractionnement de ce flux original et peuvent titre envoyes vers le recepteur, sur un seul chemin physique ou de la meme maniere que le paquets de donnees du flux de donnees multimedia, c'est-a-dire sur une pluralite de chemins physiques, eventuellement distincts de ceux utilises par les fragments de flux de donnees multimedia. Selon une particularite avantageuse, le procede selon ('invention comprend une contre reaction, depuis le recepteur vers I'emetteur, permettant de reguler la transmission des paquets de donnees multimedia, ladite contre reaction etant effectuee par un envoi depuis le recepteur vers I'emetteur d'au moins un indicateur relatif a la transmission des paquets sur au moins un chemin physique. Dans une version avantageuse de I'invention, la contre reaction peut titre effectuee sur au moins un chemin physique.

Dans ce cas, le procede selon ('invention peut comprendre une mesure d'au moins un indicateur de qualite de transmission sur au moins un chemin physique de liaison en fonction d'informations relatives soit a la transmission, soit aux donnees multimedia transmises sur ledit chemin, soit aux deux.

Les indicateurs mesures peuvent comprendre les indicateurs suivants : le nombre de paquets recus et debit, Ie nombre de paquets perdus, le nombre de paquets regus desordonne, la gigue, et le nombre de desynchronisation du flux, Ces indicateurs peuvent titre calcules par des methodes classiques Ces indicateurs peuvent avantageusement titre calcules en fonction d'informations concernant la transmission de flux sur chaque chemin physique. Les indicateurs calcules peuvent titre transmis par le recepteur a I'emetteur conformement au protocole TCP/IP, au travers d'un reseau de communication IP de type Internet, identique ou non au reseau utilise pour Ia transmission du flux de donnees multimedia. - 11 -Avantageusement, la contre reaction peut entraIner un ajustement d'un debit de transmission de donnee sur au moins un chemin en fonction d'au moins un indicateur relatif a la transmission. Elie peut aussi, par exemple, entrainer une variation d'un debit global d'encodage sur au moins un encodeur interne ou externe si cela est possible. De plus, les indicateurs peuvent titre recus par un module de reception au niveau de ('emetteur et transmis a un ou plusieurs modules de controles, tel qu'un module de controle de fractionnement, un module de controle de debit d'encodage, un module de controle d'emission de signal sur au moins un chemin, etc. pour titre utilise dans le reajustement du debit des operations effectuees par ces modules. Suivant un autre aspect de ('invention, it est propose un systeme de transmission d'un flux de donnees multimedia depuis au moins un emetteur vers au moins un recepteur au travers d'au moins une liaison comprenant au moins un reseau de communication utilisant le protocole IP, comprenant: - des moyens de mise en paquets, a ('emission, d'au moins une partie des donnees du flux de donnees conformement a un format predefini; - des moyens de transmission des paquets ainsi formes de 20 I'emetteur vers le recepteur au travers dudit reseau de communication ; et - des moyens de liaison dudit emetteur audit recepteur, au moins une partie de ladite liaison etant constituee par une pluralite de chemins physiques distincts predefinis. 25 L'architecture retenue peut avantageusement titre une architecture a microprocesseur et bus, aussi bien pour ('emetteur que pour le recepteur. Cette architecture permet une grande modularite en terme d'entree et de sortie et permet d'accueillir toute forme d'interfaces d'entree et sortie adaptees a ce bus. On peut utiliser typiquement un bus de technologie PCI 30 32 ou PCI 64 (ce qui inclus aussi Compact PCI et PMC). Pour plus d'informations sur ces technologies voir http:/Jwww.pcisig.com/specifications/order form ou https://www.picmg.org/specorderformsec-nonmember.stm ou encore http://shop.ieee.org/ieeestore/Product.aspx?product no=SH94922. - 12 -Selon une version avantageuse, le systeme selon ('invention peut comprendre des moyens de contre reaction du recepteur vers ('emetteur permettant de reguler la transmission des paquets de donnees multimedia, ladite contre reaction etant effectuee par envoi dudit recepteur vers ledit emetteur d'au moins un indicateur a la transmission. Avantageusement le systeme peut comprendre des moyens de correction d'au moins une erreur de transmission de paquets de donnees multimedia regus grace a des donnees de redondance. Ces moyens peuvent de plus comprendre des moyens de constitution de paquets de donnees de redondance servant a la correction de donnees. Enfin le systeme peut comprendre des moyens de stockage de donnees tels qu'une memoire ou des moyens permettant de realiser des fonctions de file d'attente et de synchronisation des differents elements du systeme.

D'autres avantages et caracteristiques apparaltront a la description detaillee d'un mode de realisation nullement limitatif et des figures sur lesquelles : - figure 1 represente un schema general d'utilisation du systeme selon ('invention - figure 2 est un schema d'un exemple de fractionnement et reassemblage du flux de donnees multimedia conformement au procede selon ('invention ; - figure 3 est un schema d'un exemple de fractionnement et de reassemblage du flux de donnees multimedia avec prise en compte de la qualite de transmission conformement au procede selon ('invention - figure 4 un schema representant un exemple de Correction d'erreur ; - figure 5 represente une architecture materielle d'un emetteur selon I'invention - figure 6 represente une architecture materielle d'un recepteur selon I'invention - 13 - - figure 7 est un schema d'un module d'adaptation electrique d'entree selon ('invention ; - figure 8 un schema d'une architecture generate d'un emetteur selon ('invention ; - figure 9 est un schema d'un module d'adaptation electrique de sortie selon ('invention ; - figure 10 est un schema d'une architecture generate d'un recepteur selon ('invention ; et Le schema general d'une utilisation d'un systeme selon ('invention est presente en figure 1. Le systeme est compose entre autre d'un emetteur et d'un recepteur qui sont notamment composes respectivement de deux dispositifs IPSplit 11 et IPCombine 12. Le flux de donnees multimedia F a transporter est compose dans cet exemple d'une source video et audio numerique et peut etre livre selon differents formats et interfaces : MPEG2 Transport Stream sur ASI, MPEG2 Transport Stream sur IP, Video et audio non compresses sur SDI Video et audio compresse sur SDTI IPSplit 11 assure ('encapsulation ou la re-encapsulation de ces donnees et distribue les fragments du flux de donnees multimedia sur plusieurs liens d'acces au moyen de plusieurs equipements d'acces 13 et chemins reseau pour disposer du debit et de la redondance necessaire. L'acces au reseau 14 peut se faire de multiples manieres, I'essentiel etant quill s'agisse d'un reseau IP. On peut citer cornme moyen d'acces - xDSL Fibre Ethernet - IP sur Satellite Wimax

Les fragments du flux de donnees multimedia original F sont achemines dans le reseau 14 par plusieurs chemins. En reception, IPCombine 12 connecte au reseau 14 au moyen d'une pluralite d'equipements 15 de connexion, - 14 -reassemble le flux de donnees multimedia original F a partir de ces fragments de flux. Le flux de donnees multimedia original est delivre au client selon differents formats et interfaces : MPEG2 Transport Stream sur ASI, MPEG2 Transport Stream sur IP, Video et audio non compresses sur SDI Video et audio compresse sur SDTI

Le schema en figure 2 illustre de maniere generale ce que IPSplit 11 et IPCombine 12 assurent comme fonction de repartition du trafic sur plusieurs chemins 21. Les paquets 22 correspondants au flux F d'origine portent un identifiant de sequence pour garantir leur ordre. Si ce n'est pas le cas, ils seront encapsules dans un paquet, typiquement RTP, pour ajouter cette information d'ordre. Le debit de ce flux d'entree est D. Le IPSplit 11 fractionne le flux de donnees original vers les differents chemins 21, en tenant compte des contraintes de debit de chacun des chemins 21. Chaque chemin 21 vehicule un debit Di pour le chemin i. La somme des debits des chemins 21 est superieure ou egale au debit D du flux original F. A Ia reception, le IPCombine 12 rassemble les portions du flux de donnees multimedia original F qui sont vehiculees sur chaque chemin 21 et le flux de donnees multimedia original F est restitue en sortie. Pour gerer cela, les mecanismes de re-ordonnancement mis en place doivent prendre en compte les effets du reseau 14 en matiere - de desordonnancement de paquets 22 dans chaque chemin 21, - de difference de latence entre les differents chemins 21. Ces deux defauts inseres par les reseaux IP 14 utilises sont corriges par le recepteur par des mecanismesde bufferisation et de dequeuing optimises. Le schema en figure 3 illustre une amelioration du processus precedent. En effet, les protocoles de transport utilises, detailles plus loin dans ce document permettent d'obtenir des mesures 32 de la qualite des canaux de transport empruntes par les fragments de flux. On peut en particulier mesurer la gigue, le taux de perte de paquets et le re-o rd onnancement. - 15 - A partir de ces informations, disponibles sur le recepteur, une boucle de contre-reaction 31 permet a I'emetteur d'ajuster le debit alloue a chaque chemin 21 de maniere dynamique, en fonction de la qualite observee sur chaque chemin 21. Des contraintes de debit minimum/maximum peuvent etre allouees par I'utilisateur sur chaque chemin 21 pour lui permettre d'imposer a un processeur de controle 33 de respecter Ies contraintes de la topologie reseau sous-jacente. Dans le schema presente par la figure 3, ceci se materialise de la maniere suivante : - Les paquets 22 sont envoyes sur chaque chemin 21 avec une repartition initiate fixee par I'utilisateur. -Une qualite jugee mauvaise est mesuree sur le chemin Dn. La qualite est jugee correcte sur les autres chemins 21. - L'information remonte immediatement vers I'emetteur. - Le processeur de controle 33 applique une strategie parametrable par I'utilisateur. II peut par exemple decider, par un pilotage 35 de reaffecter le debit differemment : diminuer celui du chemin n en ('occurrence et augmenter celui des autres chemins 21; it peut aussi piloter I'encodeur 36 interne ou externe (le cas echeant) pour faire varier le debit d'encodage par une commande 37 du debit encodeur source. La repartition des fragments de flux est modifiee, dans notre exemple en augmentant le debit des chemins 1 a i au detriment du chemin n. On a donc : pour le chemin 1 : D'1>_D1, etc. pour le chemin i : - pour le chemin n D'n<_Dn, avec D'j representant les nouveaux debits apres correction par le pilotage 35. Lorsque la qualite mesuree redevient correcte, en fonction de la strategie choisie dans le processeur de controle 33, celui-ci tente eventuellement progressivement de retablir les valeurs initialement demandees par I'utilisateur (repartition entre les chemins et debit de I'encodeur 36) ou pas. Ce mecanisme permet aussi de gerer de la redondance de lignes 21. Par exemple, on peut initialement affecter tout le debit sur une ligne 21 - 16 - avec une autre ligne 21 sans debit initial servant de secours. Dans ce cas, en cas de perturbation sur la premiere ligne 21, on peut implementer une strategie pour basculer tout le debit sur la seconde ligne 21. Une autre strategie peut etre de decider de transmettre sur deux lignes 21 et d'affecter le debit sur rune ou I'autre pour alleger celle qui viendrait en defaut. Le tableau suivant illustre certains cas de securisation possibles (non exhaustif). On notera que pour simplifier cette illustration, on ne tient pas compte de ('augmentation de debit faible (<< overhead >>) lies a ('encapsulation du flux de donnees multimedia tors de la fragmentation. Cas de backup Debit IP utile de Debit IP Debit IP transports cas transports cas nominal degrade ligne Lignes en secours complet ('une Ligne 1 (8 Mb/s) D = 8 Mb/s D = 0 Mb/s de I'autre. (Cas degrade sans perte de performance) Ligne 2 (8 Mb/s) D = 0 Mb/s D = 8 Mb/s Lignes en partage de charge et Ligne 1 (8 Mb/s) D/2 = 4 Mb/s D = 0 Mb/s secours complet ('une de I'autre. (Cas degrade sans perte de performances) Ligne 2 (8 Mb/s) D/2 = 4 Mb/s D = 8 Mb/s Lignes en partage de charge et Ligne 1 (4 Mb/s) D/2 = 4 Mb/s D = 0 Mb/s secours partiel ('une de I'autre. Cas degrade avec perte de performances (reduction automatique du debit d'encodage). Ligne 2 (4 Mb/s) D/2 = 4 Mb/s D = 4 Mb/s Tableau 1 : Etude de cas de strategie de securisation pour le transport de 8Mb/s sur differentes configurations de lignes La solution permet aussi de s'adapter a des cas de redondances moins tranches que precedemment. En effet, si par exemple une ligne 21 presente des erreurs importantes ou si son debit devient partiellement indisponible, la solution va basculer une partie du debit sur une autre ligne 21, jusqu'a ce que les conditions redeviennent correctes sur la ligne 21 impactee. 17 - Enfin, les exemples ont ete presentes pour 2 lignes 21 par simplicite, mais la solution permet de travailler sur un nombre illimite de lignes 21. D'autre part, etant donne que le flux de donnees multimedia F envoye est un flux < temps reel >> it n'est pas envisageable de retransmettre des paquets perdus. Le mecanisme de FEC (Forward Error Correction), ajoute au mecanisme de fractionnement et reassemblage permet de se premunir contre un certain taux de perte de paquets 22. Le mecanisme de FEC propose est conforme a la recommendation du Pro-MPEG Forum (Code of Practice 3 ou COP3). La figure 4 donne un apercu du mecanisme general de FEC. IPSplit calcule un nouveau paquet FEC F0, Fl, F3 sur la base des paquets 22 du flux de donnees multimedia original F une information de redondance qui est representee par les paquets FEC. Chaque paquet FEC est calcule sur la base d'un certain nombre de paquets originaux 22 identifies. Les paquets FEC sont ensuite envoyes sur le reseau 14 via un ou plusieurs chemins 21. Le flux de donnees FEC peut suivre, ou pas, la meme strategie de partitionnement que le flux de donnees multimedia original F. Les debits sur les chemins 21 sont augmentes d'une valeur Dfi qui correspond au debit de flux de donnees FEC vehicule sur le chemin i. Ce debit depend entre autre de la puissance de reconstruction du FEC choisi. Le flux de donnees FEC peut en tout ou partie etre vehicule sur au moins un autre chemin physique que ceux empruntes par le flux de donnees multimedia. Durant le transport, le paquet 6 est perdu. A la reception, IPCombine 12 detecte la perte du paquet 6 et utilise ('information de FEC pour le reconstruire. IPCombine 12 utilise les informations des paquets lies a FO (paquets 0, 3 et 9) pour reconstruire 6. Le paquet reconstruit (6r) vient remplacer le paquet perdu dans le flux de donnees multimedia de sortie. L'architecture retenue est une architecture a micro-processeur et bus, aussi bien pour I'emetteur que pour le recepteur. Cette architecture permet une grande modularite en terme d'entree et de sortie et permet d'accueillir toute forme d'interfaces d'entree et sortie adaptees a ce bus. On utilisera typiquement un bus de technologie PCI 32 ou PCI 64 (ce qui inclus aussi Compact PCI et PMC). - 18 - La figure 5 presente ('architecture 50 typique de I'emetteur. Les cartes en entree sont modulaires et it est possible de mettre une ou plusieurs cartes de chaque type, en fonction des interfaces 51 necessaires - une interface d'acquisition ASI avec une connectique coaxiale BNC 75Q, une interface Ethernet avec un connecteur R345 Ethernet ou Fibre Optique, un module encoder ou une interface d'acquisition SDI avec une connectique SDI BNC 75 Q etc. Le micro-processeur 52 et la memoire 53 sont utilises pour les traitements des differents flux de donnees. Un co-processeur 54 pourra titre utilise pour decharger le processeur 52 de certains travaux.

Les signaux sont regus par les interfaces d'entree 51, sont traites par celles-ci dans le cas du codeur, et sont envoyes sur le bus 55 sous leur forme numerique vers la memoire 53 et/ou le processeur 52. Le processeur 52 recupere ces donnees et les traitent, avec ('aide eventuelle du co-processeur 54. Les traitements en question sont detailles dans la suite du document. Le processeur 52 envoie ensuite les donnees vers les interfaces de sorties 56. Ces interfaces de sortie peuvent titre composees de tous types d'interfaces reseaux, par exemple, d'une interface Fast ou Giga Ethernet avec une connectique R345 ou fibre optique.

La figure 6 presente I'architecture 60 typique du recepteur. On retrouve la meme architecture que pour I'emetteur, a la difference que les cartes d'entree sont ici des cartes de generation. La figure 8 presente les details de ('implementation de I'emetteur. On decrit ici ('ensemble de la chaine mais seules les parties faisant ('objet de la presente invention sont presentees en detail. Les autres parties relevent de I'etat de ('art existant. La figure 7 presente un module 70 d'adaptation electrique d'entree. Le flux multimedia F est regu sous forme electrique. Plusieurs interfaces 73 sont possibles (ASI, SDI, Ethernet essentiellement). Ces interfaces 73 - 19 - peuvent etre suivies d'un module 77 de traitement de protocole d'entree. Le module 70 d'adaptation electrique d'entree permet d'encapsuler, grace a un module d'encapsulation RTP 74, les donnees composant le flux F recu dans des paquets RTP 22. Ceci est realise pour les flux Transport Stream, comme pour les flux SDI conformement aux recommandations de : - Pro-MPEG Forum Code of Practice 3 (COP3) - RFC RTP et RFC encapsulation TS dans RTP. Pour plus d'information concernant le RFC RTP voir The Internet Society : RFC 3550 << RTP: A Transport Protocol for Real-Time Applications et RFC 2250 : << RTP Payload Format for MPEG1/MPEG2 Video >>. Le module 70 peut comprendre une horloge 74 et une FIFO 76. Eventuellement, le module 70 peut aussi realiser la compression de signaux video et audio non compresses. Dans ce cas, un module de compression additionnel genere un flux MPEG2-TS et on se retrouve donc dans le meme cas qu'un flux TS exterieur. Enfin, dans le cas d'une entree Ethernet, Ies paquets pourront etre recus soit sous forme de paquets UDP contenant des paquets TS directement, soft de flux de paquets RTP contenant des paquets TS. Dans ce dernier cas, le module d'entree se contentera uniquement d'assurer I'ordre d'insertion des paquets dans la FIFO d'entree.

Le module d'adaptation genere des paquets RTP 22 horodates et ordonnes. Ces paquets sont places dans la FIFO d'entree EIQ dans leur ordre naturel << Sequence Number croissant et continu >>. Les paquets sont extraits de la queue d'entree EIQ en se basant sur le taux de remplissage de la queue d'entree EIQ. Ce taux sera reglable pour absorber plus ou moins de gigue d'entree. Des que le niveau de remplissage depassera le taux fixe, I'ordonnanceur Round Robin ponder-6 (Weighted Round Robin ou WRR) 81 commencera a extraire des paquets 22 de la queue d'entree EIQ pour les traiter. L'objectif est de distribuer les fragments flux vers differents chemins 21 en respectant des contraintes de repartitions initiales. C'est I'etape I de fractionnement du flux vers plusieurs chemins 21. Ces contraintes sont exprimees de la maniere suivante : - on a n chemin [cheminl, chemin2,... cheminn] sur lesquels sont acheminees les fractions du flux de donnees multimedia initial, - 20 -

- chaque chemin i transporte une part de debit initiale note T(i) Ia fraction du debit total que lion souhaite voir absorbee par le chemin;. T(i) = debit du fragment de flux de donnees multimedia original a acheminer sur le chemin;/ debit global de ce flux. n - on a d'autre part ITO) =1 de telle maniere que ('ensemble de =1

ce flux sera absorbe par ('ensemble des chemins 21.

D'autre part, pour permettre la contre reaction 30 (c'est-a-dire ('adaptation dynamique des parametres de repartition en fonction de la qualite observee des chemins 21), des valeurs minimum et maximum de ces taux sont parametrees :

Tmin(i) est la fraction minimum transportable sur le chemin; Tmax(i) est la fraction maximum transportable sur le chemin;

- Avec T max(i) ? 1 i=1

L'ordonnanceur 81 utilise T(i) comme poids pour affecter les paquets extraits de la queue d'entree EIQ dans chacune des queues de sortie EOQi, composes typiquement par des FIFO, correspondant chacune a un chemin 21. Ceci est fait conformement au fonctionnement d'un ordonnanceur Round Robin. Une des proprietes de ('ordonnanceur Round Robin 81 dans ce cas sera de diviser le debit de maniere conforme aux coefficients T(i) de telle maniere que si le debit total est Dtotal, le debit transporte sur le chemin i sera Di = Dtotal.T(i).

Avant d'etre insere dans la queue de sortie EOQi sur le chemin 21 specifie, le paquet RTP est re-encapsule dans un nouveau paquet RTP propre a chaque chemin 21, par des modules 83, appeles << modules SHInsert . C'est I'etape II dans le schema de reference. A ('issue de cette etape, les paquets originaux sont encapsules dans un nouveau paquet RTP appele RTP-SH detaille plus bas.

Les paquets sont envoyes sur le reseau grace au module 82, lors d'une etape III, dite << Etape de Dequeuing et de controle de debit >>. Le module extrait les paquets de la queue de sortie EOQi pour le chemin i. Une version simple du module 82 sera simplement d'extraire les paquets en fonction du taux de remplissage de la queue EOQi associee. Dans ce cas, - 21 - c'est le fonctionnement meme de I'ordonnanceur WRR 81 qui assure la repartition du debit sur chaque chemin. Dans une version plus elaboree, le module 82 peut assurer le lissage et le controle de debit. Dans ce cas, ('implementation s'appuie sur une strategie classique de type << token bucket filter . Le module 82 extrait les paquets RTP-SH des queues de sortie (EOQi) pour les envoyer sur le reseau IP 14 a I'adresse et sur le port UDP correspondant a chaque chemin 21. Cet envoie des paquets RTP-SH est fait au travers d'une couche de communication UDP/IP, comprenant un traitement du protocole UDP et un traitement du protocole IP respectivement par des modules 85 et 86, typiquement sur un support Ethernet. Pour adresser les differents chemins 21, une ou plusieurs adresses IP et une ou plusieurs interfaces Ethernet 87 pourront etre utilisees.

La figure 10 presente les details de ('implementation du recepteur/reassembleur de flux. Les flux 102 de paquets RTP-SH de chaque chemin 21 sont recus sur une ou plusieurs interfaces 101, de type Ethernet par exemple. Chacun des chemins 21 se termine sur un couple (adresse IP, port UDP) distinct. C'est ce qui permet de differ-ender les differents chemins 21 a la reception. La reception des flux 102 est realisee par un module 104 de traitement du protocole IP et un module 105 de traitement du protocole UDP. C'est I'etape de traitement V, faisant intervenir les couches UDP/IP et les interfaces physiques reseau. Apres leur reception, les paquets sont remis au module suivant de traitement du protocole RTP 103, lors d'une etape VI de lecture et traitement du protocole RTP. Les paquets au format RTP-SH sont recus sur chaque chemin 21. Apres les operation classiques de traitement des protocoles IP 104 et UDP 105, deux operations sont effectuees sur ces paquets : • L'ordre des paquets est pris en compte et les paquets RTP sont inseres de maniere ordonnee sur la base du << Sequence Number dans la file d'attente d'entree RIQi. Les paquets sont donc ordonnes dans cette file d'attente. Pour ce faire, le module 103 de traitement du protocole RTP insere le paquet dans la queue RIQi au bon endroit pour que Iordre des SN soit respecte (strictement croissant de la tete vers la queue de la file - 22 -d'attente). Le module de traitement 103 assure aussi la suppression des paquets en doublon. La queue RIQi n'est donc pas une FIFO mais une queue permettant la manipulation de la position des paquets. Ceci necessite egalement que I'algorithme de reassemblage (voir plus loin) maintienne chaque queue d'entree RIQi a un niveau minimum de remplissage pour permettre de reordonner les paquets dans la queue directement. La valeur de ce seuil minimum permet de palier a des desordonnancements plus ou moins importants. D'autre part, les latences sur tous les chemins 21 n'etant pas necessairement les memes, ces files d'attente permettront de compenser cette difference et permettront ainsi de remettre en phase les flux 102 des differents chemins pour assurer une recomposition optimisee du flux de donnees multimedia original F. • Mesurer la qualite sur une periode courte et sur une periode longue du flux de donnees regu sur chaque chemin. Pour ce faire, le module 15 103 de chaque chemin calcule en particulier : - Le nombre de paquets requs ; - Le nombre de paquets perdus ; - Le nombre de paquets requs desordonne ; - La gigue ; 20 - Le nombre de desynchronisation du flux de donnees ; La RFC RTP precise comment calculer ces indicateurs de qualite, en particulier la gigue. Le nombre de paquets requs permet de deduire un debit moyen sur une periode courte et sur une periode longue. Les Timestamps >> requs dans les paquets RTP sont utilises pour synthetiser 25 une horloge locale 96, image de I'horloge distante 75. A ('issue de cette premiere phase, les paquets de chaque chemin 21 sont presents dans des files d'attente separees RIQi, ranges de maniere ordonnee selon le SN (decroissant de la queue vers la tete de la file d'attente). L'etape VII comprend le reassemblage du flux de donnees multimedia 30 d'origine F a partir des fractions de flux 102. Le processus de reassemblage recupere les paquets de chaque file d'attente RIQi, correspondant a chaque chemin (i), pour reconstituer le flux de donnees multimedia d'origine. Pour optimiser ('extraction et eviter de reordonnancer le flux de donnees multimedia de sortie plus que necessaire, on elit le prochain paquet extrait - 23 - sur la base du SN d'origine le plus petit (SNIn). La logique suivante est utilisee par I'ordonnanceur 107 pour reassembler les paquets de maniere optimale en respectant deux contraintes : - permettre le reordonnancement dans les queues RIQi avant le reassemblage. Pour cela, un seuil minimum de << dequeuing est respecte pour chaque queue (Thr(i) pour la queue RIQi). Ce seuil correspond a un nombre de paquets et correspond aussi au desordonnancement maximum que pourra subir un paquet (un paquet deplace de plus de Thr(i) paquets sur un chemin 21 ne sera pas reordonne par le systeme). permettre ('absorption de la difference de latence introduite par les differents chemins de transport. Ceci permet de remettre en phase des flux 102 provenant des differents chemins 21 pour permettre le reassemblage du flux de donnees multimedia d'origine sans reordonnancement dans la queue de sortie (ROQ). Ainsi, si le maximum de reordonnancement n'a pas ete depasse (Thr(i)) dans chaque chemin 21, les paquets 22 qui sorte du module 107 de reordonnancement sont les paquets 22 du flux de donnees multimedia d'origine F, ranges dans ROQ selon leur SNin. La logique est la suivante a chaque iteration (periodique) : - Si toutes les files d'attente IQi ont un taux de remplissage superieur a Thr(i) : - Selectionner parmi toutes les IQi la file d'attente IQj ayant en tete le paquet de SNin le plus petit -Dequeuer IQj de ce paquet et 1'inserer dans ROQ de maniere ordonnee

- Sinon Ne rien faire Une information 1071 de taux de remplissage et SN minimum pour 30 chaque queue RIQi est communiquee a I'ordonnanceur 107. L'insertion dans ROQ est fait de la meme maniere que ('insertion dans RIQi, c'est-a-dire en s'assurant du bon ordre du paquet, selon SNin. Le choix de la valeur de Thr(i) est fait de maniere a eviter une latence artificielle dans les files RIQi. Une valeur de Thr(i) proportionnelle au debit 35 du fragment de flux de donnees multimedia original vehicule sur le chemin 21 d'ordre i permet d'eviter d'introduire une latence artificielle. - 24 - L'algorithme permet aux RIQi des chemins 21 ayant les latences les plus faibles de jouer le role de << ligne a retard >> en bufferisant le flux de maniere adaptative. Les RIQi doivent etre dimensionnees pour permettre d'absorber la difference de latence maximum entre les chemins.

Typiquement, chaque RIQi devra avoir une taille permettant d'absorber Ia difference de latence maximum entre les chemins. Cette taille est proportionnelle au produit du debit maximum du flux de donnees multimedia d'origine et de la difference maximum de latence permise entre les chemins 21.

Le paquet elu par la methode prscedente est insere dans la queue de sortie (ROQ) apres que le RTP-SH a ete extrait de ce paquet, lors d'une etape VIII d'extraction de I'entete de fractionnement et de resequencement effectue par un module 108, appele << SH-Extract&Seq >>. L'insertion dans la queue de sortie (ROQ) s'accompagne d'un eventuel re-ordonnancement selon le SN du flux de donnees multimedia original. Les paquets 21 sont extraits de la queue de sortie par un module 109 de suppression de gigue et de controle de debit. Le vidage des paquets de la file d'attente ROQ et leur transmission au module 90 d'adaptation physique et de protocole est assure le module 109 dont le fonctionnement est active quand le taux de remplissage de ROQ, represents par 1093 depasse un seuil fixe tors de la configuration. L'implementation de ce module 109 est faite sur la base des procedes standard de suppression de gigue et de controle de debit. II s'appuie entre autre sur les TS (<< Timestamps >>) des flux de donnees regues et sur les donnees 1092 transmises d'horloge 96 synthetisse localement, par un module 961. II pilote, par un pilotage 1091, le debit de sortie de I'etage d'un module 90 d'adaptation physique et de protocole pour la sortie des paquets et c'est lui qui extrait les paquets de la queue de sortie (ROQ). Le module 90 d'adaptation physique et protocolaire de sortie du recepteur est decrit dans la figure 9. Le << payload >> des paquets RTP recus par ce module est desencapsule par un module 92 de desencapsulation RTP et leur protocole est adapts au support de sortie. Les donnees brutes ainsi obtenues sont stockees dans une file d'attente. - 25 - Le module 90 assure ensuite, par un module 93 de traitement du protocole de sortie, le formatage de ces donnees brutes au protocole de sortie specifique a ['interface 94 choisie. Dans le cas d'Ethernet avec un protocole RTP en sortie 95, I'etape de reformatage pourra etre supprimee.

Les donnees ainsi reformataes sont envoyees a I'etage de sortie electrique 95. C'est a cet etage ou a I'etage de reformatage protocolaire que le debit de sortie est fixe. Ce debit est fixe par le module 109 de controle du debit et de la gigue en amont par la commande 1091.

Au niveau du recepteur, des indicateurs de qualite 1002 sont calcules par le module 1001 de calcul des indicateurs de qualite de reception, sur la base des informations 1000 transmises par le module 103 de traitement du protocole RTP. Ces informations 1000 comprennent des statistiques de reception par chemin, a savoir, des informations de gigue, de pertes de paquets, de de-sequencement, de taille de queue de reception, etc. Le module 103 calcule par des methodes classiques et pour une serie de periodes temporelles (courte, moyenne, longue), les indicateurs suivants : - Le nombre de paquets regus et debit, Le nombre de paquets perdus, - Le nombre de paquets regus desordonne, La gigue, et - Le nombre de desynchronisation du flux regu Ces donnees sont eventuellement correlees avec la valeur de TS et de SN qui sont transportees dans le flux RTP. Les indicateurs 1002 calcules sont transmis par le module 1003 d'envoi des statistiques de reception, suivi d'un adaptateur reseau 1004, a I'emetteur dans des messages TCP/IP par le biais d'un reseau IP, identique ou pas au reseau utilise pour transmettre Ies flux de donnees audiovisuels. Les donnees sont transmises periodiquement, a ['initiative du recepteur. Celui-ci transmet a une frequence reguliere parametrable par I'utilisateur mais peu aussi transmettre plus frequemment en fonction des valeurs mesurees. L'adaptation reseau est ('adaptation physique au reseau de communication C'est par exemple une adaptation de type Ethernet. -26-L'emetteur du flux de donnees multimedia recoit les indicateurs 1002 de qualite envoyes a I'etape precedente. Une adaptation reseau est effectuee au prealable pour s'adapter au support physique du reseau IP. Les donnees sont revues sous forme de paquets TCP/IP, formates au protocole applicatif precedent. Le module de reception 891 decode les indicateurs de qualite 1002 en fonction du protocole applicatif et les transmet au module 89 de controle du fractionnement et du debit d'encodage. Les debits instantanes sont calcules par le module 82. II s'agit d'un calcul simple de debit se basant sur I'horloge de reference 75 et sur le nombre de paquets ecoules sur une periode donnee. Des methodes classiques d'estimation de debit instantane dans ce type de contexte seront utilisees. C'est dans le module 89 de controle du fractionnement et du debit d'encodage que reside ('intelligence decisionnelle pour modifier ('allocation de debit et modifier le debit d'encodage pour s'adapter aux conditions operationnelles du reseau. Ce module 89, permet de controler le debit d'encodage du module d'adaptation 88, par un pilotage 895, I'ordonnanceur 81 par un pilotage 896, les FIFO EOQi par un pilotage 897, les modules 82 par un pilotage 898. II recoit pour ces controles, des informations 893 de taux de remplissage des FIFOS de sortie EOQi et des informations 892 de debits instantanes des modules 82. Le module 88 d'adaptation pour le pilotage de I'encodeur permet un pilotage 881 du module 70 d'adaptation physique et protocolaire d'entree et en particulier de I'encodeur si le module 70 en contient un, et le cas echeant un pilotage 882 d'un encodeur externe au travers d'une interface RS232, RS422 ou Ethernet. Nous allons maintenant decrire le principe et le format d'un paquet RTP-SH. On definit une structure fixe permettant de modifier les parametres de I'en-tete RTP des paquets. En effet, afin de rester conforme a la norme RTP un certain nombre de parametres de cet en-tete doivent titre modifies en raison du fractionnement du flux d'origine. L'increment constant des numeros de sequences doit titre assure. Le << Payload Type >> doit titre egalement modifie puisque qu'on ne transporte plus le meme type de donnees au sens strict. Enfin le transport d'informations liees a I'horloge est -27-

necessaire pour permettre une synthese d'horloge au niveau du recepteur ainsi que pour mesurer la qualite des liens de communication.

Cet en-tete est ajoute a la charge utile (payload) du paquet. On y sauvegarde les informations originales qui vont etre modifiees. Le header RTP standard a la forme suivante : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ IV=2IPIXI CC IMI PT I sequence number I ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ timestamp ±±±±±±±±±±±±±±±±±±±±±±±±±+±±±±±± + synchronization source (SSRC) identifier I +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+ I contributing source (CSRC) identifiers •• ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ Pour rester compatible avec RTP, en terme de continuite de SN durant ('operation de fractionnement, on definit un header specifique qui vient s'inserer devant le << payload du paquet d'origine, au debut du << payload du nouveau paquet. II se trouve donc entre le header RTP standard et le << payload du paquet d'origine. Ce header specifique, nomme << Splitting Header (SH) est insere apres les CSRC si CC > 0 et apres le << header extension si X=1.

D'autre part, si le FEC RTP est mis en ceuvre conformement au Pro-MPEG COP3, ('insertion du << Splitting Header pour ce type de paquets est effectue de maniere identique a ce qui est presente precedemment.

On peut considerer que le << Splitting Header est un << header specifique au << payload au sens de la RFC RTP. II est donc transparent au niveau RTP puisqu'inclus dans le payload RTP.

De plus, le << Splitting Header propose est defini pour permettre de transporter des informations de TS (<< Timestamp ) de transport. En effet, Ia definition dans RTP du TS est homogene avec la notion de << presentation timestamp definit dans MPEG2 par exemple. II s'agit du moment d'echantillonnage des donnees et non pas du moment de leur transmission (et donc du rythme de leur transmission). II peut etre necessaire, pour avoir un controle fin du < jitter de transport et de la reconstitution de -28- I'horloge de reference, de devoir inserer un TS de transport insere au moment de I'envoi sur le reseau. Le << Splitting Header propose permet de transporter les informationsprecedentes et de transporter le TS original, le Transport Timestamp etant transports dans le header RTP.

Le RTP-SH se presente donc sous la forme suivante : Format de RTP-SH 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ I V=2 I Orig PT I Orig Sequence number I Reserved I ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ 1 Orig Timestamp I ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ • V est la version du << splitting Header . La version presentee est la version 2. • << Orig PT est la valeur de Payload Type dans le flux d'origine. • << Orig Sequence Number est la valeur de << sequence number dans le flux d'origine. • Les 6 derniers bits sont reserves • << Orig Timestamp est la valeur du < tmestamp dans le flux d'origine. Les paquets du flux d'origine ont la structure suivante : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ IV=21PIx1 CC IMI PTin I SNin ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ 1 TSin ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ I synchronization source (SSRC)n) identifier I

I contributing source (CSRC) identifiers I +=+=+=+=+=+=+=+_+=-+=+_+ •+=+=.+=+=+=+=+=+=+=-+=+=+=+=+=+=+=+=+=+=+_+ defined by profile length I ±-±±±-+±±-±±+_.+..._+_±+_.±+_.._±+ ±+ t + ±+ + -+ -±±±+ h acler e: tef =LCf .............................•

............................................ .... ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ I Payload I 2895181 - 29 -..DTD: Les donnees a I'interieur du cadre en pointille sont optionnelles, en fonction des valeurs de X et CC. Le contenu du header RTP est modifie tors du passage dans I'emetteur au niveau SH et dans le recepteur. Les 5 modifications sont faites de la maniere suivante : - I'emetteur substitue les valeurs PT (Payload Type), SN (Sequential Number) et TS (TimeStamp) du paquet d'origine par des valeurs propres au flux fragmentes. PT est une valeur caracteristique d'un flux fragmentes et SN est recalcule par 10 I'emetteur pour repondre a la recommandation RTP, a savoir que Ia valeur SN croit de 1 a chaque paquet. - les autres valeurs restent inchangees dans le Header RTP fixe. - le cas echeant, les valeurs contenues dans la liste de CSRC sont inchangees. 15 le cas echeant, le contenu du << Header Extension >> reste inchange. - le cas echeant, les valeurs du Header > de FEC et de son extension eventuelle restent inchangees. -I'emetteur insere le << Splitting Header > en en-tete du << payload >> du paquet d'origine. Les valeurs originales de << PTin >> et << SNin >> sont recopiees dans le << Splitting Header >>. En sortie de I'emetteur, les paquets des flux fragmentes ont la forme suivante : - 30 - 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ V=2IPIXI CC IMI PTsplit I SNsplit I ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ TSSplit I ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ I synchronization source (SSRC) identifier I :••••J~IJy!L•t~•i~u~uu~u~,u/L•; •i••1RU~u+u~_uu.1J4;, i!~1•,•1 u+u~u~ut,u/L •Z.•_y~1!~u ~,u~• I contributing u T yS Ct,E -t_ T I I contributing source sIù,~I~~ identifiers +=+=+=+=4 =+=+=-fù==-, =4 =+='{-=+=+=+=+="#ù=+=+=+=4 =+=+=+ =+=+=+=+=+=+=+ defined profile length

header extension I V=1 I PTin I SNin I Reserved I ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ TSin ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+ Payload I Le << payload >> de ce nouveau paquet RTP est constitue du << Splitting Header > et du << payload >> du paquet d'origine. Dans le schema precedent, it commence en dessous de la zone en pointilles. PTSpIit >>, << SNSpIit >> et << TSSplit > sont des valeurs inserees par I'emetteur pour correspondre aux exigences de RTP. Ces valeurs seront utilisees pour caracteriser la qualite de la liaison correspondante au chemin que ces paquets emprunteront. << PTin >>, << SNin >> et << TSin >> sont les copies des valeurs du << header > du flux RTP d'origine, elles seront utilisees pour reconstruire le flux a destination.

L'invention n'est pas limitee a I'application a I'exemple decrit cidessus et est applicable a la transmission de tout flux de donnees multimedia.20

Claims

REVENDICATIONS

1) Procede de transmission d'un flux de donnees multimedia (F) depuis au moins un emetteur vers au moins un recepteur au travers d'au moins une liaison comprenant au moins un reseau (14) de communication de type IP, ledit procede comprenant les etapes suivantes : - mise en paquet, a ('emission, d'au moins une partie des donnees du flux de donnees multimedia (F) conformement a au 10 moins un format predefini ; et -transmission des paquets (22) ainsi formes de ('emetteur vers le recepteur, au moins une partie de ladite liaison entre I'emetteur et le recepteur etant constituee par une pluralite de chemins physiques (21) distincts predefinis. 15

2) Procede selon la revendication 1, caracterise en ce qu'il comprend une contre reaction (30), depuis le recepteur vers I'emetteur, permettant de reguler la transmission des paquets (22) de donnees multimedia, ladite contre reaction (30) etant effectuee par un envoi depuis le recepteur vers 20 I'emetteur d'au moins un indicateur (1002) relatif a la transmission des paquets (22) sur au moins un chemin physique (21).

3) Procede selon ('une quelconque des revendications 1 ou 2, caracterise en ce qu'il comprend en outre un fractionnement (I) du flux de donnees 25 multimedia (F) constituant une partition des paquets dudit flux dans au moins un ensemble dit fragment contenant au moins un paquet.

4) Procede selon la revendication 3, caracterise en ce que le fractionnement (I) du flux est effectue a un debit ajuste en fonction d'au moins un 30 parametre, dit poids, determine en fonction d'au moins une donnee choisie dans la liste suivante: parametre d'initialisation, indicateur (1002) de qualite de transmission, debit relatif a une autre operation.- 32 -

5) Procede selon rune quelconque des revendication precedentes, caracterise en ce qu'il comprend en reception une correction d'au moins une erreur de transmission de paquets (22) de donnees multimedia regus grace a des donnees de redondance (FO, Fl, F3).

6) Procede selon rune quelconque des revendication precedentes, caracterise en ce qu'il comprend en outre une distribution (I) du flux de donnees sur une pluralite de chemins (21) physiques de transmission, en fonction d'informations relatives a au moins un chemin (21) de transmission.

7) Procede selon rune quelconque des revendications 3 a 6, caracterise en ce que le fractionnement de paquets (22) de donnees est ajustee dynamiquement en fonction essentiellement d'au moins un debit effectif fixe 15 ou variable de transmission sur au moins un chemin (21).

8) Procede selon la revendication 6, caracterise en ce que le fractionnement de paquets (22) de donnees est ajustee dynamiquement en fonction essentiellement d'au moins une valeur de gigue de transmission 20 sur au moins un chemin (21).

9) Procede selon rune quelconque des revendications precedentes, caracterise en ce que I'etape (II) de mise en paquet comprend au moins une encapsulation des donnees dans un paquet conforme au Real Time 25 Protocole (RTP) sur au moins un chemin (21).

10) Procede selon rune quelconque des revendications precedentes, caracterise en ce qu'il comprend en outre une emission (IV) de paquets de donnees de I'emetteur vers le recepteur, au travers d'une pluralite de 30 chemins (21) physiques, chacun des ces chemins (21) physiques etant adresse par I'emetteur au moyen d'une ou plusieurs adresses IP (Internet Protocole). 10- 33 -

11) Procede selon rune quelconque des revendications precedentes, caracterise en ce qu'il comprend en outre une reception (V), par le recepteur, de paquets de donnees sur une pluralite de chemins (21) physique, chacun de ces chemins (21) physique debouchant sur un couple (adresse IP, port UDP).

12) Procede selon rune quelconque des revendications precedentes, caracterise en ce qu'il comprend en outre une extraction (VIII) de donnees multimedia d'au moins un paquet recu.

13) Procede selon rune quelconque des revendications precedentes, caracterise en ce qu'il comprend en outre un reassemblage (VII) d'une pluralite de paquets recus sur une pluralite de chemins physiques (21) de liaison entre le reseau de transmission (14) et le recepteur, lesdits paquets etant selectionnes sur ladite pluralite de chemins (21) en fonctions d'informations quills contiennent.

14) Procede selon rune quelconque des revendications precedentes, caracterise en ce qu'une reception d'un nouveau paquet est suivie par un ordonnancement de ce paquet dans une file d'attente (RIQi) en fonction d'informations relatives au nouveau paquet recu et/ou a au moins un paquet precedemment rep.

15) Procede selon rune quelconque des revendications precedentes, caracterise en ce qu'il comprend en outre une mesure d'au moins un indicateur (1002) de qualite de transmission sur au moins un chemin physique (21) de liaison en fonction d'informations relatives soit a la transmission, soit aux donnees multimedia transmises sur ledit chemin (21), soit aux deux.

16) Procede selon rune quelconque des revendications 2 a 15, caracterise en ce que la contre reaction (30) entraine un ajustement d'un debit de transmission de donnee sur au moins un chemin (21) en fonction d'au moins un indicateur (1002) relatif a la transmission. 2895181 - 34 -

17) Procede selon rune quelconque des revendications 2 a 16, caracterise en ce que la contre reaction est effectuee sur au moins un chemin physique. 5

18) Procede selon rune quelconque des revendications precedentes, caracterise en ce qu'il comprend une adaptation permettant un formatage des donnees du flux de donnees multimedia (F) a transmettre selon au moins un format predefini. 10

19) Procede selon la revendication 18, caracterise en ce que le formatage des donnees est effectue a un debit ajuste en fonction d'au moins un parametre choisi dans la Iiste suivante : parametre d'initialisation, un indicateur (1002) de qualite de transmission, un debit quelconque. 15

20) Procede selon rune quelconque des revendications precedentes, caracterise en ce que la transmission comprend un envoi de I'emetteur vers le recepteur, de paquets (FO, Fl, F3) de redondance du flux (F) multimedia a transmettre. 20

21) Systeme de transmission d'un flux de donnees multimedia depuis au moins un emetteur vers au moins un recepteur au travers d'au moins une liaison comprenant au moins un reseau (14) de communication utilisant le protocole IP, comprenant: - des moyens (83) de mise en paquets (22), a ('emission, d'au 25 moins une partie des donnees du flux (F) de donnees conformement a un format predefini; - des moyens de transmission des paquets ainsi formes de I'emetteur vers le recepteur au travers dudit reseau (14) de communication ; et 30 - des moyens de liaison dudit emetteur audit recepteur, au moins une partie de ladite liaison etant constituee par une pluralite de chemins (21) physiques distincts predefinis.