Content for TS 23.380 Word version: 17.1.0

0… 4… 5… 5.2… 5.4… 5.5… 5.6… 5.8… 5.8.4… 5.8.5… 6…

5.5 PCRF-based P-CSCF restoration 5.5.1 Introduction 5.5.2 PCRF-based P-CSCF restoration information flow - deactivate PDN connection/PDP context 5.5.3 PCO-based optional extension 5.5.4 Coexistence with "Update PDP context/bearer at P-CSCF failure" mechanism 5.5.5 P-CSCF restoration in roaming scenarios for PCRF based solution
...

5.5 PCRF-based P-CSCF restoration |R12| p. 30

5.5.1 Introduction p. 30

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 p. 30

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.

Copy of original 3GPP image for 3GPP TS 23.380, Fig. 5.5.2-1: PCRF based P-CSCF restoration

Figure 5.5.2-1: PCRF based P-CSCF restoration
(⇒ copy of original 3GPP image)

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.

Step 1.

The S-CSCF receives a terminating INVITE message.

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

Step 2b.

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

Step 3.

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

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

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

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

Step 6.

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

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

Step 8.

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

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

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

Step 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 p. 33

5.5.3.1 Introduction p. 33

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 p. 33

This procedure is described by Figure 5.4.3.2-1 (for EPC) starting with step 8a and Figure 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 p. 33

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 p. 33

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 p. 33

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:

Both HPLMN and VPLMN support the PCRF based P-CSCF restoration; or
When the HPLMN does not support the PCRF based P-CSCF restoration but VPLMN does and NAT is not performed.

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.