Dealing with failures that do not allow non-3GPP access to 5GCN

Abstract

To establish a secure association with user equipment (UE) in an access network, using an interworking function in a core network system such as a 5G core network.SOLUTION: In a core network system, an interworking function attempts to establish a secure association with user equipment (UE) in an untrusted access network. When the secure association is not accepted by the 5G core network, the UE receives from the core network a response indicating that Non-3GPP access to the 5G core network is not allowed. Upon receiving the response, the UE ends a session by sending a 5G-Stop message formatted in an Extensible Authentication Protocol (EAP) response. The EAP-Response / 5G-Stop message includes a message-id field with a 5G Stop value.SELECTED DRAWING: Figure 15

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority under 35 U.S.C. §119 to U.S. Provisional Application No. 62 / 692,722, filed June 30, 2018, entitled “Method and Apparatus For Handling Authentication Failure During Security Association Establishment,” which is expressly incorporated herein by reference.

[0002] The present application relates generally to access networks, and more particularly to session establishment by user equipment in access networks when security association establishment is not authorized.

[0003] 2. Description of Related Art The statements in this section provide a description of the related art and are not admissions of prior art. User equipment (UE), such as smartphones, smart tablets, laptops, computers, and smart watches, often include both wireless local area network (WLAN) connectivity (e.g., IEEE 802.11x-compliant WLAN connectivity) and radio access network connectivity (e.g., technologies that fully or partially comply with the 3rd Generation Partnership Project (3GPP) set of standards, including EVDO, UMTS, HSPA, and LTE). Thus, the UE can connect to a 3GPP Evolved Packet Core (EPC) network using two types of access technologies, consisting of 3GPP access networks and non-3GPP access networks.

[0004] In general, a 3GPP access network conforms, in whole or in part, to technologies specified by the 3GPP set of standards, including, for example, GPRS, UMTS, EDGE, HSPA, LTE, and LTE Advanced. A non-3GPP access network conforms, in whole or in part, to technologies not specified by the 3GPP set of standards, including technologies such as cdma2000, WLAN (such as IEEE 802.11x-compliant WLAN), or fixed networks.

[0005] The 3GPP set of standards specifies "non-3GPP" access technologies with different security mechanisms: untrusted and trusted access networks. Untrusted access networks include access networks that may pose increased security risks (e.g. public WLAN or femtocell access networks). Trusted access networks include access networks that the network operator recognizes as having a certain degree of trustworthiness from a security perspective and can interface directly with the EPC network.

[0006] In the new set of 5G standards, non-3GPP access networks (N3ANs) are treated as 5G access networks and as part of the 5G system (5GS). For untrusted non-3GPP access, a non-3GPP interworking function (N3IWF) provides signaling interface termination for the control plane and user plane, respectively, similar to an NG-RAN node. Thus, a 5G-capable UE can access a 5G core network (5GCN) by connecting to the non-3GPP access network as a 5G access network via the N3IWF. The N3IWF relays uplink and downlink control plane signaling between the UE and the 5GCN. Additionally, the N3IWF provides user plane connectivity between the UE and the 5GCN for sessions over the non-3GPP access network.

[0007] Currently, signaling procedures between the UE and the N3IWF specify when the establishment of a particular security authentication is approved by the network. However, there is no method available to deal with when the establishment of a security association is not approved by the network. Similarly, for user plane connections, a method needs to be specified to deal with when the establishment of a user plane security association is not approved by the network.

[0008] Thus, there is a need to provide a system and method that assists in handling failures during security association establishment for access to 5GCN via non-3GPP access networks. Other needs and advantages are also provided by the embodiments described herein. Summary of the Invention

[0009] The following presents a summary of the disclosed subject matter in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an exhaustive overview of the disclosed subject matter. It is not intended to identify key or critical elements of the disclosed subject matter or to delineate the scope of the disclosed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

[0010] In one aspect, an interworking function node for managing a network connection to a core network via an untrusted access network includes a first network interface configured to communicate with a user equipment (UE) via the untrusted access network and a second network interface configured to communicate with one or more nodes in the core network. The interworking function node comprises a processing device configured to process a request for connection establishment to a core network from a UE in the untrusted access network, generate a request to the core network, determine that the connection establishment is not authorized by the core network, and generate a response message to the UE, where the response message includes an error indicating that the connection establishment via the untrusted access network is not permitted by the core network.

[0011] In another aspect, an Access and Mobility Management Function (AMF) for handling a network attachment request from an Interworking Function node includes a network interface configured to communicate with an Interworking Function node and an Authentication Function in a core network. The AMF also includes a processing device configured to process a request for authentication and secure connection establishment of a UE via an untrusted access network, generate a request for an authentication and subscription check to an Authentication Server Function (AUSF), determine that a response to the authentication and subscription check indicates authentication failure, and generate an authentication and secure connection establishment response message by including a cause value in the response message indicating that access to the core network via the untrusted access network is not allowed.

[0012] In another aspect, a user equipment (UE) includes a network interface configured to communicate with an interworking function node over an untrusted access network, the UE including a processing device configured to generate a registration request for secure session establishment to a core network, process a response message from the interworking function node, and determine from the response message that connection establishment over the untrusted access network is not permitted by the core network.

[0013] In one or more of the above aspects, the processing device in the interworking function node is configured to receive a request for authentication and secure connection establishment from the UE via an untrusted access network, generate an authentication and subscription check request, send the authentication and subscription check request to an Access and Mobility Management Function (AMF) via a second interface, receive an authentication and subscription check response from the AMF, and generate an Internet Key Exchange (IKE) response message to the UE having a NAS payload including an error indicating that connection establishment via the untrusted access network is not allowed by the core network.

[0014] In one or more of the above aspects, the processing device in the interworking function node is configured to receive a response from the access and mobility management function encapsulating a registration reject message including a 5GMM cause value indicating that non-3GPP access to the 5GCN is not allowed, and generate an Internet Key Exchange (IKE) response message having a payload including a message type indicating that the connection establishment is not authorized by the core network.

[0015] In one or more of the above aspects, a processing device within the interworking function node is configured to generate an Internet Key Exchange (IKE) response message having a notification payload including a private notification message type indicating a failure reason.

[0016] In one or more of the above aspects, the processing device in the interworking function node is configured to generate an IKE response message by generating an IKE response message having a notification payload including a private notification message type indicating that untrusted non-3GPP access to the 5GCN is not allowed.

[0017] In one or more of the above aspects, the processing device in the interworking function node is configured to send a response message to the UE, the response message indicating that the connection establishment is not approved by the core network, receive a stop message from the UE, and generate a failure message to the UE.

[0018] In one or more of the above aspects, the processing device within the interworking function node is configured to process a stop message from the UE, the stop message including a 5G-Stop message format having a message identifier field, the message identifier field including a 5G-Stop identifier.

[0019] In one or more of the above aspects, the request for connection establishment from the UE in the untrusted access network includes an IKE request message to initiate an IPsec security association (SA) with the core network.

[0020] In one or more of the above aspects, the core network is a 5GCN and the untrusted access network is a non-3GPP access network.

[0021] In one or more of the above aspects, the AMF processing device is configured to encapsulate a registration rejection message including a cause value in a response message, the cause value including a 5GMM cause value indicating that non-3GPP access to the 5GCN is not allowed.

[0022] In one or more of the above aspects, the processing device of the AMF is configured to generate an Extensible Authentication Protocol (EAP) failure indication in the response message.

[0023] In one or more of the above aspects, the processing device of the user equipment is configured to generate a stop message indicating an end of a registration request for secure session establishment to the 5GCN and send the stop message to the interworking function node via the non-3GPP access network.

[0024] In one or more of the above aspects, the processing device of the user equipment is configured to generate the stop message as an EAP-Response formatted message including a message identifier field set to 5G-Stop.

[0025] In one or more of the above aspects, the processing device of the user equipment is configured to process an EAP failure message from the interworking function node and to perform a security association deletion procedure.

[0026] In one or more of the above aspects, the processing device of the user equipment is configured to retry registration with the 5GCN by generating a second registration request for secure session establishment to the 5GCN, and determine from a second response message from the interworking function node that the connection establishment via the untrusted access network is successful.

[0027] In one or more of the above aspects, the processing device of the user equipment is configured to generate a second registration request for secure session establishment to the 5GCN with the updated parameters.

[0028] Additional aspects are set forth in part in the following detailed description, figures, and any claims, and in part can be derived from the detailed description. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only, and that the claims are not limited to the disclosed embodiments.

[0029] Some embodiments of apparatus and / or methods according to embodiments of the present disclosure will now be described, by way of example only, and with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0030] [Figure 1] 1 shows a schematic block diagram of an embodiment of a type of access network. [Diagram 2] 1 shows a schematic block diagram of an embodiment of a 5G system architecture for non-3GPP access. [Diagram 3] 1 illustrates a logic flow diagram illustrating an embodiment of a method for registering a UE in a 5GCN via an untrusted non-3GPP access network. [Figure 4] 1 illustrates a logic flow diagram of an embodiment of a method for addressing an embodiment in which establishment of an IKE SA and a signaling IPsec SA is not authorized. [Diagram 5] 1 illustrates a logic flow diagram of an embodiment of a method for EAP-5G session procedures following authentication failure due to a recoverable error. [Figure 6] 1 illustrates a logic flow diagram illustrating an embodiment of an EAP-5G session procedure for registration rejected due to an unrecoverable error failure. [Figure 7] 1 shows a schematic block diagram of an embodiment of an EAP-Response / 5G-Stop message. [Figure 8]1 illustrates a logic flow diagram of an embodiment of a method for message flow between network functions when establishment of an IKE SA and a signaling IPsec SA for UE registration over non-3GPP access is not authorized. [Figure 9] 1 illustrates a logic flow diagram of an embodiment of a method for message flow between network functions when establishment of an IKE SA and a signaling IPsec SA for UE registration over non-3GPP access is not approved due to subscription restrictions. [Figure 10] 1 illustrates a logic flow diagram of an embodiment of a method for message flow between network functions when establishment of a user plane IPsec security association is not authorized. [Figure 11] 11 illustrates a schematic block diagram of an embodiment of a 5GMM cause information element 1100. [Figure 12] 1 shows a schematic block diagram of an embodiment of values ​​of a 5GMM cause information element. [Figure 13] 1 illustrates a logic flow diagram of an embodiment of a method of the N3IWF. [Figure 14] 1 illustrates a logic flow diagram of an embodiment of a method for registration request to a core network via an untrusted access network with authentication failure due to a recoverable error. [Figure 15] 1 illustrates a logic flow diagram of an embodiment of a method for registration request to a core network via an untrusted access network with authentication failure due to an unrecoverable error. [Figure 16] 1 illustrates a schematic block diagram of an exemplary user equipment embodiment. [Figure 17] 1 shows a schematic block diagram of an embodiment of an AMF node. [Figure 18] 1 shows a schematic block diagram of an embodiment of an N3IWF. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] The description and drawings merely illustrate the principles of the various embodiments. It will therefore be understood that those skilled in the art will be able to devise various configurations that embody the principles described in the specification and claims, but which are not explicitly described or shown herein, and are within the spirit and scope of the present disclosure. Furthermore, all examples described herein are expressly intended to be primarily for educational purposes only to assist the reader in understanding the principles of the present embodiments and the concepts that the inventors have contributed to further developing the present technology, and should not be construed as being limited to such specifically described examples and conditions. Furthermore, all descriptions herein that describe principles, aspects, and embodiments, as well as specific examples thereof, are intended to encompass their equivalents.

[0032] Some of the abbreviations mentioned herein are expanded below for convenience. 5GC 5G Core 5GCN 5G Core Network 5GS 5G System 5G-AN 5G Access Network 5GMM 5GS Mobility Management 5G-GUTI 5G Global Unique Temporary Identifier 5G-S-TMSI 5G S-Temporary Mobile Subscription Identifier 5QI 5G QoS Identifier AMF Access and Mobility Management Functions AUSF authentication server function EAP Extensible Authentication Protocol HPLMN Public Land Mobile Home Network IKEv2 Internet Key Exchange v2 IMSI International Mobile Subscriber Identity IMEI International Mobile Equipment Identity IPsec Internet Protocol Security MCM Multi-Connection Mode N3IWF Non-3GPP Interworking Function NAS non-access layer PDN Packet Data Network PLMN Public Land Mobile Network QoS Quality of Service SA Security Association SCM Single Connection Mode UDM Unified Data Management UE User Equipment UICC Universal Integrated Circuit Card USIM UMTS Subscriber Identity Module

[0033] One or more embodiments are described herein that provide systems and methods for providing network services to unauthenticated user equipment. For example, various methods are described for establishing a session for an unauthenticated UE in a non-3GPP access network.

[0034] FIG. 1 shows a schematic block diagram of an embodiment of a type of access network for a 5G Core Network (5GCN) 100 that is fully or partially compliant with a set of 3rd Generation Partnership Project (3GPP) standards for 5G systems, such as Technical Specification (TS) 23.501 “System Architecture for the 5G System”, Technical Specification (TS) 23.502 defining procedures for the 5G system, and Technical Specification (TS) 23.503 defining a policy and charging control framework for the 5G system.

[0035] The 5GCN 100 is communicatively coupled to one or more access networks 102. In an embodiment, the access networks 102 may include one or more 3GPP access networks 104 or one or more non-3GPP access networks 106. The 3GPP access networks 104 may conform, in whole or in part, to technologies specified by the 3GPP set of standards, including, for example, GPRS, UMTS, EDGE, HSPA, LTE, and LTE Advanced. The non-3GPP access networks 106 may conform, in whole or in part, to technologies not specified by the 3GPP set of standards. The non-3GPP access networks 106 may be so specified in the 3GPP set of standards. The non-3GPP access networks 106 may include one or more trusted non-3GPP access networks 108 or one or more untrusted non-3GPP access networks 110.

[0036] The trusted non-3GPP access network 108 is an operator-built or operator-supported wireless local area network (WLAN) with encryption and secure authentication methods, such as an IEEE 802.11x-compliant WLAN network. In one embodiment, the trusted non-3GPP access network 108 supports the following exemplary features: 802.1x-based authentication that also requires radio access network (RAN) encryption, 3GPP-based network access using EAP methods for authentication, and IPv4 and / or IPv6 protocols. However, the operator may determine that other types of non-3GPP access networks with different security types are recognized as trusted. The untrusted non-3GPP access network 110 includes non-3GPP access networks that are unknown to the operator or that do not include a supported authentication standard. For example, the untrusted non-3GPP access network may include a home or public WLAN, such as a publicly available IEEE 802.11x-compliant WLAN network, a home WLAN, or one created and managed by another non-operator.

[0037] 2 shows a schematic block diagram of an embodiment of a 5G system architecture for non-3GPP access, which is described in further detail in technical specification 3GPP TS 23.501, Release 15 (December 2017), entitled "System Architecture for the 5G System," which is incorporated herein by reference.

[0038] The non-3GPP access network is connected to the 5GCN 100 via a non-3GPP interworking function (N3IWF). The N3IWF 204 interfaces with the control plane (CP) and user plane (UP) functions of the 5GCN 100 via the N2 and N3 interfaces, respectively. The UE 200 establishes an IP Security (IPSec) tunnel with the N3IWF 204 to attach to the 5GCN 100 via the untrusted non-3GPP access network 110. The UE 200 is authenticated by the 5GCN 100 and attached to the 5GCN 100 through the IPSec tunnel establishment procedure. Further details regarding the attachment of the UE 200 to the 5GCN 100 via the untrusted non-3GPP access 110 are described in 3GPP TS 23.502, Release 15 (December 2017), entitled "Procedures for the 5G System," which is incorporated herein by reference.

[0039] The 5GCN 100 includes a home public land mobile network or equivalent home PLMN (HPLMN) that includes an access and mobility management function (AMF) 202. The AMF 202 provides termination of the control plane interface (N2) and termination of the NAS (N1) protocol set, as well as NAS encryption and integrity protection. The AMF 202 also provides registration and connection management. The AMF 202 may include various functionalities to support the non-3GPP access network 110. For example, the AMF 202 may provide support for the N2 interface control protocol with the N3IWF 204 and support for NAS signaling with the UE 200 via the N3IWF 204. Additionally, the AMF 202 may provide support for authentication of the UE 200 connected via the N3IWF 204, and management of mobility, authentication, and separate security context state(s) of the UE 200 connected via non-3GPP access or simultaneously connected via 3GPP access and non-3GPP access. Non-Access Stratum (NAS) is a set of protocols in the 5G standard. 5G NAS (Non-Access Stratum) includes procedures related to 5GMM (5GS Mobility Management) and 5GSM (5G Session Management) in 5GS (5G System). NAS is used to carry control signaling between User Equipment (UE) and 5GCN functions. A version of the 5G NAS protocol is defined in 3GPP TS 24.501: “Access-Stratum (NAS) protocol for 5G System (5GS)” Version 1.1 (May 9, 2018), which is incorporated herein by reference.

[0040] The Session Management Function (SMF) 206 includes session management functionality, e.g., session establishment, modification, and teardown, including tunnel maintenance between the UPF 208 and the AN nodes. The SMF 206 also provides UE IP address allocation and management (including optional authorization), and DHCPv4 (server and client) and DHCPv6 (server and client) functionality.

[0041] The User Plane Function (UPF) 208 provides the interconnection point for external PDU sessions to the data network and packet routing and forwarding. The UPF 208 also supports the user plane part of policy rule enforcement, e.g., gating, redirection, traffic steering, etc.

[0042] The Policy Control Function (PCF) 214 supports a unified policy framework for governing network behavior. The Unified Data Management (UDM) 212 includes support for generation of 3GPP AKA authentication credentials, access authorization based on subscription data (e.g., roaming restrictions), and serving NF registration management for the UE (e.g., storing the serving AMF for the UE, storing the serving SMF for the UE's PDU sessions). The UDM 212 also provides SMS and subscription management. To provide this functionality, the UDM 212 uses subscription data (including authentication data) that may be stored in the UDR. Another module provides the Authentication Server Function (AUSF) 210.

[0043] The functionality of the N3IWF 204 in case of untrusted non-3GPP access 110 includes support for IPsec tunnel establishment with the UE 200. The N3IWF 204 terminates the IKEv2 / IPsec protocol with the UE 200 over the NWu interface, and the N3IWF 204 relays the necessary information to authenticate the UE 200 and authorize its access to the 5GCN 100 over the N2 interface. The N3IWF 204 provides termination of the N2 and N3 interfaces to the 5GCN 100 for the control plane and the user plane, respectively. The N3IWF 204 relays uplink and downlink control plane NAS (N1) signaling between the UE 200 and the AMF 202. The N3IWF 204 provides handling of N2 signaling from the SMF 206 (relayed by the AMF 202) related to PDU sessions and QoS. The N3IWF 204 further provides for the establishment of IPsec security associations (IPsec SAs) to support PDU session traffic. The N3IWF 204 also provides for relaying uplink and downlink user plane packets between the UE 200 and the UPF 208.

[0044] FIG. 3 illustrates a logic flow diagram illustrating an embodiment of a method for registering a UE 200 with a 5GCN 100 via an untrusted non-3GPP access 110. The method includes a vendor-specific Extensible Authentication Protocol (EAP) called "EAP-5G". EAP is defined in IETF RFC 3748: "Extensible Authentication Protocol (EAP)" dated June 2004. EAP-5G is a vendor-specific EAP for 5GS (EAP-5G) that is used to encapsulate NAS messages between the UE 200 and the N3IWF 204. EAP-5G packets utilize the "Extended" EAP type and an existing 3GPP vendor ID registered with IANA under the SMI Private Enterprise Code Registry (i.e., 10415). In an embodiment, EAP-5G is utilized only to encapsulate NAS messages (not for authentication).

[0045] If the UE 200 needs to be authenticated, an EAP-AKA′ mutual authentication is performed between the UE 200 and the AUSF 210 as described herein below. During registration and subsequent registration procedures via the untrusted non-3GPP access network 110, NAS messages are exchanged between the UE 200 and the AMF 202.

[0046] In step 1, the UE 200 connects to the untrusted non-3GPP access network 110 with a procedure outside the scope of 3GPP (such as the procedure specified in the IEEE 802.11 WLAN protocol) and is assigned an IP address. Any non-3GPP authentication method may be used, for example no authentication (for toll-free WLAN), Extensible Authentication Protocol (EAP) with pre-shared key, username / password, etc. When the UE 200 decides to attach to the 5GCN 100, it selects an N3IWF 204 in the 5G PLMN.

[0047] In step 2, the UE 200 proceeds to establish an IPsec Security Association (SA) with the selected N3IWF 204 by initiating an Internet Key Exchange (IKE) protocol initial exchange, e.g., as described in IETF RFC 7296, “Internet Key Exchange Protocol Version 2 (IKEv2),” October 2014. After step 2, subsequent IKE messages are encrypted and integrity protected by using the IKE SA established in this step.

[0048] In step 3, UE 200 shall initiate the IKE_AUTH exchange by sending an IKE_AUTH request message. No AUTH payload is included in the IKE_AUTH request message, indicating that the IKE_AUTH exchange uses an Extensible Authentication Protocol (EAP) signaling protocol, e.g., EAP-5G signaling (such as EAP-AKA', as described in IETF RFC 5448, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')," March 5, 2018, and incorporated herein by reference).

[0049] In step 4, the N3IWF 204 responds with an IKE_AUTH Response message that includes an EAP-Request / 5G-Start packet that informs the UE 200 to start an EAP-5G session, i.e., to start sending NAS messages encapsulated in EAP-5G packets.

[0050] In step 5, the UE 200 generates and sends a registration request to the 5GCN 100, e.g., an IKE_AUTH request including an EAP-Response / 5G-NAS packet including access network parameters (AN-Params) and a NAS registration request message. Thus, the UE confirms the start of an EAP-5G session, e.g., by sending an EAP-Response / 5G-NAS packet including a) a NAS message, e.g., a NAS-PDU field including a registration request message, and b) an AN parameters field (see 3GPP TS 23.502) including access network parameters such as SUPI or 5G-GUTI, selected network, and S-NSSAI. The AN parameters (AN-Params) are used by the N3IWF 204 to select the AMF 202 in the 5GCN 100.

[0051] In step 6a, the N3IWF 204 selects an AMF 202 in the 5GCN 100 based on the received AN parameters and local policies. The N3IWF 204 then forwards the registration request received from the UE 200 to the selected AMF 202 in step 6b. Upon receiving the NAS message from the AMF 202, the N3IWF 204 includes the NAS message in an EAP-Request / 5G-NAS message to the UE 200. The EAP-Request / 5G-NAS message includes a NAS-PDU field that contains the NAS message. Further NAS messages between the UE 200 and the AMF 202 via the N3IWF 204 are inserted in the NAS-PDU fields of the EAP-Response / 5G-NAS message (in the direction from the UE to the N3IWF) and the EAP-Request / 5G-NAS message (in the direction from the N3IWF to the UE).

[0052] In steps 7a and 7b, the selected AMF 202 may decide to request a persistent identity (SUPI) for the UE by sending a NAS Identity Request message to the UE 200 via the N3IWF 204. This NAS message, and all subsequent NAS messages, are encapsulated in EAP / 5G-NAS packets and sent by the N3IWF 204 to the UE 200.

[0053] In step 8, the AMF 202 may decide to authenticate the UE 200. In this case, the AMF 202 shall select the AUSF 210 by using the SUPI or the encrypted SUPI of the UE 200, and in step 8a, send a key request to the selected AUSF 210. The AUSF 210 may initiate EAP-AKA′ authentication in step 8b as specified in TS 3GPP TS 33.501: “Security Architecture and Procedures for 5G Systems”, Release 15 (March 26, 2018), which is incorporated herein by reference. The EAP-AKA′ challenge packet is encapsulated in a NAS authentication message to the N3IWF in step 8c, and this NAS authentication message is encapsulated in an EAP / 5G-NAS packet in step 8d. The UE 200 generates an authentication response to the EAP-AKA challenge in step 8e, and the authentication response is forwarded to the AMF by the N3IWF 204 in step 8f. The AUSF 210 then receives the authentication response from the AMF in step 8g.

[0054] After the authentication of the UE 200 is successful, in step 8h, the AUSF 210 sends to the AMF 202 an anchor key (SEAF key) that is used by the AMF 202 to derive a security key for the NAS and a security key (N3IWF key) for the N3IWF 204. The UE 200 also derives the anchor key (SEAF key) and derives a security key for the NAS and a security key (N3IWF key) for the N3IWF 204 from the anchor key. The N3IWF key is used by the UE 200 and the N3IWF 204 to establish an IPsec security association (in step 11). The AUSF 210 includes the SUPI (unencrypted) if the AMF 202 provided the encrypted SUPI to the AUSF 210 in step 8a.

[0055] In steps 9a and 9b, the AMF 202 sends a Security Mode Command (SMC) request to the UE 200 to activate NAS security. This request (in an N2 message) is sent to the N3IWF 204 first with the N3IWF key. If the EAP-AKA′ authentication is successfully performed in step 8, the AMF 202 encapsulates the EAP-Success received from the AUSF 210 in an SMC request message in step 9a.

[0056] In step 10a, the UE 200 completes the EAP-AKA′ authentication (if initiated in step 8) and creates a NAS security context and an N3IWF key. After the N3IWF key is created in the UE 200, the UE 200 requests the completion of the EAP-5G session by sending an EAP-Response / 5G-Complete packet, which triggers the N3IWF 204 to send an EAP-Success to the UE 200 in step 10b, assuming that the N3IWF 204 has also received the N3IWF key from the AMF 202. The EAP-5G session is now completed and no further EAP-5G packets can be exchanged. If the N3IWF 204 has not received the N3IWF key from the AMF 202, the N3IWF 204 responds with an EAP-Failure.

[0057] In step 11, an IPsec SA is established between the UE 200 and the N3IWF 204 by using the common N3IWF key created in the UE 200 and received by the N3IWF 204 in step 9a. This IPsec SA is called the "signaling IPsec SA". After the signaling IPsec SA is established, all NAS messages between the UE 200 and the N3IWF 204 are exchanged via this IPsec SA. The signaling IPsec SA shall be configured to operate in transport mode. The SPI value is used to determine whether an IPsec packet carries a NAS message.

[0058] In step 12, UE200 sends an SMC Complete message over the established signaling IPsec SA, and all subsequent NAS messages are exchanged between UE200 and AMF202 over this IPsec SA.

[0059] As described above, the UE 200 and the N3IWF 204 define a method when the establishment of the IKE SA and the signaling IPsec SA via the non-3GPP access network 110 is approved by the 5GCN 100. However, there is no system or method available to deal with when the establishment of the IKE SA and the signaling IPsec SA is not approved by the 5GCN 100. Furthermore, for the user plane, a system and method needs to be specified to deal with when the establishment of the user plane IPsec SA is not approved by the 5GCN 100. In general, a method and system needs to be established to deal with the denial of non-3GPP access to the 5GCN 100.

[0060] Embodiments - Process and protocol enhancements to handle when UE registration via a non-3GPP access network is not acknowledged by the 5G core network 4 illustrates a logic flow diagram of an embodiment of a method 400 for handling when the establishment of an IKE SA and a signaling IPsec SA is not authorized. In step 402, the UE 200 proceeds with a request for the establishment of an IPsec security association (SA) with the selected N3IWF 204. The UE 200 initiates the establishment of the IPsec SA using the Internet Key Exchange (IKE) protocol described in IETF RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)," (October 2014). The UE 200 sends an IKE_AUTH request message in step 404. In step 406, the N3IWF 204 responds with an IKE_AUTH response message that includes an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet informs the UE 200 to start an EAP-5G session, i.e., to start sending NAS messages encapsulated in EAP-5G packets.

[0061] In step 408, the UE 200 generates a registration request to the 5GCN 100, for example, an IKE_AUTH request including an EAP-Response / 5G-NAS packet including access network parameters (AN-Params) and a NAS Registration Request message. The AN-Params includes information used by the N3IWF 204 to select the AMF 202 in the 5GCN 100 (e.g., SUPI or 5G-GUTI, selected network, and NSSAI, etc.).

[0062] In some cases, UE registration via non-3GPP access is rejected due to authentication failure, e.g., EAP-AKA′ authentication was not successful. In that case, the establishment of the IKE SA and the signaling IPsec SA is not approved by the 5GCN 100. In an embodiment, the AMF 202 generates a REGISTRATION REJECT message, and the N3IWF 204 sends an EAP-Response / 5G-NAS message including a NAS-PDU field containing the REGISTRATION REJECT message to the UE in step 410.

[0063] Upon receiving the Registration Reject message, the UE 200 terminates the Registration Request by generating and sending an EAP-Response / 5G-Stop message (encapsulated in an IKE_Auth Request) in step 412. The UE 200 receives an IKE_AUTH Response with an EAP Failure message from the N3IWF 204 in step 414. Upon receiving an EAP-Failure message from the N3IWF 204, the UE 200 performs an IKEv2 SA deletion procedure. The UE 200 will not re-initiate the establishment of the IKE SA and the signaling IPsec SA from the same PLMN to the N3IWF 204 until it switches off or the UICC containing the USIM is removed.

[0064] If the registration of the UE 200 via the non-3GPP access network 110 is rejected, the AMF 202 sends a registration reject message to the N3IWF 204. In response, the N3IWF 204 sends an EAP-Response / 5G-NAS message to the UE 200, including a NAS-PDU field containing the registration reject message. The subsequent response of the UE 200 may vary depending on the reason for the registration rejection. In case of a recoverable error, such as a syntax error or a specific temporary rejection reason, the UE 200 may attempt to re-initiate the registration with valid parameters. For other rejection reasons, the UE 200 stops the EAP-5G procedure and restores the IKE SA and EAP stack related resources. A 5G-Stop indication is required to stop the EAP-5G procedure. Both of these procedures are described in further detail herein.

[0065] Embodiment - Completion of EAP-5G Procedures After Registration Failure Due to a Recoverable Error 5 illustrates a logic flow diagram of an embodiment of a method 500 of EAP-5G session procedures after authentication failure due to a recoverable error. In this embodiment, a UE 200 registration request to the 5GCN 100 via an untrusted non-3GPP access network 110 is rejected.

[0066] The N3IWF 204 sends an EAP-Request / 5G-Start message to the UE 200 in step 502. The 5G-Start message requests the UE 200 to start an EAP-5G session, i.e., to start sending NAS messages encapsulated in EAP-5G packets. The UE 200 generates a registration request to the 5GCN 100 in an EAP-Response / 5G-NAS message, which includes the AN parameters and a NAS-PDU field containing the registration request in step 504. In this embodiment, the UE 200 registration to the 5GCN 100 is rejected by the AMF 202. The AMF 202 sends a registration reject message to the N3IWF 204. In response, the N3IWF 204 sends an EAP-Request / 5G-NAS message to the UE 200 in step 506, which includes a NAS-PDU field containing a NAS registration reject message.

[0067] Although retrying registration is not mandatory, UE200 can try to initiate registration to 5GCN again. In case of a recoverable error, such as a syntax error or a specific temporary rejection reason, UE200 may modify the registration request message with updated parameters and retry registration. Alternatively, UE200 may retry registration at a later time without updating the parameters.

[0068] UE 200 sends a second registration request formatted as an EAP-Response / 5G-NAS message including updated AN parameters, if necessary, and a NAS-PDU field including the registration request in step 508. UE 200 and N3IWF 204 then perform IKE SA and signaling IPsec SA establishment to create a NAS security context and N3IWF keys (not shown).

[0069] After the N3IWF keys are created in the UE 200, the N3IWF 204 sends an EAP-Request / 5G NAS message including a NAS PDU with a SECURITY MODE COMMAND message indicating EAP-success at 510. The UE 200 requests completion of the EAP-5G session by generating and sending an EAP-Response / 5G-NAS message with a NAS PDU including a SECURITY MODE COMPLETE message at 512, thereby triggering the N3IWF 204 to send an EAP-Success to the UE 200, assuming that the N3IWF 204 has also received the N3IWF keys from the AMF 202. The EAP-5G session is now completed and no further EAP-5G packets can be exchanged.

[0070] In this manner, the UE 200 can retry a registration request to the 5GCN 100 via the non-3GPP access network 110 when rejected. The rejection may be due to a recoverable error, such as a syntax error or an error in the AN parameters. When such a recoverable error is corrected, the second registration attempt may be successful. In another embodiment, the rejection is due to a temporary rejection reason. The UE 200 can then retry the registration with the same parameters and complete the EAP-5G session.

[0071] Embodiment - Completion of EAP-5G Procedures After Registration Failure Due to an Unrecoverable Error 6 illustrates a logic flow diagram illustrating an embodiment of an EAP-5G session procedure for registration rejection due to an unrecoverable error or permanent failure, in which the UE 200 registration request to the 5GCN 100 via the untrusted non-3GPP access network 110 is rejected again.

[0072] The N3IWF 204 sends an EAP-Request / 5G-Start message to the UE 200 in step 602 to initiate registration to the 5GCN 100 via the non-3GPP access network 110. The UE 200 responds with a registration request, e.g., an EAP-Response / 5G-NAS message including the AN parameters and a NAS-PDU field including the registration request in step 604.

[0073] If the authentication fails due to an unrecoverable error, such as EAP-AKA′ authentication not being successful, the N3IWF 204 receives a registration reject message from the AMF 202 (not shown). In response to receiving the registration reject message from the AMF 202, the N3IWF 204 generates 606 an EAP-Request / 5G-NAS message to the UE 200. The EAP-Request / 5G-NAS message includes a NAS-PDU field that includes a NAS registration reject message with an EAP-Failure field.

[0074] The UE 200 terminates the registration procedure by generating and sending an EAP-Response / 5G-Stop message in step 608. The 5G-stop message indicates that the EAP session for registration to the 5GCN 100 via the non-3GPP access network 110 has ended. After receiving the EAP-Response / 5G-Stop message from the UE 200, the N3IWF 204 terminates the EAP-5G procedure in step 610 by sending an EAP-Failure message to the UE 200. In this embodiment, the UE 200 stops the EAP-5G session without retrying on registration.

[0075] 7 illustrates a schematic block diagram of an embodiment of an EAP-Response / 5G-Stop message 700. The EAP-Response / 5G-Stop message 700 includes various EAP packets with exemplary fields including a code 702, an identifier 704, a length 706, a type 708, a vendor ID 710, a vendor type 712, a message identifier (message ID) 714, a spare 716, and an extension 718. The message ID field 714 of the EAP packets includes an identifier to indicate the 5G-Stop message. Example values ​​for the fields in the EAP packets are shown in Table 1 below. TIFF0007612286000001.tif151154Table 1 Example of EAP-Response / 5G-Stop message fields

[0076] The message identifier (Message ID) field 714 in the EAP message contains a 5G Stop identifier or value. The fields and values ​​of the EAP-Response / 5G-Stop message 700 are only examples and other fields / values ​​or protocol packets may be implemented that indicate a similar meaning of stopping registration.

[0077] EMBODIMENTS - METHOD AND PROTOCOL ENHANCEMENTS FOR HANDLING WHEN IPSEC SA BUSINESS IS NOT AUTHORIZED DUE TO AUTHENTICATION FAILURE 8 illustrates a logic flow diagram of an embodiment of a method 800 for message flow between network node functions when an IKE SA and a signaling IPsec SA for a UE 200 registration via a non-3GPP access network 110 are not authorized for establishment due to an authentication failure. For example, an IKE SA and a signaling IPsec SA may not be authorized for establishment due to a failure of an authentication procedure such as an AKA-Challenge or AKA′-challenge. The method 800 includes a new private IKEv2 notify message type to communicate the failure to the UE 200 and a new cause value to indicate that access to the 5GCN 100 is not permitted by the non-3GPP access network 110.

[0078] The UE 200 connects to an untrusted non-3GPP access network (N3AN) 110, e.g., a public WLAN, in step 802 using the 802.1x protocol. Once the UE 200 decides to attach to the 5GCN 100, the UE 200 selects an N3IWF 204 in the 5G PLMN in step 804. The UE 200 proceeds to establish an IPsec security association (SA) with the selected N3IWF 204, e.g., by initiating an IKE initial exchange, e.g., as described in IETF RFC 7296, “Internet Key Exchange Protocol Version 2 (IKEv2)” (October 2014), in step 806. After the IKE SA is established, subsequent IKE messages are encrypted and integrity protected by using the IKE SA established in this step 806.

[0079] Next, the UE 200 initiates an IKE_AUTH exchange by sending an IKE_AUTH request message in step 808. No AUTH payload is included in the IKE_AUTH request message, indicating that the IKE_AUTH exchange must use EAP signaling (EAP-5G signaling in this case). The UE 200 will set the UE ID field of this message equal to an arbitrary random number. The N3IWF 204 responds in step 810 with an IKE_AUTH Response message that includes an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet informs the UE 200 to start an EAP-5G session, i.e., to start sending NAS messages encapsulated in EAP-5G packets.

[0080] The UE 200 may also validate the N3IWF certificate and verify that the identity of the N3IWF 204 matches the N3IWF 204 selected by the UE 200. Absence of a certificate from the N3IWF 204 or failure of identity verification may result in a failed connection. The UE 200 then sends an IKE_AUTH request including an EAP-Response / 5G-NAS packet to request registration to the 5GCN 100 in step 812. The EAP-Response / 5G-NAS message includes the AN parameters (e.g., GUAMI, selected PLMN ID, requested NSSAI) and a NAS-PDU field including the registration request.

[0081] Next, the N3IWF 204 selects the AMF 202 using the AN parameters and, in step 814, forwards the registration request received from the UE 200 to the AMF 202 in an N2 NAS transport message.

[0082] The AMF 202 may decide to authenticate the UE 200. In this case, the AMF 202 selects the AUSF 210 in step 816 and sends a key request to the AUSF 210. The AUSF 210 may then initiate an authentication procedure such as AKA-Challenge or AKA'-challenge in step 818. Between the AMF 202 and the UE 200, the authentication packet is encapsulated in a NAS authentication message, which is encapsulated in an EAP-5G / 5G-NAS packet. In steps 820 and 822, an EAP-Request / AKA'-Challenge message in an authentication request message of the NAS message is sent to the UE 200 via the N3IWF 204. This message may include an ngKSI that is used by the UE 200 and the AMF 202 to identify a partial native security context that is created if the authentication is successful. The UE 200 forwards the RAND and AUTN received in the EAP-Request / AKA'-Challenge message to the USIM.

[0083] Upon receiving RAND and AUTN, the USIM verifies the authentication vector by checking if the AUTN can be accepted. If so, the USIM calculates a response RES in step 823. The UE 200 sends an EAP-Response / AKA'-Challenge message in an Auth-Resp message of the NAS message in step 824. The EAP-Response / AKA'-Challenge message is sent to the AUSF 210 via the AMF 202 in steps 826 and 828. The AUSF 210 will then try to verify the message. If the AUSF 210 verifies the message successfully, it continues with the authentication.

[0084] In prior known systems, the AUSF 210 returns an error when it determines that non-3GPP access to the 5GCN 100 is not permitted due to authentication failure in step 830. In the new and improved system and method, the AMF 202 generates a new private IKEv2 notification message type to communicate that non-3GPP access to the 5GCN 100 is not permitted due to, for example, authentication failure.

[0085] In step 832, the AUSF 210 sends an HTTP EAP-session message including an EAP payload of EAP-Failure and an authentication result of AUTHENTICATION_FAILURE. The AMF 202 generates a new 5G Mobility Management (5GMM) cause indicating that non-3GPP access of the 5GCN 100 is not allowed. In step 834, the AMF 202 generates an N2 NAS Transport message including a registration rejection and an EAP message indicating EAP failure, and including a 5GMM cause. The 5GMM cause indicates that the error type is, for example, "non-3GPP access of the 5GCN is not allowed" in this case.

[0086] In step 836, the UE 200 receives a private notification message type (e.g., 8192 ··· Receive an IKE_AUTH Response message containing a notification payload with a 5GMM notification message type of "any private notification message type within a predefined range, such as 16383" (e.g., 5G_AUTH_AUTH_NOTIFICATION_HEADER_TYPE_NOT_ALLOWED) and an EAP message type of EAP-Failure.

[0087] Thus, the method 800 includes a new private IKEv2 notify message type and a new 5GMM cause value to notify the UE of a registration request failure that non-3GPP access to the 5GCN 100 is not allowed. Although a new private IKEv2 notify message is implemented, other types of messages, or formats, or fields, or error types may be implemented to notify the UE 200 that non-3GPP access to the 5GCN 100 is not allowed or has been denied.

[0088] Upon receiving the private notification message with a 5GMM cause of NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED, the UE 200 terminates the EAP-5G session by sending an EAP-Response / 5G-Stop message in step 838. The UE 200 receives an IKE_AUTH Response message with an EAP Failure message from the N3IWF 204 in step 840.

[0089] Upon receiving the EAP failure message from the N3IWF 204, the UE 200 performs an IKEv2 SA deletion procedure and closes the IKE SA in step 842. The UE 200 does not re-initiate the establishment of the IKE SA and IPsec SA from the same PLMN to the N3IWF 204 until it switches off or the UICC containing the USIM is removed. The UE 200 may send an IKEv2 SA deletion INFORMATIONAL message in step 844. The N3IWF 204 may then close the IKEv2 SA in step 846.

[0090] Embodiments - Method and protocol enhancements for handling when IPsec SA establishment is not authorized due to subscription restrictions 9 illustrates a logic flow diagram of an embodiment of a method 900 for message flow between network functions when establishment of an IKE SA and a signaling IPsec SA for UE 200 registration over a non-3GPP access is not authorized due to subscription restrictions. For example, subscription restrictions may cause establishment of an IKE SA and a signaling IPsec SA to be not authorized. The method 900 includes a new private IKEv2 notification message type to communicate the failure to the UE 200 and a new cause value to indicate that access to the 5GCN 100 is not permitted by the non-3GPP access network 110.

[0091] The UE 200 connects to an untrusted non-3GPP access network (N3AN) 110, e.g., a public WLAN, in step 902 using the 802.1x protocol. Once the UE 200 decides to attach to the 5G CN 100, the UE 200 selects an N3IWF 204 in the 5G PLMN in step 904. The UE 200 proceeds to establish an IPsec security association (SA) with the selected N3IWF 204, e.g., by initiating an IKE initial exchange, e.g., as described in IETF RFC 7296, “Internet Key Exchange Protocol Version 2 (IKEv2),” October 2014, in step 906. After the IKE SA is established, subsequent IKE messages are encrypted and integrity protected using the keys established in this IKE SA.

[0092] Next, the UE 200 initiates an IKE_AUTH exchange by sending an IKE_AUTH request message in step 908. No AUTH payload is included in the IKE_AUTH request message, indicating that the IKE_AUTH exchange must use EAP signaling (EAP-5G signaling in this case). The UE 200 sets the UE ID field of this message equal to an arbitrary random number. The N3IWF 204 responds in step 910 with an IKE_AUTH Response message that includes an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet informs the UE 200 to start an EAP-5G session, i.e., to start sending NAS messages encapsulated in EAP-5G packets.

[0093] The UE 200 may also validate the N3IWF certificate and verify that the identity of the N3IWF 204 matches the N3IWF 204 selected by the UE. Absence of a certificate from the N3IWF 204 or failure of identity verification may result in a failed connection. The UE 200 then sends a registration request in an IKE_AUTH request including an EAP-Response / 5G-NAS packet in step 912. The EAP-Response / 5G-NAS packet includes AN parameters such as GUAMI, selected PLMN ID, requested NSSAI, and a NAS PDU with the registration request. The N3IWF 204 then selects the AMF 202 in step 914 and forwards the registration request in the NAS PDU received from the UE 200 to the AMF 202.

[0094] The AMF 202 may decide to authenticate the UE 200. In this case, the AMF 202 selects the AUSF 210 in step 916 and sends a key request to the AUSF 210. The AUSF 210 may then initiate an authentication procedure such as AKA-Challenge or AKA′-challenge in step 918. Between the AMF 202 and the UE 200, the authentication packet is encapsulated in a NAS authentication message, which is encapsulated in an EAP-5G / 5G-NAS packet. An EAP-Request / AKA′-Challenge message in an authentication request message of the NAS message is sent by the AMF to the UE 200 in step 920 and forwarded by the N3IWF in step 922. This message may include a ngKSI that is used by the UE 200 and the AMF 202 to identify a partial native security context that is created if the authentication is successful. The UE 200 transfers the RAND and AUTN received in the EAP-Request / AKA′-Challenge message to the USIM of the UE 200.

[0095] Upon receiving the RAND and AUTN, the USIM verifies the authentication vector by checking whether the AUTN can be approved. If so, the USIM calculates an authentication response in step 923. The UE 200 sends an EAP-Response / AKA′-Challenge message in an Auth-Resp message of the NAS message in step 924. The EAP-Response / AKA′-Challenge message is sent by the N3IWF to the AMF in step 926 and then to the AUSF 210 in step 928. The AUSF 210 will then attempt to verify the message. If the AUSF 210 successfully verifies this message, it continues with the authentication. However, the AUSF 210 may reject the authentication in step 930 and not allow access to the non-3GPP 5GCN 100.

[0096] In the prior known system, when the AUSF210 determines that the authentication has failed, the AUSF210 returns an error. In the new and improved method, the AMF202 generates a new cause to communicate that non-3GPP access to the 5GCN100 is not allowed. For example, the AMF202 can generate a new private IKEv2 notification message type to communicate to the UE200 that non-3GPP access to the 5GCN100 is not allowed, for example, due to subscription or network restrictions.

[0097] In step 932, the AUSF 210 sends an HTTP EAP-session message with an EAP payload of EAP-Failure and an authentication result of AUTHENTICATION_FAILURE with a cause. The AMF 202 generates an N2 NAS transport message with a 5GMM cause with registration rejected and an EAP message of EAP failure in step 934. The 5GMM cause indicates that the error type is NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED.

[0098] The N3IWF 204 receives a response from the AMF 202 encapsulating a registration reject message with a 5GMM cause value indicating that non-3GPP access to the 5GCN is not allowed and an EAP-Failure type message. The N3IWF 204 then encapsulates a private notification message type (e.g., 8192 ··· Generate an IKE_AUTH Response message containing a Notify payload with a 5GMM notification message type (any private notification message type within a predefined range, such as 16383). The private IKEv2 Notify message contains an EAP Response / 5G-NAS PDU with a registration rejection with 5GMM cause of "NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED" and an EAP message type of EAP-Failure.

[0099] Thus, a new 5GMM cause code is implemented to inform the UE 200 that non-3GPP access to the 5GCN 100 is not allowed. This 5GMM cause is generated by the AMF 202 and is sent to the UE 200 when the UE 200 requests a service via non-3GPP access in a PLMN where the UE 200 is not allowed to access the 5GCN 100 via the non-3GPP access network 110 due to subscription or network restrictions. Thus, the UE 200 is informed that access to the 5GCN 100 via the non-3GPP access network 110 has been denied.

[0100] The UE 200 receives an IKE_AUTH Response message from the N3IWF 204, in step 936, that includes a notification payload with a private notification message type, an EAP message of EAP-Failure, and a 5GMM cause of NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED. As a result, the UE 200 receives a registration rejection notification with a reason, rather than simply receiving an error message.

[0101] UE 200 then terminates the registration request by generating an EAP-Response / 5G-Stop message to N3IWF 204 in step 938. UE 200 receives an IKE_AUTH response message with an EAP failure message from N3IWF 204 in step 940.

[0102] Upon receiving the EAP failure message from the N3IWF 204, the UE 200 performs an IKEv2 SA deletion procedure and closes the IKE SA in step 942. In this example, due to an uncorrectable error of subscription or network limitation, the UE 200 does not re-initiate the establishment of the IKE SA and IPsec SA from the same PLMN to the N3IWF 204 until it switches off or the UICC containing the USIM is removed. The UE 200 may send an IKEv2 SA deletion INFORMATIONAL message in step 944. The N3IWF 204 may then close the IKEv2 SA in step 946.

[0103] EMBODIMENTS - METHOD AND PROTOCOL ENHANCEMENTS FOR HANDLING WHEN USER PLANE IPSEC SA ESTABLISHMENT IS NOT AUTHORIZED 10 illustrates a logic flow diagram of an embodiment of a method for message flow between network node functions when establishment of a user plane IPsec security association (SA) is not authorized. The UE 200 connects to an untrusted non-3GPP access network (N3AN) 110, e.g., a public WLAN, using an 802.1x protocol in step 1002. When the UE 200 decides to attach to the 5GCN 100, the UE 200 selects an N3IWF 204 in the 5G PLMN in step 1004. The UE 200 proceeds to establish an IPsec security association (SA) with the selected N3IWF 204 by initiating an IKE initial exchange in step 1006. In this embodiment, the UE 200 successfully establishes an IKE SA and a signaling IPsec SA to the selected N3IWF 204 in 1008. For example, as shown in FIG. 3, authentication of the UE 200, such as, for example, an EAP-AKA′ procedure, is successful and EAP-5G is completed.

[0104] Next, the UE 200 sends a PDU session establishment request message to the AMF 202 at 1010 to establish a user plane IPsec SA. This PDU session establishment request message is sent via the signaling IPsec SA to the N3IWF 204, which transparently forwards this message to the AMF 202 of the 5GCN 100 at step 1012. The AMF 202 can create a session management (SM) context with the SMF 206 at step 1014. The AMF 202 sends a NAS N2 interface PDU session request message to the N3IWF 204 to establish access resources for this PDU session, for example in an N2 PDU session resource setup request at step 1016. The PDU session request may include a PDU session ID, a PDU session establishment acknowledgement, a QFI, a QoS profile, etc.

[0105] Based on its own policy and configuration and based on the QoS profile received in the N2 PDU session request, N3IWF204 determines the number of user plane IPsec SAs to establish and the QoS profile associated with each user plane IPsec SA. For example, N3IWF204 may decide to establish one user plane IPsec SA and associate all QoS profiles with this user plane IPsec SA. In this example, all QoS flows of the PDU session are forwarded through one user plane IPsec SA. In another example, N3IWF204 may decide to establish multiple user plane IPsec child SAs and associate specific QoS profiles with various user plane IPsec child SAs among the multiple user plane IPsec child SAs.

[0106] The N3IWF 204 sends an IKE Create_Child_SA request to the UE 200 in step 1018 to establish a first user plane IPsec child SA for the PDU session. The IKE Create_Child_SA request indicates the first user plane IPsec child SA with an ID of SAup1. The request may include a 3GPP-specific Notify payload that includes (a) the QFI(s) associated with the child SA, (b) an ID of the PDU session associated with this child SA, (c) optionally, a DSCP value associated with the child SA, and (d) an UP_IP_ADDRESS. The IKE Create_Child_SA request may also include other information such as the SA payload, the Traffic Selector (TS) of the N3IWF 204 and the UE 200.

[0107] If UE 200 approves the new IPsec child SA, UE 200 sends an IKE Create_Child_SA response in step 1020. UE 200 and N3IWF 204 may exchange multiple iterations of IKE Create_Child_SA requests and responses to establish multiple IPsec child SAs in step 1022. Additional IPsec child SAs are established, each associated with one or more QFI(s) and a UP_IP_ADDRESS.

[0108] If the user plane IPsec SA request in step 1024 is not accepted by the UE 200, as in step 1026, the UE 200 sends a CREATE_CHILD_SA Response message with a notification payload of type Error to the N3IWF 204 in step 1026. The notification message type may be "Error". The notification message type of "Error" indicates that the IPsec child SA is not accepted by the UE 200.

[0109] Upon receiving the CREATE_CHILD_SA response message with the notification payload of error type, the N3IWF 204 indicates the failure and the list of PDU session resources that failed to be set up to the AMF 202 via an N2 PDU session resource setup response message in step 1032 to trigger the rejection of the PDU session establishment over the non-3GPP access. Alternatively, if the N3IWF 204 previously decided to create multiple user plane IPsec SAs for the QoS flow identifier (QFI) of the PDU session and one or more user plane IPsec SAs of the PDU session are already active, the network may choose to complete the PDU session establishment by mapping the QFI(s) of the failed user plane IPsec SA to the already established user plane IPsec SA, as shown in steps 1028 and 1030.

[0110] Upon receiving an N2 PDU Session Resource Release Command containing a NAS PDU indicating a PDU Session Establishment Reject message in step 1034, the N3IWF 204 transparently forwards the PDU Session Establishment Reject to the UE 200 in step 1036. A dedicated 5G Session Management (5GSM) cause (5GSM_cause) "IPsec SA failure" is defined to indicate the reason for the PDU session rejection.

[0111] Embodiment – ​​Private IKEv2 Notify Message Type for Non-3GPP Access The notification message types for non-3GPP access are shown in Table 2 below. In this example, a private IKEv2 notification message and a private error type are described, but other message protocols, values, and error types may be used to provide a reason or error notification to the UE 200 when non-3GPP access to the 5GCN 100 is not allowed.

[0112] In this example, a private IKEv2 notification message type is defined for non-3GPP access use. Notification message types with values ​​of 8192 to 16383 (decimal) are reserved for private error use, although other values ​​and fields may be implemented. Notification message types with values ​​of 40960 to 65535 (decimal) are reserved for use in private status. This specification describes only the private IKEv2 notification message type used in this specification. The private notification message error type defined in Table 2 is an error notification indicating an error during negotiation of non-3GPP access to the 5GCN100. For example, the error type may be generated in response to negotiation of an IKEv2 SA or IPsec SA for non-3GPP access to the 5GCN100. The fields and values ​​of the private notification message type are only examples, and other fields / values ​​indicating similar meanings may be implemented. JPEG0007612286000002.jpg118156Table 2 Notification message types for non-3GPP access

[0113] The UE 200 may receive a message with an error type indicating that non-3GPP access to the 5GCN 100 is not permitted. As a result, the UE 200 is notified that access to the 5GCN 100 via the non-3GPP access network 110 has been denied.

[0114] EMBODIMENT - CAUSE CODE FOR NOTIFYING AUTHENTICATION FAILURE DUE TO NO SUBSCRIPTION FOR NON-3GPP ACCESS TO A 5GC NETWORK FIG. 11 shows a schematic block diagram of an embodiment of a 5GMM cause information element 1100. The 5GMM cause information element 1100 includes a 5GMM cause information element indicator (IEI) 1104 and a cause value 1106. The cause value 1106 indicates the reason why the 5GMM request from the UE 200 to access the 5GCN 100 is rejected by the network. In this embodiment, a new cause code corresponds to "non-3GPP access to 5GCN is not allowed". This 5GMM cause is sent to the UE 200 when the UE 200 requests a service via non-3GPP access in a PLMN where the UE 200 is not allowed to access the 5GCN 100 via non-3GPP access due to subscription, network restrictions, or other authentication failures.

[0115] FIG. 12 shows a schematic block diagram of an embodiment of values ​​of a 5GMM Cause information element. In this example, the predefined value corresponds to "non-3GPP access to 5GCN not allowed". Any other value received by the UE 200 is treated as "protocol error, unspecified". Any other value received by the network is also treated as "protocol error, unspecified". The fields and values ​​of the 5GMM Cause information element are only examples and other fields / values ​​exhibiting similar meanings may be implemented.

[0116] 13 illustrates a logic flow diagram of an embodiment of a method 1300 of the N3IWF 204. The N3IWF 204 communicates with a node in the 5GCN 100 using a first interface using one or more protocols at step 1302. The N3IWF 204 communicates with a UE over a non-3GPP access network at step 1304 using at least a second interface, such as a WLAN transceiver conforming to an IEEE 802.1x WLAN protocol.

[0117] In step 1306, the N3IWF 204 processes a registration request for establishing a secure connection from the UE 200 in the untrusted access network to the core network. For example, the N3IWF 204 receives an EAP-Response / 5G-NAS message including an AN parameter and a registration request from the UE 200. The N3IWF 204 forwards the message to the 5GCN 100 for authentication and subscription check of the UE 200. For example, the N3IWF 204 generates a request for authentication and subscription check and sends the request for authentication and subscription check to the AMF 202 via the second interface.

[0118] The N3IWF 204 determines in step 1308 that the establishment of the connection is not authorized by the core network, for example, due to an unrecoverable error. For example, the AMF 202 receives an authentication failure response from the AUSF 210. The AMF 202 generates a NAS transport message with a registration rejection and an EAP message of EAP failure including a 5GMM cause. The 5GMM cause (5GMM_cause) indicates that the error type is NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED. The N3IWF 204 receives a response from the AMF 202 encapsulating a registration rejection message including a 5GMM cause value indicating that non-3GPP access to 5GCN is not allowed.

[0119] The N3IWF 204 generates a response message to the UE, which includes a cause value indicating that the establishment of the connection via the untrusted network access is not permitted by the core network in step 1310. For example, the N3IWF 204 generates an Internet Key Exchange (IKE) Response message with a payload including a message type or EAP-Failure indicating that the establishment of the connection is not authorized by the 5GCN 100, and a 5GMM cause. The EAP-Response / 5G-NAS message to the UE 200 includes a Registration Reject message including an EAP-Failure field and a 5GMM cause. The 5GMM cause of the Registration Reject message indicates that the non-3GPP access is not permitted by the 5GCN 100.

[0120] In an embodiment, the IKE response message to the UE is a private notification message type (e.g., 8192 ··· The private IKEv2 notify message may include an IKE_AUTH Response message containing a Notify payload with a 5GMM notification message type (any private notification message type within a predefined range, such as 16383). The private IKEv2 notify message includes an EAP Response / 5G-NAS PDU containing a registration rejection with a 5GMM cause of "NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED" and an EAP message type of EAP-Failure.

[0121] The N3IWF 204 processes the response from the UE 200, including the stop message, and generates a failure message to the UE 200 in response. For example, the UE 200 sends an EAP-Response / 5G-Stop message to the N3IWF 204 to indicate the end of the registration request for secure session establishment with the 5GCN 100. The EAP-response packet includes a message type identifier of 5G stop. After receiving the EAP-Response / 5G-Stop message from the UE 200, the N3IWF 204 terminates the EAP-5G procedure by sending an EAP-Failure message to the UE 200. Although the N3IWF 204 is described as performing these steps in the method 1300, other nodes or modules in communication with the UE and the core network may perform one or more of the steps described herein.

[0122] FIG. 14 illustrates a logic flow diagram of an embodiment of a method 1400 of registration request to a core network via an untrusted access network with authentication failure due to a recoverable error. The UE 200 is configured to communicate to an interworking function (e.g., N3IWF 204) in the 5GCN 100 via a non-3GPP access network at step 1402. The UE 200 may request registration to the 5GCN 100 via the non-3GPP access network at 1404. The UE 200 processes a response message at 1406 including an indication that non-3GPP access to the 5GCN 100 is not allowed. The UE 200 determines at step 1408 that the error or rejection reason is recoverable. The UE 200 may modify parameters in this second registration request from the first attempt. Alternatively, the UE may decide to retry registration later with the same parameters. Next, the UE 200 sends a second registration request to the 5GCN 100 via the non-3GPP access network in step 1410. The UE 200 then processes the response in step 1412 that the session establishment was successful.

[0123] FIG. 15 illustrates a logic flow diagram of an embodiment of a method 1500 of registration request to a core network via an untrusted access network with authentication failure due to an unrecoverable error. The UE 200 is configured to communicate to an interworking function (e.g., N3IWF 204) in the 5GCN 100 via a non-3GPP access network at step 1502. The UE 200 may request registration to the 5GCN 100 via the non-3GPP access network at 1504. The UE 200 processes a response message at 1506 including an indication that non-3GPP access to the 5GCN 100 is not allowed. The UE 200 determines at step 1508 that the error or rejection reason is not recoverable. The UE 200 terminates the session at step 1510 and generates a response including a stop message. The UE 200 receives the failure message at step 1512 and performs a deletion procedure to close the session.

[0124] 16 illustrates a schematic block diagram of an embodiment of an exemplary user equipment 200. User equipment (UE) 200 may include a smartphone, smart tablet, laptop, smart watch, PC, television or other device operable to communicate via a non-3GPP access network 110. Additional or alternative components and functions may be included within UE 200. Furthermore, one or more of the functions and components illustrated herein may not be present or may not be combined with other components or functions.

[0125] The UE 200 includes a processing device 1600 and a memory device 1602 configured to perform one or more of the functions described herein with respect to the UE 200. The memory device 1602 may include managed objects 1604 that store applications and operational instructions that control the processing device 1600 to perform various functions described herein. The UE 200 may also include a UICC 1606 that includes a USIM 1608 for storage of an IMSI. In other embodiments, the UE 200 does not have UICC functionality, e.g., the UE 200 does not have a UICC 1606, the UE 200 has an inoperable UICC 1606, etc.

[0126] The UE 200 may further include a Bluetooth transceiver 1610, a WLAN (IEEE 802.11x compliant) transceiver 1612, a mobile RF (3G / 4G) transceiver 1614, and a GPS 1616. The WLAN transceiver 1612 may operate as a non-3GPP access interface to the WLAN network. The UE 200 may further include a user interface 1618, an AC adapter 1620, a battery module 1622, a USB transceiver 1624, and an Ethernet port 1628.

[0127] The UE 200 may further include a digital camera 1630, a touch screen controller 1632, a speaker 1634, and a microphone 1636. The UE 200 may also include a power management unit 1638. One or more internal communication buses (not shown) may communicatively couple one or more of the components of the UE 200.

[0128] FIG. 17 illustrates a schematic block diagram of an embodiment of an exemplary AMF 202. The AMF 202 includes any one or more nodes with the functionality of the AMF 202. The AMF 202 may be integrated with other nodes in the 5GCN 100. Additional or alternative components and functions may be included in the AMF 202. Furthermore, one or more of the functions and components illustrated herein may not be present or may not be combined with other components or functions or nodes. The AMF 202 includes a processing device 1700 and a memory device 1702 configured to perform one or more of the functions described herein with respect to the AMF 202. The AMF 202 may include a network interface 1704 including ports for interfacing with other network nodes in the 5GCN 100.

[0129] 18 illustrates a schematic block diagram of an embodiment of an exemplary N3IWF 204. The N3IWF 204 may be an access point in a wireless local area network, a gateway in a local area network, or other type of node including the interworking functionality described herein. The N3IWF 204 may be integrated with other nodes in the access network or 5GCN 100. Additional or alternative components and functions may be included in the N3IWF 204. Furthermore, one or more of the functions and components illustrated herein may not be present or may not be combined with other components or functions.

[0130] The N3IWF 204 includes a processing device 1800 and a memory device 1802 configured to perform one or more of the functions described herein. The N3IWF 204 may include a first network interface 1804 (e.g., an Ethernet port, an IP port) for interfacing with other network nodes in the 5GCN 100. The N3IWF 204 may also include one or more other types of interfaces for communicating with a UE, such as a WLAN transceiver 1806 (e.g., compliant with an IEEE 802.1x WLAN type network). The N3IWF 204 may also include a mobile RF transceiver 1808 compliant with a cellular air interface. The UE 200 may communicate with the N3IWF 204 using one or more of the WLAN transceiver 1806 or the mobile RF transceiver 1808.

[0131] In an embodiment, the processing device is configured to receive an IPsec security association (SA) request from the UE 200 via an untrusted non-3GPP access network and perform an authentication protocol for the UE 200 in the untrusted non-3GPP access network, such as an IKE protocol. The N3IWF 204 can then obtain an authentication response indicating that the IPsec SA request is not authorized by the core network. The N3IWF 204 can then generate an authentication response to the UE 200 indicating that access to the core network by the UE 200 via the untrusted access network is denied.

[0132] The processing device described herein includes at least one processing device such as a microprocessor, a microcontroller, a digital signal processor, a microcomputer, a central processing unit, a field programmable gate array, a programmable logic device, a state machine, a logic circuit, an analog circuit, a digital circuit, and / or any device that manipulates signals (analog and / or digital) based on hard-coded and / or operational instructions in the circuit. The memory device is a non-transitory memory device and may be an internal memory or an external memory, and the memory may be a single memory device or multiple memory devices. The memory device may be a read-only memory, a random access memory, a volatile memory, a non-volatile memory, a static memory, a dynamic memory, a flash memory, a cache memory, and / or any non-transitory memory device that stores digital information. The term "module" is used in the description of one or more embodiments of the elements herein. A module includes one or more processing devices and / or one or more non-transitory memory devices operable to perform one or more functions, as may be described herein. A module may operate independently and / or in combination with other modules and may utilize the processing devices and / or memories of other modules and / or operational instructions of other modules. As also used herein, a module may include one or more sub-modules, each of which may be one or more modules.

[0133] As may be used herein, the term "operable" or "configurable" indicates that an element includes one or more of circuits, instructions, modules, data, input(s), output(s), etc., for performing one or more of the described or required corresponding functions, and may further include inferential coupling to one or more other items to perform the described or required corresponding functions. As may also be used herein, the term(s) "coupled," "coupled to," "connected to," and / or "connecting" or "interconnected" include direct connections or links between nodes / devices and / or indirect connections between nodes / devices through intervening items (e.g., items include, but are not limited to, components, elements, circuits, modules, nodes, devices, network elements, etc.). As may be further used herein, inferential connections (i.e., when one element is connected to another element by inference) include direct and indirect connections between two items, similar to "connected."

[0134] It is noted that aspects of the disclosure may be described herein as a process, which is depicted as a schematic, a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Moreover, the order of operations may be rearranged. A process ends when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its end corresponds to a return of the function to the calling function or to the main function.

[0135] Various features of the present disclosure described herein can be implemented in various systems and devices without departing from the present disclosure. It should be noted that the above aspects of the present disclosure are merely examples and should not be construed as limiting the present disclosure. The description of the aspects of the present disclosure is intended to be illustrative and not limiting of the claims. Thus, the present teachings can be readily applied to other types of devices, and many alternatives, modifications, and variations will be apparent to those skilled in the art.

[0136] In the above specification, certain representative aspects of the invention have been described with reference to specific examples. However, various modifications and changes may be made without departing from the scope of the invention as set forth in the claims. The specification and figures are illustrative rather than limiting, and modifications are intended to be included within the scope of the invention. Thus, the scope of the invention should be determined by the claims and their legal equivalents, and not merely by the examples described. For example, the components and / or elements recited in any device claim may be assembled or otherwise operatively configured in various combinations, and therefore are not limited to the specific configurations recited in the claims.

[0137] Moreover, although certain benefits, other advantages, and solutions to problems have been described above with respect to particular embodiments, any particular benefit, advantage, solution to a problem, or elements which may give rise to or make more pronounced any particular benefit, advantage, or solution, should not be construed as a critical, essential, or essential feature or component of any or all of the claims.

[0138] As used herein, the terms "comprise," "comprises," "comprising," "having," "including," "includes," or any variation thereof, are intended to refer to a non-exclusive inclusion such that a process, method, article, composition, or apparatus making up a list of elements does not include only the recited elements, but may include other elements not expressly listed or inherent to such process, method, article, composition, or apparatus. Other combinations and / or variations of the above-described structure, arrangement, application, proportions, elements, materials, or components used in the practice of the invention, in addition to those not specifically mentioned, may be varied or otherwise specifically adapted to particular environments, manufacturing specifications, design parameters, or other operating requirements without departing from the same general principles.

[0139] Furthermore, reference to an element in the singular is intended to mean "one or more" and not "one and only one" unless otherwise specified. The term "a part" refers to one or more unless otherwise specified. All structural and functional equivalents to the elements of the various embodiments described throughout this disclosure that are known or that later become known to those of skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Furthermore, nothing disclosed herein is intended to be made available to the public, regardless of whether such disclosure is expressly set forth in the claims. No claim element is intended to be construed as a "means-plus-function" type element under 35 U.S.C. 112(f) unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, the element is recited using the phrase "step for."

Claims

1. An interworking function node (N3IWF) for managing a network connection to a fifth generation core network (5GCN) via an untrusted non-third generation partnership project (non-3GPP) access network, the N3IWF comprising: a first network interface configured to communicate with a user equipment (UE) via the untrusted non-3GPP access network; A second network interface configured to communicate with an Access and Mobility Management Function (AMF) in the 5GCN; and 1. A processing device, comprising: Processing a request for establishing a secure connection to the 5GCN received from the UE via the untrusted non-3GPP access network to generate a request to the AMF of the 5GCN; providing an authentication and secure connection establishment request to the AMF in the 5GCN via the second network interface; determining, based on a response from the AMF in the 5GCN in response to the authentication and secure connection establishment request, that establishment of a secure connection via an untrusted non-3GPP access network is not permitted by the 5GCN; providing the UE with a response message including a 5G Mobility Management (5GMM) cause value indicating that the 5GCN does not allow access to the 5GCN via any untrusted non-3GPP access network; receiving, in response to the response message, from the UE a STOP message terminating the request to establish the secure connection to the 5GCN via the untrusted non-3GPP access network, the STOP message including a message identifier field including a 5G-Stop identifier indicating that the UE intends to terminate the request to establish the secure connection to the 5GCN via the untrusted non-3GPP access network; A processing device configured to cause the N31WF to execute Equipped with N3IWF.

2. The processing device further comprises: receiving, from the UE, the request to establish the secure connection to the 5GCN through the first network interface via the untrusted non-3GPP access network; receiving the response to the request for authentication and subscription check from the AMF of the 5GCN through the second network interface; generating an Internet Key Exchange (IKE) Response message to the UE having a Non-Access Stratum (NAS) payload including the 5GMM cause value indicating that the 5GCN does not allow a secure connection establishment via any untrusted non-3GPP access network; The N3IWF according to claim 1 , configured to cause the N31WF to execute the following:

3. The processing device further comprises: receiving a response from the AMF of the 5GCN encapsulating a registration rejection message including an indication that the 5GCN does not allow a secure connection establishment to the 5GCN via any untrusted non-3GPP access network; generating the IKE response message having a payload including a message type indicating that the 5GCN does not allow a secure connection to be established with the 5GCN via an untrusted non-3GPP access network; The N3IWF according to claim 2 , configured to cause the N31WF to execute the following:

4. The processing device further comprises: generating said IKE response message having a notification payload including a private notification message type indicating a failure reason; or generating the IKE response message with the notification payload including the private notification message type indicating that connection establishment and connectivity with the 5GCN via an untrusted non-3GPP access network is not permitted by the 5GCN; The N3IWF according to claim 2, configured to cause the N31WF to generate the IKE response message by any one of the following:

5. The processing device further comprises: generating a failure message to the UE in response to receiving the stop message from the UE; and processing the stop message received from the UE, the stop message comprising a 5G-Stop message format having a message identifier field, the message identifier field comprising a 5G-Stop identifier; The N3IWF according to claim 1 , configured to cause the N31WF to execute the following:

6. The N3IWF of claim 1, wherein the registration request for secure connection establishment received from the UE via the untrusted non-3GPP access network includes an IKE request message for initiating an IPsec security association (SA) with the 5GCN.

7. An access and mobility management function (AMF) device for handling a network connection request from an interworking function node (N3IWF) of a fifth generation core network (5GCN), the AMF device comprising: A network interface configured to communicate with the N3IWF and an Authentication and Subscription Function (AUSF) in the 5GCN; 1. A processing device, comprising: receiving from the N3IWF via the network interface an authentication and secure connection establishment request related to a registration request for establishing a secure connection with the 5GCN via an untrusted non-3rd Generation Partnership Project (non-3GPP) access network, the registration request having been received by the N3IWF from a user equipment (UE); in response to receiving the authentication and secure connection establishment request, providing to the AUSF of the 5GCN a request for authentication and subscription check; generating a response message in response to the authentication and secure connection establishment request received from the N3IWF by encapsulating an indication in a response message that the 5GCN does not allow access to the 5GCN via any untrusted non-3GPP access networks in response to the authentication and subscription check by the AUSF determining that the authentication and subscription check has failed; providing the response message to the N3IWF; a processing device configured to cause the AMF device to execute AMF is equipped with.

8. The processing device further comprises: The AMF device according to claim 7, configured to cause the AMF device to encapsulate a registration rejection message including the indication that the 5GCN does not allow a secure connection establishment with the 5GCN via any untrusted non-3GPP access network in the response message.

9. The processing device further comprises: The AMF device of claim 8, configured to cause the AMF device to generate an Extensible Authentication Protocol (EAP) failure indication in the response message.

10. A user equipment (UE), A network interface configured to communicate with an Interworking Function Node (N3IWF) of a Fifth Generation Core Network (5GCN) over an untrusted non-Third Generation Partnership Project (non-3GPP) access network; 1. A processing device, comprising: generating a registration request for establishing a secure connection with the 5GCN; sending a message to the N3IWF of the 5GCN via the untrusted non-3GPP network, the message including the request for secure connection establishment with the 5GCN; receiving, in response to the request, from the N3IWF of the 5GCN a response message including a 5G Mobility Management (5GMM) cause value indicating that the 5GCN does not allow a secure connection establishment with the 5GCN via any untrusted non-3GPP access network; determining from the response message that the 5GCN does not permit a secure connection establishment with the 5GCN via any untrusted non-3GPP access network; generating a stop message if the 5GCN does not allow a secure connection establishment with the 5GCN via any untrusted non-3GPP access network, the stop message including a message identifier field, the message identifier field including a 5G-Stop identifier indicating that the UE intends to terminate the request to establish the secure connection to the 5GCN via the untrusted non-3GPP access network; Setting the 5G stop identifier in the message identifier field of the stop message to 5G-Stop; sending the stop message towards the N3IWF of the 5GCN to terminate the registration request for the secure connection establishment with the 5GCN via the untrusted non-3GPP network; a processing device configured to cause the UE to execute A UE comprising:

11. The processing device further comprises: generating a stop message indicating an end of the registration request for establishing a secure connection to the 5GCN; sending the stop message to the N3IWF of the 5GCN via the untrusted non-3GPP network; The UE of claim 10, configured to cause the UE to execute the following:

12. The processing device further comprises:

12. The UE of claim 11, configured to cause the UE to generate the stop message as an Extensible Authentication Protocol (EAP)-Response formatted message including a message identifier field set to 5G-Stop.

13. The processing device further comprises: Processing an EAP failure message from the N3IWF; and performing a security association (SA) deletion procedure; The UE of claim 12, configured to cause the UE to execute the following:

Images