[go: up one dir, main page]

WO2025210408A1 - Authentification à l'aide d'un identifiant d'utilisateur - Google Patents

Authentification à l'aide d'un identifiant d'utilisateur

Info

Publication number
WO2025210408A1
WO2025210408A1 PCT/IB2025/000264 IB2025000264W WO2025210408A1 WO 2025210408 A1 WO2025210408 A1 WO 2025210408A1 IB 2025000264 W IB2025000264 W IB 2025000264W WO 2025210408 A1 WO2025210408 A1 WO 2025210408A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
authentication
message
amf
request message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/IB2025/000264
Other languages
English (en)
Inventor
Sheeba Backia Mary BASKARAN
Andreas Kunz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lenovo Singapore Pte Ltd
Original Assignee
Lenovo Singapore Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lenovo Singapore Pte Ltd filed Critical Lenovo Singapore Pte Ltd
Publication of WO2025210408A1 publication Critical patent/WO2025210408A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/72—Subscriber identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication

Definitions

  • the present disclosure relates to wireless communications, and more specifically to authentication using a user identifier (ID), for example, a network-controlled user ID.
  • ID user identifier
  • 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).
  • 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.).
  • RATs radio access technologies
  • 3G third generation
  • 4G fourth generation
  • 5G fifth generation
  • 6G sixth generation
  • 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.
  • 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.
  • a method performed or performable by a UE for wireless communication 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.
  • 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.
  • 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.
  • 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.
  • Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.
  • Figure 2 illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.
  • Figure 3 illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.
  • Figure 4A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.
  • Figure 4B is a continuation of the flow diagram of Figure 4A.
  • Figure 5A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.
  • Figure 5B is a continuation of the flow diagram of Figure 5 A.
  • Figure 6 illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.
  • Figure 7 illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.
  • Figure 8A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.
  • Figure 8B is a continuation of the flow diagram of Figure 8A.
  • Figure 9A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.
  • Figure 9B is a continuation of the flow diagram of Figure 9A.
  • Figure 9C is a continuation of the flow diagram of Figures 9A and 9B.
  • Figure 9D is a continuation of the flow diagram of Figures 9A, 9B and 9C.
  • Figure 10A illustrates a flow diagram of communications in a wireless system in accordance with aspects of the present disclosure.
  • Figure 1 OB is a continuation of the flow diagram of Figure 10A.
  • Figure 11 illustrates an example of a protocol stack in accordance with aspects of the present disclosure.
  • Figure 12 illustrates an example of a UE in accordance with aspects of the present disclosure.
  • Figure 13 illustrates an example of a processor in accordance with aspects of the present disclosure.
  • Figure 14 illustrates an example of an NE in accordance with aspects of the present disclosure.
  • Figure 15 illustrates a flowchart of a method performed by a UE, in accordance with aspects of the present disclosure.
  • Figure 16 illustrates a flowchart of a method performed by an NE, in accordance with aspects of the present disclosure.
  • 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.
  • the methods may be performed using computer-executable code embedded on a computer-readable medium.
  • 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.
  • the authentication and authorization of a user ID corresponding to a human user scenario may be required.
  • 3GPP third generation partnership project
  • 5G systems a UE is authenticated and authorized for services based on the subscription with the mobile network operator (MNO) (or wireless carrier).
  • MNO mobile network operator
  • 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.
  • the authentication of the gateway UE 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).
  • UDM/UDR unified data management and/or unified data repository
  • the existing 5G systems do not allow user-specific authentication in the case of non-3GPP devices.
  • the attacker can access the network as a non-3GPP device via one gateway UE or residential gateway without any authorization and restriction.
  • 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 necessary 7 operator 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.
  • FIG. 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.
  • CN core network
  • the wireless communications system 100 may support various radio access technologies.
  • 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.
  • 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.
  • LTE Long- Term Evolution
  • LTE-A LTE-Advanced
  • NR new radio
  • 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.
  • IEEE Institute of Electrical and Electronics Engineers
  • Wi-Fi Wi-Fi
  • WiMAX IEEE 802.16
  • 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.
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • CDMA code division multiple access
  • 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.
  • an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.
  • 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.
  • 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.
  • an NE 102 may be moveable, for example, a satellite associated with a non-terrestnal network (NTN).
  • NTN non-terrestnal network
  • 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.
  • the one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100.
  • a UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology 7 .
  • the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples.
  • 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.
  • LoT intemet-of-things
  • LoE intemet-of-everything
  • MTC machine-type communication
  • a UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link.
  • a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link.
  • D2D device-to-device
  • the communication link may be referred to as a sidelink.
  • a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.
  • An NE 102 may support communications with the CN 106, or with another NE 102, or both.
  • 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).
  • the NE 102 may communicate with each other directly.
  • the NE 102 may communicate with each other or indirectly (e.g.. via the CN 106).
  • 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).
  • TRPs transmission-reception points
  • the CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions.
  • the CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility 7 (e.g., a mobility 7 management entity 7 (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)).
  • EPC evolved packet core
  • 5GC 5G core
  • MME mobility 7 management entity 7
  • AMF access and mobility management functions
  • S-GW serving gateway
  • PDN gateway packet data network gateway
  • UPF user plane function
  • the control plane entity may manage non-access stratum (NAS) functions, such as mobility 7 , 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.
  • NAS non-access stratum
  • 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.
  • one or more UEs 104 may communicate with the application server.
  • a UE 104 may establish a session (e.g...
  • 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).
  • 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).
  • the NEs 102 and the UEs 104 may support different resource structures.
  • the NEs 102 and the UEs 104 may support different frame structures.
  • the NEs 102 and the UEs 104 may support a single frame structure.
  • 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.
  • 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 subcarrier spacing e.g.. 15 kHz
  • a normal cyclic prefix e.g. 15 kHz
  • a time interval of a resource may be organized according to frames (also referred to as radio frames).
  • Each frame may have a duration, for example, a 10 millisecond (ms) duration.
  • each frame may include multiple subframes.
  • each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration.
  • each frame may have the same duration.
  • each subframe of a frame may have the same duration.
  • a time interval of a resource may be organized according to slots.
  • 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.
  • Each slot may include a number (e.g., quantity) of symbols (e.g., orthogonal frequency domain multiplexing (OFDM) symbols).
  • the number (e g., quantity) of slots for a subframe may depend on a numerology 7 .
  • a slot may include 14 symbols.
  • an extended cyclic prefix e.g., applicable for 60 kHz subcarrier spacing
  • a slot may include 12 symbols.
  • an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc.
  • 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).
  • FR1 410 MHz - 7. 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
  • FR5 114.25 GHz - 300 GHz
  • the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands.
  • 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).
  • FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.
  • FR1 may be associated with one or multiple numeral ogies (e.g., at least three numerologies).
  • FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies).
  • Wireless communication in unlicensed 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.
  • the unlicensed operation can be on the Uu interface (referred to as NR-U) or also on sidelink interface (e.g., SL-U).
  • 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.
  • the operator can take additional information from the network into account to provide a higher level of security for the authentication of a user.
  • the user ID 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.
  • IMSI international mobile subscriber identity
  • MSISDN mobile station international subscriber directory number
  • IP internet protocol
  • IMS IMS private identity
  • IMPU IMS public user identify
  • SUPI subscription permanent identifier
  • GPSI generic public subscription identifier
  • IMEI international mobile equipment identity
  • the user ID is an identity associated with the (e.g., human) user and is independent of the particular 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.
  • the user ID may be provided by some entity within the operator’s network or by a third party.
  • the 3GPP system e.g., implementing or implemented by the wireless communication system 100
  • 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.
  • PLMN public land mobile network
  • 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.
  • the operator may be able to enable or disable the use of a user ID in the operator’s network.
  • the 3GPP system may protect the privacy of the user by transferring to a service only user ID information that is necessary 7 to provide the service and for which the user has consented to when registering for the service.
  • 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.
  • 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.
  • the 3GPP system provides means to support authentication and authorization of the human user based on a user ID linked to a 3GPP subscription.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 5G-RG 5G residential gateway
  • 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.
  • 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.
  • 5GS 5G system
  • 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).
  • a UE 202 e.g., an implementation of the UE 104
  • AMF 204 e.g., an implementation of a network function (NF) in the CN 106
  • SMF session management function
  • UDM/UDR 208 e.g., an implementation of a NF in the CN 106
  • PCF policy control function
  • 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.
  • the UE 202 may indicate the current user ID in N1 session management (SM) container (see messaging 214).
  • SM session management
  • the AMF 204 selects a SMF 206 (see block 216).
  • 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).
  • 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).
  • the SMF 206 is responsible for checking whether the UE 202 requests are compliant with the user identity profile.
  • 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.
  • the SMF 206 transmits an Nsmf PDUSession CreateSMContextResponse message (e.g., including an SM context ID) to the AMF 204 (see messaging 222).
  • the SMF 206 may transmit aNsmf PDUSession UpdateSMContextResponse message to the AMF 204.
  • the SMF 206 also provides the user identity profile to the AMF 204 in step 3 c.
  • 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).
  • 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.
  • PCC policy and charging control
  • the SMF 206 may initiate the user ID policy association establishment procedure.
  • the request type parameter indicates “existing PDU Session,” then the SMF 206 may provide information 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 category 7 identifier 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.
  • step 5 the SMF 206 continues with the PDU session establishment request procedure initiated in step 1 (see block 226).
  • the procedure 200 ends.
  • the procedure 200 does not consider the user type of the user ID provided by the UE 202 to authenticate the user ID.
  • the number of user IDs that a human user can use may be different from the non-3GPP device limitations and restrictions.
  • a human user can use only one user ID related to the subscription related to the user authentication.
  • FIG. 3 depicts an exemplary 7 procedure 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).
  • a UE 302 e.g., an implementation of the UE 104 and/or UE 202
  • AMF 304 e.g., an implementation of the AMF 204
  • AUSF authentication server function
  • UDM unified data management function
  • a user profile is provided to the UDM 308 and is linked to the subscription information of the UE 302 (see block 310).
  • the user profile is provided by the operator or by the service provider.
  • the operator or service provider may interact with the UDM 308 via an NEF (not depicted in Figure 3).
  • a user e.g., associated with “user identifier-x” initiates registration procedure (see messaging 312).
  • the registration request message transmitted by the UE 302 includes the user identity for registration (e.g.. “user identifier-x”).
  • 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 306 or UDM 308 (see block 314).
  • the authentication and security procedures may be performed according to 3GPP technical specification (TS) 23.502.
  • the AMF 304 requests the UE subscription information retrieval from the UDM 308 by invoking the Nudm SDM Get service (see messaging 316).
  • 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.
  • the UDM 308 returns the subscription information of the UE 302, e.g., in a Nudm SDM Response service message (see messaging 318).
  • the UE subscription information is exchanged according to 3GPP TS 23.502.
  • the UDM 308 also provides the user profile to the AMF 304 in the Nudm SDM Response service message.
  • 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).
  • 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).
  • 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.
  • 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.
  • 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 system to provide necessary operator services and third-party services to the user.
  • 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.
  • 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.
  • a network e.g., a 3GPP system which may implement, or be implemented by, the wireless communication system 100
  • 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.
  • 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
  • a UDM 408 e.g., an implementation of a NF in the CN 106
  • AF/AS target application function
  • AS application server
  • 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.
  • the UDM 408 may comprise an authentication credential repository' function (ARPF) for generating and storing authentication credentials.
  • ARPF authentication credential repository' function
  • 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:
  • the UE 402 sends a NAS message or an N1 transport message to the SEAF 404 (see messaging 412).
  • the NAS message or N1 transport message may be a registration request message, a mobility registration update message, 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.
  • SUCI subscription concealed identifier
  • 5G-GUTI 5G global unique temporary identifier
  • 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.
  • the procedure 400 supports two different options for the UE 402 to provide the user ID to the network.
  • the UE 402 provides the user ID at step 1 in the NAS message or N1 transport message.
  • 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.
  • 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.
  • the Nausf UEAuthentication Authenticate request message contains the serving network (SN) name and either the SUCI or a SUPI.
  • 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.
  • the AUSF 406 may check that the requesting SEAF 404 in the serving network (e.g., identified by 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.
  • the serving network e.g., identified by the 3gpp-Sbi-Originating-Network-Id header specified in 3GPP TS 29.500
  • the AUSF 406 may check a local configuration to confirm the SEAF 404.
  • the AUSF 406 may invoke the Nudm UEAuthentication service by sending a Nudm UEAuthentication Get request message to the UDM 408 (see messaging 416).
  • 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).
  • 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.
  • SIDF subscriber de-concealing function
  • the SIDF de-conceals the SUCI to gain the SUPI before the UDM 408 can process the request (see block 418).
  • 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).
  • 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.
  • 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).
  • 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:
  • #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) or entity 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).
  • #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).
  • 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
  • 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).
  • #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).
  • 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.
  • #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).
  • 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
  • #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 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).
  • User ID-n i.e., n-th user ID
  • allowed service IDs or names or types authorized AF/AS IDs to consume the user ID, authentication results and credentials
  • 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
  • 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.
  • 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.
  • a respective user ID may be in any of the following formats:
  • 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.
  • MNC mobile network code
  • MCC mobile country’ code
  • User ID format 2 useridcode. privacy protected ID/pseudonymousid/anonymousid gc. mnc ⁇ MNC>. mcc ⁇ MC C >.3 gppnetwork. org" .
  • 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".
  • NAI network access identifier
  • NAI format uses the syntax: usemame@realm, e.g., to uniquely identify a user.
  • the UDM 408 sends a Nudm UEAuthentication Get response message to the AUSF 406 (see messaging 420).
  • the AUSF 406 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).
  • 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.
  • 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).
  • the AUSF 406 sends to the SEAF 404 aNausf_UEAuthentication_Authenticate response message (see messaging 424).
  • the Nausf UEAuthentication Authenticate response message may include a result indication (i.e., as ‘success’), and an anchor key (i.e., KSEAF).
  • the Nausf UEAuthentication Authenticate response message may further include the indication that user-specific authentication is required.
  • 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.
  • the SEAF 404 (or AMF) may fetch the user authentication requirements as part of the subscription data in any Nudm service operation message.
  • the SEAF 404 may request the UE subscription information retrieval from the UDM 408, if not already received (e.g., from a source AMF).
  • 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).
  • 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).
  • 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.
  • 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).
  • 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.
  • the SEAF 404 (or AMF) considers user authentication as successful.
  • the AUSF 406 sends to the UDM 408 the user authentication request that includes the user ID (see messaging 432).
  • 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).
  • 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.
  • AAA-S authentication, authorization, and accounting server
  • 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.
  • the AF/AS 410 or AAA-S
  • AAA-S authentication and authorization data/attributes
  • 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.
  • the UE 402 may send a user service access request message to the AF/AS 410 with the user ID and an access token (see messaging 438).
  • 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).
  • 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.
  • OAuth open authorization
  • 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.
  • a network e.g., a 3GPP system which may implement, or be implemented by, the wireless communication system 100
  • FIGS 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).
  • a UE 502 e.g., an implementation of the UE 104, the UE 202, the UE 302, and/or the UE 402
  • SEAF 504 e.g., an implementation of the SEAF 404
  • 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 functionality 7 via the AMF.
  • the UDM 508 may comprise an ARPF for generating and storing authentication credentials.
  • 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:
  • 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.
  • 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.
  • the user type parameter may indicate any of a human user, a non-3GPP device, an entity, or an application.
  • 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 UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate request message to the AUSF 506 whenever the SEAF 504 determines to initiate an authentication.
  • the Nausf UEAuthentication Authenticate request message contains the SN name and either the SUCI or a SUPI. as descnbed above.
  • 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.
  • 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.
  • the AUSF 506 may invoke the Nudm UEAuthentication service by sending a Nudm UEAuthentication Get request message to the UDM 508 (see messaging 516).
  • 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.
  • 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).
  • SIDF subscription identifier de-concealing function
  • 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).
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • the UE 502 may send a user service access request message to the AF/AS 510 yvith the user ID and an access token (see messaging 528).
  • 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).
  • 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.
  • OAuth open authorization
  • 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.
  • 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.
  • AAAMA anchor function AnF
  • 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).
  • 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:
  • 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).
  • 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.
  • 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.
  • the UDM 608 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
  • the UDM 608 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).
  • 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
  • the UDM 608 also includes the RID of the UE 602 in the Nudm UEAuthentication Get response message (see messaging 616).
  • 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.
  • 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.
  • A- KID AKMA key ID
  • 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.
  • the A-KID is in NAI format, i.e., having the form “usemame@realm.”
  • 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.
  • KDF key derivation function
  • 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).
  • 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.
  • the AAnF 610 stores the latest information sent by the AUSF 606.
  • the AUSF 606 When reauthentication runs, the AUSF 606 generates a new 7 A-KID and a new 7 KAKMA, and sends the newly generated A-KID and KAK A to the AAnF 610.
  • 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.
  • the AAnF 610 sends the response to the AUSF 606, e.g., using a
  • 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).
  • 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.
  • 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.
  • 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...
  • 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
  • a UDM 710 e g., an implementation of the UDM 408, the UDM 508, and/or the UDM 608.
  • 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.
  • NEF network exposure function
  • the UDM 710 may be substituted with an operator ID management function or similar service.
  • 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:
  • 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.
  • 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).
  • the user ID may have the NAI format described above.
  • 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.
  • 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.
  • the AF ID may consist of the fully qualified domain name (FQDN) of the AKMA AF 708 and the Ua.
  • FQDN fully qualified domain name
  • yvhich parameter identifies the security protocol that the AKMA AF 708 will use with the UE 702.
  • 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.
  • URI uniform resource identifier
  • 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.
  • 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.
  • the AAnF 706 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.
  • the AAnF 706 sends a request to the AKMA AF 708, and upon confirming the presence of the UE-specific KAKMA identified by the A-KID.
  • Nudm 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 user authentication and authorization data is required (i.e., to fetch user authentication and authorization data/ attributes from the UDM 710).
  • 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).
  • 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.
  • the user authentication and authorization data/attributes may be stored (i.e., at the UDM 710) in a user identity profile.
  • 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).
  • 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.
  • 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.
  • the AAnF 706 finds that roaming is not allowed, it shall respond the AKMA AF 708 containing a failure indication that 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.
  • 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.
  • 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).
  • a 3GPP network e.g., a 5GC
  • N3AN non-3GPP access network
  • 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 below 7 with reference to Figures 9A-9D).
  • FIGS 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..
  • 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
  • UNAN untru
  • 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).
  • step lathe UE 802 connects to the UNAN 804 and acquires an IP address (see block 812).
  • 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).
  • 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 messaging 816).
  • IPsec internet protocol security
  • IKE internet key exchange
  • RRC request-for-comment
  • 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).
  • EAP extensible authentication protocol
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 AUTH request in step 5.
  • the UE 802 may ignore an EAP identity request, if received, or may respond with the SUCI it sent in the registration request.
  • 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.
  • UL uplink
  • the user ID can be ‘device identifier in NAI format’ and ‘User Type’ is set as non-3GPP devices or device.
  • 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).
  • 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.
  • the UE 802 connects to 5GC via W- 5GAN, which has the W-AGF function that provides connectivity to the 5GC viaN2 and N3 reference points.
  • 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.
  • the N3IWF 806 selects an AMF 808 (see block 824).
  • 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).
  • 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, then the 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.
  • 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.
  • 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.
  • SMC NAS security mode command
  • 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.
  • the AMF 808 may send a key request to the AUSF 810, and the AUSF 810 may initiate an authentication procedure.
  • 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.
  • 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.
  • KA F AMF key
  • 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.
  • 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.
  • the N3IWF 806 forwards the NAS SMC message to the UE 802 within an EAP-Request/5G-NAS packet (see messaging 832).
  • 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).
  • 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).
  • the AMF 808 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.
  • KNSIWF N3IWF key
  • the AMF 808 includes the KNSIWF in the NGAP initial context setup request sent to the N3IWF 806 (see messaging 838).
  • 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.
  • 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.
  • the N3IWF 806 sends an NGAP initial context setup response message to the AMF 808 (see messaging 844).
  • 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 806 is 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.
  • 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).
  • 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.
  • the AMF 808 may trigger a UE policy update procedure and update the UE policy (see message exchange 852).
  • the AMF 808 sends a registration reject message to the N3IWF 806 (see messaging 854).
  • the registration reject message is ciphered and integrity protected.
  • the N3IWF 806 forwards the registration reject message to the UE 802 (see messaging 856).
  • 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.
  • the UE 802 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.
  • FIGS 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 UE 104, 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).
  • a UE 902 e.g., an implementation
  • 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).
  • TNAP 906 communicates with one or more user devices (including the UE 902) via a layer-2 (L2) interface.
  • 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.
  • the TNAP 906 communicates with the TNGF 908 via an authentication, authorization, and accounting (AAA) interface.
  • AAA authentication, authorization, and accounting
  • the TNGF 908 communicates with the AMF 910 via an N2 interface.
  • 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").
  • trusted connectivity e.g., "5G connectivity”
  • step 1 an L2 connection is established between the UE 902 and the TNAP 906 (see messaging 914).
  • this step corresponds to an 802. 11 association process.
  • PPP point-to-point protocol
  • this step corresponds to a PPP link control protocol (LCP) negotiation process.
  • this step may not be required.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • the user ID may be ‘device identifier in NAI format' and the user type parameter may be set as non-3GPP device.
  • 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).
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the UE 902 and AUSF 912 perform an authentication and key agreement procedure via TNGF 908 and AMF 910 (see message exchange 934).
  • the authentication packets are encapsulated within NAS authentication messages and the NAS authentication messages are encapsulated within EAP/5G-NAS packets.
  • 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.
  • 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.
  • the AMF 910 sends a NAS SMC request towards the UE 902 in order to activate NAS security (see messaging 940).
  • the AMF 910 also encapsulates the EAP-Success packet received from the AUSF 912 within the NAS SMC request message.
  • the TNGF 908 forwards the NAS SMC request message to the UE 902 within an EAP-Req/5G-NAS packet (see messaging 942).
  • 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).
  • the TNGF 908 forwards the NAS SMC complete message to the AMF 910 within an N2 message (see messaging 946).
  • the AMF 910 sends an N2 initial context setup request message to the TNGF 908 that includes the KTNGF) (see messaging 948).
  • the UE 902 has independently derived the same KTNGF.
  • 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).
  • TNGF contact information which includes the IP address of the TNGF 908
  • 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).
  • KTNAP TNAP key
  • the KTNAP is not included in the L2 message sent from the TNAP 906 to the UE 902.
  • the UE 902 has independently derived the same KTNGF.
  • 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.
  • the TNAP key and IPsec key are derived using a KDF (i.e., a cryptographic hash function).
  • the TNGF 908 sends the TNAP key and an EAP-Success packet to the TNAP 906 (see messaging 954).
  • 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.
  • 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.
  • 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 over the air. All messages between UE 902 and TNAP 906 are encrypted and integrity protected from this step onwards.
  • the KTNAP is used to derive security keys for encryption protection over the L2 connection between UE 902 and TNAP 906.
  • the UE 902 receives an IP configuration from the TNAN 904, e.g., with dynamic host configuration protocol (DHCP) (see messaging 960).
  • DHCP dynamic host configuration protocol
  • 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).
  • IKE INIT exchange uses the IP address of TNGF 908 that the UE 902 received during the EAP-5G signaling in step 9b.
  • 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 identity 7 as 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.
  • the TNGF 908 completes the mutual authentication and IKE AUTH exchange (see messaging 966).
  • 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.
  • the TNGF 908 responds to AMF 910 with an N2 initial context setup response message (see messaging 968).
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • the TNGF 908 transmits a PDU session establishment accept message to the UE 902 completing the PDU session establishment (see messaging 982).
  • 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).
  • the AMF 910 may trigger a UE policy update procedure and update the UE policy (see message exchange 986).
  • the AMF 910 sends a registration reject message to the TNGF 908 (see messaging 988).
  • the registration reject message is ciphered and integrity protected.
  • the TNGF 908 forwards the registration reject message to the UE 902 (see messaging 990).
  • 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.
  • the UE 902 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 user authentication 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.
  • 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).
  • NSSAAF undertakes any AAA protocol interworking with the AAA-S. Multiple EAP methods are possible for network slice-specific authentication and authorization (NSSAA).
  • AAA-S belongs to a third party' the NSSAAF contacts the AAA-S via an AAA proxy (AAA-P).
  • AAA-P AAA proxy
  • the NSSAAF and the AAA-P may be co-located.
  • a privacy -protection capable EAP method is recommended, if privacy protection is required.
  • FIGS 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.
  • SEAF e.g., an implementation of the AMF 204, the AMF 304, the AMF 604, the AMF 808, and/or the A
  • 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.
  • 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.
  • S-NSSAI single network slice selection assistance information
  • the AMF 1004 may determine if a user authentication needs to be performed for the UE 1002 in addition to the slice authentication.
  • 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.
  • 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.
  • 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.
  • NSSAI network slice selection assistance information
  • 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).
  • a NAS message e.g., NAS mobility management (MM) transport message including the S-NSSAI
  • EAP ID user ID for EAP authentication
  • the NAS message includes an indication that user authentication (i.e., user-specific authentication) is needed and a user ID request indication.
  • 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).
  • a NAS message e.g., NAS MM transport message
  • the user ID may have the NAI format described above.
  • the AMF 1004 sends an authentication request message to the NSSAAF 1006, such as an Nnssaaf_NSSAA_Authenticate request service message (see messaging 1020).
  • the authentication request message includes the EAP ID, the user ID, a UE ID (e g., GPSI), and the S-NSSAI.
  • 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 the user authentication and authorization data/attributes or user authentication result if available (see messaging 1022).
  • a user data request message such as an Nudm DM user data request message
  • the UDM/UDR 1008 to fetch the user authentication and authorization data/attributes or user authentication result if available (see messaging 1022).
  • the user data request message includes the S-NSSAI and the user ID.
  • 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).
  • 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.
  • 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 party 7 and 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.
  • 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.
  • 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.
  • 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).
  • EAP messages are exchanged between the AAA-S 1012 and the UE 1002.
  • One or more than one iterations of these steps may occur.
  • 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 protocol message with the EAP message also includes the GPSI, the S-NSSAI (or ENSI), a user authentication message, and the user ID.
  • the AAA-P 1010 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.
  • 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).
  • 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).
  • 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.
  • 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).
  • 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).
  • 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.
  • 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).
  • 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).
  • the AMF 1004 may initiate a UE configuration update procedure, e.g., for each access ty pe.
  • 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.
  • 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.
  • RRC radio resource control
  • NAS non-access stratum
  • 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 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.
  • IP internet protocol
  • PDU Layer not depicted
  • 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.”
  • 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.
  • 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).
  • QoS quality' of service
  • the RRC layer 1122 manages the addition, modification, and release of carrier aggregation and/or dual connectivity 7 .
  • the RRC layer 1122 also manages the establishment, configuration, maintenance, and release of signaling radio bearers (SRBs) and data radio bearers (DRBs).
  • SRBs signaling radio bearers
  • DRBs data radio bearers
  • 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.
  • the AS layers 1126 and 1128 are between the UE 1106 and the RAN (i.e., RAN node 1108) and carry 7 information over the wireless portion of the network.
  • 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.
  • 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.
  • MAC PDUs also known as transport blocks (TBs)
  • SDUs MAC service data units
  • 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.
  • 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.
  • 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.
  • 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.
  • control data e.g., RRC signaling
  • traffic logical channels which earn user plane data.
  • 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.
  • DL downlink
  • 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.
  • MCS modulation and coding scheme
  • 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.
  • 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”).
  • 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
  • MIMO multiple-input multiple-output
  • FIG. 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.
  • 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.
  • DSP digital signal processor
  • ASIC application-specific integrated circuit
  • 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).
  • the processor 1202 may be configured to operate the memory 1204.
  • 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.
  • the memory 1204 may include volatile or non-volatile memory 7 .
  • 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.
  • 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).
  • 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.
  • 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.
  • the authentication message further comprises the user ID.
  • 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.
  • 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.
  • 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.
  • the user authentication capability is comprised in a security’ capabilities IE.
  • the user authentication is performed over a user plane in a mobile communication network.
  • 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.
  • 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.
  • the controller 1206 may utilize an operating system (OS) such as iOS®, ANDROID®, WINDOWS®, or other operating systems.
  • OS operating system
  • the controller 1206 may be implemented as part of the processor 1202.
  • 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.
  • a receiver chain 1210 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium.
  • the receiver chain 1210 may include one or more antennas for receiving the signal over the air or wireless medium.
  • the receiver chain 1210 may 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.
  • 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.
  • FIG. 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.
  • ALUs arithmetic-logic units
  • 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).
  • 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.
  • a protocol stack e.g., a software stack
  • operations e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading
  • 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).
  • RAM random access memory
  • ROM read-only memory
  • DRAM dynamic RAM
  • SDRAM synchronous dynamic RAM
  • SRAM static RAM
  • FeRAM ferroelectric RAM
  • MRAM magnetic RAM
  • RRAM resistive RAM
  • flash memory phase change memory
  • PCM phase change memory
  • 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.
  • 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.
  • the controller 1302 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 7 1304 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.
  • 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.
  • 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.
  • ALUs arithmetic logic units
  • the memory 1304 may include one or more caches (e.g., memory local to or included in the processor 1300 or other memory 7 , such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc.
  • the memory 7 1304 may reside within or on a processor chipset (e.g., local to the processor 1300). In some other implementations, the memory 7 1304 may reside external to the processor chipset (e.g., remote to the processor 1300).
  • 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 memory 7 or another type of memory 7 .
  • the controller 1302 and/or the processor 1300 may be configured to execute computer-readable instructions stored in the memory 1304 to cause the processor 1300 to perform various functions.
  • 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.
  • 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.
  • the one or more ALUs 1306 may be configured to support various operations in accordance with examples as described herein.
  • the one or more ALUs 1306 may reside within or on a processor chipset (e.g., the processor 1300).
  • 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.
  • 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.
  • logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND)
  • the processor 1300 may support various functions (e g., operations, signaling) of a UE. in accordance with examples as disclosed herein.
  • 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 capability 7 ; perform a primary 7 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.
  • 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.
  • the controller 1302 coupled with the memory 7 1304 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 an indication 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.
  • FIG 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.
  • 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.
  • 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.
  • an intelligent hardware device e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof.
  • 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.
  • the memory 7 1404 may include volatile or non-volatile memory 7 .
  • the memory 7 1404 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.
  • the processor 1402 and the memory 7 1404 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 stored in the memory 1404).
  • the processor 1402 may include multiple processors and the memory 7 1404 may include multiple memories.
  • One or more of the multiple processors may be coupled with one or more of the multiple memories, which may be individually or collectively, configured to perform various functions (e.g., operations, signaling) of the NE 1400 as disclosed herein.
  • 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.
  • 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.
  • the authentication request message may include the user ID and security credentials associated with the user identity profile.
  • the second authentication entity comprises a third-party AAA-S or an AS (or AF).
  • 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.
  • the NE 1400 may comprise a UDM.
  • the authentication request message is received from an AUSF or an NSSAAF.
  • 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.
  • the controller 1406 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems.
  • the controller 1406 may be implemented as part of the processor 1402.
  • 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.
  • a receiver chain 1410 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium.
  • 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.
  • 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.
  • Figure 15 depicts one embodiment of a method 1500 in accordance with aspects of the present disclosure.
  • the operations of the method 1500 may be implemented by a UE as described herein.
  • the UE may execute a set of instructions to control the function elements of the UE to perform the described functions.
  • 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.
  • 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.
  • 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 some implementations, aspects of the operation of step 1506 may be performed by a UE, as described with reference to Figure 12.
  • 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.
  • 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.
  • 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.
  • the RAN may execute a set of instructions to control the function elements of the RAN to perform the described functions.
  • 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.
  • 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.
  • 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. In some implementations, aspects of the operations of step 1606 may be performed by an NE, as described with reference to Figure 14.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Divers aspects de la présente divulgation concernent la transmission (1502) d'un message d'authentification comprenant un type d'utilisateur et une capacité d'authentification d'utilisateur et la réalisation (1504) d'une authentification primaire associée à l'UE. Des aspects de la présente divulgation peuvent concerner la transmission (1506) d'un identifiant d'utilisateur (ID) et la réalisation (1508) d'une authentification d'utilisateur sur la base du type d'utilisateur et de l'ID d'utilisateur. Des aspects de la présente divulgation peuvent concerner l'accès (1510) à un service associé à l'ID d'utilisateur sur la base de l'authentification d'utilisateur.
PCT/IB2025/000264 2024-05-11 2025-05-12 Authentification à l'aide d'un identifiant d'utilisateur Pending WO2025210408A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202463645855P 2024-05-11 2024-05-11
US63/645,855 2024-05-11

Publications (1)

Publication Number Publication Date
WO2025210408A1 true WO2025210408A1 (fr) 2025-10-09

Family

ID=96391533

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2025/000264 Pending WO2025210408A1 (fr) 2024-05-11 2025-05-12 Authentification à l'aide d'un identifiant d'utilisateur

Country Status (1)

Country Link
WO (1) WO2025210408A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220086145A1 (en) * 2019-06-17 2022-03-17 Huawei Technologies Co., Ltd. Secondary Authentication Method And Apparatus
US20220345887A1 (en) * 2019-10-09 2022-10-27 Lenovo (Singapore) Pte. Ltd. Accessing a mobile communication network using a user identifier
EP3994907B1 (fr) * 2019-07-03 2024-02-14 NEC Corporation Procédés de commande pour gestion d'identités d'utilisateurs multiples par ue

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220086145A1 (en) * 2019-06-17 2022-03-17 Huawei Technologies Co., Ltd. Secondary Authentication Method And Apparatus
EP3994907B1 (fr) * 2019-07-03 2024-02-14 NEC Corporation Procédés de commande pour gestion d'identités d'utilisateurs multiples par ue
US20220345887A1 (en) * 2019-10-09 2022-10-27 Lenovo (Singapore) Pte. Ltd. Accessing a mobile communication network using a user identifier

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "ETSI TS 23.502 v16.11.0 rel.16 - Excerpt section 4.2.2.2", 1 January 2022 (2022-01-01), XP093301240, Retrieved from the Internet <URL:https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/16.11.00_60/ts_123502v161100p.pdf?utm_source=chatgpt.com> *
ANONYMOUS: "ETSI TS 23.502 v16.11.0 rel.16 -excerpt References", 1 January 2022 (2022-01-01), XP093301650, Retrieved from the Internet <URL:https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/16.11.00_60/ts_123502v161100p.pdf> *
ANONYMOUS: "ETSI TS 24.501 v17.9.0 rel.17 . excerpt section 9", 1 January 2023 (2023-01-01), XP093301256, Retrieved from the Internet <URL:https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/17.09.00_60/ts_124501v170900p.pdf?utm_source=chatgpt.com> *
ANONYMOUS: "ETSI TS 33.501 v15.2.0- Excerpt secion 13.3 and 13.4", 1 October 2018 (2018-10-01), XP093301603, Retrieved from the Internet <URL:https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/15.02.00_60/ts_133501v150200p.pdf?utm_source=chatgpt.com> *

Similar Documents

Publication Publication Date Title
CN110235423B (zh) 对用户设备的辅认证
US10939294B2 (en) Network access identifier including an identifier for a cellular access network node
US20240298174A1 (en) Method and systems for authenticating ue for accessing non-3gpp service
KR101961301B1 (ko) 통합된 스몰 셀 및 wi-fi 네트워크를 위한 통합 인증
JP2020505845A (ja) 緊急アクセス中のパラメータ交換のための方法およびデバイス
CN119014024A (zh) 在与wlan接入网络的第一认证之后向移动网络注册
US20250133399A1 (en) Application programming interface (api) access management in wireless systems
US20250167994A1 (en) Application programming interface (api) access management in wireless systems
WO2024160413A1 (fr) Réauthentification pour mobilité d&#39;équipement utilisateur dans un réseau de communication sans fil
WO2024235491A1 (fr) Enregistrement d&#39;équipement utilisateur
WO2025210408A1 (fr) Authentification à l&#39;aide d&#39;un identifiant d&#39;utilisateur
US20250350939A1 (en) Authentication and connection establishment for reduced capability devices
US20250233728A1 (en) Authenticated encryption with associated data (aead) modes for non-access stratum (nas) and access stratum (as) security
US20250365150A1 (en) Attribute-based credentials for resource access
US20250344265A1 (en) Apparatus and Method for Establishing a Direct Communication Connection to a Network Via an Access Point of a Different Network Type
US20250365576A1 (en) Attribute-based credentials for resource access
WO2025154046A1 (fr) Techniques de protection de la confidentialité à travers des domaines de sécurité
WO2025123706A1 (fr) Procédés et appareils pour prendre en charge de multiples accès d&#39;un ue à un réseau central
WO2025134096A1 (fr) Application de protocoles de sécurité sur la base de capacités d&#39;équipement utilisateur (ue) dans des systèmes de communication sans fil
WO2025134103A1 (fr) Protection d&#39;identifiant d&#39;abonné dans un réseau hébergé
WO2024208444A1 (fr) Connexions sécurisées dans un réseau de communication sans fil
WO2025229235A1 (fr) Appareils et procédés de communication sécurisée dans un système de communication sans fil
WO2025229236A1 (fr) Appareils et procédés pour une communication sécurisée dans un système de communication sans fil
WO2024069502A1 (fr) Fourniture de clés de sécurité à un réseau de desserte d&#39;un équipement utilisateur
WO2025169174A1 (fr) Appareil et procédé d&#39;attribution d&#39;une identité temporaire à un dispositif à utiliser dans un réseau sans fil

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25738188

Country of ref document: EP

Kind code of ref document: A1