Apparatus and method for signaling that a fifth generation core network does not allow establishment of a secure connection over a non-third generation partnership project access network

Abstract

Processing failure for non-3GPP access to a 5G CN is provided. An interworking function in a core network system, such as a 5G core network, attempts to establish a security association with a user equipment (UE) in an untrusted access network. When the 5G core network does not accept the security association, the UE receives a response from the core network that includes a message type indicating that non-3GPP access to the 5G core network is not allowed. Upon receiving the response message, the UE ends the 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.

Description

[0001] This application is a divisional application of Chinese patent application No. 201980044322.7, filed on June 28, 2019, with a priority date of June 30, 2018, entitled "Processing failures that do not allow non-3GPP access to 5GCN".

[0002] Cross-references to related applications

[0003] This application claims priority 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 hereby expressly incorporated by reference. Technical Field

[0004] This application generally relates to access networks, and more specifically, to session establishment by user equipment in an access network when security association establishment is not accepted. Background Technology

[0005] The statements in this section provide a description of the prior art, not an admission of prior art. For example, user equipment (UE) devices such as smartphones, tablets, laptops, computers, and smartwatches typically have both wireless local area network (WLAN) connectivity (e.g., WLAN connectivity compliant with IEEE 802.11x) and radio access network connectivity (e.g., technologies fully or partially compliant with the 3GPP standards set, including EVDO, UMTS, HSPA, and LTE). Therefore, a UE can connect to a 3GPP Evolved Packet Core (EPC) network using both types of access technologies, consisting of 3GPP access networks and non-3GPP access networks.

[0006] Typically, 3GPP access networks fully or partially comply with technologies specified in the 3GPP standards set, including, for example, GPRS, UMTS, EDGE, HSPA, LTE, and LTE-Advanced. Non-3GPP access networks fully or partially comply with technologies not specified in the 3GPP standards set. These include technologies such as cdma2000, WLAN (e.g., WLAN compliant with IEEE 802.11x), or fixed networks.

[0007] The 3GPP standards set specifies “non-3GPP” access technologies with different security mechanisms: untrusted access networks and trusted access networks. Untrusted access networks include those that may pose higher security risks (e.g., public WLANs or femtocell access networks). Trusted access networks include those that network operators have a trust level for from a security perspective and can directly interface with EPC networks.

[0008] In the new 5G standards set, non-3GPP access networks (N3AN) are considered 5G access networks and are regarded as part of the 5G system (5GS). For untrusted non-3GPP access, the non-3GPP interworking function (N3IWF), like NG-RAN nodes, provides termination of signaling interfaces for the control plane and user plane respectively. Therefore, 5G-enabled UEs can access the 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. In addition, the N3IWF provides user plane connectivity between the UE and the 5GCN for sessions on the non-3GPP access network.

[0009] Currently, when the network accepts certain security authentication establishments, a signaling procedure is specified between the UE and the N3IWF. However, there is no available method to handle cases where the network does not accept security association establishments. Similarly, for user plane connections, a method needs to be specified to handle cases where the network does not accept user plane security association establishments.

[0010] Therefore, there is a need to provide a system and method for handling failures during the establishment of a secure association for accessing a 5GCN via a non-3GPP access network. The implementation described herein also provides other requirements and benefits. Summary of the Invention

[0011] The following is an overview of the disclosed subject matter to provide a basic understanding of some aspects of it. This overview is not an exhaustive summary of the disclosed subject matter. It is not intended to identify key or defining elements of the disclosed subject matter or to delineate its scope. Its sole purpose is to present some concepts in a simplified form as an introduction to the more detailed descriptions discussed below.

[0012] In one aspect, an interoperability function node for managing network connections 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 interoperability function node includes processing means configured to: process a request from a UE in the untrusted access network to establish a connection with the core network and generate a request to the core network; determine that the core network does not accept the connection establishment; and generate a response message to the UE, wherein the response message includes an error indicating that the core network does not allow connection establishment via the untrusted access network.

[0013] On the other hand, an Access and Mobility Management Function (AMF) for processing network connection requests from an interworking function node includes a network interface configured to communicate with an authentication function in the interworking function node and the core network. The AMF also includes processing means configured to: process a request from a UE to authenticate and establish a secure connection via an untrusted access network; generate a request for authentication and subscription checks to an Authentication Server Function (AUSF); determine a response to the authentication and subscription checks indicating authentication failure; and generate the response message by including a reason value indicating that access to the core network via the untrusted access network is not permitted in the response message for authentication and secure connection establishment.

[0014] On the other hand, the user equipment (UE) includes a network interface configured to communicate with an interoperability node via an untrusted access network. The UE includes processing means configured to: generate a registration request for establishing a secure session with the core network; process a response message from the interoperability node; and determine, based on the response message, that the core network does not allow connection establishment via the untrusted access network.

[0015] In one or more of the above aspects, the processing apparatus in the interoperability node is configured to: receive a request from the UE for authentication and secure connection establishment through an untrusted access network; generate a request for authentication and subscription checks, and transmit the request for authentication and subscription checks to the Access and Mobility Management Function (AMF) via a second interface; receive requests from...

[0016] The AMF's response to authentication and subscription checks; and the generation of an Internet Key Exchange (IKE) response message to the UE, the IKE response message having an erroneous NAS payload including an indication that the core network does not allow connection establishment through an untrusted access network.

[0017] In one or more of the foregoing aspects, the processing apparatus in the interoperability node is configured to: receive a response from the access and mobility management function, the response encapsulating a registration rejection message, the registration rejection message including a 5GMM reason value indicating that non-3GPP access to the 5GCN is not permitted; and generate an Internet Key Exchange (IKE) response message having a payload including a message type indicating that the core network does not accept connection establishment.

[0018] In one or more of the above aspects, the processing device in the interoperability node is configured to generate an Internet Key Exchange (IKE) response message having a notification payload including a special notification message type indicating the cause of failure.

[0019] In one or more of the above aspects, the processing apparatus in the interoperability node is configured to generate an IKE response message by generating an IKE response message having a notification payload including a dedicated notification message type indicating that untrusted non-3GPP access to the 5GCN is not permitted.

[0020] In one or more of the above aspects, the processing device in the interoperability node is configured to: transmit a response message to the UE, wherein the response message indicates that the core network does not accept the connection establishment; receive a stop message from the UE; and generate a failure message to the UE.

[0021] In one or more of the foregoing aspects, the processing apparatus in the interoperability function node is configured to process a stop message from the UE, wherein the stop message includes a 5G stop message format having a message identifier field, and wherein the message identifier field includes a 5G stop identifier.

[0022] In one or more of the above aspects, a request for connection establishment from a UE in an untrusted access network includes an IKE request message initiating an IPsec Security Association (SA) with the core network.

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

[0024] In one or more of the foregoing aspects, the processing apparatus in the AMF is configured to encapsulate a registration rejection message including a cause value in a response message, wherein the cause value includes a 5GMM cause value indicating that non-3GPP access to the 5GCN is not permitted.

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

[0026] In one or more of the foregoing aspects, the processing apparatus in the user equipment is configured to: generate a stop message indicating the end of a registration request for establishing a secure session with the 5GCN; and transmit the stop message to the interoperability node via a non-3GPP access network.

[0027] In one or more of the foregoing aspects, the processing device in the user equipment is configured to generate a stop message as a message in EAP response format, the message including a message identifier field set to 5G stop.

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

[0029] In one or more of the above aspects, the processing apparatus in the user equipment is configured to re-attempt registration with the 5GCN by generating a second registration request to establish a secure session with the 5GCN, and to determine that the connection established through the untrusted access network was successful based on a second response message from the interoperability node.

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

[0031] Additional aspects will be set forth in part in the detailed description, the accompanying drawings, and any claims appended, and will also derive in part from the detailed description. It should be understood that the foregoing summary and the following detailed description are merely exemplary and illustrative, and the claims are not limited to the disclosed embodiments. Attached Figure Description

[0032] Some embodiments of the apparatus and / or method according to the present disclosure will now be described by way of example and with reference to the accompanying drawings, wherein:

[0033] Figure 1 Schematic block diagrams of implementation schemes for various types of access networks are shown.

[0034] Figure 2 A schematic block diagram of an implementation scheme for a 5G system architecture for non-3GPP access is shown.

[0035] Figure 3 A logic flowchart is shown, illustrating an implementation scheme of a method for a UE to register with a 5GCN via an untrusted non-3GPP access network.

[0036] Figure 4A logic flowchart of an implementation method for processing an implementation in which IKE SA and signaling IPsec SA establishment are not accepted is shown.

[0037] Figure 5 A logical flowchart of an implementation of a method for an EAP-5G session procedure following an authentication failure due to a recoverable error is shown.

[0038] Figure 6 A logic flowchart is shown, illustrating an implementation scheme for an EAP-5G session procedure that results in registration rejection due to an unrecoverable error failure.

[0039] Figure 7 A schematic block diagram of an implementation scheme for EAP response / 5G stop message is shown.

[0040] Figure 8 A logical flowchart of an implementation scheme for a method of message flow between network functions is shown when the establishment of IKE SA and signaling IPsec SA for UE registration via non-3GPP access is not accepted.

[0041] Figure 9 A logical flowchart is shown for an implementation of a method for message flow between network functions when the establishment of IKE SA and signaling IPsec SA for UE registration via non-3GPP access is not accepted due to subscription restrictions.

[0042] Figure 10 A logical flowchart of an implementation of a method for message flow between network functions is shown when user plane IPsec security association establishment is not accepted.

[0043] Figure 11 A schematic block diagram of an implementation of the 5GMM cause information element 1100 is shown.

[0044] Figure 12 A schematic block diagram illustrating an implementation of the values ​​for the 5GMM cause information element is shown.

[0045] Figure 13 A logical flowchart of an implementation scheme for the N3IWF method is shown.

[0046] Figure 14 A logical flowchart is shown for an implementation of a method for making a registration request to the core network through an untrusted access network in the event that authentication fails due to a recoverable error.

[0047] Figure 15A logical flowchart is shown for an implementation of a method for making a registration request to the core network through an untrusted access network in the event that authentication fails due to an unrecoverable error.

[0048] Figure 16 A schematic block diagram of an implementation scheme for an example user device is shown.

[0049] Figure 17 A schematic block diagram of an AMF node implementation scheme is shown.

[0050] Figure 18 A schematic block diagram of an implementation scheme for N3IWF is shown. Detailed Implementation

[0051] The description and accompanying drawings illustrate only the principles of various embodiments. Therefore, it will be understood that those skilled in the art will be able to design various arrangements that, while not explicitly described or shown herein, embody the principles of this document and the claims and fall within the spirit and scope of this disclosure. Furthermore, all examples listed herein are intended primarily for illustrative purposes only to aid the reader in understanding the principles of the embodiments and the inventive concepts made by the inventors to further their understanding in the art, and should be construed as not being limited to these specifically listed examples and conditions. Moreover, all statements herein referencing principles, aspects, and embodiments and their specific examples are intended to cover their equivalents.

[0052] For convenience, some of the abbreviations described in this article will be expanded below:

[0053] 5GC 5G core

[0054] 5GCN 5G Core Network

[0055] 5GS 5G system

[0056] 5G-AN 5G Access Network

[0057] 5GMM 5GS Mobility Management

[0058] 5G-GUTI 5G Globally Unique Temporary Identifier

[0059] 5G-S-TMSI 5G S Temporary Mobile Subscription Identifier

[0060] 5QI 5G QoS identifier

[0061] AMF Access and Mobility Management Functions

[0062] AUSF Authentication Server Functionality

[0063] EAP Extensible Authentication Protocol

[0064] HPLMN Home Public Land Mobile Network

[0065] IKEv2 Internet Key Exchange Version 2

[0066] IMSI International Mobile Subscriber Identity

[0067] IMEI (International Mobile Equipment Identity)

[0068] IPsec Internet Protocol Security

[0069] MCM Multi-Connection Mode

[0070] N3IWF Non-3GPP Interoperability Function

[0071] NAS Non-Access Layer

[0072] PDN (Packet Data Network)

[0073] PLMN Public Land Mobile Network

[0074] QoS (Quality of Service)

[0075] SA Security Association

[0076] SCM Single Connection Mode

[0077] UDM Unified Data Management

[0078] UE User Equipment

[0079] UICC General Integrated Circuit Card

[0080] USIM UMTS Subscriber Identity Module

[0081] This document describes one or more embodiments of systems and methods for providing network services to unauthenticated user equipment. For example, various methods for establishing sessions for unauthenticated UEs in non-3GPP access networks are described.

[0082] Figure 1 A schematic block diagram is shown illustrating implementation schemes for various types of access networks for a 5G core network (5GCN) 100, which fully or partially conforms to the 3rd Generation Partnership Project (3GPP) standards set for 5G systems, such as Technical Specification (TS) 23.501 "System Architecture for 5G Systems", Technical Specification (TS) 23.502 defining procedures for 5G systems, and Technical Specification (TS) 23.503 defining the policy and charging control framework for 5G systems.

[0083] The 5GCN 100 is communicatively coupled to one or more access networks 102. In an embodiment, the access network 102 may include one or more 3GPP access networks 104 or one or more non-3GPP access networks 106. The 3GPP access network 104 fully or partially conforms to technologies specified in the 3GPP standards set and includes, for example, GPRS, UMTS, EDGE, HSPA, LTE, and LTE-Advanced. The non-3GPP access network 106 fully or partially conforms to technologies not specified in the 3GPP standards set. The non-3GPP access network 106 may also be specified in the 3GPP standards set. The non-3GPP access network 106 may include one or more non-3GPP trusted access networks 108 or one or more non-3GPP untrusted access networks 110.

[0084] Trusted non-3GPP access network 108 is an operator-built or operator-supported wireless local area network (WLAN), such as an IEEE 802.11x compliant WLAN network with encryption and secure authentication methods. In one implementation, trusted non-3GPP access network 108 supports the following example features: 802.1x-based authentication, which in turn requires encryption of the radio access network (RAN); 3GPP-based network access using EAP methods for authentication; and IPv4 and / or IPv6 protocols. However, operators may determine that other types of non-3GPP access networks with different types of security will be considered trusted. Untrusted non-3GPP access network 110 includes non-3GPP access networks that are unknown to the operator or do not include supported authentication standards. For example, untrusted non-3GPP access networks may include home or public WLANs, such as IEEE 802.11x compliant WLAN networks open to public, home, or other non-operator-initiated and managed networks.

[0085] Figure 2 A schematic block diagram illustrating an implementation scheme for a 5G system architecture for non-3GPP access is shown. This architecture is described in more detail in the technical standard 3GPP TS23.501 (Revision 15) (December 2017), entitled "System Architecture for the 5G System," which is incorporated herein by reference.

[0086] A non-3GPP access network connects to 5GCN 100 via a non-3GPP interoperability function (N3IWF). N3IWF 204 interfaces with the control plane (CP) and user plane (UP) functions of 5GCN 100 via the N2 and N3 interfaces, respectively. UE 200 establishes an IPSec tunnel with N3IWF 204 to attach to 5GCN 100 through an untrusted non-3GPP access network 110. UE 200 is authenticated by 5GCN 100 and attached to 5GCN 100 during the IPSec tunnel establishment procedure. Further details regarding UE 200's attachment to 5GCN 100 via an untrusted non-3GPP access network 110 are described in 3GPP TS23.502 (Release 15) (December 2017), entitled "Procedures for the 5G System," the technical standard of which is incorporated herein by reference.

[0087] 5GCN 100 includes a Home Public Land Mobile Network or an equivalent Home PLMN (HPLMN), including Access and Mobility Management Functions (AMF) 202. AMF 202 provides termination of the control plane interface (N2) and the NAS (N1) protocol set, as well as NAS encryption and integrity protection. AMF 202 also provides registration and connection management. AMF 202 can include various functions to support non-3GPP access networks 110. For example, AMF 202 can provide support for the N2 interface control protocol via N3IWF 204 and support NAS signaling with UE 200 via N3IWF 204. Additionally, AMF 202 can support authentication of UE 200 connected via N3IWF 204, as well as mobility management, authentication, and separate security context states for UE 200 via non-3GPP access connections or simultaneously via 3GPP and non-3GPP access connections. The Non-Access Stratum (NAS) is a protocol set in the 5G standard. 5G NAS (Non-Access Stratum) includes procedures related to 5GMM (5GS Mobility Management) and 5GSM (5G Session Management) on 5GS (5G System). NAS is used to transmit control signaling between User Equipment (UE) and 5GCN functions. The version of the 5G NAS protocol is defined in 3GPP TS24.501: “Access-Stratum (NAS) protocol for 5G System (5GS)”, version 1.1 (May 9, 2018), which is incorporated herein by reference.

[0088] The Session Management Function (SMF) 206 includes session management functionality such as session establishment, modification, and publication, including tunnel maintenance between the UPF 208 and the AN node. SMF 206 also provides UE IP address allocation and management (including optional authorization) as well as DHCPv4 (server and client) and DHCPv6 (server and client) functionality.

[0089] User plane function (UPF) 208 provides external PDU session points for interconnection with data networks and packet routing and forwarding. UPF 208 also supports the user plane portion of policy rule enforcement, such as strobing, redirection, and traffic redirection.

[0090] Policy Control Function (PCF) 214 supports a unified policy framework for managing network behavior. Unified Data Management (UDM) 212 includes support for generating 3GPP AKA authentication credentials, access authorization based on subscription data (e.g., roaming restrictions), and UE service NF registration management (e.g., AMF for UE storage services, SMF for UE PDU session storage services). It also provides SMS and subscription management. To provide this functionality, UDM 212 uses subscription data (including authentication data) that can be stored in the UDR. Another module provides Authentication Server Function (AUSF) 210.

[0091] In the case of untrusted non-3GPP access 110, the functionality of N3IWF 204 includes supporting IPsec tunnel establishment with UE 200. N3IWF 204 terminates the IKEv2 / IPsec protocol with UE 200 via the NWu interface and relays the information required to authenticate UE 200 and authorize its access to 5GCN 100 via the N2 interface. N3IWF 204 provides terminals for 5GCN 100 with N2 and N3 interfaces for the control plane and user plane, respectively. N3IWF 204 relays uplink and downlink control plane NAS (N1) signaling between UE 200 and AMF 202. N3IWF 204 provides processing of N2 signaling related to PDU sessions and QoS from SMF 206 (relayed by AMF 202). N3IWF 204 also provides the establishment of IPsec Security Associations (IPsec SAs) to support PDU session traffic. The N3IWF 204 also provides uplink and downlink user plane packets relay between UE 200 and UPF 208.

[0092] Figure 3A logic flowchart is shown, illustrating an implementation of a method for UE 200 to register with 5GCN 100 via untrusted non-3GPP access 110. This method includes a vendor-specific Extensible Authentication Protocol (EAP) called “EAP-5G”. EAP is defined in IETF RFC 3748, “Extensible Authentication Protocol (EAP)”, published in June 2004. EAP-5G is a vendor-specific EAP for 5GS used to encapsulate NAS messages between UE 200 and N3IWF 204. EAP-5G packets utilize an “extended” EAP type and an existing 3GPP vendor ID registered with IANA according to the SMI Private Enterprise Code Registry (i.e., 10415). In this implementation, EAP-5G is used only for encapsulating NAS messages (not for authentication).

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

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

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

[0096] In step 3, UE 200 will initiate the process by sending an IKE_AUTH request message.

[0097] IKE_AUTH exchange. The AUTH payload is not included in the IKE_AUTH request message, which instructs the IKE_AUTH exchange to use the Extensible Authentication Protocol (EAP) signaling protocol, such as...

[0098] EAP-5G signaling (e.g., the EAP-AKA described in IETF RFC 5448: "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)" (March 5, 2018), which is incorporated herein by reference).

[0099] In step 4, N3IWF 204 responds with an IKE_AUTH response message, which includes an EAP Request / 5G Start packet. The EAP Request / 5G Start packet notifies UE 200 to initiate an EAP-5G session, i.e., to begin sending NAS messages encapsulated within EAP-5G packets.

[0100] In step 5, UE 200 generates and transmits a registration request for 5GCN 100, such as an IKE_AUTH request, which includes an EAP response / 5G-NAS packet containing access network parameters (AN parameters) and a NAS registration request message. Therefore, the UE confirms the start of the EAP-5G session by sending an EAP response / 5G-NAS packet, which includes: a) a NAS-PDU field containing a NAS message (e.g., a registration request message); and b) an AN parameter field containing access network parameters, such as SUPI or 5G-GUTI, the selected network, and S-NSSAI, etc. (see 3GPP TS23.502). N3IWF 204 uses the AN parameters to select AMF 202 in 5GCN 100.

[0101] In step 6a, N3IWF 204 selects AMF202 in 5GCN 100 based on the received AN parameters and local policies. N3IWF 204 then forwards the registration request received from UE 200 to the selected AMF 202 in step 6b. After receiving the NAS message from AMF 202, N3IWF 204 includes the NAS message in the EAP request / 5G-NAS message sent to UE 200. The EAP request / 5G-NAS message includes a NAS-PDU field containing the NAS message. Other NAS messages transmitted between UE 200 and AMF 202 via N3IWF 204 are inserted into the NAS-PDU field of the EAP response / 5G-NAS message (UE to N3IWF direction) and the EAP request / 5G-NAS message (N3IWF to UE direction).

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

[0103] In step 8, AMF 202 can decide to authenticate UE 200. In this case, AMF 202 will select AUSF 210 by using UE 200's SUPI or an encrypted SUPI, and will send a key request to the selected AUSF 210 in step 8a. AUSF 210 can initiate EAP-AKA' authentication in step 8b, as specified in TS 3GPP TS 33.501: "Security Architecture and Procedures for 5G System" (March 26, 2018, version 15), the protocol of which is incorporated herein by reference. In step 8c, the EAP-AKA' challenge packet is encapsulated in a NAS authentication message destined for N3IWF, and in step 8d, the NAS authentication message is encapsulated in an EAP / 5G-NAS packet. In step 8e, UE 200 generates an authentication response to the EAP-AKA challenge. In step 8f, the authentication response is forwarded to the AMF by N3IWF 204. Then, in step 8g, AUSF 210 receives the authentication response from the AMF.

[0104] After successful authentication of UE 200, in step 8h, AUSF 210 sends the anchor key (SEAF key) to AMF 202, which uses the anchor key to derive the NAS security key and the N3IWF 204 security key (N3IWF key). UE 200 also derives the anchor key (SEAF key) and from it derives the NAS security key and the N3IWF 204 security key (N3IWF key). UE 200 and N3IWF 204 use the N3IWF key to establish an IPsec security association (in step 11). If AMF 202 provided an encrypted SUPI to AUSF 210 in step 8a, then AUSF 210 includes the SUPI (unencrypted).

[0105] In steps 9a and 9b, AMF 202 sends a Security Mode Command (SMC) request to UE 200 to activate NAS security. This request is first sent to N3IWF 204 (within the N2 message) along with the N3IWF key. If EAP-AKA authentication was successfully performed in step 8, the EAP received by AMF 202 from AUSF 210 will be successfully encapsulated in the SMC request message in step 9a.

[0106] In step 10a, UE 200 completes EAP-AKA authentication (if initiated in step 8) and creates a NAS security context and an N3IWF key. After creating the N3IWF key in UE 200, UE 200 requests completion of the EAP-5G session by sending an EAP response / 5G completion packet. Assuming N3IWF 204 has also received the N3IWF key from AMF 202, this triggers N3IWF 204 to send an EAP success message to UE 200 in step 10b. This completes the EAP-5G session, and no further EAP-5G packets are exchanged. If N3IWF 204 has not yet received the N3IWF key from AMF 202, N3IWF 204 responds with an EAP failure.

[0107] In step 11, an IPsec SA is established between UE 200 and N3IWF 204 using the public N3IWF key created in UE 200 and received by N3IWF 204 in step 9a. This IPsec SA is referred to as the "Signaling IPsec SA". After the Signaling IPsec SA is established, all NAS messages are exchanged between UE 200 and N3IWF 204 via this IPsec SA. The Signaling IPsec SA will be configured to operate in transport mode. The SPI value is used to determine whether IPsec packets carry NAS messages.

[0108] In step 12, UE 200 sends an SMC completion message via the established signaling IPsec SA, and all subsequent NAS messages are exchanged between UE 200 and AMF 202 via this IPsec SA.

[0109] As described above, UE 200 and N3IWF 204 have defined methods for accepting the establishment of IKE SA and signaling IPsec SA on non-3GPP access network 110 when 5GCN 100 accepts the establishment of IKE SA and signaling IPsec SA. However, there is no available system or method to handle the case where 5GCN 100 does not accept the establishment of IKE SA and signaling IPsec SA. Furthermore, for the user plane, a system and method need to be specified to handle the case where 5GCN 100 does not accept the establishment of user plane IPsec SA. Typically, a method and system for handling the rejection of non-3GPP access to 5GCN 100 needs to be established.

[0110] Implementation Plan - Process and Protocol Enhancements for Handling Situations Where the 5G Core Network Does Not Accept UE Registration Through Non-3GPP Access Networks

[0111] Figure 4 A logical flowchart of an implementation of method 400 for handling cases where IKE SA and signaling IPsec SA establishment are not accepted is shown. In step 402, UE 200 continues with a request to establish an IPsec security association (SA) with the selected N3IWF 204. UE 200 initiates IPsec SA establishment using the Internet Key Exchange (IKE) protocol described in IETF RFC 7296 “Internet Key Exchange Protocol version 2 (IKEv2)” (October 2014). In step 404, UE 200 sends an IKE_AUTH request message. In step 406, N3IWF 204 responds with an IKE_AUTH response message, which includes an EAP Request / 5G Start packet. The EAP Request / 5G Start packet notifies UE 200 to initiate an EAP-5G session, i.e., to begin sending NAS messages encapsulated within EAP-5G packets.

[0112] In step 408, UE 200 generates a registration request, such as an IKE_AUTH request, to 5GCN 100. The IKE_AUTH request includes an EAP response / 5G-NAS packet, which contains access network parameters (AN parameters) and a NAS registration request message. The AN parameters contain information used by N3IWF 204 to select AMF 202 in 5GCN 100 (e.g., SUPI or 5G-GUTI, the selected network, and NSSAI).

[0113] In some cases, such as due to authentication failure (e.g., EAP-AKA authentication fails), UE registration via non-3GPP access is rejected. Then, 5GCN 100 does not accept IKE SA and signaling IPsec SA establishment. In one implementation, in step 410, AMF 202 generates a registration rejection message, and N3IWF 204 sends an EAP response / 5G-NAS message to the UE, the EAP response / 5G-NAS message including a NAS-PDU field containing the registration rejection message.

[0114] Upon receiving the registration rejection message, in step 412, UE 200 terminates the registration request by generating and sending an EAP response / 5G stop message (encapsulated in an IKE_Auth request). In step 414, UE 200 receives an IKE_AUTH response with an EAP failure message from N3IWF 204. Upon receiving the EAP failure message from N3IWF 204, UE 200 executes the IKEv2 SA removal procedure. UE 200 does not re-initiate IKE SA and signaling IPsec SA establishment from the same PLMN to N3IWF 204 until the UICC containing the USIM is disconnected or removed.

[0115] When UE 200's registration via non-3GPP access network 110 is rejected, AMF 202 transmits a registration rejection message to N3IWF 204. In response, N3IWF 204 transmits an EAP response / 5G-NAS message to UE 200, the EAP response / 5G-NAS message including...

[0116] The NAS-PDU field contains the registration rejection message. Subsequent UE 200 responses may vary depending on the reason for the registration rejection. For recoverable errors, such as syntax errors or certain temporary rejection reasons, the UE 200 may attempt to initiate registration again using valid parameters. Due to other rejection reasons, the UE 200 terminates the EAP-5G procedure and restores resources related to the IKE SA and EAP stack. Terminating the EAP-5G procedure requires a 5G stop instruction. Both procedures are described in more detail herein.

[0117] Implementation Plan - Completion of EAP-5G Procedures Following Registration Failure Due to Recoverable Errors

[0118] Figure 5A logical flowchart of an implementation of method 500 for an EAP-5G session procedure following authentication failure due to a recoverable error is shown. In this implementation, the UE 200's registration request to the 5GCN 100 via an untrusted non-3GPP access network 110 is rejected.

[0119] In step 502, N3IWF 204 transmits an EAP request / 5G start message to UE 200. The 5G start message requests UE 200 to initiate an EAP-5G session, i.e., to begin sending NAS messages encapsulated within EAP-5G packets. In step 504, UE 200 generates a registration request to 5GCN 100 with an EAP response / 5G-NAS message, which includes AN parameters and a NAS-PDU field containing the registration request. In this embodiment, AMF 202 rejects UE 200's registration with 5GCN 100. AMF 202 transmits a registration rejection message to N3IWF 204. In response, in step 506, N3IWF 204 transmits an EAP response / 5G-NAS message to UE 200, which includes a NAS-PDU field containing the NAS registration rejection message.

[0120] UE 200 can attempt to register with the 5GCN again, but re-attempting registration is not mandatory. For recoverable errors, such as syntax errors or certain temporary rejection reasons, UE 200 can modify the registration request message using updated parameters and re-attempt registration. Alternatively, UE 200 can re-attempt registration later without updating parameters.

[0121] In step 508, UE 200 transmits a second registration request formatted as an EAP response / 5G-NAS message, which includes updated AN parameters (if needed) and a NAS-PDU field including the registration request. Then, UE 200 and N3IWF 204 perform IKE SA and signaling IPsec SA establishment to create a NAS security context and an N3IWF key (not shown).

[0122] After the N3IWF key is created in UE 200, at 510, N3IWF 204 transmits an EAP request / 5G NAS message including a NAS PDU with a security mode command message indicating EAP success. At 512, UE 200 requests completion of the EAP-5G session by generating and transmitting an EAP response / 5G-NAS message with a NAS PDU including a security mode completion message. Assuming N3IWF 204 has also received the N3IWF key from AMF 202, this triggers N3IWF 204 to send an EAP success message to UE 200. This completes the EAP-5G session, and no further EAP-5G packets are exchanged.

[0123] Therefore, when rejected, UE 200 can retry the registration request to 5GCN 100 via a non-3GPP access network 110. 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 succeed. In another implementation, the rejection is due to a temporary reason. UE 200 can then retry registration using the same parameters and complete the EAP-5G session.

[0124] Implementation Plan - Completion of EAP-5G Procedures Following Registration Failure Due to Unrecoverable Errors

[0125] Figure 6 A logic flowchart is shown, illustrating an implementation scheme for an EAP-5G session procedure where registration is rejected due to an unrecoverable error or permanent failure. In this implementation, the UE 200's registration request to the 5GCN 100 via the untrusted non-3GPP access network 110 is rejected again.

[0126] In step 602, N3IWF 204 transmits an EAP request / 5G start message to UE 200 via non-3GPP access network 110 to initiate registration with 5GCN 100. In step 604, UE 200 responds with a registration request, for example, an EAP response / 5G-NAS message including AN parameters and a NAS-PDU field containing the registration request.

[0127] If authentication fails due to an unrecoverable error, such as an unsuccessful EAP-AKA authentication, N3IWF204 receives a registration rejection message from AMF 202 (not shown). In response to receiving the registration rejection message from AMF 202, at step 606, N3IWF 204 generates an EAP request / 5G-NAS message for UE 200. The EAP request / 5G-NAS message includes a NAS-PDU field, which includes a NAS registration rejection message with an EAP failure field.

[0128] In step 608, UE 200 terminates the registration process by generating and transmitting an EAP response / 5G stop message. The 5G stop message indicates the end of the EAP session used for registration with 5GCN 100 via non-3GPP access network 110. After receiving the EAP response / 5G stop message from UE 200, in step 610, N3IWF 204 completes the process by sending an EAP failure message to UE 200.

[0129] EAP-5G procedure. In this implementation, UE 200 terminated the EAP-5G session without retrying during registration.

[0130] Figure 7 A schematic block diagram of an implementation of an EAP response / 5G stop message 700 is shown. The EAP response / 5G stop message 700 includes various EAP packets, wherein exemplary fields include code 702, identifier 704, length 706, type 708, vendor ID 710, vendor type 712, message identifier (message ID) 714, spare 716, and extension 718. The message ID field 714 of the EAP packet includes an identifier used to indicate a 5G stop message. Examples of values ​​for the fields in the EAP packet are described in Table 1 below.

[0131]

[0132] Table 1

[0133] Example fields of EAP response / 5G stop message

[0134] The message identifier (message ID) field 714 in the EAP message includes a 5G stop identifier or value. The fields and values ​​in the EAP response / 5G stop message 700 are examples, and other fields / values ​​or protocol groups with similar meanings indicating registration stop can be implemented.

[0135] Implementation Plan - Enhanced methods and protocols for handling situations where IPsec SA establishment is not accepted due to authentication failure.

[0136] Figure 8A logical flowchart of an implementation of a method 800 for message flow between network node functions is shown when the establishment of an IKE SA and a signaling IPsec SA for UE 200 registration via a non-3GPP access network 110 is rejected due to authentication failure. For example, the establishment of an IKE SA and a signaling IPsec SA may not be accepted due to the failure of an authentication procedure such as an AKA challenge or AKA' challenge. Method 800 includes a new dedicated IKEv2 notification message type to signal the failure to the UE 200 and includes a new reason value to indicate that access to the 5GCN 100 via the non-3GPP access network 110 is not permitted.

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

[0138] In step 808, UE 200 then initiates an IKE_AUTH exchange by sending an IKE_AUTH request message. The AUTH payload is not included in the IKE_AUTH request message, indicating that the IKE_AUTH exchange will use EAP signaling (in this case, EAP-5G signaling). UE 200 sets the UE ID field in this message to any random number. In step 810, N3IWF 204 responds with an IKE_AUTH response message, which includes an EAP request / 5G start packet. The EAP request / 5G start packet notifies UE 200 to initiate an EAP-5G session, i.e., to begin sending NAS messages encapsulated within EAP-5G packets.

[0139] UE 200 can also verify the N3IWF certificate and confirm that the identity of N3IWF 204 matches the N3IWF 204 selected by UE 200. A missing certificate for N3IWF 204 or unsuccessful identity verification may result in connection failure. In step 812, UE 200 then sends an IKE_AUTH request including an EAP response / 5G-NAS packet to request registration with 5GCN 100. The EAP response / 5G-NAS message includes AN parameters (e.g., GUAMI, the selected PLMN ID, the requested NSSAI) and a NAS-PDU field including the registration request.

[0140] In step 814, N3IWF 204 then selects AMF 202 using the AN parameter and forwards the registration request received from UE 200 to AMF 202 as an N2 NAS transmission message.

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

[0142] Upon receiving RAND and AUTN, the USIM verifies the authentication vector by checking if AUTN is acceptable. If so, in step 823, the USIM calculates the response RES. In step 824, the UE 200 sends an EAP response / AKA' challenge message in the NAS message authentication response message. In steps 826 and 828, the EAP response / AKA' challenge message is transmitted to AUSF 210 via AMF 202. AUSF 210 then attempts to verify the message. If AUSF 210 has successfully verified this message, it continues with authentication.

[0143] In previously known systems, if AMF 210 determines that non-3GPP access to the 5GCN 100 is not permitted due to authentication failure in step 830, it returns an error. In the new, improved system and method, AMF 202 generates a new dedicated IKEv2 notification message type to signal, for example, that non-3GPP access to the 5GC network is not permitted due to authentication failure.

[0144] In step 832, AMF 210 sends an HTTP EAP session message with an EAP payload indicating EAP failure and an authentication result indicating authentication failure. AMF 202 generates a new 5G Mobility Management (5GMM) reason to indicate that non-3GPP access of 5GCN 100 is not permitted. In step 834, AMF 202 generates an N2 NAS delivery message with registration rejection and an EAP message indicating EAP failure and including the 5GMM reason. The 5GMM reason indicates the error type, such as "non-3GPP access of 5GCN not permitted" in this case.

[0145] In step 836, UE 200 receives an IKE_AUTH response message from N3IWF 204. This response message has a notification payload of a dedicated notification message type (e.g., any dedicated notification message type within a predefined range, such as 8192......16383). The dedicated IKEv2 notification message includes an EAP response / 5G-NAS PDU, which includes a registration rejection with the 5GMM reason "NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED" and...

[0146] EAP message types for EAP failures.

[0147] Therefore, method 800 includes a new dedicated IKEv2 notification message type and a new 5GMM reason value to notify the UE of the failure of the registration request, i.e., non-3GPP access to the 5GCN 100 is not allowed. Although the new dedicated IKEv2 notification message is implemented, other types of messages, formats, fields, or error types can be implemented to notify the UE 200 that non-3GPP access to the 5GC network is not allowed or has been rejected.

[0148] Received due to 5GMM reason

[0149] When the dedicated notification message NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED is received, in step 838, UE200 terminates the EAP-5G session by sending an EAP response / 5G-stop message. In step 840, UE200 receives an IKE_AUTH response message with an EAP failure message from N3IWF 204.

[0150] Upon receiving an EAP failure message from N3IWF 204, in step 842, UE 200 executes the IKEv2 SA deletion procedure and shuts down the IKE SA. UE 200 will not re-initiate IKE SA and IPsec SA establishment from the same PLMN to N3IWF 204 until the UICC containing the USIM is disconnected or removed. In step 844, UE 200 may transmit an IKEv2 SA deletion information message. Then, in step 846, N3IWF 204 may shut down the IKEv2 SA.

[0151] Implementation Plan - Enhanced Methods and Protocols for Handling IPsec SA Establishment When Subscription Limitations Prevent Acceptance

[0152] Figure 9 A logical flowchart of an implementation of method 900 for message flow between network functions is shown when the establishment of an IKESA and a signaling IPsec SA for UE 200 registration via non-3GPP access is not accepted due to subscription restrictions. For example, the establishment of an IKESA and a signaling IPsec SA may not be accepted due to subscription restrictions. Method 900 includes a new dedicated IKEv2 notification message type to signal failure to UE 200 and includes a new reason value to indicate that access to 5GCN 100 via non-3GPP access network 110 is not permitted.

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

[0154] In step 908, UE 200 then initiates an IKE_AUTH exchange by sending an IKE_AUTH request message. The AUTH payload is not included in the IKE_AUTH request message, indicating that the IKE_AUTH exchange will use EAP signaling (in this case, EAP-5G signaling). UE 200 sets the UE ID field in this message to any random number. In step 910, N3IWF 204 responds with an IKE_AUTH response message, which includes an EAP request / 5G start packet. The EAP request / 5G start packet notifies UE 200 to initiate an EAP-5G session, i.e., to begin sending NAS messages encapsulated within EAP-5G packets.

[0155] UE 200 can also verify the N3IWF certificate and confirm that the identity of N3IWF 204 matches the N3IWF 204 selected by the UE. A missing certificate or unsuccessful identity verification by N3IWF 204 may cause connection failure. In step 912, UE 200 then sends a registration request in an IKE_AUTH request that includes an EAP response / 5G-NAS packet. The EAP response / 5G-NAS packet includes AN parameters such as GUAMI, the selected PLMN ID, the requested NSSAI, and the NAS PDU with the registration request. In step 914, N3IWF 204 then selects AMF 202 and forwards the registration request from the NAS PDU received from UE 200 to AMF 202.

[0156] AMF 202 can decide to authenticate UE 200. In this case, AMF 202 selects AUSF 210 in step 916 and sends a key request to AUSF 210. In step 918, AUSF 210 can then initiate an authentication procedure, such as an AKA challenge or an AKA' challenge. Between AMF 202 and UE 200, the authentication packet is encapsulated in a NAS authentication message, and the NAS authentication message is encapsulated in an EAP-5G / 5G-NAS packet. The EAP request / AKA' challenge message is transmitted by AMF to UE 200 in a NAS message authentication request message in step 920, and forwarded by N3IWF in step 922. This message may include the ngKSI to be used by UE 200 and AMF 202 to identify the partial local security context created in the event of successful authentication. UE 200 will forward the RAND and AUTN received in the EAP request / AKA' challenge message to its USIM.

[0157] Upon receiving RAND and AUTN, the USIM verifies the authentication vector by checking if AUTN is acceptable. If so, in step 923, the USIM calculates the authentication response. In step 924, the UE 200 sends an EAP response / AKA' challenge message in the NAS message authentication response message. The EAP response / AKA' challenge message is transmitted from the N3IWF to the AMF in step 926, and then to the AUSF 210 in step 928. The AUSF 210 then attempts to verify the message. If the AUSF 210 has successfully verified this message, it continues with authentication. However, in step 930, the AUSF 210 may refuse authentication and disallow non-3GPP access to the 5GCN100.

[0158] In previously known systems, if AUSF 210 determines that authentication has failed, it returns an error. In the new improved approach, AMF 202 generates new reasons to signal that non-3GPP access to 5GCN 100 is not permitted. For example, AMF 202 can generate a new dedicated IKEv2 notification message type to signal to UE 200 that non-3GPP access to 5GCN 100 is not permitted, for example, due to subscription or network restrictions.

[0159] In step 932, AMF 210 sends an HTTP EAP session message containing an EAP payload indicating EAP failure and an authentication result indicating authentication failure with a reason. In step 934, AMF 202 generates an N2 NAS delivery message containing a registration rejection and an EAP message indicating EAP failure with a 5GMM reason. The 5GMM reason indicates the error type as NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED.

[0160] N3IWF 204 receives a response from AMF 202 encapsulating a registration rejection message, which includes a 5GMM reason value indicating that non-3GPP access to 5GCN is not permitted and an EAP failure type message. In step 936, N3IWF 204 generates an IKE_AUTH response message with a notification payload of a dedicated notification message type (e.g., any dedicated notification message type within a predefined range, such as 8192......16383). The dedicated IKEv2 notification message includes an EAP response / 5G-NAS PDU, which includes a registration rejection with a 5GMM reason of “NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED” and

[0161] EAP message types for EAP failures.

[0162] Therefore, a new 5GMM reason code was implemented to signal to UE 200 that non-3GPP access to 5GCN 100 is not permitted. This 5GMM reason is generated by AMF 202, and if UE 200 requests service via non-3GPP access in the PLMN, this 5GMM reason is transmitted to UE 200, indicating that UE 200 is not permitted to access 5GCN 100 via non-3GPP access network 110 due to subscription or network restrictions. Therefore, UE 200 is notified of the refusal to access 5GCN 100 via non-3GPP access network 110.

[0163] In step 936, UE 200 receives a notification payload from N3IWF 204.

[0164] The IKE_AUTH response message, whose notification payload has a dedicated notification message type, an EAP failure EAP message, and a 5GMM reason, is included.

[0165] The UE 200 therefore receives a registration rejection notification with a reason, instead of just receiving an error message, because the error message is NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED.

[0166] In step 938, UE 200 then terminates the registration request by generating an EAP response / 5G stop message to N3IWF 204. In step 940, UE 200 receives an IKE_AUTH response message with an EAP failure message from N3IWF 204.

[0167] Upon receiving an EAP failure message from N3IWF 204, in step 942, UE 200 executes the IKEv2 SA deletion procedure and shuts down the IKE SA. In this example, due to an unrecoverable error caused by subscription or network limitations, UE 200 does not re-initiate IKE SA and IPsec SA establishment from the same PLMN to N3IWF 204 until the UICC containing the USIM is disconnected or removed. In step 944, UE 200 may transmit an IKEv2 SA deletion information message. In step 946, N3IWF 204 may then shut down the IKEv2 SA.

[0168] Implementation Plan - Enhanced Methods and Protocols for Handling When User Plane IPsec SA Establishment is Not Accepted

[0169] Figure 10 A logical flowchart of an implementation of a method for message flow between network node functions is shown when a user plane IPsec security association (SA) establishment is not accepted. In step 1002, UE 200 connects to an untrusted non-3GPP access network (N3AN) 110, for example, connecting to a public WLAN using the 802.1x protocol. When UE 200 decides to attach to 5GCN 100, in step 1004, UE 200 selects N3IWF 204 in the 5G PLMN. In step 1006, UE 200 continues the establishment of the IPsec security association (SA) with the selected N3IWF 204 by initiating an IKE initial exchange. In this implementation, at 1008, UE 200 successfully establishes the IKE SA and signals the IPsec SA to the selected N3IWF 204. For example, as Figure 3 As shown, UE 200 authentication (e.g., the EAP-AKA procedure) was successful, and EAP-5G was completed.

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

[0171] Based on its own policies and configurations, and based on the QoS profiles received in the N2 PDU session request, the N3IWF 204 determines the multiple user plane IPsec SAs to be established and the QoS profiles associated with each user plane IPsec SA. For example, the N3IWF 204 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 will be transmitted through one user plane IPsec SA. In another example, the N3IWF 204 may decide to establish multiple user plane IPsec sub-SAs and associate certain QoS profiles with different user plane IPsec sub-SAs among the multiple user plane IPsec sub-SAs.

[0172] In step 1018, N3IWF 204 sends an IKE Create_Child_SA request to UE 200 to establish a first user plane IPsec subSA for a PDU session. The IKE Create_Child_SA request indicates a first user plane IPsec subSA with the SAup1 identifier. This request may include a 3GPP-specific notification payload, which includes (a) the QFI associated with the subSA, (b) the identifier of the PDU session associated with this subSA, (c) optionally, the DSCP value associated with the subSA, and (d) UP_IP_ADDRESS. The IKE Create_Child_SA request may also include other information, such as the SA payload, the traffic selector (TS) of N3IWF 204 and UE 200, etc.

[0173] In step 1020, when UE 200 accepts a new IPsec sub-SA, UE 200 sends an IKE Create_Child_SA response. In step 1022, UE 200 and N3IWF 204 can exchange multiple iterations of the IKE Create_Child_SA request and response to establish multiple IPsec sub-SAs. Additional IPsec sub-SAs are established, each IPsec sub-SA associated with one or more QFIs and...

[0174] Associated with UP_IP_ADDRESS.

[0175] If UE 200 does not accept the user plane IPsec SA request in step 1024 in step 1026, then in step 1026, UE 200 will send a notification payload with an error type.

[0176] A CREATE_CHILD_SA response message is sent to N3IWF 204. The notification message type can be "Error". A notification message type of "Error" indicates that UE 200 does not accept IPsec subSA.

[0177] Upon receiving a CREATE_CHILD_SA response message with an error-type notification payload, in step 1032, N3IWF 204 indicates the failure and a list of PDU session resource setting failures to AMF 202 via an N2 PDU session resource setting response message to trigger a refusal to establish a PDU session via non-3GPP access. Alternatively, if 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 of the failed user plane IPsec SA to the already established user plane IPsec SA, as shown in steps 1028 and 1030.

[0178] When an N2 PDU session resource release command, including a NAS PDU indicating a PDU session establishment rejection message, is received in step 1034, in step 1036, N3IWF 204 transparently forwards the PDU session establishment rejection to UE 200. A dedicated 5G Session Management (5GSM) reason, "IPsec SA Failure," is established to indicate the reason for the PDU session rejection.

[0179] Implementation Plan - Dedicated IKEv2 Notification Message Types for Non-3GPP Access

[0180] Table 2 below lists the notification message types for non-3GPP access. This example describes dedicated IKEv2 notification messages and dedicated error types; however, when non-3GPP access to the 5GCN 100 is not permitted, other message protocols, values, and error types can be used to provide the UE 200 with notifications of reasons or errors.

[0181] In this example, a dedicated IKEv2 notification message type is defined for non-3GPP access. While other values ​​and fields can be implemented, a notification message type with values ​​(in decimal) between 8192 and 16383 is reserved for dedicated errors only. A notification message type with values ​​(in decimal) between 40960 and 65535 is reserved for dedicated states. Only the dedicated IKEv2 notification message type used in this specification is described here. The dedicated notification message error type defined in Table 2 is an error notification that indicates an error has occurred during negotiation of non-3GPP access to 5GCN 100. For example, an error type can be generated in response to negotiating an IKEv2SA or IPsec SA for non-3GPP access to 5GCN 100. The fields and values ​​of the dedicated notification message type are examples, and other fields / values ​​indicating similar meanings can be implemented.

[0182]

[0183]

[0184] Table 2

[0185] Notification message types for non-3GPP access

[0186] UE 200 can receive a message with an error type indicating that non-3GPP access to 5GCN 100 is not allowed. Therefore, UE 200 is notified to refuse access to 5GCN 100 through non-3GPP access network 110.

[0187] Implementation Plan — Reason Code for Signaling Notification Authentication Failure Due to Lack of Subscription for Non-3GPP Access to 5GC Network

[0188] Figure 11A schematic block diagram of an implementation of the 5GMM cause information element 1100 is shown. 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 network refuses a 5GMM request from UE 200 to access 5GCN 100. In this implementation, the new cause code corresponds to "Non-3GPP access to 5GCN not allowed". If UE 200 requests service via non-3GPP access in the PLMN, this 5GMM cause is sent to UE 200, indicating that UE 200 is not allowed to access 5GCN 100 via non-3GPP access due to subscription or network restrictions or other authentication failures.

[0189] Figure 12 A schematic block diagram illustrating an implementation of the values ​​for the 5GMM cause information element is shown. In this example, the predetermined value corresponds to "Non-3GPP access to 5GCN not allowed". Other values ​​received by the UE 200 are considered "Protocol error, unspecified". Any other values ​​received by the network are also considered "Protocol error, unspecified". The fields and values ​​of the 5GMM cause information element are examples, and other fields / values ​​indicating similar meanings can be implemented.

[0190] Figure 13 A logical flowchart of an implementation of method 1300 of N3IWF 204 is shown. In step 1302, N3IWF 204 communicates with a node in 5GCN 100 using one or more protocols via a first interface. In step 1304, N3IWF 204 communicates with the UE via a non-3GPP access network using at least a second interface (e.g., a WLAN transceiver conforming to the IEEE 802.1x WLAN protocol).

[0191] In step 1306, N3IWF 204 processes a registration request from UE 200 in an untrusted access network to establish a secure connection with the core network. For example, N3IWF 204 receives an EAP response / 5G-NAS message from UE 200, including AN parameters and a registration request. N3IWF 204 forwards the message to 5GCN 100 for authentication and subscription checks of UE 200. For example, N3IWF 204 generates a request for authentication and subscription checks and transmits the request to AMF 202 via a second interface.

[0192] In step 1308, N3IWF 204 determines that the core network does not accept connection establishment, for example, due to an unrecoverable error. For example, AMF 202 receives an authentication failure response from AMF 210. AMF 202 generates a NAS delivery message containing a registration rejection and an EAP failure indicating a 5GMM reason. The 5GMM reason indicates the error type as follows:

[0193] NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED. N3IWF 204 receives a response from AMF 202 encapsulating a registration rejection message, which includes a 5GMM reason value indicating that non-3GPP access to 5GCN is not permitted.

[0194] In step 1310, N3IWF 204 generates a response message to the UE, wherein the response message includes a reason value indicating that the core network does not allow connection establishment through untrusted network access. For example, N3IWF 204 generates an Internet Key Exchange (IKE) response message with a payload including a message type indicating that 5GCN 100 does not accept connection establishment or EAP failure and a 5GMM reason. The EAP response / 5G-NAS message to UE 200 includes a registration rejection message with an EAP failure field and a 5GMM reason. The 5GMM reason in the registration rejection message indicates that 5GCN 100 does not allow non-3GPP access.

[0195] In the implementation, the IKE response message destined for the UE may include an IKE_AUTH response message with a notification payload of a dedicated notification message type (e.g., any dedicated notification message type within a predefined range, such as 8192......16383). The dedicated IKEv2 notification message includes an EAP response / 5G-NAS PDU, which includes a registration rejection with the 5GMM reason "NON_3GPP_ACCESS_TO_5GCN_NOT_ALLOWED" and...

[0196] EAP message types for EAP failures.

[0197] N3IWF 204 processes responses from UE 200 that include stop messages and generates a failure message in response to UE 200. For example, UE 200 transmits an EAP response / 5G stop message to N3IWF 204 to indicate the end of a registration request to establish a secure session with 5GCN 100. The EAP response packet includes a message type identifier for 5G stop. After receiving the EAP response / 5G stop message from UE 200, N3IWF 204 completes the EAP-5G procedure by sending an EAP failure message to UE 200. Although N3IWF 204 is described as performing these steps in method 1300, other nodes or modules communicating with the UE and core network may also perform one or more of the steps described herein.

[0198] Figure 14 A logical flowchart of an implementation of method 1400 for making a registration request to a core network via an untrusted access network in the event of authentication failure due to a recoverable error is shown. In step 1402, UE 200 is configured to communicate with an interoperability function (e.g., N3IWF 204) in 5GCN 100 via a non-3GPP access network. In 1404, UE 200 requests registration with 5GCN 100 via the non-3GPP access network. In 1406, UE 200 processes a response message with a notification that non-3GPP access to 5GCN 100 is not permitted. In step 1408, UE 200 determines that the error or reason for the rejection is recoverable. UE 200 can correct the parameters in this second registration request starting from the first attempt. Alternatively, the UE can decide to retry registration later using the same parameters. Then, in 1410, UE 200 transmits the second registration request to 5GCN 100 via the non-3GPP access network. Then, in step 1412, UE 200 processes a response indicating successful session establishment.

[0199] Figure 15A logical flowchart of an implementation of method 1500 for requesting registration to a core network via an untrusted access network in the event of authentication failure due to an unrecoverable error is shown. In step 1502, UE 200 is configured to communicate with an interoperability function (e.g., N3IWF 204) in 5GCN 100 via a non-3GPP access network. In 1504, UE 200 requests registration with 5GCN 100 via the non-3GPP access network. In 1506, UE 200 processes a response message with a notification that non-3GPP access to 5GCN 100 is not permitted. In step 1508, UE 200 determines that the error or reason for the rejection is not recoverable. In step 1510, UE 200 terminates the session and generates a response with a stop message. In step 1512, UE 200 receives a failure message, executes a deletion procedure, and closes the session.

[0200] Figure 16 A schematic block diagram of an embodiment of example user equipment 200 is shown. User equipment (UE) 200 may include a smartphone, smart tablet computer, laptop computer, smartwatch, PC, TV, or other device that can 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 shown herein may be absent or combined with other components or functions.

[0201] UE 200 includes a processing device 1600 and a memory device 1602 configured to perform one or more functions described herein with respect to UE 200. The memory device 1602 may include a managed object 1604 that stores application programs and operation instructions that control the processing device 1600 to perform the various functions described herein. UE 200 may also include a UICC 1606, which includes a USIM 1608 for storing an IMSI. In other embodiments, UE 200 may not have UICC functionality; for example, UE 200 may not have a UICC 1606, or may have a non-operational UICC 1606, etc.

[0202] 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 can be used as a non-3GPP access interface to a WLAN network. 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.

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

[0204] Figure 17 A schematic block diagram of an implementation of the example AMF 202 is shown. The AMF 202 includes any one or more nodes having the functionality of the AMF 202. The AMF 202 can be integrated with other nodes in the 5GCN 100. Additional or alternative components and functions may be included within the AMF 202. Additionally, one or more of the functions and components shown herein may be absent or combined with other components, 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, which includes ports for interfacing with other network nodes in the 5GCN 100.

[0205] Figure 18 A schematic block diagram of an example implementation of the N3IWF 204 is shown. The N3IWF 204 can be an access point in a wireless LAN, a gateway in a LAN, or other type of node including the interoperability functions described herein. The N3IWF 204 can be integrated with other nodes in an access network or 5GCN 100. Additional or alternative components and functions may be included within the N3IWF 204. Furthermore, one or more of the functions and components shown herein may be absent or combined with other components or functions.

[0206] The N3IWF 204 includes a processing device 1800 and a memory device 1802, configured to perform one or more 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 the UE, such as a WLAN transceiver 1806 (e.g., IEEE 802.1x WLAN type network compliant). The N3IWF 204 may also include a mobile RF transceiver 1808 compatible 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.

[0207] In one implementation, the processing apparatus is configured to receive an IPsec Security Association (SA) request from UE 200 made through an untrusted non-3GPP access network, and to perform UE 200's authentication protocol, such as the IKE protocol, in the untrusted non-3GPP access network. N3IWF 204 can then obtain an authentication response indicating that the core network does not accept the IPsec SA request. N3IWF 204 can then generate an authentication response for UE 200, wherein the authentication response indicates that UE 200 is denied access to the core network through the untrusted access network.

[0208] The processing apparatus described herein includes at least one processing apparatus, such as a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field-programmable gate array, programmable logic device, state machine, logic circuit, analog circuit, digital circuit, and / or any apparatus that manipulates signals (analog and / or digital) based on hard-coded circuit and / or operating instructions. The memory device is a non-transitory memory device and may be internal or external memory, and may be a single memory device or multiple memory devices. The memory device may be read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, 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 apparatuses and / or one or more non-transitory memory devices operable to perform one or more functions as described herein. A module may operate independently and / or in conjunction with other modules and may utilize the processing apparatus and / or memory of other modules and / or the operating instructions of other modules. Also as used herein, a module may contain one or more sub-modules, each sub-module being one or more modules.

[0209] As used herein, the terms “operable to” or “configurable to” indicate that an element includes one or more of circuits, instructions, modules, data, inputs, outputs, etc., to perform one or more of the described or necessary corresponding functions, and may also include inferred coupling with one or more other items to perform the described or necessary corresponding functions. As may also be used herein, the terms “coupled,” “coupled to,” “connected to,” and / or “connected” or “interconnected” include direct connections or links between nodes / devices, and / or indirect connections between nodes / devices via intermediate 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, inferred connections (i.e., inferred connections between one element and another) include direct and indirect connections between two items in the same manner as “connected to.”

[0210] Note that aspects of this disclosure may be described herein as processes depicted as schematic diagrams, flowcharts, flow charts, structural diagrams, or block diagrams. Although a flowchart may describe operations as a sequential process, many operations may be executed in parallel or simultaneously. Furthermore, the order of operations may be rearranged. Upon completion of an operation, the process terminates. A process may correspond to a method, function, program, subroutine, subroutine, etc. When a process corresponds to a function, its termination corresponds to the function returning to the calling function or the main function.

[0211] Various features of the present disclosure described herein can be implemented in different systems and apparatuses without departing from this disclosure. It should be noted that the foregoing aspects of this disclosure are merely illustrative and should not be construed as limiting the scope of the disclosure. The description of various aspects of this disclosure is intended to be illustrative and not to limit the scope of the claims. Thus, the 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.

[0212] In the foregoing description, 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. This description and drawings are illustrative rather than restrictive, and modifications are intended to be included within the scope of this disclosure. Therefore, the scope of this disclosure may be determined by the claims and their legal equivalents rather than solely by the described examples. For example, any components and / or elements recited in the device claims may be assembled in various arrangements or otherwise operably configured, and are therefore not limited to the specific configurations recited in the claims.

[0213] Furthermore, certain benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments; however, no benefit, advantage, solution to a problem, or any element that may lead to or make more apparent any particular benefit, advantage, or solution, should be construed as a key, essential, or necessary feature or component of any or all claims.

[0214] As used herein, the terms “comprising,” “having,” or any other variation thereof are intended to mean a non-exclusive inclusion, such that a process, method, article, composition, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed or inherent to such process, method, article, composition, or apparatus. Unless otherwise specifically stated, other combinations and / or modifications of the above-described structures, arrangements, applications, proportions, elements, materials, or components used in the practice of this invention may be altered or otherwise particularly adapted to specific environments, manufacturing specifications, design parameters, or other operational requirements without departing from its general principles.

[0215] Furthermore, unless otherwise stated, reference to an element in the singular is not intended to mean "one and only one," but rather "one or more." Unless otherwise expressly stated, the term "some" means one or more. All structural and functional equivalents of the elements throughout the various aspects described in this disclosure, as known or to be known by one of ordinary skill in the art, are expressly incorporated herein by reference and are intended to be covered by the claims. Moreover, regardless of whether the disclosure herein is expressly recited in the claims, it is not intended to be made available to the general public. Pursuant to 35 U.SC §112(f), no element of a claim should be construed as an element of the type "apparatus with additional function" unless the element is expressly stated using the phrase "apparatus for…" or, in a method claim, the element is stated using the phrase "step for…".

Claims

1. A non-Generation 3 Partner Program (NGP) interoperability node, configured to manage network connections to a fifth-generation core network via an untrusted NGP access network, the NGP interoperability node comprising: The first network interface is configured to communicate with the user equipment via the untrusted non-3rd generation partner program access network; The second network interface is configured to communicate with the access and mobility management function nodes in the fifth-generation core network; as well as The processing equipment is configured as follows: Processing requests for establishing secure connections to the fifth-generation core network, the requests being received from the user equipment via the untrusted non-third-generation partner program access network, and generating requests to the access and mobility management function nodes of the fifth-generation core network; The second network interface is used to provide authentication and secure connection establishment requests to the access and mobility management function nodes in the fifth-generation core network; Based on the response received from the access and mobility management function node in the fifth-generation core network in response to the authentication and secure connection establishment request, it is determined that the fifth-generation core network does not allow the establishment of a secure connection to the network through an untrusted non-third-generation partner program. The user equipment is provided with a response message, the response message including a fifth-generation mobility management reason value, the fifth-generation mobility management reason value indicating that the fifth-generation core network does not allow access to the fifth-generation core network through any untrusted non-third-generation partner program access network; as well as In response to providing the response message to the user equipment, a stop message is received from the user equipment, the stop message terminating the request to establish the secure connection to the fifth-generation core network through the untrusted non-third-generation partner program access network.

2. The non-third-generation partner program interoperability node according to claim 1, wherein the processing device is configured as: The request for establishing a secure connection to the fifth-generation core network is received from the user equipment via the first network interface through the untrusted non-third-generation partner program access network; The response to the request for authentication and subscription checks is received from the access and mobility management function node of the fifth-generation core network via the second network interface. as well as An Internet key exchange response message with a non-access stratum payload is generated and sent to the user equipment. The non-access stratum payload includes a fifth-generation mobility management reason value indicating that the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network.

3. The non-third-generation partner program interoperability node according to claim 2, wherein the processing device is further configured to: The fifth-generation core network receives a registration rejection message from its access and mobility management function node. The registration rejection message includes an indication that the fifth-generation core network does not allow secure access to its network via any untrusted non-3rd Generation Partner Program access network; and Generate the Internet key exchange response message with a payload, the payload including a message type indicating that the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network.

4. The non-Generation 3 Partner Program interoperability node of claim 2, wherein the processing device is further configured to generate the Internet key exchange response message by any of the following: Generate the Internet key exchange response message with a notification payload, the notification payload including a special notification message type indicating the reason for failure; or Generate the Internet key exchange response message having the notification payload, the notification payload including: The special notification message type instructs the fifth-generation core network not to establish or connect to the fifth-generation core network via any untrusted non-third-generation partner program access network.

5. The non-third-generation partner program interoperability node according to any of the preceding claims, wherein the processing device is further configured to: In response to receiving the stop message from the user equipment, a failure message is generated and provided to the user equipment; and Process the stop message received from the user equipment, wherein the stop message includes a fifth-generation stop message format having a message identifier field, and wherein the message identifier field includes a fifth-generation stop identifier.

6. An access and mobility management function node configured to process network connection requests from non-3rd generation partner program interoperability function nodes of a fifth-generation core network, the access and mobility management function node comprising: The network interface is configured to communicate with the non-3rd Generation Partner Program interoperability nodes and authentication and subscription functions in the fifth-generation core network; as well as The processing equipment is configured as follows: The authentication and secure connection establishment request is received from the non-3rd Generation Partnership Project (NGP) interoperability function node through the network interface. The authentication and secure connection establishment request is associated with a registration request to establish a secure connection with the fifth-generation core network. The registration request is received by the NGP interoperability function node from the user equipment through the untrusted NGP access network. In response to receiving the authentication and secure connection establishment request, a request for authentication and subscription checks is provided to the authentication and subscription function of the fifth-generation core network; In response to determining that the authentication and subscription check performed by the authentication and subscription function has failed, the response message is generated in response to the authentication and secure connection establishment request received from the non-3rd Generation Partner Program interoperability node by encapsulating in the response message an indication that the 5G core network does not allow access to the 5G core network through any untrusted non-3G Partner Program access network. as well as The response message is provided to the non-third-generation partner program interoperability function node.

7. The access and mobility management function node according to claim 6, wherein the processing device is further configured to: The registration rejection message is encapsulated in the response message, and the registration rejection message includes: The fifth-generation core network does not allow secure connections to the fifth-generation core network to be established through any untrusted non-third-generation partner program access network.

8. The access and mobility management function node according to claim 7, wherein the processing device is configured as: Generate an Extensible Authentication Protocol failure indication to be provided in the response message.

9. A user equipment, comprising: The network interface is configured to communicate with the non-3rd generation partner program interoperability nodes of the fifth generation core network through the untrusted non-3rd generation partner program access network; as well as The processing equipment is configured as follows: Generate a registration request for establishing a secure connection with the fifth-generation core network; The message is sent to the non-third generation partner program interoperability node of the fifth generation core network through the untrusted non-third generation partner program access network, the message including the request for establishing a secure connection with the fifth generation core network; In response to sending the message including the request, a response message is received from the non-3rd generation partner program interoperability node of the 5G core network, the response message including a 5G mobility management reason value, the 5G mobility management reason value indicating that the 5G core network does not allow the establishment of a secure connection with the 5G core network through any untrusted non-3rd generation partner program access network; Based on the response message, it is determined that the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network; If the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network, a stop message including a message identifier field is generated, the message identifier field including the fifth-generation stop identifier; Set the fifth-generation stop identifier in the message identifier field of the stop message to the fifth-generation stop; as well as The stop message is transmitted to the non-3rd Generation Partner Program (NGLP) interoperability node of the 5th generation core network to terminate the registration request for establishing the secure connection with the 5th generation core network via the untrusted NGLP access network.

10. The user equipment of claim 9, wherein the stop message indicates the end of the registration request established by the user equipment for a secure connection to the fifth-generation core network via the untrusted non-third-generation partner program access network.

11. The user equipment of claim 10, wherein the processing device is further configured to: The stop message is generated as an Extensible Authentication Protocol (ESP) response formatted message, which includes a message identifier field set to fifth-generation stop.

12. The user equipment of claim 11, wherein the processing device is further configured to: Processing Scalable Authentication Protocol failure messages from the non-Generation 3 Partner Program interoperability nodes; and Perform the secure association deletion procedure.

13. A method for managing network connections to a fifth-generation core network via an untrusted non-third-generation partner program access network, the method comprising: The request for establishing a secure connection to the fifth-generation core network from a user equipment is processed via a non-3rd Generation Partnership Project (NGP) interoperability function node. The request is received via the network interface between the NGP interoperability function node and the access and mobility management function node in the fifth-generation core network. The network interface is used to provide authentication and secure connection establishment requests to the access and mobility management function nodes in the fifth-generation core network. Based on the response received from the access and mobility management function node in the fifth-generation core network in response to the authentication and secure connection establishment request, it is determined that the fifth-generation core network does not allow secure connection establishment through any untrusted non-third-generation partner program access network. The response message is provided to the user equipment, the response message including the indication that the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network; and In response to providing the response message to the user equipment, a stop message is received from the user equipment, the stop message terminating the request to establish a secure connection to the fifth-generation core network.

14. The method of claim 13, further comprising: The request for establishing a secure connection to the fifth-generation core network is received from the user equipment via the first network interface through the untrusted non-third-generation partner program access network; The response to the request for authentication and subscription checks is received from the access and mobility management function node of the fifth-generation core network via the second network interface. as well as An Internet key exchange response message with a non-access stratum payload is generated and sent to the user equipment. The non-access stratum payload includes a fifth-generation mobility management reason value indicating that the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network.

15. The method of claim 14, further comprising: The fifth-generation core network receives a response encapsulated with a registration rejection message from the access and mobility management function node. The registration rejection message includes an indication that the fifth-generation core network does not allow the establishment of a secure connection to the fifth-generation core network via any untrusted non-third-generation partner program access network. Generate the Internet key exchange response message with a payload, the payload including a message type indicating that the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network.

16. The method of claim 14, wherein generating the Internet key exchange response message further comprises: Generate the Internet key exchange response message with a notification payload, the notification payload including a special notification message type indicating the reason for failure; or Generate the Internet key exchange response message with the notification payload, the notification payload including: the special notification message type indicating that the fifth-generation core network does not allow secure connections to the fifth-generation core network to be established through any untrusted non-third-generation partner program access network.

17. The method according to any one of claims 13-16, further comprising: In response to receiving the stop message from the user equipment, a failure message is generated for the user equipment, and the failure message is provided to the user equipment; as well as Process the stop message received from the user equipment, wherein the stop message includes a fifth-generation stop message format having a message identifier field, and wherein the message identifier field includes a fifth-generation stop identifier.

18. A method for managing network connections to a fifth-generation core network via an untrusted non-third-generation partner program access network, the method comprising: At the access and mobility management function node of the fifth-generation core network, an authentication and secure connection establishment request is received from the non-third-generation partner program interoperability function node of the fifth-generation core network through a network interface. The authentication and secure connection establishment request is associated with a registration request to establish a secure connection with the fifth-generation core network. The registration request is received by the non-third-generation partner program interoperability function node from the user equipment through the untrusted non-third-generation partner program access network. In response to receiving the authentication and secure connection establishment request, a request for authentication and subscription checks is provided to the authentication and subscription function of the fifth-generation core network; In response to determining that the authentication and subscription check performed by the authentication and subscription function has failed, the response message is generated in response to the authentication and secure connection establishment request received from the non-3rd Generation Partner Program interoperability node by encapsulating in the response message an indication that the 5th Generation Core Network does not allow the establishment of a secure connection with the 5th Generation Core Network through any untrusted non-3rd Generation Partner Program access network. as well as The response message is provided to the non-third-generation partner program interoperability function node.

19. The method of claim 18, further comprising: The response message encapsulates a registration rejection message, which includes an indication that the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network.

20. The method of claim 19, further comprising: Generate the Extensible Authentication Protocol failure indication in the response message.

21. A method for managing network connections to a fifth-generation core network via an untrusted non-third-generation partner program access network, the method comprising: Generate a registration request at the user equipment for establishing a secure connection to the fifth-generation core network; The user equipment sends the registration request to the non-third-generation partner program interoperability node of the fifth-generation core network through the untrusted non-third-generation partner program access network. At the user equipment, in response to sending the registration request, a response message is received from the non-3rd generation partner program interoperability function node of the 5G core network. The response message includes a 5G mobility management reason value, which indicates that the 5G core network does not allow the establishment of a secure connection with the 5G core network through any untrusted non-3rd generation partner program access network. The response message indicates that the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network; After determining that the fifth-generation core network does not allow the establishment of a secure connection with the fifth-generation core network through any untrusted non-third-generation partner program access network, a stop message is generated, the stop message including a message identifier field, the message identifier field including a fifth-generation stop identifier; Set the fifth-generation stop identifier in the message identifier field of the stop message to the fifth-generation stop; as well as The stop message is transmitted from the user equipment to the non-3rd generation partner program interoperability node of the fifth generation core network to terminate the registration request for establishing the secure connection with the fifth generation core network via the untrusted non-3rd generation partner program access network.

22. The method of claim 21, wherein the stop message indicates to the non-3rd Generation Partner Program (NDP) interoperability node that the user equipment is terminating the registration request for establishing a secure connection to the fifth-generation core network via the untrusted NDP access network.

23. The method of claim 22, further comprising: The stop message is generated as an Extensible Authentication Protocol (ESP) response formatted message, which includes a message identifier field set to fifth-generation stop.

24. The method of claim 23, further comprising: Process the Scalable Authentication Protocol failure message from the non-Generation 3 Partner Program interoperability node; as well as Perform the secure association deletion procedure.

Images