Authentication using a user identifier

Abstract

Various aspects of the present disclosure relate to transmitting (1502) an authentication message comprising a user type and a user authentication capability and performing (1504) a primary authentication associated with the UE. Aspects of the present disclosure may relate to transmitting (1506) a user identifier (ID) and performing (1508) a user authentication based on the user type and the user ID. Aspects of the present disclosure may relate to accessing (1510) a service associated with the user ID based on the user authentication.

Description

AUTHENTICATION USING A USER IDENTIFIERTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to authentication using a user identifier (ID), for example, a network-controlled user ID.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, which may be know n as a netw ork equipment (NE), supporting 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 (RATs) 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., 5G- Advanced (5G- A). sixth generation (6G), etc.).SUMMARY

[0003] 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.

[0004] A UE for wireless communication is described. The UE may be configured to, capable of, or operable to transmit an authentication message comprising a user type and a user authentication capability; perform a primary authentication associated with the UE; transmit a user ID; perform a user authentication based on the user type and the user ID; and access a service associated with the user ID based on the user authentication.

[0005] A processor for wireless communication is described. The processor may be configured to, capable of, or operable to transmit an authentication message comprising a user type and a user authentication capability; perform a primary authentication associated with the UE; transmit a user ID; perform a user authentication based on the user type and the user ID; and access a service associated with the user ID based on the user authentication.

[0006] A method performed or performable by a UE for wireless communication is described. The method may include transmitting an authentication message comprising a user type and a user authentication capability; performing a primary authentication associated with the UE; transmitting a user ID; performing a user authentication based on the user type and the user ID; and accessing a service associated with the user ID based on the user authentication.

[0007] An apparatus for performing a network function is described. The apparatus may be configured to, capable of, or operable to receive an authentication request message comprising a user type, a user authentication capability, and a user ID associated with a UE; identify a user identity profile based on the authentication request message; determine a requirement for user authentication based at least in part on the user type and the user authentication capability; and transmit, to a first authentication entity, an authentication response message for triggering a primary authentication of the UE, where the authentication response message comprises an indication of the requirement for user authentication.

[0008] A processor for implementing a network function is described. The processor may be configured to, capable of, or operable to receive an authentication request message comprising a user type, a user authentication capability, and a user ID associated with a UE; identify a user identity profile based on the authentication request message; determine a requirement for user authentication based at least in part on the user type and the user authentication capability; and transmit, to a first authentication entity, an authentication response message for triggering a primary authentication of the UE, where the authentication response message comprises an indication of the requirement for user authentication.

[0009] A method performed or performable by a network function for wireless communication is described. The method may include receiving an authentication request message comprising a user type, a user authentication capability, and a user ID associated with a UE; identifying a user identity profile based on the authentication request message; determining a requirement for user authentication based at least in part on the user type and the user authentication capability; and transmitting, to a first authentication entity, an authentication response message for triggering a primary authentication of the UE, where the authentication response message comprises an indication of the requirement for user authentication.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0011] Figure 2 illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.

[0012] Figure 3 illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.

[0013] Figure 4A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.

[0014] Figure 4B is a continuation of the flow diagram of Figure 4A.

[0015] Figure 5A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.

[0016] Figure 5B is a continuation of the flow diagram of Figure 5 A.

[0017] Figure 6 illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.

[0018] Figure 7 illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.

[0019] Figure 8A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.

[0020] Figure 8B is a continuation of the flow diagram of Figure 8A.

[0021] Figure 9A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.

[0022] Figure 9B is a continuation of the flow diagram of Figure 9A.

[0023] Figure 9C is a continuation of the flow diagram of Figures 9A and 9B.

[0024] Figure 9D is a continuation of the flow diagram of Figures 9A, 9B and 9C.

[0025] Figure 10A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.

[0026] Figure 1 OB is a continuation of the flow diagram of Figure 10A.

[0027] Figure 11 illustrates an example of a protocol stack in accordance with aspects of the present disclosure.

[0028] Figure 12 illustrates an example of a UE in accordance with aspects of the present disclosure.

[0029] Figure 13 illustrates an example of a processor in accordance with aspects of the present disclosure.

[0030] Figure 14 illustrates an example of an NE in accordance with aspects of the present disclosure.

[0031] Figure 15 illustrates a flowchart of a method performed by a UE, in accordance with aspects of the present disclosure.

[0032] Figure 16 illustrates a flowchart of a method performed by an NE, in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0033] Various aspects of the present disclosure relate to authentication in a wireless communications system using a user ID, such as a network-controlled user ID. In certain implementations, the methods may be performed using computer-executable code embedded on a computer-readable medium. In certain implementations, an apparatus or system may include a computer-readable medium containing computer-readable code which, when executed by a processor, causes the apparatus or system to perform at least a portion of the below described solutions.

[0034] In future wireless communication networks, the authentication and authorization of a user ID corresponding to a human user scenario may be required. In current third generation partnership project (3GPP) 5G systems, a UE is authenticated and authorized for services based on the subscription with the mobile network operator (MNO) (or wireless carrier). However. 5G systems do not allow for human user specific authentication. Human user-specific authentication is important because it ensures that only the legitimate, authorized individual can access and control the services or resources tied to their subscription or account. However, current 5G systems are unable to provide efficient and effective mechanisms for human user specific authentication.

[0035] Moreover, for the cases of one or more non-3GPP devices behind one gateway UE or residential gateway, currently the authentication of the gateway UE (or UE acting as a residential gateway) is a device-specific authentication similarly based on the subscription information managed at the MNO, i.e., at the unified data management and / or unified data repository (UDM / UDR). However, the existing 5G systems do not allow user-specific authentication in the case of non-3GPP devices. Importantly, if the non-3GPP devices behind one gateway UE (or residential gateway) are not authenticated and authorized through means supported by the network, the attacker can access the network as a non-3GPP device via one gateway UE or residential gateway without any authorization and restriction.

[0036] Various aspects of the present disclosure describe solutions for how user human user specific authentication, and related authorization can be performed in a wireless communication network (e.g., a modification of the current 5G system) to provide necessary7operator services and third party services to the user, while also allowing the user to use only an allowed number of user identifiers to perform a user authentication, thereby preventing any misuse of other user’s identifier linked to the subscriptions of different users, for different use. Aspects of the present disclosure describe how the user type is verified during user authentication to check if the user is only using the user (e.g., human user) related identifier linked to the subscription to perform the user authentication.

[0037] For the case of non-3GPP devices, aspects of the present disclosure describe specific user authentication and how a UE subscription can be linked to multiple user identifiers, i.e., one unique user identifier per device is managed, for all non-3GPP devices connected to a UE or residential gateway whose subscription is managed in the network, so the present disclosure describes how the user identifier and authentication is handled in such cases. 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 a Long- Term Evolution (LTE) network or an LTE-Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a new radio (NR) network, such as a 5G network, a 5G-A network, or a 5G ultrawideband (5G-UWB) network.

[0039] 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.

[0040] 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 RAN, aNodeB, 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.

[0041] 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-terrestnal 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.

[0042] 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 remoteunit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology7. 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 intemet-of-things (loT) device, an intemet-of-everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0043] 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.

[0044] 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, N3, 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).

[0045] 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 mobility7(e.g., a mobility7management entity7(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 mobility7, 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.

[0046] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N3, 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 a PDN connection, 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).

[0047] 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 5G 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.

[0048] 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., q=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., jU=O) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., / z=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g.. q=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., =3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g.. q=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0049] 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, forexample, 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.

[0050] 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, z=l, z=2, r=3, ^=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.

[0051] Each slot may include a number (e.g., quantity) of symbols (e.g., orthogonal frequency domain multiplexing (OFDM) symbols). In some implementations, the number (e g., quantity) of slots for a subframe may depend on a numerology7. 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.

[0052] 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.

[0053] FR1 may be associated with one or multiple numeral ogies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerologywhich includes 15 kHz subcarrier spacing; a second numerology (e.g., ^=1), which includes 30 kHz subcarrier spacing; and a third numerology7(e.g., g=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., / z=3), which includes 120 kHz subcarrier spacing.

[0054] Wireless communication in unlicensed spectrum (also referred to as “shared spectrum”) in contrast to licensed spectrum offer some obvious cost advantages allowing communication to obviate overlaying operator’s licensed spectrum and rather use license free spectrum according to local regulation in specific geographies. From the 3GPP technology perspective, the unlicensed operation can be on the Uu interface (referred to as NR-U) or also on sidelink interface (e.g., SL-U).

[0055] Identifying distinguished user identities of the user (provided by some external party or by the operator) in the operator network enables an operator to provide an enhanced user experience and optimized performance as well as to offer services to devices that are not part of a 3GPP network. The user to be identified could be an individual human user, using a UE with a certain subscription, or an application running on or connecting via a UE, or a device (“thing”) behind a gateway UE. Network settings can be adapted and services offered to users according to their needs, independent of the subscription that is used to establish the connection. By acting as an identity provider, the operator can take additional information from the network into account to provide a higher level of security for the authentication of a user.

[0056] Regarding the requirements of user IDs and user authentication, the user ID, as used herein, is independent of existing identifiers relating to subscription or device (e.g., international mobile subscriber identity (IMSI), mobile station international subscriber directory number (MSISDN), internet protocol (IP) multimedia services (IMS) private identity (IMPI), IMS public user identify (IMPU), subscription permanent identifier (SUPI), generic public subscription identifier (GPSI), international mobile equipment identity (IMEI)) and of other UE IDs. In other words, the user ID is an identity associated with the (e.g., human) user and is independent of theparticular device being used or the service being accessed by the user. Accordingly, the user may be authenticated independently from the access device (e.g., UE) or the service being accessed by the user.

[0057] In some examples, the user ID may be provided by some entity within the operator’s network or by a third party. In some examples, the 3GPP system (e.g., implementing or implemented by the wireless communication system 100) supports interworking with a third party7network entity7for authentication of the user ID. Accordingly, the 3GPP system may support authentication of a user ID regardless of the user's access, the user's UE and its home public land mobile network (PLMN), or the provider of the user ID.

[0058] Regarding access to services, the 3GPP system may allow a UE access to a respective network slice based on successful user ID authentication. Additionally, the 3GPP system may deny a UE access to the respective network slice based on unsuccessful user ID authentication.

[0059] Regarding operator requirements, the operator may be able to enable or disable the use of a user ID in the operator’s network. Regarding privacy requirements, the 3GPP system may protect the privacy of the user by transferring to a service only user ID information that is necessary7to provide the service and for which the user has consented to when registering for the service.

[0060] In various implementations, the authentication and authorization of a human user ID may focus on the authentication and authorization of a human user of a subscription and the restriction on number of simultaneously active user IDs of a subscription. Regarding security' threats, without support for an authentication and authorization mechanism for the human user, an attacker may impersonate the human user of a subscription and gain unauthorized access to services normally available for that subscription legitimate user. Regarding the potential security requirements, the 3GPP system provides means to support authentication and authorization of the human user based on a user ID linked to a 3GPP subscription.

[0061] In various implementations, the user ID is a piece of information used to identify one specific user identify, which is privacy sensitive, and associated with a user identify profile. As such, the exposure of user identify profile information may be a key issue. Either during the communication using user ID or during the exposure of user identify profile information, without proper protection against linkabilify and trackabilify attack, the privacy sensitive information may be leaked to undesired party so that the privacy of the user is violated. In some implementations, the 3GPP system may provide mechanisms for mitigating privacy attacks (e.g.,trackabi 1 i ty , lin kabi 1 i ty) against user ID during the communication between the UE and the network, including the procedures for user authentication and service access. In some implementations, the 3GPP system provides mechanisms for mitigating privacy attacks (e.g., disclosure) during the exposure of user identity profile information by the network to entities outside operator domain.

[0062] In various implementations, the user ID may be involved with the authentication and authorization of one or more non-3GPP devices operating behind one gateway UE or a 5G residential gateway (5G-RG). To address security issues related to the authentication and authorization of one or more non-3GPP devices behind one gateway UE or 5G-RG, it may be necessary to identify the non-3GPP devices connecting behind the gateway UE or 5G-RG.

[0063] If the non-3GPP devices behind one gateway UE or 5G-RG are not authenticated and authorized through means supported by the network, the attacker can access the network as a non-3GPP device via one gateway UE or 5G-RG without any authorization and restriction. Accordingly, the 3GPP system may provide means to support authentication and authorization of a non-3GPP device behind UE or 5G-RG based on a non-3GPP device identifier, such as the user ID.

[0064] Figure 2 depicts an exemplary' procedure 200 to support identifying the human user of a UE’s 3 GPP subscription, in accordance with aspects of the present disclosure. The procedure 200 provides a high-level mechanism for PDU session establishment for specific user ID to support identifying the human user of a UE’s 3GPP subscription, such as when the human user accesses services via the 5G system (5GS) using a user ID. The procedure 200 may be performed by a UE 202 (e.g., an implementation of the UE 104), an AMF 204 (e.g., an implementation of a network function (NF) in the CN 106), a session management function (SMF) 206 (e.g., an implementation of a NF in the CN 106), a UDM / UDR 208 (e.g., an implementation of a NF in the CN 106), and a policy control function (PCF) 210 (e.g., an implementation of a NF in the CN 106).

[0065] At step 0, the UE 202 registers with the network with its subscription and establishes a NAS security context with the AMF 204 (see block 212). The user ID associated with the subscription has been authenticated and authorized.

[0066] At step 1, if the user ID is supported on this UE 202, when the user is active, during PDU session establishment procedure, then the UE 202 may indicate the current user ID in N1 session management (SM) container (see messaging 214).

[0067] At step 2, the AMF 204 selects a SMF 206 (see block 216).

[0068] At step 3a, if the AMF 204 does not have an association with a SMF 206 for the PDU session ID associated with the user ID sent by UE 202 (e.g., when the request ty pe parameter is “initial request”), then the AMF 204 invokes the Nsmf PDUSession CreateSMContextRequest service with the PDU session ID, the user ID, and other relevant parameters to create the SM context (see messaging 218).

[0069] Alternatively, if the AMF 204 already has an association with an SMF 206 for the PDU session ID associated with the user ID provided by the UE 202 (e.g., when the request type parameter indicates “existing PDU Session”), then the AMF 204 may update the SM context by invoking the Nsmf PDUSession UpdateSMContextRequest service with the PDU session ID, the user ID and other relevant parameters (see messaging 218).

[0070] The SMF 206 is responsible for checking whether the UE 202 requests are compliant with the user identity profile.

[0071] At step 3b, if the user identity' profile for the corresponding subscription is not available, then the SMF 206 retrieves the user identity profile and UE SM subscription data from the UDM / UDR 208 (see messaging 220). In some examples, the SMF 206 may subscribe with the UDM / UDR 208 to be notified when the user identity profile is modified.

[0072] At step 3c, the SMF 206 transmits an Nsmf PDUSession CreateSMContextResponse message (e.g., including an SM context ID) to the AMF 204 (see messaging 222). Alternatively, the SMF 206 may transmit aNsmf PDUSession UpdateSMContextResponse message to the AMF 204. In some examples, the SMF 206 also provides the user identity profile to the AMF 204 in step 3 c.

[0073] At step 4, the SMF 206 may perform a user ID policy association establishment procedure to establish a user ID policy association with the PCF 210 and get the default policy and charging control (PCC) rules for the PDU sessions associated with the user ID (see exchange 224). Alternatively, the SMF 206 may perform a user ID policy association modification procedure with the PCF 210 to modify an existing user ID policy association and get the PCC rules associated with the user ID.

[0074] For example, if the request ty pe parameter is “initial request,” then the SMF 206 may initiate the user ID policy association establishment procedure. As another example, if the request type parameter indicates “existing PDU Session,” then the SMF 206 may provideinformation on one or more policy control request trigger conditions that have been met by an SMF -initiated user ID policy association modification procedure. If a service category7identifier has been associated with the user ID, then the operator-defined policies for this service category can be used for this user ID in this step.

[0075] At step 5, the SMF 206 continues with the PDU session establishment request procedure initiated in step 1 (see block 226). The procedure 200 ends.

[0076] However, the procedure 200 does not consider the user type of the user ID provided by the UE 202 to authenticate the user ID. As the number of user IDs that a human user can use may be different from the non-3GPP device limitations and restrictions. For example, a human user can use only one user ID related to the subscription related to the user authentication. But in case of non-3GPP access where multiple devices can access via a UE 202 or residential gateway (RG), there can be multiple user IDs managed. In other words, i.e., to serve each device with a dedicated or unique user ID, there may be multiple user IDs that are associated with (i.e., linked to) such UE subscriptions. Therefore, without sufficient verification of the user type involved in the user authentication, the necessary restrictions or limitations over the user ID usage per user cannot be controlled with the procedure 200.

[0077] Figure 3 depicts an exemplary7procedure 300 to support registration for a UE and a human user, in accordance w ith aspects of the present disclosure. The procedure 300 may be performed by a UE 302 (e.g., an implementation of the UE 104 and / or UE 202), an AMF 304 (e.g., an implementation of the AMF 204), an authentication server function (AUSF) 306 (e.g., an implementation of a NF in the CN 106), and a unified data management function (UDM) 308 (e.g., an implementation of a NF in the CN 106 and / or the UDM / UDR 208).

[0078] At step 1, a user profile is provided to the UDM 308 and is linked to the subscription information of the UE 302 (see block 310). In some examples, the user profile is provided by the operator or by the service provider. In certain examples, the operator or service provider may interact with the UDM 308 via an NEF (not depicted in Figure 3).

[0079] At step 2, a user (e.g., associated with “user identifier-x”) initiates registration procedure (see messaging 312). In the registration request message transmitted by the UE 302 includes the user identity for registration (e.g.. “user identifier-x”).

[0080] At optional step 3, one or more authentication and security procedures may be performed between the UE 302 and the 5GS, including one or more of the AMF 304, AUSF 306or UDM 308 (see block 314). In some examples, the authentication and security procedures may be performed according to 3GPP technical specification (TS) 23.502.

[0081] At step 4, if the UE subscription information was not received (e.g., from a source AMF), the AMF 304 requests the UE subscription information retrieval from the UDM 308 by invoking the Nudm SDM Get service (see messaging 316). In some examples, the AMF 304 includes the identity of the user to be registered (e.g., ’‘user identifier-x”) in the Nudm SDM Get service message sent to the UDM 308.

[0082] At step 5, the UDM 308 returns the subscription information of the UE 302, e.g., in a Nudm SDM Response service message (see messaging 318). In certain examples, the UE subscription information is exchanged according to 3GPP TS 23.502. In some examples, if in step 4 the AMF 304 indicated a user identity, then the UDM 308 also provides the user profile to the AMF 304 in the Nudm SDM Response service message.

[0083] At step 6, the AMF 304 analyses the retrieved user profile and stores it (i.e., locally within the AMF 304) in a UE context associated with the UE 302 (see block 320).

[0084] At optional step 7, if a user-specific authentication is required (i.e., based on the user profile), then the AMF 304 triggers the user-specific authentication procedure for the user (see block 322).

[0085] At step 8, the AMF 304 sends a registration accept message to the UE 302 and includes in it the user registration status parameter in which the AMF 304 indicates which user successfully registered (e.g., user identifier-x) or which user was rejected, if any (see messaging 324). If there is a rejected user, then the AMF 304 provides in the user registration status a reject cause and potentially a back-off timer.

[0086] However, the procedure 300 also does not consider the user ty pe of the user ID provided by the UE 302 to authenticate the user ID. As described above, for the case of non- 3 GPP access where multiple devices can access via a UE 202 or residential gateway (RG). there can be multiple user IDs that are managed by a UE or gateway. Therefore, without sufficient verification of the user type involved in the user authentication, the necessary restrictions or limitations over the user profile usage per user cannot be controlled with the procedure 300.

[0087] In various embodiments, the aspects of the present disclosure describe how to authenticate a user (e.g., a human user, independent of the access device or service being accessed), and how related authorization can be performed in the wireless communication systemto provide necessary operator services and third-party services to the user. In such embodiments, the aspects of the present disclosure additionally let the user to use only an allowed number of user ID to perform a user authentication and to prevent any misuse of other user's identifier linked to the subscription for different use. The aspects of the present disclosure describe how the user type is verified during user authentication to check if the user is only using the user (e.g., human user) related identifier linked to the subscription to perform the user authentication. Meanwhile for the case of non-3GPP devices specific user authentication, the aspects of the present disclosure describe how a UE subscription can be linked to multiple user IDs, i.e., one unique user ID per device is managed, for all non-3GPP devices connected to a UE / residential gateway whose subscription is managed in the network.

[0088] According to aspects of a first solution, a network (e.g., a 3GPP system which may implement, or be implemented by, the wireless communication system 100) initiates and performs user authentication and authorization for the user based on the user type, user ID and user authentication requirement information / policy managed in the network.

[0089] Figures 4A-4B depict an exemplary procedure 400 to perform user authentication and authorization following primary authentication, in accordance with aspects of the present disclosure. The procedure 400 may be performed by a UE 402 (e.g., an implementation of the UE 104, the UE 202. and / or the UE 302), a security anchor function (SEAF) 404 (e.g., an implementation of a NF in the CN 106) providing an authentication functionality in a serving network, an AUSF 406 (e.g., an implementation of the AUSF 306), and a UDM 408 (e.g., an implementation of a NF in the CN 106), and a target application function (AF) or application server (AS), denoted “AF / AS" 410 (e.g., an implementation of a NF in the CN 106).

[0090] In some examples, the SEAF 404 may reside in an AMF, such as the AMF 204 and / or AMF 304, such that the SEAF 404 provides the authentication functionality via the AMF. In some implementations of the procedure 400, the UDM 408 may comprise an authentication credential repository' function (ARPF) for generating and storing authentication credentials. In some examples, the AUSF 406 and UDM 408 are located in a home netw ork of the UE 402, which may be different from the serving network where the SEAF 404 is located. The steps shown in Figures 4A-4B are as follows:

[0091] Beginning in Figure 4A, at step 1 the UE 402 sends a NAS message or an N1 transport message to the SEAF 404 (see messaging 412). In some examples, the NAS message or N1 transport message may be a registration request message, a mobility registration updatemessage, a periodic registration update message, any initial NAS message, a PDU session establishment message, a modification request message, or the like. The NAS message or N1 transport message includes a UE identifier (e.g.. a subscription concealed identifier (SUCI) and / or a 5G global unique temporary identifier (5G-GUTI)), a user authentication capabilities information element (IE), a user type parameter, and (optionally) a user ID. Here, the UE 402 includes a SUCI or 5G-GUTI in a registration request message, and the user authentication capabilities IE may be an individual IE or may be part of the security capabilities IE. Also, the user type parameter may indicate any of a human user, a non-3GPP device, an entity, or an application.

[0092] The procedure 400 supports two different options for the UE 402 to provide the user ID to the network. In the first option (Option- 1) the UE 402 provides the user ID at step 1 in the NAS message or N1 transport message. Alternatively, in the second option (Option-2) the UE 402 does not include the user ID in the NAS message or N1 transport message of step 1, and instead provides the user ID when prompted by the network after primary authentication of the UE 402.

[0093] At step 2, the SEAF 404 may initiate an authentication with the UE 402 during any procedure establishing a signaling connection with the UE 402, according to the SEAF's policy (see messaging 414). Accordingly, the SEAF 404 may invoke the Nausf UEAuthentication service by sending a Nausf UEAuthentication Authenticate request message to the AUSF 406 whenever the SEAF 404 determines to initiate an authentication. In various implementations, the Nausf UEAuthentication Authenticate request message contains the serving network (SN) name and either the SUCI or a SUPI. For example, the Nausf UEAuthentication Authenticate request message may contain the SUPI for the in case where the SEAF 404 has a valid 5G-GUTI for the UE 402 and re-authenticates the UE 402. Otherwise, the SEAF 404 includes the SUCI in the Nausf_UEAuthentication_Authenticate request message.

[0094] The Nausf UEAuthentication Authenticate request message additionally contains the user authentication capabilities IE. the user type parameter, and the user ID (if provided) as received in step 1. The Nausf UEAuthentication Authenti cate request may furthermore contain a disaster roaming service indication. Additionally, the local policy for the selection of the authentication method does not need to be on a per-UE basis, but can be the same for all UEs.

[0095] At step 3, upon receiving the Nausf UEAuthentication Authenticate request message, the AUSF 406 may check that the requesting SEAF 404 in the serving network (e.g., identifiedby the 3gpp-Sbi-Originating-Network-Id header specified in 3GPP TS 29.500) is entitled to use the SN name in the Nausf UEAuthentication Authenticate request. For disaster roaming, the AUSF 406 may check a local configuration to confirm the SEAF 404.

[0096] If the AUSF 406 determines that the SEAF 404 is allowed, the AUSF 406 may invoke the Nudm UEAuthentication service by sending a Nudm UEAuthentication Get request message to the UDM 408 (see messaging 416). Here, the Nudm_UEAuthentication_Get request message sent from the AUSF 406 to the UDM 408 includes the following information: the SUCI or SUPI; the SN name; a disaster roaming service indication (if received from SEAF); the user authentication capabilities IE; the user type parameter; and the user ID (if provided in step 1).

[0097] At step 4a, upon reception of the Nudm UEAuthentication Get request, if a SUCI is received, then the UDM 408 invokes a subscription identifier de-concealing function (SIDF) to fetch the SUPI. The SIDF de-conceals the SUCI to gain the SUPI before the UDM 408 can process the request (see block 418). At step 4b, based on SUPI, the UDM 408 (or ARPF) selects the authentication method for the primary authentication of the UE 402 (i.e., device-specific authentication).

[0098] At step 4c, based on the received user authentication capability IE and / or the user type parameter, the UDM 408 determines to fetch the user identity' profile for determining whether additional user authentication is needed. The operator manages (e.g., in the UDM 408) user authentication requirement information / policy along with the SUPI in the UE subscription data. The user authentication requirement information can say if user authentication is ‘needed’ or ‘not needed’ for the UE / user related to the subscription.

[0099] During step 4c, if the user authentication is set as ‘needed’, then based on the received user authentication capability' IE and / or the user ty pe parameter, the UDM 408 determines to fetch the user identity profile and determines to perform additional user authentication now or later (e g., when a service is requested by the user / UE).

[0100] The user identity profile is a collection of information associated with the user IDs of a (human) user. The user identity' profile may include user authentication and authorization data / attributes for each of the user IDs (e.g., #1, #2, #3, #4, . . . , #n) belonging to a specific user type. Exemplary entries of the user identity profile steps are as follows:

[0101] #1- User Type (indicated any of human user or non-3GPP devices or device or fixed network residential gateway (FN-RG) or 5G-RG or authenticable non-3GPP device (AUN3) orentity or application), User ID -1 (i.e., first user ID), allowed service IDs or names or types (authorized AF / AS IDs to consume the user ID, authentication results and credentials) list along with validity of user ID usage per service, security credentials for user authentication, user service access / authorization token (signed by operator function, client ID: set as user ID. scope: set as one or more third party services which can be provided for the user, exp: expiration time set for the access token based on the validity' of the user ID or service usage of the user ID).

[0102] #2- User Type (indicated any of human user or non-3GPP devices or FN-RG or 5G-RG or AUN3 or device or entity or application), User ID-2 (i.e., second user ID), allowed service IDs or names or types (authorized AF / AS IDs to consume the user ID, authentication results and credentials) list along with validity' of user ID usage per service, security credentials for user authentication, user service access / authorization token (signed by operator function, client ID: set as user ID, scope: set as one or more third party services which can be provided for the user, exp: expiration time set for the access token based on the validity of the user ID or service usage of the user ID).

[0103] #3- User Type (indicated any of human user or non-3GPP devices or device or FN-RG or 5G-RG or AUN3 or entity or application), User ID-3 (i.e., third user ID), allowed service IDs or names or types (authorized AF / AS IDs to consume the user ID, authentication results and credentials) list along with validity’ of user ID usage per service, security credentials for user authentication, user service access / authorization token (signed by operator function, client ID: set as user ID, scope: set as one or more third party services which can be provided for the user, exp: expiration time set for the access token based on the validity of the user ID or service usage of the user ID).

[0104] #4- User Type (indicated any of human user or non-3GPP devices or device or FN-RG or 5G-RG or AUN3 or entity or application), User ID-4 (i.e., fourth user ID), allowed service IDs or names or types (authorized AF / AS IDs to consume the user ID, authentication results and credentials) list along with validity' of user ID usage per service, security credentials for user authentication, user service access / authorization token (signed by operator function, client ID: set as user ID. scope: set as one or more third party services which can be provided for the user, exp: expiration time set for the access token based on the validity of the user ID or service usage of the user ID).

[0105] #n- User Type (indicated any of human user or non-3GPP devices or device or FN-RG or 5G-RG or AUN3 or entity or application), User ID-n (i.e., n-th user ID), allowed serviceIDs or names or types (authorized AF / AS IDs to consume the user ID, authentication results and credentials) list along with validity of user ID usage per service, security credentials for user authentication, user service access / authorization token (signed by operator function, client ID: set as user ID. scope: set as one or more third party services which can be provided for the user, exp: expiration time set for the access token based on the validity of the user ID or service usage of the user ID).

[0106] In some implementations, the user type parameter can have a value to indicate if the user is a human or device or non-3GPP device / application or entity. In some implementations, the security credentials for user authentication can include for, e.g.. symmetric secret key or asymmetric keys (public-private key) / certificate or biometric attributes, etc.

[0107] A respective user ID may be in any of the following formats:

[0108] User ID format 1 : privacy protected ID / pseudonymousid / anonymousid@"5gc.userid. mnc<MNC>.mcc<MCC>.3gppnetwork.org", where <MNC> denotes the mobile network code (MNC) associated with the user ID, and where <MCC> denotes the mobile country’ code (MCC) associated with the user ID.

[0109] User ID format 2: useridcode. privacy protected ID / pseudonymousid / anonymousid gc. mnc<MNC>. mcc<MC C >.3 gppnetwork. org" .

[0110] User ID format 3: SUPI type set as ‘userid’, where privacy protected ID / pseudonymousid / anonymousid is used as the username (i.e., in network access identifier (NAI) format) and the realm (i.e., in NAI format) indicating @"5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org". As used herein, the NAI format uses the syntax: usemame@realm, e.g., to uniquely identify a user.[OHl] User ID format 4: useridcode. privacy protected digital ID (e.g., set by the operator or human user or third party' service provider) @"5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org".

[0112] At step 5, the UDM 408 sends a Nudm UEAuthentication Get response message to the AUSF 406 (see messaging 420). which includes an authentication vector (AV) specific to the selected authentication method specific, the SUPI, an authentication and key management for applications (AKMA) indication, and a routing indicator (RID). According to implementations of Option-2, the Nudm UEAuthentication Get response message may additionally include an indication that user-specific authentication is required, i.e., if the UDM / UDR determines that additional user authentication needs to be performed for the user of the UE 402.

[0113] At step 6, using the AV, authentication messages specific to the selected authentication method are exchanged between the UE 402 and the AUSF 406 via the SEAF 404 (and / or associated AMF), and mutual authentication is performed, referred to as primary authentication (see message exchange 422).

[0114] Continuing on Figure 4B, at step 7, following a successful primary authentication, the AUSF 406 sends to the SEAF 404 aNausf_UEAuthentication_Authenticate response message (see messaging 424). In various embodiments, the Nausf UEAuthentication Authenticate response message may include a result indication (i.e., as ‘success’), and an anchor key (i.e., KSEAF). According to Option-2, the Nausf UEAuthentication Authenticate response message may further include the indication that user-specific authentication is required.

[0115] The SEAF 404 (or associated AMF) stores the indication that user-specific authentication is required along with the SUPI in the UE context. The NAS security and AS security establishment occur as in the existing system. Alternatively, following a successful primary authentication, the SEAF 404 (or AMF) may fetch the user authentication requirements as part of the subscription data in any Nudm service operation message.

[0116] For example, the SEAF 404 (or AMF) may request the UE subscription information retrieval from the UDM 408, if not already received (e.g., from a source AMF). In the Nudm SDM Get message to the UDM 408, the SEAF 404 (or AMF) includes the user type parameter and the user ID of the user to be registered. The UDM 408 returns the UE subscription information and, if the SEAF 404 (or AMF) indicated the user ID and user type parameter, the UDM 408 also provides the indication that user-specific authentication is required and / or user authentication and authorization data / attributes to the SEAF 404 (or AMF).

[0117] At step 8, according to Option-2, the SEAF 404 (or AMF) sends a user authentication request message in any NAS transport / NAS MM message, i.e., when the UE 402 did not provide the user ID in step 1 (see messaging 426). For example, step 8 may be performed when the UE 408 later requests a PDU session establishment and SEAF 404 (or AMF or SMF) determines to initiate user authentication for the UE, i.e., based on the indication that user-specific authentication is required and / or user authentication and authorization data / attributes fetched from the UDM 408.

[0118] At step 9, the UE 402 sends a user authentication response message in an NAS transport or NAS MM message along with the user ID (see messaging 428). In certain implementations, the SEAF 404 (or AMF) verifies the UE-provided user ID received in step 9.e.g., using a user ID received as part of the user authentication and authorization data / attributes.If both user IDs match, then the SEAF 404 (or AMF) considers user authentication as successful.

[0119] At step 10, the SEAF 404 (or AMF) sends to the AUSF 406 a user authentication request that includes the user ID (see messaging 430).

[0120] At step 11, the AUSF 406 sends to the UDM 408 the user authentication request that includes the user ID (see messaging 432).

[0121] At step 12, based on the received user ID, the UDM 408 initiates user authentication with the AF / AS 410 that is authorized (e.g., eligible) to authenticate the (human) user for the user-requested services (see messaging 434). Alternatively, the UDM 408 may initiate the user authentication with an authentication, authorization, and accounting server (AAA-S) that is authorized (e.g., eligible) to authenticate the (human) user for the user-requested services. In some implementations, the UDM 408 transmits a user authentication request to the AF / AS 410 (or AAA-S) which includes the user ID and related authentication and authorization data / attributes (e.g., credentials) to enable the AF / AS 410 (or AAA-S) to perform the necessary user authentication and authorization.

[0122] At step 13, the AF / AS 410 (or AAA-S) and the UE 402 perform user authentication over the application layer using the security credentials available as part of the authentication and authorization data / attributes fetched from the UDM 408 and is available at the UE side (in the client) at the application layer data (see message exchange 436). Based on user ID, the UE 402 and the AF / AS 410 (or AAA-S) fetch the security credentials to perform user authentication for the user ID and perform authorization for the services in step 14-16.

[0123] At step 14, the UE 402 (e.g., in the application layer) may send a user service access request message to the AF / AS 410 with the user ID and an access token (see messaging 438).

[0124] At step 15, the AF / AS 410 verifies the user authorization, i.e., the service access request is verified using the access token and authorization information which is available as part of the authentication and authorization data / attributes fetched by the UDM 408 (see block 440). In some implementations, the AF / AS 410 verifies the access token (e.g., an open authorization (OAuth) access token) using the public key of the MNO and verifies the claims in the token, i.e., the allowed services, vs requested services, validity of the access token and the issuer of the access token.

[0125] At step 15, the AF / AS 410 sends to the UE 402 a user service access response (see messaging 442), i.e., with the result set as “success’' if the authorization is successful; else, with the result set as “failure.'’ Afterwards, the UE 402 is able to access the requested service based on the successful user authentication.

[0126] According to aspects of a second solution, a network (e.g., a 3GPP system which may implement, or be implemented by, the wireless communication system 100) initiates and performs user authentication and authorization for the user based on the user ty pe, user ID and user authentication requirement information / policy managed in the network.

[0127] Figures 5A-5B depict an exemplary procedure 500 to perform user authentication and authorization following primary authentication, in accordance with aspects of the present disclosure. The procedure 500 may be performed by a UE 502 (e.g., an implementation of the UE 104, the UE 202, the UE 302, and / or the UE 402), a SEAF 504 (e.g., an implementation of the SEAF 404) providing an authentication functionality in a serving network, an AUSF 506 (e.g.. an implementation of the AUSF 306 and / or the AUSF 406), a UDM 508 (e.g.. an implementation of the UDM 408), and an AF / AS 510 (e g., an implementation of the AF / AS 410).

[0128] In some examples, the SEAF 504 may reside in an AMF, such as the AMF 204 and / or AMF 304, such that the SEAF 504 provides the authentication functionality7via the AMF. In some implementations of the procedure 500, the UDM 508 may comprise an ARPF for generating and storing authentication credentials. In some examples, the AUSF 506 and UDM 508 are located in a home network of the UE 502, which may be different from the serving network where the SEAF 504 is located. The steps shown in Figures 5A-5B are as follows:

[0129] Beginning in Figure 5A, at step 1, the UE 502 sends a NAS message or an N1 transport message to the SEAF 504 (see messaging 512). Examples of candidate NAS message and N1 transport messages are described above with reference to Figure 4A. The NAS message or N1 transport message includes a UE identifier (e.g., a SUCI and / or a 5G-GUTI), a user authentication capabilities IE, a user type parameter, and a user ID. Here, the UE 502 includes a SUCI or 5G-GUTI in a registration request message, and the user authentication capabilities IE may be an individual IE or may be part of the security capabilities IE. Also, the user type parameter may indicate any of a human user, a non-3GPP device, an entity, or an application.

[0130] At step 2, the SEAF 504 may initiate an authentication with the UE 502 during any procedure establishing a signaling connection with the UE 502, according to the SEAF's policy (see messaging 514). Accordingly, the SEAF 504 may invoke the Nausf UEAuthenticationservice by sending a Nausf_UEAuthentication_Authenticate request message to the AUSF 506 whenever the SEAF 504 determines to initiate an authentication. In various implementations, the Nausf UEAuthentication Authenticate request message contains the SN name and either the SUCI or a SUPI. as descnbed above.

[0131] The Nausf UEAuthentication Authenticate request message additionally contains the user authentication capabilities IE, the user type parameter, and the user ID as received in step 1. The Nausf UEAuthentication Authenticate request may furthermore contain a disaster roaming service indication. Additionally, the local policy for the selection of the authentication method does not need to be on a per-UE basis but can be the same for all UEs.

[0132] At step 3, upon receiving the Nausf UEAuthentication Authenticate request message, the AUSF 506 may check that the requesting SEAF 504 in the serving network is entitled to use the SN name in the Nausf UEAuthentication Authenticate request. For disaster roaming, the AUSF 506 may check a local configuration to confirm the SEAF 504.

[0133] If the AUSF 506 determines that the SEAF 504 is allowed, the AUSF 506 may invoke the Nudm UEAuthentication service by sending a Nudm UEAuthentication Get request message to the UDM 508 (see messaging 516). Here, the Nudm_UEAuthentication_Get request message sent from the AUSF 506 to the UDM 508 includes the following information: the SUCI or SUPI; the SN name; a disaster roaming service indication (if received from SEAF); the user authentication capabilities IE; the user type parameter; and the user ID.

[0134] At step 4a, upon reception of the Nudm UEAuthentication Get request, if a SUCI is received, then the UDM 508 invokes a subscription identifier de-concealing function (SIDF) to de-conceal the SUCI and gain the SUPI (see block 518). At step 4b, based on SUPI, the UDM 508 (or ARPF) selects the authentication method for the primary authentication of the UE 502 (i.e., device-specific authentication).

[0135] At step 4c, based on the received user authentication capability IE and / or the user type parameter, the UDM 508 determines to fetch the user identity profile for determining whether additional user authentication is needed. The operator manages (e.g., in the UDM 508) user authentication requirement information / policy along with the SUPI in the UE subscription data. The user authentication requirement information can say if user authentication is ‘needed’ or ‘not needed’ for the UE / user related to the subscription.

[0136] During step 4c, if the user authentication is set as ‘needed’, then based on the received user authentication capability' IE and / or the user type parameter, the UDM 508 determines to fetch the user identity profde and determines to perform additional user authentication now or later (e.g., when a service is requested by the user / UE).

[0137] As described above, the user identity profile is a collection of information associated with the user IDs of a (human) user and may include user authentication and authorization credentials / attributes data for each of the user IDs (e.g., #1, #2, #3, #4, . . . , #n) belonging to a specific user type.

[0138] At step 5. the UDM 508 sends a Nudm UEAuthentication Get response message to the AUSF 506 (see messaging 520), which includes an AV specific to the selected authentication method specific, the SUPI, an indication that user-specific authentication is required (i.e., if the UDM / UDR determines that additional user authentication needs to be performed for the user of the UE 502), one or more AF IDs, the user ID, authentication and authorization credentials / attributes data, an AKMA indication, and a RID.

[0139] Continuing in Figure 5B. at step 6. using the AV, authentication messages specific to the selected authentication method are exchanged between the UE 502 and the AUSF 506 via the SEAF 504 (and / or associated AMF), and mutual authentication is performed, referred to as primary' authentication (see message exchange 522).

[0140] At step 7. following a successful primary’ authentication, the AUSF 506 sends to the AF / AS 510 a user authentication request message which includes the user ID, authentication and authorization credentials / attributes data (see messaging 524). The user authentication request message may be included in a Nausf service operation message, a Naf service operation message, a Nnf service operation message, or the like.

[0141] At step 8. the AF / AS 510 (or AAA-S) and the UE 502 perform user authentication over the application layer using the security credentials available as part of the authentication and authorization data / attributes fetched from the AUSF 506 and is available at the UE side (in the client) at the application layer data (see message exchange 526). Based on user ID, the UE 502 and the AF / AS 510 (or AAA-S) fetch the security credentials to perform user authentication for the user ID and perform authorization for the services in step 9-11.

[0142] At step 9. the UE 502 (e.g.. in the application layer) may send a user service access request message to the AF / AS 510 yvith the user ID and an access token (see messaging 528).

[0143] At step 10, the AF / AS 510 verifies the user authorization, i.e., the service access request is verified using the access token and authorization information which is available as part of the authentication and authorization data / attributes fetched by the UDM 508 (see block 530). In some implementations, the AF / AS 510 verifies the access token (e.g., an open authorization (OAuth) access token) using the public key of the MNO and verifies the claims in the token, i.e., the allowed services, vs requested services, validity of the access token and the issuer of the access token.

[0144] At step 11, the AF / AS 510 sends to the UE 502 a user service access response (see messaging 532), i.e.. with the result set as “success” if the authorization is successful; else, with the result set as “failure.” Afterwards, the UE 502 is able to access the requested service based on the successful user authentication.

[0145] According to aspects of a third solution, the CN 106 may include a AKMA anchor function (AAnF) that stores one or more AKMA keys for a UE. e.g., in a UE-AKMA context, and may generate key material to be used for secure messaging between the UE and the AF. Moreover, the third solution provides mechanisms whereby user authentication and authorization data can be provided to an AAnF (as shown in Figure 6), and the user authentication and authorization data can be provided to the AF for user authentication and authorization (as shown in Figure 7).

[0146] Figure 6 depicts an exemplary procedure 600 to provide user authentication and authorization data along with AKMA context after primary authentication, in accordance with aspects of the present disclosure. The procedure 600 may be performed by a UE 602 (e.g., an implementation of the UE 104, the UE 202, the UE 302, the UE 402 and / or the UE 502), an AMF 604 (e.g., an implementation of the AMF 204 and / or AMF 304), an AUSF 606 (e.g., an implementation of the AUSF 306, the AUSF 406, and / or the AUSF 506), a UDM 608 (e.g., an implementation of the UDM 408 and / or the UDM 508), and an AAnF 610 (e.g., an implementation of a NF in the CN 106). The steps shown in Figure 6 are as follows:

[0147] At step 1, during a primary authentication procedure 612, the AUSF 606 interacts with the UDM 608 in order to fetch authentication information such as subscription credentials (e.g., authentication and key agreement (AKA) AVs) and the authentication method (see messaging 614). In some embodiments, the AUSF 606 invoked a Nudm UEAuthentication Get service operation by sending a Nudm UEAuthentication Get request message, e.g., including the SUPI or SUCI of the UE 602.

[0148] In some implementations, the Nudm UEAuthentication Get request message includes the user authentication capability IE, the user type parameter, and the user ID, e.g., as described above with reference to step 3 of Figure 4A and / or step 3 of Figure 5A. The user authentication capability IE. the user type parameter, and the user ID may be acquired as described above with reference to steps 1-2 of Figure 4A and / or steps 1-2 of Figure 5A. Upon receiving the Nudm UEAuthentication Get request message, the UDM 608 fetches a user identity profile and determines whether user authentication is required, e.g., as described above with reference to step 4c of Figure 4A and / or step 4c of Figure 5

[0149] Returning to Figure 6, at step 2, in the response, the UDM 608 generates and transmits a Nudm UEAuthentication Get response message (e.g., as described above with reference to step 5 of Figure 4A and / or step 5 of Figure 5A) and may also indicate to the AUSF 606 whether the AKMA anchor key needs to be generated for the UE 602 by sending an AKMA indication. If the AKMA indication is included, the UDM 608 also includes the RID of the UE 602 in the Nudm UEAuthentication Get response message (see messaging 616).

[0150] If the UDM 608 determines that user authentication is required, then the Nudm UEAuthentication Get response message includes the indication that user-specific authentication is required and may additionally include the user ID, the user identity attributes (i.e., authentication and authorization credentials / attributes data), and applicable AF ID(s) specific to the services to be provided for the UE 602.

[0151] At step 3a, if the AUSF 606 receives the AKMA indication from the UDM 608, then the AUSF 606 stores the AUSF key (KAUSF) and generate the AKMA anchor key (KA MA) from the KAUSF after the primary authentication procedure 612 is successfully completed via the AMF 604 (see block 618). Additionally, at step 3b, the AUSF 606 generates the AKMA key ID (A- KID) for the generated KAKMA (see block 620). Concurrently, the UE 602 generates the KAKMA and the A-KID from the KAUSF before initiating communication with an AKMA AF.

[0152] The A-KID identifies the KAKMA key of the UE 602. The AUSF 606 uses the RID received from the UDM 608 to derive the A-KID. In some implementations, the A-KID is in NAI format, i.e., having the form “usemame@realm.” For the A-TID, the username part includes the RID and the AKMA temporary UE ID (A-TID), and the realm part shall include a home network identifier. The A-TID may be derived from KAUSF.

[0153] The chance of A-TID collision is not zero but practically low as the A-TID derivation is based on a key derivation function (KDF). The KAK A shall be derived from KAUSF. SinceKAKMA and the A-TID in the A-KID are both derived from the KAUSF concurrently generated in the UE 602 and the home network resulting from the primary' authentication procedure 612, the KAKMA and A-KID can only be refreshed by a new successful primary authentication.

[0154] At step 4. after AKMA key material is generated, the AUSF 606 selects the AAnF 610 and send the generated A-KID and KAK A to the AAnF 610 together with the SUPI of the UE 602, e.g., using the Naanf_AKMA_KeyRegi strati on service operation (see messaging 622). In some implementations, the Naanf AKMA KeyRegi strati on request message may further include the indication that user-specific authentication is required, the user ID, and the user identity attributes (i.e.. authentication and authorization credentials / attributes data), and applicable AF ID(s), as received in step 2.

[0155] The AAnF 610 stores the latest information sent by the AUSF 606. When reauthentication runs, the AUSF 606 generates a new7A-KID and a new7KAKMA, and sends the newly generated A-KID and KAK A to the AAnF 610. After receiving the new generated A-KID and KAKMA, the AAnF 610 deletes the old A-KID and KAKMA and stores the new generated A- KID and KAKMA.

[0156] At step 5, the AAnF 610 sends the response to the AUSF 606, e.g., using aNaanf AKMA AnchorKey Register response service message (see messaging 624). The AAnF 610 stores the received indication that user-specific authentication is required, the user ID, the user identity attributes (i.e., authentication and authorization credentials / attributes data) along with SUPI, and applicable AF ID(s).

[0157] However, the AUSF 606 need not store any AKMA key material after delivery to the AAnF 610. Accordingly, in some implementations, the AUSF 606 deletes the AKMA key material after transmitting the Naanf AKMA AnchorKey Register request message or receiving the Naanf AKMA AnchorKey Register response message.

[0158] Further the AAnF 610 can provide the user identity attributes, i.e., authentication and authorization credentials / attributes data to the applicable AF(s) to enable user authentication as shown in Figure 7 below.

[0159] Figure 7 depicts an exemplary procedure 700 to provide user authentication and authorization data along with an AKMA application key (KAF) to the AF. in accordance with aspects of the present disclosure. The procedure 700 may be performed by a UE 702 (e.g.. an implementation of the UE 104, the UE 202, the UE 302, the UE 402, the UE 502, and / or the UE602), a AUSF 704 (e.g., an implementation of the AUSF 306, the AUSF 406, the AUSF 506, and / or AUSF 606), an AAnF 706 (e.g., an implementation of the AAnF 610), an AKMA AF 708 (e.g., an implementation of the AF / AS 410 and / or AF / AS 510), and a UDM 710 (e g., an implementation of the UDM 408, the UDM 508, and / or the UDM 608).

[0160] In some examples, the AKMA AF 708 may reside in a different network than the AAnF 706 and UDM 710, and so the AAnF 706 communicates with the AKMA AF 708 via a network exposure function (NEF) 712. In some implementations of the procedure 700, the UDM 710 may be substituted with an operator ID management function or similar service.

[0161] Before communication between the UE 702 and the AKMA AF 708 can start, the UE 702 and the AKMA AF 708 need to know whether to use AKMA. This knowledge may be implicit to the specific application on the UE 702 and the AKMA AF 708 or indicated by the AKMA AF 708 to the UE 702. The steps shown in Figure 7 are as follows:

[0162] As a prerequisite, before initiating communication w ith an AKMA AF 708, the UE 702 performs primary authentication and establishes (i.e., generates) the KAKMA and the A-KID from the KAUSF (see message exchange 714). The AUSF 704 may generate the KAKMA and the A- KID for the AAnF 706, as described above. The primary authentication and establishment of the KAKMA may be as described above with reference to Figure 6.

[0163] At step 1 of Figure 7, the UE 702 initiates communication with the AKMA AF 708 by transmitting an application session establishment request message that includes the derived A- KID and the user ID (see messaging 716). Here, the user ID may have the NAI format described above. In some implementations, the UE 702 may derive KAF before sending the application session establishment request message. In other implementations, the UE 702 may derive KAF after sending the application session establishment request message.

[0164] At step 2. if the AKMA AF 708 does not have an active context associated with the A-KID, then the AKMA AF 708 selects the AAnF 706. and sends a request to AAnF 706 invoking the Naanf_AKMA_ApplicationKey_Get service operation (see messaging 718). The Naanf AKMA ApplicationKey Get request message include the A-KID and user ID. The AKMA AF 708 also includes its identity (denoted “AF ID ’) in the request, as well as an indication that user authentication and authorization data is required (or an indication that userspecific authentication is required), e.g., to request the KAF for the UE 702.

[0165] In some implementations, the AF ID may consist of the fully qualified domain name (FQDN) of the AKMA AF 708 and the Ua. In security7protocol identifier, yvhich parameter identifies the security protocol that the AKMA AF 708 will use with the UE 702.

[0166] If the AKMA AF 708 yvants to receive a notification for AKMA service disabling, then the AKMA AF 708 shall include an AKMA service disable uniform resource identifier (URI) in the Naanf AKMA ApplicationKey Get request message. Based on the AKMA service disable URI, the AAnF 706 shall create an implicit subscription for the AKMA AF 708 for the AAnF 706 to later notify the AKMA AF 708 about AKMA service disable. Implicit subscription has an expiration time set by operator policy.

[0167] Upon receiving the Naanf_AKMA_ApplicationKey_Get request message, the AAnF 706 may check whether the AAnF 706 can provide the service to the AKMA AF 708 based on the configured local policy or based on the authorization information available in the signaling (i.e., OAuth 2.0 token). If the check is successful, the AAnF 706 performs the following procedures. Otherwise, the AAnF 706 rejects the service request.

[0168] First, the AAnF 706 verifies whether the subscriber is authorized to use AKMA based on the presence of the UE-specific K K identified by the A-KID. If KAKMA is present in AAnF, the AAnF 706 retrieves the authentication credentials and an authorization / access token from the UDM 710 (described in steps 3-4). Otherwise, if the KAKMA is not present in the AAnF 706, then the AAnF 706 transmits a response to the AKMA AF 708 (described in step 5) with an error response.

[0169] Upon receiving the request from the AKMA AF 708, if the AAnF 706 determines this specific AF needs the GPSI of the UE 702, and if user authentication and authorization data / attributes are available for the UE 702 according to its local policy, the AAnF 706 sends a Nudm SDM Get request to the UDM 710 to fetch the GPSI of the UE and user authentication and authorization data / attributes. The UDM responds with the GPSI of the UE. the AAnF 706 shall store the received GPSI as part of UE’s AKMA context. However, if the specific AF does not need GPSI, the AAnF 706 shall continue yvith step 3.

[0170] At step 3, after receiving the request from the AKMA AF 708, and upon confirming the presence of the UE-specific KAKMA identified by the A-KID, the AAnF 706 sends aNudm EventExposure Subscribe request to the UDM 710 (see messaging 720) with the SUPI or GPSI (i.e., to request the RoamingStatusReport), the user ID, and the indication that userauthentication and authorization data is required (i.e., to fetch user authentication and authorization data / attributes from the UDM 710).

[0171] At step 4a, based on the user ID, and the authentication result available, the UDM 710 retrieves the security credentials for user authentication and authorization for the user ID (i.e., the user authentication and authorization data / attributes) (see block 722). At step 4b, the UDM 710 sends a Nudm EventExposure Subscribe response to the AAnF 706 with the information of roaming status and with the user authentication and authorization data / attributes (i.e., including security credentials) (see messaging 724). Later on, if the roaming status changes, the UDM 710 may also send a notification to the AAnF 706 about the updated roaming information.

[0172] The user authentication and authorization data / attributes may be stored (i.e., at the UDM 710) in a user identity profile. As described above, the user authentication and authorization data / attributes may include one or more of: user type (indicated any of human user or non-3GPP devices or device or FN-RG or 5G-RG or AUN3 or entity or application), user ID- x, allowed service IDs or names or types (authorized AF / AS IDs to consume the user ID, authentication results and credentials) list along with validity of user ID usage per service, security credentials for user authentication, user service access / authorization token (signed by operator function, client ID: set as user ID, scope: set as one or more third party services which can be provided for the user, exp: expiration time set for the access token based on the validity of the user ID or service usage of the user ID).

[0173] Once the AAnF 706 receives the roaming status from the UDM 710, the AAnF 706 checks the local policy and determines whether to provide service to the UE 702. If yes, the AAnF 706 derives the K F from KAKMA, e.g., if it does not already have KAF. Further the AAnF 706 stores the KAF expiration time as part of UE’s AKMA context. When UE is dual registered, the UE is treated as roaming if at least one of the serving PLMNs indicates the UE is roaming.

[0174] At step 5, if the AAnF 706 determines to provide AKMA service to the UE 702, the AAnF 706 sends Naanf AKMA ApplicationKey Get response message to the AKMA AF 708 (see messaging 726). The Naanf AKMA ApplicationKey Get response message includes the SUPI / GPSI of the UE 702. the user ID, the user authentication and authorization attributes data received from the UDM 710, the derived KAF and the KAF expiration time. Whether to send SUPI or GPSI is determined by the AAnF 706, e.g., based on the local policy. If the AAnF 706 finds that roaming is not allowed, it shall respond the AKMA AF 708 containing a failure indicationthat roaming is not allowed. If the KAKMA is not present in the AAnF 706, then the AAnF 706 transmits an error response to the AKMA AF 708.

[0175] At step 6, the AKMA AF 708 sends the application session establishment response message to the UE 702 (see messaging 728). If the information in step 5 indicates failure of AKMA key request, the AKMA AF 708 shall reject the application session establishment by including a failure cause. Afterwards, the UE 702 may trigger a new application session establishment request with the latest A-KID to the AKMA AF 708. The AKMA AF 708 perform user authentication and authorization verification based on the user authentication and authorization attributes data fetched from AAnF 706 or use the user authentication result received. In some implementations, the AKMA AF 708 may use the access token to do authorization for the user ID for the service access.

[0176] According to aspects of a fourth solution, user authentication can be performed for one or more non-3GPP devices that connect to a 3GPP network (e.g., a 5GC) via a non-3GPP access network (N3AN). In some implementations, a UE behind a 5G-RG can use either an untrusted non-3GP access (e g., described below with reference to Figures 8A-8B) or a trusted non-3GPP access (e.g., described below7with reference to Figures 9A-9D).

[0177] Figures 8A-8B depicts an exemplary procedure 800 to provide user authentication of non-3GPP devices via an untrusted access network, in accordance with aspects of the present disclosure. The procedure 800 may be performed by a UE 802 (e.g., an implementation of the UE 104, the UE 202, the UE 302, the UE 402, the UE 502, the UE 602, and / or the UE 702), an untrusted non-3GPP access network (UNAN) 804 (e.g., an implementation of the NE 102), an non-3GPP interworking function (N3IWF) 806 (e g., an implementation of the NE 102 or a node in the CN 106), an AMF 808 (e.g.. an implementation of the AMF 204. the AMF 304, and / or the AMF 604), and an AUSF 810 (e.g., an implementation of the AUSF 306, the AUSF 406, the AUSF 506, the AUSF 606, and / or the AUSF 704).

[0178] Beginning in Figure 8A, at step lathe UE 802 connects to the UNAN 804 and acquires an IP address (see block 812). At step lb, when the UE 802 decides to attach to the 5GC network, the UE 802 selects an N3IWF in a 5G PLMN and obtains (e.g., discovers) the IP address of the selected N3IWF 806 (see block 814).

[0179] At step 2, the UE 802 proceeds with the establishment of an internet protocol security (IPsec) security association (SA) with the selected N3IWF by initiating an internet key exchange (IKE) initial exchange (e.g., according to request-for-comment (RFC) 7296) (see messaging816). After step 2, all subsequent IKE messages are encrypted and integrity protected by using the IKE SA established in this step.

[0180] At step 3, the UE 802 initiates an IKE authentication (IKE AUTH) exchange by sending an IKE AUTH request message (see messaging 818). The authentication (AUTH) pay load is not included in the IKE AUTH request message, which indicates that the IKE AUTH exchange is to use extensible authentication protocol (EAP) signaling (in this case EAP-5G signaling). As per the RFC 7296, in the IDi, the UE 802 sets the ID type as ID KEY-ID in this message and sets its value equal to any random number. The UE 802 does not use its GUTI / SUCI / SUPI as the ID in this step. If the UE 802 is provisioned with the N3IWF root certificate, it shall include the CERTREQ payload within the IKE AUTH request message to request the certificate of the N3IWF 806.

[0181] At step 4, the N3IWF 806 responds with an IKE AUTH response message which includes the N3IWF identity, the AUTH payload to protect the previous message it sent to the UE 802 (in the IKE SA INIT exchange) and an EAP-Request / 5G-Start packet (see messaging 820). The EAP-Request / 5G-Start packet informs the UE 802 to initiate an EAP-5G session, i.e., to start sending NAS messages encapsulated within EAP-5G packets. If the UE 802 has sent a CERTREQ payload in step 3, the N3IWF 806 also includes the CERT payload including the certificate of the N3IWF 806.

[0182] At step 5. the UE 802 validates the certificate of the N3IWF 806 and confirms that the N3IWF identity matches the N3IWF 806 selected by the UE 802. An absence of the certificate from the N3IWF 806 if the UE 802 had requested the certificate or unsuccessful identity confirmation shall result in a connection failure. The UE 802 sends an IKE AUTH request to the N3IWF 806 (see messaging 822). The IKE AUTH request includes an EAP-Response / 5G-NAS packet that contains a registration request message containing the UE security capabilities IE, the user ID, the user authentication capability IE, the user type parameter, and the SUCI. In some implementations, the user ID may have the NAI format described above. If the UE 802 is already registered with the 5GC over 3GPP access and there is an available security context, then the UE 802 uses the security context to integrity protect the registration request message and sends the 5G-GUTI instead of the SUCI.

[0183] The N3IWF 806 refrains from sending an EAP -Identity request. The N3IWF 806 does not send an EAP -Identity request because the UE 802 includes its identity in the IKE AUTHrequest in step 5. In some implementations, the UE 802 may ignore an EAP identity request, if received, or may respond with the SUCI it sent in the registration request.

[0184] If the UE 802 has registered to the same AMF 808 through a 3GPP access, and if this is the first time that the UE 802 connects to the 5GC through a non-3GPP access, then the value of corresponding uplink (UL) NAS COUNT used for integrity protection is 0; else the UE 802 can use the existing non-3GPP specific UL NAS COUNT for integrity protection.

[0185] For the case of non-3GPP devices, where the device connects to non-3GPP access via the UEs or residential gateway (e.g., FN-RG or 5G-RG), the user ID can be ‘device identifier in NAI format’ and ‘User Type’ is set as non-3GPP devices or device.

[0186] Alternatively, for the case AUN3 type of non-3GPP devices, where the device connects to non-3GPP access via the UEs or residential gateway (e.g., FN-RG or 5G-RG), the user ID can be ‘ AUN3 device identifier in NAI format’ and ‘User Type’ is set as non-3GPP devices or device or AUN3 and 5G-RG and W-AGF is used in the UNAN 804 to connect to the AMF 808 (or corresponding SEAF).

[0187] Alternatively, for the case where the UE 802 is the 5G-RG, it can be connected to 5GC via W-5GAN, NG RAN or via both accesses, thus the user ID can be '5G-RG specific user ID in NAI format’ and ‘User Type’ is set as device or 5G-RG.

[0188] Alternatively for the case where the UE 802 is the FN-RG, it connects to 5GC via W- 5GAN, which has the W-AGF function that provides connectivity to the 5GC viaN2 and N3 reference points. Since the FN-RG is a non-wireless entity defined by BBF or CableLabs, it does not support N1 connectivity. The W-AGF provides N1 connectivity’ on behalf of the FN-RG, thus the user ID can be ‘FN-RG specific user ID in NAI format’ and ‘User Type’ is set as device or FN-RG.

[0189] At step 6a, the N3IWF 806 selects an AMF 808 (see block 824). At step 6b, the N3IWF 806 forwards the registration request message containing the user ID, the user authentication capability IE, and the user type parameter received from the UE 802 to the selected AMF 808 (see messaging 826).

[0190] At step 7, if the AMF 808 receives a 5G-GUTI and the registration request message is integrity protected, the AMF 808 may use the security context to verify the integrity protection. If the UE 802 has registered to the same AMF 808 through 3GPP access, and if this is the first time that the AMF 808 receives the NAS signaling of the UE 802 via the non-3GPP access, thenthe value of corresponding UL NAS COUNT used for integrity verification is 0. Else, the AMF 808 may use the existing non-3GPP specific UL NAS COUNT for integrity' verification.

[0191] If integrity' is verified successfully, this means that the UE 802 is authenticated by the AMF 808. If integrity is verified successfully and no newer security context has been activated over the 3GPP access, then the primary authentication and step 8 to step 11 may be skipped.

[0192] If integrity is verified successfully and a newer security context has been activated over the 3GPP access, then authentication may be skipped but the AMF 808 may activate the newer context with a NAS security mode command (SMC) procedure as described in step 8 and onwards. Otherwise, the AMF 808 shall authenticate the UE 802.

[0193] At step 7. if the AMF 808 decides to authenticate the UE 802. the AMF 808 may authenticate the UE 802 using an existing authentication methods (see block 828), and step 3-7 enhancements of the first and second solutions are applicable here. In this case, the AMF 808 may send a key request to the AUSF 810, and the AUSF 810 may initiate an authentication procedure. Between the AMF 808 and the UE 802, the authentication packets are encapsulated within NAS authentication messages and the NAS authentication messages are carried in N2 signaling between the AMF 808 and the N3IWF 806 and then are encapsulated within EAP- 5G / 5G-NAS packets between the N3IWF 806 and the UE 802.

[0194] In the final authentication message from the home network, the AUSF 810 sends the SEAF anchor key (KSEAF) derived from AUSF to the SEAF (not shown in Figure 8A). The SEAF shall derive the AMF key (KA F) from KSEAF and send it to the AMF 808, which is used by the AMF 808 to derive NAS security keys. If EAP-AKA' is used for authentication, then the AUSF 810 shall include the EAP-Success indication. The UE 802 also derives the anchor key KSEAF and from that key it derives the KAMF followed by the NAS security keys. The NAS COUNTs associated with NAS connection identifier "0x02" are set at the UE 802 and the AMF 808.

[0195] At step 8. the AMF 808 sends a NAS SMC to the UE 802 in order to activate the NAS security associated with NAS connection identifier "0x02". This message is first sent to the N3IWF 806, i.e., within an N2 message (see messaging 830). If EAP-AKA' is used for authentication, the AMF 808 shall encapsulate the EAP-Success indication received from AUSF 810 within the NAS SMC message.

[0196] At step 9. the N3IWF 806 forwards the NAS SMC message to the UE 802 within an EAP-Request / 5G-NAS packet (see messaging 832).

[0197] Continuing in Figure 8B, at step 10, the UE 802 completes the authentication (if initiated in step 7) and creates a NAS security context or activates another one based on the received next generation key set identifier (ngKSI) in the NAS SMC message. The UE 802 shall respond to the NAS SMC it received from the AMF 808 based on the selected algorithms and parameters. The UE 802 shall encapsulate the NAS SMC complete message in the EAP-5G response message (see messaging 834).

[0198] At step 11, the N3IWF 808 shall forward the NAS packet containing the NAS SMC complete message to the AMF 808 over the N2 interface (see messaging 836).

[0199] At step 12, upon reception of the NAS SMC complete message from the UE 802. or upon success of integrity protection verification, the AMF 808 initiates the next generation application protocol (NGAP) procedure to set up the AN context. The AMF 808 shall compute the N3IWF key (KNSIWF), e.g., using the UL NAS COUNT associated with NAS connection identifier "0x02", for the establishment of the IPsec SA between the UE 802 and the N3IWF 806. The AMF 808 includes the KNSIWF in the NGAP initial context setup request sent to the N3IWF 806 (see messaging 838).

[0200] At step 13, the N3IWF 806 sends an IKE AUTH message with an EAP-Success / EAP-5G indication to the UE 802 upon reception of the NGAP initial context setup request message containing the KNSIWF (see messaging 840). This completes the EAP-5G session and no further EAP-5G packets are exchanged. If the N3IWF 806 does not receive the KNSI F from the AMF 808, then the N3IWF 806 responds to the UE 802 with an EAP-Failure indication.

[0201] At step 14, the IPsec SA is established between the UE 802 and the N3IWF 806 (see messaging 842) by using the KNSIWF that was created in the UE 802 using the uplink NAS COUNT associated with NAS connection identifier "0x02" and was received by the N3IWF 806 from the AMF 808 in step 12.

[0202] At step 15, upon successful establishment of the IPsec SA between the UE 802 and the N3IWF 806, the N3IWF 806 sends an NGAP initial context setup response message to the AMF 808 (see messaging 844).

[0203] At step 15a, if the AMF 808 received an indication that user-specific authentication is required and received user authentication and authorization attributes from the AUSF 810 (e g., in turn from the UDM / UDR) during the authentication (step 7). then the AMF 808 determines to perform user authentication. Additionally, the AMF 808 may determine whether the N3IWF 806is appropriate for the network slice selected (see block 846). If the network slice is compatible with the N3IWF 806, then the AMF 808 proceeds with step 16 and step 17 (corresponding to Case A). Otherwise, if the selected N3IWF 806 is not compatible, then the AMF 808 proceeds with step 18 to step 20 (corresponding to Case B). and step 16 to 17 are skipped.

[0204] At step 16, for Case A, when the NGAP initial context setup response message for the UE 802 is received by the AMF 808, the AMF 808 sends an NAS registration accept message along with the indication that user-specific authentication is required / requested for the UE 802 over the N2 interface towards the N3IWF 806 (see messaging 848).

[0205] At step 17, upon receiving the NAS registration accept message from the AMF 808, the N3IWF 806 forwards the NAS registration accept message to the UE 802 over the established IPsec SA (see messaging 850). All further NAS messages betw een the UE 802 and the N3IWF 806 are sent over the established IPsec SA.

[0206] At step 18, for Case B, the AMF 808 may trigger a UE policy update procedure and update the UE policy (see message exchange 852).

[0207] At step 19a, the AMF 808 sends a registration reject message to the N3IWF 806 (see messaging 854). The registration reject message is ciphered and integrity protected. At step 19b, the N3IWF 806 forwards the registration reject message to the UE 802 (see messaging 856).

[0208] At step 20, the UE 802 deciphers and verifies the integrity of the registration reject message (see block 858). If the verification is successful, then the UE 802 selects a new N3IWF and sends a registration request message to the AMF 808 via the newly selected N3IWF.

[0209] Upon receiving the indication that user-specific authentication is required / requested from the AMF 808 in the NAS registration accept message, the UE 802 sends the user ID and the authorization information (e.g., service access token) in the NAS transport as part of the user authentication request / response. The user authentication request / response is then forwarded by the N3IWF 806 to the AMF 808 and the AMF 808 verifies the received user ID and the authorization information with the available authentication and authorization attribute data; if the received information matches the available data, then the user authentication and authorization is considered to be successful.

[0210] Figures 9A-9B depict an exemplary procedure 900 to provide user authentication of non-3GPP devices via an untrusted access network, in accordance with aspects of the present disclosure. The procedure 900 may be performed by a UE 902 (e.g., an implementation of the UE104, the UE 202, the UE 302, the UE 402, the UE 502, the UE 602, the UE 702, and / or the UE 802), a trusted non-3GPP access network (TNAN) 904 (e.g., an implementation of the NE 102), an AMF 910 (e.g., an implementation of the AMF 204, the AMF 304, the AMF 604, and / or the AMF 808). and an AUSF 912 (e.g., an implementation of the AUSF 306. the AUSF 406. the AUSF 506, the AUSF 606, the AUSF 704 and / or the AUSF 810).

[0211] The TNAN 904 comprises a trusted non-3GPP access point (TNAP) 906 (e.g., an implementation of the NE 102) and a trusted non-3GPP gateway function (TNGF) 908 (e.g., an implementation of the NE 102). In some implementations, the TNAP 906 communicates with one or more user devices (including the UE 902) via a layer-2 (L2) interface. Examples of the L2 interface include, but are not limited to, IEEE 802.1 1 wireless local area network (WLAN), IEEE 802.3 local area network (LAN) (also known as Ethernet), point-to-point protocol (PPP), PPP over Ethernet (PPPoE), and the like. In some implementations, the TNAP 906 communicates with the TNGF 908 via an authentication, authorization, and accounting (AAA) interface. In some implementations, the TNGF 908 communicates with the AMF 910 via an N2 interface.

[0212] As a prerequisite, the UE 902 selects a PLMN and a TNAN 904 for connecting to this PLMN by using a TNAN selection procedure. During this procedure, the UE 902 discovers the PLMNs with which the TNAN 904 supports trusted connectivity (e.g., "5G connectivity").

[0213] Beginning in Figure 9A, at step 1 an L2 connection is established between the UE 902 and the TNAP 906 (see messaging 914). In the case of an IEEE 802. 11 type of access, this step corresponds to an 802. 11 association process. In the case of a point-to-point protocol (PPP) type of access, this step corresponds to a PPP link control protocol (LCP) negotiation process. In certain other types of non-3GPP access (e.g., Ethernet), this step may not be required.

[0214] An EAP authentication procedure is initiated in steps 2-3. Between the UE 902 and the TNAP 906. the EAP messages are encapsulated into L2 packets, e.g.. into IEEE 802.3 / 802. lx packets, into IEEE 802. 11 / 802. lx packets, into PPP packets, etc. Between the TNAP 906 and TNGF 908, the EAP packets are encapsulated into AAA messages. The TNAP 906 is a trusted entity.

[0215] At step 2, the TNAP 906 transmits an EAP identify request message (see messaging 916) and at step 3 the UE 902 responds by transmitting an EAP identify response message. The UE 902 provides a NAI that triggers the TNAP 906 to send an AAA request to a TNGF 908.

[0216] An EAP-5G procedure is executed in steps 4-10. The TNGF 908 converts EAP packets / messages received from the TNAP 906 into N2 messages for transmission to the AMF 910 and converts N2 messages received from the AMF 910 into EAP packets / messages for transmission to the TNAP 906.

[0217] At step 4, the TNGF 908 transmits an EAP request containing a 5G-Start packet to initiate an EAP-5G session, i.e., to start sending NAS messages encapsulated within EAP-5G packets (see messaging 918). The EAP-5G packets are not to be encapsulated into IKEv2 packets. The TNGF 908 transmits the EAP request (encapsulated into an AAA message) to the TNAP 906, and the TNAP 906 forwards the EAP request (encapsulated into one or more L2 packets) to the UE 902 (see messaging 920).

[0218] At step 5, the UE 902 transmits an EAP-5G response packet containing an access network (AN) parameters and a NAS message wi th a registration request message (or other service request message). The UE 902 transmits the EAP-5G response (encapsulated into one or more L2 packets) to the TNAP 906, and the TNAP 906 forwards the EAP-5G response (encapsulated into an AAA message) to the TNGF 908 (see messaging 922). Here, the AN parameters comprises a UE ID (i.e., a 5G-GUTI or a SUCI) and the NAS message also includes the user ID, a user authentication capability IE, and a user type parameter, as described above. In some implementations, the user ID may have the NAI format described above. The value in the UE identity shall be stored at TNGF 908 to be used as a key identifier as described in step 13b.

[0219] For the case of non-3GPP devices, where a device connects to non-3GPP access via the UE 902s or residential gateway (e.g., FN-RG or 5G-RG), the user ID may be ‘device identifier in NAI format' and the user type parameter may be set as non-3GPP device.

[0220] At step 6a, the TNGF 908 selects an AMF in the 5G core network of the selected PLMN based on the received AN-Params and local policy (see block 924). At step 6b, the TNGF 908 forwards the registration request (or the service request) received from the UE 902 to the selected AMF 910, e.g., within an N2 initial UE message (see messaging 926).

[0221] At conditional step 7a, the AMF 910 may decide to request the SUCI of the UE 902 by sending a NAS identity request message to the UE 902 (see messaging 928). The AMF 910 transmits the NAS identity request message to the TNGF 908 within an N2 message. The TNGF 908 encapsulates the NAS identity request message within EAP / 5G-NAS packets and forwards the NAS message to the UE 902 via the TNAP 906.

[0222] At step 7b, the UE 902 sends a NAS identity response message containing the SUCI of the AMF 910 (see messaging 930). The UE 902 encapsulates the NAS identity request message within one or more EAP / 5G-NAS packets and sends the NAS message to the TNGF 908 via the TNAP 906. The TNGF 908 transmits the NAS identity response message to the AMF 910 within an N2 message.

[0223] Continuing in Figure 9B at step 8, the AMF 910 may determine to authenticate the UE 902 by invoking an AUSF 912. In this case, the AMF 910 selects the AUSF 912 based on the SUPI or SUCI of the UE 902. At step 8a, the AMF 910 sends an authentication request message to the AUSF 912 (see messaging 932). This authentication request message includes the SUPI or SUCI of the UE 902, and further includes the user ID, the user authentication capability IE, and the user type parameter received in the registration request message.

[0224] At step 8b, the UE 902 and AUSF 912 perform an authentication and key agreement procedure via TNGF 908 and AMF 910 (see message exchange 934). In some implementations, the authentication packets are encapsulated within NAS authentication messages and the NAS authentication messages are encapsulated within EAP / 5G-NAS packets.

[0225] At step 8c, after the successful authentication, the AUSF 912 sends an authentication response message to the AMF 910 (see messaging 936). The authentication response message contains a KSEAF which is used by the AMF 910 to derive NAS security keys and a security keys for the TNGF 908 (i.e., KTNGF) and the TNAP 906 (i.e., KTNAP). The authentication response message also contains an EAP-Success packet based on successful completion of the authentication and key agreement procedure between the AUSF 912 and UE 902.

[0226] The UE 902 also derives the KSEAF after the successful authentication, and from that key it derives the same NAS security keys and KTNGF and KTNAP (see block 938). The TNGF key (KTNGF) and TNAP key (KTNAP) are used by the UE 902 and TNAN 904 for establishing the IPsec SA in later steps.

[0227] At step 9a, the AMF 910 sends a NAS SMC request towards the UE 902 in order to activate NAS security (see messaging 940). Here, it is assumed that authentication was successfully completed in step 8, therefore the AMF 910 also encapsulates the EAP-Success packet received from the AUSF 912 within the NAS SMC request message. At step 9b, the TNGF 908 forwards the NAS SMC request message to the UE 902 within an EAP-Req / 5G-NAS packet (see messaging 942).

[0228] At step 9c, the UE 902 completes the authentication procedure (if initiated in step 8), creates a NAS security context and the and sends the NAS SMC complete message (within an EAP-Res / 5G-NAS packet) towards the AMF 910 (see messaging 944). At step 9d, the TNGF 908 forwards the NAS SMC complete message to the AMF 910 within an N2 message (see messaging 946).

[0229] At step 10a, the AMF 910 sends an N2 initial context setup request message to the TNGF 908 that includes the KTNGF) (see messaging 948). As described above, the UE 902 has independently derived the same KTNGF.

[0230] At step 10b, after receiving the KTNGF (e g., equivalent to the KNSIWF described above), the TNGF 908 sends an EAP-Request / 5G-Notification packet to the UE 902 containing TNGF contact information (which includes the IP address of the TNGF 908) to the UE 902 via the TNAP 906 (see messaging 950).

[0231] Additionally, the TNGF 908 generates the TNAP key (KTNAP) and transfers it from the TNGF 908 to the TNAP 906 in step 10b (i.e., within a AAA message). However, the KTNAP is not included in the L2 message sent from the TNAP 906 to the UE 902. As described above, the UE 902 has independently derived the same KTNGF.

[0232] At step 10c, the UE 902 sends an EAP-Response / 5G-Notification packet to the TNGF 908 (see messaging 952). Additionally, the TNGF 908 uses the KTNGF to derive a TNAP key and an IPsec key. In various embodiments, the TNAP key and IPsec key are derived using a KDF (i.e., a cryptographic hash function).

[0233] At step lOd, after receiving the EAP-Response / 5G-Notification packet from the UE 902, the TNGF 908 sends the TNAP key and an EAP-Success packet to the TNAP 906 (see messaging 954). At step lOe, the TNAP 906 forwards the EAP-Success packet to the UE 902 (see messaging 956). Delivery of this EAP-Success packet completes (i.e., ends) the EAP-5G session for NAS signaling, and no further EAP-5G packets are exchanged.

[0234] At step 11, the common KTNAP is used by the UE 902 and TNAP 906 to derive security keys according to the applied non-3GPP technology and to establish an IPsec SA to protect all subsequent traffic. In case of IEEE 802.11 non-3GPP technology', the KTNAP is the pairwise master key (PMK), and a 4-way handshake is executed (see messaging 958) which establishes a security context between the UE 902 and the TNAP 906 (e.g.. implementing an IEEE 802. 11 WLAN access point (AP)) that is used to protect unicast and multicast traffic overthe air. All messages between UE 902 and TNAP 906 are encrypted and integrity protected from this step onwards. Regardless of the applied non-3GPP technology7, it is assumed that the KTNAP is used to derive security keys for encryption protection over the L2 connection between UE 902 and TNAP 906.

[0235] Continuing in Figure 9C, at step 12 the UE 902 receives an IP configuration from the TNAN 904, e.g., with dynamic host configuration protocol (DHCP) (see messaging 960).

[0236] At step 13a, the UE 902 initiates an IKE initial exchange (IKE_INIT) with the TNGF 908 to negotiate security parameters to protect IKE authentication (IKE_AUTH) messages (see messaging 962). The IKE INIT exchange uses the IP address of TNGF 908 that the UE 902 received during the EAP-5G signaling in step 9b.

[0237] At step 13b, the UE 902 initiates the IKE AUTH exchange and includes the same UE ID (i.e., SUCI or 5G-GUTI) as provided in step 5 (see messaging 964). The TNGF 908 uses the UE identity7as a key identifier to discover the KTNGF common to the TNGF 908 and the UE 902. The UE 902 and TNGF 908 each use the KTNGF to derive a common trusted IPsec key (Knpsec) to be used for mutual authentication. Null encryption may be negotiated, e.g.. as specified in RFC 2410.

[0238] At step 13c, the TNGF 908 completes the mutual authentication and IKE AUTH exchange (see messaging 966). After step 13c, an IPsec SA is established between the UE 902 and TNGF 908 (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.

[0239] At step 14, after the NWt connection is successfully established, the TNGF 908 responds to AMF 910 with an N2 initial context setup response message (see messaging 968).

[0240] At step 14a, if the AMF 910 received an indication that user-specific authentication is required and received user authentication and authorization attributes from the AUSF 912 (e.g., in turn from the UDM / UDR) during the authentication (step 8). then the AMF 910 determines to perform user authentication. Additionally, the AMF 910 may determine whether the TNGF 908 is appropriate for the netw ork slice selected (see block 970). If the network slice is compatible with the TNGF 908, then the AMF 910 proceeds with steps 15 to 19 (corresponding to Case A). Otherwise, if the selected TNGF 908 is not compatible, then the AMF 910 proceeds with step 20 to step 20 (corresponding to Case B), and steps 15 to 19 are skipped.

[0241] At step 15a, for Case A, based on the AMF 910 receiving the NGAP initial context setup response message for the UE 902, the AMF 910 sends the NAS registration accept message over the N2 towards the TNGF 908 along with the indication that user-specific authentication is required / requested for the UE 802 (see messaging 972).

[0242] At step 15b, upon receiving the NAS registration accept message from the AMF 910, the TNGF 908 forwards the NAS Registration accept message, including the indication that userspecific authentication is required / requested, to UE 902 via the established NWt connection (see messaging 974). All further NAS messages between the UE 902 and the TNGF 908 are carried over the established NWt connection.

[0243] At step 16, the UE 902 initiates a PDU session establishment by transmitting a PDU session establishment request message over IPsec (see messaging 976). This PDU session establishment may be implemented as specified in 3GPP TS 23.502, clause 4. 12a.5.

[0244] Continuing in Figure 9D, at step 17 the TNGF 908 may establish one or more IPsec child SAs per PDU session, the IPsec child SAs identified using the PDU session ID (see messaging 978 and 980).

[0245] At step 18, the TNGF 908 transmits a PDU session establishment accept message to the UE 902 completing the PDU session establishment (see messaging 982).

[0246] At step 19, user plane data for the established PDU session is transported between the UE 902 and TNGF 908 inside the established IPsec child SA (see messaging 984).

[0247] At step 20, for Case B, the AMF 910 may trigger a UE policy update procedure and update the UE policy (see message exchange 986).

[0248] At step 21a, the AMF 910 sends a registration reject message to the TNGF 908 (see messaging 988). The registration reject message is ciphered and integrity protected. At step 21b, the TNGF 908 forwards the registration reject message to the UE 902 (see messaging 990).

[0249] At step 22, the UE 902 deciphers and verifies the integrity of the registration reject message (see block 992). If the verification is successful, then the UE 902 selects a new TNGF and sends a registration request message to the AMF 910 via the newly selected TNGF.

[0250] Upon receiving the indication that user-specific authentication is required / requested from the AMF 910 in the NAS registration accept message, the UE 902 sends the user ID and the authorization information (e.g., service access token) in the NAS transport as part of the userauthentication request / response. The user authentication request / response is then forwarded by the TNGF 908 to the AMF 910 and the AMF 910 verifies the received user ID and the authorization information with the available authentication and authorization attribute data; if the received information matches the available data, then the user authentication and authorization is considered to be successful.

[0251] According to aspects of a fifth solution, authentication and authorization can be performed for third party' services during slice authentication as shown in Figures 10A-10B. In some implementations, a SEAF / AMF performs the role of the EAP authenticator and communicates with an AAA-S via a network slice-specific authentication and authorization function (NSSAAF). The NSSAAF undertakes any AAA protocol interworking with the AAA-S. Multiple EAP methods are possible for network slice-specific authentication and authorization (NSSAA). If the AAA-S belongs to a third party' the NSSAAF contacts the AAA-S via an AAA proxy (AAA-P). In some implementations, the NSSAAF and the AAA-P may be co-located. To protect privacy of the EAP ID used for the EAP-based NSSAA, a privacy -protection capable EAP method is recommended, if privacy protection is required.

[0252] Figures 10A-10B depict an exemplary' procedure 1000 to provide user authentication during network slice authentication, in accordance with aspects of the present disclosure. The procedure 1000 may be performed by a UE 1002 (e.g., an implementation of the UE 104, the UE 202, the UE 302, the UE 402, the UE 502, the UE 602, the UE 702, the UE 802, and / or the UE 902), an AMF 1004 having an SEAF (e.g., an implementation of the AMF 204, the AMF 304, the AMF 604, the AMF 808, and / or the AMF 910), an NSSAAF 1006 (e.g., an implementation of a NF in the CN 106), a UDM / UDR 1008 (e.g., an implementation of the UDM / UDR 208, the UDM 308. the UDM 408, the UDM 508, the UDM 608, and / or the UDM 710). and an AAA-S 1 12. The NSSAAF 1006 provides an interface with the AAA domain (e.g., the AAA-S 1012). In some implementations, the NSSAAF 1006 communicates with the AAA-S 1012 via an AAA- P 1010.

[0253] Beginning in Figure 10A, at step 1 the AMF 1004 may trigger the start of the NSSAA procedure for one or more network slices that are requiring NSSAA, e.g.. based on change of subscription information, or as triggered by the AAA-S 1012 (see block 1014). A network slice may be identified using single network slice selection assistance information (S-NSSAI), i.e., an identifier containing a slice / service type and (optionally) a slice differentiator. Based on the indication that user-specific authentication is required from the UDM / UDR 1008 or based on operator policy / subscription information (i.e., user authentication policy), the AMF 1004 (orSEAF) may determine if a user authentication needs to be performed for the UE 1002 in addition to the slice authentication.

[0254] If NSSAA and user authentication is triggered as a result of registration procedure, then the AMF 1004 may determine, e.g., based on the UE context stored in the AMF 1004, that for some or all S-NSSAI(s) subject to NSSAA and the user authentication is required, the UE 1002 has already been authenticated, e.g., following a registration procedure on a first access. Depending on the NSSAA result (e.g., success / failure) from the previous registration, the AMF 1004 may decide, e.g., based on network policies, to skip NSSAA for these S-NSSAIs during the registration on a second access.

[0255] If the NSSAA procedure corresponds to a re-authentication and re-authorization procedure triggered as a result of AAA server-triggered UE re-authentication and reauthorization for one or more S-NSSAIs, or triggered by the AMF 1004 based on operator policy or a subscription change and if S-NSSAIs that are requiring NSSAA are included in the allowed network slice selection assistance information (NSSAI) for each access t pe (e.g., 3GPP access, non-3GPP access), the AMF 1004 selects an access type to be used to perform the NSSAA procedure, e.g., based on network policies.

[0256] At step 2, the AMF 1004 sends a NAS message (e.g., NAS mobility management (MM) transport message including the S-NSSAI) to request the UE 1002 to provide a user ID for EAP authentication (EAP ID) for the S-NSSAI (see messaging 1016). Here, the NAS message includes an indication that user authentication (i.e., user-specific authentication) is needed and a user ID request indication.

[0257] At step 3, the UE 1002 sends an EAP ID response in a NAS message (e.g., NAS MM transport message) to provide the EAP ID for the S-NSSAI. alongside the S-NSSAI and the user ID towards the AMF 1004 (see messaging 1018). Here, the user ID may have the NAI format described above.

[0258] At step 4, the AMF 1004 sends an authentication request message to the NSSAAF 1006, such as an Nnssaaf_NSSAA_Authenticate request service message (see messaging 1020). Here, the authentication request message includes the EAP ID, the user ID, a UE ID (e g., GPSI), and the S-NSSAI.

[0259] At step 5. based on the received user ID. the NSSAAF 1006 sends a user data request message, such as an Nudm DM user data request message, to the UDM / UDR 1008 to fetch theuser authentication and authorization data / attributes or user authentication result if available (see messaging 1022). Here, the user data request message includes the S-NSSAI and the user ID.

[0260] At step 6, the UDM / UDR 1008 sends a user data response message, such as an Nudm DM user data response message, to the NSSAAF 1006 (see messaging 1024). Here, the user data response message includes the S-NSSAI, user ID, user authentication and authorization data / attributes fetched from the user identity profile. Additionally, or alternatively, if a user authentication result is available, the UDM / UDR 1008 may also provide the user authentication result.

[0261] At step 7. the NSSAAF 1006 forwards the EAP ID response in an AAA protocol message towards the AAA-S 1012 (see messaging 1026). The AAA protocol message with the EAP ID response also includes the S-NSSAI and GPSI. If the AAA-P 1010 is present (e.g., because the AAA-S 1012 belongs to athird party7and the operator deploys a proxy towards third parties), then the NSSAAF 1006 forwards the AAA protocol message containing the EAP ID response to the AAA-P 1010; otherwise, the NSSAAF 1006 forwards the AAA protocol message directly to the AAA-S 1012. The NSSAAF 1006 routes to the AAA-S 1012 based on the S- NSSAI.

[0262] The AAA-S 1012 uses the EAP-ID and S-NSSAI to identify for which UE 1002 and network slice the authorization is requested. The AAA-S 1012 stores the GPSI to create an association with the EAP ID in the EAP ID response message, e.g.. so the AAA-S 1012 can later use the GPSI / EAP ID association to revoke authorization or to trigger reauthentication.

[0263] If the AAA-S 1012 belongs to the third party', the NSSAAF 1006 may optionally map the S-NSSAI to external network slice information (ENSI) and forward the EAP identity message to the AAA-S 1012 together with the ENSI, the user ID, the user authentication and authorization attributes, and the GPSI. In this case, the AAA-S 1012 uses the EAP-ID, the user ID, and the ENSI to identify the UE 1002 for which the slice authorization and the user-specific authentication and authorization are requested, e.g., when sending a user authentication message (or user authentication and authorization message).

[0264] Continuing in Figure 10B, during step 8 to 13, EAP messages are exchanged between the AAA-S 1012 and the UE 1002. One or more than one iterations of these steps may occur.

[0265] At step 8. the AAA-S 1012 transmits an EAP message (e.g.. encapsulated in a AAA protocol message) towards the NSSAAF 1006 (see messaging 1028). The AAA protocolmessage with the EAP message also includes the GPSI, the S-NSSAI (or ENSI), a user authentication message, and the user ID. Again, if the AAA-P 1010 is present, then the AAA-S 1012 forwards the AAA protocol message to the AAA-P 1010; otherwise, the AAA-S 1012 forwards the AAA protocol message directly to the NSSAAF 1006.

[0266] At step 9, the NSSAAF 1006 forwards the EAP message, the GPSI, the user authentication message, and the user ID to the AMF 1004, e.g., in a Nnssaaf_NSSAA_Authenticate response message (see messaging 1030).

[0267] At step 10, the AMF 1004 forwards the EAP message, the user authentication message, and the user ID to the UE 1002, e.g., in aNAS MM transport message (see messaging 1032).

[0268] At step 11, the UE 1002 computes a result for the EAP message and / or user authentication message received from the AAA-S 1012 and transmits a response to the AMF 1004, e.g., in aNAS MM transport message (see messaging 1034). The NAS MM transport message also comprises an EAP message, a user authentication message, and the user ID.

[0269] At step 12, the AMF 1004 forwards the EAP message, GPSI, user authentication message, and user ID to the NSSAAF 1006, e.g., in a Nnssaaf NSSAA Authenticate request message (see messaging 1036).

[0270] At step 13, the NSSAAF 1006 forwards the EAP message, the GPSI, the S-NSSAI (or ENSI), the user authentication message, and the user ID towards the AAA-S 1012, e.g., in an AAA protocol message, either directly or via the AAA-P 1010 (see messaging 1038).

[0271] At step 14, EAP authentication and user authentication and authorization completes. The AAA-S 1012 delivers an EAP-Success / Failure message and user authentication and authorization failure / success message (e.g., encapsulated in a AAA protocol message) to the NSSAAF 1006, either directly or via the AAA-P 1010 (see messaging 1040). The AAA protocol message with the EAP-Success / Failure message and the user authentication and authorization failure / success message also includes the GPSI, the S-NSSAI (or ENSI), and the user ID.

[0272] At step 15, the NSSAAF 1006 forwards the EAP-Success / Failure message, the user authentication and authorization failure / success message, and the user ID to the AMF 1004, e.g., in a Nnssaaf_NSSAA_Authenticate response message (see messaging 1042).

[0273] At step 16, the AMF 1004 transmits a NAS MM transport message to the UE 1002 that contains the EAP-Success / Failure message, the user authentication and authorization failure / success message, and the user ID (see messaging 1044).

[0274] Based on the result of slice-specific authentication (EAP-Success / Failure) and the user authentication and authorization failure / success, if a new allowed NSS Al or new rejected NSSAIs needs to be delivered to the UE 1002, or if AMF re-allocation is required, the AMF 1004 may initiate a UE configuration update procedure, e.g., for each access ty pe.

[0275] If the NSSAA procedure cannot be completed (e.g., due to server error or the UE 1002 becoming unreachable), the AMF 1004 may set the status of the corresponding S-NSSAI subject to NSSAA in the UE context, so that an NSSAA is executed next time the UE 1002 requests to register with the S-NSSAI.

[0276] Figure 11 illustrates an example of a protocol stack 1100, in accordance with aspects of the present disclosure. While Figure 11 shows a UE 1106, a RAN node 1108, and a 5GC 1110 (e.g., comprising at least an AMF), these are representative of a set of UEs 104 interacting with an NE 102 (e.g., base station) and a CN 106. As depicted, the protocol stack 1100 comprises a user plane protocol stack 1102 and a control plane protocol stack 1104. The user plane protocol stack 1102 includes a physical (PHY) layer 1112, a medium access control (MAC) sublayer 1114, a radio link control (RLC) sublayer 1116, a packet data convergence protocol (PDCP) sublayer 1118, and a service data adaptation protocol (SDAP) sublayer 1120. The control plane protocol stack 1 104 includes a PHY layer 1 112, a MAC sublayer 11 14, an RLC sublayer 11 16, and a PDCP sublayer 1118. The control plane protocol stack 1104 also includes a radio resource control (RRC) layer 1122 and a non-access stratum (NAS) layer 1124.

[0277] The access stratum (AS) layer 1126 (also referred to as “AS protocol stack"’) for the user plane protocol stack 1102 consists of at least SDAP, PDCP, RLC and MAC sublayers, and the physical layer. The AS layer 1128 for the control plane protocol stack 1 104 consists of at least RRC, PDCP, RLC and MAC sublayers, and the physical layer. The layer-1 (LI) includes the PHY layer 1112. The L2 is split into the SDAP sublayer 1120, PDCP sublayer 1118, RLC sublayer 1116, and MAC sublayer 1114. The layer-3 (L3) includes the RRC layer 1122 and the NAS layer 1124 for the control plane and includes, e.g., an internet protocol (IP) layer and / or PDU Layer (not depicted) for the user plane. LI and L2 are referred to as “lower layers,” while L3 and above (e.g., transport layer, application layer) are referred to as “higher layers” or “upper layers.”

[0278] The PHY layer 1112 offers transport channels to the MAC sublayer 1114. The PHY layer 1112 may perform a beam failure detection procedure using energy’ detection thresholds, as described herein. In certain embodiments, the PHY layer 1112 may send an indication of beam failure to a MAC entity at the MAC sublayer 1114. The MAC sublayer 1 114 offers logical channels to the RLC sublayer 1116. The RLC sublayer 1116 offers RLC channels to the PDCP sublayer 1118. The PDCP sublayer 1118 offers radio bearers to the SDAP sublayer 1120 and / or RRC layer 1122. The SDAP sublayer 1120 offers quality' of service (QoS) flows to the core network (e.g., 5GC). The RRC layer 1122 manages the addition, modification, and release of carrier aggregation and / or dual connectivity7. The RRC layer 1122 also manages the establishment, configuration, maintenance, and release of signaling radio bearers (SRBs) and data radio bearers (DRBs).

[0279] The NAS layer 1124 is between the UE 1106 and an AMF in the 5GC 1110. NAS messages are passed transparently through the RAN. The NAS layer 1124 is used to manage the establishment of communication sessions and for maintaining continuous communications with the UE 1106 as it moves between different cells of the RAN. In contrast, the AS layers 1126 and 1128 are between the UE 1106 and the RAN (i.e., RAN node 1108) and carry7information over the wireless portion of the network. While not depicted in Figure 11 , the IP layer exists above the NAS layer 1124. a transport layer exists above the IP layer, and an application layer exists above the transport layer.

[0280] The MAC sublayer 1114 is the lowest sublayer in the L2 architecture of the NR protocol stack. Its connection to the PHY layer 11 12 below is through transport channels, and the connection to the RLC sublayer 1116 above is through logical channels. The MAC sublayer 1114 therefore performs multiplexing and demultiplexing between logical channels and transport channels: the MAC sublayer 1114 in the transmitting side constructs MAC PDUs (also known as transport blocks (TBs)) from MAC service data units (SDUs) received through logical channels, and the MAC sublayer 1114 in the receiving side recovers MAC SDUs from MAC PDUs received through transport channels.

[0281] In the radio protocol architectures described herein, the term “SDU"’ refers to a data unit that is received by a sublayer from a higher sublayer, or that is sent by a sublayer to a higher sublayer. Likewise, the term “PDU” refers to a data unit that is sent by a sublayer to a lower sublayer, or that is received by a sublayer from a lower sublayer.

[0282] The MAC sublay er 1114 provides a data transfer service for the RLC sublayer 1116 through logical channels, which are either control logical channels which carry control data (e.g.,RRC signaling) or traffic logical channels which earn user plane data. On the other hand, the data from the MAC sublayer 1114 is exchanged with the PHY layer 1112 through transport channels, which are classified as UL or downlink (DL). Data is multiplexed into transport channels depending on how it is transmitted over the air.

[0283] The PHY layer 1112 is responsible for the actual transmission of data and control information via the air interface, i.e., the PHY layer 1112 carries all information from the MAC transport channels over the air interface on the transmission side. Some of the important functions performed by the PHY layer 1112 include coding and modulation, link adaptation (e.g., adaptive modulation and coding (AMC)). power control, cell search and random access (for initial synchronization and handover purposes) and other measurements (inside the 3GPP system (i.e., NR and / or LTE system) and between systems) for the RRC layer 1122. The PHY layer 1112 performs transmissions based on transmission parameters, such as the modulation scheme, the coding rate (i.e.. the modulation and coding scheme (MCS)). the number of physical resource blocks (PRBs), etc.

[0284] In some embodiments, the protocol stack 1 100 may be an NR protocol stack used in a 5G NR system. An LTE protocol stack may comprise similar structure to the protocol stack 1100, with the differences that the LTE protocol stack lacks the SDAP sublayer 1120 in the AS layer 1126, that an EPC replaces the 5GC 1110, and that the NAS layer 1124 is between the UE 1106 and an MME in the EPC. Additionally, the present disclosure distinguishes between a protocol layer (such as the aforementioned PHY layer 1112, MAC sublayer 1114, RLC sublayer 1116, PDCP sublayer 1118, SDAP sublayer 1120, RRC layer 1122 and NAS layer 1124) and a transmission layer in multiple-input multiple-output (MIMO) communication (also referred to as a "‘MIMO layer” or a “data stream”).

[0285] Figure 12 illustrates an example of a UE 1200 in accordance with aspects of the present disclosure. The UE 1200 may include a processor 1202, a memory 1204, a controller 1206, and a transceiver 1208. The processor 1202, the memory 1204, the controller 1206, or the transceiver 1208. 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.

[0286] The processor 1202, the memory' 1204, the controller 1206, or the transceiver 1208, 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.

[0287] The processor 1202 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a central processing unit (CPU), an ASIC, a field programmable gate array (FPGA), or any combination thereof). In some implementations, the processor 1202 may be configured to operate the memory 1204. In some other implementations, the memory 1204 may be integrated into the processor 1202. The processor 1202 may be configured to execute computer-readable instructions stored in the memory 1204 to cause the UE 1200 to perform various functions of the present disclosure.

[0288] The memory 1204 may include volatile or non-volatile memory7. The memory' 1204 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1202, cause the UE 1200 to perform various functions described herein. The code may be stored in a non -transitory' computer-readable medium such the memory' 1204 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.

[0289] In some implementations, the processor 1202 and the memory 1204 coupled with the processor 1202 may be configured to cause the UE 1200 to perform various functions (e.g., operations, signaling) described herein (e.g., executing, by the processor 1202, instructions stored in the memory 1204). In some implementations, the processor 1202 may include multiple processors and the memory 1204 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may' be individually or collectively, configured to perform various functions (e.g., operations, signaling) of the UE 1200 12 12 12 12as disclosed herein.

[0290] The processor 1202 coupled with the memory 1204 may be configured to, capable of, or operable to cause the UE 1200 to transmit an authentication message comprising a user type and a user authentication capability; perform a primary authentication associated with the UE; transmit a user ID; perform a user authentication based on the user ty pe and the user ID; and access a service associated with the user ID based on the user authentication.

[0291] In some implementations, the authentication message further comprises the user ID. In other implementations, the processor 1202 coupled with the memory' 1204 may be configured to, capable of, or operable to cause the UE 1200 to: 1) receive a user authentication request message in response to the primary authentication; and 2) transmit a user authentication response message comprising the user ID.

[0292] In some implementations, to access the service, the processor 1202 coupled with the memory' 1204 may be configured to, capable of, or operable to cause the UE 1200 to: 1) transmit a user service access request message comprising the user ID and a service authorization token associated with the user ID; and 2) receive a user service access response message.

[0293] In certain implementations, the processor 1202 coupled with the memory 1204 may be configured to, capable of, or operable to cause the UE 1200 to: 1) transmit an application session request message comprising the user ID; and 2) receive an application session response message comprising the service authorization token.

[0294] In some implementations, the user authentication capability is comprised in a security’ capabilities IE. In some implementations, the user authentication is performed over a user plane in a mobile communication network.

[0295] In some implementations, to perform the user authentication, the processor 1202 coupled with the memory' 1204 may be configured to, capable of, or operable to cause the UE 1200 to exchange EAP messages with a third-party AAA-S.

[0296] The controller 1206 may manage input and output signals for the UE 1200. The controller 1206 may also manage peripherals not integrated into the UE 1200. In some implementations, the controller 1206 may utilize an operating system (OS) such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1206 may be implemented as part of the processor 1202.

[0297] In some implementations, the UE 1200 may include at least one transceiver 1208. In some other implementations, the UE 1200 may have more than one transceiver 1208. The transceiver 1208 may represent a wireless transceiver. The transceiver 1208 may’ include one or more receiver chains 1210, one or more transmitter chains 1212, or a combination thereof.

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

[0299] A transmitter chain 1212 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1212 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 1212 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 1212 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0300] Figure 13 illustrates an example of a processor 1300 in accordance with aspects of the present disclosure. The processor 1300 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1300 may include a controller 1302 configured to perform various operations in accordance with examples as described herein. The processor 1300 may optionally include at least one memory 1304, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 1300 may optionally include one or more arithmetic-logic units (ALUs) 1306. 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).

[0301] The processor 1300 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 1300) 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).

[0302] The controller 1302 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 1300 to cause the processor 1300 to support various operations in accordance with examples as described herein. For example, the controller 1302 may operate as a control unit of the processor 1300, generating control signals that manage the operation of various components of the processor 1300. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

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

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

[0305] The memory 1304 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1300, cause the processor 1300 to perform various functions described herein. The code may be stored in a non-transitory computer- readable medium such as system memory7or another type of memory7. The controller 1302 and / or the processor 1300 may be configured to execute computer-readable instructions stored in thememory 1304 to cause the processor 1300 to perform various functions. For example, the processor 1300 and / or the controller 1302 may be coupled with or to the memory’ 1304, the processor 1300, the controller 1302, and the memory 1304 may be configured to perform various functions described herein. In some examples, the processor 1300 may include multiple processors and the memory 1304 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.

[0306] The one or more ALUs 1306 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1306 may reside within or on a processor chipset (e.g., the processor 1300). In some other implementations, the one or more ALUs 1306 may reside external to the processor chipset (e.g., the processor 1300). One or more ALUs 1306 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1306 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1306 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 1306 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 1306 to handle conditional operations, comparisons, and bitwise operations.

[0307] In various implementations, the processor 1300 may support various functions (e g., operations, signaling) of a UE. in accordance with examples as disclosed herein. For example, the controller 1302 coupled with the memory 1304 may be configured to, capable of. or operable to cause the processor 1300 to transmit an authentication message comprising a user type and a user authentication capability7; perform a primary7authentication associated with the UE; transmit a user ID; perform a user authentication based on the user ty pe and the user ID; and access a service associated with the user ID based on the user authentication.

[0308] In various implementations, the processor 1300 may support various functions (e.g., operations, signaling) of an NE or a network function (e.g., of the CN 106), in accordance with examples as disclosed herein. For example, the controller 1302 coupled with the memory71304 may be configured to, capable of, or operable to cause the processor 1300 may be configured to or operable to support a means for transmitting cell barring information for a first cell associated with a first frequency layer; transmit, on the first cell, broadcast information comprising anindication of a second cell associated with a second frequency layer; transmit, to a UE, a paging message via the second cell; receive, from the UE, a paging response message via the first cell; and establish a connection with the UE via the first cell.

[0309] Figure 14 illustrates an example of an NE 1400 in accordance with aspects of the present disclosure. The NE 1400 may include a processor 1402, a memory 1404, a controller 1406, and a transceiver 1408. The processor 1402, the memory 1404, the controller 1406, or the transceiver 1408, 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.

[0310] The processor 1402, the memory 1404, the controller 1406, or the transceiver 1408, or various combinations or components thereof may be implemented in hardware (e.g., circuitry ). The hardware may include a processor, a DSP, an 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.

[0311] The processor 1402 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 1402 may be configured to operate the memory 1404. In some other implementations, the memory 1404 may be integrated into the processor 1402. The processor 1402 may be configured to execute computer-readable instructions stored in the memory 1404 to cause the NE 1400 to perform various functions of the present disclosure.

[0312] The memory71404 may include volatile or non-volatile memory7. The memory71404 may store computer-readable, computer-executable code including instructions when executed by the processor 1402 cause the NE 1400 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1404 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.

[0313] In various implementations, the processor 1402 and the memory71404 coupled with the processor 1402 may be configured to cause the NE 1400 to perform various functions (e.g., operations, signaling) described herein (e.g., executing, by the processor 1402, instructions storedin the memory 1404). In some implementations, the processor 1402 may include multiple processors and the memory71404 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may be individually or collectively, configured to perform various functions (e.g., operations, signaling) of the NE 1400 as disclosed herein.

[0314] The processor 1402 coupled with the memory 1404 may be configured to, capable of, or operable to cause the NE 1400 to receive an authentication request message comprising a user type, a user authentication capability, and a user ID associated with a UE; identify a user identity profile based on the authentication request message; determine a requirement for user authentication based at least in part on the user type and the user authentication capability; and transmit, to a first authentication entity, an authentication response message for triggering a primary authentication of the UE, where the authentication response message comprises an indication of the requirement for user authentication.

[0315] In some implementations, the processor 1402 coupled with the memory 1404 may be configured to, capable of, or operable to cause the NE 1400 to transmit, to a second authentication entity, a user authentication request message for triggering a user authentication. In such implementations, the authentication request message may include the user ID and security credentials associated with the user identity profile. In certain implementations, the second authentication entity comprises a third-party AAA-S or an AS (or AF).

[0316] The processor 1402 coupled with the memory 1404 may be configured to, capable of, or operable to cause the NE 1400 to fetch one or more security credentials for authenticating the user ID. In some implementations, the NE 1400 may comprise a UDM. In some implementations, the authentication request message is received from an AUSF or an NSSAAF.

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

[0318] In some implementations, the NE 1400 may include at least one transceiver 1408. In some other implementations, the NE 1400 may have more than one transceiver 1408. The transceiver 1408 may represent a wireless transceiver. The transceiver 1408 may include one or more receiver chains 1410, one or more transmitter chains 1412, or a combination thereof.

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

[0320] A transmitter chain 1412 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1412 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 AM, FM. or digital modulation schemes like PSK or QAM. The transmitter chain 1412 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 1412 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0321] Figure 15 depicts one embodiment of a method 1500 in accordance with aspects of the present disclosure. In various embodiments, the operations of the method 1500 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.

[0322] At step 1502, the method 1500 may include transmitting an authentication message comprising a user type and a user authentication capability. The operations of step 1502 may be performed in accordance with examples as described herein. In some implementations, aspects of the operation of step 1502 may be performed by a UE, as described with reference to Figure 12.

[0323] At step 1504, the method 1500 may include performing a primary authentication associated with the UE. The operations of step 1504 may be performed in accordance with examples as described herein. In some implementations, aspects of the operation of step 1504 may be performed by a UE, as described with reference to Figure 12.

[0324] At step 1506, the method 1500 may include transmitting a user ID. The operations of step 1506 may be performed in accordance with examples as described herein. In someimplementations, aspects of the operation of step 1506 may be performed by a UE, as described with reference to Figure 12.

[0325] At step 1508, the method 1500 may include performing a user authentication based on the user type and the user ID. The operations of step 1508 may be performed in accordance with examples as described herein. In some implementations, aspects of the operation of step 1508 may be performed by a UE, as described with reference to Figure 12.

[0326] At step 1510, the method 1500 may include accessing a service associated with the user ID based on the user authentication. The operations of step 1510 may be performed in accordance with examples as described herein. In some implementations, aspects of the operation of step 1510 may be performed by a UE, as described with reference to Figure 12.

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

[0328] Figure 16 depicts one embodiment of a method 1600 in accordance with aspects of the present disclosure. The operations of the method 1600 may be implemented by an NE or a network function of the CN 106, as described herein. In some implementations, the RAN may execute a set of instructions to control the function elements of the RAN to perform the described functions.

[0329] At step 1602, the method 1600 may include receiving an authentication request message comprising a user type, a user authentication capability, and a user ID associated with a UE. The operations of step 1602 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 1602 may be performed by an NE, as described with reference to Figure 14.

[0330] At step 1604, the method 1600 may include identifying a user identity profile based on the authentication request message. The operations of step 1604 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 1604 may be performed by an NE, as described with reference to Figure 14.

[0331] At step 1606, the method 1600 may include determining a requirement for user authentication based at least in part on the user type and the user authentication capability'. The operations of step 1606 may be performed in accordance with examples as described herein. Insome implementations, aspects of the operations of step 1606 may be performed by an NE, as described with reference to Figure 14.

[0332] At step 1608, the method 1600 may include transmitting, to a first authentication entity, an authentication response message for triggering a primary authentication of the UE. the authentication response message including an indication of the requirement for user authentication. The operations of step 1608 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of step 1608 may be performed by an NE. as described with reference to Figure 14.

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

[0334] 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.

Claims

CLAIMSWhat is claimed is:

1. A user equipment (UE), comprising: at least one memory7; and at least one processor coupled with the at least one memory and configured to cause the UE to: transmit an authentication message comprising a user type and a user authentication capability; perform a primary7authentication associated with the UE; transmit a user identifier (ID); perform a user authentication based on the user type and the user ID; and access a service associated with the user ID based on the user authentication.

2. The UE of claim 1. wherein the authentication message further comprises the user ID.

3. The UE of claim 1, wherein the at least one processor is configured to cause the UE to: receive a user authentication request message in response to the primary7authentication; and transmit a user authentication response message comprising the user ID.

4. The UE of claim 1, wherein the user authentication capability is comprised in a security capabilities information element (IE).

5. The UE of claim 1, wherein to access the service, the at least one processor is configured to cause the UE to: transmit a user service access request message comprising the user ID and a service authorization token associated with the user ID; and receive a user service access response message.

6. The UE of claim 5. wherein the at least one processor is configured to cause the UE to: transmit an application session request message comprising the user ID; and receive an application session response message comprising the service authorization token.

7. The UE of claim 1, wherein the user authentication is performed over a user plane in a mobile communication network.

8. The UE of claim 1. wherein to perform the user authentication, the at least one processor is configured to cause the UE to exchange extensible authentication protocol (EAP) messages with a third-party authentication, authorization, and accounting server (AAA- S).

9. A method at, the method comprising: transmitting an authentication message comprising a user type and a user authentication capability; performing a primary authentication associated with a user equipment (UE); transmitting a user identifier (ID); performing a user authentication based on the user type and the user ID; and accessing a service associated with the user ID based on the user authentication.

10. An apparatus for performing a network function, the apparatus comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the apparatus to: receive an authentication request message comprising a user type, a user authentication capability, and a user identifier (ID) associated with a user equipment (UE); identify a user identity profile based on the authentication request message; determine a requirement for user authentication based at least in part on the user type and the user authentication capability; and transmit, to a first authentication entity, an authentication response message for triggering a primary' authentication of the UE, wherein the authentication response message comprises an indication of the requirement for user authentication.

11. The apparatus of claim 10, wherein the at least one processor is configured to cause the apparatus to: transmit, to a second authentication entity, a user authentication request message for triggering a user authentication,wherein the authentication request message comprises the user ID and security credentials associated with the user identity profile.

12. The apparatus of claim 11. wherein the second authentication entity comprises a third- party authentication, authorization, and accounting server (AAA-S) or an application server (AS).

13. The apparatus of claim 10, wherein the at least one processor is configured to cause the apparatus to fetch one or more security' credentials for authenticating the user ID.

14. The apparatus of claim 10, wherein the network function comprises a unified data management (UDM) function in a mobile communication network.

15. The apparatus of claim 10, wherein the authentication request message is received from an authentication server function (AUSF) or a network slice specific authentication and authorization function (NSSAAF).

16. A method performed at a network function, the method comprising: receiving an authentication request message comprising a user ty pe, a user authentication capability, and a user identifier (ID) associated with a user equipment (UE); identifying a user identity profile based on the authentication request message; determining a requirement for user authentication based at least in part on the user type and the user authentication capability; and transmitting, to a first authentication entity, an authentication response message for triggering a primary authentication of the UE, wherein the authentication response message comprises an indication of the requirement for user authentication.

17. The method of claim 1 , further comprising: transmitting, to a second authentication entity, a user authentication request message for triggering a user authentication, wherein the authentication request message comprises the user ID and security credentials associated with the user identity profile.

18. The method of claim 17, wherein the second authentication entity comprises a third-party authentication, authorization, and accounting (AAA) server or an application server.

19. The method of claim 16, further comprising fetching one or more security credentials for authenticating the user ID.

20. The method of claim 16. wherein the network function comprises a unified data management (UDM) function in a mobile communication network, and wherein the authentication request message is received from an authentication server function (AUSF) or a network slice specific authentication and authorization function (NSSAAF).

Images