FR2906666A1 - Procede de reservation de ressource dans un reseau local comprenant une pluralite de sous-reseaux, produit programme d'ordinateur, moyen de stockage et dispositif correspondants. - Google Patents

Abstract

L'invention concerne un Procédé de réservation de ressources dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur appartenant à un réseau de communication, ledit réseau comprenant une pluralité de sous-réseaux interconnectés par un moins un dispositif d'interconnexion possédant au moins deux interfaces de communication connectées auxdits sous-réseaux.

Description

1 Procédé de réservation de ressource dans un réseau local comprenant une

pluralité de sous-réseaux, 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 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 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 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. 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 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 2906666 2 services qu'il peut mettre en oeuvre (on parlera dans la suite de ses services ) au 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 5 é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, exécute les commandes associées et met à jour la machine d'état. Le serveur 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. 10 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 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 15 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 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 20 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 dédiés au monde audio/vidéo numérique domestique. 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 Media Server en 25 anglais) ayant accès à des contenus multimédia qu'il peut diffuser sur le réseau local, un lecteur de media (ou Media Renderer ) capable de jouer localement ce type de contenus multimédia reçus du réseau, et un poste de contrôle coordonnant les opérations. Le standard UPnP Quality of Service (pour UPnP Qualité de 30 Service , ci-après référencé UPnP QoS ), tel que décrit dans le document de 2906666 3 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 équipements UPnP. Trois services sont ainsi définis : le service UPnP QosPolicyHolder , ci-après désigné par 5 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 ; 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 10 consignes de QoS à appliquer à un flux de donnée d'un contenu particulier ; et le service UPnP QosManager , ci-après désigné par 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 15 QosPolicyHolder la politique à appliquer et d'informer les QosDevice sur le chemin du flux des actions à mettre en place. Les demandes de garantie de Qualité de Service (QoS) proviennent des applications multimédias réparties qui ne se contentent plus du service au mieux de l'Ethernet. Ces applications vont du simple transfert de données à 20 celles plus complexes telles que la téléphonie, la vidéo à la demande ou la conférence multimédia. Le standard UPnP s'appuie sur le protocole de multicast UDP ( User Datagram Protocol ) pour ses besoins de découverte d'équipements et services UPnP. Plus précisément, le standard UPnP s'appuie sur le protocole SSDP 25 ( Simple Service Discovery Protocol ) qui correspond au protocole HTTP sur UDP dont les messages sont transmis en multicast vers l'adresse 239.255.255.250 et le port 1900. Ainsi, un poste de contrôle UPnP écoute cette adresse pour découvrir tous les équipements et services qui l'intéressent. Par défaut, le standard UPnP AV 30 attribue la valeur 4 au champ TTL ( Time-To-Live ), ce qui signifie que les 2906666 4 messages transmis en multicast peuvent franchir jusqu'à quatre routeurs du réseau local. En fin de compte, par défaut, un poste de contrôle UPnP peut contrôler des flux transitant sur 4+1 sous-réseaux Ethernet (appelés subnets en anglais). Le standard UPnP QoS est un standard émergeant, en cours de 5 spécification. En particulier, le standard UPnP QoS n'adresse pas le problème de la gestion de réseaux Ethernet complexes , c'est-à-dire subdivisés en plusieurs sous-réseaux locaux. Ainsi, en réponse à une requête en réservation de ressource d'un poste de contrôle UPnP, un service QosManager tel que spécifié par le standard UPnP QoS n'est pas capable d'adresser de bout en bout une politique de 10 QoS (ou réservation de ressource) pour un flux traversant plusieurs sous-réseaux d'un réseau local. Comme explicité précédemment, le besoin de garantie de QoS pour des flux multimédia (en termes de bande passante, et/ou de criticité temps réel) est de plus en plus important au fur et à mesure de la multiplicité des postes multimédia 15 des utilisateurs. Cependant, on s'aperçoit que pour remplir cet objectif, une coordination est nécessaire entre les équipements appartenant à différents sous-réseaux afin de délivrer des services de QoS de bout en bout. Hélas, la norme UPnP QoS ne prévoit aucune interaction entre des équipements appartenant à différents sous-réseaux. 20 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 modes de réalisation, est de fournir une technique de réservation de ressources 25 QoS de bout en bout, sans discontinuité, lors de la transmission d'un contenu sur un chemin de transmission traversant au moins deux sous-réseaux d'un réseau local mettant en oeuvre un protocole de réservation de ressource centralisé (UPnP QoS). 2906666 5 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. L'invention, dans au moins un de ses modes de réalisation, a encore pour 5 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 Conformément à un mode de réalisation particulier, l'invention concerne un procédé de réservation de ressources dans le cadre de la transmission d'un 10 contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur appartenant à un réseau de communication, ledit réseau comprenant une pluralité de sous-réseaux interconnectés par un moins un dispositif d'interconnexion possédant au moins deux interfaces de communication connectées auxdits sous-réseaux, 15 ledit procédé étant mis en oeuvre par un dispositif gestionnaire supérieur. Selon l'invention, un tel procédé comprend les étapes suivantes : - création, pour au moins une desdites interfaces de communication, d'au moins une représentation de service de réservation de ressources internes associée à ladite interface de communication ; 20 - déclaration que chaque représentation de service correspond à un service de réservation de ressources internes de l'interface de communication à laquelle elle est associée ; - réception d'une première requête de réservation de ressources internes, pour la transmission dudit contenu, destinée à une représentation de 25 service associée à une interface de communication, dite interface de communication ciblée ; - réservation de ressources internes, pour la transmission du contenu, dans le ou les dispositifs, dit(s) dispositif(s) à réserver, dudit chemin de transmission qui appartient(nent) à au moins un sous-réseau qui n'est pas 30 connecté à l'interface de communication ciblée. 2906666 6 Le principe général de l'invention consiste à créer au moins une représentation de service entre des sous-réseaux d'un réseau de communication (mettant en oeuvre un protocole de réservation de ressource centralisé) lors de la transmission d'un contenu sur un chemin de transmission, ces représentation de 5 service permettant (en recevant des requêtes de réservation de ressource et en les transmettant à un dispositif gestionnaire supérieur) de propager la mise en oeuvre d'une réservation de ressources interne d'un sous réseau à un autre sous réseau du chemin de transmission. Ainsi, l'invention permet de fournir une technique de réservation de 10 ressources internes QoS de bout en bout, sans discontinuité, lors de la transmission d'un contenu sur un chemin de transmission traversant au moins deux sous-réseaux d'un réseau de communication mettant en oeuvre un protocole de réservation de ressource centralisé. Par ailleurs ce procédé de réservation de ressources est compatible avec les 15 recommandations des protocoles (tels que les protocoles QoS, UPnP, UPnP-Av et UPnP-QoS) mis en oeuvre. Avantageusement, l'étape de réservation de ressources internes comprend les étapes suivantes : - détermination si au moins un dispositif à réserver, dit dispositif à réserver 20 localisé, est localisé dans le sous-réseau du dispositif gestionnaire supérieur ; et - dans le cas d'une détermination positive, envoi d'une seconde requête de réservation de ressources internes pour la transmission du contenu à chacun du ou des dispositif(s) à réserver localisé(s). 25 Ainsi, la réservation de ressource interne est mise en oeuvre dans le sous- réseau du dispositif gestionnaire. Préférentiellement, le procédé de réservation de ressource comprend également les étapes suivantes : - détermination d'un dispositif, dit dispositif gestionnaire distant, compris 30 dans le sous-réseau, dit sous-réseau du dispositif gestionnaire distant, 2906666 7 connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication ciblée mais qui est distincte de l'interface de communication ciblée ; et - envoi au dispositif gestionnaire distant d'une demande d'envoi d'une 5 troisième requête de réservation de ressources internes pour la transmission du contenu au(x) dispositif(s) du chemin de transmission appartenant au sous-réseau du dispositif gestionnaire distant. Ainsi, la réservation de ressource interne est mise en oeuvre dans le sous-réseau donné. 10 Avantageusement, préalablement à l'étape de réservation de ressources internes, il comprend l'étape suivante : - détermination d'une représentation de service, dite représentation de service redondante, qui est associée à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication 15 ciblée mais qui est distincte de l'interface de communication ciblée. Préférentiellement, le procédé de réservation de ressource comprend en outre les étapes suivantes : - réception d'une quatrième requête de réservation de ressources internes, pour la transmission du contenu, destinée à être traitée par la 20 représentation de service redondante ; et - émission d'un rapport positif d'exécution de ladite quatrième requête sans que ladite exécution ne soit effective. Selon une caractéristique de l'invention, lors de l'étape de création, il n'est pas créé de représentation de service de réservation de ressources internes pour les 25 interfaces de communication du ou des dispositifs d'interconnexion du sous-réseau comprenant le dispositif gestionnaire supérieur. En effet, par exemple, le dispositif gestionnaire supérieur assure la réservation de ressource interne dans son propre sous réseau. Avantageusement, lors de l'étape de déclaration, il n'est pas déclaré de 30 représentation de service de réservation de ressources internes pour les interfaces 2906666 8 de communication du ou des dispositifs d'interconnexion du sous-réseau comprenant le dispositif gestionnaire supérieur. Préférentiellement, chaque représentation de service de réservation de ressources internes localise le dispositif gestionnaire supérieur par une adresse de 5 type Anycast. Selon une caractéristique de l'invention, l'étape de création est précédée d'une étape de détection d'une apparition d'au moins un sous-réseau dans ledit réseau. Avantageusement, chaque représentation de service de réservation de 10 ressources internes comprend une information d'identification d'au moins un dispositif appartenant à un sous-réseau connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication associée à ladite représentation de service et qui est distincte de l'interface de communication associée à ladite représentation de service. 15 Préférentiellement, le procédé de réservation de ressource comprend en outre les étapes suivantes - détection du retrait d'un dispositif, dit dispositif retiré, d'un sous-réseau ;et - modification d'au moins une représentation de service comprenant une information d'identification du dispositif retiré. 20 Préférentiellement, le procédé de réservation de ressource comprend en outre les étapes suivantes -détection de l'ajout d'un dispositif, dit dispositif ajouté, dans un sous-réseau ; et - modification d'au moins une représentation de service comprenant une 25 information d'identification du dispositif ajouté. Préférentiellement, le procédé de réservation de ressource comprend en outre les étapes suivantes détection du retrait d'un sous-réseau, dit sous-réseau retiré, dudit réseau ;et modification d'au moins une représentation de service comprenant une 30 information d'identification d'un du ou des dispositif(s) du sous-réseau 2906666 9 retiré. Préférentiellement, le procédé de réservation de ressource comprend en outre une étape de destruction d'au moins une représentation de services qui ne comprend pas d'identification de dispositif compris dans un sous-réseau connecté 5 à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication associée à ladite représentation de service et qui est distincte de l'interface de communication associée à ladite représentation de service. Avantageusement, 10 - le ou lesdits service(s) de réservation de ressources internes est(sont) un(des) QosDevice(s) selon le protocole UPnP QoS ; - lesdites requêtes de réservation de ressources internes sont des messages SetupTrafficQos selon le protocole UPnP QoS ; et la ou lesdites demande(s) d'envoi de requête de réservation de ressources 15 internes est(sont) un(des) message(s) RequestTrafficQos selon le protocole UPnP QoS. L'invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédés de réservation de ressources tel que précédemment décrit, lorsque ledit 20 programme est exécuté sur un ordinateur. L'invention concerne également un moyen de stockage lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de réservation de ressources tel que précédemment décrit. 25 L'invention concerne également un dispositif gestionnaire supérieur appartenant à un réseau de communication, ledit réseau comprenant une pluralité de sous-réseaux interconnectés par un moins un dispositif d'interconnexion possédant au moins deux interfaces de communication connectées auxdits sous-réseaux, ledit dispositif gestionnaire supérieur comprenant des moyens de 30 réservation de ressources dans le cadre de la transmission d'un contenu de 2906666 10 données sur un chemin de transmission entre un dispositif source et un dispositif récepteur. Selon l'invention, le dispositif gestionnaire supérieur comprend : - des moyens de création, pour au moins une desdites interfaces de 5 communication, d'au moins une représentation de service de réservation de ressources internes associée à ladite interface de communication ; - des moyens de déclaration que chaque représentation de service correspond à un service de réservation de ressources internes de l'interface de communication à laquelle elle est associée ; 10 - des premiers moyens de réception d'une première requête de réservation de ressources internes pour la transmission dudit contenu destinée à une représentation de service associée à une interface de communication, dite interface de communication ciblée ; - des moyens de réservation de ressources internes, pour la transmission du 15 contenu, dans le ou les dispositifs, dit(s) dispositif(s) à réserver, dudit chemin de transmission qui appartient(nent) à au moins un sous-réseau qui n'est pas connecté à l'interface de communication ciblée. Avantageusement, les moyens de réservation de ressources internes comprennent : 20 - des premiers moyens de détermination si au moins un dispositif à réserver, dit dispositif à réserver localisé, est localisé dans le sous-réseau du dispositif gestionnaire supérieur ; et - des premiers moyens d'envoi d'une seconde requête de réservation de ressources internes pour la transmission du contenu à chacun du ou des 25 dispositif(s) à réserver localisé(s), lesdits premiers moyens d'envoi d'une seconde requête de réservation de ressources internes étant activés dans le cas d'une détermination positive par les premiers moyens de détermination. Préférentiellement, le dispositif gestionnaire supérieur comprend 30 également : 2906666 11 - des seconds moyens de détermination d'un dispositif, dit dispositif gestionnaire distant, compris dans le sous-réseau, dit sous-réseau du dispositif gestionnaire distant, connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de 5 communication ciblée mais qui est distincte de l'interface de communication ciblée ; et - des seconds moyens d'envoi au dispositif gestionnaire distant d'une demande d'envoi d'une troisième requête de réservation de ressources internes pour la transmission du contenu au(x) dispositif(s) du chemin de 10 transmission appartenant au sous-réseau du dispositif gestionnaire distant. Préférentiellement, le dispositif gestionnaire supérieur comprend également : - des troisièmes moyens de détermination d'une représentation de service, dite représentation de service redondante, qui est associée à une interface 15 de communication du dispositif d'interconnexion auquel appartient l'interface de communication ciblée mais qui est distincte de l'interface de communication ciblée. Avantageusement, le dispositif gestionnaire supérieur comprend également : 20 - des seconds moyens de réception d'une quatrième requête de réservation de ressources internes, pour la transmission du contenu, destinée à la représentation de service redondante ; et - des moyens d'émission d'un rapport positif d'exécution de ladite quatrième requête sans que ladite exécution ne soit effective. 25 Selon une caractéristique préférentielle de l'invention, les moyens de création ne créent pas de représentation de service de réservation de ressources internes pour les interfaces de communication du ou des dispositifs d'interconnexion du sous-réseau comprenant le dispositif gestionnaire supérieur. Selon une caractéristique avantageuse de l'invention, les moyens de 30 déclaration ne déclarent pas de représentation de service de réservation de 2906666 12 ressources internes pour les interfaces de communication du ou des dispositifs d'interconnexion du sous-réseau comprenant le dispositif gestionnaire supérieur. Préférentiellement, chaque représentation de service de réservation de ressources internes comprend des moyens de localisation du dispositif 5 gestionnaire supérieur par une adresse de type Anycast. Préférentiellement, le dispositif gestionnaire supérieur comprend des moyens de détection d'une apparition d'au moins un sous-réseau dans ledit réseau. Avantageusement, chaque représentation de service de réservation de 10 ressources internes comprend une information d'identification d'au moins un dispositif appartenant à un sous-réseau connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication associée à ladite représentation de service et qui est distincte de l'interface de communication associée à ladite représentation de service. 15 Préférentiellement, le dispositif gestionnaire supérieur comprend également : - des moyens de détection du retrait d'un dispositif, dit dispositif retiré, d'un sous-réseau ;et - des moyens de modification d'au moins une représentation de service 20 comprenant une information d'identification du dispositif retiré. Avantageusement, le dispositif gestionnaire supérieur comprend également : des moyens de détection de l'ajout d'un dispositif, dit dispositif ajouté, dans un sous-réseau ; et 25 - des moyens de modification d'au moins une représentation de service comprenant une information d'identification du dispositif ajouté. Selon une caractéristique préférentielle de l'invention, le dispositif gestionnaire supérieur comprend également : -des moyens de détection du retrait d'un sous-réseau, dit sous-réseau retiré, 30 dudit réseau ;et 2906666 13 - des moyens de modification d'au moins une représentation de service comprenant une information d'identification d'un du ou des dispositif(s) du sous-réseau retiré. Préférentiellement, le dispositif gestionnaire supérieur comprend 5 également des moyens de destruction d'au moins une représentation de services qui ne comprend pas d'identification de dispositif compris dans un sous-réseau connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication associée à ladite représentation de service et qui est distincte de l'interface de communication associée à ladite 10 représentation de service. Avantageusement, - le ou lesdits service(s) de réservation de ressources internes est(sont) un(des) QosDevice(s) selon le protocole UPnP QoS ; -lesdites requêtes de réservation de ressources internes sont des messages 15 SetupTrafficQos selon le protocole UPnP QoS ; et - la ou lesdites demande(s) d'envoi de requête de réservation de ressources internes est(sont) un(des) message(s) RequestTrafficQos selon le protocole UPnP QoS. 5. Liste des figures 20 D'autres caractéristiques et avantages de l'invention apparaîtront plus 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 25 en oeuvre le procédé de réservation de ressource selon un mode de réalisation particulier de l'invention ; la figure 2 présente un schéma d'un équipement générique mettant en oeuvre le procédé de réservation de ressource selon le mode de réalisation particulier de l'invention précité ; 30 - la figure 3 présente un schéma, sous la forme de blocs fonctionnels, de 2906666 14 l'équipement générique 200 de la figure 2 ; la figure 4 illustre le principe de l'initialisation du QosManager supérieur dans le réseau local selon le mode de réalisation particulier de l'invention ; la figure 5 illustre le principe de la demande d'établissement de QoS lors 5 de la transmission du contenu c0 depuis le serveur de flux vers le terminal client selon le mode de réalisation particulier de l'invention ; les figures 6A et 6B présentent des algorithmes de mise à jour de la topologie du réseau local par le QosManager supérieur selon le mode de réalisation particulier de l'invention, lors de la réception de messages du 10 protocole de routage échangés entre les dispositifs routeurs (figure 6A) et lors de la réception de messages du protocole SSDP (figure 6B) ; les figures 7A à 7C présentent des algorithmes mis en oeuvre par le second service 302 du QosManager supérieur 200 lors de la réception respectivement d'une requête d'obtention d'informations sur les 15 équipements du chemin de transmission de c0 GetPathlnformation (figure 7A), d'une requête d'établissement de la QoS sur le chemin de c0 SetupTrafficQoS (figure 7B) et d'une requête de retrait de la QoS ReleaseTrafficQos (figure 7C) dans le cadre de la transmission de c0 selon le mode de réalisation particulier de l'invention ; 20 - les figures 8A et 8B présentent des algorithmes mis en oeuvre par le premier service 301 du QosManager supérieur 200 lors de la réception respectivement d'une requête d'obtention d'établissement de QoS RequestTrafficQoS (figure 8A) et d'une requête de retrait de la QoS ReleaseTrafficQos (figure 8B) dans le cadre de la transmission du 25 contenu c0 selon le mode de réalisation particulier 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 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 2906666 15 conformes à un protocole de signalisation centralisée, par exemple le protocole UPnP QoS . Bien entendu, le protocole de signalisation centralisé peut être tout autre protocole que le protocole UPnP QoS. 5 Le réseau local 100 est par exemple un réseau Ethernet 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 équipement UPnP QoS (ou équipement mettant en oeuvre le standard UPnP QoS) 10 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éseaulocal 100 qui sont directement contrôlés par l'utilisateur) et des équipements 15 d'infrastructure réseau permettant la liaison entre ces équipements terminaux. Le réseau local 100 présente la particularité d'être constitué de trois sous réseaux 100A, 100B et 100C reliés par des dispositifs routeurs 130-R1, 130-R2. 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 20 de segments sans fil (par exemple conformes aux normes Wifi ou Bluetooth , marques déposées). 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 Media Server ) qui est notamment capable 25 d'émettre en continu des contenus vidéo suivant des protocoles réseau et 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 ; 30 - un terminal client 120, disposant d'un service UPnP Media Renderer , 2906666 16 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 5 télécommande proposant à l'utilisateur une sélection d'équipements UPnP sur le réseau local 100 et des contenus multimédia à jouer ; des ordinateurs tels que représentés par H2 et H3. La catégorie des équipements d'infrastructure réseau comprend notamment des équipements d'interconnexion 140 qui peuvent notamment être : 10 - des équipements de routage de niveau 2, par exemple des commutateurs (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 15 disposant de deux cartes réseau constitue un pont). Ces équipements d'infrastructure réseau 140 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 20 peuvent également implémenter le standard UPnP QoS. 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 25 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 30 second segment dans l'un des cas suivants : 2906666 17 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. 5 Un commutateur est considéré comme un pont qui a plus de deux interfaces. La catégorie des équipements d'infrastructure réseau comprend également les dispositifs routeurs 130-R1, 130-R2. Il s'agit d'équipements de commutation de niveau 3 (ou router en anglais) ci-après désigné par routeur . Un routeur est une machine ayant plusieurs cartes réseau dont chacune est reliée à un sous10 réseau différent. Ainsi, un routeur est un dispositif d'interconnexion de plus de deux segments Ethernet, suivant un critère d'acheminement basé au niveau réseau 3 (par exemple des adresses IP source et destination). Ainsi, les routeurs fonctionnent grâce à des tables de routage et des protocoles de routage, selon le modèle suivant: 15 - le routeur reçoit une trame provenant d'une machine connectée à un des réseaux auquel il est rattaché ; - les datagrammes sont transmis à la couche IP ; - le routeur analyse l'en-tête du datagramme ; - si l'adresse IP de destination appartient à l'un des sous-réseaux auquel une 20 des interfaces du routeur est directement connectée, l'information doit être envoyée à la couche 4 après que l'en-tête IP ait été désencapsulée (enlevée) afin de procéder à une translation d'adresse IP ; on parle alors de concept NAT ("Network Address Translation"), terme qui représente la modification des adresses IP dans l'en-tête d'un datagramme IP effectuée 25 par un routeur. Le routeur envoie ensuite le datagramme sur le sous-réseau concerné. - si l'adresse IP de destination fait partie d'un sous-réseau auquel aucune des interfaces du routeur est directement connectée, le routeur consulte sa table de routage, une table qui définit le chemin à emprunter pour une adresse 30 donnée ; il détermine ainsi par quel sous-réseau auquel une de ces 2906666 18 interfaces est directement connectée le datagramme doit être envoyé et procède à l'envoi du datagramme. Des services conformes au standard UPnP QoS peuvent être embarqués dans certains des équipements du réseau local 100. 5 On considère dans la suite que les serveur de flux multimédia 110, terminal client 120 et poste de contrôle UPnP 160 disposent du service UPnP QosDevice (on les désignera dans la suite par équipements QosDevice). Par ailleurs, chaque sous-réseau 100-A, 100-B et 100-C du réseau local 100 comprend un service UPnP QosManager unique respectivement 150-A, 10 150-B et 150-C que l'on désigne ci-après par QosManager 150-A, 150-B et 150-C (autrement appelés dispositifs gestionnaires dans le cadre de la réservation de ressource). Ces services UPnP QosManager peuvent être embarqués dans n'importe quel équipement disposant préférentiellement d'une plateforme matérielle identique à celle de l'équipement générique 200 décrit ci-après en 15 relation avec la figure 2. La norme UPnP QoS définit plus précisément les procédures à suivre pour choisir le responsable QosManager actif si plusieurs services sont en concurrence. Les services QosManager 150-A, 150-B et 150-C sont responsables de la gestion locale des ressources QoS dans leur propre sous-réseau respectivement 20 100-A, 100-B et 100-C. Selon la norme UPnP QoS, ils ne sont pas capables de gérer la QoS en dehors de leur propre sous-réseau. Dans la suite, on décrit le procédé de réservation de ressource selon le mode de réalisation particulier de l'invention précité, dans un exemple particulier de la transmission d'un contenu (ou flux) multimédia c0 sur un chemin de 25 transmission entre un dispositif source (serveur de flux multimédia 110) et un dispositif récepteur (terminal client 120) appartenant au réseau local 100. Ainsi lors de la sélection du contenu c0 par le poste de contrôle 160, un message (par exemple un message conforme au protocole UPnP-Av, message ci-après désigné par Avt_SetAvTransportUri ou message 1) conforme au 2906666 19 protocole UPnP est envoyé au terminal client 120 en vue d'avertir son service Media Renderer du type de contenu multimédia c0 à recevoir. En parallèle, le poste de contrôle 160 demande au service QosManager 150-B de son sous-réseau 100-B de préparer les ressources QoS nécessaires au 5 bon acheminement au contenu multimédia c0 entre le serveur de flux 110 et le terminal client 120 (par exemple au moyen d'un message conforme au protocole UPnP-QoS, message ci-après désigné par QM_RequestTrafficQos ou message 2). Le QosManager 150-B cherche à obtenir le chemin de transmission de c0 à 10 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 c0 (message 3). Si tous les équipements QosDevice présents sur le chemin de transmission de c0 admettent les caractéristiques QoS du contenu c0, le QosManager 150-B 15 acquittera la requête du poste de contrôle 160, et ce dernier autorisera le terminal client 120 à jouer le contenu multimédia c0 (par exemple au moyen d'un message conforme au protocole UPnP-Av, message ci-après désigné par Avt_Play ou message 4). Le terminal client 120 enverra alors une requête de lecture du flux 20 multimédia au serveur de flux 110 (par exemple par un message de type RTSP afin de recevoir le flux multimédia au format de diffusion RTP). Le procédé de réservation de ressource selon l'invention 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 plusieurs 25 machines du réseau local 100, par exemple dans le QosManager supérieur 200 (ou dispositif gestionnaire supérieur 200) décrit notamment ci-après en relation avec la figure 2. On présente, en relation avec la figure 2, un schéma d'un QosManager supérieur 200 mettant en oeuvre le procédé de réservation de ressource selon le 30 mode de réalisation particulier de l'invention précité. 2906666 20 On se place dans la suite dans le cas où le QosManager supérieur 200 est confondu avec le QosManager 150-A. Cependant, le QosManager supérieur peut être confondu avec tout autre dispositif du réseau local 100 ou même être un dispositif distinct de tout dispositif du réseau local 100 (par exemple, un micro- 5 ordinateur ou une station de travail). Ce QosManager supérieur 200 peut notamment être connecté à tout moyen de stockage d'image, de vidéos, ou de sons reliés à une carte graphique et délivrant au QosManager supérieur 200 des données multimédia. Ainsi, le QosManager supérieur 200 comporte un bus de communication 10 202 auquel sont reliés : 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 ; 15 - une mémoire vive 206 (mémoire cache référencée RAM), comportant des 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 20 le ou les logiciel(s) selon l'invention, à l'aide d'un clavier 210 ou de tout 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 à 25 transmettre et à recevoir des données. Le QosManager supérieur 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 30 ou à y écrire des données traitées ou à traiter conformément au procédé de 2906666 21 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 5 l'invention (par exemple, un disque compact (CD-ROM) ou une carte mémoire). Le bus de communication 202 permet la communication et l'interopérabilité entre les différents dispositifs inclus dans le QosManager supérieur 200 ou reliés à cet équipement. 10 De manière plus générale, grâce au bus de communication 202, l'unité centrale 203 est susceptible de communiquer des instructions à tout dispositif inclus dans le QosManager supérieur 200 directement ou par l'intermédiaire d'un autre dispositif du QosManager supérieur 200. Le code exécutable de chacun du ou des logiciel(s) précités permettant au 15 QosManager supérieur 200 de mettre en oeuvre le procédé de réservation de 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 20 sous tension, le ou les logiciels qui sont stockés dans une mémoire non volatile (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 25 selon l'invention. On présente, en relation avec la figure 3, un schéma sous la forme de blocs fonctionnels du QosManager supérieur 200 de la figure 2. Principalement, le QosManager supérieur 200 dispose d'une connectivité réseau possédant des piles logicielles capables d'interpréter différents protocoles 30 réseaux ainsi que des services utilisant ces protocoles. 2906666 22 En premier lieu, on rappelle que les dispositifs routeurs 130-R1, 130-R2 sont des dispositifs d'interconnexion qui permettent le routage des informations à l'intérieur d'un réseau local constitué d'une pluralité de sous-réseaux. Ils s'échangent des informations grâce à des protocoles de routage appelés IGP (pour 5 Interior Gateway Protocol ), tel que le protocole de routage RIP (pour Routing Information Protocol ) ou tel que le protocole de routage OSPF

(pour Open Shortest Path First ). Le protocole RIP est incorporé dans de nombreux systèmes d'exploitation UNIX. Il s'agit d'un protocole Distance Vector très simple (les routeurs Distance 10 Vector fonctionnent en envoyant à leurs voisins l'intégralité de leur table de routage). La table de routage est transmise dans des paquets RIP, encapsulés dans des datagrammes UDP. Le numéro de port utilisé est le 520. Les paquets RIP ont une taille maximale de 512 octets. Si la table de routage à transmettre est plus grande, elle est envoyée en plusieurs paquets. Les paquets RIP sont envoyés en 15 diffusion (ou broadcast en anglais). La technique Link State (ou Etat des Liens en français) a été développée pour pallier aux inconvénients de la technique Distance Vector . A cet effet, au lieu d'envoyer à leurs voisins l'ensemble des destinations possibles, les routeurs leur envoient des paquets décrivant la liste des liens auxquels ils sont 20 raccordés, ainsi que le coût associé à ces liaisons. Ces paquets sont appelés Link State Packets (LSP) ou Link State Advertisements (LSA). Les voisins qui reçoivent ces paquets les transmettent à leur tour à leurs voisins (sauf à celui qui a émis le paquet). Ces paquets sont envoyés lors de certains évènements, comme un changement d'état d'un lien, un changement de coût ou l'arrivée d'un nouveau 25 routeur. Les routeurs constituent une base de données au moyen de ces paquets, et calculent ensuite une "carte" (ou topologie) complète du réseau à partir de laquelle ils peuvent déterminer la meilleure route d'une source donnée vers une destination donnée (celle dont la somme des coûts est la plus faible). Les routeurs découvrent eux-mêmes leurs voisins en envoyant des paquets "Hello" auxquels les voisins 30 répondent. 2906666 23 Le QosManager supérieur 200 selon l'invention implémente un protocole de routage IGP représenté par le bloc 310. De manière préférentielle mais non limitative, il s'agira du protocole OSPF car, ainsi, une cartographie du sous-réseau dans lequel se situe le QosManager supérieur 200 est plus facilement réalisable. 5 Les messages reçus du sous-réseau sont exploités afin que les informations résultantes soient stockées localement dans une base de données topologie réseau 304 mémorisant la topologie réseau au niveau 3. Ainsi, le QosManager supérieur 200 acquiert la connaissance d'une topologie complète du réseau local 100. Le bloc 301 décrit ci-après ou, indifféremment, la base de données 304 10 peut aussi comporter un gestionnaire d'événements capable d'émettre des signaux internes afin d'alerter les blocs 301 et 302 (décrits ci-après) des modifications de la topologie du réseau. De plus, une pile UPnP 311 est embarquée dans le QosManager supérieur 200 afin de supporter les mécanismes de l'invention. 15 Ainsi, un premier service 301 appelé QosManager étendu (ou Enhanced QosManager ) du QosManager supérieur 200 est capable de s'interfacer avec la pile UPnP 311 afin de découvrir des services UPnP QoS sur tous les sous-réseaux du réseau local 100 (au moyen d'une interface SSDP 312) et de communiquer avec d'autres équipements QosDevice (ou équipements 20 compatibles avec le protocole UPnP QoS), au moyen par exemple d'une interface SOAP 313. On notera que le service QosManager étendu 301 du QosManager supérieur 200 selon l'invention est également capable d'intégrer les algorithmes d'un service QosManager 150 classique tel que défini par la norme UPnP QoS. 25 Ceci à pour effet de proposer une gestion locale des ressources QoS dans le sousréseau où est situé le QosManager supérieur 200. Un second service 302 appelé Manager de QosDevice Virtuel (ou Virtual-QosDevice Manager ) est exécuté par le QosManager supérieur 200. Comme décrit ci-après (en relation avec la figure 6), ce second service 302 est 30 capable de : 2906666 24 - générer des représentations de services de réservation de ressources internes QosDevice virtuels 305 (ou équipements virtuels compatibles avec le protocole UPnP QoS) dans le réseau local 100 ; diffuser sur le réseau des messages SSDP permettant la déclaration de la 5 présence de services QosDevice virtuels 305, dans le but qu'un service QosManager 150 classique quelque part sur le réseau 100 apporte au second service 302 du QosManager supérieur 200 les informations nécessaires au bon déroulement de l'invention ; - diffuser sur le réseau des messages SSDP permettant la déclaration de la 10 modification de services QosDevice virtuels 305 précédemment déclarés, lorsqu'un changement de topologie survient dans le réseau 100. On notera que dans le présent mode de réalisation de l'invention, les premier 301 et second 302 services sont distincts dans le seul but de clarifier la description. Cependant, selon une variante de ce mode de réalisation de 15 l'invention, ces services peuvent être confondus. Par exemple, ces premier 301 et second 302 services sont implémentés en langage de programmation objet, et ainsi le second service 302 instancie autant d'objets représentation de service QosDevice virtuel 305 que nécessaire. Chaque représentation de service QosDevice virtuel 305 est perçue par les dispositifs 20 UPnP Qos du réseau 100 comme étant un service QosDevice classique, et est directement accessible selon le protocole UPnP et UPnP QoS grâce à la description SSDP qui a été fournie. Tel qu'expliqué ci-après (en relation avec la figure 6), au fur et à mesure que la topologie du réseau se modifie, les représentations de service QosDevice 25 virtuels 305 sont créées et détruites, et les messages UPnP et SSDP correspondants sont émis en destination du sous-réseau où est déclarée la présence du service virtuel 305. Une base de données UPnP 303 du QosManager supérieur 200 mémorise l'ensemble des différents services et équipements compatibles avec le protocole 30 UPnP dans le réseau local 100 complet. De manière préférentielle, cette base de 2906666 25 données permet d'obtenir des listes de machines et services associés selon des critères multiples tels que : le type de machine (par exemple, un serveur UPnP Av), la nature du service UPnP QoS si disponible, et le sous-réseau où est située cette machine. 5 Cette base de donnée est enrichie à la fois par le premier service 301 et par le second service 302. On illustre, en relation avec la figure 4, le principe de l'initialisation du QosManager supérieur 200 dans le réseau local 100 selon le mode de réalisation particulier de l'invention précité. 10 Sur cette figure 4 est schématisée la localisation des services QosDevice virtuels 305-A1, 305-B1, 305-B2, 305-Cl sur le réseau local 100. Cette localisation est celle perçue par les dispositifs UPnP QoS, tels que les QosManager classiques 150, suite à la déclaration des services QosDevice virtuels 305 faite par le QosManager supérieur 200. Dans chaque sous-réseau 100-A, 100- 15 B et 100-C, le QosManager 150-A, 150-B et 150- C classique détecte la présence des services QosDevice virtuels 305-A1, 305-B1, 305-B2, 305-C1 et communique avec eux comme s'il s'agissait de réels services QosDevice présents sur leur propre sous-réseau. Ces services QosDevice virtuels 305-A1, 305-B1, 305-B2, 305-Cl sont cependant créés par le QosManager supérieur 200 et sont 20 physiquement présents sur la machine qui héberge le QosManager supérieur 200, comme indiqué sur la figure 3. Les actions réalisées par le QosManager supérieur 200 selon l'invention lors de son démarrage sont présentées ci-après. Au démarrage, la base de données 304 est enrichie dès l'arrivée d'informations en provenance du réseau local 100 par le premier service 301. Une 25 mise à jour (détaillée ci-après, en relation avec la figure 6) est réalisée en tâche de fond, et un message interne d'avertissement peut être émis entre le premier service 301 et le second service 302 dans le cas de modifications de la topologie (remplacement d'un routeur, équipements devenant inaccessibles,...). Le second service 302 consulte la base de données 304 afin de déterminer 30 la disposition des routeurs dans le réseau local 100. Ainsi, il connaît les adresses 2906666 26 IP des équipements de chaque sous-réseau 100-A, 100-B et 100-C, cette information étant un critère important pour la classification des services et machines UPnP dans la base de données 303. Le second service 302 demande alors que les équipements UPnP Av de 5 tout le réseau se fassent connaître. Cette demande est relayée par le protocole SSDP permettant la diffusion de ce type de datagrammes (ou messages) UPnP. On notera que ces datagrammes passent les dispositifs routeurs 130-R1, 130-R2 et sont donc visibles dans tous les sous-réseaux du réseau local 100 (avec un maximum de 4 dispositifs routeurs franchis, ce qui est largement suffisant pour le 10 réseau local 100 courant). Comme déjà mentionné, les messages selon les normes UPnP (UPnP Av et UPnP QoS) peuvent transiter entre plusieurs sous-réseaux. Contrairement à la norme UPnP Av, les messages UPnP QoS ne sont pas interprétables directement en dehors du sous réseau d'où ils sont émis, car l'information contenue dans ces messages est relative à des notions de QoS locale 15 à un sous-réseau. On peut noter que dans le cas de la mise en oeuvre du protocole UPnP classique, ces datagrammes sont émis par le poste de contrôle UPnP 160. En option, si la base de données 304 indique la présence de plus de 5 segments IP consécutifs, la valeur TTL des paquets IP transportant les messages 20 SSDP pourra être augmentée en accord avec le nombre de segments trouvés. Les annexes 1 et 2 donnent des exemples de messages SSDP pour la découverte respectivement, d'un serveur UPnP-Av (par exemple le serveur de flux 110) et d'un équipement UPnP-Av Renderer (par exemple le terminal client 120). 25 Dans le cadre de la présente invention, ces messages permettent d'obtenir la localisation des équipements UPnP Av dans les différents sous-réseaux 100-A, 100-B et 100-C. Par ailleurs, le premier service 301 prend connaissance de tous les autres services QosManager 150-A, 150-B et 150-C disponibles sur le réseau local 100. 30 Simultanément aux actions effectuées par le second service 302, le premier 2906666 27 service 301 envoie des requêtes SSDP sur le réseau par l'intermédiaire de la pile protocolaire 311. L'annexe 3 donne un exemple de message SSDP pour la découverte d'un service QosManager. 5 Lors de la réception de réponses, la base de données 303 est mise à jour. On peut noter que dans le cas de la mise en oeuvre du protocole UPnP classique, ces datagrammes sont émis par le poste de contrôle UPnP 160, désireux de connaître le responsable QosManager 150-B de son sous-réseau 100-B et qui ignore les datagrammes de réponse en provenance des autres sous-réseaux 100-A 10 et 100-C (masque d'adressage IP). Dans le cadre de l'invention, ces datagrammes sont émis par le QosManager supérieur 200 afin de connaître l'ensemble des équipements QosManager présents sur le réseau 100, et les datagrammes de réponse en provenance des autres sous-réseaux ne sont donc pas ignorés. Selon l'invention, le premier service 301 classifie dans la base 303 les 15 informations reçues de tous les datagrammes de réponse à cette interrogation. Ensuite, pour chaque sous-réseau, le service 302 crée les représentations des services QosDevice virtuels 305-A1, 305-B1, 305-B2, 305-Cl. Par exemple, pour le sous-réseau 100-A, la représentation de service QosDevice virtuel 305-Al est créée dans le but de simuler la présence d'un 20 service QosDevice présent dans l'interface de communication avec le sous-réseau 100-A de l'équipement d'interconnexion 130-R2 qui est situé à la frontière entre le sous-réseau 100-A et le sous-réseau 100-B. Ce service QosDevice virtuel 305-A1 se décrit comme un pont permettant de joindre tous les équipements UPnP Av disposés dans les sous-réseaux 25 accessibles par le dispositif routeur 130-R2 au moyen des autres interfaces de communication que celle pour laquelle le service QosDevice virtuel est associé (de tels équipements sont par exemple une caméra UPnP 170 du réseau 100-B, le serveur de flux 110 ou les ordinateurs H2 et H3 du sous-réseau 100-C). Dans le cas de la représentation de service virtuel QosDevice 305-A1, la description 30 correspond aux équipements des sous-réseaux 100-B et 100-C, qui sont 2906666 28 accessibles du réseau 100-A par l'intermédiaire du routeur 130-R2 par son interface de communication avec le sous-réseau 100-B. L'annexe 4 donne un exemple de message SSDP pour la notification de la présence du service QosDevice virtuel 305-A 1. 5 Le champ LOCATION indique l'adresse IP de l'équipement intégrant le service QosDevice virtuel, en l'occurrence la machine hébergeant le QosManager supérieur 200. Dans le mode de réalisation particulier précité de l'invention, ce champ LOCATION indique une adresse IP Anycast à la place de l'adresse IP réelle de la machine hébergeant le QosManager supérieur 200 afin d'en masquer 10 la localisation. Ce mécanisme permet que la machine hébergeant le QosManager supérieur 200 reçoive les messages émis par le QosManager classique 150 qui sont adressés à un service QosDevice virtuel 305. En effet, le QosManager classique 150 pourrait exclure le service QosDevice virtuel 305 des destinataires des messages de gestion QoS, du fait que l'adresse de la machine 200 qui héberge 15 le QosManager supérieur indique qu'elle se situe dans un autre sous-réseau que celui qui est à portée du standard UPnP QoS. Le protocole Anycast permet une transmission point-à-point entre un client et le plus proche serveur identifié par l'adresse Anycast (conformément au protocole RFC1546). Le principe du protocole Anycast est que le client cherche à 20 communiquer avec un service (offert par plusieurs serveurs), peu importe quel serveur lui répond. Le réseau de routeurs est en charge de délivrer les paquets au serveur le plus proche (le protocole Anycast est supporté par les protocoles de routage RIP ou OSPF). Afin de distinguer les service QosDevice virtuels, on particularise l'URL 25 du champ LOCATION afin d'indiquer quel est celui concerné : par exemple, on ajoute à l'URL debase ( / ) la chaine de caractères ( VQD ) suivie d'un indice quelconque permettant de distinguer le service QosDevice virtuel. Ainsi, l'accès aux services XML est effectué relativement à cette nouvelle base. La requête "GetPathlnformation" du standard UPnP QoS permet d'obtenir 30 des informations sur les équipements QosDevice appartenant au chemin de 2906666 29 transmission du contenu cO et notamment les adresses MAC de ces équipements QosDevice. Ce type d'information est notamment utilisé par le QosManager local pour déterminer le chemin de transit du flux multimédia : tous les équipements UPnP QoS de ce chemin seront alors requis d'établir une QoS pour le flux. Il est 5 donc important de laisser croire au QosManager 150 classique que le service QosDevice virtuel est un équipement sur le chemin du contenu cO, c'est-à-dire de ne pas indiquer dans la description du QosDevice virtuel 305 que la machine qui héberge le service est localisée dans un sous-réseau distinct de celui du QosManager 150 classique. Pour le sous-réseau comprenant la machine qui 10 héberge le QosManager supérieur 200, la description du QosDevice virtuel 305 peut contenir l'adresse IP réelle de cette machine à la place de l'adresse Anycast. L'annexe 5 donne un exemple d'une possible représentation d'un équipement QosDevice implémentant une fonction pont entre deux ports Ethernet (le premier attaché au segment local, le second donnant accès aux équipements 15 UPnP Av distants). Le champ "ReachableMac" liste les adresses MAC des équipements UPnP Av accessibles à travers le lien, c'est-à-dire les équipements qui ne sont pas de simples équipements d'interconnexion. Dans l'exemple précédent, le routeur 130-R2 est considéré. Le lien ethO est connecté à une première interface du dispositif 20 routeur 130-R2, et le champ "ReachableMac" correspondant liste les adresses MAC des dispositifs UPnP Av du sous-réseau 100-A, c'est-à-dire le dispositif 120. Le lien eth1 est connecté à une interface du dispositif routeur 130-R2, et le champ "ReachableMac" correspondant liste alors les adresses MAC de tous les autres équipements UPnP Av disposés sur les sous-réseaux 100-B et 100-C, c'est- 25 à-dire les dispositifs 160, 170, 100, HI et H2 dans le cas où chacun de ceux-ci sont effectivement des dispositifs UPnP Av. Selon un mode de mise en oeuvre particulier de l'invention, le premier service 301 peut demander à la pile SSDP 312 de lui remonter les notifications de présence de services QosDevice sur le réseau local 100. Le premier service 301 30 cherche alors à les classifier dans la base de données 303 selon leur appartenance 2906666 30 à leur sous-réseau respectif, et ainsi, lors d'une interrogation par l'action "GetPathInformation", le champ "ReachableMac" pourra contenir les adresses MAC des éléments QosDevice du ou des sous-réseau(x) auquel (auxquels) la représentation de service QosDevice virtuel courant réfère. 5 De la même manière, on exportera la présence d'autres équipements UPnP Av dans le sous-réseau 100-B (la représentation de service QosDevice virtuel 305-B1 fournit la liste des équipements UPnP Av du sous-réseau 100-A ; la représentation de service QosDevice virtuel 305-B2 fournit la liste des équipements UPnP Av du sous-réseau 100-B) et dans le sous-réseau 100-C (la 10 représentation de service QosDevice virtuel 305-Cl fournit la liste des équipements UPnP Av des sous-réseaux 100-A et 100-B). Finalement, les représentations de services QosDevice virtuels, bien qu'étant internes au QosManager supérieur 200, sont perçues par les autres équipements comme de réels services tels que disposés dans le réseau local 100 15 illustré par la figure 4. Dans le cas d'un autre réseau local à base de sous-réseaux, implémentant l'invention, s'il n'est détecté aucun QosManager dans le sous-réseau où est disposé le QosManager supérieur 200, alors, du fait que le QosManager supérieur 200 implémente un service QosManager, il n'est pas nécessaire de créer de 20 représentation de service QosDevice virtuel dans ce sous-réseau. En effet, on est sûr dans ce cas que le service QosManager interrogé pour des besoins de QoS sera celui du QosManager supérieur 200 et que, de par sa connaissance de la topologie complète du réseau 100, sera à même de contacter chacun des QosManager classiques 150 des autres sous-réseaux afin d'effectuer la réservation de 25 ressources pour l'intégralité du chemin de transmission du contenu. On illustre, en relation avec la figure 5, le principe de la demande d'établissement de QoS lors de la transmission du contenu c0 depuis le serveur de flux 110 vers le terminal client 120 selon le mode de réalisation particulier de l'invention. 30 La figure 5 présente les commandes d'établissement de QoS reçues par le 2906666 31 QosManager supérieur 200 de l'invention (suite à la phase d'initialisation décrite précédemment, en relation avec la figure 4) en provenance du QosManager 150-B, et l'impact des actions menées par le QosManager supérieur 200 suite à cette demande de QoS. La procédure est similaire pour des commandes d'établissement 5 de QoS en provenance du QosManager 150-C. Selon la norme UPnP QoS, le poste de contrôle 160 décide d'un type de trafic multimédia à communiquer entre un dispositif source et un dispositif récepteur. Dans notre exemple, le terminal client 120 et le serveur de flux 110 sont situés dans deux sous-réseaux 100-A et 100-C distincts et le poste de contrôle 10 160 se situe dans un troisième sous-réseau 100-B. Cependant, toute autre répartition des dispositif source, dispositif récepteur et poste de contrôle, dans plusieurs sous-réseaux du réseau local 100 est envisageable dans le cadre de l'invention. Dans un premier temps, le poste de contrôle 160 demande (étape 1) au 15 QosManager 150-B (qui est situé dans le même sous-réseau que le poste de contrôle), au moyen d'un message normalisé RequestTrafficQoS , d'établir une politique de QoS pour la transmission du contenu multimédia cO spécifié. Le message normalisé RequestTrafficQos contient des informations sur les caractéristiques du flux cO ainsi que la destination (terminal client 120) et la 20 source (serveur de flux 110). La norme UPnP QoS décrit la structure XML appelée TrafficDescriptor caractérisant le contenu cO. La structure TrafficDescriptor décrite par la norme UPnP QoS comprend deux champs optionnels : QosBoundarySourceAddress et QosBoundaryDestinationAddress . 25 Le champ QosBoundarySourceAddress est dédié au cas où un contenu est émis depuis un terminal situé en dehors du réseau local (ou, par extension, en dehors du sous réseau du poste de contrôle). Dans ce cas, le poste de contrôle doit fournir l'adresse IP de la limite d'application de QoS vers la direction de la source. 30 Le champ QosBoundaryDestinationAddress est dédié au cas où un 2906666 32 contenu est destiné à un terminal situé en dehors du réseau local (ou, par extension, en dehors du sous réseau du poste de contrôle). Dans ce cas, le poste de contrôle doit fournir l'adresse IP de la limite d'application de QoS vers la direction de la destination. 5 Conformément à la norme UPnP QoS, ces deux champs sont utilisés par le service QosManager du sous-réseau lorsqu'il prend ses décisions relatives à la détermination du chemin de transmission emprunté par le flux et la sélection des équipements QosDevice sur ce chemin de transmission. Le principe de l'invention n'est pas affecté par la présence ni l'absence de 10 ces champs lors de l'émission d'une requête QoS en provenance du poste de contrôle 160. En effet, seul le QosManager 150-B, qui n'a qu'une connaissance du réseau 100 limitée au réseau 100-B, peut éprouver des difficultés à établir la QoS pour la transmission du flux car les bornes d'application dans le sous-réseau 100- 15 B ne lui sont pas indiquées. Pour le QosManager supérieur 200, qui a toutes les capacités de connaître la topologie globale du réseau 100, ces informations sont facultatives : il se basera sur les adresses IP des extrémités du chemin de transmission du flux (client 120, serveur 110) pour déterminer les actions à appliquer pour chaque sous-réseau. De même, par le biais d'une requête 20 "GetPathlnformation", le QosManager 150-B obtiendra l'information désirée de la part des équipements QosDevice virtuels 305-B 1 et 305-B2, dont les représentations listent respectivement le dispositif 120 et le dispositif 110. Ensuite, le QosManager 150-B cherche à trouver le chemin de transmission du contenu cO, qui est constitué par des équipements QosDevice du 25 sous-réseau 100-B présents sur le chemin de transmission de cO (par exemple les dispositifs 140 du sous réseau 100-B). Dans le cadre de la requête GetPathlnformation émise par le QosManager 150-B, les QosDevice virtuels 305-B 1 et 305-B2 sont considérés comme faisant partie de la liste de ces équipements QosDevice du sous-réseau 30 100-B sous la responsabilité du QosManager 150-B. 2906666 33 Ensuite, un message SetupTrafficQos est alors envoyé (étape 2) à tous les QosDevice concernés (c'est-à-dire appartenant au chemin de transmission) dans le sous-réseau, y compris les QosDevice virtuels 305-B1 et 305-B2 générés par le QosManager supérieur 200. 5 Ce message SetupTrafficQos est alors reçu par les services QosDevice virtuels 305-B l et 305-B2 qui transmettent (étape 2A) à leur tour cette requête en interne au second service 302 du QosManager supérieur 200. Puis, le second service 302 : analyse les informations de cette requête SetupTrafficQos ; 10 -détecte la localisation du terminal client 120 et du serveur de flux 110 ; et grâce à la connaissance de la topologie du réseau local 100 fournie par la base de donnée 304, connaît les sous-réseaux (autres que le sous-réseau 100-B du QosManager 150-B et du dispositif de contrôle 160) 100-A et 100-C concernés par le passage du contenu cO. 15 Avec le recoupement de la base de données 303, les services QosManager 150-A et 150-C de ces sous-réseaux 100-A et 100-C sont sélectionnés et ensuite informés (étape 3) au moyen d'une requête RequestTrafficQos du besoin d'établissement de QoS pour le flux multimédia. La requête RequestTrafficQos utilisée est du même type que celle envoyée par le poste de 20 contrôle 160, et a donc une portée limitée à chaque sous-réseau. La norme UPnP précise que la requête RequestTrafficQos contient notamment une indication sur les caractéristiques du contenu cO à transmettre (structure XML TrafficDesriptor), qui correspondent à celles reçues par le service QosManager du réseau concerné en provenance du poste de contrôle. 25 En effet, les champs QosBoundarySourceAddress et QosBoundaryDestinationAddress de la structure TrafficDescriptor peuvent être différents de ceux proposés à l'origine par le poste de contrôle 160. Dans le cas où le chemin de transmission du contenu commence en dehors du sous-réseau concerné, la valeur spécifiée dans le champ QosBoundarySourceAddress peut 30 être l'adresse IP d'un dispositif routeur permettant la communication avec la 2906666 34 source. Dans le cas où le chemin de transmission du contenu se termine en dehors du sous-réseau concerné, la valeur spécifiée dans le champ QosBoundaryDestinationAddress peut être l'adresse IP d'un dispositif routeur permettant la communication avec la destination. 5 Ainsi, chaque service QosManager 150-A et 150-C est appelé à gérer localement les ressources QoS propres à son sous-réseau 100-A et 100-C respectif, le service QosManager 150-B ayant pris à son compte la gestion du sousréseau 150-B. Le QosManager supérieur 200 devra cependant éviter la redondance de 10 réservations de ressources pour un même contenu. En effet, les QosManager 150-A et 150-C de ces sous-réseaux 100-A et 100-C vont envoyer une requête SetupTrafficQos aux QosDevice virtuels qui sont déclarés sur leur sous-réseau et qui se trouvent sur le chemin de transmission du contenu. Le QosManager supérieur 200 devra alors distinguer les requêtes adressées à des QosDevice 15 virtuels qui correspondent à des sous- réseaux déjà pris en compte pour la réservation de ressources en vue de la transmission du contenu. Ainsi, le QosManager supérieur 200 n'effectuera pas de réservations de ressources pour les requêtes adressées à des QosDevice virtuels qui représentent les équipements du sous-réseau d'où est émis la requête SetupTrafficQos traitée à l'étape 2A, 20 c'est-à-dire celle qui a initié la procédure de réservation de ressources dans le sous-réseau courant. Le QosManager supérieur 200 pourra retourner un rapport d'exécution positif de la requête, même s'il n'a pas effectué la réservation, afin que le QosManager classique 150-A ou 150-C considère que l'opération de réservation de ressources sur son sous-réseau s'est parfaitement déroulée. 25 Si l'on se réfère à l'illustration de la figure 5, une requête RequestTrafficQos est envoyée par le poste de contrôle 160 au QosManager 150-B pour établir une transmission de données avec qualité de service du dispositif 110 au dispositif 120, respectivement situés sur les sous-réseaux 100-C et 100-A. Le QosManager 150-B enverra alors une requête SetupTrafficQos 30 aux QosDevice virtuels qui sont déclarés sur leur sous-réseau 100-B, c'est-à-dire 2906666 les QosDevice virtuels 305-B2 et 305-B1. Ces requêtes seront interprétées par le QosManager supérieur 200 qui s'assurera de la réservation de ressources, pour respectivement les sous-réseaux 100-C et 100-A. Il contactera alors le QosManager 150-C au moyen d'une requête RequestTrafficQos . Le 5 QosManager 150-C émettra en conséquence des requêtes SetupTrafficQos sur son sous-réseau, l'une d'elle adressant le QosDevice virtuel 305-Cl. Or, le QosDevice virtuel 305-Cl est représentatif des sous-réseaux 100-A et 100-B. La réservation de ressources sur le sous-réseau 100-A est prise en compte par le traitement de la requête SetupTrafficQos adressée au QosDevice virtuel 305- 10 B I et la réservation de ressources sur le sous-réseau 100-B est prise en compte par le QosManager 150-B à la réception de la requête RequestTrafficQos émise par le poste de contrôle 160. Le QosManager supérieur 200 ne devra alors pas prendre en compte la requête SetupTrafficQos adressée au QosDevice virtuel 305- Cl afin d'éviter la redondance de réservations de ressources pour la 15 transmission des données entre l'équipement 110 et l'équipement 120. Il pourra cependant émettre vers le QosManager 150-C un rapport positif d'exécution de la réservation afin que celui-ci considère que l'opération de réservation de ressources sur son sous-réseau s'est parfaitement déroulée. Ainsi, tel qu'illustré par les figures 4 et 5, une demande de réservation de 20 ressource conforme à l'invention (qui est transparente pour le demandeur) est transmise depuis le sous-réseau d'où elle est émise vers les services conformes à la présente invention, lesquels sont alors chargés de propager les besoins de QoS dans les autres sous-réseaux concernés par le biais des traitements spécifiques à l'invention réalisés par le QosManager supérieur 200. 25 On présente, en relation avec les figures 6A et 6B, des algorithmes de mise à jour de la topologie du réseau local 100 par le QosManager supérieur 200 selon le mode de réalisation particulier de l'invention, lors de la réception de messages du protocole de routage échangés entre les dispositifs routeurs 130-R1 et 130-R2 (figure 6A) lors de la réception de messages du protocole SSDP (figure 6B). 30 Ces algorithmes sont notamment exécutés dans le cadre de la phase 2906666 36 d'initialisation du QosManager supérieur 200 précitée en relation avec la figure 4. On détaille ci-après l'algorithme de la figure 6A. Dans une étape 600, lors de la réception d'un nouveau message conforme au protocole de routage IGP, le bloc fonctionnel 310, en mettant en oeuvre le 5 protocole de routage IGP, avertit la base de données topologie réseau 304 de la réception de ce nouveau message du protocole de routage. Dans une étape 601, le QosManager supérieur 200 enregistre la modification de topologie indiquée dans ce nouveau message dans la base de données topologie réseau 304. 10 Le but de la présente invention n'est pas de proposer une architecture de la base de données topologie réseau 304, car il existe de multiples solutions pour gérer les résultats des protocoles de routage, et ces solutions sont notamment dépendantes du protocole de routage utilisé (par exemple, dans le cadre du protocole OSPF). 15 Des modifications de topologie réseau sont par exemple l'apparition ou la disparition de sous-réseaux. Dans une étape 602, le QosManager supérieur 200 vérifie à partir du nouveau message du protocole de routage si un nouveau sous-réseau est détecté. Si un nouveau sous-réseau est détecté, dans une étape 603, la base de 20 données UPnP 303 du QosManager supérieur 200 enregistre les équipements UPnP Av et les services UPnP QosManager de ce nouveau sous-réseau. Cette base de données UPnP 303 peut être architecturée en orientation objet, dans le sens où une instance objet est créée pour chaque sous-réseau et est liée avec deux listes d'objets, l'une (liste L2) référençant des équipements UPnP 25 Av du sous-réseau et l'autre (liste L1) des services QosManager pour ce même sous-réseau. Cette base de données peut aussi être une base de données structurée de type SQL, possédant plusieurs tables (par exemple, une table pour identifier les sous-réseaux, une autre pour les équipements UPnP Av et une dernière pour les services QosManager). Un recoupement entre ces tables par un script SQL 30 approprié permet d'obtenir instantanément les listes L1 et L2 préalablement 2906666 37 explicitées. Dans une étape 604, le gestionnaire d'événements intégré à la base de données UPnP 304 alerte le second service 302 de la détection du nouveau sous-réseau, afin que ce second service 302 crée une ou plusieurs représentations de 5 service QosDevice virtuels 305 relatifs au(x) dispositif(s) routeur(s) connexes à ce nouveau sous-réseau. Le second service 302 mémorise également l'association de ces services QosDevice virtuels 305 avec un identifiant, préalablement généré, du nouveau sous-réseau. Dans une étape 605, le second service 302 demande que chaque service 10 QosDevice virtuel 305 soit déclaré dans le réseau (au moyen de messages de notification SSDP). Dans une étape 611, le second service 302 initie également une recherche des équipements UPnP Av et services QosManager (SSDP search) pour connaître les systèmes UPnP du nouveau sous-réseau. Il en résultera potentiellement une 15 modification de représentations de service QosDevice virtuel déjà existantes. En effet, l'apparition d'un sousréseau dans le réseau 100 permet l'accès à de nouveaux dispositifs par le biais du ou des dispositif(s) d'interconnexion ajouté(s), ces dispositifs devenant accessibles par le biais des interfaces de communication des dispositifs d'interconnexion déjà présents dans le réseau 100. 20 Dans une étape 612, le second service 302 demande que chaque service QosDevice virtuel 305 modifié soit déclaré dans le réseau (au moyen de messages de notification SSDP). Puis, dans une étape 613, il est mis fin à l'algorithme. Si aucun nouveau sous-réseau n'est détecté dans l'étape 602, le QosManager supérieur 200 vérifie, dans une étape 606, à partir du nouveau 25 message du protocole de routage si un sous-réseau a disparu. Si aucun sous-réseau n'a disparu, alors il est mis fin à l'algorithme dans une étape 613. Si un sous-réseau a disparu, alors dans une étape 607, le second service 302 identifie les services QosDevice virtuels 305 de ce sous-réseau et leur 30 demande d'informer le réseau 100 de leur mise hors service (au moyen par 2906666 38 exemple de l'envoi d'un message SSDP BYE) avant de les effacer dans une étape 608. Les services QosDevice virtuels des autres sous-réseaux (toujours présents) sont informés qu'un sous-réseau a disparu grâce à la notification de la 5 disparition des équipements UPnP Av et sont modifiés en conséquence. Dans une étape 609, les QosManager de chacun des sous-réseaux sont informés que les services QosDevice virtuels de leur sous-réseau ont subit une modification. En effet, un message UPnP Pathlnformation informe des modifications dans le routage et de l'accessibilité des équipements listés dans les 10 représentations de services QoSDevice virtuels concernés par la modification. Ensuite, dans une étape 610, on supprime de la base de données 303 les équipements UPnP Av et le(s) service(s) QosManager qui ont disparu. On détaille ci-après l'algorithme de la figure 6B. Dans une étape 650, un nouveau message conforme au protocole SSDP est 15 reçu par le QosManager supérieur 200. Puis, dans une étape 651, le QosManager supérieur 200 identifie le sous-réseau d'où est émis le message. Pour ce faire, il analyse le champ LOCATION dans le corps du message SSDP ou l'adresse source de l'entête IP et obtient donc l'adresse IP de l'émetteur et donc le sous-réseau dans lequel est situé cet émetteur. 20 Dans une étape 652, le QosManager supérieur 200 détecte si ce nouveau message est un message de notification de la présence d'un nouvel équipement UPnP Av (Media Server, Renderer, Player etc....) à partir de la nature de ce message SSDP. En effet, un champ descriptif de ce message SSDP contient une indication 25 sur le type d'équipement rencontré. Par exemple, il contient le champ suivant : USN: uuid:59dff867-9244-48fe-9fbd-a73312c90481::urn:schemas-upnp-org:device: MediaServer:l. Il est possible de prévoir conformément à la présente invention que si cet équipement est déjà connu et référencé dans la base de données 303, il est mis fin 30 à l'algorithme dans une étape 661 (ce cas n'est pas représenté sur la figure 6B). 2906666 39 Si le nouveau message est un message de notification de la présence d'un nouvel équipement UPnP Av, dans une étape 653, le QosManager supérieur 200 enregistre dans la base de données 303 ce nouvel équipement pour le sous-réseau dont le nouvel équipement dépend. 5 Les étapes 654 et 657 ci-après détaillées permettent de déterminer les services QosDevice virtuels 305 devant refléter l'arrivée de ce nouvel équipement dans la liste des adresses MAC exportées par les réponses aux requêtes GetPathlnformation . Dans une étape 654, pour chaque sous-réseau (hormis celui où est localisé 10 le nouvel équipement), le second service 302 recherche les services QosDevice virtuels qui sont représentatifs du sous-réseau auquel appartient le nouvel équipement. Ces représentations sont alors modifiées de manière à refléter la présence du nouvel équipement. Par exemple, dans le réseau local 100, l'apparition d'un poste UPnP Av tel que le poste H1 du sous-réseau 100-B se 15 traduit par la modification des services QosDevice virtuels 305-A1 et 305-C1. Puis, dans une étape 657, les QosManager de chacun des sous-réseaux sont informés que les services QosDevice virtuels de leur sous-réseau ont subit une modification, grâce à l'envoi de messages de notification d'événements UPnP pour l'événement Pathlnformation , communément selon la norme UPnP QoS. 20 Puis, il est mis fin à l'algorithme dans une étape 661. Dans l'étape 652, si le nouveau message SSDP n'est pas un message de notification de la présence d'un nouvel équipement, alors dans une étape 658, le QosManager supérieur 200 détecte si le nouveau message SSDP est un message de notification de la présence d'un nouveau service QosManager à partir de la 25 nature de ce message SSDP. Pour ce faire, ce message SSDP contient par exemple l'un des champs suivant : - USN: uuid:59dff867-9244-48fe-9fbd-a73312c90486::urn:schemas-upnporg:device: QosManager:1 ; 30 - USN: uuid:59dff867-9244-48fe-9fbd-a73312c90486::urn:schemas-upnp- 2906666 org: service: QosManager: 1. Si le nouveau message SSDP n'est pas un message de notification de la présence d'un nouveau service QosManager, alors il est considéré par l'algorithme qu'un équipement a disparu du réseau. Les cas où les messages reçus 5 ne concernent pas un changement de QosManager, l'apparition ou la disparition d'un équipement font l'objet d'un traitement séparé non représenté ici. L'équipement disparu est alors retiré des bases de données du QosManager supérieur 200 (dans une étape 660) et les représentations de QosDevice virtuel sont modifiées en conséquence dans l'étape 654. Cette modification est déclarée 10 dans le réseau 100 de la même manière que pour la découverte d'un nouvel équipement dans le réseau et ne sera pas plus amplement décrite. Si le nouveau message SSDP est un message de notification de la présence d'un nouveau service QosManager, alors, dans une étape 659, le QosManager supérieur 200 enregistre ce nouveau service QosManager dans la base de données 15 303 pour conserver les caractéristiques permettant d'accéder à ce service (identifiant, adresse IP, URL) et le lien avec le sous-réseau dont il appartient. Puis il est mis fin à l'algorithme dans une étape 661. On présente, en relation avec les figures 7A à 7C, des algorithmes mis en oeuvre par le second service 302 du QosManager supérieur 200 lors de la 20 réception respectivement d'une requête d'obtention d'informations sur les équipements du chemin de transmission de cO GetPathlnformation (figure 7A), d'une requête d'établissement de la QoS sur le chemin de cO SetupTrafficQoS (figure 7B) et d'une requête de retrait de la QoS ReleaseTrafficQos (figure 7C) dans le cadre de la transmission de cO selon le 25 mode de réalisation particulier de l'invention précité. Ces requêtes conformes au protocole UPnP, proviennent d'un QosManager classique 150 sur l'un des sous-réseaux du réseau local 100 et parviennent au QosManager supérieur 200 par le biais des QosDevice virtuels déclarés sur le sous-réseau dont le QosManager classique 150 est responsable. 30

Dans l'exemple particulier précité, ces requêtes proviennent du QosManager 150- 2906666 41 B, suite à une requête de QoS pour la transmission d'un contenu émanant du Poste de Contrôle 160. L'algorithme de la figure 7A comprenant les étapes 700 à 707 représente les actions mises en oeuvre par le second service 302 après la notification (étape 5 700) par la pile UPnP 311 de la réception d'une requête GetPathlnformation (normalisée pour une interface UPnP QosDevice). Dans une étape 701, identique à l'étape 651 (précitée en relation avec la figure 6), dans laquelle le second service 302 identifie le sous-réseau du service QosManager demandeur, c'est-à-dire qui a émis la requête (QosManager 150-B 10 dans l'exemple particulier). Dans une étape 702, le second service 302 détermine quelle représentation de service QosDevice virtuel est concernée par la requête, par exemple par récupération de l'indice du service QosDevice virtuel dans l'URL de l'adresse HTTP utilisée.

15 Dans une étape 703, le second service 302 identifie les équipements UPnP Av de chacun des sous-réseaux accessibles à partir de la représentation de service QosDevice virtuel préalablement identifiée dans l'étape 702 et réalise une liste de tels équipements. En effet, chaque représentation de service QosDevice virtuel connaît sa 20 localisation dans le réseau local 100 par le biais de la machine qui l'héberge et peut donc savoir par l'intermédiaire de la base de données topologie réseau 304 les autres sous-réseaux auquel il peut accéder. Ainsi, la base de données UPnP 303 peut alors fournir la liste des machines UPnP Av (et leurs caractéristiques, dont l'adresse MAC qui nous intéresse ici).

25 Préférentiellement, l'algorithme comprend également une étape 704 dans laquelle le second service 302 obtient les adresses MAC des équipements qui sont connexes avec la représentation de service QosDevice virtuel préalablement identifiée dans l'étape 702. On pourra se référer àla description de la figure 4 qui détaille le remplissage du fichier XML de réponse.

30 Dans une étape 705, le second service 302 construit un message de 2906666 42 réponse XML formaté correctement avec les adresses MAC locales du sous-réseau du QosManager demandeur et avec les adresses MAC des équipements UPnP Av distants obtenues à l'étape 704, comme représenté en annexe 5 (déjà décrite).

5 Ensuite, dans une étape 706, le second service envoie ce message de réponse XML, puis il est mis fin à l'algorithme dans une étape 707. L'algorithme de la figure 7B comprenant les étapes 710 à 718 représente les actions mises en oeuvre par le second service 302 après la notification (étape 710) par la pile UPnP 311 de la réception d'une requête SetupTrafficQos 10 (normalisée pour une interface UPnP QosDevice). Dans une étape 711, le second service 302 met en oeuvre l'étape 701 précitée. Dans une étape 712, le second service détecte si le contenu cO doit traverser plusieurs sous-réseaux lors de son parcours du chemin de transmission.

15 Il consulte pour ce faire les champs SourceAddress et DestinationAddress (précité en relation avec la figure 5) qui contiennent les adresses IP des dispositifs source et récepteur du contenu cO. La base de données topologie réseau 304 permet aisément de savoir si les dispositifs source et récepteur sont des équipements localisés dans un même sous-20 réseau ou non. Si le contenu cO ne doit pas traverser plusieurs sous-réseaux, dans une étape 717, une réponse positive est quand même envoyée au service QosManager 150 demandeur, puis dans une étape 718, il est mis fin à l'algorithme. Si le contenu cO doit traverser plusieurs sous-réseaux, dans une étape 713, 25 la base de données 304 détermine une liste des sous-réseaux par lesquels transite le contenu cO lorsqu'il parcourt le chemin de transmission grâce aux informations préalablement recueillies par le protocole de routage 310. Ensuite, dans une étape 714, le second service 302 enlève, de la liste des sous-réseaux précitée, le sous-réseau d'où provient la requête, c'est-à-dire le sous- 30 réseau où est situé le QosManager qui émet la requête SetupTrafficQos . En 2906666 43 effet, il n'est pas nécessaire de l'avertir de l'établissement d'une QoS qu'il connaît déjà localement). Dans une étape 715, le second service 302 détermine à partir de la base de données 303 les services QosManager 150 des sous-réseaux précédemment 5 sélectionnés. Cette sélection est mémorisée ainsi que les caractéristiques du flux afin de permettre une résiliation rapide de l'allocation des ressources QoS lorsque cela sera demandé. Ensuite, dans une étape 716, le second service 302 demande au premier service 301 d'envoyer une requête d'établissement de QoS 10 ( RequestTrafficQos ) à chacun de ces services QosManager de la liste. On rappelle que la description du contenu multimédia est conservée à la différence des champs QosBoundarySourceAddress et QosBoundaryDestinationAddress , qui sont susceptibles d'être mis à jour comme expliqué précédemment (en relation avec la figure 5). Le QosManager 15 supérieur 200 joue alors de rôle de Poste de Contrôle distant pour les QosManager 150 ainsi adressés, comme déjà décrit en relation avec la figure 4. Le QosManager de chaque sous-réseau se réserve le contrôle des ressources QoS locales, et peut éventuellement répondre négativement à la requête du premier service 301. Dans ce cas, une erreur peut être remontée en retour du 20 message SetupTrafficQos reçu par le QosManager supérieur 200 et qui a démarré cet algorithme. Le QosManager supérieur 200 devra toutefois veiller à éviter la redondance des réservations de ressources pour une même transmission de contenu, comme déjà expliqué en relation avec la figure 5.

25 Dans un mode préférentiel de l'invention, le QosManager supérieur 200 n'effectue pas les étapes 713 à 715. Comme illustré en relation avec la figure 5, le QosManager supérieur 200 recevra une requête SetupTrafficQos pour chacune des représentations de QosDevice virtuel déclarées sur le chemin de transmission. Il lui suffira alors d'appliquer la politique de réservation de ressources pour les 30 dispositifs qui sont identifiés dans la description du QosDevice virtuel et qui sont 2906666 sur le chemin de transmission. Les dispositifs qui sont sur le chemin de transmission du flux et qui ne sont pas identifiés dans la description du QosDevice virtuel sont identifiés dans un autre QosDevice virtuel, qui fera lui aussi l'objet de la réception d'une requête SetupTrafficQos . Il n'en reste pas moins que le 5 QosManager supérieur 200 devra veiller à éviter la redondance des réservations de ressources pour une même transmission de contenu, comme déjà expliqué en relation avec la figure 5. Puis il est mis fin à l'algorithme dans l'étape 718. L'algorithme de la figure 7C comprenant les étapes 720 à 723 représente 10 les actions mises en oeuvre par le second service 302 après la notification (étape 720) par la pile UPnP 311 de la réception d'une requête ReleaseTrafficQos (normalisée pour une interface UPnP QosDevice). Dans une étape 721, le second service 302 détermine la transmission de contenu concernée par la requête ReleaseTrafficQos et retrouve la liste 15 mémorisée des services QosManager à qui il a été demandé un établissement de QoS dans leurs sous-réseaux respectifs pour cette transmission de contenu. Ensuite, dans une étape 722, une requête de résiliation de l'allocation de ressource QoS ( ReleaseTrafficQoS ) est présentée à chacun des équipements QosManager par le premier service 301.

20 Le QosManager supérieur 200 devra toutefois veiller à éviter la redondance des libérations de ressources pour une même transmission de contenu, comme déjà expliqué en relation avec la figure 5 dans le cas de la redondance de réservations de ressources. Dans un mode préférentiel de l'invention, le QosManager supérieur 200 25 n'effectue pas les étapes 713 à 715. Il n'y a donc pas d'étape de mémorisation des équipements QosManager à qui il a été demandé un établissement de QoS dans leurs sous-réseaux respectifs pour cette transmission de contenu. Le QosManager supérieur 200 recevra une requête ReleaseTrafficQoS pour chacune des représentations de QosDevice virtuel déclarées sur le chemin de transmission. Il 30 lui suffira alors d'appliquer la politique de libération de ressources pour les 2906666 dispositifs qui sont identifiés dans la description du QosDevice virtuel et qui sont sur le chemin de transmission du flux. Les dispositifs qui sont sur le chemin de transmission du flux et qui ne sont pas identifiés dans la description du QosDevice virtuel sont identifiés dans un autre QosDevice virtuel, qui fera lui aussi l'objet de 5 la réception d'une requête ReleaseTrafficQoS . Il ne reste pas moins que le QosManager supérieur 200 devra veiller à éviter la redondance des libérations de ressources pour une même transmission de contenu, comme déjà expliqué en relation avec la figure 5 dans le cas de la redondance de réservations de ressources. Puis, il est mis fin à l'algorithme dans une étape 723.

10 On présente, en relation avec les figures 8A et 8B, des algorithmes mis en oeuvre par le premier service 301 du QosManager supérieur 200 lors de la réception respectivement d'une requête d'obtention d'établissement de QoS RequestTrafficQoS (figure 8A) et d'une requête de retrait de la QoS ReleaseTrafficQos (figure 8B) dans le cadre de la transmission du contenu c0 15 selon le mode de réalisation particulier de l'invention. Ces requêtes conformes au protocole UPnP, proviennent du poste de contrôle 160, quand celui-ci est localisé sur le même sous-réseau que le QosManager supérieur 200 et que le QosManager supérieur 200 est lui-même QosManager du sous-réseau auquel il appartient. L'interface UPnP QoS du 20 QosManager supérieur 200 est la même que celle d'un QosManager classique, cependant, les processus exécutés notamment par le module SOAP 313 bénéficient des avantages de l'invention. L'algorithme de la figure 8A comprenant les étapes 800 à 810 représente les actions mises en oeuvre par le premier service 301 après la notification (étape 25 800) par la pile UPnP 311 de la réception d'une requête RequestTrafficQos (normalisée pour une interface UPnP QosDevice). Le protocole UPnP précise que la requête RequestTrafficQos contient notamment une indication sur les caractéristiques du contenu c0 à transmettre (structure XML TrafficDesriptor), selon les informations en possession du poste 30 de contrôle 160.

2906666 46 Ces informations vont permettre au premier service 301, dans une étape 801, d'effectuer, au sein du sous-réseau du QosManager supérieur 200 (appelé ci-après sous réseau courant), le traitement QoS classique au niveau des équipements QosDevice de ce sous-réseau courant.

5 Puis, le QosManager supérieur 200 met en oeuvre son service QosManager 150 interne afin de valider l'établissement de la QoS dans le sous-réseau courant selon les recommandations de la norme UPnP QoS. Si tout se déroule correctement (c'est-à-dire que les services QosDevice des autres équipements du chemin de transmission dans le sous-réseau courant ont 10 accepté l'établissement de QoS), dans une étape 802, le premier service 301 détecte si le contenu cO doit traverser au moins un autre sous-réseau (que le sous-réseau courant) lors de son parcours du chemin de transmission. Si le contenu cO ne doit pas traverser au moins un autre sous-réseau, alors, dans une étape 810, il est mis fin à l'algorithme et le premier service 301 s'est comporté comme un 15 service QosManager classique. Si le contenu cO doit traverser au moins un autre sous-réseau (que le sous-réseau courant), les étapes 803 à 806 sont mises en oeuvre. Elles sont identiques aux étapes 713 à 716 de la Figure 7 et ne sont donc pas détaillées ici. Puis, dans une étape 807, le premier service détermine si tous les services 20 QosManager des autres sous-réseaux (autre que le sous-réseau courant) ont répondu positivement à l'établissement de QoS dans leur sous-réseau. Si c'est le cas, l'algorithme se termine dans l'étape 810. Sinon, (avant de mettre fin à l'algorithme dans l'étape 810) dans une étape 809, un code d'erreur est rapporté en retour au poste de contrôle 160 afin éventuellement que celui-ci 25 propose des caractéristiques de flux moins contraignantes. L'algorithme de la figure 8B comprenant les étapes 811 à 815 représente les actions mises en oeuvre par le premier service 301 après la notification (étape 811) par la pile UPnP 311 de la réception d'une requête ReleaseTrafficQos (normalisée pour une interface UPnP QosDevice).

30 Dans une étape 812, détermine la transmission de contenu concernée par la 2906666 47 requête ReleaseTrafficQos afin de retrouver la liste des services QosDevice du sous-réseau local concerné par ce contenu, et leur demander de relâcher les ressources éventuellement réservées pour ce contenu (c'est le comportement habituel d'un service QosManager 150 selon la norme UPnP QoS). Ensuite des 5 étapes 813 et 814, identiques aux étapes 721 et 722 de la figure 7, sont mises en oeuvre. Puis il est mis fin à l'algorithme dans une étape 815. L'homme du métier comprendra que les variantes introduites dans la description des figures 7B et 7C restent d'application ici. Ainsi, grâce aux différents algorithmes précités, l'invention est capable, à 10 partir de messages élémentaires UPnP, de réaliser une réservation de ressource demandée par un dispositif de contrôle d'un sous-réseau pour la transmission d'un contenu à travers différents sous-réseaux d'un réseau local.

15 2906666 48 ANNEXE 1 M-SEARCH * HTTP/ 1.1 MX: 3 5 ST: urn: schemas-upnp-org: device: MediaServer: 1 HOST: 239.255.255.250:1900 MAN: "ssdp: di scover" 10 2906666 49 ANNEXE 2 M-SEARCH * HTTP/1.1 MX: 3 5 ST: urn:schemas-upnp-org:device:MediaRenderer:1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" 10 2906666 ANNEXE 3 M-SEARCH * HTTP/1.1 MX: 3 5 ST: urn: schemas-upnp-org: service: QosManager: 1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" 10 2906666 51 ANNEXE 4 NOTIFY * HTTP/1.1 LOCATION: http:// 172.20.4.55:60221 /V QD 1 / 5 HOST:239.255.255.250:1900 SERVER: WINDOWS, UPnP/1.0 NTS: ssdp:alive USN: uuid:466a3 1 b4-f65f-462b-a3c3-c3e 1648dbf7b::urn: schemas-upnporg: service: QosDevice: 1 10 CACHE-CONTROL: max-age=1800 NT: urn:schemas-upnp-org:service:QosDevice:1 15 2906666 52 ANNEXE 5 <DeviceReachableMacs xmins="http://www.upnp.org/schemas/QosDevice.xsd"> 5 <LinkReachableMacs> <LinkId>ethO</LinkId> <Bridgeld>Bridge0</Bridgeld> <ReachableMac>112233aabb03</ReachableMac> </LinkReachableMacs> 10 <LinkReachableMacs> <LinkId>ethl</Linkld> <Bridgeld>BridgeO</Bridgeld> <ReachableMac>112233aabb07</ReachableMac> <ReachableMac>112233aabb05</ReachableMac> 15 <ReachableMac>112233aabb09</ReachableMac> <ReachableMac>112233aabb04</ReachableMac> <ReachableMac>112233aabb06</ReachableMac> </LinkReachableMacs> </DeviceReachableMacs> 20

Claims (32)

REVENDICATIONS

1. Procédé de réservation de ressources dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source (110) et un dispositif récepteur (120) appartenant à un réseau de communication (100), ledit réseau comprenant une pluralité de sous-réseaux (100-A, 100B, 100-C) interconnectés par un moins un dispositif d'interconnexion (130-R1, 130-R2) possédant au moins deux interfaces de communication connectées auxdits sous-réseaux, ledit procédé étant mis en oeuvre par un dispositif gestionnaire supérieur (200), 10 caractérisé en ce que le procédé comprend les étapes suivantes : - création, pour au moins une desdites interfaces de communication, d'au moins une représentation de service de réservation de ressources internes associée à ladite interface de communication ; - déclaration que chaque représentation de service correspond à un service 15 de réservation de ressources internes de l'interface de communication à laquelle elle est associée ; - réception d'une première requête de réservation de ressources internes, pour la transmission dudit contenu, destinée à une représentation de service associée à une interface de communication, dite interface de 20 communication ciblée ; - réservation de ressources internes, pour la transmission du contenu, dans le ou les dispositifs, dit(s) dispositif(s) à réserver, dudit chemin de transmission qui appartient(nent) à au moins un sous-réseau qui n'est pas connecté à l'interface de communication ciblée. 25

2. Procédé de réservation de ressources selon la revendication 1, caractérisé en ce que l'étape de réservation de ressources internes comprend les étapes suivantes : - détermination si au moins un dispositif à réserver, dit dispositif à réserver localisé, est localisé dans le sous-réseau du dispositif gestionnaire 30 supérieur (200) ; et 2906666 54 - dans le cas d'une détermination positive, envoi d'une seconde requête de réservation de ressources internes pour la transmission du contenu à chacun du ou des dispositif(s) à réserver localisé(s).

3. Procédé de réservation de ressources selon la revendication 2, caractérisé 5 en ce qu'il comprend également les étapes suivantes : -détermination d'un dispositif, dit dispositif gestionnaire distant, compris dans un sous-réseau, dit sous-réseau du dispositif gestionnaire distant, connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication ciblée mais qui est distincte de l'interface de communication ciblée ; et - envoi au dispositif gestionnaire distant d'une demande d'envoi d'une troisième requête de réservation de ressources internes pour la transmission du contenu au(x) dispositif(s) du chemin de transmission appartenant au sous-réseau du dispositif gestionnaire distant.

4. Procédé de réservation de ressources selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, préalablement à l'étape de réservation de ressources internes, il comprend l'étape suivante : -détermination d'une représentation de service, dite représentation de service redondante, qui est associée à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication ciblée mais qui est distincte de l'interface de communication ciblée.

5. Procédé de réservation de ressources selon la revendication 4, caractérisé en ce qu'il comprend en outre les étapes suivantes : -réception d'une quatrième requête de réservation de ressources internes, pour la transmission du contenu, destinée à la représentation de service redondante ; et émission d'un rapport positif d'exécution de ladite quatrième requête sans que ladite exécution ne soit effective.

6. Procédé de réservation de ressources selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, lors de l'étape de création, il n'est pas 2906666 55 créé de représentation de service de réservation de ressources internes pour les interfaces de communication du ou des dispositifs d'interconnexion du sous-réseau comprenant le dispositif gestionnaire supérieur (200).

7. Procédé de réservation de ressources selon l'une quelconque des 5 revendications 1 à 5, caractérisé en ce que, lors de l'étape de déclaration, il n'est pas déclaré de représentation de service de réservation de ressources internes pour les interfaces de communication du ou des dispositifs d'interconnexion du sous-réseau comprenant le dispositif gestionnaire supérieur (200).

8. Procédé de réservation de ressources selon l'une quelconque des 10 revendications 1 à 7, caractérisé en ce que chaque représentation de service de réservation de ressources internes localise le dispositif gestionnaire supérieur (200) par une adresse de type Anycast.

9. Procédé de réservation de ressources selon l'une quelconque des revendications 1 à 8, caractérisé en ce que l'étape de création est précédée d'une 15 étape de détection d'une apparition d'au moins un sous-réseau dans ledit réseau (100).

10. Procédé de réservation de ressources selon l'une quelconque des revendications 1 à 9, caractérisé en ce que chaque représentation de service de réservation de ressources internes comprend une information d'identification d'au 20 moins un dispositif appartenant à un sous-réseau connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication associée à ladite représentation de service et qui est distincte de l'interface de communication associée à ladite représentation de service.

11. Procédé de réservation de ressources selon la revendication 10, caractérisé 25 en ce qu'il comprend en outre les étapes suivantes : -détection du retrait d'un dispositif, dit dispositif retiré, d'un sous-réseau ;et - modification d'au moins une représentation de service comprenant une information d'identification du dispositif retiré.

12. Procédé de réservation de ressources selon l'une quelconque des 30 revendications 10 et 11, caractérisé en ce qu'il comprend en outre les étapes 2906666 56 suivantes : - détection de l'ajout d'un dispositif, dit dispositif ajouté, dans un sous-réseau ; et - modification d'au moins une représentation de service comprenant une 5 information d'identification du dispositif ajouté.

13. Procédé de réservation de ressources selon l'une quelconque des revendications 10 à 12, caractérisé en ce qu'il comprend en outre les étapes suivantes : - détection du retrait d'un sous-réseau, dit sous-réseau retiré, dudit réseau 10 (100) ;et - modification d'au moins une représentation de service comprenant une information d'identification d'un du ou des dispositif(s) du sous-réseau retiré.

14. Procédé de réservation de ressources selon la revendication 13, caractérisé 15 en ce qu'il comprend en outre une étape de destruction d'au moins une représentation de services qui ne comprend pas d'identification de dispositif compris dans un sous-réseau connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication associée à ladite représentation de service et qui est distincte de l'interface de 20 communication associée à ladite représentation de service.

15. Procédé de réservation de ressources selon l'une quelconque des revendications 1 à 14, caractérisé en ce que : - le ou lesdits service(s) de réservation de ressources internes est(sont) un(des) QosDevice(s) selon le protocole UPnP QoS ; 25 - lesdites requêtes de réservation de ressources internes sont des messages SetupTrafficQos selon le protocole UPnP QoS ; et - la ou lesdites demande(s) d'envoi de requête de réservation de ressources internes est(sont) un(des) message(s) RequestTrafficQos selon le protocole UPnP QoS. 30

16. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des 2906666 57 instructions de code de programme pour l'exécution des étapes du procédé de réservation de ressources selon l'une quelconque des revendications 1 à 15, lorsque ledit programme est exécuté sur un ordinateur.

17. Moyen de stockage lisible par un ordinateur, stockant un jeu d'instructions 5 exécutables par ledit ordinateur pour mettre en oeuvre le procédé de réservation de ressources selon l'une quelconque des revendications 1 à 15.

18. Dispositif gestionnaire supérieur (200) appartenant à un réseau de communication (100), ledit réseau comprenant une pluralité de sous-réseaux interconnectés par un moins un dispositif d'interconnexion (130-R1, 130-R2) 10 possédant au moins deux interfaces de communication connectées auxdits sous-réseaux, ledit dispositif gestionnaire supérieur comprenant des moyens de réservation de ressources dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source (110) et un dispositif récepteur (120), 15 caractérisé en ce qu'il comprend : - des moyens de création, pour au moins une desdites interfaces de communication, d'au moins une représentation de service de réservation de ressources internes associée à ladite interface de communication ; -des moyens de déclaration que chaque représentation de service 20 correspond à un service de réservation de ressources internes de l'interface de communication à laquelle elle est associée ; - des premiers moyens de réception d'une première requête de réservation de ressources internes pour la transmission dudit contenu destinée à une représentation de service associée à une interface de communication, dite 25 interface de communication ciblée ; - des moyens de réservation de ressources internes, pour la transmission du contenu, dans le ou les dispositifs, dit(s) dispositif(s) à réserver, dudit chemin de transmission qui appartient(nent) à au moins un sous-réseau qui n'est pas connecté à l'interface de communication ciblée. 30

19. Dispositif gestionnaire supérieur selon la revendication 18, caractérisé en 2906666 58 ce que les moyens de réservation de ressources internes comprennent : - des premiers moyens de détermination si au moins un dispositif à réserver, dit dispositif à réserver localisé, est localisé dans le sous-réseau du dispositif gestionnaire supérieur (200) ; et 5 des premiers moyens d'envoi d'une seconde requête de réservation de ressources internes pour la transmission du contenu à chacun du ou des dispositif(s) à réserver localisé(s), lesdits premiers moyens d'envoi d'une seconde requête de réservation de ressources internes étant activés dans le cas d'une détermination positive par les premiers moyens de 10 détermination.

20. Dispositif gestionnaire supérieur selon la revendication 19, caractérisé en ce qu'il comprend également : - des seconds moyens de détermination d'un dispositif, dit dispositif gestionnaire distant, compris dans le sous-réseau, dit sous-réseau du 15 dispositif gestionnaire distant, connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication ciblée mais qui est distincte de l'interface de communication ciblée ; et - des seconds moyens d'envoi au dispositif gestionnaire distant d'une 20 demande d'envoi d'une troisième requête de réservation de ressources internes pour la transmission du contenu au(x) dispositif(s) du chemin de transmission appartenant au sous-réseau du dispositif gestionnaire distant.

21. Dispositif gestionnaire supérieur selon l'une quelconque des revendications 18 à 20, caractérisé en ce qu'il comprend également : 25 -des troisièmes moyens de détermination d'une représentation de service, dite représentation de service redondante, qui est associée à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication ciblée mais qui est distincte de l'interface de communication ciblée. 30

22. Dispositif gestionnaire supérieur selon la revendication 21, caractérisé en 2906666 59 ce qu'il comprend en outre : - des seconds moyens de réception d'une quatrième requête de réservation de ressources internes, pour la transmission du contenu, destinée à la représentation de service redondante ; et 5 - des moyens d'émission d'un rapport positif d'exécution de ladite quatrième requête sans que ladite exécution ne soit effective.

23. Dispositif gestionnaire supérieur selon l'une quelconque des revendications 18 à 22, caractérisé en ce que les moyens de création ne créent pas de représentation de service de réservation de ressources internes pour les 10 interfaces de communication du ou des dispositifs d'interconnexion du sous-réseau comprenant le dispositif gestionnaire supérieur (200).

24. Dispositif gestionnaire supérieur selon l'une quelconque des revendications 18 à 22, caractérisé en ce que les moyens de déclaration ne déclarent pas de représentation de service de réservation de ressources internes 15 pour les interfaces de communication du ou des dispositifs d'interconnexion du sous-réseau comprenant le dispositif gestionnaire supérieur (200).

25. Dispositif gestionnaire supérieur selon l'une quelconque des revendications 18 à 24, caractérisé en ce que chaque représentation de service de réservation de ressources internes comprend des moyens de localisation du 20 dispositif gestionnaire supérieur (200) par une adresse de type Anycast.

26. Dispositif gestionnaire supérieur selon l'une quelconque des revendications 18 à 25, caractérisé en ce qu'il comprend des moyens de détection d'une apparition d'au moins un sous-réseau dans ledit réseau (100).

27. Dispositif gestionnaire supérieur selon l'une quelconque des 25 revendications 18 à 26, caractérisé en ce que chaque représentation de service de réservation de ressources internes comprend une information d'identification d'au moins un dispositif appartenant à un sous-réseau connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication associée à ladite représentation de service et qui est distincte de 30 l'interface de communication associée à ladite représentation de service. 2906666 60

28. Dispositif gestionnaire supérieur selon la revendication 27, caractérisé en ce qu'il comprend en outre : - des moyens de détection du retrait d'un dispositif, dit dispositif retiré, d'un sous-réseau ; et 5 -des moyens de modification d'au moins une représentation de service comprenant une information d'identification du dispositif retiré.

29. Dispositif gestionnaire supérieur selon l'une quelconque des revendications 27 et 28, caractérisé en ce qu'il comprend en outre : - des moyens de détection de l'ajout d'un dispositif, dit dispositif ajouté, 10 dans un sous-réseau ; et - des moyens de modification d'au moins une représentation de service comprenant une information d'identification du dispositif ajouté.

30. Dispositif gestionnaire supérieur selon l'une quelconque des revendications 27 à 29, caractérisé en ce qu'il comprend en outre : 15 -des moyens de détection du retrait d'un sous-réseau, dit sous-réseau retiré, dudit réseau (100) ;et - des moyens de modification d'au moins une représentation de service comprenant une information d'identification d'un du ou des dispositif(s) du sous-réseau retiré. 20

31. Dispositif gestionnaire supérieur selon la revendication 30, caractérisé en ce qu'il comprend en outre des moyens de destruction d'au moins une représentation de services qui ne comprend pas d'identification de dispositif compris dans un sous-réseau connecté à une interface de communication du dispositif d'interconnexion auquel appartient l'interface de communication 25 associée à ladite représentation de service et qui est distincte de l'interface de communication associée à ladite représentation de service.

32. Dispositif gestionnaire supérieur selon l'une quelconque des revendications 18 à 31, caractérisé en ce que : - le ou lesdits service(s) de réservation de ressources internes est(sont) 30 un(des) QosDevice(s) selon le protocole UPnP QoS ; 2906666 61 - lesdites requêtes de réservation de ressources internes sont des messages SetupTrafficQos selon le protocole UPnP QoS ; et - la ou lesdites demande(s) d'envoi de requête de réservation de ressources internes est(sont) un(des) message(s) RequestTrafficQos selon le protocole 5 UPnP QoS.