EP3583757B1 - Method for changing mobile network - Google Patents

Description

The present invention relates to IP (" Internet Protocol ") type communications networks, and in particular those among the IP networks which are capable of implementing advanced session control protocols. IP networks allow the distribution of conversational data, as part of services such as “Voice over IP” (VoIP), “Content Sharing”, or “Instant Messaging”.

More particularly, the present invention relates to mobile network changes on the part of a mobile terminal (for the sake of brevity, we will simply say “terminal” hereinafter) during communication. We speak of "communication handover ", or "access transfer", when a terminal communicates via an IP core network to which it belongs, first going through a first access , called initial, then by a second access, called target, to this core network (we say that a terminal “belongs” to a given IP network when the user of this terminal has an account with the operator of this IP network, regardless of the access used by the user to connect to the IP network). This switchover, which can be, for example, triggered by a degradation of the transmission quality on the initial mobile network, can concern all or part of the media flows associated with the communication and/or signaling: we then speak of total transfer or partial communication.

Conventional advanced session control protocols, such as the SIP protocol (initials of the English words " Session Initiation Protocol ", meaning "Session Initiation Protocol"), use so-called "signaling" messages, which are messages allowing a terminal to request a connection with another terminal, or also messages signaling that a telephone line is busy, or signaling that the called telephone is ringing, or even signaling that such and such a telephone is connected to the network and can be reached from such and such manner.

The SIP protocol was defined by the IETF ( Internet Engineering Task Force ) in document RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol. The SIP protocol was then extended in particular in document RFC 3265. This extension defines event notification procedures.

Remember that communication services on an IP network can identify physical or virtual resources by means of character strings, for example “URIs” (initials of the English words “ Uniform Resource Identifier ” meaning “Uniform Resource Identifier”). URI syntax is defined in IETF RFC 3986; knowing the URI of a resource makes it possible (for example, by means of a DNS query) to obtain the IP address of network equipment of the operator managing this resource.

In particular, in networks implementing the SIP protocol, two types of resource identifiers are distinguished: those of the form “SIP-URI” as defined in document RFC 3261 of the IETF, or those of the form “tel-URI” as defined in IETF RFC 3966. A SIP-URI is of the form "user@host" (for example, alice@domain1), where the "host" part identifies the domain of the operator responsible for the identity represented by the "user" part. A tel-URI is of the form "tel:phone_number" (for example, tel:+33123456789) in reference to international public telephone numbers, or of the form "tel:phone_number;phone-context=..." (for example, tel:0623456789;phone-context=+33) in reference to telephone numbers assigned by an operator for its private network.

This SIP protocol is used in particular in IMS type infrastructures (initials of the English words “ IP Multimedia Subsystem ” meaning “Multimedia Subsystem over IP”).

The IMS architecture was introduced by the 3GPP for mobile networks, then taken over by TISPAN (“ Telecommunications and Internet Converged Services and Protocols for Advanced Networking ”) for fixed networks. This architecture allows the dynamic establishment and control of multimedia sessions between two clients as well as the reservation of resources at the level of the multimedia stream transport network. Thanks to this architecture, network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate the amounts to be paid. bill customers. The IMS currently provides access to services such as telephony, video telephony, Presence and Instant Messaging, for which it also manages the interaction.

Each user of an IMS network can be identified by means of various identities, including IMPI (initials of the English words “ IP Multimedia Private Identity ” meaning “Private Identity for IP Multimedia”) and IMPU (initials of the English words “ IP Multimedia PUblic identity ” meaning “Public Identity for IP Multimedia”).

IMPI is defined in 3GPP specification TS 23.228. The IMPI is an identity permanently assigned by the operator of a network to a subscription with this operator, and is used, for example, for registration, access authorization, administration of services offered to the user, and billing (note that a user can have several IMPIs within the same subscription; each IMPI can thus be associated with a different terminal). The IMPI has the form of a NAI (initials of the English words “ Network Access Identifier ” meaning “Network Access Identifier”), as defined in document RFC 4282 of the IETF. Note that in most current mobile networks, the IMPI is derived from the IMSI (International Mobile Subscriber Identity) identifier stored in the SIM (Subscriber Identity Module) card; it is then easy to establish a correspondence between these two identities; in particular, the IMSI is, conversely, deductible from the IMPI.

A user uses his IMPU to communicate with other users. The IMPU is in the form of a URI or a short number, or even any alias. In a mobile network, part of the IMPU corresponds to the public telephone number (ie for use by third parties) of the user, called MSISDN (initials of the English words " Mobile Station ISDN Number " meaning "Station ISDN Number"). Mobile ") ; therefore there is a direct correlation between IMPU and MSISDN.

Note that, for a given IMPI, there may be several IMPUs (for example, a tel-URI and a SIP-URI).

Note also that an IMPU can be shared, so that several terminals (for example, phones, smartphones, or tablets) can be reached with the same public identity (for example, a telephone number). single phone for a whole family of users). Each of these terminals is distinguished by its own private identity (IMPI). A common example of such a multi-terminal configuration is the “multi-SIM” case: a user who subscribes to this option has several SIM cards (and therefore several IMSIs), which can be reached using the same telephone number public MSISDN.

All of these identities of a user are configured by the operator when creating an account with that operator, and used when attaching and registering the user on the network.

In particular, the same terminal, when it is "multi-mode", can attach to and register with an IP core network via several types of mobile networks, such as a GSM (Global System) network. for Mobile Communications), a UMTS (Universal Mobile Telecommunications System) network, a WiFi network (IEEE 802.11 group standards), or an LTE (Long Term Evolution) network. A multi-mode terminal offers its user the possibility of choosing the best possible network to establish communication. The choice criteria applied generally depend on the user or operator of the IP network: operator pricing policy, quality of communication, available bandwidth, and so on.

Nowadays, there is great interest in Voice over LTE (VoLTE) telephony services, as well as Video over LTE (ViLTE) telephony services. English). In this context, it was envisaged that, if necessary, we could switch a communication from an LTE mobile network to a GSM or UMTS mobile network; such a switchover is technically complex, because it is necessary in particular to ensure the continuity of a telephone call initiated in a packet-switched network (“ packet-switched ”, or PS, in English) and continued in a circuit-switched network ( “ circuit-switched ”, or CS, in English).

Thus, the TS 23.237 (stage 2) and TS 24.237 (stage 3) standards of the 3GPP (Third Generation Partnership Project) define access transfer mechanisms for switching from an LTE network to a GSM or UMTS network, and offer operators wishing to implement such access transfers two types of procedures. The first type is called “SRVCC” (initials of the English words “ Single Radio Voice Call Continuity ” meaning “Unique Radio Voice Call Continuity”). The second type is called “eSRVCC” (initials of the English words “ enhanced Single Radio Voice Call Continuity ” meaning “Optimized Single Radio Voice Call Continuity”). These two types of procedures use a dedicated application server (“ Application Server ”, or AS, in English), called SCC-AS (after the initials of the English words “ Service Centralization and Continuity ” meaning “Centralization and Continuity of Service"), to manage the signaling received from the terminals at the time of switchover.

The eSRVCC procedure in particular uses, in addition to the SCC-AS, entities called ATCF (initials of the English words “ Access Transfer Control Function ” meaning Function of Access Transfer Control) and ATGW (initials of the English words “ Access Transfer Gateway ” meaning Access Transfer gateway), which are placed on the access segment to the core network. Signaling is anchored in the ATCF, and media streaming is anchored in the ATGW. This anchor is not modified during the access transfer, so that the SCC-AS does not need to indicate to the remote terminal a modification of the media stream. This second procedure makes it possible to reduce voice communication cutoff times at the time of access transfer compared to an SRVCC type procedure, because the eSRVCC procedure intervenes on the media streams as close as possible to the user for whom it is intended. triggered, while the SRVCC procedure requires a complete renegotiation between the two users involved in the communication. The advantage of eSRVCC compared to SRVCC, in addition to reducing the number of signaling exchanges, is therefore to be able to switch media flows as close as possible to the user changing network, so that the interruption of the media is as short as possible.

The choice of the procedure to apply is based on the analysis by the SCC-AS of the characteristics of the media stream as transmitted in the signaling during the transfer: if the media stream is not modified, the eSRVCC procedure can be applied; if the media stream is modified, the SRVCC procedure must be applied.

In both architectures (ie SRVCC and eSRVCC), when transferring access to the circuit domain, the user identifier transmitted to the SCC-AS or the ATCF is the public telephone number MSISDN. However, in the case of a multi-terminal subscription, when transferring access from one of these terminals, it is not possible to determine which terminal of all the subscriber's terminals has changed mobile network, since the only identifier transmitted by the circuit domain is the MSISDN, which is, as explained above, associated with the public identity of the user. In other words, when a user has several terminals sharing the same public identity, it is impossible to know, if applicable, which of these terminals participated in an access transfer procedure.

• enregistrer, pour chacune d'une pluralité de sessions de communication en cours, un élément d'informations de session comprenant une identité d'utilisateur identifiant un terminal participant à la session et un premier identifiant du terminal dans un domaine CS du réseau de communication, ladite identité d'utilisateur étant associée à une pluralité de terminaux et ledit premier identifiant comprenant au moins un MSISDN, un IMSI ou un GRUU (Globally Routable Unique User),
• recevoir une requête de transfert de session, ladite requête de transfert de session demandant le transfert d'une session associée à un deuxième identifiant de dispositif inclus dans la requête, le deuxième identifiant de dispositif identifiant un terminal dans le domaine CS et comprenant au moins un MSISDN, un IMSI ou un GRUU,
• comparer le deuxième identifiant de dispositif reçu avec la pluralité de premiers identifiants de dispositif enregistrés, et
• identifier, sur la base de cette comparaison, une session en cours particulière à laquelle la requête de transfert de session reçue se rapporte.

In this regard, the request can be consulted US 2011238845 , which concerns session transfer techniques implemented by an SCC-AS entity in an IMS domain. Said SCC-AS entity includes means for:

• record, for each of a plurality of current communication sessions, an element of session information comprising a user identity identifying a terminal participating in the session and a first identifier of the terminal in a CS domain of the communication network, said user identity being associated with a plurality of terminals and said first identifier comprising at least one MSISDN, an IMSI or a GRUU (Globally Routable Unique User),
• receive a session transfer request, said session transfer request requesting the transfer of a session associated with a second device identifier included in the request, the second device identifier identifying a terminal in the CS domain and comprising at least one MSISDN, an IMSI or a GRUU,
• comparing the received second device identifier with the plurality of registered first device identifiers, and
• identify, based on this comparison, a particular current session to which the received session transfer request relates.

This application US 2011238845 specifies, however, that, for the SCC-AS entity to be able to identify the session to be transferred, the MSISDN of the terminal in the CS domain must not be shared by a plurality of terminals in the IMS domain. Furthermore, this application concerns the transfer of a calling terminal, and does not teach how to identify a particular terminal subject to transfer among a plurality of called terminals.

The document US 2016/0037390 describes components of a telecommunications network configured to manage a failover of a communication session of user equipment, such as for example an emergency communication session.

The document NOKIA SIEMENS NETWORKS ET AL: "Discussion about correct call leg handling alternatives", no. China; 20081007, October 7, 2008 (2008-10-07), XP050331314 describes solutions for correlating CS and SIP call legs in a domain transfer situation when a user uses more than one terminal sharing the same public identity.

In the state of the art, the switching of a communication in which a terminal taking part in a set of several mobile terminals is therefore not possible: any attempt to implement an SRVCC procedure or An e-SRVCC procedure is doomed to failure because it cannot identify the terminal involved in the switchover.

• détection qu'il devient nécessaire de basculer une communication à laquelle participe un terminal depuis un premier réseau mobile connecté à un réseau IP, vers un second réseau mobile connecté au même réseau IP,
• transmission par un premier centre de gestion appartenant audit premier réseau mobile à un second centre de gestion appartenant audit second réseau mobile de l'identifiant IMSI dudit terminal,
• envoi dudit identifiant IMSI au coeur de réseau IP par ledit second centre de gestion,
• réception par une entité de contrôle des transferts d'accès d'une requête de changement de réseau mobile contenant ledit identifiant IMSI, et
• identification de l'adresse de contact du terminal par ladite entité de contrôle des transferts d'accès au moyen de l'identifiant IMSI.

The present invention therefore relates, according to a first aspect, to a method for changing a mobile network, comprising the following steps:

• detection that it becomes necessary to switch a communication in which a terminal participates from a first mobile network connected to an IP network, to a second mobile network connected to the same IP network,
• transmission by a first management center belonging to said first mobile network to a second management center belonging to said second mobile network of the IMSI identifier of said terminal,
• sending said IMSI identifier to the IP core network by said second management center,
• receipt by an access transfer control entity of a mobile network change request containing said IMSI identifier, and
• identification of the contact address of the terminal by said access transfer control entity by means of the IMSI identifier.

Said method is remarkable in that, during the registration of said terminal with said IP network, a registration server in charge of the terminal obtained said IMSI identifier and sent it to said access transfer control entity. .

• de la procédure classique exécutée pour un terminal lors de son enregistrement sur un réseau IP, et
• des procédures d'identification classiques exécutées par les entités de contrôle des transferts d'accès.

Thus, the invention proposes the modification:

• the classic procedure executed for a terminal when registering on an IP network, and
• classic identification procedures carried out by access transfer control entities.

It will be noted that the IP network to which the invention applies can be not only an IMS network, but also any IP network compatible with access transfer procedures similar to the SRVCC and eSRVCC procedures.

It should also be noted that the modified registration procedure according to the invention is particularly applicable in the case of a multi-terminal configuration. Indeed, the identification of a terminal (calling or called) undergoing a change of mobile network among a plurality of terminals belonging to the same user can be carried out by simple consultation of the list, thus constituted, of identifiers IMSI of these terminals.

Thanks to these provisions, an access transfer control entity in charge of the user can unambiguously identify a terminal of this user involved in a change of mobile network. This ensures in particular the success of access transfers in a multi-terminal subscription situation.

According to particular characteristics, after obtaining said IMSI identifier, said registration server sends it to an SCC-AS entity.

According to even more specific characteristics, after receiving said IMSI identifier, said SCC-AS entity transmits it to an ATCF entity.

According to other particular characteristics, after obtaining said IMSI identifier, said registration server sends it to an ATCF entity.

Thanks to these provisions, at least one of the access transfer control entities (SCC-AS and/or ATCF) in charge of the user can, in the case of a multi-terminal configuration, be informed of the IMSI identifier of each of this user's terminals. This access transfer control entity can therefore easily identify the contact address of one of these terminals which would then be subject to a change of mobile network.

According to a second aspect, the invention relates to various devices.

It thus concerns, firstly, a registration server in an IP network, comprising means for, when registering with said IP network of a terminal for which said registration server is responsible, obtaining the IMSI identifier of said terminal and send it to an access transfer control entity.

The invention also relates, secondly, to an entity for controlling access transfers in an IP network constituted by an SCC-AS entity, and comprising means for receiving from a recording server, and recording, the IMSI identifier of a terminal.

According to particular characteristics, this access transfer control entity further comprises means for transmitting the IMSI identifier of a terminal to an ATCF entity.

The invention also relates, thirdly, to an entity for controlling access transfers in an IP network constituted by an ATCF entity, and comprising means for receiving from a recording server or a SCC-AS entity, and record the IMSI identifier of a terminal.

• recevoir une requête de changement de réseau mobile concernant un terminal, ladite requête contenant l'identifiant IMSI dudit terminal, et
• identifier l'adresse de contact du terminal au moyen dudit identifiant IMSI.

According to particular characteristics, any of the access transfer control entities briefly described above further comprises means for:

• receive a mobile network change request concerning a terminal, said request containing the IMSI identifier of said terminal, and
• identify the contact address of the terminal by means of said IMSI identifier.

The advantages offered by these devices are essentially the same as those offered by the processes briefly explained above.

• au moins un serveur d'enregistrement tel que décrit succinctement ci-dessus, et
• au moins une entité de contrôle des transferts d'accès telle que décrite succinctement ci-dessus.

According to a third aspect, the invention relates to a communication system in an IP network, comprising:

• at least one recording server as briefly described above, and
• at least one access transfer control entity as briefly described above.

The advantages offered by this communication system are essentially the same as those offered by the methods briefly explained above.

The invention also relates to a computer program downloadable from a communications network and/or stored on a computer-readable medium and/or executable by a microprocessor. This computer program is remarkable in that it includes instructions for managing the operation of a recording server as briefly described above, or of an access transfer control entity as briefly described. above, when run on a computer.

The advantages offered by this computer program are essentially the same as those offered by said method.

• la figure 1 illustre les étapes mises en oeuvre classiquement dans la procédure SRVCC,
• la figure 2a représente schématiquement une architecture réseau utilisée classiquement pour la procédure eSRVCC,
• la figure 2b illustre les étapes mises en oeuvre classiquement dans la procédure eSRVCC, et
• la figure 3 illustre les étapes mises en oeuvre classiquement au cours d'un enregistrement dans la procédure eSRVCC.

Other aspects and advantages of the invention will appear on reading the detailed description below of particular embodiments, given by way of non-limiting examples. The description refers to the accompanying figures, in which:

• there figure 1 illustrates the steps classically implemented in the SRVCC procedure,
• there figure 2a schematically represents a network architecture conventionally used for the eSRVCC procedure,
• there figure 2b illustrates the steps classically implemented in the eSRVCC procedure, and
• there Figure 3 illustrates the steps classically implemented during a recording in the eSRVCC procedure.

As the SRVCC and eSRVCC procedures are designed to work preferably with IMS type IP networks, we will start with a few reminders concerning this type of network.

When a user wishes to benefit from the services offered by an IMS network, he sends signaling messages to the network which may include various types of requests.

First of all, the user's client device must, barring exceptions (such as certain emergency calls), register on the network by sending it a request called "SIP REGISTER". When the network is unable to make the link between this recording and a previous recording (for example following a network failure, or following a shutdown of the client device for a duration greater than a predetermined value), the recording is considered as being an initial recording. After an initial registration, the user's client device must periodically send a request to the network to confirm that it wishes to maintain its registration.

To be able to record client devices, IMS networks include one or more recording servers, called “S-CSCF” (initials of the English words “ Serving-Call Server Control Function ” meaning “Server Call Session Control Function”). "), suitable (among others functions) to manage the registration procedure of devices connected to the network.

IMS networks also include one or more interrogation servers, called "I-CSCF" (initials of the English words " Interrogating-Call Server Control Function") - moreover often physically combined with S-CSCF registration servers to constitute call servers denoted "I/S-CSCF" - which, at the time of registration of a client device, interrogate a data server of subscriber called “HSS” (initials of the English words “ Home Subscriber Server ” meaning “Home Subscriber Server”), in order to be able to select an S-CSCF server having the characteristics which are necessarily (and, where applicable, optionally) required to achieve the level of service subscribed to by the user. The HSS servers each contain a client database, and are therefore the equivalent in IP networks of the “HLR” servers (initials of the English words “ Home Location Register ” meaning “Home Location Register”) used in networks GSM. Each HSS server contains the IMS subscriptions of the operator's subscribers as well as their service profiles. In particular, the TS 29.228 specification (Section B.1 and figure B.1.1 in particular) of the 3GPP provides for the possibility of provisioning in the subscription of the user of a mobile terminal, the IMSI of the terminal in the same way as its identity private.

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

IMS networks further include:

• one (or more) voicemail server(s): a voicemail server manages the subscription of the client device to the submission/consultation events of messages from the user of this client device, and notifies the client device when the occurrence of these events;
• one (or more) presence server(s): a presence server manages the subscription of the client device to presence events that the user of this client device wishes to monitor, and notifies the client device when the occurrence occurs of these events; And
• one (or more) telephony server(s): a telephony server manages the telephone services to which the user of the client device has subscribed to with its operator, such as number presentation or call forwarding.

Voicemail servers, presence servers, and telephony servers are examples of what are called “ application servers ,” or AS.

The S-CSCF server that has been assigned to the user authenticates that user, and then downloads the user profile from the HSS server. This profile contains information about the services to which this user is entitled. The information is stored in the form of “ initial Filter Criteria” (iFC). The S-CSCF then sends a message called “ third party registration ” to all application servers. The body of this message contains service information in XML and/or the original SIP REGISTER request and/or the 200 OK response to the original SIP REGISTER request. The purpose of third party registration is to let application servers know that this user is available on the network (for example, TAS will stop forwarding calls intended for this user to their Voicemail).

The user can then make use of said services during the current session. These may, for example, be services offered automatically to all users of the IMS network. These may also be services to which this user has subscribed with the network operator, and which are automatically made available to him. Finally, these may be services that the user can use after issuing an appropriate request (SIP SUBSCRIBE). These services include audiovisual applications as mentioned above. It may also be a subscription to the state of a resource, in which case event notifications (SIP NOTIFY) are sent to the client device as soon as the state of the resource changes.

IMS networks also include one or more servers called “P-CSCF” (initials of the English words “ Proxy-Call Server Control Function ” meaning “Proxy Call Session Control Function”). For each client device connected to an IMS network, there is a P-CSCF server serving as a connection entity between the IMS core network and the mobile network used by this client device; thus, all SIP signaling exchanged between the client device on the one hand, and the I-CSCF interrogation server or the S-CSCF recording server on the other hand, passes through the P-CSCF server.

Finally, IMS networks include media gateways, such as the IMS-AGW (IMS Access Gateway). A “media gateway” is an entity responsible, under the control of a P-CSCF server, for opening and closing the doors between the mobile network and the core network on the media level; the “media gateway” entity is also in charge of traffic policing, as well as marking media flows in terms of Quality of Service.

Concerning mobile networks that can interconnect with an IMS network, we will focus below on CS networks of GSM or UMTS type, and PS networks of LTE type.

• une ou plusieurs stations de base (appelées « Node B » en UMTS) ; et
• un ou plusieurs centres de gestion, appelés « MSC » (Mobile Switching Center) ; un centre de gestion MSC est généralement associé à une passerelle média MGW (Media Gateway) située à la frontière entre le réseau mobile CS et le réseau IMS ; le point d'accès dans le coeur de réseau IMS est un serveur I-CSCF.

It is recalled that the CS networks include in particular:

• one or more base stations (called “Node B” in UMTS); And
• one or more management centers, called “MSC” (Mobile Switching Center); an MSC management center is generally associated with a media gateway MGW (Media Gateway) located at the border between the mobile network CS and the IMS network; the access point in the IMS core network is an I-CSCF server.

• une ou plusieurs stations de base, appelées « eNode B » ;
• au moins un centre de gestion MME (Mobility Management Entity) ; un centre de gestion MME est généralement associé à une passerelle média PGW (PDN Gateway) située à la frontière entre le réseau mobile CS et le réseau IMS ; le point d'accès dans le coeur de réseau IMS est un serveur P-CSCF ;
• au moins 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 de base eNode B, ainsi que de point d'ancrage lors des transferts entre un réseau LTE et un réseau mettant en oeuvre une autre technologie 3GPP ; et
• au moins une passerelle PGW, mentionnée ci-dessus : la PGW fournit la connectivité entre l'UE et les réseaux à paquets de données (« Packet Data Networks », ou PDN, en anglais) externes, en servant de point d'entrée et de sortie du trafic pour l'UE ; un terminal mobile 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.

The PS networks include:

• one or more base stations, called “eNode B”;
• at least one MME (Mobility Management Entity) management center; an MME management center is generally associated with a PGW media gateway (PDN Gateway) located at the border between the mobile network CS and the IMS network; the access point in the IMS core network is a P-CSCF server;
• at least one SGW gateway (Serving Gateway): the SGW routes and transmits user data packets, and also acts as a mobility anchor point for user data during transfers between eNode B base stations, as well as an anchor point during transfers between an LTE network and a network implementing another 3GPP technology; And
• at least one PGW gateway, mentioned above: the PGW provides connectivity between the UE and external Packet Data Networks (PDNs), serving as an entry point and exit traffic for the EU; a mobile terminal can be connected simultaneously to several PGWs to have access to several PDNs; the PGW ensures the execution of the network policy, filtering of packets for each user, assistance with imputation, legal interception and monitoring of packets.

The mobile network changes considered below include in particular the switching of a communication from an MME management center of the LTE network to an MSC management center of the GSM or UMTS network.

We will now describe the SRVCC procedure, drawing on the articles from Frédéric Launay titled “SRVCC-Single Radio Voice Call Continuity” (available at http://blogs.univ-poitiers.fr/f-launay/2015/06/24/srvcc-single-radio-voice-call-continuity / ) And “SRVCC-Single Radio Voice Call Continuity-Suite” (available at http://blogs.univ-poitiers.fr/f-launay/tag/esrvcc/ ).

There figure 1 (adapted from 3GPP specification TS 24.237, section A.6.2) summarizes the classic protocol exchanges of the SRVCC procedure between, on the one hand, the CS domain (equipment designated “ Interworking entities ” in the figure), and on the other share the IMS network elements.

In IMS networks, when a client device UE A sends a call to a client device UE B, or receives a call from a client device UE B, a SIP INVITE call request is transmitted to a server S -CSCF; the execution of the associated task (returning the request to an Application Server) depends on the subscriber's subscription rules, and this task is carried out by applying to the call the list of rules defined on the basis of the parameters of the iFC filter mentioned above.

Prior to the SRVCC procedure, the call was anchored by the SCC-AS server mentioned above, as illustrated in step 1 of the figure 1 (when a call passes through an SCC-AS, it is said to be “anchored” by the SCC-AS). More precisely, if we place ourselves on the side of the client device UE A at the origin of the call, the call will be transmitted first to the SCC-AS before being processed by the Application Server of Telephony (“ Telephony Application Server ”, or TAS, in English); if we place ourselves on the side of the client device UE B receiving the call, the call is first transmitted to the TAS, which then transfers it to the SCC-AS.

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

When the eNode B base station to which the client device UE A is connected detects that the signal received by this client device UE A is weak (step 2), the MME responsible for this client device UE A sends a request switching to the CS network (step 3). To do this, the MME must be able to:

• separate the Data flow (PS) from the Voice flow (managed by CS mode after switching),
• manage the switchover of non-Voice PS virtual channels (“ bearers ”) to the target network, and
• initiate the SRVCC switchover procedure using the Voice bearer .

• demander au MSC de réserver des ressources radio au niveau de l'interface d'accès radio CS ; 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 émettre vers le SCC-AS une requête INVITE de demande de basculement pour le compte du dispositif-client UE A.

An interface, named “Sv”, between the MSC and the MME allows the MME to:

• request the MSC to reserve radio resources at the CS radio access interface; the MSC is therefore responsible for reserving resources for call continuity; And
• give the MSC an identifier of the SCC-AS so that the MSC can send an INVITE request to the SCC-AS for a switchover request on behalf of the client device UE A.

When registering the client device to the IMS network, the MME retrieved an identifier called “STN-SR” (initials of the English words “ Session Transfer Number for SRVCC ” meaning “Session Transfer Number for SRVCC”) from the from the HSS server (which itself received it from the SCC-AS). This is a number in E.164 telephone format. It is this SCC-AS identifier which is transmitted by the MME to the MSC so that the latter can issue said switchover request to the SCC-AS.

The MSC then sends to the IMS network a SIP INVITE request requesting transfer of an active session, including said STN-SR number as well as the public telephone number MSISDN of the user of the client device UE A (step 4) .

The SCC-AS then receives said INVITE request (step 6), and takes care of the session transfer. From this moment, the MME can ask the UE A client device to switch to the GSM or UMTS network. The SCC-AS informs the UE B client of the transfer of access to take into account the new media streams towards the MSC (steps 7 to 13). After the switchover, the SCC-AS sends confirmation of the success of the procedure to the MSC (steps 14 and 15).

We will now describe the classic eSRVCC procedure, drawing on the article “Mind the coverage hole!” (available at https://realtimecommunication.wordpress.com/2015/03/24/mind-the-coverage-hole/#more-380 ).

The classic eSRVCC procedure is described in the GSMA IR.64 specifications, as well as TS 23.237 and TS 24.237 of the 3GPP. The architecture used in this procedure is illustrated schematically on the figure 2a .

• l'ATCF agit comme point d'ancrage pour la signalisation SIP, et est placé dans le chemin de signalisation SIP entre un P-SCSF et un S-CSCF ; chaque ATCF est identifié par un numéro STN-SR ; le SCC-AS reçoit le STN-SR de l'ATCF en charge d'un abonné 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.

As mentioned above, the eSRVCC architecture includes two entities intended to serve as anchor points on the access segment to the core network. These entities are:

• the ATCF acts as an anchor for SIP signaling, and is placed in the SIP signaling path between a P-SCSF and an S-CSCF; each ATCF is identified by an STN-SR number; the SCC-AS receives the STN-SR from the ATCF in charge of a subscriber at the time of subscriber registration, and then transmits it to the HSS; the HSS in turn transmits it to the MME (as in the SRVCC procedure described briefly above); And
• the ATGW acts as an anchor for the media flow; the ATGW is controlled by the ATCF; The ATGW is often co-located with an IMS-AGW media gateway.

There figure 2b (adapted from 3GPP specification TS 24.237, Section A.18.3) summarizes the classic protocol exchanges of the eSRVCC procedure between the CS domain and the IMS network elements.

As explained above, when a mobile terminal registers on an IMS network, it issues a SIP REGISTER request, which is received by a P-CSCF server. According to the eSRVCC procedure, this P-CSCF server transmits the SIP REGISTER request to the ATCF. If the mobile terminal's original network is compatible with the eSRVCC procedure, the ATCF decides, based on the operator's policy, whether or not to anchor SIP signaling.

If it decides to anchor the signaling, the ATCF enriches the initial SIP REGISTER request, in particular by including itself for sessions created based on this registration, and by adding its URI (called ATCF-URI) in the signaling path.

• le numéro de téléphone public MSISDN de l'utilisateur du dispositif-client UE A, et
• l'URI 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 »).

The SIP REGISTER request thus enriched is then transmitted by the ATCF to the I-CSCF server, which transmits it to the S-CSCF, then the S-CSCF sends to the SCC-AS a message containing the initial SIP REGISTER request in the message body . The SCC-AS takes into account the STN-SR number from the ATCF, and updates the HSS server. The SCC-AS then sends to the ATCF, in the message body of a request using the SIP MESSAGE method (described in IETF document RFC 3428):

• the MSISDN public telephone number of the user of the UE client device A, and
• the URI of the SCC-AS, called ATU-STI (initials of the English words “Access Transfer Update – Session Transfer Identifier ” meaning “Update of Access Transfer – Session Transfer Identifier”).

Once registered, the UE A client device can establish a PS communication with a UE B client device (step 1 of the figure 2b ).

When the eNode B base station to which the client device UE A is connected detects that the signal received by this client device UE A is weak, the MME responsible for this client device UE A sends a switchover request to the CS network (2nd step). The request contains in particular the STN-SR number of the ATCF, as well as the user's MSISDN telephone number. The MSC/MGCF produces a SIP INVITE request including this STN-SR number as well as this MSISDN number, and sends it to the ATCF (step 3).

The ATCF finds the user's MSISDN number in the "P-Asserted-Identity" field of the received INVITE request, and requests the required media stream modifications from the ATGW (steps 4 and 5). Then the ATCF sends to the SCC-AS, by means of the ATU-STI (mentioned above), a new SIP INVITE request reproducing the “Target-Dialog” header identifying the dialogue established by the INVITE request before the switchover (steps 8 and 9).

Note that, in the SRVCC and eSRVCC procedures briefly described above, the only identifier transmitted by the CS domain to the IMS core network (see step 4 of the figure 1 , or step 3 of the figure 2b ) is the user's MSISDN public telephone number. As explained above, it follows that, in the state of the art, when the user has several terminals sharing the same public identity, it is not possible from this public identity to determine the private identity of the terminal having participated in an access transfer procedure.

We will now describe embodiments of the invention, in which the network considered will be of the IMS type, as briefly described above.

In these embodiments, the IMSI identifier will preferably be delivered to the relevant elements of the network by means of a dedicated SIP header, which will be called “P-Associated-IMSI”. We could have for example:
P-Associated-IMSI: 208010123456789.

We already know, in fact, a header making it possible to provide the IMSI identifier, but this header is used within the framework of a very specific restoration function in the event of an error: it is the “Restoration-Info” header defined in 3GPP TS 24.229, Section 7.2.11. Also, the definition of a new header is preferred so as not to confuse the different uses; however, novel use of the Restoration-Info header for the purposes of the present invention is also possible.

Furthermore, these embodiments introduce modifications compared to the classic registration procedure of a terminal on an IMS network, as will now be explained.

A first embodiment concerns a modified eSRVCC procedure.

The classic registration procedure for a terminal near an IMS core network is illustrated on the Figure 3 (adapted from 3GPP specification TS 24.237, Section A.3.3). In this case, the terminal is in a roaming situation; it therefore registers from a visited network (V-PLMN, for Visited-Public Land Mobile Network) in the original network (H-PLMN, for Home-Public Land Mobile Network) of the user; the entities (P-CSCF, ATCF) of the visited network transmit the registration requests to the entities (I-CSCF, S-CSCF, SCC-AS, HSS) of the user's original network.

First, the S-CSCF server in charge of the user obtains the IMSI identifier of the terminal which is registering.

According to a first variant, the S-CSCF server deduces the IMSI identifier from the IMPI private identity.

• le serveur S-CSCF envoie au serveur HSS un message DIAMETER SAR (Server-Assignment-Request) dans lequel il indique, notamment, son nom en relation avec l'identité privée IMPI de l'utilisateur qu'il a pris en charge ; et
• le serveur S-CSCF reçoit de la part du serveur HSS, dans une réponse DIAMETER SAA (Server-Assignment-Answer), un complément de données concernant l'utilisateur en cours d'enregistrement (telles que des identités complémentaires, ou le profil de l'utilisateur) ; le serveur HSS fournit également dans cette réponse SAA (et plus précisément dans l'objet « User-Profile » de cette réponse SAA, comme spécifié dans la Section B1, mentionnée ci-dessus, de la norme TS 29.228) l'identifiant IMSI si ce dernier est disponible.

According to a second variant, in accordance with document RFC 4740 of the IETF, following step 12 of the Figure 3 (reception of a “SIP REGISTER” request by the S-CSCF server), the following sub-steps take place (not shown on the Figure 3 ):

• the S-CSCF server sends to the HSS server a DIAMETER SAR (Server-Assignment-Request) message in which it indicates, in particular, its name in relation to the IMPI private identity of the user it has supported; And
• the S-CSCF server receives from the HSS server, in a DIAMETER SAA (Server-Assignment-Answer) response, additional data concerning the user being registered (such as additional identities, or the profile of the user) ; the HSS server also provides in this SAA response (and more precisely in the “User-Profile” object of this SAA response, as specified in Section B1, mentioned above, of the TS 29.228 standard) the IMSI identifier if the latter is available.

The S-CSCF server will then be able to provide the IMSI identifier to network elements that need it.

For example, according to step 13 of the Figure 3 , it is conventionally expected that the S-CSCF server sends a SIP 200 OK response to the I-CSCF server of the original network. In the present embodiment, the S-CSCF may insert a P-Associated-IMSI (or Restoration-Info) header containing the IMSI identifier. So, at step 14 of the Figure 3 (transmission of the SIP 200 OK to the ATCF), the ATCF will have the IMSI identifier; the ATCF can then broadcast this information in the registration context associated with the user.

As another example, in step 17 of the Figure 3 , it is conventionally expected that the S-CSCF server transmits the SIP REGISTER request to the SCC-AS. In the present embodiment, the S-CSCF server can insert a P-Associated-IMSI (or Restoration-Info) header containing the IMSI identifier. The SCC-AS is thus informed of the IMSI identifier of the terminal which is registering, and can then broadcast this information in the user registration context. For example, when sending the SIP MESSAGE request (steps 19 and 20 of the Figure 3 ) to the ATCF, the SCC-AS server may insert the IMSI identifier in the body of this request or in a P-Associated-IMSI (or Restoration-Info) header of this request.

The SCC-AS and the ATCF then have, in the registration context of the terminal which has just registered, all the “uncrossed out” public identities (that is to say, usable by the terminal to make calls) of the terminal, the contact address of the terminal, and its IMSI identifier.

A second embodiment concerns a modified SRVCC procedure.

The modifications compared to the classic recording are similar to those described above with reference to the first embodiment. Remember that the SRVCC architecture does not include an ATCF entity; therefore, steps 19 to 24 of the Figure 3 do not exist.

First of all, the S-CSCF server in charge of the user obtains the IMSI identifier of the terminal which registers as described above in the context of the first embodiment.

The S-CSCF server can then provide the IMSI identifier to network elements that need it.

For example, the S-CSCF server issues a SIP 200 OK response to the I-CSCF server on the originating network, into which the S-CSCF server inserts a P-Associated-IMSI (or Restoration-Info) header containing the IMSI identifier. The I-CSCF server can then transmit this SIP 200 OK response to the P-CSCF server in charge of the terminal which is registering. Knowledge by the P-CSCF server of the IMSI identifier of a terminal can be particularly useful when this terminal is roaming, as illustrated in the Figure 3 . In addition, the P-CSCF server can, in the case of a multi-terminal configuration, generate a call report (“ Call Detail Record ” , or CDR, in English) and/or statistics relating to a particular terminal (identified by its IMSI identifier) of the set of terminals; it is then possible to distinguish each of the user's terminals at the level of the network operator's information and billing systems.

As another example, when the S-CSCF server transmits the SIP REGISTER request to the SCC-AS, the S-CSCF server may insert a P-Associated-IMSI (or Restoration-Info) header containing the IMSI identifier. The SCC-AS is thus informed of the IMSI identifier of the terminal which is registering.

The SCC-AS then has, in the context of registration of the terminal which has just registered, all of the uncrossed public identities of the terminal, the contact address of the terminal, and its IMSI identifier.

Note that the registration procedures that have just been described for the eSRVCC and SRVCC procedures are particularly applicable in the case of a multi-terminal configuration.

When establishing a session between two users as described in step 1 of figures 1 And 2b , and prior to receiving an access transfer request, the SCC-AS and the ATCF will therefore be able to determine, among the plurality of terminals of each of the calling and called users, which one is used to establish this session. Indeed, the information stored in the registration contexts of the ATCF and the SCC-AS makes it possible to make the association between the contact addresses of each of the terminals, their respective IMSI identifiers and the public identities used for the establishment of this session.

We will now explain, in the context of the application of the invention to the switching of a communication from an LTE network connected to an IMS network to a GSM or UMTS network connected to the same IMS network, how a change takes place. mobile network for one of these terminals.

The procedure that takes place in the mobile core network (“Evolved Packet Core”, or EPC, in English) during an access transfer is described in 3GPP specifications TS 23.401 and TS 29.280. As mentioned above, this procedure notably includes switching the communication from an MME management center of the LTE network to an MSC management center of the GSM or UMTS network. According to Table 5.2.2 of said TS 29.280 specification, the information which is transmitted to the MSC management center during the switchover includes in particular the IMSI identifier of the terminal concerned.

However, in the state of the art, this IMSI identifier is not transmitted by the MSC management center to the IMS core network (ATCF or SCC-AS) (see SIP INVITE request in step 4 of the figure 1 , or in step 3 of the figure 2b ).

According to the present application of the invention, the MSC management center uses the “P-Associated-IMSI” SIP header (or the “Restoration-Info” SIP header). in order to transmit to the IMS core network the IMSI identifier (obtained in accordance with the TS 29.280 specification) relating to the terminal being the subject of an access transfer. This information is then used in conjunction with the MSISDN telephone number, either by the SCC-AS following receipt of the INVITE request in step 6 of the figure 1 in the case of an SRVCC procedure, either by the ATCF following receipt of the SIP INVITE request in step 3 of the figure 2b in the case of an eSRVCC procedure.

In the case of the first embodiment of the invention (modified eSRVCC procedure), the ATCF then completes the user context initialized following receipt of the SIP 200 OK response during step 14 of the Figure 3 . As the ATCF has previously stored the correspondence between the IMSI identifier and the contact address of each user's terminal, the ATCF is able to determine without ambiguity the terminal concerned by the access transfer procedure.

In the case of the second embodiment of the invention (modified SRVCC procedure), the IMSI identifier is used by the SCC-AS to complete the user context initialized following receipt of the SIP REGISTER registration request ( step equivalent to step 17 of the Figure 3 ). As the SCC-AS has previously stored the correspondence between the IMSI identifier and the contact address of each user's terminal, the SCC-AS is able to determine without ambiguity the terminal concerned by the transfer procedure. access.

It will be noted that the present invention can be implemented within the nodes of an IP network, for example recording servers or access transfer control entities, by means of software and/or hardware components, such as than electronic circuits.

The software components can be integrated into a conventional network node management computer program. Therefore, as indicated above, the present invention also relates to a computer system. This computer system conventionally comprises a central processing unit controlling a memory by signals, as well as an input unit and an output unit. Additionally, this computer system can be used to execute a computer program including instructions for the implementation of any of the mobile network change methods according to the invention.

Indeed, the invention also relates to a computer program downloadable from a communications network comprising instructions for executing the steps of a mobile network change method according to the invention, when it is executed on a computer . This computer program may be stored on a computer-readable medium and may be executable by a microprocessor.

This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.

The invention also relates to an information medium, irremovable, or partially or totally removable, readable by a computer, and comprising instructions for a computer program as mentioned above.

The information carrier can be any entity or device capable of storing the program. For example, the support may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, such as a hard disk, or even a USB key (“ USB flash drive ” in English).

On the other hand, the information carrier may be a transmissible medium such as an electrical or optical signal, which may be carried via an electrical or optical cable, by radio or by other means. The computer program according to the invention can in particular be downloaded onto an Internet type network.

Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of any of the mobile network switching methods according to the invention .

Claims (9)

1. Method for changing mobile network, comprising the following steps:

   - detecting that it becomes necessary to hand over a communication in which a terminal participates from a first mobile network connected to an IP, Internet Protocol, network, to a second mobile network connected to the same IP network,

   - a first management centre belonging to said first mobile network transmitting, to a second management centre belonging to said second mobile network, the IMSI, International Mobile Subscriber Identity, identifier of said terminal,

   - said second management centre sending said IMSI identifier to the IP network, and

   - an access transfer control entity of the IP network receiving a request to change mobile network relating to said terminal and containing said IMSI identifier, the method further comprising a step of said access transfer control entity identifying the contact address of the terminal by means of the IMSI identifier, the method being characterized in that, during the registration of said terminal with said IP network, a registration server in charge of executing the session control services for the terminal obtained said IMSI identifier and forwarded it to said access transfer control entity.
2. Method for changing mobile network according to Claim 1, characterized in that, after having obtained said IMSI identifier, said registration server forwards it to an SCC-AS, Service Centralization and Continuity, entity.
3. Method for changing mobile network according to Claim 2, characterized in that, after having received said IMSI identifier, said SCC-AS entity transmits it to an ATCF, Access Transfer Control Function, entity.
4. Method for changing mobile network according to Claim 1, characterized in that, after having obtained said IMSI identifier, said registration server forwards it to an ATCF entity.
5. Access transfer control entity in an IP, Internet Protocol, network, consisting of an SCC-AS, Service Centralization and Continuity, entity and comprising means for:

   receiving and registering the IMSI, International Mobile Subscriber Identity, identifier of a terminal sent by a registration server in charge of executing the session control services for said terminal during the registration of said terminal with said IP network;

   receiving a request to change mobile network relating to said terminal, said request containing said IMSI identifier of said terminal, and

   identifying the contact address of the terminal by means of said IMSI identifier.
6. Access transfer control entity in an IP, Internet Protocol, network, consisting of an ATCF, Access Transfer Control Function, entity and comprising means for receiving and registering the IMSI, International Mobile Subscriber Identity, identifier of a terminal sent by a registration server in charge of executing the session control services for said terminal, during the registration of said terminal with said IP network, or by an SCC-AS, Service Centralization and Continuity, entity, to which said registration server in charge of the terminal sent said IMSI identifier during the registration of said terminal with said IP network, said ATCF entity further comprising means for:

   - receiving a request to change mobile network relating to said terminal, said request containing said IMSI identifier of said terminal, and

   - identifying the contact address of the terminal by means of said IMSI identifier.
7. Communication system in an IP, Internet Protocol) network, comprising:

   - at least one access transfer control entity according to Claim 5 or 6; and

   - at least one registration server in charge of executing the session control services for said terminal and comprising means for, during the registration of a terminal which said registration server is in charge of with said IP network, obtaining the IMSI, International Mobile Subscriber Identity, identifier of said terminal and forwarding it to said access transfer control entity or, when said access transfer control entity consists of an ATCF entity, to an SCC-AS, Service Centralization and Continuity, entity able to transmit said IMSI identifier to said ATCF entity.
8. Irremovable, or partially or totally removable, data storage means, comprising computer program code instructions for managing the operation of an access transfer control entity according to Claim 5 or 6.
9. Computer program which can be downloaded from a communications network and/or stored on a computer-readable medium and/or can be executed by a microprocessor, characterized in that it comprises instructions for managing the operation of an access transfer control entity according to Claim 5 or 6, when it is executed on a computer.

Images