Notification in EAP procedure

CN115428495BActive Publication Date: 2026-10-23LENOVO (SINGAPORE) PTE LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202080099385.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-04-06
Publication Date
2026-10-23
Estimated Expiration
2040-04-06

Smart Images

  • Figure CN115428495B_ABST
    Figure CN115428495B_ABST
Patent Text Reader

Abstract

Apparatuses, methods, and systems are disclosed for supporting a notification procedure during 5G registration over a non-3GPP access network. One apparatus includes a transceiver that communicates with a mobile communication network ("MCN") via a trusted non-3GPP access network ("TNAN"), and a processor that receives a message from an access gateway in the TNAN to start an EAP session. Here, the EAP session facilitates establishing a NAS signaling connection between the apparatus and the MCN and encapsulating NAS messages exchanged between the apparatus and an AMF in the MCN. The processor receives an EAP notification request from the access gateway before the EAP session is completed. Here, the EAP notification request includes at least one access parameter. The processor sends an EAP notification response and completes the EAP session.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The topics disclosed in this article generally relate to supporting the notification process during 5G registration when accessing networks via non-3GPP networks. Background Technology

[0002] The following abbreviations and acronyms are defined herein, and at least some of them are referenced in the following description.

[0003] The following technologies are involved: Third Generation Partnership Project (“3GPP”), Fifth Generation Core (“5GC”), Access and Mobility Management Function (“AMF”), Access Point Name (“APN”), Access Layer (“AS”), Access Network Information (“ANI”), Application Programming Interface (“API”), Data Network Name (“DNN”), Downlink (“DL”), Enhanced Mobile Broadband (“eMBB”), Evolved Node B (“eNB”), Evolved Packet Core (“EPC”), and Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”). Home Subscriber Server (“HSS”), IP Multimedia Subsystem (“IMS”, also known as “IP Multimedia Core Network Subsystem”), Internet Protocol (“IP”), Long Term Evolution (“LTE”), LTE-Advanced (“LTE-A”), Media Access Control (“MAC”), Mobile Network Operator (“MNO”), Mobility Management Entity (“MME”), Non-Access Stratum (“NAS”), Narrowband (“NB”), Network Functions (“NF”), Network Access Identifier (“NAI”), Next Generation (e.g., 5G) Node B ( The network includes “gNB”, Next Generation Radio Access Network (“NG-RAN”), New Radio (“NR”), Policy Control Function (“PCF”), Packet Data Network (“PDN”), Packet Data Unit (“PDU”), PDN Gateway (“PGW”), Public Land Mobile Network (“PLMN”), Quality of Service (“QoS”), Radio Access Network (“RAN”), Radio Access Technology (“RAT”), Radio Resource Control (“RRC”), Receive (“Rx”), Single Network Slice Selection Auxiliary Information (“S-NSSAI”), Serving Gateway (“SGW”), Session Management Function (“SMF”), Transmission Control Protocol (“TCP”), Transmit (“Tx”), Unified Data Management (“UDM”), User Entity / Equipment (Mobile Terminal) (“UE”), Uplink (“UL”), User Plane (“UP”), Universal Mobile Telecommunications System (“UMTS”), User Datagram Protocol (“UDP”), User Location Information (“ULI”), Wireless Local Area Network (“WLAN”), and Global Microwave Access Interoperability (“WiMAX”).

[0004] In some embodiments, a UE supporting the 5G NAS protocol can register with the 5G core ("5GC") network via a trusted non-3GPP access network ("TNAN"). The registration process assumes that the AMF initiates a Security Mode Control ("SMC") exchange with the UE and provides the TNGF IP address to the UE within the context of this exchange. Note that after the UE has successfully connected to the trusted non-3GPP access network and has obtained IP configuration, the TNGF IP address is required in the UE to establish a secure IP connection (also known as an NWt connection) with the TNGF. Summary of the Invention

[0005] Methods for supporting the notification process during 5G registration via a non-3GPP network are disclosed. Apparatus and systems also perform the functions of these methods.

[0006] One method of the TNGF for supporting the notification process during 5G registration via a non-3GPP access network includes initiating an EAP session with the UE. Here, the EAP session facilitates the establishment of a NAS signaling connection between the UE and the mobile communication network. The EAP session is used to encapsulate NAS messages exchanged between the UE and the AMF in the mobile communication network. The method includes receiving a request from the AMF. Here, the request indicates that the EAP session is about to complete. The method includes determining whether the UE will receive at least one access parameter before the EAP session completes. The method includes sending an EAP notification request to the UE in response to determining that the UE will receive at least one access parameter before the EAP session completes. Here, the EAP notification request includes at least one access parameter. The method includes receiving an EAP notification response from the UE. The method includes completing (i.e., ending or closing) the EAP session.

[0007] One method for a UE to support a notification process during 5G registration via a non-3GPP access network includes receiving a message initiating an EAP session with an access gateway in a TNAN. Here, the EAP session facilitates the establishment of a NAS signaling connection between the UE and the mobile network. The EAP session is used to encapsulate NAS messages exchanged between the UE and the AMF in the mobile network. The method includes receiving an EAP notification request from the access gateway before the EAP session concludes. Here, the EAP notification request includes at least one access parameter. The method includes sending an EAP notification response. The method includes completing (i.e., ending or closing) the EAP session. Attached Figure Description

[0008] A more detailed description of the embodiments briefly described above will be presented with reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only a few embodiments and are therefore not intended to limit the scope. The embodiments will be described and explained using additional specificity and detail through the use of the drawings, in which:

[0009] Figure 1 This is a diagram illustrating one embodiment of a wireless communication system for supporting a notification process during 5G registration via a non-3GPP access network.

[0010] Figure 2A This is a signal flow diagram illustrating one embodiment of the notification process during 5G registration via a non-3GPP access network;

[0011] Figure 2B yes Figure 2A The continuation of the process described in the text;

[0012] Figure 2C yes Figure 2B The continuation of the process described in the text;

[0013] Figure 3 This is a signal flow diagram illustrating another embodiment of the notification process during 5G registration via a non-3GPP access network;

[0014] Figure 4 This is a block diagram illustrating one embodiment of a user equipment device for supporting a notification process during 5G registration via a non-3GPP network.

[0015] Figure 5 This is a block diagram illustrating one embodiment of a network device apparatus for supporting a notification process during 5G registration via a non-3GPP network.

[0016] Figure 6 This is a flowchart illustrating an embodiment of a first method for supporting the notification process during 5G registration via a non-3GPP access network; and

[0017] Figure 7 This is a flowchart illustrating an embodiment of a second method for supporting the notification process during 5G registration via a non-3GPP access network. Detailed Implementation

[0018] As those skilled in the art will understand, aspects of the embodiments can be embodied as a system, apparatus, method, or program product. Therefore, embodiments can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects.

[0019] For example, the disclosed embodiments can be implemented as hardware circuitry including custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, procedures, or functions.

[0020] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices stored in machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In one embodiment, the storage device employs only signals for accessing the code.

[0021] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof.

[0022] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more cables, portable computer disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable optical disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium capable of containing or storing programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0023] References to "an embodiment," "embodiment," or similar language in this specification mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. Therefore, unless expressly stated otherwise, throughout this specification, the phrases "in an embodiment," "in an embodiment," and similar language may, but not necessarily all, refer to the same embodiment, but rather mean "one or more, but not all, embodiments." Unless expressly stated otherwise, the terms "comprising," "including," "having," and variations thereof mean "including, but not limited to,". Unless expressly stated otherwise, the list of enumerated items does not imply that any or all items are mutually exclusive. Unless expressly stated otherwise, the terms "a," "an," and "the" also mean "one or more".

[0024] As used herein, a list containing the conjunction “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one or more of” includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one of” includes one and only one of any single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C and excludes combinations of A, B, and C. As used herein, “selected from the group consisting of A, B, and C” includes one and only one of A, B, or C and excludes combinations of A, B, and C. As used in this article, “selecting members of groups consisting of A, B, and C and their combinations” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B, and C.

[0025] Furthermore, the features, structures, or characteristics of the described embodiments can be combined in any suitable manner. In the following description, numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more specific details, or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0026] The following description of aspects of embodiments is based on schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to embodiments. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to generate machinery, such that instructions executable via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / actions specified in the schematic flowcharts and / or schematic block diagrams.

[0027] The code can also be stored in a storage device that can instruct a computer, other programmable data processing apparatus or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of art including instructions that implement the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0028] The code may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the code executing on the computer or other programmable apparatus provides a process for implementing the function / action specified in the schematic flowchart and / or schematic block diagram.

[0029] The schematic flowcharts and / or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the schematic flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function.

[0030] It should also be noted that in some alternative embodiments, the functions annotated in the boxes may occur in a different order than those annotated in the figures. For example, two boxes shown successively may actually be performed substantially simultaneously, or these boxes may sometimes be performed in reverse order, depending on the functionality involved. Other steps and methods that are functionally, logically, or effectively equivalent to one or more boxes or portions thereof in the illustrated figures are conceivable.

[0031] The description of the elements in each figure can be referenced to the elements in the preceding figures. Throughout all figures, the same reference numerals refer to the same elements, including alternative embodiments of the same elements.

[0032] Methods, apparatus, and systems for supporting the notification process during 5G registration via non-3GPP access networks are disclosed. As specified in the current 3GPP 5G specification, a UE can connect to the 5G core in a PLMN via several types of so-called trusted non-3GPP access networks, all of which provide connectivity between the UE and the 5G system via a trusted non-3GPP gateway function (“TNGF”). Note that the TNGF can be deployed as part of the access network, thus forming a trusted non-3GPP access network (“TNAN”). These access networks are considered trusted from the perspective of the 5G core network because they support secure signaling interfaces and interoperability with the 5G core network. Such networks are considered non-3GPP access networks because they are based on technologies not specified by 3GPP, such as Wi-Fi access networks and wired access networks.

[0033] The current 3GPP specification defines how a UE (referred to as "UE" in this document) supporting the 5G-NAS protocol can register with the 5G Core (5GC) network via a trusted non-3GPP access network. The entire process is described in TS 23.502, Clause 4.12a.2.2, "Registration procedure for trusted non-3GPP access". This procedure assumes that the AMF initiates a Security Mode Control ("SMC") exchange with the UE (see steps 9a-9d) and provides the TNGF IP address to the UE within the context of this exchange (in step 9b). Note that after the UE has successfully connected to the trusted non-3GPP access network and has obtained IP configuration, the TNGF IP address is required in the UE to establish an NWt connection with the TNGF (in step 13).

[0034] However, providing the TNGF IP address to the UE during SMC switching presents the following problems:

[0035] First, in some scenarios, the AMF does not need to initiate SMC exchange with the UE during the registration process via trusted non-3GPP access. For example, if the UE has already registered with the 5GC via NG-RAN before accessing TNAN, and therefore a 5G-NAS security context has already been created in the UE and its serving AMF, then SMC exchange is not required. The 5G-NAS security context contains information such as cryptographic keys and algorithms, which are used to cryptographically protect NAS messages exchanged between the UE and the AMF.

[0036] In the above scenario, the registration request message sent by the UE via TNAN uses the existing 5G-NAS security context in the UE for integrity protection, and the AMF uses its own 5G-NAS security context to verify its integrity. If the verification is successful, this indicates that the UE has a valid 5G-NAS security context, and the AMF can skip the authentication process and SMC exchange for this UE.

[0037] It is also clear that since the UE has a valid (and not expired) 5G-NAS security context, the AMF does not need to initiate an SMC exchange. After verifying the integrity of the received registration request message, the AMF can immediately derive the TNGF key (as specified in TS 33.501) and provide this key to the TNGF. In this scenario, the UE does not receive the TNGF IP address during the EAP-5G session, and therefore, it cannot establish an NWt connection after the EAP-5G session is completed. As a result, the 5G registration process via trusted non-3GPP access will fail. Note that the TNGF cannot send the TNGF IP address to the UE in the EAP-success packet because, according to EAP RFC 3748, this packet can exclude parameters.

[0038] Secondly, even in other scenarios where the AMF decides to initiate an SMC exchange during 5G registration via trusted non-3GPP access, providing the TNGF IP address to the UE during the SMC exchange (as currently specified in TS 23.502) is not feasible because the TNGF is unaware of when the AMF will send the SMC command to the UE. This is because the TNGF transparently relays NAS messages between the UE and the AMF without decoding or processing these NAS messages. Furthermore, providing the TNGF IP address to the UE at another opportunity (e.g., when it sends the first EAP / 5G-NAS message to the UE) risks exposing the TNGF IP address to the UE before authentication. Therefore, any unauthenticated and / or malicious UE could receive this IP address and initiate an attack targeting the TNGF.

[0039] This document discloses a process that enables the TNGF to send its IP address to the UE only after it receives an indication from the AMF that the EAP-5G session should be successfully completed. More specifically, this disclosure extends the EAP-5G protocol operating between the UE and TNGF during 5G registration via trusted non-3GPP access, enabling the TNGF to send "access parameters" (such as the TNGF IP address) to the UE after receiving an indication from the AMF that the EAP-5G session should be successfully completed. Access parameters are any type of parameter (including the TNGF IP address) that the TNGF wishes to provide to the UE before the completion of the EAP-5G session and can be sent to the UE with or without password protection. After sending the access parameters to the UE, the TNGF sends an EAP-success packet to the UE to signal the successful completion of the EAP-5G session. Access parameters are provided to the UE when the AMF indicates to the TNGF that the EAP-5G session should be successfully completed. However, access parameters can also be provided to the UE as a failure result indication when the AMF indicates to the TNGF that the EAP-5G session should not have been successfully completed.

[0040] Figure 1 This disclosure describes a wireless communication system 100 for supporting a notification process during 5G registration via a non-3GPP access network, according to embodiments of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105 in a PLMN, at least one trusted non-3GPP access network (“TNAN”) 120, and a mobile core network 140. The TNAN 120 may consist of at least one base station unit 121. The remote unit 105 may communicate with the TNAN 120 using a non-3GPP communication link, depending on the radio access technology deployed by the TNAN 120. Although Figure 1 A specific number of remote units 105, base station units 110, TNAN 120, and mobile core network 140 are depicted, but those skilled in the art will recognize that any number of remote units 105, base station units 110, TNAN 120, and mobile core network 140 can be included in the wireless communication system 100.

[0041] In one implementation, the wireless communication system 100 conforms to the 5G system specified in the 3GPP specification. However, more generally, the wireless communication system 100 may implement other open or proprietary communication networks, such as LTE / EPC (referred to as 4G) or WiMAX, and other networks. This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0042] In one embodiment, remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., internet-connected TVs), smart appliances (e.g., internet-connected appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, remote unit 105 may include wearable devices such as smartwatches, fitness bands, optical head-mounted displays, etc. Furthermore, remote unit 105 may be referred to as a UE, subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit (“WTRU”), device, or other terms used in the art.

[0043] Remote unit 105 can communicate directly with one or more base station units 121 in TNAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Alternatively, the UL and DL communication signals can be carried on communication link 113. Note that TNAN 120 is an intermediate network providing remote unit 105 with access to the mobile core network 140.

[0044] Base station unit 121 can serve multiple remote units 105 within a service area, such as a cell or cell sector, via communication link 113. Base station unit 121 can communicate directly with one or more remote units 105 via communication signals. Typically, base station unit 121 transmits DL communication signals to serve remote units 105 in the time, frequency, and / or spatial domains. Furthermore, DL communication signals can be carried on communication link 113. Communication link 113 can be any suitable carrier in the licensed or unlicensed radio spectrum. Communication link 113 facilitates communication between one or more remote units 105 and / or one or more base station units 121.

[0045] As described above, TNAN 120 supports secure signaling interfaces and interoperability with the 5G core network. TNAN includes at least one TNGF; in the depicted embodiments, TNAN 120 includes a first TNGF 125 and a second TNGF 127. In some embodiments, TNAN 120 supports Tn interfaces between TGNFs within TNAN 120.

[0046] Base station unit 121 may be distributed across a geographical area. In some embodiments, base station unit 121 may also be referred to as a Trusted Non-3GPP Access Point (“TNAP”), access terminal, access point, base station, relay node, device, or any other term used in the art. Base station unit 121 is typically part of a radio access network (“RAN”), such as TNAN 120, which may include one or more controllers communicatively coupled to one or more corresponding base station units 121. These and other elements of the radio access network are not illustrated but are generally well known to those skilled in the art. Base station unit 121 is connected to mobile core network 140 via TNAN 120.

[0047] In some embodiments, remote unit 105 communicates with an application server (or other communication peer) via a network connection to mobile core network 140. For example, an application in remote unit 105 (e.g., a web browser, media client, telephone / VoIP application) can trigger remote unit 105 to establish a PDU session (or other data connection) with mobile core network 140 using TNAN 120. To establish a PDU session, remote unit 105 must register with mobile core network.

[0048] In one embodiment, the mobile core network 140 is a 5G core (“5GC”) or an evolved packet core (“EPC”), which may be coupled to data networks such as the Internet and private data networks, as well as other data networks. The remote unit 105 may have a subscription or other account with respect to the mobile core network 140. This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0049] The mobile core network 140 includes several network functions (“NFs”). As depicted, the mobile core network 140 includes at least one user plane function (“UPF”) 141. The mobile core network 140 also includes multiple control plane functions, including but not limited to access and mobility management functions (“AMF”) 143, session management functions (“SMF”) 145, and policy control functions (“PCF”) 147. In some embodiments, the mobile core network 140 may also include a unified data management function (“UDM”) 149, an authentication server function (“AUSF”), a network repository function (“NRF”) (used by various NFs to discover and communicate with each other via APIs), or other NFs defined for the 5G core network.

[0050] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. Each network slice includes a set of CP and UP network functions, wherein each network slice is optimized for a specific type of service or service category. For ease of illustration, in Figure 1 Different network slices are not shown, but their support is assumed. In one example, each network slice includes SMF and UPF, but the individual network slices share AMF 143, PCF 147, and UDM. In another example, each network slice includes AMF, SMF, and UPF. Although in Figure 1 A specific number and type of network functions are described, but those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140.

[0051] When remote unit 105 attempts to register with mobile core network 140 via TNAN 120, TNGF 125 can initiate an EAP-5G procedure for sending 5G-NAS messages between remote unit 105 and mobile core network 140 (e.g., AMF 143). As discussed above, the TNGF's network address (e.g., IP address) is required to establish an NWt connection. To ensure that remote unit 105 receives the TNGF address before the EAP procedure ends, and to protect the TNGF address from exposure to unauthorized entities, TNGF 123 only sends the TNGF IP address to remote unit 105 within the access parameters after receiving an indication from AMF 143 that the EAP-5G procedure can be successfully completed, as referenced. Figure 2A-2C and Figure 3 Further detailed description.

[0052] Figure 2A-2C This disclosure describes a process 200 for supporting a notification process during 5G registration via a non-3GPP access network, according to embodiments of the present disclosure. Process 200 relates to a UE 205 (e.g., an embodiment of remote unit 105), a TNAN 210 (e.g., an embodiment of TNAN 120), a TNGF 213 (e.g., an embodiment of TNGF 123), an NG-RAN 215, and an AMF 221 (e.g., an embodiment of AMF 143) in a 5G core network 220 (e.g., an embodiment of mobile core network 140). Process 200 details the signaling flow of a modified registration process for a scenario where the UE 205 initiates registration with the 5G core network 220 via a trusted non-3GPP access network. Similar steps occur in other scenarios, such as when the UE 205 attempts to perform a service request instead of a registration request.

[0053] refer to Figure 2A Process 200 begins at step 0 as UE 205 registers with the 5G core network 220 via 3GPP access, for example, via NG-RAN 215 (see message passing 225). During this first registration, a 5G-NAS security context 207 is created in UE 205 and in the AMF 221 serving UE 205. This security context 207 contains cryptographic keys and algorithms that will be used to protect NAS messages exchanged between UE 205 and AMF 221.

[0054] At step 1, UE 205 decides to connect to the same 5G core network 220 via an available non-3GPP access network. UE 205 discovers a non-3GPP access network that supports 5G connectivity (or “trusted” connectivity) to this 5GC, and therefore selects this “trusted” non-3GPP access network (here, TNAN 210) and initiates a registration process for the trusted non-3GPP access, for example, as specified in Clause 4.12a.2.2 of 3GPP TS 23.502 as amended herein. In the most typical case, the trusted non-3GPP access network is a WLAN access network conforming to the IEEE 802.11 specification. First, UE 205 establishes a Layer 2 (L2) connection with the trusted non-3GPP access point (TNAP) 211 in the trusted non-3GPP access network (see message 227). In the case of an IEEE 802.11 WLAN, this L2 connection corresponds to an 802.11 association.

[0055] In steps 2-3, the EAP procedure is initiated. The EAP message is encapsulated into a Layer 2 packet, for example, an IEEE 802.11 / 802.1x packet. TNAP 211 requests the UE identity, and UE 205 sends a Network Access Identifier (“NAI”) in response (see Message Passing 229, 231). The NAI provided by UE 205 indicates that UE 205 is requesting “5G connectivity” to a specific PLMN; for example, NAI = “…”.<any_username> @nai.5gc.mnc <mnc>.mcc <mcc>".3gppnetwork.org". This NAI triggers TNAP 211 to select TNGF (i.e., TNGF 213) and sends an AAA request to the selected TNGF 213 (see box 233, messaging 235). Between TNAP 211 and TNGF 213, each EAP packet is encapsulated into an AAA message.

[0056] Note that multiple TNGFs can be deployed in a TNAN 120, all providing access to the 5GC within the same PLMN. These TNGFs can support different tracking regions and network slices, or they can support the same tracking region and network slice. Figure 2A-2C In the example embodiment shown, it is assumed that the selected TNGF 213 can support network slicing permitted by the 5G core network 220 for UE 205, therefore, it is not necessary to relocate this TNGF to another TNGF. However, in other embodiments, TNGF relocation may occur as part of process 200, which is discussed in more detail below.

[0057] At step 4, after receiving the AAA request, TNGF 213 responds with an AAA response message, which includes an EAP-Request / 5G-Start packet (see Message Passing 237) instructing UE 205 that the EAP-5G session has started and that UE 205 is able to begin sending NAS messages encapsulated within EAP-5G packets.

[0058] At step 5, UE 205 sends an EAP-Response / 5G-NAS packet containing access network parameters (AN-Params) and a registration request message (or service request message) (see message passing 239). Note that the AN-Params sent by UE 205 are different from the access parameters sent by TNGF and including, for example, the TNGF IP address discussed above.

[0059] Here, AN-Params include the UE identity (e.g., SUCI or 5G-GUTI), the selected PLMN identity, and the establishment reason. Optionally, if UE 205 is not operating under the default NSSAI included mode D (as specified in 3GPP TS23.502), a requested NSSAI may also be included. The establishment reason provides the reason for requesting a signaling connection with the 5G core network 220. TNAP 210 forwards the EAP-Response / 5G-NAS packet to TNGF 213 within the AAA request message.

[0060] Note that because UE 205 has already established 5G-NAS security context 207 (in step 0), the registration request message is protected for integrity by applying the cryptographic key and algorithm in 5G-NAS security context 207.

[0061] At step 6, TNGF 213 selects AMF 221 in the 5G core network 220 of the selected PLMN based on the received AN-Params and local policies, for example, as specified in Clause 6.3.5 of 3GPP TS 23.501 (see box 241). Then, TNGF 213 forwards the registration request (or service request) received from UE 205 to the selected AMF 221 within the N2 initial UE 205 message (see message passing 243). This message contains N2 parameters including the selected PLMN ID and the establishment reason.

[0062] exist Figure 2B Continuing on, at step 7, AMF 221 verifies the integrity of the received registration request and confirms that UE205 has the correct 5G NAS security context (see box 245). Therefore, AMF 221 decides to skip the authentication process and the security mode control process. Subsequently, AMF 221 sends an initial context establishment request to TNGF 213 to enable the completion of the EAP-5G session (see message passing 247). This message includes the TNGF key, which should be used to establish secure communication in TNAN 210.

[0063] In an alternative embodiment where the registration is to be relocated to another TNGF, the AMF 221 sends a TNGF relocation command (instead of an initial context establishment request) containing the TNGF key and the IP address of the other TNGF (i.e., the new TNGF to which the registration is to be relocated).

[0064] At step 8, because TNGF 213 receives the TNGF key, TNGF 213 determines that the EAP-5G session will successfully complete (see box 249). However, TNGF 213 also determines that UE 205 will receive access parameters, such as the IP address of TNGF 213 (TNGF address), before the EAP-5G session completes. Without the TNGF address, UE 205 cannot establish an NWt connection later (in... Figure 2C (In step 13) and therefore registration will fail.

[0065] Therefore, TNGF 213 sends an EAP-Request / 5G-Notification packet to UE 205 containing one or more access parameters and may also contain a result indication (e.g., success or failure) indicating whether the EAP-5G session was successful.

[0066] If necessary, one or more access parameters can be cryptographically protected by TNGF 213 using the received TNGF key and, for example, a predefined cryptographic algorithm (e.g., encryption or integrity protection). Cryptographic protection allows for the encryption of sensitive access parameters and prevents unauthorized or malicious users from obtaining these parameters, for example, by monitoring traffic on non-3GPP access air interfaces. Note that the EAP-Request / 5G-Notification packet is sent to UE 205 before establishing air interface security between UE 205 and TNAP 211 in step 11. Therefore, the access parameters in this EAP-Request / 5G-Notification packet can be monitored by unauthorized users if they are not protected.

[0067] Alternatively, instead of using predefined cryptographic algorithms to protect access parameters, UE 205 can indicate to TNGF 213 a set of supported cryptographic algorithms(s). For example, the EAP-Response / 5G-NAS packet in step 5a may include these algorithms. In such embodiments, TNGF 213 may select one of the supported algorithms and indicate the selected cryptographic algorithm to UE 205, for example, in the EAP-Request / 5G-Notification packet sent in step 8.

[0068] If AMF 221 decides to reject the registration request from UE 205 in the previous step (i.e., step 7), then (instead of the initial context establishment request) AMF 221 first sends a DL NAS transport message to TNGF 213 containing a registration rejection message that will be forwarded to UE 205, and then sends a UE context release command to TNGF 213, which will be an indication that the EAP-5G session should not have been successfully completed.

[0069] This will trigger TNGF 213 to send an EAP-Failure message to UE 205. However, before sending the EAP-Failure (in step 10), TNGF 213 may send an EAP-Request / 5G-Notification packet to UE 205 to provide access parameters explaining the reason for the failure and / or access parameters that can be used (e.g., when TNGF 213 becomes overloaded) to retry registration.

[0070] At step 9, UE 205 derives the TNGF key using the AMF key previously created during the authentication process (e.g., via 3GPP access), and verifies any received access parameters if they are cryptographically protected (see box 253). UE 205 informs TNGF 213 whether it successfully received the access parameters (see message passing 255). If UE 205 successfully verifies (i.e., decrypts) and accepts the received access parameters, UE 205 responds with an EAP-Response / 5G-Notification packet indicating success (i.e., with result = "success"). Note that if UE 205 fails to verify the received access parameters, UE 205 responds with an EAP-Response / 5G-Notification packet indicating failure (i.e., with result = "failure").

[0071] At step 10a, in response to the EAP-Response / 5G-Notification packet, TNGF 213 (e.g., from the TNGF key) derives the TNAP key, which will be used to establish air interface security with UE 205 (see box 257).

[0072] continue Figure 2C At step 10b, TNGF 213 sends an EAP-success packet to TNAP 211 within an AAA Accept message (see message passing 259). The AAA Accept includes a TNAP key (derived from the TNGF key), which should be used to establish air interface security with UE 205. At step 10c, TNAP 211 sends an EAP-success packet to UE 205 (i.e., encapsulated in a Layer 2 packet), which terminates the EAP-5G session initiated in step 4.

[0073] At step 11, using the TNAP key (which is also derived by UE 205 from the TNGF key, see box 261), UE 205 and TNAP 211 establish air interface security (see message 263). In the case of IEEE 802.11 WLAN, this corresponds to a four-way handshake exchange. Subsequently, at step 12, UE 205 obtains IP configuration information including IP addresses (see message 265).

[0074] At step 13, UE 205 begins establishing an NWt connection using the TNGF address received in step 8c (i.e., as part of the access parameters sent by the TNGF, see box 267). First, at step 13a, UE 205 initiates an IKE procedure toward TNGF 213 by starting an IKE initial exchange according to RFC 7296. In steps 8b and 8c, an IKE_AUTH request / response message is exchanged using an AUTH payload derived from the public TNGF key created in UE 205 and AMF 221. Note that the UE 205 identity (5G-GUTI) received by TNGF 213 in step 13b (within the IDi payload of the IKE signaling) indicates to TNGF 213 which TNGF key should be used to authenticate UE 205.

[0075] Following successful authentication in step 13c, a secure IPsec SA is created between UE 205 and TNGF 213. In step 13d, UE 205 establishes a TCP connection with TNGF 213 (as specified in TS 23.502), thus completing the establishment of an NWT connection between UE 205 and TNGF 213.

[0076] At step 14, after the NWt connection between UE 205 and TNGF 213 is established, TNGF 213 responds to AMF 221 with an Initial Context Establishment Response message, indicating that a secure connection with UE 205 has been established (see message 269). At step 15, AMF 221 sends a DLNAS transmission to TNGF 213 containing a registration acceptance message for UE 205. This message is forwarded to UE 205 within the established NWt connection (see message 271).

[0077] Following the above signaling flow, UE 205 completes its registration with the 5G core network 220 via trusted non-3GPP access, and the established NWt connection is used to transmit further NAS messages between UE 205 and AMF 221.

[0078] Procedure 200 is based on the assumption that UE 205 has already registered with the 5G core network 220 via 3GPP access (i.e., NG-RAN 215) and has established a 5G NAS security context 207, which is applied when UE 205 attempts to register with the 5G core network 220 via non-3GPP access (i.e., TNAN 210). If UE 205 does not have a 5G NAS security context 207 when attempting to register via non-3GPP access, the registration procedure is modified as discussed below.

[0079] Figure 3 This document describes a process 300 for supporting a notification process during 5G registration via a non-3GPP access network, according to embodiments of the present disclosure. Process 300 relates to UE 205, TNGF 213 in TNAN 210, and AMF 221 in the 5G core network 220. Process 300 details a signaling flow for a modified registration process in a scenario where UE 205 initiates registration with the 5G core network 220 via a trusted non-3GPP access network but a 5G-NAS security context has not yet been established at the time of registration initiation. Similar steps occur in other scenarios, such as when UE 205 attempts to perform a service request instead of a registration request. Note that TNGF 213 does not send access parameters to UE 205 until it receives an indication (TNGF key) from AMF 221 that the EAP-5G session can be successfully completed.

[0080] refer to Figure 3 Process 300 begins as UE 205 connects to TNAP 211, initiates an EAP session (i.e., an EAP-5G session) with TNGF 213, and initiates a registration process with the 5G core network 220 (see box 301). Steps 1-6 of process 300 are referenced above. Figure 2A The discussion process is the same as steps 1-6 of 200.

[0081] At step B1, UE 205 and AMF 221 perform mutual authentication and key negotiation procedures (see message 303). In steps B2-B7, AMF 221 initiates a Security Mode Control ("SMC") exchange with UE 205, which creates a 5G NAS security context between UE 205 and AMF 221 (see message 305).

[0082] At step 7a, AMF 221 determines that the authentication and security mode control process has been successfully completed (see box 307). Subsequently, at step 7b, AMF 221 sends an initial context establishment request to TNGF 213 to enable the completion of the EAP-5G session (see message passing 309). This message includes the TNGF key, which should be used to establish secure communication between the UE and TNAN 210. Instead of the initial context establishment request, as discussed above, AMF 221 may send a TNGF relocation command, which includes the TNGF key and the IP address to which the new TNGF is registered.

[0083] At step 8a, because TNGF 213 receives the TNGF key, TNGF 213 determines that the EAP-5G session will be successfully completed and that UE 205 will receive access parameters before the completion of the EAP-5G session (see box 311). As above, the receipt of the TNGF key in step 7b triggers TNGF 213 to send access parameters. Note that in procedure 300, TNGF 213 does not send access parameters to UE 205 until it receives an indication from AMF 221 that the EAP-5G session can be successfully completed (i.e., the TNGF key).

[0084] Therefore, in steps 8b and 8c, TNGF 213 sends an EAP-Request / 5G-Notification packet to UE 205 containing one or more access parameters and may also include a result indication (e.g., success or failure) indicating whether the EAP-5G session was successful. Again, one or more access parameters may be cryptographically protected by TNGF 213, as referenced above. Figure 2B The subject of discussion.

[0085] Process 300 ends as UE 205 verifies the received access parameters, completes the EAP-5G session, establishes an NWt connection with TNGF 213, and completes the NAS registration process with AMF 221 (see box 315). Steps 9-15 of process 300 are the same as above. Figure 2B and Figure 2C The discussion process is the same as steps 9-15 of 200.

[0086] If AMF 221 decides to reject the registration request from UE 205, then (instead of the initial context establishment request in step 7b) AMF 221 may first send a DLNAS transport message to TNGF 213 containing a registration rejection message to be forwarded to UE 205, and then send a UE context release command to TNGF 213, which would be an indication that the EAP-5G session should not have been successfully completed, thereby triggering TNGF 213 to send an EAP-failure message to UE 205. However, before sending the EAP-failure (in step 10), TNGF 213 may send an EAP-request / 5G-notification packet to UE 205 to provide access parameters explaining the reason for the failure and / or access parameters that can be used to retry registration.

[0087] Figure 4 This description depicts one embodiment of a user equipment device 400, which can be used to support the notification process during 5G registration via a non-3GPP access network, according to embodiments of the present disclosure. The user equipment device 400 may be an embodiment of a remote unit 105 and / or a UE 205. Furthermore, the user equipment device 400 may include a processor 405, a memory 410, an input device 415, an output device 420, and a transceiver 425. In some embodiments, the input device 415 and the output device 420 are combined into a single device, such as a touchscreen. In some embodiments, the user equipment device 400 does not include any input device 415 and / or output device 420.

[0088] As depicted, transceiver 425 includes at least one transmitter 430 and at least one receiver 435. Here, transceiver 425 communicates with a mobile core network (e.g., 4GC) via an access network. Additionally, transceiver 425 may support at least one network interface 440. Here, at least one network interface 440 facilitates communication with the TNGF (e.g., using the "NWt" interface). Furthermore, at least one network interface 440 may include interfaces for communication with the AMF, SMF, and / or UPF.

[0089] In one embodiment, processor 405 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 405 may be a microcontroller, microprocessor, central processing unit ("CPU"), graphics processing unit ("GPU"), auxiliary processing unit, field-programmable gate array ("FPGA"), or similar programmable controller. In some embodiments, processor 405 executes instructions stored in memory 410 to perform the methods and routines described herein. Processor 405 is communicatively coupled to memory 410, input device 415, output device 420, and transceiver 425.

[0090] In various embodiments, processor 405 controls user equipment device 400 to implement the UE behavior described above. In some embodiments, processor 405 receives a message initiating an EAP session (i.e., an EAP-5G session) with an access gateway (i.e., TNGF) in a TNAN (see [link to relevant documentation]). Figure 2A (Message 4b). Here, the EAP session facilitates the establishment of a NAS signaling connection between the user equipment device 400 and the mobile communication network, and wherein the EAP session is used to encapsulate NAS messages exchanged between the user equipment device 400 and the AMF in the mobile communication network. The processor 405 receives an EAP notification request from the access gateway before the EAP session is completed. Here, the EAP notification request includes at least one access parameter. The processor 405 sends an EAP notification response and completes (i.e., closes / ends) the EAP session.

[0091] In some embodiments, the processor 405 establishes a secure IP connection (e.g., an NWt connection) with the access gateway using at least one access parameter in response to the completion of an EAP session, wherein the secure IP connection is used to transmit NAS messages between the user equipment device 400 and the AMF after the EAP session is completed. In some embodiments, the NAS signaling connection is used to register the user equipment device 400 with the mobile communication network. In other embodiments, the NAS signaling connection may be used to carry service requests from the user equipment device 400 to the network.

[0092] In some embodiments, at least one access parameter includes at least one of the following: TNGF address, TNGF identity, UE identity of user equipment device 400, and selected cryptographic algorithm. In some embodiments, the access gateway is a first TNGF in TNAN, wherein the TNGF address includes one of the following: a first TNGF address of the first TNGF in TNAN and a second TNGF address of the second TNGF.

[0093] In some embodiments, access parameters are cryptographically protected (e.g., encrypted or integrity protected) using a TNGF key. For example, the TNGF key may be used with a predefined cryptographic algorithm to protect the access parameters. Alternatively, the TNGF key may be used with a cryptographic algorithm selected by the TNGF, as discussed below. In some embodiments, the EAP notification response indicates whether the user equipment device 400 has successfully received at least one access parameter.

[0094] In some embodiments, processor 405 sends a set of cryptographic algorithms supported by user equipment device 400 and receives a selected cryptographic algorithm, wherein the access gateway selects the selected cryptographic algorithm from the set of cryptographic algorithms. In such an embodiment, processor 405 uses the selected cryptographic algorithm and the TNGF key to verify (e.g., decrypt) access parameters.

[0095] In some embodiments, the selected cryptographic algorithm may be indicated in the EAP notification request. In some embodiments, the processor 405 may indicate successful acceptance of the access parameter in response to successful processing (e.g., verification and / or decryption) of at least one cryptographically protected access parameter.

[0096] In one embodiment, memory 410 is a computer-readable storage medium. In some embodiments, memory 410 includes volatile computer storage media. For example, memory 410 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 410 includes non-volatile computer storage media. For example, memory 410 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 410 includes both volatile and non-volatile computer storage media. In some embodiments, memory 410 stores data related to supporting the notification process during 5G registration via a non-3GPP access network, such as security keys, IP addresses, etc. In some embodiments, memory 410 also stores program code and related data, such as an operating system ("OS") or other controller algorithms operating on user equipment device 400, and one or more software applications.

[0097] In one embodiment, input device 415 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 415 may be integrated with output device 420, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 415 includes a touchscreen, allowing text to be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 415 includes two or more different devices, such as a keyboard and a touch panel.

[0098] In one embodiment, output device 420 may include any known electronically controllable display or display device. Output device 420 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 420 includes an electronic display capable of outputting visual data to a user. For example, output device 420 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 420 may include wearable displays, such as smartwatches, smart glasses, heads-up displays, etc. Furthermore, output device 420 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0099] In some embodiments, output device 420 includes one or more speakers for generating sound. For example, output device 420 may generate an auditory alarm or notification (e.g., a beep or ringtone). In some embodiments, output device 420 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 420 may be integrated with input device 415. For example, input device 415 and output device 420 may form a touchscreen or similar touch-sensitive display. In other embodiments, all or part of output device 420 may be located near input device 415.

[0100] As discussed above, transceiver 425 communicates with one or more network functions of a mobile communication network via one or more access networks. Transceiver 425 operates under the control of processor 405 to transmit and receive messages, data, and other signals. For example, processor 405 may selectively activate the transceiver (or a portion thereof) at specific times to send and receive messages.

[0101] Transceiver 425 may include one or more transmitters 430 and one or more receivers 435. Although only one transmitter 430 and one receiver 435 are illustrated, user equipment device 400 may have any suitable number of transmitters 430 and receivers 435. Furthermore, transmitters 430 and receivers 435 may be of any suitable type. In one embodiment, transceiver 425 includes a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum.

[0102] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip performing functions for use with both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, certain transceivers 425, transmitters 430, and receivers 435 may be implemented as physically separate components that access shared hardware and / or software resources, such as, for example, a network interface 440.

[0103] In various embodiments, one or more transmitters 430 and / or one or more receivers 435 may be implemented and / or integrated into a single hardware component (such as a multi-transceiver chip, system-on-a-chip, ASIC, or other type of hardware component). In some embodiments, one or more transmitters 430 and / or one or more receivers 435 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components such as network interface 440 or other hardware components / circuitets may be integrated with any number of transmitters 430 and / or receivers 435 into a single chip. In such embodiments, transmitters 430 and receivers 435 may be logically configured as transceivers 425 using a plurality of common control signals or as modular transmitters 430 and receivers 435 implemented in the same hardware chip or in a multi-chip module.

[0104] Figure 5 This description depicts one embodiment of a network device apparatus 500 that can be used to support the notification process during 5G registration via a non-3GPP access network, according to embodiments of the present disclosure. In some embodiments, the network device apparatus 500 may be an embodiment of TNGF. In other embodiments, the network device apparatus 500 may be an embodiment of AMF. Furthermore, the network device apparatus 500 may include a processor 505, a memory 510, an input device 515, an output device 520, and a transceiver 525. In some embodiments, the input device 515 and the output device 520 are combined into a single device, such as a touchscreen. In some embodiments, the network device apparatus 500 does not include any input device 515 and / or output device 520.

[0105] As depicted, transceiver 525 includes at least one transmitter 530 and at least one receiver 535. Here, transceiver 525 communicates with one or more remote units 105. Additionally, transceiver 525 may support at least one network interface 540, such as... Figure 1 The NWt, N2, and N3 interfaces are depicted in the diagram. In some embodiments, transceiver 525 supports a first interface for communicating with RAN nodes, a second interface for communicating with one or more network functions in the mobile core network (e.g., 5GC), and a third interface for communicating with remote units (e.g., UEs).

[0106] In one embodiment, processor 505 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 505 may be a microcontroller, microprocessor, central processing unit ("CPU"), graphics processing unit ("GPU"), auxiliary processing unit, field-programmable gate array ("FPGA"), or similar programmable controller. In some embodiments, processor 505 executes instructions stored in memory 510 to perform the methods and routines described herein. Processor 505 is communicatively coupled to memory 510, input device 515, output device 520, and first transceiver 525.

[0107] In various embodiments, processor 505 controls network device apparatus 500 to implement the TNGF behavior described above. In some embodiments, processor 505 initiates an EAP session with the UE (i.e., EAP-5G) (see, for example, see...). Figure 2A (Message 4a). Here, the EAP session facilitates the establishment of a NAS signaling connection between the UE and the mobile communication network. The EAP session is used to encapsulate NAS messages exchanged between the UE and the AMF in the mobile communication network. Processor 505 receives a request from the AMF, wherein the request indicates that the EAP session is about to be completed and determines whether the UE should receive at least one access parameter before the EAP session is completed. In response to determining that the UE should receive at least one access parameter before the EAP session is completed, processor 505 sends an EAP notification request to the UE. Here, the EAP notification request includes at least one access parameter. Processor 505 receives an EAP notification response from the UE and completes (i.e., ends and / or closes) the EAP session.

[0108] In some embodiments, the processor 505 establishes a secure IP connection (e.g., an NWT connection or an IPsec connection) with the UE in response to the completion of an EAP session. In such embodiments, the secure IP connection is initiated by the UE by applying at least one access parameter. Here, the secure IP connection is used to transmit NAS messages between the UE and the AMF after the EAP session is completed. In some embodiments, the NAS signaling connection is used to register the UE with the mobile communication network. In other embodiments, the NAS signaling connection may be used to carry service requests from the UE to the network.

[0109] Although the NAS signaling connection is between the UE and the AMF, the NWt connection (e.g., an IPsec connection) is between the UE and the TNGF. The NWt connection is used for secure transmission of NAS messages between the UE and the AMF, i.e., after the EAP session has ended. Note that before the NWt connection is established (i.e., between the UE and the AMF), NAS messages are transmitted via the EAP session (between the UE and the TNGF). However, after the NWt connection is established (which occurs after the EAP session ends), subsequent NAS messages are transmitted via the NWt connection (between the UE and the TNGF).

[0110] In some embodiments, the request from the AMF does not contain a NAS message. In some embodiments, the request from the AMF is one of an Initial Context Establishment Request and a TNGF Relocation Request, wherein the TNGF Relocation Request indicates that a NAS signaling connection should be established via a different TNGF.

[0111] In some embodiments, a request from the AMF indicates that the EAP session is about to be successfully completed by including at least one of the following: a TNGF key and a TNGF address. In other embodiments, a request from the AMF indicates that the EAP session is about to be unsuccessfully completed by including a UE context release command.

[0112] In some embodiments, at least one access parameter includes a TNGF address, a TNGF identity, a UE identity, and / or a selected cryptographic algorithm. In some embodiments, the TNGF address is a TNGF address received from the AMF (i.e., in the case of TNGF relocation) or an address of the network device 500.

[0113] In some embodiments, a TNGF key is used to cryptographically protect access parameters. For example, the TNGF key may be used in conjunction with a predefined cryptographic algorithm to protect access parameters. Alternatively, the TNGF key may be used in conjunction with a cryptographic algorithm selected by network device 500, as discussed below. In some embodiments, the EAP notification response indicates whether the UE has successfully verified at least one cryptographically protected access parameter.

[0114] In some embodiments, processor 505 receives a set of cryptographic algorithms supported by the UE and selects a cryptographic algorithm from that set. In such embodiments, processor 505 indicates the selected cryptographic algorithm to the UE, wherein at least one access parameter is cryptographically protected using the selected cryptographic algorithm and a TNGF key. In some embodiments, processor 505 indicates the selected cryptographic algorithm in an EAP notification request. In other embodiments, processor 505 indicates the selected cryptographic algorithm in a separate signaling message.

[0115] In some embodiments, the EAP notification response indicates whether the UE has successfully received at least one access parameter. In some embodiments, when the EAP notification response indicates that the UE has successfully received the access parameter, the processor 505 completes the EAP session by sending an EAP-success packet. In some embodiments, when the EAP notification response indicates that the UE has not successfully received at least one access parameter, the EAP session is completed by sending an EAP-failure packet.

[0116] In one embodiment, memory 510 is a computer-readable storage medium. In some embodiments, memory 510 includes volatile computer storage media. For example, memory 510 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 510 includes non-volatile computer storage media. For example, memory 510 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 510 includes both volatile and non-volatile computer storage media. In some embodiments, memory 510 stores data related to supporting the notification process during 5G registration via a non-3GPP access network, such as security keys, IP addresses, UE context, etc. In some embodiments, memory 510 also stores program code and related data, such as an operating system ("OS") or other controller algorithms operating on network device apparatus 500, and one or more software applications.

[0117] In one embodiment, input device 515 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 515 may be integrated with output device 520, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 515 includes a touchscreen, allowing text to be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 515 includes two or more different devices, such as a keyboard and a touch panel.

[0118] In one embodiment, output device 520 may include any known electronically controllable display or display device. Output device 520 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 520 includes an electronic display capable of outputting visual data to a user. For example, output device 520 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 520 may include wearable displays, such as smartwatches, smart glasses, heads-up displays, etc. Furthermore, output device 520 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0119] In some embodiments, output device 520 includes one or more speakers for generating sound. For example, output device 520 may generate an auditory alarm or notification (e.g., a beep or ringtone). In some embodiments, output device 520 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 520 may be integrated with input device 515. For example, input device 515 and output device 520 may form a touchscreen or similar touch-sensitive display. In other embodiments, all or part of output device 520 may be located near input device 515.

[0120] As discussed above, transceiver 525 can communicate with one or more remote units and / or with one or more interoperability functions that provide access to one or more PLMNs. Transceiver 525 can also communicate with one or more network functions (e.g., in mobile core network 140). Transceiver 525 operates under the control of processor 505 to transmit messages, data, and other signals, and also to receive messages, data, and other signals. For example, processor 505 can selectively activate the transceiver (or a portion thereof) at specific times to send and receive messages.

[0121] Transceiver 525 may include one or more transmitters 530 and one or more receivers 535. In some embodiments, one or more transmitters 530 and / or one or more receivers 535 may share transceiver hardware and / or circuitry. For example, one or more transmitters 530 and / or one or more receivers 535 may share antennas, antenna tuners, amplifiers, filters, oscillators, mixers, modulators / demodulators, power supplies, etc. In one embodiment, transceiver 525 uses different communication protocols or protocol stacks to implement multiple logical transceivers while using common physical hardware.

[0122] Figure 6 This invention describes one embodiment of a method 600 for supporting a notification process during 5G registration via a non-3GPP access network, according to embodiments of the present disclosure. In various embodiments, method 600 is performed by a UE such as the remote unit 105, UE 205, and / or user equipment device 400 described above. In some embodiments, method 600 is performed by a processor such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0123] Method 600 initiates and receives message 605, which initiates an EAP session with the access gateway in the TNAN. Here, the EAP session facilitates the establishment of a NAS signaling connection between the UE and the mobile communication network. The EAP session is used to encapsulate NAS messages exchanged between the UE and the AMF in the mobile communication network. Method 600 includes receiving an EAP notification request 610 from the access gateway before the EAP session concludes. Here, the EAP notification request includes at least one access parameter. Method 600 includes sending an EAP notification response 615. Method 600 includes completing the EAP session 620 (i.e., ending or closing). Method 600 concludes.

[0124] Figure 7 This invention describes one embodiment of a method 700 for supporting a notification process during 5G registration via a non-3GPP access network, according to embodiments of the present disclosure. In various embodiments, method 700 is performed by a TNGF such as TNGF 125, TNGF 127, TNGF 213 and / or a TNGF of network device device 500 as described above. In some embodiments, method 700 is performed by a processor such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0125] Method 700 initiates and 705 begins the EAP session with the UE. Here, the EAP session facilitates the establishment of a NAS signaling connection between the UE and the mobile communication network. The EAP session is used to encapsulate NAS messages exchanged between the AMF (Active Mobile Message Provider) in the UE and the mobile communication network.

[0126] Method 700 includes receiving a request from the AMF at 710. Here, the request indicates that the EAP session is about to end. Method 700 includes determining whether the UE will receive at least one access parameter before the EAP session ends.

[0127] Method 700 includes sending a 720 EAP notification request to the UE in response to determining that the UE will receive at least one access parameter before the EAP session ends. Here, the EAP notification request includes at least one access parameter. Method 700 includes receiving a 725 EAP notification response from the UE. Method 700 includes completing a 730 (i.e., ending or closing) EAP session. Method 700 ends.

[0128] This document discloses a first apparatus according to embodiments of the present disclosure for supporting a notification process during 5G registration via a non-3GPP access network. The first apparatus may be implemented by a TNGF such as TNGF 125, TNGF 127, TNGF 213 and / or the TNGF of network device apparatus 500 described above. The first apparatus includes a network interface for communicating with a mobile communication network and a processor for initiating an EAP session (i.e., EAP-5G) with a UE. Here, the EAP session facilitates the establishment of a NAS signaling connection between the UE and the mobile communication network. The EAP session is used to encapsulate NAS messages exchanged between the UE and the AMF in the mobile communication network. The processor receives a request from the AMF indicating that the EAP session is about to complete and determines whether the UE should receive at least one access parameter before the EAP session completes. In response to determining that the UE should receive at least one access parameter before the EAP session completes, the processor sends an EAP notification request to the UE. Here, the EAP notification request includes at least one access parameter. The processor receives an EAP notification response from the UE and completes (i.e., ends / closes) the EAP session.

[0129] In some embodiments, the processor establishes a secure IP connection (e.g., an NWT connection or an IPsec connection) with the UE in response to the completion of an EAP session. In such embodiments, the secure IP connection is initiated by the UE by applying at least one access parameter. Here, the secure IP connection is used to transmit NAS messages between the UE and the AMF after the EAP session is completed. In some embodiments, the NAS signaling connection is used to register the UE with the mobile communication network. In other embodiments, the NAS signaling connection may be used to carry service requests from the UE to the network.

[0130] In some embodiments, the request from the AMF does not contain a NAS message. In some embodiments, the request from the AMF is one of an Initial Context Establishment Request and a TNGF Relocation Request, wherein the TNGF Relocation Request indicates that a NAS signaling connection should be established via a different TNGF.

[0131] In some embodiments, a request from the AMF indicates that the EAP session is about to complete successfully by including at least one of the following: a TNGF key and a TNGF address. In other embodiments, a request from the AMF indicates that the EAP session is about to fail by including a UE context release command.

[0132] In some embodiments, at least one access parameter includes a TNGF address, a TNGF identity, a UE identity, and / or a selected cryptographic algorithm. In some embodiments, the TNGF address is the TNGF address received from the AMF (i.e., in the case of TNGF relocation) or the address of the first device.

[0133] In some embodiments, the access parameters are cryptographically protected using a TNGF key. For example, the TNGF key may be used in conjunction with a predefined cryptographic algorithm to protect the access parameters. Alternatively, the TNGF key may be used in conjunction with a cryptographic algorithm selected by the first device, as discussed below. In some embodiments, the EAP notification response indicates whether the UE has successfully verified at least one cryptographically protected access parameter.

[0134] In some embodiments, the processor receives a set of cryptographic algorithms supported by the UE and selects one from that set. In such embodiments, the processor indicates the selected cryptographic algorithm to the UE, wherein at least one access parameter is cryptographically protected using the selected cryptographic algorithm and a TNGF key. In some embodiments, the processor indicates the selected cryptographic algorithm in an EAP notification request.

[0135] In some embodiments, the EAP notification response indicates whether the UE has successfully received at least one access parameter. In some embodiments, when the EAP notification response indicates that the UE has successfully received the access parameter, the processor completes the EAP session by sending an EAP-success packet. In some embodiments, when the EAP notification response indicates that the UE has not successfully received at least one access parameter, the processor completes the EAP session by sending an EAP-failure packet.

[0136] This document discloses a first method for supporting a notification process during 5G registration via a non-3GPP network, according to embodiments of this disclosure. The first method can be performed by a TNGF such as TNGF 125, TNGF 127, TNGF 213 and / or a TNGF of network device 500 described above. The first method includes initiating an EAP session (i.e., an EAP-5G session) with a UE. Here, the EAP session facilitates the establishment of a NAS signaling connection between the UE and the mobile communication network. The EAP session is used to encapsulate NAS messages exchanged between the UE and the AMF in the mobile communication network. The first method includes receiving a request from the AMF. Here, the request indicates that the EAP session is about to complete. The first method includes determining whether the UE will receive at least one access parameter before the EAP session completes. The first method includes sending an EAP notification request to the UE in response to determining that the UE will receive at least one access parameter before the EAP session completes. Here, the EAP notification request includes at least one access parameter. The first method includes receiving an EAP notification response from the UE. The first method includes completing (i.e., ending / closing) the EAP session.

[0137] In some embodiments, the first method includes establishing a secure IP connection (e.g., an NWT connection or an IPsec connection) with the UE in response to the completion of an EAP session. In such embodiments, the secure IP connection is initiated by the UE by applying at least one access parameter. Here, the secure IP connection is used to transmit NAS messages between the UE and the AMF after the EAP session is completed. In some embodiments, the NAS signaling connection is used to register the UE with the mobile communication network. In other embodiments, the NAS signaling connection may be used to carry service requests from the UE to the network.

[0138] In some embodiments, the request from the AMF does not contain a NAS message. In some embodiments, the request from the AMF is one of an Initial Context Establishment Request and a TNGF Relocation Request, wherein the TNGF Relocation Request indicates that a NAS signaling connection should be established via a different TNGF.

[0139] In some embodiments, a request from the AMF indicates that the EAP session is about to complete successfully by including at least one of the following: a TNGF key and a TNGF address. In other embodiments, a request from the AMF indicates that the EAP session is about to fail by including a UE context release command.

[0140] In some embodiments, at least one access parameter includes a TNGF address, a TNGF identity, a UE identity, and / or a selected cryptographic algorithm. In some embodiments, the TNGF address is the TNGF address received from the AMF (i.e., in the case of TNGF relocation) or the address of the TNGF.

[0141] In some embodiments, a TNGF key is used to cryptographically protect access parameters. For example, the TNGF key may be used in conjunction with a predefined cryptographic algorithm to protect access parameters. Alternatively, the TNGF key may be used in conjunction with a cryptographic algorithm selected by the TNGF, as discussed below. In some embodiments, the EAP notification response indicates whether the UE has successfully verified at least one cryptographically protected access parameter.

[0142] In some embodiments, the first method includes receiving a set of cryptographic algorithms supported by the UE and selecting a cryptographic algorithm from the set. In such embodiments, the first method includes instructing the UE of the selected cryptographic algorithm, wherein at least one access parameter is cryptographically protected using the selected cryptographic algorithm and a TNGF key. In some embodiments, the first method includes instructing the selected cryptographic algorithm in an EAP notification request. In other embodiments, the first method includes instructing the selected cryptographic algorithm in a separate signaling message.

[0143] In some embodiments, the EAP notification response indicates whether the UE has successfully received at least one access parameter. In some embodiments, the first method includes completing the EAP session by sending an EAP-success packet when the EAP notification response indicates that the UE has successfully received the access parameter. In some embodiments, the EAP session is completed by sending an EAP-failure packet when the EAP notification response indicates that the UE has not successfully received at least one access parameter.

[0144] This document discloses a second apparatus according to embodiments of the present disclosure for supporting a notification process during 5G registration via a non-3GPP access network. The second apparatus may be implemented by a UE such as the remote unit 105, UE 205, and / or user equipment apparatus 400 described above. The second apparatus includes: a transceiver communicating with a mobile communication network via a TNAN; and a processor receiving a message initiating an EAP session (i.e., an EAP-5G session) with an access gateway (i.e., TNGF) in the TNAN. Here, the EAP session facilitates the establishment of a NAS signaling connection between the second apparatus and the mobile communication network, and wherein the EAP session is used to encapsulate NAS messages exchanged between the second apparatus and the AMF in the mobile communication network. The processor receives an EAP notification request from the access gateway before the EAP session concludes. Here, the EAP notification request includes at least one access parameter. The processor sends an EAP notification response and concludes (i.e., closes / ends) the EAP session.

[0145] In some embodiments, the processor uses at least one access parameter to establish a secure IP connection (e.g., an NWt connection) with the access gateway in response to completing an EAP session, wherein the secure IP connection is used to transmit NAS messages between the second device and the AMF after the EAP session is completed. In some embodiments, the NAS signaling connection is used to register the second device with the mobile communication network. In other embodiments, the NAS signaling connection may be used to carry service requests from the second device to the network.

[0146] In some embodiments, at least one access parameter includes at least one of the following: a TNGF address, a TNGF identity, a network identity of the second device, and a selected cryptographic algorithm. In some embodiments, the access gateway is a first TNGF in a TNAN, wherein the TNGF address includes one of the following: a first TNGF address of a first TNGF in a TNAN and a second TNGF address of a second TNGF.

[0147] In some embodiments, access parameters are cryptographically protected (e.g., encrypted or integrity protected) using a TNGF key. For example, the TNGF key may be used with a predefined cryptographic algorithm to protect the access parameters. Alternatively, the TNGF key may be used with a cryptographic algorithm selected by the TNGF, as discussed below. In some embodiments, the EAP notification response indicates whether the second device has successfully received at least one access parameter.

[0148] In some embodiments, the processor sends a set of cryptographic algorithms supported by a second device and receives a selected cryptographic algorithm, wherein the access gateway selects the selected cryptographic algorithm from the set of cryptographic algorithms. In such an embodiment, the processor uses the selected cryptographic algorithm and the TNGF key to verify (e.g., decrypt) access parameters.

[0149] In some embodiments, the selected cryptographic algorithm may be indicated in the EAP notification request. In some embodiments, the processor may indicate successful acceptance of the access parameter in response to successful processing (e.g., verification and / or decryption) of at least one cryptographically protected access parameter.

[0150] This document discloses a second method, according to embodiments of the present disclosure, for supporting a notification process during 5G registration via a non-3GPP access network. The second method can be implemented by a UE such as the remote unit 105, UE 205, and / or user equipment device 400 described above. The second method includes receiving a message initiating an EAP session (i.e., an EAP-5G session) with an access gateway (i.e., TNGF) in the TNAN. Here, the EAP session facilitates the establishment of a NAS signaling connection between the UE and the mobile communication network. The EAP session is used to encapsulate NAS messages exchanged between the UE and the AMF in the mobile communication network. The second method includes receiving an EAP notification request from the access gateway before the EAP session concludes. Here, the EAP notification request includes at least one access parameter. The second method includes sending an EAP notification response. The second method includes completing (i.e., ending / closing) the EAP session.

[0151] In some embodiments, the second method includes establishing a secure IP connection (e.g., an NWt connection) with an access gateway using at least one access parameter in response to the completion of an EAP session, wherein the secure IP connection is used to transmit NAS messages between the UE and the AMF after the EAP session is completed. In some embodiments, the NAS signaling connection is used to register the UE with the mobile communication network. In other embodiments, the NAS signaling connection is used to carry service requests from the UE to the network.

[0152] In some embodiments, at least one access parameter includes at least one of the following: TNGF address, TNGF identity, UE identity, and selected cryptographic algorithm. In some embodiments, the access gateway is a first TNGF in a TNAN, wherein the TNGF address includes one of the following: a first TNGF address of a first TNGF in a TNAN and a second TNGF address of a second TNGF in a second TNGF.

[0153] In some embodiments, access parameters are cryptographically protected (e.g., encrypted or integrity protected) using a TNGF key. For example, the TNGF key may be used with a predefined cryptographic algorithm to protect access parameters. Alternatively, the TNGF key may be used with a cryptographic algorithm selected by the TNGF, as discussed below. In some embodiments, the EAP notification response indicates whether the UE has successfully received at least one access parameter.

[0154] In some embodiments, the second method includes sending a set of cryptographic algorithms supported by the UE and receiving a selected cryptographic algorithm, wherein the access gateway selects the selected cryptographic algorithm from the set of cryptographic algorithms. In such embodiments, the second method includes processing (e.g., verifying and / or decrypting) access parameters using the selected cryptographic algorithm and a TNGF key.

[0155] In some embodiments, the selected cryptographic algorithm may be indicated in the EAP notification request. In some embodiments, the second method may include indicating successful acceptance of the access parameter in response to successful processing (e.g., verification and / or decryption) of at least one cryptographically protected access parameter.

[0156] The embodiments may be practiced in other specific forms. The described embodiments are to be considered illustrative rather than limiting in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations falling within the meaning and scope of the claims should be covered within their scope.< / mcc> < / mnc>

Claims

1. An apparatus for storing code for gateway functionality, the apparatus comprising: At least one memory storing the code; as well as At least one processor, coupled to the at least one memory, and configured to execute the code to enable the gateway functionality: Initiate an Extensible Authentication Protocol ("EAP") session associated with a user equipment ("UE"), wherein the gateway function supports the exchange of a first non-access stratum ("NAS") message set between the UE and the Access and Mobility Management Function ("AMF"); A first request is received from the AMF, the first request including a security key for ensuring secure communication with the UE, wherein the first request is received in response to the authorization process and the security mode control process being skipped; In response to receiving the first request including the security key, an EAP notification request is sent to the UE, wherein the EAP notification request includes at least one access parameter; Receive EAP notification response from the UE; and Complete the EAP session.

2. The apparatus according to claim 1, wherein, The at least one processor is configured to cause the gateway to establish a secure Internet Protocol ("IP") connection with the UE in response to the completion of the EAP session, wherein the secure IP connection is based on the at least one access parameter, and wherein the secure IP connection is used to transmit a second set of NAS messages between the UE and the AMF after the completion of the EAP session.

3. The apparatus according to claim 1, wherein, The at least one processor is configured to enable the gateway to: establish a NAS signaling connection; and register the UE with the network.

4. The apparatus according to claim 1, wherein, The first request from the AMF lacks a NAS message.

5. The apparatus according to claim 1, wherein, The first request is an initial context establishment request or a Trusted Non-3GPP Gateway Function ("TNGF") relocation request, wherein the TNGF relocation request includes an indication to establish a NAS signaling connection via a different TNGF.

6. The apparatus according to claim 1, wherein, The first request includes: a Trusted Non-3GPP Gateway Function ("TNGF") key or a TNGF address, or both, to indicate that the EAP session is about to be successfully completed.

7. The apparatus according to claim 1, wherein, The first request includes a UE context release command to indicate that the EAP session will not be completed successfully.

8. The apparatus according to claim 1, wherein, The at least one access parameter includes one or more of the following: a Trusted Non-3GPP Gateway Function ("TNGF") address, a TNGF identity, a UE identity, or a selected cryptographic algorithm, wherein the TNGF address includes: a TNGF address received from the AMF or the address of the device or both.

9. The apparatus according to claim 1, wherein, The security key includes a Trusted Non-3GPP Gateway Function ("TNGF") key, wherein the TNGF key is used to cryptographically protect the at least one access parameter, and wherein the EAP notification response indicates whether the UE has successfully verified the at least one access parameter.

10. The apparatus according to claim 1, wherein, The at least one processor is further configured to cause the gateway to: Receive an indication of the set of cryptographic algorithms supported by the UE; Select a cryptographic algorithm from the set of cryptographic algorithms; as well as Instructions for a selected cryptographic algorithm are transmitted to the UE, wherein the selected cryptographic algorithm and the security key are used to cryptographically protect the at least one access parameter, wherein the security key includes a Trusted Non-3GPP Gateway Function ("TNGF") key.

11. The apparatus according to claim 1, wherein, The EAP notification response indicates whether the UE has successfully received the at least one access parameter.

12. The apparatus according to claim 1, wherein, The at least one processor is configured to cause the gateway to complete the EAP session by performing the following actions: sending an EAP-success packet when the EAP notification response indicates that the UE has successfully accepted the at least one access parameter, or sending an EAP-failure packet when the EAP notification response indicates that the UE has not successfully received the at least one access parameter.

13. A method performed by a gateway function, the method comprising: Initiate an Extensible Authentication Protocol ("EAP") session with the user equipment ("UE"), wherein the gateway function supports the exchange of a first non-access stratum ("NAS") message set between the UE and the Access and Mobility Management Function ("AMF"); A first request is received from the AMF, the first request including a security key for ensuring secure communication with the UE indicating that the EAP session is about to be completed, wherein the first request is received in response to the authorization process and the security mode control process being skipped; In response to receiving the first request including the security key, an EAP notification request is sent to the UE, the EAP notification request including at least one access parameter; Receive EAP notification response from the UE; and Complete the EAP session.

14. A user equipment ("UE") comprising: At least one memory for storing code; as well as At least one processor, coupled to the at least one memory, and configured to execute the code to cause the UE to: The UE receives a message to initiate an Extensible Authentication Protocol ("EAP") session with an access gateway in a Trusted Non-3GPP Gateway Function ("TNAN"), wherein the UE supports the exchange of a first set of Non-Access Stratum ("NAS") messages between the UE and the Access and Mobility Management Function ("AMF"), wherein the message is received in response to the authorization process and security mode control process being skipped. Before the EAP session is completed, an EAP notification request is received from the access gateway, the EAP notification request including at least one access parameter; Send EAP notification response; and Complete the EAP session.

15. The UE according to claim 14, wherein, The at least one processor is configured to cause the UE to: establish a Secure Internet Protocol ("IP") connection with the access gateway using the at least one access parameter in response to the completion of the EAP session, wherein the Secure IP connection is used to transmit a second set of NAS messages between the UE and the AMF after the completion of the EAP session.

16. The UE according to claim 14, wherein, The at least one processor is configured to cause the UE to: establish a NAS signaling connection; and register the UE with the network.

17. The UE according to claim 14, wherein, The EAP notification response indicates whether the UE has successfully received the at least one access parameter, wherein the at least one access parameter includes one or more of the following: a Trusted Non-3GPP Gateway Function ("TNGF") address, a TNGF identity, the UE's network identity, or a selected cryptographic algorithm or a combination thereof.

18. The UE according to claim 14, wherein, The at least one processor is further configured to cause the UE to: Indicates the set of cryptographic algorithms supported by the UE; The access gateway receives an instruction for a selected cryptographic algorithm, wherein the selected cryptographic algorithm is chosen from the set of cryptographic algorithms. The selected encryption algorithm and the Trusted Non-3GPP Gateway Function ("TNGF") key are used to verify the at least one access parameter, and In response to successful verification of at least one access parameter, an indication of successful acceptance of the access parameter is transmitted.

19. The UE according to claim 18, wherein, The EAP notification response includes an indication of the selected cryptographic algorithm.

20. A method performed by a user equipment ("UE"), the method comprising: The UE receives a message initiating an Extensible Authentication Protocol ("EAP") session with an access gateway in a Trusted Non-3GPP Access Network ("TNAN"), wherein the UE supports the exchange of a first Non-Access Stratum ("NAS") message set between the UE and the Access and Mobility Management Function ("AMF"), wherein the message is received in response to the authorization process and security mode control process being skipped. Before the EAP session is completed, an EAP notification request is received from the access gateway, the EAP notification request including at least one access parameter; Send EAP notification response; and Complete the EAP session.

Citation Information

Patent Citations

  • Method to authenticate with a mobile communication network

    CN110603891A