FR2998985A1 - Mecanisme de gestion de la veille des equipements d'un reseau domestique. - Google Patents

Abstract

Mécanisme de gestion de la veille des équipements d'un réseau domestique. L'invention concerne un procédé de contrôle (PROXY) de la consommation d'énergie d'au moins un terminal (3) dans un réseau local (4). Le terminal (3) est apte à répondre à une requête en découverte (MSEARCH) et à se mettre en veille (SLEEP). Le procédé (PROXY) comporte une étape d'obtention (E11) d'une description (DESCR) d'au moins un terminal (3) avant sa mise en veille (E3, SLEEP); une étape de gestion (E13, E14, E15, E16, E17) d'une requête en découverte (E22, MSEARCH) à la place du terminal (3) en veille ; une étape de requête (E17, WAKEUP) de modification de l'état de veille du terminal.

Description

Mécanisme de gestion de la veille des équipements d'un réseau domestique. Domaine technique L'invention se rapporte au domaine des télécommunications et plus particulièrement aux équipements d'un réseau domestique de télécommunications. De manière générale, l'invention s'applique à tout équipement terminal, ou plus simplement terminal, d'un tel réseau, doté d'une fonction de mise en veille. Etat de la technique Un réseau domestique est un réseau informatique qui relie ensemble, avec ou sans fils, les équipements terminaux d'une maison (ordinateurs, périphériques d'impression, de stockage, etc) aptes à communiquer ensemble. Un réseau domestique comporte un équipement routeur, aussi communément appelé passerelle domestique, ou plus simplement passerelle, élément intermédiaire assurant la redirection, ou routage, des paquets de données entre les différents terminaux et réseaux qui lui sont connectés.

La norme UPnP (de l'anglais « Universal Plug and Play ») a pour but de permettre à des terminaux périphériques de se connecter aisément et de communiquer simplement au sein d'un tel réseau. Elle constitue un ensemble de protocoles de communication basés sur le protocole IP (Internet ProtocM et promulgué par le forum de normalisation UPnP (UPnP Forum). Pour contrôler les équipements du réseau, UPnP utilise des points de contrôle (en anglais : Control Points ou CP). Un point de contrôle émet classiquement vers les différents équipements du réseau des messages dits de découverte (MSEARCH) afin de récupérer en retour une description des équipements correspondant à la requête. Ces messages de découverte sont émis le plus souvent en mode de communication point vers multipoint (multicast), du point de contrôle vers les équipements. Un terminal compatible avec la norme UPnP répond à ces messages de requête, et émet de surcroît, à fréquence régulière, des messages de présence (ALIVE) pour signifier qu'il est actif et connecté sur le réseau. Un terminal d'un réseau domestique consomme de l'énergie. Il est donc usuel de l'éteindre ou de le mettre en veille lorsqu'il n'est pas nécessaire de l'utiliser. Un mode de veille est un mode dans lequel sont désactivées certaines fonctionnalités du terminal, ce qui permet de diminuer sa consommation d'énergie tout en permettant un réveil plus rapide. Il existe parfois plusieurs niveaux de veille pour un même équipement. Dans la suite, on entend par veille un état de l'équipement dans lequel il ne peut pas émettre de message de présence, ni répondre à un message de requête en découverte du point de contrôle. Il existe plusieurs mécanismes de réveil des terminaux d'un réseau domestique : si les équipements sont connectés en Ethernet, on peut imaginer d'utiliser un protocole de réveil de type « Wake on Lan » (WoL), un standard des réseaux Ethernet qui permet à un terminal éteint d'être démarré à distance. Si les équipements disposent d'un module Zigbee, une technologie sans fil radio de basse puissance, il est possible d'échanger sur un canal radio des messages conformes au protocole ZigBee. Mais ces techniques n'offrent pas de solution, autre qu'un réveil périodique, pour que l'équipement endormi puisse répondre à une recherche en découverte. Dans sa déclinaison Low Power (de référence UPnP Low Power Architecture for LJPnPTM Version 1.0, August 28, 2007, Version 1.00), la norme UPnP permet de réveiller les équipements alors qu'ils sont en veille. A cet effet, les points de contrôle doivent cependant transmettre un message spécifique (SearchSleepingDevices) sur le réseau pour savoir quels équipements sont endormis, puis éventuellement les réveiller, avant de leur transmettre le message de découverte. Cette déclinaison Low Power doit donc être spécifiquement mise en oeuvre sur chaque point de contrôle qui souhaite pouvoir réveiller les équipements du réseau. Cette mise en oeuvre est lourde et contraignante. L'invention offre une solution ne présentant pas les inconvénients de l'état de la 20 technique. A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de contrôle de la consommation d'énergie d'au moins un terminal dans un réseau local, le terminal étant apte à répondre à une requête en découverte et à se mettre en veille, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes : 25 - Obtention d'une description d'au moins un terminal avant sa mise en veille; - Gestion d'une requête en découverte à la place du terminal en veille ; Requête de modification de l'état de veille du terminal. Ainsi, l'invention offre l'avantage de traiter un terminal en veille comme s'il était réveillé. Le procédé de l'invention répond en effet à la requête en découverte à la place du 30 terminal, qui se trouve dans un état de veille, et donc dans l'incapacité de répondre lui- même ; le procédé de l'invention agit en d'autres termes comme un proxy, selon la terminologie anglo-saxonne. Ce procédé offre l'avantage de la transparence pour le point de contrôle qui effectue la requête en découverte, puisqu'il reçoit une réponse comme si le terminal concerné était présent et apte à communiquer sur le réseau ; de plus, comme le réveil du terminal est effectué ensuite parallèlement, celui-ci a le temps de se réveiller avant que le point de contrôle ne commence effectivement à communiquer avec lui. Par parallèlement, on entend juste avant, juste après ou simultanément à la réponse au point de contrôle. Ainsi, pour le point de contrôle, tout se passe comme si l'équipement était éveillé alors qu'il est en veille et consomme donc de manière évidente moins d'énergie. Selon un mode de mise en oeuvre particulier de l'invention, le procédé est caractérisé en ce qu'il comporte en outre une étape de réception d'une notification d'entrée en veille du terminal. Un tel mode de mise en oeuvre permet au procédé de l'invention de savoir exactement à partir de quel moment il doit prendre en charge les communications adressées au terminal (typiquement, la requête en découverte) puisque le terminal, tant qu'il est encore éveillé, peut répondre lui-même. L'avantage est donc de relayer les fonctions du terminal exactement au bon moment, réalisant ainsi un compromis optimal entre la qualité de service et l'économie d'énergie. Selon un second mode de mise en oeuvre particulier de l'invention, qui pourra être mis en oeuvre alternativement ou cumulativement avec le précédent, l'étape de gestion d'une requête en découverte à la place du terminal en veille comporte les sous-étapes suivantes : Emission d'au moins une notification sur le réseau local comportant au moins une partie de la description du terminal ; Réponse à une requête en découverte du point de contrôle pour au moins un terminal en veille dont une partie au moins de la description correspond à la requête en découverte ; Réponse à une demande de description du point de contrôle avec la description du terminal en veille. Ce mode de mise en oeuvre de l'invention permet d'émettre des messages 30 d'annonce et de répondre successivement à une requête en découverte, puis à une demande de description, à la place du terminal, c'est-à-dire en substituant l'adresse du Proxy à celle du terminal, conformément aux protocole UPnP, de manière tout à fait transparente pour le point de contrôle, qui pense s'adresser au terminal, et non au proxy. De cette manière, c'est au dernier moment, lorsqu'on est certain que la description du terminal en veille correspond bien à la demande du point de contrôle, que l'on établit effectivement la communication entre le point de contrôle et le terminal.

Selon un troisième mode de mise en oeuvre particulier de l'invention, qui pourra être mis en oeuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit plus haut est en outre caractérisé en ce que l'étape de_requête de modification de l'état de veille du terminal comporte un message de réveil selon la norme UPnP. Ce mode de réalisation de l'invention permet d'utiliser uniquement le protocole UPnP et de bénéficier de ses avantages, notamment liés à la gestion fine des modes de veille selon la norme UPnP Low Power précitée. Selon un quatrième mode de mise en oeuvre particulier de l'invention, qui pourra être mis en oeuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit plus haut est en outre caractérisé en ce que l'étape de_requête de modification de l'état de veille du terminal comporte un message de réveil dans un paquet Ethernet. Ce mode de réalisation de l'invention permet d'utiliser un message de Wake on Lan (WoL) dans un paquet Ethernet, et donc de réaliser des économies d'énergie encore plus importantes en diminuant drastiquement la consommation de l'équipement. En effet, pour pouvoir être réveillé par le paquet Wake-On-Lan, l'équipement n'a besoin d'alimenter que sa carte Ethernet. Tout le reste de l'équipement (CPU, RAM, disque dur, etc.) peut être éteint. Selon un cinquième mode de mise en oeuvre particulier de l'invention, qui pourra être mis en oeuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit plus haut est en outre caractérisé en ce que l'étape de requête de modification de l'état de veille du terminal comporte un message de réveil selon le protocole Zigbee.

Ce mode de réalisation de l'invention permet notamment d'adresser des équipements qui sont dans des états de veille profonde, voir éteints, puisque le module qui assure le protocole Zigbee peut disposer de sa propre alimentation, et donc réveiller le terminal éteint sur réception du message de réveil. Selon encore un sixième mode de mise en oeuvre particulier de l'invention, qui pourra être mis en oeuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit plus haut est en outre caractérisé en ce que l'étape de_requête de modification de l'état de veille du terminal comporte un message de réveil du canal radio d'une liaison sans fils . Ce mode de réalisation de l'invention permet notamment d'adresser des équipements qui sont dans des états de veille profonde, voir éteints, mais qui ont conservé une activité sur la liaison radio WIFI. Selon encore un mode de mise en oeuvre particulier de l'invention, le procédé est caractérisé en ce qu'il comporte en outre une étape de fourniture de données à la place du terminal. Un tel mode de mise en oeuvre permet au procédé de l'invention de conserver, en plus de la description des capacités du terminal, un certain nombre de données relatives à ce terminal et aux services offerts (vignettes, images, vidéos, etc) pour répondre à sa place en attendant son réveil. Selon encore un mode de mise en oeuvre particulier de l'invention, le procédé est caractérisé en ce qu'il comporte en outre une étape de redirection vers le terminal.

Un tel mode de mise en oeuvre permet au procédé de l'invention de continuer à recevoir les demandes pour le terminal alors qu'il est déjà réveillé, et à rediriger ou non la requête selon sa nature, ou l'état de réveil du terminal, etc. Par exemple si la requête est de type BROWSE, pour visualiser l'arborescence des contenus sur le terminal, le proxy peut décider de rediriger la requête vers le terminal en fournissant son adresse, ou au contraire de la traiter à la place du terminal car il dispose des données nécessaires, évitant ainsi de le charger inutilement. Selon un aspect matériel, l'invention concerne également un dispositif de contrôle de la consommation d'énergie d'au moins un terminal dans un réseau local, le terminal étant apte à répondre à une requête en découverte et à se mettre en veille (SLEEP), ledit dispositif étant caractérisé en ce qu'il comporte : Un module d'obtention d'une description d'au moins un terminal avant sa mise en veille ; Un module de gestion d'une requête en découverte à la place du terminal en veille ; - Un module de requête de modification de l'état de veille du terminal. Selon un aspect matériel, l'invention concerne également une passerelle domestique comportant un tel dispositif.

Selon un autre aspect matériel, l'invention concerne encore un programme d'ordinateur apte à être mis en oeuvre sur un dispositif tel que décrit ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé défini au-dessus Ce programme peut être mis en oeuvre dans le dispositif inséré dans un équipement quelconque du réseau local, en particulier dans la passerelle domestique définie ci-dessus. L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.

Les figures: La figure 1 représente un réseau domestique correspondant au contexte général de l'invention. La figure 2 représente une architecture d'un terminal implémentant un mode de réalisation de l'invention. La figure 3 représente un chronogramme des échanges entre les différents équipements du réseau local lors de la mise en oeuvre de l'invention. Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente un réseau domestique correspondant au contexte général de l'invention. Le réseau domestique (4) est par exemple un réseau local IP (« Internet Protocol »). Dans cet exemple, le réseau local supporte les fonctionnalités et protocoles de la norme UPnP précitée. Le réseau domestique (4) comporte une passerelle domestique (1) reliée au réseau Internet (5) par une liaison haut débit. Il comporte aussi dans cet exemple trois équipements terminaux (2,3,7) aptes à établir des communications avec la passerelle domestique (1). Par la suite, on entend par équipement terminal, ou plus simplement terminal, tout dispositif apte à se connecter sur le réseau domestique via le protocole UPnP, tel un ordinateur portable, un décodeur numérique de télévision ou plus généralement tout 30 équipement apte à communiquer selon la norme UPnP.

Le terminal 3 est par exemple un périphérique de stockage réseau, ou serveur de médias (Media Servet) au sens UPnP ; il partage des contenus multimédia avec les autres équipements du réseau. Le terminal 2 est par exemple un téléviseur dit « connecté » (c'est-à-dire qu'il est capable de communiquer avec un réseau Internet) qui reçoit des données telles que des flux vidéo de télévision ou de vidéo à la demande ou des données de guide de programme à partir du réseau (4) et notamment en provenance du Media Server (3) ou de la passerelle (1), ou d'un réseau externe (par exemple, de Télévision Numérique de Terre ou TNT, non représenté). Le téléviseur (2) comprend un Media Rendererau sens UPnP ; il a pour fonction d'assurer le rendu (affichage) du contenu multimédia. Le téléviseur (2) et le périphérique de stockage (3) peuvent se mettre en veille. Lorsqu'ils sont en veille profonde, ils n'émettent plus de message de présence (ALIVE) sur le réseau. Pour mettre en relation ces équipements, un point de contrôle au sens UPnP (Control Point- CP) est installé sur le terminal 7, par exemple une tablette informatique. Le point de contrôle a pour fonction de découvrir les équipements et les mettre en relation. Par exemple, le point de contrôle présente le contenu du Media Server de l'équipement (3) à l'utilisateur et lui permet de le jouer sur le Media Renderer du téléviseur (2) selon l'enchaînement suivant : le point de contrôle parcourt (BROWSE) le contenu du Media Server, demande au Media Renderer de jouer (PLAY) l'un des contenus du Media Server, et le flux media est établi entre les deux équipements. Il est à noter que le point de contrôle peut se trouver sur un autre équipement, par exemple sur la passerelle domestique (1) ou sur le téléviseur (2). Dans la plupart des cas, le point de contrôle est notamment localisé dans le même équipement que le Media Renderer.

Un problème se pose dans ce type d'architecture si l'un, ou plusieurs, des équipements, sont en veille, par exemple le périphérique (3). En effet, s'il est en veille, et notamment en veille profonde, il ne peut répondre à la requête en découverte du point de contrôle, qui ne peut donc en découvrir les capacités. Il ne peut pas davantage émettre de message ALIVE sur le réseau. En d'autres termes, le point de contrôle ne peut pas connaître sa disponibilité, ni ses fonctionnalités, et ne peut donc pas en faire part à l'utilisateur. L'invention permet une gestion transparente de la mise en veille des équipements par l'introduction, par exemple sur la passerelle, d'un module logiciel, que l'on appelle « proxy UPnP », ou plus simplement PROXY, contenant une liste des équipements UPnP présents sur le réseau domestique, ainsi que leur description (adresses, noms, type de l'équipement et des services associés embarqués, etc.) Dans ce contexte, lorsqu'un équipement UPnP passe en veille, par exemple en veille profonde, le module PROXY envoie à la place de l'équipement UPnP endormi les messages d'annonce UPnP (ALIVE) ainsi que les réponses aux messages de découverte du point de contrôle (M-SEARCH), et éventuellement d'autres réponses à d'autres types de requêtes (BROWSE), en se faisant passer pour l'équipement endormi (d'où son appellation de proxy, le terme anglais référant à un objet qui se fait passer pour un autre).

On va maintenant décrire l'invention plus en détails à l'appui des figures 2 et 3. La figure 2 représente l'architecture d'un équipement qui implémente un mode de réalisation de l'invention, comme par exemple la passerelle (1) de la figure 1. Il comprend, classiquement, des mémoires (M) associées à un processeur (CPU).

Les mémoires peuvent être de type ROM (de l'anglais Read Only Memoty) ou RAM (de l'anglais Random Access Memoty) ou encore Flash. Une partie de la mémoire M contient notamment, selon l'invention, une table de description d'un ou plusieurs équipements du réseau aptes à se mettre en veille. Cette table est utilisée par le module PROXY de simulation d'un équipement UPnP endormi.

Un exemple d'une telle table est donné ci-dessous dans une syntaxe de description XML (de l'Anglais« eXtended Markup Language ».) <deviceList> - <device> <status>standby</status> <ZigBeeEnabled>false</ZigBeeEnabled> <WoLEnabled>true</WoLEnabled> <MACAddress>01:02:03:04:05:06</MACAddress> <URLBase>http://192.168.1.10/</URLBase> <deviceType>urn:schemas-upnp- org:device:MediaServer:1</deviceType> <modelDescription>Orange Media Server</modelDescription> <modelName>PC</modelName> <UDN>uuid:1cd3c616-b194-4411-87c6-022cf7264139</UDN> <serviceList> - <service> <serviceType>urn:schemas-upnp- org:service:ConnectionManager:1</serviceType> <serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId> </service> - <service> <serviceType>urn:schemas-upnp- org:service:ContentDirectory:1</serviceType> <serviceId>urn:upnp-org:serviceId:ContentDirectory</serviceId> <SCPDURL>cds.xml</SCPDURL> <controlURL>/upnp/control/cds</controlURL> <eventSubURL>/upnp/event/cds</eventSubURL> </service </serviceList> </device> «device> <status>off</status> <ZigBeeEnabled>true</ZigBeeEnabled> <WoLEnabled>false</WoLEnabled> <ZigBeeAddress>ABCD</ZigBeeAddress> <URLBase>http://192.168.1.11/</URLBase> <deviceType>urn:schemas-upnp-org:device:MediaRenderer:1</deviceType> <modelDescription>Orange Media Renderer</modelDescription> <serviceList> - <service> <serviceType>urn:schemas-upnp-org:service:ConnectionManager:1 </serviceType> <serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId> </service> - <service> <serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType> <serviceId>urn:upnp-org:serviceId:AVTransport</serviceId> </service> <service> <serviceType>urn:schemas-upnp-org:service:RenderingContro1:1</serviceType> <serviceId>urn:upnp-org:serviceId:RenderingControl</serviceId> </service> </serviceList> </device> </deviceList> Ce fichier comprend une liste (<deviceList>) de deux équipements, chacun des équipements étant classiquement décrit entre une balise ouvrante <device> et une balise fermante </device>. Le premier équipement est un Media Server (balise <DeviceType>). Il est en veille (balise <status>), et il propose deux types de services (<serviceType>) UPnP: il est capable de se connecter en UPnP (Connection Manager) et de lister les contenus qui sont accessibles par son intermédiaire (ContentDirectory). Il fonctionne classiquement en mode de communication Ethernet ; il est capable par ce moyen de recevoir des messages de réveil Wake on Lon (<WoLEnabled>true), qui permettent à un terminal en veille d'être réveillé à distance. Le second équipement est un Media Renderer (<DeviceType>). Il est éteint (<status>), et il propose deux types de services UPnP : il est capable de se connecter en UPnP (Connection Manager), de transporter et de jouer un contenu audiovisuel (AVTransport). Il fonctionne en mode radio selon le protocole ZigBee (<ZigBeeEnabled>) qui permet notamment de le réveiller à distance. On notera que ces données XML ne constituent qu'un exemple de données de description et que l'invention peut également s'appliquer à des données de description conformes à un autre standard. La passerelle 1 communique avec le réseau local et le réseau Internet via le module Ethernet et les modules radio WIFI et Zigbee. Le module Ethernet permet notamment d'émettre et recevoir des commandes de réveil de type WoL. Le module WIFI permet de communiquer sans fils sur un canal radio. Le module Zigbee permet d'échanger sur un canal radio des messages conformes au protocole ZigBee (par exemple des messages de réveil). La passerelle 1 comprend en outre, conformément à ce mode de réalisation de l'invention, un module PROXY de contrôle de l'énergie. Le module PROXY peut être par exemple un programme logiciel s'exécutant dans la mémoire de la passerelle 1, ou un ensemble matériel et logiciel apte à contrôler le terminal pour communiquer à sa place et le faire entrer et sortir d'un état de veille. Le module PROXY peut, alternativement, se trouver sur un autre équipement du réseau local.

On peut imaginer de surcroît que le point de contrôle (CP selon la terminologie UPnP) se trouve à l'intérieur de la passerelle domestique (1) ; le CP communique avec les terminaux (sur l'exemple, les terminaux 2 et 3) via le réseau local (4,5) en mode filaire (Ethernet) ou sans fils ; alternativement, il peut être également situé à l'extérieur de la passerelle, comme représenté sur la figure 1. La figure 3 représente les échanges entre un point de contrôle (CP) de type UPnP, un proxy selon l'invention (PROXY) et un terminal (3), par exemple le Media Server de la figure 1, ou encore selon d'autres exemple un Media Renderer, un serveur de téléphonie (Telephony Servet) sur un PC, un périphérique de stockage de contenus dans le réseau (NAS), un décodeur TV numérique, etc. Le terminal (3) est accessible sur le réseau local via son adresse LOC1 (typiquement une URL, de l'anglais Uniform Ressource Locator, comportant une combinaison d'adresse Internet (IP) et de numéro de port) et le PROXY via une adresse LOC2. Lorsque le terminal 3 sort d'un mode de veille, comme il sera détaillé par la suite, il est probable que son adresse change. Il devient alors accessible, selon l'exemple, via l'adresse LOC3. Lors d'une étape El, le terminal (3) émet sur le réseau, en mode multicast, une annonce de type UPnP ALIVE pour signifier qu'il est présent et actif. Le message diffusé est schématisé sur la figure 3, comme tous les messages suivants, par le type de message (ALIVE) suivi des paramètres du message entre séparateurs (<>), et éventuellement de l'adresse entre parenthèses. Ainsi, ALIVE(LOC1) signifie que le terminal transmet son adresse en paramètre du message ALIVE. La syntaxe complète d'un tel message UPnP serait de la forme : SSDP NOTIFY ssdp : alive LOCA7701V1. Le message ALIVE est reçu dans l'exemple par le PROXY (E10) et par le CP (E20). Après avoir reçu le message ALIVE (E10), le PROXY de l'invention transmet, lors d'une étape Eh, sur le réseau, un message GET (http GET LOCA770N 1) et récupère en réponse les informations relatives au terminal, générées au cours d'une étape E2 par le terminal et transmises via un message OK comportant en paramètre ces informations <DESCR>. Il s'agit notamment de l'adresse de l'équipement, de son type, des services rendus, etc. comme représenté par exemple dans la table XML décrite à l'appui de la figure 2. Le PROXY sauvegarde ces données dans une base de données (DB) qui se trouve dans une mémoire associée, par exemple la mémoire M de la figure 2. Lors d'une étape E3, le terminal (3) passe en veille, à la suite par exemple d'une action de l'utilisateur. Il en informe le PROXY par un message approprié, par exemple un message de notification (NOTIFY) UPnP ou encore un message conforme au protocole Zigbee. D'autres paramètres peuvent être associés à ce message, par exemple le niveau de veille si le terminal dispose de plusieurs niveaux de veille différents, le temps de réveil associé, la consommation électrique, l'adresse de réveil, etc.

Lors d'une étape E12, le PROXY enregistre l'état du terminal endormi (par exemple, dans la base de données DB). A partir de ce moment, il sait qu'il devra répondre à la place du terminal endormi. Il se met donc à émettre régulièrement des messages ALIVE à la place du terminal, comme schématisé à la sortie de l'étape E13 par le message ALIVE<DESCR>(LOC2) qui comporte en paramètre l'adresse (LOC2) du PROXY et non l'adresse (LOC1) du terminal (3) (message UpnP : SSDP NOTIFY ssdp :alive LOCATION2). Lors d'une étape E22, le control point CP, qui a par exemple été sollicité par un utilisateur désirant visualiser un film situé sur le terminal (3), émet une requête dite requête en découverte (MSEARCH<CIBLE>), pour rechercher tous les terminaux UPnP du réseau de type correspondant à la cible, c'est-à-dire dans l'exemple tous les terminaux de type Media Server. Dans la syntaxe UPnP, ce message est de la forme UPnP; SSDP MSEARCH cible. Le PROXY reçoit et analyse ce message au cours d'une étape E14, à la suite de laquelle il répond (E15) au CP avec les informations qu'il a récupérées auprès du ou des terminaux UPnP endormis qui répondent au critère de recherche. La réponse, issue de l'étape E15, est de type http Ok 200 LOCATION2 schématisée par OK <CIBLE> (LOC2) sur la figure.

Le point de contrôle CP, s'il est intéressé par la cible découverte à l'étape E23, réagit alors au cours d'une étape E24 par un message GET<CIBLE> (HTTP GET LOCATION2) pour récupérer davantage d'informations sur la cible découverte. Lors d'une étape E17, le PROXY de l'invention émet deux messages (simultanément ou successivement) vers les deux autres entités, respectivement vers le terminal (WAKEUP) afin qu'il puisse répondre aux sollicitations ultérieures du CP, et vers le CP pour lui fournir les informations qu'il a récupérées du (ou des) terminal (terminaux) endormi(s) correspondant à la cible. Le message de réveil (WAKEUP) est par exemple un message UPnP de réveil, ou un message WOL (Wake on Lan) ou un message Zigbee. Il peut être accompagné de paramètres, comme par exemple un délai de réveil (T). Ce message permet donc de réveiller le terminal en avance, c'est-à-dire suffisamment tôt pour pouvoir répondre rapidement aux sollicitations ultérieures du CP. Le message de description (0K<DESCR>) comporte en paramètre l'adresse du PROXY (LOC2) et non l'adresse du Media Server (LOC1) avec lequel le CP croit avoir entamé un dialogue.

Lors d'une étape E26 facultative, représentée en pointillé sur la figure, le CP peut demander une visualisation du contenu de l'équipement qui vient de lui être communiqué en tant que cible. Le message correspondant, BROWSE, est reçu par le PROXY lors d'une étape E18, au cours de laquelle il examine et éventuellement transmet ou affiche les informations dont il dispose, qui peuvent avoir été déposées dans la mémoire cache préalablement (par exemple lors de l'étape E11). En référence à la table XML précédemment décrite, le PROXY utilise pour répondre les contenus des balises associées au service ContentDirectory. Le PROXY peut garder quelques éléments en cache (vignettes, images, vidéos, etc) pour répondre « temporairement » en attendant le réveil du terminal. On peut ainsi imaginer que le PROXY peut accéder à la liste des films disponibles sur le terminal (3) et peut la présenter au CP avant même que le terminal (3) ne soit réveillé. Lors d'une étape E5, le terminal sort de son état de veille et émet un message ALIVE sur le réseau, qui est reçu par le CP à l'étape E27 et par le PROXY à l'étape E10. A la suite de ce message ALIVE, qui comporte en paramètre la nouvelle adresse LOC3 du terminal, le CP peut accéder classiquement au nouveau terminal découvert par une requête de type GET (étape E28) comportant en paramètre l'adresse LOC3 du terminal (HTTP GET LOCATION3).Le terminal répond à cette requête (étape E6) par un message OK <LOC3> et la communication entre les équipements peut se dérouler normalement, de manière conforme au protocole UPnP. Par la suite, le terminal (3) peut prévenir le PROXY d'une mise en veille ultérieure et le cycle recommence. Selon une variante, présentée en pointillé aux étapes E19 et E26bis, le CP émet une nouvelle requête BROWSE vers le PROXY, à destination du terminal, et le PROXY répond, non plus par un simple affichage des données du terminal, comme à l'étape E18, mais par une opération de redirection de contenu (par exemple par l'intermédiaire d'un message HTTP ici noté URL w/REDIRECT) , afin que le CP puisse accéder au terminal qui est désormais réveillé et donc prêt à fournir lui-même le service. Ainsi, le PROXY peut offrir différentes réponses conformément à plusieurs variantes possibles de réalisation, lors d'une requête de service UPnP impliquant un contenu (par exemple l'étape E19). Différents modes de réalisation de mise en mémoire cache et/ou de redirection peuvent être combinés en fonction du réveil ou non de l'équipement terminal d'origine et des différentes informations de consommation (au sens des contenus UPnP) de celui-ci.

Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention.

Notamment, l'invention peut aussi prendre en compte différents types de message UPnP et pas seulement les messages UPnP AV de type BROWSE. Ainsi, le PROXY peut prendre en charge les messages GetCallLogs ou GetValues afin de renvoyer au CP le journal d'appels ou le carnet d'adresses en attendant le réveil d'un équipement terminal de type UPnP Telephony Server.

Claims (12)

1. REVENDICATIONS1. Procédé de contrôle (PRO)(Y) de la consommation d'énergie d'au moins un terminal (3) dans un réseau local (4), le terminal (3) étant apte à répondre à une requête en découverte (MSEARCH) et à se mettre en veille (SLEEP), ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes : Obtention (E11) d'une description (DESCR) d'au moins un terminal (3) avant sa mise en veille (E3, SLEEP); Gestion (E13, E14, E15, E16, E17) d'une requête en découverte (E22, MSEARCH) à la place du terminal (3) en veille ; Requête (E17, WAKEUP) de modification de l'état de veille du terminal.
2. 2. Procédé de contrôle (PRO)(Y) de la consommation d'énergie d'un terminal selon la revendication 1, ledit procédé étant caractérisé en ce qu'il comporte en outre une étape de réception (E12) d'une notification d'entrée en veille (E3, NOTIFY SLEEP) du terminal (3).
3. 3. Procédé de contrôle (PRO)(Y) de la consommation d'énergie d'un terminal selon la revendication 1, caractérisé en ce que l'étape de gestion d'une requête en découverte comporte les sous-étapes suivantes Emission (E13) d'au moins une notification (ALIVE) sur le réseau local comportant au moins une partie de la description (DESCR) du terminal Réponse (E15) à une requête en découverte (MSEARCH<CIBLE>) du point de contrôle (CP) pour au moins un terminal (3) en veille dont une partie au moins de la description (DESCR) correspond à la requête en découverte (CIBLE); Réponse (E17) à une demande de description (GET) du point de contrôle (CP) avec la description (DESCR) du terminal (3) en veille.
4. 4. Procédé de contrôle de la consommation d'énergie d'un terminal selon la revendication 1, caractérisé en ce que l'étape de requête (E17, WAKEUP) de modification de l'état de veille du terminal comporte un message de réveil (WakeUp) selon la norme UPnP.
5. 5. Procédé de contrôle de la consommation d'énergie d'un terminal selon la revendication 1, caractérisé en ce que l'étape de requête (E17, WAKEUP) de modification de l'état de veille du terminal comporte un message de réveil (Wake on Lan) dans un paquet Ethernet.
6. 6. Procédé de contrôle de la consommation d'énergie d'un terminal selon la revendication 1, caractérisé en ce que l'étape de requête (E17, WAKEUP) de modification de l'état de veille du terminal comporte un message de réveil (On/Off) selon le protocole Zigbee.
7. 7. Procédé de contrôle de la consommation d'énergie d'un terminal selon la revendication 1, caractérisé en ce que l'étape de requête (E17, WAKEUP) de modification de l'état de veille du terminal comporte un message de réveil du canal radio d'une liaison sans fils (WIFI).
8. 8. Procédé de contrôle de la consommation d'énergie d'un terminal selon la revendication 1, ledit procédé étant caractérisé en ce qu'il comporte en outre une étape (E18) de fourniture de données (BROWSE) à la place du terminal.
9. 9. Procédé de contrôle de la consommation d'énergie d'un terminal selon la revendication 1, ledit procédé étant caractérisé en ce qu'il comporte en outre une étape (E19) de redirection (BROWSE w/REDIRECT) vers le terminal.
10. 10. Dispositif de contrôle (PRO)(Y) de la consommation d'énergie d'au moins un terminal (3) dans un réseau local (4), le terminal (3) étant apte à répondre à une requête en découverte (MSEARCH) et à se mettre en veille (SLEEP), ledit dispositif étant caractérisé en ce qu'il comporte : Un module d'obtention (WIFI, Zigbee, ETH) d'une description ( OK, DESCR) d'au moins un terminal (3) avant sa mise en veille (E11, SLEEP); Un module de Gestion (PROXY, BD) d'une requête en découverte (E13, MSEARCH) à la place du terminal (3) en veille ; Un module de requête (WIFI, Zigbee, ETH) de modification de l'état de veille du terminal.
11. 11. Passerelle domestique (1) comportant un dispositif selon la revendication 10.
12. 12. Programme d'ordinateur apte à être mis en oeuvre sur un dispositif tel que défini dans la revendication 10, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé défini selon la revendication 1.