FR3021836A1 - Procede pour informer une entite d' un reseau ip du type de reseau d' acces utilise par un terminal - Google Patents

Abstract

L'invention concerne un procédé de notification dans un réseau IP, ledit procédé étant relatif à un dispositif-client donné connecté à un réseau d'accès audit réseau IP, et comprenant les étapes suivantes : une entité d'un réseau IP souscrit (E1-E2) auprès de l'entité de raccordement en charge dudit dispositif-client aux évènements de changement de type de réseau d'accès de ce dispositif-client ; ladite entité de raccordement en charge dudit dispositif-client informe (E3) l'entité réseau souscriptrice du type de réseau d'accès auquel le dispositif-client est présentement connecté ; si l'entité de raccordement reçoit (E6) une information mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, l'entité de raccordement transmet (E7) cette information à l'entité réseau souscriptrice. Application aux réseaux IMS.

Description

PROCEDE POUR INFORMER UNE ENTITE D'UN RESEAU IP DU TYPE DE RESEAU D'ACCES UTILISE PAR UN TERMINAL La présente invention concerne les réseaux de communications de type IP (« Internet Protocol »), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en oeuvre des protocoles de contrôle de session évolués. Les réseaux IP permettent la diffusion de données conversationnelles, dans le cadre de services tels que « Voix sur IP » (VolP), « Partage de Contenu », ou « Messagerie Instantanée ». Plus particulièrement, la présente invention concerne les moyens mis en place dans un réseau IP pour permettre à des entités de ce réseau, telles que des serveurs de coeur de réseau, de mettre à jour de façon dynamique des informations concernant le type de réseau d'accès auquel est connecté un dispositif-client (« User Equipment » en anglais) donné. Au sens de l'invention, le « type » d'un réseau représente la technologie et l'architecture mises en oeuvre dans ce réseau. Le « dispositif-client » concerné par l'invention peut par exemple être un terminal mobile. Il peut également s'agir d'un terminal fixe, ou d'une passerelle domestique (« Residential Gateway » en anglais) ou située dans une entreprise, ayant accès à au moins deux réseaux IP ; ce terminal fixe peut par exemple être un ordinateur personnel ayant accès, d'une part, au réseau mobile 3G au moyen d'une « clé 3G » insérable dans l'ordinateur, et d'autre part à un réseau fixe ADSL via une passerelle domestique. On supposera en général que l'utilisateur de ce dispositif-client possède un compte auprès de l'opérateur du réseau IP, et ce, quel que soit le réseau d'accès utilisé par le dispositif-client pour se connecter à ce réseau IP. Des exemples de serveurs de coeur de réseau aptes à mettre en oeuvre la présente invention seront fournis plus bas.

3021836 2 Les services de communication sur réseau IP peuvent identifier des ressources physiques ou virtuelles au moyen de chaînes de caractères telles qu'une « URI » (initiales des mots anglais « Uniform Resource Identifier » signifiant « Identifiant Uniforme de Ressource »). La syntaxe 5 des URIs est définie dans le document RFC 3986 de l'IETF ; la connaissance de l'URI d'une ressource permet d'obtenir l'adresse IP d'un équipement du réseau de l'opérateur gérant cette ressource. Dans la présente description, nous appellerons « URI » tout type d'identifiant de ressource applicative physique ou virtuelle accessible sur un réseau.

10 Les protocoles de contrôle de session évolués classiques, tels que le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initiation de Session »), utilisent des messages dits de « signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des 15 messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Le protocole SIP a été défini par l'IETF (Internet Engineering Task Force) dans le document RFC 3261. Ce protocole permet l'établissement, 20 la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP a ensuite été étendu notamment dans le document RFC 3265. Cette extension définit des procédures de notification d'événements. Le protocole SIP est utilisé en particulier dans les infrastructures de 25 type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »). L'IMS a été défini par l'organisme de normalisation 3GPP (« Third Generation Partnership Project ») et TISPAN (« Telecommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, 3021836 3 puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les 5 opérateurs réseau peuvent commodément mettre en oeuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction.

10 Lorsqu'un usager souhaite bénéficier des services offerts par un réseau IMS, il émet vers le réseau des messages de signalisation pouvant inclure notamment divers types de requêtes. Tout d'abord, le dispositif-client de l'usager doit, sauf exceptions (telles que certains appels d'urgence), s'enregistrer sur le réseau. Lorsque 15 le réseau est incapable de faire le lien entre cet enregistrement et un enregistrement précédent (par exemple suite à une panne réseau, ou suite à un arrêt du terminal pendant une durée supérieure à une valeur prédéterminée), l'enregistrement est considéré comme étant un enregistrement initial. Après un enregistrement initial, le dispositif-client de 20 l'utilisateur doit envoyer périodiquement au réseau une requête pour confirmer qu'il souhaite maintenir son enregistrement. Pour pouvoir donc enregistrer les dispositifs-clients, les réseaux IMS comprennent un ou plusieurs serveurs d'enregistrement, appelés « SCSCF » (initiales des mots anglais « Serving-Gall Server Control 25 Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau. Les réseaux IMS comprennent en outre un ou plusieurs serveurs d'interrogation, appelés « I-CSCF » (initiales des mots anglais 30 « Interrogating-Cali Server Control Function » signifiant « Fonction de 3021836 4 Commande de Session d'Appel Interrogatrice ») - d'ailleurs souvent combinés physiquement avec les serveurs d'enregistrement S-CSCF pour constituer des serveurs d'appel dénotés « I/S-CSCF » - qui, au moment de l'enregistrement d'un dispositif-client, interrogent un serveur de 5 données d'abonné appelé « HSS » (initiales des mots anglais « Home Subscriber Server » signifiant « Serveur d'Abonné de Rattachement »), afin de pouvoir sélectionner un serveur S-CSCF possédant les caractéristiques qui sont obligatoirement (et, le cas échéant, optionnellement) requises pour atteindre le niveau de service souscrit par 10 l'usager. Les serveurs HSS contiennent chacun une base de données-clients, et sont donc l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home Location Register » signifiant « Registre de Localisation de Rattachement ») utilisés dans les réseaux GSM. Chaque serveur HSS contient le « profil » d'un certain nombre de 15 dispositifs-clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits. En effet, chaque usager peut, après qu'un serveur S-CSCF lui ait été ainsi attribué, envoyer une requête de souscription à certains services 20 valable pour la connexion en cours. Le principe général est qu'un dispositif-client peut souscrire à un service particulier à l'aide d'une requête appropriée (SUBSCRIBE). Ainsi, dans le cas d'une souscription à l'état d'une ressource, des notifications d'évènement (NOTIFY) sont envoyées au dispositif-client dès lors que l'état de la ressource change ; 25 par exemple, lorsque l'utilisateur d'un terminal dispose d'une boîte vocale sur le réseau, ce terminal peut souscrire à une notification de dépôt de message, c'est-à-dire qu'il peut demander à être informé chaque fois qu'un message a été enregistré sur cette boîte vocale ; le terminal de l'utilisateur peut, de même, demander à être notifié de son propre état 30 d'enregistrement, et ainsi de suite.

3021836 5 Les requêtes de souscription initiales sont émises soit de manière automatique juste après le démarrage du terminal ou d'une application installée sur ce terminal, soit suite à une action de l'utilisateur sur l'interface du terminal. Pour chaque souscription, le dispositif-client doit 5 émettre d'abord une requête initiale, et puis périodiquement une requête pour renouveler sa souscription (on parle de « rafraîchissement » de la souscription). Pour chaque souscription (qu'il s'agisse d'une souscription initiale ou d'un rafraîchissement), le réseau indique au dispositif-client la période 10 de rafraîchissement souhaitée par l'opérateur du réseau pour cette souscription. Dans le cas du document RFC 3265, la période de rafraîchissement maximale associée à la souscription à un service (« event-package » en anglais) particulier offert par le réseau est définie par renvoi au document qui définit ce service particulier ; par exemple, 15 concernant la souscription à la notification de dépôt de message, le document RFC 3842 préconise (cf. « event-package message summary ») une période de rafraîchissement allant de quelques heures à quelques jours. Les réseaux IMS comprennent en outre un ou plusieurs serveurs 20 appelés « P-CSCF » (initiales des mots anglais « Proxy-Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Mandataire »). Pour chaque dispositif-client connecté à un réseau IMS, il existe un serveur P-CSCF servant d'entité de raccordement entre le coeur de réseau IMS et le réseau d'accès utilisé par ce dispositif-client ; ainsi, 25 toute la signalisation SIP échangée entre le dispositif-client d'une part, et le serveur d'interrogation I-CSCF ou le serveur d'enregistrement S-CSCF d'autre part, passe par le serveur P-CSCF. Les normes TS 23.203 et TS 29.212 du 3GPP prévoient de caractériser les réseaux d'accès en termes de technologie et 30 d'architecture, à l'aide d'un identifiant appelé IP-CAN (initiales des mots 3021836 6 anglais « IP Connectivity Access Network » signifiant « Réseau d'Accès à la Connectivité IP ») ; un certain nombre de valeurs possibles pour l'IPCAN sont définies dans la Section 5.3.27 de la norme TS 29.212. Pour un IP-CAN donné, on peut au besoin indiquer de manière plus précise la 5 technologie radio (« Radio Access Technology », ou RAT, en anglais) utilisée ; un certain nombre de valeurs possibles pour la RAT sont définies dans la Section 5.3.31 de la norme TS 29.212. Avec la mise en oeuvre de la norme LTE (« Long Term Evolution ») du 3GPP, les opérateurs réseau sont confrontés à la problématique 10 consistant à pouvoir offrir à un usager des services qui dépendent du type de réseau d'accès sur lequel l'usager est situé. En effet, certains services ne peuvent fonctionner que si le débit qu'ils requièrent est disponible à l'accès ; or ce débit varie considérablement en fonction de la RAT mise en oeuvre par le réseau d'accès. Certains services, comme par exemple le 15 partage vidéo (« video sharing » en anglais) du bouquet RCS (« Rich Communication Services »), peuvent fonctionner en technologie LTE, peuvent fonctionner avec une qualité dégradée en technologie 3G, et sont carrément non-fonctionnels en technologie 2G. Outre les services, ce sont certaines applications qui pourraient n'être disponibles que sur la base 20 d'un débit suffisant. Au sein d'un service donné, l'information du type de réseau d'accès peut également servir à ajuster un paramètre de fonctionnement, tel que la possibilité ou non d'émettre un flux audio ou vidéo en Haute Définition. Une autre motivation à connaître le type d'accès sur lequel se 25 trouve un abonné est liée à la taxation. En effet, un opérateur pourrait appliquer des tarifs préférentiels pour un même service dès lors qu'il a connaissance que le service sera dégradé (par exemple parce que le service n'est pas prévu pour être utilisé sur tel ou tel type de couverture radio), ou simplement pour encourager un usage l'utilisation d'un réseau 3021836 7 d'accès qui déleste le réseau radio global, par exemple en relation avec un service disponible sur un réseau d'accès de type WiFi. Selon les normes SIP en vigueur, un en-tête (« header » en anglais) SIP appelé « P-Access-Network-lnformation » (ou PANI) permet 5 de véhiculer l'information du type de réseau d'accès utilisé par un dispositif-client donné, mais il n'est pas prévu de diffuser cette information au cours d'une session établie, ou en-dehors de la session elle-même. En conséquence, selon l'état de l'art, il est possible pour des entités du coeur de réseau IMS telles qu'un serveur S-CSCF ou un serveur d'applications 10 de connaître le type de réseau d'accès au moment de l'établissement d'une session, mais il n'est leur est pas possible de connaître le type de réseau d'accès à tout instant. Or cette information est accessible à tout instant aux serveurs PCSCF, mais les serveurs P-CSCF ne sont pas en charge de la gestion 15 des services, lesquels sont généralement du ressort des serveurs d'application (« Application Servers », ou AS, en anglais). Les serveurs PCSCF ne sont pas non plus en charge de l'émission des rapports de données de taxation (« Charging Data Records », ou CDR en anglais) ; on rappelle à cet égard (cf. Wikipedia) qu'un CDR est, dans la terminologie 20 du 3GPP, une collection formatée d'informations concernant un événement de télécommunication taxable (comme le fait de placer un appel téléphonique, ou de naviguer sur Internet à partir d'un téléphone mobile) ; un opérateur émet des CDR pour préparer les factures de ses abonnés, et il se fonde principalement pour ce faire sur les CDR émis par 25 des AS ou par des serveurs S-CSCF. La présente invention concerne donc un procédé de notification dans un réseau IP, ledit procédé étant relatif à un dispositif-client donné connecté à un réseau d'accès audit réseau IP, et comprenant les étapes suivantes : 3021836 8 a) une entité d'un réseau IP souscrit auprès de l'entité de raccordement en charge dudit dispositif-client aux évènements de changement de type de réseau d'accès de ce dispositif-client, b) ladite entité de raccordement en charge dudit dispositif-client 5 informe l'entité réseau souscriptrice du type de réseau d'accès auquel le dispositif-client est présentement connecté, et c) si l'entité de raccordement reçoit une information mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, l'entité de raccordement transmet cette 10 information à l'entité réseau souscriptrice. Ainsi, l'invention propose de créer une nouvelle souscription permettant à une quelconque entité d'un réseau IP, telle qu'un serveur de coeur de réseau, ayant souscrit au service selon l'invention, d'être informée de tout changement, par un certain dispositif-client, de réseau 15 d'accès impliquant un changement de « type de réseau » au sens de l'invention. Grâce à ces dispositions, cette entité réseau pourra modifier dynamiquement les caractéristiques enregistrées concernant un dispositif-client (tel qu'un terminal mobile), de manière à prendre les mesures 20 adaptées. Ces mesures peuvent consister par exemple à éviter de router des appels arrivés vers un dispositif-client qui n'est pas sous une couverture radio permettant de rendre un service associé à cet appel (avec éventuellement libération de l'appel), ou bien à enrichir les CDR engendrés par les différents dispositifs réseau ayant souscrit au service 25 selon l'invention, en indiquant dans ces CDR les changements de type d'accès du dispositif-client. Selon des caractéristiques particulières, ledit procédé comprend en outre une étape au cours de laquelle ladite entité de raccordement en charge dudit dispositif-client émet, à destination d'une entité de 30 commande de politique réseau, une demande de notification de 3021836 9 changement de type de réseau d'accès concernant ledit dispositif-client ; de plus, lors de ladite étape c), ladite information reçue par l'entité de raccordement et mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, est fournie par ladite 5 entité de commande de politique réseau. Grâce à ces dispositions, comme expliqué en détail ci-dessous, l'entité de raccordement peut être elle-même informée desdits changements de réseau d'accès, sur la base de mécanismes déjà existants dans nombre de réseaux IP actuels.

10 Corrélativement, l'invention concerne divers dispositifs. Elle concerne ainsi, premièrement, une entité de raccordement entre un coeur de réseau IP et un réseau d'accès audit réseau IP. Ladite entité de raccordement est remarquable en ce qu'elle possède des moyens pour : 15 - recevoir, de la part d'une entité dudit réseau IP, une requête de souscription aux évènements de changement de type de réseau d'accès concernant un dispositif-client connecté audit réseau d'accès et dont ladite entité de raccordement a la charge, - informer l'entité réseau souscriptrice du type de réseau d'accès 20 auquel le dispositif-client est présentement connecté, et - si l'entité de raccordement reçoit une information mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, transmettre cette information à l'entité réseau souscriptrice.

25 Selon des caractéristiques particulières, ladite entité de raccordement possède en outre des moyens pour : - émettre, à destination d'une entité de commande de politique réseau, une demande de notification de changement de type de réseau d'accès concernant ledit dispositif-client, et 3021836 10 - recevoir, de la part de ladite entité de commande de politique réseau, une information indiquant un type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté. L'invention concerne aussi, deuxièmement, une entité d'un réseau 5 IP. Ladite entité réseau est remarquable en ce qu'elle possède des moyens pour : - souscrire, auprès d'une entité de raccordement entre ledit réseau IP et un réseau d'accès, aux évènements de changement de type de réseau d'accès concernant un dispositif-client connecté audit réseau 10 d'accès et dont ladite entité de raccordement a la charge, - recevoir, de la part de ladite entité de raccordement, une information concernant le type de réseau d'accès auquel ledit dispositif-client est présentement connecté, et - recevoir, de la part de ladite entité de raccordement, un message 15 de notification l'informant d'un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté. Cette entité réseau pourra notamment être un serveur de coeur de réseau, tel qu'un serveur d'enregistrement ou un serveur d'applications. Les avantages offerts par ces dispositifs sont essentiellement les 20 mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus. On notera qu'il est possible de réaliser ces dispositifs dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques.

25 L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé de notification 30 succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur.

3021836 11 Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation 5 particuliers, donnés à titre d'exemples non limitatifs. La description se réfère à la figure unique qui l'accompagne, et qui représente schématiquement un système pour la fourniture de services multimédia apte à mettre en oeuvre l'invention. Bien que la présente invention concerne les réseaux IP en général, 10 on va considérer à présent, à titre d'exemple de réalisation, une architecture de réseau de type IMS, telle que présentée succinctement ci-dessus. Cette architecture est illustrée sur la figure 1. Les services multimédia offerts par ce réseau IMS 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage 15 de contenu (« content-sharing » en anglais), de Présence, de Messagerie Instantanée, ou de télévision. Ces services sont à la disposition de l'utilisateur d'un dispositif-client (« User Equipment », ou UE en anglais) 10 appartenant au réseau 1, qui permet au dispositif-client 10 d'échanger des flux multimédias et des signaux de contrôle de session conformes au 20 protocole SIP, par exemple avec le dispositif-client (non représenté) d'un utilisateur appartenant à un réseau SIP (non représenté) relié au réseau 1. Le dispositif-client 10 peut être un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise, disposant de moyens de signalisation SIP et pouvant comprendre des moyens de restitution d'un 25 contenu audiovisuel. Comme le montre la figure 1, ce réseau IMS 1 comprend, outre une infrastructure de transport IP (non représentée) : - au moins un serveur S-CSCF ; le serveur S-CSCF 27 gère notamment la procédure d'enregistrement des dispositifs connectés 30 au réseau 1 ; le serveur S-CSCF 27 gère également le routage de la 3021836 12 signalisation entre le dispositif-client 10 et les serveurs de messagerie vocale VM 25, de Messagerie Instantanée 26, et de téléphonie TAS 29 ; - au moins un serveur I-CSCF ; le serveur I-CSCF 22 gère notamment 5 le routage en direction d'autres terminaux gérés par le même réseau IMS 1 et le routage de la signalisation entre ce réseau IMS 1 et d'autres réseaux (non représentés) ; - au moins un serveur P-CSCF ; le serveur P-CSCF 21 sert d'entité de raccordement entre le coeur de réseau IMS et le réseau d'accès 10 utilisé par le dispositif-client 10 ; - au moins un serveur de base de données, de type HSS ; le serveur HSS 24 contient le profil de l'utilisateur du dispositif-client 10 en termes de données d'authentification, de localisation et de services souscrits ; 15 - au moins un serveur VM 25 de messagerie vocale (« message- summary » en anglais) ; le serveur VM 25 gère la souscription du dispositif-client 10 aux événements de dépôt/consultation des messages à l'intention du dispositif-client 10, et notifie le dispositif-client 10 lors de l'occurrence de ces événements ; 20 - au moins un serveur de Messagerie Instantanée IM 26 ; en cas de souscription de l'utilisateur de l'UE 10 au service de Messagerie Instantanée, cet utilisateur peut dialoguer « instantanément » en ligne avec d'autres abonnés à ce service ; et - au moins un serveur de téléphonie TAS 29 ; le serveur TAS gère les 25 services téléphoniques auxquels l'utilisateur du terminal 10 a souscrits auprès de son opérateur, tels que la présentation du numéro ou le renvoi d'appel. Les serveurs de messagerie vocale VM 25, de Messagerie Instantanée IM 26, et de téléphonie TAS 29 sont des exemples de 30 Serveurs d'Applications (AS).

3021836 13 Certains services, comme ceux du serveur VM 25 et du serveur de Messagerie Instantanée IM 26, s'appuient sur la souscription du terminal 10 à des événements prédéterminés, comme expliqué ci-dessus. Pour mettre en oeuvre la taxation des usagers, les réseaux IMS 5 utilisent une architecture appelée PCC (initiales des mots anglais « Policy and Charging Control » signifiant « Commande de Politique et de Taxation »). Comme expliqué par exemple dans le tutoriel intitulé « PCC (Policy and Charging Control) pour les Services Data Mobiles » publié en 2011 par la Société « Etudes et Formations en Télécommunications » (cf. 10 http://www.efortcom), cette architecture PCC consiste en une entité centralisée appelée PCRF (initiales des mots anglais « Policy Control and Charging Rules Function » signifiant « Fonction de Commande de Politique et de Règles de Taxation »), qui fournit des règles de taxation et de « politique d'opérateur » (comme par exemple le débit maximum 15 alloué, ou la priorité du flux selon son type) à une entité appelée PCEF (initiales des mots anglais « Policy and Charging Enforcement Function » signifiant « Fonction d'Application de Politique et de Taxation »). L'entité PCRF est apte à déterminer la méthode de taxation pour un flux de service donné ; elle a accès aux données d'abonnement de l'usager afin 20 de pouvoir adapter l'usage des ressources de transport par le service, ainsi que la taxation du service, en fonction du profil de l'usager. L'entité PCEF sélectionne une règle PCC pour chaque paquet de données dudit flux en examinant les données de service contenues dans ce paquet. Sur la figure 1, les lignes en pointillé représentent le chemin « réel » 25 des signaux SIP (entre l'UE 10 et l'entité PCEF 31, puis entre l'entité PCEF 31 et le serveur P-CSCF 21). La ligne hachurée (entre l'UE 10 et le serveur P-CSCF 21) représente le chemin « logique » de la signalisation SIP. L'entité PCRF 30 est connectée à l'entité PCEF 31 et à l'entité PCSCF 21.

3021836 14 Les fonctions de l'entité PCRF exploitées par la présente invention dans le cadre spécifique des réseaux IMS sont supposées remplies, dans le cadre d'un type quelconque de réseau IP, par une entité appelée « entité de commande de politique réseau », dont l'entité PCRF 5 représente un cas particulier. Chaque entité du réseau IP souhaitant exploiter l'information de changement de type d'accès radio, que l'on appellera par exemple « Access modification », pour un certain dispositif-client doit souscrire conformément à l'invention auprès de l'entité de raccordement (serveur P- 10 CSCF dans un réseau IMS) en charge de ce dispositif-client. La demande de souscription est émise par cette entité réseau, de préférence, juste après l'enregistrement réseau du dispositif-client. L'entité réseau recevra alors des notifications lors de tout changement, par le dispositif-client concerné, de réseau d'accès 15 impliquant un changement de « type de réseau » au sens de l'invention. Il peut s'agir, par exemple : - d'un changement d'IP-CAN (par exemple de IP-CAN-TYPE=3GPPGPRS à IP-CAN-TYPE=3GPP-EPS), sans changement de RAT, ou - d'un changement de RAT (par exemple, de RAT-20 TYPE=HSPA EVOLUTION à RAT-TYPE=GERAN), sans changement d'IP-CAN, ou encore - d'un changement à la fois d'IP-CAN et de RAT. On va décrire à présent un premier mode de réalisation, dans lequel le noeud souscripteur est un serveur d'applications (AS) hébergeant 25 un service de type « service 1 ». Lors d'une étape E1, l'AS souscrit à l'évènement de changement de type de réseau d'accès auprès du serveur P-CSCF : SUBSCRIBE sip:impu observed user@operator.ims.com SIP/2.0 To: <sip:impu observed user@operator.ims.com > 30 From: <sip: AS servicel@operator.ims.com>;tag=78923 3021836 15 Call-Id: [...] CSeq: 1 SUBSCRIBE Contact: AS_service1@operator.ims.co Event: Access modification 5 Expires:[...] Accept:application/Access modification-notification Content-Length: 0 Comme expliqué plus haut, la mention SUBSCRIBE indique qu'il s'agit d'un message SIP (« méthode ») de souscription. On notera que la 10 ressource IP destinataire du message SIP (appelée de manière générale « Request-URI »), qui est indiquée à la suite de la méthode SUBSCRIBE ainsi que dans le champ « To », est ici : sip:impu observed user@operator.ims.com, laquelle n'est autre que l'identité publique (« IP Multimedia PUblic 15 identity >>, ou IMPU en anglais) de l'usager dont on « observe » les changements de réseau d'accès. Comme le serveur P-CSCF est la seule entité destinataire possible pour les demandes de souscription à l'évènement « Access Modification », ce serveur est en réalité une destination implicite des demandes de souscription. Ce mode de 20 réalisation permet avantageusement à l'entité réseau souscriptrice de ne pas avoir à mémoriser l'adresse du, ou des, serveur(s) P-CSCF concerné(s) ; cette mémorisation aurait été d'ailleurs particulièrement complexe en cas de « forking », c'est-à-dire lorsqu'un usager utilise plusieurs dispositifs-clients sous la même identité publique.

25 Lors d'une étape E2, le serveur P-CSCF accepte la souscription : SIP/2.0 200 OK To: impu observed user@operator.ims.com;tag=123456 From: <sip: AS service1@operator.ims.com>;tag=78923 Call-Id: [ ...] 30 CSeq: 1 SUBSCRIBE Contact: [ ...] 3021836 16 Event: Access modification Expires:[ ...] Content-Length: 0 Lors d'une étape E3, le serveur P-CSCF informe l'AS, dans la 5 notification (message NOTIFY) de finalisation de souscription, du type de type de réseau d'accès présentement utilisé par le dispositif-client. Selon une première variante, les informations de type de réseau d'accès sont véhiculées au sein d'un en-tête (« header >>) dédié, que nous appellerons « Access-Event » : 10 NOTIFY sip:AS_servicel@operator.ims.com SIP/2.0 From:<sip:impu observed user@operator.ims.com>;tag=123456 To: <sip: AS service1@operator.ims.com>;tag=78923 Call-Id: [ ...] CSeq: 1 NOTIFY 15 Contact: [ ...] Event: Access modification Subscription-State: active Access-Event:AoC;IP-CAN-TYPE=3GPP-GPRS; RAT-TYPE=HSPA EVOLUTION 20 Content-Length: 0 On notera que l'en-tête « Access-Event » ci-dessus indique l'adresse de contact (représentée par « AoC ») du dispositif-client ; en effet, lorsqu'un dispositif-client change de réseau d'accès, il change en même temps d'adresse de contact ; le type de réseau auquel est connecté le dispositif- 25 client visé par la souscription est donc associé à une certaine adresse de contact de ce dispositif-client. Lors d'une étape E4, l'AS confirme la bonne réception du message NOTIFY : SIP/2.0 200 OK 30 From: <sip: impu observed user@operator.ims.com>; 3021836 17 tag=123456 To: <sip:AS service1@operator.ims.com>;tag=78923 Call-Id: [ ...] CSeq: 1 NOTIFY 5 Contact: [ ...] Lors d'une étape E5, le serveur P-CSCF émet (sur une interface appelée « Rx »), s'il ne l'a déjà fait, une demande de notification à destination de l'entité PCRF du réseau IMS. Pour ce faire, le serveur PCSCF peut avantageusement, par exemple, appliquer la procédure 10 indiquée dans les Sections 4.4.6.4 et 5.3.13 de la norme TS 29.214, ainsi que dans la section B.1a de la norme TS 29.213 du 3GPP : la demande de notification prend alors la forme d'une commande « AA-Request » (AAR) valorisant un champ « Attribute-Value Pair » (AVP) appelé « Specific-Action » avec la valeur « IP-CAN CHANGE ». En 15 conséquence, le serveur P-CSCF sera notifié par l'entité PCRF à chaque fois que le dispositif-client passe d'un réseau d'accès d'un certain type, à un réseau d'accès d'un autre type. Suite à la réception par le serveur P-CSCF, lors d'une étape E6, de la part d'une entité PCRF, d'une information de changement de type de 20 réseau d'accès concernant le dispositif-client, le serveur P-CSCF, lors d'une étape E7, en informe l'AS : NOTIFY sip:AS_servicel@operator.ims.com SIP/2.0 From: <sip:impu observed user@operator.ims.com >;tag=123456 To: <sip: AS service1@operator.ims.com>;tag=78923 25 Call-Id: [ ...] CSeq: 2 NOTIFY Contact: [ ...] Event: Access modification Subscription-State: active 30 Access-Event: AoC;IP-CAN-TYPE=3GPP-GPRS;RAT-TYPE=GERAN Content-Length: 0 3021836 18 On notera que cette notification indique, dans l'en-tête « AccessEvent », la nouvelle adresse de contact (« AoC ») du dispositif-client concerné par la souscription. Enfin, lors d'une étape E8, l'AS confirme la bonne réception du 5 message NOTIFY : SIP/2.0 200 OK From: <sip:impu observed user@operator.ims.com >; tag=123456 To: <sip: AS service1@operator.ims.com>;tag=78923 10 Call-Id: [ ...] CSeq: 2 NOTIFY Contact: [ ...] Selon un deuxième mode de réalisation de l'invention, les échanges décrits ci-dessus impliquent un serveur S-CSCF au lieu d'un 15 AS. Dans les modes de réalisation décrits ci-dessus, les informations de type de réseau d'accès ont été véhiculées dans l'en-tête Access-Event du message NOTIFY envoyé aux souscripteurs. Mais d'autres formats sont évidemment possibles pour véhiculer ces informations. Ainsi, selon une 20 deuxième variante, ces informations peuvent être véhiculées dans le corps de message (« body xml » en anglais) du message NOTIFY. De manière générale, la présente invention peut être mise en oeuvre au sein des noeuds d'un réseau IP, par exemple des entités de raccordement ou des serveurs de coeur de réseau, au moyen de 25 composants logiciels et/ou matériels. Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière 30 classique une unité centrale de traitement commandant par des signaux 3021836 19 une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre de l'un quelconque des procédés de notification selon l'invention.

5 En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de notification selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut 10 être exécutable par un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter 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 15 souhaitable. L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

20 Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB 25 (« USB flash drive » en anglais). 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 d'ordinateur selon l'invention peut être en particulier 30 téléchargé sur un réseau de type Internet.

3021836 20 En variante, 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 de l'un quelconque des procédés de notification selon l'invention. 5

Claims (14)

1. REVENDICATIONS1. Procédé de notification dans un réseau IP, ledit procédé étant relatif à un dispositif-client donné connecté à un réseau d'accès audit réseau IP, et comprenant les étapes suivantes : a) une entité d'un réseau IP souscrit (E1-E2) auprès de l'entité de raccordement en charge dudit dispositif-client aux évènements de changement de type de réseau d'accès de ce dispositif-client, b) ladite entité de raccordement en charge dudit dispositif-client informe (E3) l'entité réseau souscriptrice du type de réseau d'accès auquel le dispositif-client est présentement connecté, et c) si l'entité de raccordement reçoit (E6) une information mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, l'entité de raccordement transmet (E7) cette information à l'entité réseau souscriptrice.
2. 2. Procédé de notification selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape (E5) au cours de laquelle ladite entité de raccordement en charge dudit dispositif-client émet, à destination d'une entité de commande de politique réseau, une demande de notification de changement de type de réseau d'accès concernant ledit dispositif-client, et en ce que, lors de ladite étape c), ladite information reçue par l'entité de raccordement et mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, est fournie par ladite entité de commande de politique réseau.
3. 3. Procédé de notification selon la revendication 2, caractérisé en ce que, ledit réseau IP étant un réseau IMS, ladite entité de commande de politique réseau comprend une entité PCRF.
4. 4. Procédé de notification selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite entité réseau souscriptrice est un serveur de coeur de réseau. 3021836 22
5. 5. Procédé de notification selon l'une quelconque des revendications précédentes, caractérisé en ce que, ledit réseau IP étant un réseau IMS, ledit changement de type de réseau d'accès concerne un changement de type d'IP-CAN (IP Connectivity Access Network) et/ou un 5 changement de type de RAT (Radio Access Technology).
6. 6. Entité de raccordement entre un coeur de réseau IP et un réseau d'accès audit réseau IP, caractérisée en ce qu'elle possède des moyens pour : - recevoir, de la part d'une entité dudit réseau IP, une requête de 10 souscription aux évènements de changement de type de réseau d'accès concernant un dispositif-client connecté audit réseau d'accès et dont ladite entité de raccordement a la charge, - informer l'entité réseau souscriptrice du type de réseau d'accès auquel le dispositif-client est présentement connecté, et 15 - si l'entité de raccordement reçoit une information mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, transmettre cette information à l'entité réseau souscriptrice. 20
7. 7. Entité de raccordement selon la revendication 6, caractérisée en ce que, ledit réseau IP étant un réseau IMS, ladite entité de raccordement comprend un serveur P-CSCF.
8. 8. Entité de raccordement selon la revendication 6 ou la revendication 7, caractérisée en ce qu'elle possède en outre des moyens 25 pour : - émettre, à destination d'une entité de commande de politique réseau, une demande de notification de changement de type de réseau d'accès concernant ledit dispositif-client, et 3021836 23 - recevoir, de la part de ladite entité de commande de politique réseau, une information indiquant un type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté.
9. 9. Entité d'un réseau IP, caractérisé en ce qu'elle possède des 5 moyens pour : - souscrire, auprès d'une entité de raccordement entre ledit réseau IP et un réseau d'accès, aux évènements de changement de type de réseau d'accès concernant un dispositif-client connecté audit réseau d'accès et dont ladite entité de raccordement a la charge, 10 - recevoir, de la part de ladite entité de raccordement, une information concernant le type de réseau d'accès auquel ledit dispositif-client est présentement connecté, et - recevoir, de la part de ladite entité de raccordement, un message de notification l'informant d'un autre type de réseau d'accès auquel le 15 dispositif-client s'est subséquemment connecté.
10. 10. Entité réseau selon la revendication 9, caractérisé en ce qu'elle comprend un serveur de coeur de réseau. 20
11. 11. Entité réseau selon la revendication 10, caractérisé en ce que ledit serveur de coeur de réseau est un serveur d'enregistrement ou un serveur d'applications.
12. 12. Entité réseau selon la revendication 11, caractérisé en ce que, ledit réseau IP étant un réseau IMS, ledit serveur d'enregistrement est un 25 serveur S-CSCF.
13. 13. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de notification selon l'une quelconque des revendications 1 à 5. 3021836 24
14. 14. Programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de notification selon 5 l'une quelconque des revendications 1 à 5, lorsqu'il est exécuté sur un ordinateur.