Content for TS 24.302 Word version: 18.6.0

4.1 Trusted and untrusted accesses 4.2 cdma2000® HRPD Access System 4.3 WiMAX Access System 4.3A WLAN 4.4 Identities 4.5 Fixed Broadband Access System 4.6 Restrictive non-3GPP access networks 4.7 Provision and handling of local emergency numbers 4.8 Quality of service support
...

4 General p. 21

4.1 Trusted and untrusted accesses p. 21

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 p. 21

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 p. 21

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 |R14| p. 21

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 p. 22

4.4.1 User identities p. 22

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 TS 23.003; or
if the UE has an IMSI, it shall use the IMSI for the identification, as user part of the emergency NAI.

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.

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

RFC 4187 and TS 23.003 provide definitions for UE and user identities although they use slightly different terms. Similar terms are also used in TS 33.402. 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 TS 33.402.
The Fast-Reauthentication NAI is to be used as the Fast-Reauthentication Identity or the re-authentication ID as specified in TS 33.402.
The Pseudonym Identity is to be used as the Pseudonym as specified in TS 33.402.

4.4.2 Identification of IP Services/PDN connections p. 22

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 TS 23.003. 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 TS 24.244) for multi-connection mode (MCM)

4.4.3 FQDN for ePDG Selection p. 22

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 TS 23.402, and used as input to the DNS mechanism for ePDG selection.

The detailed format of this ePDG FQDN is specified in TS 23.003.

4.4.4 Access Network Identity p. 22

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 TS 33.402). 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 |R10| p. 23

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 TS 23.003.

4.4.6 Home Agent address(es) |R10| p. 23

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 |R10| p. 23

The Security Parameters Index (SPI, see RFC 4301) 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 |R11| p. 23

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 TS 24.139.

The UE procedures for support of fixed broadband access are specified in TS 24.139 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 TS 23.203.

4.6 Restrictive non-3GPP access networks |R12| p. 23

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 |R14| p. 23

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:

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;
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
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:

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;
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
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.

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 |R15| p. 24

4.8.1 General p. 24

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

4.8.2 QoS differentiation in trusted WLAN p. 24

4.8.2.1 General p. 24

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 p. 24

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 TS 24.244:

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 TS 24.244. 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 p. 25

If WLCP multiple bearer PDN connectivity is used:

For uplink packets, the UE shall select a 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 most recent DSCP value received in the same WLCP bearer from the TWAG or 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 WLCP bearer and the S2a bearer mapping table.

NOTE 1:
The UE can map QCIs to DSCP values, for example, by using the mapping between standardized QCI values and Release 99 3GPP QoS parameter values specified in TS 23.401 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.

NOTE 2:
The UE can send the same DSCP as that received in the downlink, in case the privacy of the user is to be protected.

NOTE 3:
Whether the UE determines DSCP based on the most recent DSCP value received in the same WLCP bearer from the TWAG or on the QoS mapping is left to the implementation.
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, based on operator policy, use the QCI and the ARP 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 4:
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 TS 23.401 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 p. 25

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.