FR2908577A1 - Procede de transmission conformement a un protocole de transmission par rafales d'un contenu de donnees,produit programme d'ordinateur,moyen de stockage et dispositif correspondants. - Google Patents

Procede de transmission conformement a un protocole de transmission par rafales d'un contenu de donnees,produit programme d'ordinateur,moyen de stockage et dispositif correspondants. Download PDF

Info

Publication number
FR2908577A1
FR2908577A1 FR0609884A FR0609884A FR2908577A1 FR 2908577 A1 FR2908577 A1 FR 2908577A1 FR 0609884 A FR0609884 A FR 0609884A FR 0609884 A FR0609884 A FR 0609884A FR 2908577 A1 FR2908577 A1 FR 2908577A1
Authority
FR
France
Prior art keywords
value
content
transmission
window size
accepted
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0609884A
Other languages
English (en)
Other versions
FR2908577B1 (fr
Inventor
Pascal Viger
Patrice Nezou
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0609884A priority Critical patent/FR2908577B1/fr
Publication of FR2908577A1 publication Critical patent/FR2908577A1/fr
Application granted granted Critical
Publication of FR2908577B1 publication Critical patent/FR2908577B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/13—Flow control; Congestion control in a LAN segment, e.g. ring or bus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/781—Centralised allocation of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de gestion de ressources pour la transmission dans un réseau de communication (100) d'un premier contenu de données entre un premier dispositif source (110) et un premier dispositif récepteur (120A, 120B) sur un premier chemin de transmission comprenant au moins un premier dispositif intermédiaire (140A, 140B, 140C).Selon l'invention, dans le cadre d'un tel procédé, un dispositif gestionnaire (150) effectue les étapes suivantes :- détermination d'un ensemble de valeurs de taille de fenêtre acceptables pour la transmission du premier contenu ;- détermination d'une valeur de taille de fenêtre, dite première valeur acceptée, parmi l'ensemble de valeurs de taille de fenêtre acceptables déterminé, ladite première valeur acceptée étant la valeur de fenêtre maximale acceptée par au moins ledit au moins un premier dispositif intermédiaire pour la transmission du premier contenu ;envoi, au premier dispositif récepteur, d'une information représentative de ladite première valeur acceptée afin d'initialiser la transmission du premier contenu entre le premier dispositif source et le premier dispositif récepteur suivant une taille de fenêtre égale à ladite première valeur acceptée.

Description

1 Procédé de transmission conformément à un protocole de transmission par
rafales d'un contenu de données, produit programme d'ordinateur, moyen de stockage et dispositif correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des transmissions de contenus de données dans un réseau de communication. Plus précisément, l'invention concerne le contrôle de la qualité de service mise en oeuvre dans le cadre de telles transmissions. 2. Solutions de l'art antérieur Les protocoles de type ARQ (pour Automated Repeat reQuest ) sont des protocoles de contrôle d'erreur lors de la transmission de données selon lesquels le récepteur détecte les erreurs de transmission d'un message ou d'un ensemble de données et demande automatiquement la retransmission de ce message ou de cet ensemble de données à l'expéditeur.
Les réseaux IP (pour Internet Protocol qui est défini par la norme RFC791 de l'IETF) peuvent supporter à la fois du trafic conforme au protocole UDP et du trafic conforme au protocole TCP. Le protocole UDP (pour User Datagram Protocol qui est défini par la norme RFC768 de l'IETF) est prévu pour des transactions en temps réel (sans principe de retransmission) autorisant des transmissions rapides mais sans assurance de la délivrance des paquets. C'est le principe du mode non-connecté ou datagramme : il n'y a pas de moyen de vérifier si tous les paquets envoyés sont bien arrivés à destination, ni de vérifier dans quel ordre les paquets sont arrivés. Tel qu'expliqué dans l'annexe 1 qui présente les principes de fonctionnement du protocole TCP, le protocole TCP (pour Transmission Control Protocol qui est défini par la norme RFC793 de l'IETF) est un protocole de type ARQ ou protocole de transmission par rafales qui est basé sur des mécanismes de contrôle et de retransmission, et assure ainsi la délivrance de chaque paquet vers la destination. Cependant, ce protocole n'est pas performant pour des échanges de type temps réel . Pour ce type d'échanges (en temps réel), 2908577 2 il est souvent préférable de gérer les pertes, les erreurs ou les congestions, plutôt que d'essayer de les éviter. Le standard "Universal Plug and Play" (ci-après désigné par standard UPnP) a pour objectif de permettre de manière simple et efficace à des systèmes 5 et des équipements d'être mis en réseaux et de collaborer, sans configuration préalable. Les équipements compatibles avec le standard UPnP sont notamment des dispositifs audio-vidéo ou des ordinateurs personnels (PCs) fabriqués par diverses sociétés. Ces équipements peuvent être intégrés dans un réseau IP (pour Internet 10 Protocol ) local tel qu'un réseau domestique. Le standard UPnP fournit à un équipement compatible des moyens de connexion dynamique à un réseau UPnP (qui met en oeuvre le standard UPnP), lui permet de découvrir les autres équipements compatibles du réseau et lui permet de communiquer (ou exposer) ses propres capacités. 15 La technologie UPnP est basée sur le protocole réseau TCP/IP, sur le protocole HTTP (pour HyperText Transport Protocol ) et sur le protocole XML (pour Extensible Markup Language ). Les constituants essentiels d'un réseau UPnP sont les équipements, les services offerts par ces équipements et les postes de contrôle (ou control 20 points en anglais). Un équipement UPnP (qui met en oeuvre le standard UPnP) peut supporter plusieurs services, et est catégorisé en fonction de la liste des services (par exemple un service de type serveur de contenus vidéo , un service de type imprimante, etc.) qu'il peut fournir. Un équipement UPnP expose les services qu'il peut mettre en oeuvre (on parlera dans la suite de ses services ) au 25 moyen d'un fichier de description en langage XML. Un service dans un équipement UPnP comprend une machine d'état, un serveur de contrôle et un serveur d'événements. La machine d'état modélise un état du service grâce à la mise à jour de variables d'état caractérisant l'équipement. Le serveur de contrôle reçoit les requêtes d'équipements distants, 30 exécute les commandes associées et met à jour la machine d'état. Le serveur 2908577 3 d'événements orchestre la diffusion sur le réseau de cette mise à jour auprès des équipements UPnP ayant montré leur intérêt pour cette information. Un poste de contrôle UPnP est capable de découvrir et de contrôler des équipements UPnP du réseau UPnP. Quand un nouvel équipement est découvert 5 par le poste de contrôle, ce dernier obtient une description de ce nouvel équipement, a ainsi connaissance des services offerts par cet équipement, demande une description précise de chaque service disponible et enfin envoie des requêtes de contrôle du service sélectionné. Le poste de contrôle peut aussi souscrire auprès du serveur d'événements afin d'être notifié de tout changement 10 d'état. Le standard UPnP Audio Visual (pour UPnP audio visuel , ci-après référencé UPnP AV ) définit un ensemble d'équipements UPnP (par exemple les télévisions, les magnétoscopes, lecteurs DVD, les lecteurs MP3, les ordinateurs PC, ...) avec leurs services associés, qui sont plus spécifiquement 15 dédiés au monde audio/vidéo numérique. Les trois entités logiques principales d'un réseau UPnP AV (qui met en oeuvre le standard UPnP AV) sont : un serveur de media (ou UPnP MediaServer ) ayant accès à des contenus multimédia qu'il peut diffuser sur le réseau local, un lecteur de media (ou UPnP MediaRenderer ) capable de jouer 20 localement ce type de contenus multimédia reçus du réseau, et un poste de contrôle coordonnant les opérations demandées par l'utilisateur (telles que play , stop , pause , ...). Le serveur de média et le lecteur de média ne mettent pas en oeuvre le protocole UPnP pour échanger directement entre eux des informations. En effet, 25 afin d'échanger des contenus multimédia, ils utilisent des protocoles à part du protocole UPnP (on les appelle protocoles out-of-band ). Ces protocoles outof-band sont principalement le protocole HTTP (pour HyperText Transfer Protocol tel que défini dans la norme RFC2616) au dessus du protocole TCP/IP, et le protocole RTP (pour Real-time Transport Protocol tel que défini dans la 30 norme RFC 1889) au dessus du protocole UDP. 2908577 4 Le standard UPnP Quality of Service (pour UPnP Qualité de Service , ci-après référencé UPnP QoS ), tel que décrit dans le document de référence UPnP QoS standard vl.0/v2.0 , définit un ensemble de services UPnP relatifs à la gestion de qualité de service, qui sont intégrés à des 5 équipements UPnP. Trois services sont ainsi définis : le service UPnP QosPolicyHolder , ci-après désigné par QosPolicyHolder , qui gère les politiques de Qualité de Service (ci-après désignée par QoS) validées par un utilisateur et à appliquer sur le réseau ; 10 le service UPnP QosDevice , ci-après désigné par QosDevice , qui est un service d'un équipement du réseau permettant de recevoir les consignes de QoS à appliquer à un flux de donnée d'un contenu particulier ; et le service UPnP QosManager , ci-après désigné par 15 QosManager , qui, sur ordre d'un Poste de Contrôle voulant mettre en place un flux multimédia, est en charge de recueillir auprès du QosPolicyHolder la politique à appliquer et d'informer les QosDevice sur le chemin de transmission du flux des actions à mettre en place. Les demandes de garantie de Qualité de Service (QoS) proviennent des 20 applications multimédias réparties qui ne se contentent plus du service au mieux du protocole Ethernet. Ces applications vont du simple transfert de données à celles plus complexes telles que la téléphonie, la vidéo à la demande ou la conférence multimédia. La caractérisation, en termes de besoins de QoS, d'un flux conforme au 25 protocole UDP est réalisée au moyen d'un modèle descriptif de trafic multimédia autrement appelé en anglais Trafic Specification ou TSPEC (ci-après désigné par structure TSPEC). La structure TSPEC contient une liste de paramètres définissant les caractéristiques de transfert du flux (par exemple les plus importantes sont la 30 bande passante nécessaire, la latence, la gigue). Cette structure est 2908577 5 particulièrement utilisée par les protocoles de signalisation centralisés tels que le protocole UPnP QoS et les protocoles de signalisation en ligne tels que le protocole RSVP. Cependant, la structure TSPEC n'est pas adaptée pour la caractérisation, 5 en termes de besoins de QoS, des flux conformes au protocole de transmission par rafales TCP (communément appelés flux élastiques) car les mécanismes de transport fiables du protocole TCP (utilisation d'une fenêtre glissante, l'algorithme de démarrage lent slow start , l'algorithme d'évitement de congestion congestion avoidance , les algorithmes de retransmission rapide fast 10 retransmit et de récupération rapide fast recovery , etc.) font que le comportement sur le réseau de ce protocole TCP est imprévisible tout au long d'une communication. Un flux transmis conformément au protocole TCP se comporte d'une façon telle qu'il essaie de partager la bande passante au mieux avec les différents 15 flux concurrents. Cependant, lorsque la place mémoire dans les équipements d'interconnexion du réseau devient insuffisante (ce qui se traduit par exemple par des situations de congestion), des expirations de délai d'attente (ou timeout ) apparaissent, ce qui se traduit par une retransmission conformes au protocole TCP des paquets perdus. Ces retransmissions amplifient les situations de congestion. 20 En effet, comme le dispositif émetteur ne reçoit pas d'acquittement de la part du dispositif récepteur pour les données émises (à cause de la congestion), il retransmet les données non acquittées. Comme explicité préalablement, le besoin en garantie (ou qualité) de service pour la transmission des flux multimédia (en termes de bande passante, 25 et/ou de criticité temps réel) est croissant avec l'augmentation du nombre d'équipements multimédia mis en oeuvre par les utilisateurs. Cependant, afin d'assurer cette QoS, une gestion du comportement du protocole TCP est nécessaire afin d'éviter des engorgements (ou congestions) sur les équipements d'interconnexion du réseau et respecter au mieux les demandes 30 de QoS des flux transmis conformément au protocole TCP (congestion, 2908577 6 timeout ) mais aussi pour éviter que des perturbations (telles que des délais ou de la gigue) n'affectent les flux conformes au protocole UDP. Des techniques visant à gérer le comportement du protocole TCP ont été proposées dans l'art antérieur. De telles techniques consistent par exemple à 5 contrôler l'admission des flux ou à ajuster dynamiquement le fenêtrage du protocole TCP. Elles sont basées sur une mesure des performances du réseau à un instant donné (par exemple, sur le calcul du RTT ou Round Trip Time ). Cependant ces techniques classiques restent localisées sur un équipement d'interconnexion sur le réseau, et ne tiennent pas compte d'une vue d'ensemble 10 des caractéristiques du réseau. 3. Objectifs de l'invention L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention, dans au moins un de ses 15 modes de réalisation, est de fournir une technique de gestion de la réservation de ressources, dans un réseau mettant en oeuvre un protocole de signalisation centralisé, lors de la transmission d'un contenu conformément à un protocole de transmission par rafale qui permette de réduire les phénomènes de congestion. Un autre objectif de l'invention, dans au moins un de ses modes de 20 réalisation, est de mettre en oeuvre une telle technique qui s'applique à l'ensemble du réseau. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui soit compatible avec les recommandations des protocoles mis en oeuvre. 25 L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de mettre en oeuvre une telle technique qui soit simple à mettre en oeuvre et pour un faible coût. 4. Exposé de l'invention Dans un mode de réalisation particulier de l'invention, il est proposé un 30 procédé de gestion de ressources pour la transmission dans un réseau de 2908577 7 communication d'un premier contenu de données entre un premier dispositif source et un premier dispositif récepteur sur un premier chemin de transmission comprenant au moins un premier dispositif intermédiaire. Selon l'invention, un dispositif gestionnaire effectue les étapes suivantes : 5 détermination d'un ensemble de valeurs de taille de fenêtre acceptables pour la transmission du premier contenu ; détermination d'une valeur de taille de fenêtre, dite première valeur acceptée, parmi l'ensemble de valeurs de taille de fenêtre acceptables déterminé, ladite première valeur acceptée étant la valeur de fenêtre 10 maximale acceptée par au moins ledit au moins un premier dispositif intermédiaire pour la transmission du premier contenu ; envoi, au premier dispositif récepteur, d'une information représentative de ladite première valeur acceptée afin d'initialiser la transmission du premier contenu entre le premier dispositif source et le premier dispositif récepteur 15 suivant une taille de fenêtre égale à ladite première valeur acceptée. Le principe général de l'invention consiste, dans un réseau (par exemple mettant en oeuvre un protocole de signalisation centralisé), à ajuster (ou adapter) dynamiquement les valeurs de taille de fenêtre des contenus à transmettre conformément au protocole de transmission par rafales. 20 Ainsi, on obtient une gestion de la réservation de ressources lors de la transmission de contenus conformément à un protocole de transmission par rafales qui permette de réduire les phénomènes de congestion dans le réseau. Dans le cadre de l'invention, cet ajustement peut être mise en oeuvre par le dispositif gestionnaire du protocole de signalisation centralisé. 25 Ainsi, cette gestion est centralisée et tient compte de l'ensemble du réseau. Ainsi, on peut obtenir une qualité de service (QoS) complète contrôlée par au moins un équipement conforme au protocole de signalisation centralisée sur un réseau local pour des contenu transmis selon un protocole de transmission par rafales. 2908577 8 Par ailleurs, le procédé selon l'invention permet de mettre en oeuvre de la réservation de ressource QoS dans un réseau de communication de manière tout à fait transparente pour l'utilisateur. Préférentiellement, l'étape de détermination de la première valeur acceptée 5 comprend également les étapes suivantes : sélection d'une valeur de taille de fenêtre acceptable parmi l'ensemble de valeurs de taille de fenêtre acceptables, dite première valeur sélectionnée courante ; détermination si la première valeur sélectionnée courante est acceptée par 10 ledit au moins un premier dispositif intermédiaire ; dans le cas d'une détermination négative, réitération des étapes de sélection et de détermination avec une première valeur sélectionnée suivante inférieure à la première valeur sélectionnée courante. Ainsi, on obtient la première valeur acceptée en testant, au moins auprès 15 du ou des premier dispositif intermédiaire, différentes valeurs de taille de fenêtre acceptables. Avantageusement, l'étape de détermination si la première valeur sélectionnée courante est acceptée par ledit au moins un premier dispositif intermédiaire comprend l'étape suivante : 20 - envoi audit au moins un premier dispositif intermédiaire d'une requête d'allocation de ressources correspondant à la première valeur sélectionnée courante, et une valeur de taille de fenêtre est considérée comme acceptée par ledit au moins un premier dispositif intermédiaire lorsque le dispositif gestionnaire reçoit dudit 25 au moins un premier dispositif intermédiaire un rapport positif d'allocation de ressources correspondant à la première valeur sélectionnée courante. Selon une caractéristique de l'invention, préalablement à l'étape de réitération, il comprend les étapes suivantes : - détermination d'un ou plusieurs dispositifs, dit(s) dispositifs acceptant, 30 parmi le ou les premier(s) dispositif(s) intermédiaire(s), ayant accepté la 2908577 9 première valeur sélectionnée courante ; - envoi audit(auxdits) dispositif(s) acceptant d'une requête de libération de ressources correspondant à la première valeur sélectionnée courante. Ainsi, on peut libérer des ressources au niveau de ces dispositifs qui ont 5 accepté la première valeur sélectionnée courante, ce qui permet à ces dispositifs de pouvoir transmettre d'autres flux (ou contenus). Selon un mode de réalisation de l'invention, dans le cas où aucune première valeur sélectionnée n'est acceptée dans l'étape de détermination d'une première valeur acceptée, le procédé de gestion comprend également les étapes 10 suivantes : sélection d'au moins un second contenu de données, le second contenu étant en cours de transmission entre un second dispositif source et un second dispositif récepteur sur un second chemin de transmission comprenant au moins un second dispositif intermédiaire, au moins un du 15 ou desdits second(s) dispositif(s) intermédiaire(s) étant aussi un du ou desdits premier(s) dispositif(s) intermédiaire(s) ; détermination d'une valeur de taille de fenêtre acceptable, dite seconde valeur acceptable, pour la transmission du second contenu ; envoi, à au moins ledit au moins un second dispositif intermédiaire, d'une 20 information représentative de ladite seconde valeur acceptable afin de mettre à jour la transmission du second contenu suivant une taille de fenêtre égale à ladite seconde valeur acceptable. Ainsi, on peut réallouer, au niveau d'un dispositif du premier chemin de transmission, une partie des ressources dédiées à la transmission du second 25 contenu à la transmission du premier contenu. Préférentiellement, une valeur de taille de fenêtre est dite acceptable pour la transmission d'un contenu si elle vérifie au moins un des critères appartenant au groupe comprenant : - la valeur de taille de fenêtre est supérieure à une valeur maximale de taille 30 de paquet du contenu ; 2908577 10 - la valeur de taille de fenêtre est supérieure à une valeur minimale prédéfinie vérifiant n*MSS, où n est un coefficient dépendant de la priorité du contenu et MSS est une valeur maximale de taille de paquet du contenu 5 - la valeur de taille de fenêtre est supérieure à une taille minimale de fenêtre pour la transmission d'un contenu moins prioritaire ; - la valeur de taille de fenêtre est inférieure à un produit max_bandwidth * RTT sur le chemin de transmission du contenu, où max_bandwidth est la bande passante théorique maximale sur le chemin de 10 transmission du contenu et RTT est une valeur moyennée du temps de parcours du chemin de transmission du contenu. L'invention concerne également un procédé de gestion de ressources pour la transmission dans un réseau de communication d'un contenu de données entre un dispositif source et un dispositif récepteur sur un chemin de transmission 15 comprenant au moins un dispositif intermédiaire. Selon l'invention, un du ou desdits dispositifs intermédiaires, dit dispositif impliqué, effectue les étapes suivantes: réception d'un message comprenant une valeur de taille de fenêtre acceptée par au moins ledit au moins un dispositif intermédiaire pour la 20 transmission dudit contenu ; détermination de la position, sur le chemin de transmission, dudit dispositif impliqué ; - dans le cas où le dispositif impliqué est le dispositif récepteur, envoi au dispositif source d'un message, dit premier message d'initialisation, 25 d'initialisation de la transmission du contenu, ledit premier message d'initialisation comprenant la valeur acceptée. Selon un mode de réalisation de l'invention, dans le cas où le dispositif impliqué n'est pas le dispositif récepteur, le procédé comprend les étapes suivantes: 30 - réception d'un message, dit second message d'initialisation, d'initialisation 2908577 11 de la transmission du contenu, ledit second message d'initialisation comprenant au moins une valeur indiquant un niveau de ressources disponibles sur le dispositif récepteur pour la transmission du contenu, dite valeur retenue; 5 - détermination si la valeur retenue est supérieure à la valeur acceptée ; - si la valeur retenue est supérieure à la valeur acceptée, modification dudit second message d'initialisation, en remplaçant la valeur retenue par la valeur acceptée ; - envoi dudit second message d'initialisation au dispositif source. 10 Préférentiellement, dans le cas où le dispositif impliqué n'est pas le dispositif récepteur, le procédé comprend les étapes suivantes : -réception d'un message, dit message d'acquittement, d'acquittement de l'initialisation de la transmission du contenu, ledit message d'acquittement comprenant au moins une valeur indiquant un niveau de ressources 15 disponibles sur le serveur pour la transmission du contenu, dite valeur retenue; - détermination si la valeur retenue est supérieure à la valeur acceptée ; - si la valeur retenue est supérieure à la valeur acceptée, modification dudit message d'acquittement, en remplaçant la valeur retenue par la valeur 20 acceptée ; - envoi dudit message d'acquittement au dispositif récepteur. Avantageusement, si la valeur retenue n'est pas supérieure à la valeur acceptée, le procédé de gestion comprend en outre l'étape suivante : - envoi à un dispositif gestionnaire conforme à un protocole de signalisation 25 centralisé, d'un message comprenant la valeur retenue, afin de permettre une mise à jour d'une valeur de taille de fenêtre acceptée pour le contenu de données. Selon une caractéristique de l'invention, le procédé de gestion comprend en outre les étapes suivantes : 30 - réception d'au moins un paquet du contenu ; 2908577 12 - détermination à partir dudit au moins un paquet reçu d'une valeur minimale de taille de fenêtre pour la transmission du contenu, dite valeur inférieure ; - envoi à un dispositif gestionnaire, de la valeur inférieure, afin de permettre 5 une mise à jour d'un ensemble de valeur de taille de fenêtre acceptables pour la transmission du contenu. Selon une caractéristique de l'invention, la valeur inférieure correspond à une valeur maximale de taille de paquet du contenu. Avantageusement, une valeur de taille de fenêtre est dite acceptable pour 10 la transmission d'un contenu si elle vérifie au moins un des critères appartenant au groupe comprenant : - la valeur de taille de fenêtre est supérieure à une valeur maximale de taille de paquet du contenu ; - la valeur de taille de fenêtre est supérieure à une valeur minimale 15 prédéfinie vérifiant n*MSS, où n est un coefficient dépendant de la priorité du contenu et MSS est une valeur maximale de taille de paquet du contenu - la valeur de taille de fenêtre est supérieure à une taille minimale de fenêtre pour la transmission d'un contenu moins prioritaire ; 20 - la valeur de taille de fenêtre est inférieure à un produit max_bandwidth * RTT sur le chemin de transmission du contenu, où max_bandwidth est la bande passante théorique maximale sur le chemin de transmission du contenu et RTT est une valeur moyennée du temps de parcours du chemin de transmission du contenu. 25 L'invention concerne également un produit programme d'ordinateur, téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour la mise en oeuvre des procédés de gestion de ressources tels que précédemment décrits. 30 L'invention concerne également un moyen de stockage, éventuellement 2908577 13 totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre les procédés de gestion de ressources tel que précédemment décrits. L'invention concerne également un dispositif gestionnaire comprenant des 5 moyens de gestion de ressources pour la transmission dans un réseau de communication d'un premier contenu de données entre un premier dispositif source et un premier dispositif récepteur sur un premier chemin de transmission comprenant au moins un premier dispositif intermédiaire. Selon l'invention, les moyens de gestion comprennent : 10 - des moyens de détermination d"un ensemble de valeurs de taille de fenêtre acceptables pour la transmission du premier contenu ; des moyens de détermination d'une valeur de taille de fenêtre, dite première valeur acceptée, parmi l'ensemble de valeurs de taille de fenêtre acceptables déterminé, ladite première valeur acceptée étant la valeur de 15 fenêtre maximale acceptée par au moins ledit au moins un premier dispositif intermédiaire pour la transmission du premier contenu ; des moyens d'envoi, au premier dispositif récepteur, d'une information représentative de ladite première valeur acceptée afin d'initialiser la transmission du premier contenu entre le premier dispositif source et le 20 premier dispositif récepteur suivant une taille de fenêtre égale à ladite première valeur acceptée. Selon une caractéristique de l'invention, les moyens de détermination de la première valeur acceptée comprennent : des moyens de sélection d'une valeur de taille de fenêtre acceptable parmi 25 l'ensemble de valeurs de taille de fenêtre acceptables, dite première valeur sélectionnée courante ; des moyens de détermination si la première valeur sélectionnée courante est acceptée par ledit au moins un premier dispositif intermédiaire ; des moyens d'activation, dans le cas d'une détermination négative, desdits 30 moyens de sélection et desdits moyens de détermination avec une première 2908577 14 valeur sélectionnée suivante inférieure à la première valeur sélectionnée courante. Avantageusement, les moyens de détermination si la première valeur sélectionnée courante est acceptée par ledit au moins un premier dispositif 5 intermédiaire comprennent : - des moyens d'envoi audit au moins un premier dispositif intermédiaire d'une requête d'allocation de ressources correspondant à la première valeur sélectionnée courante, et une valeur de taille de fenêtre est considérée comme acceptée par ledit au moins 10 un premier dispositif intermédiaire lorsque le dispositif gestionnaire reçoit dudit au moins un premier dispositif intermédiaire un rapport positif d'allocation de ressources correspondant à la première valeur sélectionnée courante. Selon un mode de mise en oeuvre de l'invention, les moyens de gestion comprennent en outre : 15 - des moyens de détermination d'un ou plusieurs dispositifs, dit(s) dispositifs acceptant, parmi le ou les premier(s) dispositif(s) intermédiaire(s), ayant accepté 1 a première valeur sélectionnée courante ; - des moyens d'envoi audit(auxdits) dispositif(s) acceptant d'une requête de libération de ressources correspondant à la première valeur sélectionnée 20 courante. Selon une caractéristique avantageuse de l'invention, les moyens de gestion comprennent également : des moyens de sélection d'au moins un second contenu de données, le second contenu étant en cours de transmission entre un second dispositif 25 source et un second dispositif récepteur sur un second chemin de transmission comprenant au moins un second dispositif intermédiaire, au moins un du ou desdits second(s) dispositif(s) intermédiaire(s) étant aussi un du ou desdits premier(s) dispositif(s) intermédiaire(s) ; des moyens de détermination d'une valeur de taille de fenêtre acceptable, 30 dite seconde valeur acceptable, pour la transmission du second contenu ; 2908577 15 des moyens d'envoi, à au moins ledit au moins un second dispositif intermédiaire, d'une information représentative de laditeseconde valeur acceptable afin de mettre à jour la transmission du second contenu suivant une taille de fenêtre égale à ladite seconde valeur acceptable. 5 Avantageusement, une valeur de taille de fenêtre est dite acceptable pour la transmission d'un contenu si elle vérifie au moins un des critères appartenant au groupe comprenant : - la valeur de taille de fenêtre est supérieure à une valeur maximale de taille de paquet du contenu ; 10 - la valeur de taille de fenêtre est supérieure à une valeur minimale prédéfinie vérifiant n*MSS, où n est un coefficient dépendant de la priorité du contenu et MSS est une valeur maximale de taille de paquet du contenu - la valeur de taille de fenêtre est supérieure à une taille minimale de fenêtre 15 pour la transmission d'un contenu moins prioritaire ; la valeur de taille de fenêtre est inférieure à un produit max_bandwidth * RTT sur le chemin de transmission du contenu, où max_bandwidth est la bande passante théorique maximale sur le chemin de transmission du contenu et RTT est une valeur moyennée du temps de 20 parcours du chemin de transmission du contenu. L'invention concerne également un dispositif de transmission (qui correspond au dispositif impliqué précité) comprenant des moyens de gestion de ressources pour la transmission dans un réseau de communication d'un contenu de données entre un dispositif source et un dispositif récepteur sur un chemin de 25 transmission comprenant au moins un dispositif intermédiaire, ledit dispositif de transmission étant un du ou desdits dispositifs intermédiaires. Selon l'invention, les moyens de gestion comprennent : des moyens de réception d'un message comprenant une valeur de taille de fenêtre acceptée par au moins ledit au moins un dispositif intermédiaire 30 pour la transmission dudit contenu ; 2908577 16 des moyens de détermination de la position, sur le chemin de transmission, dudit dispositif de transmission ; - des moyens d'envoi au dispositif source d'un message, dit premier message d'initialisation, d'initialisation de la transmission du contenu, 5 ledit premier message d'initialisation comprenant la valeur acceptée, lesdits moyens d'envoi étant activés si le dispositif de transmission est le dispositif récepteur. Avantageusement, le dispositif de transmission étant distinct du dispositif récepteur, les moyens de gestion comprennent : 10 des moyens de réception d'un message, dit second message d'initialisation, d'initialisation de la transmission du contenu, ledit second message d'initialisation comprenant au moins une valeur indiquant un niveau de ressources disponibles sur le dispositif récepteur pour la transmission du contenu, dite valeur retenue; 15 - des moyens de détermination si la valeur retenue est supérieure à la valeur acceptée; - des moyens de modification dudit second message d'initialisation, en remplaçant la valeur retenue par la valeur acceptée, lesdits moyens de modification étant activés si la valeur retenue est supérieure à la valeur :20 acceptée; - des moyens d'envoi dudit second message d'initialisation au dispositif source. Préférentiellement, le dispositif de transmission étant distinct du dispositif récepteur, les moyens de gestion comprennent : 25 -des moyens de réception d'un message, dit message d'acquittement, d'acquittement de l'initialisation de la transmission du contenu, ledit message d'acquittement comprenant au moins une valeur indiquant un niveau de ressources disponibles sur le serveur pour la transmission du contenu, dite valeur retenue; 30 - des moyens de détermination si la valeur retenue est supérieure à la valeur 2908577 17 acceptée; - des moyens de modification dudit message d'acquittement, en remplaçant la valeur retenue par la valeur acceptée, lesdits moyens de modification étant activés si la valeur retenue est supérieure à la valeur acceptée ; 5 - des moyens d'envoi dudit message d'acquittement au dispositif récepteur. Avantageusement, les moyens de gestion comprennent en outre : - des moyens d'envoi à un dispositif gestionnaire conforme à un protocole de signalisation centralisé, d'un message comprenant la valeur retenue, afin de permettre une mise à jour d'une valeur de taille de fenêtre acceptée 10 pour le contenu de données, lesdits moyens d'envoi étant activés si la valeur retenue n'est pas supérieure à la valeur acceptée. Selon une caractéristique avantageuse de l'invention, les moyens de gestion comprennent en outre : - des moyens de réception d'au moins un paquet du contenu ; 15 - des moyens de détermination à partir dudit au moins un paquet reçu d'une valeur minimale de taille de fenêtre pour la transmission du contenu, dite valeur inférieure ; - des moyens d'envoi à un dispositif gestionnaire, de la valeur inférieure, afin de permettre une mise à jour d'un ensemble de valeurs de taille de 20 fenêtre acceptables pour la transmission du contenu. Avantageusement, la valeur inférieure correspond à une valeur maximale de taille de paquet du contenu. Préférentiellement, une valeur de taille de fenêtre est dite acceptable pour la transmission d'un contenu si elle vérifie au moins un des critères appartenant au 25 groupe comprenant : - la valeur de taille de fenêtre est supérieure à une valeur maximale de taille de paquet du contenu ; - la valeur de taille de fenêtre est supérieure à une valeur minimale prédéfinie vérifiant n*MSS, où n est un coefficient dépendant de la priorité 30 du contenu et MSS est une valeur maximale de taille de paquet du contenu 2908577 18 - la valeur de taille de fenêtre est supérieure à une taille minimale de fenêtre pour la transmission d'un contenu moins prioritaire ; - la valeur de taille de fenêtre est inférieure à un produit 5 max_bandwidth * RTT sur le chemin de transmission du contenu, où max_bandwidth est la bande passante théorique maximale sur le chemin de transmission du contenu et RTT est une valeur moyennée du temps de parcours du chemin de transmission du contenu. Les avantages des produit programme d'ordinateur, moyen de stockage, 10 dispositif gestionnaire et dispositif de transmission sont les mêmes que ceux des procédé de gestion de ressource précédemment décrit, ils ne sont pas détaillées plus amplement. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus 15 clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un schéma d'un réseau local dans lequel peut être mis en oeuvre le procédé de transmission selon un mode de réalisation 20 conforme à l'invention ; la figure 2 présente un schéma d'un dispositif générique apte à mettre en oeuvre le procédé de transmission selon le mode de réalisation particulier de l'invention précité ; la figure 3 illustre le principe du procédé de transmission du contenu cO 25 selon le mode de réalisation particulier de l'invention précité dans le cadre du réseau 100 de la figure 1 ; la figure 4 présente les étapes d'un algorithme mis en oeuvre par un équipement Digital Media Player du réseau local lorsque le QosManager met en oeuvre le procédé de transmission de cO selon le mode 30 de réalisation particulier précité de l'invention ; 2908577 19 la figure 5 présente les étapes principales d'un algorithme d'obtention de la valeur de la taille de fenêtre acceptée pour c0 mis en oeuvre par le QosManager du réseau local clans le cadre du procédé de transmission selon le mode de réalisation précité de l'invention ; 5 la figure 6 présente les étapes principales d'un algorithme de mise à jour de la valeur de la taille de fenêtre pour la transmission d'un flux TCP cl selon un mode de mise en oeuvre préférentiel de l'invention. 6. Description d'un mode de réalisation de l'invention On décrit ci-après le procédé de réservation de ressource selon un mode de 10 réalisation particulier de l'invention dans le cadre d'un réseau local 100 (dont un schéma est illustré en figure 1) qui comprend notamment des équipements conformes à un protocole de signalisation centralisée, par exemple le protocole UPnP QoS . Bien entendu, le protocole de signalisation centralisé peut être tout autre 15 protocole que le protocole UPnP QoS. Le réseau local 100 est par exemple un réseau mettant en oeuvre le protocole IEEE 802 (ou tout autre protocole de type IEEE 802-x) tel que le protocole Ethernet et permet de mettre en oeuvre des communications de type UPnP QoS (au moins entre certains équipements) pour lesquelles chaque 20 équipement UPnP QoS (ou équipement mettant en oeuvre le standard UPnP QoS) du réseau est identifié et communique périodiquement la description de ses services. Le réseau local 100 comprend à la fois des équipements terminaux qui sont visibles par l'utilisateur (par exemple des terminaux multimédia du réseau local 25 100 qui sont directement contrôlés par l'utilisateur) et des équipements d'infrastructure réseau permettant la liaison entre ces équipements terminaux. On notera que le réseau local 100 peut aussi bien être un réseau domestique qu'un réseau local d'entreprise, constitué partiellement ou totalement de segments sans fil (par exemple conformes aux normes Wifi ou 30 Bluetooth , marques déposées). 2908577 20 La catégorie des équipements terminaux comprend notamment : un serveur de flux multimédia 110 répondant à la norme UPnP AV (que l'on appelle également UPnP MediaServer ) qui est notamment capable d'émettre en continu des contenus vidéo suivant des protocoles réseau et 5 qui fonctionne en mode connecté (par exemple via le protocole HTTP sur TCP/IP) et/ou en mode non connecté (par exemple via le protocole RTP sur le protocole UDP/IP). Ce serveur peut notamment être un ordinateur personnel, un lecteur DVD ou une caméra possédant une connectivité IP ; un terminal client 120, disposant d'un service UPnP Media Renderer , 10 qui peut notamment être un ordinateur personnel ou un écran de téléviseur apte à afficher les flux multimédia en provenance du serveur 110 ; un poste de contrôle UPnP 160, qui peut notamment être un ordinateur personnel, une tablette PC, un assistant personnel (ou PDA), une télécommande proposant à l'utilisateur une sélection d'équipements UPnP 15 sur le réseau local 100 et des contenus multimédia à jouer. La catégorie des équipements d'infrastructure réseau comprend notamment des équipements d'interconnexion 140A, 140B et 140C qui peuvent notamment être : des équipements de routage de niveau 2, par exemple des commutateurs 20 (ou switches en anglais) qui sont des dispositifs d'interconnexion de plus de deux segments Ethernet, suivant un critère d'acheminement basé au niveau réseau 2 (par exemple des adresses MAC Ethernet) ; des ponts entre deux segments du réseau (par exemple, un ordinateur disposant de deux cartes réseau constitue un pont). 25 Ces équipements d'infrastructure réseau 140A, 140B et 140C implémentent généralement des protocoles de QoS tels que des protocoles de gestion de priorité des flux (par exemple le protocole IEEE-802.1p) ou des protocoles de signalisation de réservation en ligne QoS tel que le protocole SBM normalisé par RFC-2814. Ils peuvent également implémenter le standard UPnP 30 QoS. 2908577 21 Un pont est un matériel d'interconnexion qui relie deux segments Ethernet. A chacun des segments auquel est connecté un pont, est associée une table des adresses MAC des équipements terminaux de ce segment qui est gérée par le pont. Une telle table est construite par le pont à l'aide d'un processus d'apprentissage 5 dans lequel, à chaque émission d'une trame par un équipement, le pont stocke dans la table l'adresse MAC de l'équipement terminal en regard avec le segment concerné. Ces tables permettent au pont de router les trames. En effet, lorsque le pont reçoit une trame provenant de son premier segment, il relaye la trame vers son 10 second segment dans l'un des cas suivants : l'adresse du destinataire de la trame correspond à une adresse du second segment ; il s'agit d'une adresse de diffusion (ou broadcast en anglais) ; l'adresse n'est pas connue par le pont. 15 Un commutateur est considéré comme un pont qui a plus de deux interfaces. Des services conformes au standard UPnP QoS (tels que des QosDevice, des QosPolicyHolder ou des QosManager) peuvent être embarqués dans certains des équipements du réseau local 100 (tel qu'indiqué dans la norme UPnP QoS). Les services UPnP QosDevice sont embarqués notamment sur les 20 équipements d'interconnexion 140A, 140B et 140C de la figure 1, mais aussi sont supportés par le serveur 110 et le terminal client 120 (ou les premier 120A et second 120B terminaux clients de la figure 3). Par ailleurs, le réseau local 100 comprend un service UPnP QosManager unique qui est par exemple embarqué dans un dispositif 150 que 25 l'on désigne ci-après par QosManager 150 (autrement appelé dispositif gestionnaire dans le cadre de la réservation de ressource). Cependant, ce
service UPnP QosManager peut être embarqué dans n'importe quel équipement du réseau local 100 disposant préférentiellement d'une plateforme matérielle identique à celle de l'équipement générique 200 décrit ci- 30 après en relation avec la figure 2. La norme UPnP QoS définit plus précisément 2908577 22 les procédures à suivre pour choisir le responsable QosManager actif si plusieurs services sont en concurrence. Dans la suite, on décrit le procédé de transmission selon le mode de réalisation particulier de l'invention précité dans un exemple particulier de la 5 transmission, conforme au protocole T'CP, d'un contenu (ou flux) multimédia cO sur un chemin de transmission entre un dispositif source (serveur de flux multimédia 110) et un dispositif récepteur (terminal client 120 ou le second 120B terminal client de la figure 3) appartenant au réseau local 100. Bien entendu, le procédé de transmission selon l'invention s'applique au 10 contexte de tout autre protocole de transmission par rafales tel que le protocole LLC-2 (conformément au standard IEEE 802.2) qui fournit un service de transmission de type ARQ pour la sous-couche liaison commune aux standards IEEE de niveau MAC (802.3, 802.4, 803.5,...) ou tel que le protocole HDLC, pour High-Level Data Link Control , qui est un protocole de niveau 2 de la couche 15 OSI utilisé pour supporter des protocoles de communication tels que H.323, V.120 ou X.25. Ainsi lors de la sélection du contenu cO par un utilisateur via le poste de contrôle 160, un message 180 (par exemple un message RequestTrafficQos conforme au protocole UPnP-QoS, message ci-après désigné par 20 RequestTrafficQos ) est envoyé au QosManager 150 en vue de l'avertir du type de contenu multimédia cO à recevoir et de préparer les ressources QoS nécessaires au bon acheminement du contenu cO entre le serveur de flux multimédia 110 et le terminal client 120 (ou le second 120B terminal client de la figure 3). Ensuite, le QosManager 150 cherche à obtenir le chemin de transmission 25 de cO à travers le réseau, afin de déterminer quels sont les équipements QosDevice à informer de la réservation de ressources à effectuer pour la transmission du contenu cO (confirmation des paramètres QoS du contenu cO par émission vers les équipements QosDevice d'un message SetupTrafficQos 181 conforme au protocole UPnP QoS ci-après désigné par SetupTrafficQos ). 2908577 23 Si tous les équipements QosDevice présents sur le chemin de transmission de c0 (par exemple comprenant les QosDevice 140A à 140C) admettent les caractéristiques QoS du contenu c0, le QosManager 150 acquittera (ou accusera réception de) la requête du poste de contrôle 160, et ce dernier autorisera le 5 terminal client 120 (ou le second 120B terminal client de la figure 3) à jouer le contenu multimédia c0 (par exemple au moyen d'un message Avt_Play 182 conforme au protocole UPnP AV, message ci-après désigné par Avt_Play ). Le terminal client 120 (ou le second 120B terminal client de la figure 3) enverra alors une requête de lecture du flux multimédia au serveur de flux 110 10 (par exemple au moyen d'un message de type RTSP afin de recevoir le flux multimédia au format de diffusion RTP ou au moyen d'une requête HTTP pour accéder directement à la ressource multimédia). Dans le cas de la transmission ,du contenu c0 conformément au protocole TCP (le poste de contrôle 160 propose une URL d'accès au contenu en mettant en 15 oeuvre le protocole HTTP), une requête HTTP GET est émise depuis le client 120 (ou le second 120B terminal client de la figure 3) vers le serveur 110. L'ouverture de cette connexion TCP suit les étapes conformes à la norme TCP décrites en annexe 1 (messages SYN 191 et message SYN-ACK 192). Le contenu transmis par la suite est noté 190. 20 Le procédé de transmission selon l'invention (décrit de manière plus détaillée en relation avec les figures 3 à 6) est mis en oeuvre sous la forme d'un logiciel et/ou d'une pluralité de sous logiciels (comprenant une pluralité d'algorithmes décrits ci-après) qui est (sont) exécuté(s) dans une ou plusieurs machines du réseau local 100, par exemple dans le QosManager 150. :25 On présente, en relation avec la figure 2, un schéma d'un dispositif générique 200 apte à mettre en oeuvre le procédé de transmission de c0 selon le mode de réalisation particulier de l'invention précité. Par exemple, le QosManager 150 précité en relation avec la figure 1 est identique au dispositif générique 200 décrit en relation avec la figure 2. 30 Ce dispositif générique 200 peut notamment être connecté à tout moyen de 2908577 24 stockage d'image, de vidéos, ou de sons reliés à une carte graphique et délivrant au dispositif générique 200 des données multimédia. Ainsi, le dispositif générique 200 comporte un bus de communication 202 auquel sont reliés : 5 une unité centrale de traitement 203 (qui est par exemple un microprocesseur référencé CPU) ; une mémoire morte 204 référencée ROM, pouvant comporter le ou les logiciel(s) précité(s) et référencé(s) Prog ; une mémoire vive 206 (mémoire cache référencée RAM), comportant des 10 registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution du ou des logiciel(s) précité(s) ; un écran 208 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec le ou les logiciel(s) selon l'invention, à l'aide d'un clavier 210 ou de tout 15 autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 211 ou un crayon optique ; une interface de communication 218 reliée à un réseau de communication distribué 220, par exemple le réseau local 100, l'interface étant apte à transmettre et à recevoir des données. 20 Le dispositif générique 200 comprend également (mais ceci est optionnel) : un disque dur 212 pouvant comporter le ou les logiciel(s) Prog ; un lecteur de disquette 214 adapté à recevoir une disquette 216 et à y lire ou à y écrire des données traitées ou à traiter conformément au procédé de 25 réservation de ressource selon l'invention. Bien entendu, au lieu de la disquette 216, on peut mettre en oeuvre tout support d'information lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser le ou les logiciel(s) selon l'invention (par exemple, un disque compact (CD-ROM) ou une carte 30 mémoire). 2908577 25 Le bus de communication 202 permet la communication et l'interopérabilité entre les différents dispositifs inclus dans le dispositif générique 200 ou reliés à cet équipement. De manière plus générale, grâce au bus de communication 202, l'unité 5 centrale 203 est susceptible de communiquer des instructions à tout dispositif inclus dans le dispositif générique 200 directement ou par l'intermédiaire d'un autre dispositif du dispositif générique 200. Le code exécutable de chacun du ou des logiciel(s) précités permettant au dispositif générique 200 de mettre en oeuvre le procédé de réservation de 10 ressource selon l'invention, peut être stocké, par exemple, dans le disque dur 212 ou dans la mémoire morte 204. L'unité centrale 203 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des logiciel(s) selon l'invention. Lors de la mise sous tension, le ou les logiciels qui sont stockés dans une mémoire non volatile 15 (par exemple le disque dur 212 ou la mémoire morte 204), sont transférés dans la mémoire vive 206 qui contiendra alors le code exécutable du ou des logiciel(s) selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre du procédé de réservation de ressource selon l'invention. :20 On illustre, en relation avec la figure 3, le principe du procédé de transmission du contenu c0 selon le mode de réalisation particulier de l'invention précité dans le cadre du réseau 100 de lia figure 1. Dans le cadre de cette figure 3, le terminal client 110 du réseau 100 illustré en figure 1 est remplacé par des premier terminal client 120A et second terminal :25 client 120B. Dans la suite, on suppose qu'un contenu 190 est déjà en transit entre le premier terminal client 120A et le serveur de flux multimédia 110. Le poste de contrôle 160 informe le QosManager 150 d'une requête d'établissement de QoS selon des caractéristiques précises (au moyen des étapes 401 à 405 de l'algorithme 30 ci-après décrit en relation avec la figure 4) pour l'introduction d'un contenu 2908577 26 multimédia cO conforme au protocole TCP à transmettre du serveur 110 vers le second terminal client 120B. Ces caractéristiques QoS sont préalablement obtenues par le poste de contrôle 160 par la description du media cO offerte par le UPnP MediaServer 110 comme décrit ci-après en relation avec la figure 4. 5 Lors d'une étape 1, une requête (ou message) RequestTrafficQos 301 est envoyée du poste de contrôle 160 vers le QosManager 150. Sur détection que le nouveau contenu cO est de type TCP, le QosManager 150 détermine une valeur initiale acceptable de taille de fenêtre TCP (ou TCP window size ) pour le contenu cO en fonction des caractéristiques de cO qui sont 10 précisées dans la structure TSPEC contenue dans la requête RequestTrafficQos. Une valeur de taille de fenêtre est dite acceptable pour la transmission d'un contenu si elle vérifie au moins un des critères appartenant au groupe comprenant : -la valeur de taille de fenêtre est supérieure à une valeur maximale de taille 15 de paquet du contenu, appelée MSS ; - la valeur de taille de fenêtre est supérieure à une valeur minimale prédéfinie (n*MSS), où n est un coefficient prédéterminé fonction de la priorité du flux ; - la valeur de taille de fenêtre est supérieure à une taille minimale de fenêtre 20 pour un contenu de priorité inférieure (proportionnellement à leur débit) ; c'est-à-dire qu'un flux de plus forte priorité sera privilégié dans l'allocation de ressources liée à la taille de fenêtre ; - la valeur de taille de fenêtre est inférieure à un produit max_bandwidth * RTT sur le chemin, où max_bandwidth est la bande :25 passante théorique maximale sur le lien réseau et RTT est une valeur moyennée du paramètre RTT (pour Round Trip Time ) ou temps de parcours du chemin de transmission. Comme expliqué dans l'annexe 1 relative au protocole TCP, la valeur de la taille de fenêtre TCP initiale déterminée à l'ouverture de la connexion correspond 30 à la taille maximum des données transmises en une ou plusieurs rafale pour un 2908577 27 flux donné avant retour d'un acquittement de réception des données par le dispositif récepteur. Cette valeur est directement appliquée à une taille mémoire réservée pour un contenu TCP. Le choix de cette valeur mémoire est crucial. Dans l'état de l'art, cette 5 valeur est dissociée de toute considération de ressource mémoire disponible sur le réseau. Le procédé de transmission selon l'invention vise à calculer une valeur de fenêtre initiale idéale selon les caractéristiques du flux cO à transporter, puis à éventuellement adapter (ou ajuster) cette valeur aux conditions environnementales du réseau de façon à obtenir une valeur acceptée (définie ci-après). 10 De manière générale, une taille mémoire (ou Buffer_size ) suit la formule suivante : Buffer_size = bandwidth * delay (1) ou : Buffer size = bandwidth * RTT (2) 15 où bandwidth est la bande passante et delay est le temps maximum écoulé entre la transmission d'une donnée par le dispositif source et la réception de son acquittement. La valeur du paramètre RTT (pour Round Trip Time ) est facilement obtenue, par exemple, grâce à l'envoi d'un message ping , et est déterministe 20 sur le réseau local 100. Dans une étape 2, le QosManager 150 initie une négociation (qui sera détaillée ci-après en relation avec la figure 5) de la valeur de la taille de fenêtre pour cO avec tous les QosDevices intermédiaires (dans le présent cas les dispositifs 140A, 140B et 140C) présents sur le chemin de transmission du flux cO 25 entre le serveur de flux multimédia 110 et le second terminal client 120B. Pour ce faire, il envoie à chacun d'eux un message SetupTrafficQos 302 (et éventuellement un message AdmitTrafficQos du protocole UPnP QoS). Dans le cadre de cette négociation, le QosManager 150 est apte à modifier les caractéristiques du flux cO proposées par le poste de contrôle 160. En effet, la 30 structure TSPEC sert à inclure des informations telles que le débit binaire (ou bit 2908577 28 rate ) en bits par seconde (ou bps ), la latence (en ms), la gigue (en ms) et/ou la classification du trafic (par exemple jeu, audio, vidéo, etc...). On présente ci-après des exemples de champs de la structure TSPEC utiles dans le cadre de la présente invention : 5 - Maximum burst size (ou taille de rafale maximale en octets) : supporte l'échange de la valeur de fenêtre TCP calculée à l'étape 1, donnant la limite de la rafale de transmission de paquets du serveur ; - Maximum Packet size (ou taille de paquet maximale en octets) : supporte l'échange de la valeur du champ TCP MSS (cf. annexe 1) lorsque 10 celle-ci sera connue (après établissement de la connexion), donnant la limite minimale que la fenêtre TCP ne doit pas franchir. On verra par la suite que cette valeur sera utile dans les algorithmes d'ajustement de la valeur de la taille de fenêtre d'un flux existant ; - MeanDatarate (ou bande passante moyenne en bits/s) : supporte 15 l'indication de bande passante du flux vidéo, qui est généralement obtenue par le poste de contrôle 160 sur information fournie par le serveur 110, comme stipulé dans le standard UPnP AV. Dans une étape 3, chaque dispositif d'interconnexion 140A à 140C comprenant le service UPnP QosDevice du standard UPnP QoS vérifie son état de 20 fonctionnement (en particulier, son état de congestion). Ainsi, un dispositif intermédiaire donné du chemin de transmission peut éventuellement avertir le QosManager d'une incapacité à mener à bien la politique QoS recommandée par le QosManager 150. Dans ce cas, le QosManager 150 découvre que des ressources sont 25 manquantes, et il recherche alors parmi les flux qui transitent par le dispositif donné, le ou les flux à dégrader (par exemple le flux 190) dont la QoS peut être réduite. La politique de réduction peut par exemple être basée sur une gestion de priorité entre les flux, et/ou l'ajustement disponible (écart entre la valeur de fenêtre initiale qui reste le maximum, et la valeur du champ TCP MSS qui est le 30 minimum). 2908577 29 Par exemple, le flux multimédia 190 est détecté comme étant un flux TCP à dégrader (ou qui peut être ajusté) afin de permettre l'introduction d'un autre flux concurrent (le flux cO en cours d'admission). Dans une étape 4, une fois que les flux à dégrader ont été identifiés, le 5 QosManager 150calcule les nouvelles valeurs de taille de fenêtre TCP pour ces flux à dégrader, et la nouvelle valeur de taille de fenêtre pour le flux cO en cours d'admission. Ensuite, pour chaque flux en cours de transmission à mettre à jour (dont le flux 190), et pour le flux cO en cours d'admission, les QosDevice intermédiaires 10 du chemin de transmission de ce flux (par exemple les QosDevices 140A à 140C pour le flux cO) reçoivent chacun, dans un message SetupTrafficQos 302, une nouvelle valeur de taille de fenêtre pour ce flux. Dans le cas du second terminal client 120B (concerné par la transmission du flux cO), pour chaque flux en cours de transmission à mettre à jour (dont les 15 flux cO et 190), le QosManager 150 fournit la valeur de taille de fenêtre déterminée pour ce flux au second terminal client 120B. Pour ce faire, deux possibilités conformes à l'invention détaillées ci-après sont offertes. La première possibilité conforme à l'invention consiste à remettre cette nouvelle valeur au poste de contrôle 160 en retour du message RequestTrafficQoS 20 301 que le poste de contrôle 160 a préalablement envoyée au QosManager 150. Le poste de contrôle 160 est ensuite en charge de transmettre cette nouvelle valeur au second terminal client 120B par l'intermédiaire d'un message 303 conforme à la norme UPnP AV (par exemple un message PrepareForConnection , ou un message SetAvTransportUri ou un message Avt_Play ). Cette première 25 possibilité implique que le corps des messages UPnP AV dédiés à cette transmission doit être modifié et que ces messages ne sont donc plus conformes au standard UPnP AV. La seconde possibilité conforme à l'invention est privilégiée dans le cadre du présent mode de réalisation particulier, car elle respecte les standards UPnP en 30 place. Elle consiste en ce que le QosManager 150 informe directement le second 2908577 30 terminal client 120B de la nouvelle valeur de taille fenêtre choisie à travers la structure TSPEC incorporée dans le corps d'un message SetupTrafficQos 304 (selon l'Application Programming Interface ou API UPnP QosDevice). Une fois informé de la valeur de fenêtre TCP choisie en fonction des 5 capacités des équipements d'interconnexion 140A à 140C du chemin de transmission, et sur réception du message Avt_Play 303 en provenance du poste de contrôle 160, le second terminal client 120B active, au moyen d'un message 305, la création de la connexion TCP en direction du serveur 110. Cette activation est réalisée en indiquant la nouvelle valeur de taille de 10 fenêtre TCP dans un message TCP SYN 305 en remplacement de la valeur classique proposée par le système d'exploitation exécutant le logiciel et/ou la pluralité de sous logiciels de l'invention précité(s). Après établissement de la connexion, la valeur du champ TCP MSS du message TCP SYN est obtenue par le second terminal client 120B qui la conserve 15 afin de la transmettre au QosManager 150. Conformément à l'invention, le second terminal client 120B peut envoyer des messages d'alerte 306 (notifications UPnP ou événements) au QosManager 150 dans les cas suivants : - si la nouvelle valeur de la taille de fenêtre TCP reçue dans le message 20 d'acquittement TCP SYN en provenance du serveur 110 est inférieure à l'originale, il est important d'adapter les réservations de QoS afin de ne pas allouer des ressources dans les équipements d'interconnexion 140A à 140C qui ne seront jamais utilisées ; - pour informer de la valeur du champ TCP MSS issue de la connexion : le 25 QosManager connaît ainsi la taille mémoire tampon minimale pour un paquet TCP, et ainsi il peut ajuster la taille de la fenêtre TCP de telle façon qu'elle soit égale à n * MSS, ou n est un entier supérieur ou égal à 1. Dans le cas du premier terminal client 120A (concerné par la transmission du flux 190 à mettre à jour), pour chaque flux en cours de transmission à mettre à 30 jour (dont le flux 190), le QosManager150 informe le client 120A de la nouvelle 2908577 31 valeur de la taille de fenêtre. Ainsi, par exemple, QosManager 150 informe directement le premier terminal client 120A de la nouvelle valeur de taille fenêtre choisie en incorporant cette nouvelle valeur dans le champ Maximum Burst Size de la structure 5 descriptive TSPEC du flux d'un message SetupTrafficQos 307. Afin d'appliquer cette nouvelle recommandation de fenêtre, le premier terminal client 120A doit mettre en oeuvre un algorithme 308 d'adaptation ou d'ajustement de la valeur de la taille de fenêtre du flux pour le contrôle du flux. Pour ce faire, le premier terminal client 120A peut par exemple mettre en oeuvre 10 l'une des deux solutions suivantes. Dans une première solution conforme à l'invention, le premier terminal client 120A modifie de manière dynamique la valeur de la taille de fenêtre TCP advertised window (aussi appelée acknowledge-window ) dans un paquet d'acquittement (ou ACK pour acknowledgment) renvoyé vers le serveur 110. 15 En effet, tel qu'indiqué en annexe 1, conformément au protocole TCP, chaque en-tête de segment contient un champ de fenêtre instantanée appelé advertised-window qui spécifie combien d'octets supplémentaires de données le client est prêt à accepter. Un fait important au sujet du protocole TCP est que le serveur n'est pas autorisé à envoyer plus d'octets que ce qui est spécifié dans le :20 champ advertised window . Ainsi, cette valeur indique au serveur une limite pour la transmission, et peut être assimilée à la taille mémoire que le client est apte à recevoir. En théorie, le protocole TCP a prévu que cette valeur puisse être nulle, auquel cas un envoi d'un autre paquet ACK appelé window update serait nécessaire pour annoncer 25 que le client est prêt à recevoir les données. En pratique, cela ne se produira pas avec la présente invention car la valeur initiale de la fenêtre TCP est déjà corrélée avec les ressources QoS d'un état précédent du réseau. Afin de réduire/augmenter le débit du serveur, le client modifie la valeur du champ advertised window selon la formule suivante : 30 new_advertised_WD = advertised_WD û (initWD û updateWD) 2908577 32 où : - initWD est la valeur maximale de la fenêtre (valeur initiale négociée à l'établissement de la connexion) ; - updateWD est la nouvelle valeur maximale de la fenêtre spécifiée ; 5 advertised_WD est la valeur théorique de disponibilité dans le buffer du récepteur (inférieure ou égale à initWD) ; - new_advertised_WD est la valeur à émettre dans le paquet d'acquittement advertised window . Dans une seconde solution conforme à l'invention, on met en oeuvre un 10 champ ECN (pour Explicit Congestion Notation ) dans l'entête d'un message TCP. La mise en oeuvre du champ ECN améliore les performances du protocole TCP. En effet, lorsqu'un équipement routeur ou commutateur détecte l'occurrence d'une congestion (avant que tout le buffer ne soit rempli), cet équipement a la 15 possibilité d'indiquer la congestion par positionnement du code Congestion Experienced ou CE dans le champ Explicit Congestion Notification de l'entête de la trame IP (conformément à la norme RFC3168). Un des avantages de l'utilisation du champ ECN est que cela permet d'éviter la perte non nécessaire de paquets pour des connexions TCP sensibles au 20 délai (tel que par exemple des connexions de type streaming de vidéos). Le protocole ECN permet aussi d'éviter des timeouts (ou écoulements de délais) TCP pour la retransmission. Ainsi, lorsque ce champ est positionné, il indique une congestion et le serveur régule plus lentement son débit d'émission : il n'augmente plus la fenêtre 25 cwnd d'émission. Le premier terminal client 120A a la possibilité de marquer ce bit lorsqu'il détecte que la valeur de la fenêtre TCP dynamique cwnd approche du nouveau seuil qui lui a été indiqué. On présente, en relation avec la figure 4, les étapes d'un algorithme mis en oeuvre par un équipement Digital Media Player du réseau local 100 conforme 30 à l'invention lorsque le QosManager 150 met en oeuvre le procédé de transmission 2908577 33 de cO selon le mode de réalisation particulier précité de l'invention. Un équipement Media Player est un équipement disposant des programmes applicatifs capables de jouer des contenus multimédia (à la fois audio et vidéo). Dans la terminologie DLNA (pour Digital Living Network 5 Alliance ), un équipement DMP (pour Digital Media Player ) appartient à une classe d'équipements comprenant des fonctionnalités poste de contrôle (ou UPnP Control Point ) et des fonctionnalités de visualisation locale (ou UPnP MediaRenderer ). Par exemple, dans le cadre d'un mode de mise en oeuvre particulier de 10 l'invention, l'équipement Digital Media Player ci-après dénommé équipement DMP est constitué, au moins en partie, par le poste de contrôle 160 et le terminal client 120 (ou au moins un des premier et second terminaux clients de la figure 2) du réseau local 100 de la figure 1. Par exemple, cet équipement Digital Media Player est architecturé sensiblement de la même façon que le dispositif 15 générique 200 de la figure 2. Les actions réalisées par l'équipement DMP conforme à l'invention, lors de la réception d'une commande de l'utilisateur pour l'affichage local sur le terminal client 120 du flux multimédia cO conforme au protocole TCP et sélectionné sur le serveur 110 distant, sont présentées ci-dessous. 20 Dans une étape 400, l'équipement DMP (en tant que poste de contrôle 160) reçoit une commande interne présentant la sélection par l'utilisateur depuis une interface graphique du contenu multimédia cO situé sur le serveur 110. Par soucis de simplification, on supposera que le protocole d'accès à ce contenu est de type HTTP sur TCP. 25 Dans une étape 401, l'équipement DMP recueille les informations relatives au flux multimédia cO mis à disposition par le serveur 110. Ces informations ont préalablement été obtenues par l'envoi d'une ou plusieurs requêtes Browse comme spécifié par la norme UPnP AV pour le service CDS ou ContentDirectoryService . Selon cette même norme, les réponses données par 30 le serveur 110 contiennent notamment un champ ressource res précisant le 2908577 34 type (ou version) de flux de transport pour cO et certains éléments tels que la bande passante nécessaire. Il existe un champ ressource par type (ou version) de flux de transport pour le contenu multimédia cO, sachant que le serveur 110 peut proposer différentes versions de ce contenu cO selon par exemple des critères de 5 qualité. Selon la convention, la liste des champs ressource est ordonnée par ordre de priorité décroissante selon les volontés du serveur 110. En pratique, les premières descriptions correspondent aux meilleures résolutions du contenu multimédia cO, et donc à des critères QoS plus stricts. 10 L'équipement DMP sélectionne un champ ressource pour cO. Dans une étape 402, le champ ressource sélectionné est analysé afin de formater les critères des QoS relatifs au flux cO dans la structure TSPEC d'un message RequestTrafficQoS à envoyer au QosManager 150. Dans une étape 403, l'équipement DMP vérifie s'il reçoit une réponse 15 d'acceptation par le QosManager 150. Dans une étape 404, si l'équipement DMP ne reçoit pas d'acceptation du QosManager 150, alors, il vérifie s'il est possible (en fonction des capacités du réseau) de mettre en oeuvre d'autres type (ou version) de flux de transport pour cO, chacun associé à un champ de ressource. 20 S'il est possible (en fonction des capacités du réseau) de mettre en oeuvre d'autres type (ou version) de flux de transport pour cO, alors dans une étape 405, l'équipement DMP sélectionne un autre champ ressource pour cO parmi les champs de ressource associés à ces types de flux de transport. Puis, l'étape 402 est à nouveau mise en oeuvre. '25 S'il n'est pas possible (en fonction des capacités du réseau) de mettre en oeuvre d'autres type (ou version) de flux de transport pour cO, alors dans une étape 409, il est mis fin à l'algorithme. Si l'équipement DMP reçoit une acceptation du QosManager 150, alors, alors une étape 406 est mise en oeuvre. 30 Selon le mode de réalisation précité de l'invention, l'équipement Digital 2908577 Media Player comprend aussi un service UPnP QosDevice. Grâce à l'implémentation de ce service QosDevice, dans l'étape 406, l'équipement DMP reçoit un message SetupTrafficQos par lequel le QosManager 150 indique, à l'équipement DMP, les paramètres QoS du flux c0 qui ont été 5 négociés (au moyen de l'algorithme d'obtention ci-après décrit en relation avec la figure 5) par le QosManager 150 sur le réseau local 100 avec tous les QosDevice intermédiaires 140A à 140C du chemin de transmission de c0 entre le serveur 110 et l'équipement DMP (en tant que terminal client 120) mettant en oeuvre le présent algorithme. 10 On peut noter que les informations envoyées dans ce message SetupTrafficQos sont plus précises que les informations originelles récupérées par l'équipement DMP (en tant que poste de contrôle 160) dans les étapes 401 et 405. Ces informations structurées dans la structure TSPEC comprennent 15 notamment la valeur de la taille de fenêtre TCP acceptée à utiliser lors de l'ouverture de la connexion TCP (champ Maximum burst size ) pour la transmission de c0. Cette valeur est stockée dans les mémoires internes de l'équipement DMP et est notée maxWI) dans le sens ou cette valeur de la taille de fenêtre acceptée est un maximum qu'il ne faudra jamais dépasser du fait que la 20 connexion est paramétrée sur cette valeur. Selon une variante du mode de réalisation précité de l'invention, l'équipement DMP n'intègre pas de service UPnP QosDevice (et ne reçoit donc pas de message SetupTrafficQos dans l'étape 406). Dans ce cas, la valeur de la taille de fenêtre acceptée maxWD est obtenue en réponse au message 25 RequestTrafficQoS envoyé au QosManager 150 par l'équipement DMP (en tant que poste de contrôle 160). On notera que cette variante n'est pas privilégiée dans le sens où elle n'est pas standard au protocole UPnP QoS. Les algorithmes de détermination de la valeur de la taille de fenêtre TCP acceptée maxWD proposée par le QosManager 150 seront explicités ci-après en 30 relation avec la figure 5. 2908577 36 Sur réception d'une commande interne émanant de l'interface graphique locale pour jouer le flux cO, dans une étape 407, l'équipement DMP (en tant que terminal client 120) ouvre une connexion TCP avec le serveur 110 en précisant la valeur maxWD dans le segment TCP SYN. 5 Selon une autre variante du mode de réalisation précité, l'activation de l'étape 400 implique explicitement la demande de l'utilisateur de jouer le contenu multimédia cO sélectionné. Dans ce cas, l'activation de l'étape 407 est directe. A la fin de la phase de connexion TCP, dans une étape 408, des informations relatives à cette connexion TCP sont envoyées par l'équipement 10 DMP au QosManager 150. Ces informations sont par exemple la valeur de la taille de la fenêtre TCP modifiée pour le transport du flux cO (en effet, il arrive que le serveur 110 abaisse la valeur acceptée spécifiée par le QosManager pour le terminal client 120) et la valeur MSS de cette connexion. Ces informations peuvent être rendues en réponse au message 15 SetupTrafficQos , ou par un événement UPnP proposé par le service UPnP QosDevice. Dans tous les cas, la valeur maxWD doit refléter la valeur de fenêtre TCP négociée par la phase d'établissement de la connexion TCP, et cette valeur est enregistrée localement dans la structure TSPEC décrivant le flux en cours cO (champ Maximum Burst size ). De même, la valeur MSS est stockée dans le :20 champ Maximum Packet size de la structure TSPEC associée au flux cO. Cette structure TSPEC est accessible pour le QosManager 150 par l'action UPnP GetQosState , en charge de donner des renseignements sur les flux actifs transitant sur l'équipement supportant le service QosDevice, comme précisé dans le standard UPnP QoS. 25 Puis, dans l'étape 409, il est mis fin à l'algorithme. On présente, en relation avec la figure 5, les étapes principales d'un algorithme d'obtention de la valeur de la taille de fenêtre acceptée (ci-après désignée par maxWD) pour cO mis en oeuvre par le QosManager 150 du réseau local 100 dans le cadre du procédé de transmission selon le mode de réalisation 30 précité de l'invention. 2908577 37 On rappelle pour information que, conformément à la norme UPnP QoS, le service QosManager peut être localisé dans n'importe quel équipement du réseau local 100. Dans le cadre du présent mode de réalisation particulier de l'invention, le 5 service QosManager est disposé dans le QosManager 150 du réseau 100 des figures 1 et 3. Selon un mode de mise en oeuvre particulier de l'invention, le QosManager peut être confondu avec l'équipement DMP de la figure 4. L'algorithme correspondant aux étapes de cette figure 5 mis en oeuvre par le QosManager 150 vise à calculer la taille de la fenêtre TCP pour la transmission 10 du nouveau flux cO sur son chemin de transmission, à conserver les informations relatives à la connexion courante de ce flux cO, et, éventuellement, à adapter la QoS des flux existants en vue de l'admission de ce nouveau flux cO. L'utilisateur sélectionne le contenu cO auprès du poste de contrôle 160. Puis, selon la norme UPnP QoS, le poste de contrôle 160 décide d'un type 15 de flux de transport pour le contenu multimédia cO conforme au protocole TCP à communiquer entre le serveur 110, de type UPnP MediaServer, et le terminal client 120 (figure 1) ou le second terminal client 120B (figure 3), ces dernier étant de type de type UPnP MediaRenderer. Dans une étape 500, le QosManager 150 reçoit un message 20 RequestTrafficQoS provenant du poste de contrôle 160, par lequel le poste de contrôle 160 demande au QosManager 150 d'établir une politique de QoS pour le flux multimédia cO notamment au niveau des QosDevice du chemin de transmission de cO. Le message normalisé RequestTrafficQoS contient des informations sur 25 les caractéristiques nominales du flux cO ainsi que la destination et la source du flux (la norme UPnP QoS décrit la structure XML appelée TrafficDescriptor caractérisant ce flux cO, contenant les éléments TSPEC spécifiés précédemment). On présente, en relation avec l'annexe 2, un exemple de structure TrafficDescriptor reçue dans le message RequestTrafficQos. 30 Dans une étape 501, suite à la réception du message RequestTrafficQos, le 2908577 38 QosManager 150 détecte le type de média (par exemple image, vidéo, son,...) de cO et le protocole mis en oeuvre pour l'accès à co (par exemple le protocole FTP, le protocole http,...) afin de particulariser le flux cO sélectionné. En effet, dans un mode de réalisation préféré de l'invention, on choisit de 5 proposer des priorités pour la gestion des flux tels que le flux cO. La norme UPnP QoS précise que, suite à la réception du message RequestTrafficQos, le QosManager 150 interroge le service UPnP QoS nommé QosPolicyHolder du réseau local 100 afin d'obtenir la politique de gestion locale de la QoS. Cela se traduit par l'obtention d'un numéro de classification du type de 10 trafic nommé Traffic Importance Number (ou TIN). Cette classification correspond bien à une classification par typage de contenu multimédia (donnée audio, jeu, donnée audio/vidéo, image). Cependant, il est possible d'affiner cette caractérisation en tenant compte du type de protocole d'accès à la ressource (HTTP, FTP) afin, par exemple, de favoriser les données en mode streaming (via 15 HTTP) de celles en mode téléchargement (via FTP), ces dernières n'ayant pas de critère temps réel pour la diffusion. Des étapes 502 et 503 ci-après détaillées constituent une phase d'initialisation de la valeur de la taille de fenêtre initiale pour cO sur le chemin de transmission de cO. :20 Dans une étape 502, suite aux informations fournies dans le message RequestTrafficQos par le poste de contrôle 160, sur le débit moyen de la source (le serveur 110), on peut en déduire une estimation de la valeur de la taille de fenêtre TCP initiale nommée DefaultWD (grâce à la formule (1) décrite à l'étape 1 précédemment décrite en relation avec de la figure 3) de cO. 25 Dans une étape 503, le QosManager calcul une valeur de taille de fenêtre modulé de cO ci-après référencée InitWD selon la formule : InitWD = DefaultWD x coeff (TIN) où coeff (TIN) est une fonction des caractéristiques du flux cO (dont le numéro de classification du type de trafic TIN) et de la politique QoS du réseau 30 local 100 découvertes à l'étape précédente. 2908577 39 On notera que, selon une variante du mode de réalisation particulier précité, l'étape 503 de calcul de la valeur InitWD modulée n'est pas mise en oeuvre et la suite de l'algorithme utilise le paramètre DefaultWD au lieu du paramètre InitWD. 5 Suite à la phase d'initialisation de la valeur de la taille de fenêtre initiale de c0, dans une étape 504, le QosManager 150 obtient le chemin de transmission du flux c0. Il obtient donc la liste des équipements QosDevice intermédiaires (c'est-à-dire, dans le présent cas, les équipements d'interconnexion 140A à 140C), entre le serveur 110 et le terminal client 120 (figure 1) ou le second terminal client 10 120B (figure 3), par lesquels transite le contenu c0. Grâce aux informations reçues de la requête GetPathlnformation , les équipements d'interconnexion 140A à 140C sont considérés comme faisant partie de la liste de ces équipements QosDevice intermédiaires. On notera aussi que le QosManager 150 est aussi capable de détecter si le 15 terminal client 120 (figure 1) ou le second terminal client 120B (figure 3) concerné par le flux c0 dispose du service QosDevice. Pour chacun des QosDevice intermédiaires (sur le chemin de transmission du flux c0), il est appliqué tout ou partie des étapes 505 à 517 ci-après décrites. Dans une étape 505, le QosManager vérifie si un QosDevice courant parmi 20 les QosDevices intermédiaires n'a pas été questionné sur l'admission de QoS. Si tous les QosDevice du chemin de transmission ont été testés (avec une étape 506 ci-après décrite) alors une étape 520 ci-après décrite est mise en oeuvre. Si un QosDevice courant doit être interrogé, alors, pour ce QosDevice courant, dans une étape 506, le QosManager 150 teste si celui-ci accepte 25 l'admission du nouveau flux c0 avec les propriétés QoS mises à jour par le QosManager 150 lors les étapes précédentes. Pour cela, un message SetupTrafficQos est envoyé au QosDevice courant et ce message comprend la valeur InitWD calculée (lors de l'étape 503) dans le champ Maximum Burst Size de la structure TSPEC du message. 30 Un exemple d'une telle structure TSPEC est donné dans l'annexe 3. 2908577 Selon une variante du mode de réalisation particulier précité de l'invention, au lieu du message SetupTrafficQos , un message AdmitTrafficQos est envoyé en remplacement quand les services QosDevice sont compatibles avec la version 3 de la norme UPnP QoS. 5 Dans une étape 507, le QosDevice 150 vérifie si le QosDevice courant accepte les caractéristiques QoS proposées pour le flux cO. Si le QosDevice courant n'accepte pas les caractéristiques QoS proposées pour le flux cO, alors une étape 510 ci-après décrite est mise en oeuvre. Si le QosDevice courant accepte les caractéristiques QoS proposées pour 10 le flux, alors, dans une étape 508, la valeur InitWD est considérée comme acceptée. Puis, dans une étape 509, la valeur InitWD pour cO et pour le QosDevice courant est enregistrée dans une variable admittedWD appartenant à une liste L des valeurs de taille de fenêtre pour cO admises (admittedWD) par les QosDevice 15 du chemin de transmission de cO. Puis l'étape 505 est remise en oeuvre. Ainsi, si un QosDevice donné n'accepte pas les caractéristiques QoS proposées par le QosManager 150 pour le flux cO, alors l'algorithme entre dans une phase d'adaptation (ou ajustement) des valeurs de la taille des fenêtres des flux transitant par le QosDevice donné (correspondant aux étapes 510 à 518 ci- :20 après décrites). Ainsi, dans l'étape 510, le QosManager 150 stocke la valeur InitWD dans une variable admittedWD. La suite des opérations est basée sur la détermination de la valeur admittedWD correspondante aux ressources mémoire accordées par l'équipement 25 QosDevice donné pour le flux cO à admettre. Cette valeur est tout d'abord initialisée par la valeur de la taille de fenêtre initWD idéale qui doit être ensuite réduite. De manière préférentielle, dans un but d'optimisation de la procédure de calcul de la valeur de la taille de la fenêtre, comme l'arrivée à l'étape 510 est 30 relative à une itération (étape 505) des QosDevice du chemin de transmission, la 2908577 41 valeur affectée à l'étape 510 pourra être celle déterminée lors de la précédente itération relative au précédent QosDevice testé. Suite à l'étape 510, dans une étape 511, le QosManager 150 sélectionne, parmi l'ensemble des flux référencés par et qui transitent par le QosDevice donné, 5 les flux à dégrader. Chaque flux à dégrader est associé à un chemin de transmission du flux à dégrader qui
passe par le QosDevice donné. On appelle flux à dégrader un flux qui vérifie au moins un critère. On suppose dans la suite, par exemple, que le critère est la priorité. Ainsi, préférentiellement, le QosManager 150 détecte les flux moins prioritaires que le 10 nouveau flux c0 à admettre (par exemple, ces priorités sont notamment basées sur les critères utilisés par les étapes 501 et 502 précitées). Ces flux moins prioritaires sont appelés flux à dégrader. Pour chaque flux à dégrader, le QosManager 150 relève la valeur courante de la taille de fenêtre TCP nommée currentWD et la valeur minimale MSS du flux 15 c0 au niveau du QosDevice donné. Dans une étape 512, pour chaque flux à dégrader, le QosManager 150 calcule une valeur updatedWD qui remplace, pour le flux, la taille de fenêtre TCP currentWD au niveau du QosDevice donné. La taille de fenêtre updatedWD est réduite par rapport à la taille de fenêtre 20 currentWD. Par exemple, une politique de dégradation de réservation QoS pour un flux peut être relative à la classification de ce flux (par exemple un flux vidéo peut être réduit de 5% par chaque itération de tentative de réduction), sachant que la limite de réduction maximale correspond à la valeur MSS. Il est tout aussi envisageable d'associer une limite de réduction différente selon la classification 25 du flux selon la norme UPnP QoS (par exemple cette limite est k*MSS, ou k=1 pour un téléchargement de données telles que des fichiers multimédia, k=2 pour du streaming vidéo, k=3 pour du streaming audio, etc...). De manière préférentielle, s'il y a peu de marge pour dégrader les tailles de fenêtre currentWD des flux à dégrader, dans une étape 513 le QosManager 150 :30 abaisse la valeur admittedWD pour le nouveau flux c0 au niveau du QosDevice 2908577 donné. Afin de tester la disponibilité de ressources sur le QosDevice donné en fonction des nouvelles valeurs calculées updatedWD pour les tailles de fenêtre des flux à dégrader, on met à jour tous ces flux à dégrader avant d'être sûr que le 5 QosDevice donné peut fournir la QoS requise. Pour éviter d'avoir à mettre à jour chacun des flux à dégrader avant d'être sur que le QosDevice donné peut fournir la QoS requise, une étape 514 prévoit de demander, au préalable, au QosDevice donné s'il peut fournir la différence entre les ressources déjà affectées et celles qui le seront par la suite, différence que l'on 10 appelle dans la suite la marge à tester. En effet, bien que la demande lors de l'étape 506 dépassait la capacité mémoire totale du QosDevice donné, et a donc eu pour effet d'amener à l'exécution de cette phase d'adaptation de l'algorithme (étapes 510 à 518), il est possiblequ'il reste une marge de disponibilité de ressources dans le QosDevice 15 donné entre celles actuellement réservées (pour l'ensemble des flux qui transitent par le QosDevice donné) et la capacité mémoire totale du QosDevice donné. Ainsi, dans l'étape 514, le QosManager 150 calcule une valeur testWD qui correspond à la marge à tester et est égale à la somme des valeurs updatedWD pour chacun des flux à dégrader à laquelle on ajoute la valeur admittedWD pour 20 cO et auxquels on retranche la somme des valeurs currentWD pour chacun des flux à dégrader. Si la valeur du champ testWD est nulle, alors cela signifie que la valeur admittedWD pour le nouveau flux cO doit uniquement être obtenue à partir de la dégradation de flux transitant par le QosDevice donné (ce qui signifie que le 25 QosDevice donné est proche de la congestion). Dans une étape 515, si la valeur testWD n'est pas nulle, le QosManager 150 envoie une requête AdmitTrafficQos d'admission d'un flux fictif associé à une valeur de la taille de fenêtre qui est la valeur testWD. Ceci permet de déterminer si les valeurs de taille de fenêtre pour 30 l'ensemble des flux transitant par le QosDevice donné, précédemment calculées, 42 2908577 43 rentrent dans la marge de disponibilité de ressources mémoire du QosDevice donné. Dans l'algorithme considéré, par souci de simplicité de description, cette requête est immédiatement suivie d'une requête de résiliation car le flux est fictif.
5 Cependant une variante consiste à n'envoyer une requête de résiliation à un QosDevice que si la requête d'allocation a été rejetée par au moins un autre QosDevice sur le chemin de transmission. Dans ce cas, la description de flux ne correspond pas à un flux fictif, mais bien au flux de données cO. C'est-à-dire, qu'une fois qu'un QosDevice accepte une taille de fenêtre déterminée comme 10 acceptable pour la transmission d'un contenu, les ressources associées sont désormais réservées par le QosDevice pour la transmission de ce contenu, et le resteront jusqu'à l'établissement effectif d'une connexion entre le dispositif source et le dispositif récepteur du contenu, à moins qu'au moins un autre QosDevice sur le chemin de transmission du contenu ne rejette cette valeur. Dans 15 ce cas, la réservation est annulée et une nouvelle itération peut se mettre en place, par sélection d'une nouvelle taille de fenêtre acceptable pour la transmission du contenu, cette taille de fenêtre étant inférieure à la taille de fenêtre testée précédemment , ou par une étape complémentaire de dégradation des transmissions de flux de données déjà en place, de manière à augmenter les 20 ressources disponibles sur le chemin de transmission du flux à mettre en place et ainsi favoriser l'établiseement d'une connexion pour ce nouveau flux. Dans une étape 516, le QosManager vérifie si le QosDevice donné accepte les caractéristiques QoS proposées pour le flux fictif. Si le QosDevice donné accepte les caractéristiques QoS proposées pour le 25 flux fictif (résultat positif de la requête d'admission du flux fictif), alors dans l'étape 509, le QosManager 150 stocke la valeur admittedWD pour cO associée au QosDevice donné dans la liste L. Puis l'algorithme sort de la phase d'adaptation des valeurs de la taille des fenêtres des flux transitant par le QosDevice donné.
30 Préférentiellement, lors de l'exécution de l'étape 509 après le test 516, la 2908577 44 liste des flux à dégrader est aussi conservée dans la liste L pour le QosDevice donné, afin que cette information soit utilisée par la suite dans une étape 521 ci-après décrite. Si le QosDevice donné n'accepte pas les caractéristiques QoS proposées 5 pour le flux fictif (résultat négatif de la requête d'admission du flux fictif), alors dans une étape 517, le QosManager 150 vérifie s'il est possible de réduire (s'il existe une marge de diminution) les valeurs admittedWD (valeur de la taille de fenêtre pour cO) et/ou de chacune des valeurs updatedWD (valeurs de taille de fenêtre des flux à dégrader).
10 Si une telle réduction de la ou des valeur(s) admittedWD et/ou updatedWD est possible, alors l'étape 512 est à nouveau mise en oeuvre avec ces valeurs réduites. Dans le cas inverse, l'algorithme s'arrête dans une étape 526 après que le QosDevice ait envoyé, dans une étape 518, un rapport d'erreur au poste de 15 contrôle 160. Telle qu'indiqué précédemment, après le test 505, si tous les QosDevice du chemin de transmission ont été testés (avec l'étape 506), alors l'étape 520 est mise en oeuvre. Ceci assure qu'une valeur de la taille de fenêtre a été trouvée pour le :20 nouveau flux cO dans chacun des QosDevice du chemin de transmission, et que, le cas échéant, des flux à dégrader transitant par des QosDevice du chemin de transmission ont subi une réduction d'allocation de ressources QoS. Dans l'étape 520, le QosManager 150 obtient la valeur minimale de toutes les valeurs admittedWD pour cO dans la liste L des valeurs admises par chacun 25 des QosDevice du chemin de transmission de cO. Cette valeur minimale, ci-après désignée par maxWD ou valeur de la taille de fenêtre acceptée pour cO, est représentative du maximum de ressources QoS que les QosDevice du chemin de transmission de cO peuvent admettre pour le nouveau flux cO. La valeur maxWD sert de base aux calculs suivants et notamment à ceux 30 de l'étape 521.
2908577 Dans une étape 521, à partir de la liste L, le QosManager 150 calcule pour chaque QosDevice du chemin de transmission de cO, et pour chaque flux à dégrader, une nouvelle valeur updatedWD en tenant compte de la valeur maxWD. Afin que le QosManager 150 puisse plus rapidement retrouver tous les 5 QosDevices à mettre à jour, il peut y avoir mémorisation des QosDevices du chemin de transmission de cO détectés lors de l'étape 504. Cette étape est quasiment similaire à l'étape 512, à la différence que l'on connaît l'objectif final de réduction pour chaque flux à dégrader. Ainsi chaque flux à dégrader est associé à une nouvelle valeur de réduction de ressources QoS 10 updatedWD. Chaque valeur updatedWD est conservée dans la mémoire interne du QosManager 150 afin de garder une trace de la valeur de fenêtrage active pour chaque flux auquel elle est associée. Dans une étape 522, pour chaque flux à dégrader, le QosManager envoie une commande de mise à jour des paramètres de QoS pour les flux à dégrader (par 15 exemple au moyen d'un message SetupTrafficQos comportant la valeur updatedWD calculée dans l'étape 521 pour ce flux) à chaque QosDevice sur les chemins de transmission des flux à dégrader (en effet grâce au standard UPnP QoS, le QosManager 150 conserve une liste des équipements QosDevice concernés par le transit d'un flux particulier). :20 Par exemple, dans le cas de la figure 3, si un flux à dégrader transite par le commutateur 140E et également par d'autres commutateurs non représentés sur la figure 3, en supposant que ce flux à dégrader doit être mis à jour, la commande de mise à jour est à envoyer à tous les QosDevice par où ce flux à dégrader transite (y compris 140B).
25 Ensuite, dans une étape 523, le QosManager 150 envoie, à tous les QosDevices du chemin de transmission de cO, un message SetupTrafficQos d'établissement de QoS comprenant la valeur maxWD (ou valeur de la taille de fenêtre acceptée pour cO) dans le champ MaxBurstSize de la structure TSPEC de ce message UPnP.
30 Préférentiellement, le terminal client 120 (figure 1) ou le second terminal 2908577 46 client 120B (figure 3) supporte le service UPnP QosDevice, et donc, le message SetupTrafficQos de l'étape 523 permet d'activer l'étape 406 de l'algorithme de la figure 4. De même, pour chaque flux à dégrader, le message SetupTrafficQos de 5 l'étape 522 pour la mise à jour d'une valeur de fenêtre pour ce flux à dégrader est reçu également par un équipement de type terminal client au bout du chemin de transmission du flux à dégrader. Ainsi, au moins une des première et seconde possibilités conformes à l'invention décrites à l'étape 4 de la figure 3 pour la fourniture, à cet équipement de type terminal client, de la nouvelle valeur de taille 10 de fenêtre pour ce flux à dégrader est alors mis en oeuvre. Selon une variante du présent mode de réalisation préférentiel, le terminal client 120 (figure 1) ou le second terminal client 120B (figure 3) ne supporte pas le service UPnP QosDevice et alors, la valeur maxWD est transmise par voix de retour au poste de contrôle 160 (étape 524).
15 Le poste de contrôle 160 sera alors en charge d'indiquer cette valeur dans un message UPnP AV (tel que Avt_Play ) envoyé au terminal client 120 (figure 1) ou au second terminal client 120B (figure 3) dans le but d'activer l'étape 406 de l'algorithme de la figure 4. En réponse aux actions réalisées à l'étape 408 de la figure 4, le 20 QosManager 150 est notifié, lors d'une étape 525, de paramètres additionnels relatifs à la connexion TCP ouverte par le terminal client 120 (figure 1) ou le second terminal client 120B (figure 3). Ces paramètres seront utiles pour la suite en cas de besoin de modification des paramètres de QoS tel que décrit à l'étape 512.
25 Puis, dans l'étape 526, il est mis fin à l'algorithme. Des améliorations peuvent être apportées à cet algorithme. Ainsi, on s'aperçoit que l'admission d'un flux lors d'une charge importante du réseau aboutit à une valeur maxWD plus faible, et que cette valeur n'est pas revue à la hausse lorsque les conditions s'améliorent. Ce comportement peut par exemple :30 être reconsidéré en modifiant l'étape 520 afin d'ajouter la conservation de la 2908577 47 valeur jugée idéale pour le flux, et lors de la disparition d'un flux existant, en procédant à une analyse (sensiblement identique à celle des étapes 510 à 514) pour augmenter les ressources QoS de certains flux avec comme limite la valeur de fenêtrage idéale précédemment conservée. La mémoire ainsi libérée peut être 5 réallouée pour les trafics restant en fonction de leur priorité associée. On présente, en relation avec la figure 6, les étapes principales d'un algorithme de mise à jour de la valeur de la taille de fenêtre pour la transmission d'un flux TCP cl selon un mode de mise en oeuvre préférentiel de l'invention. Cet algorithme est mis en oeuvre par un dispositif d'interconnexion du réseau local 10 100. Selon un premier exemple conforme à l'invention, le flux cl est un des flux à dégrader qui transitent par le QosDevice donné de la figure 5 et l'équipement d'interconnexion est par exemple situé sur le chemin de transmission de cl lors de la mise en oeuvre du procédé de transmission de c0 15 selon le mode de réalisation précité de l'invention. Selon un second exemple conforme à l'invention, le flux cl est le flux c0 précité. L'équipement d'interconnexion comprend un service UPnP QosDevice, par exemple il est l'un quelconque des équipements d'interconnexion 140A à 20 140C du réseau 100. Ainsi, tel que décrit en regard avec la figure 5, l'équipement d'interconnexion dialogue avec le QosManager 150. L'algorithme présenté indique les actions menées par l'équipement d'interconnexion lors de la réception, dans une étape 600, d'un message 25 SetupTrafficQos relatif au flux cl conforme au protocole TCP. On rappelle que le champ MaxBurstSize de la structure TSPEC de ce message SetupTrafficQos contient une indication de la valeur maxWD de la taille de fenêtre TCP négociée pour cl sur le réseau local 100. Cet algorithme permet de vérifier et faire respecter l'application de cette 30 consigne de QoS (principe du traffic shaping ) pour Cl.
2908577 48 Préférentiellement, cet algorithme est mis en oeuvre dans le cas où le terminal client du chemin de transmission de cl n'est pas compatible avec la présente invention (c'est-à-dire qu'il ne met pas en oeuvre les algorithmes (concernant le terminal client) décrits en relation avec la figure 4). En effet, dans 5 ce cas, les actions demandées par le QosManager 150 au terminal client ne peuvent pas être mises en oeuvre par le terminal client afin de configurer le flux cl TCP en respect de la QoS acceptée. Dans une étape 601, l'équipement d'interconnexion exécute les actions classiques attendues d'un service QosDevice telles que la gestion de ses 10 ressources internes pour l'admission du flux cl, le stockage des caractéristiques QoS du flux cl, etc... Conformément à la présente invention, dans une étape 602, l'équipement d'interconnexion vérifie si le flux cl est un flux déjà ouvert (pour une mise à jour) ou un nouveau flux.
15 Dans le cas d'un nouveau flux, dans une étape 603, l'équipement d'interconnexion attend un segment (ou paquet) TCP SYN pour cl qui caractérise la mise en oeuvre du protocole d'ouverture de connexion TCP pour cl. Les informations de la trame IP relatives aux adresses IP ou adresses MAC des clients et serveurs, au port du serveur, au protocole utilisé, etc..., peuvent être 20 comparées aux informations disponibles dans la caractérisation du flux cl envoyée par le QosManager 150 à travers le message SetupTrafficQos. Dans une étape 604, une fois le flux cl identifié par le segment TCP SYN à destination du serveur 110, la valeur de la taille de fenêtre (ci-après référencée WD) proposée par le terminal client est comparée par l'équipement 25 d'interconnexion avec la valeur maxWD fournie dans la structure TSPEC de spécification de la QoS acceptée pour le flux cl. Dans le cas où la valeur proposée (WD) est inférieure à la valeur maxWD acceptée, dans une étape 609, il est mis fin à l'algorithme. Cette valeur peut toutefois être communiquée par l'équipement d'interconnexion au QosManager 30 150 de manière à ce que celui-ci tienne compte de la valeur de taille de fenêtre qui 2908577 49 sera effective pour le flux cl. Le QosManager 150 pourra ainsi renégocier cette valeur de fenêtre avec l'ensemble des équipements d'interconnexion de type QosDevice sur le chemin de transmission du flux cl et ainsi libérer des ressources internes aux QosDevices inutilement réservées.
5 Au cas où la valeur proposée (WD) est supérieure à la valeur maxWD acceptée, dans une étape 605, l'équipement d'interconnexion met en oeuvre un réajustement de la valeur proposée par insertion de la valeur maxWD à la place de la valeur originale proposée par le terminal client avant de faire suivre le segment TCP SYN ainsi modifié jusqu'à la source du flux cl et de mettre fin à 10 l'algorithme dans l'étape 609. De même que pour l'étape 408 de la figure 4, le service QosDevice de l'équipement d'interconnexion peut être particularisé afin de transmettre au QosManager 150 des informations additionnelles relatives à l'établissement de la connexion TCP.
15 Si le flux cl est un flux déjà ouvert (pour une mise à jour), alors une étape 606 est mise en oeuvre. Les étapes d'adaptation (ou d'ajustement) 606 à 608 sont identiques aux étapes 603 à 605, si ce n'est que : dans l'étape 606, l'équipement d'interconnexion attend un segment (ou 20 paquet) TCP ACK pour et ; dans l'étape 607, c'est la valeur de la taille de fenêtre utilisée au cours de la transmission du flux ( advertised window ) qui est comparée par l'équipement d'interconnexion avec la valeur maxWD fournie dans la structure TSPEC de spécification de la QoS autorisée pour le flux cl (ceci 25 est particulièrement utile lors de l'adaptation de la valeur de la taille de fenêtre après ouverture de la connexion) ; dans l'étape 608, au cas où la taille de fenêtre utilisée au cours de la transmission du flux ( advertised window ) est supérieure à la valeur maxWD acceptée, l'équipement d'interconnexion met en oeuvre un 30 réajustement de la valeur utilisée par insertion de la valeur maxWD.
2908577 Au moins une des première et seconde possibilités conformes à l'invention décrites à l'étape 4 de la figure 3 pour la fourniture de la nouvelle valeur de taille de fenêtre pour ce flux cl est alors mise en oeuvre. Au cas où la taille de fenêtre utilisée au cours de la transmission du flux 5 ( advertised window ) est inférieure à la valeur maxWD acceptée, l'équipement d'interconnexion peut informer le QosManager 150 de cette nouvelle valeur, de manière à ce que celui-ci tienne compte de la valeur de taille de fenêtre qui sera effective pour le flux cl. Le QosManager 150 pourra ainsi renégocier cette valeur de fenêtre avec l'ensemble des équipements d'interconnexion de type QosDevice 10 sur le chemin de transmission du flux cl et ainsi libérer des ressources internes aux QosDevices inutilement réservées. Préférentiellement, un test supplémentaire (non représenté sur cette figure 6) est inséré entre l'étape 602 et l'étape 606. Ce test consiste en ce que si la valeur mise à jour ci-après référencée maxWD' est identique à la valeur maxWD 15 originale de consigne pour l'établissement du flux cl, alors les étapes d'adaptation 606 à 608 ne sont pas mises en oeuvre. La configuration du flux TCP cl revient à la considération de la fenêtre initiale et le comportement du flux TCP cl se régule automatiquement. Selon un mode préférentiel de l'invention, tel que décrit en relation avec la 20 figure 4, l'équipement DMP intègre un service UPnP QosDevice en plus de services UPnP AV MediaRenderer. Les étapes 400 à 404 sont relatives à l'exécution d'un algorithme typique pour un poste de contrôle UPnP, alors que les étapes 406 et 408 reflètent le comportement du service UPnP QosDevice de l'équipement DMP. Comme décrit précédemment, l'exécution de l'étape 406 est :25 conditionnée à la réception du message SetupTrafficQos en provenance du QosManager 150. L'étape 407 est relative au comportement du service AVTransport du protocole UPnP AV (c'est-à-dire que la réception d'un message de commande Avt_Play() va autoriser le déroulement de l'étape 407). Dans la pratique, comme le poste de contrôle est interne au DMP, la commande 30 Avt_Play() reste interne au DMP.
2908577 51 Selon une variante de l'invention, l'équipement DMP peut être contrôlé par un équipement poste de contrôle déporté, comme l'équipement 160: ainsi le poste de contrôle 160 interagit directement avec le service AVTransport de cet équipement, c'est-à-dire que la réception de requêtes Avt_Play() amène à 5 l'exécution de l'étape 407. On notera par ailleurs que cet équipement peut être positionné sur le chemin de transit de flux de données : c'est par exemple le cas d'un poste PC disposant de la fonctionnalité DMP par l'intermédiaire d'un logiciel applicatif, et qui de plus dispose de plusieurs accès réseaux faisant de lui un élément 10 d'interconnexion au même titre que les équipements de type 140. Ainsi, l'équipement DMP peut aussi être considéré aussi comme un dispositif intermédiaire 140. Dans ce cas, la réception d'un message SetupTrafficQos en provenance du QosManager 150 conduira lors de l'étape 406 à déterminer le positionnement 15 de l'équipement courant en correspondance avec le flux spécifié (nouveau ou à mettre à jour) par le message de QoS précité. Cette détermination consiste à découvrir si l'équipement courant est le destinataire du flux ou seulement un équipement intermédiaire sur le chemin du flux : des champs spécifiques dans la structure XML TrafficDescriptor (décrite en annexe 2) du message 20 SetupTrafficQos (tels que le champ DestinationAddress et DestinationPort ) peuvent aisément être comparés avec les caractéristiques réseau de l'équipement afin de déterminer si l'équipement courant est le destinataire du flux ou seulement un équipement intermédiaire sur le chemin du flux. Dans le cas où l'équipement courant est bien le destinataire du flux, il sera 25 procédé à l'exécution de l'étape 407 telle que précédemment décrite en relation avec la figure 4. Si l'équipement courant n'est pas destinataire du flux mais un équipement intermédiaire sur le chemin du flux spécifié, il sera procédé à l'exécution de l'étape 601 telle que déjà décrite en relation avec la figure 6.
30 2908577 52 ANNEXE 1 Le protocole TCP (pour "Transrnission Control Protocol" tel que défini par la norme RFC 793) est un protocole de type ARQ qui a été créé dans le but 5 d'assurer des transferts de données sur l'Internet selon des critères de vitesse et qualité forts. Au moins deux mécanismes sont utilisés pour gérer l'excès de trafic arrivant sur un récepteur : le premier consiste à utiliser des mémoires tampon de réception, et le second met en place un contrôle de flux. Le protocole TCP permet d'assurer le transfert des données de façon fiable, 10 bien qu'il utilise le protocole IP, qui n'intègre aucun contrôle de livraison de datagramme. En effet, le protocole TCP possède un système d'accusé de réception ( acknowledge en anglais ou ACK:) permettant au client et au serveur de s'assurer de la bonne réception mutuelle des données. Lors de l'émission d'un 15 segment, un numéro d'ordre (appelé aussi numéro de séquence) est associé. A la réception d'un segment de donnée, la machine réceptrice va retourner un segment de donnée dont le drapeau ACK est à 1 (afin de signaler qu'il s'agit d'un accusé de réception) accompagné d'un numéro d'accusé de réception égal au numéro d'ordre précédent. Etant donné que ce processus de communication, qui se fait grâce à 20 une émission de données et d'un accusé de réception, est basé sur un numéro d'ordre (ou numéro de séquence), il faut que les machines émettrices et réceptrices (client et serveur) connaissent le numéro d'ordre initial de l'autre machine (appelé Initial Sequence Number en anglais ou ISN). L'établissement d'une connexion TCP s'effectue en trois temps : :25 Dans un premier temps, le client envoie un segment comportant le drapeau SYN (ou message SYN) pour signaler qu'il s'agit d'un segment de synchronisation, avec son numéro de séquence initial (ISN = x). Dans un second temps, le serveur reçoit le segment de synchronisation provenant du client, puis lui envoie un accusé de réception, c'est-à-dire un 30 segment dont le drapeau ACK est à 1 et le drapeau SYN est à 1 comprenant son 2908577 53 propre numéro de séquence (ISN = y), mais il doit également acquitter le paquet précédent, ce qu'il fait avec un numéro d'accusé de réception qui contient le numéro d'ordre initial du client, incrémenté de 1 (ack = x + 1). Puis, dans un troisième temps, le client transmet au serveur un accusé de 5 réception, c'est-à-dire un segment dont le drapeau ACK est à 1, dont le drapeau SYN est à 0, car il ne s'agit plus d'un segment de synchronisation. Son numéro d'ordre est incrémenté (seq = x + 1) et le numéro d'accusé de réception représente le numéro d'ordre initial du serveur incrémenté de 1 (ack = y + 1) . Une fois achevée cette phase nommée three-way handshake , les deux 10 applications sont en mesure d'échanger les octets qui justifient l'établissement de la connexion. Le contrôle de flux gère l'allocation de ressources au niveau du destinataire, telles que la mémoire et le processus. En général, conformément au contrôle de flux, la destination fixe une limite au débit de transmission mis en 15 oeuvre par toutes les sources qui envoient des données à la destination. Les sources et les destinations coordonnent le transfert de données grâce à un échange de messages comprenant des requêtes et des accusés de réception. Avant que la source commence à envoyer des paquets, elle envoie une requête à la destination visant à obtenir la permission de comrnencer la transmission. En réponse à cette 20 requête, la destination envoie un message comprenant une identification du nombre de paquets que la source peut transmettre à la destination sans autorisation supplémentaire. Ce nombre est communément appelé "taille de fenêtre". Alors, la source transmet le nombre de paquets autorisés à la destination et attend que la 25 destination vérifie leur réception. Après que la destination ait reçu avec succès un paquet, elle envoie un message en retour à la source comprenant un accusé de réception indiquant que le paquet a été reçu avec succès et, dans certains cas, autorisant la source à envoyer un autre 1paquet. De cette façon, le nombre de paquets sur le réseau transitant depuis la 30 source vers la destination ne dépasse jamais la taille de fenêtre autorisée.
2908577 54 On distinguera par la suite différentes appellations pour les fenêtres TCP : - TCP window : la valeur initiale validée lors de l'établissement de la connexion, qui est la valeur maximale admise durant toute la durée de la connexion ; 5 cwnd ou Congestion window : la valeur de fenêtre courante émise depuis le serveur dans un paquet TCP en destination du client ; - acknowledge-window ou advertised-window : la valeur de fenêtre envoyée dans un paquet TCP ACK vers le serveur, qui indique l'occupation mémoire dans le client ; 10 - sliding window : (pour fenêtre glissante) valeur de fenêtre interne à un serveur lui permettant de connaitre le nombre de données à transmettre depuis l'arrivée du dernier segment TCP d'acquittement. Une grande taille de fenêtre TCP encourage l'émission. Si le nombre de données reçues est supérieur à ce que la fenêtre indique, les données hors fenêtre 15 seront rejetées. Cette déperdition entraîne un grand nombre de retransmissions et surcharge inutilement le réseau et les TCP. L'usage d'une petite taille de fenêtre morcelle le débit en ajoutant un certain retard supplémentaire au "temps de boucle", mais en limitant la surcharge du réseau due aux retransmissions. L'ouverture d'une toute petite fenêtre réduit aussi les performances en augmentant 20 le poids des en-têtes par rapport aux données. Même avec la mise en place de ces mécanismes, dans un réseau occupé, plusieurs sources envoient simultanément des flux dans le réseau à plus d'une destination. Si trop de tels flux convergent vers un unique routeur dans un laps de 25 temps trop court, alors la capacité limitée en mémoire tampon de ce routeur n'est pas capable de traiter ce volume de flux et ce routeur va rejeter ou détruire une partie des paquets. Lorsqu'une telle situation se produit, le réseau est dit congestionné. Lorsqu'une telle situation se produit, les transferts dans le réseau 30 ralentissent considérablement et le débit du réseau chute. Du fait que certaines 2908577 ressources du réseau sont dédiées à la mise en oeuvre de retransmissions, au moment où le réseau connaît une surcharge, il existe un risque substantiel d'occurrence de propagations de congestions et de blocage du réseau tout entier. La valeur du champ TCP MSS indique la quantité maximale de données 5 TCP par datagramme IP que le système local peut accepter. Lorsqu'il est envoyé, le datagramme IP peut être fragmenté en plusieurs paquets. Théoriquement, cette valeur peut atteindre la valeur de 65495, cependant une valeur aussi importante n'est jamais mise en oeuvre. Typiquement, un système terminal utilise l'interface MTU (pour "outgoing interface MTU") à laquelle est retranché la valeur 40 10 comme sa valeur de champ TCP MSS. Par exemple, une valeur de champ TCP MSS pour le protocole Ethernet est 1460 (1500 - 40 = 1460). La valeur du champ TCP MSS est renseignée dans les paquets qui servent à établir la connexion qui sont les paquets qui contiennent le signal SYN. Chaque coté envoie sa propre valeur de champ TCP MSS. Il n'est pas requis que chaque 15 coté utilise la même valeur de champ TCP MSS, mais chaque coté ne peut pas envoyer plus de données que ce qui est autorisé par le poste distant. La valeur du champ TCP MSS est envoyée à la taille de segment maximale (pour Maximum Segment Size ou MSS) de l'option de l'entête TCP. On peut noter que la valeur par défaut de la taille de la mémoire tampon de :20 l'interface de connexion diffère beaucoup en fonction de l'implémentation. Les anciennes implémentations dérivées de Berkeley imposent des valeurspar défaut des mémoires tampon TCP de réception et d'envoi à 4KB, alors que les systèmes plus récents mettent en oeuvre des valeurs plus importantes (jusqu'à 64KB). Par exemple, dans WINDOWS XP (marque déposée), la valeur actuelle de 25 la taille de fenêtre en réception s'ajuste automatiquement en fonction des incréments pairs de la taille maximale de segment (MSS) négociée pendant l'établissement de la connexion TCP.
2908577 56 ANNEXE 2 <TrafficDescriptor> <td:TrafficHandle>flowl</td:TrafficHandle> 5 <td:Trafficld> <td:SourceAddress> <td:Ipv4>192.168.1.50</td:Ipv4> </td:SourceAddress> <td:SourcePort>23</td:SourcePort> 10 <td:DestinationAddress> <td:Ipv4>192.168.1.50</td:Ipv4> </td:DestinationAddress> <td:DestinationPort>23</td:DestinationPort> <td:IpProtocol>6</td:IpProtocol> 15 </td:Trafficld> <td:AvailableOrderedTspecList> <td:Tspec> <td:TspecIndex>300</td:TspecIndex> <td:AvTransportUri>"http://192.168.1.51/ 20 videol.mpeg"</td:AvTransportUri> <td:TrafficClass>AV</td:TrafficClass> <td:MeanDatarate>50</td:MeanDatarate> </td:Tspec> <td:Tspec> 25 <td:Tspeclndex>2</td:Tspeclndex> <td:AvTransportUri>"http://192.168.1.51/ soundl.mp3"</td:AvTransportUri> <td:TrafficClass>Audio</td:TrafficClass> <td:MeanDatarate>9</td:MeanDatarate> 30 </td:Tspec> </td:Available0rderedTspecList> <(f rafficDescriptor> 5 10 2908577 57 ANNEXE 3 <td:Tspec> <td:Tspeclndex>300</td:Tspeclndex> <td:AvTransportUri>"http://192.168.1.51/ videol.mpeg"</td:AvTransportUri> <td:TrafficClass>AV</td:TrafficClass> <td:MeanDatarate>50</td:MeanDatarate> <td:MaxBurstSize>4380</td:MaxBurstSize > </td:Tspec> 15

Claims (28)

REVENDICATIONS
1. Procédé de gestion de ressources pour la transmission dans un réseau de communication (100) d'un premier contenu de données entre un premier dispositif source (110) et un premier dispositif récepteur (120A, 120B) sur un premier chemin de transmission comprenant au moins un premier dispositif intermédiaire (140A, 140B, 140C), caractérisé en ce qu'un dispositif gestionnaire (150) effectue les étapes suivantes : détermination d'un ensemble de valeurs de taille de fenêtre acceptables pour la transmission du premier contenu ; - détermination d'une valeur de taille de fenêtre, dite première valeur acceptée, parmi l'ensemble de valeurs de taille de fenêtre acceptables déterminé, ladite première valeur acceptée étant la valeur de fenêtre maximale acceptée par au moins ledit au moins un premier dispositif intermédiaire pour la transmission du premier contenu ; - envoi, au premier dispositif récepteur, d'une information représentative de ladite première valeur acceptée afin d'initialiser la transmission du premier contenu entre le premier dispositif source et le premier dispositif récepteur suivant une taille de fenêtre égale à ladite première valeur acceptée.
2. Procédé de gestion de ressources selon la revendication 1, caractérisé en ce que l'étape de détermination de la première valeur acceptée comprend également les étapes suivantes : - sélection d'une valeur de taille de fenêtre acceptable parmi l'ensemble de valeurs de taille de fenêtre acceptables, dite première valeur sélectionnée courante ; - détermination si la première valeur sélectionnée courante est acceptée par ledit au moins un premier dispositif intermédiaire ; dans le cas d'une détermination négative, réitération des étapes de sélection et de détermination avec une première valeur sélectionnée suivante inférieure à la première valeur sélectionnée courante.
3. Procédé de gestion de ressources selon la revendication 2, caractérisé en ce 2908577 59 que l'étape de détermination si la première valeur sélectionnée courante est acceptée par ledit au moins un premier dispositif intermédiaire comprend l'étape suivante : - envoi audit au moins un premier dispositif intermédiaire d'une requête 5 d'allocation de ressources correspondant à la première valeur sélectionnée courante, et en ce qu'une valeur de taille de fenêtre est considérée comme acceptée par ledit au moins un premier dispositif intermédiaire lorsque le dispositif gestionnaire reçoit dudit au moins un premier dispositif intermédiaire un rapport positif 10 d'allocation de ressources correspondant à la première valeur sélectionnée courante.
4. Procédé de gestion de ressources selon la revendication 3, caractérisé en ce que, préalablement à l'étape de réitération, il comprend les étapes suivantes : - détermination d'un ou plusieurs dispositifs, dit(s) dispositifs acceptant, 15 parmi le ou les premier(s) dispositif(s) intermédiaire(s), ayant accepté la première valeur sélectionnée courante ; - envoi audit(auxdits) dispositif(s) acceptant d'une requête de libération de ressources correspondant à la première valeur sélectionnée courante.
5. Procédé de gestion de ressources selon l'une quelconque des :20 revendications 1 à 4, caractérisé en ce que, dans le cas où aucune première valeur sélectionnée n'est acceptée dans l'étape de détermination d'une première valeur acceptée, il comprend également les étapes suivantes : sélection d'au moins un second contenu de données, le second contenu étant en cours de transmission entre un second dispositif source et un 25 second dispositif récepteur sur un second chemin de transmission comprenant au moins un second dispositif intermédiaire (140A, 140B, 140C), au moins un du ou desdits second(s) dispositif(s) intermédiaire(s) étant aussi un du ou desdits prernier(s) dispositif(s) intermédiaire(s) ; détermination d'une valeur de taille de fenêtre acceptable, dite seconde 30 valeur acceptable, pour la transmission du second contenu ; 2908577 60 envoi, à au moins ledit au moins un second dispositif intermédiaire, d'une information représentative de ladite seconde valeur acceptable afin de mettre à jour la transmission du second contenu suivant une taille de fenêtre égale à ladite seconde valeur acceptable. 5
6. Procédé de gestion de ressources selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'une valeur de taille de fenêtre est dite acceptable pour la transmission d'un contenu si elle vérifie au moins un des critères appartenant au groupe comprenant : la valeur de taille de fenêtre est supérieure à une valeur maximale de taille 10 de paquet du contenu ; - la valeur de taille de fenêtre est supérieure à une valeur minimale prédéfinie vérifiant n*MSS, où n est un coefficient dépendant de la priorité du contenu et MSS est une valeur maximale de taille de paquet du contenu ; 15 - la valeur de taille de fenêtre est supérieure à une taille minimale de fenêtre pour la transmission d'un contenu moins prioritaire ; - la valeur de taille de fenêtre est inférieure à un produit max_bandwidth * RTT sur le chemin de transmission du contenu, où max_bandwidth est la bande passante théorique maximale sur le chemin 20 de transmission du contenu et RTT est une valeur moyennée du temps de parcours du chemin de transmission du contenu.
7. Procédé de gestion de ressources pour la transmission dans un réseau de communication (100) d'un contenu de données entre un dispositif source (110) et un dispositif récepteur (120A, 120B) sur un chemin de transmission comprenant 25 au moins un dispositif intermédiaire (140A, 140B, 140C), caractérisé en ce qu'un du ou desdits dispositifs intermédiaires (140A, 140B, 140C), dit dispositif impliqué, effectue les étapes suivantes: réception d'un message comprenant une valeur de taille de fenêtre acceptée par au moins ledit au moins un dispositif intermédiaire pour la 30 transmission dudit contenu ; 2908577 61 détermination de la position, sur le chemin de transmission, dudit dispositif impliqué ; - dans le cas où le dispositif impliqué est le dispositif récepteur, envoi au dispositif source d'un message, dit premier message d'initialisation, 5 d'initialisation de la transmission du contenu, ledit premier message d'initialisation comprenant la valeur acceptée.
8. Procédé de gestion de ressources selon la revendication 7, caractérisé en ce que, dans le cas où le dispositif impliqué n'est pas le dispositif récepteur, le procédé comprend les étapes suivantes : 10 - réception d'un message, dit second message d'initialisation, d'initialisation de la transmission du contenu, ledit second message d'initialisation comprenant au moins une valeur indiquant un niveau de ressources disponibles sur le dispositif récepteur pour la transmission du contenu, dite valeur retenue; 15 - détermination si la valeur retenue est supérieure à la valeur acceptée ; - si la valeur retenue est supérieure à la valeur acceptée, modification dudit second message d'initialisation, en remplaçant la valeur retenue par la valeur acceptée ; - envoi dudit second message d'initialisation au dispositif source. 20
9. Procédé de gestion de ressources selon la revendication 8, caractérisé en ce que, dans le cas où le dispositif impliqué n'est pas le dispositif récepteur, le procédé comprend les étapes suivantes : - réception d'un message, dit message d'acquittement, d'acquittement de l'initialisation de la transmission du contenu, ledit message d'acquittement 25 comprenant au moins une valeur indiquant un niveau de ressources disponibles sur le serveur pour la transmission du contenu, dite valeur retenue; -détermination si la valeur retenue est supérieure à la valeur acceptée ; -si la valeur retenue est supérieure à la valeur acceptée, modification dudit :30 message d'acquittement, en remplaçant la valeur retenue par la valeur 2908577 62 acceptée ; - envoi dudit message d'acquittement au dispositif récepteur.
10. Procédé de transmission selon ]l'une des revendications 8 et 9, caractérisé en ce que, si la valeur retenue n'est pas supérieure à la valeur acceptée, il 5 comprend en outre l'étape suivante : - envoi à un dispositif gestionnaire conforme à un protocole de signalisation centralisé, d'un message comprenant la valeur retenue, afin de permettre une mise à jour d'une valeur de taille de fenêtre acceptée pour le contenu de données. 10
11. Procédé de gestion de ressources selon l'une quelconque des revendications 7 à 10, caractérisé en ce qu'il comprend en outre les étapes suivantes : réception d'au moins un paquet du contenu ; -détermination à partir dudit au moins un paquet reçu d'une valeur 15 minimale de taille de fenêtre pour la transmission du contenu, dite valeur inférieure ; - envoi à un dispositif gestionnaire, de la valeur inférieure, afin de permettre une mise à jour d'un ensemble de valeurs de taille de fenêtre acceptables pour la transmission du contenu. 20
12. Procédé de gestion de ressources selon la revendication 11, caractérisé en ce que la valeur inférieure correspond à une valeur maximale de taille de paquet du contenu.
13. Procédé de gestion de ressources selon l'une quelconque des revendications 7 à 12, caractérisé en ce qu'une valeur de taille de fenêtre est dite 25 acceptable pour la transmission d'un contenu si elle vérifie au moins un des critères appartenant au groupe comprenant : - la valeur de taille de fenêtre est supérieure à une valeur maximale de taille de paquet du contenu ; - la valeur de taille de fenêtre est supérieure à une valeur minimale 30 prédéfinie vérifiant n*MSS, où n est un coefficient dépendant de la priorité 2908577 63 du contenu et MSS est une valeur maximale de taille de paquet du contenu ; - la valeur de taille de fenêtre est supérieure à une taille minimale de fenêtre pour la transmission d'un contenu moins prioritaire ; 5 - la valeur de taille de fenêtre est inférieure à un produit max_bandwidth * RTT sur le chemin de transmission du contenu, où max_bandwidth est la bande passante théorique maximale sur le chemin de transmission du contenu et RTT est une valeur moyennée du temps de parcours du chemin de transmission du contenu. 10
14. Produit programme d'ordinateur, téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de gestion de ressources selon l'une au moins des revendications 1 à 6 et/ou du procédé de gestion de 15 ressources selon l'une au moins des revendications 7 à 13.
15. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de gestion de ressources selon l'une au moins des revendications 1 à 6 et/ou le procédé de gestion de ressources selon 20 l'une au moins des revendications 7 à 13.
16. Dispositif gestionnaire comprenant des moyens de gestion de ressources pour la transmission dans un réseau de communication (100) d'un premier contenu de données entre un premier dispositif source (110) et un premier dispositif récepteur (120A, 120B) sur un premier chemin de transmission 25 comprenant au moins un premier dispositif intermédiaire (140A, 140B, 140C), caractérisé en ce que les moyens de gestion comprennent : des moyens de détermination d'un ensemble de valeurs de taille de fenêtre acceptables pour la transmission du premier contenu ; des moyens de détermination d'une valeur de taille de fenêtre, dite 30 première valeur acceptée, parmi l'ensemble de valeurs de taille de fenêtre 2908577 64 acceptables déterminé, ladite première valeur acceptée étant la valeur de fenêtre maximale acceptée par au moins ledit au moins un premier dispositif intermédiaire pour la transmission du premier contenu ; des moyens d'envoi, au premier dispositif récepteur, d'une information 5 représentative de ladite première valeur acceptée afin d'initialiser la transmission du premier contenu entre le premier dispositif source et le premier dispositif récepteur suivant une taille de fenêtre égale à ladite première valeur acceptée.
17. Dispositif gestionnaire selon la revendication 16, caractérisé en ce que les 10 moyens de détermination de la première valeur acceptée comprennent : des moyens de sélection d'une valeur de taille de fenêtre acceptable parmi l'ensemble de valeurs de taille de fenêtre acceptables, dite première valeur sélectionnée courante ; des moyens de détermination si la première valeur sélectionnée courante 15 est acceptée par ledit au moins un premier dispositif intermédiaire ; des moyens d'activation, dans le cas d'une détermination négative, desdits moyens de sélection et desdits moyens de détermination avec une première valeur sélectionnée suivante inférieure à la première valeur sélectionnée courante. 20
18. Dispositif gestionnaire selon la revendication 17, caractérisé en ce que les moyens de détermination si la première valeur sélectionnée courante est acceptée par ledit au moins un premier dispositif intermédiaire comprennent : - des moyens d'envoi audit au moins un premier dispositif intermédiaire d'une requête d'allocation de ressources correspondant à la première 25 valeur sélectionnée courante, et en ce qu'une valeur de taille de fenêtre est considérée comme acceptée par ledit au moins un premier dispositif intermédiaire lorsque le dispositif gestionnaire reçoit dudit au moins un premier dispositif intermédiaire un rapport positif d'allocation de ressources correspondant à la première valeur sélectionnée :30 courante. 2908577 65
19. Dispositif gestionnaire selon la revendication 18, caractérisé en ce que les moyens de gestion comprennent en ouvre : - des moyens de détermination d'un ou plusieurs dispositifs, dit(s) dispositifs acceptant, parmi le ou les premier(s) dispositif(s) 5 intermédiaire(s), ayant accepté la première valeur sélectionnée courante ; - des moyens d'envoi audit(auxdits) dispositif(s) acceptant d'une requête de libération de ressources correspondant à la première valeur sélectionnée courante.
20. Dispositif gestionnaire selon l'une quelconque des revendications 16 à 19, 10 caractérisé en ce que les moyens de gestion comprennent également : des moyens de sélection d'au moins un second contenu de données, le second contenu étant en cours de transmission entre un second dispositif source et un second dispositif récepteur sur un second chemin de transmission comprenant au moins un second dispositif intermédiaire 15 (140A, 140B, 140C), au moins un du ou desdits second(s) dispositif(s) intermédiaire(s) étant aussi un du ou desdits premier(s) dispositif(s) intermédiaire(s) ; des moyens de détermination d'une valeur de taille de fenêtre acceptable, dite seconde valeur acceptable, pour la transmission du second contenu ; 20 - des moyens d'envoi, à au moins ledit au moins un second dispositif intermédiaire, d'une information représentative de ladite seconde valeur acceptable afin de mettre à jour la transmission du second contenu suivant une taille de fenêtre égale à ladite seconde valeur acceptable.
21. Dispositif gestionnaire selon l'une quelconque des revendications 16 à 20, 25 caractérisé en ce qu'une valeur de taille de fenêtre est dite acceptable pour la transmission d'un contenu si elle vérifie au moins un des critères appartenant au groupe comprenant : - la valeur de taille de fenêtre est supérieure à une valeur maximale de taille de paquet du contenu ; 30 - la valeur de taille de fenêtre est supérieure à une valeur minimale 2908577 66 prédéfinie vérifiant n*MSS, où n est un coefficient dépendant de la priorité du contenu et MSS est une valeur maximale de taille de paquet du contenu ; - la valeur de taille de fenêtre est supérieure à une taille minimale de fenêtre 5 pour la transmission d'un contenu moins prioritaire ; - la valeur de taille de fenêtre est inférieure à un produit max_bandwidth * RTT sur le chemin de transmission du contenu, où max_bandwidth est la bande passante théorique maximale sur le chemin de transmission du contenu et RTT est une valeur moyennée du temps de 10 parcours du chemin de transmission du contenu.
22. Dispositif de transmission comprenant des moyens de gestion de ressources pour la transmission dans un réseau de communication (100) d'un contenu de données entre un dispositif source (110) et un dispositif récepteur (120A, 120B) sur un chemin de transmission comprenant au moins un dispositif 15 intermédiaire (140A, 140B, 140C), ledit dispositif de transmission étant un du ou desdits dispositifs intermédiaires (140A, 140B, 140C), caractérisé en ce que les moyens de gestion comprennent : des moyens de réception d'un message comprenant une valeur de taille de fenêtre acceptée par au moins ledit au moins un dispositif intermédiaire 20 pour la transmission dudit contenu ; - des moyens de détermination de la position, sur le chemin de transmission, dudit dispositif de transmission ; - des moyens d'envoi au dispositif source d'un message, dit premier message d'initialisation, d'initialisation de la transmission du contenu, 25 ledit premier message d'initialisation comprenant la valeur acceptée, lesdits moyens d'envoi étant activés si le dispositif de transmission est le dispositif récepteur.
23. Dispositif de transmission selon la revendication 22, caractérisé en ce que, le dispositif de transmission étant distinct du dispositif récepteur, les moyens de 30 gestion comprennent : 2908577 67 - des moyens de réception d'un message, dit second message d'initialisation, d'initialisation de la transmission du contenu, ledit second message d'initialisation comprenant au moins une valeur indiquant un niveau de ressources disponibles sur le dispositif récepteur pour la transmission du 5 contenu, dite valeur retenue; - des moyens de détermination si la valeur retenue est supérieure à la valeur acceptée ; - des moyens de modification dudit second message d'initialisation, en remplaçant la valeur retenue par la valeur acceptée, lesdits moyens de 10 modification étant activés si la valeur retenue est supérieure à la valeur acceptée; - des moyens d'envoi dudit second message d'initialisation au dispositif source.
24. Dispositif de transmission selon la revendication 23, caractérisé en ce que, 15 le dispositif de transmission étant distinct du dispositif récepteur, les moyens de gestion comprennent : - des moyens de réception d'un message, dit message d'acquittement, d'acquittement de l'initialisation de la transmission du contenu, ledit message d'acquittement comprenant au moins une valeur indiquant un 20 niveau de ressources disponibles sur le serveur pour la transmission du contenu, dite valeur retenue; - des moyens de détermination si la valeur retenue est supérieure à la valeur acceptée; - des moyens de modification dudit message d'acquittement, en remplaçant 25 la valeur retenue par la valeur acceptée, lesdits moyens de modification étant activés si la valeur retenue est supérieure à la valeur acceptée ; - des moyens d'envoi dudit message d'acquittement au dispositif récepteur.
25. Dispositif de transmission selon l'une des revendications 23 et 24, caractérisé en ce que les moyens de gestion comprennent en outre : 30 -des moyens d'envoi à un dispositif gestionnaire conforme à un protocole 2908577 68 de signalisation centralisé, d'un message comprenant la valeur retenue, afin de permettre une mise à jour d'une valeur de taille de fenêtre acceptée pour le contenu de données, lesdits moyens d'envoi étant activés si la valeur retenue n'est pas supérieure à la valeur acceptée. 5
26. Dispositif de transmission selon l'une quelconque des revendications 22 à 25, caractérisé en ce que les moyens de gestion comprennent en outre : - des moyens de réception d'au moins un paquet du contenu ; - des moyens de détermination à partir dudit au moins un paquet reçu d'une valeur minimale de taille de fenêtre pour la transmission du contenu, dite 10 valeur inférieure ; - des moyens d'envoi à un dispositif gestionnaire, de la valeur inférieure, afin de permettre une mise à jour d'un ensemble de valeurs de taille de fenêtre acceptables pour la transmission du contenu.
27. Dispositif de transmission selon la revendication 26, caractérisé en ce que 15 la valeur inférieure correspond à une valeur maximale de taille de paquet du contenu.
28. Dispositif de transmission selon l'une quelconque des revendications 22 à 27, caractérisé en ce qu'une valeur de taille de fenêtre est dite acceptable pour la transmission d'un contenu si elle vérifie au moins un des critères appartenant au 20 groupe comprenant : - la valeur de taille de fenêtre est supérieure à une valeur maximale de taille de paquet du contenu ; - la valeur de taille de fenêtre est supérieure à une valeur minimale prédéfinie vérifiant n*MSS, où n est un coefficient dépendant de la priorité :25 du contenu et MSS est une valeur maximale de taille de paquet du contenu ; - la valeur de taille de fenêtre est supérieure à une taille minimale de fenêtre pour la transmission d'un contenu moins prioritaire ; - la valeur de taille de fenêtre est inférieure à un produit 30 max_bandwidth * RTT sur le chemin de transmission du contenu, où 2908577 69 max_bandwidth est la bande passante théorique maximale sur le chemin de transmission du contenu et RT'T est une valeur moyennée du temps de parcours du chemin de transmission du contenu.
FR0609884A 2006-11-10 2006-11-10 Procede de transmission conformement a un protocole de transmission par rafales d'un contenu de donnees,produit programme d'ordinateur,moyen de stockage et dispositif correspondants. Expired - Fee Related FR2908577B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0609884A FR2908577B1 (fr) 2006-11-10 2006-11-10 Procede de transmission conformement a un protocole de transmission par rafales d'un contenu de donnees,produit programme d'ordinateur,moyen de stockage et dispositif correspondants.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0609884A FR2908577B1 (fr) 2006-11-10 2006-11-10 Procede de transmission conformement a un protocole de transmission par rafales d'un contenu de donnees,produit programme d'ordinateur,moyen de stockage et dispositif correspondants.

Publications (2)

Publication Number Publication Date
FR2908577A1 true FR2908577A1 (fr) 2008-05-16
FR2908577B1 FR2908577B1 (fr) 2009-01-23

Family

ID=38178384

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0609884A Expired - Fee Related FR2908577B1 (fr) 2006-11-10 2006-11-10 Procede de transmission conformement a un protocole de transmission par rafales d'un contenu de donnees,produit programme d'ordinateur,moyen de stockage et dispositif correspondants.

Country Status (1)

Country Link
FR (1) FR2908577B1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030108059A1 (en) * 2001-11-09 2003-06-12 Matsushita Electric Industrial Co., Ltd. Methods for ensuring medium access in a wireless network
DE10228597A1 (de) * 2001-11-29 2003-06-12 Nec Europe Ltd Verfahren zum Übertragen von zeitsynchronen Daten
US20040109428A1 (en) * 2002-12-09 2004-06-10 Srikanth Krishnamurthy Method and apparatus for resource allocation for multiple traffic classes in wireless ad-hoc networks
WO2005022800A1 (fr) * 2003-08-29 2005-03-10 Commonwealth Scientific And Industrial Research Organisation Commutation de rafales de donnees optiques separees par des intervalles de temps
US7054317B1 (en) * 1999-05-14 2006-05-30 Korea Telecommunication Authority Method for controlling transmission control protocol window size in asynchronous transfer mode network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7054317B1 (en) * 1999-05-14 2006-05-30 Korea Telecommunication Authority Method for controlling transmission control protocol window size in asynchronous transfer mode network
US20030108059A1 (en) * 2001-11-09 2003-06-12 Matsushita Electric Industrial Co., Ltd. Methods for ensuring medium access in a wireless network
DE10228597A1 (de) * 2001-11-29 2003-06-12 Nec Europe Ltd Verfahren zum Übertragen von zeitsynchronen Daten
US20040109428A1 (en) * 2002-12-09 2004-06-10 Srikanth Krishnamurthy Method and apparatus for resource allocation for multiple traffic classes in wireless ad-hoc networks
WO2005022800A1 (fr) * 2003-08-29 2005-03-10 Commonwealth Scientific And Industrial Research Organisation Commutation de rafales de donnees optiques separees par des intervalles de temps

Also Published As

Publication number Publication date
FR2908577B1 (fr) 2009-01-23

Similar Documents

Publication Publication Date Title
JP4491257B2 (ja) 終端間測定に基づくネットワークへのデータストリームの許容の制御
US8943206B2 (en) Network bandwidth detection and distribution
KR101046105B1 (ko) 컴퓨터 프로그램 제조품, 리소스 요구 조정 방법 및 엔드 시스템
US7933274B2 (en) Quality of service in a home network
FR2926939A1 (fr) Procede de transmission de donnees avec anticipation des acquittements, dispositif d&#39;entree, produit programme d&#39;ordinateur et moyen de stockage correspondants
US20080189429A1 (en) Apparatus and method for peer-to-peer streaming
US20080291916A1 (en) Systems and methods for dynamic quality of service
FR2933834A1 (fr) Procede de gestion d&#39;une transmission de flux de donnees sur un canal de transport d&#39;un tunnel, tete de tunnel, produit programme d&#39;ordinateur et moyen de stockage correspondants.
EP2862324B1 (fr) Procede et dispositif d&#39;estimation rapide et peu intrusive de la bande passante disponible entre deux n uds ip
FR2909241A1 (fr) Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d&#39;interconnexion de reseaux.
FR2913156A1 (fr) Procede d&#39;allocation de ressources de transmission d&#39;un contenu de donnees, produit programme d&#39;ordinateur, moyen de stockage et dispositif correspondants
FR2925808A1 (fr) Procede de communication dans un reseau comprenant un reseau primaire et un reseau secondaire
EP3646196B1 (fr) Procédé et dispositif de téléchargement de contenu audiovisuel
FR2991474A1 (fr) Technique de communication dans un reseau de communication centre sur les informations
EP3311545B1 (fr) Procédé et dispositif de gestion de paquets dans une connexion multi-flux et multi-protocole
FR2908577A1 (fr) Procede de transmission conformement a un protocole de transmission par rafales d&#39;un contenu de donnees,produit programme d&#39;ordinateur,moyen de stockage et dispositif correspondants.
Ahsan et al. DASHing towards hollywood
FR2901943A1 (fr) Procede de reservation de ressource lors de la transmission d&#39;un contenu dans un reseau de communication, produit programme d&#39;ordinateur, moyen de stockage et dispositif correspondants
WO2023078995A2 (fr) Procédé de vérification de la fiabilité d&#39;une première valeur d&#39;un paramètre de contrôle de flux relatif à une connexion destinée à être établie entre un premier équipement de communication et un deuxième équipement de communication reliés par un chemin comprenant au moins un nœud intermédiaire au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire déterminée par le nœud intermédiaire
WO2023078993A1 (fr) Procédé de gestion d&#39;une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire
EP2645647B1 (fr) Procédé d&#39;optimisation du débit descendant d&#39;une ligne d&#39;accès asymétrique, dispositif, produit programme d&#39;ordinateur et support de stockage correspondants.
Fan et al. Petabytes in Motion: Ultra High Speed Transport of Media Files: A Theoretical Study and its Engineering Practice of Aspera fasp
CN115767143A (zh) 播放卡顿的判断方法、装置、电子设备和可读存储介质
FR2960372A1 (fr) Procede de gestion d&#39;un flux de donnees utiles passager, produit programme d&#39;ordinateur, moyen de stockage et dispositif gestionnaire correspondants
EP3861693A1 (fr) Procédé de préservation d&#39;un débit d&#39;émission de données d&#39;un terminal dans un réseau de communications

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140731