FR 2889641 A1 20070209 FR 0508431 A 20050808 2889641 1 La présente invention concerne les infrastructures et équipements informatiques et les procédés de communication dans les réseaux de télécommunications tels que l'UMTS et plus particulièrement 1.'IMS qui est la partie du réseau UMTS destinée à fournir les services mutimédia sur IP. L'IMS est défini notamment dans les recommandations 3GPP TS 22.228, TS 23. 228 et TS 24.229. Les réseaux IMS sont fondés sur le protocole SIP (Session Initiation Protocol), lequel est décrit notamment dans IETF RFC 3261 (2002) qui est incorporé par référence et dans RFC 2543 (1999). Dans la suite, SIP désignera à la fois le protocole SIP et ses évolutions et dérivés. Le développement d'Internet et des réseaux de téléphonie mobile s'est accompagné d'une évolution des capacités des terminaux et des applications qui permettent désormais aux opérateurs d'offrir des services tels que par exemple la vidéoconférence. Les infrastructures correspondantes comportent des réseaux de plus en plus hétérogènes, filaires et non filaires, dans lesquels l'accès au coeur fondé sur IP (IP-based core network) peut être accompli de différentes manières en exploitant des technologies diverses telles que par exemple UTRAN, WLAN, xDSL, CATV, etc. Les utilisateurs s'attendent à ce que la qualité de service (Quality of Service ou QoS) qui leur est proposée par leurs opérateurs soit maintenue même lorsque les services sont obtenus en collaboration avec d'autres opérateurs. Une difficulté à assurer la qualité de service de bout en bout (End-toEnd) est liée au fait que les opérateurs des différents domaines sont susceptibles de configurer chacun leur réseau d'une manière qui leur est spécifique. Pour surmonter cette difficulté, les réseaux de troisième génération proposent une infrastructure permettant un contrôle automatique de leur comportement afin d'assurer la coordination entre les différents opérateurs, une telle infrastructure étant dite contrôlée par politiques (policy-based networks). La figure 1 représente un exemple d'infrastructure IMS connue dans laquelle les routeurs d'accès (Access Routers ou AR), des réseaux d'accès au coeur de réseau (core network) sont contrôlés par une fonction de prise de décision (Policy Decision Function ou 2889641 2 PDF) du coeur de réseau, qui applique des règles contenues dans un répertoire de politiques (policy repository). Au moins un proxy P-CSCF (Cali Session Control Function) est prévu dans le coeur du réseau pour établir la session et préparer les services requis en fonction des caractéristiques de la session. Ce proxy P'-CSCF peut communiquer avec un GGSN d'au moins un réseau UTRAN, qui agit en tant que point d'application de la politique (Policy Enforcement Point ou PEP) pour ce réseau, par l'intermédiaire de l'interface Go. Les règles de politiques décrivent notamment les ressources requises pour différents services multimédia et peuvent concerner la configuration du réseau, incluant la qualité de service, les SLA, les réseaux privés virtuels (Virtual Private Network ou VPN) et les politiques de sécurité. Un inconvénient de l'infrastructure représentée à la figure 1 est que le répertoire de politiques appartient au coeur de réseau, et ne tient pas compte des politiques des réseaux d'accès non UTRAN, ni des politiques des réseaux d'accès où se trouve l'utilisateur appelé. De plus, en cas de conflit entre une qualité de service demandée par un utilisateur d'un réseau d'accès et celle susceptible d'être offerte compte tenu des ressources disponibles, une requête d'initiation de la session pourra être propagée dans le coeur du réseau avant d'être refusée. Dans un exemple, un premier utilisateur envoie à un deuxième utilisateur d'un autre domaine un message INVITE incluant les champs suivants: User Class: Silver Service: Video Phony QoS clans good Le P-CSCF dans le coeur du réseau reçoit la requête et si celle-ci n'entre pas en conflit avec les politiques définies dans le coeur du réseau, cette requête sera admise. Lorsque le deuxième utilisateur reçoit cette requête, il répond par un message OK et le premier utilisateur commence à réserver les ressources dans le bearer level. Une requête est émise par le GGSN dans le contexte du PDP pour demander au routeur du domaine du premier utilisateur de réserver les ressources. A supposer que ce domaine ne dispose pas des ressources requises, cette requête sera refusée. 2889641 3 Ainsi, le conflit n'est détecté qu'après que deux messages SIP aient été échangés et que la procédure de réservation des ressources ait commencé. La charge globale de signalisation est ainsi alourdie et un délai a été généré avant que l'utilisateur ne soit informé de l'impossibilité d'établir la session comme attendu initialement. Dans un autre exemple, le premier utilisateur envoie à un deuxième utilisateur du réseau UMTS un message INVITE incluant les champs comme cidessus et le P-CSCF interroge le répertoire des règles de politiques de l'UMTS pour savoir s'il y a conflit: Time & Date: - Validation Duration: - For Silver Subscription Class: É Video is supported for classes On suppose que la requête n'entre pas en conflit avec les politiques locales de l'UMTS mais que le deuxième domaine n'est pas informé des limitations concernant TI et SI pour ce service dans le domaine du premier utilisateur. Dans ce cas, les mêmes TI et SI ne seront pas choisis dans les deux domaines et les réseaux seront configurés différemment, ce qui entraîne une perte d'efficacité. Il existe par conséquent un besoin pour améliorer encore l'infrastructure des réseaux contrôlés par politiques, afin notamment de faciliter l'exécution des politiques. Il existe également un besoin 'pour réduire la charge globale de signalisation et les délais de détection d'un conflit entre une qualité de service demandée et les ressources disponibles. La demande EP 1 250 023 cherche à fournir la même qualité de service dans le bearer level des réseaux visités. Cette demande ne divulgue pas de procédé de négociation flexible des politiques, car le réseau home transfert ses politiques au réseau visité. Selon un premier de ses aspects, l'invention a pour objet une infrastructure IMS contrôlée par politiques, comportant au moins un réseau d'accès à un coeur de réseau, le coeur de réseau exerçant une fonction de prise de décision appliquant des règles de 2889641 4 politiques contenues dans un répertoire de politiques, infrastructure dans laquelle le réseau d'accès est agencé pour permettre l'application de règles de politiques contenues dans au moins un répertoire local et/ou dans au moins un répertoire externe au coeur de réseau. Grâce à l'invention, l'application des règles de politiques est facilitée puisque les opérateurs des réseaux d'accès n'ont plus à placer les règles de politiques dans un répertoire de politiques contrôlé par le coeur de réseau. L'invention peut permettre une coordination des politiques dans le bearer level entre différents domaines. L'invention peut également permettre à différents réseaux de comparer leurs politiques et en cas de conflit d'informer l'utilisateur très tôt dans la phase d'établissement de la session et de permettre, si l'utilisateur souhaite continuer, que les ressources les plus cohérentes soient réservées dans les différents domaines. Par coeur de réseau , encore appelé tore network, on désigne la partie de réseau située en amont du réseau d'accès. Le coeur du réseau comporte par exemple les entités fonctionnelles SGSN, GGSN, P-SCSF, I-CSCF, S-CSCF, HSS. Le coeur de réseau peut être constitué par une architecture nationale transportant le trafic agrégé provenant de tous les services de ville en ville et dans les villes, jusqu'à la frontière du réseau où les réseaux d'accès transportent ensuite le trafic destiné aux utilisateurs terminaux à leur domicile ou lieu de travail. La partie commutée (Switching part) de l'UMTS (incluant SGSN, GGSN et l'IMS) est un exemple de coeur de réseau, fournissant le contrôle d'appel et les fonctions de mobilité et de sécurité de haut niveau, telles que la mise à jour de la localisation et l'authentification. Par réseau d'accès , encore appelé access network, on désigne les éléments permettant à l'utilisateur d'accéder au coeur de réseau. Un réseau d'accès comporte par exemple RNC, Node B, BTS, BSC. Par utilisateur , on désigne 'par exemple un ordinateur personnel, la gateway d'un réseau privé, un téléphone mobile, un assistant personnel numérique, un visiophone, un SIP-Phone, un client SIP résidant sur un ordinateur, cette liste n'étant pas limitative. Dans un exemple de mise en oeuvre de l'invention, l'un au moins des réseaux d'accès exerce une fonction locale de prise de décision qui applique des règles de politiques contenues dans un répertoire de politiques externe à ce réseau d'accès, ce 2889641 5 répertoire de politiques externe pouvant avantageusement être commun à plusieurs réseaux d'accès. Le contrôle d'au moins un routeur d'accès au coeur de réseau peut être effectué par la fonction locale de prise de décision. Selon un autre exemple de mise en oeuvre de l'invention, l'un au moins des réseaux d'accès comporte un répertoire local de politiques, et la fonction de prise de décision du coeur de réseau applique des politiques contenues dans ce répertoire local pour contrôler un routeur d'accès de ce réseau d'accès au coeur de réseau. La fonction de prise de décision du coeur de réseau peut ainsi contrôler des routeurs d'accès au coeur de réseau de plusieurs réseaux d'accès. Le coeur de réseau peut comporter un serveur proxy P-CSCF qui applique les politiques décidées par la fonction de prise de décision du coeur de réseau. Dans de telles infrastructures, la signalisation entre les réseaux d'accès et le coeur de réseau s'effectue avantageusement au moins partiellement selon le protocole SIP. L'infrastructure est avantageusement agencée de telle sorte qu'en cas de conflit entre une requête correspondant à des ressources demandées et des ressources disponibles, la requête soit refusée dans une phase de signalisation avant que l'infrastructure ne cherche à réserver effectivement les ressources. Dans un exemple de mise en oeuvre de l'invention, l'utilisateur peut envoyer un message SIP comportant au moins une information concernant la qualité de service demandée et/ou des paramètres de trafic (Traffic Information ou IT) et/ou de sécurité (Sensitivity Information ou SI) en tant qu'extension SIP, non encapsulée dans SDP. Cette information est avantageusement analysée par au moins un proxy SIP du réseau d'accès, qui peut ainsi bloquer la requête en cas de conflit avec les ressources disponibles et ne pas la propager au coeur de réseau. Dans le cas où le réseau d'accès ne comporte pas de proxy SIP capable d'analyser la requête, le conflit pourra n'être détecté que dans le coeur de réseau. Néanmoins, cette détection peut avantageusement s'effectuer au niveau de la signalisation, avant que le réseau ne cherche à réserver les ressources, ce qui permet de diminuer la charge globale de signalisation et peut permettre d'informer plus rapidement l'utilisateur du rejet de la requête. 2889641 6 L'invention a encore pour objet un réseau d'accès à une infrastructure IMS contrôlée par politiques, le réseau d'accès comportant un routeur d'accès à un coeur de réseau, le réseau d'accès comportant: une fonction locale de prise de décision appliquant des règles de politiques 5 contenues dans un répertoire de politiques externe au coeur de réseau et contrôlant le routeur d'accès, ou - un répertoire local de politiques que peut appliquer une fonction de prise de décision du coeur de réseau contrôlant le routeur d'accès. L'invention a encore pour objet un procédé de contrôle par politiques d'une infrastructure IMS comportant un coeur de réseau et des réseaux d'accès à ce coeur de réseau, le coeur de réseau exerçant une fonction de prise de décision en appliquant des règles de politiques contenues dans un répertoire de politiques, procédé dans lequel: - le coeur de réseau applique, pour contrôler le routeur d'accès d'un réseau d'accès, des règles de politiques contenues dans un répertoire local de politiques de ce réseau d'accès, et/ou - le réseau d'accès exerce une fonction locale de prise de décision en appliquant des règles de politique contenues dans un répertoire de politiques externe au coeur de réseau. Plusieurs réseaux d'accès peuvent ainsi appliquer des règles de politiques contenues dans un répertoire de politiques commun à plusieurs réseaux d'accès. La fonction locale de prise de décision d'un réseau d'accès peut contrôler le routeur d'accès au coeur de réseau. Un réseau d'accès comporte avantageusement un proxy SIP agencé pour détecter un conflit entre une requête provenant d'un utilisateur de ce réseau et des 25 ressources disponibles. Cette détection peut s'effectuer par exemple par analyse d'un message SIP provenant de l'utilisateur, tel qu'un message INVITE comportant une extension TI et SI renseignant par exemple sur le niveau de qualité de service requis par l'utilisateur. La fonction de prise de décision du coeur de réseau peut avantageusement appliquer des règles de politiques contenues dans des répertoires locaux de politiques propres à différents réseaux d'accès et contrôler les routeurs d'accès de ces réseaux d'accès. 2889641 7 Par ailleurs, en ce moment, on assiste à une hétérogénéité des terminaux qui peuvent se connecter à l'IMS. Même au sein d'une même classe de terminaux (par exemple celle des terminaux mobiles), on assiste à une divergence de plus en plus marquante au niveau des capacités matérielles (taille d'écran, type de clavier, vitesse du processeur) et logicielles (système d'exploitation, applications installées). Les préférences de l'utilisateur contribuent également à cette hétérogénéité (par exemple la désactivation de la fonction vidéo afin d'économiser la batterie du terminal). Il existe plusieurs applications qui peuvent bénéficier de l'indication des capacités des terminaux. Ainsi, un utilisateur qui établit la session souhaite ne voir sur son écran que les options correspondant aux possibilités réellement offertes par le terminal de l'autre utilisateur. Par exemple, si le deuxième utilisateur a désactivé la fonction vidéo, ou n'en dispose pas, il est souhaitable que l'option correspondante ne soit pas proposée au premier utilisateur au moment de l'établissement de la session et soit par exemple désactivée et affichée en grisé. Le besoin d'indiquer au réseau les capacités des terminaux a déjà été abordé par le 3GPP dans quelques-unes de ses spécifications techniques, notamment TS 22.101 (aspects de service dans le 3G) ou TS 22.2:28 (exigences de services pour le coeur de réseau multimédia IP), incorporées ici par référence. Les capacités des terminaux peuvent être classées en deux catégories, à savoir: - d'une part les capacités matérielles qui sont liées à la structure matérielle du terminal, et - d'autre part les capacités logicielles qui sont les capacités telles que le type du système d'exploitation, les applications existantes, le profil d'utilisateur, etc. Parmi les capacités matérielles, on peut citer les caractéristiques d'affichage (taille et couleurs), les caractéristiques du clavier, les capacités audio et vidéo, les capacités de mémoire (RAM, disque dur), les commandes proactives supportées par le terminal, le profil Bluetooth (Bluetooth Profile tel que défini dans la spécification Bluetooth), le nombre de bits par pixel, la référence du CPU (par exemple Pentium III ou PowerPc 750), la possibilité d'afficher des images, les caractères acceptés pour l'entrée de texte ou l'affichage (par exemple US-ASCII, ISO8859-1 ou SHIFT-IIS), les types de claviers acceptés (par exemple Disanbiguating , Qwerty ou Phonekeypad ), le nombre de 2889641 8 soft keys sur le terminal, le facteur de forme des pixels (rapport entre la largeur et la hauteur du pixel), la résolution du pointeur et la possibilité ou non de reconnaissance vocale, entre autres. Diverses propositions ont été soumises au 3GPP pour tenter de résoudre le problème de la signalisation des capacités de terminaux. Le standard RFC3840 propose ainsi un mécanisme de signalisation des capacités de terminaux fondé sur le protocole SIP. Toutefois, il n'existe à ce jour. à la connaissance de la demanderesse, pas de solution entièrement satisfaisante au problème de la signalisation des capacités des terminaux. WO 03/10327 traite d'un problème très spécifique qui est l'adaptation du contenu des messages à un terminal de téléphonie mobile. Des informations de capacités sont communiquées du terminal vers le réseau, lequel est le seul et unique utilisateur de ces informations. Dans cette demande, un terminal ou un service ne demande pas au réseau des informations sur les capacités d'un autre terminal. Or, il existe de nombreux cas où un terminal peut bénéficier des informations de capacités d'un autre terminal, afin de permettre par exemple une prévisualisation des capacités, donner des informations complémentaires sur le destinataire ou permettre un service Presence enrichi. Il existe également de nombreux cas où une application gagne à demander des informations de capacités à l'utilisateur pour fournir un meilleur service à celui-ci. L'invention vise, selon un deuxième de ses aspects, indépendant du premier ou pouvant se combiner avec celui-ci, à améliorer la signalisation des capacités de terminaux pendant l'exécution de services. L'invention a ainsi pour objet un procédé d'établissement d'une session dans une infrastructure IMS par au moins un utilisateur ayant un terminal ayant des capacités matérielles propres, dans lequel un message SIP est envoyé par ce terminal et contient au moins une information représentative d'au moins trois paramètres décrivant des capacités matérielles du terminal. Le message avantageusement utilisé par ce terminal pour communiquer ces capacités est le message PUBLISH. Les observateurs qui surveillent ces capacités peuvent recevoir les informations correspondantes à travers le message NOTIFY, mais ils doivent souscrire au préalable à ces informations à travers le message SUBSCRIBE. Cela peut 2889641 9 assurer une comptabilité avec le service Presence tel qu'il a été décrit dans les spécifications 3GPP TS 23.141 et 3GPP TS 24.141, incorporées ici par référence. D'autres messages SIP peuvent être utilisés pour véhiculer les informations de capacités comme les requêtes INVITE, REGISTER et la réponse OK au message OPTIONS. Une en-tête peut être ajoutée à ces messages SIP pour indiquer que leur corps comporte des informations de capacités de terminaux, notamment les capacités matérielles. L'architecture selon l'invention peut comporter au moins un observateur agencé pour observer les capacités d'un ou de plusieurs terminaux et notamment au moins trois paramètres décrivant les capacités matérielles du terminal. Cet observateur peut être un utilisateur ou bien un service résidant dans un serveur d'application. L'observateur peut appliquer au moins un filtre permettant de définir les sous-ensembles des informations de capacités qu'il souhaite recevoir, ce filtre étant véhiculé pendant la phase de souscription à ces informations. L'infrastructure comporte avantageusement un serveur TC Server agencé pour stocker et gérer des informations sur les capacités des terminaux et notamment pour recevoir des terminaux des informations concernant les capacités et pour permettre à au moins un équipement observateur de demander ou de recevoir toute ou partie de ces informations. L'invention a encore pour objet un terminal utilisant le protocole de signalisation SIP, comportant un agent utilisateur agencé pour envoyer un message SIP comportant au moins une information représentative d'au moins trois paramètres décrivant des capacités matérielles du terminal. Ces informations peuvent être encapsulées dans le corps des messages SIP déjà 25 désignés pour la communication de ces informations. Le terminal peut être agencé pour envoyer une information représentative d'un changement desdits paramètres par rapport à des valeurs par défaut. En variante, le message envoyé par le terminal peut comporter les valeurs de l'intégralité ou d'un sous-ensemble desdits paramètres (ou attributs) ou un lien vers un profil stocké sur au moins un serveur externe renseignant sur les valeurs d'au moins certains desdits paramètres. Les valeurs envoyées pendant les mises à jour peuvent se substituer aux valeurs par défaut communiquées par le(s) serveur(s) externe(s). 2889641 10 L'invention pourra être mieux comprise à la lecture de la description détaillée qui va suivre, d'exemples de mise en oeuvre non limsitatifs de celle-ci, et à l'examen du dessin annexé, sur lequel: - la figure 1, précédemment décrite, représente un exemple d'infrastructure IMS connue, régie par politiques, - les figures 2 et 3 représentent deux exemples d'architectures réalisées conformément à un aspect de l'invention, - les figures 4 et 5 représentent des exemples d'architecture selon un autre aspect de l'invention, - la figure 6 illustre un échange de messages concernant les capacités de terminaux. On a représenté à la figure 2 un exemple d'infrastructure IMS comportant un coeur de réseau 10 (core network) et plusieurs réseaux d'accès 11, 12 et 13 à ce coeur de réseau, les réseaux 11 et 12 étant en l'espèce des réseaux non UTRAN et le réseau 13 un réseau UTRAN. Les réseaux d'accès 11 et 12 possèdent au moins un routeur d'accès au coeur de réseau (Access Router ou AR). Chaque réseau d'accès 11, 12 comporte dans cet exemple une fonction locale de prise de décision (Local Policy Decision Function ou LPDF) qui applique des règles de politiques contenues dans un répertoire de politiques commun 16, externe au coeur de réseau 10 ainsi qu'au réseau d'accès dans l'exemple considéré. Le coeur de réseau 10 peut également exercer une fonction de prise de décision PDF en appliquant des règles de politiques contenues dans le répertoire de politiques 16 et peut contrôler un proxy P-CSCF ainsi que le GGSN du réseau 13. Dans une telle architecture, pour les applications utilisant le protocole de signalisation SIP, la fonction de prise de décision locale LPDF peut avantageusement supporter le protocole de signalisation SIP et agir comme un proxy SIP pour l'application des politiques, de sorte que cette architecture convient plus particulièrement aux réseaux d'accès qui ont déjà un proxy SIP pour leurs services locaux, indépendamment de leur connexion au coeur de réseau. Dans l'architecture de la f i g u r e 3, les réseaux d'accès 1 l et 12 comportent un répertoire local 17 de politiques dont les règles sont appliquées par une fonction de prise de 2889641 11 décision partagée SPDF (Shared Policy Decision Function) du coeur de réseau 10, lequel peut également avoir un répertoire de politiques 18 qui lui est propre. Dans une telle architecture, la session de signalisation dans les réseaux d'accès n'a pas à être supportée par ceux-ci, ce qui permet de diminuer le coût. La fonction de prise de décision partagée SPDF peut contrôler les routeurs d'accès de tous les réseaux d'accès. Avantageusement, des extensions au protocole SIP sont définies pour faciliter la coordination entre les niveaux d'erreurs et applications pour la réservation des ressources et permettre à l'utilisateur d'exprimer exactement les paramètres QoS requis. Ces extensions peuvent notamment comporter des informations de trafic et de sécurité, notamment TI et SI. Le terminal utilisateur est avantageusement agencé pour adresser, après l'enregistrement un message tel qu'INVITE comportant une extension SI et TI renseignant sur le niveau de qualité de service requis par l'utilisateur. L'extension TI caractérise le type de trafic assorti au codec (bande passante, taille de paquets) et SI définit les paramètres tels que le délai bout à bout, la gigue et le taux maximal de perte de paquets. Dans l'infrastructure de la figure 2, le message INVITE est analysé par le proxy SIP exécutant la fonction de prise de décision locale LPDF et le réseau d'accès peut déterminer par consultation du répertoire 16 si la qualité de service demandée correspond à des ressources négociées avec les autres opérateurs. Le proxy SIP peut éventuellement être agencé pour modifier et/ou mettre à jour la qualité de service demandée en fonction des nouvelles règles politiques négociées avec les autres opérateurs. Le fait que le proxy SIP local soit informé de la qualité de service requise par l'utilisateur peut permettre également de ne pas adresser à cet utilisateur des sessions que le terminal enregistré ne permet pas d'ouvrir. Par exemple, un utilisateur peut bénéficier auprès d'un opérateur d'un abonnement permettant de recevoir de la vidéo mais peut être dans une situation particulière où il s'est enregistré avec un terminal qui ne permet pas la vidéo. Lorsque le proxy SIP de son réseau d'accès reçoit un appel vidéo qui lui est destiné, l'appelant pourra être informé qu'il est nécessaire de modifier les caractéristiques de la session avant que 2889641 12 l'appelé ne soit informé de l'appel. La charge globale de signalisation peut s'en trouver réduite. Dans un autre exemple, on suppose qu'un premier utilisateur d'un premier domaine envoie le message INVITE avec les champs suivants, à un deuxième utilisateur 5 d'un deuxième domaine: User Class: Silver Service: Video Phony QoS Class: good. La question de prise de décision locale de l'infrastructure de la figure 2 peut 10 interroger le répertoire 16 pour vérifier si cette requête entre en conflit avec les politiques du premier domaine: Time & Date: Validation Duration: For Silver Subscription Class: É Video is supported for classes Dans le cas d'un conflit entre le niveau de service demandé et les politiques du premier domaine, la fonction LPDF peut renvoyer un message d'erreur indiquant la limite du niveau de service. Le conflit est détecté de façon précoce dans le premier domaine. Dans le cas de l'infrastructure de la figure 3, à supposer que le premier utilisateur envoie le même message, le P-CSCF pourra interroger les répertoires des politiques dans les premier et deuxième domaines pour vérifier s'il y a conflit. Politiques du premier domaine: Time & Date: Validation Duration: For Silver Class: É Video is supported only in semiacceptable class 2889641 13 É TI Max Packet Size= , Codecs= , Max Bandwith= É SI: Max Packet Loss= Max Delay Jitter= Max End to End. Politiques du deuxième domaine: Time & Date: - Validation Durat.ion: For Silver Class: É Video is supported only in classes É SI: Max Packet Loss= ... Max Delay Jitter= Max End to End Delay= ... Il y a conflit entre la classe QoS demandée et les politiques du premier domaine et le P-CSCF renvoie un message d'erreur indiquant la limite du niveau de service au premier utilisateur. Le conflit a pu là encore être détecté de façon précoce. Dans un autre exemple concernant l'infrastructure de la figure 2, on suppose 20 encore que le premier utilisateur envoie le même message que ci-dessus. La fonction de prise de décision locale LPDF vérifie s'il y a conflit avec les politiques du premier domaine: Time & Date: Validation Duration: - For Silver Subscription Class: É Video is supported only in classes Le P-CSCF vérifie si les valeurs de TI et SI dans le premier domaine et dans le deuxième domaine sont compatibles et si elles sont ajustables ne pourra pas choisir TI et SI 5 moins bons que ce qui est indiqué par le premier domaine. Ainsi, des TI et SI adaptés sont choisis pour les deux domaines et la communication peut s'effectuer de façon satisfaisante à travers des réseaux hétérogènes. Dans l'infrastructure de la figure 3, le même message du premier utilisateur amène le P-CSCF à interroger les répertoires des premier et deuxième domaines pour déterminer s'il y a conflit. Politiques du premier domaine: Time & Date: - Validation Duration: For Silver Class: É Video is supported only in semi-acceptable class É TI Max Packet Size= , Codecs= Max Bandwith= É SI: Max Packet Loss= Max Delay Jitter= Max End to End. Politiques du deuxième domaine: Time & Date: - Validation Duration: For Silver Class: É Video is supported only in classes É SI: Max Packet Loss= Max Delay Jitter= Max End to End Delay= ... 20 25 30 2889641 15 En l'absence de conflit, le P-CSCF applique les règles de politiques pour ces domaines et vérifie que ces TI et SI sont compatibles et s'ils sont ajustables ne choisira pas des valeurs moins bonnes que ce qui est indiqué par le premier domaine. Le même résultat que ci-dessus est atteint. L'infrastructure représentée à la figure 4 vise plus particulièrement à améliorer la signalisation des capacités de terminaux. Cette infrastructure comporte un serveur 20 appelé Terminal Capabilities server ou TC server qui est un serveur d'application SIP chargé de stocker et gérer des informations sur les capacités des terminaux, notamment des paramètres décrivant des capacités matérielles de ceux-ci, ainsi de préférence, que des paramètres décrivant des capacités logicielles. Ce serveur 20 est agencé pour synthétiser des informations sur les capacités d'un terminal à partir des informations qu'il reçoit de l'agent utilisateur correspondant (TC user Agent 23) et d'un ou de plusieurs agents externes 25. Il permet à des observateurs (watchers 28) de demander et de recevoir tout ou partie de ces informations. L'observateur (watcher 28) est par exemple une application chargée de récupérer les informations sur les capacités d'un terminal. Il peut définir le sous-ensemble des informations qu'il souhaite recevoir à travers un filtre véhiculé pendant la phase de souscription à ces informations. Le serveur 20 est avantageusement agencé pour générer des notifications partielles vers l'observateur 28. Ces notifications peuvent contenir des informations sur les capacités qui ont été modifiées depuis la dernière notification envoyée à cet observateur. L'observateur 28 peut définir des critères spécifiant quand les notifications seront envoyées, par exemple lorsque le moyen de communication avec un terminal change. Avant d'accepter de transmettre à un observateur des informations sur les capacités d'un terminal, le serveur 20 peut essayer de vérifier son identité, sauf si cet observateur veut être anonyme. Si cette procédure échoue, une notification peut être générée par le serveur 20 vers l'utilisateur du terminal concerné. Le serveur 20 est avantageusement agencé pour gérer des politiques d'autorisation de transmission d'informations concernant les capacités des terminaux en déterminant les observateurs qui sont autorisés à recevoir des informations concernant un terminal particulier ainsi que les sous-ensembles d'informations qu'ils peuvent recevoir. 2889641 16 Les politiques d'autorisation de transmission d'informations peuvent être fournies par l'agent utilisateur ou par l'opérateur du réseau. Le serveur 20 peut encore être agencé pour recueillir des informations sur les observateurs des capacités d'un terminal particulier afin de les communiquer à l'utilisateur de ce terminal, ces informations pouvant être l'identité de l'observateur, la date de la transmission d'information, son état et sa durée. L'agent utilisateur 22 du terminal sert à collecter les informations sur les capacités à partir du terminal lui-même et réside dans celui-ci, notamment dans le module ISIM. Cet agent utilisateur 22 est agencé pour envoyer les informations au serveur 20, soit à travers un proxy 23 sur le point de référence TCep, soit sur le point de référence TCeu. Il est agencé pour assembler les informations sur les capacités, notamment physiques, selon un format défini pour ces points de références. L'infrastructure de la figure 4 comporte encore un agent externe 25 des capacités du terminal appelé TC External Agent, qui est agencé pour récupérer des informations de capacités à partir d'au moins un serveur 26 se trouvant dans un réseau externe, tel qu'un serveur appartenant à un fabricant de terminaux ou de périphériques, à un développeur d'applications ou d'un système d'exploitation, etc. Cet agent externe 25 est agencé pour communiquer avec les serveurs concernés en utilisant les protocoles qu'ils supportent et peut envoyer les informations concernant les capacités au serveur 20 selon un format compatible avec le point de référence TCex. Il peut être responsable de la gestion des problèmes d'interopérabilité et de sécurité avec les réseaux externes et peut avoir en outre la fonctionnalité de localiser le serveur 20 associé à un terminal utilisateur. Le proxy observateur encore appelé watcher proxy est chargé, entre autres, des fonctions suivantes: - résolutation d'adresses et identification du réseau associé à l'utilisateur dont les capacités de terminal sont à observer, - authentification des observateurs, -génération des informations de facturation concernant les requêtes de l'observateur. 2889641 17 Le proxy 23 désigné par TC proxy peut être chargé entre autres des fonctions suivantes: détermination de l'identité et de l'emplacement du TC server associé à un utilisateur, - authentification du watcher Proxy (en particulier lorsqu'il se trouve dans un réseau externe), authentification de l'agent utilisateur 22, - génération des informations de facturation concernant les mises à jour des informations de capacités. L'infrastructure de la figure 4 peut comporter un serveur 29 encore appelé Terminal Capabilities List Server qui est un serveur d'application SIP chargé de stocker des listes d'utilisateurs observés, permettant ainsi aux applications observatrices de recevoir des informations sur les capacités de plusieurs terminaux à l'aide d'une seule requête SUBSCRIBE. Il peut également stocker les filtres créés par ces applications et permettant de définir les terminaux (utilisateurs) qu'elles veulent observer. Le point de référence TCen permet aux agents utilisateurs 22 de gérer leurs politiques d'autorisation de souscription sur le serveur 20. Il peut utiliser les capacités du point de référence Ut. Le point de référence TCex permet à l'agent externe de communiquer des informations de capacités obtenues à partir des réseaux externes au serveur 20. Il peut offrir à ce serveur 20 la possibilité de récupérer les informations sur demande, de façon périodique ou bien suite à une transmission d'informations liées aux modifications des capacités. Ce point de référence peut permettre à l'agent externe 25 de communiquer un sous-ensemble d'informations de capacités au serveur 20. Le point de référence TCw peut permettre aux applications observatrices de demander et d'obtenir des informations de capacités à partir du serveur 20 à travers le proxy 23. Les informations obtenues peuvent être véhiculées dans le corps des messages SIP comme par exemple le message NOTIFY et la réponse OK à la requête OPTIONS. 2889641 18 Ce point de référence peut permettre aux applications observatrices d'utiliser les listes d'utilisateurs observés dans les demandes d'informations de capacités. Il peut également permettre au proxy 21 de s'interfacer au serveur 29. Ce point de référence peut également supporter les fonctionnalités du point de référence TCeu dans le cas où l'observateur est lui-même l'utilisateur observé (c'est-à-dire lorsque l'observateur observe les capacités de son propre terminal). Le point de référence TCx peut contribuer à la localisation du serveur 20 associé au terminal utilisateur observé. Il est peut être implémenté à travers les mécanismes définis pour les points de référence Cx et Dx tels qu'ils ont été définis dans la spécification TS 23.002. Le point de référence TCep peut permettre à l'utilisateur observé de communiquer des informations sur les capacités de son terminal au serveur 20. Il lui permet également d'obtenir des informations sur les demandes des observateurs concernant ses propres informations. Les communications sur ce point peuvent également s'effectuer selon le protocole sur SIP. Le point de référence TCwp peut assurer toutes les fonctionnalités offertes par les points de référence TCw et TCep. Le point de référence TCet permet aux applications observatrices 28 de gérer les listes d'utilisateurs observés sur le serveur 29. Il peut utiliser les capacités du point de référence Ut tel qu'il a été défini dans TS 23.002. A travers les fonctionnalités que l'on a décrites pour les proxy cidessus (localisation, routage, authentification, comptabilité) une correspondance peut être établie entre ces proxys et les entités conventionnelles d'une architecture IMS, comme illustré à la figure 5. Le point de référence TCw reliant le S-CSCF au I-CSCF peut être une liaison interdomaine. Dans ce cas, l'application observatrice, le TC list server et le TC proxy peuvent être dans un même domaine, et les autres entités dans un ou plusieurs autres domaines. Le TC proxy peut être assuré par l'ensemble des proxy I-CSCF, S-CSCF et 30 P-CSCF. Le watcher proxy peut être assuré par l'ensemble des proxy S-CSCF et PCSCF. 2889641 19 On a illustré à la figure 6 un échange de messages sur la capacité des terminaux, conformément à un exemple de mise en oeuvre de l'invention. L'agent utilisateur 22 utilise le message PUBLISH pour envoyer (étape 40) ses informations de capacités au serveur 20. Lorsqu'un observateur 28 veut surveiller les informations de capacités d'un ou de plusieurs terminaux, il souscrit à ces informations en envoyant (étape 41) un message SUBSCRIBE au serveur 20, et ce dernier notifie l'observateur en lui envoyant (étape 42) au moins un message NOTIFY et en incluant dans le corps de ce message les informations souhaitées. Au moins un message NOTIFY peut être envoyé ensuite par le serveur 20, suite au déclenchement d'un évènement particulier déterminé par l'observateur, par exemple un changement dans les informations de capacité causé par un nouveau message PUBLISH (étape 43), comme illustré. L'invention n'est pas limitée aux exemples qui viennent d'être décrits. L'infrastructure des figures 4 et 5 peut être implémentée en mettant en oeuvre ou non l'autre aspect de l'invention concernant les politiques. L'expression comportant un doit se comprendre comme comportant au moins un , sauf si le contraire est spécifié. 2889641 20 REVENDICATIONS 1. Infrastructure IMS contrôlée par politiques, comportant au moins un réseau d'accès (11; 12) à un coeur de réseau (10), le coeur de réseau exerçant une fonction de prise de décision appliquant des règles de politiques contenues dans un répertoire de politiques, caractérisée par le fait que le réseau d'accès (11; 12) est agencé pour permettre l'application de règles de politiques contenues dans au moins un répertoire local (17) et/ou dans au moins un répertoire (16) externe au coeur de réseau. 2. Infrastructure selon la revendication 1, dans laquelle au moins un réseau d'accès exerce une fonction locale de prise de décision (LPDF) qui applique des règles de politiques contenues dans un répertoire de politiques (16) externe à ce réseau d'accès. 3. Infrastructure selon la revendication 2, dans laquelle le répertoire de politiques externe (16) est commun à plusieurs réseaux d'accès (11, 12) . 4. Infrastructure selon la revendication 2 ou 3, dans laquelle le contrôle d'au 15 moins un routeur d'accès (AR) au coeur de réseau (10) est assuré par la fonction locale de prise de décision (LPDF). 5. Infrastructure selon la revendication 1, dans laquelle l'un au moins des réseaux d'accès comporte un répertoire local de politiques (17), et dans laquelle la fonction de prise de décision (SPDF) du coeur de réseau (10) applique des politiques contenues dans ce répertoire local (17) pour contrôler un routeur d'accès (AR) de ce réseau d'accès au coeur de réseau. 6. Infrastructure selon la revendication précédente, dans laquelle la fonction de prise de décision (SPDF) du coeur de réseau (10) contrôle des routeurs d'accès (AR) de plusieurs réseaux d'accès. 7. Infrastructure selon l'une quelconque des revendications précédentes, dans laquelle le coeur de réseau (10) comporte un serveur proxy P-CSCF qui applique les politiques décidées par la fonction de prise de décision du coeur de réseau. 8. Infrastructure selon l'une quelconque des revendications précédentes, dans laquelle la signalisation entre les réseaux d'accès (11, 12) et le coeur de réseau (10) 30 s'effectue selon le protocole SIP. 9. Infrastructure selon l'une quelconque des revendications précédentes, étant agencée de telle sorte qu'en cas de conflit entre une requête correspondant à des 2889641 21 ressources demandées et des ressources disponibles, la requête soit refusée dans une phase de signalisation avant que l'infrastructure ne cherche à réserver effectivement les ressources. 10. Réseau d'accès (11, 12) à une infrastructure IMS contrôlée par politiques, 5 le réseau d'accès comportant un routeur d'accès (AR) au coeur du réseau, caractérisé par le fait qu'il comporte: - une fonction locale de prise de décision (LPDF) appliquant des règles de politiques contenues dans un répertoire de politiques (16) externe au coeur de réseau et contrôlant le routeur d'accès (AR), ou - un répertoire local de politiques (17) que peut appliquer une fonction de prise de décision (SPDF) du coeur de réseau contrôlant le routeur d'accès. 11. Procédé de contrôle par politiques d'une infrastructure IMS comportant un coeur de réseau (10) et des réseaux d'accès (11, 12) à ce coeur de réseau, le coeur de réseau (10) exerçant une fonction de prise de décision en appliquant des règles de politiques contenues dans un répertoire de politiques, procédé dans lequel: - le coeur de réseau (10) applique, pour contrôler le routeur d'accès (AR) d'un réseau d'accès, des règles de politiques contenues dans un répertoire local de politiques (17) de ce réseau d'accès, à l'un au moins des réseaux d'accès (AR), et/ou - le réseau d'accès (11, 12) exerce une fonction locale de prise de décision (LPDF) en appliquant des règles de politiques contenues dans un répertoire de politiques (16) externe au coeur du réseau. 12. Procédé selon la revendication précédente, dans lequel plusieurs réseaux d'accès appliquent des règles de politiques contenues dans un répertoire de politiques (16) commun à plusieurs réseaux d'accès. 13. Procédé selon la revendication précédente, dans lequel la fonction locale de prise de décision (LPDF) contrôle le routeur d'accès (AR) au coeur de réseau (10). 14. Procédé selon la revendication 11, dans lequel la fonction de prise de décision (SPDF) du coeur de réseau (10) applique des règles de politiques contenues dans des répertoires de politiques locaux (17) propres à différents réseaux d'accès (11, 12) et contrôle les routeurs d'accès de ces réseaux d'accès. 15. Procédé selon la revendication 11, dans lequel le réseau d'accès est agencé pour analyser des messages SIP comportant au moins une information concernant la 2889641 22 qualité de service demandée et/ou des paramètres de trafic et/ou de sécurité en tant que nouvel en-tête SIP (SIP header), non encapsulé dans le corps du message SIP (i.e. SDP). 16. Procédé selon la revendication 11, le réseau d'accès ne comportant pas de proxy SIP capable d'analyser des requêtes des utilisateurs, dans lequel on détecte un conflit éventuel entre les ressources demandées et les ressources disponibles au niveau de la signalisation, avant que le réseau ne cherche à réserver les ressources.