FR2813483A1

FR2813483A1 - Procede, dispositif et systeme d'allocation d'une ressource dans un environnement numerique multimedia

Info

Publication number: FR2813483A1
Application number: FR0010921A
Authority: FR
Inventors: Stephane Morcel
Original assignee: Thomson Multimedia SA
Current assignee: Technicolor SA
Priority date: 2000-08-25
Filing date: 2000-08-25
Publication date: 2002-03-01
Anticipated expiration: 2020-08-25
Also published as: FR2813483B1

Abstract

L'invention concerne notamment un procédé d'allocation d'une ressource (105 à 107, 111, 112) à au moins une application qui communiquent entre elles à travers une interface numérique multimédia contrôlée par un hôte (100). Il comprend une étape de demande d'ouverture (802, 900, 803, 901) d'au moins une session auprès de la ressource (105 à 107, 111, 112) et une étape de réponse (804, 805, 902, 903) de ladite ressource autorisant ou refusant l'ouverture de ladite session. L'autorisation ou le refus d'ouverture de la session (1117) tient compte d'un niveau de priorité (603, 703) affecté à la demande d'ouverture de session par l'application.

Description

<Desc/Clms Page number 1>
Le domaine de l'invention est celui des systèmes numériques multimédia. Plus précisément, l'invention concerne la communication entre les différents composants de tels systèmes multimédia.

Classiquement, ces systèmes comprennent d'une part des appareils (décodeurs numérique, téléviseurs, magnétoscopes,...) et d'autre part des modules applicatifs capables d'échanger des données avec au moins certains des appareils. En particulier, les décodeurs numériques multimédia (en anglais set top box ) sont avantageusement conçus pour recevoir et décoder plusieurs signaux et/ou services d'origines diverses. II suffit d'équiper le décodeur du module correspondant (en général moyennant paiement) pour obtenir le service voulu. Ces modules peuvent, par exemple, se présenter sous la forme d'une carte à microprocesseur, ou d'un boîtier à rapporter à l'arrière du décodeur.

Les modules applicatifs et les appareils multimédia étant d'origines diverses et variées, il a été nécessaire de définir des règles communes pour échanger des données. Ainsi, des interfaces communes, notamment DVB- CI, NRSS B et Open Cable, ont été définies par des groupements de vidéo numérique pour permettre une standardisation des équipements de réception numérique tout en permettant aux prestataires de services fournissant les données (par exemple, des fournisseurs de programmes télévisés payants) de rester propriétaires du système d'accès conditionnel et des éléments de sécurité correspondants. En effet, un système d'accès conditionnel doit être prévu à chaque fois qu'il est nécessaire de contrôler l'accès à des données diffusées. Mais, les prestataires de services fournissant les données veulent conserver un système d'accès conditionnel spécifique.

Grâce à ces interfaces, les éléments propriétaires spécifiques peuvent être intégrés dans un module séparé des parties normalisées du terminal qui reçoivent et décodent les données vidéo numériques ou les données de services. Ainsi, les éléments propriétaires peuvent être fabriqués et vendus séparément des terminaux, ce qui facilite leur distribution.

L'invention s'applique en particulier dans le contexte de l'interface dite DVB-CI (de l'anglais Digital Video Broadcasting - Common Interface signifiant littéralement Diffusion Vidéo Numérique - Interface commune ) qui est notamment décrite dans la norme européenne EN 50221 publiée par le CENELEC (Comité Européen de Normalisation Electrotechnique).

Plus généralement, elle peut s'appliquer à la plupart des normes d'interface vidéo numérique notamment NRSS B et Open Cable.

Les modules sont appelés par extension module DVB-CI , module NRSS B et module Open Cable en référence aux normes correspondantes.

La norme européenne DVB-CI, publiée en février 1997 par le CENELEC sur Common Interface Specification for Conditional Access and other Digital Video Broadcasfing Set Top Box Applications (signifiant littéralement spécification d'interface commune pour les accès conditionnels et autres applications de décodeurs numériques multimédia pour la diffusion de vidéo numériques ), la norme NRSS (ou National Renewable Security Standards ) publiée par Electronic Industries Association dans le document NRSS :National Renewable Security Standards sous la référence DVS064 Part B et la norme Opencable publiée par Society of Cable Communications Engineers, Inc. dans le document Opencable : Point of deployement (POD) Module Interface , sous la référence SCTE DVS13 décrivent notamment une interface commune relative au codage de source, au codage de canal, aux informations de service, aux interfaces STU (de l'anglais u Set Top Unit signifiant unité de décodeur multimédia ) et aux accès conditionnels.

Selon les normes DVB-CI, Open Cable et NRSS une application implantée dans un module communiquant avec un hôte fournit des services à un utilisateur en sus de ceux offerts directement par un hôte. L'hôte est ici un terminal multimédia tel qu'un ordinateur personnel ou PC, un magnétoscope, un lecteur/enregistreur de disques optiques, un VCR (magnétoscope à cassette de l'anglais Video Cassette Recorder ) ou un IRD (Décodeur-récepteur intégré de l'anglais Integrated Receiver Decoder ) Un module est généralement un composant de petite taille nécessitant l'utilisation conjointe d'un hôte pour exécuter des tâches spécifiques telles qu'un accès conditionnel à un sous-système, un module d'application de type guide de programme électronique ou la fourniture d'éléments nécessaires à une application mais qui ne sont pas fournies par l'hôte.

Une ressource est une unité de fonctionnalités fournies par un hôte ou un module pour être utilisée par une application, elle même implantée dans

un hôte ou un module. L'application utilise la ressource (écran, clavier, télécommande, microprocesseur, mémoire...) en échangeant avec la ressource un ensemble d'objets tels que des messages de contrôle ou de données.

Chacune des normes DVB-CI, Open Cable et NRSS permet un accès aux décodeurs par les diffuseurs avec une liberté de choix du système d'accès conditionnel en définissant une interface normalisée entre un hôte et un module ou entre une ressource et une application implantant un accès conditionnel et plus généralement des fonctions propriétaires. Ainsi, les diffuseurs peuvent utiliser des modules contenant des solutions provenant de différents fournisseurs dans le même système de diffusion, augmentant par là même leurs choix et options d'a nti-piratages.

Les normes DVB-CI, Open Cable et NRSS poursuivant des buts similaires avec des moyens similaires, par souci de clarté nous allons maintenant décrire plus particulièrement certains aspects de la norme DVB- CI, ces aspects étant transposables directement aux normes Open Cable et NRSS et plus généralement à la plupart des normes relatives aux interfaces numériques mulimédia.

L'interface commune DVB-CI entre un hôte et un module est constituée de deux interfaces logiques - l'interface de flux de transport (noté TS de l'anglais Transport Stream ) qui transmet les paquets de transport MPEG2 dans deux directions sur un bus bidirectionnel. Si l'interface DVB-CI donne accès à n'importe quel service dans le TS et si ces services ont été sélectionnés par l'hôte, les paquets TS décodés transmettant ces services seront retournés alors que les autres paquets ne seront pas modifiés.

- L'interface de commande qui transmet les commandes entre l'hôte et le module. Le protocole de communication sur cette interface est défini selon plusieurs couches fournissant les fonctions nécessaires. Ces fonctions comprennent notamment la faculté de supporter plusieurs modules dans l'hôte, la faculté de supporter des combinaisons complexes entre un module et un hôte et un ensemble extensible de fonctions primitives (appelées aussi objets) qui autorise l'hôte à fournir des ressources au module.

Les applications situées dans des modules détachables peuvent utiliser des ressources de l'hôte ou présentes dans d'autres modules connectés à l'hôte. Pour communiquer avec les ressources, les applications ouvrent des sessions vers ces ressources. Une application ouvre une session en envoyant une requête d'ouverture de session vers cette ressource. La ressource répond en acceptant ou refusant l'ouverture de session. Via ces sessions, les applications peuvent envoyer des objets pour utiliser les ressources.

Chaque ressource accepte ou rejette une requête d'ouverture de session en provenance d'une application en fonction du nombre de sessions qu'elle peut supporter. Lorsque qu'un nombre maximal de sessions est atteint, la ressource rejette systématiquement les nouvelles requêtes d'ouverture de sessions. Un inconvénient notable de cette méthode est qu'elle conduit à une mauvaise gestion des sessions. Une autre méthode qui consisterait à fermer systématiquement une session déjà ouverte au profit de nouvelles sessions ne serait pas meilleure.

Un autre inconvénient est le manque de flexibilité pour l'ouverture des sessions dans le cadre des interfaces numériques multimédia. Lorsqu'une application a besoin d'ouvrir une session pour l'envoi d'objets vitaux pour la ressource, une requête d'ouverture de session peut être rejetée parce que le nombre maximum de sessions ouvertes est atteint, même si une session déjà ouverte est moins importante. Ainsi, par exemple une ressource de type affichage sur un écran de télévision, appelée souvent OSD (de l'anglais On Screen Display signifiant littéralement affichage à l'écran ), peut être monopolisée par l'affichage de messages d'informations peu importantes alors qu'une requête d'ouverture d'une session pour l'affichage d'un message d'alarme serait rejetée.

L'invention selon ses différents aspects a notamment pour objectif de pallier ces inconvénients de l'art antérieur.

Plus précisément, un objectif de l'invention est de fournir un système et un procédé de gestion des sessions dans un environnement de télévision numérique qui optimise l'ouverture des sessions d'une manière flexible et peu coûteuse à mettre en oeuvre.

L'invention a notamment pour objectif l'optimisation de la gestion des sessions dans un environnement de télévision numérique en fonction de leur importance.

Un autre objectif de l'invention est de permettre une telle gestion compatible avec les normes existantes d'interfaces pour la télévision numérique.

Dans ce but, l'invention propose un procédé d'allocation d'une ressource à au moins une application ladite ressource et ladite application communiquant entre elles à travers une interface numérique multimédia contrôlée par un hôte, comprenant une étape de demande d'ouverture d'au moins une session auprès de ladite ressource et une étape de réponse de ladite ressource autorisant ou refusant l'ouverture de ladite session, remarquable en ce que l'autorisation ou le refus d'ouverture de la session tient compte d'un niveau de priorité affecté à la demande d'ouverture de session par l'application.

Ainsi, l'invention permet de prendre en compte un niveau de priorité pour chaque session dans un environnement numérique multimédia contrôlé par un hôte. Les sessions les plus prioritaires sont ouvertes au dépend des moins prioritaires, durant les demandes d'ouvertures de session qui correspondent à des requêtes d'ouvertures et/ou de création de session. Ainsi, on d'optimise l'utilisation des ressources.

Selon une caractéristique particulière, le procédé d'allocation d'une ressource est remarquable en ce que le niveau de priorité est transmis à la ressource dans le corps de ladite demande d'ouverture d'au moins une session.

Ainsi, de façon avantageuse, l'application qui émet une demande d'ouverture maîtrise le niveau de priorité de la session dont elle requiert l'ouverture et ce niveau de priorité est pris en compte dès la réception des messages d'ouverture et/ou de création de session.

Selon une caractéristique particulière, le procédé d'allocation d'une ressource est remarquable en ce que l'interface numérique multimédia permet l'échange d'objets informatiques, comprenant au moins un champ et en ce qu'un objet ayant pour but l'ouverture d'une session comprend un champ codant le niveau de priorité.

Selon une caractéristique particulière, le procédé d'allocation d'une ressource est remarquable en ce que les objets comprennent des objets de requête d'ouverture de session et/ou des objets de création de session.

Ainsi, dans un mode de réalisation avantageux de l'invention, le codage du niveau de priorité et sa prise en compte se font de manière particulièrement simple à mettre en couvre dans un dispositif électronique et/ou informatique.

Selon une caractéristique particulière, le procédé d'allocation d'une ressource est remarquable en ce que ladite interface numérique multimédia est de type DVB-CI ou NRSS ou Open Cable.

Selon une caractéristique particulière, le procédé d'allocation d'une ressource est remarquable en ce qu'il comprend une opération de gestion de requête d'ouverture de session comprenant les étapes - de comparaison du niveau de priorité de ladite session à ouvrir au niveau de priorité d'au moins une éventuelle session ouverte.

- s'il existe une session ouverte de moindre priorité que la session à ouvrir, de fermeture d'au moins une session ouverte de moindre priorité que la session à ouvrir et d'ouverture de la session à ouvrir, - sinon, de refus de la demande d'ouverture de la session à ouvrir.

Ainsi, en cas notamment de saturation du nombre de sessions ouvertes dans une ressource, le procédé permet de remplacer aisément une session de priorité donnée par une session de priorité plus forte.

II est à noter qu'une session de moindre priorité peut s'entendre au sens strict (c'est-à-dire de priorité strictement inférieure) ou non (c'est-à-dire de priorité inférieure ou égale).

Selon une caractéristique particulière, le procédé d'allocation d'une ressource est remarquable en ce que les étapes de fermeture et de refus et éventuellement de comparaison ne sont mises en couvre que s'il y a saturation du nombre de sessions dans ladite ressource.

Ainsi, la fermeture de sessions ou le refus d'ouverture d'une nouvelle session ne sont avantageusement mise en oeuvre que s'il y a une saturation effective du nombre de sessions dans la dite ressource. La comparaison des priorités est avantageusement facultative quand il n'y a pas saturation. En pratique, les opérations de test de saturation ou de priorité peuvent

avantageusement être mises en oeuvre dans un ordre particulier ou simultanément.

L'invention propose également dans les mêmes buts que précédemment un composant multimédia numérique capable de communiquer via une interface numérique multimédia avec au moins une ressource et d'émettre une demande d'ouverture d'au moins une session, et d'allocation d'une ressource correspondante, à l'une des au moins une ressource remarquable en ce qu'il comprend des moyens d'affectation d'un niveau de priorité à chacune des demandes d'ouverture.

Ainsi, de façon avantageuse, un composant notamment une application, un module comprenant une application ou un hôte comprenant une application ou reliant une application et une ressource peut avantageusement attribuer un niveau de priorité à une demande d'ouverture de session.

L'invention propose également dans les mêmes buts que précédemment un appareil multimédia numérique capable de communiquer via une interface numérique multimédia contrôlée par un hôte avec au moins une application et d'autoriser ou de refuser l'ouverture d'une session, et l'allocation d'une ressource correspondante, en réponse à une demande émise par l'une des au moins une application remarquable en ce qu'il comprend des moyens de gestion des demandes d'ouverture tenant compte d'un niveau de priorité affecté aux demandes d'ouverture.

Les caractéristiques particulières et les avantages des appareils d'allocation d'une ressource étant les mêmes que ceux des procédés d'allocation d'une ressource, ils ne sont pas rappelés ici.

On note que, généralement, l'hôte est l'appareil multimedia lui-même. Selon une caractéristique particulière, l'appareil multimédia numérique est remarquable en ce qu'il appartient au groupe comprenant les téléviseurs, les magnétoscopes, les décodeurs numériques multimédia, les décodeurs- récepteurs intégrés (IRD), les micro-ordinateurs, les lecteurs enregistreurs de disques optiques.

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 système comportant un décodeur numérique multimédia et des modules séparés conformes à l'invention selon un mode particulier de réalisation; - les figures 2A â 2D présentent plusieurs cas de session entre une application et une ressource, conformes à l'invention selon des modes particuliers de réalisation ; - la figure 3 présente un décodeur numérique multimédia, conforme à l'invention selon un mode particulier de réalisation ; - la figure 4 présente un module conforme à l'invention selon un mode particulier de réalisation ; - la figure 5 présente un protocole en couche, conforme à l'invention selon un mode particulier de réalisation ; - la figure 6 présente un message de requête d'ouverture de session, conforme à l'invention selon un mode particulier de réalisation ; - la figure 7 présente un message de requête de création de session, conforme à l'invention selon un mode particulier de réalisation ; - la figure 8 présente un protocole de communication avec ouverture et fermeture de session simples, conforme à l'invention selon un mode particulier de réalisation ; - la figure 9 présente un protocole de communication avec ouverture de session nécessitant la fermeture d'une session moins prioritaire, conforme à l'invention selon un mode particulier de réalisation ; - la figure 10 présente un organigramme de gestion des sessions par une application, conforme à l'invention selon un mode particulier de réalisation ; - la figure 11 présente un organigramme de gestion des sessions par une ressource, conforme à l'invention selon un mode particulier de réalisation.

Le principe général de l'invention repose sur l'association à chaque session d'un niveau de priorité. On considère, par exemple, le cas où un décodeur numérique multimédia est connecté via une interface DVB-CI à des modules d'application. L'ensemble comprenant le décodeur numérique multimédia et les modules d'application constitue un système. Chacun des

éléments de ce système peut posséder en propre des ressources et des applications. Chacune des applications peut requérir l'ouverture d'une session pour utiliser une ressource du système.

Le décodeur numérique multimédia joue le rôle de l'hôte, c'est-à-dire qu'il va gérer les sessions DVB-CI. En tant qu'hôte, il possède une ressource particulière : le gestionnaire de ressource (en anglais ressource manager ). Au démarrage du système, toutes les applications et toutes les ressources vont se déclarer auprès du gestionnaire de ressource selon des procédures propres à l'interface DVB-CI. Ainsi, le gestionnaire de ressource présent dans l'hôte connaît toutes les ressources et les applications du système. En outre, le gestionnaire de ressource donne la liste des ressources aux applications et c'est lui qui gère l'ouverture et la fermeture des sessions.

Chacune des ressources peut supporter un nombre maximal de sessions N Sess Max(Res) qui dépend de la ressource et maintient une liste de sessions ouvertes, List Sess(Res) avec un niveau de priorité associé à chacune des sessions ouvertes. Pour une ressource particulière, N Sess Max(Res) est généralement compris entre 1 et 16. Néanmoins, la valeur 16 n'est nullement limitative et N Sess Max(Res) peut aussi être supérieur à 16.

Au démarrage du système, après la déclaration des ressources, une session est toujours ouverte entre le gestionnaire de ressources et chacune des autres ressources du système.

Selon l'invention, chacune des sessions possède un numéro de priorité. Ce numéro de priorité est généralement codé sur huit bits ou éléments binaires et a ainsi une valeur comprise entre 1 et 256 ; par convention, le niveau de priorité étant d'autant plus fort que la valeur le représentant est élevée; ainsi,1 indique la plus faible priorité et 256 la plus grande priorité.

La session ouverte entre le gestionnaire de ressources et chacune des autres ressources du système étant très importante, elle possède la priorité la plus grande.

On décrit ci-après un exemple de gestion de priorités.

On considère par exemple que pour une ressource Res particulière telle que la ressource OSD permettant l'affichage de caractères ou éléments graphiques sur un écran de télévision, N Sess Max(Res) est égal à deux.

On suppose que seule la session avec le gestionnaire de ressources est déjà ouverte, avec un niveau de priorité égal à 256. Suite à une demande de l'utilisateur voulant disposer du sous-titrage, une application envoie une requête d'ouverture d'une session relative à l'affichage de sous-titres au décodeur numérique multimédia via une interface DVB-CI avec une priorité par exemple égale à 5.

Le décodeur numérique multimédia relaie cette requête par une requête de création de session vers la ressource Res via une interface DVB- CI.

La ressource Res compare le nombre de sessions ouvertes, ici 1 avec le nombre maximal de sessions N Sess Max(Res) égal à 2. Le nombre maximal de sessions ouvertes n'étant pas atteint, la ressource Res répond au décodeur qu'il ouvre la session d'affichage des sous-titres avec une priorité égale à 5 et met à jour sa liste des sessions ouvertes, List Sess(Res).

Le décodeur envoie alors à l'application à l'origine de la demande une réponse indiquant que la session d'affichage des sous-titres a été ouverte. Cette application peut alors émettre vers la ressource Res, les données correspondant aux sous-titres dans le cadre de la session ouverte. On suppose qu'une application émette ensuite une requête d'ouverture d'une session d'affichage d'une information de faible importance, comme par exemple le programme du lendemain, avec une priorité égale à 2.

La ressource Res compare le nombre de sessions ouvertes, ici 2 avec le nombre maximal de sessions N Sess Max(Res) égal lui aussi à 2. Le nombre maximal de sessions ouvertes étant atteint, la ressource Res compare la priorité de la session requise avec la priorité des sessions déjà ouvertes et présentes dans la liste List Sess(Res). Les sessions ouvertes ont respectivement des priorités égales à 5 et 256 qui sont supérieures à

celle de la session requise. Le téléviseur répond donc au décodeur qu'il n'ouvre pas la session d'affichage des informations de faible importance.

Le décodeur envoie alors à l'application à l'origine de la demande une réponse indiquant que la session d'affichage des informations de faible importance n'a pas été ouverte.

On suppose maintenant qu'une application correspondant à un paiement d'émission à la carte veut informer l'utilisateur que l'émission qu'il regarde va être coupée s'il ne donne pas son accord pour provisionner un compte d'achat en affichant un message d'alerte à l'écran. Une requête d'ouverture d'une session correspondante avec une priorité égale à 20 est alors émise vers le décodeur.

Le décodeur numérique multimédia relaie cette requête par une requête d'ouverture de session vers la ressource Res via une interface DVB- cl.

La ressource Res compare le nombre de sessions ouvertes, ici 2 avec le nombre maximal de sessions N Sess Max(Res) égal lui aussi à 2. Le nombre maximal de sessions ouvertes étant atteint, le téléviseur compare la priorité de la session requise avec la priorité des sessions déjà ouvertes et présentes dans la liste List Sess(Res). Les sessions ouvertes ont respectivement des priorités égales à 5 et 256 dont l'une au moins a une priorité inférieure à celle de la session requise. La ressource Res répond donc au décodeur qu'il demande la clôture de la session de moindre importance, ici la session d'affichage des sous-titres.

Le décodeur répercute alors cette requête de clôture de session à l'application d'affichage des sous-titres qui clos effectivement la session, cesse d'émettre les données correspondant aux sous-titres et émet un message de clôture effective de la session vers le décodeur qui relaie ce message vers la ressource Res.

La ressource Res enlève de la liste des sessions ouvertes, List Sess(Res) la session d'affichage des sous-titres.

Puis, la ressource Res répond au décodeur qu'il ouvre la session d'affichage du message relatif au paiement à la carte avec une priorité égale à 20 et met à jour sa liste des sessions ouvertes, List Sess(Res).

Le décodeur envoie alors à l'application à l'origine de la demande une réponse indiquant que la session d'affichage du message relatif au paiement à la carte a été ouverte.

Cette application peut alors émettre vers la ressource Res, les données correspondant au message d'alerte dans le cadre de la session ouverte.

On présente maintenant, en relation avec la figure 1, une infrastructure d'allocation de ressource dans un environnement numérique multimédia selon l'invention.

Cette infrastructure comprend notamment - un décodeur numérique multimédia ou hôte 100 ; - un ensemble de n modules 108, 109, ..., 110 ; Le décodeur numérique multimédia 100 comprend notamment un ensemble de p ressources: Res01 105, Res02 106, Res0p 107.

Certains modules comprennent aussi une ou plusieurs ressources. Ainsi le module module 2 109 comprend une ressource Res21 111 et le module module n 110 comprend une ressource Resn1 112.

Le décodeur numérique multimédia reçoit un signal S 101, issu d'une antenne satellite ou d'un réseau câblé.

Le décodeur numérique multimédia 100 émet et reçoit des messages relatifs notamment à des requêtes d'ouverture de sessions ou des clôtures de sessions et des données relatives notamment aux sessions ouvertes ou aux applications ayant des besoins de ressources ou en utilisant. Ces messages ou données respectivement 102, 103 et 104 correspondent à des sessions relatives à l'une des ressources ou applications présentes dans l'un des modules respectivement 108, 109 et 110 et sont échangées via une interface DVB-CI.

On rappelle qu'un module est généralement un composant de petite taille nécessitant l'utilisation conjointe d'un hôte pour exécuter des tâches spécifiques telles qu'un accès conditionnel à un sous-système, un module d'application de type guide de programme électronique ou la fourniture d'éléments nécessaires à une application mais qui ne sont pas fournies par l'hôte.

Les figures 2A à 2D présentent plusieurs cas de session entre une application et une ressource.

La figure 2A illustre le cas où une application 202 est présente dans un module 200 tel un module quelconque 108, 109 ou 110 illustré en regard de la figure 1 et où une ressource 203 est présente dans un hôte 100 tel que le décodeur numérique multimédia illustré en regard de la figure 1. On note que dans ce cas, la communication entre le gestionnaire de ressources et la ressource 203 est interne à l'hôte 100.

La figure 2B illustre le cas où une application 202 est présente dans un module 200 tel un module quelconque 108, 109 ou 110 illustré en regard de la figure 1 et où une ressource 203 est présente dans un module 201 tel un module quelconque 109 ou 110 possédant une ressource illustré en regard de la figure 1. On note que dans ce cas, la session reste contrôlée (notamment dans ses phases de requêtes d'ouverture et de clôture) par le gestionnaire de ressources présent dans l'hôte 100.

La figure 2C illustre le cas où une application 202 est présente dans un hôte 100 tel que le décodeur numérique multimédia illustré en regard de la figure 1 et où une ressource 203 est présente dans un module 201 tel un module quelconque 109 ou 110 possédant une ressource illustré en regard de la figure 1. On note que dans ce cas, la communication entre le gestionnaire de ressources et l'application 202 est interne à l'hôte 100.

La figure 2D illustre le cas où une application 202 et une ressource 203 sont présentes dans un hôte 100 tel que le décodeur numérique multimédia illustré en regard de la figure 1. On note que dans ce cas, la communication entre le gestionnaire de ressources, l'application 202 et la ressource 203 est interne à l'hôte 100.

On note que la communication avec le gestionnaire de ressource et une application ou une ressource interne à l'hôte 100 se fait à travers une interface DVB-CI, au moins au niveau d'une couche session. La communication avec le gestionnaire de ressource et une application ou une ressource externe à l'hôte 100 se fait quant à elle à travers tous les niveaux d'une interface DVB-CI (physique à session).

La figure 3 illustre schématiquement un décodeur numérique multimédia 100 tel qu'il est présent dans l'infrastructure de la figure 1.

Le décodeur 100 comprend reliés entre eux par un bus d'adresses et de données 303 - un tuner/démodulateur 301 ;

- un processeur 302 ; - une interface DVB-CI 318 ; - une mémoire non volatile 304 ; - une mémoire vive 305.

Chacun des éléments illustrés en figure 3 est bien connu de l'homme du métier. Ces éléments communs ne pas décrits ici.

On observe en outre que le mot registre utilisé dans toute la description désigne dans chacune des mémoires mentionnées, aussi bien une zone de mémoire de faible capacité (quelques données binaires) qu'une zone mémoire de grande capacité (permettant de stocker un programme entier ou l'intégralité d'une séquence de données).

On note que le tuner (ou syntoniseur) 301 reçoit un signal S 101 via une interface 319 reliant le tuner 301 à une antenne satellite ou un réseau câblé et fournit en sortie un flux de données numériques transmis sous forme de paquets.

La mémoire non volatile 304 conserve dans des registres qui par commodité possèdent les mêmes noms que les données qu'il conservent notamment - un programme de fonctionnement du processeur 302 dans un registre Prog 306 ; - un ensemble de p registres N Sess Max(Res01) 307 à N Sess Max(Res0p) 308 dans lequel sont conservées les valeurs maximales de nombre de sessions que peut ouvrir chacune des ressources Res01 105 à Res0p 107 respective.

La mémoire vive 305 conserve des données, des variables et des résultats intermédiaires de traitement, dans des registres de mémoire portant dans la description, les mêmes noms que les données dont ils conservent les valeurs. La mémoire vive 305 comprend notamment - un registre Messages 309 dans lequel sont conservés les messages et les données DVB-CI échangés; - pour chacune des p ressources du décodeur 100 Res0) à Res0p, notée ResOi - une liste de sessions ouvertes List Sess(Res0i) (314, 316) incluant un numéro de priorité associé à chaque session ouverte ;

- le nombre de sessions ouvertes N Sess Open(Res0i) (315, 317).

La figure 4 illustre schématiquement un module 400 correspondant à l'un quelconque des modules 108, 109 ou 110 présents dans l'infrastructure de la figure 1.

Le module 400 comprend reliés entre eux par un bus d'adresses et de données 403 - un processeur 402 ; - une interface DVB-CI 408 ; - une mémoire non volatile 404 ; - une mémoire vive 405.

Chacun des éléments illustrés en figure 4 est bien connu de l'homme du métier. Ces éléments communs ne pas décrits ici.

On note que la mémoire non volatile 404 conserve dans des registres qui par commodité possèdent les mêmes noms que les données qu'il conservent notamment un programme de fonctionnement du processeur 402 dans un registre Prog 406.

La mémoire vive 405 conserve des données, des variables et des résultats intermédiaires de traitement, dans des registres de mémoire portant dans la description, les mêmes noms que les données dont ils conservent les valeurs. La mémoire vive 405 comprend notamment - un registre Messages 407 dans lequel sont conservés les messages et les données DVB-CI échangés entre le module 400 et le décodeur 100.

En variante (non représentée sur la figure 4), quand le module 400 possède une ou plusieurs ressources, la mémoire non volatile 404 comprend en outre pour chacune des ressources Resi du module, un registre N Sess Max(Resi) dans lequel est conservée la valeur maximale de nombre de sessions que peut ouvrir la ressource considérée. En outre, selon cette variante, la mémoire vive 405 comprend pour chacune des ressources possédée notamment - une liste de sessions ouvertes List Sess(Resi) incluant un numéro de priorité associé à chaque session ouverte ; - le nombre de sessions ouvertes N Sess Open(Resi).

Sur la figure 5, on a représenté un protocole en couche permettant à une application d'un module 510 correspondant à un module quelconque 108, 109 ou 110 tel qu'illustré en regard de la figure 1 d'accéder à une ressource offerte par un hôte 100 tel qu'illustré en regard de la figure 1.

L'application 511 présente dans le module 510 communique avec les couches session 513, transport 514, liaison 515 et physique 516 de l'interface DVB-CI à travers une API standard 512 (l'abréviation API provenant de l'anglais Application Programming Interface signifiant littéralement Interface de Programmation d'Applications).

De même, la ressource 501 présente dans l'hôte 100 communique avec les couches session 503, transport 504, liaison 505 et physique 506 de l'interface DVB-CI à travers une API standard 502.

Le module 510 est relié physiquement à l'hôte 100 via une interface DVB-CI 520. Les différents couches du module 510 (respectivement session 513, transport 514, liaison 515 et physique 516) communiquent avec les couches correspondantes (respectivement session 503, transport 504, liaison 505 et physique 506) de l'interface DVB-CI de l'hôte 100 selon une manière bien connue de l'homme du métier. II est à noter cependant que notamment des messages DVB-CI contiennent des niveaux de priorité associés à une session.

Ainsi, le module 510 et l'hôte 100 sont reliés logiquement et tout particulièrement leurs couches sessions respectives.

La figure 6 décrit un message 610 de requête d'ouverture de session émis par une application quelconque vers l'hôte 100 tel qu'illustré en regard de la figure 1, à travers une interface DVB-CI.

Ce message 610 comprend les champs suivants - un identifiant de message 600, noté Open session request tag , codé sur 8 bits (ou éléments binaires), indiquant qu'il s'agit d'un message de requête d'ouverture de session ; - un champ longueur du message 601, noté Length field() , contenant le nombre d'octets dans le message après ce champ longueur, ici égal à 5 ; - un identifiant de ressource 602, noté Ressource identifier() , codé sur 4 octets, attribué à chaque ressource du système par le

gestionnaire de ressource et que l'application connaît grâce à l'information initiale fournie par le gestionnaire de ressource; - un champ niveau de priorité 603 de la session requise, noté Significance , codé sur 1 octet.

On note que dans l'état de l'art, le champ 603 de niveau de priorité d'un de requête d'ouverture de session n'est pas présent et que le champ longueur du message 601 est égal à 4 au lieu de 5.

La figure 7 décrit un message 710 de requête de création de session. Suite à la réception par l'hôte 100 d'un message 610 tel qu'illustré en regard de la figure 6, le gestionnaire de ressources de l'hôte attribue un numéro de session puis un message 710 est émis par l'hôte 100 vers une ressource correspondante à l'identifiant 602 présent dans le message 610.

Ce message 710 comprend les champs suivants - un identifiant de message 700, noté Create session request tag , codé sur 8 bits (ou éléments binaires), indiquant qu'il s'agit d'un message de requête de création de session ; - un champ longueur du message 701, noté Length field() , ici égal à7; - un identifiant de ressource 702, noté Ressource identifier() ; - un numéro de session 704, noté Session nb ; - un champ niveau de priorité 703, noté Significance .

On note que dans l'état de l'art, le champ 703 n'est pas présent dans un message de requête de création de session et que le champ longueur du message 701 est égal à 6 au lieu de 7.

Le champ 703 permet une identification facile du niveau de priorité qui peut être utilisé par la ressource identifiée par l'identifiant 702 pour autoriser ou non la création d'une session.

Les valeurs des champs 702 et 703 sont égales aux valeurs 602 et 603 du message 610 ayant entraîné l'émission du message 710.

La figure 8 décrit un protocole d'échange entre - une application x 800 présente dans l'un des modules 108 à 110 ou dans l'hôte 100 tel qu'illustré en regard de la figure 1 ; - l'hôte 100 ; et

- une ressource 801 présente dans l'un des modules 109 à 110 ou dans l'hôte 100, tels qu'illustrés en regard de la figure 1.

Selon la figure 8, une application x 800 émet une requête 802 d'ouverture de session vers l'hôte 100 à l'aide d'un message 610 tel qu'illustré en regard de la figure 6.

Puis, le processeur 302 de l'hôte 100 extrait du message 610 et analyse l'identifiant 600 qui permet au processeur 302 d'identifier un message de type requête d'ouverture de session.

Ensuite, en fonction du champ 602, le processeur 302 identifie la ressource requise et attribue un numéro de session. Puis, le processeur 302 construit un message 710 de requête de création de session tel qu'illustré en regard de la figure 7 en recopiant les champs 602 d'identification de ressource et 603 de niveau de priorité issus du message 610 dans respectivement les champs 702 et 703 du message 710 et en mettant à jour le champ 704 de numéro de session avec le numéro attribué. Ensuite, l'hôte 100 émet une requête 803 de création de session vers la ressource 801 correspondant à l'identifiant 602 à l'aide du message 710 ainsi construit.

A la réception de la requête 803, grâce au processeur 402 respectivement 302 si la ressource 801 est présente dans un module respectivement dans l'hôte 100, la ressource 801 détermine s'il est possible d'ouvrir la session requise par la requête 803 en fonction du niveau de priorité présent dans le champ 703 du message 710 reçu, des niveaux de priorité des éventuelles sessions ouvertes présentes dans la liste des sessions ouvertes List Sess associée à la ressource 801 et du paramètre N Sess Max indiquant le nombre maximal de sessions qu'il est possible d'ouvrir pour la ressource 801. La possibilité ou non d'ouverture de session par la ressource 801 est déterminée selon un organigramme de gestion des sessions décrit en détail en regard de la figure 11.

La ressource 801 construit un message de réponse et émet vers l'hôte 100 une réponse 804 à la requête 803 positive ou négative en fonction des possibilités de la ressource requise.

A la réception de ce message, le processeur 302 de l'hôte 100 construit un message correspondant de réponse à la requête d'ouverture de session 802 et émet une réponse 805 vers l'application x 800.

A la réception de la réponse 805, l'application x 800 met en oeuvre des opérations décrites en détail en regard de la figure 10.

De manière résumée, si la réponse est négative, l'application x 800 met en oeuvre une temporisation avant d'émettre à nouveau une requête 802.

Si la réponse est positive, selon un protocole d'échange non représenté sur la figure 8, l'application x 800 émet les données relatives à la session vers l'hôte 100 qui les répercute vers la ressource 801 et la ressource 801 requise émet le cas échéant des données relatives à la session vers l'hôte 100 qui les répercute vers l'application 800.

Lorsque les échanges de données sont terminés ou à la suite d'un évènement particulier, l'application x 800 émet vers l'hôte 100 une requête 806 de clôture de session qui est répercutée (requête 807) vers la ressource 801.

A la réception de cette demande, la ressource 801 ferme la session et émet une réponse 808 de clôture de session vers l'hôte 100 qui la répercute sous la forme d'une réponse 809 vers l'application x 800.

La figure 9 décrit un protocole d'échange entre - une première application x 800 tel qu'illustrée en regard de la figure 8; - une deuxième application y 908 présente dans l'un des modules 108 à 110 ou dans l'hôte 100 tel qu'illustré en regard de la figure 1; - l'hôte 100 ; et - une ressource 801 tel qu'illustrée en regard de la figure 8.

Selon la figure 9, l'application x 800 émet une requête 802 d'ouverture de session vers l'hôte 100 à l'aide d'un message 610 tel qu'illustré en regard de la figure 6.

Le protocole d'échange de création et d'ouverture de session étant similaire à celui décrit en regard de la figure 8, les éléments de ce protocole portent les mêmes numéros de référence 803 à 805 et ne sont pas décrits davantage.

La deuxième application y 908 émet alors une requête d'ouverture de sessions 900 vers l'hôte 100, destinée à la ressource 801 et similaire à la requête 802 mais correspondant à une session de plus forte priorité. Cette

requête est répercutée par l'hôte 100 vers la ressource 801 par une requête de création de session 901.

On suppose ici que la ressource 801 a déjà ouvert un nombre N Sess Max de sessions et que la session ouverte pour l'application x 800 possède la plus basse priorité parmi les sessions ouvertes.

La ressource 801 détermine alors qu'il faut clore la session de plus basse priorité pour permettre l'ouverture requise d'une session de plus haute priorité.

Elle construit alors un message de requête de clôture de session relative à l'application x 800, qu'elle transmet au cours d'une requête 904 à l'hôte 100 qui la répercute vers la première application x 800 par une requête 905.

L'application x 800 ferme la session relative à la requête 905 et émet un message 906 de réponse de fermeture de session vers l'hôte 100 qui transmet un message 907 de réponse de fermeture de session vers la ressource 801.

La ressource 801 émet alors vers l'hôte 100 une réponse 902 positive d'ouverture de session relative à l'application y 908, similaire à la réponse 804.

L'hôte 100 émet alors une réponse 903 positive à la requête d'ouverture de session vers l'application y 908 qui peut alors ouvrir la session correspondante.

La figure 10 décrit la gestion des ressources par une application 800 ou 908. Par souci de clarté, on décrit ci-après la cas où l'application est présente dans l'un des modules 108 à 110 avec une mise en oeuvre selon le dispositif électronique 400 telle que décrit en regard de la figure 4. Néanmoins, la gestion est similaire lorsque l'application est présente dans l'hôte 100.

En figure 10 qui présente le fonctionnement d'un processeur 402 inclus dans le dispositif électronique d'un module 400, on observe qu'après une opération d'initialisation 1000 au cours de laquelle les registres de la mémoire vive 405 sont initialisés, au cours d'une opération 1001, le processeur 402 attend puis reçoit une information indiquant un besoin d'une ressource.

Puis, au cours d'une opération 1002, le processeur 402 construit un message de requête d'ouverture de session avec une priorité de session tel qu'illustré en regard de la figure 6 et émet cette requête vers l'hôte 100. On note que les niveaux de priorité sont déterminés par le constructeur du module ou de l'hôte mettant en oeuvre l'application selon préférentiellement une échelle de niveaux qui est commune à plusieurs constructeurs.

Ensuite, au cours d'une opération 1003, le processeur 402 attend puis reçoit une réponse à la requête émise.

Puis, au cours d'un test 1004, le processeur 402 détermine si la réponse à la requête est positive ou non.

Dans la négative, au cours d'une opération 1005, le processeur 402 lance une temporisation de plusieurs secondes et attend l'écoulement de cette temporisation avant de réitérer l'opération 1002.

Dans l'affirmative, au cours d'une opération 1006, le processeur 402 attend de recevoir puis reçoit une information indiquant la fin des besoins de la ressource ou une requête de fermeture de session de l'hôte 100. Une requête de fermeture de session peut notamment être engendrée par - un problème décelé par l'hôte 100 ;ou - une fermeture demandée par une ressource à la suite d'une requête de création de session plus prioritaire.

Ensuite, au cours d'un test 1007, le processeur détermine s'il s'agit ou non d'une requête de fermeture de session.

Dans l'affirmative, au cours d'une opération 1008, le processeur 402 ferme la session correspondant à la requête et envoi une réponse de fermeture de la session effectuée au décodeur 100.

Dans la négative, au cours d'une opération 1009, le processeur 402 construit un message de clôture de session et émet ce message vers le décodeur 100.

Puis, au cours d'une opération 1110, il attend puis reçoit une réponse de clôture de la session. Le processeur 402 ferme alors la session correspondante.

Ensuite, l'opération 1001 est réitérée.

La figure 11 décrit la gestion d'une ressource 801 telle qu'illustrée en regard des figures 8 et 9. Par souci de clarté, on décrit ci-après le cas où la ressource est présente dans l'un des modules 109 à 110 avec une mise en

oeuvre selon le dispositif électronique 400 selon la variante possédant une ressource telle que décrite en regard de la figure 4. Néanmoins, la gestion est similaire lorsque la ressource est présente dans l'hôte 100.

En figure 11 qui présente le fonctionnement d'un processeur 402 inclus dans le dispositif électronique d'un module 400, on observe qu'au cours d'une opération d'initialisation 1110, les registres de la mémoire vive 405 sont initialisés ; le registre N Sess Open est notamment mis à zéro et la liste List Sess est vide. Dans la description de la figure 11, les registres N Sess Open, List Sess et N Sess Max correspondent à la ressource 801 considérée.

Ensuite, au cours d'une opération 1111, le processeur 402 attend puis reçoit une requête qui peut être de création ou de fermeture de session. Ensuite, au cours d'un test 1112, le processeur 402 détermine s'il s'agit ou non d'une requête de création de session.

Dans la négative, il s'agit alors d'une requête de fermeture et au cours d'une opération 1115, le processeur 402 ferme la session, met à jour la liste List Sess des sessions ouvertes et décrémente le compteur N Sess Open. L'opération 1111 est ensuite réitérée.

Dans l'affirmative, au cours d'un test 1116, le processeur 402 détermine si le nombre de sessions ouverte N Sess Open auquel on ajoute 1 est égal ou non au paramètre N Sess Max.

Dans la négative, au cours d'une opération 1119, le processeur 402 ouvre la session correspondante, ajoute cette session à la liste des sessions ouvertes List Sess, incrémente le compteur de sessions ouvertes N Sess Open, construit un message de réponse positif et transmet ce message au décodeur 100. L'opération 1111 est ensuite réitérée.

Dans l'affirmative, au cours d'un test 1117, le processeur 402 détermine si la session requise est plus prioritaire que la session ouverte la moins prioritaire présente dans la liste List Sess Open.

En variante, au cours du test 1117, le processeur 402 détermine si la session requise est aussi ou plus prioritaire que la session ouverte la moins prioritaire présente dans la liste List Sess Open.

Dans la négative, au cours d'une opération 1120, le processeur 402 construit un message de réponse négative qu'il transmet au décodeur 100. L'opération 1111 est ensuite réitérée.

Dans l'affirmative, au cours d'une opération 1118, le processeur 402 construit un message de requête de fermeture de la session la moins prioritaire parmi les sessions ouvertes et transmet ce message vers le décodeur100.

Puis, au cours d'une opération 1121, le processeur 402 attend puis reçoit un message de réponse indiquant la clôture de la session la moins prioritaire.

Puis, au cours d'une opération 1122, le processeur 402 ferme la session la moins prioritaire, crée la session requise, met à jour la liste des sessions ouvertes List Sess et émet une réponse d'ouverture de la session requise vers l'hôte 100. L'opération 1111 est ensuite réitérée.

Bien entendu, l'invention n'est pas limitée aux exemples de réalisation mentionnés ci-dessus.

En particulier, l'homme du métier pourra apporter toute variante dans la définition des interfaces numériques vidéo et/ou multimédia ou des protocoles correspondants qui peuvent notamment être de type NRSS B ou Open Cable.

Par ailleurs, l'homme du métier pourra apporter toute variante dans la gestion des sessions liées à une ressource. La gestion des priorités de session peut notamment être effectuée ailleurs que dans la ressource concernée et en particulier au sein de l'hôte qui grâce au gestionnaire de ressources possède entre autres une liste et un nombre de sessions ouvertes liés à chaque ressource présente dans le système. II suffit alors que chaque ressource communique à l'hôte le nombre maximal de sessions qu'elle peut supporter.

On notera que l'invention ne se limite pas à une implantation purement matérielle mais qu'elle peut aussi être mise en ceuvre sous la forme d'une séquence d'instructions d'un programme informatique ou toute forme mixant une partie matérielle et une partie logicielle.

Claims

REVENDICATIONS

1. Procédé d'allocation d'une ressource (105 à 107, 111, 112) à au moins une application ladite ressource et ladite application communiquant entre elles à travers une interface numérique multimédia contrôlée par un hôte (100), comprenant une étape de demande d'ouverture (802, 900, 803, 901) d'au moins une session auprès de ladite ressource (105 à 107, 111, 112) et une étape de réponse (804, 805, 902, 903) de ladite ressource (105 à 107, 111, 112) autorisant ou refusant l'ouverture de ladite session, caractérisé en ce que l'autorisation ou le refus d'ouverture de ladite session (1117) tient compte d'un niveau de priorité (603, 703) affecté à ladite demande d'ouverture de session par ladite application.

2. Procédé d'allocation d'une ressource selon la revendication 1, caractérisé en ce que ledit niveau de priorité (603, 703) est transmis à ladite ressource dans le corps (610, 710) de ladite demande d'ouverture d'au moins une session.

3. Procédé d'allocation d'une ressource selon la revendication 2, caractérisé en ce que ladite interface numérique multimédia permet l'échange d'objets informatiques (610, 710), comprenant au moins un champ et en ce qu'un objet (610, 710) ayant pour but l'ouverture d'une session comprend un champ codant ledit niveau de priorité (603, 703).

4. Procédé d'allocation d'une ressource selon la revendication 3, caractérisé en ce que lesdits objets (610, 710) comprennent des objets de requête d'ouverture de session (Open session request 610) et/ou des objets de création de session (Create session 710).

5. Procédé d'allocation d'une ressource selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite interface numérique multimédia est de type DVB-CI ou NRSS ou Open Cable.

6. Procédé d'allocation d'une ressource selon l'une quelconque des revendications 1 ou 5, caractérisé en ce qu'il comprend une opération de gestion de requête d'ouverture de session (610, 710) comprenant des étapes

- de comparaison (1117) du niveau de priorité (603, 703) de ladite session à ouvrir au niveau de priorité d'au moins une éventuelle session ouverte (List Sess); - s'il existe une session ouverte de moindre priorité que ladite session à ouvrir, de fermeture d'au moins une session ouverte de moindre priorité que ladite session à ouvrir et d'ouverture de ladite session à ouvrir (1122); - sinon, de refus (1120) de ladite demande d'ouverture de ladite session à ouvrir.

7. Procédé d'allocation d'une ressource selon la revendication 6, caractérisé en ce que les étapes de fermeture (1118, 1122) et de refus (1120) et éventuellement de comparaison (1117) ne sont mises en ceuvre que s'il y a saturation du nombre de sessions dans ladite ressource.

8. Composant multimédia numérique capable de communiquer via une interface numérique multimédia avec au moins une ressource et d'émettre une demande d'ouverture (610, 710) d'au moins une session, et d'allocation d'une ressource correspondante, à l'une desdites au moins une ressource, caractérisé en ce qu'il comprend des moyens d'affectation d'un niveau de priorité (603,703) à chacune desdites demandes d'ouverture.

9. Appareil multimédia numérique capable de communiquer via une interface numérique multimédia contrôlée par un hôte avec au moins une application et d'autoriser ou de refuser l'ouverture d'une session, et l'allocation d'une ressource correspondante, en réponse à une demande émise par l'une desdites au moins une application, caractérisé en ce qu'il comprend des moyens de gestion desdites demandes d'ouverture tenant compte d'un niveau de priorité (603,703) affecté aux dites demandes d'ouverture (610,710).

10. Appareil multimédia numérique selon la revendication 9, caractérisé en ce qu'il appartient au groupe comprenant les téléviseurs, les magnétoscopes, les décodeurs numériques multimédia, les décodeurs- récepteurs intégrés (IRD), les micro-ordinateurs, les lecteurs enregistreurs de disques optiques.