Use cases for ePDG P-CSCF restoration support
This section describes solutions to support P-CSCF restoration for UEs with WLAN access.
There are two existing mechanisms to handle the P-CSCF restoration support as there are with E-UTRAN access.
-
The basic mechanism for the HSS-based solution and for the PCRF-based solution relies on the release of the PDN connection followed by its re-establishment to trigger a new IMS registration by the UE
-
The extension mechanism untrusted WLAN accesses to avoid the release of the PDN connection and to trigger a new IMS registration by the UE over the existing PDN connection. The extensions between the UE and the PGW are common for the HSS-based and for the PCRF-based solutions and rely on the same UE behavior
Basic PCSCF Restoration Support For an untrusted WLAN access, on S2b interface the PGW initiates a Delete Bearer Request procedure (GTP) or a Proxy Mobile IPv6 LMA Initiated PDN Connection Deletion procedure (PMIP) to the ePDG which then initiates the release of the associated IKEv2 tunnel.
A cause "reactivation requested" (as supported over 3GPP accesses) is added by the PGW over GTP-C based S2b and IKEv2 for untrusted WLAN
As a result of the release of the IMS PDN connection, the UE re-establishes the IMS PDN connection, and also perform a new P-CSCF discovery (as the IMS PDN connection was lost). After discovering a new P-CSCF, the UE will perform a new initial IMS registration towards IMS.
Extended PCSCF Restoration Support An ePDG which supports the P-CSCF restoration extension for untrusted WLAN forwards the UE capability (i.e. UE support of the P-CSCF restoration extension) in the APCO information element to the PGW over the S2b interface at the PDN connection establishment (or handover) over S2b.  Note |
The receipt by the PGW of the UE capability indicating the support of P-CSCF restoration for the untrusted WLAN access at the PDN connection establishment (or handover) over the untrusted WLAN access serves also as an indication that the ePDG supports this procedure.
|
In the P-CSCF restoration extension procedure for untrusted WLAN access, the PGW sends the updated list of the addresses of available P-CSCFs towards the UE via the ePDG, using the APCO IE in Update Bearer Request message. Same will be communicated to UE via Configuration payload in Information request message.
Flows
Basic Restoration Mechanism
HSS-based/PCRF-based basic mechanisms displayed in the below is based on the same principles i.e to disconnect the UE when P-CSCF failure is detected, which then re-establishes the connection via an alternate available P-CSCF.
Both the mechanisms have the same effect in ePDG, which will be handling PGW initiated Delete Bearer Request procedure (GTP) with cause "reactivation requested" (as supported over 3GPP accesses) and then translate it over IKEv2 (SWu) INFORMATIONAL request message containing DELETE payload with REACTIVATION_REQUESTED_CAUSE Notify payload towards UE resulting in deactivation.
After deactivation it is up to the UE to re-establish a new IMS PDN connection and performs a new P-CSCF discovery. Figure 1. HSS based basic P-CSCF restoration for WLAN
Extended Restoration Mechanism
This mechanism aims to avoid the IMS PDN deactivation and re-activation, by introducing a update procedure to inform the UE about the change in P-CSCF address. This triggers the UE to initiate a new IMS registration towards an available P-CSCF over the existing IMS PDN connection.
Extended Restoration Mechanism has the following phases:
The UE which supports the P-CSCF restoration extension for the untrusted WLAN access, sends PCSCF_RESELECTION_SUPPORT notify payload to the ePDG in the IKEv2 message (IKE-AUTH) during establishment (or handover) of the IMS PDN connection over the untrusted WLAN access.
Upon receiving the UE capability, the P-CSCF restoration extension for untrusted WLAN supporting ePDG will forward the same in the APCO information element to the PGW over the S2b interface in Create Session Request. Figure 2. PCRF Based Extended P-CSCF Restoration for Un-Trusted WLAN Access
In case of Extenstion P-CSCF restoration
-
If both UE and ePDG support P-CSCF restoration and PGW was updated of this support in Create Session Request, the PGW will send an Update Bearer Request (as described in 3GPP TS 29.274 [10]) to the ePDG including the APCO information element set with a list of available P-CSCFaddresses.
-
The ePDG will initiate an IKEv2 informational exchange procedure ( as described in 3gpp 24.302) towards the UE to forward the list of available P-CSCF addresses received from the PGW.
-
The UE will send a response to the ePDG which then sends an Update Bearer Response to the PGW.
Detailed Description
Capability support for a subscriber .
UE will share its P-CSCF restoration capability in 1st IKE_auth.
(First IKE AUTH request from Initiator)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(P-CSCF_RESELECTION_SUPPORT) } -----> ePDG
As part of this feature enhancement, the following new Private Notify Message status types will be supported.
Notify Message
|
Value (in decimal)
|
Descriptions
|
REACTIVATION_REQUESTED_CAUSE
|
40961
|
The IPsec tunnel associated to a PDN connection is released with a cause requesting the UE to reestablish the IPsec tunnel for the same PDN Connection after its release.
|
P-CSCF_RESELECTION_SUPPORT
|
41304
|
This status when present indicates that the UE supports the P-CSCF restoration extension for untrusted WLAN
|
P-CSCF_RESELECTION_SUPPORT Notify payload
The P-CSCF_RESELECTION_SUPPORT Notify payload is used to indicate the support by the UE of the P-CSCF restoration extension for untrusted WLAN.
The P-CSCF_RESELECTION_SUPPORT Notify payload is coded according to below figures.
Protocol id: Set to 0
SPI Size: Set to 0
Notify Message type: The Notify Message Type field is set to value 41304 to indicate the P-CSCF_RESELECTION_SUPPORT
Important: -From Rel 13, 3gpp started using IANA number for notify payloads which belong to private range. For features, which configure notify-status-value from private range can lead to collision and operator will have to be careful while configuring non-collision numbers.
RFC 4306 IKEv2 Private Use Status Range - integer 40960 to 65535.
This can have conflict with above Notify 3gpp standard value, one should configure it carefully.
Message
|
IE
|
Descriptions
|
Delete Bearer Request
|
CAUSE
|
cause "reactivation requested" is sent over GTP-C based S2b during deactivation of IMS session in basic mechanism of P-CSCF restoration. This cause will come in Delete bearer request for default bearer. Value is 8
|
Create Session Request
|
APCO
|
Additional Parameter List : container identifier 0012H (P-CSCF Re-selection support);
When the container identifier indicates P-CSCF Re-selection support, the container identifier contents field is empty and the length of container identifier contents indicates a length equal to zero. If the container identifier contents field is not empty, it shall be ignored. This PCO parameter may be present only if a container with P-CSCF IPv4 Address Request or P-CSCF IPv6 Address Request is present.
|
Update Bearer Request
|
APCO
|
Additional Parameter List : container identifier 0001H (P-CSCF IPv6 Address) or 000CH (P-CSCF IPv4 Address) or both.
|
Capability support on ePDg for said subscriber session:
During the set up (or handover) of the PDN connection, the ePDG should indicate capability to support the extended P-CSCF restoration using PCO/APCO.
Following Container ID is used for P-CSCF Re-Selection support indication (PCO/APCO):
0012H (P-CSCF Re selection support)
External Interfaces
S2b Interface:
Support of Additional Parameter list
0012H: MS->N/w IE: APCO: P-CSCF Re-selection support
0001H: N/w->MS IE: APCO: P-CSCF IPv6 Address
000CH: N/w->MS IE: APCO: P-CSCF IPv4 Address
Cause code: 8 Reactivation Requested
SWu:
Notify payload:
40961: REACTIVATION_REQUESTED_CAUSE
41304: P-CSCF_RESELECTION_SUPPORT