Method and apparatus for user authentication in wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Specifically, the present disclosure provides a method and an apparatus for user authentication in a wireless communication system (or mobile communication system).

Description

METHOD AND APPARATUS FOR USER AUTHENTICATION IN WIRELESS COMMUNICATION SYSTEM

[0001] The disclosure relates to a wireless communication system (or a mobile communication system). Specifically, the disclosure relates to an apparatus, a method and a system for user authentication in wireless communication system.

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz (THz) bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] Recently, there are needs to enhance user authentication procedure by a user identifier for a user equipment (UE) registered to an operator service.

[0009] Aspects of the disclosure are to address at least the above-mentioned problems and / or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the disclosure is to provide a communication method and system for converging a fifth generation (5G) communication system for supporting higher data rates beyond a fourth generation (4G).

[0010] In accordance with an aspect of the disclosure, a method performed by a network entity is provided. The method comprises: receiving, from a unified data management (UDM) entity, a first message for requesting an authentication for a user equipment (UE), the first message comprising a user identifier (ID) and a subscription permanent identifier (SUPI) linked to the user ID; and performing the authentication for the UE based on the user ID and the SUPI.

[0011] In accordance with another aspect of the disclosure, a method performed by a unified data management (UDM) entity is provided. The method comprises: receiving, from a network exposure function (NEF) entity, a first message for requesting an authentication for a user equipment (UE), the first message comprising a user identifier (ID) and a subscription permanent identifier (SUPI) linked to the user ID; and transmitting, to an access and mobility management function (AMF) entity or a session management function (SMF) entity, a second message for requesting the authentication, wherein the SUPI is obtained from a user profile storage function entity.

[0012] In accordance with another aspect of the disclosure, a network entity is provided. The network entity comprises: a transceiver; and a controller coupled with the transceiver and configured to: receive, from a unified data management (UDM) entity, a first message for requesting an authentication for a user equipment (UE), the first message comprising a user identifier (ID) and a subscription permanent identifier (SUPI) linked to the user ID, and perform the authentication for the UE based on the user ID and the SUPI.

[0013] In accordance with another aspect of the disclosure, a unified data management (UDM) entity is provided. The UDM entity comprises: a transceiver; and a controller coupled with the transceiver and configured to: receive, from a network exposure function (NEF) entity, a first message for requesting an authentication for a user equipment (UE), the first message comprising a user identifier (ID) and a subscription permanent identifier (SUPI) linked to the user ID, and transmit, to a network entity, a second message for requesting the authentication, wherein the SUPI is obtained from a user profile storage function entity.

[0014] The above and other aspects, features, and advantages of certain embodiments of the disclosure will be more apparent from the following description taken in conjunction with the accompanying drawings, in which:

[0015] FIG. 1 illustrates an example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0016] FIG. 2 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0017] FIG. 3 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0018] FIG. 4a illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0019] FIG. 4b illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0020] FIG. 5 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0021] FIG. 6a illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0022] FIG. 6b illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0023] FIG. 7 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0024] FIG. 8 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0025] FIG. 9 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0026] FIG. 10 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0027] FIG. 11 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0028] FIG. 12 is a block diagram of a terminal according to an embodiment of the disclosure.

[0029] FIG. 13 is a block diagram of a base station according to an embodiment of the disclosure.

[0030] FIG. 14 is a block diagram of a network entity (or, a network function) according to an embodiment of the disclosure.

[0031] Throughout the drawings, like reference numerals will be understood to refer to like parts, components, and structures.

[0032] The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the disclosure as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

[0033] The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of various embodiments of the disclosure is provided for illustration purpose only and not for the purpose of limiting the disclosure as defined by the appended claims and their equivalents.

[0034] It is to be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more of such surfaces.

[0035] By the term "substantially" it is meant that the recited characteristic, parameter, or value need not be achieved exactly, but that deviations or variations, including for example, tolerances, measurement error, measurement accuracy limitations and other factors known to those of skill in the art, may occur in amounts that do not preclude the effect the characteristic was intended to provide.

[0036] It is known to those skilled in the art that blocks of a flowchart (or sequence diagram) and a combination of flowcharts may be represented and executed by computer program instructions. These computer program instructions may be loaded on a processor of a general purpose computer, special purpose computer, or programmable data processing equipment. When the loaded program instructions are executed by the processor, they create a means for carrying out functions described in the flowchart. Because the computer program instructions may be stored in a computer readable memory that is usable in a specialized computer or a programmable data processing equipment, it is also possible to create articles of manufacture that carry out functions described in the flowchart. Because the computer program instructions may be loaded on a computer or a programmable data processing equipment, when executed as processes, they may carry out operations of functions described in the flowchart.

[0037] A block of a flowchart may correspond to a module, a segment, or a code containing one or more executable instructions implementing one or more logical functions, or may correspond to a part thereof. In some cases, functions described by blocks may be executed in an order different from the listed order. For example, two blocks listed in sequence may be executed at the same time or executed in reverse order.

[0038] In this description, the words "unit", "module" or the like may refer to a software component or hardware component, such as, for example, a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) capable of carrying out a function or an operation. However, a "unit", or the like, is not limited to hardware or software. A unit, or the like, may be configured so as to reside in an addressable storage medium or to drive one or more processors. Units, or the like, may refer to software components, object-oriented software components, class components, task components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays or variables. A function provided by a component and unit may be a combination of smaller components and units, and may be combined with others to compose larger components and units. Components and units may be configured to drive a device or one or more processors in a secure multimedia card.

[0039] Prior to the detailed description, terms or definitions necessary to understand the disclosure are described. However, these terms should be construed in a non-limiting way.

[0040] The "base station (BS)" is an entity communicating with a user equipment (UE) and may be referred to as BS, base transceiver station (BTS), node B (NB), evolved NB (eNB), access point (AP), 5G NB (5GNB), or gNB.

[0041] The "UE" is an entity communicating with a BS and may be referred to as UE, device, mobile station (MS), mobile equipment (ME), or terminal.

[0042] FIG. 1 illustrates an example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0043] An authentication service is a service that can allow users to be able to log into applications and websites, without registering for or joining each service. The user registers once with the Authentication service provider, and when that user want to use some other application service, that application service can request the Authentication Service provider to authorize the already registered user.

[0044] User thus has to authorize itself with the Authentication service provider only, and the application service is notified of the success or failure of the user authorization.

[0045] Figure 1 depicts a typical call flow involving such an authentication service provider (105).

[0046] A User / UE first registers itself with an Authentication service (110).

[0047] User / UE may provide its credentials like Name Mobile Phone Number, Date of Birth, etc. to the Authentication Service Provider (e.g., PASS-server) (115).

[0048] Authentication service provider then authorizes the use of a User ID and links the User ID to the particular UE (or to the particular UE-APP of the Authentication service provider installed in the UE) (120, 125, 130).

[0049] Now if the UE / user tries to access a 3rdparty service, and the 3rdparty service has relationship with the Authentication service provider 3rdparty service can prompt the user to perform authentication with the Authentication Service provider (135, 140).

[0050] User then provides it's user identity to the 3rdparty service (145).

[0051] 3rdparty service then asks the Authentication service provider in Step. 2 to verify if the particular user identified by the User ID is an actual user and registered with the Authentication service provider (150, 155).

[0052] Authentication service provider may need to prompt again for user authentication. It does so by sending a notification to the application registered with the User ID, to perform authentication for the user (160).

[0053] User is prompted in Step 5 to provide bio-information, or password etc. (165).

[0054] Upon confirming the authentication, the application notifies the Authentication service provider regarding the result of the authentication (170).

[0055] Authentications service provider then provides this result to the 3rd party service, which upon confirming the authenticity of the User, grants the particular User the access to the resource provided by the 3rd party service (175, 180).

[0056] Entities / terms used in the disclosure are described below.

[0057] UAAF (User Authentication and Authorization Function) is a function used for performing authentication related function for user authentication. It can relay message between a user and a AAA-server in order to authenticate the user.

[0058] Functionality performed by UAAF as described in the disclosure can be performed partially or wholly by NSSAAF (Network Slice Specific Authentication and Authorization Function) or AUSF (Authentication Server Function).

[0059] Operator’s User Authentication service: An operator can provide a user authentication service, by which a user can prove to 3rd parties that they are an actual human user. User may also proof to the 3rd parties that they are the user for the User ID(operator’s User ID) which is linked to the 3rd party service.

[0060] AAA-User server is an authentication server that holds credentials for authenticating a User ID.

[0061] 3rd party APP is an application which wants to verify a human user which is using its services. For example, if a person is using a bank application, after using bank User ID and bank password, bank wants to have a 2ndfactor authentication to verify the user using bank services.

[0062] Bank may have stored the operator's User ID linked to bank user id, and when the particular bank user tries to access his account, bank application will ask the operator to perform the user authentication for the operator's User ID corresponding to the bank User ID.

[0063] An Operator User ID APP for User Authentication is an application on which a user can register itself in order to avail operator's User ID authentication service. This application may also acts as an AF, in order to trigger authentication for a particular User ID in the 5G system. Some or all of the functionality as described NEF (Network Exposure Function) in the current disclosure may be performed by this Operator User ID APP.

[0064] User Profile Storage or User profile Storage Function can store information related the User ID.

[0065] The information may include, but not limited to:

[0066] * User ID

[0067] * SUPI (Subscription Permanent Identifier) / GPSI (generic public subscription identifier)(s) / UE / device identifier(s) linked with the User ID

[0068] * AAA-User server address

[0069] * Current active (or last active) UE for a User ID

[0070] Detailed scenarios will be described below.

[0071] This service can be used in scenarios to Provide Second factor authentication service to the third parties.

[0072] * User connects to some Application (e.g. BANK) which requires 2ndfactor authentication for User to login

[0073] ** Traditionally OTP (one time password) based solutions are used that are susceptible to phishing attacks

[0074] * Instead, if the already secure NAS (non-access stratum) signaling can be used to verify whether a particular User is using the device, Bank application can ask the Operator to authenticate a particular Userover already established NAS signaling between the User's UE and the operator

[0075] Overall procedure will be described below with various embodiments.

[0076] Basic procedure for authentication of User ID as requested by a 3rdparty is as follows including the user registering for user authentication service is as follows. It is assumed that the user owns a UE (or USIM) which has a subscription with the corresponding operator.

[0077] FIG. 2 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0078] OPTION 1

[0079] 1. A User of a UE registers for User Authentication service (205). It is provided with User ID and credentials. The corresponding network configurations are changed and a linking between User and UE subscription is stored in the operator entities.

[0080] 2a. User is using 3rdparty application which requires 2ndfactor authentication (210).

[0081] 2b. In order to verify the 3rdparty / provide a second factor to the 3rdparty, for the corresponding user identified by the User ID (215).

[0082] 3. 3rdparty request the Operator (via NEF) to start user authentication and verify whether an actual human user is using the particular User ID or not (220).

[0083] 4. Operator entities perform user authentication for the received User ID (225).

[0084] 5. Based on the result of authentication, Operator notifies whether the user authentication for the User ID was successful or not (230).

[0085] FIG. 3 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0086] OPTION 2

[0087] OPTION 2 is similar to OPTION 1 in Figure 2, only that 3rdparty, instead of communicating via NEF using NEF APIs, will communicate via application interface provided by a special Operator's User ID APP (320, 330). Operator's User ID APP controls an AF, which communicates with 5G entities in order to perform User Authentication.

[0088] A User can use this User ID provided by the operator and the corresponding user authentication service for following cases:

[0089] 1. When User uses some other application service, suppose that application service wants to link application service authentication (or access to that Application service) with User authentication service provided by the operator, so that User can logon to that Application service just using the authentication from the operator.

[0090] 2. When User uses some other Application service, and User wants to use the User Authentication service provided by the operator as 2ndfactor authentication for logging in to that particular application service.

[0091] Hereinafter, method of registration of a User for User ID authentication service is described.

[0092] Following steps can be followed as an expansion to Step 1 of the figure 2 (205) or figure 3 (305).

[0093] 1. User uses Operator User ID APP (which also manages an AF (application function)), application registers the User ID for a user and binds it to the UE's GPSI / SUPI in the following way

[0094] 1-a. User provides its MSISDN (Mobile Station Integrated System Digital Network) to the operator app

[0095] 1-b. AF (owned by this operator app) needs to ensure that MSISDN provided by the user is correct. For this it can verify via:

[0096] 1-b-i. OTP way

[0097] 1-b-i-1. It sends a message to the User MSISDN

[0098] 1-b-i-2. User receives it on its mobile and provides it to the APP

[0099] 1-b-i-3. APP verifies and then links the User ID with the MSISDN

[0100] 1-b-i-3-a. It invokes UDM service, Provides UDM with MSISSDN and User ID

[0101] 1-b-i-3-b. UDM stores the binding between User ID and MSISDN (GPSI)

[0102] 1-b-ii. NAS linking

[0103] 1-b-ii-1. After receiving the MSISDN, Operator AF provides UE an (User ID, authentication token)

[0104] 1-b-ii-2. UE passes the User ID and Authentication token to NAS

[0105] 1-b-ii-3. AUSF finds that token, sends AF the (User ID, token and MSISDN) and checks with the AF whether it is valid or not. AF validates that the token is for the one associated with the MSISDN and sends response.

[0106] 1-b-ii-4. If AF response is successful, AUSF makes the binding request to UDM and links the User ID with the MSISDN subscription.

[0107] Hereinafter, overall Authentication procedure will be described in detail with various embodiments.

[0108] The following options specify the details of the authentication procedure performed by the 5G Core entities for a User ID. Some or all steps of the Authentication procedure described are also valid when some internal entity itself requests for User Authentication (rather than being triggered by an AF or NEF). That corresponding entity may be replaced by NEF as described in the below procedures.The options discussed below specifies the details of the mechanism that can be used by the 5G system in order to verify and authenticate a user identified by a particular User ID. In some implementations User ID maybe in the form of GPSI, or GPSI is used as a substitute of User ID in the below procedures.

[0109] AMF (Access and mobility management function) invoked to start User-Authentication

[0110] FIG. 4a and FIG. 4b illustrate other examples of a user authentication procedure in accordance with an embodiment of the disclosure.

[0111] OPTION 1 UDM invoking AMF / SMF (Session management function)

[0112] Following procedure (as in Figure 4a and Figure 4b) describes expansion of the Steps 3 to Steps 5 of Figure 2 (220, 225, 230) and 3 (320, 325, 330), that is how authentication for a User ID will be carried out in the 5G system.

[0113] Only some of the steps described below may be performed, and also in an order different from the described order.

[0114] A1. 3rdparty APP to NEF (or AF or some other Network entity like AUSF)

[0115] A 3rdparty application request to NEF for user authentication for a user denoted by User ID (405, 475). The message may also include UE IP address or User ID itself maybe in the form of UE IP address.

[0116] Optionally if the operator controlled AF is used, that AF may itself store the mapping of User ID to a corresponding SUPI / GPSI, and it can provide that to UDM also in Step 1.NEF may also find the SUPI / GPSI for the UE IP address provided in the previous message. The NEF may determine the dedicate DNN / S-SNSSAI used for User authentication or it may determine based on identity of the AF requesting authentication.

[0117] 1. NEF (or AF or some other Network entity like AUSF) to UDM (410, 480):

[0118] * User ID

[0119] * (identity of the requesting AF / application function)

[0120] * SUPI / GPSI

[0121] * DNN / S-NSSAI

[0122] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0123] NEF sends UDM a message to perform Authentication for the User ID. It may optionally send a special indication "to perform user authentication" to UDM in order to trigger authentication for the particular User ID.

[0124] 2. UDM operation

[0125] UDM checks for the associated UE subscription for the provided User ID in the AF request (415, 485). It checks if the associated UE is currently registered to the network or not.

[0126] UDM may additionally store if there is any other active User ID on the UE associated with the User ID received from NEF in Step 2 and if any other User ID is currently active on the UE, UDM may send a rejection response to NEF including cause "User not active on the UE"

[0127] UDM may also check whether the AF / application function (based on its identity, if provided) is allowed to request for user authentication for the User ID or not.

[0128] UDM may also check the current registered network (PLMN (public land mobile network) / SNPN(standalone non-public network)) and / or location of the UE. Based on the operator policies and / or UE subscription, UDM may determine whether the UE (or the User determined by User ID) is allowed to use User ID or not and whether network can authenticate the User (determined by User ID) based on its current location and / or current registered network.

[0129] If UDM cannot find any UE subscription linked to the User ID it may send the rejection response to the NEF right way including the cause "no UE linked to the User ID".

[0130] If the UDM find a UE subscription linked to the User ID, but the UE is not registered to the network or a specific PDU Session is not registered / established with the network, it may send the rejection response to the NEF right away including the cause "UE / User ID not registered to the network". The specific PDU Session may be a dedicated PDU Session through which User Authentication can be performed. The specific PDU Session may be for a dedicated DNN(data network name) / S-NSSAI(single network slice selection assistance information) for which User authentication is performed. This dedicated DNN / S-NSSAI may be provided by the NEF or may be determined by UDM based on configuration.

[0131] If an internal User ID is to be used, UDM may provide the internal User ID (in Step.3) corresponding to the User ID received from the NEF in Step 1.

[0132] For e.g. when UDM receives the request from NEF, it may check if the UE (associated with the User ID, or UE ID) has established a PDU session to a dedicated DNN / S_NSSAI used for user authentication or not.

[0133] UDM to a network entity (e.g., AMF or SMF) (420, 490):

[0134] * AAA-user server address

[0135] * SUPI / GPSI

[0136] * User ID

[0137] *DNN / S-NSSAI

[0138] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0139] For the NEF's request in Step 1, UDM sends message to a network entity (e.g. AMF or SMF) that is serving the UE (e.g. AMF serving the UE) or specific PDU Session (e.g. SMF serving the PDU Session to a specific DNN / S-NSSAI), a message to start the User authentication for the User ID including one or more of the above parameters.

[0140] SUPI (or GPSI) is provided in order to denote the particular UE, so that user authentication for the User ID happens for the UE identified by SUPI (or GPSI).

[0141] SUPI corresponds to the UE subscription which is linked to the User ID.

[0142] GPSI may also be sent in addition to or as a replacement to SUPI.

[0143] AAA-user server address may be stored in the UDM for the corresponding User ID provided by the NEF to UDM in Step 1. This AAA-server address is stored so that UDM can inform the corresponding network entity for user authentication, which server to contact to authorize the particular User ID.

[0144] The AAA-server corresponding to the User ID, will store the credentials required to authenticate a particular User ID.

[0145] 4. AMF / SMF upon receiving the request from UDM, will try to find the UE corresponding to the SUPI provided in the request:

[0146] 4a. AMF / SMF to UE NAS-USER-Auth DL (425, 495)

[0147] 4a-i. Request for EAP(Extensible Authentication Protocol) ID

[0148] 4a-ii. User ID

[0149] AMF / SMF may send a message to UE, in order to request UE for authentication message for the provided User ID.

[0150] 4b. UE to AMF / SMF: NAS User-Auth UL (430, 4100)

[0151] 4b-i. User ID

[0152] 4b-ii. EAP ID response / EAP-authentication message

[0153] User may be prompted to provide EAP ID corresponding to the User ID. Alternatively, this step may be skipped by the AMF / SMF, and AMF / SMF may directly contact UAAF with a message containing User ID in order to request UAAF to start authentication for the User ID.

[0154] 5. AMF / SMF to UAAF (435, 4105)

[0155] * AAA-User server address

[0156] * Authentication related message (e.g. EAP Message Request) received from UE

[0157] * User ID

[0158] * GPSI

[0159] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0160] AMF / SMF may provide one or more of the above parameters to UAAF in order to start authentication for the user. GPSI may be provided in order to denote for which particular UE, the User authentication is being performed.

[0161] AMF / SMF may bypass the UAAF and may send the message directly towards AAA server.

[0162] 6. UAAF to AAA server (440, 4110)

[0163] * Authentication related message (e.g. EAP Message Request)

[0164] * User ID

[0165] If UAAF receives the AAA-user server address from AMF / SMF in previous step, it selects the corresponding AAA-User server and forwards it the Authentication related message (e.g. EAP Message Request) received from the AMF / SMF.

[0166] It may also include the User ID. Alternatively, this User ID may be included in the EAP message itself.

[0167] It may also select the corresponding AAA-user server based on the User ID and the stored configuration or based on the AAA-User server address provided by the AMF / SMF in Step 5.

[0168] 7. EAP authentication between UE and AAA server (445, 4115)

[0169] AAA-User server and UE exchanges EAP messages, so that the AAA-User server can verify whether the current user using the particular UE has the credentials for the User ID or not.

[0170] 8. AAA-user server to UAAF (450, 4120)

[0171] * EAP Success / Failure

[0172] * User ID

[0173] Once the authentication with UE is completed, AAA-user server sends the result of success or failure to UAAF based on the outcome of the authentication for the particular User ID.

[0174] 9. UAAF to AMF / SMF (455, 4125)

[0175] * User ID

[0176] * Result of authentication

[0177] * GPSI / SUPI

[0178] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0179] Upon receiving the Result of the User Authentication from AAA-User server, UAAF sends the response to the AMF / SMF. It may include other parameters like User ID (for which authentication happened) and GPSI / SUPI (to denote the UE for which authentication was performed).

[0180] Upon receiving the message, AMF / SMF may optionally update User Profile Storage Function (by sending a message) with the current active User ID for the SUPI / GPSI. User Profile Storage may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0181] 10. AMF to UDM (460, 4130)

[0182] * GPSI / SUPI

[0183] * User ID

[0184] * Result of authentication

[0185] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0186] Upon receiving the Result of the User Authentication from UAAF, AMF / SMF sends the response to the UDM. It may include other parameters like User ID (for which authentication happened) and GPSI / SUPI (to denote the UE for which authentication was performed).

[0187] Upon receiving the message, UDM may store the current active User ID for the SUPI as provided in the AMF / SMF request.

[0188] UDM may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0189] Upon receiving the message, UDM may optionally update User Profile Storage Function (by sending a message) with the current active User ID for the SUPI / GPSI. User Profile Storage may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0190] 11. UDM to NEF (or AF or some other 5G entity) (465, 4135)

[0191] Upon receiving the message from AMF / SMF in Step 10, or based on UDM operation in Step 2, UDM sends the message to NEF to notify about the result of User Authentication for the User ID as requested by the NEF or notify that User Authentication was not possible with the appropriate error code.

[0192] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0193] Upon receiving the message, NEF may optionally update User Profile Storage Function (by sending a message) with the current active User ID for the SUPI / GPSI. User Profile Storage may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0194] A2. NEF (or AF or some other 5G entity) to 3rdparty APP (470, 4140)

[0195] Based on the response to Step A1, NEF responds back to 3rdparty which requested for user authentication with the result as obtained from the AMF.

[0196] If the NEF received directly a rejection for User authentication from UDM in Step 3, it may notify the 3rdparty app with optionally including the cause.

[0197] FIG. 5 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0198] OPTION2 NEF invoking AMF / SMF

[0199] Following procedure (as in Figure 5) describes expansion of the Steps 3 to Steps 5 of Figure 2 (220, 225, 230) and 3 (320, 325, 330).

[0200] Only some of the steps described below may be performed, and also in an order different from the described order.

[0201] A1. 3rdparty APP to NEF (or AF or some Network entity like AUSF) (505)

[0202] A 3rdparty application request to NEF for user authentication for a user denoted by User ID. The message may also include UE IP address or User ID itself maybe in the form of UE IP address.

[0203] Optionally if the operator controlled AF is used, that AF may itself store the mapping of User ID to a corresponding SUPI / GPSI, and it can provide that to UDM also in Step 1.NEF may also find the SUPI / GPSI for the UE IP address provided in the previous message. The NEF may determine the dedicate DNN / S-SNSSAI used for User authentication or it may determine based on identity of the AF requesting authentication.

[0204] 1. NEF (or AF or some other Network entity like AUSF) to UDM (510)

[0205] * User ID

[0206] * (identity of the requesting AF / application function)

[0207] * DNN, S-NSSAI

[0208] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0209] NEF sends UDM a message to perform Authentication for the User ID. It may optionally send a special indication "to perform user authentication" to UDM in order to trigger authentication for the particular User ID.

[0210] 2. UDM operation (515)

[0211] UDM checks for the associated UE subscription (identified by SUPI) for the provided User ID in the AF request. It checks if the associated UE is currently registered to the network or not.

[0212] UDM may additionally store if there is any other active User ID on the UE associated with the User ID received from NEF in Step 2 and if any other User ID is currently active on the UE, UDM may send a rejection response to NEF including cause "User not active on the UE".

[0213] UDM may also check whether the AF / application function (based on its identity, if provided) is allowed to request for user authentication for the User ID or not.

[0214] UDM may also check the current registered network (PLMN / SNPN) and / or location of the UE. Based on the operator policies and / or UE subscription, UDM may determine whether the UE (or the User determined by User ID) is allowed to use User ID or not and whether network can authenticate the User (determined by User ID) based on its current location and / or current registered network.

[0215] If UDM cannot find any UE subscription linked to the User ID it may send the rejection response to the NEF right way including the cause "no UE linked to the User ID".

[0216] If the UDM find a UE subscription linked to the User ID, but the UE is not registered to the network or a specific PDU Session is not registered / established with the network, it may send the rejection response to the NEF right away including the cause "UE not registered to the network". The specific PDU Session may be a dedicated PDU Session through which User Authentication can be performed. The specific PDU Session may be for a dedicated DNN(data network name) / S-NSSAI(single network slice selection assistance information) for which User authentication is performed. This dedicated DNN / S-NSSAI may be provided by the NEF or may be determined by UDM based on configuration.

[0217] If an internal User ID is to be used, UDM may provide the internal User ID (in Step.3) corresponding to the User ID received from the NEF in Step 1.

[0218] 3. UDM to NEF (or AF or some other 5G entity like AUSF) (520)

[0219] * AAA-user server address

[0220] * SUPI / GPSI

[0221] * AMF / SMF ID

[0222] * User ID

[0223] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0224] For the NEF's request in Step 1, UDM sends to NEF the response including one or more of the above parameters.

[0225] SUPI (or GPSI) is provided in order to denote the particular UE, so that user authentication for the User ID happens for the UE identified by SUPI (or GPSI).

[0226] SUPI corresponds to the UE subscription which is linked to the User ID.

[0227] GPSI may also be sent in addition to or as a replacement to SUPI.

[0228] AAA-user server address may be stored in the UDM for the corresponding User ID provided by the NEF to UDM in Step 1. This AAA-server address is stored so that UDM can inform the corresponding network entity for user authentication, which server to contact to authorize the particular User ID.

[0229] The AAA-user server corresponding to the User ID, will store the credentials required to authenticate a particular User ID.

[0230] 4. NEF (or AF or some other Network entity like AUSF) to AMF / SMF (525)

[0231] * AAA server address

[0232] * SUPI / GPSI

[0233] * User ID

[0234] * DNN, S-NSSAI

[0235] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0236] NEF send to AMF / SMF (that is serving the UE denoted by the AMF / SMF ID provided to it) a message to start the User authentication for the User ID including one or more of the above parameters.

[0237] SUPI (or GPSI) is provided in order to denote the particular UE, so that user authentication for the User ID happens for the UE identified by SUPI (or GPSI).

[0238] SUPI corresponds to the UE subscription which is linked to the User ID.

[0239] GPSI may also be sent in addition to or as a replacement to SUPI.

[0240] AAA-user server address may be stored in the UDM for the corresponding User ID provided by the NEF to UDM in Step 1. This AAA-server address is stored so that UDM can inform the corresponding network entity for user authentication, which server to contact to authorize the particular User ID.

[0241] The AAA-server corresponding to the User ID, will store the credentials required to authenticate a particular User ID.

[0242] After receiving the message AMF / SMF decides to start user authentication by exchanging authentication related messages (e.g., EAP messages) between UE and the AAA-Server (via UAAF). Depending on whether the first authentication message need to be sent to UE or to AAA-server, AMF / SMF will perform either Step 5 or Step 6 first.

[0243] AMF / SMF operation

[0244] 5. AMF / SMF upon receiving the request in Step 4, will try to find the UE corresponding to the SUPI

[0245] 5a. AMF / SMF to UE: NAS-USER-Auth Downlink Message (530)

[0246] 5a-i. Request for EAP ID

[0247] 5a-ii. User ID

[0248] AMF / SMF may send a message to UE, in order to request UE for authentication message for the provided User ID.

[0249] 5b. UE to AMF / SMF: NAS User-Auth Uplink Message (535)

[0250] 5b-i. User ID

[0251] 5b-ii. EAP ID response / EAP-authentication message

[0252] User may be prompted to provide EAP ID corresponding to the User ID. Alternatively, this step may be skipped by the AMF / SMF, and AMF / SMF may directly contact UAAF with a message containing User ID in order to request UAAF to start authentication for the User ID.

[0253] 6. AMF / SMF to UAAF (540)

[0254] * AAA-User server address

[0255] * EAP message received from UE

[0256] * User ID

[0257] * GPSI

[0258] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0259] AMF / SMF may provide one or more of the above parameters to UAAF in order to start authentication for the user. GPSI may be provided in order to denote for which particular UE, the User authentication is being performed.

[0260] 7. UAAF to AAA-user server (545)

[0261] * EAP Message / Authentication message

[0262] * User ID

[0263] If UAAF receives the AAA-user server address from AMF / SMF in previous step, it selects the corresponding AAA-User server and forwards it the EAP message received from the AMF / SMF. Otherwise

[0264] It may also include the User ID. Alternatively, this User ID may be included in the EAP message / Authentication message itself.

[0265] 8. EAP authentication between UE and AAA-user server (550)

[0266] AAA-User server and UE exchanges EAP or authentication related messages, so that the AAA-User server can verify whether the current user using the particular UE has the credentials for the User ID or not.

[0267] 9. AAA-user server to UAAF (555)

[0268] * EAP Success / Failure

[0269] * User ID

[0270] Once the authentication with UE is completed, AAA-user server sends the result of success or failure to UAAF based on the outcome of the authentication for the particular User ID.

[0271] 10. UAAF to AMF / SMF (560)

[0272] * User ID

[0273] * Result of authentication

[0274] * GPSI / SUPI

[0275] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0276] Upon receiving the Result of the User Authentication from AAA-User server, UAAF sends the response to the AMF / SMF. It may include other parameters like User ID (for which authentication happened) and GPSI / SUPI (to denote the UE for which authentication was performed).

[0277] Upon receiving the message, AMF / SMFmay optionally update UDM / User Profile Storage Function (by sending a message) with the current active User ID for the SUPI / GPSI. UDM / User Profile Storage Function may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0278] 11. AMF / SMF to NEF (or AF or some other 5G entity) (565)

[0279] * GPSI / SUPI

[0280] * User ID

[0281] * Result of authentication

[0282] Upon receiving the Result of the User Authentication from UAAF, AMF / SMF sends the response to the NEF. It may include other parameters like User ID (for which authentication happened) and GPSI / SUPI.

[0283] Upon receiving the message, AMF / SMFmay optionally update UDM / User Profile Storage Function (by sending a message) with the current active User ID for the SUPI / GPSI. UDM / User Profile Storage Function may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0284] A2. NEF (or AF or some other 5G entity) to 3rdparty APP (570)

[0285] Based on the response to Step A1, NEF responds back to 3rdparty which requested for user authentication with the result as obtained from the AMF / SMF.

[0286] If the NEF received directly a rejection for User authentication from UDM in Step 3, it may notify the 3rdparty app with optionally including the cause.

[0287] FIG. 6a and FIG. 6b illustrate other examples of a user authentication procedure in accordance with an embodiment of the disclosure.

[0288] OPTION 3 UDM invoking AMF / SMF with User Profile

[0289] Figure 6a and figure 6b provide corresponding change to OPTION 1 with the difference a User profile storage is used to store explicitly the information related to a particular User ID (e.g. list of UEs linked, AAA-user server address which stores the User credentials).

[0290] Only some of the steps described below may be performed, and also in an order different from the described order.

[0291] A1. 3rdparty APP to NEF (or AF or some other Network entity like AUSF) (605, 690)

[0292] A 3rdparty application request to NEF for user authentication for a user denoted by User ID. The message may also include UE IP address or User ID itself maybe in the form of UE IP address.

[0293] Optionally if the operator controlled AF is used, that AF may itself store the mapping of User ID to a corresponding SUPI / GPSI, and it can provide that to UDM also in Step 3.NEF may also find the SUPI / GPSI for the UE IP address provided in the previous message. The NEF may determine the dedicate DNN / S-SNSSAI used for User authentication or it may determine based on identity of the AF requesting authentication.

[0294] 1. NEF (or AF or some other Network entity like AUSF) to User Profile Storage function (610, 695)

[0295] * User ID

[0296] * (identity of the requesting AF / application function)

[0297] * UE ID (GPSI / SUPI)

[0298] 1a, 1b, 1c. NEF sends a message to request information for a particular User ID. User Profile storage Function queries its database for the provided User ID and sends the response (610, 615, 620, 695, 6100, 6105).

[0299] If provided, User Profile Storage function may also check if the identity of the requesting AF / application function, is allowed to request user id related authorization or not.

[0300] 1c. User profile storage function to NEF (620, 6105)

[0301] * User ID

[0302] * SUPI / GPSI(s) / UE / device identifier(s)

[0303] * AAA-User server address

[0304] * Current active (or last active UE) UE

[0305] As a response to the message in Step 1, User Profile Storage function sends to NEF the information regarding the User ID provided in the request message.

[0306] SUPI / GPSI(s) / UE / device identifier(s) are used to determine which all UE(s) or SUPI(s) are linked to the User ID.

[0307] AAA-user server address may be stored for the corresponding User ID provided by the NEF. This AAA-server address is stored so that the corresponding network entity for user authentication can be informed, which server to contact to authorize the particular User ID.

[0308] Based on the list of SUPI / GPSI / UE / Device identifier(s) provided by the User profile storage, NEF may determine which UE(s) needs to be triggered for authentication for the particular User ID. For the purpose of determining these UE(s), NEF may also utilize the Current Active (or last active UE) if provided by the User profile Storage Function.

[0309] NEF may perform the Step 3, multiple times based on the number of SUPI / GPSI / UE / Device identifier(s) provided by the User profile storage function.

[0310] 2. NEF to UDM (625, 6110)

[0311] * SUPI / GPSI

[0312] * (identity of the requesting AF / application function)

[0313] * User ID

[0314] * DNN, S-NSSAI

[0315] NEF sends UDM a message to perform Authentication for the User ID. It may optionally send a special indication "to perform user authentication" to UDM in order to trigger authentication for the particular User ID.

[0316] 3. UDM operation (630, 6115)

[0317] UDM checks for the associated UE subscription for the provided SUPI / GPSI in the NEF request. It checks if the associated UE is currently registered to the network or not.

[0318] UDM may additionally store if there is any other active User ID on the UE associated with the User ID received from NEF in Step 2 and if any other User ID is currently active on the UE, UDM may send a rejection response to NEF including cause "User not active on the UE"

[0319] UDM may also check whether the AF / application function (based on its identity, if provided) is allowed to request for user authentication for the User ID or not.

[0320] UDM may also check the current registered network (PLMN / SNPN) and / or location of the UE. Based on the operator policies and / or UE subscription, UDM may determine whether the UE (or the User determined by User ID) is allowed to use User ID or not and whether network can authenticate the User (determined by User ID) based on its current location and / or current registered network.

[0321] If the UDM find the UE is not registered to the network or a specific PDU Session is not registered / established with the network, it may send the rejection response to the NEF right away including the cause "UE / User ID not registered to the network". The specific PDU Session may be a dedicated PDU Session through which User Authentication can be performed. The specific PDU Session may be for a dedicated DNN / S-NSSAI for which User authentication is performed.

[0322] For e.g. when UDM receives the request from NEF, it may check if the UE (associated with the User ID, or UE ID) has established a PDU session to a dedicated DNN / S_NSSAI used for user authentication or not.

[0323] Remaining steps will be similar to OPTION 1 as described before (635 ~ 685, 6120 ~ 6170).

[0324] FIG. 7 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0325] OPTION 4 NEF invoking AMF / SMF with User profile

[0326] Figure 7 provides corresponding change to OPTION 2 with the difference a User profile storage is used to store explicitly the information related to a particular User ID (e.g. list of UEs linked, AAA-user server address which stores the User credentials).

[0327] Only some of the steps described below may be performed, and also in an order different from the described order.

[0328] A1. 3rdparty APP to NEF (or AF or some other Network entity like AUSF) (705)

[0329] A 3rdparty application request to NEF for user authentication for a user denoted by User ID. The message may also include UE IP address or User ID itself maybe in the form of UE IP address.

[0330] Optionally if the operator controlled AF is used, that AF may itself store the mapping of User ID to a corresponding SUPI / GPSI, and it can provide that also to UDM in Step 3.NEF may also find the SUPI / GPSI for the UE IP address provided in the previous message. The NEF may determine the dedicate DNN / S-SNSSAI used for User authentication or it may determine based on identity of the AF requesting authentication.

[0331] NEF (or AF or some other Network entity like AUSF) to User Profile Storage function (710)

[0332] * User ID

[0333] * (identity of the requesting AF / application function)

[0334] NEF sends a message to request information for a particular User ID. User Profile storage Function queries its database for the provided User ID and sends the response.

[0335] If provided, User Profile Storage function may also check if the identity of the requesting AF / application function, is allowed to request user id related authorization or not.

[0336] 2. User profile storage function to NEF (715)

[0337] * User ID

[0338] * SUPI / GPSI(s) / UE / device identifier(s)

[0339] * AAA-User server address

[0340] * Current active (or last active UE) UE

[0341] As a response to the message in Step 1, User Profile Storage function sends to NEF the information regarding the User ID provided in the request message.

[0342] SUPI / GPSI(s) / UE / device identifier(s) are used to determine which all UE(s) or SUPI(s) are linked to the User ID.

[0343] AAA-user server address may be stored for the corresponding User ID provided by the NEF. This AAA-server address is stored so that the corresponding network entity for user authentication can be informed, which server to contact to authorize the particular User ID.

[0344] Based on the list of SUPI / GPSI / UE / Device identifier(s) provided by the User profile storage, NEF may determine which UE(s) needs to be triggered for authentication for the particular User ID. For the purpose of determining these UE(s), NEF may also utilize the Current Active (or last active UE) if provided by the User profile Storage Function.

[0345] NEF may perform the Step 3, multiple times based on the number of SUPI / GPSI / UE / Device identifier(s) provided by the User profile storage function.

[0346] 3. NEF to UDM (720)

[0347] * SUPI / GPSI

[0348] * (identity of the requesting AF / application function)

[0349] * User ID

[0350] NEF sends UDM a message to perform Authentication for the User ID. It may optionally send a special indication "to perform user authentication" to UDM in order to trigger authentication for the particular User ID.

[0351] 4. UDM operation (725)

[0352] UDM checks for the associated UE subscription for the provided SUPI / GPSI in the NEF request. It checks if the associated UE is currently registered to the network or not.

[0353] UDM may additionally store if there is any other active User ID on the UE associated with the User ID received from NEF in Step 2 and if any other User ID is currently active on the UE, UDM may send a rejection response to NEF including cause "User not active on the UE"

[0354] UDM may also check whether the AF / application function (based on its identity, if provided) is allowed to request for user authentication for the User ID or not.

[0355] UDM may also check the current registered network (PLMN / SNPN) and / or location of the UE. Based on the operator policies and / or UE subscription, UDM may determine whether the UE (or the User determined by User ID) is allowed to use User ID or not and whether network can authenticate the User (determined by User ID) based on its current location and / or current registered network.

[0356] If the UDM find a UE subscription linked to the User ID, but the UE is not registered to the network or a specific PDU Session is not registered / established with the network, it may send the rejection response to the NEF right away including the cause "UE not registered to the network". The specific PDU Session may be a dedicated PDU Session through which User Authentication can be performed. The specific PDU Session may be for a dedicated DNN(data network name) / S-NSSAI(single network slice selection assistance information) for which User authentication is performed. This dedicated DNN / S-NSSAI may be provided by the NEF or may be determined by UDM based on configuration.

[0357] Remaining steps will be similar to OPTION 2 as described before.

[0358] AMF / SMF being transparent to UAAF authentication

[0359] FIG. 8 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0360] OPTION 5: UDM invoking UAAF

[0361] Following procedure (as in Figure 8) describes expansion of the Steps 3 to Steps 5 of Figure 2 (220, 225, 230) and 3 (320, 325, 330), that is how authentication for a User ID will be carried out in the 5G system.

[0362] Only some of the steps described below may be performed, and also in an order different from the described order.

[0363] A1. 3rdparty APP to NEF (or AF or some other Network entity) (805)

[0364] A 3rdparty application request to NEF for user authentication for a user denoted by User ID. The message may also include UE IP address or User ID itself maybe in the form of UE IP address.

[0365] Optionally if the operator controlled AF is used, that AF may itself store the mapping of User ID to a corresponding SUPI / GPSI, and it can provide that also to UDM in Step 1.NEF may also find the SUPI / GPSI for the UE IP address provided in the previous message. The NEF may determine the dedicate DNN / S-SNSSAI used for User authentication or it may determine based on identity of the AF requesting authentication.

[0366] 1. NEF (or AF or some other Network entity) to UDM (810)

[0367] * User ID

[0368] * (identity of the requesting AF / application function)

[0369] * DNN, S-NSSAI

[0370] * SUPI / GPSI

[0371] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0372] NEF sends UDM a message to perform Authentication for the User ID.

[0373] 2. UDM operation (815)

[0374] UDM checks for the associated UE subscription for the provided User ID in the AF request. It checks if the associated UE is currently registered to the network or not.

[0375] UDM may additionally store if there is any other active User ID on the UE associated with the User ID received from NEF in Step 2 and if any other User ID is currently active on the UE, UDM may send a rejection response to NEF including cause "User not active on the UE"

[0376] UDM may also check whether the AF / application function (based on its identity provided) is allowed to request for user authentication for the User ID or not.

[0377] UDM may also check the current registered network (PLMN / SNPN) and / or location of the UE. Based on the operator policies and / or UE subscription, UDM may determine whether the UE (or the User determined by User ID) is allowed to use User ID or not and whether network can authenticate the User (determined by User ID) based on its current location and / or current registered network.

[0378] If UDM cannot find any UE subscription linked to the User ID it may send the rejection response to the NEF right way including the cause "no UE linked to the User ID"

[0379] If the UDM find a UE subscription linked to the User ID, but the UE is not registered to the network or a specific PDU Session is not registered / established with the network, it may send the rejection response to the NEF right away including the cause "UE not registered to the network". The specific PDU Session may be a dedicated PDU Session through which User Authentication can be performed. The specific PDU Session may be for a dedicated DNN(data network name) / S-NSSAI(single network slice selection assistance information) for which User authentication is performed. This dedicated DNN / S-NSSAI may be provided by the NEF or may be determined by UDM based on configuration.

[0380] If an internal User ID is to be used, UDM may provide the internal User ID (in Step.3) corresponding to the User ID received from the NEF in Step 1.

[0381] UDM performs UAAF selection in order to find the UAAF that can relay the message between UE and the corresponding AAA server.

[0382] 3. UDM to UAAF (820)

[0383] * AAA-user server address

[0384] * SUPI / GPSI

[0385] * AMF / SMF ID

[0386] * User ID

[0387] * DNN, S-NSSAI

[0388] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0389] For the NEF's request in Step 1, UDM sends message to UAAF that is serving the UE a message to start the User authentication for the User ID including one or more of the above parameters.

[0390] SUPI (or GPSI) is provided in order to denote the particular UE, so that user authentication for the User ID happens for the UE identified by SUPI (or GPSI).

[0391] SUPI corresponds to the UE subscription which is linked to the User ID.

[0392] GPSI may also be sent in addition to or as a replacement to SUPI.

[0393] AMF / SMF ID corresponds to the current AMF / SMF which is serving the UE corresponding to the SUPI.

[0394] AAA-user server address may be stored in the UDM for the corresponding User ID provided by the NEF to UDM in Step 1. This AAA-server address is stored so that UDM can inform the corresponding network entity for user authentication, which server to contact to authorize the particular User ID. The AAA-server corresponding to the User ID, will store the credentials required to authenticate a particular User ID.

[0395] After receiving the message UAAF decides to start user authentication by exchanging authentication related messages (e.g., EAP messages) between UE and the AAA-Server. Depending on whether the first authentication message need to be sent to UE or to AAA-server, UAAF will perform either Step 4 or Step 7 first.

[0396] 4. UAAF to AMF / SMF (825)

[0397] 4a. SUPI / GPSI

[0398] 4b. N1 message container for UE

[0399] 4b-i. Message type : User Auth

[0400] 4b-ii. User ID

[0401] 4b-iii. Authentication related message (e.g. EAP Message)

[0402] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0403] UAAF sends the message towards the AMF / SMF serving the UE, according to the message that was received from UDM in Step 3. It includes authentication related message along with particular User ID for which Authentication need to happen.

[0404] SUPI (or GPSI) is provided in order to denote the particular UE, so that user authentication for the User ID happens for the UE identified by SUPI (or GPSI).

[0405] 5. UE-AMF / SMF exchange (830, 835)

[0406] Upon receiving the message from UAAF, AMF / SMF forwards the message received to the UE identified by SUPI / GPSI.

[0407] AMF / SMF encapsulates message received from UAAF and sends it to UE

[0408] User on the UE is prompted to provide User credentials relevant for the User ID.

[0409] UE sends the Authentication message towards UAAF via AMF / SMF

[0410] 6. AMF / SMF to UAAF (840)

[0411] Upon receiving the message from UE, AMF / SMF forwards the message received to the UAAF as a response to Step 4.

[0412] 6a. SUPI / GPSI

[0413] 6b. N1 message container for UE

[0414] 6b-i. Message type : User Auth

[0415] 6b-ii. User ID

[0416] 6b-iii. Authentication related message (e.g. EAP Message)

[0417] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0418] 7. UAAF to AAA-User (845)

[0419] * User ID

[0420] * Authentication related message (e.g. EAP Message Request)

[0421] UAAF communicates with AAA-User server for authenticating the user by sending it the message with one or more of the above parameters.

[0422] It may also select the corresponding AAA server based on the User ID and the stored configuration or based on the AAA-User server address provided by the UDM in Step 3.

[0423] 8. AAA-User to UAAF (850)

[0424] * User ID

[0425] * Authentication related message (e.g. EAP Message Request)

[0426] AAA-User server that need to exchange authentication related message (which may be a EAP message) with the UE (or User of the UE) will send further authentication related messages back to UAAF in order to communicate them to UE.

[0427] Steps 4-8 may be repeated multiple times in order to exchange Authentication related messages (between UE and AAA-server)(855)

[0428] After the authentication is completed, AAA-user server will finally send the result of authentication (success / failure) to the UAAF based on the outcome of the authentication for the particular User ID.

[0429] 9. UAAF to UDM (860)

[0430] * SUPI / GPSI

[0431] * Indication of Authentication success / failure

[0432] * User ID

[0433] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0434] Upon receiving the result of authentication from the AAA-server, UAAF will notify the UDM about the result of authentication as a response to Step 3. It may include other parameters like User ID (for which authentication happened) and GPSI / SUPI (to denote the UE for which authentication was performed).

[0435] Upon receiving the message, UDM may store the current active User ID for the SUPI as provided in the AMF / SMF request.

[0436] UDM may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0437] Upon receiving the message, UDM may optionally update User Profile Storage Function (by sending a message) with the current active User ID for the SUPI / GPSI. User Profile Storage may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0438] 10. UDM to NEF (or AF or some other 5G entity) (865)

[0439] Upon receiving the message from UAAF in Step 9, or based on UDM operation in Step 2, UDM sends the message to NEF to notify about the result of User Authentication for the User ID as requested by the NEF or notify that User Authentication was not possible with the appropriate error code.

[0440] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0441] Upon receiving the message, NEF may optionally update User Profile Storage Function (by sending a message) with the current active User ID for the SUPI / GPSI. User Profile Storage may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0442] A2. NEF (or AF or some other 5G entity) to 3rdparty APP (870)

[0443] Based on the response to Step A1, NEF responds back to 3rdparty which requested for user authentication with the result as obtained from the AMF / SMF.

[0444] If the NEF received directly a rejection for User authentication from UDM in Step 3, it may notify the 3rdparty app with optionally including the cause.

[0445] FIG. 9 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0446] OPTION 6: NEF invoking UAAF

[0447] Following procedure (as in Figure 9) describes expansion of the Steps 3 to Steps 5 of Figure 2 (220, 225, 230) and 3 (320, 325, 330).

[0448] As in Figure 9:

[0449] A1. 3rdparty APP to NEF (or AF or some other 5G entity) (905)

[0450] A 3rdparty application request to NEF for user authentication for a user denoted by User ID. The message may also include UE IP address or User ID itself maybe in the form of UE IP address.

[0451] Optionally if the operator controlled AF is used, that AF may itself store the mapping of User ID to a corresponding SUPI / GPSI, and it can provide that also to UDM in Step 1.NEF may also find the SUPI / GPSI for the UE IP address provided in the previous message. The NEF may determine the dedicate DNN / S-SNSSAI used for User authentication or it may determine based on identity of the AF requesting authentication.

[0452] 1. NEF (or AF or some other 5G entity like AUSF) to UDM (910)

[0453] * User ID

[0454] * (identity of the requesting AF / application function)

[0455] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0456] NEF sends UDM a message to perform Authentication for the User ID. It may optionally send a special indication "to perform user authentication" to UDM in order to trigger authentication for the particular User ID.

[0457] 2. UDM operation (915)

[0458] UDM checks for the associated UE subscription for the provided User ID in the AF / NEF request. It checks if the associated UE is currently registered to the network or not.

[0459] UDM may additionally store if there is any other active User ID on the UE associated with the User ID received from NEF in Step 2 and if any other User ID is currently active on the UE, UDM may send a rejection response to NEF including cause "User not active on the UE"

[0460] UDM may also check whether the AF / application function (based on its identity, if provided) is allowed to request for user authentication for the User ID or not.

[0461] UDM may also check the current registered network (PLMN / SNPN) and / or location of the UE. Based on the operator policies and / or UE subscription, UDM may determine whether the UE (or the User determined by User ID) is allowed to use User ID or not and whether network can authenticate the User (determined by User ID) based on its current location and / or current registered network.

[0462] If UDM cannot find any UE subscription linked to the User ID it may send the rejection response to the NEF right way including the cause "no UE linked to the User ID"

[0463] If the UDM find a UE subscription linked to the User ID, but the UE is not registered to the network or a specific PDU Session is not registered / established with the network, it may send the rejection response to the NEF right away including the cause "UE not registered to the network". The specific PDU Session may be a dedicated PDU Session through which User Authentication can be performed. The specific PDU Session may be for a dedicated DNN(data network name) / S-NSSAI(single network slice selection assistance information) for which User authentication is performed. This dedicated DNN / S-NSSAI may be provided by the NEF or may be determined by UDM based on configuration.

[0464] If an internal User ID is to be used, UDM may provide the internal User ID (in Step.3) corresponding to the User ID received from the NEF in Step 1.

[0465] 3. UDM to NEF (or AF or some other 5G entity like AUSF) (920)

[0466] * AAA-user server address

[0467] * SUPI / GPSI

[0468] * AMF / SMF ID

[0469] * User ID

[0470] For the NEF's request in Step 1, UDM sends to NEF the response including one or more of the above parameters.

[0471] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0472] AAA-user server address may be stored in the UDM for the corresponding User ID provided by the NEF to UDM in Step 1. This AAA-server address is stored so that UDM can inform the corresponding network entity for user authentication, which server to contact to authorize the particular User ID.

[0473] The AAA-user server corresponding to the User ID, will store the credentials required to authenticate a particular User ID.

[0474] SUPI corresponds to the UE subscription which is linked to the User ID. AMF / SMF ID corresponds to the current AMF / SMF which is serving the UE corresponding to the SUPI.

[0475] GPSI may also be sent in addition to or as a replacement to SUPI.

[0476] NEF performs UAAF selection in order to find the UAAF that can relay the message between UE and the corresponding AAA server.

[0477] 4. NEF (or AF or some other 5G entity like AUSF) to UAAF (925)

[0478] * SUPI / GPSI

[0479] * AMF / SMF ID

[0480] * User ID

[0481] * AAA server Address

[0482] * DNN, S-NSSAI

[0483] NEF send the message to UAAF a message to start the User authentication for the User ID including one or more of the above parameters.

[0484] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0485] SUPI (or GPSI) is provided in order to denote the particular UE, so that user authentication for the User ID happens for the UE identified by SUPI (or GPSI).

[0486] After receiving the message UAAF decides to start user authentication by exchanging authentication related messages (for e.g., EAP messages) between UE and the AAA-Server. Depending on whether the first authentication message need to be sent to UE or to AAA-server, UAAF will perform either Step 5 or Step 8 first.

[0487] 5. UAAF to AMF / SMF (930)

[0488] 5a. SUPI / GPSI

[0489] 5b. N1 message container for UE

[0490] 5b-i. Message type : User Auth

[0491] 5b-ii. User ID

[0492] 5b-iii. Authentication related message (e.g. EAP Message)

[0493] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0494] UAAF sends the message towards the AMF / SMF serving the UE, as was received from NEF in Step 4. It includes authentication related message along with particular User ID for which Authentication need to happen.

[0495] 6. UE-AMF / SMF exchange (935, 940)

[0496] Upon receiving the message from UAAF, AMF / SMF forwards the message received to the UE identified by SUPI / GPSI.

[0497] * AMF / SMF encapsulates message received from UAAF and sends it to UE

[0498] * User on the UE is prompted to provide User credentials relevant for the User ID.

[0499] * UE sends the Authentication message towards UAAF via AMF / SMF

[0500] 7. AMF / SMF to UAAF (945)

[0501] Upon receiving the message from UE, AMF / SMF forwards the message received to the UAAF as a response to Step 5.

[0502] 7a. SUPI / GPSI

[0503] 7b. N1 message container for UE

[0504] 7b-i. Message type : User Auth

[0505] 7b-ii. User ID

[0506] 7b-iii. Authentication related message (e.g. EAP Message)

[0507] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0508] 8. UAAF to AAA-User (950)

[0509] * User ID

[0510] * Authentication related message (e.g. EAP Message Request)

[0511] UAAF communicates with AAA-User server for authenticating the user by sending. It may wither find the corresponding AAA server based on the User ID and the stored configuration or based on the AAA-User server address provided by the NEF in Step 4.

[0512] 9. AAA-User to UAAF (955)

[0513] * User ID

[0514] * Authentication related message (e.g. EAP Message Request)

[0515] AAA-User server that need to exchange authentication related message (which may be a EAP message) with the UE (or User of the UE) will send further authentication related messages back to UAAF in order to communicate them to UE.

[0516] Steps 5-9 may be repeated multiple times in order to exchange Authentication related messages (between UE and AAA-server)(960)

[0517] After the authentication is completed, AAA-user server will finally send the result of authentication (success / failure) to the UAAF.

[0518] 10. UAAF to NEF (or AF or some other Network entity like AUSF) (965)

[0519] * SUPI / GPSI

[0520] * Indication of Authentication success / failure

[0521] * User ID

[0522] Upon receiving the result of authentication from the AAA-server, UAAF will notify the NEF about the result of authentication to the NEF as a response to Step 4.

[0523] Additionally, an indication "user authentication" may also be provided in the message in order to denote that the request is for user authentication (or user related functionality) so that the network entity receiving this message can distinguish it from other type of messages.

[0524] Upon receiving the message, NEF may optionally update UDM / User Profile Storage Function (by sending a message) with the current active User ID for the SUPI / GPSI. UDM / User Profile Storage Function may also store the time when the particular User ID was successfully authenticated in the UE identified by the SUPI.

[0525] A2. NEF (or AF or some other 5G entity) to 3rd party APP (970).

[0526] Based on the response to Step A1, NEF responds back to 3rd party which requested for user authentication with the result as obtained from the AMF / SMF.

[0527] If the NEF received directly a rejection for User authentication from UDM in Step 3, it may notify the 3rd party app with optionally including the cause.

[0528] FIG. 10 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0529] OPTION 7 UDM invoking UAAF with User Profile

[0530] Figure 10 provides corresponding change to OPTION 5 with the difference a User profile storage is used to store explicitly the information related to a particular User ID (e.g. list of UEs linked, AAA-user server address which stores the User credentials)

[0531] Only some of the steps described below may be performed and in an order different from the described order.

[0532] A1. 3rdparty APP to NEF (or AF or some other Network entity like AUSF) (1005)

[0533] A 3rdparty application request to NEF for user authentication for a user denoted by User ID. The message may also include UE IP address or User ID itself may be in the form of UE IP address. NEF may also find the SUPI / GPSI for the UE IP address provided in the previous message. The NEF may determine the dedicate DNN / S-SNSSAI used for User authentication or it may determine based on identity of the AF requesting authentication.

[0534] Optionally if the operator controlled AF is used, that AF may itself store the mapping of User ID to a corresponding SUPI / GPSI, and it can provide that to UDM also in Step 1.

[0535] 1. NEF (or AF or some other Network entity like AUSF) to User Profile Storage function (1010)

[0536] * User ID

[0537] * (identity of the requesting AF / application function)

[0538] 1a, 1b, 1c. NEF sends a message to request information for a particular User ID (1010). User Profile storage Function queries its database for the provided User ID and sends the response (1015, 1020).

[0539] If provided, User Profile Storage function may also check if the identity of the requesting AF / application function, is allowed to request user id related authorization or not.

[0540] 1c. User profile storage function to NEF (1020)

[0541] * User ID

[0542] * SUPI / GPSI(s) / UE / device identifier(s)

[0543] * AAA-User server address

[0544] * Current active (or last active UE) UE

[0545] As a response to the message in Step 1, User Profile Storage function sends to NEF the information regarding the User ID provided in the request message.

[0546] SUPI / GPSI(s) / UE / device identifier(s) are used to determine which all UE(s) or SUPI(s) are linked to the User ID.

[0547] AAA-user server address may be stored for the corresponding User ID provided by the NEF. This AAA-server address is stored so that the corresponding network entity for user authentication can be informed, which server to contact to authorize the particular User ID.

[0548] Based on the list of SUPI / GPSI / UE / Device identifier(s) provided by the User profile storage, NEF may determine which UE(s) needs to be triggered for authentication for the particular User ID. For the purpose of determining these UE(s), NEF may also utilize the Current Active (or last active UE) if provided by the User profile Storage Function.

[0549] NEF may perform the Step 3, multiple times based on the number of SUPI / GPSI / UE / Device identifier(s) provided by the User profile storage function.

[0550] 2. NEF to UDM (1025)

[0551] * SUPI / GPSI

[0552] * (identity of the requesting AF / application function)

[0553] * User ID

[0554] * DNN, S-NSSAI

[0555] NEF sends UDM a message to perform Authentication for the User ID. It may optionally send a special indication "to perform user authentication" to UDM in order to trigger authentication for the particular User ID.

[0556] 3. UDM operation (1030)

[0557] UDM checks for the associated UE subscription for the provided SUPI / GPSI in the NEF request. It checks if the associated UE is currently registered to the network or not.

[0558] UDM may additionally store if there is any other active User ID on the UE associated with the User ID received from NEF in Step 2 and if any other User ID is currently active on the UE, UDM may send a rejection response to NEF including cause "User not active on the UE"

[0559] UDM may also check whether the AF / application function (based on its identity, if provided) is allowed to request for user authentication for the User ID or not.

[0560] UDM may also check the current registered network (PLMN / SNPN) and / or location of the UE. Based on the operator policies and / or UE subscription, UDM may determine whether the UE (or the User determined by User ID) is allowed to use User ID or not and whether network can authenticate the User (determined by User ID) based on its current location and / or current registered network.

[0561] If the UDM find a UE subscription linked to the User ID, but the UE is not registered to the network or a specific PDU Session is not registered / established with the network, it may send the rejection response to the NEF right away including the cause "UE not registered to the network". The specific PDU Session may be a dedicated PDU Session through which User Authentication can be performed. The specific PDU Session may be for a dedicated DNN(data network name) / S-NSSAI(single network slice selection assistance information) for which User authentication is performed. This dedicated DNN / S-NSSAI may be provided by the NEF or may be determined by UDM based on configuration.

[0562] Remaining steps will be similar to OPTION 5 as described before.

[0563] FIG. 11 illustrates another example of a user authentication procedure in accordance with an embodiment of the disclosure.

[0564] OPTION 8 NEF invoking UAAF with User profile

[0565] Figure 11 provides corresponding change to OPTION 6 with the difference a User profile storage is used to store explicitly the information related to a particular User ID (e.g. list of UEs linked, AAA-user server address which stores the User credentials).

[0566] Only some of the steps described below may be performed, and as in an order different from the described order.

[0567] A1. 3rdparty APP to NEF (1105)

[0568] A 3rdparty application request to NEF for user authentication for a user denoted by User ID. The message may also include UE IP address or User ID itself may be in the form of UE IP address. NEF may also find the SUPI / GPSI for the UE IP address provided in the previous message. The NEF may determine the dedicate DNN / S-SNSSAI used for User authentication or it may determine based on identity of the AF requesting authentication.

[0569] Optionally if the operator controlled AF is used, that AF may itself store the mapping of User ID to a corresponding SUPI / GPSI, and it can provide that also to UDM in Step 3.

[0570] 1. NEF (or AF or some other Network entity like AUSF) to User Profile Storage function (1110)

[0571] * User ID

[0572] * (identity of the requesting AF / application function)

[0573] NEF sends a message to request information for a particular User ID (1110). User Profile storage Function queries its database for the provided User ID and sends the response (1115, 1120).

[0574] If provided, User Profile Storage function may also check if the identity of the requesting AF / application function, is allowed to request user id related authorization or not.

[0575] 1c. User profile storage function to NEF (1120)

[0576] * User ID

[0577] * SUPI / GPSI(s) / UE / device identifier(s)

[0578] * AAA-User server address

[0579] * Current active (or last active UE) UE

[0580] As a response to the message in Step 1, User Profile Storage function sends to NEF the information regarding the User ID provided in the request message.

[0581] SUPI / GPSI(s) / UE / device identifier(s) are used to determine which all UE(s) or SUPI(s) are linked to the User ID.

[0582] AAA-user server address may be stored for the corresponding User ID provided by the NEF. This AAA-server address is stored so that the corresponding network entity for user authentication can be informed, which server to contact to authorize the particular User ID.

[0583] Based on the list of SUPI / GPSI / UE / Device identifier(s) provided by the User profile storage, NEF may determine which UE(s) needs to be triggered for authentication for the particular User ID. For the purpose of determining these UE(s), NEF may also utilize the Current Active (or last active UE) if provided by the User profile Storage Function.

[0584] NEF may perform the Step 3, multiple times based on the number of SUPI / GPSI / UE / Device identifier(s) provided by the User profile storage function.

[0585] 2. NEF to UDM (1125)

[0586] * SUPI / GPSI

[0587] * (identity of the requesting AF / application function)

[0588] * User ID

[0589] * DNN, S-NSSAI

[0590] NEF sends UDM a message to perform Authentication for the User ID. It may optionally send a special indication "to perform user authentication" to UDM in order to trigger authentication for the particular User ID.

[0591] 3. UDM operation (1130)

[0592] UDM checks for the associated UE subscription for the provided SUPI / GPSI in the NEF request. It checks if the associated UE is currently registered to the network or not.

[0593] UDM may additionally store if there is any other active User ID on the UE associated with the User ID received from NEF in Step 2 and if any other User ID is currently active on the UE, UDM may send a rejection response to NEF including cause "User not active on the UE"

[0594] UDM may also check whether the AF / application function (based on it's identity, if provided) is allowed to request for user authentication for the User ID or not.

[0595] UDM may also check the current registered network (PLMN / SNPN) and / or location of the UE. Based on the operator policies and / or UE subscription, UDM may determine whether the UE (or the User determined by User ID) is allowed to use User ID or not and whether network can authenticate the User (determined by User ID) based on it's current location and / or current registered network.

[0596] If the UDM find a UE subscription linked to the User ID, but the UE is not registered to the network or a specific PDU Session is not registered / established with the network, it may send the rejection response to the NEF right away including the cause "UE not registered to the network". The specific PDU Session may be a dedicated PDU Session through which User Authentication can be performed. The specific PDU Session may be for a dedicated DNN(data network name) / S-NSSAI(single network slice selection assistance information) for which User authentication is performed. This dedicated DNN / S-NSSAI may be provided by the NEF or may be determined by UDM based on configuration.

[0597] Remaining steps will be similar to OPTION 6 as described before.

[0598] Figure 12 is a block diagram of a terminal (or, a UE) according to the disclosure.

[0599] Referring to FIG. 12, a terminal includes a transceiver 1210, a controller 1220 and a memory 1230. The controller 1220 may refer to a circuitry, an application-specific integrated circuit (ASIC), or at least one processor. The transceiver 1210, the controller 1220 and the memory 1230 are configured to perform the operations of the UE illustrated in the figures 1 to 11, or described above. Although the transceiver 1210, the controller 1220 and the memory 1230 are shown as separate entities, they may be realized as a single entity like a single chip. Or, the transceiver 1210, the controller 1220 and the memory 1230 may be electrically connected to or coupled with each other.

[0600] The transceiver 1210 may transmit and receive signals to and from other network entities, e.g., a base station. The controller 1220 may control the UE to perform functions according to one of the embodiments described above. The controller 1220 may refer to a circuitry, an ASIC, or at least one processor. In an embodiment, the operations of the terminal may be implemented using the memory 1230 storing corresponding program codes. Specifically, the terminal may be equipped with the memory 1230 to store program codes implementing desired operations. To perform the desired operations, the controller 1220 may read and execute the program codes stored in the memory 1230 by using a processor or a central processing unit (CPU).

[0601] FIG. 13 is a block diagram of a base station according to an embodiment of the disclosure.

[0602] Referring to FIG. 13, a base station includes a transceiver 1310, a controller 1320 and a memory 1330. The transceiver 1310, the controller 1320 and the memory 1330 are configured to perform the operations of the network (e.g., gNB) illustrated in the figures 1 to 11, or described above. Although the transceiver 1310, the controller 1320 and the memory 1330 are shown as separate entities, they may be realized as a single entity like a single chip. The transceiver 1310, the controller 1320 and the memory 1330 may be electrically connected to or coupled with each other.

[0603] The transceiver 1310 may transmit and receive signals to and from other network entities, e.g., a terminal or a network function. The controller 1320 may control the base station to perform functions according to one of the embodiments described above. The controller 1320 may refer to a circuitry, an ASIC, or at least one processor. In an embodiment, the operations of the base station may be implemented using the memory 1330 storing corresponding program codes. Specifically, the base station may be equipped with the memory 1330 to store program codes implementing desired operations. To perform the desired operations, the controller 1320 may read and execute the program codes stored in the memory 1330 by using a processor or a CPU.

[0604] While the disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents.

[0605] FIG. 14 is a block diagram of a network function (or, a network entity) according to an embodiment of the disclosure.

[0606] Referring to FIG. 14, a network function (or, a network entity) includes a transceiver 1410, a controller 1420 and a memory 1430. The transceiver 1410, the controller 1420 and the memory 1430 are configured to perform the operations of the network function (or, the network entity) illustrated in the figures 1 to 11, or described above. Although the transceiver 1410, the controller 1420 and the memory 1430 are shown as separate entities, they may be realized as a single entity like a single chip. The transceiver 1410, the controller 1420 and the memory 1430 may be electrically connected to or coupled with each other.

[0607] The transceiver 1410 may transmit and receive signals to and from other network entities, e.g., a base station, or another network function (or, another network entity). The controller 1420 may control the network function (or, network entity) to perform functions according to one of the embodiments described above. The controller 1420 may refer to a circuitry, an ASIC, or at least one processor. In an embodiment, the operations of the network function (or, network entity) may be implemented using the memory 1430 storing corresponding program codes. Specifically, the network function (or, network entity) may be equipped with the memory 1430 to store program codes implementing desired operations. To perform the desired operations, the controller 1420 may read and execute the program codes stored in the memory 1430 by using a processor or a CPU.

[0608] While the disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents.

[0609] While the disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents.

[0610] As described above, embodiments disclosed in the specification and drawings are merely used to present specific examples to easily explain the contents of the disclosure and to help understanding, but are not intended to limit the scope of the disclosure. Accordingly, the scope of the disclosure should be analyzed to include all changes or modifications derived based on the technical concept of the disclosure in addition to the embodiments disclosed herein.

Claims

1.A method performed by a network entity in a wireless communication system, the method comprising:receiving, from a unified data management (UDM) entity, a first message for requesting an authentication for a user equipment (UE), the first message comprising a user identifier (ID) and a subscription permanent identifier (SUPI) linked to the user ID; andperforming the authentication for the UE based on the user ID and the SUPI.2.The method of claim 1, wherein the authentication for the UE is performed based on a UE registration check and a subscription data for the SUPI.3.The method of claim 1, wherein the first message further comprises an authentication, authorization and accounting (AAA) server address.4.The method of claim 1, wherein the network entity comprises an access and mobility management function (AMF) entity or a session management function (SMF) entity.5.A method performed by a unified data management (UDM) entity in a wireless communication system, the method comprising:receiving, from a network exposure function (NEF) entity, a first message for requesting an authentication for a user equipment (UE), the first message comprising a user identifier (ID) and a subscription permanent identifier (SUPI) linked to the user ID; andtransmitting, to an access and mobility management function (AMF) entity or a session management function (SMF) entity, a second message for requesting the authentication,wherein the SUPI is obtained from a user profile storage function entity.6.The method of claim 5, wherein the authentication for the UE is based on a UE registration check and a subscription data for the SUPI.7.The method of claim 5, wherein the first message further comprises an authentication, authorization and accounting (AAA) server address.8.A network entity in a wireless communication system, the network entity comprising:a transceiver; anda controller coupled with the transceiver and configured to:receive, from a unified data management (UDM) entity, a first message for requesting an authentication for a user equipment (UE), the first message comprising a user identifier (ID) and a subscription permanent identifier (SUPI) linked to the user ID, andperform the authentication for the UE based on the user ID and the SUPI.9.The network entity of claim 8, wherein the authentication for the UE is performed based on a UE registration check and a subscription data for the SUPI.10.The network entity of claim 8, wherein the first message further comprises an authentication, authorization and accounting (AAA) server address.11.The network entity of claim 8, wherein the network entity comprises an access and mobility management function (AMF) entity or a session management function (SMF) entity.12.A unified data management (UDM) entity in a wireless communication system, the UDM entity comprising:a transceiver; anda controller coupled with the transceiver and configured to:receive, from a network exposure function (NEF) entity, a first message for requesting an authentication for a user equipment (UE), the first message comprising a user identifier (ID) and a subscription permanent identifier (SUPI) linked to the user ID, andtransmit, to a network entity, a second message for requesting the authentication,wherein the SUPI is obtained from a user profile storage function entity.13.The UDM entity of claim 12, wherein the authentication for the UE is based on a UE registration check and a subscription data for the SUPI.14.The UDM entity of claim 12, wherein the first message further comprises an authentication, authorization and accounting (AAA) server address.15.The UDM entity of claim 12, wherein the network entity comprises an access and mobility management function (AMF) entity or a session management function (SMF) entity.

Images