5.5 PCRF-based P-CSCF restoration

23.3803GPPIMS Restoration ProceduresRelease 17TS

5.5.1 Introduction

The PCRF-based P-CSCF restoration is an optional mechanism.

This mechanism is executed when a terminating request does not proceed due to a P-CSCF failure, as long as there are no other registration flows for this terminating UE using an available P-CSCF.

The PCRF-based P-CSCF restoration consists of a basic mechanism that makes usage of a path through an alternative P-CSCF and PCRF to request the release of the IMS PDN connection to the corresponding UE, as described in clause 5.5.2; and an optional extension that avoids the IMS PDN deactivation and re-activation, as described in clause 5.5.3.

5.5.2 PCRF-based P-CSCF restoration information flow – deactivate PDN connection/PDP context

The following figures illustrate the details of PCRF-based P-CSCF restoration information flow.

The nodes included in this call flow shall execute following procedures if they support the PCRF-based P-CSCF restoration mechanism.

Figure 5.5.2-1: PCRF based P-CSCF restoration

This call flow provides two options for termination call being treated.

Option a) makes terminating UE to be deregistered until next re-registration.

Option b) continues terminating call after successful re-IMS registration.

1. The S-CSCF receives a terminating INVITE message.

2a. The S-CSCF shall populate IMSI into the terminating INVITE message. IMSI is maintained in the S-CSCF, which is obtained from HSS when the UE registers. Then the S-CSCF shall forward the Terminating INVITE message to alternative P-CSCF. The alternative P-CSCF is chosen by local configuration.

NOTE 1: The IMSI is used by the alternative P-CSCF to find the associated PCRF associated for the UE. The IMSI information is subtracted in P-CSCF.

2b. The S-CSCF shall populate IMSI into the terminating INVITE message. IMSI is maintained in the S-CSCF, which is obtained from HSS when the UE registers. Then the S-CSCF shall forward the terminating INVITE message to visited network.

2c. If IBCF or ATCF next to the failed P-CSCF has detected the P-CSCF failure, IBCF or ATCF shall forward the terminating INVITE message to alternative P-CSCF. The alternative P-CSCF is chosen by local configuration.

3. The alternative P-CSCF shall send SIP ERROR message to the S-CSCF.

4a. If option a) is chosen, the S-CSCF shall check the registration status of the Public User Identity associated to the called UE. If the registration state of the Public User Identity is registered, the S-CSCF shall check if the Public User Identity is currently registered with one or more Private User Identities.

– If the Public User Identity is currently registered with only one Private User Identity, the S-CSCF shall unregister this Public User Identity sending a Cx SAR/SAA to HSS. If the response is successful, the S-CSCF shall set this Public User Identity as Unregistered.

– If the Public User Identity is currently registered with more than one Private User Identity, the S-CSCF shall send a deregistration to HSS for the corresponding Public User Identity and Private User Identity pair via Cx SAR/SAA. If the response is successful, the S-CSCF shall set this UE as not registered.

NOTE 2: the S-CSCF can start a P-CSCF Restoration Ongoing Timer to monitor the P-CSCF Restoration procedure. If the UE performs the new IMS registration before this timer expires, as a result of the P-CSCF Restoration procedure execution, the S-CSCF stops the timer. Otherwise, the S-CSCF registers again the Public User Identity by sending a Cx SAR to the HSS and it stops the timer. The value of the P-CSCF Restoration Ongoing Timer can consider how long the P-CSCF Restoration execution may take, and then it can take into account factors like paging re-transmission timers.

4b. If option a) is chosen the S-CSCF shall send a SIP response back to the originating side. This shall be an error response if only one Private User Identity is registered; otherwise the S-CSCF shall select the best possible response following normal forking procedures.

5. The alternative P-CSCF shall send an Rx AAR message with the P-CSCF restoration indication to the associated PCRF, the associated PCRF is found by UE’s IP address (if available), IP Domain (if UE’s IP address is provided and IP address overlapping can occur), IMSI and APN. The APN and IP Domain are set based on local configuration and additionally referring to the SDP information, e.g. media field, on the received SIP INVITE message.

NOTE 3: When the UE’s IP address is not available, the P-CSCF has to include both IMSI and APN in the Rx AAR command.

NOTE 4: When IMSI is not available, the associated PCRF for the UE can be found by IP address of the UE with the condition that there is no IP translation function in the P-CSCF.

6. The PCRF shall send an Rx AAA to the P-CSCF

7. The PCRF shall find the IP-CAN session related to that UE based on the available information received in step 5 and shall send a Gx RAR including the P-CSCF restoration indication to the PDN GW/GGSN that has been associated with that IP-CAN session. In case where the alternative P-CSCF is located in the HPLMN and the associated PDN GW/GGSN is located in the VPLMN, in this case both S9 interface and Gx interface are used.

8. The PDN GW/GGSN shall send Gx RAA to the PCRF.

9. Then the PDN GW/GGSN shall perform one of following procedures.

– For 3GPP accesses, the PDN GW/GGSN initiates bearer deactivation procedure for the default bearer with "reactivation requested", if the PDN GW/GGSN has no knowledge whether the UE supports the "Update PDP context/bearer at P-CSCF failure". If the UE supports the "Update PDP context/bearer at P-CSCF failure" mechanism, step 11 and 12 in the procedure that is described in clause 5.1 is reused instead.

NOTE 5: The failed P-CSCF can be included in the new P-CSCF list if it has recovered.

– For the S2a and S2b, the PDN GW initiates bearer deactivation procedure to the trusted non 3GPP access domain and the ePDG, respectively.

– For the S2c, the PDN GW/GGSN initiates detach procedure.

NOTE 6: For the S2a/b/c, it should be noted that although this procedure does not request UE to re-attach to the IMS explicitly by signalling, it is assumed that IMS compliant UE shall re-attempt to obtain IMS service soon after detached from the IMS service.

10. UE activates the PDN connection and registers to IMS. As a result of the release of the IMS PDN connection, the voice centric UE activates the IMS PDN connection, selects a new available P-CSCF and performs a new initial IMS registration.

11. If option b) is chosen, the S-CSCF shall send the suspended terminating SIP INVITE message to a newly selected P-CSCF after the successful SIP registration for the UE.

5.5.3 PCO-based optional extension

5.5.3.1 Introduction

The PCRF-based P-CSCF basic mechanism is optionally extended by reusing part of the "Update PDP context/bearer at P-CSCF failure" mechanism described in clause 5.1, in order to avoid the need to deactivate and reactivate the IMS PDN connection.

This extension is based on the possibility for the P-GW/GGSN to know whether or not the UE supports the "Update PDP context/bearer at P-CSCF failure" mechanism. This is described in clause 5.5.3.3.

5.5.3.2 Description

This procedure is described by figure 5.4.3.2-1 (for EPC) starting with step 8a and 5.4.3.2-2 (for GPRS) starting with step 8. The nodes included in this call flow shall execute following procedures if they support the PCRF-based P-CSCF restoration mechanism.

5.5.3.3 UE indication of support for "Update PDP context/bearer at P-CSCF failure" Restoration

This function is identical to the HSS-based P-CSCF restoration. Refer to 5.4.4.

5.5.4 Coexistence with "Update PDP context/bearer at P-CSCF failure" mechanism

If the "Update PDP context/bearer at P-CSCF failure" mechanism is deployed, as soon as a P-CSCF failure is detected, as described in clause 5.1, it triggers massive radio signalling first and then massive IMS registration. Therefore, the PCRF-based P-CSCF restoration triggering use case does not occur in most cases, and benefits are minimal; i.e., in case of coexistence, the "Update PDP context/bearer at P-CSCF failure" mechanism takes precedence over the PCRF-based P-CSCF restoration mechanism in most cases. Hence, if the optional PCRF-based P-CSCF restoration is deployed in a network, the recommendation is to only deploy the PCRF-based P-CSCF restoration.

5.5.5 P-CSCF restoration in roaming scenarios for PCRF based solution

In a home routed scenario, i.e., S-GW(or any other gateway node) is in VPLMN and P-GW and P-CSCF are in HPLMN, the PCRF based solution can work sorely within HPLMN that supports the PCRF based solution, no matter VPLMN supports the solution or not.

The following procedures only apply to the local breakout scenario.

In roaming scenarios, the VPLMN and HPLMN operators may deploy the same or different P-CSCF restoration mechanisms, amongst those described in clause 5.1 (Update PDP context/bearer at P-CSCF failure), clause 5.4 (HSS based P-CSCF restoration) and clause 5.5 (PCRF based P-CSCF restoration), independently from each other.

The PCRF based P-CSCF restoration can work in roaming scenarios if:

1) Both HPLMN and VPLMN support the PCRF based P-CSCF restoration; or

2) When the HPLMN does not support the PCRF based P-CSCF restoration but VPLMN does and NAT is not performed.

NOTE: If the HPLMN does not support the PCRF based P-CSCF restoration, IMSI may not be available on terminating INVITE message.

Alternatively, based on the operator policy or roaming agreement, the VPLMN can use the "Update PDP context/bearer at P-CSCF failure" mechanism described in clause 5.1.

For a terminating call to outbound roamers, the S-CSCF may not populate IMSI to terminating INVITE message if HPLMN knows, e.g. by configuration in the S-CSCF according to roaming agreements, that VPLMN for outbound roamer does not support the PCRF based P-CSCF restoration.