Content for TS 23.380 Word version: 18.1.0
5.4 HSS-based P-CSCF restoration for 3GPP access
5.4.1 Introduction
5.4.2 Description
5.4.3 PCO-based optional extension
5.4.4 UE indication of support for "Update PDP context/bearer at P-CSCF failure" Restoration
5.4.5 Coexistence with "Update PDP context/bearer at P-CSCF failure" mechanism
5.4.6 HSS based P-CSCF restoration in roaming scenarios
...
...
5.4 HSS-based P-CSCF restoration for 3GPP access |R12| p. 23
5.4.1 Introduction p. 23
The HSS-based P-CSCF restoration described in the clause 5.4 is an optional mechanism which applies when the UE is using a 3GPP access for the IMS PDN connection.
When supported, this mechanism shall be executed when a terminating request cannot be serviced 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 HSS-based P-CSCF restoration consists of a basic mechanism that makes usage of a path through HSS and MME/SGSN to request the release of the IMS PDN connection to the corresponding UE, as described in clause 5.4.2; and an optional extension that avoids the IMS PDN deactivation and re-activation, as described in clause 5.4.3.
5.4.2 Description p. 23
5.4.2.1 General p. 23
The call flow for the HSS-based P-CSCF restoration mechanism is described in Figure 5.4.2.1-1. The nodes included in this call flow shall execute following procedures if they support the HSS-based P-CSCF restoration mechanism.
Step 1.
The terminating S-CSCF receives a SIP message for a destination UE.
Step 2.
The S-CSCF forwards the SIP message to this called UE's terminating P-CSCF.
Step 3.
The S-CSCF shall identify whether the called UE's terminating P-CSCF is not able to process this request, based on received error codes (i.e. the UE registration data is not present) or no response. In this case, the following steps shall apply to execute the HSS-based P-CSCF restoration. For more information about S-CSCF failure detection, see clause 5.4.2.2.
Step 4.
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 5.
- If the Public User Identity is currently registered with only one Private User Identity, the S-CSCF shall unregister this Public User Identity by sending a Cx SAR to the HSS, including a P-CSCF Restoration indication.
- If the Public User Identity is currently registered with more than one Private User Identity, the S-CSCF shall send a deregistration request to the HSS for the corresponding Public User Identity and Private User Identity pair via Cx SAR, including a P-CSCF Restoration indication.
The HSS shall identify whether the MME/SGSN supports HSS-based P-CSCF restoration based on feature support information provided by the MME/SGSN as described in clause 5.4.2.3, then when the HSS receives a Cx SAR with a P-CSCF Restoration indication, it shall check whether the serving node(s) for corresponding user support this feature:
Step 6.
-
if at least one of the serving nodes support the feature:
- the HSS shall send a P-CSCF restoration indication to the supporting serving node(s) where the IMSI associated to the received Private Identity is registered, i.e. SGSN and/or MME, using S6a/S6d IDR/IDA or Gr ISD request/answer; and
- the HSS shall perform either the unregistration or deregistration requested and it shall send a successful response to the S-CSCF via Cx SAA. The S-CSCF shall set respectively this Public User Identity as Unregistered or this UE as not registered.
- in addition, if the 3GPP AAA Server supports P-CSCF restoration for WLAN and if the user has an IMS APN configuration subscription for a WLAN access and is registered to a WLAN access, the procedure described in clause 5.6.2.2 from step 5 onwards shall apply.
- otherwise, the HSS shall provide an error response back in Cx SAA to the S-CSCF.
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, since the S-CSCF is not able to progress the request; otherwise the S-CSCF shall select the best possible response following normal forking procedures.
Subject to an operator policy, the error response sent by S-CSCF may in addition inform the originating side that a terminating request reattempt is possible based on timer expiration.
Step 7.
Upon reception of the P-CSCF Restoration indication from the HSS, the MME/SGSN from the received IMSI shall identify if the MM context of the UE exists and if the UE has an IMS PDN connection context. If either the MM context or the IMS PDN connection context does not exist, the MME/SGSN shall discard the P-CSCF Restoration indication without further processing; otherwise the MME/SGSN shall continue as below.
The MME/SGSN shall check the UE state:
Step 8.
- If the UE is in ECM-IDLE state, the MME/SGSN shall page the UE.
-
If the UE is initially in ECM-CONNECTED state or when it gets a response from the UE after paging:
- If ISR is active, the MME/SGSN shall send a message, via the S3 interface, to stop paging the UE at the other ISR-associated node; and
- The MME/SGSN shall execute the optional PCO-based optional extension to this mechanism as described in clause 5.4.3, if this optional extension is supported by the MME/SGSN and by the serving SGW/PGW; otherwise it shall proceed as below.
- The SGSN, or the MME if this is not the last PDN connection of the UE, shall release the UE's IMS PDN connection towards the UE by initiating a PDN disconnection procedure with the NAS cause "reactivation requested". If this is the last PDN connection of the UE, the MME shall initiate a detach procedure with the NAS cause code "reactivation requested". Additionally, the MME/SGSN shall also release the same PDN connection towards the SGW/PGW by sending Delete Session message (not shown in the Figure).
As a result of the release of the IMS PDN connection, the UE shall activate the IMS PDN connection, select an available P-CSCF and perform a new initial IMS registration, as per TS 29.061.
5.4.2.2 P-CSCF restart/failure detection by S-CSCF p. 25
5.4.2.2.1 General p. 25
If the P-CSCF is not reachable, the S-CSCF does not receive any SIP response when it sends a request. In this case, the S-CSCF shall consider the P-CSCF to be non-reachable. As long as the S-CSCF considers the P-CSCF to be non-reachable, the S-CSCF shall not try to contact again this P-CSCF for subsequent terminating requests. The S-CSCF shall consider the P-CSCF to be reachable as soon as a SIP request, including REGISTER, is received from that P-CSCF.
Various mechanisms can be used for the S-CSCF to detect a non-reachable P-CSCF, e.g. keep-alive mechanisms or expiry of timers.
If the P-CSCF is reachable, but it is not able to process the request, it shall send an error indication to the S-CSCF.
5.4.2.2.2 Direct connection from S-CSCF to P-CSCF p. 25
This is the normal case when the terminating user is not roaming.
When the S-CSCF receives a terminating request towards a UE registered to a P-CSCF that is not considered non-reachable, the S-CSCF shall forward the request to the P-CSCF. If the P-CSCF does not respond, after a pre-defined number of retransmissions, the S-CSCF shall consider the P-CSCF to be non-reachable.
5.4.2.2.3 S-CSCF connection to P-CSCF via IBCF/ATCF p. 25
This is the normal case when the terminating user is roaming and there are IBCFs between the S-CSCF and the P-CSCF. It can also be that an ATCF is inserted between the S-CSCF and the P-CSCF.
In this case, the SIP node closest to the P-CSCF shall identify when the P-CSCF is not reachable. It rejects the request with a SIP error response with an indication that the P-CSCF is not reachable.
5.4.2.3 MME/SGSN mechanism support p. 26
If the MME/SGSN supports this mechanism, it shall indicate support of this feature to the HSS in S6a/S6d ULR. If support is indicated, this information shall be stored by HSS per MME/SGSN.
5.4.3 PCO-based optional extension p. 26
5.4.3.1 Introduction p. 26
The HSS-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.4.4.
5.4.3.2 Description p. 26
This procedure is described by Figure 5.4.3.2-1 (for EPC) and Figure 5.4.3.2-2 (for GPRS). The nodes included in this call flow shall execute following procedures if they support the HSS-based P-CSCF restoration mechanism.
Steps from 1 to 6 are the same as explained in Figure 5.4.2.1-1 above.
Step 7.
The MME/SGSN shall send Modify Bearer Request / Update PDP Context Request to the P-GW/GGSN for this associated PDN connection with a P-CSCF Restoration indication.
The MME/S4 SGSN shall provide this indication to the P-GW via the S-GW. When the Modify Bearer Request is received by the S-GW with the P-CSCF Restoration indication, this message shall be forwarded to the P-GW.
Step 8.
Upon reception of the P-CSCF Restoration indication, the P-GW/GGSN shall check whether the UE has indicated it supports "Update PDP context/bearer at P-CSCF failure" mechanism, as described in clause 5.4.4:
Step 9.
- if supported, the PGW/GGSN shall send Update Bearer Request / Update PDP Context Request to the MME/SGSN with the list of available P-CSCF addresses within PCO IE to update destination UE. The list of available P-CSCFs may contain the address of the P-CSCF used by the UE if this P-CSCF has restarted and is again available.
- if not supported, the P-GW/GGSN shall release the IMS PDN connection/PDP context by sending a Delete Bearer Request / Delete PDP Context Request to the MME/SGSN with GTP cause "reactivation requested".
Upon reception of the Update Bearer Request / Update PDP Context Request, the MME/SGSN shall send an Update EPS Bearer Context Request / Modify PDP Context Request to the UE, including the PCO with the list of available P-CSCF addresses; otherwise, upon reception of a Delete Bearer Request / Delete PDP Context Request, the MME/SGSN shall send a Delete EPS Bearer Context Request / Delete PDP Context Request to the UE with the NAS cause "reactivation requested", then once the PDN connection is released, the UE shall re-activate the IMS PDN connection.
Step 10.
The UE selects an available P-CSCF. If the UE has received a Modify EPS Bearer Context Request / Modify PDP Context Request while the UE does not have any ongoing session then the UE shall select one available P-CSCF from the list for IMS registration and perform a new initial IMS registration.
5.4.4 UE indication of support for "Update PDP context/bearer at P-CSCF failure" Restoration |R16| p. 29
This optional extension is based on the possibility for the P-GW/GGSN to identify whether or not the UE supports "Update PDP context/bearer at P-CSCF failure", as described in clause 5.1 and TS 24.229 (clauses B.2.2.1C and L.2.2.1C).
The UE shall indicate this capability to the P-GW/GGSN at the activation of the IMS PDN connection /PDP context, in the PCO parameter 0012H (P-CSCF Re-selection support) as described in clause 10.5.6.3 of TS 24.008. The P-GW/GGSN shall store this UE capability.
This method has no impact on the MME/SGSN or SGW, as PCO information is transparently transferred through these network elements.
5.4.5 Coexistence with "Update PDP context/bearer at P-CSCF failure" mechanism p. 29
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 HSS-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 HSS-based P-CSCF restoration mechanism in most cases. Hence, if the optional HSS-based P-CSCF restoration is deployed in a network, the recommendation is to only deploy the HSS-based P-CSCF restoration.
5.4.6 HSS based P-CSCF restoration in roaming scenarios p. 29
The considered roaming scenarios are the ones described in clause 4.2.2 of TS 23.401.
For these roaming scenarios, when the VPLMN and the HPLMN both support the HSS based P-CSCF restoration mechanism, this mechanism shall be used for P-CSCF restoration. The HPLMN shall be aware that the VPLMN supports the HSS based P-CSCF restoration mechanism by signalling from the VPLMN. The HPLMN should not trigger a P-CSCF restoration otherwise.
For the roaming scenarios when either the VPLMN or the HPLMN does not support the HSS based P-CSCF restoration mechanism, then the PGW/GGSN which is located in network supporting the HSS based mechanism, depending on operator policy, may apply:
- no P-CSCF restoration mechanism; or
- another existing mechanism e.g. the "Update PDP context/bearer at P-CSCF failure" mechanism described in clause 5.1. The PGW/GGSN shall be aware (e.g. by local configuration) that the HSS based P-CSCF restoration mechanism cannot be used.
