Re-authentication for user equipment mobility in wireless communication network

Abstract

Aspects of the present disclosure relate to a method in a network function, the method comprising: receiving one or more first parameters indicating a capability of a user equipment (UE) to re-authenticate with a wireless communication network; receiving one or more second parameters indicating a capability of the first network access point to re-authenticate with the wireless communication network; determining a re-authentication type for UE mobility based on the one or more first parameters and the one or more second parameters; and determining security information for UE mobility based on the re-authentication type.

Description

Technical Field

[0001] The topics disclosed herein generally relate to the field of re-authentication for user equipment (UE) mobility in wireless communication networks. This document defines a network function for wireless communication, a method in a network function, a UE for wireless communication, a method in a UE, a network access point for wireless communication, a method in a network access point, a processor for wireless communication, and a method in a processor. Background Technology

[0002] A wireless communication system may include one or more network communication devices, such as base stations, which may support wireless communication with one or more user communication devices, also referred to as user equipment (UE) or other suitable terms. The wireless communication system can support wireless communication with one or more user communication devices by utilizing the resources of the wireless communication system (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers, etc.)). Additionally, the wireless communication system can support wireless communication across various radio access technologies, including third-generation (3G) radio access technology, fourth-generation (4G) radio access technology, fifth-generation (5G) radio access technology, and other suitable radio access technologies other than 5G (e.g., sixth-generation (6G)).

[0003] 5G systems currently support authentication for Trusted Non-3GPP (3GPP) access, where the UE connects (e.g., registers) to the 5G core network via a Trusted Non-3GPP Access Network (TNAN). The TNAN includes a Trusted Non-3GPP Access Point (TNAP) and a Trusted Non-3GPP Gateway Function (TNGF). In 3GPP Rel.17 and 3GPP Rel.18, if a UE moves from a source TNAP to a target TNAP, the UE will perform full authentication via the target TNAP to reconnect to the 5G system. Full authentication involves security establishment at all levels, including access network security (i.e., secure establishment between the UE and the access network) and non-access stratum security (i.e., secure establishment between the UE and the core network). Summary of the Invention

[0004] The article "a" preceding an element is unrestricted and should be understood to refer to "at least one" or "one or more" of these elements. The terms "a," "at least one," "one or more," and "at least one of one or more" are interchangeable. As used herein, including in the claims, the use of "or" in a list of items (e.g., a list of items beginning with phrases such as "at least one of..." or "one or more of..." or "one or two of...") indicates an inclusive list, such that, for example, a list of at least one of A, B, or C represents A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, as used herein, the phrase "based on" should not be construed as a reference to a closed set of conditions. For example, an example step described as "based on condition A" could be based on both condition A and condition B without departing from the scope of this disclosure. In other words, as used herein, the phrase "based on" should be interpreted in the same manner as the phrase "at least partially based on." Furthermore, as used herein, including in the claims, "set" can include one or more elements.

[0005] A network function for wireless communication is provided, the network function comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the network function: receives one or more first parameters indicating the ability of a user equipment (UE) to re-authenticate with a wireless communication network; receives one or more second parameters indicating the ability of a first network access point to re-authenticate with the wireless communication network; determines a re-authentication type for UE mobility based on one or more first parameters and one or more second parameters; and determines security information for UE mobility based on the re-authentication type.

[0006] A method in a network function is also provided, the method comprising: receiving one or more first parameters, the one or more first parameters indicating the ability of a user equipment (UE) to re-authenticate with a wireless communication network; receiving one or more second parameters, the one or more second parameters indicating the ability of a first network access point to re-authenticate with the wireless communication network; determining a re-authentication type for UE mobility based on the one or more first parameters and the one or more second parameters; and determining security information for UE mobility based on the re-authentication type.

[0007] A UE for wireless communication is also provided, the UE comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the UE: provides one or more first parameters to a network function of a wireless communication network, the one or more first parameters indicating the UE's ability to re-authenticate with the wireless communication network via a first network access point; and receives a re-authentication type from the network function, the re-authentication type being used to derive security information for UE mobility, for the UE to re-authenticate with the wireless communication network via the first network access point.

[0008] A method in a UE is also provided, the method comprising: providing one or more first parameters to a network function of a wireless communication network, the one or more first parameters indicating the UE's ability to re-authenticate with the wireless communication network via a first network access point; and receiving a re-authentication type from the network function, the re-authentication type being used to derive security information for UE mobility for the UE to re-authenticate with the wireless communication network via the first network access point.

[0009] A network access point for wireless communication is also provided, the network access point comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the network access point: receives one or more first parameters from a UE, the one or more first parameters indicating the UE's ability to re-authenticate with a wireless communication network via the network access point; provides one or more first parameters to a network function of the wireless communication network; provides one or more second parameters to the network function, the one or more second parameters indicating the network access point's ability to re-authenticate with the wireless communication network; and receives re-authentication type and / or security information for UE mobility from the network function for the UE to re-authenticate with the wireless communication network via the network access point.

[0010] A method in a network access point is also provided, the method comprising: receiving one or more first parameters from a UE, the one or more first parameters indicating the UE's ability to re-authenticate with a wireless communication network via the network access point; providing one or more first parameters to a network function of the wireless communication network; providing one or more second parameters to the network function, the second parameter indicating the network access point's ability to re-authenticate with the wireless communication network; and receiving from the network function re-authentication type and / or security information for UE mobility, for the UE to re-authenticate with the wireless communication network via the network access point.

[0011] A processor for wireless communication is also provided, the processor comprising: at least one controller coupled to at least one memory and configured such that the processor: outputs one or more first parameters indicating the ability of a UE to re-authenticate with a wireless communication network via a first network access point; and inputs a re-authentication type for deriving security information for UE mobility for the UE to re-authenticate with the wireless communication network via the first network access point.

[0012] A method for wireless communication in a processor is also provided, the method comprising: outputting one or more first parameters indicating the ability of a UE to re-authenticate with a wireless communication network via a first network access point; and inputting a re-authentication type for deriving security information for UE mobility for re-authentication via the first network access point and the wireless communication network. Attached Figure Description

[0013] Figure 1 Examples of wireless communication systems according to various aspects of this disclosure are provided.

[0014] Figure 2 Examples of TNAP mobility procedures based on various aspects of this disclosure are provided.

[0015] Figure 3 Examples of 5G and FT key tiers are provided according to various aspects of this disclosure.

[0016] Figure 4 Examples are provided of a UE attached to a first AP to establish an FT key hierarchy in accordance with various aspects of this disclosure.

[0017] Figure 5 Examples of AP mobility using over-the-air procedures are provided according to various aspects of this disclosure.

[0018] Figure 6 Examples of authentication for trusted non-3GPP access are provided in accordance with various aspects of this disclosure.

[0019] Figure 7 Examples of a security establishment process for TNAP mobility based on various aspects of this disclosure are provided.

[0020] Figure 8 Examples of updated key levels for trusted non-3GPP access to support TNAP mobility are provided according to various aspects of this disclosure.

[0021] Figures 9A and 9B provide examples of the exchange of UE and TNAP re-authentication capabilities during authentication for trusted non-3GPP access of a UE, according to various aspects of this disclosure.

[0022] Figures 10A-10C provide examples of the exchange of UE and TNAP re-authentication capabilities during re-authentication / mobility for UE trusted non-3GPP access, according to various aspects of this disclosure.

[0023] Figure 11 Examples of a UE moving from its current serving AP to a new target AP are provided in accordance with various aspects of this disclosure.

[0024] Figure 12 Another example is provided of a UE moving from the current serving AP to a new target AP according to various aspects of this disclosure.

[0025] Figure 13 An example of a user equipment (UE) 1300 according to various aspects of this disclosure is shown.

[0026] Figure 14 An example of a processor 1400 according to various aspects of this disclosure is shown.

[0027] Figure 15 An example of a network device (NE) 1500 according to various aspects of this disclosure is shown.

[0028] Figure 16 The diagram illustrates a flowchart of a method performed by a UE according to various aspects of this disclosure.

[0029] Figure 17 The diagram illustrates a flowchart of a method performed by an NE according to various aspects of this disclosure.

[0030] Figure 18 A flowchart is shown of alternative methods performed by the NE according to various aspects of this disclosure.

[0031] Figure 19 A flowchart of a method executed by a processor according to various aspects of this disclosure is shown. Detailed Implementation

[0032] In the case of UE TNAP mobility, only the access network changes, while the core network remains unchanged. Therefore, performing full authentication with the core network during UE TNAP mobility can lead to unnecessary message exchanges between the UE and the core network. This can result in resource exhaustion and delays in connection re-establishment. Therefore, 5G systems should support UE TNAP mobility with re-authentication and secure establishment (i.e., without full authentication). In this regard, some solutions can use IEEE 802.11 Fast BSS transition with FT protocol, 3GPP local re-authentication methods (for re-authentication and secure establishment), or modified ERP. If the FT protocol is used, there are some limitations. Not all TNAPs support FT, as it is an optional protocol to be supported according to the IEEE 802.11 specification, and the FT protocol only works when UE mobility occurs between two TNAPs within the same mobility domain in the TNGF (i.e., FT is not applicable when the UE moves between two TNAPs in different mobility domains or between two TNAPs in two different TNGFs). There are currently some deployments, some of which already support the FT protocol and are therefore interested in reusing it, at least where TNAP already supports FT. However, at the same time, there is a need to use at least one re-authentication method (e.g., 3GPP local re-authentication method or ERP) to cover situations where FT cannot be used. In this case, some issues arise, which will be briefly discussed below.

[0033] One such issue is that different TNAPs may support different re-authentication methods (i.e., one TNAP may support FT, while another TNAP may need to support the 3GPP native method or the ERP / modified ERP method). Therefore, unless the TNGF knows the TNAP's re-authentication capabilities, the TNGF cannot provide the TNAP with re-authentication method-specific security key material (e.g., (i) if FT is used, the TNGF needs to derive the FT key and provide it to the TNAP; (ii) if ERP / modified ERP is used, the TNGF needs to derive the rRK but provide the rMSK (derived from the rRK) to the TNAP; (iii) if the 3GPP native re-authentication method is used, the TNGF needs to send a fresh TNAP key to the TNAP and provide the TNAP with the relevant current value / random number / counter to forward it to the UE).

[0034] Another issue is that legacy UEs cannot support any UE TNAP mobility re-authentication, and only future versions of UEs can be configured to support these enhancements. Therefore, if the TNGF is unaware of the UE's re-authentication capabilities, allowing the TNGF to provide the UE with the relevant information for security establishment, the re-authentication enhancements will not work.

[0035] Therefore, typically in non-3GPP access networks, different TNAPs can support different re-authentication protocols, such as FT protocols based on IEEE 802.11 or other non-FT protocols, such as any 3GPP local re-authentication protocol (a re-authentication and secure establishment process or protocol specified by 3GPP), ERP, or a modified ERP, etc. This disclosure aims to enable the UE and TNAP to indicate their respective re-authentication capabilities, allowing the TNGF in the network to select a re-authentication method, generate the necessary re-authentication security context (specific to the supported and selected re-authentication method), and supply the security context to the TNAP to successfully perform re-authentication and secure establishment during UE mobility scenarios. Following successful UE mobility (across different TNAPs) and secure establishment, the TNGF is also provided to report the TNAP identifier of the new service (which acts as UE location information) to the AMF, which often allows the network to know the updated location information of the UE. Furthermore, this disclosure aims to provide a method for supporting UE mobility between APs with FT capabilities and APs without FT capabilities.

[0036] Various aspects of this disclosure are described in the context of wireless communication systems.

[0037] Figure 1 An example of a wireless communication system 100 according to various aspects of this disclosure is illustrated. The wireless communication system 100 may include one or more NEs 102, one or more UEs 104, and a core network (CN) 106. The wireless communication system 100 may support various radio access technologies. In some implementations, the wireless communication system 100 may be a 4G network, such as an LTE network or an advanced LTE (LTE-A) network. In some other implementations, the wireless communication system 100 may be an NR network, such as a 5G network, an advanced 5G (5G-A) network, or a 5G ultra-wideband (5G-UWB) network. In other implementations, the wireless communication system 100 may be a combination of 4G and 5G networks, or other suitable radio access technologies, including IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), and IEEE 802.20. The wireless communication system 100 may support radio access technologies other than 5G, such as 6G. In addition, the wireless communication system 100 can support technologies such as time division multiplexing (TDMA), frequency division multiplexing (FDMA), or code division multiplexing (CDMA).

[0038] One or more NEs 102 may be distributed throughout a geographic area to form a wireless communication system 100. One or more NEs 102 described herein may be, include, or may be referred to as network nodes, base stations, network elements, network functions, network entities, radio access networks (RAN), NodeBs, eNodeBs (eNBs), next-generation NodeBs (gNBs), or other suitable terms. NEs 102 and UEs 104 may communicate via a communication link, which may be a wireless or wired connection. For example, NEs 102 and UEs 104 may perform wireless communication (e.g., receiving signaling, sending signaling) via a Uu interface.

[0039] NE 102 can provide a geographic coverage area for which NE 102 can support services of one or more UE 104s within that geographic coverage area. For example, NE 102 and UE 104 can support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcasting, etc.) based on one or more radio access technologies. In some implementations, NE 102 can be mobile, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas associated with the same or different radio access technologies can overlap, but different geographic coverage areas can be associated with different NE 102s.

[0040] One or more UEs 104 may be distributed throughout the geographic area of ​​the wireless communication system 100. UE 104 may include or be referred to as a remote unit, mobile device, wireless device, remote device, subscriber device, transmitter device, receiver device, or some other suitable term. In some implementations, UE 104 may be referred to as a unit, station, terminal, or client, etc. Additionally or alternatively, UE 104 may be referred to as an Internet of Things (IoT) device, Internet of Everything (IoE) device, or Machine Type Communication (MTC) device, etc.

[0041] UE 104 can support direct wireless communication with other UE 104s via a communication link. For example, UE 104 can support direct wireless communication with another UE 104 via a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular V2X deployments, the communication link may be referred to as a sidelink. For example, UE 104 can support direct wireless communication with another UE 104 via a PC5 interface.

[0042] NE 102 can support communication with CN 106 or with another NE 102, or both. For example, NE 102 can interface with other NE 102 or CN 106 via one or more backhaul links (e.g., S1, N2, N2, or network interfaces). In some implementations, NE 102 can communicate directly with each other. In some other implementations, NE 102 can communicate with each other or indirectly (e.g., via CN 106). In some implementations, one or more NE 102 may include sub-components, such as access network entities, which may be examples of access node controllers (ANCs). The ANC can communicate with one or more UEs 104 via one or more other access network transport entities (which may be referred to as radio headends, smart radio headends, or transmit-receive points (TRPs)).

[0043] CN 106 can support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. CN 106 can be an evolved packet core (EPC) or a 5G core (5GC), which may include control plane entities that manage access and mobility (e.g., a mobility management entity (MME), access and mobility management functions (AMF)) and user plane entities that route packets or interconnections to external networks (e.g., a serving gateway (S-GW), a packet data network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entities may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signaling bearers, etc.) of one or more UEs 104 served by one or more NEs 102 associated with CN 106.

[0044] CN 106 can communicate with the packet data network via one or more backhaul links (e.g., via S1, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 can communicate with the application server. UE 104 can establish a session with CN 106 via NE 102 (e.g., a Protocol Data Unit (PDU) session, etc.). CN 106 can use the established session (e.g., an established PDU session) to route services (e.g., control information, data, etc.) between UE 104 and the application server. The PDU session may be an example of a logical connection between UE 104 and CN 106 (e.g., one or more network functions of CN 106).

[0045] In the wireless communication system 100, NE 102 and UE 104 can use the resources of the wireless communication system 100 (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communication). In some implementations, NE 102 and UE 104 can support different resource structures. For example, NE 102 and UE 104 can support different frame structures. In some implementations, such as in 4G, NE 102 and UE 104 can support a single-frame structure. In some other implementations, such as in 5G and other suitable radio access technologies, NE 102 and UE 104 can support various frame structures (i.e., multi-frame structures). NE 102 and UE 104 can support various frame structures based on one or more digital technologies.

[0046] One or more digital technologies may be supported in the wireless communication system 100, and the digital technologies may include subcarrier spacing and cyclic prefix. The first digital technology (e.g., μ =0) can be associated with the first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first digital technique (e.g., ...) associated with the first subcarrier spacing (e.g., 15 kHz) is... μ =0) can utilize one time slot per subframe. Second digital technologies (e.g., μ =1) can be associated with the second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. The third digital technology (e.g., μ =2) can be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth digital technology (e.g., μ =3) can be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth digital technology (e.g., μ =4) can be associated with the fifth subcarrier spacing (e.g., 240 kHz) and the normal cyclic prefix.

[0047] The time intervals of resources (e.g., communication resources) can be organized according to frames (also called radio frames). Each frame can have a duration, for example, 10 milliseconds (ms). In some implementations, each frame can include multiple subframes. For example, each frame can include 10 subframes, and each subframe can have a duration, for example, 1 ms. In some implementations, each frame can have the same duration. In some implementations, each subframe of a frame can have the same duration.

[0048] Alternatively or concurrently, the time intervals of resources (e.g., communication resources) can be organized according to time slots. For example, a subframe may include a certain number (e.g., quantity) of time slots. The number of time slots in each subframe may also depend on one or more digital technologies supported in the wireless communication system 100. For example, a first digital technology, a second digital technology, a third digital technology, a fourth digital technology, and a fifth digital technology (i.e., ...) associated with corresponding subcarrier intervals of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz. μ =0、 μ =1、 μ =2、 μ =3、 μ =4) One time slot per subframe, two time slots per subframe, four time slots per subframe, eight time slots per subframe, and 16 time slots per subframe can be used respectively. Each time slot can include a certain number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of time slots in a subframe can depend on the digital technology. For a normal cyclic prefix, a time slot can include 14 symbols. For an extended cyclic prefix (e.g., for a 60kHz subcarrier spacing), a time slot can include 12 symbols. The relationship between the number of symbols per time slot, the number of time slots per subframe, and the number of time slots per frame for both normal and extended cyclic prefixes can depend on the digital technology. It should be understood that for the first digital technology (e.g., ...) associated with the first subcarrier spacing (e.g., 15kHz) ... μ The reference of =0 can be used interchangeably between subframes and time slots.

[0049] In the wireless communication system 100, the electromagnetic (EM) spectrum can be divided into various categories, frequency bands, frequency channels, etc., based on frequency or wavelength. For example, the wireless communication system 100 can support one or more operating frequency bands, such as frequency range names FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, network entity 102 and UE 104 can perform wireless communication on one or more operating frequency bands. In some implementations, FR1 can be used by network entity 102 and UE 104, as well as other devices or apparatuses, for cellular communication services (e.g., control information, data). In some implementations, FR2 can be used by network entity 102 and UE 104, as well as other devices or apparatuses, for short-range, high data rate capabilities.

[0050] FR1 can be associated with one or more digital technologies (e.g., at least three digital technologies). For example, FR1 can be associated with the following: a first digital technology (e.g., μ =0), which includes a 15 kHz subcarrier spacing; second digital technology (e.g., μ =1), which includes a 30 kHz subcarrier spacing; third digital technology (e.g., μ =2), which includes a subcarrier spacing of 60 kHz. FR2 can be associated with one or more digital technologies (e.g., at least two digital technologies). For example, FR2 can be associated with a third digital technology (e.g., μ =2), which includes a 60 kHz subcarrier spacing; fourth digital technology (e.g., μ =3), which includes a subcarrier spacing of 120 kHz.

[0051] Trusted non-3GPP access networks can connect to the 5G core network via a Trusted Non-3GPP Gateway Function (TNGF). A Trusted WLAN Access Network (TNAN) is a specific type of TNAN that supports WLAN access technologies such as IEEE 802.11. The UE connects (e.g., registers) to the 5G core network via a TNAN consisting of a Trusted Non-3GPP Access Point (TNAP) and a Trusted Non-3GPP Gateway Function (TNGF). In 3GPP 5G Systems Rel.18, to support UE TNAP mobility scenarios, the 5G system is expected to enable re-authentication and secure establishment for trusted non-3GPP access when the UE moves from one TNAP (referred to as TNAP1) to another TNAP (referred to as TNAP2) without performing full authentication. However, this raises a critical issue regarding the security aspects of TNAP mobility without full authentication. This will now be briefly discussed. The 3GPP report TR 33.887, entitled “Study on Security Aspects of Phase 2 of 5WWC,” raises a similar key issue in section 5.4.

[0052] Currently, 3GPP does not support mobility between two TNAPs within the same Trusted Non-3GPP Access Network Gateway Function (TNGF). For example, when a UE moves between two nearby or overlapping TNAPs (i.e., TNAP1 and TNAP2), the connection will be interrupted. Therefore, UE service will be interrupted. Even if the second non-3GPP access network connects to the same 5GC, the UE needs to reconnect and continue service through another authentication process. Several potential security solutions exist where the UE can switch from TNAP1 to TNAP2 without interrupting the connection. However, the security aspects of optimizing inter-TNAP mobility remain to be considered.

[0053] Potential security requirements will now be discussed. 5GS should support communication mechanisms between the UE and the TNAP / TNGF to establish security with the TNAP without performing full authentication when the UE switches from another TNAP within the same TNGF. The interface between the UE and the new TNAP should provide confidentiality, integrity, and replay protection when switching from one TNAP to another within the same TNGF. Current processes that provide the potential for developing solutions will now be briefly outlined. This includes both FT-based and non-FT-based solutions. Some current processes that provide the potential for developing solutions can be further categorized as 3GPP-native solutions or modified ERP solutions.

[0054] The first potential solution involves TNAP mobility with rand. Figure 2 An example of the TNAP mobility process 200 is illustrated. The diagram shows UE 220 and TNAN 230. TNAN 230 includes TNAP#1 232, TNAP#2 234, and TNGF 236. The various processing steps and messaging flows 201-211 will now be described.

[0055] In the first step 201, according to the 3GPP specification TS 33.501 entitled "Security Architecture and Procedures for 5G Systems"... Figure 7 In step 1-19 of A.2.1-1, UE 220 connects to TNAP#1 232. In step 201, TNGF 236 also provides a re-authentication ID to UE 220. More specifically, UE 220 connects via 3GPP TS 33.501. Figure 7 The procedure defined in A.2.1-1 connects to TNAP#1 232. Once authenticated, TNGF 236 sends a re-authentication ID to UE 220 via the protected interface. The re-authentication ID can be generated as, for example, ' <plmnid><TNGF_ID><Temp Id>It should be noted that the TNGF ID can be a TNGF address (such as 'fqdn').

[0056] In a further step 202, UE 220 decides to change to TNAP#2 234. In a further step 203, an L2 connection is established between UE 220 and TNAP#2 234. In other words, in steps 202-203, UE 220 decides to move from TNAP#1 232 to TNAP#2 234 and creates an L2 connection with TNAP#2 234.

[0057] In a further step 204, an L2 message is provided to UE 220 from TNAP#2 234. This request includes an EAP request / identity. In a further step 205, an L2 message is provided from UE 220 to TNAP#2 234. The L2 message includes an EAP response / identity, TNAP_Mobility_Indication, and a re-authentication ID. In a further step 206, TNAP#2 234 provides an AAA message to TNGF236. The AAA message includes TNAP_Mobility_Indication and a re-authentication ID. In other words, TNAP#2 234 sends an L2 EAP request for identity to UE 220, and UE 220 responds with an L2 EAP response containing the identity and TNAP_Mobility_Indication flags. TNAP#2 234 forwards the EAP response containing the re-authentication ID and TNAP_Mobility_Indication flags to TNGF236.

[0058] In a further step 207, TNGF 236 verifies the request based on the context stored in step 201. TNGF increments the counter and derives a new TNAP key. In a further step 208, TNGF 236 provides an AAA message to TNAP#2 234. The AAA message includes the TNAP key, RAND, and MAC. In other words, based on the re-authentication ID, TNGF 236 identifies UE220 and retrieves the context and TNAP_Mobility_Indication. TNGF 236 checks the validity of the stored context in step 201 and then derives the TNAP key as described in this disclosure. TNGF 236 responds to TNAP#2 234 with the generated key RAND value and the MAC for the RAND value. The Message Authentication Code (MAC) is derived using the TNGF key stored in TNGF 236. In TNAP#2 234, the newly received TNAP key is treated as a pairwise master key (PMK).

[0059] In a further step 209, TNAP#2 234 provides UE 220 with an EAP request / 5G notification. This includes activating secure mode, RAND, and MAC. In a further step 210, UE 220 uses RAND to derive a new TNAP key. TNAP This is a paired master key (PMK). In a further step 211, the key is used to derive the 4-way handshake PMK to establish a secure connection between UE 220 and TNAP#2. In other words, in these steps 209-211, TNAP#2 234 sends an EAP notification to UE 220 with the RAND value and MAC address. If the MAC authentication is successful, UE 220 derives the key based on the RAND value. A 4-way handshake (see IEEE 802.11) is performed, which establishes a security context between the WLAN AP and UE 220. This security context is used to protect over-the-air unicast and multicast services.

[0060] Once process 200 is complete, TNGF 236 can use the security interface of UE 220 for the next interaction to send a new re-authentication ID to UE 220.

[0061] It should be noted that if UE 220 obtains a new IP configuration from TNAP#2 234, UE 220 uses the IKE information request "UPDATE_SA_ADDRESS" to update the SA address to TNGF 236 for further communication.

[0062] During mobility from K TNGF Derivation of K TNAP Use the following input parameters: FC=0xWX; P1=RAND; L1=length of RAND (i.e., 0x00 0x04). The input key KEY should be K. TNGF When deriving K in mobility TNAP At that time, a RAND should be generated and shared with UE 220.

[0063] It should be noted that instead of RAND, COUNT can be used as an input as an alternative. In this case, COUNT is used in place of the RAND information element in the process described above.

[0064] Another potential solution involves using fast BSS transition for TNAP mobility (see IEEE Standard 802.11™-2020 Part 11: "Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specification").

[0065] The Fast BSS Transition (FT) key hierarchy is established by the R0 key holder (R0KH) based on the Master Session Key (MSK), which is co-located with the 802.1X authenticator specified in IEEE Standard 802.11-2016 (a revision of IEEE Standard 802.11-2012) entitled "Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specification" in IEEE Information Technology Standards - Telecommunications and Information Exchange between Systems, Local Area Networks and Metropolitan Area Networks - Specific Requirements - Part 11. To support Fast BSS Transition, the entity holding the root key needs to obtain a 256-bit key (K) from the TNGF. FT This key, K, will then be used as the input key for creating the FT key hierarchy. FT Using fixed input from K TNGF This is derived from K in Annex A.22 of 3GPP TS 33.501, which is similar to the document titled "Security Architecture and Procedures for 5G Systems". TNAP From K TNGF Exported from [source], but using a new type distinguisher, for example, 0x03. Key K FT It is used to create the FT key level specified in IEEE Std 802.11™-2020 Part 11: "Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specification". Specifically, K FT It is used as the master PMK (MPMK), which is used as the input key for deriving the R0 key data. Using the R0-key-data structure, an FT key hierarchy is established. In fact, K... FT The 5G key level is linked to the FT key level because it is derived from the keys in the 5G key level and is used to create the FT key level (see more details). Figure 3 When a UE switches to a new TNAP within the same mobility domain identified by its Mobility Domain Identifier (MDID), the UE performs the fast BSS transition procedure specified in IEEE Std 802.11™-2020 Part 11: "Radio LAN Media Access Control (MAC) and Physical Layer (PHY) Specification". K has already been received from TNGF. FT The entity acts as the key holder (R0KH) of PMK-R0. R0KH derives PMK-R1 from PMK-R0 and provides it to the new AP (i.e., TNAP in TNAN) during the FT process. Figure 3 Example 300 illustrates how 5G and FT key layers are linked together. Example 300 shows MPMK=K FT How to get from K TNGF Exporting from MPMK; how PMK-R0 is exported from MPMK; how PMK-R1 is exported from PMK-R0. The 5G hierarchy is shown as including TNGF and K. TNGF MPMK is shown as being on the boundary between the 5G tier and the FT key tier. The FT key tier includes R0KH and PMK-RO. PMK-R1 is shown as being on the boundary between ROKH and TNAP / R1KH.

[0066] It should be noted that TNGF can K TNAP and K FT All are sent to the entity that holds the root key at the FT key level as the MSK. TNGF sets the MSK to K. TNAP ||K FT MSK is 512 bits, and K TNAP and K FT It is 256 bits. TNGF uses the existing mechanism to send MSK.

[0067] A brief overview of the FT security process is now provided. Full details are provided in IEEE Std 802.11™-2020 Part 11: "Specifications for Radio LAN Media Access Control (MAC) and Physical Layer (PHY)" (which is incorporated herein by reference). FT capabilities are advertised in beacon and probe response frames by including the MDIE. The MDIE, advertised in beacon and probe response frames, indicates the Mobility Domain ID (MDID), FT capabilities, and FT policies. The keys PMK-R0 and PMK-R1 are identified by PMKR0Name and PMKR1Name, respectively. Each AP obtains a different PMK-R1 provided to it to secure communication between the UE and the AP. Finally, the freshness of the service key (PTK) between the UE and the AP is ensured using current values ​​(SNonce from the UE and ANOnce from the AP). Figure 4 The illustration shows an example 400 where a UE is attached to the first AP that leads to the establishment of an FT key hierarchy. This example shows UE 420 and AP 430. The various procedural steps and message flows 401-407 will now be described.

[0068] In initial steps 401-402, UE 420 seeks to connect to AP 430, which is advertising FT capabilities, by inserting the MDE into the beacon and probe response. The MDE informs AP 430 of FT capabilities, mobility domain ID, and potential support for FT on the DS. UE 420 and AP 430 exchange 802.11 authentication request and response (open).

[0069] In a further step 403, UE 420 sends a (re)association request (FT capability) to AP 430, which includes an MDE indicating that UE 420 wants to perform FT within the indicated mobility domain.

[0070] In a further step 404, if AP 430 agrees to the proposed FT adaptation, AP 430 responds with a (re)association response that includes MDE, as well as both R1KH-ID and R0KH-ID.

[0071] In further steps 405a-c, EAP authentication is performed, resulting in both UE 420 and R0KH having PMK-R0 and PMKR0Name. AP 430 is provided with PMK, and UE 420 calculates PMK.

[0072] In a further step 406, a four-way handshake is performed between UE 420 and AP 430.

[0073] In a further step 407, UE 420 and AP 430 begin to securely exchange data.

[0074] It should be emphasized that both UE 420 and R0KH have PMK-R0 and PMKR0Name, and UE 420 has R0KH-ID.

[0075] Figure 5 Example 500 illustrating AP mobility using over-the-air procedures is provided. Example 500 shows UE 520, target AP 530, and R0KH 530. In example 500, UE 520 is already connected to another AP (not shown). The steps and message flows on various procedures 501-507 will now be briefly described.

[0076] In the first step 501, UE 520 provides an 802.11 authentication request to the target AP 530. This request includes PMKR0Name, SNonce, and R0KH-ID.

[0077] In a further step 502, target AP 530 retrieves PMK-R1 from R0KH 535.

[0078] In a further step 503, the target AP 530 provides an 802.11 authentication response to the UE 520. This response includes ANonce and R1KH-ID.

[0079] In a further step 504, UE 520 calculates PMK-R1 and PMKR1Name.

[0080] In a further step 505, UE 520 provides a reassociation request to target AP 530. The reassociation request includes PMKR1Name, ANOnce, SNonce, and MIC.

[0081] In a further step 506, the target AP 530 provides a reassociation response to the UE 520. The reassociation response includes ANonce, SNonce, and MIC.

[0082] In a further step 507, UE 520 and target AP 530 begin to securely exchange data.

[0083] Another potential solution involves secure establishment for TNAP mobility. In this example solution, during the initial registration process (i.e., after successful authentication for trusted non-3GPP access), the UE is provided with a TNGF ID and exchange freshness parameters (such as current values) to facilitate challenge and co-secure establishment between the UE and the trusted non-3GPP access network (i.e., TNGF). Figure 6 An example of authentication 600 for trusted non-3GPP access is shown. Furthermore, if a UE connected to the TNGF via TNAP (i.e., TNAP 1) decides to move to another TNAP (i.e., TNAP 2), the solution proposes using... Figure 7 The security setup process 700 for TNAP mobility is shown.

[0084] exist Figure 6 Example 600 illustrates UE 620, TNAN 630 including TNAP 632 and TNGF 636, AMF 640, and AUSF 650. The various procedural steps and message flows 601-619 will now be briefly described. In Example 600, UE 620 has an L2 interface with TNAP 632, namely Ethernet, 802.3, 802.11, and PPP. In Example 600, TNAP 632 has an AAA interface with TNGF 636.

[0085] In the first step 601, an L2 connection is established between UE 620 and TNAP 632.

[0086] Further steps 601-610a are performed according to steps 1-10a of Section 7A.2.1 of 3GPP TS 33.501. Specifically, in step 610a, AMF 640 provides an N2 initial context establishment request to TNGF 636. This request includes K TNGF .

[0087] In step 610b, TNGF 636 provides an AAA message to TNAP 632. The AAA message includes EAP-Request / 5G-Notification / TNGF address, TNGF-ID, and TNonce. Also in step 610b, TNAP 632 provides an L2 message to UE 620. The L2 message includes EAP-Request / 5G-Notification / TNGF address, TNGF-ID, and TNonce.

[0088] In step 610c, UE 620 provides an L2 message to TNAP 632. The L2 message includes EAP-Response / 5G-Notification / UNonce. Additionally, in step 610c, TNAP 632 provides an AAA message to TNGF 636. The AAA message includes EAP-Response / 5G-Notification / UNonce.

[0089] In step 610d, TNGF 636 provides another AAA message to TNAP 632. This AAA message includes the TNAP key and EAP-Success.

[0090] In step 610e, TNAP 632 provides another L2 message to UE 620. This L2 message includes EAP-Success.

[0091] Steps 610d-619 proceed accordingly to step 10d-19 in section 7A.2.1 of 3GPP TS 33.501.

[0092] and Figure 6 The actual registration process for trusted non-3GPP access steps is described in Clause 4.12a.2.2 of 3GPP specification TS 23.502 entitled "Procedures for 5G Systems," and the relevant authentication steps are shown in Clause 7A.2.1 of 3GPP specification TS 33.501 entitled "Security Architecture and Procedures for 5G Systems." Therefore, the necessary enhancements to steps 610b-610e of Example 600 are described below.

[0093] During the EAP-5G process (i.e., during Figure 6 (Executed in steps 604-610), at step 610, additional access parameters are exchanged between UE 620 and TNGF 636: In step 610b, TNGF 636 sends the TNGF address and TNGF current value (TNonce) to UE 620. Furthermore, in step 610c, UE 620 sends the UE current value (UNonce) to TNGF 636. UE 620 and TNGF 636 can derive the re-authentication ID of UE 620 from the TNGF key using input parameters such as TNGF-ID, the current value of TNGF 636, and the current value of UE 620.

[0094] Now for reference Figure 7 Example 700 illustrates the security establishment process for TNAP mobility, showing UE 720 and TNAN 730 including TNAP1 732, TNAP2 734, and TNGF 736. The various procedural steps and message flows will now be described in 700a-715.

[0095] In the first step 700a, an NWt connection exists between UE 720 and TNGF 736 via TNAP1 732. In the further step 700b, UE 720 determines that it has moved to TNAP2 734.

[0096] In a further step 701, UE 720 establishes a Layer 2 (L2) connection with TNAP2 734.

[0097] In a further step 702, TNAP2 734 typically initiates an EAP session by requesting UE identity. This is performed on an L2 connection that includes the EAP request / identity.

[0098] In a further step 703, UE 720 provides EAP response / identity via L2. This includes a Network Access Identifier (NAI) containing username=re-authentication ID and domain=nai.5gc.tngf <tngf-id>.mnc <mnc>.mcc <mcc>.3gppnetwork.org. Re-authenticate ID as follows Figure 6 The TNGF-ID is exported as shown, and it is received when the UE 720 first connects to the TNGF 736, for example, through initial registration via the TNGF 736. The UE 720 provides Username=Re-authentication ID because the UE 720 does not want to initiate NAS signaling with 5GC, but it wants to utilize the TNGF 736 for re-authentication.

[0099] In further steps 704a-704b, TNAP2 734 selects TNGF 736 based on the TNG1-ID in the received domain and forwards the NAI to TNGF 736. The NAI is forwarded in an AAA request containing the EAP response / identity and the NAI.

[0100] In a further step 705, TNGF 736 locates a stored UE context containing the received re-authentication ID, thus determining that UE 720 is a known UE 720 requesting re-authentication. Therefore, it initiates the following steps. If TNGF 736 does not find a stored UE context containing the received re-authentication ID, TNGF 736 sends an error response to UE 720, initiating signaling procedures related to normal authentication for trusted non-3GPP access, as described in Section 7A.2.1 of the 3GPP specification TS 33.501 entitled "Security Architecture and Procedures for 5G Systems". This is done when UE 720 performs initial registration via TNGF 736 (see...). Figure 6 The UE context is created in TNGF 736.

[0101] In further steps 706a-706b, TNGF 736 sends a 5G-Challenge packet to UE 720, which contains a TNonce value and a Message Authentication Code 1 (MAC1) derived using the TNGF key stored in TNGF 736. This is illustrated as TNGF 736 sending an AAA response to TNAP2 734 including EAP-Request / 5G-Challenge / TNNonce and MAC1. TNAP2 734 then provides EAP-Request / 5G-Challenge / TNonce / MAC1 to UE 720 via L2.

[0102] In a further step 707, UE 720 uses the TNGF key and TNonce stored in UE 720 to derive the expected MAC1 (XMAC1) and compares XMAC1 with the received MAC1. If they match, TNGF 736 is authenticated by UE 720.

[0103] In a further step 708, UE 720 generates UNonce and derives MAC2 using the TNGF key stored in UE 720, along with UNonce and TNonce.

[0104] In further steps 709a-709b, UE 720 responds to TNGF 736 with a 5G-challenge including UNonce, TNonce, and MAC2. This is illustrated as UE 720 responding to TNAP2 734 via L2, including EAP-response / 5G-challenge / UNonce, TNonce, and MAC2. TNAP2 734 then responds to TNGF 736 with an AAA request including EAP-response / 5G-challenge / UNonce / TNonce / MAC2.

[0105] In a further step 710, TNGF 736 uses TNGF, along with UNonce and TNonce, to derive the expected MAC2 (XMAC2). TNGF 736 compares the XMAC2 with the received MAC2. If they match, UE 720 is authenticated by TNGF 736.

[0106] In a further step 711, TNGF 736 derives a fresh re-authentication ID for UE 720, for example, by using the TNGF key, TNGF-ID, TNonce, and UNonce stored in TNGF 736. Additionally, TNGF 736 derives a new TNAP key by using the TNGF key, TNGF-ID, TNonce, and UNonce values ​​stored in TNGF 736.

[0107] In further steps 712a-712b, TNGF 736 completes the EAP-5G session by sending an EAP-Success packet to UE 720 and a new TNAP key to TNAP2 734. This is illustrated as TNGF 736 providing TNAP2 734 with an AAA accept message including the EAP-Success packet and the new TNAP key. TNAP2 734 then provides the EAP-Success packet to UE 720 via L2.

[0108] In a further step 713, UE 720 derives a new re-authentication ID using the TNGF key, TNGF-ID, TNonce, and UNonce stored in UE 720. If UE 720 and TNGF 736 share the same TNGF key, the re-authentication IDs independently derived in UE 720 and TNGF 736 will be identical. Additionally, UE 720 also derives a new TNAP key similar to TNGF 736 (as shown in step 711).

[0109] In further steps 714a-714b, a new TNAP key is applied to establish over-the-air security between UE 720 and TNAP2 734. If necessary, UE 720 may receive new (local) IP configuration information (e.g., a new IP address). The security establishment may be a 4-way handshake for WLAN.

[0110] In a further step 715, UE 720 resumes communication with TNGF 736 via TNAP2 734 (NWt connection).

[0111] Another potential solution involves using TNAP mobility with a modified ERP. In this example, the key rRK is from K. TNGF The derivation of rRK is performed according to Section 4.1 of RFC 6696 entitled "EAP Extension for EAP Re-authentication Protocol (ERP)", replacing the input key EMSK with the key K. TNGF The lower-level keys (rIK, rMSK1, etc.) are derived from the rRK according to RFC standard 6696. The difference is that no additional key needs to be transmitted from the AMF, nor is an ERP request required. Another difference compared to ERP is that in standard ERP, the AMF would need to receive an instruction to derive the rRK during master authentication. This is called the bootstrapping step of ERP. However, with the proposed modification, a similar bootstrapping is not required because the rRK will be based on the key present in the TNGF. TNGF This means that the bootstrapping is implicit, not explicit. TNGF can derive rRK upon receiving a mobility request, or at any convenient time. Figure 8 Example 800 provides an updated key hierarchy for trusted non-3GPP access that supports TNAP mobility. Example 800 illustrates K... TNGF 801 Key transfer from AMF 810 to trusted N3GPP access key. K TNGF 801 is shown as being used to derive key K in TNGF 820. TIPSec 802. Then, K TIPSec 802 is used to establish IPSec SAs, 803 and sub-SAs, and 804. TNAP 805 also comes from the K of TNAP 830 TNGF Exported from 801. rRK 806 is also derived from the K of TNGF 840. TNGF Exported in 801. rRK 806 was used to export rIK 807 and RMSK. 1-n 808.

[0112] While numerous candidate solutions have been discussed to date, none address the problem described in this paper. Specifically, the TNGF, which needs to provide the security key to the TNAP, will be unaware of the UE's re-authentication capabilities (i.e., whether it supports re-authentication-related enhancements or methods, and what re-authentication methods the UE supports). The TNGF also lacks knowledge of the TNAP's re-authentication capabilities (i.e., whether it supports re-authentication-related enhancements or methods, and which re-authentication methods the TNAP supports). Therefore, any re-authentication attempt between the UE and the TNAP / TNGF will fail.

[0113] As previously discussed, in non-3GPP access networks, different TNAPs can support different re-authentication protocols, such as FT protocols based on IEEE 802.11 or (multiple) other non-FT protocols, such as any of the following: 3GPP local re-authentication protocols (re-authentication and secure establishment procedures or protocols specified by 3GPP), ERP, or modified ERP, etc. Embodiments of this disclosure present novel features that enable the UE and TNAP to indicate their respective re-authentication capabilities, allowing the TNGF in the network to select a re-authentication method, generate the necessary re-authentication security context (specific to the supported and selected re-authentication method), and supply the security context to the TNAP to successfully perform re-authentication and secure establishment during UE mobility scenarios. Following successful UE mobility (across different TNAPs) and secure establishment, the embodiments herein also provide the AMF with a TNGF report of the new serving TNAP identifier (acting as UE location information) to allow the network to know the updated location information of the UE. Furthermore, embodiments herein propose a method for supporting UE mobility between APs with FT capabilities and APs without FT capabilities. These embodiments will now be discussed in more detail.

[0114] Some embodiments provide a method for indicating, selecting, and using supported re-authentication protocols / procedures for UE mobility in trusted non-3GPP access, and further provide related enhancements to the registration / authentication process.

[0115] The Trusted Non-3GPP Access Network connects to the 5G Core Network via the Trusted Non-3GPP Gateway Function (TNGF). The TNGF interfaces with the 5G Core Network CP and UP operate via the N2 and N3 interfaces, respectively.

[0116] The embodiments describe how the UE and TNAP indicate / notify the network (i.e., TNGF in the case of trusted non-3GPP access) of their respective re-authentication capabilities. UE re-authentication capability information may indicate whether the UE supports any one or more of the following: FT protocol (for fast BSS transition), non-3GPP access key refresh (TNGF key refresh, N3IWF key refresh), non-3GPP access re-authentication / 3GPP local re-authentication / TNAP mobility security, and modified ERP / ERP. Similarly, TNAP re-authentication capability information may indicate whether the TNAP supports any one or more of the following: FT protocol (for fast BSS transition), non-3GPP access re-authentication / 3GPP local re-authentication / TNAP mobility security, and modified ERP / ERP. Furthermore, the TNGF determines which type of re-authentication to initiate for the UE mobility scenario based on the received UE re-authentication capabilities and TNAP re-authentication capabilities, then generates the relevant security context and provides it to the TNAP, and (via the TNAP) indicates to the UE the selected re-authentication type (or) the type of security context to be exported at the UE for further security establishment.

[0117] Figures 9A-9B provide an example embodiment 900 of the exchange of UE and TNAP re-authentication capabilities during authentication for trusted non-3GPP access of a UE, according to various aspects disclosed herein. Example 900 in Figures 9A-9B illustrates a UE 920, a TNAN 930 including TNAP 932 and TNGF 936, an AMF 940, and an AUSF 950. L2 interfaces (i.e., Ethernet, 802.3, 802.11, PPP, etc.) are available between the UE 920 and TNAP 932. AAA interfaces are available between TNAP 932 and TNGF 936. Various procedural steps / messaging flows 901-915b of example 900 will now be described. It should be noted that Figure 9A illustrates procedural steps / messaging flows 901-908d, and Figure 9B illustrates procedural steps / messaging flows 909a-915b. Steps 909a-915b should be understood as following steps 901-908d in Example 900. The representation of steps 901-915b in Figures 9A and 9B is purely for illustrative purposes.

[0118] In Example 900, UE 920 selects a PLMN and a TNAN 930 for connection to that PLMN using the trusted non-3GPP access network selection process specified in Clause 6.3.12 of 3GPP specification TS 23.501 entitled "Security Aspects Study for Supporting Phase 2 of 5G Radio and Wired Convergence (5WWC)". During this process, UE 920 discovers that the TNAN 930 supports a PLMN with trusted connectivity (e.g., "5G connectivity").

[0119] Example 900 should be discussed further with reference to Figure 9A. In the first step 901, a Layer 2 connection is established between UE 920 and TNAP 932. In the case of IEEE 802.11 (see IEEE standard 802.11-2016 entitled "Specification for Media Access Control (MAC) and Physical Layer (PHY) of Wireless LANs" (a revision of IEEE standard 802.11-2012), IEEE Information Technology Standards - Telecommunications and Information Exchange between Systems, LANs and Metropolitan Area Networks - Specific Requirements - Part 11), this step corresponds to 802.11 association. In the case of PPP, this step corresponds to PPP LCP negotiation. In other types of non-3GPP access (e.g., Ethernet), this step may not be required.

[0120] In further steps 902-903, the EAP authentication process is initiated. The EAP message should be encapsulated into Layer 2 packets, such as IEEE 802.3 / 802.1x packets, IEEE 802.11 / 802.1x packets, PPP packets, etc. This is illustrated as TNAP 932 providing 'L2 (EAP-Request / Identity)' to UE 920, and UE 920 responding to TNAP 932 using 'L2 (EAP-Request / Identity), username@domain)'. UE 920 provides a NAI (i.e., username@domain), which triggers TNAP 932 to send an AAA request to TNGF 936. Between TNAP 932 and TNGF 936, EAP packets are encapsulated into an AAA message. The AAA request also includes a TNAP identifier, which can be considered user location information. It should be noted that, according to Section 4.12a.2.2 'Registration Procedure for Trusted Non-3GPP Access' of 3GPP specification TS 23.501 entitled "System Architecture for 5G Systems (5GS)", the TNAP identifier can be considered user location information. It should also be noted that if UE 920 requests "5G connectivity" from a specific PLMN, the NAI can include or be constructed as...<any_username> @nai.5gc.mnc <mnc>.mcc <mcc>.3gppnetwork.org”, or if UE 920 requests a “5G connection” to a specific SNPN, then NAI="<any_username> @nai.5gc.nid <nid>.mnc <mnc>.mcc <mcc>.3gppnetwork.org; or, if the WLANSP rule contains information including the TNGF ID to be used for a specific slice, and UE 920 supports this information, then UE 920 constructs a field NAI, where the TNGF ID is considered to be "".<any_username> @tngfid<TNGF ID> .nai.5gc.mnc <mnc>.mcc <mcc>.3gppnetwork.org”).

[0121] In further steps 904-910, the EAP-5G procedure specified in Clause 7.2.1 of 3GPP TS 33.501 is performed, wherein the EAP-Request / 5G-Start packet from TNGF 936 notifies UE 920 to initiate an EAP-5G session, i.e., to begin sending a NAS message encapsulated within an EAP-5G packet. This is shown as an AAA message, which includes the EAP-Request / 5G-Start provided from TNGF 936 to TNAP 932, and then the EAP-Request / 5G-Start provided from TNAP 932 to UE 920 via L2. Further modifications to this procedure will now be discussed. It should be noted that the EAP-5G packet should not be encapsulated as an IKEv2 packet.

[0122] In a further step 905a, UE 920 may send an EAP-Response / 5G-NAS packet containing a registration request message that includes UE security capabilities, UE re-authentication capabilities, and SUCI. If UE 920 already has 5GC access on 3GPP and an available security context exists, UE 920 can fully protect the registration request message and should send a 5G-GUTI instead of SUCI. TNGF 936 can avoid sending an EAP-Identity Request. UE 920 can ignore the EAP-Identity Request or respond with the SUCI / 5G-GUTI it sent in the registration request. If UE 920 has already registered to the same AMF 940 via 3GPP access, and if this is the first time UE 920 has connected to 5GC via non-3GPP access, the value of the corresponding UL NAS COUNT used for integrity protection is 0; otherwise, it can use an existing non-3GPP specific UL NAS COUNT for integrity protection. In some embodiments, UE 920 may send UE re-authentication capability as a separate IE in the EAP-Response / 5G-NAS packet (which will be forwarded by TNAP 932 to TNGF 936). UE 920 should also include the UE ID in the AN parameters, for example, 5G-GUTI (if obtainable from a previous registration to the same PLMN). This is illustrated as UE 920 providing '(EAP-Res / 5G-NAS / AN-Params (S-NSSAI or 5G-GUTI), NAS-PDU (Reg.Req (UE re-authentication capability))' to TNAP 932 via L2.

[0123] In a further step 905b, TNAP 932 sends the TNAP re-authentication capability to TNGF 936 via the AAA interface (or message). The received EAP-Response / 5G-NAS packet containing the registration request message is also forwarded. This is illustrated as TNAP 932 providing '(EAP-Res / 5G-NAS / AN-Params (S-NSSAI or 5G-GUTI), NAS-PDU (Reg.Req (UE re-authentication capability)), TNAP re-authentication capability)' to TNGF 936 via AAA. It should be noted that, alternatively, the new IE sent by UE 920 in step 905 can be sent unprotected as a separate IE, in which case no adaptation is required in subsequent steps 906a and 910a.

[0124] In further steps 906a-906b, TNGF 936 selects AMF 940 as specified in Clause 6.5.3 of 3GPP specification TS 23.501 entitled "System Architecture of 5G Systems (5GS)". TNGF 936 forwards the registration request received from UE 920 (which also includes UE security capabilities, UE re-authentication capabilities, and SUCI) to AMF 940. As shown in the figure, 'AMF selection' is being performed at TNGF 936, and TNGF 936 provides an N2 message to AMF 940 via N2, which includes '(Registration Request (UE Re-authentication Capability))'. It should be noted that if TNAP re-authentication capability is received, TNGF 936 may store the TNAP re-authentication capability along with the TNAP identifier.

[0125] Further steps 907a-907d and 908a-908d will now be described.

[0126] If the AMF 940 receives the 5G-GUTI and the registration is protected by integrity, it can use the security context to verify the integrity protection, as described in Clause 6.4.6 of 3GPP specification TS 33.501. If the UE 920 has already registered to the same AMF 940 via 3GPP access, and if this is the first time the AMF 940 has received the UE's NAS signaling via non-3GPP access, the value of the corresponding UL NAS COUNT used for integrity verification is 0; otherwise, it can use an existing non-3GPP specific UL NASCOUNT for integrity verification. If integrity is successfully verified, the UE 920 is instructed to be authenticated by the AMF 940. Various messages 907a-907b illustrate this process. More specifically, step 907a shows the AMF 940 and TNGF 936 exchanging an N2 message including '(Identity Request / Response)'. Step 907b shows TNGF 936 and TNAP 932 exchanging '(EAP-REQ / RES / 5G-NAS / NAS-PDU (Identity Request / Response))' via AAA; and TNAP 932 and UE 920 exchanging '(EAP-REQ / RES / 5G-NAS / NAS-PDU (Identity Request / Response))' via L2. If integrity is successfully verified and no newer security context is activated via 3GPP access, steps 909 to 911 can be skipped. If integrity is successfully verified and a newer security context has been activated via 3GPP access, authentication can be skipped, but AMF 940 should activate the newer context using the NASSMC procedure, as described in step 909 and thereafter. Otherwise, AMF 940 should authenticate UE 920.

[0127] If AMF 940 decides to authenticate UE 920, it should use one of the authentication methods discussed in Section 6.1.3 of 3GPP document TS 33.501 entitled "Security Architecture and Procedures for 5G Systems". In this case, AMF 940 should send a key request to AUSF 950, as shown in step 908a, 'Nausf_UEAuthentication Authentication Request (SUPI or SUCI)'. AUSF 950 can initiate the authentication process specified in Section 6.1.3 of 3GPP document TS 33501 entitled "Security Architecture and Procedures for 5G Systems". This authentication process is shown in step 908b as "Authentication and Key Negotiation". Between AMF940 and UE920, the authentication packet is encapsulated in a NAS authentication message, and the NAS authentication message is carried in the N2 signaling between AMF940 and TNGF936, and then encapsulated in an EAP-5G / 5G-NAS packet between TNGF936 and UE920.

[0128] In the final authentication message from the home network, AUSF 950 should transfer the authentication information from K. AUSF The anchor key K exported from the source SEAF Send to SEAF. SEAF should receive it from K. SEAF Derivation of K AMF The UE 920 then sends this key to the AMF 940, which uses it to derive the NAS security key. This is shown in step 908c as 'Nausf_UEAuthentication Authentication Response (SEAF Key, EAP-Success)'. If 'EAP-AKA' is used for authentication as described in Clause 6.1.3.1 of 3GPP document TS33.501 entitled "Security Architecture and Procedures for 5G Systems", then the AUSF 950 should include EAP-Success. The UE 920 also derives the anchor key K. SEAF And derive K from that key AMF Next is the NAS security key. This is shown in step 908d as 'Create TNGF / TNAP Key'. The NAS count associated with the NAS connection identifier "0x02" is set at UE 920 and AMF 940.

[0129] The discussion of Example 900 should continue to Figure 9B. In further steps 909a-909b, TNGF 936 forwards the NAS SMC received from AMF 940 to UE 920 within the EAP-Request / 5G-NAS packet. More specifically, AMF 940 provides TNGF 936 with an N2 message including '(SMC Request [EAP-Success])'. TNGF 936 provides '(EAP-REQ / 5G-NAS / NAS-PDU (SMC Request [EAP-Success])' to TNAP 932 via AAA. TNAP 932 then provides '(EAP-REQ / 5G-NAS / NAS-PDU (SMC Request [EAP-Success], TNGF address)' to UE 920 via L2.

[0130] In further steps 909c-909d, UE 920 completes authentication (if initiated in step 907) and creates a NAS security context or activates another NAS security context based on the ngKSI received in the NAS SMC. UE 920 should respond to the NAS SMC received from AMF 940 based on the selected algorithm and parameters, as described in Clause 6.7.2 of 3GPP document TS 33.501 entitled "Security Architecture and Procedures for 5G Systems". UE 920 should encapsulate the NAS SMC Complete message in an EAP-5G response. More specifically, UE 920 provides '(EAP-Res / 5G-NAS / SMCComplete)' to TNAP 932 via L2. TNAP 932 forwards it to TNGF 936 via AAA. TNGF 936 then provides the AMF 940 with an N2 message including the SMC Complete message.

[0131] In further steps 910a-910d, after successful authentication, a K is created in UE 920 and AMF 940 as described below. TNGF (For trusted non-3GPP access) (equivalent to K for untrusted non-3GPP access) N3IWF In step 910a (within the N2 initial context establishment request), K TNGF Transmitted from AMF 940 to TNGF 936. If AMF 940 receives the UE re-authentication capability in the registration request in step 906b, AMF 940 also sends the UE re-authentication capability to TNGF 936 in step 910a. This is shown as 'N2 Initial Context Establishment Request (KTNGF), UE Re-authentication capability'.

[0132] When from K AMF Export key K from the uplink NAS COUNT WAGF K TNGF K TWIF and K N3IWF In UE 920 and AMF 940, the following parameters should be used to form the input S of the KDF: FC=0x6E; P0=Uplink NAS COUNT; L0=Length of Uplink NAS COUNT (i.e., 0x00 0x04); P1=Access Type Discriminator; L1=Length of Access Type Discriminator (i.e., 0x00 0x01). The values ​​of the Access Type Discriminator are defined in Table 1 below. Values ​​0x00 and 0x03 to 0xf0 are reserved for future use, and values ​​0xf1 to 0xff are reserved for private use. In deriving KDF... N3IWF K WAGF K TWIF or K TNGF At this time, the access type distinguisher should be set to a non-3GPP value (0x02). The input key KEY should be a 256-bit K. AMF . Table 1

[0133] It should be noted that including UE re-authentication capability information in the registration request from UE 920 to AMF 940 provides integrity and / or confidentiality protection (using NAS security). Therefore, if available in the registration request, AMF 940 can provide UE re-authentication capability to TNGF 936 in step 910a.

[0134] Furthermore, TNAP 932 is a trusted entity. TNGF 936 should generate K as follows. TNAP And in step 910b (i.e., within the AAA message), it is transmitted from TNGF 936 to TNAP 932.

[0135] From K TNGF Derivation of K TIPSec and from K TWIF or K TNGF Derivation of K TNAP When deriving a KDF, the following parameters should be used to form the input S: FC = 0x84; P0 = type separator; L0 = length of the type separator (i.e., 0x00 0x01). The values ​​for the type separator are defined in Table 2 below. Values ​​0x00 and 0x03 to 0xf0 are reserved for future use, and values ​​0xf1 to 0xff are reserved for private use. TIPSec When using this method, the type distinguisher should be set to the value of IPSec (0x01). In exporting K... TNAP When using this method, the type distinguisher should be set to the value of TNAP (0x02). The input key KEY should be a 256-bit key. TNGF or K TWIF . Table 2

[0136] After receiving the TNGF key from AMF 940 in step 910a, TNGF 936 should send an EAP-Request / 5G-Notification packet containing "TNGF Contact Information" to UE 920 in step 910b, which includes the TNGF's IP address. This is illustrated as TNGF 936 providing '(EAP-Req / 5G-Notification / TNGF Address)' to TNAP 932 via AAA. TNAP 932 then forwards it to UE 920 via L2. Then, in step 910c, UE 920 provides EAP-Res / 5G-Notification to TNAP 932 via L2. TNAP 932 forwards it to TNGF 936 via AAA. In step 910d, after receiving the EAP-Response / 5G-Notification packet from UE 920 in step 910c, TNGF 936 can select the re-authentication method / type to be used for UE 930 (now or later during UE mobility, as described herein). TNGF 936 then sends a message containing the selected re-authentication method (IE), security key information specific to the selected re-authentication method, and an EAP-Success packet. In other words, based on the re-authentication support capabilities of UE 920 and TNAP 932, one selects the re-authentication method(s) to be used preferentially, and provides re-authentication method-specific security information in step 910e or later during mobility.

[0137] The selected re-authentication method (IE) may indicate any of the following: FT protocol (for fast BSS transition); non-3GPP access re-authentication / 3GPP local re-authentication / TNAP mobility security; modified ERP / ERP.

[0138] If the FT protocol (for fast BSS transition) is selected, the FT key is exported and provided as security key information in addition to the TNAP key. If non-3GPP access re-authentication / 3GPP local re-authentication / TNAP mobility security is selected, freshness parameters (such as current value / counter / random number and re-authentication identifier) ​​are generated and provided as security key information for future mobility, in addition to the TNAP key. If modified ERP / ERP is selected, the rRK and re-authentication identifier are exported and stored, and the re-authentication identifier is provided in addition to the TNAP key.

[0139] Alternatively, if only FT is selected, the FT key is exported and provided. Alternatively, TNGF 936 stores the received UE re-authentication capability along with the UE context for later use in selecting a secure re-authentication method during actual UE mobility. In this case, the selected re-authentication method information is not sent to UE 920 in step 910e (via TNAP 932).

[0140] UE 920 and TNGF 936 can derive a re-authentication identifier (re-authentication ID) for UE 920 from the TNGF key using input parameters such as TNGF-ID, the current value of TNGF 936, and the current value of UE 920. Alternatively, for example, the re-authentication identifier (re-authentication ID) can be generated as... <plmnid><TNGF_ID><Temp Id>.

[0141] Step 910e shows that TNGF 936 provides 'TNAP key, EAP-Success, selected re-authentication method(IE)(s), security information (FT key / re-authentication ID / non-node / TNGF ID / TNGF address)' to TNAP 932 via AAA. TNAP 932 provides EAP-Success and optional selected re-authentication method(s) to UE 920.

[0142] In a further step 911, UE 920 and TNAP 932 use the public TNAP key to derive a security key based on the applied non-3GPP technology and establish a security association to protect all subsequent services. In the case of IEEE 802.11 (see IEEE Standard 802.11-2016, a revision of IEEE Standard 802.11-2012 entitled "Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specifications" IEEE Information Technology Standards - Telecommunications and Information Exchange between Systems, Local Area Networks and Metropolitan Area Networks - Specific Requirements - Part 11), K TNAP A pair of master keys (PMK) is used, and a 4-way handshake is performed (see IEEE 802.11 above). This establishes a security context between the WLAN AP and UE 920, which is used to protect over-the-air unicast and multicast services. From this step onwards, all messages between UE 920 and TNAP 932 are encrypted and protected for integrity. Step 911 involves establishing a secure connection using a key derived from the MSK key (e.g., the WLAN 4-way handshake).

[0143] It should be noted whether step 911 is performed outside the scope of this disclosure. The current procedure assumes that Layer 2 encryption protection between UE 920 and TNAP 932 will be enabled.

[0144] In a further step 912, the UE 920 receives IP configuration from the TNAN 932, for example, via DHCP. This is shown as 'Local IP Configuration'.

[0145] In further steps 913a-913c, UE 920 should initiate an IKE_INIT exchange with TNGF 936. In step 909b, UE 920 has already received the IP address of TNGF 936 during EAP-5G signaling; subsequently, UE 920 should initiate an IKE_AUTH exchange, and should include the same UE ID as provided in step 905 (i.e., SUCI or 5G-GUTI). Public K TIPSe Used for mutual authentication. Key K TIPSec This is derived according to Annex A.22 of 3GPP document TS33.501 entitled "Security Architecture and Procedures for 5G Systems". NULL encryption is negotiated according to RFC 2410. After step 913c, an IPsec SA (i.e., NWt connection) is established between UE 920 and TNGF 936, and it is used to transmit all subsequent NAS messages. This IPsec SA is not encrypted, only integrity protection is applied. For completeness, step 913a between UE 920 and TNGF 936 is shown as 'IKE_INIT'; step 913b between UE 920 and TNGF 936 is shown as 'IKE_AUTH(Idi, SA, TSi, TSr, AUTH)'; and step 913c between UE 920 and TNGF 936 is shown as 'IKE_AUTH(Idr, SA, TSi, TSr, AUTH)'.

[0146] In a further step 914a, after the NWtp connection is successfully established, the TNGF 936 responds to the AMF 940 with an N2 Initial Context Establishment Response message, which contains the UE ID (5G-GUTI) and the identifier of the current serving TNAP.

[0147] In a further step 914a, AMF 940 may determine whether TNGF 936 is suitable for the selected slice as defined in Section 4.12.2.2 of 3GPP specification TS23.502. If it is compatible with the selected TNGF 936, the process continues to step 915a if registration is accepted. Otherwise, AMF 940 will continue to alternative step 915a if registration is rejected.

[0148] In further steps 915a-915b, the NAS registration accept message is sent by AMF 940 and forwarded by TNGF 936 to UE 920 along with a re-authentication method (if selected) (if this message was not provided by an established NWt connection in step 910e). This is illustrated as AMF 940 providing an N2 message including NAS registration accept / reject to TNGF 936. TNGF 936 then provides NAS registration accept (and optionally the selected re-authentication method) to UE 920 via the NWt-cp connection; or provides NAS registration reject via NAS through Ipsec.

[0149] UE 920 initiates PDU session establishment. TNGF 936 can establish one or more IPSec sub-SAs for each PDU session. User plane data for the established PDU session is transmitted between UE 920 and TNGF 936 within the established IPSec sub-SA.

[0150] In an alternative scenario, steps 915a-915b may include the AMF 940 triggering a UE policy update procedure and updating the UE policy. The AMF 940 should send a registration rejection message to the UE 920 via the TNGF 936. The registration rejection message is encrypted and integrity-protected, and a new 5G-GUTI is provided to the UE 920. The UE 920 should decrypt and verify the integrity of the registration rejection message. If the verification is successful, the UE 920 proceeds to step 21 of section 4.12.2.2 of the 3GPP specification TS 23.502 and sends an integrity-protected registration request message to the AMF 940 via the newly selected TNGF 936.

[0151] It should be noted that Example 900 can also be adapted for untrusted non-3GPP access networks as follows: Untrusted non-3GPP access networks can connect to the 5G core network via a Non-3GPP Interoperability Function (N3IWF) instead of a Trusted Non-3GPP Gateway Function (TNGF) 936. The N3IWF interfaces with the 5G core network CP and UP operate via the N2 and N3 interfaces, respectively. The process described in Example 900 can also be used for untrusted non-3GPP access networks, the only difference being that the TNAN930 with TNGF 936 and TNAP 932 is replaced with an untrusted non-3GPP access node / point.

[0152] Other embodiments disclosed herein relate to methods for indicating, selecting, and using re-authentication protocols / procedures for UE mobility support in trusted non-3GPP access, and also to enhancements to the mobility / re-authentication process. These embodiments describe how the UE and the new / target TNAP indicate / notify the network (i.e., TNGF in the case of trusted non-3GPP access) of their respective re-authentication capabilities during UE mobility scenarios. UE re-authentication capability information may indicate whether the UE supports any one or more of the following: FT protocol (for fast BSS transition), non-3GPP access key refresh (TNGF key refresh, N3IWF key refresh), non-3GPP access re-authentication / 3GPP local re-authentication / TNAP mobility security, and modified ERP / ERP. Similarly, TNAP re-authentication capability information may indicate whether the TNAP supports any one or more of the following: FT protocol (for fast BSS transition), non-3GPP access re-authentication / 3GPP local re-authentication / TNAP mobility security, and modified ERP / ERP. The TNGF can check during the UE mobility process whether the received re-authentication capability matches the re-authentication capability stored in the previous (initiated / initial) registration (as described previously with reference to Figures 9A-9B) to verify that the re-authentication capability has not been tampered with. Furthermore, based on the received UE re-authentication capability and the TNAP re-authentication capability, the TNGF determines which type of re-authentication to initiate for the UE mobility scenario, then generates the relevant security context and provides it to the TNAP, and (via the TNAP) indicates the selected re-authentication type to the UE, or indicates the type of security context to be exported at the UE for further re-authentication and security (re)establishment.

[0153] Based on the aspects disclosed herein, Figures 10A-10C provide an example embodiment 1000 of the exchange of UE and TNAP re-authentication capabilities during re-authentication / mobility for UE trusted non-3GPP access. Example embodiment 1000 illustrates UE 1020, TNAN 1030 including TNAP1 1032, TNAP 1034, and TNGF 1036. Further illustrated is AMF 1040. Various procedural steps / message flows 1000a-1017c will now be described with reference to Figures 10A-10C. In this respect, it should be understood that Figures 10B-10C correspond to those described in Figure 10A. Option 1 and Option 2 In other words, the figures provided in Figures 10B-10C Option 1 and Option 2 For illustrative purposes only, and should not be construed as using Option 1 or Option 2 This is part of an example embodiment 1000.

[0154] In Example 1000, it is assumed that UE 1020 and TNGF 1036 initially established an NWt connection via TNAP1 1032. In fact, TNAP1 1032 can be considered as... current TNAP. This is as shown in step 1000a. At step 1000b, UE1020 determines that it has moved to TNAP2 1034. In fact, TNAP2 1034 can be considered as Target TNAP.

[0155] In a further step 1001, UE 1020 establishes a Layer 2 (L2) connection with TNAP2 1034. TNAP2 1034 determines whether it has FT capability.

[0156] In a further step 1002, if TNAP2 1034 supports FT, then if the security key is available from the FT key holder (i.e., the old TNAP such as TNAP1 1032, etc.), then TNAP2 1034 can perform FBSS based on IEEE 802.11.

[0157] Otherwise, if TNAP2 1034 does not support FT, but if TNAP2 1034 supports (i.e., TNAP re-authentication capabilities include) non-3GPP access re-authentication / 3GPP local re-authentication / TNAP mobility security or modified ERP / ERP, then TNAP2 1034 typically initiates an EAP session by requesting UE identity. For the purposes of Example 1000, TNAP2 1034 determines that it does not support FT. Step 1002 shows TNAP2 1034 providing EAP-Req / identity to UE 1020 via L2.

[0158] In a further step 1003, UE 1020 provides EAP-Response / Identity to TNAP2 1034 via L2. A Network Access Identifier (NAI) is also provided, which contains Username=Re-authentication ID and Domain=nai.5gc.tngf <tngf-id>.mnc <mnc>.mcc <mcc>3gppnetwork.org and UE re-authentication capabilities. Re-authentication ID such as... Figure 6 The TNGF-ID is exported as shown, and it is received when UE 1020 first connects to TNGF 1036, for example, during initial registration via TNGF 1036. UE 1020 provides Username=Re-authentication ID because UE 1020 does not want to initiate NAS signaling via 5GC, but it wants to re-authenticate with TNGF 1036. Alternatively, if TNGF 1036 provides the Re-authentication ID during registration, UE 1020 can provide the received re-authentication in step 1001.

[0159] In further steps 1004a-1004b, TNAP2 1032 selects TNGF 1036 based on the TNG1-ID in the received domain and forwards the NAI and the received UE re-authentication capability to TNGF 1036. Additionally, TNAP2 includes its own TNAP re-authentication capability information and TNAP ID, and provides these to TNGF 1036. Step 1004a describes TNAP2 1034 selecting TNGF 1036. Step 1004b describes TNAP2 1034 providing an AAA request to TNGF 1036, the AAA request including (EAP-Res / identity NAI, UE re-authentication capability), TNAP re-authentication capability, and TNAP ID.

[0160] In a further step 1005a, TNGF 1036 looks up the stored UE context containing the received re-authentication ID and UE re-authentication capabilities, thus determining that UE 1020 is a known UE requesting re-authentication. Therefore, it initiates the following steps of Example 1000. If TNGF 1036 does not find a stored UE context containing the received re-authentication ID, TNGF 1036 sends an error response to UE 1020 and initiates a signaling procedure related to normal authentication for trusted non-3GPP access, as described in Clause 7A.2.1 of 3GPP specification TS 33.501. TNGF 1036 may check whether the received re-authentication capabilities match the UE re-authentication capabilities stored in the (initial) registration (as described herein with respect to Figure 9) to verify that the re-authentication capabilities have not been tampered with.

[0161] In a further step 1005b, based on the UE's re-authentication capability and the received TNAP re-authentication capability, TNGF 1036 selects a common re-authentication method supported by both UE 1020 and TNAP2 1034 for re-authentication during mobility. Based on the selected re-authentication method, TNGF 1036 also derives a re-authentication security context. TNGF 1036 also provides the derived re-authentication security context to the new TNAP2 1034 and indicates the specific information of the selected re-authentication method to be forwarded to UE 1020 (i.e., security information for the derived key), allowing UE 1020 to derive the same re-authentication security context as TNGF 1036.

[0162] The steps in the re-authentication procedure will vary depending on the re-authentication process selected. For example, if non-3GPP access re-authentication / 3GPP local re-authentication / TNAP mobility security is selected, the procedure shown in Figure 10B will be followed. Option 1 The recertification process will then proceed. More specifically, steps 1006a-1013 of Figure 10B will be performed, followed by steps 1015-1017c of Figure 10A. If a modified ERP / ERP is selected, the process will follow the steps shown in Figure 10C. Option 2 The re-authentication process will be performed. More specifically, steps 1014a-1014d of Figure 10C will be executed, followed by steps 1015-1017c of Figure 10A.

[0163] Now we will discuss Option 1 and Option 2 The process. It should be noted that when UE 1020 performs initial registration via TNGF 1036, the UE context (e.g., TNGF key, UE ID) is created / provided in TNGF 1036.

[0164] For discussion Option 1 Figure 10B will be described.

[0165] In further steps 1006a-1006b, TNGF 1036 sends a 5G-challenge packet to UE 1020. This 5G-challenge packet contains a TNonce value, a selected re-authentication type / method (optionally sent in this step, or in a later step 1012a), and a Message Authentication Code 1 (MAC1) derived using the TNGF key stored in TNGF 1036. More specifically, in step 1006a, TNGF 1036 provides an AAA response to TNAP2 1034, which includes '(EAP-Req / 5G-challenge / TNonce, selected re-authentication type / method, MAC1)'. TNAP2 1034 then provides EAP-Req / 5G-challenge / TNonce and MAC1 to UE 1020 via L2.

[0166] In a further step 1007, UE 1020 (understanding the type of re-authentication to be performed based on the selected re-authentication type / method indicated in steps 1006a / 1006b) uses the TNGF key and TNonce stored in UE 1020 to derive the expected MAC1 (XMAC1). UE 1020 compares XMAC1 with the received MAC1. If they match, TNGF 1036 is authenticated by UE 1020.

[0167] In a further step 1008, UE 1020 uses the TNGF key stored in UE 1020, along with UNonce and TNonce, to generate UNonce and export MAC2.

[0168] In further steps 1009a-1009b, UE 1020 responds to TNAP2 1034 via L2 with an EAP-Response / 5G-Challenge containing UNonce, TNonce, and MAC2. TNAP2 1034 then provides AAA request to TNGF 1036 containing EAP-Response / 5G-Challenge, UNonce, TNonce, and MAC2.

[0169] In a further step 1010, TNGF 1036 uses the TNGF key, along with UNonce and TNonce, to derive the expected MAC2 (XMAC2). TNGF 1036 compares the XMAC2 with the received MAC2. If they match, UE 1020 is authenticated by TNGF 1036.

[0170] In a further step 1011, TNGF 1036 derives a fresh re-authentication ID for UE 1020, for example, by using the TNGF key, TNGF-ID, TNonce, and UNonce stored in TNGF 1036. Furthermore, TNGF 1036 derives a new TNAP key by using the TNGF key, TNGF-ID, TNonce, and UNonce values ​​stored in TNGF 1036.

[0171] In further steps 1012a-1012b, TNGF 1036 completes the EAP-5G session by sending an EAP-Success packet and the selected re-authentication type / method to UE 1020 and a new TNAP key to TNAP2 1034. More specifically, step 1012a is shown as TNGF 1036 providing AAA acceptance to TNAP2 1034, which includes EAP-Success, the new TNAP key, and the selected re-authentication type / method. In step 1012b, TNAP2 1034 provides EAP-Success and the selected re-authentication type / method to UE 1020 via L2.

[0172] In a further step 1013, UE 1020 derives a new re-authentication ID based on the indicated selected re-authentication type / method (in steps 1006a / b or 10012b) using the TNGF key, TNGF-ID, TNonce, and UNonce stored in UE 1020. If UE 1020 and TNGF 1036 share the same TNGF key, the re-authentication IDs independently derived in UE 1020 and TNGF 1036 will be identical. Furthermore, UE 1020 also derives a new TNAP key similar to TNGF 1036 (as shown in step 1011).

[0173] To discuss option 2, Figure 10C will be described.

[0174] In the first step 1014a, TNGF 1036 derives rRK and rMSK (as new TNAP keys) and stores them together with the re-authentication ID.

[0175] In a further step 1014b, TNGF 1036 sends an EAP-Success message or an EAP completion / re-authentication message along with a new TNAP key (rMSK) and the selected re-authentication type / method in the AAA response.

[0176] In a further step 1014c, TNAP2 1034 forwards the EAP-Success message or EAP completion / re-authentication message from the L2 message, along with the received selected re-authentication type / method indication / information, to UE 1020.

[0177] In a further step 1014d, based on the indicated selected re-authentication type / method, UE 1020 understands the type of re-authentication performed, and derives rRK and rMSK into a new TNAP key (similar to TNGF 1036), and stores it together with the re-authentication ID.

[0178] Returning to Figure 10A, steps 1015a-1017c of the remaining procedure will now be discussed. These steps are generally applicable (i.e., regardless of the method used). Option 1 still Option 2 process).

[0179] In further steps 1015a-1015b, a new TNAP key is applied to establish over-the-air security between UE 1020 and TNAP2 1034. In other words, the security establishment is achieved using the new TNAP key (e.g., using a 4-way handshake over WLAN). If necessary, UE 1020 may receive new IP configuration information (e.g., local IP configuration such as a new IP address).

[0180] In step 1016, UE 1020 resumes communication with TNGF 1036 via TNAP2 1034. This is shown as an NWt connection.

[0181] In step 1017a, TNGF 1036 sends an N2 message with the UE ID (e.g., 5G-GUTI) and the current new TNAP identifier, i.e., an initial context establishment update message (or sends information in any N2 message to update AMF 1040 with the UE's current location information).

[0182] In a further step 1017b, AMF 1040 updates the UE location information / UE context with the current service TNAP identifier.

[0183] In a further step 1017c, AMF 1040 sends an N2 Initial Context Establishment Update Acknowledgment / Response Message (in any N2 message) with a success / acknowledgment indication to TNGF 1036.

[0184] Certain adaptations can be made to Example 1000 to enable it to operate for untrusted non-3GPP access networks. The untrusted non-3GPP access network can connect to the 5G core network via a Non-3GPP Interoperability Function (N3IWF) instead of a Trusted Non-3GPP Gateway Function (TNGF) 1036. The N3IWF interfaces with the 5G core network CP and UP operate via the N2 and N3 interfaces, respectively. The procedures described in Example 1000 can also be used for untrusted non-3GPP access networks, the only difference being that the TNAN 1030, including TNGF 1036 and TNAP1 / TNAP2 1032 / 1034, is replaced with an untrusted non-3GPP access node / point.

[0185] Other embodiments disclosed herein relate to methods for notifying the network of UE location information during an FT-based UE mobility procedure. These embodiments describe how to support UE mobility between two TNAPs that support two different re-authentication protocols, such as FT (i.e., FBSS based on IEEE 802.11) and non-FT (i.e., non-3GPP access re-authentication / 3GPP local re-authentication / TNAP mobility security establishment method).

[0186] Figure 11 Example 1100 is shown, based on various aspects disclosed herein, in which a UE moves from a current serving AP (which is an AP without non-FT capabilities) to a new target AP (which has FT capabilities). Example 1100 shows UE 1120, TNAP 11132, TNAP 2 1134, and TNGF 1136. Various procedural steps / message flows 1101-1106 will now be described. TNAP 11132 is considered to have no FT capabilities. TNAP 2 1134 is considered to have FT capabilities. Furthermore, TNAP 1 1132 can be considered the current TNAP serving UE 1120. TNAP 2 1134 can be considered the target TNAP. In other words, a currently successful and secure session and data transmission are ongoing between UE 1120 and TNAP 1 1132.

[0187] In the first step 1101, the FT-enabled UE 1120 can send an FT request (FTO, FTO address, TargetAP address, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID]) to the new target AP TNAP2 1134. UE 1120 may include 5G-GUTI or TNGF 1136 and any UE ID / re-authentication identifier known to it, as well as the TNGF 1136 address in the FTO.

[0188] In a further step 1102, if the target AP TNAP2 1134 cannot obtain any FT-related key (e.g., PMK-R1 or PMK Rx) from the FT key holder (R0-KH), then the target AP TNAP2 1134 determines to obtain the FT key from TNGF 1136.

[0189] In a further step 1103, the target AP TNAP2 1134 contacts TNGF 1136 based on the FTO including the UE ID and TNGF ID. The target AP TNAP2 1134 sends an FT key request message with TNAP re-authentication capability, TNAP ID, FTO / 5G-GUTI / re-authentication ID in an AAA request, and instructs the UE to support the FT protocol.

[0190] In a further step 1104, TNGF 1136 identifies the UE context based on FTO / 5G-GUTI / Re-authentication ID and checks the UE's re-authentication capability to see if it matches the TNAP information provided by UE 1120 for FT support. If the verification is successful, TNGF 1136 derives the FT key from the TNGF key.

[0191] In a further step 1105, TNGF 1136 sends an AAA response and an FT key response message including the FT key to TNAP2 1134.

[0192] In a further step 1106, the new target AP TNAP2 1134 and UE 1120 perform an FBSS transition based on IEEE 802.11.

[0193] As a further adaptation of Example 1100, for untrusted non-3GPP scenarios, TNAP 1132 / 1134 is replaced with AP, and TNGF 1136 is replaced with N3IWF.

[0194] Figure 12 Another example embodiment 1200 is shown, illustrating a UE moving from a current serving AP (which is an AP with FT capability) to a new target AP (which does not have FT capability) according to various aspects disclosed herein. Example 1200 illustrates UE 1220, TNAP1 1232, TNAP2 1234, and TNGF 1236. TNAP1 1232 can be considered as an AP with FT capability. TNAP2 1234 can be considered as an AP without FT capability. Furthermore, TNAP1 1232 can be considered as the current serving AP for UE 1220, i.e., a successful and secure session and data transmission are in progress. Therefore, TNAP2 1234 can be considered as the target AP. Various procedural steps / message flows 1201-1206 will now be described.

[0195] In the first step 1201, the UE 1220 with FT capability can send an FT request (FTO, FTO address, TargetAP address, RSNE[PMKR0Name], MDE, FTE[SNonce, R0KH-ID]) to the new target AP TNAP2 1234. The UE 1220 may include TNGF 1236 and a 5G-GUTI or any UE ID / re-authentication identifier that is known to itself, and includes the TNGF address in the FTO.

[0196] In a further step 1202a, if the target AP TNAP2 1234 does not support the FT protocol and if it supports any non-FT protocol used for re-authentication / secure establishment, it will determine to send an identity request to the UE 1220.

[0197] In a further step 1202b, TNAP2 1234 typically initiates an EAP session by requesting UE identity. This is illustrated as TNAP2 1234 providing an EAP request / identity to UE 1220 via L2.

[0198] In a further step 1203, UE 1220 provides EAP Response / Identity and Network Access Identifier (NAI) to TNAP2 1234 via L2. The NAI contains Username=Re-authentication ID and Domain=nai.5gc.tngf <tngf-id>.mnc <mnc>.mcc <mcc>.3gppnetwork.org, 5G-GUTI, and UE re-authentication capability. The re-authentication ID and TNGF-ID are received when UE 1220 first connects to TNGF 1236, for example, during initial registration via TNGF 1236. UE 1220 provides Username=Re-authentication ID and 5G-GUTI because UE 1220 does not want to initiate NAS signaling with 5GC, but it wants to re-authenticate with TNGF 1236. Alternatively, if TNGF 1236 provides the re-authentication ID during registration, UE 1220 can provide the received re-authentication in step 1201.

[0199] In a further step 1204, target TNAP2 1234 selects TNGF 1236 based on the TNGF1-ID in the received domain, and forwards EAP-Res / Identity, NAI, 5G-GUTI, and the received UE re-authentication capability to TNGF 1236 in the AAA request. Furthermore, TNAP2 1234 also includes its own TNAP re-authentication capability information and TNAP ID, and provides them to TNGF 1236.

[0200] In a further step 1205, TNGF 1236 searches the stored UE context, which contains the received re-authentication ID / 5G-GUTI and UE re-authentication capabilities. Therefore, it determines that UE 1220 is a known UE requesting re-authentication. Thus, it initiates steps 1005b to 1017c of Figures 10A-10C. If TNGF 1236 does not find a stored UE context containing the received re-authentication ID, TNGF 1236 sends an error response to UE 1220 or initiates a signaling procedure related to normal authentication for trusted non-3GPP access as described in Clause 7A.2.1 of 3GPP specification TS 33.501. TNGF 1236 may check whether the received re-authentication capabilities match the UE re-authentication capabilities stored during the previous (initial) registration to verify that the re-authentication capabilities have not been tampered with.

[0201] As described above, in a further step 1206, steps 1005b to 1017c of Figures 10A-10C can be performed.

[0202] This disclosure provides a network function for wireless communication, the network function comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the network function: receives one or more first parameters indicating the ability of a user equipment (UE) to re-authenticate with a wireless communication network; receives one or more second parameters indicating the ability of a first network access point to re-authenticate with the wireless communication network; determines a re-authentication type for UE mobility based on one or more first parameters and one or more second parameters; and determines security information for UE mobility based on the re-authentication type.

[0203] The network function can be TNGF or N3IWF as disclosed in the various aspects herein, namely TNGF 936 in Figure 9 and TNGF 1036 in Figure 10. Figure 11 TNGF 1136, Figure 12 TNGF 1236.

[0204] The UE can be the UE described in the various aspects disclosed herein, namely, UE 920 in Figure 9, UE 1020 in Figure 10, etc. Figure 11 UE 1120 Figure 12 UE 1220.

[0205] The first network access point can be a trusted or untrusted access point as described in the various aspects disclosed herein, that is, the first network access point can be TNAP 932 in Figure 9, TNAP 1032 and 1034 in Figure 10. Figure 11 TNAP 1132, 1134, Figure 12 TNAP 1232, 1234.

[0206] The wireless communication network can be a wireless communication network or system as described in the various aspects disclosed herein, a 3GPP network, a core network, or 5GS / 5GC, i.e. Figure 1 Wireless communication system 100.

[0207] One or more first parameters that indicate the ability of a first network access point to re-authenticate with a wireless communication network are also referred to herein as 'UE re-authentication capability information' and 'UE re-authentication capability'.

[0208] One or more second parameters that indicate the ability of a first network access point to re-authenticate with a wireless communication network are also referred to herein as 'TNAP re-authentication capability information' and 'TNAP re-authentication capability'.

[0209] The term 'UE mobility' will be understood by those skilled in the art, but for completeness, it includes the mobility of a UE, which results in a UE connection to a wireless communication network changing, migrating, or moving from one access point to another, as described in the embodiments herein. The term 'UE mobility' may also be referred to in the context of 'UE mobility scenarios' or 'UE mobility procedures'.

[0210] In the embodiments described herein, security information is also referred to as 'security context' or 'security context information'.

[0211] The re-authentication type is also referred to in this document as 're-authentication method', 're-authentication process', or 're-authentication protocol'.

[0212] Network functions tend to allow UEs and network access points to provide their ability to re-authenticate with the wireless communication network in response to UE mobility. Therefore, network functions can determine the appropriate re-authentication type / method based on the provided capabilities, and thereby generate suitable security information for re-authentication. This tends to mitigate the problem of network functions being unaware of the UE and network access point's re-authentication capabilities, and thus mitigate the failure of re-authentication attempts. Other problems mitigated by network functions will become apparent from the disclosure herein.

[0213] In some embodiments, at least one processor coupled to at least one memory is further configured to enable network functions to: provide re-authentication type and / or security information to a first network access point; and / or provide re-authentication type and / or security information to a UE.

[0214] In some embodiments, at least one processor coupled to at least one memory is configured to enable network functionality to receive one or more first parameters and one or more second parameters during a UE registration process and / or a UE mobility process.

[0215] As described herein, the registration process can be the initial registration performed according to Example 900 of Figure 9. The UE mobility process can be according to Example 1000 of Figure 10. Figure 11 Example 1100 or Figure 12 Example 1200 demonstrates a UE mobility scenario.

[0216] In some embodiments, at least one processor coupled to at least one memory is configured to cause the network function to further receive at least one of the following: a UE identifier associated with the UE; and a network access point identifier associated with a first network access point.

[0217] The UE identifier may be referred to as 'UE-ID' in this document, for example, it could be SUCI or 5G-GUTI. The network access point identifier may be referred to as TNAP ID or TNAP identifier or AP identifier in this document.

[0218] In some embodiments, at least one processor coupled to at least one memory is further configured to enable network functions to provide at least one of the following to the Access and Mobility Management Function (AMF) of the wireless communication network: a UE identifier and one or more first parameters; and a first network access point identifier.

[0219] For example, AMF can be AMF 940 in Figure 9 or AMF 1040 in Figure 10.

[0220] In some embodiments, at least one processor coupled to at least one memory is configured to enable the network function to determine the re-authentication type during a UE mobility process.

[0221] In some embodiments, at least one processor coupled to at least one memory is configured to enable network functionality: receiving one or more first parameters from the AMF of a wireless communication network.

[0222] In some embodiments, the TNGF's network function may receive one or more first parameters from the AMF for the UE via N2.

[0223] In some embodiments, at least one processor coupled to at least one memory is configured to enable the network function to provide the AMF with the UE’s current location (i.e., current location information) (which may be the current AP identifier) ​​after the UE has successfully re-authenticated with the wireless communication network via a first network access point.

[0224] In some embodiments, the UE mobility process includes: the UE transitioning between a first network access point and a second network access point in a wireless communication network, wherein: the first network access point supports the Fast Transition (FT) protocol, and the second network access point does not support the FT protocol; or the first network access point does not support the FT protocol, and the second network access point supports the FT protocol. For example, the network function may be... Figures 11-12 TNGF 1136, 1236. Therefore, for example, the first network access point and the second network access point can be access points 1132, 1134 or 1232, 1234.

[0225] In some embodiments, one or more first parameters indicate whether the UE supports at least one of the following: Fast Switching (FT) protocol; Non-3GPP Access Key Refresh; Non-3GPP Access Re-authentication; 3GPP Local Re-authentication; Mobility Security; Modified Re-authentication Protocol (ERP) or ERP.

[0226] In some embodiments, one or more second parameters indicate whether the first network access point supports at least one of the following: FT protocol; non-3GPP access re-authentication; 3GPP local re-authentication; mobility security; modified ERP or ERP.

[0227] In some embodiments, the re-authentication type indicates the re-authentication method selected from a list of re-authentication methods, which includes: FT protocol-based methods; non-3GPP access-based re-authentication methods; 3GPP local re-authentication methods; mobility security-based methods; and modified ERP / ERP-based methods.

[0228] In some embodiments, the security information includes one or more of the following: an indication of the type of security key used to derive the security key; and the security key.

[0229] In some embodiments, the first network access point is a trusted non-3GPP network access point and the network function is a trusted network gateway function (TNGF); or the first network access point is an untrusted non-3GPP network access point and the network function is a non-3GPP access interoperability function (N3IWF).

[0230] In some embodiments, one or more first parameters are received from the UE via a first network access point.

[0231] This disclosure also provides a method in a network function, the method comprising: receiving one or more first parameters, the one or more first parameters indicating the ability of a user equipment (UE) to re-authenticate with a wireless communication network; receiving one or more second parameters, the one or more second parameters indicating the ability of a first network access point to re-authenticate with a wireless communication network; determining a re-authentication type for UE mobility based on the one or more first parameters and the one or more second parameters; and determining security information for UE mobility based on the re-authentication type.

[0232] In some embodiments, the method includes: providing a re-authentication type and / or security information to a first network access point; and / or providing a re-authentication type and / or security information to a UE.

[0233] In some embodiments, the method includes receiving one or more first parameters and one or more second parameters during a registration process for a UE and / or a UE mobility process.

[0234] In some embodiments, the method includes receiving at least one of the following: a UE identifier associated with a UE; and a network access point identifier associated with a first network access point.

[0235] In some embodiments, the method includes providing at least one of the following to the access and mobility management function (AMF) of a wireless communication network: a UE identifier and one or more first parameters; and a first network access point identifier.

[0236] In some embodiments, the method includes: determining a re-authentication type during a UE mobility process.

[0237] In some embodiments, the method includes receiving one or more first parameters from the AMF of a wireless communication network.

[0238] In some embodiments, the method includes receiving one or more first parameters from an AMF for the UE via N2.

[0239] In some embodiments, the method includes: after the UE has successfully re-authenticated with the wireless communication network via a first network access point, providing the AMF with the UE's current location (i.e., current location information) (the current location information may be the current AP identifier).

[0240] In some embodiments, the UE mobility process includes: the UE switching between a first network access point and a second network access point in a wireless communication network, wherein: the first network access point supports the Fast Switching (FT) protocol and the second network access point does not support the FT protocol; or the first network access point does not support the FT protocol and the second network access point supports the FT protocol.

[0241] In some embodiments, one or more first parameters indicate whether the UE supports at least one of the following: Fast Switching (FT) protocol; Non-3GPP Access Key Refresh; Non-3GPP Access Re-authentication; 3GPP Local Re-authentication; Mobility Security; Modified Re-authentication Protocol (ERP) or ERP.

[0242] In some embodiments, one or more second parameters indicate whether the first network access point supports at least one of the following: FT protocol; non-3GPP access re-authentication; 3GPP local re-authentication; mobility security; modified ERP or ERP.

[0243] In some embodiments, the re-authentication type indicates the re-authentication method selected from a list of re-authentication methods, which includes: FT protocol-based methods; non-3GPP access-based re-authentication methods; 3GPP local re-authentication methods; mobility security-based methods; and modified ERP / ERP-based methods.

[0244] In some embodiments, the security information includes one or more of the following: an indication of the type of security key used to derive the security key; and the security key.

[0245] In some embodiments, the first network access point is a trusted non-3GPP network access point and the network function is a trusted network gateway function (TNGF); or the first network access point is an untrusted non-3GPP network access point and the network function is a non-3GPP access interoperability function (N3IWF).

[0246] In some embodiments, one or more first parameters are received from the UE via a first network access point.

[0247] A UE for wireless communication is also provided, the UE comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the UE: provides one or more first parameters to a network function of a wireless communication network, the one or more first parameters indicating the UE's ability to re-authenticate with the wireless communication network via a first network access point; and receives a re-authentication type from the network function, the re-authentication type being used to derive security information for UE mobility, for the UE to re-authenticate with the wireless communication network via the first network access point.

[0248] The network function can be TNGF or N3IWF as disclosed in the various aspects herein, namely TNGF 936 in Figure 9 and TNGF 1036 in Figure 10. Figure 11 TNGF 1136, Figure 12 TNGF 1236.

[0249] The UE can be the UE described in the various aspects disclosed herein, namely, UE 920 in Figure 9, UE 1020 in Figure 10, etc. Figure 11 UE 1120 Figure 12 UE 1220.

[0250] The first network access point can be a trusted or untrusted access point as described in the various aspects disclosed herein, that is, the first network access point can be TNAP 932 in Figure 9, TNAP 1032 and 1034 in Figure 10. Figure 11 TNAP 1132, 1134, Figure 12 TNAP 1232, 1234.

[0251] In some embodiments, at least one processor coupled to at least one memory is further configured to cause the UE to: derive security information based on the re-authentication type; and then use the security information to re-authenticate or establish a secure connection with the wireless communication network via a first network access point.

[0252] In some embodiments, at least one processor coupled to at least one memory is configured such that the UE: provides one or more first parameters to the network function during a registration process for the UE; and / or provides one or more first parameters to the network function during a UE mobility process for the UE, wherein the UE transitions between a first network access point and a second network access point in a wireless communication network.

[0253] In some embodiments, one or more first parameters indicate whether the UE supports at least one of the following: Fast Switching (FT) protocol; Non-3GPP Access Key Refresh; Non-3GPP Access Re-authentication; 3GPP Local Re-authentication; Mobility Security; Modified Re-authentication Protocol (ERP) or ERP.

[0254] In some embodiments, the re-authentication type indicates the re-authentication method selected from a list of re-authentication methods, which includes: FT protocol-based methods; non-3GPP access-based re-authentication methods; 3GPP local re-authentication methods; mobility security-based methods; and modified ERP / ERP-based methods.

[0255] A method in a UE is also provided, the method comprising: providing one or more first parameters to a network function of a wireless communication network, the one or more first parameters indicating the UE's ability to re-authenticate with the wireless communication network via a first network access point; and receiving a re-authentication type from the network function, the re-authentication type being used to derive security information for UE mobility for the UE to re-authenticate with the wireless communication network via the first network access point.

[0256] In some embodiments, the method includes: deriving security information based on the re-authentication type; and then using the security information to re-authenticate or establish a secure connection with a wireless communication network via a first network access point.

[0257] In some embodiments, the method includes: providing one or more first parameters to a network function during a registration process for a UE; and / or providing one or more first parameters to a network function during a UE mobility process for a UE, wherein the UE transitions between a first network access point and a second network access point in a wireless communication network.

[0258] In some embodiments, one or more first parameters indicate whether the UE supports at least one of the following: Fast Switching (FT) protocol; Non-3GPP Access Key Refresh; Non-3GPP Access Re-authentication; 3GPP Local Re-authentication; Mobility Security; Modified Re-authentication Protocol (ERP) or ERP.

[0259] In some embodiments, the re-authentication type indicates the re-authentication method selected from a list of re-authentication methods, which includes: FT protocol-based methods; non-3GPP access-based re-authentication methods; 3GPP local re-authentication methods; mobility security-based methods; and modified ERP / ERP-based methods.

[0260] A network access point for wireless communication is also provided, the network access point comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the network access point: receives one or more first parameters from a UE, the one or more first parameters indicating the UE's ability to re-authenticate with a wireless communication network via the network access point; provides one or more first parameters to a network function of the wireless communication network; provides one or more second parameters to the network function, the one or more second parameters indicating the network access point's ability to re-authenticate with the wireless communication network; and receives re-authentication type and / or security information for UE mobility from the network function for the UE to re-authenticate with the wireless communication network via the network access point.

[0261] The network function can be TNGF or N3IWF as disclosed in the various aspects herein, namely TNGF 936 in Figure 9 and TNGF 1036 in Figure 10. Figure 11 TNGF 1136, Figure 12 TNGF 1236.

[0262] The UE can be the UE described in the various aspects disclosed herein, namely, UE 920 in Figure 9, UE 1020 in Figure 10, etc. Figure 11 UE 1120 Figure 12 UE 1220.

[0263] The network access point can be a trusted or untrusted access point as described in the various aspects disclosed herein, that is, the network access point can be TNAP 932 in Figure 9, TNAP 1032 and 1034 in Figure 10, etc. Figure 11 TNAP 1132, 1134, Figure 12 TNAP1232, 1234.

[0264] A method in a network access point is also provided, the method comprising: receiving one or more first parameters from a UE, the one or more first parameters indicating the UE's ability to re-authenticate with a wireless communication network via the network access point; providing one or more first parameters to a network function of the wireless communication network; providing one or more second parameters to the network function, the one or more second parameters indicating the network access point's ability to re-authenticate with the wireless communication network; and receiving re-authentication type and / or security information for UE mobility from the network function for the UE to re-authenticate with the wireless communication network via the network access point.

[0265] A processor for wireless communication is also provided, the processor comprising: at least one controller coupled to at least one memory and configured such that the processor: outputs one or more first parameters indicating the ability of a UE to re-authenticate with a wireless communication network via a first network access point; and inputs a re-authentication type for deriving security information for UE mobility for the UE to re-authenticate with the wireless communication network via the first network access point.

[0266] A method for wireless communication in a processor is also provided, the method comprising: outputting one or more first parameters indicating the ability of a UE to re-authenticate with a wireless communication network via a first network access point; and inputting a re-authentication type for deriving security information for UE mobility for UE re-authentication via the first network access point and the wireless communication network.

[0267] This disclosure provides a function (i.e., TNGF) in a wireless communication network. This function is configured to: receive UE re-authentication capability; receive TNAP re-authentication capability from a TNAP; determine / select a re-authentication method / type for UE mobility to use between different TNAPs by considering the UE re-authentication capability and the TNAP authentication capability; derive a re-authentication security key based on the selected re-authentication type; provide the derived security key to the TNAP; and provide the selected re-authentication type to the UE, indicating the type of security key to be derived by the UE for mobility scenarios.

[0268] In some embodiments, this function notifies the AMF of the UE ID and the current TNAP identifier.

[0269] In some embodiments, the TNGF receives UE re-authentication capability from the UE via the TNAP.

[0270] In some embodiments, the TNGF receives UE re-authentication capability from the AMF for the UE via N2.

[0271] In some embodiments, TNGF selects the re-authentication method to be used during the registration or migration process.

[0272] In some embodiments, TNGF indicates the selected re-authentication method to be used by the UE during the mobility process.

[0273] In some embodiments, after successful mobility and connection re-establishment with the new TNAP by providing the current TNAP ID and UE ID, the TNGF notifies the AMF of the UE's current location.

[0274] Figure 13 An example of a UE 1300 according to various aspects of this disclosure is illustrated. UE 1300 may include a processor 1302, a memory 1304, a controller 1306, and a transceiver 1308. The processor 1302, memory 1304, controller 1306, or transceiver 1308, or various combinations thereof, or various components thereof, may be examples of parts for performing various aspects of this disclosure described herein. These components may be coupled via one or more interfaces (e.g., operational ground, communication ground, functional ground, electronic ground, electrical ground).

[0275] Processor 1302, memory 1304, controller 1306, or transceiver 1308, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may include a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof, configured or otherwise supporting components for performing the functions described in this disclosure.

[0276] Processor 1302 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some implementations, processor 1302 may be configured to operate memory 1304. In other implementations, memory 1304 may be integrated into processor 1302. Processor 1302 may be configured to execute computer-readable instructions stored in memory 1304 to cause UE 1300 to perform various functions of this disclosure.

[0277] Memory 1304 may include volatile or non-volatile memory. Memory 1304 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1302, cause UE 1300 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 1304 or another type of memory. Computer-readable media include both non-transitory computer storage media and communication media, including any medium that facilitates the transfer of computer programs from one place to another. Non-transitory storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0278] In some implementations, processor 1302 and memory 1304 coupled to processor 1302 can be configured such that UE 1300 performs one or more functions described herein (e.g., processor 1302 executes instructions stored in memory 1304). For example, according to the examples disclosed herein, processor 1302 can support wireless communication at UE 1300. UE 1300 can be UE 920 of FIG. 9, UE 1020 of FIG. 10, etc. Figure 11 UE 1120 Figure 12 UE 1220. UE 1300 can be configured to support components for performing the methods disclosed herein.

[0279] Controller 1306 can manage input and output signals for UE 1300. Controller 1306 can also manage peripheral devices not integrated into UE 1300. In some implementations, controller 1306 can utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, controller 1306 can be implemented as part of processor 1302.

[0280] In some implementations, UE 1300 may include at least one transceiver 1308. In other implementations, UE 1300 may have more than one transceiver 1308. Transceiver 1308 may represent a wireless transceiver. Transceiver 1308 may include one or more receiver chains 1310, one or more transmitter chains 1312, or a combination thereof.

[0281] Receiver chain 1310 can be configured to receive signals (e.g., control information, data, packets) via a wireless medium. For example, receiver chain 1310 may include one or more antennas for receiving signals over the air or via a wireless medium. Receiver chain 1310 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 1310 may include at least one demodulator configured to demodulate the received signal and acquire transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 1310 may include at least one decoder for decoding the demodulated signal to receive transmitted data.

[0282] Transmitter chain 1312 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 1312 may include at least one modulator for modulating data onto a carrier signal to prepare the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques, such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes such as phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 1312 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 1312 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0283] Figure 14 An example of a processor 1400 according to various aspects of this disclosure is illustrated. Processor 1400 may be an example of a processor configured to perform various operations according to the examples described herein. Processor 1400 may include a controller 1402 configured to perform various operations according to the examples described herein. Processor 1400 may optionally include at least one memory 1404, which may be, for example, an L1 / L2 / L3 cache. Additionally or alternatively, processor 1400 may optionally include one or more arithmetic logic units (ALUs) 1406. One or more of these components may be electronically communicated or otherwise coupled (e.g., operative ground, communicative ground, functional ground, electronic ground, electrical ground) via one or more interfaces (e.g., buses).

[0284] Processor 1400 may be a processor chipset and includes a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receive, acquire, retrieve, send, output, forward, store, determine, identify, access, write, read) according to the examples described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to the processor chipset or included in the processor chipset (e.g., processor 1400)) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase-change memory (PCM), etc.).

[0285] Controller 1402 can be configured to manage and coordinate various operations of processor 1400 (e.g., signaling, receiving, acquiring, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, and reading) to enable processor 1400 to support various operations of the UE according to the examples described herein. For example, controller 1402 can operate as a control unit of processor 1400, generating control signals that manage the operation of various components of processor 1400. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating operation timing.

[0286] Controller 1402 can be configured to fetch (e.g., fetch, retrieve, receive) instructions from memory 1404 and determine subsequent instructions(s) to be executed, enabling processor 1400 to support various operations according to the examples described herein. Controller 1402 can be configured to track the memory addresses of instructions associated with memory 1404. Controller 1402 can be configured to decode instructions to determine the operations to be performed and the operands involved. For example, controller 1402 can be configured to interpret instructions and determine control signals to be output to other components of processor 1400, enabling processor 1400 to support various operations according to the examples described herein. Additionally or alternatively, controller 1402 can be configured to manage data flow within processor 1400. Controller 1402 can be configured to control data transfers between registers, arithmetic logic unit (ALU), and other functional units of processor 1400.

[0287] Memory 1404 may include one or more caches (e.g., memory or other memory, such as RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc., local to or included in processor 1400). In some implementations, memory 1404 may reside within or on the processor chipset (e.g., locally to processor 1400). In other implementations, memory 1404 may reside outside the processor chipset (e.g., remotely from processor 1400).

[0288] Memory 1404 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1400, cause processor 1400 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as system memory or another type of memory. Controller 1402 and / or processor 1400 may be configured to execute computer-readable instructions stored in memory 1404 to cause processor 1400 to perform various functions. For example, processor 1400 and / or controller 1402 may be coupled to or coupled to memory 1404, and processor 1400, controller 1402, and memory 1404 may be configured to perform the various functions described herein. In some examples, processor 1400 may include multiple processors, and memory 1404 may include multiple memories. One or more of the multiple processors may be coupled to one or more of the multiple memories, which may be configured individually or collectively to perform the various functions described herein.

[0289] One or more ALUs 1406 can be configured to support various operations as described in the examples herein. In some implementations, one or more ALUs 1406 may reside within or on a processor chipset (e.g., processor 1400). In other implementations, one or more ALUs 1406 may reside outside the processor chipset (e.g., processor 1400). One or more ALUs 1406 can perform one or more calculations on data, such as addition, subtraction, multiplication, and division. For example, one or more ALUs 1406 can receive input operands and an opcode that determines the operation to be performed. One or more ALUs 1406 can be configured with various logic and arithmetic circuitry, including adders, subtractors, shifters, and logic gates, to process and manipulate data according to the operations. Alternatively or concurrently, one or more ALU 1406 may support logical operations such as AND, OR, XOR, NOR, and NAND, enabling one or more ALU 1406 to handle conditional operations, comparisons, and bitwise operations.

[0290] Based on the examples disclosed herein, processor 1400 may support wireless communication. Processor 1400 may be configured or operable to support components for performing the methods described herein.

[0291] Figure 15 An example of an NE 1500 according to various aspects of this disclosure is illustrated. The NE 1500 may include a processor 1502, a memory 1504, a controller 1506, and a transceiver 1508. The processor 1502, memory 1504, controller 1506, or transceiver 1508, or various combinations thereof, or various components thereof, may be examples of parts for performing various aspects of this disclosure described herein. These components may be coupled via one or more interfaces (e.g., operational ground, communication ground, functional ground, electronic ground, electrical ground).

[0292] Processor 1502, memory 1504, controller 1506, or transceiver 1508, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may include a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof, configured or otherwise supporting components for performing the functions described in this disclosure.

[0293] Processor 1502 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some implementations, processor 1502 may be configured to operate memory 1504. In other implementations, memory 1504 may be integrated into processor 1502. Processor 1502 may be configured to execute computer-readable instructions stored in memory 1504 to cause NE 1500 to perform various functions of this disclosure.

[0294] Memory 1504 may include volatile or non-volatile memory. Memory 1504 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1502, cause NE 1500 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 1504 or another type of memory. Computer-readable media include both non-transitory computer storage media and communication media, including any medium that facilitates the transfer of computer programs from one place to another. Non-transitory storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0295] In some implementations, processor 1502 and memory 1504 coupled to processor 1502 can be configured such that NE 1500 performs one or more functions described herein (e.g., processor 1502 executes instructions stored in memory 1504). For example, according to the examples disclosed herein, processor 1502 can support wireless communication at NE 1500. NE 1500 can be configured to support components for performing the methods described herein. NE 1500 can be a network function, such as TNGF or N3IWF as described in the aspects disclosed herein, i.e., TNGF 936 of FIG. 9, TNGF 1036 of FIG. 10, etc. Figure 11 TNGF 1136, Figure 12 The TNGF 1236. The NE 1500 can be a network access point, such as a trusted or untrusted access point as described in the various aspects disclosed herein; that is, the network access point can be TNAP 932 of Figure 9, TNAP 1032 and 1034 of Figure 10. Figure 11 TNAP 1132, 1134, Figure 12 TNAP 1232, 1234.

[0296] Controller 1506 can manage input and output signals for the NE 1500. Controller 1506 can also manage peripheral devices not integrated into the NE 1500. In some implementations, controller 1506 can utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, controller 1506 can be implemented as part of processor 1502.

[0297] In some implementations, the NE 1500 may include at least one transceiver 1508. In other implementations, the NE 1500 may have more than one transceiver 1508. The transceiver 1508 may represent a wireless transceiver. The transceiver 1508 may include one or more receiver chains 1510, one or more transmitter chains 1512, or a combination thereof.

[0298] Receiver chain 1510 can be configured to receive signals (e.g., control information, data, packets) via a wireless medium. For example, receiver chain 1510 may include one or more antennas for receiving signals over the air or via a wireless medium. Receiver chain 1510 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 1510 may include at least one demodulator configured to demodulate the received signal and acquire transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 1510 may include at least one decoder for decoding the demodulated signal to receive transmitted data.

[0299] Transmitter chain 1512 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 1512 may include at least one modulator for modulating data onto a carrier signal to prepare the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques, such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes such as phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 1512 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 1512 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0300] Figure 16 A flowchart illustrating a method according to various aspects of this disclosure is shown. The operation of this method can be implemented by a UE as described herein. In some implementations, the UE can execute a set of instructions to control the functional elements of the UE to perform the described functions.

[0301] At 1610, the method may include: providing one or more first parameters to a network function of the wireless communication network, the one or more first parameters indicating the UE's ability to re-authenticate with the wireless communication network via a first network access point. Operation of 1610 can be performed according to the examples described herein. In some implementations, aspects of operation of 1610 may be derived from references... Figure 13 The UE is used to execute this.

[0302] At 1620, the method may include: receiving a re-authentication type from a network function, the re-authentication type being used to derive security information for UE mobility, for the UE to re-authenticate with the wireless communication network via a first network access point.

[0303] The operations of 1620 can be performed according to the examples described in this article. In some implementations, aspects of the operations of 1620 can be obtained from references. Figure 13 The UE is used to execute this.

[0304] It should be noted that the method described in this paper describes one possible implementation, and the operations and steps can be rearranged or otherwise modified, and other implementations are also possible.

[0305] Figure 17 A flowchart illustrating a method according to various aspects of this disclosure is shown. The operation of this method can be implemented by an NE as described herein. In some implementations, the NE can execute an instruction set to control the functional elements of the NE to perform the described functions.

[0306] At 1710, the method may include receiving one or more first parameters, the one or more first parameters indicating the UE's ability to re-authenticate with the wireless communication network. The operation of 1710 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1710 can be derived from references... Figure 15 The NE is used to execute this.

[0307] At 1720, the method may include receiving one or more second parameters, the one or more second parameters indicating the capability of the first network access point to re-authenticate with the wireless communication network. The operation of 1720 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1720 can be derived from references... Figure 15 The NE is used to execute this.

[0308] At 1730, the method may include: determining the re-authentication type for UE mobility based on one or more first parameters and one or more second parameters. The operation of 1730 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1730 can be derived from references... Figure 15 The NE is used to execute this.

[0309] At 1740, the method may include: determining security information for UE mobility based on the re-authentication type. The operation at 1740 can be performed according to the examples described herein. In some implementations, aspects of the operation at 1740 can be derived from references... Figure 15 The NE is used to execute this.

[0310] It should be noted that the method described in this paper describes one possible implementation, and the operations and steps can be rearranged or otherwise modified, and other implementations are also possible.

[0311] Figure 18 A flowchart illustrating a method according to various aspects of this disclosure is shown. The operation of this method can be implemented by an NE as described herein. In some implementations, the NE can execute an instruction set to control the functional elements of the NE to perform the described functions.

[0312] At 1810, the method may include: receiving one or more first parameters from the UE, the one or more first parameters indicating the UE's ability to re-authenticate with the wireless communication network via a network access point. The operation of 1810 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1810 can be derived from references... Figure 15 The NE is used to execute this.

[0313] At 1820, the method may include providing one or more first parameters to the network functions of the wireless communication network. The operation of 1820 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1820 can be derived from references... Figure 15 The NE is used to execute this.

[0314] At 1830, the method may include providing one or more second parameters to the network function, the one or more second parameters indicating the network access point's ability to re-authenticate with the wireless communication network. The operation of 1830 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1830 can be derived from references... Figure 15 The NE is used to execute this.

[0315] At 1840, the method may include: receiving re-authentication type and / or security information for UE mobility from a network function, for the UE to re-authenticate with the wireless communication network via a network access point. The operation of 1840 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1840 may be derived from references... Figure 15 The NE is used to execute this.

[0316] It should be noted that the method described in this paper describes one possible implementation, and the operations and steps can be rearranged or otherwise modified, and other implementations are also possible.

[0317] Figure 19 A flowchart illustrating a method according to various aspects of this disclosure is shown. The operation of this method can be implemented by a processor of a UE as described herein. In some implementations, the processor can execute an instruction set to control the functional elements of the processor to perform the described functions.

[0318] At point 1910, the method may include: outputting one or more first parameters indicating the UE's ability to re-authenticate with a wireless communication network via a first network access point. The operation of point 1910 can be performed according to the examples described herein. In some implementations, aspects of the operation of point 1910 can be derived from references... Figure 14 The processor described above executes the commands.

[0319] At point 1920, the method may include: inputting a re-authentication type for deriving security information regarding UE mobility for the UE to re-authenticate with the wireless communication network via a first network access point. The operation of point 1920 can be performed according to the examples described herein. In some implementations, aspects of the operation of point 1920 may be derived from references... Figure 14 The processor described above executes the commands.

[0320] It should be noted that the method described in this paper describes one possible implementation, and the operations and steps can be rearranged or otherwise modified, and other implementations are also possible.

[0321] The description provided herein is intended to enable those skilled in the art to make or use this disclosure. Various modifications to this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0322] The following abbreviations are relevant to the areas covered in this document: 5GC, 5G Core Network; 5G-AN, 5G Access Network; 5G-RG, 5G Residential Gateway; NG-RAN, 5G Radio Access Network; 5G AV, 5G Authentication Vector; 5G HE AV, 5G Home Environment Authentication Vector; 5G NSWO, 5G Non-Seamless WLAN Offload; 5G SE AV, 5G Service Environment Authentication Vector; ABBA, Reverse Downbidding Between Architectures; AEAD, Authentication Encryption with Related Data; AES, Advanced Encryption Standard; AKA, Authentication and Key Negotiation; AMF, Access and Mobility Management Function; ARPF, Authentication Credential Repository and Processing Function; AUSF, Authentication Server Function; AUTN, Authentication Token; CCA, Client Credential Assertion; CH, Credential Holder; CIoT, Cellular Internet of Things; cNRF, Consumer NRF; CP, Control Plane; CTR, Counter (Mode); CU, Central Unit; DCS Default credential server; DN, Data Network; DNN, Data Network Name; DU, Distributed Unit; EAP, Extensible Authentication Protocol; EMSK, Extended Master Session Key; EN-DC, E-UTRA-NR Dual Connectivity; ENSI, External Network Slice Information; EPS, Evolved Packet System; FT, Fast BSS Transition; FN-CRG, Fixed Network Cable RG; FN-RG, Fixed Network RG; gNB, NR Node B; GUTI, Globally Unique Temporary UE Identity; HRES, Hash Response; HXRES, Hash Expected Response; IKE Internet Key Exchange; KSI, Key Set Identifier; MeNB, Master eNB; MN, Master Node; MSK, Master Session Key; N3IWF, Non-3GPP Interoperability Function; NAI, Network Access Identifier; NAS, Non-Access Stratum; NDS, Network Domain Security; NF, Network Function; NG, Next Generation; ng-eNB, Next Generation Evolved Node B; ngKSI, Key Set Identifier in 5G; N5CW, WLAN supporting non-5G; N5GC, supporting non-5G; NIA, 5G Integrity Algorithm; NR, New Radio; NR-DC, NR -NR Dual Connectivity; NSSAI, Network Slice Selection Auxiliary Information; NSSAA, Network Slice Specific Authentication and Authorization; Non-Seamless WLAN Offload; NOUNCE, Use-once Number; NSWOF, Non-Seamless WLAN Offload Function; PDN, Packet Data Network; PEI, Permanent Device Identifier; RES, Response; RAND, Random; SCG, Secondary Cell Group; SEAF, Security Anchor Function; SgNB, Secondary gNB; SIDF, Subscription Identifier Dehiding Function; SMC, Security Mode Command; SMF, Session Management Function; SN, Secondary Node; SN Id, Serving Network Identifier; SUCI, Subscription Hidden Identifier; SUPI, Subscription Permanent Identifier; TLS, Transport Layer Security; TNAN, Trusted Non-3GPP Access Network;TNAP, Trusted Non-3GPP Access Point; TNGF, Trusted Non-3GPP Gateway Function; TWAP, Trusted WLAN Access Point; TWIF, Trusted WLAN Interoperability Function; TSC, Time-Sensitive Communications; UE, User Equipment; UDM, Unified Data Management; UDR, Unified Data Repository; ULR, Update Location Request; UP, User Plane; UPF, User Plane Function; URLLC, Ultra-Reliable Low-Latency Communications; USIM, Universal Subscriber Identity Module; and XRES, Expected Response.< / mcc> < / mnc> < / mcc> < / mnc> < / plmnid> < / mcc> < / mnc> < / mcc> < / mnc> < / nid> < / mcc> < / mnc> < / mcc> < / mnc> < / plmnid>

Claims

1. A network function for wireless communication, comprising: At least one memory; as well as At least one processor, coupled to the at least one memory, and configured to enable the network function: Receive one or more first parameters, the one or more first parameters indicating the user equipment (UE)'s ability to re-authenticate with the wireless communication network; Receive one or more second parameters, the one or more second parameters indicating the ability of the first network access point to re-authenticate with the wireless communication network; The re-authentication type for UE mobility is determined based on one or more first parameters and one or more second parameters; as well as Security information for UE mobility is determined based on the re-authentication type.

2. The network function of claim 1, wherein the at least one processor coupled to the at least one memory is further configured to cause the network function to: Provide the re-authentication type and / or security information to the first network access point; and / or Provide the UE with the re-authentication type and / or the security information.

3. The network function according to any one of claims 1 to 2, wherein the at least one processor coupled to the at least one memory is configured such that the network function receives the one or more first parameters and the one or more second parameters during a registration process and / or a UE mobility process for the UE.

4. The network function of claim 3, wherein the at least one processor coupled to the at least one memory is configured such that the network function further receives at least one of the following: The UE identifier associated with the UE; and The network access point identifier associated with the first network access point.

5. The network function of claim 4, wherein the at least one processor coupled to the at least one memory is further configured to cause the network function to provide at least one of the following to the Access and Mobility Management Function (AMF) of the wireless communication network: The UE identifier and the one or more first parameters; and The first network access point identifier.

6. The network function of claim 2, wherein the at least one processor coupled to the at least one memory is configured such that the network function: determines the re-authentication type during a UE mobility process.

7. The network function of claim 6, wherein the at least one processor coupled to the at least one memory is configured such that the network function receives the one or more first parameters from the AMF of the wireless communication network.

8. The network function of claim 7, wherein the at least one processor coupled to the at least one memory is configured such that the network function: after the UE has successfully re-authenticated with the wireless communication network via the first network access point, provides the AMF with the current location of the UE.

9. The network function according to any one of claims 6 to 8, wherein the UE mobility process comprises: The UE switches between the first network access point and the second network access point in the wireless communication network, wherein: The first network access point supports fast switching of the FT protocol, and the second network access point does not support the FT protocol; or The first network access point does not support the FT protocol, while the second network access point does support the FT protocol.

10. The network function according to any one of the preceding claims, wherein the one or more first parameters indicate whether the UE supports at least one of the following: Rapidly transforming the FT protocol; Non-3GPP Partner Program 3GPP Access Key Refresh; Non-3GPP access re-authentication; 3GPP local recertification; Mobility security; The modified recertification protocol for ERP or ERP.

11. The network function according to any one of the preceding claims, wherein the one or more second parameters indicate whether the first network access point supports at least one of the following: FT Agreement; Non-3GPP access re-authentication; 3GPP local recertification; Mobility security; Modified ERP or ERP.

12. The network function according to any one of the preceding claims, wherein the re-authentication type indicates a re-authentication method selected from the list of re-authentication methods, the list of re-authentication methods comprising: Methods based on the FT protocol; Methods for re-authentication of non-3GPP access; A method based on 3GPP local re-authentication; A mobility security-based approach; as well as Modified ERP / ERP-based approach.

13. The network function according to any one of the preceding claims, wherein the security information includes one or more of the following: An indication of the security key type used to derive the security key; and Security key.

14. The network function according to any one of the preceding claims, wherein: The first network access point is a trusted non-3GPP network access point, and the network function is a Trusted Network Gateway Function (TNGF); or The first network access point is an untrusted non-3GPP network access point, and the network function is a non-3GPP access interoperability function (N3IWF).

15. A UE for wireless communication, comprising: At least one memory; as well as At least one processor, coupled to the at least one memory, and configured such that the UE: One or more first parameters are provided to the network functions of the wireless communication network, the one or more first parameters indicating the UE's ability to re-authenticate with the wireless communication network via a first network access point; as well as The network function receives a re-authentication type, which is used to derive security information for UE mobility, for the UE to re-authenticate with the wireless communication network via the first network access point.

16. The UE of claim 15, wherein the at least one processor coupled to the at least one memory is further configured such that the UE: The security information is derived based on the re-authentication type; and then... Using the security information, re-authenticate or establish a secure connection with the wireless communication network via the first network access point.

17. The UE according to any one of claims 15 to 16, wherein the at least one processor coupled to the at least one memory is configured such that the UE: During the registration process for the UE, the network function is provided with one or more first parameters; and / or During a UE mobility process for the UE, one or more first parameters are provided to the network function, wherein the UE transitions between a first network access point and a second network access point in the wireless communication network.

18. The UE according to any one of claims 15 to 17, wherein the one or more first parameters indicate whether the UE supports at least one of the following: Rapidly transforming the FT protocol; Non-3GPP Partner Program 3GPP Access Key Refresh; Non-3GPP access re-authentication; 3GPP local recertification; Mobility security; The modified recertification protocol for ERP or ERP.

19. The UE according to any one of claims 15 to 18, wherein the re-authentication type indicates a re-authentication method selected from the list of re-authentication methods, the list of re-authentication methods comprising: Methods based on the FT protocol; Methods for re-authentication of non-3GPP access; A method based on 3GPP local re-authentication; A mobility security-based approach; as well as Based on a modified ERP / ERP methodology.

20. A network access point for wireless communication, comprising: At least one memory; as well as At least one processor, coupled to the at least one memory, and configured such that the network access point: The UE receives one or more first parameters, the one or more first parameters indicating the UE's ability to re-authenticate with the wireless communication network via the network access point; Provide the one or more first parameters to the network functions of the wireless communication network; Provide one or more second parameters to the network function, the one or more second parameters indicating the network access point's ability to re-authenticate with the wireless communication network; as well as The network function receives re-authentication type and / or security information for UE mobility, which is used for the UE to re-authenticate with the wireless communication network via the network access point.

Images