7 Tunnel management procedures

24.3023GPPAccess to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networksRelease 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1 General

The purpose of tunnel management procedures is to define the procedures for establishment or disconnection of an end-to-end tunnel between the UE and the ePDG. The tunnel establishment procedure is always initiated by the UE, whereas the tunnel disconnection procedure can be initiated by the UE or the ePDG.

The tunnel is an IPsec tunnel (see IETF RFC 4301 [30]) established via an IKEv2 protocol exchange IETF RFC 7296 [28] between the UE and the ePDG. The UE may indicate support for IETF RFC 4555 [31]. The security mechanisms for tunnel setup using IPsec and IKEv2 are specified in 3GPP TS 33.402 [15].

7.2 UE procedures

7.2.1 Selection of the ePDG

7.2.1.1 General

If the UE does not supports ePDG selection according to 3GPP TS 24.502 [77], the UE performs ePDG selection based on the ePDG configuration information configured by the home operator in the UE either via H-ANDSF or via USIM or via implementation specific means. Implementation specific means apply only if the configurations via H-ANDSF and USIM are not present. The ePDG configuration information may consist of home ePDG identifier or ePDG selection information or both:

– when available in ANDSF MO, the ePDG configuration information is provisioned in ePDG node under Home Network Preference as specified in 3GPP TS 24.312 [13]; and

– when available in USIM, the ePDG configuration information is provisioned in EF_ePDGId and EF_{ePDGSelection} files as specified in 3GPP TS 31.102 [45].

The ePDG configuration information provided by ANDSF may also be pre-configured by the home operator on the ME or provisioned on the UICC. The UE shall use the information in the following order of precedence:

1) ePDG configuration information provided by the ANSDF server to the ME;

2) ePDG configuration information configured on the UICC;

3) ePDG configuration information pre-configured on the ME.

The UE shall support the implementation of standard DNS mechanisms in order to retrieve the IP address(es) of the ePDG. The input to the DNS query is an ePDG FQDN as specified in clause 4.4.3 and in 3GPP TS 23.003 [3].

If the UE supports ePDG selection according to 3GPP TS 24.502 [77], then the UE selects the ePDG according to 3GPP TS 24.502 [77].

7.2.1.2 Determination of the country the UE is located in

If the UE cannot determine whether it is located in the home country or in a visited country, as required by the ePDG selection procedure specified in 3GPP TS 23.402 [6], the UE shall stop the ePDG selection.

NOTE: It is out of scope of the present specification to define how the UE determines whether it is located in the home country or in a visited country or in a location that does not belong to any country. When the UE is in coverage of a 3GPP RAT, it can, for example, use the information derived from the available PLMN(s). In this case, the UE can match the MCC of the PLMN to which a cell belongs, broadcast on the BCCH of the 3GPP access, against the UE’s IMSI to determine if they belong to the same country, as defined in 3GPP TS 23.122 [4]. If the UE is not in coverage of a 3GPP RAT, the UE can use other techniques, including user-provided location.

7.2.1.3 Handling of ePDG selection based on the country the UE is located in

The UE shall proceed as follows:

1) if the UE is located in its home country and

a) if the ePDG selection information is provisioned in the ePDG configuration information and if an entry for the HPLMN is available in the ePDG selection information, the UE shall construct an ePDG FQDN based on configured FQDN format of HPLMN as described in 3GPP TS 23.402 [6] and encoding in 3GPP TS 23.003 [3]:

b) if the ePDG selection information is not provisioned in the ePDG configuration information or if the ePDG selection information is provisioned and an entry for the HPLMN is not available in the ePDG selection information, the UE shall:

i) if Home ePDG identifier is provisioned in the ePDG configuration information, use the configured IP address to select the ePDG, or if configured IP address is not available, construct an ePDG FQDN using the configured FQDN; and

ii) if the Home ePDG identifier is not provisioned in the ePDG configuration information, construct an ePDG FQDN based on the Operator Identifier FQDN format using the PLMN ID of the HPLMN as described in 3GPP TS 23.003 [3];

c) if the ePDG configuration information is not configured on the UE, or the ePDG configuration information is configured but empty, the UE shall construct the ePDG FQDN based on the Operator Identifier FQDN format using the PLMN ID of the HPLMN stored on the USIM; and

d) If the ePDG selection is for establishing emergency bearer services and the UE is not equipped with a UICC, the UE may construct the Operator Identifier FQDN format based on a PLMN ID obtained via implementation specific means,

and for the cases a) through d), the UE shall use the DNS server function to resolve the contructed ePDG FQDN to the IP address(es) of the ePDG(s). The UE shall select an IP address of an ePDG with the same IP version as its local IP address;

2) if the UE is not located in its home country and

a) if the ePDG selection information is provisioned in the ePDG configuration information and if the UE is attached to a VPLMN via 3GPP access:

i) if an entry for the VPLMN is available in the ePDG selection information, the UE shall construct an ePDG FQDN based on configured FQDN format of the VPLMN as described in 3GPP TS 23.402 [6] and encoding in 3GPP TS 23.003 [3];

ii) if an entry for the VPLMN is not available in the ePDG selection information, and an ‘Any_PLMN’ entry is available in the ePDG selection information, the UE shall construct an ePDG FQDN based on the configured FQDN format of the ‘Any_PLMN’ entry as described in 3GPP TS 23.402 [6] and encoding in 3GPP TS 23.003 [3],

and for case i) and ii), the UE shall use the DNS server function to resolve the contructed ePDG FQDN to the IP address(es) of the ePDG(s). The UE shall select an IP address of an ePDG with the same IP version as its local IP address; and

b) if one of the following is true:

– the UE is not attached to a PLMN via 3GPP access and the UE uses WLAN;

– the ePDG configuration information is not configured;

– the ePDG selection information is not provisioned in the ePDG configuration information; or

– the UE is attached to a VPLMN via 3GPP access and an entry for the VPLMN is not available in the ePDG selection information and an ‘Any_PLMN’ entry is not available in the ePDG selection information,

the UE shall perform a DNS query (see 3GPP TS 23.003 [3]) as specified in clause 7.2.1.4 to determine if the visited country mandates the selection of ePDG in this country:

i) if selection of ePDG in visited country is mandatory:

– if the UE is attached to a VPLMN via 3GPP access and the PLMN ID of VPLMN is included in one of the returned DNS records, the UE shall select an ePDG in this VPLMN by constructing an ePDG FQDN based on the Operator Identifier FQDN format using the PLMN ID of the VPLMN as described in 3GPP TS 23.003 [3]; and

– if the UE is not attached to a PLMN via 3GPP access or the UE is attached to a VPLMN via 3GPP access and the PLMN ID of VPLMN is not included in any of the DNS records:

– if the ePDG selection information is provisioned, the UE shall select an ePDG from a PLMN included in the DNS response that has highest PLMN priority (see 3GPP TS 24.312 [13]) in the ePDG selection information and construct an ePDG FQDN based on the configured FQDN format of the PLMN entry as described in 3GPP TS 23.402 [6] and encoding in 3GPP TS 23.003 [3]; and

– if the ePDG selection information is not provisioned or the ePDG selection information does not contain any of the PLMNs in the DNS response, selection of the PLMN is UE implementation specific. The UE shall select an ePDG from a PLMN included in the DNS response and construct an ePDG FQDN based on the Operator Identifier FQDN format using the PLMN ID of the PLMN as described in 3GPP TS 23.003 [3],

and for the above cases, the UE shall use the DNS server function to resolve the contructed ePDG FQDN to the IP address(es) of the ePDG(s). The UE shall select an IP address of an ePDG with the same IP version as its local IP address;

ii) if the DNS response contains no records, selection of ePDG in visited country is not mandatory:

– if the ePDG selection information is provisioned and contains one or more PLMNs in the visited country, the UE shall select an ePDG from a PLMNs that has highest PLMN priority (see 3GPP TS 24.312 [13]) in the ePDG selection information;

– if the ePDG selection information is not provisioned or if the ePDG selection information is provisioned and contains no PLMNs in the visited country, the UE shall select an ePDG in the HPLMN as follows:

– if the Home ePDG identifier is provisioned in the ePDG configuration information (see 3GPP TS 24.312 [13]), the UE shall use the configured IP address to select the ePDG, or if configured IP address is not available, use the configured FQDN and run DNS query to obtain the IP address(es) of the ePDG(s); and

– if the Home ePDG identifier is not provisioned in the ePDG configuration information, the UE shall construct an ePDG FQDN based on the Operator Identifier FQDN format using the PLMN ID of the HPLMN as described in 3GPP TS 23.003 [3], and

– if the ePDG selection is for establishing emergency bearer services and the UE is not equipped with a UICC, the UE may construct the Operator Identifier FQDN format based on a PLMN ID obtained via implementation specific means.

iii) if no DNS response is received, the UE shall terminate the ePDG selection procedure.

If selecting an ePDG in the HPLMN fails, and the selection of ePDG in the HPLMN is performed using Home ePDG identifier configuration and there are more pre-configured ePDGs in the HPLMN, the UE shall repeat the tunnel establishment attempt using the next FQDN or IP address(es) of the ePDG in the HPLMN.

Upon reception of a DNS response containing one or more IP addresses of ePDGs, the UE shall select an IP address of ePDG with the same IP version as its local IP address. If the UE does not receive a response to an IKE_SA_INIT request message sent towards to any of the received IP addresses of the selected ePDG, then the UE shall repeat the ePDG selection as described in this clause, excluding the ePDG for which the UE did not receive a response to the IKE_SA_INIT request message.

NOTE 1: The time the UE waits before reattempting access to another ePDG or to an ePDG that it previously did not receive a response to an IKE_SA_INIT request message, is implementation specific.

The UE shall select only one ePDG also in case of multiple PDN connections.

7.2.1.4 Determine if the visited country mandates the selection of ePDG in this country

In order to determine if the visited country mandates the selection of ePDG in this country (see 3GPP TS 23.402 [6]), the UE shall perform the DNS NAPTR query using Visited Country FQDN as specified in 3GPP TS 23.003 [3].

If the result of this query is:

– a set of one or more records containing the service instance names of the form "epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org", the UE shall determine thst the visited country mandates the selection of the ePDG in this country; and

NOTE: The (<MCC>, <MNC>) pair in each record represents PLMN Id (see 3GPP TS 23.003 [3]) in the visited country which can be used for ePDG selection in clause 7.2.1.3.

– no records containing the service instance names of the form "epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org", the UE shall determine that the visited country does not mandate the selection of the ePDG in this country.

7.2.1A Selection of the ePDG for emergency bearer services

The UE performs ePDG selection for emergency bearer services based on the ePDG configuration information provided by the home operator in the UE via H-ANDSF or via USIM, or via implementation specific means.

The ePDG configuration information used for selecting the ePDG for emergency bearer services includes:

– when available in ANDSF MO, Emergency_ePDG_Identifier and ePDG selection information are provisioned in ePDG node under Home Network Preference as specified in 3GPP TS 24.312 [13]; and

– when available in the USIM, the Emergency ePDG Identifier and ePDG selection information are provisioned in EF_ePDGIdEm and EF_{ePDGSelection} files as specified in 3GPP TS 31.102 [45].

NOTE: Implementation specific means apply only if the configurations via H-ANDSF and USIM are not present.

When performing ePDG selection for establishing emergency bearer services, the UE shall proceed by following the general ePDG selection procedure specified in clause 7.2.1 except:

– Emergency_ePDG_Identifier shall be used instead of Home ePDG identifier;

– All ePDG FQDNs and visited country FQDNs for DNS query shall be constructed based on the ePDG FQDN format defined for emergency services as defined in 3GPP TS 23.003 [3]; and

– If the ME is not equipped with a UICC, the UE shall consider the ePDG configuration information as not available.

7.2.2 Tunnel establishment

7.2.2.1 Tunnel establishment accepted by the network

Once the ePDG has been selected, the UE shall initiate the IPsec tunnel establishment procedure using the IKEv2 protocol as defined in IETF RFC 7296 [28] and 3GPP TS 33.402 [15].

The UE shall send an IKE_SA_INIT request message to the selected ePDG in order to setup an IKEv2 security association. Upon receipt of an IKE_SA_INIT response, the UE shall send an IKE_AUTH request message to the ePDG, including:

– The type of IP address (IPv4 address or IPv6 prefix or both) that needs to be configured in an IKEv2 CFG_REQUEST Configuration Payload. If the UE requests for both IPv4 address and IPv6 prefix, the UE shall send two configuration attributes in the CFG_REQUEST Configuration Payload: one for the IPv4 address and the other for the IPv6 prefix;

– The "IDr" payload, containing the APN in the Identification Data, for non-emergency session establishment. For emergency session establishment, the UE shall format the "IDr" payload according to clause 7.2.5. The UE shall set the ID Type field of the "IDr" payload to ID_FQDN as defined in IETF RFC 7296 [28]. The UE indicates a request for the default APN by omitting the "IDr" payload, which is in accordance with IKEv2 protocol as defined in IETF RFC 7296 [28]; and

– The "IDi" payload containing the NAI.

The IKE_AUTH request message may also contain:

– An indication in a notify payload that MOBIKE is supported by the UE;

– The INTERNAL_IP6_DNS or the INTERNAL_IP4_DNS attribute in the CFG_REQUEST Configuration Payload. The UE can obtain zero or more DNS server addressed in the CFG_REPLY payload within the IKE_AUTH response message as specified in IETF RFC 7296 [28]; or

– The P_CSCF_IP6_ADDRESS attribute, the P_CSCF_IP4_ADDRESS attribute or both in the CFG_REQUEST Configuration Payload. The UE can obtain zero or more P-CSCF server addresses in the CFG_REPLY Configuration Payload within the IKE_AUTH response message as specified in IETF RFC 7651 [64].

The UE may support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2. If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute, the UE shall include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute indicating support of receiving timeout period for liveness check in the CFG_REQUEST configuration payload within the IKE_AUTH request message. If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 indicating the timeout period for the liveness check is included in the CFG_REPLY configuration payload within the IKE_AUTH response message or if the UE has a pre-configured timeout period, the UE shall perform the tunnel liveness checks as described in clause 7.2.2A.

NOTE 1: The timeout period for liveness check is pre-configured in the UE in implementation-specific way.

If the UE supports N1 mode and N1 mode capability is enabled, the UE shall indicate the PDU session ID in the IKE_AUTH request message during the IKEv2 authentication and tunnel establishment for initial attach.

If the UE supports N1 mode and N1 mode capability is disabled, the UE may indicate the PDU session ID in the IKE_AUTH request message during the IKEv2 authentication and tunnel establishment for initial attach.

If the UE supports N1 mode, regardless whether the N1 mode capability is enabled or disabled, the UE shall indicate the PDU session ID in the IKE_AUTH request message during the IKEv2 authentication and tunnel establishment for handover of an existing PDN connection from EPS which the PDU session ID is associated with, or for transferring of an existing PDU session from 5GS.

If the UE supports N1 mode, regardless whether the N1 mode capability is enabled or disabled, the UE shall not indicate the PDU session ID in the IKE_AUTH request message during the IKEv2 authentication and tunnel establishment for handover of a PDN connection which no PDU session ID is associated with.

In order to indicate the PDU session ID in the IKE_AUTH request message, the UE shall include the N1_MODE_CAPABILITY Notify payload as defined in clause 8.2.9.15 in the IKE_AUTH request message and shall:

– if the UE is establishing a PDN connection not related to any existing PDU session or any existing PDN connection, allocate a PDU session ID which is not currently being used by another PDU session over either 3GPP access or non-3GPP access, set the PDU Session ID field of the N1_MODE_CAPABILITY Notify payload to the allocated PDU session ID, and associate the allocated PDU session ID with the PDN connection that is being established;

if the UE is transferring an existing PDU session from 5GS, set the PDU Session ID field of the N1_MODE_CAPABILITY Notify payload to the PDU session ID of the existing PDU session that is being transferred, and associate the PDU session ID with the PDN connection that is being established. If the existing PDU session is a non-emergency PDU session, the UE shall in addition associate the S-NSSAI of the existing PDU session that is being transferred and the related PLMN ID with the PDN connection that is being established; or

– if the UE is transferring an existing PDN connection from EPS and a PDU session ID is associated with the PDN connection that is being transferred, set the PDU Session ID field of the N1_MODE_CAPABILITY Notify payload to the PDU session ID associated with the existing PDN connection. If the existing PDN connection is a non-emergency PDN connection and an S-NSSAI and a related PLMN ID are associated with the existing PDN connection, the UE shall in addition associate the S-NSSAI and the related PLMN ID with the PDN connection that is being established.

During the IKEv2 authentication and security association establishment, if the UE supports explicit indication about the supported mobility protocols, it shall provide the indication as described in clause 6.3.

During the IKEv2 authentication and tunnel establishment for initial attach, the UE shall provide an indication about Attach Type, which indicates Initial Attach. To indicate attach due to initial attach, the UE shall include either the INTERNAL_IP4_ADDRESS or the INTERNAL_IP6_ADDRESS attribute or both in the CFG_REQUEST Configuration Payload within the IKE_AUTH request message. The INTERNAL_IP4_ADDRESS shall contain no value and the length field shall be set to 0. The INTERNAL_IP6_ADDRESS shall contain no value and the length field shall be set to 0.

During the IKEv2 authentication and tunnel establishment for handover, the UE not supporting IP address preservation for NBM shall indicate Initial Attach as described in the previous paragraph.

NOTE 2: The UE cannot handover PDN connection with PDN type "Ethernet" or "non-IP" from E-UTRAN to an ePDG because PDN connections with PDN type "Ethernet" or PDN type "non-IP" are not supported over ePDG.

During the IKEv2 authentication and security association establishment for handover, the UE supporting IP address preservation for NBM, shall provide an indication about Attach Type, which indicates Handover Attach. During the IKEv2 authentication and security association establishment for transfer of an existing PDU session from 5GS, the UE shall provide an indication about Attach Type, which indicates Handover Attach. To indicate attach due to handover, the UE shall include the previously allocated home address information during the IPSec tunnel establishment. Depending on the IP version, the UE shall include either the INTERNAL_IP4_ADDRESS or the INTERNAL_IP6_ADDRESS attribute or both in the CFG_REQUEST Configuration Payload within the IKE_AUTH request message to indicate the home address information which is in accordance with IKEv2 protocol as defined in IETF RFC 7296 [28]. If the previously allocated home address information consists of both an IPv4 address and an IPv6 prefix, then the UE shall include the INTERNAL_IP4_ADDRESS attribute and the INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST configuration payload within the IKE_AUTH request message. If the previously allocated home address information consists of an IPv4 address only, then the UE shall include the INTERNAL_IP4_ADDRESS attribute and shall not include the INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST configuration payload within the IKE_AUTH request message. If the previously allocated home address information consists of an IPv6 prefix only, then the UE shall include the INTERNAL_IP6_ADDRESS attribute and shall not include the INTERNAL_IP4_ADDRESS attribute in the CFG_REQUEST configuration payload within the IKE_AUTH request message. The UE shall support IPSec ESP (see IETF RFC 4303 [32]) in order to provide secure tunnels between the UE and the ePDG as specified in 3GPP TS 33.402 [15].

The UE may support multiple authentication exchanges in the IKEv2 protocol as specified in IETF RFC 4739 [49] in order to support authentication and authorization with an external AAA server allowing the UE to support PAP authentication procedure, or CHAP authentication procedure, or both, as described in 3GPP TS 33.402 [15].

If NBM is used and the UE wishes to access an external PDN and therefore needs to perform authentication and authorization with an external AAA server, the UE shall:

– If the IKE_SA_INIT response contains a "MULTIPLE_AUTH_SUPPORTED" Notify payload, then include a "MULTIPLE_AUTH_SUPPORTED" Notify payload in the IKE_AUTH request as described in IETF RFC 4739 [49] and perform the additional authentication steps as specified in 3GPP TS 33.402 [15]; and

– If the IKE_SA_INIT response does not contain a "MULTIPLE_AUTH_SUPPORTED" Notify payload, then perform the UE initiated disconnection as defined in clause 7.2.4.1. The subsequent UE action is implementation dependent (e.g. select a new ePDG).

After the successful authentication with the 3GPP AAA server, the UE receives from the ePDG an IKE_AUTH response message containing a single CFG_REPLY Configuration Payload including the assigned remote IP address information (IPv4 address or IPv6 prefix) as described in clause 7.4.1. Depending on the used IP mobility management mechanism the following cases can be differentiated:

– If DSMIPv6 is used for IP mobility management, the UE configures a remote IP address based on the IP address information contained in the INTERNAL_IP4_ADDRESS or INTERNAL_IP6_SUBNET attribute of the CFG_REPLY Configuration Payload. The UE uses the remote IP address as Care-of-Address to contact the HA.

– If NBM is used for IP mobility management and the UE performs an initial attach, the UE configures a home address based on the address information from the CFG_REPLY Configuration Payload. Otherwise, if NBM is used and the UE performs a handover attach, the UE continues to use its IP address configured before the handover, if the address information provided in the CFG_REPLY Configuration Payload does match with the UE’s IP address configured before the handover. If the UE’s IP address (IPv4 address or IPv6 prefix) does not match with the address information of the CFG_REPLY Configuration Payload, the UE shall configure a new home address based on the IP address information contained in the INTERNAL_IP4_ADDRESS, INTERNAL_IP6_SUBNET or INTERNAL_IP6_ADDRESS attribute of the CFG_REPLY Configuration Payload. In the latter case, the IP address preservation is not possible.

NOTE 3: In case of IPv6 address, the UE performs the match only on the IPv6 prefix provided within the CFG_REPLY Configuration Payload contained in the INTERNAL_IP6_SUBNET or INTERNAL_IP6_ADDRESS.

If the UE receives a PDN_TYPE_IPv4_ONLY_ALLOWED Notify payload or a PDN_TYPE_IPv6_ONLY_ALLOWED Notify payload, then the UE shall not subsequently initiate another UE requested PDN connectivity procedure specific to the non-3GPP access to the same APN to obtain a PDN type different from the one allowed by the network until:

– the UE is switched off;

– the UICC containing the USIM is removed; or

– the network initiated the deactivation of the PDN connectivity to the given APN.

If the UE supports DSMIPv6, the UE may request the HA IP address(es), by including a corresponding CFG_REQUEST Configuration Payload containing a HOME_AGENT_ADDRESS attribute within the IKE_AUTH request message. The HOME_AGENT_ADDRESS attribute content is defined in clause 8.2.4.1. The HA IP address(es) requested in this attribute are for the APN for which the IPsec tunnel with the ePDG is set-up. In the CFG_REQUEST within the IKE_AUTH request message, the UE sets respectively the IPv6 address field and the optional IPv4 address field of the HOME_AGENT_ADDRESS attribute to 0::0 and to 0.0.0.0. If the UE can not obtain the IP addresses of the HA via IKEv2 signalling, it uses the home agent address discovery as specified in 3GPP TS 24.303 [11].

In case the UE wants to establish multiple PDN connections and if the UE uses DSMIPv6 for mobility management, the UE shall use DNS as defined in 3GPP TS 24.303 [11] to discover the HA IP address(es) for the additional PDN connections after IKEv2 security association was established to the ePDG.

During the IKEv2 authentication and security association establishment, following the UE’s initial IKE_AUTH request message to the ePDG, if the UE subsequently receives an IKE_AUTH response message from the ePDG containing the EAP-Request/AKA-Challenge, after verifying the received authentication parameters and successfully authenticating the ePDG as specified in 3GPP TS 33.402 [15], the UE shall send a new IKE_AUTH request message to the ePDG including the EAP-Response/AKA-Challenge. In addition, the UE shall provide the requested mobile device identity if available, as specified in clause 7.2.6.

If the UE supports P-CSCF restoration extension for untrusted WLAN as specified in 3GPP TS 23.380 [66], the UE shall send its capability indication of the support of P-CSCF restoration to the ePDG by including the P-CSCF_RESELECTION_SUPPORT Notify payload within an IKE_AUTH request message. The content of the P-CSCF_RESELECTION_SUPPORT Notify payload is described in clause 8.2.9.4.

If:

– the UE supports N1 mode; or

– N1 mode capability is disabled and the UE indicated the PDU session ID in the IKE_AUTH request message;

and the UE receives the N1_MODE_INFORMATION Notify payload as defined in clause 8.2.9.16 in the IKE_AUTH response message, the UE shall delete the associated S-NSSAI, if any, and (re‑)associate the S-NSSAI in the S-NSSAI Value field of the N1_MODE_INFORMATION Notify payload with the PDU session associated with the IKEv2 security association that was established, and if the UE receives the N1_MODE_S_NSSAI_PLMN_ID Notify payload as defined in clause 8.2.9.17 in the IKE_AUTH response message, the UE shall delete the associated PLMN ID, if any, and (re-)associate the PLMN ID that the S-NSSAI relates to in the S-NSSAI PLMN ID field of the N1_MODE_S_NSSAI_PLMN_ID Notify payload with the PDU session associated with the IKEv2 security association that was established.

7.2.2.2 Tunnel establishment not accepted by the network

If the UE receives the IKE_AUTH response message from an ePDG of the HPLMN including a Notify payload with a Private Notify Message Type NON_3GPP_ACCESS_TO_EPC_NOT_ALLOWED or USER_UNKNOWN or PLMN_NOT_ALLOWED or AUTHORIZATION_REJECTED or RAT_TYPE_NOT_ALLOWED or ILLEGAL_ME as defined in clause 8.1.2, then after the UE authenticates the network by using ePDG certificate and AUTH parameters as specified in 3GPP TS 33.402 [15], the UE shall close the related IKEv2 security association states and shall not retry the authentication procedure to an ePDG from the same PLMN until switching off or the UICC containing the USIM is removed.

If the above Private Notify Message Type is received from the VPLMN’s ePDG and the UE authenticates the network by using ePDG certificate and AUTH parameters as specified in 3GPP TS 33.402 [15]:

– If the received Notify Message Type is NON_3GPP_ACCESS_TO_EPC_NOT_ALLOWED or USER_UNKNOWN or AUTHORIZATION_REJECTED or RAT_TYPE_NOT_ALLOWED or ILLEGAL_ME, the UE may retry the authentication procedure with an ePDG deployed by the HPLMN if allowed according to the ePDG selection procedure in clause 7.2.1 and clause 7.2.1A; or

– If the received Private Notify Message Type is PLMN_NOT_ALLOWED, the UE should retry the authentication procedure with an ePDG deployed by the HPLMN if allowed according to the ePDG selection procedure in clause 7.2.1 and clause 7.2.1A.

If the UE receives from the ePDG the IKE_AUTH response message, including a Notify payload with a Private Notify Message Type "NETWORK_FAILURE" as defined in clause 8.1.2 then after the UE authenticates the network, the UE shall close the related IKEv2 security association states and:

a) if the received IKE_AUTH response message from ePDG contains a Notify payload with the BACKOFF_TIMER Notify payload as defined in clause 8.2.9.1, the UE shall behave as follows:

i) if the timer value indicates neither zero nor deactivated, start the Tw3 timer with the value provided and not retry the authentication procedure to the same ePDG until timer Tw3 expires or the UE is switched off or the UICC containing the USIM is removed;

ii) if the timer value indicates that this timer is deactivated, not retry the authentication procedure to the same ePDG until the UE is switched off or the UICC containing the USIM is removed; and

iii) if the timer value indicates zero, may retry the authentication procedure to an ePDG from the same PLMN; or

b) if the BACKOFF_TIMER Notify payload is not included in the received IKE_AUTH response message from ePDG, the UE shall start an implementation specific backoff timer. The UE shall not re-try the authentication procedure with the same ePDG until the backoff timer expires or the UE is switched off or the UICC containing the USIM is removed.

If the UE receives from the ePDG an IKE_AUTH response message including a Notify Payload with a Private Notify Message Error Type "NO_APN_SUBSCRIPTION" as defined in clause 8.1.2 then after the UE authenticates the network, the UE shall close the related IKEv2 security association states and:

a) if the received IKE_AUTH response message from ePDG contains a Notify payload with the BACKOFF_TIMER Notify payload as defined in clause 8.2.9.1, the UE shall behave as follows:

i) if the timer value indicates neither zero nor deactivated, start the Tw3 timer with the value provided and not retry the authentication procedure to the same PLMN for the same APN until timer Tw3 expires or the UE is switched off or the UICC containing the USIM is removed;

ii) if the timer value indicates that this timer is deactivated, not retry the authentication procedure to the same PLMN for the same APN until the UE is switched off or the UICC containing the USIM is removed; and

iii) if the timer value indicates zero, may retry the authentication procedure to an ePDG from the same PLMN for the same APN; or

b) if the BACKOFF_TIMER Notify payload is not included in the received IKE_AUTH response message from ePDG, the UE shall not retry the authentication procedure with the same PLMN for the same APN the UE is switched off or the UICC containing the USIM is removed, unless the UE has an implementation specific backoff timer. In that case, the UE shall not retry until that implementation specific timer expires.

NOTE 1: The UE can perform NSWO from the current untrusted WLAN access network even though the tunnel establishment procedure to the ePDG is not accepted by the network.

NOTE 2: Switching off and USIM change conditions are implemented taking into consideration the user experience aspect.

If NBM is used and if the UE receives from the ePDG an IKE_AUTH response message containing a Notify payload with a Private Notify Message Type PDN_CONNECTION_REJECTION as specified in clause 8.1.2 that includes an IP address information in the Notification Data field, the UE shall not attempt to re-establish this PDN connection with the same IP address while connected to the current ePDG and the UE shall close the related IKEv2 security association states.

If NBM is used and if the UE receives from the ePDG an IKE_AUTH response message containing a Notify payload with a Private Notify Message Type PDN_CONNECTION_REJECTION as specified in clause 8.1.2 and no Notification Data field, then after the UE authenticates the network, the UE shall not attempt to establish additional PDN connections to this APN while connected to the current ePDG. The UE shall close the related IKEv2 security association states. Subsequently, the UE can attempt to establishment additional PDN connections to the given APN if one or more existing PDN connections to the given APN are released. While connected to the current ePDG, if this PDN connection is the first PDN connection for the given APN, the UE shall not attempt to establish PDN connection to the given APN.

If NBM is used and if the UE receives from the ePDG an IKE_AUTH response message containing a Notify payload with a Private Notify Message Type MAX_CONNECTION_REACHED as specified in clause 8.1.2, then after the UE authenticates the network, the UE shall not attempt to establish any additional PDN connections while connected to the current ePDG. The UE shall close the related IKEv2 security association states. Subsequently, the UE can attempt to establishment additional PDN connections via the ePDG if one or more existing PDN connections via the ePDG are released.

7.2.2A Liveness check procedure

If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 and the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 was included in the CFG_REPLY configuration payload within the IKE_AUTH response message received in clause 7.2.2 the UE shall set the timeout period for the liveness check to the value of the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute.

If the UE does not support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 or the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 was not included in the CFG_REPLY configuration payload within the IKE_AUTH response message received in clause 7.2.2 then:

1) if the LivenessCheckPeriod node as specified in 3GPP TS 24.312 [13] is configured, the UE shall use the timeout period for the liveness check indicated by the LivenessCheckPeriod node; and

2) if the LivenessCheckPeriod node as specified in 3GPP TS 24.312 [13] is not configured, the UE shall use the pre-configured value of the timeout period for liveness check.

NOTE: The timeout period is pre-configured in the UE in implementation-specific way.

If the UE has not received any cryptographically protected IKEv2 or IPSec message for the duration of the timeout period for liveness check, the UE shall send an INFORMATIONAL request with no payloads as per IETF RFC 7296 [28]. If an INFORMATIONAL response is not received, the UE shall deem the IKEv2 security association to have failed, and shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA as specified in IETF RFC 7296 [28].

7.2.2B Handling of NBIFOM

If the IKEv2 authentication and security association establishment is triggered by procedures in 3GPP TS 24.161 [69], the UE shall include the NBIFOM_GENERIC_CONTAINER Notify payload (see clause 8.1.2.3)in the IKE_AUTH request message. The UE shall set the NBIFOM container contents field of the NBIFOM_GENERIC_CONTAINER Notify payload as specified in 3GPP TS 24.161 [69].

7.2.2C Rekeying procedure

The UE may support rekeying as defined in IETF RFC 7296 [28].

To trigger rekeying, the UE shall use the rekeying time parameter (see IETF RFC 7296 [28]) if it is configured by the RekeyingTime node as specified in 3GPP TS 24.312 [13], If the rekeying time parameter is not configured, the UE shall use an implementation-specific rekeying time (e.g. 18 hours).

7.2.2D NAT keep alive procedure

The UE may support NAT keep alive handling as defined in IETF RFC 7296 [28] and IETF RFC 3948 [72].

To control the NAT-keepalive packet sending, the UE shall use the parameter M (see IETF RFC 3948 [72]]) if it is configured by the NATKeepAliveTime node as specified in 3GPP TS 24.312 [13], If the parameter M is not configured, the UE shall use an implementation-specific time.

7.2.3 Tunnel modification

7.2.3.1 UE-initiated modification

This procedure is used if MOBIKE as defined in IETF RFC 4555 [31] is supported by the UE.

When there is a change of local IP address for the UE, the UE shall update the IKE security association with the new address, and shall update the IPsec security association associated with this IKE security association with the new address. The UE shall then send an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification to the ePDG.

If, further to this update, the UE receives an INFORMATIONAL request with a COOKIE2 notification present, the UE shall copy the notification to the COOKIE2 notification of an INFORMATIONAL response and send it to the ePDG.

This procedure is also used during the UE-initiated IP flow mobility procedure (see clause 6.3.3.3 of 3GPP TS 23.161 [68]) or the NBIFOM IP flow mapping procedure (see clause 6.4.3 of 3GPP TS 23.161 [68]).

If the UE-initiated modification is triggered by procedures in 3GPP TS 24.161 [69], the UE shall include the NBIFOM_GENERIC_CONTAINER Notify payload (see clause 8.1.2.3) in the INFORMATIONAL request to the ePDG. The UE shall set the NBIFOM container contents field of the NBIFOM_GENERIC_CONTAINER Notify payload as specified in 3GPP TS 24.161 [69].

7.2.3.2 UE behaviour towards ePDG initiated modification

This procedure is used if P-CSCF restoration extension for untrusted WLAN is supported as specified in 3GPP TS 23.380 [66].

If the UE receives the P_CSCF_IP6_ADDRESS attribute, the P_CSCF_IP4_ADDRESS attribute or both as specified in IETF RFC 7651 [64] in the CFG_REQUEST configuration payload within the INFORMATIONAL request from the ePDG and the UE supports P-CSCF restoration extension for untrusted WLAN as specified in 3GPP TS 23.380 [66], the UE shall reply with an INFORMATIONAL response and proceed as specified in clause 5.6.5.2 of 3GPP TS 23.380 [66]. The INFORMATIONAL response shall include the received P_CSCF_IP6_ADDRESS attribute or the P_CSCF_IP4_ADDRESS attribute or both in the CFG_REPLY Configuration Payload. The P_CSCF_IP6_ADDRESS attribute shall contain no value and the length field shall be set to 0. The P_CSCF_IP4_ADDRESS shall contain no value and the length field shall be set to 0.

Upon of receipt of the NBIFOM_GENERIC_CONTAINER Notify payload (see clause 8.1.2.3) in an INFORMATIONAL request, the UE shall reply with an INFORMATIONAL response and if required by procedures in 3GPP TS 24.161 [69], the UE shall include the NBIFOM_GENERIC_CONTAINER Notify payload (see clause 8.1.2.3) in the INFORMATIONAL response. The UE shall set the NBIFOM container contents field of the NBIFOM_GENERIC_CONTAINER Notify payload as specified in 3GPP TS 24.161 [69].

7.2.4 Tunnel disconnection

7.2.4.1 UE initiated disconnection

The UE shall use the procedures defined in the IKEv2 protocol (see IETF RFC 7296 [28]) to disconnect one or more IPsec tunnels to the ePDG. The UE shall close the incoming security associations associated with the tunnel and instruct the ePDG to do the same by sending the INFORMATIONAL request message including a "DELETE" payload. The DELETE payload shall contain either:

i) Protocol ID set to "1" and no subsequent Security Parameters Indexes (SPIs) in the payload. This indicates closing of IKE security association, and implies the deletion of all IPsec ESP security associations that were negotiated within the IKE security association;

ii) if the IKEv2 multiple bearer PDN connectivity is not supported or not used in the PDN connection as determined in clause 7.2.7, Protocol ID set to "3" for ESP. The Security Parameters Indexes included in the payload shall correspond to the particular incoming ESP security associations at the UE for the given tunnel in question; or

iii) if the IKEv2 multiple bearer PDN connectivity is used in the PDN connection as determined in clause 7.2.7, the Protocol ID field of the DELETE payload is set to "3" for ESP and the SPI field of the DELETE payload includes UE’s ESP SPIs of all bearer contexts of the PDN connection.

7.2.4.2 UE behaviour towards ePDG initiated disconnection

On receipt of the INFORMATIONAL request message including "DELETE" payload, indicating that the ePDG is attempting tunnel disconnection, the UE shall:

i) Close all security associations identified within the DELETE payload (these security associations correspond to outgoing security associations from the UE perspective). If no security associations were present in the DELETE payload, and the protocol ID was set to "1", the UE shall close the IKE security association, and all IPsec ESP security associations that were negotiated within it towards the ePDG; and

ii) The UE shall delete the incoming security associations corresponding to the outgoing security associations identified in the "DELETE" payload.

The UE shall send an INFORMATIONAL response message. If the INFORMATIONAL request message contained a list of security associations, the INFORMATIONAL response message shall contain a list of security associations deleted in step (ii) above.

If the UE is unable to comply with the INFORMATIONAL request message, the UE shall send INFORMATION response message with either:

i) A NOTIFY payload of type "INVALID_SPI", for the case that it could not identify one or more of the Security Parameters Indexes in the message from the ePDG; or

ii) A more general NOTIFY payload type. This payload type is implementation dependent.

If the INFORMATIONAL request message including the DELETE payload contains the REACTIVATION_REQUESTED_CAUSE Notify payload, the UE shall re-establish the IPsec Tunnel for the corresponding PDN connection after its release. The coding of the P-CSCF_RESELECTION_SUPPORT Notify payload is described in clause 8.2.9.6.

NOTE: For an IMS PDN connection, the re-establishment of the IPSec tunnel is part of the "Re-establishment of the IP-CAN used for SIP signalling procedure" specified in 3GPP TS 24 229 [67] clause R.2.2.1B.

7.2.4.3 Local tunnel disconnection initiated from 3GPP access

A PDN connection over untrusted WLAN over S2b can be released locally in the UE, i.e. without any peer-to-peer signalling between the ePDG and the UE, based on the trigger received from the 3GPP access, e.g. during the P-CSCF restoration procedure for NBIFOM PDN connections (see 3GPP TS 23.380 [66]).

Upon receiving over the 3GPP access:

– a DEACTIVATE EPS BEARER CONTEXT REQUEST message with the EPS bearer context of a default EPS bearer context and ESM cause #39 "reactivation requested" (see 3GPP TS 24.301 [10]); or

– a DETACH REQUEST message with the detach type "re-attach required" (see 3GPP TS 24.301 [10])

to release the resources for a PDN connection over the 3GPP access, the UE shall:

a) close the related IKEv2 security association for the IPsec tunnel associated with this PDN connection; and

b) consider that the ePDG is no longer responding (see RFC 7296 [28]) and not send any messages to the ePDG.

7.2.5 Emergency session establishment

If the UE needs to establish an IMS emergency session over untrusted non-3GPP access as specified in 3GPP TS 24.229 [67], the UE shall:

– if the UE is not connected to an ePDG yet, select an ePDG that supports emergency services as described in clause 7.2.1A;

– if the UE is already connected to an ePDG that has indicated its capability of support emergency services as specified in clause 7.4.1.1 and the ePDG is located in the same country where the UE is currently located, reuse ePDG for emergency session; and

– if the UE is already connected to an ePDG but the ePDG does not support the emergency services or ePDG is not located in the same country where the UE is currently located, first follow procedure described in clause 7.2.4.1 to disconnect existing IPsec tunnel. The UE shall then select an ePDG that supports emergency services as described in clause 7.2.1A.

Once the UE selects an ePDG that supports emergency services as specified in clause 7.2.1A, or if the UE is already connected to an ePDG and the ePDG is reused for emergency session, the UE shall initiate an IKEv2 tunnel establishment procedure towards this ePDG as described in clause 7.2.2. Upon receipt of an IKE_SA_INIT response, the UE shall send an IKE_AUTH request message to the ePDG according to clause 7.2.2.1 with the "IDr" payload containing the string "EMERGENCY", using capital letters only, in the Identification Data. The UE shall set the ID Type field of the "IDr" payload to ID_FQDN.

NOTE: In this procedure, the only scenario in which the UE is not in the same country as the ePDG it is connected to, is when the UE is not in the country of its HPLMN and the ePDG is in the country of the HPLMN.

In order to establish a new emergency session over an untrusted WLAN, the UE shall include:

– an INTERNAL_IP4_ADDRESS attribute with the length field set to zero;

an INTERNAL_IP6_ADDRESS attribute with the length field set to zero; or

– both of the above;

in the CFG_REQUEST Configuration Payload within the IKE_AUTH request message.

In order to perform handover of an emergency session from a 3GPP access network to untrusted WLAN, the UE shall include:

– the INTERNAL_IP4_ADDRESS attribute set to the IPv4 address of the previously allocated home address information;

the INTERNAL_IP6_ADDRESS attribute set to the IPv6 address of the previously allocated home address information; or

– both of the above;

in the CFG_REQUEST Configuration Payload within the IKE_AUTH request message. If the previously allocated home address information consists of both an IPv4 address and an IPv6 prefix, then the UE shall include the INTERNAL_IP4_ADDRESS attribute and the INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST configuration payload within the IKE_AUTH request message.

If the UE does not receive a response to an IKE_SA_INIT request message sent towards the selected ePDG, then the UE shall repeat the ePDG search as described in 3GPP TS 23.402 [6], excluding the ePDG for which the UE did not receive a response to the IKE_SA_INIT request message. The UE shall stop the establishment of emergency session if it is unable to select an ePDG for emergency bearer services.

If after sending an IKE_AUTH request message to the ePDG to initiate emergency session, the UE receives IKE_AUTH response message from the ePDG containing a Notify payload with a Private Notify Message Type "UNAUTHENTICATED_EMERGENCY_NOT_SUPPORTED", the UE shall follow the steps above to select a new ePDG for emergency session establishment by excluding the ePDGs from which the emergency session request was previously not accepted or by implementation specific means.

If the UE receives the Notify Message Type IMEI_NOT_ACCEPTED as defined in clause 8.1.2.2, the UE shall not retry the authentication procedure from the same PLMN until switching off, the UICC containing the USIM is replaced, or a UICC containing the USIM is inserted.

If the UE is already connected to an ePDG selected by the procedure in clause 7.2.1A, the UE is considered as attached for emergency bearer services. In such a case, the UE shall not initiate any addtional IKEv2 tunnel establishment procedure.

If the UE is connected to an ePDG selected by the procedure in clause 7.2.1, and the ePDG has indicated its capability of support emergency service to the UE as specified in clause 7.4.1.1 and is located in the same country where the UE is currently located, the UE, when it requires emergency services, shall initiate an IKEv2 tunnel establishment procedure towards the same ePDG to request for emergency session as specified in clause 7.2.2 provided that an emergency PDN connection is not already active.

7.2.6 Mobile identity signaling

During the IKEv2 authentication and security association establishment, if the UE:

– receives IKE_AUTH response message from ePDG containing a Notify payload with the DEVICE_IDENTITY Notify Message Type and the Identity Type field of the DEVICE_IDENTITY Notify payload is set to either ‘IMEI’ or ‘IMEISV’ and the Identity Value field is empty;

– successfully authenticates the network or requests emergency session; and

– has Mobile Equipment Identity IMEI or IMEISV available,

the UE shall include the DEVICE_IDENTITY Notify payload in the new IKE_AUTH request message.

At any time after successful tunnel establishment, if the UE:

– receives INFORMATIONAL request message from ePDG containing a Notify payload with the DEVICE_IDENTITY Notify Message Type and the Identity Type field of the DEVICE_IDENTITY Notify payload is set to either ‘IMEI’ or ‘IMEISV’ and the Identity Value field is empty; and

– has the UE’s Mobile Equipment Identity IMEI or IMEISV available,

the UE shall send INFORMATIONAL response containing a DEVICE_IDENTITY Notify payload.

The UE shall set the DEVICE_IDENTITY as follows:

– if IMEISV is available, the UE shall include IMEISV in the DEVICE_IDENTITY Notify payload. The Identity Type field of the DEVICE_IDENTITY Notify payload shall be set to ‘IMEISV’: and

– if IMEI is available and IMEISV is not available, the UE shall include IMEI in the DEVICE_IDENTITY attribute. The Identity Type field of the DEVICE_IDENTITY Notify payload shall be set to ‘IMEI’.

The detailed coding of the DEVICE_IDENTITY Notify payload is described in clause 8.2.9.2.

7.2.7 IKEv2 multiple bearer PDN connectivity

7.2.7.1 General

The UE may support the IKEv2 multiple bearer PDN connectivity.

If the UE supports the IKEv2 multiple bearer PDN connectivity, then the UE shall perform handling specified in the present clause. Otherwise the UE does not perform handling specified in the present clause and remaining clauses of the parent clause of the present clause.

The UE shall include an IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY Notify payload as specified in clause 8.2.9.9 within an IKE_AUTH request message establishing an IKE SA of a PDN connection. If the IKE_AUTH response message contains an EPS_QOS Notify payload as specified in clause 8.2.9.10, the UE shall consider that the IKEv2 multiple bearer PDN connectivity is used in the PDN connection.

If the IKEv2 multiple bearer PDN connectivity is used in the PDN connection, then the UE shall perform the handling specified in remaining clauses of the parent clause of the present clause. Otherwise the UE does not perform the handling specified in remaining clauses of the parent clause of the present clause.

7.2.7.2 Maintained information

The UE shall maintain one or more bearer contexts for the PDN connection. Each bearer context consists of a UE’s ESP SPI, an ePDG’s ESP SPI, an EPS QoS, an extended EPS QoS, a TFT, an APN-AMBR, an extended APN-AMBR, and an indication whether the bearer context is the default bearer context. The TFT can be absent only in the default bearer context. The extended EPS QoS can be absent for any bearer context. The APN-AMBR and the extended APN-AMBR are absent for bearer contexts which are not the default bearer context. The APN-AMBR can be present or absent for the default bearer context. The extended APN-AMBR can be present for the default bearer context only if the APN-AMBR is present for the default bearer context.

7.2.7.3 Control plane procedures

7.2.7.3.1 General

Parent clause of the present clause describe control plane procedures for the IKEv2 multiple bearer PDN connectivity.

7.2.7.3.2 Establishment of IKEv2 SA and initial IPSec ESP tunnel

NOTE: Inclusion of a IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY Notify payload in an IKE_AUTH request message is specified in clause 7.2.7.1.

Upon receiving the IKE_AUTH response message establishing the IKE SA of the PDN connection, the UE shall add a new bearer context to the PDN connection. The new bearer context shall consist of the UE’s ESP SPI created by the IKE_AUTH request/response pair, the ePDG’s ESP SPI created by the IKE_AUTH request/response pair, the EPS QoS indicated in the EPS_QOS Notify payload, the extended EPS QoS indicated in the EXTENDED_EPS_QOS Notify payload (if included in the IKE_AUTH response message), the APN-AMBR indicated in the APN_AMBR Notify payload (if included in the IKE_AUTH response message), and the extended APN-AMBR indicated in the EXTENDED_APN_AMBR Notify payload (if included in the IKE_AUTH response message) of the IKE_AUTH response message, and the indication that the bearer context is the default bearer context.

7.2.7.3.3 Establishment of an additional IPSec ESP tunnel

Upon receiving a CREATE_CHILD_SA request message in the IKE SA of the PDN connection, with an EPS_QOS Notify payload as specified in clause 8.2.9.10, with a TFT Notify payload as specified in clause 8.2.9.11, and without a REKEY_SA Notify payload, if the UE sends a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, the UE shall add a new bearer context to the PDN connection. The new bearer context shall consist of the UE’s ESP SPI created by the CREATE_CHILD_SA request/response pair, the ePDG’s ESP SPI created by the CREATE_CHILD_SA request/response pair, the EPS QoS indicated in the EPS_QOS Notify payload of the CREATE_CHILD_SA request message, the extended EPS QoS indicated in the EXTENDED_EPS_QOS Notify payload (if included in the CREATE_CHILD_SA request message), the TFT indicated in the TFT Notify payload of the CREATE_CHILD_SA request message, and the indication that the bearer context is not the default bearer context.

a) the UE checks for semantic errors in TFT operations as follows:

1) if the TFT operation in the TFT Notify payload is an operation other than "Create a new TFT", the UE shall send a CREATE_CHILD_SA response message with the SEMANTIC_ERROR_IN_THE_TFT_OPERATION Notify payload;

b) the UE checks for syntactical errors in TFT operations as follows:

1) if the TFT operation in the TFT Notify payload is "Create a new TFT" and the packet filter list in the TFT Notify payload is empty, the UE shall send a CREATE_CHILD_SA response message with the SYNTACTICAL_ERROR_IN_THE_TFT_OPERATION Notify payload; and

2) if there are other types of syntactical errors in the coding of the TFT Notify payload, such as a mismatch between the number of packet filters subfield, and the number of packet filters in the packet filter list, the UE shall send a CREATE_CHILD_SA response message with the SYNTACTICAL_ERROR_IN_THE_TFT_OPERATION Notify payload;

c) the UE checks for semantic errors in packet filters as follows:

1) if a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter, the UE shall send a CREATE_CHILD_SA response message with the SEMANTIC_ERRORS_IN_PACKET_FILTERS Notify payload. How the UE determines a semantic error in a packet filter is outside the scope of the present document; and

2) if the resulting TFT does not contain any packet filter which applicable for the uplink direction, the UE shall send a CREATE_CHILD_SA response message with the SEMANTIC_ERRORS_IN_PACKET_FILTERS Notify payload;

d) the UE checks syntactical errors in packet filters as follows:

1) if the TFT operation in the TFT Notify payload is "Create a new TFT" and two or more packet filters in the resultant TFT would have identical packet filter identifiers, the UE shall send a CREATE_CHILD_SA response message with the SYNTACTICAL_ERRORS_IN_PACKET_FILTERS Notify payload;

2) if the TFT operation in the TFT Notify payload is "Create a new TFT" and two or more packet filters in all TFTs associated with this PDN connection would have identical packet filter precedence values:

i) if the old packet filters do not belong to the default bearer contex, the UE shall send a CREATE_CHILD_SA response message with the SYNTACTICAL_ERRORS_IN_PACKET_FILTERS Notify payload; and

NOTE: the UE is not expected to be able to release a particular bearer context.

ii) if one or more old packet filters belong to the default bearer context, the UE shall release the PDN connection as specified in clause 7.2.4.1; and

3) if there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier, the UE shall send a CREATE_CHILD_SA response message with the SYNTACTICAL_ERRORS_IN_PACKET_FILTERS Notify payload.

7.2.7.3.4 Release of an additional IPSec ESP tunnel

Upon receiving an INFORMATIONAL request message in the IKE SA of the PDN connection, with a DELETE payload indicating an ePDG’s ESP SPI of a bearer context of the PDN connection, the UE shall send an INFORMATIONAL response message without an IKEv2 notify payload indicating an error and the UE shall remove the bearer context from the PDN connection.

7.2.7.3.5 Modification of an IPSec ESP tunnel due to change of EPS QoS and TFT

Upon receiving an INFORMATIONAL request message the IKE SA of the PDN connection, with a MODIFIED_BEARER Notify payload as specified in clause 8.2.9.12 indicating an ePDG’s ESP SPI of a bearer context of the PDN connection, if the UE sends an INFORMATIONAL response message without an IKEv2 notify payload indicating an error:

a) if the EPS_QOS Notify payload as specified in clause 8.2.9.10 is included in the INFORMATIONAL request message:

1) the UE shall update the bearer context with the EPS QoS indicated in the EPS_QOS Notify payload; and

2) if the EXTENDED_EPS_QOS Notify payload as specified in clause 8.2.9.10A is included in the INFORMATIONAL request message, the UE shall update the bearer context with the extended EPS QoS indicated in the EXTENDED_EPS_QOS Notify payload;

b) if the TFT Notify payload as specified in clause 8.2.9.11 is included in the INFORMATIONAL request message, the UE shall update the bearer context with the TFT indicated in the TFT Notify payload; and

c) if the bearer context is the default bearer context and the APN_AMBR Notify payload as specified in clause 8.2.9.13 is included in the INFORMATIONAL request message:

1) the UE shall update the bearer context with the APN-AMBR indicated in the APN_AMBR Notify payload; and

2) if the EXTENDED_APN_AMBR Notify payload as specified in clause 8.2.9.14 is included in the INFORMATIONAL request message, the UE shall update the bearer context with the extended APN-AMBR indicated in the EXTENDED_APN_AMBR Notify payload.

Upon receiving an INFORMATIONAL request message the IKE SA of the PDN connection, with a MODIFIED_BEARER Notify payload as specified in clause 8.2.9.12 indicating an ePDG’s ESP SPI of a bearer context of the PDN connection, and with a TFT Notify payload as specified in clause 8.2.9.11:

a) the UE checks for semantic errors in TFT operations as follows:

1) if the TFT operation in the TFT Notify payload is "Create a new TFT" and there is already an existing TFT for the bearer context, the UE shall further process the new activation request and, if it was processed successfully, delete the old TFT;

2) if the TFT operation in the TFT Notify payload is an operation other than "Create a new TFT" and there is no TFT for the bearer context, the UE shall not diagnose an error and perform the following actions to resolve the inconsistency:

i) if the TFT operation is "Delete existing TFT" or "Delete packet filters from existing TFT", and if no error according to items b, c, and d was detected, consider the TFT as successfully deleted; and

ii) if the TFT operation is "Add packet filters in existing TFT" or "Replace packet filters in existing TFT", the UE shall process the new request as an activation request;

3) if the TFT operation in the TFT Notify payload is "Delete packet filters from existing TFT" and it would render the TFT empty:

i) if the packet filters belong to a bearer context which is not the default bearer context, the UE shall process the new deletion request and, if no error according to items b, c, and d was detected, the UE shall send an INFORMATIONAL response message with the SEMANTIC_ERROR_IN_THE_TFT_OPERATION Notify payload; and

ii) if the packet filters belong to a bearer context which is the default bearer context, the UE shall process the new deletion request and if no error according to items b, c, and d was detected then delete the existing TFT; and

4) if the TFT operation in the TFT Notify payload is "Delete existing TFT" and the bearer context is not the default bearer context, the UE shall send an INFORMATIONAL response message with the SEMANTIC_ERROR_IN_THE_TFT_OPERATION Notify payload;

b) the UE checks for syntactical errors in TFT operations as follows:

1) if the TFT operation in the TFT Notify payload is "Create a new TFT", "Add packet filters in existing TFT", "Replace packet filters in existing TFT" or "Delete packet filters from existing TFT" and the packet filter list in the TFT Notify payload is empty, the UE shall send an INFORMATIONAL response message with the SYNTACTICAL_ERROR_IN_THE_TFT_OPERATION Notify payload;

2) if TFT operation in the TFT Notify payload is "Delete existing TFT" or "No TFT operation" with a non-empty packet filter list in the TFT Notify payload, the UE shall send an INFORMATIONAL response message with the SYNTACTICAL_ERROR_IN_THE_TFT_OPERATION Notify payload;

3) if TFT operation in the TFT Notify payload is "Replace packet filters in existing TFT" when the packet filter to be replaced does not exist in the original TFT, the UE shall not diagnose an error, further process the replace request and, if no error according to items c and d was detected, include the packet filters received to the existing TFT;

4) if TFT operation in the TFT Notify payload is "Delete packet filters from existing TFT" when the packet filter to be deleted does not exist in the original TFT, the UE shall not diagnose an error, further process the deletion request and, if no error according to items c and d was detected, consider the respective packet filter as successfully deleted;

5) if TFT operation in the TFT Notify payload is "Delete packet filters from existing TFT" with a packet filter list also including packet filters in addition to the packet filter identifiers, the UE shall send an INFORMATIONAL response message with the SYNTACTICAL_ERROR_IN_THE_TFT_OPERATION Notify payload; and

6) if there are other types of syntactical errors in the coding of the TFT Notify payload, such as a mismatch between the number of packet filters subfield, and the number of packet filters in the packet filter list, the UE shall send an INFORMATIONAL response message with the SYNTACTICAL_ERROR_IN_THE_TFT_OPERATION Notify payload;

c) the UE checks for semantic errors in packet filters as follows:

1) if a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter, the UE shall send an INFORMATIONAL response message with the SEMANTIC_ERRORS_IN_PACKET_FILTERS Notify payload. How the UE determines a semantic error in a packet filter is outside the scope of the present document; and

2) if the resulting TFT, which is assigned to a bearer context which is not the default bearer context, does not contain any packet filter applicable for the uplink direction among the packet filters created on request from the network, the UE shall send an INFORMATIONAL response message with the SEMANTIC_ERRORS_IN_PACKET_FILTERS Notify payload; and

d) the UE checks for syntactical errors in packet filters as follows:

1) if the TFT operation in the TFT Notify payload is "Create a new TFT", "Add packet filters to existing TFT", and two or more packet filters in the resultant TFT would have identical packet filter identifiers:

i) if two or more packet filters with identical packet filter identifiers are contained in the new request, the UE shall send an INFORMATIONAL response message with the SYNTACTICAL_ERRORS_IN_PACKET_FILTERS Notify payload; and

ii) if two or more packet filters with identical packet filter identifiers are not contained in the new request, the UE shall not diagnose an error, further process the new request and, if it was processed successfully, delete the old packet filters which have the identical packet filter identifiers;

2) if the TFT operation in the TFT Notify payload is "Create a new TFT", "Add packet filters to existing TFT" or "Replace packet filters in existing TFT", and two or more packet filters among all TFTs associated with this PDN connection would have identical packet filter precedence values:

i) if the old packet filters do not belong to the default bearer contex, the UE shall send an INFORMATIONAL response message with the SYNTACTICAL_ERRORS_IN_PACKET_FILTERS Notify payload; and

NOTE: the UE is not expected to be able to release a particular bearer context.

ii) if one or more old packet filters belong to the default bearer context, the UE shall release the PDN connection as specified in clause 7.2.4.1; and

3) if there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier, the UE shall send an INFORMATIONAL response message with the SYNTACTICAL_ERRORS_IN_PACKET_FILTERS Notify payload.

7.2.7.3.6 ePDG initiated IPSec ESP tunnel rekeying

Upon receiving a CREATE_CHILD_SA request message in the IKE SA of the PDN connection, with a REKEY_SA Notify payload indicating an ePDG’s ESP SPI of a bearer context of the PDN connection, if the UE sends a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, the UE shall set the UE’s ESP SPI of the bearer context to the UE’s ESP SPI created by the CREATE_CHILD_SA request/response pair and shall set the ePDG’s ESP SPI of the bearer context to the ePDG’s ESP SPI created by the CREATE_CHILD_SA request/response pair.

7.2.7.3.7 UE initiated IPSec ESP tunnel rekeying

Upon receiving a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, for a CREATE_CHILD_SA request message sent in the IKE SA of the PDN connection, with a REKEY_SA Notify payload indicating an UE’s ESP SPI of a bearer context of the PDN connection, the UE shall set the UE’s ESP SPI of the bearer context to the UE’s ESP SPI created by the CREATE_CHILD_SA request/response pair and shall set the ePDG’s ESP SPI of the bearer context to the ePDG’s ESP SPI created by the CREATE_CHILD_SA request/response pair.

7.2.7.4 User plane procedures

7.2.7.4.1 General

Parent clause of the present clause describe user plane procedures for the IKEv2 multiple bearer PDN connectivity.

7.2.7.4.2 Uplink IP packet handling

If an uplink IP packet to be sent via a PDN connection:

– matches the packet filters applicable for the uplink direction of the TFT of a bearer context of the PDN connection, the UE shall forward the uplink IP packet using the ePDG’s ESP SPI of the bearer context. The UE shall use the QCI in the EPS QoS of the bearer context to derive the DSCP value for uplink packets and set the DSCP field as specified in IETF RFC 2474 [75] of the outer IP header of the ESP packet.

– does not match the packet filters applicable for the uplink direction of the TFT of any bearer context of the PDN connection and a bearer context without the TFT exists in the PDN connection, the UE shall forward the uplink IP packet using the ePDG’s ESP SPI of the bearer context without the TFT. The UE shall set the DSCP field as specified in IETF RFC 2474 [75] of the outer IP header of the ESP packet to the DSCP value in a QoS mapping with the QCI indicated in the EPS QoS of the bearer context without the TFT.

– does not match the packet filters applicable for the uplink direction of the TFT of any bearer context of the PDN connection and a bearer context without the TFT does not exist in the PDN connection, the UE shall discard the uplink IP packet.

NOTE 1: The UE can map QCI to DSCP value, for example, by using the mapping between standardized QCI values and Release 99 3GPP QoS parameter values specified in 3GPP TS 23.401 [4] table E.3, and the mapping between Release 99 3GPP QoS parameter values and DSCP values specified in IEEE Std 802.11 [57] table R-1.

NOTE 2: The TSi payload and the TSr payloads are not used for selection of ESP SPI for the uplink IP packet.

7.3 3GPP AAA server procedures

The UE – 3GPP AAA server procedures are as specified in 3GPP TS 29.273 [17] and 3GPP TS 33.402 [15].

7.4 ePDG procedures

7.4.1 Tunnel establishment

7.4.1.1 Tunnel establishment accepted by the network

Upon receipt of an IKE_AUTH request message from the UE requesting the establishment of a tunnel, the ePDG shall proceed with authentication and authorization. The basic procedure described in 3GPP TS 33.402 [15], while further details are given below.

During the UE’s authentication and authorization procedure, the 3GPP AAA server provides to the ePDG an indication about the selected IP mobility mechanism as specified in 3GPP TS 29.273 [17].

The ePDG shall proceed with IPsec tunnel setup completion and shall relay in the IKEv2 Configuration Payload (CFG_REPLY) of the final IKE_AUTH response message:

– The remote IP address information to the UE as follows:

– If NBM is used as IP mobility mechanism, the ePDG shall assign either an IPv4 address or an IPv6 Home Network Prefix or both to the UE via a single CFG_REPLY Configuration Payload. If the UE requests for both IPv4 address and IPv6 prefix, but the ePDG only assigns an IPv4 address or an IPv6 Home Network Prefix due to subscription restriction or network preference, the ePDG shall include the assigned remote IP address information (IPv4 address or IPv6 prefix) via a single CFG_REPLY Configuration Payload and should add the corresponding PDN_TYPE_IPv4_ONLY_ALLOWED Notify payload, or PDN TYPE_IPv6_ONLY_ALLOWED Notify payload. If the ePDG assigns an IPv4 address, the CFG_REPLY contains the INTERNAL_IP4_ADDRESS attribute. If the ePDG assigns an IPv6 Home Network Prefix, the CFG_REPLY contains the INTERNAL_IP6_SUBNET or INTERNAL_IP6_ADDRESS configuration attributes. The ePDG obtains the IPv4 address and/or the IPv6 Home Network Prefix from the PDN GW; or

NOTE: In case of IPv6 address, if CFG_REPLY Configuration Payload contains the INTERNAL_IP6_SUBNET or INTERNAL_IP6_ADDRESS, the UE considers only IPv6 Home Network Prefix defined by the prefix length value.

– If DSMIPv6 is used as IP mobility mechanism, depending on the information provided by the UE in the CFG_REQUEST payload the ePDG shall assign to the UE either a local IPv4 address or local IPv6 address (or a local IPv6 prefix) via a single CFG_REPLY Configuration Payload. If the ePDG assigns a local IPv4 address, the CFG_REPLY contains the INTERNAL_IP4_ADDRESS attribute and should add the corresponding PDN TYPE_IPv4_ONLY_ALLOWED Notify payload or PDN TYPE_IPv6_ONLY_ALLOWED Notify payload. If the ePDG assigns a local IPv6 address or a local IPv6 prefix the CFG_REPLY contains correspondingly the INTERNAL_IP6_ADDRESS or the INTERNAL_IP6_SUBNET attribute; and

– If the UE included the INTERNAL_IP6_DNS or the INTERNAL_IP4_DNS in the CFG_REQUEST Configuration payload, the ePDG shall include the same attribute in the CFG_REPLY Configuration payload including zero or more DNS server addresses as specified in IETF RFC 7296 [28];

– If the UE included the P_CSCF_IP6_ADDRESS attribute, the P_CSCF_IP4_ADDRESS attribute or both in the CFG_REQUEST configuration payload, the ePDG may include one or more instances of the same attribute in the CFG_REPLY configuration payload as specified in IETF RFC 7651 [64]; and

– The ePDG may include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in clause 8.2.4.2 indicating the timeout period for liveness check in the CFG_REPLY configuration payload. Presence of the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute in the IKE_AUTH request can be used as input for decision on whether to include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute.

If the UE does not provide an APN to the ePDG during the tunnel establishment of a non-emergency session, the ePDG shall include the default APN in the "IDr" payload of the IKE_AUTH response message. If the UE provided an APN to the ePDG during the tunnel establishment, the ePDG shall not change the provided APN and shall include the APN in the IDr payload of the IKE_AUTH response message. The ePDG shall set the ID Type field of the "IDr" payload to ID_FQDN as defined in IETF RFC 7296 [28]. Handling of "IDr" payload in case of an emergency session is specified in clause 7.4.4. An IPsec tunnel is now established between the UE and the ePDG.

If the UE indicates Handover Attach by including the previously allocated home address information and the ePDG obtains one or more PDN GW identities from the 3GPP AAA server, the ePDG shall use these identified PDN GWs in the subsequent PDN GW selection process. If the UE indicates Initial Attach i.e. home address information not included:

– if the PDN GW allocation type received from the 3GPP AAA server indicates the static allocation type, the received PDN GW identities shall be used to select PDN-GW; and

– if the PDN GW allocation type received from the 3GPP AAA server indicates the dynamic allocation type, the PDN GW is selected based on DNS query via the UE requested APN.

The ePDG shall support IPSec ESP (see IETF RFC 4303 [32]) in order to provide secure tunnels between the UE and the ePDG as specified in 3GPP TS 33.402 [15].

During the IKEv2 authentication and tunnel establishment, if the UE requested the HA IP address(es) and if DSMIPv6 was chosen and if the HA IP address(es) are available, the ePDG shall provide the HA IP address(es) (IPv6 address and optionally IPv4 address) for the corresponding APN as specified by the "IDr" payload in the IKE_AUTH request message by including in the CFG_REPLY Configuration Payload a HOME_AGENT_ADDRESS attribute. In the CFG_REPLY, the ePDG sets respectively the IPv6 Home Agent address field and optionally the IPv4 Home Agent address field of the HOME_AGENT_ADDRESS attribute to the IPv6 address of the HA and to the IPv4 address of the HA. If no IPv4 HA address is available at the ePDG or if it was not requested by the UE, the ePDG shall omit the IPv4 Home Agent Address field. If the ePDG is not able to provide an IPv6 HA address for the corresponding APN, then the ePDG shall not include a HOME_AGENT_ADDRESS attribute in the CFG_REPLY.

The ePDG may support multiple authentication exchanges in the IKEv2 protocol as specified in IETF RFC 4739 [49] in order to support additional authentication and authorization of the UE with an external AAA server.

If the ePDG supports authentication and authorization of the UE with an external AAA server, on receipt of an IKE_SA_INIT message the ePDG shall include a Notify payload of type "MULTIPLE_AUTH_SUPPORTED" in the IKE_SA_INIT response message to the UE.

On successful completion of authentication and authorization procedure of the UE accessing EPC and on receipt of an IKE_AUTH request containing a Notify payload of type "ANOTHER_AUTH_FOLLOWS", the ePDG shall send an IKE_AUTH response containing the "AUTH" payload.

Upon receipt of a subsequent IKE_AUTH request from the UE containing the user identity in the private network within the "IDi" payload, the ePDG shall:

– if PAP authentication is required, then send an EAP-GTC request to the UE within an IKE_AUTH response message. Upon receipt of an EAP-GTC response from the UE, the ePDG shall use the procedures defined in 3GPP TS 29.275 [18] and 3GPP TS 29.274 [50] to authenticate the user with the external AAA server; and

– if CHAP authentication is required, then send an EAP MD5-Challenge request to UE. Upon receipt of EAP MD5-Challenge response within an IKE_AUTH request message from the UE, the ePDG shall use the procedures defined in 3GPP TS 29.275 [18] and 3GPP TS 29.274 [50] to authenticate the user with the external AAA server. If the ePDG receives Legacy-Nak response containing EAP–GTC type from the UE (see IETF RFC 3748 [29]) the ePDG may change the authentication and authorization procedure. If the ePDG does not change the authentication and authorization procedure or if the ePDG receives a Legacy-Nak response not containing EAP-GTC, the ePDG shall send an EAP-Failure to the UE.

NOTE: The signalling flows for authentication and authorization with an external AAA server are described in 3GPP TS 33.402 [15].

If the IKE_AUTH request message contains a P-CSCF_RESELECTION_SUPPORT Notify payload as described in clause 8.2.9.4 and if the ePDG supports the P-CSCF restoration extension (see 3GPP TS 23.380 [66]), the ePDG shall send a P-CSCF_RESELECTION_SUPPORT indication to the PGW.

If the ePDG supports emergency service, the ePDG shall send its capability indication of support emergency service to the UE by including the EMERGENCY_SUPPORT Notify payload within an IKE_AUTH response message. The content of the EMERGENCY_SUPPORT Notify payload is described in clause 8.2.9.7.

7.4.1.2 Tunnel establishment not accepted by the network

During the tunnel establishment procedures, if the ePDG receives from the AAA Server the Authentication and Authorization Answer message with the Result code IE (as specified in 3GPP TS 29.273 [17]):

a) DIAMETER_ERROR_USER_NO_NON_3GPP_SUBSCRIPTION, the ePDG shall include, in the IKE_AUTH response message to the UE, a Notify payload with a Private Notify Message Type NON_3GPP_ACCESS_TO_EPC_NOT_ALLOWED as defined in clause 8.1.2;

b) DIAMETER_ERROR_USER_UNKNOWN, the ePDG shall include, in the IKE_AUTH response message to the UE, a Notify payload with a Private Notify Message Type USER_UNKNOWN as defined in clause 8.1.2;

c) DIAMETER_AUTHORIZATION_REJECTED, the ePDG shall include, in the IKE_AUTH response message to the UE, a Notify payload with a Private Notify Message Type AUTHORIZATION_REJECTED as defined in clause 8.1.2;

d) DIAMETER_ERROR_RAT_TYPE_NOT_ALLOWED, the ePDG shall include, in the IKE_AUTH response message to the UE, a Notify payload with a Private Notify Message Type RAT_TYPE_NOT_ALLOWED as defined in clause 8.1.2;

e) DIAMETER_UNABLE_TO_ COMPLY, the ePDG shall include, in the IKE_AUTH response message to the UE, a Notify payload with a Private Notify Message Type NETWORK_FAILURE as defined in clause 8.1.2 and the ePDG may also include a BACKOFF_TIMER Notify payload of the IKE_AUTH response message;

f) DIAMETER_ERROR_ROAMING_NOT_ALLOWED, the ePDG shall include, in the IKE_AUTH response message to the UE, a Notify payload with a Private Notify Message Type PLMN_NOT_ALLOWED as defined in clause 8.1.2;

g) DIAMETER_ERROR_ USER_NO_APN_SUBSCRIPTION, the ePDG shall include, in the IKE_AUTH response message to the UE, a Notify Payload with a Private Notify Message Type NO_APN_SUBSCRIPTION as defined in clause 8.1.2 and the ePDG may also include a BACKOFF_TIMER Notify payload of the IKE_AUTH response message; or

h) DIAMETER_ERROR_ILLEGAL_EQUIPMENT, the ePDG shall include, in the IKE_AUTH response message to the UE, a Notify payload with a Private Notify Message Type ILLEGAL_ME as defined in clause 8.1.2.

NOTE: In the cases a) through h), the ePDG still provides to the UE the information needed to authenticate the ePDG.

During the tunnel establishment procedures, when the network has determined that the requested procedure cannot be completed successfully due to a network failure, e.g. due to ePDG congestion, the ePDG:

a) shall include in the IKE_AUTH response message to the UE a Notify payload with a Private Notify Message Type NETWORK_FAILURE as defined in clause 8.1.2; and

b) may also include a BACKOFF_TIMER Notify payload of the IKE_AUTH response message.

If NBM is used and if the ePDG needs to reject a PDN connection due to conditions as specified in 3GPP TS 29.273 [17] or the network policies or the ePDG capabilities to indicate that no more PDN connection request of the given APN can be accepted for the UE, the ePDG shall include, in the IKE_AUTH response message, a Notify payload with a Private Notify Message Type PDN_CONNECTION_REJECTION as specified in clause 8.1.2. Additionally if the IKE_AUTH request message from the UE indicated Handover Attach as specified in clause 7.2.2, and the ePDG needs to reject a PDN connection for example due to the corresponding PDN GW identity not received for the APN, the ePDG shall include, in the IKE_AUTH response message, a Notify payload with a Private Notify Message Type "PDN_CONNECTION_REJECTION" as specified in clause 8.1.2 and the Notification Data field with the IP address information from the Handover Attach indication. If the UE indicated Initial Attach, the Notification Data field shall be omitted.

If the ePDG needs to reject a PDN connection due to the network policies or capabilities to indicate that no more PDN connection request with any APN can be accepted for the UE, the ePDG shall include in the IKE_AUTH response message containing the IDr payload a Notify payload with a Private Notify Message Type MAX_CONNECTION_REACHED as specified in clause 8.1.2.

7.4.1A Liveness check

If the ePDG has not received any cryptographically protected IKEv2 or IPSec message for the duration of the timeout period for liveness check selected according to the local policy, the ePDG shall send an INFORMATIONAL request with no payloads IETF RFC 7296 [28]. If an INFORMATIONAL response is not received, the ePDG shall deem the IKEv2 security association to have failed, shall discard all states associated with the IKE SA and any child SAs that were negotiated using that IKE SA as specified in IETF RFC 7296 [28] and shall inform the PGW and the 3GPP AAA Server that the connection has been released.

7.4.1B Handling of NBIFOM

If the UE included the NBIFOM_GENERIC_CONTAINER Notify payload (see clause 8.1.2.3) within the IKE_AUTH request message, and if required by procedures in 3GPP TS 24.161 [69], the ePDG shall include the same Notify payload within the IKE_AUTH response message as specified in 3GPP TS 24.161 [69]. The ePDG shall set the NBIFOM container contents field of the NBIFOM_GENERIC_CONTAINER Notify payload as specified in 3GPP TS 24.161 [69].

7.4.1C Handling of N1 mode support

If the UE included the N1_MODE_CAPABILITY Notify payload (see clause 8.1.2.3) within the IKE_AUTH request message, the ePDG may include the N1_MODE_INFORMATION Notify payload and the N1_MODE_S_NSSAI_PLMN_ID Notify payload within the IKE_AUTH response message. The ePDG shall set the S-NSSAI Value field of the N1_MODE INFORMATION Notify payload to the S-NSSAI for the PDU session associated with the IKEv2 security association if the ePDG receives the S-NSSAI information as specified in 3GPP TS 29.274 [50] for the PDU session indicated in the PDU session ID field of the N1_MODE_CAPABILITY Notify payload. The ePDG shall set the S-NSSAI PLMN ID field of the N1_MODE_S_NSSAI_PLMN_ID Notify payload to the PLMN ID that the S-NSSAI relates to for the PDU session associated with the IKEv2 security association if the ePDG receives the PLMN ID that the S-NSSAI relates to as specified in 3GPP TS 29.274 [50] for the PDU session indicated in the PDU session ID field of the N1_MODE_CAPABILITY Notify payload.

7.4.2 Tunnel modification

7.4.2.1 ePDG-initiated modification

The ePDG shall forward the list of available P-CSCF addresses received from the P-GW by including the P_CSCF_IP6_ADDRESS attribute, the P_CSCF_IP4_ADDRESS attribute or both as specified in IETF RFC 7651 [64] in the CFG_REQUEST configuration payload within the INFORMATIONAL request to the UE as specified in 3GPP TS 23.380 [66].

If the ePDG-initiated modification procedure is triggered by NBIFOM procedures in 3GPP TS 24.161 [69], the ePDG shall include the NBIFOM_GENERIC_CONTAINER Notify payload (see clause 8.1.2.3) in the INFORMATIONAL request. The ePDG shall set the NBIFOM container contents field of the NBIFOM_GENERIC_CONTAINER Notify payload as specified in 3GPP TS 24.161 [69].

If the ePDG-initiated modification is initiated by a UE-initiated modification, i.e. by a received INFORMATIONAL request message, then the ePDG shall include in the sent INFORMATIONAL request message a PTI Notify payload as specified in clause 8.1.2.3 with the Related Message ID field set to the Message ID field of the received INFORMATIONAL request message.

7.4.2.2 ePDG behaviour towards UE-initiated modification

When receiving an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification, the ePDG shall check the validity of the IP address and update the IP address in the IKE security association with the values from the IP header. The ePDG shall reply with an INFORMATIONAL response.

The ePDG may initiate a return routability check for the new address provided by the UE, by including a COOKIE2 notification in an INFORMATIONAL request and send it to the UE. When the ePDG receives the INFORMATIONAL response from the UE, it shall check that the COOKIE2 notification payload is the same as the one it sent to the UE. If it is different, the ePDG shall close the IKE security association by sending an INFORMATIONAL request message including a "DELETE" payload.

If no return routability check is initiated by the ePDG, or if a return routability check is initiated and is successfully completed, the ePDG shall update the IPsec security associations associated with the IKE security association with the new address.

Upon of receipt of the NBIFOM_GENERIC_CONTAINER Notify payload (see clause 8.1.2.3)in an INFORMATIONAL request, the ePDG shall reply with an INFORMATIONAL response and if required by procedures in 3GPP TS 24.161 [69], the ePDG shall include the NBIFOM_GENERIC_CONTAINER Notify payload in the INFORMATIONAL response. The ePDG shall set the NBIFOM container contents field of the NBIFOM_GENERIC_CONTAINER Notify payload as specified in 3GPP TS 24.161 [69].

7.4.3 Tunnel disconnection

7.4.3.1 ePDG initiated disconnection

The ePDG shall use the procedures defined in the IKEv2 protocol (see IETF RFC 7296 [28]) to disconnect one or more IPsec tunnels to the UE. The ePDG shall close the incoming security associations associated with the tunnel and instruct the UE to do likewise by sending the INFORMATIONAL request message including a "DELETE" payload. The DELETE payload shall contain either:

i) Protocol ID set to "1" and no subsequent Security Parameter Indexes in the payload. This indicates that the IKE security association, and all IPsec ESP security associations that were negotiated within it between ePDG and UE shall be deleted;

ii) if the IKEv2 multiple bearer PDN connectivity is not supported or not used in the PDN connection as determined in clause 7.4.6, the Protocol ID set to "3" for ESP. The SECURITY PARAMETERS INDEXES s included in the payload shall correspond to the particular incoming ESP SECURITY ASSOCIATION at the ePDG for the given tunnel in question; or

iii) if the IKEv2 multiple bearer PDN connectivity is used in the PDN connection as determined in clause 7.4.6, the Protocol ID field of the DELETE payload is set to "3" for ESP and the SPI field of the DELETE payload includes ePDG’s ESP SPIs bound to each the S2b bearers of the PDN connection.

The INFORMATIONAL request message, in addition of the DELETE payload, may include the REACTIVATION_REQUESTED_CAUSE Notify payload.

If the ePDG receives the reactivation requested cause in a Delete Bearer Request over S2b, the ePDG shall include the REACTIVATION_REQUESTED_CAUSE Notify payload in the INFORMATIONAL request message containing a DELETE payload.

7.4.3.2 ePDG behaviour towards UE initiated disconnection

On receipt of the INFORMATIONAL request message including "DELETE" payload indicating that the UE is initiating tunnel disconnect procedure, the ePDG shall:

i) Close all security associations identified within the DELETE payload (these security associations correspond to outgoing security associations from the ePDG perspective). If no security associations were present in the DELETE payload, and the protocol ID was set to "1", the ePDG shall close the IKE security association, and all IPsec ESP security associations that were negotiated within it towards the UE; and

ii) The ePDG shall delete the incoming security associations corresponding to the outgoing security associations identified in the "DELETE" payload.

The ePDG shall send an INFORMATIONAL response message. This shall contain a list of security associations deleted in step (ii) above.

If the ePDG is unable to comply with the INFORMATIONAL request message, the ePDG shall send INFORMATION response message with either:

i) a NOTIFY payload of type "INVALID_SPI", for the case that it could not identify one or more of the SECURITY PARAMETERS INDEXES in the message from the UE; or

ii) a more general NOTIFY payload type. This payload type is implementation dependent.

7.4.3.3 Local tunnel disconnection initiated by PGW

A PDN connection over untrusted WLAN over S2b can be released locally in the ePDG, i.e. without any peer-to-peer signalling between the ePDG and the UE, based on the trigger received from the PGW, e.g. during the P-CSCF restoration procedure for NBIFOM PDN connections (see 3GPP TS 23.380 [66]).

Upon receiving a request from PGW to release the resources for a PDN connection with cause "local release" (see 3GPP TS 29.274 [50]) the ePDG shall:

a) close the related IKEv2 security association for the IPsec tunnel associated with this PDN connection; and

b) consider that the UE is no longer responding (see RFC 7296 [28]) and not send any messages to the UE.

7.4.4 Emergency session establishment

If the "IDr" payload containing the string "EMERGENCY", using capital letters only, in the Identification Data is included in the IKE_AUTH request message from the UE, the ePDG shall:

a) if:

1) an INTERNAL_IP4_ADDRESS attribute with the length field set to zero;

2) an INTERNAL_IP6_ADDRESS attribute with the length field set to zero; or

3) both of the above;

are included in the CFG_REQUEST Configuration Payload within the IKE_AUTH request message, handle the session establishment as an emergency session establishment;

b) if:

1) an INTERNAL_IP4_ADDRESS attribute with the length field set to non-zero;

2) an INTERNAL_IP6_ADDRESS attribute with the length field set to non-zero; or

3) both of the above;

are included in the CFG_REQUEST Configuration Payload within the IKE_AUTH request message, handle the session establishment as a handover of an emergency session;

c) in the IKE_AUTH response message, the ePDG shall not include the APN in the "IDr" payload; and

d) ignore the fact that the "EMERGENCY" string does not comply with the ID_FQDN ID Type, as described in IETF RFC 7296 [28].

In addition, if the IKE tunnel establishment is initiated for emergency session:

1) if IMSI is provided to the network but the ePDG receives from the AAA Server the Authentication and Authorization Answer message with the Result code IE indicating DIAMETER_ERROR_USER_UNKNOWN (see 3GPP TS 29.273 [17]), and thus the network considers the IMSI is unauthenticated:

– if the ePDG is configured to support unauthenticated emergency session over WLAN and Mobile Equipment Identity signalling over untrusted WLAN, the ePDG shall request the IMEI from the UE using the Mobile Equipment Identity signalling procedure by including the DEVICE_IDENTITY Notify payload in the IKE_AUTH response message as specified in clause 7.4.5; or

– if the ePDG is not configured to support unauthenticated emergency session over WLAN or the ePDG is not configured to support Mobile Equipment Identity signalling over untrusted WLAN, the ePDG shall reject the requested PDN connection for emergency session. The ePDG shall include, in the IKE_AUTH response message, a Notify payload with a Private Notify Message Type "UNAUTHENTICATED_EMERGENCY_NOT_SUPPORTED" as specified in clause 8.1.2; or

2) if IMSI is not provided to the network and the UE’s IMEI is used as the User Identity in the IDi payload of the IKE_AUTH request message:

– if the ePDG is configured to support emergency services from unauthenticated UE and the local policies and regulations allow unauthenticated emergency sessions, the ePDG sends an EAP payload with the NAI in the IDi payload received from the UE to the 3GPP AAA Server serving the specific domain indicated in the realm part of NAI in the IDr payload. If the ePDG receives the Authentication and Authorization Answer message with the Result code IE indicating DIAMETER_ERROR_USER_UNKNOWN (see 3GPP TS 29.273 [17]), the ePDG shall reject the emergency services request from the UE with the Notify Message Type IMEI_NOT_ACCEPTED as specified in clause 8.1.2.2; or

– if the ePDG is not configured to support emergency services from unauthenticated UE or if the local policies and regulations do not allow unauthenticated emergency sessions, the ePDG shall reject the emergency services request from the UE with the Notify Message Type IMEI_NOT_ACCEPTED as specified in clause 8.1.2.2.

7.4.5 Mobile identity signaling

If the network supports Mobile Equipment Identity signalling over untrusted WLAN, the ePDG may request the UE to provide the Mobile Equipment Identity by including the DEVICE_IDENTITY Notify payload with the Identity Type field set to either ‘IMEI’ or ‘IMEISV’ and an empty Identity Value field in:

– the IKE_AUTH response message to the initial IKE_AUTH request message received from the UE during the IKEv2 authentication and security association establishment; or

– the INFORMATIONAL request message at any time after successful IPSec tunnel establishment.

If the ePDG receives the following response message from the UE:

– the IKE_AUTH request message with the DEVICE_IDENTITY Notify payload; or

– the INFORMATIONAL response message with the DEVICE_IDENTITY Notify payload,

and the Identity Type field set to either ‘IMEI’ or ‘IMEISV’ and the Identity Value is not empty, the ePDG shall forward the received IMEI or IMEISV identity to the 3GPP AAA server as specified in 3GPP TS 29.273 [17] and to the PDN GW as specified in 3GPP TS 29.275 [18] and 3GPP TS 29.274 [50].

7.4.6 IKEv2 multiple bearer PDN connectivity

7.4.6.1 General

The ePDG may support the IKEv2 multiple bearer PDN connectivity.

If the ePDG supports the IKEv2 multiple bearer PDN connectivity, then the ePDG shall perform handling specified in the present clause. Otherwise the ePDG does not perform handling specified in the present clause and remaining clauses of the parent clause of the present clause.

If the IKE_AUTH request message contains an IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY Notify payload as specified in clause 8.2.9.9 and the ePDG decides to use the IKEv2 multiple bearer PDN connectivity in the PDN connection of the IKE SA being established by the IKE_AUTH request message according to local policy, the ePDG shall consider that the IKEv2 multiple bearer PDN connectivity is used in the PDN connection.

If the IKEv2 multiple bearer PDN connectivity is used in the PDN connection, then the ePDG shall perform the handling specified in remaining clauses of the parent clause of the present clause. Otherwise the ePDG does not perform the handling specified in remaining clauses of the parent clause of the present clause.

7.4.6.2 Maintained information

The ePDG shall maintain a binding of an ePDG’s ESP SPI and a UE’s ESP SPI to each S2b bearer of the PDN connection.

7.4.6.3 Control plane procedures

7.4.6.3.1 General

Parent clause of the present clause describe control plane procedures for the IKEv2 multiple bearer PDN connectivity.

7.4.6.3.2 Establishment of IKEv2 SA and initial IPSec ESP tunnel

In the IKE_AUTH response message establishing an IKE SA of the PDN connection:

a) the ePDG shall include an EPS_QOS Notify payload as specified in clause 8.2.9.10 indicating the EPS QoS of the default S2b bearer of the PDN connection;

b) the ePDG may include an EXTENDED_EPS_QOS Notify payload as specified in clause 8.2.9.10A indicating the extended EPS QoS of the default S2b bearer of the PDN connection;

c) the ePDG may include an APN_AMBR Notify payload as specified in clause 8.2.9.13 indicating the APN-AMBR of the PDN connection; and

d) if the APN_AMBR Notify payload is included, the ePDG may include an EXTENDED_APN_AMBR Notify payload as specified in clause 8.2.9.14 indicating the extended APN-AMBR of the PDN connection

.Upon sending the IKE_AUTH response message, the ePDG shall bind the ePDG’s ESP SPI created by the IKE_AUTH request/response pair and the UE’s ESP SPI created by the IKE_AUTH request/response pair to the default S2b bearer of the PDN connection.

7.4.6.3.3 Establishment of an additional IPSec ESP tunnel

If a dedicated S2b bearer of the PDN connection is activated, the ePDG shall send a CREATE_CHILD_SA request message in the IKE SA of the PDN connection. In the CREATE_CHILD_SA request message:

a) the ePDG shall include an EPS_QOS Notify payload as specified in clause 8.2.9.10 indicating the EPS QoS of the dedicated S2b bearer of the PDN connection;

b) the ePDG may include an EXTENDED_EPS_QOS Notify payload as specified in clause 8.2.9.10A indicating the extended EPS QoS of the dedicated S2b bearer of the PDN connection; and

c) the ePDG shall include an TFT Notify payload as specified in clause 8.2.9.11 indicating the TFT of the dedicated S2b bearer of the PDN connection.

Upon receiving a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, the ePDG shall accept the dedicated S2b bearer activation and shall bind the ePDG’s ESP SPI created by the CREATE_CHILD_SA request/response pair and the UE’s ESP SPI created by the CREATE_CHILD_SA request/response pair to the dedicated S2b bearer of the PDN connection.

Upon receiving a CREATE_CHILD_SA response message with an IKEv2 notify payload indicating an error, the ePDG shall reject the dedicated S2b bearer activation.

7.4.6.3.4 Release of an additional IPSec ESP tunnel

If a dedicated S2b bearer of the PDN connection is deactivated, the ePDG shall send a INFORMATIONAL request message in the IKE SA of the PDN connection. In the INFORMATIONAL request message, the ePDG shall include an DELETE payload indicating the ePDG’s ESP SPI bound to the dedicated S2b bearer.

Upon receiving of a INFORMATIONAL response message, the ePDG shall acknowledge deactivation of the dedicated S2b bearer.

7.4.6.3.5 Modification of an IPSec ESP tunnel due to change of EPS QoS and TFT

If an S2b bearer of the PDN connection is modified, the ePDG shall send a INFORMATIONAL request message in the IKE SA of the PDN connection. In the INFORMATIONAL request message, the ePDG shall include an MODIFIED_BEARER Notify payload as specified in clause 8.2.9.12 indicating the ePDG’s ESP SPI bound to the S2b bearer. In the INFORMATIONAL request message:

a) the ePDG may include an EPS_QOS Notify payload as specified in clause 8.2.9.10 indicating the EPS QoS of the S2b bearer of the PDN connection;

b) if the EPS_QOS Notify payload is included, the ePDG may include an EXTENDED_EPS_QOS Notify payload as specified in clause 8.2.9.10A indicating the extended EPS QoS of the default S2b bearer of the PDN connection;

c) the ePDG may include an TFT Notify payload as specified in clause 8.2.9.11 indicating the TFT of the S2b bearer of the PDN connection; and

d) if the S2b bearer is the default S2b bearer:

1) the ePDG may include an APN_AMBR Notify payload as specified in clause 8.2.9.13 indicating the APN-AMBR of the PDN connection; and

2) if the APN_AMBR Notify payload is included, the ePDG may include an EXTENDED_APN_AMBR Notify payload as specified in clause 8.2.9.14 indicating the extended APN-AMBR of the PDN connection.

Upon receiving a INFORMATIONAL response message without an IKEv2 notify payload indicating an error, the ePDG shall accept the S2b bearer modification.

Upon receiving a INFORMATIONAL response message with an IKEv2 notify payload indicating an error, the ePDG shall reject the S2b bearer modification.

7.4.6.3.6 ePDG initiated IPSec ESP tunnel rekeying

Upon receiving a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, for a CREATE_CHILD_SA request message sent in the IKE SA of the PDN connection, with a REKEY_SA Notify payload indicating an ePDG’s ESP SPI bound to an S2b bearer of the PDN connection, the ePDG shall set the ePDG’s ESP SPI bound to the S2b bearer to the ePDG’s ESP SPI created by the CREATE_CHILD_SA request/response pair and shall set the UE’s ESP SPI bound to the S2b bearer to the UE’s ESP SPI created by the CREATE_CHILD_SA request/response pair.

7.4.6.3.7 UE initiated IPSec ESP tunnel rekeying

Upon receiving a CREATE_CHILD_SA request message in the IKE SA of the PDN connection, with a REKEY_SA Notify payload indicating an UE’s ESP SPI bound to an S2b bearer of the PDN connection, if the ePDG sends a CREATE_CHILD_SA response message without an IKEv2 notify payload indicating an error, the ePDG shall set the ePDG’s ESP SPI bound to the S2b bearer to the ePDG’s ESP SPI created by the CREATE_CHILD_SA request/response pair, and shall set the UE’s ESP SPI bound to the S2b bearer to the UE’s ESP SPI created by the CREATE_CHILD_SA request/response pair.

7.4.6.4 User plane procedures

7.4.6.4.1 General

Parent clause of the present clause describe user plane procedures for the IKEv2 multiple bearer PDN connectivity.

7.4.6.4.2 Downlink IP packet handling

The ePDG shall forward a downlink IP packet received via an S2b bearer of the PDN connection using an UE’s ESP SPI bound to the S2b bearer. The ePDG shall use the QCI of S2b bearer via which the downlink packet was received to derive the DSCP value for downlink packets and set the DSCP field as specified in IETF RFC 2474 [75] of the outer IP header of the ESP packet.

NOTE: The ePDG can map QCI to DSCP value, for example, by using the mapping between standardized QCI values and Release 99 3GPP QoS parameter values specified in 3GPP TS 23.401 [4] table E.3, and the mapping between Release 99 3GPP QoS parameter values and DSCP values specified in IEEE Std 802.11 [57] table R-1.

7.4.6.4.3 Uplink IP packet handling

The ePDG shall forward an uplink IP packet received via an ePDG’s ESP SPI bound to an S2b bearer of the PDN connection using the S2b bearer.