Content for  TS 23.502  Word version:  18.5.0

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 for NWu interface selects an N3IWF in a 5G PLMN, as described in clause 6.3.6 of TS 23.501. When the UE decides to attach to 5GC network, the UE operating in SNPN access mode for NWu interface selects an N3IWF in an SNPN, as described in clause 6.3.6.2a of TS 23.501.

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. After step 2, all subsequent IKE messages are encrypted and integrity protected by using the IKE SA established in this step.

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, indicating that MOBIKE is supported. In addition, as specified in TS 33.501, 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. In the case of WLAN access, if the UE has an MPS subscription, the UE shall include a Notify payload in the IKE_AUTH request indicating its MPS subscription.

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.

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), the Requested NSSAI and the Establishment cause. The Establishment cause provides the reason for requesting a signalling connection with 5GC and the N3IWF may use the Establishment cause to determine the DSCP value on N2. 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. 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). If at step 1 the UE selects the N3IWF based on Tracking/Location Area of same PLMN as described in clause 6.3.6 of TS 23.501, the UE may include this TA in the last visited TAI in registration request in order to help the AMF to determine the target N3IWF as described in step 17. If the UE in SNPN access mode for NWu interface performs the Registration procedure for UE onboarding, the UE shall include an indication in the AN parameters that the connection request is for onboarding. The Registration Type "SNPN Onboarding" indicates that the UE wants to perform SNPN Onboarding Registration.

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

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. The AMF may use the Establishment cause to determine the Message Priority header and then the DSCP value for subsequent signalling according to TS 29.500.

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 based on SUPI or SUCI. The AUSF executes the authentication of the UE as specified in TS 33.501. The AUSF selects a UDM as described in clause 6.3.8 of TS 23.501 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.

If the UE in SNPN access mode for NWu interface performs the Registration procedure for UE onboarding, the interaction between AMF and AUSF (step 8a, 8b, 8g and 8h in Figure 4.12.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.

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.

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

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.

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

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

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

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:

1. an "inner" IP address; and
2. a NAS_IP_ADDRESS and a TCP port number.

The N3IWF may apply a DSCP value to this signalling IPsec SA, in which case all IP packets exchanged between the UE and N3IWF via the "signalling IPsec SA" shall be marked with this DSCP value. 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. 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.

The AMF determines the allowed 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 allowed subset and based on operator's policy configured in the AMF, the AMF determines whether a different N3IWF should be used. If the UE supports slice-based N3IWF selection and the AMF determines to use a different N3IWF, then the AMF proceeds with steps 15-19. Otherwise, i.e. if the AMF determines to use the selected N3IWF that supports part of the allowed subset, the AMF proceeds with steps 13 and 14. In this case, steps 15-19 are skipped.

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.

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

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 and the AMF is able to select a UE PCF that supports UE policies for slice specific N3IWF selection, the AMF may trigger UE policy association establishment if a suitable UE policy association does not exist yet. Then the AMF triggers the UE PCF to update the UE policies for slice specific N3IWF selection by either indicating the request in Npcf_UEPolicyControl_Create or, if a UE policy already exists, by issuing a Npcf_UEPolicyControl_Update. The AMF requests the PCF to receive a notification when the PCF has completed the update of these UE policies.

The PCF updates the UE policies for slice specific N3IWF selection per the procedure defined in Figure 4.2.4.3-1. When the update of these UE policies is completed, the PCF notifies the AMF by invoking Npcf_UEPolicyControl_UpdateNotify.

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.

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.

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

The N3IWF detects that the UE is not reachable.

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.

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.

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.

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.

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.

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.