The present invention relates to failure recovery in an IP Multimedia Subsystem network and in particular to a method and apparatus for enabling recovery from failure of a Serving Call Session Control Function.
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media that 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.
The UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). This enables high-data rate packet switch transmissions well beyond the 64 kbps limit of ISDN through the GSM call network, which is a necessity for UMTS data transmission rates of up to 2 Mbps. UMTS is standardised by the 3rd Generation Partnership Project (3GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for a specification of the network architecture.
The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 8). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
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. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS (although other protocols such as Diameter are also used for network signalling).
Specific details of the operation of the UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS that are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.229.
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if an S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. The SIP REGISTER message is forwarded to the selected S-CSCF which adds its identity into the SIP Service-Route header in the 200 OK response. When the P-CSCF receives the 200 OK response from the S-CSCF, it learns the S-CSCF identity from the Service-Route header. When a registered user subsequently sends a SIP request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF. It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated in an S-CSCF. This is referred to as the “terminating” call case. For the terminating call case, S-CSCF allocation is temporary and the UE must subsequently register with the IMS in order to initiate further calls.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Application Servers should be “linked in” during a SIP Session establishment. Different IFCs may be applied to different call cases. The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile. Certain Application Servers will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server). For example, in the case of call forwarding, the appropriate (terminating) application server will determine the new terminating party to which a call to a given subscriber will be forwarded. In the case that an IFC indicates that a SIP message received at the S-CSCF should be forwarded to a particular SIP AS, that AS is added into the message path. Once the SIP message is returned by the AS to the S-CSCF, it is forwarded on towards its final destination, or forwarded to another AS if this is indicated in the IFCs.
Current IMS Core specifications do not include procedures for the recovery to a consistent state after a failure in a network element. Specifically, S-CSCF failure is only considered in the case of initial registration (i.e. if an I-CSCF is unable to contact a selected S-CSCF, it is able to select and alternative). Whilst consideration has been given to this problem (see 3GPP SA2, CT1 and CT4), the solutions proposed have generally suffered from the problem of the potential double assignment of S-CSCFs for the same IMS Subscription and the loss of registration state. A work item covering this failure case has been created and the study requirements are defined in 3GPP TS 23.820 v0.1.0 (C4-070890). It is expected that failure recover will be provided for in TS 29.329 Release 8.
Failures of S-CSCFs can be short term (temporary) or can be long term (permanent). In the case of a permanent failure, the P-CSCF will return an error message (408 timeout) to the UE in the event that no response is received from a selected S-CSCF after a threshold number of reattempts is reached. This is illustrated in
It is an object of the present invention to provide a mechanism for recovering from the failure of an S-CSCF following the allocation of that S-CSCF during IMS registration of the UE. This object is achieved by sending from the P-CSCF to the UE a re-register message which forces the UE to perform a re-registration with the IMS.
According to a first aspect of the present invention there is provided a method of facilitating recovery from the failure of a Serving Call Session Control Function within an IP Multimedia Subsystem network. The method comprises receiving at a Proxy Call Session Control Function a SIP request sent by a User Equipment possessing an identity previously registered with the IP Multimedia Subsystem network and for which a given Serving Call Session Control Function was selected. The Proxy Call Session Control Function determines that said given Serving Call Session Control Function has failed or is otherwise unreachable, and sends a re-registration message to said user equipment, receipt of said re-registration message at the user equipment forcing the user equipment to perform a registration procedure with the IP Multimedia Subsystem network.
Embodiments of the present invention ensure that the failure of an S-CSCF does not result in the loss of IMS service to the user equipment, and ensures that user equipment can respond to an S-CSCF failure in a predictable manner.
Said Proxy Call Session Control Function may include within the re-registration message a delay value, the delay value causing said user equipment to delay initiation re-registration for the specified delay. Alternatively, said Proxy Call Session Control Function may include within the re-registration message a delay value, the delay value causing said user equipment to delay a resending of said SIP request for the specified delay, following successful IP Multimedia Subsystem registration. Both of these approaches will tend to result in the spreading of the signalling load over time, following S-CSCF failure within an IMS network.
According to one embodiment of the invention, the method may comprise receiving said re-registration message at said user equipment and subsequently performing a registration procedure with the IP Multimedia Subsystem network. At said user equipment, an indication that the previously allocated Serving Call Session Control Function has failed (and optionally an identification of the failed Serving Call Session Control Function) can be included within a SIP Register message initiating said registration procedure, thus allowing an Interrogating Call Session Control Function of the IP Multimedia Subsystem network to send a request to a Home Subscriber Server for Serving Call Session Control Function capabilities, said request indicating/identifying the failed Serving Call Session Control Function.
This embodiment has the advantage that repeat signalling between the I-CSCF and the failed S-CSCF can be avoided. The Register request sent by the UE to the I-CSCF immediately results in selection of a new S-CSCF.
According to a second aspect of the present invention there is provided apparatus configured to operate as a Proxy Call Session Control Function within an IP Multimedia Subsystem network. The apparatus comprises:
According to a third aspect of the present invention there is provided apparatus configured to operate as an Interrogating Call Session Control Function within an IP Multimedia Subsystem network. The apparatus comprises:
According to a fourth aspect of the present invention there is provided user equipment configured to provide user access to services facilitated by an IP Multimedia Subsystem network. The user equipment is arranged in use to perform an IP Multimedia Subsystem network registration resulting in allocation of a Serving Call Session Control Function to the user equipment, to send a SIP request towards the IP Multimedia Subsystem network, to receive, as a result of a failure of the allocated Serving Call Session Control Function, a re-register message from a Proxy Call Session Control Function, and to respond to receipt of said re-register message by performing a re-registration with the IP Multimedia Subsystem network.
It will be appreciated that the existing mechanisms provide for the recovery from an S-CSCF failure during a registration procedure. It will also be appreciated that recovery from a failure during a terminating call case is already provided for as the I-CSCF is necessarily included within the SIP request path. In the following, the problem of recovering from an S-CSCF failure during an originating call case is addressed.
Referring to the signalling diagram of
It is proposed here to add to the relevant IMS standard (3GPP TS 24.229) a new SIP error response, referred to here as SIP “Re-Register”. Upon detection by the P-CSCF that the S-CSCF is unavailable [using one of the mechanisms a) to e) above], the P-CSCF returns the new error response to the UE (step 3). Receipt of the error response at the UE causes the UE to initiate a repeat registration procedure. Assuming implementation of currently specified procedures at the I-CSCF, re-registration will almost certainly cause the I-CSCF to select once again the same failed S-CSCF. However, in the absence of a response from that S-CSCF, the ICSCF will select an alternative S-CSCF and registration will proceed. The newly selected S-CSCF may recover data associated with the UE and lost by the failed S-CSCF.
The P-CSCF may optionally include within the Re-register response an indication to the UE to initiate the new registration with a given delay, possibly defining the delay or a delay range. This provides a mechanism for the P-CSCF to spread the load of incoming SIP requests towards the network and to avoid signalling overloads in the case of major network failures. Another option for similar situations proposed here is for the P-CSCF to be able to add an indication to UE to delay re-attempt of the SIP INVITE (or other request) following re-registration.
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, as a UE can implicitly learn from receipt of a Re-register SIP message that the previously allocated S-CSCF has failed, it could include in the Register request an indication that the S-CSCF has failed. The I-CSCF may use this indication to directly reselect a new S-CSCF, avoiding the need for the I-CSCF to send the request to the failed S-CSCF in the first instance.
Number | Date | Country | Kind |
---|---|---|---|
PCT/EP2007/060324 | Sep 2007 | EP | regional |
This application claims priority on PCT International Application No. PCT/EP2007/060324 filed Sep. 28, 2007, the disclosure of which is fully incorporated herein by reference.