4.12 Procedures for Untrusted non-3GPP access

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

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

4.12.1 General

Clause 4.12 defines the procedures to support Untrusted non-3GPP access by describing the differences compared to the defined procedures in other clauses. The procedures for Untrusted non-3GPP access are also used by a UE that accesses SNPN services via a PLMN over 3GPP access.

4.12.2 Registration via Untrusted non-3GPP Access

4.12.2.1 General

Clause 4.12.2 specifies how a UE can register to 5GC via an untrusted non-3GPP Access Network. It is based on the Registration procedure specified in clause 4.2.2.2.2 and it uses a vendor-specific EAP method called "EAP-5G". The EAP-5G packets utilize the "Expanded" EAP type and the existing 3GPP Vendor-Id registered with IANA under the SMI Private Enterprise Code registry. The "EAP-5G" method is used between the UE and the N3IWF and is utilized only for encapsulating NAS messages (not for authentication). If the UE needs to be authenticated, mutual authentication is executed between the UE and AUSF. The details of the authentication procedure are specified in TS 33.501 [15].

In Registration and subsequent Registration procedures via untrusted 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.12.2.2 Registration procedure for untrusted non-3GPP access

The signalling flow in Figure 4.12.2.2-1 does not show all the details of a registration procedure via untrusted non-3GPP access. It shows primarily the steps executed between the UE and N3IWF. All the details of a registration procedure, including interactions with PCF, UDM, etc. are specified in clause 4.2.2.2.2.

Figure 4.12.2.2-1: Registration via untrusted non-3GPP access

1. The UE connects to an untrusted non-3GPP Access Network with any appropriate authentication procedure and it is assigned an IP address. For example, a non-3GPP authentication method can be used, e.g. no authentication (in the case of a free WLAN), EAP with pre-shared key, username/password, etc. When the UE decides to attach to 5GC network, the UE not operating in SNPN access mode selects an N3IWF in a 5G PLMN, as described in clause 6.3.6 of TS 23.501 [2]. When the UE decides to attach to 5GC network, the UE operating in SNPN access mode selects an N3IWF in an SNPN, as described in clause 6.3.6.2a of TS 23.501 [2].

NOTE 1: The UE Selection of a N3IWF that supports the S-NSSAIs needed by the UE is enabled based on ANDSP configuration defined in TS 23.501 [2]. The N3IWF selection based on this information is documented in TS 23.501 [2].

2. The UE proceeds with the establishment of an IPsec Security Association (SA) with the selected N3IWF by initiating an IKE initial exchange according to RFC 7296 [3]. After step 2, all subsequent IKE messages are encrypted and integrity protected by using the IKE SA established in this step.

3. The UE shall initiate an IKE_AUTH exchange by sending an IKE_AUTH request message. The AUTH payload is not included in the IKE_AUTH request message, which indicates that the IKE_AUTH exchange shall use EAP signalling (in this case EAP-5G signalling). If the UE supports MOBIKE, it shall include a Notify payload in the IKE_AUTH request, as specified in RFC 4555 [40], indicating that MOBIKE is supported. In addition, as specified in TS 33.501 [15], if the UE is provisioned with the N3IWF root certificate, it shall include the CERTREQ payload within the IKE_AUTH request message to request the N3IWF’s certificate.

4. The N3IWF responds with an IKE_AUTH response message, which includes an EAP-Request/5G-Start packet. The EAP-Request/5G-Start packet informs the UE to initiate an EAP-5G session, i.e. to start sending NAS messages encapsulated within EAP-5G packets. If the N3IWF has received a CERTREQ payload from the UE, the N3IWF shall include the CERT payload in the IKE_AUTH response message containing the N3IWF’s certificate. How the UE uses the N3IWF’s certificate is specified in TS 33.501 [15].

5. The UE shall send an IKE_AUTH request, which includes an EAP-Response/5G-NAS packet that contains the Access Network parameters (AN parameters) and a Registration Request message. The AN parameters contain information that is used by the N3IWF for selecting an AMF in the 5G core network. This information includes e.g. the GUAMI, the Selected PLMN ID (or PLMN ID and NID, see clause 5.30 of TS 23.501 [2]), the Requested NSSAI and the Establishment cause. The Establishment cause provides the reason for requesting a signalling connection with 5GC. Whether and how the UE includes the Requested NSSAI as part of the AN parameters is dependent on the value of the Access Stratum Connection Establishment NSSAI Inclusion Mode parameter, as specified in clause 5.15.9 of TS 23.501 [2]. The registration request may contain an indication that the UE supports N3IWF selection based on the slices the UE wishes to use over untrusted non-3GPP access (i.e. that the UE supports Extended Home N3IWF identifier configuration and Slice-specific N3IWF prefix configuration).

NOTE 2: The N3IWF does not send an EAP-Identity request because the UE includes its identity in the first IKE_AUTH. This is in line with RFC 7296 [3] clause 3.16.

6. The N3IWF shall select an AMF based on the received AN parameters and local policy, as specified in clause 6.3.5 of TS 23.501 [2]. The N3IWF shall then forward the Registration Request received from the UE to the selected AMF within an N2 message. This message contains N2 parameters that include 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 Untrusted non-3GPP access.

7. The selected AMF may decide to request the SUCI by sending a NAS Identity Request message to UE. This NAS message and all subsequent NAS messages are sent to UE encapsulated within EAP/5G-NAS packets.

8. The AMF may decide to authenticate the UE by invoking an AUSF. In this case, the AMF shall select an AUSF as specified in clause 6.3.4 of TS 23.501 [2] based on SUPI or SUCI.

The AUSF executes the authentication of the UE as specified in TS 33.501 [15]. The AUSF selects a UDM as described in clause 6.3.8 of TS 23.501 [2] and gets the authentication data from UDM. The authentication packets are encapsulated within NAS authentication messages and the NAS authentication messages are encapsulated within EAP/5G-NAS packets. After the successful authentication:

– In step 8h, the AUSF shall send the anchor key (SEAF key) to AMF which is used by AMF to derive NAS security keys and a security key for N3IWF (N3IWF key). The UE also derives the anchor key (SEAF key) and from that key it derives the NAS security keys and the security key for N3IWF (N3IWF key). The N3IWF key is used by the UE and N3IWF for establishing the IPsec Security Association (in step 11).

– In step 8h, the AUSF shall also include the SUPI, if in step 8a the AMF provided to AUSF a SUCI.

NOTE 4: EAP-AKA’ or 5G-AKA are allowed for the authentication of UE via non-3GPP access, as specified in TS 33.501 [15]. Figure 4.12.2.2-1 only shows authentication flow using EAP-AKA’. Authentication methods other than EAP-AKA’ or 5G-AKA are also allowed for UE accessing SNPN services via a PLMN, as specified in TS 33.501 [15], Annex I, as well as for UE accessing SNPN services directly via Untrusted non-3GPP access.

9a. The AMF shall send a NAS Security Mode Command to UE in order to activate NAS security. If an EAP-AKA’ authentication was successfully executed in step 8, the AMF shall encapsulate the EAP-Success received from AUSF within the NAS Security Mode Command message.

9b. The N3IWF shall forward the NAS Security Mode Command message to UE within an EAP/5G-NAS packet.

9c. The UE completes the EAP-AKA’ authentication (if initiated in step 8), creates a NAS security context and an N3IWF key and sends the NAS Security Mode Complete message within an EAP/5G-NAS packet.

9d. The N3IWF relays the NAS Security Mode Complete message to the AMF.

10a. Upon receiving NAS Security Mode Complete, the AMF shall send an NGAP Initial Context Setup Request message that includes the N3IWF key.

10b. This triggers the N3IWF to send an EAP-Success to UE, which completes the EAP-5G session. No further EAP-5G packets are exchanged.

11. The IPsec SA is established between the UE and N3IWF by using the common N3IWF key that was created in the UE in step 9c and received by the N3IWF in step 10a. This IPsec SA is referred to as the "signalling IPsec SA". After the establishment of the signalling IPsec SA, the N3IWF notifies the AMF that the UE context (including AN security) was created by sending a NGAP Initial Context Setup Response. The signalling IPsec SA shall be configured to operate in tunnel mode and the N3IWF shall assign to UE an "inner" IP address. If the N3IWF has received an indication that the UE supports MOBIKE (see step 3), then the N3IWF shall include a Notify payload in the IKE_AUTH response message sent in step 11a, indicating that MOBIKE shall be supported, as specified in RFC 4555 [40].

All subsequent NAS messages exchanged between the UE and N3IWF shall be sent via the signalling IPsec SA and shall be carried over TCP/IP. 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 that is received in step 11a. The N3IWF 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. The TCP connection used for reliable NAS transport between the UE and N3IWF shall be initiated by the UE right after the signalling IPsec SA is established in step 11a. The UE shall send the TCP connection request to the NAS_IP_ADDRESS and to the TCP port number specified in TS 24.502 [41].

12. The AMF determines the subset of the requested NSSAI that is allowed by the subscribed S-NSSAI(s); the AMF may detect that the N3IWF used by the UE is not compatible with this subset and then proceed with steps 15-19. Otherwise, i.e. if the N3IWF supports the subset of the requested NSSAI that is allowed by the subscribed S-NSSAI(s), the AMF proceeds with step 13 and 14 and steps 15-19 are skipped.

NOTE 5: The AMF considers the subscribed S-NSSAI(s) before determining to trigger the UE PCF to avoid triggering the UE PCF to update the UE policies for Requested S-NSSAIs that the UE is not subscribed for.

13. The AMF sends the NAS Registration Accept message in an N2 message sent to the N3IWF. The N2 Message includes the Allowed NSSAI for the access type for the UE. The Allowed NSSAI is a subset of the slices supported by the selected N3IWF.

14. The N3IWF forwards the NAS Registration Accept message to UE via the established signalling IPsec SA. If the NAS Registration Accept message is received by the N3IWF before the IPsec SA is established, the N3IWF shall store it and forward it to the UE only after the establishment of the signalling IPsec SA.

Steps 15 to 19 correspond to the case where the AMF has detected that the N3IWF used by the UE is not compatible with the subset of the requested NSSAI that is allowed by the subscribed S-NSSAI(s).

15. If the UE Registration Request contains an indication that the UE supports N3IWF selection based on the slices the UE wishes to use over untrusted non-3GPP access, the AMF may trigger the UE PCF to update the N3IWF selection related policies on the UE (contained in ANDSP.

NOTE 6: The UE is assumed to inform PCF whether the UE supports Extended Home N3IWF identifier configuration and Slice-specific N3IWF prefix configuration as part of the UE policy update procedure. Details will be specified in Stage 3 specifications.

16. The PCF updates the UE policy per procedure in figure 4.2.4.3-1.

17. The AMF sends via the N3IWF a UE Registration Reject indicating that the UE selected N3IWF was not appropriate for the requested slices that the UE is allowed to access to. The AMF optionally may provide target N3IWF information (FQDN and/or IP address) to the UE within the Registration Reject message.

Editor’s note: Whether to prevent to prevent the UE from loop of registration request and AMF reject for example in case of error in policy update, in UE policy provided, etc. is FFS.

NOTE 7: The AMF may determine a target N3IWF that supports the subset of the requested NSSAI that is allowed by the subscribed S-NSSAI(s) based on the list of supported TAs and the corresponding list of supported slices for each TA obtained in N2 interface management procedures as specified in TS 38.413 [10].

Editor’s note: Whether there is a need for the PCF to notify AMF about the completion of policy delivery is FFS.

18. If supported by the UE and if the UE received target N3IWF information in step 17, the UE connects to the target N3IWF, otherwise the UE may perform N3IWF selection again using the updated N3IWF selection information received in step 16. The UE uses the target N3IWF information in the Registration Reject only for the N3IWF selection directly following the rejected registration and UE shall not store for future use.

The AMF provides the Access Type set to "Non-3GPP access" to the UDM when it registers with the UDM and the RAT type determined as specified in clause 5.3.2.3 of TS 23.501 [2].

NOTE 8: The Access Type and the RAT type are is set to "Untrusted Non-3GPP access" even when the UE accesses SNPN services via PLMN over 3GPP access.

4.12.2.3 Emergency Registration for untrusted non-3GPP Access

Emergency Registration procedure is used by UEs requiring to perform emergency services but cannot gain normal services from the network. These UEs are in limited service state as defined in TS 23.122 [22].

The regular registration procedure described in clause 4.12.2 applies with the following differences:

– If the UE has no SUPI and no valid 5G-GUTI, PEI shall be included instead of its encrypted Permanent User ID (SUCI) in the NAS message.

– NSSAI shall not be included by the UE. The AMF shall not send the Allowed NSSAI in the Registration Accept message.

– If the AMF is not configured to support Emergency Registration, the AMF shall reject any Registration Request that indicates Registration type "Emergency Registration".

– If the AMF is configured to support Emergency Registration for unauthenticated UEs and the UE indicated Registration Type "Emergency Registration", the AMF skips the authentication and security setup or the AMF accepts that the authentication may fail and continues the Emergency Registration procedure.

– If the authentication is performed successfully, the NAS messages will be protected by the NAS security functions (integrity and ciphering). The AMF shall derive the N3IWF key, per TS 33.501 [15] and shall provide it to the N3IWF after the authentication completion using an NGAP Initial Context Setup Request message as in the regular registration procedure.

– If the authentication is skipped or authentication fails, the NAS messages will not be protected by the NAS security functions (integrity and ciphering). However, the AMF shall create an N3IWF key and shall provide it to the N3IWF after the authentication completion (whenever authentication has failed or has been skipped) using an NGAP Initial Context Setup Request message. The N3IWF shall use it to complete IKE SA establishment and shall acknowledge the AMF by sending an NGAP Initial Context Setup Response message.

NOTE: According to TS 33.501 [15], the UE and the AMF independently generate the KAMF (and derived keys) in an implementation defined way and populate the 5G NAS security context with this KAMF to be used when activating a 5G NAS security context."

– As in step 14 of figure 4.2.2.2.2-1 for Emergency Registration, if the UE was not successfully authenticated, the AMF shall not update the UDM. Also for an Emergency Registration, the AMF shall not check for access restrictions, regional restrictions or subscription restrictions.

– Steps 16 and 21b of figure 4.2.2.2.2-1 are not performed since AM and UE policy for the UE are not required for Emergency Registration.

4.12.3 Deregistration procedure for untrusted non-3gpp access

Figure 4.12.3-1: Deregistration procedure for untrusted non-3gpp access

1. The Deregistration procedure is triggered by one of the events:

1a. For UE-initiated Deregistration as in steps from 1 to 7 of Figures 4.2.2.3.2-1.

1b. For network initiated deregistration as in steps from 1 to 6 of Figure 4.2.2.3.3-1.

If the UE is in CM-CONNECTED state either in 3GPP access, non-3GPP access or both,

– the AMF may explicitly deregister the UE by sending a Deregistration request message ( Deregistration type, access type set to non-3GPP) to the UE as in step 2 of Figure 4.2.2.3.3-1.

– the UDM may want to request the deletion of the subscribers RM contexts and PDU Sessions with the reason for removal set to subscription withdrawn to the registered AMF as in step 1 of Figure 4.2.2.3.3-1.

2. AMF to N3IWF: The AMF sends a N2 Context UE Release Command message to the N3IWF with the cause set to Deregistration to release N2 signalling as defined in step 4 of clause 4.12.4.2.

3. N3IWF to UE: The N3IWF sends INFORMATIONAL Request (Delete payload) message to the UE. The Delete payload is included to indicate the release of the IKE SA.

4. UE to N3IWF: The UE sends an empty INFORMATIONAL Response message to acknowledge the release of the IKE SA as described in RFC 7296 [3]. Non-3GPP access specific resources are released including the IKEv2 tunnel (and the associated IPSec resources) and the local UE contexts in N3IWF (N3 tunnel Id).

5. N3IWF to AMF: The N3IWF acknowledges the N2 UE Context Release Command message by sending N2 UE Context Release Complete message to the AMF as defined in step 7 of clause 4.12.4.2.

4.12.4 N2 procedures via Untrusted non-3GPP Access

4.12.4.1 Service Request procedures via Untrusted non-3GPP Access

The Service Request procedure via Untrusted non-3GPP Access shall be used by a UE in CM-IDLE state over non-3GPP access to request the re-establishment of the NAS signalling connection and the re-establishment of the user plane for all or some of the PDU Sessions which are associated to non-3GPP access.

The Service Request procedure via Untrusted non-3GPP Access shall be used by a UE in CM-CONNECTED state over non-3GPP access to request the re-establishment of the user plane for one or more PDU Sessions which are associated to non-3GPP access.

When the UE is in CM-IDLE state over non-3GPP access, the Service Request procedure via Untrusted non-3GPP Access is as described in clause 4.2.3.2 (UE Triggered Service Request) with the following exceptions:

– The Service Request procedure is never a response to a Paging, i.e. there is no Network Triggered Service Request procedure via Untrusted non-3GPP Access.

– The (R)AN corresponds to an N3IWF.

– The UE establishes a "signalling IPsec SA" with the N3IWF by using the procedure specified in clause 4.12.2 for the registration via untrusted non-3GPP access. In particular, the UE includes the Service Request and the AN parameters in an EAP-5G packet, which is further encapsulated in an IKE_AUTH request.

– The AN parameters include the Selected PLMN ID (or PLMN ID and NID, see clause 5.30 of TS 23.501 [2]) and Establishment cause. The Establishment cause provides the reason for requesting a signalling connection with the 5GC. The UE includes GUAMI information in the AN parameters. The N3IWF selects the AMF according to GUAMI information.

– The N2 parameters sent from N3IWF to AMF include the Establishment cause.

– The user plane between the UE and N3IWF is established not with RRC signalling but with IKEv2 signalling, as specified in clause 4.12.5 (i.e. by using an IKEv2 Create_Child_SA exchange). The user plane of each PDU Session consists of one or more Child SAs.

When the UE is in CM-CONNECTED state over non-3GPP access, the Service Request procedure via Untrusted non-3GPP Access is as described in clause 4.2.3.2 (UE Triggered Service Request) with the following exceptions:

– All NAS signalling exchanged between the UE and network is transferred within the established "signalling IPsec SA".

– The (R)AN corresponds to an N3IWF.

When the UE is in CM-CONNECTED state over non-3GPP access and the network receives downlink data for a PDU Session over non-3GPP access that has no user plane, the steps 1-4a in clause 4.2.3.3 (Network Triggered Service Request) shall be performed with the following exceptions:

– The (R)AN corresponds to an N3IWF.

– The user plane between the UE and N3IWF is established (in step 4a) with IKEv2 signalling, as specified in clause 4.12.5 (i.e. by using an IKEv2 Create_Child_SA exchange). The user plane of each PDU Session consists of one or more Child SAs.

4.12.4.2 Procedure for the UE context release in the N3IWF

This procedure is used to release the N2 signalling connection and the N3 User Plane connection. If the procedure is initiated by the AMF the IKEv2 SA for a UE is being released. The procedure will move the UE from CM-CONNECTED to CM-IDLE in AMF and all UE related context information is deleted in the N3IWF.

Both N3IWF-initiated and AMF-initiated UE context release in the N3IWF procedures are shown in Figure 4.12.4.2-1.

Figure 4.12.4.2-1: Procedure for the UE context release in the N3IWF

1. The UE has already registered in the 5GC and may have established one or multiple PDU Sessions.

2. The N3IWF detects that the UE is not reachable.

3. The N3IWF sends a N2 UE Context Release Request message to the AMF This step is equivalent to step 1b of Figure 4.2.6-1.

NOTE: AN Release procedure can also be triggered by an AMF internal event and in that case step 2 and step 3 do not take place.

4. AMF to N3IWF: If the AMF receives the N2 UE Context Release Request from N3IWF or if due to an internal AMF event the AMF wants to release N2 signalling, the AMF sends an N2 UE Context Release Command (Cause) to the N3IWF. The cause indicated is cause from step 3 or a cause due to internal AMF event. This step is equivalent to step 2 of Figure 4.2.6-1.

5. If the IKEv2 tunnel has not been released yet, the N3IWF performs the release of the IPsec tunnel as defined in RFC 7296 [3] indicating to release the IKE SA and any Child IPSec SA if existing. The N3IWF sends to the UE the indication of the release reason if received in step 4.

6. The UE sends an empty INFORMATIONAL Response message to acknowledge the release of the IKE SA as described in RFC 7296 [3]. The N3IWF deletes the UE’s context after receiving the empty INFORMATIONAL Response message.

7. N3IWF to AMF: The N3IWF confirms the release of the UE-associated N2-logical connection by returning N2 UE Release Complete (list of PDU Session ID(s) with active N3 user plane) to the AMF as in step 4 defined in clause 4.2.6. The AMF marks the UE as CM-IDLE state in untrusted non-3GPP access.

8. For each of the PDU Sessions in the N2 UE Context Release Complete, the steps 5 to 7 in clause 4.2.6 are performed (PDU Session Update SM Context). After the AMF receives the Nsmf_PDUSession_UpdateSMContext Response as in step 7 of clause 4.2.6, the AMF considers the N3 connection as released. If list of PDU Session ID(s) with active N3 user plane is included in step 3, then this step is performed before step 4.

4.12.4.3 CN-initiated selective deactivation of UP connection of an existing PDU Session associated with Untrusted 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 non-3GPP Access of a UE in CM-CONNECTED state, with the following exceptions:

– The NG-RAN corresponds to an N3IWF.

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

4.12.5 UE Requested PDU Session Establishment via Untrusted non-3GPP Access

Clause 4.12.5 specifies how a UE can establish a PDU Session via an untrusted non-3GPP Access Network as well as to hand over an existing PDU Session between 3GPP access and non-3GPP access. The procedure applies in non-roaming, roaming with LBO as well as in home-routed roaming scenarios.

For non-roaming and LBO scenarios, if the UE is simultaneously registered to a 3GPP access in a PLMN different from the PLMN of the N3IWF, the functional entities in the following procedures are located in the PLMN of the N3IWF. For home-routed roaming scenarios, the AMF, V-SMF and associated UPF in VPLMN in the following procedure is located in the PLMN of the N3IWF.

The procedure below is based on the PDU Session Establishment procedure specified in clause 4.3.2.2.1 (for non-roaming and roaming with LBO) and the PDU Session Establishment procedure specified in clause 4.3.2.2.2 (for home-routed roaming).

Figure 4.12.5-1: PDU Session establishment via untrusted non-3GPP access

1. The UE shall send a PDU Session Establishment Request message to AMF as specified in step 1 of clause 4.3.2.2.1. This message shall be sent to N3IWF via the IPsec SA for NAS signalling (established as specified in clause 4.12.2) and the N3IWF shall transparently forward it to AMF in the 5GC.

2a. In the case of non-roaming or roaming with Local Breakout, steps 2-11 specified in clause 4.3.2.2.1are executed according to the PDU Session Establishment procedure over 3GPP access. In the case of home-routed roaming, steps 2-14 specified in clause 4.3.2.2.2 are executed according to the PDU Session Establishment procedure over 3GPP access.

2b. As described in step 12 of clause 4.3.2.2.1, the AMF shall send a N2 PDU Session Request message to N3IWF to establish the access resources for this PDU Session.

3. Based on its own policies and configuration and based on the QoS profiles received in the previous step, the N3IWF shall determine the number of IPsec Child SAs to establish and the QoS profiles associated with each IPsec Child SA. For example, the N3IWF may decide to establish one IPsec Child SA and associate all QoS profiles with this IPsec Child SA. In this case, all QoS Flows of the PDU Session would be transferred over one IPsec Child SA.

4a. The N3IWF shall send to UE an IKE Create_Child_SA request according to the IKEv2 specification in RFC 7296 [3] to establish the first IPsec Child SA for the PDU Session. The IKE Create_Child_SA request indicates that the requested IPsec Child SA shall operate in tunnel mode. This request shall include a 3GPP-specific Notify payload which contains (a) the QFI(s) associated with the Child SA, (b) the identity of the PDU Session associated with this Child SA, (c) optionally, a DSCP value associated with the Child SA, (d) optionally a Default Child SA indication and (e) optionally, the Additional QoS Information specified in clause 4.12a.5

The IKE Create_Child_SA request shall also include another 3GPP-specific Notify payload, which contains the UP_IP_ADDRESS that is specified in step 8 below.

If a DSCP value is included, then the UE and the N3IWF shall mark all IP packets sent over this Child SA with this DSCP value. There shall be one and only one Default Child SA per PDU session. The UE shall send all QoS Flows to this Child SA for which there is no mapping information to a specific Child SA. The IKE Create_Child_SA request also contains other information (according to RFC 7296 [3]) such as the SA payload, the Traffic Selectors (TS) for the N3IWF and the UE, etc.

After receiving the IKE Create_Child_SA request, if the Additional QoS Information is received, the UE may reserve non-3GPP Access Network resources according to the Additional QoS Information.

4b. If the UE accepts the new IPsec Child SA, the UE shall send an IKE Create_Child_SA response according to the IKEv2 specification in RFC 7296 [3]. During the IPsec Child SA establishment the UE shall not be assigned an IP address.

4c-4d. If in step 3 the N3IWF determined to establish multiple IPsec Child SAs for the PDU Session, then additional IPsec Child SAs shall be established, each one associated with one or more QFI(s), optionally with a DSCP value, with a UP_IP_ADDRESS and optionally with the Additional QoS Information specified in clause 4.12a.5. For each IPsec Child SA, if the Additional QoS Information is received, the UE may reserve non-3GPP Access Network resources according to the Additional QoS Information for the IPsec Child SA.

5. After all IPsec Child SAs are established, the N3IWF shall forward to UE via the signalling IPsec SA (see clause 4.12.2.2) the PDU Session Establishment Accept message received in step 2b.

6. The N3IWF shall send to AMF an N2 PDU Session Response.

7. In the case of non-roaming or roaming with Local Breakout, all steps specified in clause 4.3.2.2.1 after step 14 are executed according to the PDU Session Establishment procedure over 3GPP access. In the case of home-routed roaming, all steps specified in clause 4.3.2.2.2 after step 18 are executed according to the PDU Session Establishment procedure over 3GPP access.

8. On the user-plane:

– When the UE has to transmit an UL PDU, the UE shall determine the QFI associated with the UL PDU (by using the QoS rules of the PDU Session), it shall encapsulate the UL PDU inside a GRE packet and shall forward the GRE packet to N3IWF via the IPsec Child SA associated with this QFI. The header of the GRE packet carries the QFI associated with the UL PDU. The UE shall encapsulate the GRE packet into an IP packet with source address the "inner" IP address of the UE and destination address the UP_IP_ADDRESS associated with the Child SA.

– When the N3IWF receives a DL PDU via N3, the N3IWF uses the QFI and the identity of the PDU Session in order to determine the IPsec Child SA to use for sending the DL PDU over NWu. The N3IWK encapsulates the DL PDU inside a GRE packet and copies the QFI in the header of the GRE packet. The N3IWF may include also in the GRE header a Reflective QoS Indicator (RQI), which shall be used by the UE to enable reflective QoS. The N3IWF shall encapsulate the GRE packet into an IP packet with source address the UP_IP_ADDRESS associated with the Child SA and destination address the "inner" IP address of the UE.

4.12.6 UE or Network Requested PDU Session Modification via Untrusted non-3GPP access

The UE or network requested PDU Session Modification procedure via untrusted non-3GPP access is depicted in figure 4.12.6-1. The procedure applies in non-roaming, roaming with LBO as well as in home-routed roaming scenarios.

For non-roaming and LBO scenarios, the functional entities in the following procedures are located in the PLMN of the N3IWF.

The procedure below is based on the PDU Session Modification procedure specified in clause 4.3.3.2 (for non-roaming and roaming with LBO) and on the PDU Session Modification procedure specified in clause 4.3.3.3 (for home-routed roaming).

Figure 4.12.6-1: UE or Network Requested PDU Session Modification via untrusted non-3GPP access

1. If the PDU Session Modification procedure is initiated by the UE, the UE shall send a PDU Session Modification Request message to AMF as specified in step 1 of clause 4.3.2.2. The message shall be sent to N3IWF via the established IPsec SA for NAS signalling. The N3IWF shall transparently forward the PDU Session Modification Request to AMF/SMF.

2. In the case of non-roaming or LBO, the steps 1a (from AMF) to 1e and steps 2-3 as per the PDU Session Modification procedure in clause 4.3.3.2 are executed.

In the case of home-routed, the steps 1a (from AMF) to 1d and steps 2-3 as per the PDU Session Modification procedure in clause 4.3.3.3 are executed.

3. The AMF sends N2 PDU Session Resource Modify Request (N2 SM information received from SMF, NAS message) message to the N3IWF. This step is the same as step 4 in clause 4.3.3.2 (for non-roaming and roaming with Local Breakout) and step 5 in clause 4.3.3.3 (for home-routed roaming).

4. The N3IWF may issue IKEv2 signalling exchange with the UE that is related with the information received from SMF according to the IKEv2 specification in RFC 7296 [3]. Based on the N2 SM information received from the SMF, the N3IWF may perform one of the following:

4a. The N3IWF may decide to create a new Child SA for the new QoS Flow(s). In this case, the N3IWF establishes a new Child SA by sending an IKE_CREATE_CHILD_SA request message, which includes the SA, the PDU Session ID, the QFI(s), optionally a DSCP value and optionally the Additional QoS Information specified in clause 4.12a.5. If the Additional QoS Information is received, the UE may reserve non-3GPP Access Network resources according to the Additional QoS Information.

4b. The N3IWF may decide to add or remove QoS Flow(s) to/from an existing Child SA. In this case, the N3WIF updates the QoS Flow and Child SA mapping information by sending an INFORMATIONAL request message, which includes the QFI(s) associated with the Child SA and optionally the Additional QoS Information specified in clause 4.12a.5, which contains the new QoS information that should be associated with the existing Child SA. If the Additional QoS Information is received, the UE may update the reserved non-3GPP Access Network resources for the existing Child SA according to the Additional QoS Information.

4c. The N3IWF may decide to delete an existing Child SA, e.g. when there is no QoS Flow mapped to this Child SA. In this case, the N3IWF deletes the existing Child SA by sending INFORMATIONAL request message, which includes a Delete payload.

NOTE: If the N3IWF has included the Default Child SA indication during the establishment of one of the Child SAs of the PDU Session, the N3IWF may not update the mapping between QoS Flows Child SAs.

5. The N3IWF acknowledges N2 PDU Session Request by sending a N2 PDU Session Response Message to the AMF to acknowledge the success or failure of the request.

6. In the case of non-roaming or LBO, step 7 as per the PDU Session Modification procedure in clause 4.3.3.2 is executed. In the case of home-routed, the steps 8-10 as per the PDU Session Modification procedure in clause 4.3.3.3 are executed.

7. The N3IWF sends the PDU Session Modification Command to UE (if received in step 3) and receives the response message from UE.

Steps 4a/4c and step 7 may happen consecutively. Steps 7b map happen before step 4b/4d.

8. The N3IWF forwards the NAS message to the AMF.

9. For non-roaming and roaming with LBO, all the steps after step 10 in clause 4.3.3.2 are executed according to the general PDU Session Modification procedure. For home-routed roaming, all steps after step 13 in clause 4.3.3.3 are executed according to the general PDU Session Modification procedure.

4.12.7 UE or network Requested PDU Session Release via Untrusted non-3GPP access

Clause 4.12.7 specifies how a UE or network can release a PDU Session via an untrusted non-3GPP Access Network. The UE requested PDU Session Release procedure via Untrusted non-3GPP access applies in non-roaming, roaming with LBO as well as in home-routed roaming scenarios.

NOTE: If the UE is simultaneously registered to 3GPP access in the same PLMN as non-3GPP access, when non-3GPP access is not available to the UE (e.g. due to out of non-3GPP access coverage) or UE is in CM-IDLE for non-3GPP access, the UE may perform the PDU Session Release procedure via 3GPP access as described in clause 4.3.4.

Figure 4.12.7-1: UE Requested PDU Session Release via Untrusted non-3GPP access

1. One or more PDU Sessions are already established for the UE using the procedure described in clause 4.12.2.

2. The UE sends a NAS message (N1 SM container (PDU Session Release Request), PDU Session ID) to the AMF via the N3IWF as defined in clause 4.3.4.

3. For non-roaming and roaming with LBO, the steps 1a (from AMF) to 4 according to the PDU Session Release procedure defined in clause 4.3.4.2 are executed. For home-routed roaming, the steps 1a (from AMF) to step 7 according to the PDU Session Release procedure defined in clause 4.3.4.3 are executed.

4. This step is the same as step 4 in clause 4.3.4.2 (non-roaming and LBO) and step 6 in clause 4.3.4.3 (home-routed roaming).

If the message received from the SMF does not include N2 SM Resource Release request, the AMF sends N2 Downlink NAS transport (N1 SM container (PDU Session Release Command), PDU Session ID,Cause) message to the N3IWF and steps 5 to 8 are skipped.

5. Upon receiving AN session release request message from the AMF, the N3IWF triggers the release of the corresponding Child SA by sending INFORMATIONAL EXCHANGE (Delete Payload) to the UE. Delete payload is included in the message listing the SPIs of the Child SAs to be deleted to this PDU Session as described in RFC 7296 [3].

6. The UE responds with INFORMATIONAL EXCHANGE (Delete Payload) message. Delete payload is included for the paired SAs going in the other direction as described in RFC 7296 [3].

7. This step is the same as step 6 in 4.3.4.2 (non-roaming and LBO) and step 8 in clause 4.3.4.3 (home-routed roaming).

8. For non-roaming and roaming with LBO, steps 7 according to the PDU Session Release procedure defined in clause 4.3.4.2 are executed. For home-routed roaming, step 9-10 according to the PDU Session Release procedure defined in clause 4.3.4.3 are executed.

9. The N3IWF delivers the NAS message (N1 SM container (PDU Session Release Command), PDU Session ID, Cause) to the UE.

10. The UE sends a NAS message (N1 SM container (PDU Session Release Ack), PDU Session ID) to the N3IWF.

11. This step is the same as step 9 in 4.3.4.2 (non-roaming and LBO) and step 11 in clause 4.3.4.3 (home-routed roaming).

Steps 5 and 9 may happen consecutively. Step 10 may happen before step 6.

12. For non-roaming and roaming with LBO, all steps after step 10 in the PDU Session Release procedure defined in clause 4.3.4.2 are executed. In the case of home-routed roaming, all steps after step 12 in the PDU Session Release procedure defined in clause 4.3.4.3 are executed.

The network requested PDU Session Release procedure via Untrusted non-3GPP access is the same as the network requested PDU Session Release Procedure specified in clause 4.3.4.2 (for Non-Roaming and Roaming with Local Breakout) with the following differences:

– The (R)AN corresponds to an N3IWF.

– In step 5 the N3IWF upon receiving N2 SM request to release the AN resources associated with the PDU Session from the AMF, the N3IWF triggers the release of the corresponding Child SA to the UE as specified in step 5 and 6, in Figure 4.12.7-1.

– User Location Information is not included in the step 6, 7a, 9, 10a and 12 of the procedure.

4.12.8 Mobility from a non-geographically selected AMF to a geographically selected AMF

This procedure describes the AMF change that takes place when an UE initially served via non-3GPP access by an AMF selected based on non-geographical criteria (e.g. because the UE had no 3GPP access coverage or because only non-geographically selectable N3IWF are deployed) gets 3GPP access and is now to be served by an AMF selected in the same PLMN by the NG-RAN based on geographical criteria.

Figure 4.12.8-1: Mobility from a non-geographically selected AMF to a geographically selected AMF

1. The UE registers over non-3GPP access, as described in clause 4.12.2. During this procedure:

a An AMF (source AMF) is selected by the N3IWF in step 6a, based on non-geographical criteria (e.g. because the UE has no 3GPP access coverage or because only non-geographically selectable N3IWF are deployed).

b The UE receives, within the Registration Accept message, a 5G-GUTI containing a GUAMI of the non-geographically selected AMF. The UE also receives an Allowed NSSAI and optionally Mapping Of Allowed NSSAI.

2. The UE may activate PDU Sessions over non-3GPP access, as described in clause 4.12.5.

3. The UE gets 3GPP access and issues a Registration Request over 3GPP access as defined in step 1 of Figure 4.2.2.2.2-1, providing its 5G-GUTI.

If the 5G-GUTI does not indicate an AMF of the same Region ID as that of the NG-RAN, the NG-RAN selects an AMF Set and an AMF in the AMF Set as described in clause 6.3.5 of TS 23.501 [2].

Steps 3 to 22 of Figure 4.2.2.2.2-1 take place including following aspects:

– step 4 of Figure 4.2.2.2.2-1 takes place i.e. the new AMF invokes the Namf_Communication_UEContextTransfer service operation on the old AMF to request the UE’s SUPI and MM Context.

– in step 5 of Figure 4.2.2.2.2-1, the old AMF includes information about active NGAP association to N3IWF.

– in step 18 of Figure 4.2.2.2.2-1, the new AMF modifies the NGAP association toward N3IWF.

– in step 21 of Figure 4.2.2.2.2-1, the Registration Accept message shall include the updated 5G-GUTI that the UE will use to update its 3GPP and non-3GPP registration contexts.