Brevet FR2908576A1 — publié le 20080516

-1- La présente invention concerne des réseaux de communication de données. La présente invention est particulièrement applicable à la délivrance de paquets de données d'un flux de données d'un dispositif émetteur à un dispositif récepteur. Les réseaux de communication de données peuvent s'avérer peu fiables en raison d'erreurs de transmission, de congestions ou d'arrêts temporaires des liaisons, lesquels entraînent une perte de paquets de données. De nombreux réseaux de données comme le réseau IP ( Internet Protocol ) ou l'ATM (mode de transfert asynchrone) comprennent des noeuds d'interconnexion (routeurs, commutateurs, etc.) afin de router les paquets de données depuis des dispositifs source jusqu'à des dispositifs destinataires. Dans ce type de réseau, la congestion est la source principale de pertes quand différents flux de données sont amenés à transiter par un même lien de capacité insuffisante. Les paquets en surplus finissent par être jeté par le noeud d'interconnexion situé à l'entrée du lien. De plus, 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 Control , IETF RFC3448) or AIMD ( Additive Increase/Multiplicative Decrease , IETF RFC2581) qui produisent, par nature, une pluralités de congestions même si elles sont de courtes durées. En cas de congestion, les noeuds d'interconnexion rejettent un nombre plus ou moins élevé de paquets de données afin de maintenir le niveau de remplissage des tampons de réception en dessous d'un seuil acceptable. On sait d'après l'art antérieur que le rejet de données sans considérer leur importance peut avoir de graves conséquences pour certains types de transmission de données tels que les flux vidéo. Dans le document US2005/0021806, Richardson et coll. décrivent l'association de niveaux de priorité aux flux de données, un niveau de priorité supérieur étant assigné à un type de données de haute importance et un niveau de priorité inférieur étant assigné à un type de données de moindre importance, l'importance dépendant du contenu des données. En conséquence, quand la congestion dans le réseau entraîne un rejet de données, les données du flux d'un type de données de moindre importance sont rejetées avant les données du flux d'un type de données d'une plus grande importance. Toutefois, même si les données de haute importance ne sont pas susceptibles d'être rejetées durant une congestion du fait de leur association à un niveau de haute priorité, le rendu du flux de données au niveau du dispositif destinataire après une congestion reste dégradé en raison de l'absence de données de moindre importance. II est nécessaire de réduire l'effet des paquets de données rejetés sur la qualité du flux de données rendu au niveau du dispositif destinataire. 2908576 -2- La présente invention a été réalisée pour réduire l'effet des pertes des paquets de données en attribuant de façon appropriée des niveaux de priorité aux paquets de données avant leur transmission. Conformément à un aspect principal de la présente invention, il est fourni un 5 procédé de transmission sur un réseau de communication de données de paquets de données d'un flux de données à un dispositif récepteur comprenant les étapes consistant à: sélectionner un paquet de données dans une mémoire tampon contenant des paquets de données à transmettre ; 10 déterminer si le temps de lecture du paquet de données sélectionné au niveau du dispositif récepteur permet une récupération dudit paquet de données sélectionné ; attribuer un premier niveau de priorité ou un deuxième niveau de priorité au paquet de données sélectionné en fonction du résultat de l'étape de détermination ; et transmettre le paquet de données sélectionné avec ledit premier ou deuxième 15 niveau de priorité attribué. Un avantage de ce procédé est l'amélioration de la stratégie d'attribution des niveaux de priorité aux paquets de données par la prise en compte de la possibilité de récupération de ces paquets de données. La récupération peut être effectuée par retransmission des paquets de données rejetés en raison d'une congestion dans le 20 réseau. De façon alternative, la récupération peut être effectuée par la transmission de paquets de redondance générés à partir des paquets de données rejetés par l'application d'un schéma de contrôle d'erreur à priori ( Forward Error Correction ). Une meilleure qualité de rendu du flux de données, par ex. de la qualité d'affichage vidéo, est ainsi assurée. 25 En outre, ce procédé est particulièrement efficace lorsque les congestions dans le réseau sont de courtes durées comme celles générées par les mécanismes de contrôle de congestion de type TFRC ou AIMD. Avantageusement, le plus haut des premier et deuxième niveaux de priorité est attribué au paquet de données sélectionné si le temps de lecture du paquet de données 30 sélectionné ne permet pas de le récupérer en cas de perte. Ainsi, la probabilité de non-rejet du paquet de données sélectionné en cas de congestion est supérieure. Si le temps de lecture du paquet de données sélectionné permet de le récupérer en cas de perte, il suffit d'attribuer le plus bas des premier et deuxième niveaux de priorité au paquet de données sélectionné puisqu'il reste encore au moins une autre chance de le récupérer, 35 par exemple en le retransmettant avec potentiellement un niveau de priorité attribué différent. 2908576 -3- Conformément à un mode de réalisation préféré de l'invention, le flux de données contient des types de données d'importances différentes, le niveau de priorité attribué étant basé sur le type de données contenues dans le paquet de données sélectionné en plus du résultat de l'étape de détermination. 5 L'avantage est donc de construire une mesure groupée de l'importance des données qui tient compte non seulement du niveau d'importance des données mais aussi de la possibilité de récupération ou non du paquet de données correspondant, par exemple par retransmission en cas d'échec d'une transmission initiale. Avantageusement, lorsque le contenu dudit paquet de données contient des 10 données de haute importance, le plus haut des premier et deuxième niveaux de priorité est attribué si le résultat de l'étape de détermination est négatif (le temps de lecture du paquet de données sélectionné au niveau du dispositif récepteur ne permet pas une récupération dudit paquet de données sélectionné), et le plus bas des premier et deuxième niveaux de priorité est attribué si le résultat est positif (le temps de lecture 15 permet une récupération du paquet de données). La probabilité de fournir correctement les données de haute importance ainsi que les données de faible importance au niveau du dispositif récepteur est par conséquent augmentée. L'invention concerne également urne application logicielle pour transmettre sur un réseau de communication de données des paquets de données d'un flux de données à un 20 dispositif récepteur. En outre, l'invention concerne un dispositif émetteur mettant en oeuvre l'application logicielle pour transmettre les paquets de données, et un support de mémoire pour mémoriser le code d'une telle application logicielle. La figure 1 est un exemple d'un réseau de communication de données où la 25 présente invention peut être mise en oeuvre. La figure 2 illustre un schéma de principe d'un dispositif émetteur adapté pour incorporer l'invention. La figure 3 est un organigramme illustrant un procédé de transmission de paquets de données conformément à un premier mode de réalisation de la présente invention telle 30 qu'elle doit être mise en oeuvre au niveau du dispositif expéditeur. La figure 4 est un organigramme illustrant un procédé de transmission de paquets de données conformément à un second mode de réalisation de la présente invention telle qu'elle doit être mise en oeuvre au niveau du dispositif expéditeur. La figure 5 montre graphiquement le principe de base de la présente invention en 35 considérant l'importance des données et deux niveaux de priorité. 2908576 -4- La figure 6 illustre des diagrammes représentant l'évolution du niveau de remplissage du tampon de réception en utilisant des procédés de l'art antérieur pour attribuer les priorités de réseau. La figure 7 illustre des diagrammes représentant l'évolution du niveau de 5 remplissage du tampon de réception conformément à l'invention pour résumer les avantages de la présente invention. Dans ce qui suit, nous donnons une description détaillée de modes de réalisation de la présente invention par référence aux dessins annexés. La figure 1 est un exemple de réseau de communication de données où la présente 10 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 de communication de données peut contenir des noeuds d'interconnexion (103) et des liaisons (104) qui créent des chemins entre les dispositifs. Les noeuds d'interconnexion et le dispositif récepteur 15 peuvent rejeter des paquets de données en cas de congestion (débordement de la mémoire de réception). De manière caractéristique, le réseau de communication de données met en oeuvre un mécanisme pour gérer le trafic de réseau et apporter des garanties de qualité de service (QoS) telles que DiffServ ( Differentiated Services ) qui existe dans les réseaux 20 IP ( Internet Protocol ) modernes. DiffServ fonctionne sur le principe de la classification du trafic, où chaque paquet de données est placé dans un nombre limité de classes de trafic (7 par exemple). Chaque noeud d'interconnexion (routeur) sur le réseau est configuré pour différencier le trafic en fonction de sa classe. Chaque classe de trafic peut être gérée différemment, garantissant un traitement préférentiel du trafic de priorité 25 supérieure sur le réseau quand des paquets de données doivent être rejetés. En envoyant des paquets de données avec des priorités différentes, le serveur 101 peut contrôler le type de paquets qui sont rejetés par les routeurs de réseau 103 en cas de congestion et par extension l'impact des pertes de paquets sur la qualité finale du flux de données. 30 Le flux de données fourni par le serveur 101 peut comprendre des informations vidéo, des informations audio, des combinaisons des deux ou n'importe quel autre type d'informations qui peut incorporer différents niveaux d'importance de données. Un exemple d'un tel flux de données est un flux vidéo MPEG comprenant différents types de trames vidéo telles que des trames clés (I), des trames prédictives avant (P), et 35 des trames prédictives arrière (B), où les trames clés servent de base au traitement des trames prédictives avant et arrière. Les trames I représentent donc des données importantes puisque la perte d'une seule trame 1 rend impossible le traitement correct des 2908576 -5- trames P et B associées. Inversement, les trames P et B représentent des données moins importantes puisque leur perte n'empêche pas le décodeur au niveau du dispositif récepteur de traiter les trames I, et n'entraîne qu'une qualité dégradée. D'autres techniques de compression connues de l'homme de métier (H.264/AVC, 5 MPEG4 pour la vidéo, AMR, G.711, AAC pour l'audio, etc.) conduisent de la même façon à des flux de données incorporant différents niveaux d'importance de données. Par exemple, un flux vidéo H.264/AVC contient des en-têtes qui décrivent le contenu de blocs de données, des vecteurs de mouvement et des informations de texture. Les en-têtes peuvent être considérés comme des données très importantes, les vecteurs de 10 mouvement comme des données d'importance moyenne et les informations de texture comme des données de faible importance. L'importance relative des données peut aussi être inférée à partir du type de flux de données indépendamment de toute technique de compression. Par exemple, dans un flux audio/vidéo, les données audio peuvent être considérées plus importantes que les 15 données vidéo. Les paquets de données peuvent être n'importe quelle collection de parties du flux de données partageant le même niveau ou un niveau proche d'importance de données. Différentes techniques peuvent être utilisées pour partager le flux de données en paquets de données. Par exemple, un flux vidéo MPEG peut être transporté dans deux types de 20 paquets de données ; des paquets de données de haute importance contenant des données de trames I et des paquets de données de faible importance contenant des données de trames P et/ou B. De plus, une trame peut être transportée dans plusieurs paquets de données d'un type donné. En variante, le codage d'un flux vidéo peut être effectué tranche par tranche, où une tranche forme une partie codée indépendamment 25 d'une trame vidéo. Comme le codage de trame vidéo, le codage des tranches vidéo peut conduire à différents niveaux d'importance des données pouvant être transportées dans un ou plusieurs paquets de données. Le dispositif émetteur 101 peut être n'importe quel type de dispositif de traitement de données susceptible de fournir un flux de données à un dispositif récepteur. Dans un 30 exemple, le dispositif émetteur est 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 ou Real-time Transport Protocol ) ou n'importe quel autre type de protocole de communication. La figure 2 illustre un schéma de principe d'un dispositif émetteur 101 adapté pour 35 incorporer l'invention. De préférence, le dispositif émetteur comprend une unité de traitement centrale (UC) 201 capable d'exécuter des instructions provenant d'une ROM de programmes 203 2908576 -6- à la mise sous tension du dispositif émetteur, et 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) qui fonctionne comme zone de travail de l'UC 201, et la capacité de mémoire de celle-ci peut être 5 développée par une RAM facultative connectée à un port d'expansion (non illustré). Les instructions concernant l'application logicielle peuvent être chargées dans la mémoire principale 202 à partir du disque dur (HD) 206 ou bien de la ROM de programmes 203 par exemple. Une telle application logicielle, lorsqu'elle est exécutée par l'UC 201, entraîne l'exécution des étapes des organigrammes montrés aux figures 3 ou 4. 10 Le numéro de référence 204 est une interface réseau qui permet la connexion du dispositif émetteur au réseau de communication. L'application logicielle lorsqu'elle est exécutée par l'UC est adaptée pour réagir à des requêtes du client reçues par le biais de l'interface réseau et fournir au client des flux de données par l'intermédiaire du réseau. Le numéro de référence 205 représente une interface d'utilisateur pour afficher des 15 informations à un utilisateur, et/ou recevoir des entrées de celui-ci. La figure 3 illustre un organigramme pour transmettre des paquets de données conformément à un premier mode de réalisation de la présente invention telle qu'elle doit être mise en oeuvre par le dispositif émetteur 101. Dans ce premier mode de réalisation, le réseau de communication gère des premier et deuxième niveaux de priorité. 20 De manière caractéristique, le dispositif émetteur met en oeuvre un tampon d'émission pour mémoriser des paquets de données obtenus à partir de la mise en paquets du flux de données avant leur transmission au client 102. Un paquet est sélectionné dans le tampon d'émission à l'étape 301, et le temps de lecture d'un tel paquet au niveau du dispositif récepteur est déterminé à l'étape 302. 25 Le temps de lecture est le temps auquel le dispositif récepteur doit présenter ce paquet de données à une application pour le rendu du flux de données. Le rendu du flux de données, comme par exemple le décodage et l'affichage d'un flux vidéo, est un processus en temps réel, et de ce fait si un paquet de données n'est pas disponible au temps de lecture, il devient obsolète et est rejeté à sa réception. Le point dans le temps 30 auquel un paquet de données sera présenté à l'application de rendu dépend du contenu du paquet de données et du type de codage utilisé (basé sur des tranches ou des trames par exemple dans le cas des flux vidéo). Plus précisément, le temps de lecture correspond au temps auquel un paquet de données est lu par l'application de rendu dans le tampon de réception au niveau du client 35 102. Le temps de lecture peut être estimé en fonction des informations de retour du client. Le client peut fournir un niveau de remplissage du tampon correspondant à la 2908576 -7- différence entre le temps de lecture ordonnancé du paquet de données suivant à transférer du tampon de réception à l'application de rendu et le temps de lecture du dernier paquet de données contenu dans le tampon de réception avant la transmission des informations de retour au serveur contenant ce niveau de remplissage. Le niveau de 5 remplissage du tampon représente alors le temps nécessaire pour présenter tout le contenu du tampon de réception à l'application de rendu. Une estimation du délai de lecture est alors obtenue en rajoutant au niveau de remplissage du tampon le délai de transmission du serveur au client. La mise en oeuvre du transfert d'informations de retour peut être propriétaire ou bien 10 suivre certains standards. Par exemple, dans le document "DLNA Networked Device Interoperability Guidelines", de mars 2006, spécifiant le transport de flux de données sur HTTP ou RTP, des rapports de remplissage de tampon (BFR pour Buffer Fullness Reports ) sont transmis par un dispositif récepteur. Un BFR contient, entre autres choses, le numéro de séquence du paquet de données suivant contenu dans le tampon 15 de réception à présenter à l'application de rendu au niveau du client et le délai de lecture, calculé juste avant l'envoi du BFR. Quand le serveur obtient le délai de lecture du client il peut estimer le temps de lecture du paquet sélectionné en ajoutant le délai de lecture à la date de transmission ordonnancée du paquet de données sélectionné. On notera que par défaut le paquet de 20 données sélectionné doit être transmis à un point dans le temps conforme à l'algorithme du Délai le Plus Proche en Premier (EDF pour Earliest Deadline First ), mais d'autres options existent. Par exemple, le paquet de données sélectionné peut être ordonnancé à un point dans le temps plus en avance que le point dans le temps par défaut comme cela est expliqué dans un deuxième mode de réalisation de la présente invention. 25 En variante, le serveur peut utiliser des horodatages ( timestamps ) pour déterminer le temps de lecture du paquet de données sélectionné. Un horodatage est généralement associé à chaque trame vidéo d'un flux vidéo et correspond au temps de lecture relatif des trames vidéo. Le client doit fournir dans les informations de retour au serveur l'horodatage de la trame suivante à présenter à l'application de rendu. La 30 différence entre cet horodatage et l'horodatage de la 'trame vidéo transportée dans le paquet de données sélectionné correspond dans ce cas au délai de lecture. Le temps de lecture du paquet de données sélectionné est alors obtenu en ajoutant le délai de lecture à la date ordonnancée à laquelle le paquet de données sélectionné sera transmit. On notera que lorsqu'une trame est transportée dans plusieurs paquets de 35 données, tous ces paquets de données partagent le même horodatage puisqu'ils doivent être rendus ensemble par l'application de rendu pour le décodage de la trame transportée. 2908576 -8- Un test est effectué à l'étape 303 pour vérifier si, en fonction du temps de lecture prédéterminé du paquet de données sélectionné par l'un ou l'autre des deux procédés de détermination, il reste suffisamment de temps pour transmettre le paquet de données et le présenter à l'application de rendu au niveau du client. 5 S'il n'y a pas suffisamment de temps, le paquet de données sélectionné est rejeté (étape 304) afin d'économiser la bande passante du réseau et le procédé continue avec un nouveau paquet de données sélectionné dans le tampon d'émission à l'étape 301. A l'étape 305 de l'organigramme de la figure 3, un test est effectué pour vérifier si le temps de lecture du paquet de données sélectionné à l'étape 301 permet au moins une 10 retransmission. L'homme de métier sait qu'une retransmission peut être déclenchée explicitement après la réception d'un accusé de réception négatif qui informe de l'échec de la transmission initiale, ou implicitement par l'absence d'un accusé de réception positif. Dans un cas défavorable, une retransmission est déclenchée après l'arrivée à terme d'une temporisation d'une durée prédéterminée AT1. Dans un cas favorable, une 15 retransmission est déclenchée après une durée AT2 s AT1 par la réception d'un accusé de réception négatif. Le test à l'étape 305 peut tenir compte d'un des deux cas précédents, ou d'un cas intermédiaire. Une confiance maximale sur la possibilité de récupérer le paquet de données est obtenue lorsque le cas défavorable est pris en compte. 20 Posons TRET le temps nécessaire pour effectuer une retransmission. Le test 305 est positif si : temps de lecture ? date de transmission ordonnancée du paquet de données sélectionné + TRET ; où TRET = AT + RTT/2, RTT étant le temps de propagation aller-retour, RTT/2 le 25 délai de transmission du serveur au client, et AT1 >_ AT >_ AT2. Le temps de propagation aller-retour peut être par exemple calculé en fonction des informations de retour fourni par RTCP (Protocole de Commande de Transport en Temps réel ou Real Time Transport Control Protocol ). Il faut noter que la présente invention ne doit pas être restreinte en ce qui concerne 30 l'étape 305 uniquement au mode de réalisation qui consiste à tester si le temps de lecture du paquet de données sélectionné au niveau du dispositif récepteur permet au moins une retransmission de ce paquet, mais peut être généralisée à tout mode de réalisation qui permet de tester si le temps de lecture du paquet de données sélectionné permet sa récupération. 35 Par exemple, un moyen de correction d'erreur sans retransmission (FEC) peut être utilisé pour générer des paquets de redondance qui sont utilisés par le dispositif récepteur pour récupérer un ou plusieurs paquets de données perdus. Si les paquets de 2908576 -9- redondance peuvent être générés, transmis et reçus à temps par le dispositif récepteur pour la récupération du paquet de données sélectionné alors le test 305 est positif, sinon il est négatif. Des accusés de réception explicites ou implicites peuvent être utilisés pour informer le serveur que des paquets de redondance doivent être transmis (ce type de 5 protocole s'appelle Hybrid Automatic Repeat reQuest/Forward Error Correction ). En variante, les paquets de redondance peuvent être transmis sans considération d'une information de retour de la part du client (utilisation d'un FEC pure). Par exemple, un paquet de données et un paquet de redondance qui lui est associé peuvent être transmis systématiquement avec un certain niveau de priorité. 10 Si le test 305 ci-dessus est positif, un deuxième niveau de priorité est attribué au paquet de données sélectionné (étape 306), sinon un premier niveau de priorité, supérieur au deuxième niveau de priorité, est attribué au paquet de données sélectionné (étape 307). Le paquet de données sélectionné est enfin transmis au client à la date de transmission ordonnancée (étape 308). 15 Autrement dit, s'il y a suffisamment de temps pour effectuer au moins une retransmission, une priorité inférieure est donnée au paquet de données lors de la première transmission car il reste possible de retransmettre le paquet de données s'il est rejeté par les noeuds d'interconnexion. En revanche, s'il n'y a pas suffisamment de temps pour effectuer au moins une retransmission, une priorité supérieure est donnée au paquet 20 de données pour augmenter les chances que le paquet de données a d'atteindre correctement le dispositif récepteur même en cas de congestion du réseau. La figure 4 illustre un organigramme pour transmettre des paquets de données conformément à un second mode de réalisation de la présente invention. Dans ce second mode de réalisation, le réseau de communication gère au moins trois niveaux de priorités. 25 Ces priorités sont appelées premier, deuxième et troisième niveaux de priorité où : premier niveau > troisième niveau > deuxième niveau. Les étapes 401, 402, 403 et 404 sont semblables aux étapes 301, 302, 303 et 304 de la figure 3, et ne seront donc pas décrites davantage. A l'étape 405 un test est effectué pour déterminer le niveau d'importance des 30 données contenues dans le paquet de données. Si les données sont de faible importance, le troisième niveau de priorité est attribué au paquet de données sélectionné (étape 406). Le paquet de données est ensuite ordonnancé pour être transmis à un point dans le temps par défaut en tenant compte des paquets de données déjà présents dans le tampon d'émission (étape 407). 35 Comme on l'a décrit ci-dessus, l'importance des données dépend du contenu du paquet de données. L'UC 201 lit l'en-tête du paquet de données pour déterminer le type de son contenu. Par exemple, dans le cas d'un flux vidéo MPEG, l'UC 201 détermine si le 2908576 -10-contenu constitue une partie ou la totalité d'une trame clé (I) ou d'une trame prédictive (P ou B), où une trame clé représente des données de haute importance et une trame prédictive représente des données de faible importance. Si le paquet de données contient à la fois une partie ou la totalité d'une trame clé et de trames prédictives, les données 5 contenues dans le paquet de données sont considérées être d'une haute importance. Par défaut, les paquets de données sont mémorisés dans le tampon d'émission dans l'ordre dans lequel ils sont générés après la mise en paquets des données de sortie du codeur, et sont transmis dans le même ordre au client selon le principe Premier Entré, Premier Sorti (tout en respectant l'algorithme du Délai le Plus Proche en Premier, EDF). 10 Si le test 405 détermine que les données sont de haute importance, l'ordre par défaut de l'ordonnancement de la transmission du paquet de données sélectionné peut être modifié. La modification de l'ordre par défaut est optionnelle, mais si elle est mise en oeuvre, elle peut augmenter le délai de lecture et ainsi rendre plus probable la possibilité d'entreprendre une retransmission. 15 L'étape 409 détermine le point dans le temps le plus en avance possible pour ordonnancer la transmission du paquet de données sélectionné. Ceci correspond à combien en avance un paquet de données peut être transmis avant sa date de transmission par défaut sans empêcher le décodeur ou l'application de rendu au niveau du client de décoder ou de rendre correctement le flux de données. 20 En considérant le point dans le temps le plus en avance déterminé à l'étape 409, un test est effectué à l'étape 410 pour vérifier si le temps de lecture du paquet de données sélectionné permet au moins une retransmission. Si l'étape 409 n'est pas mise en oeuvre, la vérification est effectuée en considérant la date d'ordonnancement par défaut. Les détails de mise en oeuvre de ce test sont semblables à ceux de l'étape 305, excepté pour 25 la date (ou point dansle temps) d'ordonnancement de la transmission du paquet de données sélectionné comme on l'a expliqué ci-dessus. Si le test est positif (au moins une retransmission est possible), le deuxième niveau de priorité est attribué au paquet de données sélectionné (étape 411), et un point dans le temps pour ordonnancer la transmission du paquet de données est établi, permettant l'au 30 moins une retransmission (étape 412). On notera que le point dans le temps établi ne correspond pas nécessairement au point dans le temps le plus en avance. Si le test est négatif (pas de retransmission possible), le premier niveau de priorité est attribué au paquet de données sélectionné (étape 413) et l'ordonnancement de la transmission du paquet de données est établi à un point dans le temps par défaut (étape 35 414). Enfin, à l'étape 408 le paquet de données sélectionné est transmis au client au point dans le temps ordonnancé dans l'une des étapes 407, 412 ou 414. 2908576 -11- En cas de congestion dans le réseau, un paquet de données ayant le deuxième niveau de priorité (niveau de priorité inférieur) est rejeté en premier. S'il arrivait que ce paquet de données contienne des données importantes, ceci implique qu'il a été rejeté par un noeud intermédiaire du réseau pour sauvegarder soit un autre paquet de données 5 contenant des données importantes et ne pouvant pas être retransmis, soit un paquet de données contenant des données de faible importance. [)ans l'un ou l'autre cas, le paquet de données rejeté sera retransmis avec le premier niveau de priorité (niveau de priorité supérieur), à moins qu'une autre retransmission ne soit possible. En conséquence, la présente invention conformément à son deuxième mode de 10 réalisation attribue des priorités en fonction de l'importance groupée des données qui tient compte non seulement du niveau d'importance des données mais aussi de la possibilité ou non de retransmettre le paquet de données correspondant en cas de défaillance d'une transmission initiale. Les données de haute importance pouvant être retransmises possèdent une importance groupée inférieure durant leur transmission initiale à celle des 15 données de faible importance qui ne peuvent pas être retransmises. Ceci permet une meilleure gestion de l'attribution des priorités et une optimisation des performances de transmission (une réduction du nombre de paquets de données perdus dans le réseau). Le concept de génération de différents niveaux d'importance groupée de données peut être étendu pour l'adapter à tout nombre disponible de priorités et à une pluralité de 20 niveaux d'importance de données. En effet, il est habituel que les réseaux puissent gérer plus de trois priorités, et l'on pourrait vouloir différencier plus de deux niveaux d'importance de données. Conformément à un troisième mode de réalisation de la présente invention, l'attribution de niveaux de priorité aux paquets de données conformément aux modes de 25 réalisation de la figure 3 ou de la figure 4 est améliorée pour tenir compte de paramètres supplémentaires comme par exemple l'équilibre entre les quantités de données de faible importance et de données de haute importance dans le tampon de réception du dispositif récepteur, et/ou la largeur de bande passante de réseau effectivement consommée pour la transmission du flux de données par rapport à la largeur de bande passante attribuée. 30 Dans l'un ou l'autre cas, il peut être utile de commuter entre un procédé d'attribution de priorité conformément aux figures 3 ou 4 et un procédé par défaut dans lequel un niveau de priorité supérieur est attribué aux paquets de données contenant des données de haute importance en comparaison à un niveau de priorité inférieure attribué aux paquets de données contenant des données de faible importance. La commutation entre 35 le procédé par défaut et le procédé de, la figure 3 ou 4 peut être effectuée de façon répétée pour satisfaire des contraintes de réseau prédéterminées représentant les paramètres donnés ci-dessus par exemple. 2908576 -12- Par exemple, si la quantité de données de haute importance dans le tampon de réception est inférieure à la quantité de données de faible importance, il est préférable d'attribuer aux paquets de données qui contiennent ce type de données (de haute importance) un niveau de priorité supérieure afin d'augmenter leur probabilité d'atteindre 5 le dispositif récepteur après une seule transmission, même si une retransmission aurait été possible. Il est important de maintenir la quantité de données de haute importance au moins égale à la quantité de données de faible importance afin de garantir une qualité de rendu acceptable par l'application de rendu. Bien sûr, si l'équilibre entre les données de faible et de haute importance dans le tampon de réception change, la stratégie 10 d'attribution de niveaux de priorité peut être adaptée en conséquence. La largeur de bande passante effective utilisée pour transporter le flux de données peut aussi être prise en compte pour décider de la stratégie d'attribution de niveaux de priorité à adopter. Quand une pluralité de flux de données est transportée à travers certaines liaisons communes dans le réseau de communication, ils doivent partager la 15 largeur de bande passante disponible et les niveaux de priorité attribués aux paquets de données appartenant à différents flux de données doivent être maintenus cohérents pour éviter d'inonder le réseau avec un trafic de haute priorité uniquement. La cohérence des niveaux de priorité entre différents flux de données peut être maintenue en respectant la largeur de bande passante attribuée. En effet, la retransmission de paquets de données 20 contenant des données de haute importance et l'attribution d'une priorité élevée aux paquets de données contenant des données de faible importance peut conduire à une utilisation effective de la largeur de bande passante supérieure à la largeur de bande passante attribuée. Un seuil peut être établi pour commuter entre le procédé par défaut et le procédé de la figure 3 ou 4 afin de maintenir la largeur de bande passante utilisée 25 proche, en moyenne, de la largeur de bande passante attribuée. La figure 5 montre graphiquement le principe de base de la présente invention en considérant l'importance des données et deux niveaux de priorité PLI et PL2 où PLI > PL2. Ces deux niveaux de priorité peuvent être par exemple les premier et deuxième niveaux de priorité tels que décrits dans le deuxième mode de réalisation de la figure 4. 30 Pour des raisons de simplicité, la figure ne représente que l'ordre d'envoi des paquets de données contenant des parties d'une même trame en fonction de leur importance, mais le principe peut aussi s'appliquer à une pluralité de trames/flux. L'axe Y représente le degré d'importance relative des données à l'intérieur d'une trame allant des données les plus importantes (en bas) aux données les moins 35 importantes (en haut). L'axe X représente le temps. La trame est produite par le codeur sur l'expéditeur au temps T et est consommée par le décodeur sur le récepteur au temps T + D, où D est supérieur ou égal au délai de 2908576 -13- lecture de la trame. Le délai de lecture et D sont égaux si le décodeur est considéré comme l'application de rendu. La trame produite au temps T est transmise sur le réseau entre les temps Ti et T2 avec T REVENDICATIONS 1. Procédé de transmission sur un réseau de communication de données de paquets de données d'un flux de données à un dispositif récepteur, caractérisé en ce qu'il comprend les étapes consistant à : sélectionner un paquet de données dans une mémoire tampon contenant des paquets de données à transmettre (301, 401) ; déterminer si le temps de lecture du paquet de données sélectionné au niveau du dispositif récepteur permet une récupération dudit paquet de données sélectionné (303, 410) attribuer un premier niveau de priorité ou un deuxième niveau de priorité au paquet de données sélectionné en fonction du résultat de l'étape de détermination (306, 307, 411,413); et transmettre le paquet de données sélectionné avec ledit premier ou deuxième niveau de priorité attribué (308, 408). 2. Procédé selon la revendication 1, caractérisé en ce que le plus haut des premier et deuxième niveaux de priorité est attribué au paquet de données sélectionné si le résultat de l'étape de détermination est négatif (307, 413), et le plus bas des premier et deuxième niveaux de priorité est attribué si le résultat est positif (306, 411). 3. Procédé selon la revendication 1, caractérisé en ce que le flux de données contient des types de données d'importances différentes, le niveau de priorité attribué étant basé sur le type de données contenu dans le paquet de données sélectionné en plus du résultat de l'étape de détermination. 25 4. Procédé selon la revendication 3, caractérisé en ce que lorsque le contenu dudit paquet de données contient des données de haute importance, le plus haut des premier et deuxième niveaux de priorité est attribué si le résultat de l'étape de détermination est négatif (413), et le plus bas des premier et deuxième niveaux de priorité est attribué si le 30 résultat est positif (411). 5. Procédé selon la revendication 4, caractérisé en ce que lorsque le contenu dudit paquet de données contient des données de faible importance (406), un troisième niveau de priorité est attribué au paquet de données sélectionné, ledit troisième niveau de priorité 35 ayant une valeur intermédiaire entre les premier et deuxième niveaux de priorité. 2908576 -16 - 6. Procédé selon la revendication 3, caractérisé en ce qu'il comprend en outre une étape de détermination de la quantité de données de haute importance contenues dans le tampon de réception du dispositif récepteur, et en ce que si la quantité déterminée est inférieure à un seuil prédéterminé, le plus haut des premier et deuxième niveaux de 5 priorité est attribué au paquet de données s'il contient des données de haute importance et le plus bas des premier et deuxième niveaux de priorité est attribué au paquet de données s'il contient des données de faible importance. 7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'il contient une 10 autre étape de détermination du temps de lecture du paquet de données sélectionné (302, 402). 8. Procédé selon la revendication 7, caractérisé en ce que l'étape de détermination du temps de lecture comprend une étape de réception depuis le dispositif récepteur d'un 15 délai de lecture représentant le temps nécessaire pour présenter tous les paquets de données dans un tampon de réception du dispositif récepteur à une application de rendu. 9. Procédé selon la revendication 7, caractérisé en ce que l'étape de détermination du temps de lecture comprend une étape de réception depuis le dispositif récepteur d'un 20 horodatage associé au paquet de données suivant à présenter à une application de rendu au niveau du dispositif récepteur. 10. Procédé selon l'une des revendications 8 et 9, caractérisé en ce que le temps de lecture est égal à la somme du délai de lecture et d'une date de transmission ordonnancée du paquet de données sélectionné. 11. Procédé selon l'une des revendications 1 et 10, caractérisé en ce que la récupération du paquet de données sélectionné consiste à effectuer au moins une retransmission dudit paquet de données. 12. Procédé selon l'une des revendications 1 et 10, caractérisé en ce que la récupération du paquet de données sélectionné consiste à transmettre au moins un paquet de redondance généré à partir d'au moins du paquet de données sélectionné en utilisant un schéma de correction d'erreur à priori. 13. Procédé selon la revendication 11, caractérisé en ce que l'étape consistant à déterminer si le temps de lecture du paquet de données sélectionné au niveau du 35 2908576 -17- dispositif récepteur permet au moins une retransmission ou non dudit paquet de données sélectionné comprend une étape consistant à comparer le temps de lecture déterminé à la somme d'une date de transmission ordonnancée du paquet de données sélectionné et du temps nécessaire pour effectuer au moins une retransmission. 5 14. Application logicielle pour transmettre sur un réseau de communication de données des paquets de données d'un flux de données à un dispositif récepteur, agencé de telle sorte que lorsqu'elle est exécutée, les étapes suivantes sont exécutées : sélectionner un paquet de données dans une mémoire tampon contenant des 10 paquets de données à transmettre (301, 401) ; déterminer si le temps de lecture du paquet de données sélectionné au niveau du dispositif récepteur permet une récupération dudit paquet de données sélectionné (303, 410) ; attribuer un premier niveau de priorité ou un deuxième niveau de priorité au paquet 15 de données sélectionné en fonction du résultat de l'étape de détermination (306, 307, 411,413); et transmettre le paquet de données sélectionné avec ledit premier ou deuxième niveau de priorité attribué (308, 408). 20 15. Support de mémoire pour mémoriser le code de l'application logicielle selon la revendication 14. 16. Dispositif émetteur pour transmettre sur un réseau de communication de données des paquets de données d'un flux de données à un dispositif récepteur, 25 caractérisé en ce qu'il comprend : une unité de sélection pour sélectionner un paquet de données dans une mémoire tampon contenant des paquets de données à transmettre ; une unité de détermination pour déterminer si le temps de lecture du paquet de données sélectionné au niveau du dispositif récepteur permet une récupération dudit 30 paquet de données sélectionné ; une unité d'attribution pour attribuer un premier niveau de priorité ou un deuxième niveau de priorité au paquet de données sélectionné en fonction du résultat de l'unité de détermination ; et une unité de transmission pour transmettre le paquet de données sélectionné avec 35 ledit premier ou deuxième niveau de priorité attribué.