FR3003714A1 - Mecanisme de deploiement d'un service dans un reseau domestique - Google Patents

Abstract

L'invention concerne un procédé de gestion du déploiement d'un service (PHO) dans un réseau local (1). Le service requiert de la part d'au moins un terminal (2,3,4,5) du réseau local (1) une capacité matérielle et/ou logicielle. Le procédé est caractérisé en ce qu'il comporte les étapes de : - réception (E10) d'une requête (INST, ACT) relative au service (PHO) en provenance d'un terminal (2-5) ; - acquisition (E12) d'au moins une information liée à la capacité (Win7, available_storage d'au moins un terminal (2-5) du réseau local ; - vérification (E15) d'au moins une information acquise (Win7, available_storage) en fonction de la capacité requise (SLAI, SLAA) ; - action (INST, ACT, PHOV, PHOP) sur au moins un terminal (2-5) pour déployer le service (PHO).

Description

Mécanisme de déploiement d'un service dans un réseau domestique. Domaine technique L'invention se rapporte au domaine des télécommunications et plus particulièrement à un réseau local de communications. De manière générale, l'invention s'applique aux équipements d'un tel réseau et plus particulièrement à la passerelle résidentielle dans le cas d'un réseau domestique. Etat de la technique Un réseau domestique est un réseau informatique qui relie ensemble, avec ou sans fils, les équipements terminaux, ou plus simplement 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, é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. Dans le contexte d'un réseau domestique, un utilisateur a la possibilité d'exécuter un service donné sur un terminal donné disposant de caractéristiques propres (par exemple, visualiser les photographies numériques de l'utilisateur sur un téléviseur ou sur une tablette numérique). Un tel service peut être vu comme un ensemble de composantes logicielles, ou programmes, associées à un ensemble de composantes matérielles. Le service ne peut être rendu sur un terminal particulier que si l'ensemble des composantes logicielles et/ou matérielles nécessaires à son bon fonctionnement sont déployées, c'est à dire installées et activées pour ce type de terminal. Par déploiement d'un service, on entend ici plus largement l'installation et la désinstallation de composantes logicielles du service ainsi que l'activation et la désactivation de composantes logicielles ou matérielles du service. Dans certains cas, il est souhaitable d'exécuter un tel service sur plusieurs équipements terminaux (tablette, smartphone, TV, PC, etc.) d'un même utilisateur : par exemple, un utilisateur peut souhaiter visualiser des photographies numériques, grâce à un service de gestion de telles données, sur son téléviseur, mais aussi sur une tablette numérique, ou en coopération entre les deux terminaux. Or, rendre un tel service sur des terminaux hétérogènes est complexe à mettre en oeuvre. Il faut en effet s'assurer que le service peut être installé, puis qu'il peut être exécuté et enfin qu'il s'exécute correctement sur tous les terminaux visés de l'utilisateur. Il existe des solutions pour déployer un tel service sur un terminal donné : par exemple, une boutique d'applications (« App Store » ou « boutique Android ») permet à l'utilisateur de télécharger un service donné (par exemple le logiciel de gestion de photographies cité préalablement) sur une tablette donnée. Selon un autre exemple, les spécifications du forum international « broadband forum », en particulier la spécification TR069 ("CPE WAN Management Protocol"), offrent des solutions pour gérer la communication entre un équipement terminal d'un réseau local et un serveur d'auto-configuration associé dans un réseau appartenant à un opérateur, permettant ainsi une administration à distance (configuration, diagnostic, maintenance, etc.) d'un terminal donné. Il s'agit dans ces cas d'une solution homogène, c'est-à-dire que le même logiciel est installé sur tous les terminaux de même type (par exemple, sur toutes les tablettes équipées d'un système Android). Il existe aussi des solutions pour déployer un même service, sous forme de composantes logicielles, sur plusieurs terminaux de même type. Par exemple, l'application « Windows update» de Microsoft permet de mettre à jour automatiquement un parc de terminaux (ordinateurs personnels, tablettes, etc.) équipés d'un système d'exploitation Windows. Il s'agit, dans ce cas également, d'une solution homogène, dans le sens où le même logiciel est installé sur tous les terminaux équipés d'un même système d'exploitation (par exemple, sur tous les PC et tablettes équipées d'un système Windows Ces solutions ne permettent pas aujourd'hui de déployer automatiquement un tel service sur un ensemble de terminaux hétérogènes du réseau local (par exemple, des composantes logicielles complémentaires pour un PC sous Windows et une tablette sous Android). L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique.

L'invention A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de gestion du déploiement d'un service dans un réseau local, ledit service requérant de la part d'au moins un terminal du réseau local une capacité matérielle et/ou logicielle, ledit procédé étant caractérisé en ce qu'il comporte les étapes de : - réception d'une requête relative au service en provenance d'un terminal ; - acquisition d'au moins une information liée à la capacité d'au moins un terminal du réseau local ; - vérification d'au moins une information acquise en fonction de la capacité requise ; - action sur au moins un terminal pour déployer le service. L'invention permet ainsi de déployer un service pour différents terminaux (PC, tablette, etc.) de l'utilisateur, tout en prenant en compte leurs caractéristiques : si deux terminaux selon l'invention exhibent des caractéristiques différentes, l'action exécutée sur les dits terminaux peut être différente. Par exemple, dans le contexte d'un service de gestion des photographies numériques de l'utilisateur, il peut être envisagé d'installer et exécuter un logiciel de partage de photos sur le PC de l'utilisateur, et un logiciel de visualisation sur la tablette de l'utilisateur. En particulier, la récupération des caractéristiques liées aux terminaux concernés du réseau local permet de déployer le service de manière fiable pour l'utilisateur, après avoir vérifié que les caractéristiques pré-requises sont bien vérifiées par les informations acquises sur les différents terminaux hétérogènes. Par action, on entend ici l'installation, activation, désinstallation ou désactivation liée à l'une des composantes logicielles nécessaires au déploiement du service, c'est-à-dire le déploiement d'une partie du service. Il peut aussi s'agir d'une activation ou d'une désactivation de composantes matérielles du service (activation ou désactivation d'une carte réseau par exemple).

Selon un mode de mise en oeuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que la requête est une requête d'installation du service et l'action sur le terminal une action d'installation d'une composante logicielle appartenant au service.

Ainsi, une première étape de déploiement d'un service selon l'invention peut consister à installer le service sur les différents terminaux. Par installation, on peut aussi entendre une mise à jour dans le cas ou la composante logicielle ou matérielle serait déjà présente sur le terminal cible, mais nécessiterait une modification.

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, un procédé tel que décrit ci-dessus est caractérisé en ce la requête est une requête d'activation du service et l'action sur le terminal une action d'activation d'une composante logicielle ou matérielle appartenant au service. Ainsi, une seconde étape de déploiement du service selon l'invention permet d'activer le service sur les différents terminaux, par exemple la composante logicielle qui permet de visualiser les photographies numériques sur la tablette et la composante logicielle qui permet de partager les photographies sur le PC de l'utilisateur. Ceci est particulièrement avantageux si le service a été préalablement installé. Alternativement, on peut imaginer que la commande d'activation entraîne une vérification et une installation préalables, éventuellement une mise à jour, des composantes du service, sans qu'il en soit fait mention via une requête explicite : un service, pour être activé, doit au préalable être présent, c'est-à-dire installé. 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 ci-dessus comporte en outre les étapes suivantes : - acquisition d'un modèle pour la mise en oeuvre du service demandé ; - instanciation du modèle acquis pour obtenir un modèle instancié.

L'invention permet ainsi de déployer le service pour différents terminaux hétérogènes (PC, tablette, etc.) de l'utilisateur, de manière simple et efficace : grâce au modèle, différentes composantes logicielles et/ou matérielles correspondant au service peuvent être prévues pour un déploiement sur différents terminaux. Par exemple, le modèle peut préciser que le service de rendu photographique nécessite l'installation d'une composante logicielle (le programme de partage de photographies) sur un PC et d'une autre composante logicielle (le programme de visualisation) sur une tablette possédant certaines caractéristiques. L'instanciation permet de spécialiser le modèle reçu pour le réseau local concerné (la tablette apparaissant dans le modèle instancié est l'une de celles appartenant à l'utilisateur concerné). Le modèle, une fois instancié, fournit alors toutes les indications nécessaires au bon déroulement du déploiement sur les terminaux hétérogènes de manière automatique, c'est à dire sans avoir recours à un opérateur humain.

Selon une variante de ce troisième mode de mise en oeuvre particulier de l'invention, le procédé est caractérisé en ce que le modèle comporte un plan de déploiement du service. Un tel plan de déploiement du service permet de décrire les différents types d'installations et d'actions successives à effectuer sur les différents terminaux du réseau (par exemple, installer une composante logicielle de partage de photos sur un PC et une composante logicielle de visualisation sur une tablette du client). Il peut s'agir d'un plan d'installation, d'activation, de désactivation ou de désinstallation.

Selon une autre variante de ce troisième mode de mise en oeuvre particulier de l'invention, qui pourra être mis en oeuvre cumulativement ou alternativement avec la précédente, le procédé est caractérisé en ce que le modèle comporte un ensemble de contraintes.

Par contrainte, on entend ici un pré-requis logiciel ou matériel nécessaire au déploiement du service : par exemple, la tablette destinée à la visualisation doit posséder certaines dimensions ; le PC destiné au module de partage doit posséder une certaine quantité de mémoire vive.

Cette variante permet d'accéder à une vue globale des pré-requis et des actions à effectuer sur le réseau local choisi. Cette ensemble de contraintes peut être typiquement exprimé dans des modules, dits modules SLA (Service Level Agreement) qui permettent de lister les contraintes nécessaires pour l'ensemble des terminaux associés au service. Ainsi, l'étape de vérification des informations acquises des terminaux permet de n'autoriser le déploiement d'un service que si l'ensemble des contraintes, ou pré-requis, relatives à ce terminal sont respectées, évitant ainsi les problèmes classiques auquel un utilisateur peut être confronté : manque de mémoire, de disque dur pour exécuter le programme, insuffisance de bande passante, modules logiciels manquants, etc. Selon un aspect matériel, l'invention concerne également un dispositif de gestion du déploiement d'un service dans un réseau local, ledit service requérant de la part d'au moins un terminal (2,3,4,5) du réseau local (1) une capacité matérielle et/ou logicielle, ledit dispositif de gestion (GHM) étant caractérisé en ce qu'il comporte : - un module de réception d'une requête relative au service en provenance d'au moins un terminal ; - un module d'acquisition d'au moins une information liée à la capacité d'au moins un terminal du réseau local ; - un module de vérification de l'information acquise en fonction de la capacité requise ; - un module d'action sur au moins un terminal pour déployer le service.

Selon un autre aspect matériel, l'invention concerne encore une passerelle domestique caractérisée en ce qu'elle comprend un dispositif tel que défini ci-dessus. Selon encore un autre aspect matériel, l'invention concerne 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. 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 le contexte général d'un mode de réalisation de l'invention.

La figure 2 représente une architecture d'une passerelle résidentielle implémentant un mode de réalisation de l'invention. La figure 3 schématise la manière dont la passerelle résidentielle prépare le déploiement d'un service puis le déploie effectivement selon un mode de réalisation de l'invention.

La figure 4 schématise la manière dont la passerelle résidentielle prépare et réalise l'activation d'un service hétérogène. Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente un réseau domestique, ou réseau local, correspondant au contexte général de l'invention. Le réseau domestique (1) est par exemple un réseau local IP (Internet Protocol). Le réseau domestique (1) comporte une passerelle résidentielle (6) reliée au réseau large bande (7) de l'opérateur par une liaison haut-débit (8). Il comporte aussi, dans cet exemple, des équipements terminaux (2, 3, 4, 5) aptes à établir des communications avec la passerelle résidentielle (6). Par la suite, on entend par équipement terminal, ou plus simplement terminal, tout dispositif apte à se connecter et communiquer sur le réseau domestique. Dans ce mode de réalisation de l'invention, quatre équipements terminaux (2, 3, 4, 5) sont représentés. Il s'agit respectivement d'un téléviseur (2) (équipé d'un décodeur numérique, ou STB, non représentée), d'un ordinateur personnel (PC,3), d'un disque dur (NAS,4) et d'une tablette numérique (TAB,5). Ces terminaux appartiennent à l'utilisateur 10. Ils sont de nature hétérogène. Ils peuvent, par exemple, différer par : - leur système d'exploitation (Windows, Linux, Android, etc.) ; - leur type de connexion au réseau (Ethernet, Wifi, Bluetooth, etc.) ; - leurs capacités en mémoire (disque dur pour le stockage des vidéos, mémoire vive pour l'exécution des programmes, etc.) Un terminal du réseau local est généralement capable de communiquer avec un réseau Internet via la passerelle (6). Le réseau large-bande (7) de l'opérateur comporte par exemple une plateforme de services (9) qui contient un certain nombre de services de l'opérateur, par exemple des services de vidéo à la demande (VOD), des services de gestion de photographies numériques (PHO), etc. Dans la suite de cet exemple, on considère que l'utilisateur (10) souhaite visualiser des photographies sur sa tablette (5) et son TV (2), les stocker sur son NAS (4) et les partager entre les différents terminaux via une composante logicielle installé sur son PC (3). Selon l'état de la technique connue, il lui faut télécharger manuellement le service sur chacun des terminaux en ayant vérifié au préalable que certaines contraintes sont respectées : par exemple, un disque dur en réseau (NAS, 4) doit être présent ou connecté ; selon un autre exemple, le disque dur en réseau (NAS, 4) doit avoir suffisamment d'espace de stockage, les terminaux doivent disposer d'une certaine capacité en mémoire vive (RAM), et ils doivent tous être connectés au réseau local avec un débit (bande passante) minimum. Un certain nombre de logiciels peut par ailleurs être pré-requis : composante logicielle de visualisation de photographies pour la tablette sous Android et pour le TV, composante logicielle de partage pour le PC sous Windows 7, etc. S'ils ne sont pas déjà correctement installés sur les terminaux cible, l'utilisateur (10) devra les installer manuellement. Dans le cas de l'invention, au contraire, l'utilisateur est déchargé de ces différentes actions : la passerelle récupère un modèle, ou template selon la terminologie anglo-saxonne, pour le déploiement du service. Puis elle l'instancie, effectue un contrôle des terminaux concernés du réseau local, et finalement supervise l'installation des composantes logicielles du service sur les différents terminaux. Le terme de modèle tel qu'utilisé dans la suite de la description, correspond en fait à deux éléments distincts dont la combinaison permet d'offrir le service au client de manière transparente : - un plan de déploiement pour le service requis. Ce plan de déploiement comporte notamment une liste d'action à effectuer pour chaque catégorie de terminal concernée par le service (modules logiciels à télécharger, etc.). Conformément à la définition du déploiement donnée précédemment, un plan de déploiement peut être soit un Plan d'Installation (PdI), soit un Plan d'Activation (PdA). - un ensemble de documents de service (SLA pour Service Level Agreement) définissant les pré-requis, ou contraintes, pour chaque terminal (bande passante, type de connexion, mémoire disponible, etc.). Un SLA peut être soit un SLA d'Installation (SLAI), soit un SLA d'Activation (SLAA). Afin de communiquer avec la passerelle lors des échanges relatifs au déploiement, chaque terminal du client (10) doit être équipé d'un module logiciel ou matériel qui assure la gestion locale du déploiement (installation, activation, etc.). Ce module sera désigné par la suite sous le terme de LHM (pour « Local Home Manager ») alors que le module qui gère le déploiement sur la passerelle sera désigné sous le terme de GHM (pour « Global Home Manager »). La figure 2 représente l'architecture d'un terminal qui implémente un mode de réalisation de l'invention, comme par exemple la passerelle (6) 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 Memory) ou RAM (de l'anglais Random Access Memory) ou encore Flash. La passerelle 6 communique avec le réseau large bande de l'opérateur via un module Ethernet (ETH) et avec le réseau local via un module de communication filaire ou non filaire (Ethernet, Wifi, etc.).

La passerelle 6 comprend en outre, conformément à l'invention, un certain nombre de modules qui peuvent être matériels ou logiciels, regroupés dans une entité qui s'appelle le GHM (pour : « Global Home Manager », que l'on peut traduire par « Gestionnaire Global de la Maison ») : - CORE : c'est le coeur du GHM, en charge de la coordination de tous les autres modules ; il récupère notamment le modèle, les informations sur le réseau local et ses terminaux, il fait instancier le modèle, demande les analyses correspondantes, gère les mises à jour, etc. - IMI (pour Infrastructure de Monitoring et d'Inventaire) : c'est le module en charge de récupérer et gérer les informations de surveillance (monitoring) et d'inventaire sur le réseau local (logiciels, liens réseaux, capacité des terminaux, etc.). - TI (pour Template Instancier) : c'est le module chargé de réaliser l'instanciation du modèle (i.e. template), c'est-à-dire de générer à partir de ce modèle une structure de données valides représentative du réseau local, comportant notamment les étapes de déploiement (issues du plan de déploiement du service) et l'état du réseau local (issu des SLAs : nom et type des terminaux, état des connexions, etc.). - ANA (pour ANAlyzer) : c'est le module qui traite la demande d'analyse sur la base du modèle instancié. Il vérifie que le réseau local satisfait les pré- requis (en terme de terminaux, liens réseaux et composants logiciels) du service à déployer. - DPE (pour Deployment Plan Executer) : c'est le module chargé d'exécuter le plan de déploiement après qu'il a été instancié, en entrant notamment en communication avec les modules locaux (LHM) des différents terminaux pour leur demander d'installer et/ou d'exécuter des programmes du service. Il ne s'agit naturellement que d'un exemple de répartition possible des modules et des tâches associées au sein de la passerelle domestique. Toute autre organisation en modules logiciels ou matériels à la portée de l'homme du métier peut être envisagée.

La figure 3 schématise la manière dont la passerelle résidentielle réalise une préparation au déploiement d'un service, puis le déploiement effectif du service sur les terminaux (2-5) de l'utilisateur (10).

On rappelle le contexte de l'exemple : l'utilisateur (10) veut installer un service de gestion de photographies numériques (PHO) pour pouvoir rechercher, visualiser, partager les photographies qui se trouvent sur les terminaux présents dans sa maison, notamment son PC (3), sa tablette (5), son TV (2) et son disque dur (4). A cette fin, deux composantes logicielles doivent être installées sur ses équipements : composante logicielle de partage (PHOP) sur le PC-Windows (3) et composante logicielle de visualisation (PHOV) sur la tablette-Android (5). L'utilisateur (10) émet une première requête INST(PHO) vers la passerelle (6). Il s'agit ici d'une requête pour l'installation du service PHO, reçue par le module CORE du GHM de la passerelle lors d'une étape E10. La requête comporte donc en paramètre un identifiant du service (nom, numéro, référence, etc.). En variante, on peut bien sûr envisager de passer d'autres paramètres, comme par exemple les identifiants du PC, de la tablette, etc. choisis par l'utilisateur dans le cadre du déploiement du service PHO. Lors d'une étape suivante E11, le module CORE demande au serveur (9) de l'opérateur les modèles (respectivement d'installation : TI et d'activation : TA) comportant le plan de déploiement (resp. d'installation PdI et d'activation PdA) du service et les documents SLA (resp. d'installation SLAI et d'activation SLAA). Le serveur répond lors d'une étape E20 par la fourniture des modèles. Selon une variante, ces documents sont déjà accessibles par le GHM, par exemple ils se trouvent sur la passerelle, qui n'a donc pas besoin de les requérir à l'extérieur. Selon une autre variante, les modèles peuvent être mis à disposition sur un site web du fournisseur/éditeur de logiciel du service PHO et accessibles via une requête appropriée (HTTP, FTP, etc.) Selon encore une autre variante, les modèles peuvent être dans le réseau Internet (« Cloud »).

Selon encore une autre variante, seul le modèle d'installation est fourni lors de cette étape, le modèle d'activation restant à fournir ultérieurement suite à une requête d'activation. Le dispositif GHM (module CORE) reçoit lors de l'étape E11 deux fichiers modèles, chacun correspondant aux deux ensembles d'informations suivants : 1. Le plan de déploiement du service (resp. un plan d'installation - PdI ou un plan d'Activation - PdA) : Le but de ce document est de fournir, pour chaque terminal du réseau qui peut être concerné, une méthode d'installation (resp. d'activation) des composantes logicielles nécessaires au fonctionnement du service. Notamment, il précise quelles sont les actions à enchaîner pour installer (resp. activer) le service sur chaque type de terminal (PC sous Windows 7, tablette sous Android, etc.). 2. L'ensemble des SLA. Un SLA (de l'anglais Service Level Agreement, en français « accord de niveau de service ») correspond de manière générale à un contrat entre un fournisseur de services et un utilisateur. Un SLA indique un certain niveau de prestations de services : niveau de performance garanti, temps d'arrêt ou de disponibilité du service, etc. Dans le contexte de ce mode de réalisation de l'invention, le SLA comporte notamment, pour chaque terminal concerné, la liste des contraintes (pré-requis) nécessaires pour installer (resp. ultérieurement activer) le service : par exemples, un PC sous Windows devra être présent et démarré, tel terminal devra être connecté à tel autre, l'un des terminaux visés devra comporter au minimum 20 mégaoctets (Mo) de mémoire pour pouvoir assurer le bon fonctionnement du service, etc. Ainsi, le SLA permet de faire une première analyse du réseau local (et donc des terminaux, liens réseaux et logiciels qu'il contient) avant déploiement. Des exemples de tels ensembles sont fournis en Annexe 1 au format XML. Les ensembles « plan de déploiement » (ici, plan d'installation PdI) et « SLA » (ici, SLA d'installation SLAI) sont regroupés dans le document modèle (repérable par la première balise : <dep/oymentP/anAndS/a>). Naturellement, il est tout à fait envisageable, et facilement à la portée de l'homme du métier, de traiter ces ensembles selon des fichiers distincts (par exemple, un premier fichier pour le plan de déploiement, puis un fichier pour le SLA) dans un format différent. Pour la compréhension de l'invention, des commentaires ont été ajoutés en italique après les signes « // ».

Le plan de déploiement (balise « <serviceInstallationPlan> » pour une installation, resp. balise « <serviceActivationPlan> » pour une activation, etc.) prévoit l'installation du logiciel « PartageDePhotos » pour un PC sous système d'exploitation Windows 7. Il fournit notamment l'adresse URL (http://orangeServer/pdpWin7exe) à laquelle le LHM présent sur le PC doit se connecter pour obtenir le composant logiciel nécessaire au déploiement du service, à savoir la composante logicielle de partage de photographies (PHOP). L'ensemble des SLA (balise « installationTSlaTemplate » pour une installation, balise « <activationTSlaTemplate> » pour une activation, etc.) prévoit plusieurs modules Service Level Objective (SLO), chaque module étant repérable par la balise ouvrante « <serviceLevelObjective_DTO_list> ». Deux modules SLO sont détaillés pour la compréhension de l'invention : il s'agit d'un premier module relatif à la connexion du terminal à la passerelle (repérable par l'identifiant #sLO_id_6#) et d'un second module relatif à l'espace de stockage nécessaire sur les terminaux (repéré pour le premier terminal par l'identifiant #sLO_id_11#). Notamment, l'opérateur « MoreOrEqual » indique ici qu'il faut un minimum de 20 mégaoctets d'espace disponible sur un terminal de type computer Win7pour la composante logicielle. Naturellement, ces entités sont données à titre d'exemple. De nombreux autres modules SLO pouvant être insérés dans le modèle, en fonction des contraintes du service : SLO sur la capacité minimale de la bande passante pour chaque connexion (bande passante entre la passerelle et le terminal), SLO sur la présence d'un décodeur numérique pour la lecture des fichiers images correspondant à un certain format (par exemple, format d'extension « .raw »), SLO sur le statut du terminal (présence ou absence du terminal dans le réseau local), etc. Parallèlement à l'acquisition des modèles, le module CORE du GHM de la passerelle procède lors d'une étape E12 à l'acquisition d'informations sur le réseau local et ses terminaux, via le module IMI d'infrastructure de monitoring en charge de la collecte de ces informations auprès du réseau local. Dans ce mode de réalisation, les équipements de la maison sont découverts et connus de l'IMI. Par exemple, dans le contexte de l'exemple, le module GHM « sait » que le réseau local dispose d'un ordinateur de type PC qui fonctionne sous Windows 7 (le PC de l'utilisateur 10). En variante, on pourra cependant imaginer que le GHM a détecté, via le module IMI, au moins deux terminaux dans le réseau local susceptibles de répondre aux contraintes (deux PC sous Windows 7). Un dialogue pourra alors s'engager avec l'utilisateur au cours d'une étape (facultative) E13 pour poser des questions à l'utilisateur dans le but de départager les deux terminaux éligibles. Après avoir reçu les modèles, le module CORE du GHM de la passerelle se charge, lors d'une étape E14 de faire instancier le modèle d'installation par le module TI d'instanciation, c'est-à-dire de donner une valeur effective aux champs du modèle pour un terminal ou un groupement de terminaux du réseau local. Des fichiers XML résultants peuvent par exemple prendre la forme proposée en annexe 2 (les champs en gras ont été instanciés). Notamment, pour la partie « plan de déploiement » le GHM se procure l'identifiant du réseau local (« EndUserLanId » est remplacé ici par la référence « 33 » du réseau local), remplace les valeurs des balises <deviceId> par les identifiants des terminaux dans le réseau local tels que connus via le module IMI (par exemple, <deviceId>PC14</deviceId> pour le PC sous Windows 7 de l'utilisateur 10) et cela pour chaque terminal impliqué. Cela permet de définir quelles actions sont à effectuer sur quels terminaux du réseau local lors du déploiement du service.

Pour ce qui concerne la seconde partie de l'instanciation (SLA), il s'agit de définir les pré-requis effectifs au niveau du réseau local (terminaux, liens réseaux et logiciels, etc) pour le service à déployer. Dans l'exemple, le terminal repéré par son identifiant PC14 doit posséder au moins 20 Mo de mémoire pour que l'application puisse s'installer correctement.

Après instanciation du modèle d'installation, aboutissant aux deux fichiers schématisés dans la figure 3 sous l'appellation de PdI_inst (pour « Plan d'Installation instancié ») et SLAI_inst (pour « SLA d'Installation instancié »), les informations du réseau local sont vérifiées par rapport aux contraintes exprimées dans les SLA, lors d'une étape E15 : le module d'analyse (ANA) vérifie l'ensemble des contraintes, à partir d'une part du SLAI instancié obtenu à l'étape précédente et d'autre part des informations de surveillance et d'inventaire qui ont été récupérées par le module IMI à l'étape E12. Par exemple, ANA vérifie que le PC sous Windows 7 du SLAi instancié (d'identifiant PC14) est connecté, qu'il dispose des capacités de bande passante correctes, qu'il a bien un décodeur installé pour le décodage des images au format « .raw », etc. Puis le module ANA fournit au module CORE du GHM les résultats de la demande d'analyse. Si le résultat de cette analyse est favorable, le module CORE se met en relation avec le module d'exécution DPE du GHM. Le module DPE demande au module LHM du terminal, au cours d'une étape E16, d'exécuter une étape du plan d'installation, par exemple télécharger et installer une composante logicielle pour le partage des photos (PHOP) sur le PC et un module de visualisation (PHOV) des images sur la tablette, etc.

Si au contraire le résultat de cette analyse est défavorable, on peut envisager par exemple un arrêt du déploiement et l'information de l'utilisateur. Le module LHM du terminal concerné reçoit la demande du module GHM de la passerelle lors d'une étape E3 et télécharge lors d'une étape E4 une composante logicielle (PHOP, PHOV) du service (e.g. http://orangeServer/pdpWin7.exe) depuis le serveur de l'opérateur. Il faut noter que, selon une variante, le programme nécessaire à l'exécution du service peut se trouver déjà installé sur le terminal, rendant cette étape facultative. Puis le module LHM exécute l'installation du programme téléchargé et transmet, lors d'une étape E5, le résultat de l'opération qu'il vient d'effectuer au module CORE du GHM de la passerelle. Les étapes E3-E5 (sur le module LHM du terminal) et E16-E17 (sur le module GHM de la passerelle) peuvent être effectuées autant qu'il est nécessaire pour exécuter toutes les actions prévues dans le plan d'installation (téléchargement et installation d'une composante logicielle, ouverture d'une connexion réseau, etc.) Enfin, lors d'une étape E18, le module GHM de la passerelle domestique peut, via son module IMI, remettre à jour les données concernant le réseau local, par exemple un inventaire qui tient compte des logiciels installés sur les différents terminaux.

La figure 4 schématise la manière dont la passerelle résidentielle réalise une activation d'un service lors d'une phase ultérieure à celle de l'installation. La figure 4 est très proche de la figure 3. Les étapes communes ne seront donc pas détaillées. Le contexte de l'exemple est toujours le suivant : l'utilisateur (10) veut maintenant activer le service de gestion de photos (PHO) pour pouvoir échanger et visualiser les photos qui se trouvent sur les terminaux présents dans sa maison, notamment son PC, sa tablette, son TV/STB, et son NAS. L'utilisateur (10) émet une première requête ACT(PHO) vers la passerelle (6) pour l'activation du service PHO, reçue par le module CORE du GHM de la passerelle lors d'une étape E'10. On suppose que le module CORE dispose du modèle qu'il a typiquement reçu lors d'un déploiement préalable du service (voir la figure 3). On suppose notamment dans ce mode de réalisation que le plan d'activation du service ainsi que la partie SLA correspondant à l'activation ont été récupérées lors d'une phase initiale en même temps que les documents correspondants relatifs à 1"installation du service. Il n'a donc pas besoin de les requérir à l'extérieur. Le fichier modèle comporte un plan d'activation du service (PdA) dont le contenu est similaire à celui du plan d'installation (PdI) de la figure précédente, mis à part la balise <serviceInstallationPlan> qui devient ici <serviceActivationPlan > et la balise <basicActionName>ACTIVE</basicActionName> qui indique une activation. De manière similaire, pour ce qui concerne la partie SLA, la structure est très similaire à <installationTSlaTemplate> (qui devient ici <activationTSlaTemplate>), mais des informations complémentaires sont proposées à l'analyse : quantité de mémoire vive libre, de CPU libre et de stockage libre sur chaque terminal visé au moment de l'activation, présence des connexions réseaux et de leur capacité disponible, etc.

Le module CORE du GHM de la passerelle procède lors d'une étape E'12 à l'acquisition des paramètres du réseau local et de ses terminaux, via le module IMI d'infrastructure de monitoring en charge de la collecte de ces informations auprès du réseau local.

Le module CORE du GHM de la passerelle se charge, lors d'une étape E'14 de faire instancier le plan d'activation (PdA) et le SLA d'activation (SLAA) par le module TI d'instanciation, c'est-à-dire de donner une valeur effective aux champs du modèle pour un terminal ou un groupement de terminaux du réseau local. L'instanciation du modèle d'activation, lors de l'activation du service, est similaire à celle du modèle d'installation. Après instanciation du modèle, aboutissant aux deux fichiers schématisés dans la figure 4 sous l'appellation de PdA_inst (pour « Plan d'Activation instancié ») et SLAA_inst (pour « SLA d'Activation instancié»), les informations du réseau local sont vérifiées par rapport aux pré-requis exprimées dans le SLAA, lors d'une étape E'15 : le module d'analyse (ANA) vérifie l'ensemble des pré-requis, à partir d'une part du SLAA instancié obtenu à l'étape précédente et d'autre part des informations de surveillance et d'inventaire IMI qui ont été obtenues à l'étape E'12. Par exemple, conformément à l'un des SLO, on peut vérifier que l'un des équipements a au moins 20 Mégaoctets disponibles.

Si le résultat de cette analyse est acceptable, le module CORE se met en relation avec le module d'exécution DPE du GHM. Le module DPE demande au module LHM du terminal, au cours d'une étape E'16, d'exécuter une étape du plan d'activation, par exemple, activer la composante logicielle de visualisation (PHOV) des images sur la tablette.

Le module LHM du terminal concerné reçoit la demande du module GHM de la passerelle lors d'une étape E'3. Il active la composante logicielle sélectionnée et transmet, lors d'une étape E'5, le résultat de l'opération qu'il vient d'effectuer au module CORE du GHM de la passerelle. Les étapes E'3-E'5 (sur le LHM du terminal) et E'16-E'17 (sur le GHM de la passerelle) peuvent être effectuées autant qu'il est nécessaire pour exécuter toutes les actions prévues dans le plan d'activation.

On notera que des 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.

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.

Annexe 1 <deploymentPlanAndSla> //TEMPLATE <serviceInstallationPlan> //Première partie PdI <deployableUserServiceId>PartageDePhotos</deployableUserServiceId> //PHO <description>Template d'install du logiciel de partage photos </description> <lanId>EndUserLanId</landId> <steps >//install du logiciel pour les terminaux sous Windows? <basicActionName>INSTALL</basicActionName> <deviceId>DeviceId0fComputerWin7</deviceId> <parameters> <deploymentUnitUrl> //@ du programme executable pour module PHOP http://orangeServer/pdpWin7.exe</deploymentUnitUrl > <version>1.0.0</version> <id>PDPWin7</id> <deploymentUnitOption>/passive,/norestart</deploymentUnitOption> </parameters> <timeOutlnMilliSeconds>60000</timeOutlnMilliSeconds> </steps> <steps> //install du logiciel pour devices de type Tablette, etc. </steps> </servicelnstallationPlan> <installationTSIaTemplate> //Deuxième partie SLAI <temporalizedSlaIdentifier>tsla_id_dh_1</temporalizedSlaIdentifier> <beginingDate>2012-12-24T11:22:11.686+01:00</beginingDate> <endingDate>2019-12-30T13:46:11.686+01:00</endingDate> <formula>(#sLO_id_1#)8«...)&&(#sLO_id_6#)8«...)&8(#sLO_id_11#)8«...) </formula> <temporality>1</temporality> <serviceLevelObjective_DTO_Iist> //Connexion du der équipement. <SLO_id>#sLO_id_6#</SLO_id> <SLO_attribut>ComputerWin7_related_data_connected_to_box</SLO_attribut <serviceLevelObjectiveDescription>sLO_desc_6</serviceLevelObjectiveDescrip tion> <operator> EqualTo</operator> <threshold>true</threshold> <thresholdType>java.lang.Boolean</thresholdType> </serviceLevelObjective_DTO _list> <serviceLevelObjective_DTO_Iist> //Connexion des autres équipements <serviceLevelObjective_DTO_Iist> //Espace de stockage du der équipement. <SLO_id>#sLO_id_11#</SLO_id> <operator> MoreOrEqualTo</operator> <SLO_attribut>ComputerWin7_related_data_available_storage_in_megaoctet s</SLO_attribut> <serviceLevelObjectiveDescription>sLO_desc_11</serviceLevelObjectiveDescri ption> <threshold>20</threshold> <thresholdType>java.lang.Integer</thresholdType> </serviceLevelObjective_DTO _list> <serviceLevelObjective_DTO_Iist> //Idem pour l'Espace de stockage disponible des autres équipements. </serviceLevelObjective_DTO _list> </installationTSlaTemplate> </deolovmentPlanAndSla> Annexe 2 <deploymentPlanAndSla> //TEMPLATE instancié pour le LAN de l'utilisateur <serviceInstallationPlan> //partie PdI instanciée <deployableUserServiceId>PartageDePhotos</deployableUserServiceId> <description>Template d'install du logiciel de partage de photos</description> <lanId>33</landId> <steps> <basicActionName>INSTALL</basicActionName> <deviceId> PC14</deviceld> <parameters> <deploymentUnitUrl>http://orangeServer/pdpWin7.exe</deploymentUnitUrl <version>1.0.0</version> <id>PDPWin7</id> <deploymentUnitOption>/passive,/norestart</deploymentUnitOption> </parameters> <timeOutlnMilliSeconds>60000</timeOutlnMilliSeconds> </steps> <steps> //Même "partie" steps pour les unités de déploiement pour la Tablette Smartphone, la STB et le NAS. </steps> </servicelnstallationPlan> <installationTSIaTemplate>//partieSLA instanciée pour les éq. de l'utilisateur <temporalizedSlaIdentifier>tsla_id_dh_1</temporalizedSlaIdentifier> <beginingDate>2011-12-24T11:22:11.686+01:00</beginingDate> <endingDate>2019-12-30T13:46:11.686+01:00</endingDate> <formula>(#sLO_id_1#)8«...)&8(#sLO_id_6#)8«...)8e(#sLO_id_11#)8«... )</formula> <temporality>1</temporality> <serviceLevelObjective_DTO _list> //premier SLO <SLO_id>#sLO_id_11#</SLO_id> <operator>MoreOrEqualTo</operator> <SLO_attribut>PC14_related_data_available_storage_in_megaoctets </SLO_attribut> <serviceLevelObjectiveDescription>sLO_desc_11</serviceLevelObjectiveDesc ription> <threshold>20</threshold> <thresholdType>java.lang.Integer</thresholdType> </serviceLevelObjective_DTO_I ist> <serviceLevelObjective_DTO_list> //autres SLO pour l'Espace de stockage disponible des autres équipements. </serviceLevelObjective_DTO_Iist> </installationTSIaTemplate> </deploymentPlanAndSla>

Claims (9)

1. REVENDICATIONS1. Procédé de gestion du déploiement d'un service (PHO) dans un réseau local (1), ledit service requérant de la part d'au moins un terminal (2,3,4,5) du réseau local (1) une capacité matérielle et/ou logicielle, ledit procédé étant caractérisé en ce qu'il comporte les étapes de : réception (E10) d'une requête (INST, ACT) relative au service (PHO) en provenance d'un terminal (2-5) ; acquisition (E12) d'au moins une information liée à la capacité (Win7, available storage) d'au moins un terminal (2-5) du réseau local ; vérification (E15) d'au moins une information acquise ( Win7, available storage)en fonction de la capacité requise (SLAI, SLAA) ; action (INST, ACT, PHOV, PHOP) sur au moins un terminal (2-5) pour déployer le service (PHO).
2. 2. Procédé de gestion du déploiement d'un service (PHO) selon la revendication 1, caractérisé en ce que la requête est une requête d'installation (INST) du service et l'action sur le terminal une action d'installation d'une composante logicielle (PHOV, PHOP) appartenant au service (PHO).
3. 3. Procédé de gestion du déploiement d'un service (PHO) selon la revendication 1, caractérisé en ce que la requête est une requête d'activation (ACT) du service et l'action sur le terminal une action d'activation (ACT) d'une composante logicielle (PHOV, PHOP) ou matérielle appartenant au service (PHO).
4. 4. Procédé de gestion de la mise en oeuvre d'un service (PHO) selon la revendication 1, caractérisé en ce qu'il comporte en outre les étapes de : - acquisition d'un modèle (E11, template, PdI, PdA, SLAI, SLAA) pour la mise en oeuvre du service (PHO) demandé ; - instanciation (E14,) du modèle acquis pour obtenir un modèle instancié (PdI_inst, PdA_inst, SLAI_inst, SLAA_inst).
5. 5. Procédé selon la revendication 4, caractérisé en ce que le modèle comporte un plan de déploiement du service ("serviceInstallationPlan", PdI, PdA)
6. 6. Procédé selon la revendication 4, caractérisé en ce que le modèle comporte un ensemble de contraintes (SLAI, SLAA, « espace de stockage »).
7. 7. Dispositif de gestion (GHM) du déploiement d'un service (PHO) dans un réseau local (1), ledit service requérant de la part d'au moins un terminal (2,3,4,5) du réseau local (1) une capacité matérielle et/ou logicielle, ledit dispositif de gestion (GHM) étant caractérisé en ce qu'il comporte : - un module de réception d'une requête (INST, ACT) relative au service (PHO) en provenance d'au moins un terminal (2-5) ; un module d'acquisition d'au moins une information liée à la capacité Win7, available storage) d'au moins un terminal du réseau local ; un module de vérification de l'information acquise en fonction de la capacité requise (SLAI, SLAA) ; un module d'action sur au moins un terminal (2-5) pour déployer le service (PHO).
8. 8. Passerelle domestique caractérisée en ce qu'elle comprend un dispositif tel que défini dans la revendication 7.
9. 9. Programme d'ordinateur apte à être mis en oeuvre sur un dispositif (GHM) tel que défini dans la revendication 7, 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.