WO2013156061A1

WO2013156061A1 - Failure handling within a network implementing srvcc

Info

Publication number: WO2013156061A1
Application number: PCT/EP2012/057018
Authority: WO
Inventors: Leif Gustavsson; Afshin Abtin; Hans Andersson; Tobias Olof Austrell; Johan Roelof KOLNER
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2012-04-17
Filing date: 2012-04-17
Publication date: 2013-10-24

Abstract

A method of handling the failure of a Service Centralization and Continuity Application Server (SCC-AS) within an IP Multimedia Subsystem (IMS) network implementing a Single Radio Voice Call Continuity function. The method comprises, following the failure of an SCC-AS for a given end user, replacing at an Access Transfer Control Function (ATCF) serving the user, a first Access Transfer Update Session Transfer Identification (ATU-STI) that identifies said SCC-AS, with a further ATU-STI that identifies a redundant SCC-AS. This allows the ATCF to subsequently notify the redundant SCC-AS of an access transfer request in respect of the user.

Description

FAILURE HANDLING WITHIN A NETWORK IMPLEMENTING SRVCC

Technical Field The present invention relates to failure handling within a network implementing Service Continuity using the Single Radio Voice Call Continuity (SRVCC). More particularly, the invention relates to the handling of the failure of a Service Centralisation and Continuity Application Server (SCC-AS). Background

IP Multimedia (IPMM) services provide a dynamic combination of voice, video, messaging, data, etc, within the same session. By growing the numbers of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services.

IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to- person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP),

Existing cellular network deployments are dominated by the 2G and 3G standards. The process of rolling out so-called 4G networks has just begun, and it will be many years before 4G network coverage is sufficient to allow 2G and 3G networks to be withdrawn completely. A fundamental requirement for real-time service provision is the seamless handover of services for subscribers moving across cell boundaries of the radio access network (RAN). Given the ongoing co-existence of 2G, 3G and 4G networks, it is particularly desirable to allow for the handover of real-time service connections such as voice calls between the different radio access technologies.

Considering further the 4G technology, this is being specified under the name LTE (Long Term Evolution) and SAE (System Architecture Evolution) in 3GPP. The LTE radio access network technology implements only a packet switched access, in contrast to 2G and 3G (using GERAN and UTRAN radio access network technologies respectively) which provide for both packet switched and circuit switched access. In 2G and 3G networks, packet switched connections are used to carry data whilst circuit switched connections are used for real-time services such as voice calls. In 4G networks, all services will be carried via packet switched connections. In the case of a voice call initiated when a user is attached to an LTE radio access network (termed Enhanced UTRAN or E-UTRAN), that call will of course make use of a packet switched connection. If it is necessary for the call to be transferred to a 2G or 3G radio access network, e.g. because the user moves out of the coverage area of the E-UTRAN but remains within the coverage area of a GERAN or UTRAN network, the call must be switched from a packet switched (PS) access to a circuit switched (CS) access. Of course, the process for implementing the handover must be seamless such that little or no disruption of the call is perceived by the user. An appropriate access handover mechanism is also required in the case of the handover of a call from a PS access using a 3G UTRAN (HSPA) access network to a CS call using either 3G UTRAN access or 2G GSM access.

Figure 1 illustrates schematically a scenario in which a user terminal (or User Equipment, UE, according to 3G terminology) initiates a voice call using an LTE radio access network and is subsequently handed over to a GSM/Edge Radio Access Network (GERAN). The call is established using the IMS network described above and which provides a common service control network for the PS and CS domains provided through the LTE, UTRAN, or GERAN radio accesses. In particular, the IMS includes a Multimedia Telephony (MMTel) Application Server which implements service logic for establishing and controlling voice calls. In order to implement the access handover, media control must be transferred from the Evolved Packet Core (EPC) network of the 4G domain to an allocated Mobile Switching Centre (MSG) within the 2G/3G domain. Other components illustrated in Figure 1 are a Mobile Switching Centre Server (MSS) - i.e. the service part of the traditional MSG - which has support for the GSM access network, an enhanced Node B (eNodeB) which provides inter alia control of radio access within the LTE RAN, a Serving/PDN gateway (S/P-GW), a Mobility Management Entity (MME) (both the S/P-GW and the MME reside within the EPC), and a Home Subscriber Server that resides within a subscriber's home network. The S-GW sits in the user plane where it forwards and routes packets to and from the eNodeB and the PDN GW (not shown in Figure 1 ). The S-GW also serves as the local mobility anchor for inter-eNodeB handovers and roaming between two 3GPP systems. The PDN GW acts as the interface between the radio network and the Packet Data Networks (PDNs), such as the Internet or SIP-based IMS networks (fixed and mobile). The PDN GW is the mobility anchor point for intra-3GPP access system mobility and for mobility between 3GPP access systems and non-3GPP access systems.

Interworking solutions for IMS Centralized Services (ICS) as specified in 3GPP TS 23.292, "IP Multimedia Subsystem (IMS) centralized services; Stage 2", allows IMS sessions using CS bearers to be treated as standard IMS sessions, which is required for the purpose of IMS Service Continuity. ICS defines signalling mechanisms between the UE and IMS for transport of information to centralise the service in the IMS, and TS 23.237 "IP Multimedia Subsystem (IMS) Service Continuity" defines the additional procedures needed for service continuity when using CS access for media transport. Within the context of TS 23.292 and TS 23.237, the further 3GPP document TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2", describes a mechanism for handing over a voice call from a PS to a CS access. With reference to Figure 1 , this relies upon ICS and Service Continuity functionality that is implemented in the Service Centralisation and Continuity Application Server (SCC-AS) within the IMS (shown co-located with the MMTel AS in Figure 1 ). Whilst effective, the mechanism described in TS 23.216 (identified as Rel-9) involves a relatively long path for handover control signalling given that the SCC-AS is located in a user's home network and the signalling may have to pass through an IMS network associated with a visited network (in the case of a roaming subscriber where the serving network is not the home network). Handovers may be delayed as a result, possibly giving rise to interruptions in voice calls. SRVCC is applicable to handover to a CS access from a PS access where that PS access is provided by either of an LTE access or a UTRAN (HSPA) access. It has been recognised that such a long path for access handover related signalling is undesirable. This problem is addressed in TS 23.237, "IP Multimedia Subsystem (IMS) Service Continuity", which proposes introducing the architecture illustrated in Figure 2. An Access Transfer Control Function (ATCF) is included in the serving (e.g. visited) IMS network. This architecture is referred to as Rel-10. According to Rel-10, the ATCF acts as a media gateway controller for an Access Transfer Gateway (ATGW) that is also present in the serving IMS network. The ATGW acts as an anchor for the IMS media traffic to allow media traffic to be switched quickly from the PS access network to the CS access network via the MSG. Additional functions of IMS Service Continuity are provided by the ATCF/ ATGW in the serving (visited if roaming) network. In particular, responsibility for managing radio access handovers is delegated from the SCC-AS to the ATCF. Within the CS core network, an SRVCC function is introduced into one of the network MSCs. This may or may not be the same MSG as the Target MSG for the handover. When the UE performs IMS registration, a decision is made (by the P-CSCF) as to whether or not to include the ATCF in the path. If the ATCF is included, the ATCF reports a Session Transfer Number Single Radio (STN-SR) and an ATCF-mgmt-URI to the SCC-AS in the home IMS network. The STN-SR is recorded by the SCC-AS in the HSS in respect of the ongoing IMS session. The STN-SR points uniquely to the ATCF and is useable outside of the IMS (e.g. in CS network and in an Enhanced Packet Core Network, ECN) to address the ATCF. Following this registration procedure, as illustrated in Figure 3, the SCC-AS provides Access Transfer Information towards the ATCF by sending to it a message including the Access Transfer Update Session Transfer Identification (ATU-STI). The ATU-STI is an identifier identifying the selected SCC-AS. The SCC-AS uses the ATCF-mgmt-URI, which is an address of the ATCF useable internally within the IMS, to direct the messages to the ATCF.

When the UE is either initiating or receiving an incoming call, the ATCF makes a decision concerning whether or not to anchor the media in the controlled ATGW. If the media is anchored at the ATGW, then, when an access handover takes place, the redirection of media to the new access will be carried out locally in the serving (e.g. visited) network. The anchored media in the ATGW is redirected to the CS side instead of the PS side. The MSG in the CS network sends an access transfer message to the ATCF, the message including the C-MSISDN of the UE. The ATCF uses the C-MSISDN to identify the correct user and session [NB. The SCC-AS will have provided the C-MSISDN to the ATCF at user IMS registration, together with the ATU-STI.] The ATCF then updates the SCC-AS that the transfer has taken place by sending an Access Transfer Update message to the SCC-AS, using the stored ATU- STI to route to the SCC-AS. Figure 4 illustrates in more detail the associated signaling, showing in particular the Access Transfer Update sent from the ATCF to the SCC-AS (via the S-CSCF).

Some considerable time may elapse between a UE's IMS registration and the need for an ongoing communication session to change access. During this period, the SCC-AS instance allocated to the UE can fail (due for example to hardware or software faults, a fault occurring on a link, or the SCC-AS being taken out of service). In such a scenario, as the SCC-AS must be involved in both originating and terminating call set up procedures, any attempt to establish a call involving the UE will fail. This is illustrated in Figure 5.

One might think that this problem could be addressed simply by providing a backup or "geographically redundant" SCC-AS to replace the operational SCC-AS in the event that that SCC-AS fails. In this scenario, user IMS registration data would need to be copied from the failed SCC-AS (either before failure or after if some "recovery" mechanism is provided) to the redundant SCC-AS. However, as is illustrated in Figure 6, this approach may continue to result in the failure of the session handover procedure as the Access Transfer update, sent by the ATCF and addressed to the failed SCC-AS, will not be delivered to the redundant SCC-AS. This is because the ATU-STI held by the ATCF for the transferred UE will continue to point at the failed SCC-AS.

Summary

According to a first aspect of the present invention there is provided a method of handling the failure of a Service Centralization and Continuity Application Server (SCC- AS) within an IP Multimedia Subsystem (IMS) network implementing a Single Radio Voice Call Continuity function. The method comprises, following the failure of an SCC- AS for a given end user, replacing at an Access Transfer Control Function (ATCF) serving the user, a first Access Transfer Update Session Transfer Identification (ATU- STI) that identifies said SCC-AS, with a further ATU-STI that identifies a redundant SCC-AS. This allows the ATCF to subsequently notify the redundant SCC-AS of an access transfer request in respect of the user.

Embodiments of the present invention enable an appropriate service level to be maintained, to users, in the event of an SCC-AS failover. In particular, in such an event, PS calls established by a user may continue to be handed over to a CS access when required.

The ATCF may receive the further ATU-STI in a SIP request sent from said redundant SCC-AS.

According to a second aspect of the present invention there is provided a method of handling the failure of a Service Centralization and Continuity Application Server (SCC- AS) within an IP Multimedia network implementing a Single Radio Voice Call Continuity function. The method comprises, at IP Multimedia Subsystem (IMS) registration of a user, recording at a Serving Call Session Control Function (S-CSCF) an ATCF-mgmt- URI being an address of an Access Transfer Control Function (ATCF) serving the user. The method further comprises detecting failure of a SCC-AS serving the user at said S- CSCF and sending from the S-CSCF to a redundant SCC-AS, said ATCF-mgmt-URI to enable said redundant SCC-AS to send its address to the ATCF.

The failure of said SCC-AS may be detected in response to receipt by the S-CSCF of a session initiation request sent to or from said user. Furthermore, the step of sending said ATCF-mgmt-URI to said redundant SCC-AS may comprise sending the ATCF- mgmt-URI in a SIP NOTIFY, in response to receipt of a SIP SUBSCRIBE sent by said redundant SCC-AS. The method may further comprise, at the S-CSCF, also storing a Session Transfer Number Single Radio (STN-SR) being an address of an Access Transfer Control Function (ATCF) serving the user, and sending that STN-SR to the redundant SCC-AS together with said ATCF-mgmt-URI. According to a third aspect of the present invention there is provided a method of handling the failure of a Service Centralization and Continuity Application Server (SCC- AS) within an IP Multimedia network implementing a Single Radio Voice Call Continuity function. The method comprises, at a redundant SCC-AS providing redundancy for a failed SCC-AS, receiving from a Serving Call Session Control Function (S-CSCF) or a Home Subscriber Server (HSS) or other network node, an ATCF-mgmt-URI being an address of an Access Transfer Control Function (ATCF) serving a user. User data including said ATCF-mgmt-UR is stored, and an Access Transfer Update Session Transfer Identification (ATU-STI), that identifies the redundant SCC-AS, is sent to said ATCF using the received ATCF-mgmt-URI.

The method may further comprise, in response to receipt at said redundant SCC-AS of a session initiation request in respect of said user, using the SIP SUBCRIBE method to obtain said ATCF-mgmt-URI from the S-CSCF. The method may further comprise, at said redundant SCC-AS, receiving an STN-SR of said ATCF from said S-CSCF, together with said ATCF-mgmt-URI, and storing that STN-SR in a Home Subscriber Server (HSS).

According to a fourth aspect of the present invention there is provided a method of handling the failure of a Service Centralization and Continuity Application Server (SCC- AS) within an IP Multimedia network implementing a Single Radio Voice Call Continuity function. The method comprises, at IP Multimedia Subsystem (IMS) registration of a user, recording at a Serving Call Session Control Function (S-CSCF), Home Subscriber Server (HSS) or other network node, an ATCF-mgmt-URI being an address of an Access Transfer Control Function (ATCF) serving the user, and registering the user with an operational SCC-AS.

At said S-CSCF, failure of said operational SCC-AS is detected and, as a result, said ATCF-mgmt-URI is sent to a redundant SCC-AS from the S-CSCF, HSS or other network node. Said ATCF-mgmt-URI is received at said redundant SCC-AS and user data stored including said ATCF-mgmt-URI. An Access Transfer Update Session Transfer Identification (ATU-STI) that identifies the redundant SCC-AS, is then sent to said ATCF using the received ATCF-mgmt-URI. The ATU-STI is received and stored at said ATCF, whereupon a session initiation request received from said user can be forwarded by said ATCF to said redundant SCC-AS. The method may comprise, in response to receipt at said redundant SCC-AS of a session initiation request initiated by said user, using the SIP NOTIFY to deliver said ATCF-mgmt-URI from the S-CSCF to the redundant SCC-AS. The method may further comprise storing a STN-SR of said ATCF at the S-CSCF, sending that STN-SR to the redundant SCC-AS together with said ATCF-mgmt-URI, and, at the redundant SCC- AS, receiving the STN-SR and storing it in the HSS.

According to a fifth aspect of the present invention there is provided an apparatus configured to implement an Access Transfer Control Function (ATCF) within an IP Multimedia Subsystem (IMS) network implementing a Single Radio Voice Call Continuity function. The apparatus comprises a memory for storing an Access Transfer Update Session Transfer Identification (ATU-STI) that identifies an SCC-AS serving a user registered with the IMS, and a memory controller configured, following the failure of an SCC-AS serving a given end user, to replace in said memory a first Access Transfer Update Session Transfer Identification (ATU-STI) that identifies the failed SCC-AS, with a further ATU-STI that identifies a redundant SCC-AS. Thereafter, the ATCF may notify the redundant SCC-AS of an access transfer request in respect of the user.

The apparatus may comprise a receiver for receiving the further ATU-STI in a SIP message sent from said redundant SCC-AS.

According to a sixth aspect of the present invention there is provided apparatus configured to implement a Serving Call Session Control Function (S-CSCF) within an IP Multimedia Subsystem (IMS) network implementing a Single Radio Voice Call Continuity function. The apparatus comprises a memory and memory controller for recording, at IP Multimedia Subsystem (IMS) registration of a user, an ATCF-mgmt- URI being an address of an Access Transfer Control Function (ATCF) serving the user, and a detector for detecting failure of a SCC-AS serving the user at said S-CSCF and for sending from the S-CSCF to a redundant SCC-AS, said ATCF-mgmt-URI to enable said redundant SCC-AS to send its address to the ATCF.

Said detector may be configured to detect a failure following receipt by the S-CSCF of a session initiation request sent by said user. The detector may also be configured to send the ATCF-mgmt-U I to the redundant SCC-AS in a SIP NOTIFY in response to receipt of a SIP SUBSCRIBE sent by said redundant SCC-AS.

According to a seventh aspect of the present invention there is provided apparatus configured to implement a Service Centralization and Continuity Application Server (SCC-AS) within an IP Multimedia network implementing a Single Radio Voice Call Continuity function. The apparatus comprises a receiver for receiving, from a Serving Call Session Control Function (S-CSCF), Home Subscriber Server (HSS) or other network node, an ATCF-mgmt-URI being an address of an Access Transfer Control Function (ATCF) serving a user, and a memory for storing user data including said ATCF-mgmt-URI. The apparatus further comprises a transmitter for sending an Access Transfer Update Session Transfer Identification (ATU-STI) that identifies the SCC-AS, to said ATCF using the received ATCF-mgmt-URI. The receiver may be configured to receive said ATCF-mgmt-URI in a SIP SUBSCRIBE message from the S-CSCF.

Brief Description of the Drawings Figure 1 illustrates schematically a prior art architecture for managing PS to CS handover of voice calls according to 3GPP Rel-9;

Figure 2 illustrates schematically a prior art architecture for managing PS to CS handover of voice calls according to 3GPP Rel-10;

Figure 3 illustrates a procedure occurring at IMS user registration in the Rel-10 architecture of Figure 2, and which informs an ATCF node of the address of the allocated SCC-AS;

Figure 4 illustrates a procedure for handling PS to CS handover of a user terminal according to the Rel-10 architecture of Figure 2;

Figure 5 illustrates a handover failure process occurring in the Rel-10 architecture of Figure 2, due to failure of the allocated SCC-AS;

Figure 6 illustrates a handover failure process occurring in the Rel-10 architecture of Figure 2, due to failure of the allocated SCC-AS, despite the introduction of a redundant SCC-AS;

Figure 7 illustrates an improved handover process which allows a redundant SCC-AS to signal its ATU-STI to a serving ATCF; Figure 8 is a flow diagram further illustrating the process of Figure 7;

Figures 9 to 1 1 illustrate respectively S-CSCF, SCC-AS and ATCF nodes for use in implementing the process of Figures 7 and 8. Detailed Description

As has been discussed above, the 3GPP Single Radio Voice Call Continuity (SRVCC) mechanism provides for the handover of a voice call from a Packet Switched (PS) access to a Circuit Switched (CS) access, whilst the enhancements introduced in Rel- 10 provide for an optimised access handover procedure by delegating certain responsibilities from the SCC-AS in a subscriber's home network to an ATCF in a serving (e.g. visited) network. As has also been discussed, the current SRVCC proposals do not address the risk posed by an SCC-AS failure. The present proposal addresses the risk of SCC-AS failure by making use of a geographically redundant SCC-AS that can take over from some other SCC-AS in the event that the other SCC-AS fails or is otherwise taken out of service (e.g. due to upgrading or maintenance). The term "geographically" is used here to indicate that the redundant node is in a different geographical location such that failure of the redundant SCC-AS is unlikely to occur at the same time as the operational SCC-AS. [The process to be described is not however limited to such redundant SCC-ASs, and may be applied to co-located SCC-ASs.] The term "redundant" SCC-AS should also be interpreted to include, for example, a standby SCC-AS that is only brought into use when an operational SCC-AS fails, or an already operational SCC-AS (in the sense that it may already be serving other users when another operational SCC-AS fails). The only requirement is that it provides redundancy, or back-up, for the operational SCC-AS.

To facilitate a transfer of responsibilities between SCC-ASs at SCC-AS failure, restoration of the registration information for a user in the redundant SCC-AS is carried out. The ATCF-mgmt-URI of the ATCF serving a UE is held in the operational S- CSCF for possible upload to redundant SCC-AS in the event of a failure of the operational SCC-AS. The S-CSCF may also hold the STN-SR of the serving ATCF. [In the following discussion, the STN-SR and the ATCF-mgmt-URI of a given ATCF are referred to collectively as the "ATCF addresses". However, it may also be understood that this term may be used to identify only the ATCF-mgmt-U I (i.e. the STN-SR is optional). The term also encompasses other, e.g. future, schemes for address the ATCF.] Following a failure, this uploading of the ATCF addresses allows the redundant SCC-AS to replace, in the ATCF, the previously stored ATU-STI (for the failed SCC-AS) with the ATU-STI for the redundant SCC-AS.

Two possible mechanisms for recreating the user database at the redundant SCC-AS are:

1 ) Use of Registration Event or third party registration information from the S- CSCF. [NB. The session data in the failed SCC-AS is not restored in the redundant SCC-AS, only the user IMS registration data. SRVCC functions dependent on session data (for example access transfer of calls in the alerting state) will not therefore work after a transfer to the redundant SCC-AS.]

2) Storage and restoration using the HSS (over the Sh interface) or some other network node.

Figure 7 illustrates the SCC-AS failure and handover procedure, termed a "fa i lover", in more detail assuming the use of option 1 ) above, i.e. use of Registration Event. Steps 1 to 6 relate to the conventional IMS registration procedure (Rel-10). At step 7, new functionality is added to the S-CSCF to cause the S-CSCF to store the ATCF addresses received in the REGISTER message (step 3). This is stored as part of the user data. Steps 8 to 12 represent standard IMS registration behaviour and result in the operational SCC-AS (that is the SCC-AS allocated to serve the registering user) obtaining and storing the ATCF addresses that represents the SIP address of the ATCF, and the ATCF obtaining and storing the ATU-STI that represents the address of the operational SCC-AS.

Step 13 in Figure 7 indicates a failure of the operational SCC-AS. The ATCF remains unaware of this failure, at least in respect of the user in question, until the UE sends an INVITE to the IMS in order to initiate a new IMS session. This INVITE is received by the P-CSCF and is forwarded via the ATCF to the S-CSCF (steps 16 and 17). At step 18, the S-CSCF will detect that the operational SCC AS has failed. This detection uses the standard mechanism of initial Filter Criteria (iFC): iFC allows the IMS to select an Application Server, in this case an SCC-AS. The result of iFC is a Fully Qualified Doman name (FQDN) and the IMS uses a DNS lockup to translate the FQDN to an IP address. The S-CSCF tries to signal to the selected SCC-AS over this IP address but will experience a timeout when the SCC-AS fails to answer. This timeout indicates to the S-CSCF that the SCC-AS has failed. The DNS lookup response, received by the S-CSCF, includes an alternative IP address for the FQDN which identifies an alternative, redundant SCC-AS. The S-CSCF uses this alternative IP address to forward the INVITE to the redundant SCC-AS. At step 20, the redundant SCC-AS determines that the INVITE relates to a (calling) user that is not in its database. As a result, the redundant SCC-AS uses the SUBSCRIBE method (steps 21 to 24) to request from the S-CSCF the addresses of the serving ATCF (ATCF-mgmt-URI and STN-SR). These are sent by the S-CSCF as an information element within the SIP NOTIFY. At step 25, the redundant SCC-AS sends a signal to the ATCF including the ATU-STI (address) of the redundant SCC-AS, using the uploaded ATCF-mgmt-URI to route the signal. At step 27, the ATCF receives this message and replaces the previously held ATU-STI with the received ATU-STI. Alternatives to the SUBSCRIBE method may be used, e.g. the SIP OPTIONS method or an additional parameter in the SIP INVITE. The redundant SCC-AS will also attempt to store the STN-SR received in the NOTIFY, in the HSS. This will address the problem arising when the operational SCC-AS failed during user registration, i.e. where that registration did not result in the STN-SR being correctly stored in the HSS.

It will be appreciated that, using this approach, session transfer will be possible for all sessions that are initiated by the user after the operational SCC-AS has failed and the ATCF has been updated with the ATU-STI of the redundant SCC-AS. Transfer of sessions ongoing at the time of failure cannot be transferred. However, it will be appreciated that the net benefit to the user will remain significant.

Figure 8 is a flow diagram further illustrating the failover procedure discussed above. At step S1 , a user (UE) initiates IMS registration in order to allow the user to make use of IMS service such as voice and multimedia calls. Registration gives rise to step S2 where the addresses of the ATCF serving the user are recorded at the S-CSCF. IMS registration of the user also results in step S3 where the user is registered with a particular (operational) SCC-AS. At some point following user IMS registration, step S4, the S-CSCF detects a failure (e.g. due to an apparatus or line fault or due to a removal from service) of the operational SCC-AS. This detection in turn, step S5, causes the S-CSCF to send to the (allocated) redundant SCC-AS the ATCF addresses which identify the serving ATCF. At step S6, the redundant SCC-AS receives the ATCF addresses and stores this in user data for the user. At step S7, the redundant SCC-AS (using the ATCF- mgmt-URI) sends it own ATU-STI to the ATCF. The ATCF receives and stores the ATU-STI at step S8. This allows the ATCF to subsequently forward access transfer requests, in respect of the user, to the redundant SCC-AS. Although not shown in Figure 8, the ATCF may also store the received STN-SR in the HSS.

Figure 9 illustrates schematically an S-CSCF node 1 configured to operate within the network architecture described above. The node is implemented using appropriate (server) hardware and comprises a memory 2 for storing, for each registered user, associated ATCF addresses (including the ATCF-mgmt-URI and STN-SR). The memory 2 is managed by a memory controller 3. A detector 4 is responsible for detecting the failure of an operational SCC-AS, for a given user, [sending the INVITE to the redundant SCC-AS] and sending the associated ATCF addresses to the redundant SCC AS (e.g. using the SUBSCRIBE-NOTIFY method). Figure 10 illustrates schematically an SCC-AS node 5 configured to operate within the network architecture described above. The node is implemented using appropriate (server) hardware and is designed to provide redundancy for some other, operational SCC-AS. When that operational SCC-AS fails, a receiver 6 receives from an S-CSCF ATCF addresses of the ATCF serving a user. These are stored in a memory 7. A transmitter 8 is provided for sending to the ATCF the ATU-STI of the redundant SCC- AS. The receiver might also be configured to receive a SIP INVITE from the S-CSCF and, in response initiate the SIP SUBCRIBE method to obtain the ATCF addresses from the S-CSCF. Figure 1 1 illustrates schematically an ATCF node 9 configured to operate within the network architecture described above. The node is implemented using appropriate (server) hardware and comprises a memory 10 for storing ATU-STI data including, for each registered user, the ATU-STI of the serving SCC-AS. A memory controller 1 1 is provided for updating the stored ATU-STI (for a given user) with a redundant SCC-AS ATU-STI in the event that the operational SCC-AS fails. The approach presented here makes it possible to introduce a redundant SCC-AS, making the SRVCC architecture better able to tolerate failures as the operational SCC- AS is no longer a single point of failure. Problems arising out of site damage due, for example, to earthquake, fire, flooding or power outage and resulting in a failure of an operational SCC-AS, can be mitigated. More particularly, a user does not need to wait until IMS re-registration before the SRVCC Access Transfer will function, and the user does not need to perform any specific action, e.g. turn off and on his or her device. It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention. For example, one alternative embodiment involves identifying the ATU-STI of the redundant SCC-AS to the S-CSCF at IMS registration of the UE, i.e. providing this ATU-STI together with the ATU-STI of the serving (operational) SCC-AS. This allows the S-CSCF to use the alternative ATU-STI in the event that a failure of the operational SCC-AS is detected. However, the approach is not optimal due to its impact on current standards. It is further noted that the invention is applicable to future network architectures which employ the SRVCC function, for example so-called LTE- Advanced or 5G.

Claims

1 . A method of handling the failure of a Service Centralization and Continuity Application Server (SCC-AS) within an IP Multimedia Subsystem (IMS) network implementing a Single Radio Voice Call Continuity function, the method comprising: following the failure of an SCC-AS for a given end user, replacing at an Access Transfer Control Function (ATCF) serving the user, a first Access Transfer Update Session Transfer Identification (ATU-STI) that identifies said SCC-AS, with a further ATU-STI that identifies a redundant SCC-AS, whereupon the ATCF may subsequently notify the redundant SCC-AS of an access transfer request in respect of the user.

2. A method according to claim 1 , wherein said ATCF receives the further ATU- STI in a SIP request sent from said redundant SCC-AS.

3. A method of handling the failure of a Service Centralization and Continuity Application Server (SCC-AS) within an IP Multimedia network implementing a Single Radio Voice Call Continuity function, the method comprising:

at IP Multimedia Subsystem (IMS) registration of a user, recording at a Serving Call Session Control Function (S-CSCF) an ATCF-mgmt-URI being an address of an Access Transfer Control Function (ATCF) serving the user; and detecting failure of a SCC-AS serving the user at said S-CSCF and sending from the S-CSCF to a redundant SCC-AS, said ATCF-mgmt-URI to enable said redundant SCC-AS to send its address to the ATCF.

4. A method according to claim 3, wherein the failure of said SCC-AS is detected in response to receipt by the S-CSCF of a session initiation request sent to or from said user.

5. A method according to claim 3 or 4, wherein said step of sending said ATCF- mgmt-URI to said redundant SCC-AS comprises sending the ATCF-mgmt-URI in a SIP NOTIFY, in response to receipt of a SIP SUBSCRIBE sent by said redundant SCC-AS.

6. A method according to any one of claims 3 to 5 and comprising, at the S-CSCF, also storing a Session Transfer Number Single Radio (STN-SR) being an address of an Access Transfer Control Function (ATCF) serving the user, and sending that STN- SR to the redundant SCC-AS together with said ATCF-mgmt-URI.

7. A method of handling the failure of a Service Centralization and Continuity Application Server (SCC-AS) within an IP Multimedia network implementing a Single

Radio Voice Call Continuity function, the method comprising:

at a redundant SCC-AS providing redundancy for a failed SCC-AS, receiving from a Serving Call Session Control Function (S-CSCF) or a Home Subscriber Server (HSS) or other network node, an ATCF-mgmt-URI being an address of an Access Transfer Control Function (ATCF) serving a user;

storing user data including said ATCF-mgmt-URI; and

sending an Access Transfer Update Session Transfer Identification (ATU-STI) that identifies the redundant SCC-AS, to said ATCF using the received ATCF- mgmt-URI.

8. A method according to claim 7 and comprising, in response to receipt at said redundant SCC-AS of a session initiation request in respect of said user, using the SIP SUBCRIBE method to obtain said ATCF-mgmt-URI from the S-CSCF.

9. A method according to claim 7 or 8 and comprising, at said redundant SCC-AS, receiving an STN-SR of said ATCF from said S-CSCF, together with said ATCF-mgmt- URI, and storing that STN-SR in a Home Subscriber Server (HSS).

10. A method of handling the failure of a Service Centralization and Continuity Application Server (SCC-AS) within an IP Multimedia network implementing a Single Radio Voice Call Continuity function, the method comprising:

at IP Multimedia Subsystem (IMS) registration of a user, recording at a Serving Call Session Control Function (S-CSCF), Home Subscriber Server (HSS) or other network node, an ATCF-mgmt-URI being an address of an Access Transfer Control Function (ATCF) serving the user;

registering the user with an operational SCC-AS;

at said S-CSCF, detecting failure of said operational SCC-AS and, as a result, sending said ATCF-mgmt-URI to a redundant SCC-AS from the S-CSCF, HSS or other network node;

at said redundant SCC-AS, storing user data including said ATCF-mgmt-URI; sending an Access Transfer Update Session Transfer Identification (ATU-STI) that identifies the redundant SCC-AS, to said ATCF using the received ATCF- mgmt-URI; and

receiving and storing the ATU-STI at said ATCF, whereupon a session initiation request received from said user can be forwarded by said ATCF to said redundant SCC-AS.

1 1 . A method according to claim 10 and comprising, in response to receipt at said redundant SCC-AS of a session initiation request initiated by said user, using the SIP NOTIFY to deliver said ATCF-mgmt-URI from the S-CSCF to the redundant SCC-AS.

12. A method according to claim 10 or 1 1 and comprising storing a STN-SR of said ATCF at the S-CSCF, sending that STN-SR to the redundant SCC-AS together with said ATCF-mgmt-URI, and, at the redundant SCC-AS, receiving the STN-SR and storing it in the HSS.

13. Apparatus configured to implement an Access Transfer Control Function (ATCF) within an IP Multimedia Subsystem (IMS) network implementing a Single Radio Voice Call Continuity function, the apparatus comprising:

a memory for storing an Access Transfer Update Session Transfer Identification

(ATU-STI) that identifies an SCC-AS serving a user registered with the IMS; and

a memory controller configured, following the failure of an SCC-AS serving a given end user, to replace in said memory a first Access Transfer Update Session Transfer Identification (ATU-STI) that identifies the failed SCC-AS, with a further ATU-STI that identifies a redundant SCC-AS, whereupon the ATCF may subsequently notify the redundant SCC-AS of an access transfer request in respect of the user.

14. Apparatus according to claim 13 and comprising a receiver for receiving the further ATU-STI in a SIP message sent from said redundant SCC-AS.

15. Apparatus configured to implement a Serving Call Session Control Function (S- CSCF) within an IP Multimedia Subsystem (IMS) network implementing a Single Radio Voice Call Continuity function, the apparatus comprising: a memory and memory controller for recording, at IP Multimedia Subsystem (IMS) registration of a user, an ATCF-mgmt-URI being an address of an Access Transfer Control Function (ATCF) serving the user; and

a detector for detecting failure of a SCC-AS serving the user at said S-CSCF and for sending from the S-CSCF to a redundant SCC-AS, said ATCF-mgmt-

URI to enable said redundant SCC-AS to send its address to the ATCF.

16. Apparatus according to claim 15, wherein said detector is configured to detect a failure following receipt by the S-CSCF of a session initiation request sent by said user.

17. Apparatus according to claim 15 or 14, wherein said detector is configured to send the ATCF-mgmt-URI to the redundant SCC-AS in a SIP NOTIFY and in response to receipt of a SIP SUBSCRIBE sent by said redundant SCC-AS.

18. Apparatus configured to implement a Service Centralization and Continuity Application Server (SCC-AS) within an IP Multimedia network implementing a Single Radio Voice Call Continuity function, the apparatus comprising:

a receiver for receiving, from a Serving Call Session Control Function (S- CSCF), Home Subscriber Server (HSS) or other network node, an ATCF-mgmt- URI being an address of an Access Transfer Control Function (ATCF) serving a user;

a memory for storing user data including said ATCF-mgmt-URI; and

a transmitter for sending an Access Transfer Update Session Transfer Identification (ATU-STI) that identifies the SCC-AS, to said ATCF using the received ATCF-mgmt-URI.

19. Apparatus according to claim 18, wherein said receiver is configured to receive said ATCF-mgmt-URI in a SIP SUBSCRIBE message from the S-CSCF.