WO2017168084A1 - Procédé de transfert de réseau d'accès pour un terminal mobile en itinérance - Google Patents

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

Info

Publication number
WO2017168084A1
WO2017168084A1 PCT/FR2017/050703 FR2017050703W WO2017168084A1 WO 2017168084 A1 WO2017168084 A1 WO 2017168084A1 FR 2017050703 W FR2017050703 W FR 2017050703W WO 2017168084 A1 WO2017168084 A1 WO 2017168084A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
scc
server
terminal
network
Prior art date
Application number
PCT/FR2017/050703
Other languages
English (en)
Inventor
José DOREE
Jean-Claude Le Rouzic
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2017168084A1 publication Critical patent/WO2017168084A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019—Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H04W36/144—Reselecting a network or an air interface over a different radio air interface technology
    • H04W36/1443—Reselecting a network or an air interface over a different radio air interface technology between licensed networks

Definitions

  • the present invention relates to communication networks of IP ("Internet Protocol") type, and in particular those of IP networks that are able to implement advanced session control protocols.
  • IP networks allow the transmission of conversational data, in the context of services such as "Voice over IP” (VoIP), "Content Sharing", or "Instant Messaging”.
  • the present invention relates to the switchover of a communication in which a mobile terminal belonging to an IP network participates, from a first access network to this IP network to a second access network to the same IP network.
  • any resource of this type will, for the sake of brevity, be referred to as the "User Equipment”.
  • These client devices may for example be a fixed or mobile terminal, or a residential gateway (English) or located in a company, or a network operator gateway ("Voice Gateway” in English) such as a DSLAM (initials of the words “Digital Subscriber Line Access Multiplexer” meaning “Digital Subscriber Line Access Multiplexer”).
  • SIP protocol initials of the words “Session Initiation Protocol” meaning “Session Initiation Protocol”
  • signaling messages
  • the SIP protocol has been defined by the Internet Engineering Task Force (IETF) in RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol.
  • the SIP protocol has been extended in particular in RFC 3265. This extension defines event notification procedures.
  • the IP network communication services can identify physical or virtual resources by means of character strings, for example "URI” (initials of the English words “Uniform Resource Identifier” meaning “Uniform Resource Identifier”).
  • URI initials of the English words "Uniform Resource Identifier” meaning "Uniform Resource Identifier”
  • the URI syntax is defined in the IETF RFC 3986; the knowledge of the URI of a resource allows (for example, by means of a DNS query) to obtain the IP address of a device of the network of the operator managing this resource.
  • SIP-URI resource identifiers
  • Tel-URI resource identifiers
  • 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 single terminal when it is "multimode", can be connected and registered to an IP core network through multiple access networks, such as a GSM (Global System for Mobile Communications) network, a Universal Mobile Telecommunications System (UMTS) network, a set of DSL lines (Digital Subscriber Line), an Ethernet network (ISO / IEC 8802-3 standard), a WiFi network (IEEE 802.1 1 standard), or an LTE network (Long Term Evolution).
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • a set of DSL lines Digital Subscriber Line
  • Ethernet network ISO / IEC 8802-3 standard
  • WiFi network IEEE 802.1 1 standard
  • LTE network Long Term Evolution
  • a multimode terminal also allows its user to switch during communication from an access network (said initial) to another access network (called target), if for example the quality of transmission on the access network. initial becomes mediocre. This is called “handover” (“handover”), or "access transfer” between the initial access network and the target access network.
  • This switchover may concern all or part of the media streams associated with the communication and / or signaling: this is called total or partial transfer of the communication.
  • LTE Voice over LTE
  • LTE video-to-video
  • 3GPP Transmission Generation Partnership Project
  • TS 23.237 stage 2
  • TS 24.237 stage 3
  • the first type is called “SRVCC” (initials of the words “Single Radio Voice Call Continuity” meaning “Single Voice Call Continuity”).
  • the second type is called “eSRVCC” (English initials "Enhanced Single Voice Voice Call Continuity” meaning “Unique Vocal Radio Call Continuity Optimized”).
  • AS Application Server
  • the procedure eSRVCC uses, in addition to the SCC-AS, entities called ATCF (initials of the words "Access Transfer Control Function” meaning Access Transfer Control Function) and ATGW (initials of the words “Access Transfer Gateway” Signifying Access Transfer Gateway), which are placed on the access segment at the heart of the network.
  • ATCF initials of the words "Access Transfer Control Function” meaning Access Transfer Control Function
  • ATGW initials of the words "Access Transfer Gateway” Signifying Access Transfer Gateway
  • the signaling is anchored in the ATCF, and the media stream is anchored in the ATGW. This anchoring is not modified during the access network transfer, so that the SCC-AS does not need to indicate to the remote terminal a change in the media stream.
  • This second procedure makes it possible to reduce the cutoff times of the voice communication at the time of the access transfer with respect to a procedure of the SRVCC type, because the eSRVCC procedure intervenes on the media flows as close as possible to the user for whom it is triggered, while the SRVCC procedure requires a complete renegotiation between the two users involved in the communication.
  • the advantage of eSRVCC over SRVCC, in addition to reducing the number of signaling exchanges, is to be able to switch the media flows closer to the user changing network, so that the interruption of the media is as short as possible.
  • the choice of the procedure to be applied 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 changed, the SRVCC procedure must be applied.
  • IBCF Interconnection Border Control Function
  • SIP signaling SIP signaling
  • IBCFs may be the property of third party operators, for example long distance operators.
  • the interest of the eSRVCC procedure is then lost, since the ATCF interpretation requested by the ATCF in the user's visited access network will have to cross these IBCFs until it reaches the SCC-AS of the network. origin (“home network” in English) of the user. In doing so, traversing IBCFs through this switch request will cause new media resources to be taken between visited and originating operator networks.
  • the eSRVCC procedure is no longer limited to switching access network flows, but also to having to create new media paths much higher in the network between the two operators, to finish as in the SRVCC procedure up to other user.
  • the creation of these new media paths requires more time than simply switching existing resources, and thus the user perceived cutoff will be noticeably more audible.
  • new resources must be committed to the core of the network, whereas eSRVCC is trying to avoid this. .
  • the present invention thus relates, according to a first aspect, to an access network transfer method for a mobile terminal, said first terminal, belonging to an IP network, comprising the following steps:
  • an ATCF server in charge of said first terminal sends to an SCC-AS application server, via an IBCF server, a request able to inform said SCC-AS application server that an access network transfer procedure was initiated for the first terminal.
  • Said method is remarkable in that said request is arranged to indicate to said SCC-AS application server that it must not propagate this request to a client device, said second terminal, also belonging to the IP network, with which the first terminal is in communication.
  • the invention proposes a new implementation for the eSRVCC procedure when IBCF servers are present between the ATCF and the SCC-AS of a mobile terminal, in order to avoid having to renegotiate the media completely. to the correspondent of this mobile terminal, as is the case in the SRVCC procedure.
  • the access network transfer of a roaming mobile terminal during a communication with a correspondent is completely transparent for this correspondent.
  • the invention proposes, by way of examples, various embodiments.
  • said request is of a type other than a call request
  • said SCC-AS application server responds to said request by sending an acknowledgment to said ATCF server.
  • said request contains an indication that said SCC-AS application server does not have to take into account a description of the media stream contained in this request.
  • said indication of the request indicates to the IBCF server also that it does not have to take into account said description of media flow contained in this request.
  • said request does not contain a description of media flow, and said SCC-AS application server responds to this request with a dedicated error code.
  • the media resources initially committed are preserved at the IBCF level, and the taking of new media resources during the switchover of the IBCF is avoided. communication, so that only the linkage of resources to access must be realized. This optimizes the media resources taken by the IBCFs, and avoids the additional time that would be required to take new media resources, delay that the roaming user could perceive when changing network access.
  • the invention relates to various devices. It thus concerns, firstly, an ATCF server in charge of a mobile terminal, said first terminal, belonging to an IP network, and comprising means for sending to an SCC-AS application server, via an IBCF server, a a request signaling to said SCC-AS application server that a procedure for transferring a first to a second access network to said IP network has been initiated for said first terminal.
  • Said ATCF server is remarkable in that it further comprises means for arranging said request so that it indicates to said SCC-AS application server that it must not propagate this request to a client device, said second terminal, also belonging to the IP network, with which the first terminal is in communication.
  • said ATCF server furthermore comprises means for sending to said first terminal an end-of-call request triggering the release of their relative media link from the first access network, in response to the reception by the ATCF server of an acknowledgment, or an end-of-call request, or a message containing a dedicated error code, issued by said SCC-AS application server.
  • the invention also relates, secondly, to an SCC-AS application server comprising means for receiving, via an IBCF server, from an ATCF server in charge of a mobile terminal, said first terminal, belonging to a IP network, a request indicating that an access network change procedure for said IP network has been initiated for said first terminal.
  • Said SCC-AS application server is remarkable in that it further comprises means for taking into account an indication of said request according to which said SCC-AS application server must not propagate this request to a client device said second terminal, also belonging to the IP network, with which the first terminal is in communication.
  • said SCC-AS application server further comprises means for finding that said request is of a type other than a call request, and responding to said request by sending an acknowledgment to said ATCF server .
  • said SCC-AS application server further comprises means for taking an indication into account, contained in said request, according to which the SCC-AS application server does not have to take into account a description of the media stream contained in this request.
  • said SCC-AS application server further comprises means for observing that said request does not contain a description of media flow, and responding to this request with a dedicated error code.
  • the invention relates to a communication system in an Internet Protocol (IP) network, comprising at least one ATCF server as briefly described above, and at least one SCC-AS server as briefly described below. above.
  • IP Internet Protocol
  • said communication system further comprises an IBCF server comprising means for intercepting a request sent by said ATCF server for said SCC-AS application server as well as means for taking an indication into account, contained in said request, according to which it must not take into account a description of media flow contained in this request.
  • IBCF server comprising means for intercepting a request sent by said ATCF server for said SCC-AS application server as well as means for taking an indication into account, contained in said request, according to which it must not take into account a description of media flow contained in this request.
  • the invention also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • This computer program is notable in that it includes instructions for executing the steps of the access network transfer method succinctly set forth above, when executed on a computer.
  • FIG. 1 schematically represents a network architecture conventionally used for the eSRVCC procedure
  • FIG. 2 schematically represents a network architecture conventionally used for the roaming procedure eSRVCC
  • FIG. 3 illustrates the steps conventionally implemented in the eSRVCC procedure when roaming
  • FIG. 4 illustrates the steps implemented in the roaming procedure eSRVCC, according to a first embodiment of the invention
  • FIG. 5 illustrates the steps implemented in the roaming procedure eSRVCC, according to a second embodiment of the invention.
  • FIG. 6 illustrates the steps implemented in the eSRVCC procedure in roaming situation, according to a third embodiment of the invention.
  • IMS networks use the SIP session control protocol (described briefly above).
  • the IMS architecture was introduced by 3GPP for mobile networks and then taken over by TISPAN ("Telecommunications and Internet Converged Services and Protocols for Advanced Networking") for fixed networks.
  • TISPAN Telecommunications and Internet Converged Services and Protocols for Advanced Networking
  • This architecture enables the dynamic establishment and control of multimedia sessions between two clients as well as the reservation of resources at the level of the network for transporting multimedia streams.
  • network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate the amounts to be billed to customers.
  • the IMS currently provides access to telephony, videophone, Presence and Instant Messaging services, which it also manages.
  • the user-device of the user must, with some exceptions (such as certain emergency calls), register on the network by sending him a request called "SIP REGISTER".
  • SIP REGISTER When the network is unable to link this record to a previous record (for example due to a network failure, or following a client-device shutdown for a duration longer than a predetermined value), the record is considered being an initial recording.
  • the user's client device After an initial registration, the user's client device must periodically send the network a request to confirm that it wishes to maintain its registration.
  • the IMS networks include one or more registration servers, called “S-CSCFs” (Initials of the English words “Serving-Call Server Control Function” meaning “Server Call Session Control Function”). "), Able (among other functions) to manage the registration procedure of devices connected to the network.
  • S-CSCFs Initials of the English words “Serving-Call Server Control Function” meaning “Server Call Session Control Function”).
  • Able able (among other functions) to manage the registration procedure of devices connected to the network.
  • the IMS networks furthermore comprise one or more interrogation servers, called "l-CSCF” (initials of the words “Interrogating- Call Server Control Function” meaning “Interrogating Call Session Control Function”) - moreover often physically combined with the S-CSCF recording servers to form call servers denoted "l / S-CSCF” - which, at the time of registration of a client device, query a data server of subscriber called “HSS” (initials of the words “Home Subscriber Server” meaning “Subscriber Subscriber Server”), in order to select an S-CSCF server with the characteristics that are obligatorily (and, if necessary, optionally) required to reach the level of service subscribed by the user.
  • HSS data server of subscriber
  • HSS Home Subscriber Server
  • Subscriber Subscriber Server Subscriber Subscriber Server
  • the HSS servers each contain a client database, and so are the equivalent in IP networks of "HLR” servers (initials of the words “Home Location Register” meaning “Link Location Registry”) used in the networks. GSM.
  • HLR Home Location Register
  • Each HSS server contains the "profile” of a number of client devices on the network, this profile including their registration status, authentication and location data, and the services to which they are entitled.
  • IMS networks further include: • one or more voicemail server (s): a voicemail server manages the subscription of the client device to the events of posting / consultation of the messages of the user of this client device, and notifies the client device at the occurrence of these events;
  • voicemail server a voicemail server manages the subscription of the client device to the events of posting / consultation of the messages of the user of this client device, and notifies the client device at the occurrence of these events
  • One (or more) presence server a presence server manages the subscription of the client device to the presence events that the user of this client device wishes to monitor, and notifies the client device when the client device occurrence of these events;
  • a telephony server manages the telephone services to which the user of the client device has subscribed with his operator, such as the presentation of the number or the call forwarding.
  • Voice mail servers, presence servers and telephony servers are examples of so-called “application servers” (or AS).
  • the S-CSCF server that has been assigned to the user authenticates this 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" (or "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 language and / or the original SIP REGISTER request and / or 200 OK response to the original SIP REGISTER request.
  • the purpose of the third-party registration is to let the application servers know that this user is available on the network (for example, the TAS will stop transferring calls intended for this user to his Voice Mailbox).
  • these services may be offered automatically to all users of the IMS network. It can also be services to which this user has subscribed to the network operator, and which are automatically made available. Finally, they may be services that the user can use after issuing an appropriate request (SIP SUBSCRIBE). These services include audiovisual applications as mentioned above. It can 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.
  • SIP NOTIFY event notifications
  • IMS networks also include one or more servers called
  • P-CSCF Proxy-Call Server Control Function
  • P-CSCF server serving as a connection entity between the IMS core network and the access network used by this client device; thus, all the SIP signaling exchanged between the client device on the one hand, and the l-CSCF interrogation server or the S-CSCF registration server on the other hand, passes through the P-CSCF server.
  • IMS networks include media gateways, such as the IMS-AGW (IMS Access Gateway).
  • a “media gateway” is a responsible entity, under the control of a P-CSCF server, for the opening and closing of the gates between the access network and the core network on the media plane; the “media gateway” entity is also in charge of traffic policing, as well as the marking of media flows in terms of Quality of Service.
  • a SIP INVITE call request is transmitted to a server S -CSCF; the execution of the associated task (return of the request to an application server) depends on the subscription rules of the subscriber, and the task that is performed is obtained by applying the event (for example a call) to the list of rules defined through the parameters of the iFC filter mentioned above.
  • the event for example a call
  • the call is routed to the SCC-AS server mentioned above.
  • the call will be sent first to the SCC-AS before being processed by the Telephony Application Server (or TAS); if we consider the client-device receiving the call, the call is first transmitted to the TAS, which then transfers it to the SCC-AS.
  • TAS Telephony Application Server
  • the access network transfer notably comprises the transfer of the communication from the entity called MME (Mobility Management Entity) of the LTE network to the entity called MSC (Mobile Switching Center) of the GSM or UMTS network.
  • MME Mobility Management Entity
  • MSC Mobile Switching Center
  • the MME and the MSC are controllers connected to a P-CSCF server of the IMS core network; the access network transfer is thus accompanied by a session transfer at the core of the network.
  • the MME responsible for this UE client device A sends a switch request to the CS network. To do this, the MME must be able to:
  • the MSC is therefore responsible for reserving resources for call continuity;
  • the MSC an identifier of the SCC-AS so that the MSC can propagate to the SCC-AS an INVITE request issued by the client device UE A.
  • the MME When attached to the IMS network, the MME retrieved an identifier called "STN-SR" (initials of the words “Session Transfer Number for SRVCC” meaning “Session Transfer Number for SRVCC”) from the HSS server ( who himself received it from SCC-AS). This is a telephone format number that meets the E.164 specification.
  • This identifier is transmitted by the MME to the MSC so that the latter can create a signaling path between the client device UE A and the SCC-AS.
  • the MSC then sends a SIP request to the IMS using the STN-SR number.
  • the SCC-AS receives the INVITE request with a transfer request message of an active session, and supports the session transfer. From this moment, the MME can request the UE-client device A to switch to the GSM or UMTS network. After failover, SIP signaling is transmitted from the SCC-AS to the MSC.
  • the access network PS for example, LTE
  • PS there is notably: an eNode B station;
  • SGW Serving Gateway
  • the SGW routes and transmits user data packets, and also acts as a mobility anchor for user data when transferring between eNode B stations, as well as anchor point during transfers between an LTE network and a network implementing another 3GPP technology;
  • PGW gateway The PGW provides connectivity between the UE and the external packet data networks ("Packet Data Networks" or "PDNs"), serving as the entry and exit point of the traffic for the EU; one UE can be connected simultaneously to multiple PGWs to access multiple PDNs; PGW provides network policy enforcement, packet filtering for each user, imputation assistance, legal interception and packet monitoring.
  • the MSC In the CS network (for example GSM or UMTS), the MSC is associated with an MGW media gateway, which is located at the border between the access network CS and the IMS network to which the UE terminal B is connected.
  • the eSRVCC architecture comprises two entities intended to serve as anchors on the access segment to the core network. These entities, schematically represented in FIG. 1, are the following:
  • ATCF acts as an anchor for SIP signaling, and is placed in the SIP signaling path between P-SCSF and S-CSCF; each ATCF is identified by an STN-SR; in an architecture including ATCF, the SCC-AS will be responsible for transmitting the ATCF STN-SR in charge of a subscriber to the HSS; the SCC-AS receives the ATCF STN-SR at the time of subscriber registration and forwards it to the HSS; the HSS in turn transmits it to the MME (as in the context of the SRVCC procedure described succinctly above); and
  • ATGW acts as an anchor for the media stream; ATGW is controlled by ATCF; ATGW is often co-located with an IMS-AGW media gateway.
  • a mobile terminal UE A when a mobile terminal UE A 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. According to ETSI TS 124 237, mentioned above, the mobile terminal UE A does not need, when registering, to announce its ability to implement the eSRVCC procedure (it must however do it during a call ). If the originating network of the mobile terminal UE A is compatible with the eSRVCC procedure, the ATCF decides, depending on the policy of the operator, to anchor or not the SIP signaling.
  • the ATCF enriches the initial SIP REGISTER request, including by including itself for sessions created on the basis of this record, and adding its URI (called ATCF-URI) in the signaling path. Note that for terminal requests, the ATCF-URI will be able to uniquely identify this record (or record stream, in case a multiple recording mechanism is used).
  • the ATCF then transmits the enriched SIP REGISTER request to the l-CSCF server, which sends the SCC-AS a message containing the initial SIP REGISTER request in the message body.
  • the SCC-AS takes into account the STN-SR (mentioned above) of the ATCF, and updates the HSS server.
  • the SCC-AS then sends to the ATCF, in the message body of a SIP MESSAGE request (described in IETF RFC 3428):
  • the public telephone number in other words the "Mobile Station ISDN Number” (ISDN Number), of the user in the CS network, here called “MSISDN of correlation” and noted C-MSISDN, and
  • ATU-STI the URI of the SCC-AS
  • the MME When the need for a switchover occurs (generally because the signal received by the mobile terminal is too weak), the MME sends a switch request to the network CS.
  • the request contains the STN-SR of the ATCF and the C-MSISDN of the user.
  • the MSC / MGCF generates a new SIP INVITE request including this STN-SR and this C-MSISDN, and sends it to the ATCF.
  • the ATCF finds the relevant C-MSISDN in the "P-Asserted-Identity" field of the received INVITE request, and sends to the SCC-AS, using the ATU-STI (mentioned above), a new request.
  • SIP INVITE reproducing the "Target-Dialog" header of the received INVITE request.
  • FIG. 2 schematically shows a network architecture conventionally used for the eSRVCC procedure in roaming situation.
  • a connection between an IBCF server, called “IBCF1”, of the visited network and an IBCF server, called “IBCF2”, of the originating network enables an UE A to communicate with its home network.
  • FIG 3 which is taken from Appendix A.18.6 of TS 24.237, illustrates the steps that are traditionally implemented in the roaming eSRVCC procedure.
  • steps 1a, 1b and 1c media streams on the PS networks are established between a mobile terminal UE A and an UE client device B.
  • the MSC / MGW transmits (step 2) an INVITE request to the ATCF / ATGW.
  • the old media PS (“Old PS media") being for the time being preserved, the UE terminal A emits (step 5a1), on its new access network CS, new media streams CS ("New CS media”) .
  • the MGW translates these CS streams into PS (“new PS media”) streams, and sends them to the ATCF / ATGW (step 5a2).
  • the ATCF / ATGW then sends (step 6) to NBCF2 an INVITE request containing the ATU-STI, which NBCF2 transfers to the SCC-AS (step 7).
  • this INVITE request triggers, from NBCF2, the reservation of resources in the media plan for the abutting of the media resources on the UE A terminal side, and the media resources on the UE B client-client side.
  • the SCC-AS compares the description of the media stream contained in this INVITE request with the description of the media stream contained in the INVITE request at the origin of the initial media streams (steps 1a, 1b and 1c), and finds that these two descriptions are different (this difference is due through the IBCF server (s)). As a result, the SCC-AS sends a new INVITE request to the UE client device B (step 8).
  • step 1 The new media resources, previously reserved by NBCF2, are then actually taken following receipt by NBCF2 of an acknowledgment 200 OK (step 1 1). It will be noted that there are then (steps 15a, 15b, 15c, 15a1, 15a2, 15b1 and 15c1) coexistence of old and new media streams.
  • the old media streams are only abandoned after the ATCF / ATGW receives a SIP BYE call end request (steps 16 to 18) sent by the SCC-AS (and relayed by NBCF1).
  • Figure 4 illustrates the steps implemented in the eSRVCC procedure in roaming, according to a first embodiment of the invention.
  • Steps 1 to 5a2 are analogous to the corresponding steps of the conventional eSRVCC procedure described above with reference to FIG. But then, in step 6, instead of forwarding to the SCC-AS the SIP INVITE call request it received, the ATCF / ATGW sends it (via NBCF2, step 7) a request for a type other than a call request (such as an SIP INVITE method); to do this, for example, a SIP MESSAGE request, or SIP INFO, or SIP REFER.
  • a type other than a call request such as an SIP INVITE method
  • This SIP request is sent to the SCC-AS ATU-STI (as Request-URI, ie as Resource Identifier, SCC-AS), so as to inform the CSC -AS, as in the classic eSRVCC procedure, that an access transfer procedure was initiated.
  • This SIP request also includes the "Target-Dialog” header (classically inserted in the INVITE request), and / or the "Session-ID” header (described in IETF RFC 7329) if this header was present in the initial INVITE request (ie when initiating communication between UE A and UE B).
  • Request-URI is the SIP-URI "sip: ATU-STI1 @ sccas.home1 .net"
  • orig-ioi visit1 .net
  • Target-Dialog me03a0s09a2sdfgjkl491777;
  • P-Asserted-Service urn: urn-7: 3gpp-service.ims.icsi.mmtel
  • IBCF 2 can not reserve any media resource, since the request contains no description of media flow. As a result, this request is advantageously processed more quickly than a request (for example an SIP INVITE request) containing a description of the media stream.
  • the SCC-AS if it is not compatible with the present invention, it sends a "405 Method Not Implemented" message to the ATCF / ATGW, which then folds over the conventional eSRVCC procedure;
  • the SCC-AS does not propagate the request to the second terminal UE B, and sends to the ATCF / ATGW (steps 8 and 9) an acknowledgment 200 OK (relayed by NBCF2).
  • the old PS media streams are retained (steps 10b and 10c), despite the existence of new CS media streams (step 10a1) between the UE A terminal and the MSC / MGW, and new streams PS media (step 10a2) between the MSC / MGW and the ATCF / ATGW.
  • the ATCF / ATGW sends to the UE terminal A a SIP BYE call termination request (step 1 1) to trigger this liberation.
  • the ATCF did not receive a SIP BYE request from the SCC-AS.
  • FIG. 5 illustrates the steps implemented in the eSRVCC procedure when roaming, according to a second embodiment of the invention. Steps 1 to 5a2 are analogous to the corresponding steps of the conventional eSRVCC procedure described above with reference to FIG.
  • the ATCF / ATGW sends it (via IBCF 2) a SIP request.
  • INVITE containing an indication that the SCC-AS should not consider the media stream description contained in this request.
  • a SIP INVITE request containing an "Access-Transfer" header valued with a dedicated indicator, which will be called "at-no-new-resources”.
  • this SIP INVITE request is sent to the ATU-STI of the SCC-AS, so as to inform the SCC-AS that an access transfer procedure has been initiated.
  • IBCF 2 In passing, IBCF 2, in view of this "at-no-new-resources" indicator, is informed that it must not reserve new media resources, despite the presence of a description of media stream in the message body.
  • FIG. 5 indicates, by way of example, that said description of media stream obeys the Session Description Protocol (SDP) format, which is the format usually used for this purpose.
  • SDP Session Description Protocol
  • the SCC-AS follows reception of this INVITE request, the SCC-AS does not propagate it to the second UE terminal B, and sends the ATCF / ATGW (steps 8 and 9) an acknowledgment 200 OK (relayed by NBCF2).
  • the old media streams are retained (steps 12b and 12c), despite the existence of new CS media streams (step 12a1) between the UE A terminal and the MSC / MGW, and new PS media streams (step 12a2) between MSC / MGW and ATCF / ATGW.
  • the procedure ends with the SCC-AS issuing a SIP BYE call completion request (steps 13 and 14) in response to the SIP INVITE call request of step 7.
  • the reception (via IBCF 2) of this ATCF call termination request SIP BYE causes the release (step 15) of the PS link between the ATCF and the UE terminal A.
  • FIG. 6 illustrates the steps implemented in the roaming procedure eSRVCC, according to a third embodiment of the invention. Steps 1 to 5a2 are analogous to the corresponding steps of the conventional eSRVCC procedure described above with reference to FIG.
  • the ATCF / ATGW request to the SCC-AS ATU-STI is a SIP INVITE call request that does not contain a description of the media stream (which is indicated on Figure 6 by "INVITE without SDP").
  • NBCF2 can not reserve new media resources for the current communication, since no description of media stream is mentioned.
  • the SCC-AS does not propagate it to the second UE B terminal, and responds to the ATCF / ATGW (via NBCF2, steps 8 and 9), with a dedicated error code (by example "492").
  • the old media streams are retained (steps 12b and 12c), despite the existence of new CS media streams (step 12a1) between the UE A terminal and the MSC / MGW, and new PS media streams (step 12a2) between MSC / MGW and ATCF / ATGW.
  • the procedure ends with the release (step 13) of the PS link between the ATCF and the UE A terminal, in response to the receipt by the ATCF (step 9) of the error code message "492".
  • IBCF 2 and not IBCF 1 have been implemented (by way of example). It should be noted, however, that for these steps it is equally possible to implement IBCF 1 instead of IBCF 2.
  • the ATCF is located on the signaling path of the REGISTER registration request sent by the UE terminal A to the S-CSCF server. If this ATCF is compatible with the present invention, it may, optionally, indicate its compatibility by inserting a dedicated "feature-tag”, which will be called “at-keep-resources", in the context of the present invention.
  • Feature-Caps header (defined in IETF RFC 6809) of the REGISTER request.
  • the SCC-AS server may, optionally, following the receipt of the REGISTER request associated with the registration of third parties (described above), insert a dedicated indicator, for example the same indicator "at-keep-resources", in the Feature-Caps header of the MESSAGE request that the SCC-AS sends back to the ATCF. Thanks to these provisions, the ATCF and SCC-AS entities inform each other as soon as the end of the registration procedure of the first terminal A, of their respective compatibilities with the present invention.
  • a dedicated indicator for example the same indicator "at-keep-resources”
  • the present invention can be implemented within the nodes of an IP network, for example ATCF servers, IBCF servers or SCC-AS servers, by means of software and / or hardware components.
  • the software components can be integrated into a typical 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 signals by a memory, as well as an input unit and an output unit.
  • this computer system may be used to execute a computer program including instructions for implementing any of the access network transfer methods of the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for executing the steps of an access network transfer 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 another desirable form.
  • the invention also relates to an information carrier, irremovable, or partially or completely removable, readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, such as a hard disk, or a USB key. ("USB flash drive" in English).
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the computer program according to the invention can in particular be downloaded to an Internet type network.
  • the information carrier may be an integrated circuit in which the program is embedded, the circuit being adapted to execute or to be used in performing any of the access network transfer methods according to the present invention. 'invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

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 : détection qu'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:+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=+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.1 1 ), 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 « Single Radio Voice Call Continuity » signifiant « Continuité d'Appel Vocal Radio Unique »). Le second type est appelé « eSRVCC » (initiales des mots anglais « enhanced Single Radio Voice Call Continuity » signifiant « Continuité d'Appel Vocal Radio Unique Optimisée »). Ces deux types de procédures utilisent un serveur d'applications (« Application Server », ou AS en anglais) dédié, appelé SCC-AS (d'après les initiales des mots anglais « Service Centralization 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 :
- détection qu'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 œuvre 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é.
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.
Selon des caractéristiques particulières, ledit système de communication comprend en outre un serveur IBCF comprenant des moyens pour intercepter une requête émise par ledit serveur ATCF à l'intention dudit serveur d'application SCC-AS ainsi que 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.
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 l'accompagnent, 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 Filter 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:/7bloqs.univ-poitiers.fr/f-launay/2015/06/24/srvcc-sinqle-radio- voice-cali-continuity/) et « SRVCC-Single Radio Voice Call Continuity-Suite » (disponible sur http://blogs.univ-poitiers.fr/f-launay/tag/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 la station eNode B à laquelle est connecté un dispositif-client UE A détecte que le signal reçu par ce dispositif-client UE A est faible, le MME responsable de ce dispositif-client UE A 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 Node 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 imunication.wordpress.com/2015/03/24/mind-the-cove
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 (« Packet 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 MSISDN en anglais), de l'utilisateur dans le réseau CS, appelé en l'occurrence « MSISDN de corrélation » et noté C-MSISDN, 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 »).
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'en- tê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 œuvre classiquement dans la procédure eSRVCC en situation d'itinérance. Initialement (étapes 1 a, 1 b et 1 c), 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 média ») é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 média »). La MGW traduit ces flux CS en flux PS (« new PS média »), et envoie ces derniers à l'ATCF/ATGW (étape 5a2).
L'ATCF/ATGW envoie alors (étape 6) à NBCF2 une requête INVITE contenant l'ATU-STI, que NBCF2 transfère au SCC-AS (étape 7). Au passage, cette requête INVITE déclenche, de la part de NBCF2, 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 1 a, 1 b et 1 c), 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 NBCF2, sont ensuite effectivement prises suite à la réception par NBCF2 d'un acquittement 200 OK (étape 1 1 ). 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 NBCF1 ).
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 1 a à 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 NBCF2, é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 l'IETF) si cet en-tête était présent dans la requête INVITE initiale (i.e. lors de l'initiation 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-STI1 @sccas.home1 .net ») :
MESSAGE sip:ATU-STI1 @sccas.home1 .net SIP/2.0
Via: SIP/2.0/UDP
atcf.visited2.net:5060;branch=z9hG4bk731 b87
Max-Forwards: 70
P-Asserted-ldentity: <tel:+1 -237-555-2222>
P-Charging-Vector: icid-value=
"AyretyU0dm+6O2lrT5tAFrbHLso=023551024";
orig-ioi=visit1 .net
Privacy: none
From: <tel:+1 -237-555-3333>;tag=1888828
To: <tel: +1 -237-555-4444>
Call-ID: cb03a0s09a2sdfglkj490444
Cseq: 127 MESSAGE
Require: tdialog
Record-Route:<sip: atcf.visited2.net:5060;lr>
Target-Dialog: me03a0s09a2sdfgjkl491777;
remote-tag=774321 ; local-tag=64727891
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 NBCF2).
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 10a1 ) 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 1 1 ) 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 œuvre dans la procédure eSRVCC en situation d'itinérance, selon un deuxième mode de réalisation de l'invention. Les étapes 1 a à 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 l'IBCF 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 NBCF2).
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 1 a à 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 à l'ATU-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, NBCF2 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 NBCF2, é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 à 1 1 , 13, 14, 17 et 18 du deuxième mode, et
- 6 à 1 1 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 œuvre au sein des nœuds d'un réseau IP, par exemple des serveurs ATCF, des serveurs 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

R E V E N D I C A T I O N S
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 :
- détection qu'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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
1 1 . 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. 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 à 1 1 .
13. Système de communication selon la revendication 12, caractérisé en ce qu'il comprend en outre un serveur IBCF comprenant des moyens pour intercepter une requête émise par ledit serveur ATCF à l'intention dudit serveur d'application SCC-AS ainsi que 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.
14. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de transfert de réseau d'accès selon l'une quelconque des revendications 1 à 5.
15. Programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de transfert de réseau d'accès selon l'une quelconque des revendications 1 à 5, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2017/050703 2016-03-30 2017-03-28 Procédé de transfert de réseau d'accès pour un terminal mobile en itinérance WO2017168084A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1652746A FR3049805A1 (fr) 2016-03-30 2016-03-30 Procede de transfert de reseau d' acces pour un terminal mobile en itinerance
FR1652746 2016-03-30

Publications (1)

Publication Number Publication Date
WO2017168084A1 true WO2017168084A1 (fr) 2017-10-05

Family

ID=56263874

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2017/050703 WO2017168084A1 (fr) 2016-03-30 2017-03-28 Procédé de transfert de réseau d'accès pour un terminal mobile en itinérance

Country Status (2)

Country Link
FR (1) FR3049805A1 (fr)
WO (1) WO2017168084A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111885584A (zh) * 2020-07-27 2020-11-03 中国联合网络通信集团有限公司 语音漫游注册方法和融合网元
CN113438698A (zh) * 2021-06-28 2021-09-24 中国电信股份有限公司 呼叫路由方法、装置、介质及电子设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160021579A1 (en) * 2014-07-15 2016-01-21 T-Mobile Usa, Inc. Telecommunication Network Pre-Establishment Service Interruption Response

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160021579A1 (en) * 2014-07-15 2016-01-21 T-Mobile Usa, Inc. Telecommunication Network Pre-Establishment Service Interruption Response

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) Service Continuity; Stage 3 (Release 13)", 3GPP STANDARD; 3GPP TS 24.237, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG1, no. V13.4.0, 18 March 2016 (2016-03-18), pages 1 - 480, XP051088175 *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Single Radio Voice Call Continuity (SRVCC) enhancements; Stage 2 (Release 10)", 23 July 2013 (2013-07-23), XP050725445, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/Latest_SA2_Specs/Rel-10/> [retrieved on 20130723] *
FRÉDÉRIC LAUNAY, SRVCC-SINGLE RADIO VOICE CALL CONTINUITY, Retrieved from the Internet <URL:http://bloqs.univ-poitiers.fr/f-launav/2015/06/24/srvcc-sinqle-radio-voice-call-continuitv/>
GSMA: "S8HR Technical Report Version 0.1 [Publication Date]", 19 October 2015 (2015-10-19), XP051041111, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/SA2/Docs/> [retrieved on 20151019] *
SRVCC-SINGLE RADIO VOICE CALL CONTINUITY-SUITE, Retrieved from the Internet <URL:http://bloqs.univ-poitiers.fr/f-launav/taq/esrvcc/>
YUAN TINGTING ET AL: "Performance Evaluation and Optimization of SRVCC Handover Scheme", 2014 IEEE INTERNATIONAL CONFERENCE ON COMPUTER AND INFORMATION TECHNOLOGY, IEEE, 11 September 2014 (2014-09-11), pages 76 - 81, XP032702874, DOI: 10.1109/CIT.2014.44 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111885584A (zh) * 2020-07-27 2020-11-03 中国联合网络通信集团有限公司 语音漫游注册方法和融合网元
CN111885584B (zh) * 2020-07-27 2022-12-02 中国联合网络通信集团有限公司 语音漫游注册方法和融合网元
CN113438698A (zh) * 2021-06-28 2021-09-24 中国电信股份有限公司 呼叫路由方法、装置、介质及电子设备

Also Published As

Publication number Publication date
FR3049805A1 (fr) 2017-10-06

Similar Documents

Publication Publication Date Title
EP2080339B1 (fr) Procede de routage d&#39;un message sip en cas d&#39;indisponibilite de noeuds intermediaires
US8325707B2 (en) Session initiation from application servers in an IP multimedia subsystem
EP1560368A1 (fr) Procédé d&#39;établissement d&#39;une session multimédia entre un équipement appelant et un équipement appelé d&#39;un réseau du type à sous domaine multimédia et système de communication mettant en oeuvre ce procédé
FR2975252A1 (fr) Procede de traitement d&#39;une requete de basculement d&#39;une communication entre deux reseaux d&#39;acces
EP2449745B1 (fr) Procédé de sélection d&#39;une ressource réseau
EP2926524B1 (fr) Routage d&#39;une requête de service visant un abonné ims
WO2017168084A1 (fr) Procédé de transfert de réseau d&#39;accès pour un terminal mobile en itinérance
WO2020128258A1 (fr) Procédé de basculement d&#39;une communication de tcp sur udp
WO2015197937A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d&#39;un appelé
Wisely SIP and conversational Internet applications
FR3067539A1 (fr) Procede de traitement d&#39;une requete et serveur d&#39;un coeur de reseau ip multimedia
EP3583757B1 (fr) Procédé de changement de réseau mobile
WO2009118383A1 (fr) Procede et passerelle de basculement d&#39;une session multimedia
EP3472993B1 (fr) Procédé de détermination d&#39;un ensemble de formats de codage pour établir une communication
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP3646578B1 (fr) Procédé de synchronisation d&#39;état média
WO2012085429A2 (fr) Procédé de localisation et d&#39;identification d&#39;un abonné connecté à un réseau émulant le rtc/rnis
EP3632078B1 (fr) Procédé de contrôle d&#39;une communication comprenant des transactions multiples
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
WO2015181505A1 (fr) Procédé pour informer une entité d&#39;un réseau ip du type de réseau d&#39;accès utilisé par un terminal
Lee et al. Interworking architecture between ims and p2psip for ubiquitous services
WO2012072920A1 (fr) Procédé et dispositif de gestion d&#39;une souscription a un service dans un réseau ims

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17717790

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17717790

Country of ref document: EP

Kind code of ref document: A1