Brevet FR2909245A1 — publié le 20080530

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 1'UMTS et plus particulièrement l'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 20 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-to-End) 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. 25 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 30 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 2909245 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 (Cal/ 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 5 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 Enfoncement 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 10 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 15 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 class : 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. 2909245 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 5 initialement. Dans un autre exemple, le premier utilisateur envoie à un deuxième utilisateur du réseau UMTS un message INVITE incluant les champs comme ci-dessus et le P-CSCF interroge le répertoire des règles de politiques de 1'UMTS pour savoir s'il y a conflit : Time & Date : 10 - Validation Duration : - For Silver Subscription Class : • Video is supported for classes REVENDICATIONS 1. 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 les capacités matérielles du terminal. 2. Procédé selon la revendication 1, dans lequel les capacités matérielles comportent l'un au moins parmi les caractéristiques d'affichage, notamment la taille et les couleurs, les caractéristiques du clavier, les capacités audio et vidéo, les capacités de mémoire, les commandes proactives supportées par le terminal, le profil Bluetooth, le nombre de bits par pixel, la référence du CPU, la possibilité d'afficher des images, les caractères acceptés pour l'entrée de texte ou l'affichage, les types de claviers acceptés, le nombre de soft keys sur le terminal, le facteur de forme des pixels, la résolution du pointeur et la possibilité ou non de reconnaissance vocale. 3. Procédé selon la revendication 1 ou 2, dans lequel le message utilisé par le terminal pour communiquer ses capacités est le message PUBLISH, le message à travers lequel les observateurs de ces capacités peuvent recevoir ces informations est le message NOTIFY, et le message à travers lequel les observateurs souscrivent au préalable à ces informations est le message SUBSCRIBE. 4. Procédé selon l'une quelconque des revendications précédentes, dans lequel le message utilisé par le terminal pour véhiculer les informations de capacité est l'un au moins parmi les requêtes INVITE, REGISTER et la réponse OK au message OPTIONS. 5. Procédé selon la revendication précédente, dans lequel une entête est rajoutée au message pour indiquer que son corps comporte des informations de capacité matérielle du terminal. 6. Infrastructure permettant de signaler des capacités physiques de terminaux, comportant au moins un observateur (28) agencé pour observer les capacités d'un terminal (UE), cet observateur étant agencé pour observer au moins trois paramètres décrivant des capacités matérielles du terminal. 7. Infrastructure selon la revendication précédente, dans laquelle l'observateur (28) est un utilisateur. 8. Infrastructure selon la revendication 6, dans laquelle l'observateur (28) est un service résidant dans un serveur d'application. 2909245 21 9. Infrastructure selon l'une quelconque des revendications 6 à 8, dans laquelle l'observateur (28) applique au moins un filtre permettant de définir les sous-ensembles des informations de capacité qu'il souhaite recevoir, ce filtre étant véhiculé pendant la phase de souscription à ces informations. 5 10. Infrastructure selon l'une quelconque des revendications 6 à 9, comportant un serveur TC Server (20) agencé pour stocker et générer des informations sur les capacités des terminaux, notamment pour recevoir des terminaux des informations concernant les capacités, et pour permettre à au moins un observateur (28) de demander ou de recevoir toute ou partie de ces informations. 10 11. Terminal utilisant un protocole de signalisation SIP, comportant un agent utilisateur (22) 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. 12. Terminal selon la revendication 11, les informations étant encapsulées dans le corps des messages SIP déjà désignés pour la communication de ces informations. 15 13. Terminal selon l'une des deux revendications immédiatement précédentes, étant agencé pour envoyer une information représentative d'un changement desdits paramètres par rapport à des valeurs par défaut. 14. Terminal selon la revendication 11 ou la revendication 12, étant agencé pour envoyer un message comportant les valeurs de l'intégralité ou d'un sous-ensemble 20 desdits paramètres ou un lien vers un profil stocké sur au moins un serveur externe renseignant sur les valeurs d'au moins certains desdits paramètres. 15. Terminal selon la revendication précédente, les valeurs envoyées pendant les mises à jour se substituant aux valeurs par défaut communiquées par le ou les serveurs externes. 25