WO2024160413A1

WO2024160413A1 - Reauthentication for user equipment mobility in a wireless communication network

Info

Publication number: WO2024160413A1
Application number: PCT/EP2023/083604
Authority: WO
Inventors: Sheeba Backia Mary BASKARAN; Andreas Kunz; Apostolis Salkintzis
Original assignee: Lenovo (Singapore) Pte. Ltd.
Priority date: 2023-10-25
Filing date: 2023-11-29
Publication date: 2024-08-08

Abstract

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

Description

REAUTHENTICATION FOR USER EQUIPMENT MOBILITY IN A WIRELESS COMMUNICATION NETWORK

TECHNICAL FIELD

[0001] The subject matter disclosed herein relates generally to the field of implementing reauthentication for user equipment (UE) mobility in a wireless communication network. 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

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).

[0003] The 5G system currently supports authentication for trusted non-3^rd Generation Partnership Project (3GPP) access, where a UE connects (e.g., registers) to a 5G core network via a trusted Non-3GPP Access Network (TNAN) which comprises of a Trusted Non-3GPP Access Point (TNAP) and a Trusted Non-3GPP Gateway Function (TNGF). In 3GPP Rel.17 and 3GPP Rel.18, if the UE moves from a source TNAP to a target TNAP, the UE will perform a full authentication via the target TNAP to re-connect to the 5G system. A full authentication involves security establishment at all levels including access network security (i.e., security establishment between the UE and access network) and non- access stratum security (i.e., the security establishment between UE and the core network).

SUMMARY

[0004] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0005] There is provided a network function for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network function to: receive one or more first parameters indicating a capability of a user equipment (UE) for reauthenticating with a wireless communication network; receive one or more second parameters indicating a capability of a first network access point for reauthenticating with the wireless communication network; determine, based on the one or more first parameters and the one or more second parameters, a reauthentication type for UE mobility; and determine, based on the reauthentication type, a security information for UE mobility.

[0006] There is further provided a method in a network function, comprising: receiving one or more first parameters indicating a capability of a UE for reauthenticating with a wireless communication network; receiving one or more second parameters indicating a capability of a first network access point for reauthenticating with the wireless communication network; determining, based on the one or more first parameters and the one or more second parameters, a reauthentication type for UE mobility; and determining, based on the reauthentication type, a security information for UE mobility.

[0007] There is further provided, a UE for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: provide, to a network function of a wireless communication network, one or more first parameters indicating a capability of the UE for reauthenticating with the wireless communication network via a first network access point; and receive, from the network function, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point.

[0008] There is further provided, a method in a UE comprising: providing, to a network function of a wireless communication network, one or more first parameters indicating a capability of the UE for reauthenticating with the wireless communication network via a first network access point; and receiving, from the network function, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point.

[0009] There is further provided a network access point for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network access point to: receive, from a UE, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via the network access point; provide, to a network function of the wireless communication network, the one or more first parameters; provide, to the network function, one or more second parameters indicating a capability of the network access point for reauthenticating with the wireless communication network; and receive, from the network function, a reauthentication type and/or security information for UE mobility for reauthenticating the UE with the wireless communication network via the network access point.

[0010] There is further provided a method in a network access point, comprising: receiving, from a UE, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via the network access point; providing, to a network function of the wireless communication network, the one or more first parameters; providing, to the network function, one or more second parameters indicating a capability of the network access point for reauthenticating with the wireless communication network; and receiving, from the network function, a reauthentication type and/or security information for UE mobility for reauthenticating the UE with the wireless communication network via the network access point.

[0011] There is further provided a processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: output, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via a first network access point; and input, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point.

[0012] There is further provided a method in a processor for wireless communication, comprising: outputting, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via a first network access point; and inputting, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point.

[0013] BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 provides an example of a wireless communications system in accordance with aspects of the present disclosure.

[0015] Figure 2 provides an example of a TNAP mobility procedure in accordance with aspects of the present disclosure.

[0016] Figure 3 provides an example of 5G and FT key hierarchies in accordance with aspects of the present disclosure. [0017] Figure 4 provides an example a UE attaching to the first AP, establishing the FT key hierarchy in accordance with aspects of the present disclosure.

[0018] Figure 5 provides an example of AP mobility using the over the air procedure in accordance with aspects of the present disclosure.

[0019] Figure 6 provides an example of authentication for trusted non-3GPP access in accordance with aspects of the present disclosure.

[0020] Figure 7 provides an example of the security establishment procedure for TNAP mobility in accordance with aspects of the present disclosure.

[0021] Figure 8 provides an example of an updated key hierarchy for trusted non-3GPP access to support TNAP mobility in accordance with aspects of the present disclosure.

[0022] Figures 9A-9B provide examples of the UE and TNAP re-authentication capabilities exchange during authentication for UE trusted non-3GPP access in accordance with aspects of the present disclosure.

[0023] Figures 10A-10C provide examples of UE and TNAP reauthentication capabilities exchange during reauthentication/mobility for UE trusted non-3GPP access in accordance with aspects of the present disclosure.

[0024] Figure 11 provides an example of a UE moving from a currently serving AP to a new target AP in accordance with aspects of the present disclosure.

[0025] Figure 12 provides a further example of a UE moving from a currently serving AP to a new target AP in accordance with aspects of the present disclosure.

[0026] Figure 13 illustrates an example of a user equipment (UE) 1300 in accordance with aspects of the present disclosure.

[0027] Figure 14 illustrates an example of a processor 1400 in accordance with aspects of the present disclosure.

[0028] Figure 15 illustrates an example of a network equipment (NE) 1500 in accordance with aspects of the present disclosure. [0029] Figure 16 illustrates a flowchart of a method performed by a UE in accordance with aspects of the present disclosure.

[0030] Figure 17 illustrates a flowchart of a method performed by a NE in accordance with aspects of the present disclosure.

[0031] Figure 18 illustrates a flowchart of an alternative method performed by a NE in accordance with aspects of the present disclosure.

[0032] Figure 19 illustrates a flowchart of a method performed by a processor in accordance with aspects of the present disclosure.

DETAILED DESCRIPTION

[0033] In the case of UE TNAP mobility, only the access network changes, and the core network remains the same. Therefore, running a full authentication with the core network during UE TNAP mobility can cause unnecessary message exchanges between the UE and the core network. This can lead to resource exhaustion and delays in connection reestablishment. Therefore, the 5G system should support UE TNAP mobility with reauthentication and security establishment (i.e., without a full authentication). In this regard, some solutions may use IEEE 802.11 Fast BSS Transition with FT protocol, 3GPP native re-authentication method (for re-authentication and security establishment), or modified ERP. If FT protocol is used, there are some limitations that not all TNAPs supports FT as it is an optional protocol to be supported according to the IEEE 802.11 specification and the FT protocol can work only if the UE mobility happens between two TNAPs within a same mobility domain in TNGF (i.e., FT cannot work for case where UE moves between two TNAPs across different mobility domains as well as between two TNAPs across two different TNGFs). There are also some current deployments where some APs already support FT protocol, hence there is an interest to reuse FT protocol at least for the case where TNAP’s already support FT. Meanwhile however, additionally at least one reauthentication method (e.g., 3 GPP native re-authentication method or ERP) needs to be used to cover the case where FT cannot be used. In this scenario certain problems occur which will be briefly discussed below. [0034] One such problem is that different TNAPs may support different reauthentication methods (i.e., one may support FT and other may need to support a 3 GPP native method or ERP/modified ERP method). Hence, unless the TNGF knows the TNAP’s re-authentication capability, the TNGF cannot provide the re-authentication method specific security key material to the TNAP (e.g., (i) if FT is used, TNGF need to derive and provide a FT Key to the TNAP, (ii) if ERP/modified ERP is used, TNGF need to derive rRK but needs to provide rMSK (derived from rRK) to the TNAP), (iii) if 3 GPP native reauthentication method is used the TNGF needs to provide a fresh TNAP key to the TNAP and related nonces/random numbers/counters need to be provided to TNAP for it to be forwarded the UE).

[0035] Another problem is that legacy UEs cannot support any UE TNAP mobility reauthentication and only future release UEs can be configured to support these enhancements. So, the re-authentication enhancements cannot work, if the UE reauthentication capability is not known to the TNGF to allow the TNGF provide the UE with related information for the security establishment.

[0036] Generally therefore, in a non-3GPP access network, different TNAPs may support different re-authentication protocols such as IEEE 802.11 based FT protocols or other non-FT protocol(s) such as any of 3 GPP native re-authentication protocol (a reauthentication and security establishment procedure or protocol specified by 3 GPP), ERP or a modified ERP etc., The present disclosure tends to enable the UE and TNAP to indicate their respective re-authentication capabilities to allow the TNGF in the network to select a reauthentication method, generate the necessary re-authentication security context (specific to the supported and selected reauthentication method) and to provision the security context to the TNAP for a successful execution of the re-authentication and security establishment during the UE mobility scenario. Following a successful UE mobility (across different TNAPs) and security establishment, the TNGF reporting of newly serving TNAP Identifier (that acts as UE location information) to the AMF is also provided, which tends to allow the network to be aware of the UE’s updated location information. Furthermore, the present disclosure tends to provide a method to support UE mobility between a FT capable AP and non-FT capable AP. [0037] Aspects of the present disclosure are described in the context of a wireless communications system.

[0038] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE- Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0039] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0040] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, 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 may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0041] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0042] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over 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, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0043] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs). [0044] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects 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 entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0045] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0046] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5 G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies. [0047] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., /r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., /r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., /r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., /r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., /r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., /r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0048] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0049] Additionally, or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., /r=0, jU=l, /r=2, jU=3, /r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively.# Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., /r=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0050] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations 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, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0051] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., /r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., /r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., /r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., /r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., /r=3), which includes 120 kHz subcarrier spacing.

[0052] A trusted non- 3 GPP access network can be connected to a 5G Core Network via a Trusted Non-3GPP Gateway Function (TNGF). A trusted WLAN access network is a particular type of a Trusted Non-3GPP Access Network (TNAN) that supports a WLAN access technology, e.g., IEEE 802.11. A UE connects (e.g., registers) to the 5G core network via trusted Non-3GPP Access Network (TNAN) which comprises of Trusted Non- 3GPP Access Point (TNAP) and Trusted Non-3GPP Gateway Function (TNGF). In 3GPP 5G System Rel.18, to support the UE TNAP Mobility scenario, the 5G System is expected to enable re-authentication and security establishment for trusted non-3GPP access when the UE moves from one TNAP (referred to as TNAP1) to the other TNAP (referred to as TNAP2) without performing a full authentication. However, this presents a key issue regarding security aspects of TNAP mobility without full authentication. This will now be briefly discussed. The 3GPP report TR 33.887, titled “Study on Security aspects for 5WWC Phase 2”, mentions a similar key issue, in clause 5.4 of that report.

[0053] Mobility between two TNAPs within the same trusted Non-3GPP Access Network Gateway Function (TNGF) is not supported in 3GPP currently. For example, when a UE moves between two nearby or overlapping TNAPS (i.e., TNAP1 and TNAP2), the connectivity will break. Therefore, UE services will be interrupted. The UE needs to reconnect and go through another authentication procedure to continue the service even though the second non-3GPP access connect to the same 5GC. There could be some potential security solutions where UE switches the TNAP1 to TNAP2 without breaking the connectivity. However, the security aspects of optimizations of inter- TNAP mobility are yet to be considered.

[0054] Potential security requirements will now be discussed. The 5GS should support a mechanism for communication between a UE and TNAP/TNGF to establish security with a TNAP without performing full authentication when the UE switches from another TNAP within the same TNGF. While switching from one TNAP to another TNAP within the same TNGF, the interface between the UE and the new TNAP shall be confidentiality, integrity, and replay protected. Current procedures offering potential for developing solutions will now be briefly introduced. This includes FT based solutions and non-FT based solutions. Some current procedures offering potential for developing solutions can be further classified as 3GPP native solutions or modified ERP solutions.

[0055] A first potential solution relates to TNAP mobility with rand. Figure 2 illustrates an example of a TNAP mobility procedure 200. The figure shows a UE 220 and a TNAN 230. The TNAN 230 comprises a TNAP#1 232, a TNAP#2234 and a TNGF 236. The various procedural steps and messaging flows 201-211 will now be described. [0056] In a first step 201, the UE 220 is connected to TNAP#1 232 in accordance with steps 1-19 of Figure 7A.2.1-1 of the 3GPP Specification TS 33.501, titled “Security architecture and procedures for 5G System". In this step 201, the TNGF 236 also provides a reauth-ID to the UE 220. More specifically, UE 220 is connected to TNAP#1 232 via the procedure defined in 3GPP TS 33.501 Figure 7A.2.1-1. Once authenticated, TNGF 236 sends the reauth-ID to UE 220 over the protected interface. Reauth-ID can be a generated as, for example, ‘<PLMNID><TNGF_ID> <Temp Id>’. It should be noted that TNGF ID could be a TNGF address (like ‘fqdn’).

[0057] In a further step 202, the UE 220 decides to change to TNAP#2234. In a further step 203, an L2 connection is established between the UE 220 and TNAP#2 234. Put differently, in the 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.

[0058] In a further step 204, an L2 message is provided from TNAP#2234 to UE 220. The 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, a TNAP Mobility lndication and Reauth-ID. In a further step 206, an AAA message is provided by TNAP#2 234 to TNGF 236. The AAA message includes TNAP_Mobility_Indication, and the Reauth-ID. Put differently, TNAP#2234 sends the L2 EAP-Request for Identity towards the UE 220 and the UE 220 responds back with an L2 EAP-Response with Identity and a TNAP Mobility lndication flag. The TNAP2234 forwards the EAP response with reauth-ID and the TNAP Mobility lndication flag towards TNGF 236.

[0059] In a further step 207, the TNGF 236 validates the request based on context stored in step 201. The TNGF increments a count and derive a new TNAP key. In a further step 208, the TNGF 236 provides an AAA message to TNAP#2 234. The AAA message includes TNAP key, RAND and MAC. Put differently, based on the reauth-ID, TNGF 236 identifies the UE 220 and retrieves the context and TNAP Mobility lndication. The TNGF 236 checks if the stored context in step 201 is valid and then derives the TNAP keys as described in the present disclosure. The TNGF 236 responds back to TNAP#2234 with the generated key RAND value and MAC for the RAND value. Message Authentication Code (MAC) is derived by using the TNGF key stored in TNGF 236. In TNAP#2234, the newly received TNAP key is considered as Pairwise Master Key (PMK).

[0060] In a further step 209, the TNAP#2 234 provides an EAP Request/5G- notification to UE 220. This includes a start security mode, RAND and MAC. In a further step 210, the UE 220 derives the new TNAP key using RAND. KTNAP is the Pairwise Master Key (PMK). In a further step 211, security establishment is achieved between the UE 220 and TNAP#2 using the key derived 4-way handshake PMK. Put differently, in these steps 209-211, the TNAP#2234 sends an EAP-notifi cation back to the UE 220 with the RAND value along with MAC. If MAC validation is successful then based on the RAND value, UE 220 derives the keys. A 4- way handshake is executed (see IEEE 802.11) which establishes a security context between the WLAN AP and the UE 220 that is used to protect unicast and multicast traffic over the air.

[0061] Once the procedure 200 is complete, the TNGF 236 sends the new reauth-ID to UE 220 over the secure interface that UE 220 can use for the next interaction.

[0062] It should be noted that if the UE 220 gets the new IP configurations from TNAP#2234, then the UE 220 updates the SA address using an IKE informational request "UPDATE SA ADDRESS" to TNGF 236 for further communications.

[0063] Derivation of KTNAP from KTNGF during mobility uses the following input parameters: FC = OxWX; Pl = RAND; LI = length of RAND (i.e., 0x00 0x04). The input key KEY shall be KTNGF. When KTNAP is derived in Mobility, RAND shall be generated and shared with UE 220.

[0064] It should be noted that instead of RAND, COUNT can be used as input as an alternative option. In that case, COUNT is replaces RAND information element usage in the above procedure.

[0065] A further potential solution relates to using fast BSS transition for TNAP mobility (see IEEE Standard 802.11™-2020 Part 11 : "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications"). [0066] The Fast BSS Transition (FT) key hierarchy is established based on the Master Session Key (MSK) by the RO Key Holder (ROKH) that is collocated with the 802. IX authenticator as specified in the IEEE Standard 802.11 -2016 (Revision of IEEE Standard 802.11-2012) IEEE Standard for Information Technology - Telecommunications and information exchange between systems, Local and Metropolitan area networks - specific requirements - Part 11, titled “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”. To support the Fast BSS Transition, the entity that will hold the root key needs to obtain a 256 bit key (KFT) from the TNGF, which is then used as an input key to create the FT key hierarchy. The key KFT is derived from KTNGF using fixed inputs similar to the derivation of KTNAP from KTNGF as described in Annex A.22 of the 3GPP TS 33.501 titled, “Security architecture and procedures for 5G system”, but using a new Usage type distinguisher, e.g., 0x03. The key KFT is used to create the FT key hierarchy specified in 802.11 IEEE Std 802.11™-2020 Part 11 : "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications". Specifically, KFT is used as Master PMK (MPMK) that is used as an input key for RO-Key-Data derivation. With the RO-Key-Data, the FT key hierarchy is established. In effect, KFT links the 5G key hierarchy and FT key hierarchy as it is derived from a key in the 5G key hierarchy and being used to create the FT key hierarchy (see Figure 3 for more details). When a UE switches to a new TNAP within the same mobility domain identified by the Mobility domain identifier (MDID), the UE performs the fast BSS transition procedure as specified in IEEE Std 802.11™-2020 Part 11 : "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications".. The entity that has received KFT from the TNGF takes the role of PMK R0 Key Holder (ROKH) that holds the key, PMK-R0. The ROKH derives PMK-R1 from PMK-R0 and provides it to the new AP (i.e., TNAP in TN AN) during the FT procedure. Figure 3 illustrates such an example 300 of how the 5G and FT key hierarchies link together. The example 300 shows how: MPMK = KFT is derived from KTNGF; PMK-R0 is derived from MPMK; and PMK-R1 is derived from PMK-R0. The 5G hierarchy is shown as including TNGF and KTNGF. The MPMK is shown on the boundary of the 5G hierarchy and FT key hierarchy. The FT key hierarchy includes ROKH and PMK- RO. PMK-R1 is shown on the boundary between ROKH and TNAP/R1KH. [0067] It should be noted that the TNGF can send both KTNAP and KFT to the entity that holds the root key of the FT key hierarchy as an MSK. The TNGF sets the MSK to KTNAP | | KFT, where MSK is 512 bits and the KTNAP and KFT are 256 bits. The TNGF sends the MSK using existing mechanisms.

[0068] A brief overview of the FT security procedure will now be provided. Complete details are provided in IEEE Std 802.11™-2020 Part 11 : "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications" which is hereby incorporated by reference. The FT capability is advertised in the Beacon and Probe Response frames by including the MDIE. The MDIE is advertised in the Beacon and Probe Response frames to indicate the Mobility Domain ID (MDID), FT capability, and the FT policy. The key PMK- R0 and PMK-R1 are identified by PMKROName and PMKRIName respectively. Each AP gets a different PMK-R1 provided to it to secure the communications between the UE and AP. Finally, nonces (SNonce from UE and ANonce from the AP) are used to ensure freshness of the traffic key (PTK) between the UE and AP. Figure 4 illustrates an example 400 of a UE attaching to the first AP that results in establishing the FT key hierarchy. The example shows a UE 420 and an AP 430. The various procedural steps and message flows 401-407 will now be described.

[0069] In initial steps 401-402, the UE 420 wants to connect to the AP 430 that is advertising FT capability through inserting the MDE into Beacons and ProbeResponses. The MDE informs about that the AP 430 is FT capable, the mobility domain ID and the potential support of FT over DS. The UE 420 and AP 430 exchange 802.11 Authentication Request and Response (Open).

[0070] In a further step 403, the UE 420 sends a (Re)association Request (FT capable) to the AP 430 with a MDE included indicating that the UE 420 wants to perform FT within the indicated mobility domain.

[0071] In a further step 404, the AP 430 responds with a (Re)association Response including the MDE and both R1KH-ID and R0KH-ID, if it agrees with the proposed FT adoption [0072] In further steps 405a-c, EAP authentication is run and results in the UE 420 and ROKH both having PMK-RO and PMKROName. The AP 430 is provided with PMK and the UE 420 calculates PMK.

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

[0074] In a further step 407, the UE 420 and AP 430 start securely exchanging data.

[0075] It is emphasised that the UE 420 and ROKH both have PMK-RO and the

PMKROName and the UE 420 has the R0KH-ID.

[0076] Figure 5 provides an example 500 showing AP mobility using the over the air procedure. The example 500 shows a UE 520, a target AP 530 and a ROKH 530. In the example 500, the UE 520 is already connected to another AP (not shown). The various procedural steps and message flows 501-507 will now be briefly introduced.

[0077] In a first step 501, the UE 520 provides an 802.11 Authentication Request to target AP 530. The request includes PMKROName, SNonce, and R0KH-ID.

[0078] In a further step 502, the target AP 530 fetches PMK-R1 from ROKH 535.

[0079] In a further step 503, the target AP 530 provides an 802.11 Authentication

Response to UE 520. The response includes ANonce and R1KH-ID.

[0080] In a further step 504, the UE 520 calculates PMK-R1 and PMKRIName.

[0081] In a further step 505, the UE 520 provides a Reassociation Request to target AP

530. The reassociation request includes PMKRIName, ANonce, SNonce, and MIC.

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

[0083] In a further step 507, the UE 520 and target AP530 start securely exchanging data.

[0084] A further potential solution relates to security establishment for TNAP mobility. In this example solution a UE is provided with a TNGF ID and exchange freshness parameter (such as nonce to facilitate challenge and common security establishment between the UE and a Trusted Non-3GPP Access Network i.e., TNGF) during the Initial registration procedure (i.e., following a successful authentication for trusted non-3GPP access). Figure 6 shows such an example 600 of authentication for trusted non-3GPP access. Further if a UE connected to a TNGF via a TNAP (i.e., say TNAP 1) decides to move to another TNAP (i.e., say TNAP 2), the solution proposes to use the Security Establishment procedure 700 for TNAP Mobility shown in Figure 7.

[0085] In the example 600 of Figure 6, shown therein are a UE 620, a TN AN 630 comprising a TNAP 632 and a TNGF 636, an AMF 640 and a AUSF 650. The various procedural steps and message flows 601-619 will now be briefly described. In the example 600, an L2 interface is present between UE 620 and TNAP 632 i.e., Ethernet, 802.3, 802.11, PPP. In the example 600, an AAA interface is present between TNAP 632 and TNGF 636.

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

[0087] The further steps 601-610a are performed according to 3GPP TS 33.501 Clause 7A.2.1 steps l-10a. Specifically, in step 610a the AMF 640 provides an N2 initial Ctx setup request to TNGF 636. The request includes KTNGF.

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

[0089] In step 610c an L2 message is provided by UE 620 to TNAP 632. The L2 message includes a EAP-Response/5G-Notification/UNonce. Also, in step 610c an AAA message is provided by TNAP 632 to TNGF 636. The AAA message includes the EAP- Response/5G-Notification/UNonce.

[0090] In step 61 Od a further AAA message is provided by TNGF 636 to TNAP 632. This AAA message includes TNAP key and EAP-success. [0091] In step 61 Oe a further L2 message is provided by TNAP 632 to UE 620. This L2 message includes the EAP-success.

[0092] Steps 610d-619 proceed accordingly to 3GPP TS 33.501 Clause 7A.2.1 steps 10d-19.

[0093] The actual registration procedure for trusted non-3GPP access steps related to Figure 6 are described in the 3GPP Specification TS 23.502, titled “Procedures for 5G System”, clause 4.12a.2.2 and the related authentication steps are shown in 3GPP Specification TS 33.501, titled “Security architecture and procedures for 5G system”, clause 7A.2.1. Therefore, the necessary enhancements for steps ‘610b - 610e of the example 600 are described below.

[0094] During the EAP-5G procedure (i.e., executed in steps 604-610 of Figure 6), the additional access parameters are exchanged between the UE 620 and the TNGF 636 at step 610: the TNGF 636 sends TNGF address and TNGF Nonce (TNonce) to UE 620 in step 610b. Further the UE 620 sends to TNGF 636, a UE Nonce (UNonce) in step 610c. The UE 620 and the TNGF 636 can derive a Reauth-ID for the UE 620 from the TNGF key using the inputs parameters such as TNGF-ID, Nonce from TNGF 636, Nonce from UE 620.

[0095] With reference now to the example 700 of Figure 7 and the security establishment procedure for TNAP mobility, shown in the example 700 are a UE 720, and a TNAN 730 comprising a TNAP1 732, a TNAP2 734 and a TNGF 736. The various procedural steps and message flows 700a-715 will now be described.

[0096] In a first step 700a there is an NWt connection between UE 720 and TNGF 736 via TNAP1 732. In a further step 700b the UE 720 determines to move to TNAP2 734.

[0097] In a further step 701, the UE 720 establishes a layer-2 (L2) connection with TNAP2 734.

[0098] In a further step 702, the TNAP2 734 initiates an EAP session, usually by requesting the UE identity. This is performed over the L2 connection including the EAP Request/identity. [0099] In a further step 703, the UE 720 provides over L2 an EAP-response/identity. This includes a Network Access Identifier (NAI) containing username = Reauth-ID and realm = nai.5gc.tngf<TNGF-ID>.mnc<MNC>.mcc<MCC> .3gppnetwork.org. The Reauth- ID was derived as described for Figure 6 and the TNGF-ID was received when the UE 720 was first connected to TNGF 736, e.g., with an Initial Registration via TNGF 736. The UE 720 provides username = Reauth-ID because the UE 720 does not want to initiate NAS signaling with 5GC, but it wants to reauthenticate with the TNGF 736.

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

[0101] In a further step 705, the TNGF 736 finds a stored UE context containing the received Reauth-ID, thus, it determines that the UE 720 is a known UE 720 which requests reauthentication. Therefore, it initiates the following steps. If the TNGF 736 cannot find a stored UE context containing the received Reauth-ID, then the TNGF 736 sends either an error response to UE 720, it initiates the signalling procedure related to normal authentication for trusted non-3GPP access as described in 3GPP Specification TS 33.501, titled “Security architecture and procedures for 5G system”, clause 7A.2.1. The UE context was created in the TNGF 736 when the UE 720 performed an initial registration (see Figure 6) via TNGF 736.

[0102] In the further steps 706a-706b, the TNGF 736 sends a 5G-Challenge packet to UE 720 which contains a TNonce value and a Message Authentication Codel (MAC1) derived by using the TNGF key stored in TNGF 736. This is shown as the TNGF 736 sending an AAA response to TNAP2 734 including the EAP-Request/5G challenge/TNone and the MACl. The TNAP2 734 then provides over L2 to the UE 720, the EAP- Request/5G-Challenge/TNonce/MACl .

[0103] In the further step 707, the UE 720 derives an expected MACl (XMAC1) using TNGF key stored in UE 720, and TNonce and compares XMAC1 with the received MACl . If they match, the TNGF 736 is authenticated by the UE 720. [0104] In a further step 708, the UE 720 generates a UNonce and derives a MAC2 using TNGF key stored in UE 720, and with UNonce and TNonce.

[0105] In further steps 709a-709b, the UE 720 responds to TNGF 736 with a 5G- Challenge containing UNonce, Tnonce and MAC2. This is shown as UE 720 responding over L2 to TNAP2 734 including EAP-Response/5G-Challenge/UNonce, TNonce, MAC2. The TNAP2 734 then responds to TNGF 736 with an AAA Request including EAP- Response/5G-Challenge/UNonce/TNonce/MAC2.

[0106] In a further step 710, the TNGF 736 derives an expected MAC2 (XMAC2) using TNGF and with UNonce and TNonce. The TNGF 736 compares XMAC2 with the received MAC2. If they match, the UE 720 is authenticated by TNGF 736.

[0107] In a further step 711, the TNGF 736 derives a fresh Reauth-ID for the UE 720, e.g., by using TNGF key stored in TNGF 736, TNGF -ID, TNonce and UNonce. In addition, the TNGF 736 derives a new TNAP key by using the TNGF key stored in TNGF 736, the TNGF-ID, the TNonce and Unonce values.

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

[0109] In a further step 713, the UE 720 derives a new Reauth-ID by using the TNGF key stored in UE 720, TNGF-ID, TNonce and UNonce. If the UE 720 and the TNGF 736 share the same TNGF key, then the Reauth-ID derived independently in the UE 720 and in the TNGF 736 will be the same. In addition, the UE 720 derives also a new TNAP key similarly to the TNGF 736 (as in step 711).

[0110] In a further step 714a-714b, the new TNAP key is applied to establish over-the- air security between the UE 720 and TNAP2 734. If needed, the 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. [0111] In further step 715, the UE 720 resumes communication with TNGF 736 via TNAP2 734 (NWt connection).

[0112] A further potential solution relates to TNAP mobility using modified ERP. In this example, the key rRK, is derived from KTNGF. The derivation of rRK is performed according to section 4.1 of the RFC Standard 6696 titled, “EAP Extensions for the EAP Reauthentication Protocol (ERP)”, replacing the input key EMSK with the key KTNGF. The lower layer keys (rIK, rMSKl, etc) are derived from rRK according to RFC Standard 6696. The difference is that no extra key needs to be transferred from the AMF and no ERP requests need to be sent. Another difference compared to ERP is that in standard ERP, the AUSF would need to receive an indication to derive rRK during primary authentication. This is called the bootstrapping steps of ERP. With the proposed modification however, a similar bootstrapping is not needed since the rRK will be based on KTNGF that is anyway present in the TNGF. This means that the bootstrapping is implicit rather than explicit. The rRK can be derived by TNGF once a mobility request is received or at any time when it is convenient. Figure 8 provides an example 800 of updated key hierarchy for trusted non- 3GPP access to support TNAP mobility. The example 800 illustrates key transfer of KTNGF 801 from AMF 810 to trusted N3GPP access keys. KTNGF 801 is shown as being used to derive keys Knpseo 802 in TNGF 820. Knpseo 802 is then used to setup IPSec SA 803 and child SAs 804. KTNAP 805 is also derived from KTNGF 801, for TNAP 830. rRK 806 is also derived from KTNGF 801, for TNGF 840. rRK 806 is used to derive rIK 807 and RMSKi-_n 808.

[0113] Whilst a number of candidate solutions have thus far been discussed, none of the candidate solutions address the problems described herein, notably that a TNGF which needs to provide security keys to a TNAP will not know UE’s re-authentication capability (i.e., whether it can support re-authentication related enhancements or methods and what is/are the re-authentication methods supported by the UE). Neither will the TNGF know the TNAP’s re-authentication capability (i.e., whether it can support re-authentication related enhancements or methods and what is/are the re-authentication methods supported by the TNAP). Hence, any re-authentication attempt between a UE and TNAP/TNGF will fail. [0114] As previously discussed, in a non-3GPP access network, different TNAPs may support different re-authentication protocols such as IEEE 802.11 based FT protocols or other non-FT protocol(s) such as any of 3 GPP native re-authentication protocol (a reauthentication and security establishment procedure or protocol specified by 3GPP), ERP or a modified ERP etc., The embodiments of the present disclosure present novel features to enable the UE and TNAP to indicate their respective re-authentication capabilities to allow the TNGF in the network to select a reauthentication method, generate the necessary re-authentication security context (specific to the supported and selected reauthentication method) and to provision the security context to the TNAP for a successful execution of the re-authentication and security establishment during the UE mobility scenario. Following a successful UE mobility (across different TNAPs) and security establishment, the embodiments herein also provide TNGF reporting of a newly serving TNAP Identifier (that acts as UE location information) to the AMF to allow the network to be aware of the UE’s updated location information. Further, the embodiments herein propose a method to support UE mobility between a FT capable AP and non-FT capable AP. These embodiments will now be discussed in greater detail.

[0115] Some embodiments provide a methods to indicate, select and use the supported re-authentication protocol/procedure for the UE mobility in Trusted Non-3GPP access and further provide related enhancements to the registration/authentication procedure.

[0116] A trusted non-3GPP access network is connected to the 5G Core Network via a Trusted Non-3GPP Gateway Function (TNGF). The TNGF interface with the 5G Core Network CP and UP functions via the N2 and N3 interfaces, respectively.

[0117] The embodiments describe how the UE and TNAP can indicate/inform the network (i.e., TNGF in the case of trusted non-3GPP access) about their respective reauthentication capabilities. A UE re-authentication capabilities information can indicate if the UE supports any one or more of: FT protocol (for Fast BSS Transition), non-3GPP access Key refresh (TNGF key refresh, N3IWF key refresh), non-3GPP access re- authentication/3GPP native re-authentication/ TNAP mobility security, modified ERP/ERP. Similarly, TNAP re-authentication capabilities information can indicate if the TNAP supports any one or more of: FT protocol (for Fast BSS Transition), non-3GPP access re- authentication/ 3 GPP native re-authentication/TNAP mobility security, modified ERP/ERP. Further the TNGF decides based on the received UE re-authentication capabilities and TNAP re-authentication capabilities which type of re-authentication to be initiated for a UE mobility scenario, then generates and provides related security context to the TNAP and indicates the UE (via TNAP) about the selected re-authentication type (or) about the type of security context to be derived at the UE for further security establishment.

[0118] Figures 9A-9B provides an example embodiment 900 of the UE and TNAP reauthentication capabilities exchange during authentication for UE trusted non-3GPP access, in accordance with aspects of the disclosure herein. The example 900 of Figures 9A-9B show a UE 920, a TNAN 930 comprising a TNAP 932 and TNGF 936, an AMF 940 and an AUSF 950. An L2 interface (i.e., ethernet, 802.3, 802.11, PPP, etc) is available between UE 920 and TNAP 932. An AAA interface is available between TNAP 932 and TNGF 936.

The various procedural steps/messaging flows 901- 915b of the example 900 will now be described. It should be noted that Figure 9A shows the procedural steps/messaging flows 901-908d and Figure 9B shows the procedural steps/messaging flows 909a-915b. The steps 909a-915b should be understood as following the steps 901-908d in the example 900. The representation of the steps 901-915b across the two figures of Figure 9A and Figure 9B is purely for illustrative purposes.

[0119] In the example 900 the UE 920 selects a PLMN and a TNAN 930 for connecting to this PLMN by using the Trusted Non-3GPP Access Network selection procedure specified in the 3GPP Specification TS 23.501 titled, “Study on security aspects for support for 5G Wireless and Wireline Convergence (5WWC) phase 2”, clause 6.3.12. During this procedure, the UE 920 discovers the PLMNs with which the TNAN 930 supports trusted connectivity (e.g., "5G connectivity").

[0120] The discussion of example 900 shall continue with reference to Figure 9A. In a first step 901, a layer-2 connection is established between the UE 920 and the TNAP 932. In case of IEEE 802.11 (see IEEE Standard 802.11-2016 (Revision of IEEE Standard 802.11-2012) IEEE Standard for Information Technology - Telecommunications and information exchange between systems, Local and Metropolitan area networks - specific requirements - Part 11, titled “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”), this step corresponds to an 802.11 Association. In case of PPP, this step corresponds to a PPP LCP negotiation. In other types of non-3GPP access (e.g., Ethernet), this step may not be required.

[0121] In further steps 902-903, an EAP authentication procedure is initiated. EAP messages shall be encapsulated into layer-2 packets, e.g., into IEEE 802.3/802. lx packets, into IEEE 802.11/802. lx packets, into PPP packets, etc. This is shown as TNAP 932 providing to UE 920 ‘L2 (EAP-Req/Identity)’ and UE 920 responding to TNAP 932 with ‘L2 (EAP-Res/Identity), username@realm’ . The UE 920 provides a NAI (i.e., username@realm that triggers the TNAP 932 to send a AAA request to a TNGF 936. Between the TNAP 932 and TNGF 936 the EAP packets are encapsulated into AAA messages. The AAA request also include the TNAP identifier, which can be treated as the User Location Information. It should be noted that the TNAP identifier can be treated as the User Location Information as per 3GPP Specification TS 23.501, titled “System architecture for the 5G System (5GS)”, Clause 4.12a.2.2, ‘Registration procedure for trusted non-3GPP access’. It should also be noted that a NAI may include or be constructed as "<any_username>@nai.5gc. mnc<MNC>.mcc<MCC>.3 gppnetwork.org" if UE 920 requests "5G connectivity" to a specific PLMN, or, NAI = "<any_username>@nai.5gc. nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org" if UE 920 request "5G connectivity" to a specific SNPN, or, if the WLANSP rule contains information including TNGF ID to use for specific slices and the UE 920 supports such information, the UE 920 builds the realm of NAI taking the TNGF ID into account NAI = "<any_username>@ tngfid<TNGF ID>.nai.5gc.mnc<MNC>.mcc<MCC> .3gppnetwork.org").

[0122] In further steps 904-910, an EAP-5G procedure is executed as specified in 3GPP TS 33.501 clause 7.2.1, where the EAP-Request/5G- Start packet from TNGF 936 informs the UE 920 to initiate an EAP-5G session, i.e., to start sending NAS messages encapsulated within EAP-5G packets. This is shown as an AAA message including EAP- Request/5G- Start being provided from TNGF 936 to TNAP 932, and then the EAP- Request/5G- start being provided over L2 from TNAP 932 to UE 920. This procedure includes further modifications as will now be discussed. It should be noted that the EAP- 5G packets shall not be encapsulated into IKEv2 packets. [0123] In further step 905a, the UE 920 can send a EAP-Response/5G-NAS packet that contains a Registration Request message containing UE security capabilities, UE reauthentication capabilities, and the SUCI. If UE 920 is already with the 5GC over 3GPP access and there is an available security context, the UE 920 can integrity protect the Registration Request message and shall send the 5G-GUH instead of SUCI. The TNGF 936 can refrain from sending an EAP-Identity request. The UE 920 may ignore an EAP Identity request or respond with the SUCI/5G-GUH it sent in the Registration Request. If the UE 920 has registered to the same AMF 940 through 3 GPP access, and if this is the first time that the UE 920 connects to the 5GC through non-3GPP access, the value of corresponding UL NAS COUNT used for integrity protection is 0; else it can use the existing non-3GPP specific UL NAS COUNT for integrity protection. In some embodiments, the UE 920 can send UE reauthentication capabilities as individual IE in EAP-Response/5G-NAS packets (to be forwarded by TNAP 932 to the TNGF 936). The UE 920 shall also include a UE ID in the AN parameter, e.g., a 5G-GUTI if available from a prior registration to the same PLMN. This is shown as UE 920 providing TNAP 932, over L2, with ‘(EAP-Res/5G-NAS/AN-Params (S-NSSAI or 5G-GUTI), NAS-PDU (Reg.Req (UE re-auth Capabilities)))’.

[0124] In further step 905b, the TNAP 932 sends to TNGF 936 in AAA interface (or message) the TNAP re-authentication capabilities. The received EAP-Response/5G-NAS packet that contains a Registration Request message is also forwarded. This is shown as TNAP 932 providing TNGF 936, over AAA, with ‘(EAP-Res/5G-NAS/AN-Params (S- NSSAI or 5G-GUTI), NAS-PDU (Reg.Req (UE re-auth Capabilities)), TNAP re-auth capabilities)’. It should be noted that alternatively, new IE sent by UE 920 in step 905 can be sent unprotected as a separate IE, in such a case adaptation in the subsequent steps 906a and 910a is not required.

[0125] In further steps 906a-906b, the TNGF 936 selects an AMF 940 as specified in the 3GPP Specification TS 23.501, titled “System architecture for the 5G System (5GS)”, clause 6.5.3. The TNGF 936 forwards the Registration Request (which includes also UE security capabilities, UE reauthentication capabilities, and the SUCI) received from the UE 920 to the AMF 940. This is shown as, ‘AMF Selection’ being performed at TNGF 936 and TNGF 936 providing over N2 to AMF 940 an N2 message including ‘(Registration Request (UE re-auth Capabilities))’. It should be noted that the TNGF 936 if it receives TNAP reauthentication capabilities, may store the TNAP re-authentication capabilities along with the TNAP identifier.

[0126] The furthers steps 907a-907d and 908a-908d will now be described.

[0127] If the AMF 940 receives a 5G-GUTI and the Registration is integrity protected, it may use the security context to verify the integrity protection as described in the 3 GPP Specification TS 33.501 clause 6.4.6. If the UE 920 has registered to the same AMF 940 through 3 GPP access, and if this is the first time that the AMF 940 receives UE’s NAS signalling through non-3GPP access, the value of corresponding UL NAS COUNT used for integrity verification is 0; else it can use the existing non-3GPP specific UL NAS COUNT for integrity verification. If integrity is verified successfully, it indicates that UE 920 is authenticated by AMF 940. The various messages 907a-907b illustrate such a procedure. More specifically, step 907a shows AMF 940 and TNGF 936 exchanging N2 messages including ‘(Identity Req./Res.)’. Step 907b shows TNGF 936 and TNAP 932 exchanging over AAA, ‘(EAP-REQ/RES/5G-NAS/NAS-PDU(Identity Req./Res.))’; and TNAP 932 and UE 920 exchanging over L2, ‘(EAP-REQ/RES/5G-NAS/NAS-PDU(Identity Req./Res.))’. If integrity is verified successfully and no newer security context has been activated over the 3 GPP access, then step 909 to step 911 may be skipped. If integrity is verified successfully and a newer security context has been activated over the 3 GPP access then authentication may be skipped but the AMF 940 shall activate the newer context with a NAS SMC procedure as described in step 909 and onwards. Otherwise, the AMF 940 shall authenticate the UE 920.

[0128] If the AMF 940 decides to authenticate the UE 920, it shall use one of the authentication methods discussed in clause 6.1.3 of the 3GPP document TS 33.501, titled "Security architecture and procedures for 5G system”. In this case, the AMF 940 shall send a key request to the AUSF 950 as shown in step 908a, ‘Nausf_UEAuthentication Authenticate Request (SUPI or SUCI)’. The AUSF 950 may initiate an authentication procedure as specified in clause 6.1.3 of the 3GPP document TS 33.501, titled "Security architecture and procedures for 5G system”. This authentication procedure is shown by step 908b as, ‘Authentication and Key Agreement’. Between AMF 940 and UE 920, the authentication packets are encapsulated within NAS authentication messages and the NAS authentication messages are carried in N2 signalling between the AMF 940 and TNGF 936, and then are encapsulated within EAP-5G/5G-NAS packets between the TNGF 936 and the UE 920.

[0129] In the final authentication message from the home network, the AUSF 950 shall send the anchor key KSEAF derived from KAUSF to the SEAF. The SEAF shall derive the KAMF from KSEAF and send it to the AMF 940 which is used by the AMF 940 to derive NAS security keys. This is shown in step 908c as, ‘Nausf_UEAuthentication Authenticate Response (SEAF key, EAP-Success)’. If EAP-AKA' is used for authentication as described in clause 6.1.3.1 of the 3GPP document TS 33.501, titled "Security architecture and procedures for 5G system”, then the AUSF 950 shall include the EAP-Success. The UE 920 also derives the anchor key KSEAF and from that key it derives the KAMF followed by NAS security keys. This is shown in step 908d as, ‘TNGF/TNAP Keys created’. The NAS COUNTs associated with NAS connection identifier "0x02" are set at the UE 920 and AMF 940.

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

[0131] In further steps 909c-909d, the UE 920 completes the authentication (if initiated in step 907) and creates a NAS security context or activates another one based on the received ngKSI in the NAS SMC. UE 920 shall respond to the NAS SMC it received from the AMF 940 based on the selected algorithms and parameters as described in clause 6.7.2 of the 3GPP document TS 33.501, titled "Security architecture and procedures for 5G system”. The UE 920 shall encapsulate the NAS SMC Complete in the EAP-5G Response. More specifically, UE 920 provides TNAP 932 over L2 with, ‘(EAP-Res/5G-NAS/SMC Complete)’. The TNAP 932 forwards this to TNGF 936 over AAA. The TNGF 936 then provides AMF 940 with an N2 message including the SMC complete.

[0132] In further steps 910a-910d, a KTNGF (for trusted non-3GPP access) as described below (equivalent to KNSIWF of untrusted non-3GPP access) is created in the UE 920 and in the AMF 940 after the successful authentication. The KTNGF is transferred from the AMF 940 to TNGF 936 in step 910a (within the N2 Initial Context Setup Request). If the AMF 940 received UE re-authentication capabilities in the Registration Request in step 906b, then the AMF 940 also sends the UE re-authentication capabilities in step 910a to the TNGF 936. This is shown as, ‘N2 Initial Ctx Setup Request (KTNGF), UE re-auth Capabilities’.

[0133] When deriving the keys KWAGF, KTNGF, KTWIF and KNSIWF from KAMF and the uplink NAS COUNT, in the UE 920 and the AMF 940, the following parameters shall be used to form the input S to the KDF: FC = 0x6E; P0 = Uplink NAS COUNT; L0 = length of uplink NAS COUNT (i.e. 0x00 0x04); Pl = Access type distinguisher; LI = length of Access type distinguisher (i.e. 0x00 0x01). The values for the access type distinguisher are defined in Table 1 below. The values 0x00 and 0x03 to OxfO are reserved for future use, and the values Oxfl to Oxff are reserved for private use. The access type distinguisher shall be set to the value for non-3GPP (0x02) when deriving KNSIWF, KWAGF, KTWIF or KTNGF. The input key KEY shall be the 256-bit KAMF.

Table 1

[0134] It should be noted that the including of UE re-authentication capabilities 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, the AMF 940 can provide the UE re-authentication capabilities to the TNGF 936 in step 910a. [0135] Furthermore, the TNAP 932 is a trusted entity. The TNGF 936 shall generate the KTNAP as described below and transfer it from the TNGF 936 to the TNAP 932 in step 910b (i.e., within a AAA message).

[0136] When deriving a Kripseo from KTNGF and when deriving a KTNAP from KTWIF or KTNGF the following parameters shall be used to form the input S to the KDF: FC = 0x84; P0 = Usage type distinguisher; L0 = length of Usage type distinguisher (i.e., 0x00 0x01). The values for the Usage type distinguisher are defined in Table 2 below. The values 0x00 and 0x03 to OxfO are reserved for future use, and the values Oxfl to Oxff are reserved for private use. The Usage type distinguisher shall be set to the value for IPSec (0x01) when deriving Kripseo. The Usage type distinguisher shall be set to the value for TNAP (0x02) when deriving KTNAP. The input key KEY shall be the 256-bit KTNGF or KTWIF.

Table 2

[0137] After receiving the TNGF key from AMF 940 in step 910a, the TNGF 936 shall send to UE 920 an EAP-Request/5G-Notification packet containing the "TNGF Contact Info", which includes the IP address of TNGF in step 910b. This is shown as TNGF 936 providing TNAP 932 over AAA with ‘(EAP-Req/5G-Notification/TNGF Address)’. The TNAP 932 then forwards this to UE 920 over L2. The UE 920 then provides, in step 910c, an EAP-Res/5G- notification over L2 to TNAP 932. The TNAP 932 forwards this to TNGF 936 over AAA. In step 91 Od, after receiving the EAP-Response/5G-Notification packet from the UE 920 in step 910c, the TNGF 936 may select the re-authentication method/type to be used for the UE 930 (either now or later during the UE mobility as described herein). The TNGF 936 then sends a message containing the selected re-authentication method IE, security key information specific to the selected re-authentication method, and EAP- Success packet. Put differently, based on UE 920 and TNAP 932 re-authentication support capabilities, select re-authentication method(s) to be used with priority, and provide reauthentication method specific security information in step 91 Oe or later during mobility. [0138] The selected re-authentication method IE can indicate any one of: FT protocol (for Fast BSS Transition); ornon-3GPP access re-authentication/3GPP native re- authentication/TNAP mobility security; modified ERP/ERP.

[0139] If FT protocol (for Fast BSS Transition) is selected, then a FT key is derived and provided as security key information in addition to the TNAP key. If non-3GPP access re- authentication/3GPP native re-authentication/TNAP mobility security is selected, freshness parameters such us Nonces/Counter/Random number and re-authentication Identifier to use in future mobility are generated and provided as security key information in addition to the TNAP key. If modified ERP/ERP is selected, rRK and re-authentication Identifier are derived and stored and a re-authentication identifier is provided in addition to the TNAP key.

[0140] Alternatively, if FT is selected only, then the FT key is derived and provided. Alternatively, the TNGF 936 stores the received UE re-authentication capabilities along with UE context to be used for the secure re-authentication method selection during the actual UE mobility later. In this case selected re-authentication method information is not sent in step 910e to the UE 920 (via the TNAP 932).

[0141] The UE 920 and the TNGF 936 can derive a Re-authentication Identifier (Reauth-ID) for the UE 920 from the TNGF key using the input parameters such as TNGF- ID, Nonce from TNGF 936, Nonce from UE 920. Alternatively, Re-authentication Identifier (Reauth-ID) can be a generated as <PLMNID><TNGF_ID> <Temp Id>, for instance.

[0142] The steps 910e show the TNGF 936 providing the TNAP 932 over AAA with, ‘TNAP Key, EAP-Success, Selected Re-auth method(s) IE, Security information (FT Key/Re-auth ID/Nonces/TNGF ID/TNGF address). The TNAP 932 provides to the UE 920 the EAP-Success and optionally the selected Re-auth method(s).

[0143] In a further step 911, the common TNAP key is used by the UE 920 and TNAP 932 to derive security keys according to the applied non-3GPP technology and to establish a security association to protect all subsequent traffic. In case of IEEE 802.11 (see the IEEE Standard 802.11-2016 (Revision of IEEE Standard 802.11-2012) IEEE Standard for Information Technology - Telecommunications and information exchange between systems, Local and Metropolitan area networks - specific requirements - Part 11, titled “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”), the KTNAP is the Pairwise Master Key (PMK) and a 4-way handshake is executed (see IEEE 802.11 as above) which establishes a security context between the WLAN AP and the UE 920 that is used to protect unicast and multicast traffic over the air. All messages between UE 920 and TNAP 932 are encrypted and integrity protected from this step onwards. Step 911 relates to security establishment using a key derived from MSK key (e.g., 4-way handshake for WLAN).

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

[0145] In further step 912, the UE 920 receives IP configuration from the TNAN 932, e.g., with DHCP. This is shown as ‘Local IP Configuration’.

[0146] In further steps 913a-913c, the UE 920 shall initiate an IKE INIT exchange with the TNGF 936. The UE 920 has received the IP address of TNGF 936 during the EAP- 5G signalling in step 909b, subsequently, the UE 920 shall initiate an IKE AUTH exchange and shall include the same UE ID (i.e., SUCI or 5G-GUTI) as in the UE ID provided in step 905. The common Kripse is used for mutual authentication. The key Knpseo is derived as specified in Annex A.22 of the 3GPP document TS 33.501, titled "Security architecture and procedures for 5G system”. NULL encryption is negotiated as specified in RFC 2410. After step 913c, an IPsec SA is established between the UE 920 and TNGF 936 (i.e., a NWt connection) and it is used to transfer all subsequent NAS messages. This Ipsec SA does not apply encryption but only apply integrity protection. For completeness, step 913a between UE 920 and TNGF 936 is shown as, TKE_INIT’; step 913b between UE 920 and TNGF 936 is shown as, ‘IKE AUTH (Idi, SA, TSi, TSr, AUTH)’; and the step 913c between UE 920 and TNGF 936 is shown as, ‘IKE AUTH (Idr, SA, TSi, TSr, AUTH)’.

[0147] In the further step 914a, after the NWtp connection is successfully established, the TNGF 936 responds to AMF 940 with an N2 Initial Context Setup Response message with the UE ID (5G-GUTI) and currently serving TNAP’s Identifier. [0148] In the further step 914a, the AMF 940 may determine whether the TNGF 936 is appropriate for the slice selected as defined in clause 4.12.2.2 of the 3GPP Specification TS 23.502. If it is compatible with the selected TNGF 936, then the procedure continues with step 915a with a Registration Accept. Otherwise, the AMF 940 shall proceed with alternative step 915a with a Registration Reject.

[0149] In further steps 915a-915b, the NAS Registration Accept message is sent by the AMF 940 and is forwarded to UE 920 by the TNGF 936 along with the Re-authentication method (if selected) and if it is not provided earlier in step 91 Oe via the established NWt connection. This is shown as the AMF 940 providing TNGF 936 with an N2 message including NAS registration accept/reject. The TNGF 936 then provides UE 920: over NWt- cp connection, the NAS registration accept (and optionally the selected re-auth method); or over NAS over Ipsec the NAS registration reject.

[0150] The UE 920 initiates a PDU session establishment. The TNGF 936 may establish one or more IPSec child SA’s per PDU session. User plane data for the established PDU session is transported between the UE 920 and TNGF 936 inside the established IPSec child SA

[0151] In an alternative case, steps 915a-915b may comprise the AMF 940 triggering the UE policy update procedure and update the UE policy. The AMF 940 shall send a Registration Reject message via TNGF 936 to the UE 920. The Registration Reject message is ciphered and integrity protected, and a new 5G-GUTI is provided to the UE 920. The UE 920 shall decipher and verify the integrity of the Registration Reject message. If verification is successful, then the UE 920 proceeds with step 21 in clause 4.12.2.2 of the 3 GPP Specification TS 23.502, and sends an integrity protected Registration request message to the AMF 940 via a new selected TNGF 936.

[0152] It should be noted that the example 900 may also be applied to Untrusted Non- 3GPP access through the following adaptations. An untrusted non-3GPP access network can connect to the 5G Core Network via a Non-3GPP InterWorking Function (N3IWF) instead a Trusted Non-3GPP Gateway Function (TNGF) 936. The N3IWF interface with the 5G Core Network CP and UP functions via the N2 and N3 interfaces, respectively. The procedure described in the example 900 can also work for untrusted non-3GPP access network with the only difference that TNAN 930 with TNGF 936 and TNAP 932 is replaced with a untrusted non-3GPP access node/point.

[0153] Further embodiments of the disclosure herein relate to methods to indicate, select and use the supported re-authentication protocol/procedure for UE mobility in Trusted Non-3GPP access and further relate to enhancements to the mobility/re- authentication procedure. These embodiments describe how a UE and new/target TNAP can indicate/inform the network (i.e., TNGF in the case of trusted non-3GPP access) about their respective re-authentication capabilities during the UE mobility scenario. A UE reauthentication Capabilities information can indicate if the UE supports any one or more of: FT protocol (for Fast BSS Transition), non-3GPP access Key refresh (TNGF key refresh, N3IWF key refresh), non-3GPP access re-authentication/3GPP native re-authentication/ TNAP mobility security, modified ERP/ERP. Similarly, a TNAP re-authentication Capabilities information can indicate if the TNAP supports any one or more of: FT protocol (for Fast BSS Transition), non-3GPP access re-authentication/ 3GPP native re- authentication/TNAP mobility security, modified ERP/ERP. The TNGF can check during the UE mobility procedure if the received re-authentication capabilities matches with the stored re-authentication capabilities from the (initiation/initial) registration (as earlier described with reference to Figures 9A-9B) earlier to verify if the re-authentication capabilities are not tampered. Further the TNGF decides based on the received UE reauthentication Capabilities and TNAP re-authentication Capabilities which type of reauthentication is to be initiated for a UE mobility scenario, then generates and provides related security context to the TNAP and indicates to the UE (via TNAP) about the selected re-authentication type, or, about the type of security context to be derived at the UE for further re-authentication and security (re-) establishment.

[0154] Figures 10A-10C provide an example embodiment 1000 of UE and TNAP reauthentication capabilities exchange during reauthentication/mobility for UE trusted non- 3 GPP access, in accordance with aspects of the disclosure herein. The example embodiment 1000 shows a UE 1020, a TNAN 1030 comprising a TNAP 1 1032, a TNAP 1034 and a TNGF 1036. Further shown is an AMF 1040. The various procedural steps/message flows 1000a-1017c will now be described with reference to Figures 10A- IOC. In this respect, it is to be understand that Figures 10B-10C correspond to the Option 1 and the Option 2 depicted in Figure 10A. Put differently, the Option 1 and Option 2 are provided in Figures 1 OB- IOC for illustrative purposes only and should be interpreted as being part of the example embodiment 1000 where either of Option 1 or Option 2 are used.

[0155] In the example 1000, there is considered to be an NWt connection established initially between UE 1020 and TNGF 1036 via TNAP1 1032. Indeed, TNAP1 1032 can be considered the current TNAP. This is shown by step 1000a. The UE 1020 determines to move to TNAP2 1034 at step 1000b. Indeed, TNAP2 1034 can be considered the target TNAP.

[0156] In a further step 1001, the UE 1020 establishes a layer-2 (L2) connection with TNAP2 1034. The TNAP2 1034 determines whether it is FT capable.

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

[0158] Else if the TNAP2 1034 does not support FT, but if the TNAP2 1034 supports (i.e., TNAP re-authentication capabilities includes) non-3GPP access re-authentication/ 3 GPP native re-authentication/TNAP mobility security, or modified ERP/ERP, then the TNAP2 1034 initiates an EAP session as usually by requesting the UE identity. For the purposes of the example 1000 the TNAP2 1034 determines that it does not support FT. The steps 1002 show TNAP2 1034 providing over L2 to UE 1020 an EAP-Req/Identity.

[0159] In a further step 1003, the UE 1020 provides over L2 to TNAP2 1034 an EAP- Response/Identity. Also provided is a Network Access Identifier (NAI) containing username = Reauth-ID and realm = nai.5gc.tngf<TNGF- ID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org and UE re-authentication Capabilities. The Reauth-ID was derived as described for Figure 6 and the TNGF-ID was received when the UE 1020 was first connected to TNGF 1036, e.g., with an Initial Registration via TNGF 1036. The UE 1020 provides username = Reauth-ID because the UE 1020 does not want to initiate NAS signalling with 5GC, but it wants to reauthenticate with the TNGF 1036. Alternatively, if Re-auth ID is provided by TNGF 1036 during registration, the UE 1020 can provide the received Re-auth in step 1001.

[0160] In further steps 1004a-1004b. The TNAP2 1032 selects TNGF 1036 based on the TNG1-ID in the received realm and forwards the NAI and received UE reauthentication Capabilities to TNGF 1036. In addition, the TNAP2 also includes its own TNAP re-authentication Capabilities information and TNAP ID and provides these to the TNGF 1036. The step 1004a depicts the TNAP2 1034 selecting the TNGF 1036. The step 1004b depicts the TNAP2 1034 providing an AAA request to TNGF 1036, the AAA request including (EAP-Res/Identity NAI, UE re-auth Capabilities), TNAP re-auth capabilities, and TNAP ID.

[0161] In the further step 1005a, the TNGF 1036 finds a stored UE context containing the received Reauth-ID and UE re-authentication Capabilities, thus, it determines that the UE 1020 is a known UE which requests reauthentication. Therefore, it initiates the following steps of example 1000. If the TNGF 1036 cannot find a stored UE context containing the received Reauth-ID, then the TNGF 1036 sends either an error response to UE 1020, and it initiates the signalling procedure related to normal authentication for trusted non-3GPP access as described in 3GPP Specification TS 33.501 clause 7A.2.1. The TNGF 1036 can check if the received re-authentication capabilities matches with the stored UE re-authentication capabilities from the (initial) registration (as described herein with respect to Figure 9) to verify if the re-authentication capabilities are not tampered with.

[0162] In the further step 1005b, based on the UE re-authentication Capabilities and received TNAP re-authentication Capabilities, TNGF 1036 selects a common reauthentication method supported by both UE 1020 and TNAP2 1034 to use for the reauthentication during the mobility. Based on the selected re-authentication method the TNGF 1036 also derives the re-authentication security context. The TNGF 1036 also provides the derived re-authentication security context to the new TNAP2 1034 and indicates the selected re-authentication method specific information (i.e., security information to derive keys) to be forwarded to the UE 1020 to allow the UE 1020 to derive the same re-authentication security context similar to the TNGF 1036. [0163] The reauthentication procedural steps will vary dependent upon which reauthentication procedure is selected. For instance, if non-3GPP access re- authentication/3GPP native re-authentication/TNAP mobility security is selected then the reauthentication procedure referred to as Option 1 and represented in Figure 10B will be followed. More specifically, the steps 1006a- 1013 of Figure 10B and then the steps 1015- 1017c of Figure 10A will be executed. If modified ERP/ERP is selected, then the reauthentication procedure referred to as Option 2 and represented in Figure 10C will be followed. More specifically the steps 1014a-1014d of Figure 10C and then the steps 1015- 1017c of Figure 10A will be executed.

[0164] The Option 1 and Option 2 procedure will now be discussed. It should be noted that the UE context (e.g., TNGF key, UE ID) was created/provided in the TNGF 1036 when the UE 1020 performed an initial registration via TNGF 1036.

[0165] For the discussion of Option 1 the Figure 10B will be described.

[0166] In further steps 1006a-1006b, the TNGF 1036 sends a 5G-Challenge packet to UE 1020 which contains a TNonce value, selected re-authentication type/method (optional to be sent here in this step or it can be sent in step 1012a later), and a Message Authentication Codel (MAC1) derived by using the TNGF key stored in TNGF 1036. More specifically, in step 1006a the TNGF 1036 provides to TNAP2 1034 an AAA Response including ‘(EAP-Req/5G-Challenge/TNonce, selected re-authentication type/method, MAC1)’. The TNAP2 1034 then provides over L2 to UE 1020, the EAP- Req/5G-Challenge/TNonce and MACE

[0167] In further step 1007, the UE 1020 (based on the selected re-authentication type/method indicated (in step 1006a/1006b) understands the type of re-authentication that need to be executed) derives an expected MAC1 (XMAC1) using TNGF key stored in UE 1020, and TNonce. The UE 1020 compares XMAC1 with the received MACl. If they match, the TNGF 1036 is authenticated by the UE 1020.

[0168] In further step 1008, the UE 1020 generates a UNonce and derives a MAC2 using TNGF key stored in UE 1020, and with UNonce and TNonce. [0169] In further step 1009a- 1009b, the UE 1020 responds over L2 to TNAP2 1034, with a EAP-Response/5G-Challenge containing UNonce, TNonce and MAC2. The TNAP2 1034 then provides an AAA Request to TNGF 1036 containing the EAP-Response/5G- Challenge, UNonce, TNonce, MAC2.

[0170] In a further step 1010, the TNGF 1036 derives an expected MAC2 (XMAC2) using TNGF key and with UNonce and TNonce. The TNGF 1036 compares XMAC2 with the received MAC2. If they match, the UE 1020 is authenticated by TNGF 1036.

[0171] In a further step 1011, the TNGF 1036 derives a fresh Reauth-ID for the UE 1020, e.g. by using TNGF key stored in TNGF 1036, TNGF-ID, TNonce and UNonce. In addition, the TNGF 1036 derives a new TNAP key by using the TNGF key stored in TNGF 1036, the TNGF-ID, the TNonce and UNonce values.

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

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

[0174] For the discussion of Option 2 the Figure 10C will be described.

[0175] In a first step 1014a, the TNGF 1036 derives the rRK and rMSK (as a new TNAP key) and stores it along with the Re-auth ID. [0176] In a further step 1014b, the TNGF 1036 sends in an AAA response the EAP success message or EAP-Finish/Re-auth message along with new TNAP key (rMSK), and the selected re-authentication type/method.

[0177] In a further step 1014c, the TNAP2 1034 forwards to UE 1020, the EAP success message or EAP-Finish/Re-auth message in an L2 message along with the received selected re-authentication type/method indication/information.

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

[0179] Returning to Figure 10A, the remaining procedural steps 1015a-1017c will now be discussed. These steps are generally applicable (i.e., applicable whether Option 1 or Option 2 procedures have been used).

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

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

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

[0183] In further step 1017b, the AMF 1040 updates the UE location information/UE Context) with the currently serving TNAP Identifier. [0184] In further step 1017c, the AMF 1040 sends to TNGF 1036 a N2 Initial Context Setup Update Acknowledgement/Response message (in any N2 message) with Success/acknowledgment indication.

[0185] Certain adaptations of the example 1000 can be made to enable the example 1000 to operate for untrusted Non-3GPP access. An untrusted non-3GPP access network can connect to the 5G Core Network via a Non-3GPP InterWorking Function (N3IWF) instead a Trusted Non-3GPP Gateway Function (TNGF) 1036. The N3IWF interface with the 5G Core Network CP and UP functions via the N2 and N3 interfaces, respectively. The procedure described in the example embodiment 1000 can also work for untrusted non- 3GPP access networks with the only difference that TNAN 1030 comprising TNGF 1036 and TNAP1/TNAP2 1032/1034 is replaced with a untrusted non-3GPP access node/point.

[0186] Further embodiments of the disclosure herein relate to, methods to inform UE location information to the network during FT based UE mobility procedures. These embodiments describes how the UE mobility can be supported between two TNAPs which support two different reauthentication protocols such as FT (i.e., IEEE 802.11 based FBSS) and non-FT (i.e., non-3GPP access re-authentication/3GPP native re-authentication/TNAP mobility security establishment methods).

[0187] Figure 11 shows an example 1100 where a UE moves from a currently serving AP (which is a Non-FT capable AP) to a new target AP (which is FT capable), in accordance with aspects of the disclosure herein. Shown in the example 1100 is a UE 1120, a TNAP1 1132, a TNAP2 1134 and a TNGF 1136. The various procedural steps/message flows 1101-1106 will now be described. The TNAP1 1132 is considered to be non-FT capable. The TNAP2 1134 is considered to be FT capable. Furthermore, the TNAP1 1132 may be considered to be the current TNAP serving the UE 1120. The TNAP2 1134 may be considered to be the target TNAP. Put differently, there is a current successful and secure session and data transmission occurring between UE 1120 and TNAP1 1132.

[0188] In a first step 1101, a FT capable UE 1120 may send a FT request (FTO, FTO address, TargetAP address, RSNE[PMKR0Name], MDE, FTE [SNonce, R0KH-ID])) to the new Target AP TNAP2 1134. The UE 1120 may include 5G-GUTI or any UE ID/Re-auth Identifier known to both TNGF 1136 and itself and the TNGF 1136 address in the FTO. [0189] In a further step 1102, if the target AP TNAP2 1134 could not fetch any FT related key (e.g., PMK-R1 or PMK-Rx) from a FT key holder (RO-KH), then the target AP TNAP2 1134 determines to fetch a FT key from the TNGF 1136.

[0190] In a further step 1103, the target AP TNAP2 1134 contacts the TNGF 1136 based on the FTO which includes the UE ID and TNGF ID. The target AP TNAP2 1134 sends in a AAA request, a FT key request message with TNAP-reauth capabilities, TNAP ID, FTO/5G-GUTI/Re-auth ID and indicates that UE supports FT protocol.

[0191] In a further step 1104, the TNGF 1136 based on FTO/5G-GUTI/Re-auth ID identifies the UE context, and checks the UE re-authentication capabilities to see if it matches the TNAP provided information that UE 1120 supports FT. If the verification is successful, the TNGF 1136 derives a FT key from the TNGF key.

[0192] In a further step 1105, the TNGF 1136 sends a AAA response to TNAP2 1134 with a FT key response message which includes the FT key.

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

[0194] As a further adaptation of the example embodiment 1100, for the untrusted non- 3GPP scenario, the TNAP 1132/1134 is replaced by an AP and the TNGF 1136 is replaced by an N3IWF.

[0195] Figure 12 shows a further example embodiment 1200 of a UE which moves ]from a currently serving AP (which is an FT capable AP) to a new target AP (which is a non-FT capable), in accordance with aspects of the disclosure herein. The example 1200 shows a UE 1220, a TNAP1 1232, a TNAP2 1234, and a TNGF 1236. The TNAP1 1232 can be considered an FT capable AP. The TNAP2 1234 can be considered a non-FT capable AP. Furthermore, the TNAP1 1232 can be considered the current serving AP for UE 1220 i.e., a successful and secure session and data transmission is occurring. The TNAP2 1234 can thus be considered the target AP. The various procedural steps/message flows 1201-1206 will now be described. [0196] In a first step 1201, a FT capable UE 1220 may send a FT request (FTO, FTO address, TargetAP address, RSNE[PMKROName], MDE, FTE [SNonce, ROKH-ID])) to the new Target AP TNAP2 1234. The UE 1220 may include 5G-GUTI or any UE ID/Re-auth Identifier known to both TNGF 1236 and itself and include the TNGF address in the FTO.

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

[0198] In a further step 1202b, the TNAP2 1234 initiates an EAP session, usually by requesting the UE identity. This is shown as TNAP2 1234 providing UE 1220 over L2 with EAP-Req/Identity.

[0199] In a further step 1203, the UE 1220 provides to TNAP2 1234 over L2 a EAP- Res/Identity and a Network Access Identifier (NAI) containing username = Reauth-ID and realm = nai.5gc.tngf<TNGF-ID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org, 5G-GUTI and UE re-authentication Capabilities. The Reauth-ID and the TNGF-ID was received when the UE 1220 was first connected to TNGF 1236, e.g. with an Initial Registration via TNGF 1236. The UE 1220 provides username = Reauth-ID and 5G-GUTI because the UE 1220 does not want to initiate NAS signalling with 5GC, but it wants to reauthenticate with the TNGF 1236. Alternatively, if Re-auth ID is provided by TNGF 1236 during registration, the UE 1220 can provide the received Re-auth in step 1201.

[0200] In a further step 1204, the target TNAP2 1234 selects TNGF 1236 based on the TNGF 1 -ID in the received realm and forwards in an AAA request the EAP-Res/Identity, the NAI, 5G-GUTI and received UE re-authentication Capabilities to TNGF 1236. In addition, the TNAP2 1234also includes its own TNAP re-authentication Capabilities information and the TNAP ID to the TNGF 1236.

[0201] In a further step 1205, the TNGF 1236 finds a stored UE context containing the received Reauth-ID/5G-GUH and UE re-authentication Capabilities, thus, it determines that the UE 1220 is a known UE which requests reauthentication. Therefore, it initiates the steps 1005b to 1017c of Figures 10A-10C. If the TNGF 1236 cannot find a stored UE context containing the received Reauth-ID, then the TNGF 1236 sends either an error response to UE 1220, or it initiates the signalling procedure related to normal authentication for trusted non-3GPP access as described in the 3GPP Specification TS 33.501 clause 7A.2.1. The TNGF 1236 can check if the received re-authentication capabilities matches with the stored UE re-authentication capabilities from the (initial) registration earlier to verify if the re-authentication capabilities are not tampered.

[0202] As noted above, in further step 1206 the steps 1005b to 1017c of Figures 10A- 10C may then be executed.

[0203] The disclosure herein provides a network function for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network function to: receive one or more first parameters indicating a capability of a user equipment (UE) for reauthenticating with a wireless communication network; receive one or more second parameters indicating a capability of a first network access point for reauthenticating with the wireless communication network; determine, based on the one or more first parameters and the one or more second parameters, a reauthentication type for UE mobility; and determine, based on the reauthentication type, a security information for UE mobility.

[0204] The network function may be a TNGF or an N3IWF as described in aspects of the disclosure herein i.e., the TNGF 936 of Figure 9, the TNGF 1036 of Figure 10, the TNGF 1136 of Figure 11, the TNGF 1236 of Figure 12.

[0205] The UE may be a UE as described in aspects of the disclosure herein i.e., the UE 920 of Figure 9, the UE 1020 of Figure 10, the UE 1120 of Figure 11, the UE 1220 of Figure 12.

[0206] The first network access point may be a trusted or untrusted access point as described in aspects of the disclosure herein i.e., the first network access point may be a TNAP 932 of Figure 9, a TNAP 1032, 1034 of Figure 10, a TNAP 1132, 1134 of Figure 11, a TNAP 1232, 1234 of Figure 12.

[0207] The wireless communication network may be a wireless communication network or system, a 3 GPP network, a core network, a 5GS/5GC, as described in aspects of the disclosure herein i.e., the wireless communication system 100 of Figure 1. [0208] The one or more first parameters indicating a capability of the first network access point for reauthenticating with the wireless communication network, are also referred to herein as ‘UE re-authentication capabilities information’ and ‘UE reauthentication capabilities’.

[0209] The one or more second parameters indicating a capability of a first network access point for reauthenticating with the wireless communication network, are also referred to herein as ‘TNAP re-authentication capabilities information’ and ‘TNAP reauthentication capabilities’.

[0210] The term ‘UE mobility’ would be understood by one skilled in the art but for completeness includes mobility of a UE resulting in the UE connection to a wireless communication network being transitioned, migrated, or moved from one access point to another access point as described in the embodiments herein. The term ‘UE mobility’ may also be referred to in the context of a ‘UE mobility scenario’ or ‘UE mobility procedure’.

[0211] The security information is also referred to in the embodiments herein as ‘security context’ or ‘security context information’.

[0212] The reauthentication type is also referred to herein as ‘reauthentication method’, ‘reauthentication procedure’ or ‘reauthentication protocol’.

[0213] The network function tends to allow a UE and network access point to provide their respective capabilities for reauthenticating with a wireless communication network for UE mobility. Hence, the network function can determine an appropriate reauthentication type/method based on the provided capabilities and generate therefrom suitable security information for the reauthentication. This tends to mitigate the problem of a network function not being aware of UE and network access point reauthentication capabilities, and hence mitigates the failure of reauthentication attempts. Other problems mitigated by the network function will be apparent from the disclosure herein.

[0214] In some embodiments, the at least one processor coupled with the at least one memory is further configured to cause the network function to: provide the reauthentication type and/or security information to the first network access point; and/or provide the reauthentication type and/or the security information to the UE. [0215] In some embodiments, the at least one processor coupled with the at least one memory is configured to cause the network function to receive the one or more first parameters and the one or more second parameters during a registration procedure and/or a UE mobility procedure for the UE.

[0216] As described herein, the registration procedure may be an initial registration performed in accordance with the example 900 of Figure 9. The UE mobility procedure may be the UE mobility scenario performed in accordance with the example 1000 of Figure 10, the example 1100 of Figure 11, or the example 1200 of Figure 12.

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

[0218] The UE identifier may be referred to herein as a ‘UE-ID’ which may, for instance, be a SUCI or a 5G-GUTI. The network access point identifier may be referred to herein as a TNAP ID or a TNAP identifier or an AP identifier.

[0219] In some embodiments, the at least one processor coupled with the at least one memory is further configured to cause the network function to provide, to an access and mobility management function (AMF) of the wireless communication network, at least one of: the UE identifier and the one or more first parameters; and the first network access point identifier.

[0220] The AMF may be the AMF 940 of Figure 9, the AMF 1040 of Figure 10 for instance.

[0221] In some embodiments, the at least one processor coupled with the at least one memory is configured to cause the network function to determine the reauthentication type during a UE mobility procedure.

[0222] In some embodiments, the at least one processor coupled with the at least one memory is configured to cause the network function to receive the one or more first parameters from an AMF of the wireless communication network. [0223] In some embodiments, the network function which may be a TNGF, receives the one or more first parameters from the AMF for the UE via N2.

[0224] In some embodiments, the at least one processor coupled with the at least one memory is configured to cause the network function to provide, to the AMF, a current location (i.e., current location information) of the UE (the current location information can be the current AP identifier) following a successful reauthentication of the UE with the wireless communication network via the first network access point.

[0225] In some embodiments, the UE mobility procedure comprises the UE transitioning between the first network access point and a second network access point of the wireless communication network, wherein either: the first network access point supports a 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 does support the FT protocol. The network function may be the TNGF 1136, 1236 of Figures 11-12 for instance. Accordingly, the first and second network access points may be the access points 1132, 1134 or 1232, 1234, for instance.

[0226] In some embodiments, the one or more first parameters indicate if the UE supports at least one of: a fast transition (FT) protocol; a non-3rd generation partnership project (3 GPP) access key refresh; a non-3GPP access re-authentication; a 3 GPP native reauthentication; a mobility security; a modified re-authentication protocol (ERP) or ERP.

[0227] In some embodiments, the one or more second parameters indicate if the first network access point supports at least one of: a FT protocol; a non-3GPP access reauthentication; a 3 GPP native reauthentication; a mobility security; a modified ERP or ERP.

[0228] In some embodiments, the reauthentication type indicates a reauthentication method selected from the list of reauthentication methods consisting of: a FT protocolbased method; a non-3GPP access reauthentication based method; a 3 GPP native reauthentication based method; a mobility security based method; and a modified ERP/ERP based method. [0229] In some embodiments the security information comprises one or more of: an indication of a security key type for deriving a security key; and a security key.

[0230] 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 InterWorking Function (N3IWF).

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

[0232] The disclosure herein further provides a method in a network function, comprising: receiving one or more first parameters indicating a capability of a user equipment (UE) for reauthenticating with a wireless communication network; receiving one or more second parameters indicating a capability of a first network access point for reauthenticating with the wireless communication network; determining, based on the one or more first parameters and the one or more second parameters, a reauthentication type for UE mobility; and determining, based on the reauthentication type, a security information for UE mobility.

[0233] In some embodiments, the method comprises: providing the reauthentication type and/or security information to the first network access point; and/or providing the reauthentication type and/or the security information to the UE.

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

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

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

[0237] In some embodiments, the method comprises determining the reauthentication type during a UE mobility procedure.

[0238] In some embodiments, the method comprises receiving the one or more first parameters from an AMF of the wireless communication network.

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

[0240] In some embodiments, the method comprises providing, to the AMF, a current location (i.e., current location information) of the UE (the current location information can be the current AP identifier) following a successful reauthentication of the UE with the wireless communication network via the first network access point.

[0241] In some embodiments, the UE mobility procedure comprises the UE transitioning between the first network access point and a second network access point of the wireless communication network, wherein either: the first network access point supports a 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 does support the FT protocol.

[0242] In some embodiments, the one or more first parameters indicate if the UE supports at least one of: a fast transition (FT) protocol; a non-3rd generation partnership project (3 GPP) access key refresh; a non-3GPP access re-authentication; a 3 GPP native reauthentication; a mobility security; a modified re-authentication protocol (ERP) or ERP.

[0243] In some embodiments, the one or more second parameters indicate if the first network access point supports at least one of: a FT protocol; a non-3GPP access reauthentication; a 3 GPP native reauthentication; a mobility security; a modified ERP or ERP.

[0244] In some embodiments, the reauthentication type indicates a reauthentication method selected from the list of reauthentication methods consisting of: a FT protocol- based method; a non-3GPP access reauthentication based method; a 3 GPP native reauthentication based method; a mobility security based method; and a modified ERP/ERP based method.

[0245] In some embodiments the security information comprises one or more of: an indication of a security key type for deriving a security key; and a security key.

[0246] 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 InterWorking Function (N3IWF).

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

[0248] There is further provided a UE for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: provide, to a network function of a wireless communication network, one or more first parameters indicating a capability of the UE for reauthenticating with the wireless communication network via a first network access point; and receive, from the network function, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point.

[0249] The network function may be a TNGF or an N3IWF as described in aspects of the disclosure herein i.e., the TNGF 936 of Figure 9, the TNGF 1036 of Figure 10, the TNGF 1136 of Figure 11, the TNGF 1236 of Figure 12.

[0250] The UE may be a UE as described in aspects of the disclosure herein i.e., the UE 920 of Figure 9, the UE 1020 of Figure 10, the UE 1120 of Figure 11, the UE 1220 of Figure 12.

[0251] The first network access point may be a trusted or untrusted access point as described in aspects of the disclosure herein i.e., the first network access point may be a TNAP 932 of Figure 9, a TNAP 1032, 1034 of Figure 10, a TNAP 1132, 1134 of Figure 11, a TNAP 1232, 1234 of Figure 12.

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

[0253] In some embodiments, the at least one processor coupled with the at least one memory is configured to cause the UE to: provide the one or more first parameters to the network function, during a registration procedure for the UE; and/or provide the one or more first parameters to the network function, during a UE mobility procedure for the UE wherein the UE is transitioning between the first network access point and a second network access point of the wireless communication network.

[0254] In some embodiments, the one or more first parameters indicate if the UE supports at least one of: a fast transition (FT) protocol; a non-3rd generation partnership project (3 GPP) access key refresh; a non-3GPP access re-authentication; a 3 GPP native reauthentication; a mobility security; a modified re-authentication protocol (ERP) or ERP.

[0255] In some embodiments, the reauthentication type indicates a reauthentication method selected from the list of reauthentication methods consisting of: a FT protocolbased method; a non 3 GPP access reauthentication based method; a 3 GPP native reauthentication based method; a mobility security based method; and a modified ERP/ERP based method.

[0256] There is further provided a method in a UE, comprising: providing, to a network function of a wireless communication network, one or more first parameters indicating a capability of the UE for reauthenticating with the wireless communication network via a first network access point; and receiving, from the network function, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point. [0257] In some embodiments, the method comprises: deriving the security information based on the reauthentication type; and then reauthenticating or establishing a secure connection with the wireless communication network, using the security information, via the first network access point.

[0258] In some embodiments, the method comprises providing the one or more first parameters to the network function, during a registration procedure for the UE; and/or providing the one or more first parameters to the network function, during a UE mobility procedure for the UE wherein the UE is transitioning between the first network access point and a second network access point of the wireless communication network.

[0259] In some embodiments, the one or more first parameters indicate if the UE supports at least one of: a fast transition (FT) protocol; a non-3rd generation partnership project (3 GPP) access key refresh; a non-3GPP access re-authentication; a 3 GPP native reauthentication; a mobility security; a modified re-authentication protocol (ERP) or ERP.

[0260] In some embodiments, the reauthentication type indicates a reauthentication method selected from the list of reauthentication methods consisting of: a FT protocolbased method; a non 3 GPP access reauthentication based method; a 3 GPP native reauthentication based method; a mobility security based method; and a modified ERP/ERP based method.

[0261] There is further provided a network access point for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network access point to: receive, from a UE, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via the network access point; provide, to a network function of the wireless communication network, the one or more first parameters; provide, to the network function, one or more second parameters indicating a capability of the network access point for reauthenticating with the wireless communication network; and receive, from the network function, a reauthentication type and/or security information for UE mobility for reauthenticating the UE with the wireless communication network via the network access point. [0262] The network function may be a TNGF or an N3IWF as described in aspects of the disclosure herein i.e., the TNGF 936 of Figure 9, the TNGF 1036 of Figure 10, the TNGF 1136 of Figure 11, the TNGF 1236 of Figure 12.

[0263] The UE may be a UE as described in aspects of the disclosure herein i.e., the UE 920 of Figure 9, the UE 1020 of Figure 10, the UE 1120 of Figure 11, the UE 1220 of Figure 12.

[0264] The network access point may be a trusted or untrusted access point as described in aspects of the disclosure herein i.e., the network access point may be a TNAP 932 of Figure 9, a TNAP 1032, 1034 of Figure 10, a TNAP 1132, 1134 of Figure 11, a TNAP 1232, 1234 of Figure 12.

[0265] There is further provided a method in a network access point, comprising: receiving, from a UE, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via the network access point; providing, to a network function of the wireless communication network, the one or more first parameters; providing, to the network function, one or more second parameters indicating a capability of the network access point for reauthenticating with the wireless communication network; and receiving, from the network function, a reauthentication type and/or security information for UE mobility for reauthenticating the UE with the wireless communication network via the network access point.

[0266] There is further provided a processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: output, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via a first network access point; and input, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point.

[0267] There is further provided a method in a processor for wireless communication, comprising: outputting, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via a first network access point; and inputting, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point.

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

[0269] In some embodiments, the function informs the AMF about a UE ID and a current TNAP Identifier.

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

[0271] In some embodiments, the TNGF receives UE re-authentication capabilities from the AMF for a UE via N2.

[0272] In some embodiments, the TNGF selects the re-authentication method to be used during a registration procedure or mobility procedure.

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

[0274] In some embodiments, the TNGF informs the AMF about the UE’s current location following a successful mobility and connection reestablishment with a new TNAP by providing the current TNAP ID and UE ID.

[0275] Figure 13 illustrates an example of a UE 1300 in accordance with aspects of the present disclosure. The UE 1300 may include a processor 1302, a memory 1304, a controller 1306, and a transceiver 1308. The processor 1302, the memory 1304, the controller 1306, or the transceiver 1308, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

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

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

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

[0279] In some implementations, the processor 1302 and the memory 1304 coupled with the processor 1302 may be configured to cause the UE 1300 to perform one or more of the functions described herein (e.g., executing, by the processor 1302, instructions stored in the memory 1304). For example, the processor 1302 may support wireless communication at the UE 1300 in accordance with examples as disclosed herein. The UE 1300 may be the UE 920 of Figure 9, the UE 1020 of Figure 10, the UE 1120 of Figure 11, the UE 1220 of Figure 12. The UE 1300 may be configured to support a means for performing the methods disclosed herein.

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

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

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

[0283] A transmitter chain 1312 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1312 may include at least one modulator for modulating data onto a carrier signal, preparing 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 like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The 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 the wireless medium. The transmitter chain 1312 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0284] Figure 14 illustrates an example of a processor 1400 in accordance with aspects of the present disclosure. The processor 1400 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1400 may include a controller 1402 configured to perform various operations in accordance with examples as described herein. The processor 1400 may optionally include at least one memory 1404, which may be, for example, an L1/L2/L3 cache. Additionally, or alternatively, the processor 1400 may optionally include one or more arithmetic-logic units (ALUs) 1406. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0285] The processor 1400 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the 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), and others).

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

[0287] The controller 1402 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1404 and determine subsequent instruction(s) to be executed to cause the processor 1400 to support various operations in accordance with examples as described herein. The controller 1402 may be configured to track memory address of instructions associated with the memory 1404. The controller 1402 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1402 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1400 to cause the processor 1400 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1402 may be configured to manage flow of data within the processor 1400. The controller 1402 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 1400.

[0288] The memory 1404 may include one or more caches (e.g., memory local to or included in the processor 1400 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 1404 may reside within or on a processor chipset (e.g., local to the processor 1400). In some other implementations, the memory 1404 may reside external to the processor chipset (e.g., remote to the processor 1400).

[0289] The memory 1404 may store computer- readable, computer-executable code including instructions that, when executed by the processor 1400, cause the processor 1400 to perform 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. The controller 1402 and/or the processor 1400 may be configured to execute computer-readable instructions stored in the memory 1404 to cause the processor 1400 to perform various functions. For example, the processor 1400 and/or the controller 1402 may be coupled with or to the memory 1404, the processor 1400, the controller 1402, and the memory 1404 may be configured to perform various functions described herein. In some examples, the processor 1400 may include multiple processors and the memory 1404 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0290] The one or more ALUs 1406 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1406 may reside within or on a processor chipset (e.g., the processor 1400). In some other implementations, the one or more ALUs 1406 may reside external to the processor chipset (e.g., the processor 1400). One or more ALUs 1406 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1406 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1406 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1406 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 1406 to handle conditional operations, comparisons, and bitwise operations.

[0291] The processor 1400 may support wireless communication in accordance with examples as disclosed herein. The processor 1400 may be configured to or operable to support a means for performing the methods described herein.

[0292] Figure 15 illustrates an example of a NE 1500 in accordance with aspects of the present disclosure. The NE 1500 may include a processor 1502, a memory 1504, a controller 1506, and a transceiver 1508. The processor 1502, the memory 1504, the controller 1506, or the transceiver 1508, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces. [0293] The processor 1502, the memory 1504, the controller 1506, or the transceiver 1508, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

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

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

[0296] In some implementations, the processor 1502 and the memory 1504 coupled with the processor 1502 may be configured to cause the NE 1500 to perform one or more of the functions described herein (e.g., executing, by the processor 1502, instructions stored in the memory 1504). For example, the processor 1502 may support wireless communication at the NE 1500 in accordance with examples as disclosed herein. The NE 1500 may be configured to support a means for performing the methods described herein. The NE 1500 may be a network function such as a TNGF or an N3IWF as described in aspects of the disclosure herein i.e., the TNGF 936 of Figure 9, the TNGF 1036 of Figure 10, the TNGF 1136 of Figure l l, the TNGF 1236 of Figure 12. The NE 1500 may be a network access point such as a trusted or untrusted access point as described in aspects of the disclosure herein i.e., the network access point may be a TNAP 932 of Figure 9, a TNAP 1032, 1034 of Figure 10, a TNAP 1132, 1134 of Figure 11, a TNAP 1232, 1234 of Figure 12.

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

[0298] In some implementations, the NE 1500 may include at least one transceiver 1508. In some 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.

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

[0300] A transmitter chain 1512 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1512 may include at least one modulator for modulating data onto a carrier signal, preparing 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 like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The 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 the wireless medium. The transmitter chain 1512 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0301] Figure 16 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a UE as described herein. In some implementations, the UE may execute a set of instructions to control the function elements of the UE to perform the described functions.

[0302] At 1610, the method may include providing, to a network function of a wireless communication network, one or more first parameters indicating a capability of the UE for reauthenticating with the wireless communication network via a first network access point. The operations of 1610 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1610 may be performed by a UE as described with reference to Figure 13.

[0303] At 1620, the method may include receiving, from the network function, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point.

[0304] The operations of 1620 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1620 may be performed by a UE as described with reference to Figure 13.

[0305] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0306] Figure 17 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions. [0307] At 1710, the method may include receiving one or more first parameters indicating a capability of a UE for reauthenticating with a wireless communication network. The operations of 1710 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1710 may be performed by a NE as described with reference to Figure 15.

[0308] At 1720, the method may include receiving one or more second parameters indicating a capability of a first network access point for reauthenticating with the wireless communication network. The operations of 1720 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1720 may be performed by a NE as described with reference to Figure 15.

[0309] At 1730, the method may include determining, based on the one or more first parameters and the one or more second parameters, a reauthentication type for UE mobility. The operations of 1730 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1730 may be performed a NE as described with reference to Figure 15.

[0310] At 1740, the method may include determining, based on the reauthentication type, a security information for UE mobility. The operations of 1740 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1740 may be performed a NE as described with reference to Figure 15.

[0311] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0312] Figure 18 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions.

[0313] At 1810, the method may include receiving, from a UE, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via the network access point. The operations of 1810 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1810 may be performed by a NE as described with reference to Figure 15.

[0314] At 1820, the method may include providing, to a network function of the wireless communication network, the one or more first parameters. The operations of 1820 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1820 may be performed by a NE as described with reference to Figure 15.

[0315] At 1830, the method may include providing, to the network function, one or more second parameters indicating a capability of the network access point for reauthenticating with the wireless communication network. The operations of 1830 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1830 may be performed by a NE as described with reference to Figure 15.

[0316] At 1840, the method may include receiving, from the network function, a reauthentication type and/or security information for UE mobility for reauthenticating the UE with the wireless communication network via the network access point. The operations of 1840 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1840 may be performed by a NE as described with reference to Figure 15.

[0317] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0318] Figure 19 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a processor for a UE as described herein. In some implementations, the processor may execute a set of instructions to control the function elements of the processor to perform the described functions. [0319] At 1910, the method may include outputting, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via a first network access point. The operations of 1910 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1910 may be performed by a processor as described with reference to Figure 14.

[0320] At 1920, the method may include inputting, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point. The operations of 1920 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1920 may be performed by a processor as described with reference to Figure 14.

[0321] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0322] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

[0323] The following abbreviations are relevant in the field addressed by 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; 5GNSWO, 5G Non-Seamless WLAN Offload; 5G SE AV, 5G Serving Environment Authentication Vector; ABBA, Anti-Bidding down Between Architectures; AEAD, Authenticated Encryption with Associated Data; AES, Advanced Encryption Standard; AKA, Authentication and Key Agreement; AMF, Access and Mobility Management Function; ARPF, Authentication credential Repository and Processing Function; AUSF, Authentication Server Function; AUTN, Authentication TokeN; CCA, Client Credentials Assertion; CH, Credentials Holder; CIoT, Cellular Internet of Things; cNRF, consumer's NRF; CP, Control Plane; CTR, Counter (mode); CU, Central Unit; DCS, Default Credentials 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-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 access InterWorking 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, Non-5G-Capable over WLAN; N5GC, Non-5G-Capable; NIA, Integrity Algorithm for 5G; NR, New Radio; NR-DC, NR- NRDual Connectivity; NSSAI, Network Slice Selection Assistance Information; NSSAA, Network Slice Specific Authentication and Authorization; NSWO, Non-Seamless WLAN Offload ; NOUNCE, Number Used Once; NSWOF, Non-Seamless WLAN Offload Function; PDN, Packet Data Network; PEI, Permanent Equipment Identifier; RES, RESponse; RAND, Random; SCG, Secondary Cell Group; SEAF, SEcurity Anchor Function; SgNB, Secondary gNB; SIDF, Subscription Identifier De-concealing Function ; SMC, Security Mode Command; SMF, Session Management Function; SN, Secondary Node ; SN Id, Serving Network Identifier; SUCI, Subscription Concealed 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 Interworking Function; TSC, Time Sensitive Communication; 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 Communication; USIM, Universal Subscriber Identity Module; and XRES, eXpected RESponse.

Claims

CLAIMS What is claimed is:

1. A network function for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network function to: receive one or more first parameters indicating a capability of a user equipment ‘UE’ for reauthenticating with a wireless communication network; receive one or more second parameters indicating a capability of a first network access point for reauthenticating with the wireless communication network; determine, based on the one or more first parameters and the one or more second parameters, a reauthentication type for UE mobility; and determine, based on the reauthentication type, a security information for UE mobility.

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

3. The network function of any one of claims 1-2, wherein the at least one processor coupled with the at least one memory is configured to cause the network function to receive the one or more first parameters and the one or more second parameters during a registration procedure and/or a UE mobility procedure for the UE.

4. The network function of claim 3, wherein the at least one processor coupled with the at least one memory is configured to cause the network function to further receive at least one of: a UE identifier associated with the UE; and a 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 with the at least one memory is further configured to cause the network function to provide, to an access and mobility management function ‘AMF’ of the wireless communication network, at least one of: 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 with the at least one memory is configured to cause the network function to determine the reauthentication type during a UE mobility procedure.

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

8. The network function of claim 7, wherein the at least one processor coupled with the at least one memory is configured to cause the network function to provide, to the AMF, a current location of the UE following a successful reauthentication of the UE with the wireless communication network via the first network access point.

9. The network function of any one of claims 6-8, wherein the UE mobility procedure comprises the UE transitioning between the first network access point and a second network access point of the wireless communication network, wherein either: the first network access point supports a 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 does support the FT protocol.

10. The network function of any preceding claim, wherein the one or more first parameters indicate if the UE supports at least one of: a fast transition ‘FT’ protocol; a non-3^rd generation partnership project ‘3GPP’ access key refresh; a non-3GPP access re-authentication; a 3 GPP native reauthentication; a mobility security; a modified re-authentication protocol ‘ERP’ or ERP.

11. The network function of any preceding claim, wherein the one or more second parameters indicate if the first network access point supports at least one of: a FT protocol; a non-3GPP access reauthentication; a 3 GPP native reauthentication; a mobility security; a modified ERP or ERP.

12. The network function of any preceding claim, wherein the reauthentication type indicates a reauthentication method selected from the list of reauthentication methods consisting of: a FT protocol-based method; a Non 3GPP access reauthentication based method; a 3 GPP native reauthentication based method; a mobility security based method; and a modified ERP/ERP based method.

13. The network function of any preceding claim, wherein the security information comprises one or more of: an indication of a security key type for deriving a security key; and a security key.

14. The network function of any preceding claim, 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 InterWorking Function ‘N3IWF’.

15. A UE for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: provide, to a network function of a wireless communication network, one or more first parameters indicating a capability of the UE for reauthenticating with the wireless communication network via a first network access point; and receive, from the network function, a reauthentication type for deriving a security information for UE mobility for reauthenticating the UE with the wireless communication network via the first network access point.

16. The UE of claim 15, wherein the at least one processor coupled with the at least one memory is further configured to cause the UE to: derive the security information based on the reauthentication type; and then reauthenticate or establish a secure connection with the wireless communication network, using the security information, via the first network access point.

17. The UE of any one of claims 15-16, wherein the at least one processor coupled with the at least one memory is configured to cause the UE to: provide the one or more first parameters to the network function, during a registration procedure for the UE; and/or provide the one or more first parameters to the network function, during a UE mobility procedure for the UE wherein the UE is transitioning between the first network access point and a second network access point of the wireless communication network.

18. The UE of any one of claims 15-17, wherein the one or more first parameters indicate if the UE supports at least one of: a fast transition ‘FT’ protocol; a non-3^rd generation partnership project ‘3GPP’ access key refresh; a non-3GPP access re-authentication; a 3 GPP native reauthentication; a mobility security; a modified re-authentication protocol ‘ERP’ or ERP.

19. The UE of any one of claims 15-18, wherein the reauthentication type indicates a reauthentication method selected from the list of reauthentication methods consisting of: a FT protocol-based method; a non 3 GPP access reauthentication based method; a 3 GPP native reauthentication based method; a mobility security based method; and a modified ERP/ERP based method.

20. A network access point for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network access point to: receive, from a UE, one or more first parameters indicating a capability of the UE for reauthenticating with a wireless communication network via the network access point; provide, to a network function of the wireless communication network, the one or more first parameters; provide, to the network function, one or more second parameters indicating a capability of the network access point for reauthenticating with the wireless communication network; and receive, from the network function, a reauthentication type and/or security information for UE mobility for reauthenticating the UE with the wireless communication network via the network access point.