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