FR3049805A1 - Procede de transfert de reseau d' acces pour un terminal mobile en itinerance - Google Patents

Abstract

L'invention concerne un procédé de transfert de réseau d'accès pour un terminal mobile, dit premier terminal (UE A), appartenant à un réseau IP (Internet Protocol), comprenant les étapes suivantes : il devient nécessaire pour ledit premier terminal (UE A) de passer d'un premier à un deuxième réseau d'accès audit réseau IP ; et un serveur ATCF (Access Transfer Control Function) en charge dudit premier terminal (UE A) fait parvenir à un serveur d'application SCC-AS (Service Centralization and Continuity), via un serveur IBCF (Interconnection Border Control Function), une requête apte à informer ledit serveur d'application SCC-AS qu'une procédure de transfert de réseau d'accès a été initiée pour le premier terminal (UE A). Selon l'invention, ladite requête est agencée de manière à indiquer audit serveur d'application SCC-AS qu'il ne doit pas propager cette requête vers un dispositif-client, dit deuxième terminal (UE B), appartenant lui aussi au réseau IP, avec lequel le premier terminal est en cours de communication. Application aux réseaux IMS.

Description

Procédé de transfert de réseau d’accès pour un terminal mobile en itinérance

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 œuvre 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 >> (VoIP), « Partage de Contenu >>, ou « Messagerie Instantanée >>.

Plus particulièrement, la présente invention concerne le basculement d’une communication à laquelle participe un terminal mobile appartenant à un réseau IP, depuis un premier réseau d’accès à ce réseau IP vers un deuxième réseau d’accès à ce même réseau IP.

On dira qu’une ressource « appartient >> à un réseau IP donné lorsque le propriétaire de cette ressource possède un compte auprès d’un opérateur de ce réseau IP, et ce, quel que soit le réseau d'accès utilisé par le propriétaire pour se connecter au réseau IP. Dans le cadre du présent document, toute ressource de ce type sera, par souci de brièveté, désignée sous le nom de « dispositif-client » (« User Equipment» en anglais). Ces dispositifs-clients peuvent par exemple être un terminal fixe ou mobile, ou une passerelle domestique (« Residential Gateway » en anglais) ou située dans une entreprise, ou encore une passerelle d'opérateur réseau (« Voice Gateway » en anglais) telle qu'un DSLAM (initiales des mots anglais « Digital Subscriber Line Access Multiplexer » signifiant « Multiplexeur d'Accès de Lignes d'Abonnés Numériques »).

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 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, 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.

On rappelle que les services de communication sur réseau IP peuvent identifier des ressources physiques ou virtuelles au moyen de chaînes de caractères, par exemple des « URI >> (initiales des mots anglais « Uniform Resource Identifier» signifiant «Identifiant Uniforme de Ressource»). La syntaxe des URI est définie dans le document RFC 3986 de l’IETF ; la connaissance de l’URI d’une ressource permet (par exemple, au moyen d’une requête DNS) d’obtenir l’adresse IP d'un équipement du réseau de l'opérateur gérant cette ressource.

En particulier, dans les réseaux mettant en œuvre le protocole SIP, on distingue deux types d’identifiants de ressource : ceux de la forme « SIP-URI » telle que définie dans le document RFC 3261 de l’IETF, ou ceux de la forme « tel-URI » telle que définie dans le document RFC 3966 de l’IETF. Une SIP-URI est de la forme « user@host » (par exemple, alice@domaine1), où la partie « host » identifie le domaine de l'opérateur responsable de l'identité représentée par la partie « user ». Une tel-URI est de la forme « tel:numéro_de_téléphone » (par exemple, tel:-1-33123456789) en référence aux numéros de téléphone publics internationaux, ou de la forme « tel:numéro_de_téléphone;phone-context=... » (par exemple, tel:0623456789;phone-context=-i-33) en référence aux numéros de téléphone attribués par un opérateur pour son réseau privé.

Un même terminal, lorsqu’il est « multimode », peut être connecté et enregistré auprès d’un cœur de réseau IP par le biais de plusieurs réseaux d’accès, tels qu’un réseau GSM (Global System for Mobile Communications), un réseau UMTS (Universal Mobile Télécommunications System), un ensemble de lignes DSL (Digital Subscriber Line), un réseau Ethernet (norme ISO/IEC 8802- 3), un réseau WiFi (norme IEEE 802.11), ou un réseau LTE (Long Term Evolution). Un terminal multimode offre la possibilité à son utilisateur de choisir un réseau parmi les différents réseaux d’accès compatibles avec le terminal pour établir une communication. Les critères de choix appliqués relèvent généralement de l’utilisateur ou de l’opérateur du cœur de réseau IP : politique tarifaire de l’opérateur, qualité de la communication, bande passante disponible, et ainsi de suite.

Un terminal multimode permet également à son utilisateur de basculer en cours de communication d’un réseau d’accès (dit initial) à un autre réseau d’accès (dit cible), si par exemple la qualité de transmission sur le réseau d’accès initial devient médiocre. On parle alors de « basculement de la communication » (« handover » en anglais), ou de « transfert d’accès » entre le réseau d’accès initial et le réseau d’accès cible. Ce basculement peut concerner tout ou partie des flux média associés à la communication et/ou de la signalisation : on parle alors de transfert total ou partiel de la communication.

De nos jours, il existe un grand intérêt pour les services de téléphonie sur LTE (« Voice over LTE », ou VoLTE, en anglais), ainsi que pour les services de visiophonie sur LTE (« Video over LTE », ou ViLTE, en anglais). Dans ce cadre, il a été envisagé qu’en cas de nécessité on puisse transférer une communication d’un accès LTE vers un accès GSM ou UMTS ; un tel transfert est techniquement complexe puisqu’il faut notamment assurer la continuité d’un appel téléphonique initié dans un réseau à commutation de paquets (« packet-switched », ou PS en anglais) et poursuivi dans un réseau à commutation de circuits (« circuit-switched », ou CS en anglais).

Ainsi, les normes TS 23.237 (stage 2) et TS 24.237 (stage 3) du 3GPP (Third Génération Partnership Project) définissent des mécanismes de transfert d’accès pour le basculement depuis la VoLTE vers un réseau GSM ou UMTS, et offrent aux opérateurs souhaitant mettre en œuvre de tels transferts d’accès deux types de procédures. Le premier type est appelé « SRVCC » (initiales des mots anglais « Singie Radio Voice Caii Continuity» signifiant «Continuité d’Appel Vocal Radio Unique »). Le second type est appelé « eSRVCC » (initiales des mots anglais « enhanced Singie Radio Voice Caii Continuity» signifiant « Continuité d’Appel Vocal Radio Unique Optimisée »). Ces deux types de procédures utilisent un serveur d'applications (« Appiication Server», ou AS en anglais) dédié, appelé SCC-AS (d’après les initiales des mots anglais « Service Centraiization and Continuity» signifiant «Centralisation et Continuité de

Service »), pour gérer la signalisation reçue de la part des terminaux au moment du basculement.

En particulier, la procédure eSRVCC utilise, outre le SCC-AS, des entités appelées ATCF (initiales des mots anglais « Access Transfer Control Function » signifiant Fonction de Commande de Transfert d’Accés) et ATGW (initiales des mots anglais «Access Transfer Gateway» signifiant passerelle de Transfert d’Accès), qui sont placées sur le segment d’accès au cœur de réseau. La signalisation est ancrée dans l’ATCF, et le flux média est ancré dans l’ATGW. Cet ancrage n’est pas modifié lors du transfert de réseau d’accès, si bien que le SCC-AS n’a pas besoin d’indiquer au terminal distant une modification du flux média. Cette seconde procédure permet de réduire les temps de coupure de la communication vocale au moment du transfert d’accès par rapport à une procédure de type SRVCC, car la procédure eSRVCC intervient sur les flux média au plus près de l’utilisateur pour lequel elle est déclenchée, alors que la procédure SRVCC nécessite une renégociation complète entre les deux utilisateurs impliqués dans la communication. L’intérêt du eSRVCC par rapport au SRVCC, outre le fait de diminuer le nombre d’échanges de signalisation, est donc de pouvoir basculer les flux média au plus près de l’utilisateur changeant de réseau, pour que l’interruption du média soit la plus courte possible.

Le choix de la procédure à appliquer repose sur l’analyse par le SCC-AS des caractéristiques du flux média telles que transmises dans la signalisation lors du transfert : si le flux média n’est pas modifié, on peut appliquer la procédure eSRVCC ; si le flux média est modifié, on doit appliquer la procédure SRVCC.

Or, lorsque l’utilisateur est en situation d’itinérance (« roaming » en anglais), la communication traverse des équipements appelés « IBCF » (initiales des mots anglais « Interconnection Border Control Function » signifiant « Fonction de Commande de Frontière d’interconnexion ». Ces équipements assurent des fonctions de sécurité entre les opérateurs sur le plan de commande (signalisation SIP) et sur le plan de média ; on notera que les IBCF peuvent être la propriété d’opérateurs tiers, par exemple des opérateurs longue-distance. L’intérêt de la procédure eSRVCC est alors perdu, car la demande de basculement interprétée par l’ATCF situé dans le réseau d’accès visité de l’utilisateur va devoir traverser ces IBCF jusqu’à atteindre le SCC-AS du réseau d’origine (« home network » en anglais) de l’utilisateur. Ce faisant, la traversée des IBCF par cette demande de basculement va provoquer la prise de nouvelles ressources sur le plan média entre les réseaux des opérateurs visité et d’origine. La procédure eSRVCC ne se limite alors plus à basculer des flux du réseau d’accès, mais aussi à devoir créer de nouveaux chemins média bien plus haut dans le réseau entre les deux opérateurs, pour finir comme dans la procédure SRVCC jusqu’à l’autre utilisateur. La création de ces nouveaux chemins média nécessite plus de temps que le simple basculement de ressources existantes, et donc la coupure perçue par l’utilisateur sera sensiblement plus audible. De plus, plutôt que de n’avoir à gérer que l’aboutement de ressources média à l’accès, il faut engager de nouvelles ressources dans les cœurs de réseaux, alors que c’est justement ce que la procédure eSRVCC tente d’éviter. On se retrouve finalement avec les inconvénients relatifs à la procédure SRVCC, mais sur une architecture de type eSRVCC. Tout l’intérêt de la procédure eSRVCC disparaît : temps de rétablissement du média important, perception par le terminal initiateur et par son correspondant de la modification du chemin, renégociation du média de bout en bout, usage de ressources médias supplémentaires ...

La présente invention concerne donc, selon un premier aspect, un procédé de transfert de réseau d’accès pour un terminal mobile, dit premier terminal, appartenant à un réseau IP, comprenant les étapes suivantes : - il devient nécessaire pour ledit premier terminal de passer d’un premier à un deuxième réseau d’accès audit réseau IP, et - un serveur ATCF en charge dudit premier terminal fait parvenir à un serveur d’application SCC-AS, via un serveur IBCF, une requête apte à informer ledit serveur d’application SCC-AS qu’une procédure de transfert de réseau d’accès a été initiée pour le premier terminal.

Ledit procédé est remarquable en ce que ladite requête est agencée de manière à indiquer audit serveur d’application SCC-AS qu’il ne doit pas propager cette requête vers un dispositif-client, dit deuxième terminal, appartenant lui aussi au réseau IP, avec lequel le premier terminal est en cours de communication.

Ainsi, l'invention propose une nouvelle mise en œuvre pour la procédure eSRVCC lorsque des serveurs IBCF sont présents entre l’ATCF et le SCC-AS d’un terminal mobile, afin d’éviter d’avoir à renégocier complètement les médias jusqu’au correspondant de ce terminal mobile, comme c’est le cas dans la procédure SRVCC.

Grâce à l’invention, le transfert de réseau d’accès d’un terminal mobile itinérant pendant une communication avec un correspondant est complètement transparent pour ce correspondant. L’invention propose, à titre d’exemples, divers modes de réalisation.

Ainsi, selon des caractéristiques particulières, ladite requête est d’un type autre qu’une requête d’appel, et ledit serveur d’application SCC-AS répond à ladite requête en faisant parvenir un acquittement audit serveur ATCF.

Selon d’autres caractéristiques particulières, ladite requête contient une indication selon laquelle ledit serveur d’application SCC-AS ne doit pas prendre en compte une description de flux média contenue dans cette requête.

Selon des caractéristiques encore plus particulières, ladite indication de la requête indique au serveur IBCF également qu’il ne doit pas prendre en compte ladite description de flux média contenue dans cette requête.

Selon encore d’autres caractéristiques particulières, ladite requête ne contient pas de description de flux média, et ledit serveur d’application SCC-AS répond à cette requête avec un code d’erreur dédié.

Comme expliqué en détail ci-dessous, dans les trois modes de réalisation décrits succinctement ci-dessus, on conserve au niveau de l’IBCF les ressources média initialement engagées, et l’on évite la prise de nouvelles ressources média lors du basculement de la communication, de sorte que seul l’aboutement des ressources à l’accès doit être réalisé. On optimise ainsi les ressources média prises par les IBCF, et l’on évite le délai supplémentaire qui serait nécessaire à la prise de nouvelles ressources média, délai que l’utilisateur en itinérance pourrait percevoir lorsqu’il change de réseau d’accès. Ces modes de réalisation permettent donc de retrouver tous les avantages de la procédure eSRVCC classique, bien que des IBCF soient présents sur le chemin de signalisation ; de plus, la mise en oeuvre de ces modes de réalisation dans les réseaux exposant plusieurs IBCF aux tiers est également avantageuse, car elle évite de prendre de nouvelles ressources média sur un autre IBCF que l’IBCF initial, et apporte donc une optimisation de l’utilisation des ressources pour les opérateurs.

Selon un deuxième aspect, l'invention concerne divers dispositifs.

Elle concerne ainsi, premièrement, un serveur ATCF en charge d’un terminal mobile, dit premier terminal, appartenant à un réseau IP, et comprenant des moyens pour faire parvenir à un serveur d’application SCC-AS, via un serveur IBCF, une requête signalant audit serveur d’application SCC-AS qu’une procédure de transfert d’un premier à un deuxième réseau d’accès audit réseau IP a été initiée pour ledit premier terminal. Ledit serveur ATCF est remarquable en ce qu’il comprend en outre des moyens pour agencer ladite requête de manière à ce qu’elle indique audit serveur d’application SCC-AS qu’il ne doit pas propager cette requête vers un dispositif-client, dit deuxième terminal, appartenant lui aussi au réseau IP, avec lequel le premier terminal est en cours de communication.

Selon des caractéristiques particulières, ledit serveur ATCF comprend en outre des moyens pour envoyer audit premier terminal une requête de fin d’appel déclenchant la libération de leur lien média relatif au premier réseau d’accès, en réaction à la réception par le serveur ATCF d’un acquittement, ou d’une requête de fin d’appel, ou encore d’un message contenant un code d’erreur dédié, émis par ledit serveur d’application SCC-AS. L’invention concerne aussi, deuxièmement, un serveur d’application SCC-AS comprenant des moyens pour recevoir, via un serveur IBCF, de la part d’un serveur ATCF en charge d’un terminal mobile, dit premier terminal, appartenant à un réseau IP, une requête signalant qu’une procédure de changement de réseau d’accès audit réseau IP a été initiée pour ledit premier terminal. Ledit serveur d’application SCC-AS est remarquable en ce qu’il comprend en outre des moyens pour prendre en compte une indication de ladite requête selon laquelle ledit serveur d’application SCC-AS ne doit pas propager cette requête vers un dispositif-client, dit deuxième terminal, appartenant lui aussi au réseau IP, avec lequel le premier terminal est en cours de communication.

Selon des caractéristiques particulières, ledit serveur d’application SCC-AS comprend en outre des moyens pour constater que ladite requête est d’un type autre qu’une requête d’appel, et répondre à ladite requête en faisant parvenir un acquittement audit serveur ATCF.

Selon d’autres caractéristiques particulières, ledit serveur d’application SCC-AS comprend en outre des moyens pour prendre en compte une indication. contenue dans ladite requête, selon laquelle le serveur d’application SCC-AS ne doit pas prendre en compte une description de flux média contenue dans cette requête.

Selon encore d’autres caractéristiques particulières, ledit serveur d’application SCC-AS comprend en outre des moyens pour constater que ladite requête ne contient pas de description de flux média, et répondre à cette requête avec un code d’erreur dédié. L’invention concerne aussi, troisièmement, un serveur IBCF comprenant des moyens pour intercepter une requête émise par un serveur ATCF à l’intention d’un serveur d’application SCC-AS. Ledit serveur IBCF est remarquable en ce qu’il comprend en outre des moyens pour prendre en compte une indication, contenue dans ladite requête, selon laquelle il ne doit pas prendre en compte une description de flux média contenue dans cette requête.

Les avantages offerts par ces dispositifs sont essentiellement les 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.

Selon un troisième aspect, l’invention concerne un système de communication dans un réseau IP (Internet Protocol), comprenant au moins un serveur ATCF tel que décrit succinctement ci-dessus, et au moins un serveur SCC-AS tel que décrit succinctement ci-dessus. 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 transfert de réseau d’accès succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur.

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 particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui raccompagnent, dans lesquelles : - la figure 1 représente schématiquement une architecture réseau utilisée classiquement pour la procédure eSRVCC, - la figure 2 représente schématiquement une architecture réseau utilisée classiquement pour la procédure eSRVCC en situation d’itinérance, - la figure 3 illustre les étapes mises en œuvre classiquement dans la procédure eSRVCC en situation d’itinérance, - la figure 4 illustre les étapes mises en œuvre dans la procédure eSRVCC en situation d’itinérance, selon un premier mode de réalisation de l’invention, - la figure 5 illustre les étapes mises en œuvre dans la procédure eSRVCC en situation d’itinérance, selon un deuxième mode de réalisation de l’invention, et - la figure 6 illustre les étapes mises en œuvre dans la procédure eSRVCC en situation d’itinérance, selon un troisième mode de réalisation de l’invention.

Les procédures SRVCC et eSRVCC étant conçues pour fonctionner de préférence avec les réseaux IP de type IMS (initiales des mots anglais « IP Multimédia Subsystem » signifiant « Sous-système Multimédia sur IP »), on va commencer par quelques rappels sur ce type de réseau.

Les réseaux IMS utilisent le protocole de contrôle de session SIP (décrit succinctement ci-dessus). L’architecture IMS a été introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN (« Télécommunications and Internet Converged Services and Protocols for Advanced Networking ») 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 opérateurs réseau peuvent commodément mettre en œuvre 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.

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 en lui envoyant une requête appelée « SIP REGISTER ». Lorsque 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 dispositif-client 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 l'usager doit envoyer périodiquement au réseau une requête pour confirmer qu'il souhaite maintenir son enregistrement.

Pour pouvoir enregistrer les dispositifs-clients, les réseaux IMS comprennent un ou plusieurs serveurs d’enregistrement, appelés « S-CSCF » (initiales des mots anglais « Serving-Call Server Control 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 « l-CSCF » (initiales des mots anglais « Interrogating-Call Server Control Function » signifiant « Fonction de 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 « l/S-CSCF » — qui, au moment de l'enregistrement d'un dispositif-client, interrogent un serveur de 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 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 dispositifs-clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services auxquels il a droit.

Les réseaux IMS comprennent en outre : • un (ou plusieurs) serveur(s) de messagerie vocale : un serveur de messagerie vocale gère la souscription du dispositif-client aux événements de dépôt/consultation des messages de l'utilisateur de ce dispositif-client, et notifie le dispositif-client lors de l'occurrence de ces événements ; • un (ou plusieurs) serveur(s) de présence : un serveur de présence gère la souscription du dispositif-client aux événements de présence que l'utilisateur de ce dispositif-client souhaite surveiller, et notifie le dispositif-client lors de l'occurrence de ces événements ; et • un (ou plusieurs) serveur(s) de téléphonie : un serveur de téléphonie gère les services téléphoniques auxquels l'utilisateur du dispositif-client 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, les serveurs de présence et les serveurs de téléphonie sont des exemples de ce que l'on appelle des « serveurs d'applications >> (« application servers », ou AS, en anglais).

Le serveur S-CSCF qui a été attribué à l’utilisateur authentifie cet utilisateur, et télécharge ensuite le profil-utilisateur à partir du serveur HSS. Ce profil contient des informations sur les services auxquels cet utilisateur a droit. Les informations sont stockées sous la forme de « critères de filtre initiaux » (« initial Fiiter Criteria », ou iFC, en anglais). Le S-CSCF envoie alors un message appelé « enregistrement de tiers » (« third party registration » en anglais) à tous les serveurs d'application. Le corps de ce message contient des informations de service en langage XML et/ou la requête SIP REGISTER d’origine et/ou la réponse 200 OK à la requête SIP REGISTER d’origine. Le but de l'enregistrement de tiers est de faire savoir aux serveurs d'application que cet utilisateur est disponible sur le réseau (par exemple, le TAS arrêtera de transférer les appels destinés à cet utilisateur vers sa Boîte Vocale). L’utilisateur peut alors faire usage desdits services pendant la session en cours. Il peut par exemple s’agir de services offerts automatiquement à tous les utilisateurs du réseau IMS. Il peut aussi s’agir de services auxquels cet utilisateur a souscrit auprès de l’opérateur du réseau, et qui sont mis automatiquement à sa disposition. Enfin, il peut s’agir de services dont l’utilisateur peut faire usage après avoir émis une requête appropriée (SIP SUBSCRIBE). Ces services comprennent des applications audiovisuelles telles que mentionnées ci-dessus. Il peut s’agir également d’une souscription à l’état d’une ressource, auquel cas des notifications d’évènement (SIP NOTIFY) sont envoyées au dispositif-client dés lors que l’état de la ressource change.

Les réseaux IMS comprennent en outre un ou plusieurs serveurs 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 cœur de réseau IMS et le réseau d’accès utilisé par ce dispositif-client ; ainsi, toute la signalisation SIP échangée entre le dispositif-client d’une part, et le serveur d’interrogation l-CSCF ou le serveur d’enregistrement S-CSCF d’autre part, passe par le serveur P-CSCF.

Enfin, les réseaux IMS comprennent des passerelles média, telles que l’IMS-AGW (IMS Access Gateway). Une « passerelle média » est une entité responsable, sous le contrôle d’un serveur P-CSCF, de l’ouverture et de la fermeture des portes entre le réseau d’accès et le cœur de réseau sur le plan média ; l’entité « passerelle média » est également en charge de la police du trafic, ainsi que du marquage des flux média sur le plan de la Qualité de Service.

On va décrire à présent la procédure SRVCC, en puisant dans les articles de Frédéric Launay intitulés « SRVCC-Single Radio Voice Call Continuity » (disponible sur http://bloqs.univ-poitiers.fr/f-launav/2015/06/24/srvcc-sinale-radio-voice-call-continuitv/) et « SRVCC-Single Radio Voice Call Continuity-Suite » (disponible sur http://bloas.univ-poitiers.fr/f-launav/taa/esrvcc/).

Dans les réseaux IMS, lorsqu’un dispositif-client UE A émet un appel vers un dispositif-client UE B, ou reçoit un appel d’un dispositif-client UE B, une requête d’appel SIP INVITE est transmise à un serveur S-CSCF ; l’exécution de la tâche associée (renvoi de la requête vers un serveur d’applications) dépend des règles de souscription de l’abonné, et la tâche qui est réalisée est obtenue en appliquant l’événement (par exemple un appel) â la liste de règles définie â travers les paramètres du filtre iFC mentionné ci-dessus. Lorsque la procédure SRVCC s’applique, l’appel est dirigé vers le serveur SCC-AS mentionné ci-dessus. Plus précisément, si l’on considère le dispositif-client à l’origine de l’appel, l’appel sera transmis d’abord au SCC-AS avant d’être traité par le

Serveur d’Application de Téléphonie (« Telephony Application Server», ou TAS, en anglais) ; si l’on considère le dispositif-client destinataire de l’appel, l’appel est d’abord transmis au TAS, qui le transfère ensuite au SCC-AS.

Le transfert de réseau d’accès comprend notamment le transfert de la communication depuis l’entité appelée MME (Mobility Management Entity) du réseau LTE vers l’entité appelée MSC (Mobile Switching Center) du réseau GSM ou UMTS. Le MME et le MSC sont des contrôleurs connectés à un serveur P-CSCF du cœur de réseau IMS ; le transfert de réseau d’accès s’accompagne ainsi d’un transfert de session au niveau du cœur de réseau.

Quand on détecte que le signal reçu par un dispositif-client UE A est faible, le MME responsable de ce dispositif-client envoie une requête de basculement au réseau CS. Pour ce faire, le MME doit être en mesure de : - séparer le flux Data (PS) du flux Voix (géré par le mode CS après basculement), - gérer le basculement des canaux virtuels (« bearers >>) PS non-Voix vers le réseau cible, et - initier la procédure de basculement SRVCC en s’appuyant sur le bearer

Voix.

Une interface, nommée « Sv >>, entre le MSC et le MME permet au MME de : - demander au MSC de réserver des ressources radio au niveau de l’interface d’accès radio CS (station de base, ou Mode B) ; le MSC est donc responsable de la réservation de ressources pour la continuité d’appel ; et - donner au MSC un identifiant du SCC-AS afin que le MSC puisse propager vers le SCC-AS une requête INVITE émise par le dispositif-client UE A.

Lors de son attachement au réseau IMS, le MME a récupéré un identifiant appelé « STN-SR >> (initiales des mots anglais « Session Transfer Number for SRVCC >> signifiant « Numéro de Transfert de Session pour SRVCC >>) de la part du serveur HSS (qui l’a lui-même reçu du SCC-AS). Il s’agit d’un numéro au format téléphonique répondant à la spécification E.164. Cet identifiant est transmis par le MME au MSC afin que ce dernier puisse créer un chemin de signalisation entre le dispositif-client UE A et le SCC-AS.

Le MSC émet alors une requête SIP vers l’IMS au moyen du numéro STN-SR. Le SCC-AS reçoit la requête INVITE avec un message de demande de transfert d’une session active, et prend en charge le transfert de session. A partir de ce moment, le MME peut demander au dispositif-client UE A de basculer vers le réseau GSM ou UMTS. Après le basculement, la signalisation SIP est transmise du SCC-AS vers le MSC.

Or la modification de l’adresse IP de destination (dispositif-client UE A vers MSC) pour le média Voix provoque des pertes de paquets et une certaine latence, car toutes les entités du réseau IMS associées au dispositif-client UE B, et le dispositif-client UE B lui-même, doivent modifier le chemin de leurs requêtes SIP.

On va décrire à présent la procédure eSRVCC classique, en puisant dans l’article « Mind the coverage hole! » (disponible sur le site https://realtimecommunication.wordpress.eom/2015/03/24/mind-the-coveraae- hole/#more-380).

La procédure eSRVCC classique est décrite dans les normes GSMA IR.64, 3GPP 23.237 et ETSI TS 124 237. L’architecture utilisée dans cette procédure est illustrée schématiquement sur la figure 1.

On trouve notamment, dans le réseau d’accès PS (par exemple, LTE) : • une station eNode B ; • un MME ; • une passerelle SGW (Serving Gateway) : la SGW route et transmet les paquets de données d'utilisateur, et fait aussi office de point d’ancrage de mobilité pour les données d'utilisateur lors des transferts entre stations eNode B, ainsi que de point d’ancrage lors des transferts entre un réseau LTE et un réseau mettant en œuvre une autre technologie 3GPP ; et • une passerelle PGW (PDN Gateway) : la PGW fournit la connectivité entre l'UE et les réseaux à paquets de données (« Racket Data Networks », ou PDN en anglais) externes, en servant de point d'entrée et de sortie du trafic pour l'UE ; un UE peut être connecté simultanément à plusieurs PGW pour avoir accès à plusieurs PDN ; la PGW assure l'exécution de la politique réseau, le filtrage de paquets pour chaque utilisateur, l'assistance à l'imputation, l'interception légale et l’auscultation de paquets.

Dans le réseau CS (par exemple GSM ou UMTS), le MSC est associé à une passerelle média MGW, qui est située à la frontière entre le réseau d’accès CS et le réseau IMS auquel est connecté le terminal UE B.

Comme mentionné ci-dessus, l’architecture eSRVCC comprend deux entités destinées à servir de points d’ancrage sur le segment d’accès au cœur de réseau. Ces entités, représentées schématiquement sur la figure 1, sont les suivantes : • l’ATCF agit comme point d’ancrage pour la signalisation SIP, et est placé dans le chemin de signalisation SIP entre le P-SCSF et le S-CSCF ; chaque ATCF est identifié par un STN-SR ; dans une architecture incluant des ATCF, le SCC-AS aura la charge de transmettre le STN-SR de l’ATCF en charge d’un abonné vers le HSS ; le SCC-AS reçoit le STN-SR de l’ATCF au moment de l’enregistrement de l’abonné, puis il le transmet au HSS ; le HSS le transmet à son tour vers le MME (comme dans le cadre de la procédure SRVCC décrite succinctement ci-dessus) ; et • l’ATGW agit comme point d’ancrage pour le flux média; l’ATGW est contrôlé par l’ATCF ; l’ATGW est souvent co-localisé avec une passerelle média IMS-AGW.

Comme expliqué ci-dessus, lorsqu’un terminal mobile UE A s’enregistre sur un réseau IMS, il émet une requête SIP REGISTER, qui est réceptionnée par un serveur P-CSCF. Selon la procédure eSRVCC, ce serveur P-CSCF transmet la requête SIP REGISTER à l’ATCF. Selon la norme ETSI TS 124 237, mentionnée ci-dessus, le terminal mobile UE A ne doit pas nécessairement, lors de son enregistrement, annoncer sa capacité à mettre en œuvre la procédure eSRVCC (il doit en revanche le faire lors d’un appel). Si le réseau d’origine du terminal mobile UE A est compatible avec la procédure eSRVCC, l’ATCF décide, en fonction de la politique de l'opérateur, d’ancrer ou non la signalisation SIP. S’il décide d’ancrer la signalisation, l'ATCF enrichit la requête SIP REGISTER initiale, notamment en s'incluant lui-même pour des sessions créées sur la base du présent enregistrement, et en ajoutant son URI (appelée ATCF-URI) dans le chemin de signalisation. On notera que pour les requêtes terminales, l’ATCF-URI pourra identifier de manière unique cet enregistrement (ou flux d'enregistrement, au cas où l’on utilise un mécanisme d'enregistrement multiple). L'ATCF transmet ensuite la requête SIP REGISTER ainsi enrichie au serveur l-CSCF, qui envoie au SCC-AS un message contenant la requête SIP REGISTER initiale dans le corps de message. Le SCC-AS prend en compte le STN-SR (mentionné ci-dessus) de l’ATCF, et met à jour le serveur HSS. Le SCC-AS envoie ensuite à l’ATCF, dans le corps de message d'une requête selon la méthode SIP MESSAGE (décrite dans le document RFC 3428 de l’IETF) : - le numéro de téléphone public, autrement dit le « Numéro ISDN de Station Mobile » (« Mobile Station ISDN Number», ou MSlSDN en anglais), de l'utilisateur dans le réseau CS, appelé en l’occurrence « MSlSDN de corrélation » et noté C-MSISDN, et - rURI du SCC-AS, appelée ATU-STI (initiales des mots anglais « Access Transfer Update - Session Transfer Identifier» signifiant « Mise à jour de Transfert d’Accès - Identifiant de Transfert de Session »).

Lorsque la nécessité d’un basculement apparaît (du fait, généralement, que le signal reçu par le terminal mobile est trop faible), le MME envoie une requête de basculement au réseau CS. La requête contient notamment le STN-SR de l’ATCF et le C-MSISDN de l'utilisateur. Le MSC/MGCF produit une nouvelle requête SIP INVITE incluant ce STN-SR et ce C-MSISDN, et l’envoie à l’ATCF. L’ATCF trouve le C-MSISDN concerné dans le champ « P-Asserted-Identity » de la requête INVITE reçue, et envoie au SCC-AS, au moyen de l’ATU-STI (mentionné ci-dessus), une nouvelle requête SIP INVITE reproduisant l’entête « Target-Dialog >> de la requête INVITE reçue.

La figure 2 représente schématiquement une architecture réseau utilisée classiquement pour la procédure eSRVCC en situation d’itinérance. Une connexion entre un serveur IBCF, appelé « IBCF1 », du réseau visité et un serveur IBCF, appelé « IBCF2 », du réseau d’origine permet à un terminal mobile UE A de communiquer avec son réseau d’origine.

La figure 3, qui est tirée de l’annexe A. 18.6 de la spécification TS 24.237, illustre les étapes mises en oeuvre classiquement dans la procédure eSRVCC en situation d’itinérance.

Initialement (étapes 1a, 1b et 1c), on établit des flux média sur les réseaux PS entre un terminal mobile UE A et un dispositif-client UE B.

Lorsque la nécessité d’un basculement apparaît pour le terminal UE A, le MSC/MGW émet (étape 2) une requête INVITE vers l’ATCF/ATGW.

Les anciens flux média PS (« Old PS media ») étant pour l’instant conservés, le terminal UE A émet (étape 5a1 ), sur son nouveau réseau d’accès CS, de nouveaux flux média CS (« New CS media »). La MGW traduit ces flux CS en flux PS (« new PS media»), et envoie ces derniers à l’ATCF/ATGW (étape 5a2). L’ATCF/ATGW envoie alors (étape 6) à l’IBCF2 une requête INVITE contenant l’ATU-STI, que l’IBCF2 transfère au SCC-AS (étape 7). Au passage, cette requête INVITE déclenche, de la part de l’IBCF2, la réservation de ressources dans le plan média pour l’aboutement des ressources média du côté du terminal UE A, et des ressources média du côté du dispositif-client UE B.

Le SCC-AS compare la description de flux média contenue dans cette requête INVITE avec la description de flux média contenue dans la requête INVITE à l’origine des flux média initiaux (étapes la, 1b et 1c), et constate que ces deux descriptions sont différentes (cette différence est due à l’entremise du, ou des serveurs IBCF). En conséquence, le SCC-AS envoie une nouvelle requête INVITE au dispositif-client UE B (étape 8).

Les nouvelles ressources média, précédemment réservées par l’IBCF2, sont ensuite effectivement prises suite à la réception par l’IBCF2 d’un acquittement 200 OK (étape 11 ). On notera qu’il y a alors (étapes 15a, 15b, 15c, 15a1, 15a2, 15b1 et 15c1) coexistence des anciens et des nouveaux flux média. Les anciens flux média ne sont abandonnés que suite à la réception par l’ATCF/ATGW d’une requête de fin d’appel SIP BYE (étapes 16 à 18) envoyée par le SCC-AS (et relayée par l’IBCFI).

On va décrire à présent plusieurs modes de réalisation de l’invention.

La figure 4 illustre les étapes mises en œuvre dans la procédure eSRVCC en situation d’itinérance, selon un premier mode de réalisation de l’invention.

Les étapes la à 5a2 sont analogues aux étapes correspondantes de la procédure eSRVCC classique décrite ci-dessus en référence à la figure 3.

Mais alors, à l’étape 6, au lieu de faire suivre vers le SCC-AS la requête d’appel SIP INVITE qu’il a reçue, l’ATCF/ATGW lui fait parvenir (via l’IBCF2, étape 7) une requête d’un type autre qu’une requête d’appel (telle qu’une méthode SIP INVITE) ; on pourra utiliser pour ce faire, par exemple, une requête SIP MESSAGE, ou SIP INFO, ou encore SIP REFER.

Cette requête SIP est adressée à l’ATU-STI du SCC-AS (en tant que Request-URI, c’est-à-dire en tant qu’identifiant de ressource, du SCC-AS), de manière à informer le SCC-AS, comme dans la procédure eSRVCC classique, qu’une procédure de transfert d’accès a été initiée. Cette requête SIP inclut également l’en-tête « Target-Dialog >> (classiquement inséré dans la requête INVITE), et/ou l’en-tête « Session-ID >> (décrit dans le document RFC 7329 de riETF) si cet en-tête était présent dans la requête INVITE initiale (i.e. lors de rinitiation de la communication entre l’UE A et l’UE B).

Voici un exemple d’une telle requête (dans laquelle la Request-URI est la SIP-URI « sip:ATU-STI 1@sccas.home1.net >>) :

MESSAGE sip:ATU-STI10sccas.homel.net SIP/2.0 Via: SIP/2.0/UDP atcf.visited2.net : 5060 ;branch=z9hG4bk731b87

Max-Eorwards: 70 P-Asserted-Identity: <tel:+l-237-555-2222> P-Charging-Vector: icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=visitl.net Privacy: none

From: <tel:+1-237-555-3333>;tag=l888828 To: <tel: +1-237-555-4444>

Call-ID: cb03a0s09a2sdfglkj490444 Cseq: 127 MESSAGE Require: tdialog

Record-Route :<sip: atcf.visited2.net : 50 60 ;lr>

Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321 ; local-tag=64 72 78 91 Session-ID: 2sdfgjkl4917

Accept-Contact: * ;+g.3gpp.icsi-ref= "urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER Content-Length: 0

On notera que lors du transfert de cette requête l’IBCF 2 ne peut réserver aucune ressource média, puisque la requête ne contient aucune description de flux média. De ce fait, cette requête est, avantageusement, traitée plus rapidement qu’une requête (par exemple une requête SIP INVITE) contenant une description de flux média.

Suite à la réception de cette requête par le SCC-AS : - si le SCC-AS n’est pas compatible avec la présente invention, il envoie un message « 405 Method Not Implemented » à l’ATCF/ATGW, qui se replie alors sur la procédure eSRVCC classique ; - si, en revanche, le SCC-AS est compatible avec la présente invention, il ne propage pas la requête vers le deuxième terminal UE B, et envoie à l’ATCF/ATGW (étapes 8 et 9) un acquittement 200 OK (relayé par l’IBCF2).

Conformément à l’invention, les anciens flux média PS sont conservés (étapes 10b et 10c), en dépit de l’existence des nouveaux flux média CS (étape lOal) entre le terminal UE A et le MSC/MGW, et des nouveaux flux média PS (étape 10a2) entre le MSC/MGW et l’ATCF/ATGW.

Enfin, si l’ATCF/ATGW constate, suite à la réception de l’acquittement 200 OK envoyé par le SCC-AS comme décrit ci-dessus (étape 9), que le lien PS entre l’ATCF et le terminal UE A n’a pas encore été libéré (comme il peut l’avoir été suite à une suppression des ressources radio requises), l’ATCF/ATGW envoie au terminal UE A une requête de fin d’appel SIP BYE (étape 11) pour déclencher cette libération.

On notera que, contrairement à la procédure classique (cf. étapes 16 et 17 de la figure 3), l’ATCF n’a pas reçu de requête SIP BYE de la part du SCC-AS.

La figure 5 illustre les étapes mises en oeuvre dans la procédure eSRVCC en situation d’itinérance, selon un deuxième mode de réalisation de l’invention.

Les étapes 1a à 5a2 sont analogues aux étapes correspondantes de la procédure eSRVCC classique décrite ci-dessus en référence à la figure 3.

Mais alors, aux étapes 6 et 7, au lieu de faire suivre vers le SCC-AS la requête d’appel SIP INVITE qu’il a reçue, l’ATCF/ATGW lui fait parvenir (via riBCF 2) une requête SIP INVITE contenant une indication selon laquelle le SCC-AS ne doit pas prendre en compte la description de flux média contenue dans cette requête. Pour ce faire, on peut utiliser par exemple une requête SIP INVITE contenant un en-tête «Access-Transfer» valorisé avec un indicateur dédié, que l’on appellera « at-no-new-ressources ». Naturellement, cette requête SIP INVITE est adressée à l’ATU-STI du SCC-AS, de manière à informer le SCC-AS qu’une procédure de transfert d’accès a été initiée.

Au passage, l’IBCF 2, au vu de cet indicateur « at-no-new-ressources », est informé qu’il ne doit pas réserver de nouvelles ressources média, et ce, en dépit de la présence d’une description de flux média dans le corps de message.

La figure 5 indique, à titre d’exemple, que ladite description de flux média obéit au format SDP (Session Description Protocol), qui est le format habituellement utilisé à cet effet.

Suite à la réception de cette requête INVITE, le SCC-AS ne la propage pas vers le deuxième terminal UE B, et envoie à l’ATCF/ATGW (étapes 8 et 9) un acquittement 200 OK (relayé par l’IBCF2).

Les anciens flux média sont conservés (étapes 12b et 12c), en dépit de l’existence des nouveaux flux média CS (étape 12a1) entre le terminal UE A et le MSC/MGW, et des nouveaux flux média PS (étape 12a2) entre le MSC/MGW et l’ATCF/ATGW.

La procédure se termine par l’émission par le SCC-AS d’une requête de fin d’appel SIP BYE (étapes 13 et 14) en réponse à la requête d’appel SIP INVITE de l’étape 7. La réception (via l’IBCF 2) de cette requête de fin d’appel SIP BYE par l’ATCF provoque la libération (étape 15) du lien PS entre l’ATCF et le terminal UE A.

La figure 6 illustre les étapes mises en œuvre dans la procédure eSRVCC en situation d’itinérance, selon un troisième mode de réalisation de l’invention.

Les étapes 1a à 5a2 sont analogues aux étapes correspondantes de la procédure eSRVCC classique décrite ci-dessus en référence à la figure 3.

Mais alors, aux étapes 6 et 7, la requête adressée par l’ATCF/ATGW à lATU-STI du SCC-AS est une requête d’appel SIP INVITE ne contenant pas de description de flux média (ce qui est indiqué sur la figure 6 par « INVITE sans SDP »). Au passage, l’IBCF2 ne peut pas réserver de nouvelles ressources média pour la communication en cours, puisqu’aucune description de flux média n’est mentionnée.

Suite à la réception de cette requête, le SCC-AS ne la propage pas vers le deuxième terminal UE B, et répond à l’ATCF/ATGW (via l’IBCF2, étapes 8 et 9), avec un code d’erreur dédié (par exemple « 492 >>).

Les anciens flux média sont conservés (étapes 12b et 12c), en dépit de l’existence des nouveaux flux média CS (étape 12a1) entre le terminal UE A et le MSC/MGW, et des nouveaux flux média PS (étape 12a2) entre le MSC/MGW et l’ATCF/ATGW.

La procédure se termine par la libération (étape 13) du lien PS entre l’ATCF et le terminal UE A, en réponse à la réception par l’ATCF (étape 9) du message avec code d’erreur « 492 ».

Dans les trois modes de réalisation décrits ci-dessus, et plus précisément aux étapes : - 6 à 9 du premier mode, - 6 à 11, 13, 14, 17 et 18 du deuxième mode, et - 6 à 11 du troisième mode, on a mis en œuvre (à titre d’exemple) l’IBCF 2 et non l’IBCF 1. On notera toutefois que l’on peut tout aussi bien, pour ces étapes, mettre en œuvre l’IBCF 1 au lieu de l’IBCF 2.

On notera également que l’ATCF est situé sur le chemin de signalisation de la requête d’enregistrement REGISTER envoyée par le terminal UE A au serveur S-CSCF. Si cet ATCF est compatible avec la présente invention, il peut, optionnellement, indiquer sa compatibilité en insérant un indicateur (« feature tag» en anglais) dédié, que l’on appellera « at-keep-ressources », dans l’en-tête Feature-Caps (défini dans le document RFC 6809 de l’IETF) de la requête REGISTER. De même, si le serveur SCC-AS est compatible avec la présente invention, il peut, optionnellement, suite à la réception de la requête REGISTER associée à l’enregistrement de tiers (décrit ci-dessus), insérer un indicateur dédié, par exemple le même indicateur « at-keep-ressources >>, dans l’en-tête Feature-Caps de la requête MESSAGE que le SCC-AS envoie en retour à l’ATCF. Grâce à ces dispositions, les entités ATCF et SCC-AS s’informent mutuellement dès la fin de la procédure d’enregistrement du premier terminal UE A, de leurs compatibilités respectives avec la présente invention.

La présente invention peut être mise en oeuvre au sein des nœuds d’un réseau IP, par exemple des serveurs ATCF, des IBCF ou des serveurs SCC-AS, au moyen de composants logiciels et/ou matériels.

Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud 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 classique une unité centrale de traitement commandant par des signaux 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 œuvre de l'un quelconque des procédés de transfert de réseau d’accès selon l’invention.

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 transfert de réseau d’accès 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 ê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 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.

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 (« 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 téléchargé sur un réseau de type Internet.

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 transfert de réseau d’accès selon l'invention.

Claims (13)

1. REVENDICATIONS

   1. Procédé de transfert de réseau d’accès pour un terminal mobile, dit premier terminal (UE A), appartenant à un réseau IP (Internet Protocol), comprenant les étapes suivantes : - il devient nécessaire pour ledit premier terminal (UE A) de passer d’un premier à un deuxième réseau d’accès audit réseau IP, et -un serveur ATCF (Access Transfer Control Function) en charge dudit premier terminal (UE A) fait parvenir à un serveur d’application SCC-AS (Service Centralization and Continuity), via un serveur IBCF (Interconnection Border Control Function), une requête apte à informer ledit serveur d’application SCC-AS qu’une procédure de transfert de réseau d’accès a été initiée pour le premier terminal (UE A), caractérisé en ce que ladite requête est agencée de manière à indiquer audit serveur d’application SCC-AS qu’il ne doit pas propager cette requête vers un dispositif-client, dit deuxième terminal (UE B), appartenant lui aussi au réseau IP, avec lequel le premier terminal est en cours de communication.
2. 2. Procédé de transfert de réseau d’accès selon la revendication 1, caractérisé en ce que : - ladite requête est d’un type (MESSAGE, INFO, REFER) autre qu’une requête d’appel, et - ledit serveur d’application SCC-AS répond à ladite requête en faisant parvenir un acquittement (200 OK) audit serveur ATCF.
3. 3. Procédé de transfert de réseau d’accès selon la revendication 1, caractérisé en ce que ladite requête contient une indication (at-no-new-ressources) selon laquelle ledit serveur d’application SCC-AS ne doit pas prendre en compte une description de flux média contenue dans cette requête.
4. 4. Procédé de transfert de réseau d’accès selon la revendication 3, caractérisé en ce que ladite indication (at-no-new-ressources) de la requête indique au serveur IBCF également qu’il ne doit pas prendre en compte ladite description de flux média contenue dans cette requête.
5. 5. Procédé de transfert de réseau d’accès selon la revendication 1, caractérisé en ce que ladite requête ne contient pas de description de flux média, et en ce que ledit serveur d’application SCC-AS répond à cette requête avec un code d’erreur dédié (492).
6. 6. Serveur ATCF (Access Transfer Control Function) en charge d’un terminal mobile, dit premier terminal (UE A), appartenant à un réseau IP (Internet Protocol), et comprenant des moyens pour faire parvenir à un serveur d’application SCC-AS (Service Centralization and Continuity), via un serveur IBCF (Interconnection Border Control Function), une requête signalant audit serveur d’application SCC-AS qu’une procédure de transfert d’un premier à un deuxième réseau d’accès audit réseau IP a été initiée pour ledit premier terminal (UE A), ledit serveur ATCF étant caractérisé en ce qu’il comprend en outre des moyens pour agencer ladite requête de manière à ce qu’elle indique audit serveur d’application SCC-AS qu’il ne doit pas propager cette requête vers un dispositif-client, dit deuxième terminal (UE B), appartenant lui aussi au réseau IP, avec lequel le premier terminal est en cours de communication.
7. 7. Serveur ATCF selon la revendication 6, caractérisé en ce qu’il comprend en outre des moyens pour envoyer audit premier terminal (UE A) une requête de fin d’appel (SIP BYE) déclenchant la libération de leur lien média relatif au premier réseau d’accès, en réaction à la réception par le serveur ATCF d’un acquittement (200 OK), ou d’une requête de fin d’appel (SIP BYE), ou encore d’un message contenant un code d’erreur dédié (492), émis par ledit serveur d’application SCC-AS.
8. 8. Serveur d’application SCC-AS (Service Centralization and Continuity), comprenant des moyens pour recevoir, via un serveur IBCF (Interconnection Border Control Function), de la part d’un serveur ATCF (Access Transfer Control Function) en charge d’un terminal mobile, dit premier terminal (UE A), appartenant à un réseau IP (Internet Protocol), une requête signalant qu’une procédure de changement de réseau d’accès audit réseau IP a été initiée pour ledit premier terminal (UE A), ledit serveur d’application SCC-AS étant caractérisé en ce qu’il comprend en outre des moyens pour prendre en compte une indication de ladite requête selon laquelle ledit serveur d’application SCC-AS ne doit pas propager cette requête vers un dispositif-client, dit deuxième terminal (UE B), appartenant lui aussi au réseau IP, avec lequel le premier terminal est en cours de communication.
9. 9. Serveur d’application SCC-AS selon la revendication 8, caractérisé en ce qu’il comprend en outre des moyens pour : - constater que ladite requête est d’un type (MESSAGE, INFO, REFER) autre qu’une requête d’appel, et - répondre à ladite requête en faisant parvenir un acquittement (200 OK) audit serveur ATCF.
10. 10. Serveur d’application SCC-AS selon la revendication 8, caractérisé en ce qu’il comprend en outre des moyens pour prendre en compte une indication (at-no-new-ressources), contenue dans ladite requête, selon laquelle le serveur d’application SCC-AS ne doit pas prendre en compte une description de flux média contenue dans cette requête.
11. 11. Serveur d’application SCC-AS selon la revendication 8, caractérisé en ce qu’il comprend en outre des moyens pour : - constater que ladite requête ne contient pas de description de flux média, et - répondre à cette requête avec un code d’erreur dédié (492).
12. 12. Serveur IBCF (Interconnection Border Control Fonction), comprenant des moyens pour intercepter une requête émise par un serveur ATCF (Access Transfer Control Fonction) à l’intention d’un serveur d’application SCC-AS (Service Centralization and Continuity), caractérisé en ce qu’il comprend en outre des moyens pour prendre en compte une indication (at-no-new-ressources), contenue dans ladite requête, selon laquelle il ne doit pas prendre en compte une description de flux média contenue dans cette requête.
13. 13. Système de communication comprenant au moins un serveur ATCF selon la revendication 6 ou la revendication 7, et au moins un serveur d’application SCC-AS selon l’une quelconque des revendications 8 à 11.