Content for TS 23.402 Word version: 18.3.0

0… 4… 4.2… 4.2.2 4.2.3 4.3… 4.4… 4.5… 4.5.7… 4.6… 4.7… 4.7.2… 4.8… 4.8.2a… 4.9… 5… 5.2… 5.4… 5.5 5.6… 5.7… 5.8… 6… 6.2… 6.3 6.4… 6.4.3… 6.5… 6.6… 6.7… 6.8… 6.10… 6.13… 6.15… 7… 7.2… 7.3 7.4… 7.5… 7.6… 7.8… 7.10… 8… 8.2.1.2 8.2.1.3… 8.2.2 8.2.3… 8.2.6… 8.3… 8.4… 8.5… 9… 9.3… 9.4… 10… 13… 16… 16.1.2… 16.1.6… 16.2… 16.2.1a… 16.3… 16.4… 16.7… 16.8… 16.10… 17… A… C… E…

4.9 Authentication and Security 4.9.1 Access Authentication in non-3GPP Accesses 4.9.2 Tunnel Authentication 4.9.3 Support for EAP Re-Authentication 4.10 QoS Concepts 4.10.1 General 4.10.3 The EPS Bearer with PMIP-based S5/S8 and E-UTRAN access 4.10.4 Application of PCC in the Evolved Packet System 4.10.5 PDN connectivity service with GTP based S2b 4.11 Charging for Non-3GPP Accesses 4.12 Multiple PDN Support 4.13 Detach principles
...

4.9 Authentication and Security p. 77

4.9.1 Access Authentication in non-3GPP Accesses p. 77

Non-3GPP access authentication defines the process that is used for Access Control i.e. to permit or deny a subscriber to attach to and use the resources of a non-3GPP IP access which is interworked with the EPC network. Non-3GPP access authentication signalling is executed between the UE and the 3GPP AAA server/HSS. The authentication signalling may pass through AAA proxies.

3GPP based access authentication is executed across a SWa/STa reference point as depicted in the EPS architecture diagram. Following principles shall apply in this case:

Transport of authentication signalling shall be independent of the non-3GPP IP Access technology.
The 3GPP based access authentication signalling shall be based on IETF protocols, for e.g., Extensible Authentication Protocol (EAP) as specified in RFC 3748.

The details of the access authentication procedure are defined in TS 33.402.

4.9.2 Tunnel Authentication p. 77

Tunnel authentication refers to the procedure by which the UE and the ePDG perform mutual authentication during the IPsec tunnel establishment between the UE and the ePDG (SWu reference point).

Tunnel authentication is used only in case of Untrusted Non-3GPP Access and is executed across a SWm reference point as depicted in the EPS architecture diagram.

The details of the tunnel authentication procedure are defined in TS 33.402.

4.9.3 Support for EAP Re-Authentication |R14| p. 78

A non-3GPP access network (typically, a WLAN) may utilize EAP re-authentication as specified in RFC 6696 in order to provide enhanced performance and optimize the user experience. As an example, a WLAN access network may utilize EAP re-authentication in order to enable Fast Initial Link Setup (specified in IEEE 802.11ai) and minimize the link-setup delay between the UE and the WLAN access network.

An EPC network may optionally support EAP re-authentication for interworking with non-3GPP accesses. Also, the UE may optionally support EAP re-authentication. By using EAP re-authentication, UEs can connect to EPC via non-3GPP access and utilize EPC services with enhanced performance. For example, a UE may experience improved voice-over-IMS service due to the small link-setup delay that occurs when the UE transitions between access points in the non-3GPP access network.

When an EPC network supports EAP re-authentication, the functionality of the 3GPP AAA server/proxy and the procedures over STa, SWa and SWd interfaces shall be enhanced in order to support the applicable procedures specified in RFC 6696. Also, when a UE supports EAP re-authentication, the UE shall be enhanced in order to support the functionality of the EAP re-authentication peer RFC 6696. EAP re-authentication over the SWu interface (i.e. when the UE establishes a secure connection with the ePDG) is not applicable.

When an EPC network supports EAP re-authentication, one or both of the following scenarios shall be supported:

The EAP re-authentication server (defined in RFC 6696) is located in the non-3GPP access network.
The EAP re-authentication server is located in the EPC network. In this case it shall be collocated with the 3GPP AAA server or with the 3GPP AAA proxy.

4.10 QoS Concepts p. 78

4.10.1 General p. 78

The QoS model that is applied in conjunction with PMIP-based reference points does not use bearer IDs in user plane packets. Instead it is based on packet filters and associated QoS parameters (QCI, ARP, MBR, GBR) provided to the access system through off-path signalling.

The PCRF signals the same packet filters and associated QoS parameters over Gxa, Gxb and Gxc as over Gx; in other words the granularity of the QoS information that is passed over Gxa, Gxb and Gxc is the same as over Gx.

4.10.2 Void

4.10.3 The EPS Bearer with PMIP-based S5/S8 and E-UTRAN access |R9| p. 79

Copy of original 3GPP image for 3GPP TS 23.402, Fig. 4.10.3-1: Two Unicast EPS bearers (PMIP-based S5/S8 and E-UTRAN access)

Figure 4.10.3-1: Two Unicast EPS bearers (PMIP-based S5/S8 and E-UTRAN access)
(⇒ copy of original 3GPP image)

For PMIP-based S5/S8 and E-UTRAN access, an EPS bearer consists of the concatenation of one Radio Bearer and one S1 bearer. The PDN Connectivity Service between a UE and an external packet data network is supported through a concatenation of an EPS Bearer and IP connectivity between Serving-GW and PDN-GW. QoS control between a Serving-GW and a PDN-GW is provided at the Transport Network Layer (TNL).

The EPS bearer is realised by the following elements:

In the UE, UL TFT maps a traffic flow aggregate to an EPS bearer in the uplink direction.
In the Serving-GW, the DL TFT maps a traffic flow aggregate to an EPS bearer in the downlink direction.
A radio bearer transports the packets of an EPS bearer between a UE and an eNodeB. There is a one-to-one mapping between an EPS bearer and a radio bearer.
An S1 bearer transports the packets of an EPS bearer between an eNodeB and a Serving-GW. There is a one-to-one mapping between an EPS bearer and a S1 bearer.
A per UE per PDN tunnel transports the packets of an EPS bearer between a Serving-GW and a PDN-GW. There is a many-to-one mapping between an EPS bearer and this per UE, per PDN tunnel.
A UE stores a mapping between an uplink packet filter and a radio bearer to create the mapping between a traffic flow aggregate and a radio bearer in the uplink.
An eNodeB stores a one-to-one mapping between a radio bearer and an S1 bearer to create the binding between a radio bearer and an S1 bearer in both the uplink and the downlink direction.
A Serving-GW stores a one-to-one mapping between a downlink packet filter and an S1 bearer to create the mapping between a traffic flow aggregate and an S1 bearer in the downlink.
A PDN-GW enforces APN-AMBR across all SDFs of the same APN that is associated with Non-GBR QCIs.

4.10.4 Application of PCC in the Evolved Packet System p. 79

EPS supports both static and dynamic PCC deployment options as specified in TS 23.401.

In case of non-3GPP access that does not support an Gxa/b or S9 interface, static QoS policies (e.g. based on subscription QoS parameters for default connectivity) may be provided to the non-3GPP access through the AAA infrastructure. To perform policy enforcement according to the subscription QoS parameters for default connectivity, additional information may be provided to the PDN-GW in one of the following ways:

from the PCRF, if present and if the PDN-GW supports the Gx interface;
from the 3GPP AAA Server through the S6b interface in the form of a static QoS profile for the S2a, PMIP based S2b, and S2c reference points;
from the ePDG through GTP based S2b in the form of a static QoS profile (Default EPS Bearer QoS), which the ePDG obtains from the 3GPP AAA Server through the SWm interface.

When dynamic policy provisioning is not deployed, the PDN-GW in case of PMIP or GTP based signalling uses the access type information (RAT Type in 3GPP access) contained in PMIP Proxy Binding Update messages or GTP Create Session Request messages for, e.g. charging. When dynamic policy provisioning is deployed, the PDN-GW relies on the PCRF for indication of the handling required due to the access technology.

The behaviour of the system when PCC is deployed only in VPLMN or only in HPLMN is described in TS 23.203.

For non-3GPP access that supports UEs with different Bearer Control Mode (BCM) capabilities, it should be possible for the UE to signal its BCM capabilities to the BBERF. It should also be possible for the BBERF to signal the selected BCM to the UE. How this information is exchanged between the UE and the BBERF is outside of the scope of 3GPP.

4.10.5 PDN connectivity service with GTP based S2b |R10| p. 80

For untrusted non-3GPP access to the EPC the PDN connectivity service is provided by IPsec connectivity between the UE and the ePDG concatenated with S2b bearer(s) between the ePDG and the PGW.

Two scenarios exist. In one scenario, only one IPSec SA is established between the UE and the ePDG and it transports traffic for the default bearer and all dedicated bearers established over S2b between the ePDG and the PDN-GW. This is depicted in clause 4.10.5.1. In the second scenario, when the UE and the ePDG supports the establishment of a separate IPsec child SA per dedicated S2b bearer that transports the traffic for that dedicated bearer, and where the main IPSec SA transports the traffic for the default bearer. This is depicted in clause 4.10.5.2.

4.10.5.1 Single IPSec SA per PDN Connection Scenario |R15| p. 80

Copy of original 3GPP image for 3GPP TS 23.402, Fig. 4.10.5.1-1: Single IPSec SA per PDN connection

Figure 4.10.5.1-1: Single IPSec SA per PDN connection
(⇒ copy of original 3GPP image)

The SWu interface between the UE and the ePDG is identical for the GTP and PMIP variants of S2b. The UE establishes a separate SWu instance (i.e. a separate IPSec tunnel) for each PDN connection.

One default S2b bearer is established on the S2b interface when the UE connects to a PDN, and that remains established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. Additional dedicated S2b bearers may be established on S2b for the same PDN connection depending on operator policy. The PGW establishes dedicated S2b bearers on S2b for the same PDN connection based on PCC decisions as specified in TS 23.203.

The ePDG releases the SWu instance when the default S2b bearer of the associated PDN connection is released.

The S2b bearer is realized by the following elements:

A GTP tunnel on S2b transports the packets of an S2b bearer between the ePDG and a PDN-GW;
The ePDG stores the mapping between uplink packet filters it receives from the PGW (e.g. in the Create Bearer Request message) and the corresponding S2b bearer;
The PDN-GW stores the mapping between downlink packet filters and an S2b bearer.

In support for the UE connectivity with the PDN:

A SWu instance (i.e. a IPSec tunnel) transports the packets of all S2b bearer(s) for the same PDN Connection between the UE and the ePDG.

The ePDG routes uplink packets to the different bearers based on the uplink packet filters in the TFTs assigned to the bearers in the PDN connection, in the same way as a UE does for uplink traffic under 3GPP access. If no match is found, the uplink data packet shall be sent via the bearer that does not have any uplink packet filter assigned. If all bearers (including the default bearer for that PDN) have been assigned an uplink packet filter, the ePDG shall discard the uplink data packet.

The PDN-GW routes downlink packets to the different bearers based on the downlink packet filters in in the TFTs assigned to the S2b bearers in the PDN connection, in the same way as the PDN-GW does on GTP-based S5/S8 bearers (see clause 4.7.2.2 of TS 23.401).

4.10.5.2 Single IPsec SA per S2b bearer Scenario |R15| p. 81

This scenario assumes both UE, and ePDG support the establishment of a separate IPsec SA per S2b bearer, while the main IPSec SA is intended for the default bearer.

Copy of original 3GPP image for 3GPP TS 23.402, Fig. 4.10.5.2-1: Single IPsec SA per S2b bearer

Figure 4.10.5.2-1: Single IPsec SA per S2b bearer
(⇒ copy of original 3GPP image)

The SWu interface between the UE and the ePDG is identical for the GTP and PMIP variants of S2b. The UE establishes a separate SWu instance (i.e. a separate IPsec SA per RFC 7296) for each PDN connection.

The ePDG releases the SWu instance, including all IP Sec SAs associated with the SWu instance, where applicable, when the default S2b bearer of the associated PDN connection is released.

The S2b bearer is realized by the following elements:

A GTP tunnel on S2b transports the packets of an S2b bearer between the ePDG and a PDN-GW;
The ePDG stores the mapping between IPSec SA and the corresponding S2b bearer;
The PDN-GW stores the mapping between downlink packet filters and an S2b bearer.

The ePDG shall establish a SA per S2b bearer as per clause 7.10. The default EPC bearer maps to the initial SA. The ePDG shall maintain a 1 to 1 mapping between an S2b bearer and an IPsec SA.

Additionally, for these UEs, TFTs and bearer QoS information is conveyed from the ePDG to the UE in IKE v2 signalling associated with the corresponding SA at EPC bearer creation and EPC bearer modification. The bearer QoS information includes information regarding the QoS characteristics of the bearer (i.e. QCI, GBR and MBR).

The IKEv2 traffic selectors TSi and TSr, defined in RFC 7296, shall not be used to route packets to the IPSec SA.

In support for the UE connectivity with the PDN:

A SWu instance (i.e. an IKEv2 SA with one or more IPsec SA) transports the packets of all S2b bearer(s) for the same PDN Connection between the UE and the ePDG.

The ePDG routes uplink packets to the different bearers based on the incoming child SA and the corresponding S2b bearer.

The UE routes uplink packets to the SAs associated with the different S2b bearers based on the uplink packet filters in the TFTs assigned to the S2b bearers in the PDN connection, in the same way as a UE does for uplink traffic under 3GPP access. If no match is found, the uplink data packet shall be sent via the SA that does not have any uplink packet filter assigned. If all IPsec SAs have been assigned an uplink packet filter, the UE shall discard the uplink data packet.

To support QoS differentiation,

for downlink packets, if the ePDG sets the DSCP, the ePDG shall use the QCI, and optionally the ARP, of the S2b bearer via which the downlink packet was received to derive the DSCP value for downlink packets. If the ePDG sets the DSCP field, it may also set it in the outer IP header of the ESP packet.

NOTE 1:
The ePDG maintains the mapping of DSCP values used on S2b and the outer ESP tunnel to the UE.

NOTE 2:
Based on operator policy and/or regional/national regulations, the ePDG can apply a different DSCP value to the outer ESP tunnel packet than the DSCP value of the inner IP packet.
for uplink packets, the UE shall either use the DSCP value that it received from the ePDG, or the QCI in dedicated bearer QoS information to set the DSCP value for uplink packets. The mapping of QoS class to DSCP could be configurable in the UE and as an example can use the recommended mappings specified in 3GPP (mapping between standardized QCIs and Release 99 QoS parameter value in TS 23.401), IEEE Std. 802.11-2012 [64], and the Wi-Fi WMM-multimedia certification profile [86]. The UE may also use information included in dedicated QoS information for local aspects of admission control (e.g. application traffic shaping), however this is out of scope for this document.

4.11 Charging for Non-3GPP Accesses p. 83

The following are related to Non-3GPP accesses:

Accounting information, e.g. the amount of data transmitted in uplink and downlink direction categorized with the QCI per UE, could be collected by components, if any, in the Non-3GPP access networks for inter-operator settlements.

4.12 Multiple PDN Support p. 83

General high level principles for the support of multiple PDNs are provided in clause 5.10.1 of TS 23.401. In addition, the following applies:

Simultaneous exchange of IP traffic to multiple PDNs is supported in the EPS, when the network policies, non-3GPP access and user subscription allow it. UE Support for multiple overlapping IP address spaces is optional.
Multiple PDN connections for a given APN and UE can be supported with the restrictions that all PDN connections for a given APN and UE shall use the same access network and shall all be moved to a new access network during handovers.
If an additional PDN connection to the same APN occurs, and an existing PDN connection to that APN exists, the same PDN-GW shall be selected.
Multiple PDN connections to different APNs may use different access networks. The UE selects the access network where to route a specific PDN connection based on user preferences and operator's policies.
A UE that is capable of routing different simultaneously active PDN connections through different access networks can do so if the UE is authorized by subscription to access each of the involved PDNs and each of the involved access networks.
The access networks the UE can stay simultaneously connected with shall include no more than one 3GPP access and one and only one non-3GPP access.

Once a specific IP mobility protocol is selected during initial attach for a specific non-3GPP access, it is not possible for the UE to use different mobility protocols for any of the PDNs that it obtains connectivity on the same non-3GPP access after initial attach. It is not possible for a UE that is connected to multiple PDNs over a 3GPP access to perform a handover to a non-3GPP access and then use different mobility protocols for the various PDNs that it connected with on the same non-3GPP access.

For the purpose of using MAPCON, the UE shall try to simultaneously connect to different APNs through different access networks only if the home network supports such simultaneous connectivity. The UE determines that the network supports such simultaneous connectivity over multiple accesses if the UE is provisioned with or has received per-APN inter-system routing policies (see clause 4.8.2.1) from the home network.

4.13 Detach principles |R10| p. 84

When a UE is attached to Evolved Packet Core via multiple access systems, the following principles shall apply during the detach procedure:

A UE that is detaching from the Evolved Packet Core (e.g. a UE that is powering off) shall perform the UE initiated detach procedure on each of the access systems through which the UE is attached to Evolved Packet Core.
A UE that is detaching from a specific access system and wants to preserve all or a subset of the active PDN connections that use that access system shall initiate UE initiated PDN disconnection procedure for each of the PDN connection which is not required to be preserved. The UE then shall initiate the applicable handover procedure to transfer to the access system through which the UE remains attached to the Evolved Packet Core each of the PDN connections to be preserved.
When HSS initiates the detach procedure to delete the UE from the Evolved Packet Core (e.g. due to subscription expiry, etc), HSS/AAA initiated detach procedure should be performed towards each node registered for the UE.