FR2988885A1 - Base de donnees, serveur hss, et serveurs de controle d'un reseau ims - Google Patents

Abstract

L'invention vise une base de données (5) accessible dans un réseau IMS (2), et comportant au moins un profil d'un utilisateur comprenant au moins un identifiant (ServId1, Servld2, ServId3) d'un service autorisé pour l'utilisateur, ladite base de données (5) étant caractérisée en ce que, dans le profil de l'utilisateur, chaque identifiant d'un service est associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service.

Description

Arrière-plan de l'invention L'invention se situe dans le domaine des télécommunications. Elle concerne plus particulièrement les réseaux de télécommunications s'appuyant sur une architecture IMS (IP Multimedia Subsystem), telle que définie par le standard 3GPP (Third Generation Partnership Project). Une telle architecture met en oeuvre de façon connue en soi, le protocole d'initiation de session SIP (Session Initial Protocol). Dans la suite de la description, par souci de simplification, on désignera par « réseau IMS » un tel réseau. De nombreuses applications multimédia s'appuyant sur une architecture IMS sont développées aujourd'hui, leur diffusion auprès des clients utilisateurs des réseaux IMS étant favorisée par la multiplication sur le marché d'équipements multimédia tels que des téléphones intelligents ou « smartphones », des tablettes multimédia, etc. Ces équipements constituent en effet les supports naturels des utilisations multimédia pour lesquelles l'architecture IMS a été développée.

Par application, on entend au sens de l'invention un logiciel apte à délivrer un ou plusieurs services, et qui est mis à disposition d'un utilisateur sur un équipement support ou UE pour « Utilisateur Equipment » en anglais (ex. smartphone ou tablette multimédia). De telles applications sont par exemple une application conversationnelle audio et/ou vidéo, une application de messagerie instantanée (ou IM, Instant Messaging), une application de téléchargement, une application de diffusion de contenu, etc. Pour délivrer un service, une application s'appuie généralement sur un ou plusieurs services dits élémentaires, mis à disposition par l'opérateur via le réseau IMS. La téléphonie multimédia et la télévision sur IP (Internet Protocol) ou IPTV (IP Television) sont des exemples de tels services élémentaires.

Dans le standard 3GPP, ces services élémentaires sont référencés par des identifiants de service aussi connus sous le nom d'ICSI (IMS Communication Service Identifier). Ainsi, le service élémentaire de téléphonie multimédia est référencé par l'ICSI « 3gpp- service.ims.icsi.mmtel ». Il convient de noter qu'une application qui utilise pour le compte d'un utilisateur, un ou plusieurs services élémentaires du réseau IMS, est tenue normalement de déclarer ces services élémentaires lors de l'enregistrement de cet utilisateur sur le réseau IMS : en d'autres mots, la requête SIP REGISTER émise par l'application pour le compte de l'utilisateur doit en principe contenir la liste des ICSI désignant ces services. Plus généralement, l'IETF (Internet Engineering Task Force), qui participe à la définition des nouveaux standards liés à Internet, introduit la notion de « feature tag » pour désigner les capacités, autrement dit les services du réseau IMS, dont une application sollicite l'usage. Ces capacités ou services requièrent en général l'utilisation de ressources spécifiques et distinctes sur le plan média. Ainsi, par exemple - un service IPTV utilise des ressources en diffusion avec une large bande passante ; - un service audio multimédia utilise des ressources bidirectionnelles, associées à une famille particulière de codecs prédéfinis ; - un service de messagerie instantanée utilise une connexion bas débit permettant de délivrer des messages textes ou permettant l'échange de fichiers ; - etc. La négociation de ces ressources média est réalisée dans l'architecture IMS via le protocole de description de session SDP (Session Description Protocol). Autrement dit, les caractéristiques des ressources média négociées par un terminal sont fournies le cas échéant dans une session SDP des requêtes de service SIP émises par le terminal. Le standard 3GPP prévoit la possibilité de contrôler, de façon indépendante, d'une part le droit d'usage des services élémentaires annoncés dans les requêtes de service SIP émises par une application hébergée sur un terminal pour le compte de l'utilisateur de ce terminal, et d'autre part, le droit d'usage des ressources média négociées par ce terminal via le protocole SDP. De tels contrôles peuvent être mis en oeuvre en particulier au niveau d'un serveur S-CSCF (Serving-Cali Session Control Function) du réseau IMS, gérant l'enregistrement des terminaux auprès du réseau. Pour réaliser ces contrôles, le serveur S-CSCF utilise des informations de droits d'usage renseignées dans les profils utilisateurs (ou User Profile) stockés dans le serveur HSS (Home Subscriber Service) du réseau IMS.

De façon connue, chaque profil utilisateur contient diverses informations relatives à l'utilisateur, telles que notamment une identité privée allouée à celui-ci, une ou plusieurs identités publiques associées à cette identité privée, et un ou plusieurs profils de service (ou Service Profile) définis pour ces identités publiques. La figure 1 illustre de façon schématique les principaux éléments d'informations contenus dans un profil utilisateur tel que défini dans l'architecture IMS.

Chaque profil de service du profil utilisateur comprend, dans un champ intitulé « Core Network Service Authorization » : - une liste d'identifiants (ICSI) de services mis à disposition par le réseau IMS et que l'utilisateur est autorisé à utiliser ; ces identifiants sont compris dans un champ Serviceld ; et - un index pointant vers un profil média décrivant des ressources média (c'est-à-dire des paramètres de session SDP) que l'utilisateur est autorisé à utiliser dans ses requêtes SIP (ex. valeurs de codecs, attributs SDP autorisés, etc.) ; cet index est compris dans un champ SubscribedMediaProfileld. Les profils de service sont obtenus par le serveur S-CSCF à travers l'interface Diameter Cx lors de l'enregistrement de l'utilisateur auprès du réseau IMS. L'interface Diameter Cx est décrite en détails dans les documents 3GPP TS 29.228, « IP Multimedia Subsystem Cx and Dx Interfaces ; Signalling flows and message contents », Release 10, décembre 2011, et TS 29.229, « Cx and Dx interfaces based on the Diameter protocol; Protocol details », Release 10, décembre 2011.

Ainsi, un contrôle pouvant être mis en place par le serveur S-CSCF consiste à vérifier que les ressources média négociées par le terminal dans les sessions SDP des requêtes de service sont compatibles avec les ressources média autorisées pour ce terminal et recensées dans le profil média identifié par l'index présent dans le champ SubscribedMediaProfileId du profil utilisateur.

En revanche, l'architecture IMS n'offre pas, dans sa définition actuelle, la possibilité de réaliser de manière simple des contrôles ou des vérifications « croisé(e)s », c'est-à-dire portant simultanément sur les services annoncés par le terminal et sur les ressources média négociées dans les sessions SDP, et ce par exemple, en vue de détecter une utilisation frauduleuse ou détournée des ressources du réseau IMS par un utilisateur.

Il existe donc un besoin d'améliorer les possibilités de contrôle et/ou de vérification offertes aujourd'hui par l'architecture IMS. Objet et résumé de l'invention L'invention répond à ce besoin en établissant, dans le profil utilisateur stocké par le réseau IMS, un lien entre les services auxquels l'utilisateur est autorisé à accéder via son terminal et les ressources média négociées par ce terminal dans les sessions SDP de ses requêtes de service SIP. Plus précisément, l'invention vise une base de données, accessible dans un réseau IMS, et comportant au moins un profil d'un utilisateur comprenant au moins un identifiant d'un service autorisé pour l'utilisateur, cette base de données étant remarquable en ce que, dans le profil de l'utilisateur, chaque identifiant d'un service est associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service. Corrélativement, l'invention vise un serveur HSS d'un réseau IMS dans lequel est stockée une base de données accessible dans le réseau, cette base de données comportant au moins un profil d'un utilisateur comprenant au moins un identifiant d'un service autorisé pour l'utilisateur, ce serveur HSS étant remarquable en ce que, dans le profil de l'utilisateur, chaque identifiant d'un service est associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service. Autrement dit, conformément à l'invention, le profil d'un utilisateur identifie maintenant pour chaque service auquel est autorisé à accéder l'utilisateur, des ressources média spécifiques autorisées pour ce service. Ainsi, l'invention ne se contente pas de combiner dans un ou plusieurs profils média toutes les combinaisons de ressources média autorisées pour l'utilisateur, mais elle offre la possibilité d'accéder, via le profil d'un utilisateur, à une liste de profils média qui sont mis en relation directe avec les services autorisés pour cet utilisateur, et qui sont adaptés spécifiquement à chacun de ces services.

Cette relation établie par l'invention entre les services et les ressources média dans le profil utilisateur vient avantageusement compléter les informations de ressources média déjà disponibles via l'index présent dans le champ SubscribedMediaProfileld du profil utilisateur, et qui recensent de manière générale les ressources média que peut négocier un terminal d'un utilisateur, indépendamment des services auxquels il est autorisé à accéder. On notera que l'élément représentatif d'un profil média ajouté par l'invention peut être de même nature que les informations présentes dans le champ SubscribedMediaProfileld défini par le standard 3GPP (c'est-à-dire notamment se présenter sous la forme d'un index pointant vers un profil média).

La relation mise en évidence dans le profil utilisateur entre les services et les ressources média conformément à l'invention permet de faciliter et d'améliorer les contrôles et les vérifications que le réseau IMS peut mettre en oeuvre à partir des informations contenues dans les requêtes de service SIP émises par les terminaux des utilisateurs. En effet, elle offre notamment la possibilité de réaliser des contrôles croisés visant à vérifier la cohérence des services annoncés par le terminal au vu des ressources média négociées dans les sessions SDP de ses requêtes de service SIP et inversement. Il est ainsi possible de détecter facilement une utilisation frauduleuse ou détournée des ressources au sens général du réseau IMS par un terminal ou par une application agissant pour le compte d'un terminal. Par ailleurs, le lien établi conformément à l'invention permet également d'anticiper les services élémentaires du réseau IMS dont une application d'un terminal d'un utilisateur va solliciter l'usage, dans le cas où par exemple, cette application aurait omis d'annoncer dans une requête SIP ces services élémentaires (cela peut arriver lorsque les applications ne sont pas totalement conformes au standard 3GPP). En effet, il est possible grâce à l'invention, de comparer les ressources média négociées par le terminal dans la session SDP de la requête de service SIP, avec les profils média associés dans la base de données de l'invention avec chaque service autorisé pour l'utilisateur, et d'en déduire, par rapprochement, le ou les identifiants de services élémentaires associés à ces ressources média. Une telle information peut alors être fournie à des dispositifs tels que des AS (Application Servers) qui contribuent à la fourniture de ces services élémentaires.

Le profil de ressources média sélectionné pour un service dépend bien entendu de la nature du service (i.e. les ressources média sélectionnées pour un service de visioconférence diffèrent de celles sélectionnées pour un service de messagerie instantanée). Mais l'invention permet également de discriminer les ressources autorisées pour un service en fonction des utilisateurs, i.e., on peut facilement, grâce à l'invention, établir des droits d'usage de ressources média différents pour un même service en fonction des utilisateurs. Cette discrimination entre utilisateurs peut être décidée notamment en fonction de l'offre de service à laquelle a souscrit l'utilisateur ou de préférences utilisateurs.

Ainsi par exemple, pour un même service de télévision sur IP, on pourra décider d'associer dans le profil d'un utilisateur A, un profil média recensant des ressources média (débits, qualité, etc.) permettant à l'utilisateur A d'accéder à une qualité de télévision Haute Définition (HD), tandis qu'on associera dans le profil d'un utilisateur B, un profil média recensant des ressources média permettant à l'utilisateur B d'accéder uniquement à une définition standard (SD, Standard Definition) de télévision. Selon un autre exemple, on pourra autoriser pour un service donné, via le profil média associé à ce service conformément à l'invention, le transfert de gros fichiers à un utilisateur A, tandis que pour ce même service on autorisera un utilisateur B à transférer uniquement des petits fichiers. Autrement dit, pour un même service élémentaire, on associe deux profils média distincts selon s'il s'agit de l'utilisateur A ou de l'utilisateur B. Dans un mode de réalisation particulier de l'invention, l'identifiant du service est associé audit au moins un élément représentatif d'un profil média par l'intermédiaire d'un champ prédéterminé du profil utilisateur.

Ce champ, spécifique à chaque identifiant de service, peut être ajouté dans le profil utilisateur en complément des champs Serviceld et SubscribedMediaProfileId définis dans le standard 3GPP. En variante, il peut être ajouté dans le profil utilisateur en remplacement du champ SubscribedMediaProfileId aujourd'hui prévu par le standard 3GPP.

Quelle que soit l'alternative retenue, ce champ devra bien entendu faire l'objet d'une déclaration préalable auprès des organismes compétents pour permettre l'ajout ou la suppression de champ dans les profils utilisateurs maintenus dans les réseaux IMS. Par ailleurs, l'interface Diameter Cx utilisée par un serveur S-CSCF pour consulter le serveur HSS devra être adaptée afin de permettre au serveur de récupérer le champ introduit conformément à l'invention.

Dans un mode particulier de réalisation de l'invention, l'élément associé à l'identifiant du service est un pointeur vers une entrée d'une table regroupant une pluralité de profils média prédéfinis. On entend par pointeur, un index ou une valeur telle qu'un entier pointant vers une entrée de la table, autrement dit, identifiant une entrée de la table. Ce mode de réalisation permet d'ajouter, de supprimer ou de mettre facilement à jour les profils média associés aux services. Selon une première variante, la table regroupant la pluralité de profils média est stockée dans le serveur HSS du réseau IMS. Cette première variante permet de répercuter les modifications apportées le cas échéant aux profils média de façon plus simple et plus rapide, puisque le serveur HSS est un serveur central, partagé par les différents équipements du réseau IMS et notamment par les divers serveurs S-CSCF du réseau IMS en charge des enregistrements des utilisateurs.

Ce mode de réalisation offre une gestion centralisée des profils média et ne nécessite pas la mise à jour de tables locales, au niveau par exemple de chaque équipement ou de chaque serveur S-CSCF, dès lors qu'une modification est apportée à l'un de ces profils. De cette sorte, l'évolution des profils média peut être avantageusement répercutée dès le réenregistrement d'un terminal, c'est-à-dire lorsque le profil de l'utilisateur est obtenu par le serveur S-CSCF gérant cet utilisateur. Selon une seconde variante, la table regroupant la pluralité de profils média est stockée dans un serveur S-CSCF du réseau IMS. De façon connue, certains équipements gérant l'accès au réseau IMS sont amenés à télécharger les profils utilisateur stockés dans le serveur HSS. C'est notamment le cas d'un serveur S-CSCF du réseau IMS lorsqu'il reçoit une requête d'enregistrement ou de réenregistrement d'un terminal d'un utilisateur, ou lorsqu'il reçoit une requête d'établissement d'appel concernant un utilisateur non encore enregistré auprès du réseau IMS. Ainsi selon un autre aspect, l'invention vise un procédé d'obtention d'un profil d'un utilisateur par un serveur de contrôle d'un réseau IMS, ce réseau IMS comprenant une base de données conforme à l'invention ou un serveur HSS conforme à l'invention, ce procédé d'obtention comprenant - une étape d'interrogation par le serveur de contrôle de la base de données ou du serveur HSS en utilisant un identifiant d'un utilisateur obtenu à partir d'une requête reçue par ce serveur de contrôle en provenance ou à destination d'un terminal de cet utilisateur ; - une étape d'obtention par le serveur de contrôle, en réponse à cette étape d'interrogation, d'un profil de cet utilisateur comprenant au moins un identifiant d'un service autorisé pour cet utilisateur, chaque identifiant d'un service étant associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service. Corrélativement, l'invention vise aussi un serveur de contrôle d'un réseau IMS comprenant une base de données conforme à l'invention ou un serveur HSS conforme à l'invention, ce serveur de contrôle comprenant : - des moyens d'interrogation de la base de données ou du serveur HSS en utilisant un identifiant d'un utilisateur obtenu à partir d'une requête reçue par le serveur de contrôle en provenance ou à destination d'un terminal de cet utilisateur ; - des moyens d'obtention, en réponse à cette étape d'interrogation, d'un profil de cet utilisateur comprenant au moins un identifiant d'un service autorisé pour cet utilisateur, chaque identifiant d'un service étant associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service.

Le procédé d'obtention peut être mis en oeuvre en adaptant notamment l'interface Diameter Cx définie actuellement par le standard 3GPP, afin d'obtenir les informations complémentaires prévues par l'invention dans le profil utilisateur. Ce procédé permet au serveur de contrôle d'être informé notamment des relations existant entre d'une part les services autorisés pour un utilisateur et d'autre part les ressources média que peut négocier cet utilisateur pour chaque service autorisé. La requête reçue du serveur de contrôle est par exemple une requête d'enregistrement du terminal, et le serveur de contrôle est par exemple un serveur S-CSCF du réseau IMS. Dans un mode particulier de réalisation de l'invention, le procédé d'obtention comprend en outre une étape d'obtention par le serveur de contrôle, en provenance de la base de données ou du serveur HSS, des profils média associés aux identifiants des services autorisés pour cet utilisateur compris dans le profil de cet utilisateur. Dans un autre mode de réalisation de l'invention, le procédé d'obtention comprend en outre une étape d'obtention par le serveur de contrôle, à partir d'une table stockée par ce serveur de contrôle regroupant une pluralité de profils média prédéfinis, des profils média associés aux identifiants des services autorisés pour cet utilisateur compris dans le profil de cet utilisateur. Comme décrit précédemment, le lien entre les services et les ressources média introduit par l'invention permet de contrôler l'accès aux services et notamment d'éviter une utilisation frauduleuse des services et/ou des ressources média par une application d'un terminal d'un utilisateur. Ainsi, selon un autre aspect, l'invention vise un procédé de contrôle d'un accès à un service par un terminal d'un utilisateur, destiné à être mis en oeuvre dans un réseau IMS comprenant une base de données conforme à l'invention ou un serveur HSS conforme à l'invention, en utilisant tout ou partie d'un profil de l'utilisateur stocké dans cette base de données ou dans ce serveur HSS et obtenu au cours d'une étape préliminaire par un procédé d'obtention selon l'invention. Ce procédé de contrôle comprend : une étape de réception d'au moins une requête de service en provenance d'un terminal de cet utilisateur contenant un identifiant d'un service annoncé par le terminal et au moins une caractéristique d'une ressource média négociée par le terminal ; une étape d'obtention : o d'un profil média associé à l'identifiant du service dans ledit profil de l'utilisateur ; ou o d'au moins un identifiant d'un service associé à un profil média contenant ladite au moins une caractéristique dans ledit profil de l'utilisateur ; une étape de contrôle au cours de laquelle on vérifie la compatibilité avec le profil média ou ledit au moins un identifiant de service obtenu au cours de l'étape d'obtention, de l'identifiant du service ou de ladite au moins une caractéristique contenu(e) dans ladite au moins une requête de service reçue en provenance du terminal.

Corrélativement, l'invention vise aussi un système de contrôle d'un accès à un service par un terminal dans un réseau IMS comprenant une base de données conforme à l'invention ou un serveur HSS conforme à l'invention, ledit contrôle étant mis en oeuvre en utilisant tout ou partie d'un profil de l'utilisateur obtenu préalablement de la base de données ou du serveur HSS, ce profil de l'utilisateur comprenant au moins un identifiant d'un service autorisé pour cet utilisateur, chaque identifiant d'un service étant associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, et ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service. Conformément à l'invention, le système de contrôle comprend : - des moyens de réception d'au moins une requête de service en provenance d'un terminal de cet utilisateur contenant un identifiant d'un service annoncé par le terminal et au moins une caractéristique d'une ressource média négociée par le terminal ; - des moyens d'obtention : o d'un profil média associé à l'identifiant du service dans ledit profil de l'utilisateur ; ou o d'au moins un identifiant d'un service associé à un profil média contenant ladite au moins une caractéristique dans ledit profil de l'utilisateur ; - des moyens de contrôle, aptes à vérifier la compatibilité avec le profil média ou ledit au moins un identifiant de service obtenu par les moyens d'obtention, de l'identifiant du service ou de ladite au moins une caractéristique contenu(e) dans ladite au moins une requête de service reçue en provenance du terminal. Par « compatible avec le profil média ou ledit au moins un identifiant de service», on entend ici en accord avec ce profil média ou avec ledit au moins un identifiant de service au regard de critères prédéfinis par l'opérateur du réseau IMS ou des dispositifs participant à la fourniture du service au terminal et/ou des capacités du réseau IMS, des dispositifs précités et du terminal.

Ce procédé, respectivement ce système, de contrôle permet de vérifier que l'usage du service identifié dans le message de l'utilisateur correspond bien aux ressources média négociées dans cette requête de service ou dans une autre requête de service. On peut de cette façon facilement détecter par exemple qu'un utilisateur qui prétend demander un service de messagerie instantanée à faible débit n'est pas en réalité en train d'établir un média haut débit destiné à exploiter un service de visioconférence HD. Dans un mode particulier de réalisation, le procédé de contrôle selon l'invention comprend en outre une étape de rejet de ladite au moins une requête de service si, au cours de l'étape de contrôle, on détecte que l'identifiant du service ou ladite au moins une caractéristique contenu(e) dans ladite au moins une requête en provenance du terminal n'est pas compatible avec le profil média ou ledit au moins un identifiant de service obtenu au cours de l'étape d'obtention. En variante, on peut prévoir la substitution par le système de contrôle de certaines ressources média considérées comme « incompatibles » avec le profil utilisateur et négociées dans la requête, par des ressources média spécifiées dans le profil média obtenu à partir du profil de l'utilisateur, et donc correspondant au service annoncé par le terminal. Bien entendu, cette substitution est réalisée dans la mesure du possible, c'est-à-dire en respectant les capacités du terminal et/ou celles du réseau IMS. Ainsi par exemple, si la bande passante négociée par le terminal dans la session SDP de la requête SIP pour un certain service est supérieure à la bande passante autorisée pour ce terminal et pour ce service, le système de contrôle peut ajuster la bande passante négociée par le terminal à la bande passante autorisée par le profil utilisateur. En revanche, si une incompatibilité est détectée au niveau d'un codec, une telle substitution ne peut être envisagée.

Le système de contrôle selon l'invention est par exemple intégré dans un serveur S- CSCF du réseau IMS. Un tel serveur est de façon connue chargé de l'enregistrement des terminaux et télécharge à cette occasion le profil utilisateur stocké dans le serveur HSS du réseau IMS, de sorte qu'une utilisation frauduleuse d'un service ou des ressources peut être détectée très rapidement. De même l'évolution des profils média peut être prise en compte dès le réenregistrement le cas échéant d'un terminal. D'autres utilisations des informations comprises dans les profils utilisateurs stockés dans la base de données ou dans le serveur HSS selon l'invention peuvent être envisagées. Ainsi, selon un autre aspect, l'invention vise également un procédé de contrôle d'un accès à un service par un utilisateur, destiné à être mis en oeuvre dans un réseau IMS comprenant une base de données conforme à l'invention ou un serveur HSS conforme à l'invention, en utilisant tout ou partie d'un profil de l'utilisateur stocké dans cette base de données ou dans ce serveur HSS et obtenu au cours d'une étape préliminaire par un procédé d'obtention selon l'invention. Ce procédé de contrôle comprend - une étape de réception d'une requête de service en provenance d'un terminal de cet utilisateur contenant un identifiant d'un service annoncé par le terminal ; une étape d'obtention d'au moins un identifiant d'un service autorisé pour cet utilisateur contenu dans le profil de l'utilisateur ; et - une étape de contrôle au cours de laquelle on vérifie la compatibilité de l'identifiant du service contenu dans la requête de service reçue en provenance du terminal avec ledit au moins un identifiant d'un service obtenu au cours de l'étape d'obtention. Corrélativement, l'invention vise aussi un système de contrôle d'un accès à un service par un terminal dans un réseau IMS comprenant une base de données conforme à l'invention ou un serveur HSS conforme à l'invention, ledit contrôle étant mis en oeuvre en utilisant tout ou partie d'un profil de l'utilisateur obtenu préalablement de cette base de données ou du serveur HSS, ce profil de l'utilisateur comprenant au moins un identifiant d'un service autorisé pour cet utilisateur, chaque identifiant d'un service étant associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, et ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service. Conformément à l'invention, ce système de contrôle comprend : - des moyens de réception d'une requête de service en provenance d'un terminal de cet utilisateur contenant un identifiant d'un service annoncé par le terminal ; - des moyens d'obtention d'au moins un identifiant d'un service autorisé pour cet utilisateur contenu dans ledit profil de l'utilisateur ; et - des moyens de contrôle aptes à vérifier la compatibilité de l'identifiant du service contenu dans la requête de service reçue en provenance du terminal avec ledit au moins un identifiant d'un service obtenu par les moyens d'obtention.

Selon un autre aspect encore, l'invention vise aussi un procédé de fourniture par une entité d'un réseau IMS comprenant une base de données conforme à l'invention ou un serveur HSS conforme à l'invention, d'un identifiant de service contenu dans un profil d'un utilisateur stocké dans cette base de données ou dans ce serveur HSS et obtenu au cours d'une étape préliminaire par un procédé d'obtention selon l'invention, ce procédé de fourniture comprenant : - une étape de réception d'une requête de service en provenance d'un terminal de cet utilisateur, cette requête de service comprenant au moins une caractéristique d'une ressource média négociée par le terminal ; - une étape d'obtention d'au moins un identifiant d'un service associé dans ledit profil de l'utilisateur à un profil média contenant ladite au moins une caractéristique ; et - une étape de fourniture dudit au moins un identifiant de service obtenu à l'étape d'obtention à un dispositif participant au traitement de la requête de service. Corrélativement, l'invention vise aussi un système de contrôle dans un réseau IMS comprenant une base de données conforme à l'invention ou un serveur HSS conforme à l'invention, apte à utiliser tout ou partie d'un profil de l'utilisateur obtenu préalablement de cette base de données ou du serveur HSS, ce profil de l'utilisateur comprenant au moins un identifiant d'un service autorisé pour cet utilisateur, chaque identifiant d'un service étant associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, et ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service. Conformément à l'invention, ce système de contrôle comprend : des moyens de réception d'une requête de service en provenance d'un terminal de cet utilisateur, cette requête de service comprenant au moins une caractéristique d'une ressource média négociée par le terminal ; des moyens d'obtention d'au moins un identifiant d'un service associé dans ledit profil de l'utilisateur à un profil média contenant ladite au moins une caractéristique ; et des moyens de fourniture dudit au moins un identifiant de service obtenu à l'étape d'obtention à un dispositif participant au traitement de la requête de service. Le procédé de fourniture selon l'invention peut être mis en oeuvre en support de vérifications réalisées par le réseau IMS pour améliorer l'accès aux services élémentaires offerts par celui-ci ou par des réseaux en partenariat avec le réseau IMS. En effet, ce procédé présente un avantage notamment lorsque des informations manquent dans les requêtes émises par le terminal et contrôlées par le réseau IMS, et qu'il n'est pas possible sur la base des informations contenues dans ces requêtes d'identifier clairement quels sont les services élémentaires dont le terminal sollicite l'usage. Il arrive en effet, que certaines applications développées pour les réseaux IMS ne respectent pas totalement les recommandations de l'IETF et du standard 3GPP concernant notamment l'annonce des services élémentaires proposés par le réseau IMS dont elles font l'usage. Grâce aux informations stockées dans le profil de l'utilisateur conformément à l'invention, on peut déduire des ressources média négociées dans une session SDP d'une requête SIP, le ou les services élémentaires dont cette application va solliciter l'usage et informer dans les plus brefs délais les dispositifs chargés de ces services. Ce procédé de fourniture présente également un intérêt à la frontière entre deux réseaux où il est important de garantir l'information de service qu'entend utiliser un utilisateur.

Dans un mode particulier de réalisation, les différentes étapes du procédé d'obtention, des procédés de contrôle et/ou du procédé de fourniture sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé d'obtention, d'un procédé de contrôle ou d'un procédé de fourniture tel que décrit ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Selon un autre aspect, l'invention vise aussi un système de communications d'un réseau IMS comprenant : une base de données ou un serveur HSS conforme à l'invention ; et un serveur de contrôle selon l'invention apte à interroger cette base de données ou ce serveur HSS. Dans un mode particulier de réalisation, le serveur de contrôle est un serveur S-CSCF du réseau IMS. Dans un autre mode de réalisation, le système de communications comprend en outre une table regroupant une pluralité de profils média prédéfinis, chaque élément représentatif d'un profil média associé à un identifiant de service dans un profil utilisateur du serveur HSS étant un pointeur vers une entrée de cette table. Cette table peut être stockée dans le serveur HSS ou dans la base de données, ou en variante, dans le serveur de contrôle du réseau IMS. Le système de communications selon l'invention bénéficie des mêmes avantages que ceux cités précédemment pour la base de données et pour les serveurs de contrôle. On peut également envisager, dans d'autres modes de réalisation, que la base de données, le serveur HSS, le procédé d'obtention, les procédés de contrôle, le procédé de fourniture, le serveur de contrôle, les systèmes de contrôle, le système de communications, le programme d'ordinateur et le support d'enregistrement selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins et à l'annexe qui en illustrent des exemples de réalisation dépourvu de tout caractère limitatif : l'annexe illustre des exemples de profils média ; la figure 1, déjà décrite, représente le contenu d'un profil utilisateur maintenu par un serveur HSS d'un réseau IMS dans l'art antérieur ; la figure 2 représente, de façon schématique, un système de communications, un serveur de contrôle, un serveur HSS et une base de données conformes à l'invention, dans un mode particulier de réalisation ; la figure 3 illustre un exemple d'informations contenues dans la base de données de la figure 2, conformément à un mode particulier de réalisation de l'invention ; la figure 4 représente, de façon schématique, l'architecture matérielle du serveur de contrôle de la figure 1 ; la figure 5 illustre les principales étapes d'un procédé d'obtention selon l'invention, dans un mode de réalisation dans lequel il est mis en oeuvre par le serveur de contrôle de la figure 2 ; les figures 6 et 7 représentent les étapes principales de deux procédés de contrôle selon l'invention, mis en oeuvre par le serveur de contrôle de la figure 2, dans un mode particulier de réalisation ; et la figure 8 représente les principales étapes d'un procédé de fourniture selon l'invention, dans un mode de réalisation dans lequel il est mis en oeuvre par le serveur de contrôle de la figure 2. Description détaillée de l'invention La figure 2 représente, dans son environnement, un système de communications 1 d'un réseau 2 s'appuyant sur une architecture IMS, conforme à l'invention, dans un mode particulier de réalisation. De façon connue en soi, une architecture de réseau IMS s'appuie sur le protocole SIP pour l'initiation de sessions d'accès aux services proposés par le réseau IMS, et sur le protocole de description de session SDP pour la négociation de ressources média utilisées par le terminal lors de l'accès à ces services. Pour de plus amples détails sur les architectures de réseau IMS, on peut se reporter au document de spécification TS23.228 du standard 3GPP intitulé « IP Multimedia Subsystem ; Stage 2 », Release 9, septembre 2010, disponible sur le site www.3gpp.org. Par ailleurs, les protocoles SIP et SDP sont décrits plus en détails respectivement dans le document RFC 3261 complété par le document RFC 3265, et dans le document RFC 4566, édités par l'IETF. On suppose ici que le réseau IMS 2 met à disposition des terminaux qui sont enregistrés auprès de lui, divers services élémentaires connus en soi, tels que par exemple un service élémentaire de téléphonie multimédia, un service élémentaire de télévision sur IP (Internet Protocol), un service élémentaire de visio-conférence, un service élémentaire de messagerie instantanée, etc. Ces services élémentaires sont identifiés par des identifiants de service ou ICSI, notés Servldl, ServId2, Servld3, etc. Conformément à l'invention, le système de communications 1 comprend ici : - un serveur HSS 3 ; et - un serveur S-CSCF 4. Le serveur HSS 3 est un serveur HSS conforme à l'invention. Il intègre les caractéristiques et les fonctionnalités d'un serveur HSS tel que défini par le standard 3GPP, et comprend en outre une base de données 5 conforme à l'invention. Dans cette base de données 5 est stocké l'ensemble des profils des utilisateurs (User Profile) gérés par le réseau IMS 2, autrement dit, des utilisateurs qui ont souscrit à une offre de service auprès de l'opérateur du réseau IMS 2. On rappelle que conformément au standard 3GPP, chaque profil utilisateur contient diverses informations relatives à l'utilisateur, telles qu'une identité privée allouée à celui-ci, une ou plusieurs identités publiques associées à cette identité privée, et un ou plusieurs profils de service associés à ces identités publiques. Chaque profil de service comprend le cas échéant, dans un champ intitulé « Core Network Service Authorization » : - une liste d'identifiants (ICSI) de services auxquels l'utilisateur est autorisé par l'opérateur du réseau IMS à accéder, cette liste étant renseignée dans le champ Serviceld du profil de service ; et - un index identifiant un profil média (Media Profile) recensant les ressources média (i.e. les paramètres de session SDP), que l'utilisateur est autorisé à utiliser dans ses requêtes de service SIP (ex. valeurs de codecs, attributs SDP autorisés, etc.), cet index étant renseigné dans le champ SubscribedMediaProfileld. Dans la suite de la description, par souci de simplification, on suppose que chaque utilisateur bénéficie d'une seule identité privée et d'une seule identité publique allouées par le réseau IMS 2, et que chaque profil utilisateur ne contient qu'un seul profil de service.

Bien entendu, l'invention s'applique également lorsque plusieurs identités publiques sont allouées à l'identité privée de l'utilisateur et lorsque le profil utilisateur comprend plusieurs profils de service. Cette généralisation ne posant toutefois aucune difficulté à l'homme du métier, elle ne sera pas décrite plus en détails ici. Dans le mode de réalisation décrit ici, chacun des profils utilisateurs stockés dans la base de données 5 diffère d'un profil utilisateur tel que défini par le standard 3GPP (et décrit ci- dessus), en ce qu'il contient en outre, dans le champ « Core Network Service Authorization » du profil de service, un champ appelé ici « ServiceMediaProfileld » spécifique à chaque identifiant de service présent dans le champ Serviceld du profil de service. Ce champ est utilisé, conformément à l'invention, pour associer à chaque identifiant de service, un ou plusieurs éléments représentatifs de profils média sélectionnés pour ce service et pour l'utilisateur (c'est-à-dire, déterminés par l'opérateur lors du provisionnement de la base de données 5), ces profils média contenant des caractéristiques de ressources média autorisées pour ce service et cet utilisateur. Autrement dit, le champ ServiceMediaProfileld renseigne, pour chaque service identifié dans le champ Serviceld d'un profil de service extrait d'un profil utilisateur, les ressources média que l'utilisateur est en droit de négocier et d'utiliser lorsqu'il fait usage de ce service élémentaire en utilisant les identités publiques référencées dans le profil de service. Il convient de noter que dans le mode de réalisation décrit ici, le champ ServiceMediaProfileld est ajouté dans le profil utilisateur en complément du champ SubscribedMediaProfileld spécifié par le standard 3GPP. Toutefois, dans un autre mode de réalisation, on peut envisager de supprimer le champ SubscribedMediaProfileld du profil utilisateur et de ne conserver que le champ ServiceMediaProfileld proposé par l'invention. En outre, dans le mode de réalisation décrit ici, les éléments représentatifs des profils média sélectionnés pour un service donné et pour un utilisateur sont des valeurs entières, pointant vers des profils média prédéfinis et regroupés dans une table 6 accessible du réseau IMS 2. Autrement dit, chaque élément est un pointeur vers une entrée (ex. une ligne ou un élément) de la table 6. Cette table 6 est stockée ici au niveau du serveur HSS 3 pour faciliter la gestion de l'évolution des profils média. Les profils média stockés dans la table 6 se présentent sous la forme de listes ou d'ensembles référençant diverses caractéristiques de ressources média autorisées (ex. valeurs d'attributs SDP, codecs autorisés, débits autorisés, etc.). Des exemples de tels profils média pour des services audio, audio haute définition, transfert de fichiers et messagerie instantanée sont fournis en Annexe. Les valeurs retenues dans ces profils ne sont données qu'à titre illustratif, et dépendent bien entendu de la politique retenue par l'opérateur. En variante, les éléments représentatifs des profils média mémorisés dans le champ ServiceMediaProfileld peuvent être constitués par les profils média eux-mêmes. La figure 3 représente, à titre illustratif, des exemples de contenus des champs Serviceld et ServiceMediaProfileld compris dans un profil de service extrait d'un profil utilisateur géré par le serveur HSS 3. Selon ces exemples, pour le profil de service considéré, l'utilisateur est autorisé à solliciter l'usage de trois services élémentaires, identifiés respectivement par les identifiants de service ServIdl, ServId2 et ServId3.

En outre, il apparaît sur la figure 3 que l'identifiant de service ServId1 est associé à deux éléments représentatifs de deux profils média distincts identifiant les caractéristiques de ressources média autorisées pour l'utilisateur pour ce service Servldl. Ces éléments sont des pointeurs vers la 2ème et la 5ème entrées de la table 6 du serveur HSS 3. Ainsi à titre illustratif, si l'on suppose que l'identifiant de service ServId1 caractérise un service élémentaire de visioconférence, le pointeur de valeur « 2 » pointe par exemple vers un profil média « audio » stocké au niveau de la 2ème entrée de la table 6 et contenant les caractéristiques des ressources audio (ex. codec audio, débit autorisé, etc.) auxquelles pourra prétendre l'utilisateur lorsqu'il accèdera à ce service de visioconférence. De façon similaire, le pointeur de valeur « 5 » pointe par exemple vers un profil média « vidéo » stocké au niveau de la 5ème entrée de la table 6 contenant les caractéristiques des ressources vidéo (ex. qualité de l'image, etc.) auxquelles pourra prétendre l'utilisateur lorsqu'il accèdera à ce service de visioconférence. Sur la figure 3, l'identifiant de service ServId2 est, quant à lui, associé à un profil média de la table 6 représenté par le pointeur de valeur « 3 » et accessible via la 3ème entrée de la table 6. Enfin, l'identifiant de service ServId3 est associé aux profils média disponibles au niveau de la lère entrée et de la 6ème entrée de la table 6.

Il convient de noter que le champ ServiceMediaProfileld, associé à chaque identifiant de service référencé dans le profil de service d'un profil utilisateur, peut être fourni par l'opérateur du réseau IMS 2 par exemple lors de la souscription de l'utilisateur à une offre de service proposée par cet opérateur.

Différents critères peuvent être appliqués par l'opérateur du réseau IMS 2 pour sélectionner les profils média renseignés (fournis) dans le champ ServiceMediaProfileld de chaque identifiant de service. Ces profils média sont bien entendu avant tout sélectionnés en fonction du type de service(s) au(x)quel(s) ils sont associés (c'est-à-dire de la nature du service), i.e., les caractéristiques des ressources média (ex. valeurs de codecs, débits, attributs SDP, etc.) contenues dans un profil média sélectionné pour un identifiant d'un service doivent être adaptées pour participer à la fourniture de ce service. Outre la nature du service, l'opérateur peut également prendre en compte lors de sa sélection, des critères liés à l'offre de service en elle-même à laquelle a souscrit l'utilisateur (ex. tarifs de cette offre, prestations offertes dans le cadre de l'offre, etc.), des priorités ou avantages que l'opérateur souhaite offrir à l'utilisateur, des préférences de l'utilisateur, etc. L'invention permet ainsi via l'introduction de ce champ de discriminer les droits d'usage des services et des ressources média alloués à un utilisateur en fonction de cet utilisateur. Ainsi par exemple, pour un même service élémentaire de télévision sur IP référencé par l'identifiant de service ServId2, on pourra décider d'associer à l'identifiant ServId2 dans le profil d'un utilisateur A, un profil média « X-HD » recensant des ressources média (débits, qualité, etc.) permettant à l'utilisateur A d'accéder à une qualité de télévision Haute Définition (HD), tandis qu'on associera à l'identifiant ServId2, dans le profil d'un utilisateur B, un profil média « X-SD » recensant des ressources média permettant à l'utilisateur B d'accéder uniquement à une définition standard (SD, Standard Definition) de télévision. Comme mentionné précédemment, l'introduction de ce champ supplémentaire dans le profil utilisateur permet d'améliorer et de diversifier les contrôles et les vérifications que peut opérer le réseau IMS 2 sur les requêtes SIP émises par les terminaux. Dans le mode de réalisation décrit ici, ces contrôles sont mis en oeuvre par le serveur S-CSCF 4. Ce serveur S-CSCF 4 intègre les différentes caractéristiques et fonctionnalités d'un serveur S-CSCF tel que défini par le standard 3GPP ; il est notamment en charge des enregistrements des terminaux auprès du réseau IMS 2. Le serveur S-CSCF 4 intègre par ailleurs ici la logique de fonctionnement et les fonctionnalités d'un serveur et d'un système de contrôle conformes à l'invention.

Plus précisément, dans le mode de réalisation décrit ici, le serveur S-CSCF 4 dispose de l'architecture matérielle d'un ordinateur telle que représentée à la figure 4.

Il comporte notamment un processeur 4A, une mémoire vive 4B, une mémoire flash non volatile 4C, une mémoire morte 4D, ainsi que des moyens de communication 4E lui permettant de communiquer avec les équipements du réseau IMS 2 (et notamment le serveur HSS 3). Les moyens de communication 4E mettent en oeuvre ici le protocole SIP ainsi qu'une interface Diameter Cx dérivée de l'interface Diameter Cx telle que définie dans le standard 3GPP, c'est-à-dire adaptée de sorte à pouvoir obtenir le contenu du champ ServiceMediaProfileld et les profils média correspondants le cas échéant. Une telle adaptation ne présente pas de difficulté pour l'homme du métier, et ne sera donc pas décrite davantage ici. Ils permettent également au serveur S-CSCF 4 de communiquer avec des terminaux, tel que notamment le terminal 7 représenté sur la figure 2, dont les utilisateurs ont souscrit à une offre de service auprès de l'opérateur du réseau IMS 2, et dont les profils sont stockés dans la base de données 5 du serveur HSS 3. Ainsi on suppose ici que le profil de l'utilisateur du terminal 7 est stocké dans la base de données 5, et comporte, en association avec chaque identifiant de service renseigné (i.e. fourni) dans le champ Serviceld du profil de service de ce profil utilisateur, un ou plusieurs pointeurs vers un ou plusieurs profils média stockés dans la table 6, ces pointeurs étant fournis par l'intermédiaire du champ ServiceMediaProfileld. La mémoire morte 4D du serveur 4 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 4A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention. Ce programme d'ordinateur comporte ici d'une part des instructions pour l'exécution des étapes d'un procédé d'obtention selon l'invention décrites maintenant en référence à la figure 5, et d'autre part, des instructions pour l'exécution des étapes de procédés de contrôle et d'un procédé de fourniture selon l'invention décrites ultérieurement en référence aux figures 6 à 8.En référence à la figure 5, on suppose que le serveur S-CSCF 4 reçoit une requête SIP d'enregistrement du terminal 7 (étape E10). Cette requête est une requête SIP REGISTER contenant un identifiant public alloué au terminal 7. Le serveur S-CSCF 4 interroge la base de données 5 du serveur HSS 3 à l'aide de cet identifiant public (étape E20), en vue de télécharger le profil de l'utilisateur du terminal 7.

A cette fin, le serveur S-CSCF 4 utilise l'interface Diameter Cx adaptée mise en oeuvre par ses moyens de communication 4E. En réponse à cette interrogation, le serveur S-CSCF 4 obtient du serveur HSS 3, le profil de l'utilisateur du terminal 7 stocké dans la base de données 5 (étape E30). Ce profil de l'utilisateur du terminal 7 contient notamment, conformément à l'invention, les identifiants des services autorisés pour cet utilisateur, chaque identifiant de service étant associé à au moins un pointeur vers un profil média stocké dans la table 6, et sélectionné pour ce service et pour cet utilisateur, contenant des caractéristiques de ressources média autorisées pour ce service et pour cet utilisateur.

Le serveur HSS 3 fournit également au serveur S-CSCF 4 les profils média identifiés dans le profil de l'utilisateur et stockés dans la table 6. En variante, ces profils média sont fournis au serveur S-CSCF 4 sur réception d'une requête de celui-ci.

Dans le mode de réalisation décrit ici, la table 6 est stockée au niveau du serveur HSS 3 de sorte à faciliter la maintenance de cette table et l'ajout/la suppression de profils média dans cette table, et de sorte à permettre une répercussion plus simple et plus rapide de ces modifications apportées aux profils média (potentiellement dès le réenregistrement d'un terminal) vers l'ensemble des serveurs S-CSCF du réseau de l'opérateur.

Dans un autre mode de réalisation, la table 6 est stockée au niveau du serveur S-CSCF 4. Dans ce mode de réalisation alternatif, sur réception du profil de l'utilisateur, le serveur S-CSCF 4 interroge la table 6 afin d'obtenir les profils média associés aux identifiants de service contenus dans le profil de l'utilisateur. Le serveur S-CSCF 4 met ensuite en oeuvre les étapes classiques mises en oeuvre par un serveur S-CSCF lors de l'enregistrement d'un terminal. Ces étapes étant connues, elles ne seront pas décrites davantage ici. Le profil de l'utilisateur du terminal 7 et les profils média associés sont stockés par le serveur S-CSCF 4, par exemple dans sa mémoire flash 4C, dans un contexte d'enregistrement associé au terminal 7.

Dans l'exemple décrit ici, l'interrogation de la base de données 5 du serveur HSS 3 par le serveur S-CSCF 4 pour récupérer le profil de l'utilisateur du terminal 7 est déclenchée sur réception d'une requête d'enregistrement reçue du terminal 7. Toutefois, cette hypothèse n'est pas limitative, et d'autres requêtes peuvent déclencher l'interrogation de la base de données 5 du serveur HSS 3 par le serveur S-CSCF 4, comme notamment la réception d'une requête d'appel à destination d'un terminal non enregistré auprès du réseau IMS. Nous allons maintenant décrire, en référence aux figures 6 à 8, divers contrôles pouvant être réalisés par le serveur S-CSCF 4, en utilisant tout ou partie des informations contenues dans le profil de l'utilisateur du terminal 7 obtenu du serveur HSS 3 (ou de façon équivalente de la base de données 5) lors de l'étape préliminaire d'enregistrement de cet utilisateur. La figure 6 illustre un premier exemple de contrôle noté CP1, réalisé sur une requête de service SIP, telle que par exemple une requête de service SIP INVITE, reçue par le serveur SCSCF 4 en provenance du terminal 7 (étape F10). On suppose que cette requête de service SIP contient l'identifiant public alloué au terminal 7 ainsi - qu'un identifiant noté Servld d'un service élémentaire mis à disposition par le réseau 2 et sollicité (i.e. annoncé dans la requête de service) par le terminal 7, et - au moins une caractéristique de ressource média notée RESSMEDIA négociée par le terminal dans une session SDP de la requête de service (étape F20). Le serveur S-CSCF 4 consulte le profil de l'utilisateur du terminal 7 associé à l'identifiant public contenu dans la requête de service, et stocké dans sa mémoire 4C à l'aide de l'identifiant Servld (étape F30). Il obtient à partir de ce profil utilisateur, le (ou les) profil(s) média associé(s) au service correspondant à l'identifiant Servld (étape F40) et stocké(s) dans la mémoire 4C lors de l'enregistrement du terminal 7. Le serveur S-CSCF 4 contrôle alors la compatibilité de ce profil média avec les caractéristiques de ressources média RESSMEDIA contenues dans la requête SIP de service reçue du terminal 7 (étape test F50). Autrement dit, il vérifie que les caractéristiques de ressources média RESSMEDIA contenues dans la requête sont en accord, au vu de critères prédéfinis par l'opérateur du réseau IMS 2, avec les ressources média recensées dans le profil média obtenu à l'étape F40, autrement dit, aux ressources média autorisées pour l'utilisateur du terminal 7 lors de l'accès au service élémentaire Servld. Ainsi par exemple, les ressources média négociées par le terminal 7 dans la requête de service SIP seront considérées comme compatibles si elles correspondent à un sous-ensemble des ressources média identifiées dans le profil média associé au service Servld, ou si elles correspondent à des exigences inférieures à celles autorisées par le profil média associé au service Servld par exemple en termes de bande passante. Le cas échéant (réponse oui à l'étape test F50), le serveur S-CSCF 4 accepte la requête de service du terminal 7 (étape F60). En revanche, si les caractéristiques RESSMEDIA contenues dans la requête ne sont pas compatibles avec les ressources média recensées dans le profil média obtenu au cours de l'étape F40 (réponse non à l'étape test F60), la requête de service est rejetée par le serveur S-CSCF 4 (étape F70). En variante, dans un autre mode de réalisation de l'invention, si le serveur S-CSCF 4 détecte une incompatibilité entre les caractéristiques RESSMEDIA contenues dans la requête de service et les ressources média recensées dans le profil média obtenu à l'étape F40, il détermine si les caractéristiques RESSMEDIA ne peuvent pas être remplacées par des caractéristiques compatibles avec celles identifiées dans le profil média. Ainsi, par exemple, si l'incompatibilité porte sur la bande passante négociée, et que la bande passante négociée par le terminal 7 dans la requête de service est supérieure à la bande passante autorisée par le profil média, le serveur S-CSCF 4 accepte la requête de service SIP, mais réduit la bande passante négociée dans la requête de service à une valeur compatible avec la bande passante autorisée par le profil média.

Il convient de noter qu'une valeur compatible ne signifie pas nécessairement une valeur inférieure. L'opérateur du réseau IMS 2 peut en effet décider qu'une valeur compatible peut être deux fois supérieure à la valeur autorisée par le profil média. Dans ce premier exemple de contrôle, on suppose que le serveur S-CSCF 4 utilise l'identifiant de service Servld compris dans la requête de service provenant du terminal 7, pour contrôler que les ressources média RESSMEDIA négociées par le terminal 7 sont compatibles avec le profil média associé dans le profil de l'utilisateur du terminal 7 au service Servld. On peut en variante envisager que le serveur S-CSCF 4 utilise les caractéristiques média RESSMEDIA négociées dans la requête de service provenant du terminal 7, pour contrôler que le service ServID annoncé par le terminal 7 est compatible avec un identifiant de service associé dans le profil de l'utilisateur du terminal 7 à un profil média recensant les caractéristiques media RESSMEDIA ou tout du moins en accord avec ces caractéristiques média. Par ailleurs, dans l'exemple envisagé ici, la requête SIP de service sur laquelle est réalisé le contrôle CP1 comprend à la fois un identifiant de service et une session SDP dans laquelle des caractéristiques de ressources média sont négociées par le terminal. On peut toutefois envisager dans un autre exemple que ces informations parviennent au serveur S-CSCF 4 via deux requêtes distinctes, le procédé de contrôle CPi n'étant mis en oeuvre qu'après la réception de ces deux requêtes. On envisage maintenant, en référence à la figure 7, un second exemple de contrôle CP2 pouvant être réalisé par le serveur S-CSCF 4 sur réception d'une requête de service SIP en provenance du terminal 7 (étape G10). On suppose que cette requête de service SIP contient l'identifiant public alloué au terminal 7 ainsi qu'un identifiant Servld d'un service élémentaire mis à disposition par le réseau 2 et sollicité (i.e. annoncé dans la requête de service) par le terminal 7 (étape G20).

Le serveur S-CSCF 4 consulte le profil de l'utilisateur du terminal 7 stocké dans sa mémoire 4C et associé à l'identifiant public contenu dans la requête de service (étape G30). Il obtient à partir de ce profil utilisateur les identifiants des services autorisés pour l'utilisateur du terminal 7 (étape G40). Le serveur S-CSCF 4 contrôle alors la compatibilité de l'identifiant de service Servld contenu dans la requête de service avec les identifiants obtenus à l'étape G40 (étape test G50). Autrement dit ici, il vérifie que l'identifiant de service Servld figure parmi les identifiants de service obtenus en consultant le profil utilisateur. Le cas échéant, le serveur S-CSCF 4 accepte la requête de service SIP reçue du terminal 7 (étape G60).

En revanche, si l'identifiant de service Servld ne correspond pas à un identifiant de service présent dans le profil de l'utilisateur, le serveur S-CSCF 4 rejette la requête (étape G70). Nous allons maintenant décrire, en référence à la figure 8, un troisième exemple de contrôle CP3 pouvant être réalisé par le serveur S-CSCF 4 sur réception d'une requête de service SIP en provenance du terminal 7 ne contenant pas d'identifiant de service annoncé par le terminal 7 mais seulement une ou plusieurs caractéristiques média RESSMEDIA négociées par celui-ci. Ce troisième contrôle CP3 vise à déterminer et à fournir un identifiant de service correspondant aux caractéristiques de ressources média négociées dans la requête de service, de manière à anticiper l'accès à ce service afin d'optimiser le rendu de ce service. Cet identifiant de service peut être fourni à un dispositif du réseau IMS 2 ou à un dispositif d'un autre réseau avec lequel l'opérateur du réseau IMS 2 entretient des accords. L'invention permet alors de s'assurer que l'information de service est disponible à la frontière entre les deux réseaux.

On suppose donc que le serveur S-CSCF 4 reçoit une requête de service SIP en provenance du terminal 7 contenant l'identifiant public alloué au terminal 7 ainsi que des caractéristiques de ressources média RESSMEDIA négociées par le terminal 7 (étape H10). En revanche, cette requête ne contient pas d'identifiant de service annoncé par le terminal 7.

Sur détection de la présence des caractéristiques de ressources média RESSMEDIA dans la requête de service (étape H20), le serveur S-CSCF 4 consulte le profil de l'utilisateur du terminal 7 associé à l'identifiant public contenu dans cette requête, et stocké dans sa mémoire 4C (étape H30). Plus précisément ici, il recherche dans ce profil utilisateur au moins un identifiant d'un service autorisé pour l'utilisateur et associé à un ou plusieurs profils média dans le profil utilisateur contenant les caractéristiques média RESSMEDIA. On suppose ici que le serveur S-CSCF 4 obtient à l'issue de cette consultation au moins un identifiant d'un service Servld vérifiant cette condition (étape H40). Le serveur S-CSCF 4 fournit alors cet identifiant de service à un dispositif participant au traitement de la requête de service SIP (étape H50).

Dans le mode de réalisation décrit ici et les différents exemples envisagés, les informations contenues dans le profil utilisateur conformément à l'invention sont utilisées par le serveur S-CSCF 4 pour effectuer des contrôles et/ou des vérifications sur les requêtes de service SIP lui parvenant. Cette hypothèse n'est toutefois pas limitative : on pourrait en effet envisager que d'autres serveurs ou équipements du réseau IMS utilisent également ces informations.30 ANNEXE 10 Exemple de profil média pour un service « Audio » : Type de média : audio Codecs autorisés : G.711, G.729 Débit maximum autorisé : 64 Kb/s Exemple de profil média pour un service « Audio haute définition (HD) » : Type de média : audio Codecs autorisés : G.711, G.729, G.722, G.729.1 Exemple de profil média pour un service « Transfert de fichier » : Type de média : message Type de contenus autorisés : image/jpg, text/plain Direction : unidirectionnel Taille maximum : 1Mo Exemple de profil média pour un service « Messagerie Instantanée » : Type de média : message Type de contenus autorisés : message/cpim, text/plain Direction : bidirectionnel Débit maximum autorisé : 1kb/s

Claims (14)

1. REVENDICATIONS1. Base de données (5) accessible dans un réseau IMS (2), et comportant au moins un profil d'un utilisateur comprenant au moins un identifiant (ServId1, Servld2, Servld3) d'un service autorisé pour l'utilisateur, ladite base de données (5) étant caractérisée en ce que, dans le profil de l'utilisateur, chaque identifiant d'un service est associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service.
2. 2. Base de données selon la revendication 1 dans laquelle l'identifiant du service (Servldl, Servld2, Servld3) est associé audit au moins un élément représentatif d'un profil média par l'intermédiaire d'un champ prédéterminé du profil utilisateur.
3. 3. Base de données selon la revendication 1 dans laquelle chaque élément représentatif d'un profil média est un pointeur vers une entrée d'une table (6) regroupant une pluralité de profils média prédéfinis.
4. 4. Serveur HSS (3) d'un réseau IMS (2) dans lequel est stockée une base de données (5) accessible dans le réseau, cette base de données comportant au moins un profil d'un utilisateur comprenant au moins un identifiant d'un service autorisé pour l'utilisateur, ledit serveur HSS étant caractérisé en ce que, dans le profil de l'utilisateur, chaque identifiant d'un service est associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service.
5. 5. Serveur HSS (3) selon la revendication 4 comprenant une table (6) regroupant une pluralité de profils média prédéfinis et dans lequel chaque élément représentatif d'un profil média est un pointeur vers une entrée de cette table.
6. 6. Procédé d'obtention d'un profil d'un utilisateur par un serveur de contrôle (4) d'un réseau IMS (2), ledit réseau IMS comprenant une base de données (5) conforme à la revendication 1 ou un serveur HSS (3) conforme à la revendication 4, ledit procédé comprenant : une étape d'interrogation (E20) par ledit serveur de contrôle de ladite base de données ou dudit serveur HSS en utilisant un identifiant d'un utilisateur obtenu à partir d'une requête reçue par ce serveur de contrôle en provenance ou à destination d'un terminal de cet utilisateur ; une étape d'obtention (E30) par ledit serveur de contrôle, en réponse à cette étape d'interrogation, d'un profil de cet utilisateur comprenant au moins un identifiant d'un service autorisé pour cet utilisateur, chaque identifiant d'un service étant associé à au moins unélément représentatif d'un profil média sélectionné pour ce service, ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service.
7. 7. Procédé d'obtention selon la revendication 6 dans lequel la requête reçue du terminal est une requête d'enregistrement de ce terminal.
8. 8. Procédé d'obtention selon la revendication 6 comprenant en outre une étape d'obtention (E30) par le serveur de contrôle, en provenance de la base de données ou du serveur HSS, des profils média associés aux identifiants des services autorisés pour cet utilisateur compris dans le profil de cet utilisateur.
9. 9. Procédé d'obtention selon la revendication 6 comprenant en outre une étape d'obtention par le serveur de contrôle, à partir d'une table stockée par ce serveur de contrôle regroupant une pluralité de profils média prédéfinis, des profils média associés aux identifiants des services autorisés pour cet utilisateur compris dans le profil de cet utilisateur.
10. 10. Procédé de contrôle (CP1) d'un accès à un service par un terminal (7) d'un utilisateur, destiné à être mis en oeuvre dans un réseau IMS (2) comprenant une base de données (5) conforme à la revendication 1 ou un serveur HSS (3) conforme à la revendication 4, en utilisant tout ou partie d'un profil de l'utilisateur stocké dans cette base de données ou dans ce serveur HSS et obtenu au cours d'une étape préliminaire (E30) par un procédé d'obtention selon la revendication 6, ledit procédé de contrôle (CP1) comprenant une étape de réception (F10) d'au moins une requête de service en provenance d'un terminal de cet utilisateur contenant un identifiant d'un service (ServId) annoncé par le terminal et au moins une caractéristique d'une ressource média (RESSMEDIA) négociée par le terminal ; une étape d'obtention (F40) o d'un profil média associé à l'identifiant du service dans ledit profil de l'utilisateur ; ou o d'au moins un identifiant d'un service associé à un profil média contenant ladite au moins une caractéristique dans ledit profil de l'utilisateur ; et une étape de contrôle (F50) au cours de laquelle on vérifie la compatibilité avec le profil média ou ledit au moins un identifiant de service obtenu au cours de l'étape d'obtention, de l'identifiant du service ou de ladite au moins une caractéristique contenu(e) dans ladite au moins une requête de service reçue en provenance du terminal.
11. 11. Procédé de contrôle (CP1) selon la revendication 10 comprenant en outre une étape de rejet (F70) de ladite au moins une requête de service si au cours de l'étape de contrôle (F50), on détecte que l'identifiant du service ou ladite au moins une caractéristique contenu(e)dans ladite au moins une requête de service en provenance du terminal n'est pas compatible avec le profil média ou ledit au moins un identifiant de service obtenu au cours de l'étape d'obtention.
12. 12. Procédé de contrôle (CP2) d'un accès à un service par un utilisateur, destiné à être mis en oeuvre dans un réseau IMS (2) comprenant une base de données (5) conforme à la revendication 1 ou un serveur HSS (3) conforme à la revendication 4, en utilisant tout ou partie d'un profil de l'utilisateur stocké dans cette base de données ou dans ce serveur HSS et obtenu au cours d'une étape préliminaire (E30) par un procédé d'obtention selon la revendication 6, ledit procédé de contrôle comprenant : - une étape de réception (G10) d'une requête de service en provenance d'un terminal de cet utilisateur contenant un identifiant d'un service annoncé par le terminal ; - une étape d'obtention (G40) d'au moins un identifiant d'un service autorisé pour cet utilisateur contenu dans ledit profil de l'utilisateur ; et - une étape de contrôle (G50) au cours de laquelle on vérifie la compatibilité de l'identifiant du service contenu dans la requête de service reçue en provenance du terminal avec ledit au moins un identifiant d'un service obtenu au cours de l'étape d'obtention.
13. 13. Procédé de fourniture (CP3) par une entité (4) d'un réseau IMS (2) comprenant une base de données (5) conforme à la revendication 1 ou un serveur HSS (3) conforme à la revendication 4, d'un identifiant de service contenu dans un profil d'un utilisateur stocké dans cette base de données ou dans ce serveur HSS et obtenu au cours d'une étape préliminaire (E30) par un procédé d'obtention selon la revendication 6, ledit procédé de fourniture (CP3) comprenant : une étape de réception (H10) d'une requête de service en provenance d'un terminal (7) de cet utilisateur, ladite requête comprenant au moins une caractéristique d'une ressource média (RESSMEDIA) négociée par le terminal ; une étape d'obtention (H40) d'au moins un identifiant d'un service associé dans ledit profil de l'utilisateur à un profil média contenant ladite au moins une caractéristique ; et une étape de fourniture (H50) dudit au moins un identifiant de service obtenu à l'étape d'obtention à un dispositif participant au traitement de la requête de service.
14. 14. Serveur de contrôle (4) d'un réseau IMS (2), ledit réseau IMS comprenant une base de données (5) conforme à la revendication 1 ou un serveur HSS (3) conforme à la revendication 4, ledit serveur de contrôle comprenant : - des moyens d'interrogation de la base de données ou du serveur HSS en utilisant un identifiant d'un utilisateur obtenu à partir d'une requête reçue par le serveur en provenance d'un terminal de cet utilisateur ; - des moyens d'obtention, en réponse à cette étape d'interrogation, d'un profil de cet utilisateur comprenant au moins un identifiant d'un service autorisé pour cet utilisateur, chaque identifiantd'un service étant associé à au moins un élément représentatif d'un profil média sélectionné pour ce service, ce profil média contenant au moins une caractéristique de ressource média autorisée pour l'utilisateur pour ce service.5