FR2935862A1 - Procede de prediction du taux d'erreurs de transmission dans un reseau de communication et serveur mettant en oeuvre un tel procede - Google Patents

Abstract

Pour prédire le taux d'erreurs de transmission dans un flux de paquets de données transmis entre un serveur et au moins un client dans un réseau de communication : le serveur envoie au moins un groupe de paquets au client ; le client calcule une pluralité d'informations statistiques sur le groupe de paquets et les transmet au serveur ; le serveur analyse (710, 720, 730, 735) les informations statistiques de façon à obtenir un indicateur de stabilité du réseau ; et le serveur calcule (715, 725, 740) une prédiction du taux d'erreurs de transmission à partir de l'indicateur de stabilité du réseau.

Description

La présente invention se rapporte à un procédé de prédiction du taux d'erreurs de transmission dans un réseau de communication, ainsi qu'à un serveur mettant en oeuvre un tel procédé. Elle appartient au domaine du transport des données multimédia (audio, vidéo, texte) dans les réseaux de communication de paquets tels que l'Internet ou les réseaux locaux de type IP (en anglais "Internet Protocof'). Dans le cadre de la transmission multimédia sur Internet ou sur des réseaux locaux (LAN, en anglais "Local Area Network"), un serveur de données multimédia doit délivrer un ou plusieurs flux de données (de type vidéo, audio, texte tel que des sous-titres, etc.) vers un ou plusieurs clients. Ces clients reçoivent et consomment ces données, par exemple en jouant la vidéo et l'audio, au fur et à mesure de leur réception. On parle de "streaming" multimédia. Ces flux multimédia sont constitués de données telles que des images, des portions ou tranches (en anglais "slices") d'images ou des portions de sons (en anglais "semples") qui ont pour caractéristique d'avoir une durée de vie utile limitée, c'est-à-dire que ces données doivent impérativement être reçues et traitées par le périphérique récepteur avant une certaine échéance. Cette échéance correspond à l'instant où la donnée est requise pour être affichée ou jouée par le client. Au-delà de cette échéance, la donnée devient inutile et est purement et simplement ignorée par le client. Pour limiter le débit des données et obtenir ainsi des débits compatibles avec celui du réseau sous-jacent, ces différents flux de données sont généralement comprimés, par exemple, pour la vidéo, selon les normes de compression MPEG 2 ou MPEG 4 part 2 ou H.264 et par exemple, pour l'audio, selon les normes de compression AMR, G.711, G.722.1, AAC. Ce sont des normes de compression avec pertes : la compression est très efficace, mais plus elle est forte, plus la donnée multimédia est dégradée. De plus en plus d'équipements disponibles pour le grand public correspondent à cette définition et sont capables d'envoyer de tels flux de données : c'est le cas des caméscopes, appareils photo, caméras de vidéosurveillance, serveurs de vidéo domestique, récepteurs TV, ordinateurs, téléphones. Les flux multimédia (vidéo, audio, texte) destinés à être envoyés peuvent être stockés et comprimés à l'avance sur l'appareil émetteur ou au contraire être capturés, comprimés et envoyés sur un réseau de communication à destination d'un appareil récepteur.

Ces flux multimédia sont transmis sur des réseaux de communication constitués de noeuds d'interconnexion (routeurs, commutateurs, etc.) afin d'acheminer les paquets de données en provenance de dispositifs source jusqu'à des dispositifs destinataires. Ils partagent ces réseaux avec d'autres flux de données (par exemple de la navigation Internet, un jeu vidéo, le transfert d'un fichier vers une imprimante, etc.). Tous ces flux de données sont susceptibles de créer de la congestion sur les réseaux de communication quand ils transitent par un même lien réseau de capacité insuffisante. Les paquets en surplus finissent généralement par être rejetés par le noeud d'interconnexion situé à l'entrée du lien.

La structure du réseau n'est pas connue par les dispositifs émetteurs et récepteurs. De même, les flux présents ne se connaissent pas et leur nombre et leur comportement peuvent être très variables dans le temps. Traditionnellement, les serveurs et les clients utilisent des protocoles de communication mettant en oeuvre des mécanismes de contrôle afin d'éviter de perdre continuellement une grande quantité de données en cas de congestion. Ils permettent de détecter l'apparition d'un phénomène de congestion en fonction des pertes de paquets et ils agissent sur le débit de transmission du flux de données afin de le réduire ou de l'augmenter de façon à être compatible avec la bande passante globale du réseau.

Les mécanismes de contrôle de congestion généralement mis en oeuvre dans les réseaux IP sont de type TFRC ("TCP Friendly Rate Controf', IETF RFC3448) ou AIMD ("Additive Increase/Multiplicative Decrease", IETF RFC2581). Par exemple, le mécanisme AIMD permet de répartir équitablement la bande passante disponible entre tous les flux de données : chaque flux concurrent obtient une part égale en moyenne. AIMD est fondé sur l'utilisation d'une fenêtre glissante, appelée fenêtre de congestion. La taille de cette fenêtre détermine la quantité de données maximale que le serveur est autorisé à envoyer immédiatement sur le réseau sans avoir à attendre le prochain acquittement. Le protocole TCP double la taille de la fenêtre de congestion à chaque RTT (temps de communication aller-retour, en anglais "Round-Trip Time"), c'est-à-dire à chaque acquittement, quand la fenêtre de congestion est inférieure au seuil de démarrage lent (en anglais "slow-start"), puis il augmente la fenêtre d'un segment de données pour chaque RTT (phase d'évitement de congestion, en anglais "congestion avoidance"). Si une perte de congestion survient, la fenêtre de congestion est réduite de moitié. Cet algorithme permet de sonder la bande passante disponible jusqu'à l'obtention d'une perte de paquets indiquant une congestion sur le réseau. Une perte de congestion est généralement décrite comme correspondant à l'expiration d'un temps d'attente (en anglais "timeout") ou à la réception de trois paquets dupliqués.

Le mécanisme de contrôle de congestion permet donc de réduire l'engorgement du réseau et donc de réduire le nombre d'erreurs de congestion. Cependant, il ne permet pas de s'affranchir totalement de celles-ci. L'impact d'une erreur sur un flux multimédia peut être très important. En effet, à cause de la compression, une erreur dans une partie d'un flux va se propager dans les autres parties du flux. Par exemple, si une tranche d'image est perdue, l'image va bien sûr avoir une partie incorrecte, mais à cause de la compression par compensation de mouvement effectuée par les codeurs vidéo modernes (normes MPEG), les images suivantes seront elles aussi affectées. Il est donc important d'essayer de corriger ces erreurs.

La technique la plus courante consiste à redemander les paquets perdus. Cependant, cette technique n'est pas utilisable dans le cas où le flux est transmis avec des contraintes de temps fortes, c'est-à-dire lorsque les données doivent être reçues avant un délai maximal et si ce délai est faible comparé au temps de communication entre le client et le serveur (RTT). Le délai maximal est par exemple lié à la date d'affichage de l'image qui est fixée par le rythme d'affichage des images sur le client. Il est donc nécessaire d'avoir recours à une méthode prédictive de correction d'erreurs.

Les méthodes prédictives consistent à coder les données multimédia à les envoyer de telle sorte que certaines parties puissent être perdues avec un impact faible sur la qualité du média reçu et décodé. Une méthode prédictive de correction d'erreurs classique consiste à créer des paquets de redondance, qui sont envoyés en plus des paquets du flux multimédia. Si un des paquets de données multimédia est absent, le récepteur peut utiliser les paquets de redondance pour recréer les paquets manquants. Les paquets de redondance peuvent être créés par exemple à l'aide d'opérations XOR ou avec des codes de Reed-Solomon.

Une autre méthode prédictive pour limiter l'impact des erreurs consiste à changer le codage du flux multimédia, pour diminuer la dépendance entre les données. On peut par exemple réduire le nombre de macroblocs dans une image utilisant un codage par prédiction de mouvement. Ainsi, une erreur est moins visible car elle a peu de chances de se propager dans les images suivantes. Dans ces deux cas, une difficulté importante consiste à évaluer le niveau de redondance nécessaire. Celle-ci est directement liée au niveau d'erreur dans le réseau. D'une part, si le taux de redondance est inférieur au taux d'erreurs réel du réseau, certaines erreurs ne pourront pas être corrigées ou auront un impact important. D'autre part, si le taux de redondance est trop important, le serveur transmet des informations inutiles. Le débit disponible pour la donnée multimédia est ainsi réduit, ce qui force à la comprimer davantage et dégrade donc sa qualité. Il est donc important d'estimer le taux d'erreurs au plus juste.

Les erreurs de transmission peuvent avoir plusieurs causes : des problèmes de transmission physique (par exemple, des interférences radio lors d'une transmission sans fil) ou des erreurs de congestion. L'invention s'intéresse uniquement à ce deuxième type d'erreurs. Le taux d'erreurs de congestion dépend de plusieurs paramètres : d'une part, du comportement de l'émetteur des données (ses propres données peuvent créer des congestions) et d'autre part, du comportement des autres flux de données utilisant le même réseau (les données des autres flux peuvent aussi créer des congestions). Dans un système où aucune connaissance a priori sur le réseau et sur le comportement des autres flux n'est disponible, l'art antérieur ne fournit aucune méthode pour déterminer le taux de correction à mettre en oeuvre. L'invention cherche à prédire les futurs taux d'erreurs de congestion lors de la transmission des prochains paquets d'un flux multimédia pour permettre un bon ajustement des méthodes prédictives de correction des erreurs.

Dans un article intitulé "Real-Time Packet Loss Prediction based on End-to-End Delay Variation", publié dans IEEE Transactions on Network and Service Management, vol. 2, n° 1, novembre 2005, L. ROYCHOUDHURI et al. décrivent un système qui utilise les mesures des temps de transmission des paquets de données pour calculer une probabilité d'erreur, afin de calculer un niveau de correction d'erreurs à appliquer aux données à envoyer. Ce système présente notamment l'inconvénient de ne pas prendre en compte l'impact d'autres flux transitant dans le réseau. La présente invention a pour but de remédier aux inconvénients de l'art antérieur.

Dans ce but, la présente invention propose un procédé de prédiction du taux d'erreurs de transmission dans un flux de paquets de données transmis entre un serveur et au moins un client dans un réseau de communication, ce procédé étant remarquable en ce qu'il comporte des étapes suivant lesquelles : le serveur envoie au moins un groupe de paquets au client ; le client calcule une pluralité d'informations statistiques sur le groupe de paquets et transmet ces informations statistiques au serveur ; le serveur analyse les informations statistiques de façon à obtenir un indicateur de stabilité du réseau ; et le serveur calcule une prédiction du taux d'erreurs de transmission à 30 partir de l'indicateur de stabilité du réseau.

Ainsi, l'invention permet de minimiser le niveau de redondance dans le flux de données codé pour obtenir un bon compromis entre bande passante et protection contre les erreurs de congestion. Par ailleurs, l'invention utilise les paquets de données envoyées avec très peu d'informations supplémentaires. En outre, l'invention est capable de détecter et de s'adapter automatiquement à différents modes de fonctionnement du réseau. Dans un mode particulier de réalisation, lors de l'étape d'analyse des informations statistiques, le serveur détermine la position des erreurs dans le groupe de paquets. En effet, la position des erreurs caractérise bien certains types de réseaux. Selon une caractéristique particulière, si le serveur détermine qu'une majorité d'erreurs est située en fin de groupe, l'indicateur de stabilité du réseau indique que le réseau est de type stable. Le serveur peut ainsi identifier que le débit du flux est en limite de capacité du réseau. Ce peut être par exemple le cas d'une transmission sur une ligne ADSL montante. Selon une autre caractéristique particulière, si le serveur détermine qu'une majorité d'erreurs est située en début de groupe, l'indicateur de stabilité du réseau indique que le réseau est de type instable. Le serveur peut ainsi identifier le cas d'un flux qui est en concurrence avec de nombreux autres flux qui réagissent de façon rapide : par exemple, une transmission longue distance sur Internet.

Dans un mode particulier de réalisation, le client calcule la capacité du réseau pour chaque paquet du groupe de paquets, définie par B; = S;/d;, où Si est la taille du paquet et d; est la variation, entre deux paquets consécutifs, de la durée de transmission d'un paquet. La capacité du réseau est en effet un paramètre important pour le 30 phénomène de congestion.

Selon une caractéristique particulière, lors de l'étape d'analyse des informations statistiques, le serveur analyse les variations de mesure de la capacité du réseau et en déduit l'indicateur de stabilité du réseau. Même si la mesure de la capacité n'est pas fiable dans certains cas, le fait que la mesure n'est pas fiable constitue en soi une nouvelle information sur le comportement du réseau, qui peut être utilisée pour prédire son comportement. Selon une autre caractéristique particulière, lors de l'étape d'analyse des informations statistiques, le serveur compare la capacité du réseau avec le débit du flux sur le réseau et en déduit l'indicateur de stabilité du réseau. Le rapport entre capacité et débit du flux est en effet un bon indicateur de types de fonctionnements différents du réseau. Selon une caractéristique particulière, si l'indicateur de stabilité du réseau indique que le réseau est de type instable, le serveur calcule une prédiction du taux d'erreurs à partir de statistiques à long terme sur le nombre d'erreurs dans le passé. Les variations à long terme permettent d'obtenir de bons indicateurs de futurs taux d'erreurs lorsque le réseau est instable vu du serveur. Selon une autre caractéristique particulière, si l'indicateur de stabilité du réseau indique que le réseau est de type stable avec une part du débit utilisée par le flux de paquets de données supérieure à un premier seuil prédéterminé, le serveur calcule une prédiction du taux d'erreurs à partir de statistiques sur la position des erreurs dans le groupe de paquets, et si l'indicateur de stabilité du réseau indique que le réseau est de type stable avec une part du débit utilisée par le flux de paquets de données inférieure à un second seuil prédéterminé, le serveur calcule une prédiction du taux d'erreurs à partir de statistiques à court terme sur l'évolution de la durée de transmission des paquets. Ainsi, le serveur utilise la méthode de prédiction d'erreurs la plus 30 efficace en fonction du type de fonctionnement du réseau.

Selon une caractéristique particulière, le procédé comporte en outre une étape suivant laquelle le serveur détermine la fiabilité de la prédiction du taux d'erreurs de transmission à partir de l'indicateur de stabilité du réseau. En effet, suivant les types de réseaux et les méthodes de calcul, le taux d'erreurs prédit est plus ou moins fiable. Cette information est intéressante si on veut utiliser le taux d'erreurs calculé. Selon une caractéristique particulière, le serveur sélectionne une méthode prédictive de correction d'erreurs en fonction de la prédiction du taux d'erreurs de transmission et de la fiabilité de la prédiction.

Le serveur adapte ainsi la méthode de correction d'erreurs, non seulement au taux d'erreurs prédit, mais aussi à la confiance qu'on peut avoir dans la prédiction. Selon une caractéristique particulière, le serveur choisit un taux de redondance prédéterminé d'une méthode de correction d'erreurs en fonction de la prédiction du taux d'erreurs de transmission et de la fiabilité de la prédiction. Si la prédiction est fiable, on peut ainsi avoir un niveau de redondance fixé de façon précise, permettant de corriger le niveau exact d'erreurs et ainsi d'avoir une qualité optimale de transmission. Selon une caractéristique particulière, lorsque les données sont des données vidéo, le serveur choisit un mode de codage intra des données en fonction de la prédiction du taux d'erreurs de transmission et de la fiabilité de la prédiction. En effet, si la prédiction n'est pas fiable, une méthode permettant d'avoir une dégradation progressive et non brutale de la qualité est préférable.

Dans le même but que celui indiqué plus haut, la présente invention propose également un serveur de transmission d'un flux de paquets de données, dans un réseau de communication comportant au moins un client, ce serveur étant remarquable en ce qu'il comporte : un module pour envoyer au moins un groupe de paquets au client ; un module pour recevoir une pluralité d'informations statistiques sur le groupe de paquets ; un module pour analyser ces informations statistiques de façon à obtenir un indicateur de stabilité du réseau ; et un module pour calculer une prédiction du taux d'erreurs de transmission à partir de l'indicateur de stabilité du réseau.

Toujours dans le même but, la présente invention vise aussi un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, remarquable en ce qu'il permet la mise en oeuvre d'un procédé de prédiction tel que succinctement décrit ci-dessus.

Toujours dans le même but, la présente invention vise aussi un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, remarquable en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé de prédiction tel que succinctement décrit ci-dessus, lorsque ce programme est chargé et exécuté par l'appareil programmable. Les caractéristiques particulières et les avantages du serveur, du moyen de stockage d'informations et du produit programme d'ordinateur étant similaires à ceux du procédé de prédiction, ils ne sont pas répétés ici. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit de modes particuliers de réalisation, donnés à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent, dans lesquels : - la figure 1 représente de façon schématique un réseau de communication de données du type réparti susceptible de mettre en oeuvre la présente invention, dans un mode particulier de réalisation ; - la figure 2 représente de façon schématique un mode particulier de réalisation d'un dispositif émetteur adapté pour mettre en oeuvre la présente invention ; - la figure 3 représente de façon schématique l'architecture d'un 30 serveur susceptible de mettre en oeuvre la présente invention, dans un mode particulier de réalisation ; - la figure 4 est un graphique illustrant un exemple non limitatif de contrôle de congestion mis en oeuvre dans le cadre de la présente invention ; - les figures 5a et 5b illustrent schématiquement l'ordonnancement des paquets mis en oeuvre dans le cadre de la présente invention, dans un mode particulier de réalisation ; - les figures 6a et 6b illustrent schématiquement l'élaboration de statistiques mise en oeuvre dans le cadre de la présente invention, dans un mode particulier de réalisation ; - la figure 7 est un organigramme illustrant les principales étapes de la prédiction d'erreurs conforme à la présente invention, dans un mode particulier de réalisation ; - la figure 8 est un graphique illustrant plusieurs exemples non limitatifs de courbes donnant la proportion d'erreurs en fonction de la position des paquets de données dans un groupe de paquets envoyés ; - la figure 9 est un organigramme illustrant les principales étapes du contrôle de débit mis en oeuvre dans le cadre de la présente invention, dans un mode particulier de réalisation ; et - la figure 10 est un organigramme illustrant les principales étapes de la sélection des paquets effectuée par l'ordonnanceur de paquets conformément à la présente invention, dans un mode particulier de réalisation. La figure 1 montre un exemple de réseau de communication de données où la présente invention peut être mise en oeuvre. Un dispositif émetteur ou serveur 101 transmet des paquets de données d'un flux de données à un dispositif récepteur ou client 102 à travers un réseau de communication de données 100. Le réseau 100 peut contenir des noeuds d'interconnexion 103a, 103b (aussi appelés routeurs) et des liaisons 104a, 104b qui créent des chemins entre les dispositifs émetteur et récepteur. Le même réseau peut être utilisé par de nombreux dispositifs serveurs et clients 111, 112 mettant ou non en oeuvre l'invention.

Les noeuds d'interconnexion reçoivent les paquets, les mémorisent temporairement dans une mémoire locale puis les retransmettent dès que possible sur un lien de sortie.

Les noeuds d'interconnexion 103 et le dispositif récepteur 102 peuvent rejeter des paquets de données en cas de congestion, c'est-à-dire en cas de débordement de la mémoire de réception. Les congestions peuvent avoir différentes causes : • D'une part, tous les liens n'ont pas la même capacité : certains liens peuvent avoir un débit plus important que le lien suivant. Si par exemple le lien 104a a un débit de l Gb/s alors que le lien 104b n'a qu'un débit de 100Mb/s, le routeur 103b, une fois sa mémoire de réception pleine, va être obligé de supprimer certains paquets. Pour que ce cas se produise, il suffit que le serveur 101 transmette des données trop rapidement. • D'autre part, la capacité des liens entrant sur un routeur peut être supérieure à la capacité d'un lien sortant. Si par exemple les paquets envoyés par les serveurs 101 et 111 utilisent le même lien 104b, si le débit cumulé des deux serveurs est supérieur à la capacité du lien 104b, le routeur 103 va rejeter certains paquets. Dans ce cas, la congestion est créée par l'ensemble des flux utilisant le réseau. En fonction du réseau, le nombre de flux concurrents sur un même chemin peut parfois être très grand ; sur Internet, plusieurs dizaines ou centaines de flux peuvent être en compétition. Le réseau 100 peut être par exemple un réseau sans fil du type WiFi / 802.1 l a ou b ou g, ou un réseau Ethernet, ou encore, comme Internet, il peut être composé de liens de différents types. Le dispositif émetteur 101 peut être n'importe quel type de dispositif de traitement de données susceptible de coder et de fournir un flux de données à un dispositif récepteur. A titre d'exemple nullement limitatif, le dispositif émetteur 101 peut être un serveur de flux capable de fournir un contenu à des clients sur demande, par exemple en utilisant le protocole RTP (protocole de transport en temps réel, en anglais "Real-time Transport Protocof') sur UDP (protocole de datagramme utilisateur, en anglais "User Datagram Protocof') ou DCCP (protocole de contrôle de congestion de datagramme, en anglais "Datagram Congestion Control Protocof') ou n'importe quel autre type de protocole de communication.

Le dispositif émetteur 101 peut mettre en oeuvre un algorithme de contrôle de congestion du type mentionné plus haut, à savoir, TFRC ou encore AIMD. Le dispositif récepteur 102 reçoit les données, les décode et les affiche avec une latence faible. Tant le dispositif émetteur 101 que le dispositif récepteur 102 peut être par exemple du type représenté sur la figure 2, décrite ci-dessous. La figure 2 illustre en effet notamment un dispositif émetteur 101 ou récepteur 102 adapté pour incorporer l'invention, dans un mode particulier de réalisation. De préférence, le dispositif émetteur 101 comporte une unité centrale de traitement (UC) 201 capable d'exécuter des instructions provenant d'une mémoire morte (ROM) de programmes 203 à la mise sous tension du dispositif émetteur, ainsi que des instructions concernant une application logicielle provenant d'une mémoire principale 202 après la mise sous tension. La mémoire principale 202 est par exemple du type mémoire vive (RAM) et fonctionne comme zone de travail de l'UC 201. La capacité de mémoire de la RAM 202 peut être augmentée par une RAM facultative connectée à un port d'extension (non illustré).

Les instructions concernant l'application logicielle peuvent être chargées dans la mémoire principale 202 à partir d'un disque dur 206 ou bien de la ROM de programmes 203 par exemple. De façon générale, un moyen de stockage d'informations qui peuvent être lues par un ordinateur ou par un microprocesseur, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Ce moyen de stockage est intégré ou non au dispositif 101 et est éventuellement amovible. L'exécution du ou des programmes mentionnés ci-dessus peut avoir lieu par exemple lorsque les informations stockées dans le moyen de stockage sont lues par l'ordinateur ou par le microprocesseur.

L'application logicielle, lorsqu'elle est exécutée par l'UC 201, entraîne l'exécution des étapes des organigrammes des figures 5a et 5b, 7, 9 et 10 sur le serveur et des figures 6a et 6b sur le client.

Le dispositif émetteur 101 ou récepteur 102 comporte en outre une interface réseau 204 qui permet sa connexion au réseau de communication 100. L'application logicielle, lorsqu'elle est exécutée par l'UC 201, est adaptée pour réagir à des paquets en provenance d'autres dispositifs 101 et 102, reçus par le biais de l'interface réseau 204 et pour fournir des paquets à d'autres dispositifs 101 et 102 par l'intermédiaire du réseau 100. Le dispositif émetteur 101 ou récepteur 102 comporte de plus une interface utilisateur 205, constituée par exemple d'un écran et/ou d'un clavier et/ou d'un dispositif de pointage tel qu'une souris ou un crayon optique, pour afficher des informations pour un utilisateur et/ou recevoir des entrées de celui- ci. Cette interface est optionnelle. Un appareil émetteur est par exemple un micro-ordinateur, une station de travail, un assistant numérique, un téléphone portable, un caméscope numérique, un appareil photo numérique, une caméra de vidéosurveillance (par exemple du type Webcam), un lecteur DVD, un serveur multimédia ou encore un élément routeur dans un réseau. Cet appareil peut intégrer directement un capteur numérique d'images, ou, en option, être connecté à différents périphériques tels que, par exemple, une caméra numérique (ou un scanner ou tout moyen d'acquisition ou de stockage d'image) reliée à une carte graphique et fournissant à l'appareil des données multimédia. L'appareil émetteur peut aussi avoir accès à des données multimédia sur un support de stockage (par exemple le disque dur 206) ou encore recevoir un flux multimédia à traiter, par exemple en provenance d'un réseau. Un appareil récepteur est par exemple un téléviseur, un micro- ordinateur, un vidéo projecteur, ou un boîtier décodeur ou adaptateur (en anglais "set top box") relié à un écran. Cet appareil peut intégrer un dispositif de rendu du média (écran ou haut-parleur) ou être branché sur un tel dispositif. La figure 3 illustre l'architecture fonctionnelle du serveur 101, dans un mode particulier de réalisation.

Dans l'exemple nullement limitatif où les données considérées sont des données vidéo, le serveur dispose en entrée d'une vidéo en provenance par exemple d'un capteur 305 (par exemple une caméra). La vidéo est fournie à un codeur vidéo ou codec 310 qui code la vidéo dans un format connu (par exemple H.264) avant de stocker le résultat dans une mémoire tampon ou buffer 325 sous forme de paquets prêts à être envoyés. En variante, le serveur pourrait recevoir une vidéo déjà codée en provenance d'un autre réseau, par exemple dans le cas d'une passerelle domestique (en anglais "home gateway') recevant une chaîne de télévision par Internet. Le codec 310 permet de transcoder la vidéo pour adapter son débit à la bande passante du réseau à la maison, qui est par exemple un réseau sans fil. Comme dans le premier cas, les données créées sont stockées dans le buffer 325. Le codec 310 est commandé par un module de contrôle de débit 320. Le module 320 détermine la quantité et le type de données que peut produire le codeur 310. Pour cela, classiquement, il utilise les informations de débit réseau provenant d'un module de contrôle de congestion 335, ainsi que le niveau d'erreurs prédit par un module d'évaluation ou estimation des erreurs 340. Le module de contrôle de débit 320 calcule la proportion du débit qui doit être allouée à la redondance à ajouter au média. Il peut aussi choisir le type de redondance : par exemple, code de Reed-Solomon ou code fontaine ou mode de codage de la vidéo préservant des redondances en augmentant par exemple la proportion de macroblocs intra. Les paquets stockés dans le buffer 325 sont lus et envoyés sur le réseau par un module ordonnanceur de paquets 330 chargé de l'envoi des paquets. Le fonctionnement du module 330 est décrit plus en détail ci-après en liaison avec la figure 5b. Le module ordonnanceur de paquets 330 décide des dates d'envoi des paquets en fonction du débit instantané calculé par le module de contrôle de congestion 335. Le module de contrôle de congestion 335, décrit plus en détail ci-après en liaison avec la figure 4, calcule le débit disponible sur le réseau. Pour effectuer ces calculs, le module 335 utilise les informations reçues du client à travers le réseau, parmi lesquelles les événements de perte de paquets, le temps de communication aller-retour sur le réseau (RTT). Ces informations sont calculées par le récepteur 102 et peuvent être transmises classiquement en utilisant les messages RTCP du protocole RTP. D'autres informations de statistiques d'erreurs sont aussi calculées par le client (comme décrit plus en détail ci-après en liaison avec la figure 6) et transmises au module d'estimation des erreurs 340. Le module 340 utilise ces informations de statistiques d'erreurs pour calculer une prédiction des futurs taux d'erreurs et de leur fiabilité, comme décrit plus en détail ci-après en liaison avec la figure 7. Cette information est ensuite transmise au module de contrôle de débit 320 (comme illustré sur la figure 9 décrite plus loin) et au module ordonnanceur de paquets 330 (comme illustré sur la figure 10 décrite plus loin) pour adapter les données envoyées. Le module de contrôle de congestion 335 calcule la quantité de données envoyée à chaque instant sur le réseau. En effet, si on envoyait tous les paquets de données composant une image en un temps très court, on créerait vraisemblablement une congestion du réseau. Il est donc souhaitable de lisser l'envoi des paquets de données, pour éviter d'envoyer trop de paquets simultanément. Il convient aussi de s'adapter à l'état de congestion du réseau en faisant varier le nombre de paquets qu'on envoie. Le contrôle de congestion le plus connu est celui de TCP, qui est de type AIMD. Cet algorithme fonctionne en augmentant de façon progressive le débit des données envoyées tant que le client signale que les paquets sont bien reçus et tant que le débit des données envoyées est inférieur au débit des données produites. En moyenne, TCP envoie un paquet en plus pour chaque aller-retour correct, ce qui donne une augmentation linéaire du débit des données envoyées. Lorsqu'une erreur apparaît, cela signifie que le réseau est congestionné ; en réaction, le débit est divisé par deux. Ce fonctionnement est illustré sur le graphique de la figure 4, qui représente le débit en fonction du temps. Lorsqu'il n'y a pas de pertes, le débit augmente linéairement. Les événements de pertes 410, 412, 414, 416 provoquent une chute du débit disponible. On peut parfois avoir plusieurs événements de pertes très rapprochés et donc des baisses rapides très importantes.

A cause du temps de transmission du paquet et du temps pour recevoir l'information si le paquet a bien été reçu, AIMD a un comportement étroitement lié au temps de communication aller-retour du réseau (RTT). Dans un réseau local ou à courte distance, le RTT peut être très bas, typiquement de l'ordre de 0,1 milliseconde. On peut donc avoir de très rapides variations de débit réseau par comparaison avec la vitesse du codeur (par exemple, une image toutes les 40 ms). On peut remarquer qu'à cause de sa vitesse de variation étroitement liée au RTT, le contrôle de congestion n'assure une répartition égale des débits 10 qu'entre des flux de même RTT. Comme AIMD, un algorithme de type TFRC fonctionne en utilisant aussi les événements de perte de paquets et un calcul de RTT. Il calcule le débit en suivant une équation qui doit donner un débit comparable à celui de TCP avec un RTT équivalent, mais avec des variations plus lissées. 15 Dans les deux cas, le module de contrôle de congestion 335 reçoit des informations de contrôle provenant du client lui permettant de calculer le taux de pertes ou les événements de perte ainsi que le temps de RTT. En utilisant ces informations, il calcule un débit réseau disponible. Il peut donc informer le module ordonnanceur de paquets 330 du débit disponible 20 sur le réseau. L'information de débit est aussi envoyée au module de contrôle de débit 320 pour que le codeur 310 puisse l'utiliser pour adapter la taille des prochaines images. Si le débit réseau est supérieur au débit maximal du codeur, celui-ci reste à son débit maximal. 25 Le module ordonnanceur de paquets 330 utilise l'information de débit calculée par le module de contrôle de congestion 335 pour décider des dates d'envoi des paquets. Une solution idéale consiste, pour le module ordonnanceur de paquets 330, à être activé à la date précise de l'envoi du prochain paquet. Cette 30 solution idéale peut se réaliser si on dispose d'une horloge très précise ou si le module ordonnanceur de paquets 330 peut être activé par la réception d'un paquet du réseau ou encore si le module ordonnanceur de paquets 330 peut être actif en permanence et donc utiliser la totalité du temps de calcul disponible de l'UC 201. Malheureusement, en pratique, dans le cas d'une application de streaming sur RTP sur une machine réelle de type PC avec un système d'exploitation qui n'est pas temps réel, le processus d'ordonnancement doit partager le temps de calcul disponible avec d'autres modules (par exemple le module de contrôle de débit 320, le module de contrôle de congestion 335 et/ou le codec 310) et avec d'autres applications et il ne peut pas être activé à une date précise. L'horloge disponible pour activer un processus a une résolution de l'ordre de 1 ms. Il est à noter que cette horloge d'activation est différente de l'horloge permettant de mesurer le temps, laquelle peut être très précise, avec une résolution de quelques microsecondes. Les figures 5a et 5b illustrent un mécanisme permettant d'obtenir un débit moyen égal au débit calculé par le module de contrôle de congestion 335.

Le résultat de l'exécution de l'algorithme d'ordonnancement est représenté sur la figure 5a. Des groupes de paquets sont envoyés rapidement et sont séparés par des intervalles de temps variables. La taille de chaque groupe est calculée en fonction du temps entre deux groupes de paquets et du débit calculé par le module de contrôle de congestion 335.

Comme le montre l'organigramme de la figure 5b, à l'étape 510, le module ordonnanceur de paquets 330 est activé par une horloge après un temps d'attente. Puis l'étape 515 consiste à mesurer le temps écoulé depuis la dernière activation. Pour cela, la valeur courante de l'horloge de mesure du temps est lue et cette valeur est comparée à la date de la dernière activation.

En pratique, sur un PC sous Windows XP ou VISTA en mode multimédia, on peut obtenir une valeur de durée d'inactivité proche de 2 ms. La valeur du débit calculé par le module de contrôle de congestion 335 est ensuite lue à l'étape 520: par exemple, 40Mb/s est une valeur réaliste pour le débit maximal d'un flux vidéo haute définition de bonne qualité.

On peut ainsi calculer la taille du groupe de paquets à envoyer, lors d'une étape 525. Dans l'exemple ci-dessus, pour un débit de 40Mb/s et 2 ms depuis la dernière activation du module ordonnanceur de paquets 330, il faut obtenir un groupe de 80 kb. Si les paquets ont une taille moyenne de 1000 octets, le groupe aura donc une taille de 10 paquets. Le nombre actuel de paquets n est mis à 0. A l'étape 530, le prochain paquet à envoyer est sélectionné. On peut par exemple choisir le plus ancien paquet en attente. On verra plus loin, en liaison avec la figure 10, d'autres méthodes de sélection des paquets, tenant compte des erreurs. Dans le cas où plus aucun paquet n'est disponible, on peut directement passer à l'étape 545 pour arrêter l'envoi du groupe. Dans ce cas, le module de contrôle de congestion 335 est informé qu'il n'y a plus de paquet disponible, afin qu'il n'augmente plus le débit réseau calculé. A l'issue de l'étape 530, on vérifie lors d'un test 535 si la somme de la taille totale des paquets déjà envoyés dans le groupe et de la taille du nouveau paquet est inférieure à la taille cible. Si la taille est plus petite (test 535 positif), le paquet peut être envoyé (étape 540). Au moment de l'envoi, le paquet i est marqué avec : • le numéro de séquence si, incrémenté à chaque paquet, • le numéro d'ordre n; dans le groupe (la taille actuelle du groupe n), • la date d'envoi Ti (la date courante). La taille actuelle du groupe n est incrémentée. Ces informations seront ensuite utilisées à la réception pour calculer les caractéristiques du réseau. On revient ensuite à l'étape 530 de sélection du prochain paquet. Si, lors du test 535, la taille du paquet sélectionné est trop grande (test 535 négatif), le paquet n'est pas envoyé. Le traitement du groupe de paquets est terminé. Le module ordonnanceur de paquets 330 s'arrête alors jusqu'à la prochaine activation. Dans le mode particulier de réalisation décrit ci-dessus, tous les paquets sont envoyés dans des groupes de paquets. En variante, on peut prévoir que certains paquets soient envoyés en continu avec un calcul précis de la date d'envoi et que de temps en temps, un groupe de paquets soit envoyé, dans le but d'obtenir des informations sur le comportement du réseau. Le client calcule plusieurs statistiques sur les réceptions de paquets : le nombre de paquets reçus à chaque position dans le groupe de paquets (mémorisé dans une table notée rec[pos]), le nombre de pertes à chaque position (mémorisé dans une table notée perte[pos]) et les estimations de capacité du réseau (mémorisées dans une table notée nb[capa]). Il calcule aussi le nombre total de pertes P et la durée courante de transfert D.

Comme le montre l'organigramme de la figure 6a, la réception d'un premier paquet sur le client active l'algorithme à l'étape 610. On passe ensuite à l'étape 615 pour recevoir le paquet. Si le paquet est déjà en attente dans le buffer de la carte réseau, la date de réception n'est pas valable : en effet, on ne peut pas avoir une mesure précise de la date de réception. Si aucun paquet n'est encore prêt, on attend de façon active (c'est-à-dire en utilisant la totalité du temps de calcul disponible de l'UC 201) le prochain paquet pendant une courte durée (par exemple 0,1 ms). Si au bout de cette durée aucun message n'est prêt, l'algorithme se met en attente (étape 655) pour permettre à d'autres modules et/ou à d'autres applications d'utiliser l'UC 201. Si un message arrive durant l'attente, il est marqué avec la date d'arrivée précise. Un paquet i a donc quatre valeurs associées : • le numéro de séquence si, • le numéro d'ordre n; dans le paquet, • la date d'envoi Ti, • la date de réception t;. On passe ensuite au test 320, qui consiste à vérifier qu'aucun paquet n'a été perdu (s; = s;_, + 1). Si au moins un paquet a été perdu (test 620 positif), le nombre total de pertes P est incrémenté et on passe à l'étape 625 pour évaluer la position de la perte.

Si le paquet courant est en début de groupe (n; = 0) alors la perte est estimée sur le groupe précédent (étape 630, lorsque le test 625 est positif). Dans ce cas, on incrémente le nombre de pertes à la position qui suit le paquet précédent reçu (perte[n;_1+1 ]++). Dans cette version simple de l'algorithme, on ne mesure pas correctement les séquences de paquets perdus. Si plusieurs paquets consécutifs sont perdus, seul le premier est pris en compte.

Si le test 625 montre que le paquet reçu n'est pas en tête de groupe (n; > 0, test 625 négatif) alors la perte est estimée à la position précédente dans le même groupe (étape 635) (perte[n; û 1]++). Après les étapes 630 ou 635, les valeurs du paquet courant sont mémorisées à l'étape 650 puis l'algorithme retourne à l'étape 615 d'attente du paquet suivant. Si à l'étape 620, aucune perte n'est détectée (test 620 négatif), on passe au test 640. On vérifie alors la validité de la date de réception du paquet courant t; et de la date de réception du paquet précédent t;_I. Si une des deux dates n'est pas valable (test 640 négatif), on passe directement à l'étape de mémorisation 650. Si les deux dates sont valables (test 640 positif), on passe à l'étape 645 de calcul de la capacité. Pour cela, on calcule d'abord la durée de transfert D; = t; û Ti. Cette valeur est mémorisée dans la variable D représentant la durée courante de transfert. Puis on calcule la dispersion entre les paquets i et i-1, définie par d; = D; û D;_I. La dispersion d; représente donc la variation, entre deux paquets consécutifs, du temps de transfert, c'est-à-dire de la durée de transmission d'un paquet. La capacité est alors B; = S;/d;, où Si est la taille du paquet i. On mémorise alors la valeur de capacité ainsi calculée dans la table nb, ce qu'on note nb[B;/Q]++. La case k=B;/Q est incrémentée, ce qui signifie que la capacité B; se trouve entre k.Q et (k+1).Q. Q permet de régler la précision des statistiques. Pour de la vidéo haute définition, on peut par exemple prendre Q = 1 Mb/s. On passe ensuite à l'étape 650 de mémorisation. Comme le montre la figure 6b, régulièrement (par exemple une fois par seconde), une autre routine du client est activée : la routine d'envoi des statistiques 660. Le client envoie ses statistiques au serveur (tables rec[pos], perte[pos], nb[capa]) en utilisant par exemple un message RTCP, à l'étape 665. Les tables sont ensuite remises à zéro à l'étape 670. D'autre part, le client envoie très souvent au serveur (par exemple une fois par RTT) les valeurs des pertes de paquets P et la durée du transfert D. Les pertes P sont alors également remises à zéro à l'étape 670.

L'organigramme de la figure 7 illustre les principales étapes de l'analyse qui est faite des statistiques établies avec l'algorithme des figures 6a et 6b dans le but d'établir des prévisions sur les prochaines erreurs. L'objectif est de distinguer plusieurs cas de réseaux très différents puis de calculer dans chacun des cas une estimation des futures erreurs. A réception des statistiques, lors d'une première étape 710, le serveur analyse la position des erreurs. Pour cela, on peut calculer pour chaque position dans les groupes de paquets la proportion de paquets perdus par rapport à tous les paquets perdus : perte[n] E perte[i] Le graphique de la figure 8 montre trois exemples de courbes d'erreurs par position dans les groupes de paquets de données, obtenues lors de simulations de différents types de réseaux. Dans un réseau où les congestions sont provoquées principalement par le flux contrôlé, les erreurs sont provoquées directement par la taille des groupes de paquets envoyés. Dans ce cas, les erreurs se trouvent principalement situées en fin de groupe (courbe à points carrés sur la figure 8). Dans un tel réseau, les erreurs sont directement induites par le comportement du flux contrôlé et sont donc facilement prévisibles : elles sont directement liées au débit ou à la position du paquet. On teste donc à l'étape 710 la position des erreurs dans les groupes de paquets. Si la majorité des erreurs se trouvent en fin des groupes (par exemple dans le dernier quart) (test 710 positif), on passe à l'étape 715 pour estimation des erreurs dans un réseau stable avec une part importante du débit utilisée par le flux contrôlé, c'est-à-dire une part du débit utilisée par le flux contrôlé supérieure à un premier seuil prédéterminé. Dans un réseau où de nombreux flux sont en compétition avec des temps de réaction beaucoup plus rapides que celui du flux contrôlé, la majorité des erreurs se trouvent au début des groupes de paquets (courbe à points triangulaires sur la figure 8) (test 710 négatif et test 720 positif). Dans un tel système, les erreurs sont difficiles à prévoir car les flux opposés peuvent réagir beaucoup plus rapidement que le flux contrôlé. Un tel réseau est dit de type instable. Ainsi, à l'étape 720, on teste la position des erreurs dans les groupes pour déterminer si une majorité se trouve en début des groupes (par exemple dans le premier quart). Si c'est le cas, on passe à l'étape 725 pour évaluer la probabilité d'erreur dans le cas instable. Si les erreurs ne se trouvent ni en début, ni en fin des groupes (tests 710 et 720 négatifs), on utilise les statistiques sur les temps de transmission pour déterminer le type de réseau. A l'étape 730, on utilise les mesures de capacités calculées par le client. Si les mesures de capacités sont très variables (test 730 positif), cela indique que le réseau est partagé avec de nombreux autres flux avec des caractéristiques variables. On revient alors au cas d'un réseau instable analysé à l'étape 725. Si la capacité est précise (test 730 négatif), on peut comparer cette capacité au débit calculé par le module de contrôle de congestion 335, lors d'un test 735. Si le débit est faible (par exemple moins de 10 % de la capacité) (test 735 positif), on a un réseau stable avec une part faible du débit utilisée par le média (courbe à points en losange sur la figure 8), c'est-à-dire une part du débit utilisée par le flux contrôlé inférieure à un second seuil prédéterminé, cas analysé à l'étape 740 ; sinon on a un réseau stable avec une part importante du débit pour le flux média contrôlé (étape 715). Dans le cas d'un réseau instable (étape 725), les estimations ne peuvent pas être précises. On utilise donc simplement des statistiques à long terme (sur plusieurs minutes passées) du nombre d'erreurs pour calculer une probabilité d'erreur. Le futur taux d'erreurs est prédit comme égal au taux d'erreurs moyen du passé. On sait cependant que cette estimation n'est pas précise. Cette double information (le taux et le fait que la prédiction est imprécise) est transmise aux modules clients (étape 750), c'est-à-dire aux modules du serveur utilisant cette information, à savoir, le module de contrôle de débit 320 et le module ordonnanceur de paquets 330.

Dans le cas d'un réseau stable avec une part de débit faible disponible pour le flux média contrôlé (étape 740), on peut utiliser les statistiques à très court terme. En effet, le réseau et les flux concurrents ont un fonctionnement compatible avec la vitesse de réaction du serveur. On peut donc utiliser les informations des dernières secondes comme prédiction du futur comportement. En particulier, les évolutions du temps de transfert entre le serveur et le client (D) sont connues pour être un bon prédicteur du taux d'erreurs (voir par exemple l'article de L. ROYCHOUDHURI et al. cité en introduction). On peut donc calculer une estimation du futur taux d'erreurs avec une bonne confiance. Cette information est ensuite transmise aux modules clients (étape 750). Dans le dernier cas, on a un réseau stable et utilisé de façon importante par le flux média (étape 715). Dans ce cas, les congestions sont provoquées directement par les évolutions du débit du flux. Les erreurs sont dans ce cas directement liées au débit du flux et à la position des paquets dans les groupes de paquets. Etant donné que, dans l'algorithme de la figure 5b, la taille des groupes de paquets est calculée en fonction du débit, on peut dans ce cas n'utiliser que les statistiques d'erreurs par position comme prédiction du futur taux d'erreurs avec une bonne confiance. Cette information est transmise aux modules clients (étape 750). L'organigramme de la figure 9 illustre le fonctionnement du module de contrôle de débit 320 du serveur.

Le module 320 utilise les informations d'estimation des futures erreurs issues de l'algorithme de la figure 7, reçues à l'étape 910. Si, lors d'un test 920, ces estimations sont considérées comme peu fiables (c'est-à-dire si ces informations ont été calculées à l'étape 725 de la figure 7), on passe dans le mode intra à l'étape 925.

En effet, comme les prévisions sont peu précises, un système de correction d'erreurs ou FEC (en anglais "Frame Error Correction") peut s'avérer peu performant car le taux d'erreurs peut souvent dépasser les capacités de correction des FEC. En effet, classiquement, les codes correcteurs d'erreurs ne peuvent pas corriger plus qu'un nombre fixé d'erreurs. Au-delà de ce taux d'erreurs, ils ne corrigent plus rien, les informations de FEC deviennent inutilisables. Dans ce cas, un mode de codage redondant peut donc être préféré car toute information correctement transmise permettra d'améliorer la qualité du flux reçu. A l'étape 925, le module de contrôle de débit 320 choisit donc un mode de codage avec des macroblocs intra plus fréquents. La proportion de macroblocs intra est choisie pour supporter le taux d'erreurs prédit. De façon simple, on peut utiliser le taux d'erreurs prédit comme proportion de macroblocs intra disposés de façon aléatoire dans le flux vidéo. Si, lors du test 920, les prédictions sont évaluées comme fiables (test 920 positif), on passe au test 930 pour savoir si on a un taux d'erreurs fixe ou un taux d'erreurs variable par position. Si le taux d'erreurs est fixe (test 930 positif), on passe à l'étape 940, où on choisit des paquets de codes correcteurs de type Reed-Solomon en nombre suffisant pour supporter le taux d'erreurs prédit. Si le taux d'erreurs n'est pas fixe (test 930 négatif), on peut utiliser un code fontaine, par exemple en utilisant les algorithmes de type Digital Fountain, pour calculer un grand nombre de paquets de redondance (étape 935). Les paquets sont ensuite transmis au module ordonnanceur de paquets 330. Ainsi, le serveur sélectionne une méthode prédictive de correction d'erreurs en fonction du taux d'erreurs de transmission prédit et de la fiabilité de cette prédiction. L'organigramme de la figure 10 montre l'algorithme de sélection des paquets de l'étape 530 de la figure 5, cette sélection étant effectuée par le module ordonnanceur de paquets 330. Le module 330 utilise aussi les informations de prédiction des erreurs, issues de l'algorithme de la figure 7, reçues à l'étape 1010. Si les prédictions sont considérées comme non fiables (test 1020 négatif), la sélection s'effectue simplement en prenant tous les paquets dans l'ordre d'arrivée, c'est-à-dire en mode FIFO (premier entré, premier sorti, en anglais "First ln First Out") (étape 1025). Le taux d'erreurs a déjà été pris en compte dans le contrôle de débit du codage.

Si les prédictions sont considérées comme fiables et que le taux d'erreurs est fixe (tests 1020 et 1030 positifs), on utilise aussi la même sélection simple à l'étape 1025. Si le taux d'erreurs dépend de la position dans les groupes (test 1020 positif et test 1030 négatif), on calcule un taux d'erreurs global en fonction du nombre de paquets à chaque position (étape 1040). On peut ensuite sélectionner le nombre de paquets de redondance adaptés parmi les paquets de redondance calculés par le codeur (étape 1045). Ainsi, le taux d'erreur prédit permet de choisir un taux de redondance approprié pour la correction des erreurs. Par ailleurs, si on dispose d'informations sur l'importance des paquets, on peut aussi choisir les positions des paquets pour placer les paquets les plus importants aux positions où les probabilités d'erreurs sont les plus faibles.

Il est à noter que l'utilisation de la prédiction du taux d'erreurs pour calculer des FEC ne constitue qu'une application parmi d'autres de la présente invention. Par exemple, la prédiction du taux d'erreurs peut également être utilisée pour la création de couches d'amélioration, dans le cas où les données sont de type vidéo.

Claims (25)

1. REVENDICATIONS1. Procédé de prédiction du taux d'erreurs de transmission dans un flux de paquets de données transmis entre un serveur (101) et au moins un client (102) dans un réseau de communication (100), ledit procédé étant caractérisé en ce qu'il comporte des étapes suivant lesquelles : le serveur (101) envoie (540) au moins un groupe de paquets au client (102) ; le client (102) calcule (620, 625, 640, 645) une pluralité d'informations statistiques sur le groupe de paquets et transmet (665) lesdites informations statistiques au serveur (101) ; le serveur (101) analyse (710, 720, 730, 735) lesdites informations statistiques de façon à obtenir un indicateur de stabilité du réseau ; et le serveur (101) calcule (715, 725, 740) une prédiction dudit taux d'erreurs de transmission à partir dudit indicateur de stabilité du réseau.
2. 2. Procédé selon la revendication 1, caractérisé en ce que, lors de l'étape d'analyse des informations statistiques, le serveur détermine (710, 720) la position des erreurs dans le groupe de paquets.
3. 3. Procédé selon la revendication 2, caractérisé en ce que si le serveur détermine (710) qu'une majorité d'erreurs est située en fin de groupe, l'indicateur de stabilité du réseau indique que le réseau est de type stable.
4. 4. Procédé selon la revendication 2, caractérisé en ce que si le serveur détermine (720) qu'une majorité d'erreurs est située en début de groupe, l'indicateur de stabilité du réseau indique que le réseau est de type instable.
5. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le client (102) calcule la capacité du réseau pour chaque paquet du groupe de paquets, définie par B; = S;/d;, où Si est la taille du paquet et d; est la variation, entre deux paquets consécutifs, de la durée de transmission d'un paquet.
6. 6. Procédé selon la revendication 5, caractérisé en ce que, lors de l'étape d'analyse des informations statistiques, le serveur (101) analyse (730) les variations de mesure de la capacité du réseau (100) et en déduit l'indicateur de stabilité du réseau.
7. 7. Procédé selon la revendication 5, caractérisé en ce que, lors de l'étape d'analyse des informations statistiques, le serveur (101) compare (735) la capacité du réseau avec le débit du flux sur le réseau (100) et en déduit l'indicateur de stabilité du réseau.
8. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, si l'indicateur de stabilité du réseau indique que le réseau (100) est de type instable, le serveur (101) calcule (725) une prédiction du taux d'erreurs à partir de statistiques à long terme sur le nombre d'erreurs dans le passé.
9. 9. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, si l'indicateur de stabilité du réseau indique que le réseau est de type stable avec une part du débit utilisée par le flux de paquets de données supérieure à un premier seuil prédéterminé, le serveur (101) calcule (715) une prédiction du taux d'erreurs à partir de statistiques sur la position des erreurs dans le groupe de paquets, et si l'indicateur de stabilité du réseau indique que le réseau est de type stable avec une part du débit utilisée par le flux de paquets de données inférieure à un second seuil prédéterminé, le serveur (101) calcule (740) une prédiction du taux d'erreurs à partir de statistiques à court terme sur l'évolution de la durée de transmission des paquets.
10. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape suivant laquelle le serveur détermine (920, 1020) la fiabilité de la prédiction du taux d'erreurs de transmission à partir dudit indicateur de stabilité du réseau.
11. 11. Procédé selon la revendication 10, caractérisé en ce que le serveur sélectionne une méthode prédictive de correction d'erreurs en fonction de la prédiction du taux d'erreurs de transmission et de la fiabilité de ladite prédiction.
12. 12. Procédé selon la revendication 11, caractérisé en ce que le serveur choisit un taux de redondance prédéterminé d'une méthode de correction d'erreurs en fonction de la prédiction du taux d'erreurs de transmission et de la fiabilité de la prédiction.
13. 13. Procédé selon la revendication 11, dans lequel les données sont des données vidéo, caractérisé en ce que le serveur choisit (925) un mode de codage intra des données en fonction de la prédiction du taux d'erreurs de transmission et de la fiabilité de la prédiction.
14. 14. Serveur (101) de transmission d'un flux de paquets de données, dans un réseau de communication (100) comportant au moins un client (102), ledit serveur étant caractérisé en ce qu'il comporte : des moyens pour envoyer au moins un groupe de paquets au client (102) ; des moyens pour recevoir une pluralité d'informations statistiques sur le groupe de paquets ; des moyens pour analyser lesdites informations statistiques de façon à obtenir un indicateur de stabilité du réseau ; et des moyens pour calculer une prédiction du taux d'erreurs de transmission à partir dudit indicateur de stabilité du réseau.
15. 15. Serveur (101) selon la revendication 14, caractérisé en ce qu'il comporte en outre des moyens pour déterminer la position des erreurs dans le 20 groupe de paquets.
16. 16. Serveur (101) selon la revendication 14 ou 15, caractérisé en ce qu'il comporte en outre des moyens pour analyser les variations de mesure de la capacité du réseau (100) et pour en déduire l'indicateur de stabilité du réseau, la capacité du réseau étant définie, pour chaque paquet du groupe de 25 paquets, par B; = S;/d;, où Si est la taille du paquet et d; est la variation, entre deux paquets consécutifs, de la durée de transmission d'un paquet.
17. 17. Serveur (101) selon la revendication 14 ou 15, caractérisé en ce qu'il comporte en outre des moyens pour comparer la capacité du réseau (100) avec le débit du flux sur le réseau et pour en déduire l'indicateur de stabilité du 30 réseau, la capacité du réseau étant définie, pour chaque paquet du groupe de paquets, par B; = S;/d;, où Si est la taille du paquet et d; est la variation, entre deux paquets consécutifs, de la durée de transmission d'un paquet.
18. 18. Serveur (101) selon l'une quelconque des revendications 14 à 17, caractérisé en ce que lesdits moyens de calcul sont adaptés à calculer une prédiction du taux d'erreurs de transmission à partir de statistiques à long terme sur le nombre d'erreurs dans le passé, si l'indicateur de stabilité du réseau indique que le réseau (100) est de type instable.
19. 19. Serveur (101) selon l'une quelconque des revendications 14 à 17, caractérisé en ce que lesdits moyens de calcul sont adaptés à calculer une prédiction du taux d'erreurs de transmission à partir de statistiques sur la position des erreurs dans le groupe de paquets, si l'indicateur de stabilité du réseau indique que le réseau est de type stable avec une part du débit utilisée par le flux de paquets de données supérieure à un premier seuil prédéterminé, et sont adaptés à calculer une prédiction du taux d'erreurs de transmission à partir de statistiques à court terme sur l'évolution de la durée de transmission des paquets, si l'indicateur de stabilité du réseau indique que le réseau est de type stable avec une part du débit utilisée par le flux de paquets de données inférieure à un second seuil prédéterminé.
20. 20. Serveur (101) selon l'une quelconque des revendications 14 à 18, caractérisé en ce qu'il comporte en outre des moyens pour déterminer la fiabilité de la prédiction du taux d'erreurs de transmission à partir dudit indicateur de stabilité du réseau.
21. 21. Serveur (101) selon la revendication 20, caractérisé en ce qu'il comporte en outre des moyens pour sélectionner une méthode prédictive de correction d'erreurs en fonction de la prédiction du taux d'erreurs de transmission et de la fiabilité de ladite prédiction.
22. 22. Serveur (101) selon la revendication 21, caractérisé en ce qu'il comporte en outre des moyens pour choisir un taux de redondance prédéterminé d'une méthode de correction d'erreurs en fonction de la prédiction du taux d'erreurs de transmission et de la fiabilité de la prédiction.
23. 23. Serveur (101) selon la revendication 21, dans lequel les données sont des données vidéo, caractérisé en ce qu'il comporte en outre des moyens pour choisir un mode de codage intra des données en fonction de la prédiction du taux d'erreurs de transmission et de la fiabilité de la prédiction.
24. 24. Moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé de prédiction selon l'une quelconque des revendications 1 à 13.
25. 25. Produit programme d'ordinateur pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé de prédiction selon l'une quelconque des revendications 1 à 13, lorsque ce programme est chargé et exécuté par l'appareil programmable.