4 General

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

4.1 Trusted and untrusted accesses

The HPLMN operator of the EPC selects whether a connected non-3GPP IP access network is a trusted or untrusted IP access network.

For a trusted non-3GPP IP access network the communication between the UE and the EPC is secure. For an untrusted non-3GPP IP access network the communication between the UE and the EPC is not trusted to be secure.

For a trusted non-3GPP IP access network, all communication between the access network and the EPC is transferred over pre-established secure links. For an untrusted non-3GPP IP access network, to secure communication between the UE and the EPC:

– a single IPSec tunnel needs to be established to the ePDG for all PDN connections when the UE accesses EPC via S2c is used; or

– an IPSec tunnel needs to be established with the same ePDG for each PDN connection when the UE accesses EPC via S2b is used.

4.2 cdma2000^® HRPD Access System

The cdma2000^® HRPD system is a wireless mobile system developed under the auspices of 3GPP2. The cdma2000^® HRPD system and its access network subsystem is compliant with 3GPP2 X.S0057 [20] and 3GPP2 C.S0087 [21], which define the core network and air interface aspects, respectively.

4.3 WiMAX Access System

The WiMAX system is a wireless mobile broadband system developed under the auspices of the WMF and the IEEE. The WiMAX system and its access network subsystem are compliant with WiMAX Forum Network Architecture Release 1.0 version 1.2 – Stage 2 [24]. The protocol architecture and signalling of the WiMAX system is specified in WiMAX Forum Network Architecture Release 1.0 version 1.2 – Stage 3 [25] which supports the air interface defined in WiMAX Forum Mobile System Profile Release 1.0 Approved Specification Revision 1.4.0 [26] specifying selected profiles of IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/Cor1-2005 [27] that are to be supported. The WiMAX access system correspond to the WiMAX Access Service Network (ASN) and to relevant interfaces, as defined in WiMAX Forum Network Architecture Release 1.0 version 1.2 – Stage 3 [25].

4.3A WLAN

WLAN is an access network developed under the auspices of IEEE Computer Society. WLAN is compliant with IEEE Std 802.11 [57], which define air interface aspects.

IEEE Std 802.11 [57] defines Access Network Query Protocol (ANQP). A UE can receive from an AP ANQP-elements in response to an ANQP query. The ANQP query response is received in a generic advertisement service response frame or a protected management frame.

Where needed, the current specification further describes the structure and contents of payload of ANQP-elements specified in IEEE Std 802.11 [57] (see annex H and annex I).

4.4 Identities

4.4.1 User identities

The user identification shall be either the root NAI, or the decorated NAI, when the UE accesses the EPC via non-3GPP access networks, and gets authentication, authorization and accounting services from the EPC.

For emergency services over WLAN:

– if IMSI is not available (i.e. a UE without USIM), the IMEI shall be used for the identification, as user part of the emergency NAI and the UE shall use a specific domain in the realm part of the NAI as specified in 3GPP TS 23.003 [3]; or

– if the UE has an IMSI, it shall use the IMSI for the identification, as user part of the emergency NAI.

NOTE 1: If the IMSI is unauthenticated on the network side and the network supports emergency session for unauthenticated IMSI, the IMEI is used for the identification on the network side (see clause 6.4.3.1A).

For handover of an emergency session from E-UTRAN to a S2a based cdma2000^® HRPD access network, if IMSI is not available (i.e. a UE without USIM) or IMSI is unauthenticated, the IMEI shall be used for the identification, as part of the emergency NAI as defined.

The UE’s Mobile Identity IMEI or IMEISV is conveyed to the network (see clause 6.4 and clause 7) and used to enable consistent services for the UE accessing the network via non-3GPP access or to support the emergency services over WLAN for the unauthenticated UEs.

NOTE 2: IMEI and IMEISV are untrusted identities stored on the UE.

User identification in non-3GPP accesses may require additional identities that are out of the scope of 3GPP.

IETF RFC 4187 [33] and 3GPP TS 23.003 [3] provide definitions for UE and user identities although they use slightly different terms. Similar terms are also used in 3GPP TS 33.402 [15]. The following list provides term equivalencies and describes the relation between various user identities.

– The Root NAI is to be used as the permanent identity as specified in 3GPP TS 33.402 [15].

– The Fast-Reauthentication NAI is to be used as the Fast-Reauthentication Identity or the re-authentication ID as specified in 3GPP TS 33.402 [15].

– The Pseudonym Identity is to be used as the Pseudonym as specified in 3GPP TS 33.402 [15].

4.4.2 Identification of IP Services/PDN connections

For access to EPC the Access Point Name (APN) is used for identifying IP services/PDN connections. The detailed definition of APN as used for access to EPC is specified in 3GPP TS 23.003 [3]. APN is conveyed in the IKEv2 signaling during tunnel establishment when S2b interface is used for UE to access EPC. When UE accesses EPC via S2a using trusted WLAN access network, APN is conveyed in EAP-AKA’ signaling for single-connection mode (SCM) or in WLAN Control Protocol (WLCP) signaling (see 3GPP TS 24.244 [56]) for multi-connection mode (MCM)

4.4.3 FQDN for ePDG Selection

An ePDG Fully Qualified Domain Name (ePDG FQDN) is either provisioned by the home operator or constructed by UE in either the Operator Identifier FQDN format or the Tracking/Location Area Identity FQDN format as described in clause 4.5.4.2 of 3GPP TS 23.402 [6], and used as input to the DNS mechanism for ePDG selection.

The detailed format of this ePDG FQDN is specified in 3GPP TS 23.003 [3].

4.4.4 Access Network Identity

For access to EPC via S2a using a trusted non-3GPP access network, the UE uses the Access Network Identity (ANID) in the key derivation (see 3GPP TS 33.402 [15]). The handling of the Access Network Identity is described in clause 6.4.2.4 and the generic format and specific values for the Access Network Identity are defined in clause 8.1.1.

4.4.5 ANDSF Server Name

The ANDSF Server Name (ANDSF-SN) is used for ANDSF discovery. The detailed rules are defined in clause 6.8.2.2.1 and the format of the ANDSF-SN is specified in 3GPP TS 23.003 [3].

4.4.6 Home Agent address(es)

If DSMIPv6 is used, the Home Agent IPv6 address (and optionally an IPv4 address) are needed. Within this specification, Home Agent address(es) signalling via IKEv2 between the UE and the ePDG is defined in clause 7.4.1.

4.4.7 Security Parameters Index

The Security Parameters Index (SPI, see IETF RFC 4301 [30]) identifies uniquely a security association between the UE and the ePDG. For the case of NBM using S2b a one to one mapping between SPI and PDN connection applies.

4.5 Fixed Broadband Access System

The fixed broadband access system is a type of high-speed Internet access for multi-service broadband packet networking. The fixed broadband access system is specified by the Broadband Forum, including addressing interoperability, architecture and management.

For support of fixed broadband access interworking, the EPC network procedures are specified in 3GPP TS 24.139 [51].

The UE procedures for support of fixed broadband access are specified in 3GPP TS 24.139 [51] and can be used when the EPC network uses the fixed broadband access interworking or the fixed broadband access convergence.

The architecture of the fixed broadband access convergence is specified in 3GPP TS 23.203 [5A].

4.6 Restrictive non-3GPP access networks

An untrusted non-3GPP access network can be a restrictive non-3GPP access network. When the UE is served by a restrictive non-3GPP access network, the UE and the ePDG follow the additional procedures described in the annex F.

4.7 Provision and handling of local emergency numbers

It is a UE implementation option to support the procedures of this clause.

Once the UE has a secure connection to a PLMN through non-3GPP access, the UE supports obtaining local emergency numbers by one of the following ways:

i) when the UE is connected to a PLMN through trusted non-3GPP access, the local emergency numbers is provided through ANQP, within the ANQP payload. The signalling protocol and methods for use of ANQP is as specified in IEEE Std 802.11 [57]. See also annex I;

ii) when the UE is connected to a PLMN through untrusted non-3GPP access, local emergency numbers can be provided through DNS query. See annex J; or

iii) when the UE is connected to a PLMN through untrusted non-3GPP access, local emergency numbers can be provided through IKEv2. See annex K.

Upon receiving the local emergency numbers through any of the methods indicated above, the UE shall store the local emergency numbers:

a) if the Non-3GPP emergency number indicator within the Non-3GPP NW provided policies IE through registration procedures over 3GPP access is set to "use of non-3GPP emergency numbers permitted", and:

– if the UE is connected to a PLMN through non-3GPP access and also registered to same PLMN or different PLMN through 3GPP access in the same country, then provide these local emergency numbers to upper layers for the detection of UE initiated emergency call;

– if the UE is connected to a PLMN through non-3GPP access but is also registered to different PLMN through 3GPP access that is not in the same country, then do not use the received local emergency numbers;

b) if the Non-3GPP emergency number indicator within the Non-3GPP NW provided policies IE through registration procedures over 3GPP access is set to "use of non-3GPP emergency numbers not permitted", or if no Non-3GPP NW provided policies IE was provided through registration procedures over 3GPP access, then:

– do not use the received local emergency numbers for the detection of UE initiated emergency call over 3GPP access; and

c) if the UE:

– is connected to a PLMN through non-3GPP access;

– is not registered to any PLMN through 3GPP access;

– is not in limited service state camped on an acceptable cell of any PLMN through 3GPP access; and

– can determine that the MCC information of the local emergency numbers received over non-3GPP access corresponds to the country in which the UE is located;

then, as an implementation option, provide these local emergency numbers to upper layers for the detection of UE initiated emergency call.

NOTE: The UE determination of the country in which the UE is located, is UE implementation specific.

The local emergency numbers, received in any of the methods indicated above:

– are only valid in the country where these local emergency numbers were provided;

– replace only the stored local emergency numbers received over non-3GPP access, if any;

– shall be deleted when UE moves to a country different from where the local emergency numbers were received; and at switch off or removal of the USIM.

4.8 Quality of service support

4.8.1 General

QoS differentiation may be supported for both trusted WLAN and untrusted WLAN.

4.8.2 QoS differentiation in trusted WLAN

4.8.2.1 General

For trusted WLAN, QoS differentiation may be supported if Multi-Connection mode (MCM) based access to EPC is used.

4.8.2.2 QoS signalling

As part of EAP-AKA’ authentication via TWAN, the UE and the TWAN first negotiates TWAN connection mode usage as described in clause 6.4.

During PDN connection establishment, the UE indicates to the TWAG whether WLCP multiple bearer PDN connectivity capability is supported or not, as specified in 3GPP TS 24.244 [56]:

– if the UE does not indicate that WLCP multiple bearer PDN connectivity is supported, or if the UE indicates that WLCP multiple bearer PDN connectivity is supported but the TWAG does not support WLCP multiple bearer PDN connectivity, then QoS differentiation is not supported. Single point-to-point PDN connection is used to carry all S2a bearers traffic between the UE and TWAG; or

– if WLCP multiple bearer PDN connectivity is supported by both the UE and TWAN, then QoS differentiation is supported and multiple bearer PDN connectivity shall be used between the UE and TWAG:

– During PDN connection establishment, the TWAG shall establish a default WLCP bearer for the PDN connection. The default WLCP bearer remains established throughout the lifetime of the PDN connection; and

– The TWAG shall establish a separate WLCP bearer for each additional S2a dedicated bearer of the PDN connection using WLCP signalling as specified in 3GPP TS 24.244 [56]. Each WLCP bearer is associated with TFT and bearer level QoS (i.e. QCI, GBR and MBR) for one-to-one mapping between WLCP bearer and S2a bearer. The TWAG shall maintain the WLCP bearer to the S2a bearer mapping table.

4.8.2.3 QoS differentiation in user plane

If WLCP multiple bearer PDN connectivity is used:

– For uplink packets, the UE shall select WLCP bearer based on the uplink packet filters in the TFTs. If no match is found, the UE shall select the WLCP bearer that does not have any uplink packet filter assigned. If all bearers have been assigned an uplink packet filter, the UE shall discard the uplink data packet. The UE shall then use the QCI in WLCP bearer level QoS information to derive the DSCP value for uplink packets. The UE shall provide the user plane connection id to the lower layers to be used as the MAC address of the TWAG associated with the WLCP bearer. The TWAG shall then route the uplink packets to the corresponding S2a bearers based on the the WLCP bearer and the S2a bearer mapping table.

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-2012 [57] table V-1.

– For downlink packets, the PDN GW routes the packets to S2a bearers based on the downlink packet filters in the TFTs assigned to each of the S2a bearers. The TWAG then selects the corresponding WLCP bearer for the downlink packets based on the the WLCP bearer and the S2a bearer mapping table. The TWAG shall also use the QCI in WLCP bearer level QoS information to derive the DSCP value for downlink packets. The TWAG shall provide the user plane connection id to the lower layers to be used as the MAC address of the TWAG associated with the WLCP bearer.

NOTE 2: The TWAG 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.

4.8.3 QoS differentiation in untrusted non-3GPP access

For untrusted non-3GPP access, QoS differentiation is provided if the UE and the ePDG supports the IKEv2 multiple bearer PDN connectivity and the IKEv2 multiple bearer PDN connectivity is used in the PDN connection as defined in clause 7.2.7 and clause 7.4.6.