4.5 High Level Functions

23.4023GPPArchitecture enhancements for non-3GPP accessesRelease 18TS

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

4.5.1 PDN GW Selection Function for Non-3GPP Accesses for S2a and S2b

PDN Gateway selection for non-3GPP accesses uses similar mechanisms as defined in TS 23.401 [4], with the following modification:

– The PDN Gateway selection function interacts with the 3GPP AAA Server or 3GPP AAA Proxy and uses subscriber information provided by the HSS to the 3GPP AAA Server. The HSS shall include the UE Usage Type in the UE’s subscription information if any and, if included, the ePDG/TWAN shall select the PDN GW as described in TS 23.401 [4], clause 4.3.25.1. To support separate PDN GW addresses at a PDN GW for different mobility protocols (PMIP, MIPv4 or GTP), the PDN GW Selection function takes mobility protocol type into account when deriving PDN GW address by using the Domain Name Service function.

During the initial authorization, PDN Gateway selection information for each of the subscribed PDNs is returned to the ePDG or the Trusted Non-3GPP Access Network. The PDN Gateway selection information includes:

– The PDN GW identity, which is a logical name (FQDN) or IP address and an APN; or

– an APN and an indication whether the allocation of a PDN GW from the visited PLMN is allowed or a PDN GW from the home PLMN shall be allocated.

This enables the entity requiring the IP address of the PDN Gateway to proceed with selection as per the procedures defined in TS 23.401 [4], clauses 4.3.8.1 and 4.3.25.1. Once the selection has occurred, the PDN Gateway registers its association with a UE and the APN with the AAA/HSS by sending PDN GW identity, that is either its IP address (e.g. if it has a single IP address for all the mobility protocols it supports or if it only supports one mobility protocol) or its FQDN (e.g. if it has multiple IP addresses for the mobility protocols it supports), as well as information that identifies the PLMN in which the PDN GW is located, to the 3GPP AAA Server or AAA Proxy only when the Access Technology Type is non-3GPP. For 3GPP access types, the MME/S4-SGSN updates the HSS with the selected PDN GW identity, as well as information that identifies the PLMN in which the PDN GW is located, according to TS 23.401 [4]/TS 23.060 [21]. This permits the HSS and 3GPP AAA Server or Proxy to provide the association of the PDN Gateway identity and the related APN for the UE subsequently.

NOTE 1: The format of the information that identifies the PLMN in which the PDN GW is located is defined in stage 3 specifications.

In the case that a UE already has assigned PDN Gateway(s), the PDN GW identity for each of the already allocated PDN Gateway(s), as well as information that identifies the PLMN in which the PDN GW is located, are returned by the 3GPP AAA Server or Proxy during the authorization step. This eliminates the need to repeat PDN Gateway selection for the PDNs the UE is already connected with. The information about the PLMN in which the PGW is located allows the receiving entity to determine an appropriate APN-OI. The ePDG may use this information to determine the S2b protocol type (PMIP or GTP). The TWAN may also use this information to determine the S2a protocol type (PMIP or GTP).

Upon mobility between 3GPP and non-3GPP accesses, PDN Gateway selection information for the subscribed PDNs the UE is not yet connected with is returned to the target access system as done during initial attachment. For the PDNs the UE is already connected with transfer of PDN GW information takes place as defined below:

– If a UE attaches to a non-3GPP access and it already has assigned PDN Gateway(s) due to a previous attach in a 3GPP access, the HSS provides the PDN GW identity, as well as information that identifies the PLMN in which the PDN GW is located, for each of the already allocated PDN Gateway(s) with the corresponding PDN information to the 3GPP AAA server over the SWx reference point.

– If a UE attaches to a 3GPP access and it already has an assigned PDN Gateway(s) due to a previous attach in a non-3GPP access, the HSS provides the PDN GW identity, as well as information that identifies the PLMN in which the PDN GW is located, for each of the already allocated PDN Gateway(s) with the corresponding PDN information to the MME over the S6a reference point and/or S4-SGSN over the S6d reference point.

The HSS receives the PDN GW identity for each of the selected PDN GWs and the corresponding PDN information for a given UE, from both the 3GPP AAA Server and also from the MME/S4-SGSN, depending on the currently in-use access. The HSS is responsible for the storage of the selected PDN GW identity as described in clause 12.

The ePDG may be configured with the S2b protocol variant(s) on a per HPLMN granularity, or may retrieve information regarding the S2b protocol variants supported by the PDN GW (PMIP or/and GTP) from the Domain Name Service function.

The TWAN may be configured with the S2a protocol variant(s) on a per HPLMN granularity, or may retrieve information regarding the S2a protocol variants supported by the PDN GW (PMIP or/and GTP) from the Domain Name Service function.

NOTE 2: The location of the PDN GW selection function depends upon the type of S2 interface used for attachment and the IP mobility mechanism being used.

– For PMIPv6 on S2a/b, the entity requesting the PDN Gateway is the entity acting as Mobile Access Gateway (MAG).

– For GTP on S2b, the entity requesting the PDN Gateway is the ePDG.

– For GTP on S2a, the TWAG, described in clause 16.1.2, is requesting the PDN Gateway.

– For the PMIP-based S8-S2a/b chained cases, the PDN GW information is sent together with the selected Serving GW address from the 3GPP AAA proxy to the entity acting as MAG in the non-3GPP access network during access authentication and authorization. The PDN GW selection mechanism is the same as in the unchained case. The MAG function of the non-3GPP access network conveys the PDN GW address to the Serving GW as part of the PMIPv6 PBU message.

– For MIPv4 FA mode on S2a, the entity requesting the PDN Gateway is the entity that plays the role of the FA.

4.5.1a PDN GW Selection Function for eHRPD with SIPTO support

In order to select the appropriate PDN GW for SIPTO in eHRPD access via HSGW, the PDN GW selection function needs to support DNS mechanism that allows selection of a PDN GW which is close to the HSGW for the UE. Details related to SIPTO support for eHRPD access is defined in 3GPP2 X.S0057 [51].

4.5.2 PDN GW Selection Function for S2c

For the S2c reference point, the UE needs to know the IP address of the PDN Gateway for the PDN the UE wants to connect to. This address is made known to the UE using one of the following methods:

1) Via PCO at the attach procedure or UE requested PDN Connectivity procedure, for 3GPP access (as defined in TS 23.401 [4]) or trusted non-3GPP access (if supported).

2) Via IKEv2 during tunnel setup to ePDG. For a UE’s initial Attach, during the IKEv2 tunnel establishment procedure on the SWu interface (between UE and ePDG):

– For non-roaming case, the 3GPP AAA Server selects the HA (PDN GW) which is close to the ePDG and sends the HA (PDN GW) FQDN or IP address to the ePDG;

– For roaming with local breakout case, the 3GPP AAA Proxy selects the HA (PDN GW) which is close to the ePDG and sends the HA (PDN GW) FQDN or IP address to the ePDG;

The HA (PDN GW) FQDN or IP address are then forwarded to the UE by the ePDG.

NOTE 1: Whether the selected PDN GW is closer to the UE than other PDN GW depends on the network configurations and operations, it may be geographically/topologically closer or less IP hops.

3) If the IP address of the PDN GW is not received using options 1-2 above and if the UE knows that the HA is in the PDN where the UE is attached to then the UE shall request a PDN Gateway address via DHCP IETF RFC 6611 [41].

4) If the IP address of the PDN GW is not delivered using options 1-3 above the UE can interact directly with the Domain Name Service function by composing a FQDN corresponding to the PDN.

For the S2c reference point, the network can force a reallocation of the PDN Gateway selected upon initial DSMIPv6 bootstrapping for the PDN the UE wants to connect to. This may happen if one of the following situations occurs:

– The UE has done initial network attachment on an access system supporting network-based mobility, but the PDN Gateway discovered by the UE for the S2c reference point is different from the PDN Gateway allocated at initial network attachment. In this case, to enable IP address preservation based on DSMIPv6 upon inter-system mobility, the network must trigger a PDN Gateway reallocation for the S2c reference point, to re-direct the UE to the PDN Gateway that was selected upon initial network attachment.

– The UE has done initial network attachment over S2c and, relying on DNS, has discovered a sub-optimal PDN Gateway. In this case, based on operator’s policies, the network can optionally trigger a PDN Gateway reallocation to re-redirect the UE to a PDN Gateway that can provide better performance.

PDN Gateway reallocation for the S2c reference point is triggered by the AAA/HSS during DSMIPv6 bootstrapping. For a UE’s initial Attach, if the UE has selected a initial PDN GW and initiated DSMIPv6 bootstrapping:

– In non-roaming scenario, the PDN GW reports the UE Care of Address (allocated by the WLAN AN or ePDG) to the 3GPP AAA Server. According to the UE CoA and the pre-configuration, the 3GPP AAA Server finds there are other PDN GW(s) which are close to the UE, then it can initiate a PDN GW reallocation procedure (Clause 6.10 "PDN GW reallocation upon attach on S2c") to redirect the UE to the other PDN GW.

– In roaming with local breakout scenario, the PDN GW reports the UE Care of Address (allocated by the WLAN AN or ePDG) to the 3GPP AAA Proxy. According to the UE CoA and the pre-configuration, the 3GPP AAA Proxy finds there are other PDN GW(s) which are close to the UE, then it can initiate a PDN GW reallocation procedure (clause 6.10 "PDN GW reallocation upon attach on S2c") to redirect the UE to the other PDN GW.

NOTE 2: Whether the selected PDN GW is closer to the UE than other PDN GW depends on the network configurations and operations, it may be geographically/topologically closer or less IP hops.

NOTE 3: This reallocation is initiated only if the UE has not yet successfully established a binding with the selected PDN GW.

The HSS receives the values of identity(ies) of all allocated PDN GWs and the corresponding PDN information for a given UE from the 3GPP AAA. The HSS is responsible for the storage of PDN GW identity information.

4.5.3 Serving GW Selection Function for Non-3GPP Accesses

The S‑GW selection function allocates an S‑GW that acts as a local anchor for non-3GPP access in the case of S8-S2a/b chained roaming. Whether S8-S2a/b chaining should be used is decided by 3GPP AAA Proxy based on per-HPLMN configuration.

The Serving GW selection function is located in 3GPP AAA Proxy. If an S‑GW is needed for non-3GPP access in the visited network, the 3GPP AAA proxy will select an S‑GW for the UE during initial attach or handover attach. The 3GPP AAA proxy shall send the selected S‑GW address to the MAG function of the Trusted non-3GPP IP access or ePDG in the chained S8-S2a/b scenarios.

There is no mechanism standardized for S‑GW address preservation for handover between 3GPP and non-3GPP in S2/S8 chained case within this Release of the specification.

4.5.4 ePDG Selection

4.5.4.1 General

The UE performs ePDG selection based on a set of information configured by the HPLMN in the UE, and based on the UE’s knowledge of the PLMN it is attached to.

A UE connected to one or multiple PDN GWs uses a single ePDG.

4.5.4.2 ePDG FQDNs Construction

When the UE attempts to construct an FQDN for selecting an ePDG in a certain PLMN-x (either a VPLMN or the HPLMN), then the UE shall construct one of the following FQDN formats:

– Operator Identifier FQDN: The UE constructs the FQDN by using the PLMN-x ID as the Operator Identifier.

– Tracking/Location Area Identity FQDN: The UE constructs the FQDN by using the identity of the Tracking Area/Location Area it is located in (i.e. based on PLMN-x ID and TAC/LAC). The Tracking/Location Area Identity FQDN is used to support location-specific ePDG selection within a PLMN.

The ePDG FQDN formats are specified in TS 23.003 [16].

The UE selects one of the above FQDN formats as follows:

a) If the UE attempts to select an ePDG in the registered PLMN and the UE is configured to use for this PLMN the Tracking/Location Area Identity FQDN as defined in point 2) of clause 4.5.4.3; and

b) the UE knows the TAI/LAI of the area the UE it is located in (e.g. the TAI/LAI from the most recent Attach or TAU/LAU),

then the UE constructs a Tracking/Location Area Identity FQDN. Otherwise the UE constructs the Operator Identifier FQDN.

Also, the UE constructs the Operator Identifier FQDN as a fallback in the case of failure of DNS resolution of a Tracking/Location Area Identity based FQDN.

4.5.4.3 UE Configuration By HPLMN

The UE may be configured (e.g. via H-ANDSF, USIM, etc.) by the HPLMN with the following configuration, whose usage is defined in clause 4.5.4.4:

1) ePDG identifier configuration: It contains the FQDN or IP address of an ePDG in the HPLMN.

NOTE: The FQDN in the ePDG identifier configuration may have a different format than the one described in clause 4.5.4.2.

2) ePDG selection information: It contains a prioritized list of PLMNs which are preferred for ePDG selection. It also indicates if selection of an ePDG in a PLMN should be based on Tracking/Location Area Identity FQDN or on Operator Identifier FQDN, as specified in clause 4.5.4.4. The list of PLMNs may include the HPLMN.

The PLMNs included in the ePDG selection information are PLMNs that have roaming agreements with HPLMN for interworking with untrusted WLANs.

The ePDG selection information may include an "any PLMN" entry, which matches any PLMN the UE is attached to except the HPLMN. If the ePDG selection information contains both the "any PLMN" and the PLMN the UE is attached to, the UE shall give precedence to the latter.

4.5.4.4 UE ePDG Selection Procedure

The UE shall perform ePDG selection by executing the steps below. Unless otherwise specified, when the UE attempts to select an ePDG, the UE shall construct an FQDN for this ePDG as specified in clause 4.5.4.2 and shall use the DNS server function to obtain the IP address(es) of this ePDG.:

1) The UE shall attempt to determine the country it is located in. This is determined by implementation-specific methods not defined in this specification. If the UE cannot determine the country it is located in, the UE shall stop the ePDG selection.

2) If the UE determines to be located in its home country, then:

a) The UE shall select an ePDG in the HPLMN. If the ePDG selection information contains the HPLMN, the UE shall construct an FQDN as specified in clause 4.5.4.2. If the ePDG selection information does not contain the HPLMN and the UE is configured with the ePDG identifier defined in bullet 1) of clause 4.5.4.3, then the UE shall either use the configured FQDN and use the DNS server function to obtain the IP address(es) of the ePDG(s) in the HPLMN, or the UE shall use the configured IP address. Otherwise, the UE shall construct an Operator Identifier FQDN and shall use the DNS server function to obtain the IP address(es) of the ePDG(s) in the HPLMN.

b) If the UE cannot select an ePDG in the HPLMN, then the UE shall stop the ePDG selection.

3) If the UE determines to be located in a country other than its home country (called the visited country), then:

a) If the UE is registered via 3GPP access to a PLMN and this PLMN matches an entry in the ePDG selection information, then the UE shall select an ePDG in this PLMN. If the UE fails to connect to an ePDG in this PLMN, the UE shall select an ePDG by performing the DNS procedure specified in clause 4.5.4.5.

b) In all other cases, (e.g. when the UE is not configured with the ePDG selection information, or the UE is registered via 3GPP access to a PLMN but this PLMN does not match an entry in the ePDG selection information, or the UE is not registered via 3GPP access to any PLMN), the UE shall select an ePDG by performing the DNS procedure specified in clause 4.5.4.5.

4.5.4.5 ePDG Selection with DNS-based Discovery of Regulatory Requirements

The UE shall perform ePDG selection according to the following procedure when the UE determines to be located in a country other than its home country (called the visited country) and when the conditions defined in clause 4.5.4.4 apply.

The UE shall perform a DNS query using Visited Country FQDN, as specified in TS 23.003 [16] to determine if the visited country mandates the selection of ePDG in this country as specified below.

1) If the DNS response contains no records, then the UE determines that the visited country does not mandate the selection of ePDG in this country. In this case:

a) If the ePDG selection information contains one or more PLMNs in the visited country, the UE shall select an ePDG in one of these PLMNs. The UE shall consider these PLMNs based on their priorities in the ePDG selection information. If the UE fails to connect to an ePDG in one or more of these PLMNs, the UE shall select an ePDG in the HPLMN according to bullet 1b below.

b) Otherwise, including the case when the UE fails to connect to an ePDG according to bullet 1a above, the UE shall select an ePDG in the HPLMN. If the UE is configured with the ePDG identifier defined in bullet 1) of clause 4.5.4.3, then the UE shall either use the configured FQDN and use the DNS server function to obtain the IP address(es) of the ePDG(s) in the HPLMN, or the UE shall use the configured IP address. Otherwise, the UE shall construct an Operator Identifier FQDN as specified in clause 4.5.4.2 and shall use the DNS server function to obtain the IP address(es) of the ePDG(s) in the HPLMN.

2) If the DNS response contains one or more records, then the UE determines that the visited country mandates the selection of ePDG in this country. Each record in the DNS response shall contain the identity of a PLMN in the visited country which may be used for ePDG selection. In this case:

a) If the UE is registered via 3GPP access to a PLMN which is included in the DNS response, then the UE shall select an ePDG in this PLMN. If the UE fails to connect to an ePDG in this PLMN, then the UE shall select an ePDG in one of the other PLMNs included in the DNS response as specified in bullet 2b below.

b) If the UE is registered via 3GPP access to a PLMN which is not included in the DNS response or the UE is not registered via 3GPP access to any PLMN or the UE fails to connect to an ePDG according to bullet 2a above, then the UE shall select an ePDG in one of the PLMNs included in the DNS response as follows:

The UE shall select one of the PLMNs included in the DNS response based on the prioritized list of PLMNs in the ePDG selection information (i.e. the UE shall select first the highest priority PLMN in the ePDG selection information that is contained in the DNS response). If the ePDG selection information does not contain any of the PLMNs in the DNS response or the UE is not configured with the ePDG selection information, or the UE was not able to connect to an ePDG in the PLMNs included in the ePDG selection information and in the DNS response, then the UE shall select a PLMN included in the DNS response based on its own implementation means.

c) If the UE cannot select an ePDG in any of the PLMNs included in the DNS response, then the UE shall stop the ePDG selection.

3) If the UE does not receive a DNS response, then the UE shall stop the ePDG selection.

After the UE selects a PLMN for ePDG selection as specified above, UE shall construct an Operator Identifier FQDN for the selected PLMN and shall use the DNS server function to obtain the IP address(es) of the ePDG(s) in this PLMN.

4.5.4a ePDG Selection for Emergency Services

4.5.4a.1 General

UE initiates the ePDG selection for emergency services when it detects a user request for emergency session and determines that WLAN shall be used for the emergency access.

Unless the UE is attached to an ePDG that has indicated support for the emergency services and is located in the same country where the UE is currently located, the UE terminates the exisitng ePDG connection, if any, and performs the emergency ePDG selection procedure described in clause 4.5.4a.2. Otherwise, the UE should reuse the existing ePDG connection.

4.5.4a.2 Emergency ePDG Selection Procedure

The ePDG selection for emergency services shall use the ePDG selection procedure for non-emergency services specified in clause 4.5.4, with the following modifications:

1) Separately configured ePDG Emergency Identifier shall be used instead of the ePDG Identifier specified in clause 4.5.4.3;

2) For a UE equipped with a UICC, the Operator Identifier Emergency FQDN and the Tracking/Location Area Identity Emergency FQDN (specified in TS 23.003 [16]) shall be constructed based on the rules specified in clause 4.5.4.2 and shall be used instead of the Operator Identifier FQDN and the Tracking/Location Area Identity FQDN respectively;

3) The DNS-based discovery of the regulatory requirements described in clause 4.5.4.5 in the context of emergency ePDG selection shall be based on a Visited Country Emergency FQDN (specified in TS 23.003 [16]), instead of the Visited Country FQDN;

4) If the UE is not equipped with a UICC, the UE shall perform the emergency ePDG selection procedure without using the ePDG selection configuration data (the ePDG Emergency Identifier and the ePDG selection information), i.e., the UE shall consider those data as not configured and the UE may construct the Operator Identifier FQDN format based on a PLMN ID obtained via implementation specific means.

NOTE 1: In case of authentication failure during an emergency ePDG selection attempt, or when the UE is not equipped with a UICC, the ePDG selection attempt may result in unauthenticated emergency attachment, if allowed by local policies.

NOTE 2: The ePDG access (for both the emergency and non-emergency services) may be rejected by the network based on local policies related to availability of emergency services in specific geographic areas.

4.5.5 PCRF Selection

In addition to the PDN-GW and AF being served by one or more PCRF nodes in a HPLMN and, where applicable , in VPLMN as in TS 23.401 [4], the following nodes in this specification also are served by PCRF:

– Serving GW;

– Elements in trusted non-3gpp access;

– ePDG.

Selection of a PCRF by nodes served by PCRF in this specification, is the same as that in specified in TS 23.203 [19].

4.5.6 DSMIPv6 Home Link Detection Function

The DSMIPv6 Home Link Detection Function is used by the UE to detect if, for a specific PDN, an access interface is the Home Link from a DSMIPv6 perspective.

It is up to the UE configuration to decide when to trigger the home link detection function for a specific PDN connection, except that homelink detection for an access interface shall be performed before sending any DSMIPv6 Binding Update via that access interface.

The UE detects the home link comparing the IPv6 prefix associated with a specific access system of the UE , and the Home Network Prefix (HNP) associated with the PDN connection. If there is a match, the UE detects it is in the home link for this specific PDN over the access interface. Otherwise, the UE detects it is not in the home link for this specific PDN over the access interface.

Home Network Prefix (HNP) may be assigned in a 3GPP access via PCO during 3GPP attach, if supported by the UE, or via IKEv2.

NOTE: The UE knows the IPv6 prefix associated with a specific access system interface via IP address allocation mechanisms applied in that access system.

The UE knows the HNP associated with a specific PDN from the IPsec security association bootstrap (see clause 6.3, step 4) or from PCO received in 3GPP attach.

4.5.7 IMS Emergency Session Support

4.5.7.1 Overview

Support for IMS Emergency Session for E-UTRAN access connected to the EPC with GTP-based S5/S8 is covered in TS 23.401 [4]. Corresponding changes that apply for PMIP-based S5/S8 interface are covered in clause 5 of this specification.

For this Release of the specification, IMS Emergency Session Support for non-3GPP accesses connected to EPC is limited to:

– Support of handover of emergency sessions from E‑UTRAN access to HRPD access and is covered in clause 9 of this specification with an overview provided in clause 9.2.2.

NOTE: Support for IMS emergency sessions over HRPD access connected to EPC is not covered in this specification.

– Support of IMS Emergency Session Support over WLAN access to EPC as described in clause 4. 5.7.2

4.5.7.2 IMS Emergency Session Support over WLAN access to EPC

4.5.7.2.1 Introduction

This clause provides an overview about the EPC functionality for emergency PDN connections used to support IMS Emergency Session over WLAN untrusted or trusted access to EPC defined in TS 23.167 [83]. The specific functionality is described in the affected procedures and functions of this specification. For discrepancies between this overview clause and the detailed procedure and function descriptions the latter take precedence.

UEs request a PDN Connection for emergency services (also called an emergency PDN connection) when they are aware they need to establish an IMS emergency session.

The UE shall not issue an emergency session over WLAN access to EPC if the emergency session can be established via 3GPP access.

In this Release of the specification, the same four behaviours of IMS emergency session support as identified in TS 23.401 [4] clause 4.3.12 are applicable.

To get EPC access for emergency services in case of untrusted WLAN, the UE shall select an ePDG that supports emergency services as specified in clause 4.5.4a. Then, if a new ePDG is selected, the UE shall execute the procedure of Initial attach for S2b emergency services described in clause 7.2.5. Otherwise, if an existing ePDG connection is reused, the UE shall perform the UE-initiated Connectivity to Additional PDN to Emergency Service PDN connectin described in clause 7.6.3.

An ePDG/TWAG that supports emergency services is configured with Emergency Configuration Data that are applied to all PDN Connections for emergency services. The Emergency Configuration Data contain the Emergency APN which is used to derive a PDN GW, the statically configured PDN GW for the Emergency APN and optionally a fallback statically configured PDN GW, and may also contain information on the default QoS to apply to a PDN Connection for emergency services (as defined in clause 4.5.7.2.4).

The following procedures apply for emergency PDN connections for untrusted WLAN case:

– procedures defined in clause 7.4.3 ("UE/ePDG-initiated Detach Procedure and UE-Requested PDN Disconnection");

– procedures defined in clause 7.6 ("UE-initiated Connectivity to Additional PDN");

– procedures defined in clause 7.9.2 ("PDN GW initiated Resource Allocation Deactivation");

– procedures defined in clause 7.10 ("Dedicated S2b bearer activation");

– procedures defined in clause 7.11.1 ("PDN GW initiated bearer modification");

– procedures defined in clause 8 ("Handovers without Optimizations Between 3GPP Accesses and Non-3GPP IP Accesses").

As part of these procedures, the UE local IP address and optionally UDP or TCP source port number (if NAT is detected) are reported from ePDG to the PDN GW. When Access Network Information reporting has been set by the PCRF, the UE local IP address and optionally UDP or TCP source port number (if NAT is detected) is reported to the PCRF.

NOTE: The UE local IP address is used by the UE for sending all IKEv2, RFC 5996 [9], messages and as the source address on the outer header of the IPsec tunnel to the ePDG.

To get EPC access for emergency services in case of trusted WLAN, the UE shall select a Trusted WLAN that supports emergency services. This is defined in clause 4.8.2b. Then the UE executes the procedure of Initial attach for S2a emergency services described in clause 16.2.1a

The following procedures apply for emergency PDN connections for trusted WLAN case:

– procedures defined in clause 16.3 ("Detach and PDN disconnection in WLAN on S2a");

– procedures defined in clause 16.4 ("PDN GW initiated Resource Allocation Deactivation in WLAN on S2a");

– procedures defined in clause 16.5 ("Dedicated bearer activation in WLAN on GTP S2a");

– procedures defined in clause 16.6.1 ("PDN GW Initiated Bearer Modification");

– procedures defined in clause 16.7.1.1 ("UE/TWAN Initiated Detach Procedure in WLAN on GTP S2a");

– procedures defined in clause 16.7.2.1 ("UE/TWAN Initiated Detach Procedure in WLAN on PMIP S2a");

– procedures defined in 16.8 ("UE Initiated PDN connectivity request procedure in WLAN on S2a for Multi-connection Mode");

– procedures defined in clause 16.9 ("UE/TWAN Initiated PDN disconnection for Multi-connection Mode");

– procedures defined in clause 16.10 ("Handover procedure from 3GPP access to WLAN on S2a");

The emergency PDN connection is not a subscribed service. Thus procedures related with HSS Initiated Subscribed QoS Modification in clause 7.11.2, procedures related with HSS Initiated Bearer Modification in clauses 16.6.2 and 16.7.2.2 or procedures related with "HSS/AAA-initiated Detach Procedure" in clauses 7.4.4, 16.3.1.2 and 16.3.2.2 do not apply to emergency PDN connections.

Procedures related with S2c do not apply to emergency PDN connections.

4.5.7.2.2 Architecture Reference Model for Emergency Services

In this Release of the specification, both the non-roaming architecture defined in Figure 4.2.2-1 and the roaming architecture defined in Figure 4.2.3-1 apply for emergency services.

4.5.7.2.3 PDN GW selection function for Emergency Services

The PDN GW selection does not depend on subscriber information in the HSS since emergency service support is not a subscribed service but a local service. Upon reception from the UE indication that a PDN connection for emergency services needs to be established, the ePDG/TWAG looks up its configured Emergency Configuration Data. The Emergency Configuration Data contains the Emergency APN to be used to derive a PDN GW, or may also contain the statically configured PDN GW for the Emergency APN.

When a PDN GW is selected based on the Emergency APN, the PDN GW selection function described in clause 4.3.8.1 of TS 23.401 [4] for normal bearer services is applied to the Emergency APN. The PDN GW selection function shall always derive a PDN GW in the local PLMN.

This functionality is used by the Initial Attach procedure for emergency services as described in clause 7.2.5 for untrusted WLAN and clause 16.2.1a for trusted WLAN.

4.5.7.2.4 QoS for Emergency Services

The Default QoS values used over S2b/S2a for establishing emergency PDN connections are configured in the Emergency Configuration Data.

NOTE: The WLAN network may support traffic priority management based on DSCP marking or may support WFA WMM profile specification, however the mapping between the 3GPP PCC QoS and the DSCP marking in ePDG/TWAG and the control of QoS marking by UE for uplink traffic are not defined in this release of the specification.

4.5.7.2.5 PCC for Emergency Services

The same mechanisms than defined for 3GPP access in clause 4.3.12.6 of TS 23.401 [4] apply.

4.5.7.2.6 IP Address Allocation

The same mechanisms than defined for 3GPP access in clause 4.3.12.8 of TS 23.401 [4] apply.

4.5.7.2.7 Handling of PDN Connections for Emergency Bearer Services

The same mechanisms as those defined for 3GPP access in clause 4.3.12.9 of TS 23.401 [4] apply with the only difference being that it is the ePDG/TWAG (and not the MME) that shall reject any additional emergency PDN Connection requests.

4.5.7.2.8 Network provided WLAN Location Information

In the case of trusted WLAN Access, WLAN Location Information is provided as specified in clause 16.1.7.

In the case of untrusted WLAN access, WLAN Location Information is provided as follows:

When as part of procedures for Authentication and Authorization on an Access Point based on USIM credentials, the WLAN Access Network provides WLAN Access Network location information to the 3GPP AAA server that it considers as network provided location, the 3GPP AAA server stores this information and provides it to the ePDG at the SWm Authentication and or Autorization procedure or upon request of the ePDG.

NOTE 1: It is up to local 3GPP AAA server policies to decide whether location information received from the WLAN access network may be considered as network provided location. The definition of the policies used by 3GPP AAA server is outside the scope of 3GPP.

This location information is called WLAN Location Information and contains the same information as is contained in the TWAN Identifier defined in clause 16.1.7. The Age of the WLAN Location information is provided in conjunction with the WLAN Location information.

NOTE 2: In cases where an UE may within an area move between AP(s) without the 3GPP AAA server being notified of this mobility, the WLAN Location Information can only refer to the first AP used by the UE within the area.

The 3GPP AAA server shall update its storage of WLAN Location Information associated with an UE when it receives WLAN Access Network location information from a WLAN AN that it considers as trustworthy for network provided location. The 3GPP AAA server shall remove its storage of WLAN Location Information associated with an UE when it becomes aware that the WLAN session of the UE is terminated or when it receives WLAN Access Network location information from a WLAN AN that it considers as not trustworthy for network provided location.

The ePDG shall store WLAN Location Information associated with an UE when it receives WLAN Access Network location information from the 3GPP AAA server. The ePDG shall remove its storage of WLAN Location Information associated with an UE when it receives from the 3GPP AAA server an indication that no WLAN Access Network location information is available for this UE.

The WLAN Location Information information and its Age, when available, are propagated by the ePDG to the PDN GW and then via PCC as defined in TS 23.203 [19]. This takes place at the UE-initiated connectivity to an initial PDN connection (Attach Procedure), at the UE-initiated connectivity to an additional PDN connection or, as described below, when the ePDG needs to send User Location Information about an already established PDN connection.

When the AAA server has sent WLAN Location Information at the UE-initiated connectivity to an initial (Attach Procedure) or additional PDN connection, and when later the ePDG needs to send User location Information towards the PDN GW over S2b, the ePDG may initiate a WLAN Location Information Request to fetch the most up to date WLAN Location Information in conjunction with the age of this Information.

Figure 4.5.7.2.8-1: EPDG retrieval of WLAN Location Information

0) When the 3GPP AAA server detects that the UE has moved between WLAN AN, it locally updates or removes the WLAN Location Information information and its Age it stores for the UE.

1) A procedure is triggered that requires the ePDG to provide User Location Information over S2b for an already established PDN connection. The corresponding procedures are:

– 7.4.3 UE/ePDG-initiated Detach Procedure and UE-Requested PDN Disconnection with GTP on S2b.

– 7.9.2 PDN GW initiated Resource Allocation Deactivation with GTP on S2b.

– 7.10 Dedicated S2b bearer activation with GTP on S2b.

– 7.11 S2b bearer modification with GTP on S2b.

2) When the AAA server has sent WLAN Location Information at the set-up of a SWm session and the ePDG has detected a change of the outer IP address of the UE, the ePDG initiates a WLAN Location Information Request (IMSI) towards the 3GPP AAA server.

3) The 3GPP AAA server provides a WLAN Location Information Answer that may contain WLAN location information and WLAN location information Age or an indication that no WLAN location information is available. The ePDG replaces any WLAN location information andWLAN location information Age it may have stored beforehand by the information received from the 3GPP AAA server. When the WLAN Location Information Answer contains an indication that no WLAN location information is available, the ePDG removes any WLAN location information and WLAN location information Age it may have stored beforehand about the UE.

4) The ePDG issues S2b signalling with User Location Information. The User Location Information shall include UE local IP address and optionally UDP or TCP source port number (if NAT is detected). The User Location Information includes WLAN Location Information (and its Age) only when the ePDG has such information currently available about the UE. When the PDN GW receives no WLAN Location Information from the ePDG it shall delete any such information it may have stored for the PDN connection.

5) If requested by the PCRF the PDN GW forwards to the PCRF following information extracted from User Location Information it may have received from the ePDG:

– The UE local IP address and optionally UDP or TCP source port number (if NAT is detected).

– WLAN location information in conjunction with the Age of this information,

When the PCRF receives no WLAN location information from the PDN GW within User Location Information the WLAN location information is considered as not any longer valid.

4.5.7.2.9 Determination of location

If the UE needs to provide location information when requesting an emergency session, the UE may determine its location by using its own implementation-specific means (e.g. by using its GPS receiver). If, however, the UE cannot determine its location by its own means, the UE may retrieve its location from a WLAN AP, prior or after association with the AP, by requesting the Civic Location ANQP element, the Geospatial Location ANQP element or both as specified in IEEE Std 802.11-2012 [64]), using ANQP procedures described in HS2.0 Rel‑2 specification [75].

NOTE: Location determination based on WLAN ANQP procedures should be considered as less reliable than e.g. location determination based on GPS receiver.

4.5.7.2.10 Support of PS handover with 3GPP EPC

Seamless PS handover between WLAN and 3GPP EPC is supported if the following conditions are satisfied:

– For UEs without UICC or with an unauthenticated IMSI and for authenticated roaming UEs, the ePDG/TWAG is configured with a static PDN GW identity and optionally a fallback PDN GW identity as part of the Emergency Configuration Data.

– When the UE initiates an Emergency Attach with handover indication to the MME, the MME uses the static PDN GW identity locally configured instead of querying the HSS as described in TS 23.401 [4].

– For authenticated non-roaming UEs, based on operator policy, the ePDG/TWAG may select a PDN GW based on DNS look up for the emergency APN, which is configured in the Emergency Configuration Data. In such case:

– During the initial establishment of the PDN connection for emergency services, the "PDN GW currently in use for emergency services", which comprises the PDN GW address and an indication that the PDN connection is for emergency services is provided to the HSS by the PDN GW via the 3GPP AAA server over S6b and SWx as described in clause 7.2.5 for untrusted WLAN and clauses 16.2.1a and 16.8.1 for trusted WLAN and by the MME over S6a as described in TS 23.401 [4]. The HSS stores it as a specific data "PDN GW currently in use for emergency services", not associated with any APN. If the HSS detects that the UE is attached to the other access (3GPP or WLAN), the HSS updates the corresponding serving node (MME, ePDG or TWAN) with the "PDN GW currently in use for emergency services".

– During the handover procedure from WLAN to 3GPP EPC, the "PDN GW currently in use for emergency services" information is provided by the HSS as part of the subscription information sent to the MME over S6a as described in clause 8.6.1.1 for untrusted WLAN and clause 16.11 for trusted WLAN.

– During the handover procedure from 3GPP EPC to WLAN, the "PDN GW currently in use for emergency services" information is provided by the HSS as part of the subscription information sent to the ePDG / TWAG via the 3GPP AAA server over SWx and SWm / STa as described in clause 8.6.2.1 for untrusted WLAN and clauses 16.10.1.1 and 16.10.2.1 for trusted WLAN.

– Alternatively for non-roaming authenticated UEs, based on operator policy (e.g. the network supports handovers to/from HRPD), the ePDG/TWAG may be configured with a static PDN GW identity as part of the Emergency Configuration Data. In such case, when the UE initiates an Emergency Attach with handover indication to the MME, the MME uses the static PDN GW identity locally configured instead of querying the HSS as described in TS 23.401 [4].

4.5.8 APN congestion Control Function for eHRPD

The PDN GW may provide mechanisms for avoiding and handling overload situations for eHRPD over S2a. These include the rejection of PDN connection requests from UEs.

When performing overload control the PDN GW shall operate as specified in clause 4.3.7.5 of TS 23.401 [4].

NOTE: The words of "Bearer" in clause 4.3.7.5 of TS 23.401 [4] are replaced by "PDN connection" for eHRPD.

When receiving the rejection from the PDN GW, the HSGW shall operate as specified in clause 4.13 of the 3GPP2 X.S0057 [51].

4.5.9 GTP-C signalling based Load and Overload Control for trusted and untrusted WLAN

4.5.9.1 GTP-C load control

GTP-C Load Control feature is an optional feature which allows a GTP control plane node to send its Load Control Information to a peer GTP control plane node which the receiving GTP control plane peer node uses to augment existing PDN GW selection procedure.

GTP-C Load Control feature allows the PDN GW to send its Load Control Information to the TWAN/ePDG (for enhanced load balancing across PDN GWs during Attach or new PDN connectivity request scenarios).

This feature is supported over S2a and S2b interfaces via GTPv2 control plane protocol.

The same concepts as described in TS 23.401 [4], clause 4.3.7.1a.1 for PGW Load Control apply with the TWAN/ePDG playing a similar role as the MME/SGSN.

NOTE: Refer to clause 12 of TS 29.274 [57] for the details, such as exact format of the Load Control Information, mechanisms to discover the support of the feature by the peer node, interfaces for which this feature is applicable, APN level load control, etc.

4.5.9.2 GTP-C overload control

GTP-C Overload Control feature is an optional feature. Nodes using GTP control plane signalling may support communication of Overload Control Information in order to mitigate overload situation for the overloaded node through actions taken by the peer node(s).

This feature is supported over S2a and S2b interfaces via GTPv2 control plane protocol.

The Overload Control Information may convey information regarding the node itself and/or regarding specific APN(s) status.

GTP-C Overload Control feature allows the PDN GW to send its Overload Control Information to the TWAN/ePDG.

GTP-C Overload Control feature allows the TWAN/ePDG to send its Overload Control Information to the PDN GW.

An ePDG may apply certain restrictions towards PDN GW that have indicated overload, e.g.:

– reject PDN connection requests from the UE (e.g. Initial Attach, UE-initiated Connectivity to Additional PDN, Attach and PDN Connectivity Request at handover to Untrusted WLAN) and locally set a back-off timer. As long as the back-off timer is running, the ePDG shall reject the subsequent PDN connection requests from the UE;

– reduce/throttle messages towards the PDN GWs indicating overload status;

– apply other implementation specific mechanisms, which are outside the scope of 3GPP specifications.

A TWAN may during access authentication in Transparent Single-Connection Mode, Single-Connection Mode and during WLCP procedures in Multi-Connection Mode apply certain restrictions towards PDN GW that have indicated overload, e.g.:

– reject PDN connection requests from the UE (e.g. Initial Attach with PDN Connectivity, UE Initiated PDN connectivity request, Attach and PDN Connectivity Request at handover to Trusted WLAN) as follows:

– for Transparent Single-Connection Mode, locally set a back-off timer and prevent the UE from accessing the SSID. For any further request for the same UE and the same SSID, as long as the back-off timer is running, the TWAN prevents the UE from accessing the SSID.

NOTE 1: Some UE(s) may prohibit an AP when they fail to authenticate on this AP. The following mechanisms can help lowering the risk of having to reject an attempt to access TWAN in Transparent Single-Connection Mode:

– The TWAN reselects another PDN GW to retry PDN connection establishment, if more than one PDN GW supports the target APN,

– If possible, the TWAN rejects UEs in Single-Connection Mode and Multi-Connection Mode before rejecting UEs in Transparent Single-Connection Mode when the PDN GW(s) have indicated overload.

– for Single-Connection Mode, reject EPC access requests from the UE with a Session Management back-off timer that instructs the UE to not request new PDN connectivity to the same APN for the indicated time.

– for Multi-Connection Mode, reject WLCP PDN connection requests for the same APN from the UE with a Session Management back-off timer that instructs the UE to not request new PDN connectivity to the same APN for the indicated time.

– reduce/throttle messages towards the PDN GWs indicating overload status;

– apply other implementation specific mechanisms, which are outside the scope of 3GPP specifications.

The same concepts as described in TS 23.401 [4] clause 4.3.7.1a.2 for PGW Overload Control apply with the TWAN/ePDG playing a similar role as the MME/SGSN.

NOTE 2: Refer to clause 12 of TS 29.274 [57] for the details, such as exact format of the Overload Control Information, mechanisms to discover the support of the feature by the peer node, interfaces for which this feature is applicable, APN level overload control, etc.

If the UE has received a Session Management back-off timer over non-3GPP access from the TWAG, the UE shall not send any Session Management requests related to that APN to the network via WLAN as long as the Session Management back-off timer is running.

A Session Management back-off timer received over non-3GPP access has no impact on the UE behaviour in 3GPP access. A Session Management back-off time received over 3GPP access has no impact on the UE behaviour in non-3GPP access.

NOTE 3: For ePDG, since a Session Management back-off timer is not provided to the UE, the UE may retry its request. This results in repeated signaling towards the ePDG before the network rejects the request from UE. Hence, it may cause the overload of the ePDG.

A PDN GW may apply certain restrictions towards TWAN/ePDG that have indicated overload, e.g. apply similar policies as those described in TS 23.401 [4] clause 4.3.7.1a.2 in the case of an MME or an SGW has indicated overload.