4.12a Procedures for Trusted non-3GPP access

23.5023GPPProcedures for the 5G System (5GS)Release 18TS

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

4.12a.1 General

Clause 4.12a defines the procedures to support trusted non-3GPP access by describing the differences compared to the defined procedures in other clauses.

4.12a.2 Registration via Trusted non-3GPP Access

4.12a.2.1 General

Clause 4.12a.2 specifies how a UE can register to 5GC via a trusted non-3GPP Access Network. The utilized procedure is very similar with the 5GC registration procedure over untrusted non-3GPP access in clause 4.12.2.2 and it is based on the Registration procedure specified in clause 4.2.2.2.2. It uses the same vendor-specific EAP method (called "EAP-5G") as the one specified in clause 4.12.2.1. In this case, the "EAP-5G" method is used between the UE and the TNGF and is utilized for encapsulating NAS messages.

In Registration and subsequent Registration procedures via trusted non-3GPP access, the NAS messages are always exchanged between the UE and the AMF. When possible, the UE can be authenticated by reusing the existing UE security context in AMF.

4.12a.2.2 Registration procedure for trusted non-3GPP access

The UE connects to a trusted non-3GPP Access Network (TNAN) and it also registers to 5GC over via this TNAN, by using the EAP-based procedure shown in the figure 4.12a.2.2. This procedure is very similar with the 5GC registration procedure over untrusted non-3GPP access in clause 4.12.2.2. The link between the UE and the TNAN can be any data link (L2) that supports EAP encapsulation, e.g. PPP, PANA, Ethernet, IEEE 802.3, IEEE 802.11, etc. The interface between the TNAP and TNGF is an AAA interface.

Figure 4.12a.2.2-1: Registration via trusted non-3GPP access

0. The UE which is not operating in SNPN access mode selects a PLMN and a TNAN for connecting to this PLMN by using the Trusted Non-3GPP Access Network selection procedure specified in clause 6.3.12 of TS 23.501 [2]. During this procedure, the UE discovers the PLMNs with which the TNAN supports trusted connectivity (e.g. "5G connectivity").

The UE operating in SNPN access mode selects an SNPN and a TNAN for connecting to this SNPN by using the Trusted Non-3GPP Access Network selection procedure specified in clause 5.30.2.13 of TS 23.501 [2]. During this procedure, the UE discovers the SNPNs with which the TNAN supports trusted connectivity (e.g. "5G connectivity").

NOTE 1: In this Release, it is assumed that when the trusted non-3GPP access is a trusted WLAN access, the UE is configured (e.g. with the WLANSP rules defined in TS 23.503 [20]) to select an SSID associated with a non-3GPP Tracking Area, which supports one or more of the UE’s subscribed S-NSSAIs.

1. A layer-2 connection is established between the UE and the TNAP. In the case of IEEE Std 802.11 [48], this step corresponds to an 802.11 Association. In the case of PPP, this step corresponds to a PPP LCP negotiation. In other types of non-3GPP access (e.g. Ethernet), this step may not be required.

2-3. An EAP procedure is initiated. EAP messages are encapsulated into layer-2 packets, e.g. into IEEE 802.3/802.1x packets, into IEEE 802.11/802.1x packets, into PPP packets, etc. The NAI provided by the UE not operating in SNPN access mode indicates that the UE requests "5G connectivity" to a specific PLMN (e.g. NAI = "<any_username>@nai.5gc. mnc<MNC>.mcc<MCC>.3gppnetwork.org"). The NAI provided by the UE operating in SNPN access mode indicates that the UE request "5G connectivity" to a specific SNPN (e.g. NAI = "<any_username>@nai.5gc. nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org"). This NAI triggers the TNAP to send an AAA request to a TNGF, which operates as an AAA proxy. Between the TNAP and TNGF the EAP packets are encapsulated into AAA messages. The AAA request also include the TNAP identifier, which can be treated as the User Location Information.

NOTE 2: In this Release, it is assumed that when the trusted non-3GPP access is a trusted WLAN access, the TNAP selects a TNGF based on the realm provided by the UE and also based on the SSID selected by the UE. All TNGFs associated with the SSID selected by the UE support the same non-3GPP tracking area.

4-10. An EAP-5G procedure is executed as the one specified in clause 4.12.2.2 for the untrusted non-3GPP access with the following modifications:

– A TNGF key (instead of an N3IWF key) is created in the UE and in the AMF after the successful authentication. The TNGF key is transferred from the AMF to TNGF in step 10a (within the N2 Initial Context Setup Request). The TNGF derives a TNAP key, which is provided to the TNAP. The TNAP key depends on the non-3GPP access technology (e.g. it is a Pairwise Master Key in the case of IEEE Std 802.11 [48]). How these security keys are created, it is specified in TS 33.501 [15].

– In step 5 the UE shall include the Requested NSSAI in the AN parameters only if allowed, according to the conditions defined in clause 5.15.9 of TS 23.501 [2], for the trusted non-3GPP access. The UE shall also include a UE Id in the AN parameters, e.g. a 5G-GUTI if available from a prior registration to the same PLMN or SNPN. If the UE in SNPN access mode performs the Registration procedure for UE onboarding, the UE shall include an indication in the AN parameters that the connection request is for onboarding.

– In the N2 message sent in step 6b, the TNGF includes a UE Location Information (ULI) that contains a "null" IP address (e.g. 0.0.0.0) because the UE is not yet assigned an IP address. After the UE is assigned an IP address, the TNGF includes this address in subsequent N2 messages. This N2 message also includes the Selected PLMN ID and optionally the Selected NID, and the Establishment cause.

NOTE 3: The Selected NID is present when the UE connects to an SNPN via Trusted non-3GPP access.

– If the UE in SNPN access mode performs the Registration procedure for UE onboarding, the interaction between AMF and AUSF (step 8a and step 8c in Figure 4.12a.2.2-1) is replaced with step 9-1 or step 9-2 or step 9-3 in Figure 4.2.2.2.4-1, depending on the 5GC architecture that is used for UE onboarding.

– After receiving the TNGF key from AMF in step 10a, the TNGF shall send to UE an EAP-Request/5G-Notification packet containing the "TNGF Contact Info", which includes the IP address of TNGF. After receiving an EAP-Response/5G-Notification packet from the UE in step 10c, the TNGF shall send message 10d containing the EAP-Success packet.

11. The TNAP key is used to establish layer-2 security between the UE and TNAP. In the case of IEEE Std 802.11 [48], a 4-way handshake is executed, which establishes a security context between the WLAN AP and the UE that is used to protect unicast and multicast traffic over the air.

12. The UE receives IP configuration from the TNAN, e.g. with DHCP.

13. At this point, the UE has successfully connected to the TNAN and has obtained IP configuration. The UE sets up a secure NWt connection with the TNGF as follows:

The UE initiates an IKE_INIT exchange using the IP address of TNGF received during the EAP-5G signalling, in step 10b. Subsequently, the UE initiates an IKE_AUTH exchange and provides its identity. The identity provided by the UE in the IKEv2 signalling should be the same as the UE Id included in the AN parameters in step 5. This enables the TNGF to locate the TNGF key that was created before for this UE, during the authentication in step 8. The TNGF key is used for mutual authentication. NULL encryption is negotiated between the UE and the TNGF, as specified in RFC 2410 [49].

In step 13c, the TNGF provides to UE (a) an "inner" IP address, (b) a NAS_IP_ADDRESS and a TCP port number and (c) a DSCP value. After this step, an IPsec SA is established between the UE and TNGF. This is referred to as the "signalling IPsec SA" and operates in Tunnel mode. Operation in Tunnel mode enables the use of MOBIKE [40] for re-establishing the IPsec SAs when the IP address of the UE changes during mobility events. All IP packets exchanged between the UE and TNGF via the "signalling IPsec SA" shall be marked with the above DSCP value. The UE and the TNAP may map the DSCP value to a QoS level (e.g. to an EDCA Access Class [48]) supported by the underlying non-3GPP Access Network. The mapping of a DSCP value to a QoS level of the non-3GPP Access Network is outside the scope of 3GPP.

Right after the establishment of the "signalling IPsec SA", the UE shall setup a TCP connection with the TNGF by using the NAS_IP_ADDRESS and the TCP port number received in step 13c. The UE shall send NAS messages within TCP/IP packets with source address the "inner" IP address of the UE and destination address the NAS_IP_ADDRESS. The TNGF shall send NAS messages within TCP/IP packets with source address the NAS_IP_ADDRESS and destination address the "inner" IP address of the UE.

This concludes the setup of the NWt connection between the UE and the TNGF. All subsequent NAS messages between UE and TNGF are carried over this NWt connection (i.e. encapsulated in TCP/IP/ESP).

14. After the NWt connection is successfully established, the TNGF responds to AMF with an N2 Initial Context Setup Response message.

15. Finally, the NAS Registration Accept message is sent by the AMF and is forwarded to UE via the established NWt connection. Now the UE can use the TNAN (a) to transfer non-seamless offload traffic and (b) to establish one or more PDU Sessions.

4.12a.2.3 Emergency Registration for trusted non-3GPP Access

Emergency Registration procedure for trusted non-3GPP access shall be supported as specified in clause 4.12.2.3 for untrusted non-3GPP access with the following differences:

– The regular registration shall refer to clause 4.12a.2.

– The N3IWF is substituted by the TNGF.

– The N3IWF key is substituted by the TNGF key.

4.12a.3 Deregistration procedure for Trusted non-3GPP access

The Deregistration procedure via trusted non-3GPP access shall be supported as specified in clause 4.12.3 for the untrusted non-3GPP access with the following modifications:

– The untrusted non-3GPP access is substituted by a trusted non-3GPP access point (TNAP).

– The N3IWF is substituted by the TNGF.

– If the UE has reserved QoS resources over non-3GPP access by using the Additional QoS Information (specified in clause 4.12a.5), then the UE shall release these resources.

4.12a.4 N2 procedures via Trusted non-3GPP Access

4.12a.4.1 Service Request procedures via Trusted non-3GPP Access

The Service Request procedure via trusted non-3GPP access shall be supported as specified in clause 4.12.4.1 for the untrusted non-3GPP access with the following modifications:

– The untrusted non-3GPP access is substituted by a trusted non-3GPP access.

– The N3IWF is substituted by the TNGF.

– The user plane between the UE and TNGF is established with IKEv2 signalling, as specified in clause 4.12a.5 (i.e. by using an IKEv2 Create_Child_SA exchange). The IKEv2 Create Child SA Request shall include the Additional QoS Information to reserve non-3GPP specific QoS resources as defined in clause 4.12a.5.

4.12a.4.2 Procedure for the UE context release in the TNGF

This procedure for releasing the N2 signalling connection and the N3 user plane connection for a UE connected to 5GC via trusted non-3GPP access, shall be the same as the procedure specified in clause 4.12.4.2 for the untrusted non-3GPP access with the following modifications:

– The untrusted non-3GPP access is substituted by a trusted non-3GPP access point (TNAP).

– The N3IWF is substituted by the TNGF.

– If the UE has reserved any non-3GPP specific QoS resources, the UE releases these resources when the IKEv2 Child SA is released.

4.12a.4.3 CN-initiated selective deactivation of UP connection of an existing PDU Session associated with Trusted non-3GPP Access

The procedure described in clause 4.3.7 (CN-initiated selective deactivation of UP connection of an existing PDU Session) is used for CN-initiated selective deactivation of UP connection for an established PDU Session associated with trusted non-3GPP Access for a UE in CM-CONNECTED state, with the following exceptions:

– The NG-RAN corresponds to a TNAN including a TNGF.

– The user plane between the UE and TNGF, i.e. Child SA(s) for the PDU Session, is released not with RRC signalling but with IKEv2 signalling, as specified in clause 4.12a.7.

– If the UE has reserved any non-3GPP specific QoS resources, the UE releases these resources when the IKEv2 Child SA is released.

4.12a.5 UE Requested PDU Session Establishment via Trusted non-3GPP Access

After the UE registers to 5GC via trusted non-3GPP access, the UE may request a PDU Session establishment by using the same procedure as the one specified in clause 4.12.5 for untrusted non-3GPP access, with the following modifications:

– The N3IWF in Figure 4.12.5-1 should be substituted with a TNGF and the Untrusted non-3GPP access should be substituted with a Trusted non-3GPP Access Point (TNAP).

– The TNGF may send a TNGF Identities parameter to AMF inside an N2 Uplink NAS Transport message. The TNGF Identities parameter contains a list of identifiers (i.e. FQDNs or IP addresses) of N3 terminations supported by the TNGF. If received by the AMF, it shall forward it to the SMF, which may use it as input to UPF selection.

– The IKEv2 Create Child SA Request message that is sent by the TNGF to UE (in steps 4a and 4c), in order to establish a child SA for one or more QoS flows, shall also include Additional QoS Information. The Additional QoS Information shall contain:

a) If the IPsec child SA carries a GBR flow: QoS Characteristics and GBR QoS Flow Information:

– The QoS Characteristics are associated with the 5QI of the GBR flow and are defined in clause 5.7.3 of TS 23.501 [2]. The TNGF either receives the QoS Characteristics via the N2 interface (in the case of a dynamically assigned 5QI), or is pre-configured with the QoS Characteristics (in the case of a standardized 5QI).

– The GBR QoS Flow Information (defined in TS 38.413 [10]) is part of the QoS Profile received via the N2 interface and contains: MFBR, GFBR and optionally Maximum Packet Loss Rate. The Notification Control is not included in the QoS profile.

b) If the IPsec child SA carries a non-GBR flow: QoS Characteristics:

– The QoS Characteristics are defined in bullet a) above.

The TNGF may aggregate multiple GBR flows or multiple non-GBR flows into the same IPsec child SA. In this case, the TNGF derives, in an implementation specific way, the QoS Characteristics of the aggregated flow by considering the QoS Characteristics of the individual flows. Similarly, the TNGF derives, in an implementation specific way, the GBR QoS Flow Information of an aggregated GBR flow by considering the GBR QoS Flow Information of the individual GBR flows.

NOTE: The above behaviour of the TNGF does not create any impact on the N2 interface.

– After receiving an IKEv2 Create Child SA Request message, the UE shall use the Additional QoS Information contained in this message to determine what QoS resources to reserve over the non-3GPP access, including e.g. guaranteed bit rates and delay bounds for UL/DL communication. How the UE determines what QoS resources to reserve over the non-3GPP access and how these QoS resources are reserved, is outside the scope of 3GPP specifications.

– If the UE fails to reserve QoS resources over non-3GPP access for the QoS flows associated with the child SA (e.g. because the non-3GPP Access Network rejects the allocation of the requested bit rates), the UE shall reject the IKEv2 Child SA Request.

4.12a.6 UE or network Requested PDU Session Modification via Trusted non-3GPP access

The UE or network requested PDU Session Modification procedure via trusted non-3GPP access is the same procedure as the one specified in clause 4.12.6 for untrusted non-3GPP access, with the following modifications:

– The N3IWF in Figure 4.12.6-1 should be substituted with a TNGF and the Untrusted non-3GPP access should be substituted with a Trusted non-3GPP Access Point (TNAP).

– The IKEv2 Create Child SA Request sent by the TNGF in step 4a, in order to create new QoS flow(s) for the PDU Session, shall include the Additional QoS Information defined in clause 4.12a.5. If the UE decides to reserve QoS resources over non-3GPP access for the QoS flows associated with the Child SA but fails to reserve these resources, the UE shall reject the IKEv2 Child SA Request.

– The IKEv2 Informational Request sent by the TNGF in step 4b shall include the Additional QoS Information defined in clause 4.12a.5, when the IKEv2 Informational Request is sent to modify one or more existing QoS flows. If the UE decides to reserve QoS resources over non-3GPP access for the QoS flows associated with the Child SA but fails to reserve these resources, the UE shall indicate the failure in the IKEv2 Informational Response. The TNGF includes the list of QoS flows which are failed to setup in step 5.

– The IKEv2 Informational Request sent by the TNGF in step 4c to release an existing IKEv2 Child SA shall trigger the UE to release the resources reserved over non-3GPP access for this IKEv2 Child SA.

– If, after the PDU Session establishment, the UE determines that the QoS resources reserved over non-3GPP access for the QoS flows associated with a Child SA are released, then the UE shall initiate an INFORMATIONAL exchange, as specified in RFC 7296 [3], to delete the Child SA. After the Child SA is deleted, the TNGF initiates PDU Session Modification procedure as described in step 1e, in clause 4.3.3.2, including the list of QoS flows, which are released.

4.12a.7 UE or network Requested PDU Session Release via Trusted non-3GPP access

The UE or the network can release a PDU Session via a trusted non-3GPP Access Network as specified in clause 4.12.7 for the untrusted non-3GPP access with the following modifications:

– The untrusted non-3GPP access is substituted by a trusted non-3GPP access point (TNAP).

– The N3IWF is substituted by the TNGF.

– If the UE reserved any non-3GPP specific QoS resources, the UE releases these resources when the IKEv2 Child SA is released.

4.12a.8 Mobility from a non-geographically selected AMF to a geographically selected AMF

The procedure specified in clause 4.12.8 for untrusted non-3GPP access applies also to the trusted non-3GPP access with the following modifications:

– The untrusted non-3GPP access is substituted by a trusted non-3GPP access point (TNAP).

– The N3IWF is substituted by the TNGF.

– The PDU Session is activated in step 2 as specified in clause 4.12a.5.

4.12a.9 Support of mobility from source to target TNAP

In this Release, if the UE moves from a source TNAP to a target TNAP, the UE shall perform a full authentication via the target TNAP to re-connect to the 5G system.