Method for application-specific authentication to network services in a wireless network and wireless network

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. Accordingly, an embodiment of the present disclosure discloses a method performed by an application function (AF) server, the method including: receiving a first request message including a user equipment (UE) service identifier (ID) from a terminal; sending a second request message to an authentication server for requesting association information of the terminal, the second request message including the terminal ID; receiving association information of the terminal from the authentication server if the association information is searched based on the terminal ID; and verifying whether the UE service ID is associated with the terminal ID in the association information of the terminal.

Description

[Technical Field]

[0001] The present disclosure relates to wireless communications, and more particularly to a method and a wireless network for optimized application-specific authentication for network services (e.g., fifth generation (5G) services) in a wireless network. The present disclosure relates to application-specific authentication for network services in a wireless communication network. [Background technology]

[0002] 5G mobile communication technology defines a wide frequency band to enable high transmission speeds and new services, and can be implemented in frequencies below 6 GHz ("Sub 6 GHz") such as 3.5 GHz, as well as ultra-high frequency bands ("Above 6 GHz") known as millimeter wave (mmWave) such as 28 GHz and 39 GHz. Also, 6G mobile communication technology, known as the "Beyond 5G" system, is being considered for implementation in the terahertz band (e.g., 95 GHz to 3 THz) to achieve transmission speeds 50 times faster and ultra-low latency that is one-tenth of that of 5G mobile communication technology.

[0003] In the early stages of 5G mobile communications technology, the goal is to support services and meet performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). The technologies include beamforming and massive MIMO to mitigate radio wave path loss and increase radio wave transmission distance in ultra-high frequency bands, various numerology support (such as multiple subcarrier spacing operation) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial connection technology to support multiple beam transmission and wideband, definition and operation of Band-Width Part (BWP), new channel coding methods such as Low Density Parity Check (LDPC) code for large-volume data transmission and Polar Code for highly reliable transmission of control information, L2 pre-processing, and network slicing to provide dedicated networks specialized for specific services. Standardization of the technology has progressed, including slicing.

[0004] Discussions are currently underway to improve and enhance the initial 5G mobile communications technology in consideration of the services that 5G mobile communications technology is intended to support. Physical layer standardization is underway for technologies such as Vehicle-to-Everything (V2X), which aims to increase user convenience by helping autonomous vehicles make driving decisions based on their own location and status information transmitted by vehicles; New Radio Unlicensed (NR-U), which aims to operate systems in unlicensed bands in accordance with various regulatory requirements; NR terminal low-power technology (UE power saving); Non-Terrestrial Network (NTN), which is direct communication between terminals and satellites to ensure coverage in areas where communication with terrestrial networks is not possible; and positioning.

[0005] In addition, standardization is underway in the areas of radio interface architecture / protocol for technologies such as the Industrial Internet of Things (IIoT), which supports new services through collaboration and integration with other industries; Integrated Access and Backhaul (IAB), which provides nodes for expanding network service areas by integrating wireless backhaul links and access links; Mobility Enhancement, including Conditional Handover and Dual Active Protocol Stack (DAPS) handover; and Two-Step Random Access (2-step RACH for NR), which simplifies random access procedures. Standardization is also underway in the areas of system architecture / service for 5G baseline architecture (e.g., Service-Based Architecture, Service-Based Interface) for the integration of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies; and Mobile Edge Computing (MEC), which provides services based on the terminal's location.

[0006] Once 5G mobile communication systems are commercialized, the explosive increase in connected devices will be connected to communication networks, necessitating the enhancement of the functions and performance of 5G mobile communication systems and the integrated operation of connected devices.To this end, new research will be conducted on 5G performance improvement and complexity reduction using extended reality (XR), artificial intelligence (AI), and machine learning (ML) to efficiently support augmented reality (AR), virtual reality (VR), and mixed reality (MR), as well as AI service support, metaverse service support, drone communications, and more.

[0007] In addition, the development of such 5G mobile communication systems will lay the foundation for the development of new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multiple antenna transmission technologies such as full-dimensional multiple-input multiple-output (FD-MIMO), array antennas, and large-scale antennas, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using orbital angular momentum (OAM), and reconfigurable intelligent surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, AI-based communication technology that utilizes satellites and artificial intelligence (AI) from the design stage and incorporates end-to-end AI support functions to achieve system optimization, and next-generation distributed computing technology that uses ultra-high-performance communication and computing resources to realize services of a complexity that exceeds the limits of terminal computing capabilities. Summary of the Invention [Problem to be solved by the invention]

[0008] It would be desirable to provide a useful alternative for application-specific authentication (checking of associations) optimized for 5G services. [Means for solving the problem]

[0009] Therefore, according to one embodiment of the present application, a method for application-specific authentication for network services in a wireless network is disclosed. The method includes, by a network function entity of the wireless network, establishing a mapping between a service-specific identifier of a user equipment (UE) to provide access to a network service of the wireless network. Further, the method includes, by an application server, receiving a service request from the UE to access a network service provided by the application server in the wireless network. Further, the method includes, by an NF entity, authenticating at least one identity (ID) of the UE (before providing access to the service request). Further, the method includes, by the NF entity, verifying a mapping between the service-specific identifier of the service request and an already-authenticated ID of the UE to allow access to a network service provided by the application server in the wireless network.

[0010] According to one embodiment, the service specific identifier includes the UE's Subscription Permanent Identifier (SUPI), Generic Public Subscription Identifier (GPSI), Edge Enabler Client (EEC) identifier, service identifier for the MSGin5G server, and Vertical Application Layer (VAL) user identifier (ID).

[0011] According to one embodiment, the NF entity includes an authentication server, and the authentication server includes at least one of a Unified Data Management (UDM) entity, an Authentication, Authorization and Accounting (AAA) entity, an Authentication Server Function (AUSF) entity, a conf management server, and a MSGin5G configuration function entity.

[0012] According to one embodiment, the application server includes at least one of an edge server, an MSGin5G server, a V2X (Vehicle to Everything) server, an Unmanned Aerial System (UAS) server, and a SEAL (Service Enabler Architecture Layer) server.

[0013] Therefore, according to one embodiment, a method for application-specific authentication for a network service in a wireless network is disclosed. The method includes transmitting, by a UE of the wireless network, a request to an application server of the wireless network for accessing a network service provided by the application server of the wireless network. The method further includes establishing, by the UE, a secure channel between the UE and the application server after successful mutual authentication of at least one identity of the UE and the application server. The method further includes transmitting, by the UE, a service request to the application server over the secure channel. The method further includes including, by the UE, a service-specific identifier or a UE-specific identifier in the service request to the application server over the secure channel. The method further includes receiving, by the UE, a response message acknowledging successful authentication for the requested service based on the service-specific identifier or the UE-specific identifier included by the application server. The method further includes accessing, by the UE, the network service from the application server.

[0014] Therefore, according to one embodiment, a method for application-specific authentication for network services in a wireless network is disclosed. The method includes receiving, by an application server of the wireless network, a service request from a UE of the wireless network. The method further includes, in response to receiving the service request, authenticating, by the application server, a UE ID included in the service request. The method further includes, after successful mutual authentication, establishing, by the application server, a secure channel between the UE and the application server. The method further includes, by the application server, sending a response message acknowledging successful authentication and authorization of the UE by the application server. The method further includes providing, by the application server, a network service to the UE.

[0015] According to one embodiment, a service request received from a UE is authorized based on a mapping between service-specific identifiers of the UE established by an authentication server in the wireless network.

[0016] Thus, according to one embodiment, a wireless network for application-specific authentication to network services in a wireless network is disclosed. The wireless network includes a network function entity and an application server. The network function entity includes an application-specific authentication controller coupled to a memory and a processor. The application-specific authentication controller is configured to establish a mapping between service-specific identifiers of UEs to provide access to network services in the wireless network and store the mapping in memory. The application server includes the application-specific authentication controller coupled to the memory and the processor.

[0017] The application specific authentication controller of the application server is configured to receive a service request from the UE for accessing a network service provided by the application server in the wireless network, and to include a service specific identifier or a UE specific identifier in the service request to the application server via a secure channel. The application specific authentication controller of the network function entity is configured to authenticate the UE before providing access to the network service provided by the application server in the wireless network. The application specific authentication controller of the network function entity is configured to verify a mapping between the service specific identifier of the request and an already authenticated ID of the UE to allow access to the network service provided by the application server in the wireless network.

[0018] Therefore, according to one embodiment, a UE for application-specific authentication for network services in a wireless network is disclosed. The UE includes an application-specific authentication controller coupled to a memory and a processor. The application-specific authentication controller is configured to send a request to an application server of the wireless network to access a network service provided by the application server of the wireless network. Further, the application-specific authentication controller is configured to establish a secure channel between the UE and the application server after successful mutual authentication of the UE by the application server.

[0019] The application-specific authentication controller is further configured to send a service request to the application server over the secure channel. The application-specific authentication controller is further configured to include a service-specific identifier or a UE-specific identifier in the service request to the application server over the secure channel. The application-specific authentication controller is further configured to receive a response message acknowledging successful authorization for the requested service by the application server. The application-specific authentication controller is further configured to access a network service from the application server.

[0020] Therefore, according to one embodiment, an application server for application-specific authentication for network services in a wireless network is disclosed. The application server includes an application-specific authentication controller coupled to a memory and a processor. The application-specific authentication controller is configured to receive a service request from a UE in the wireless network. The application-specific authentication controller is further configured to authenticate a UE ID included in the request in response to receiving the service request. The application-specific authentication controller is further configured to establish a secure channel between the UE and the application server (e.g., an edge server or an MSGin5G server) after successful mutual authentication. The application-specific authentication controller is further configured to send a response message acknowledging successful authentication of the UE and the application server. The application-specific authentication controller is further configured to provide the network service to the UE. [Effects of the Invention]

[0021] A primary objective of embodiments of the present application is to provide a method and a wireless network for optimized application-specific authentication for 5G services in a wireless network.

[0022] Another objective of the present embodiment is to manage the identity of the UE to verify the authorization (association check) of the UE when the UE requests service access.

[0023] Another object of the embodiments of the present application is to provide the UE's associated ID to the AF, which may be located inside or outside the PLMN to protect privacy.

[0024] Another objective of embodiments of the present application is to maintain association / mapping of UE identifiers with an OAuth server, authentication server or identity management server.

[0025] The above and other aspects of the present embodiments will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating preferred embodiments and various specific details thereof, is given by way of illustration and not by way of limitation. Many changes and modifications may be made within the scope of the present embodiments, and the present embodiments include all such modifications.

[0026] Prior to the detailed description below, it may be advantageous to set forth definitions of certain words and phrases used throughout this patent document: the terms "include" and "comprise" and their derivatives mean including, without limitation; the term "or" means and / or; the terms "associated with" and "associated therewith" and their derivatives can mean include, contain, included within, contained within, interconnected with, connected to or with, coupled to or with, in communication with, cooperate with, interleaved, collocated, adjacent to, bounded by, possessing, etc.; the term "controller" means any device, system, or portion thereof that controls at least one operation, and such a device may be embodied in hardware, firmware, or software, or a combination of at least two of these. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely.

[0027] It should be noted that various functions described below may be embodied or supported by one or more computer programs, each of which is formed from computer-readable program code and executed by a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, associated data, or portions thereof adapted for implementation by appropriate computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, compact disc (CD), digital video disc (DVD), or any other type of memory. "Non-transitory" computer-readable medium excludes wired, wireless, optical, or other communication links that convey transient electrical or other signals. Non-transitory computer-readable media include media that can permanently store data and media that can store data and be later overwritten, such as re-recordable optical disks or erasable memory devices.

[0028] Definitions for certain words or phrases are provided throughout this patent document, and those of ordinary skill in the art should understand that in many, if not most, cases, such definitions apply to prior as well as future uses of the defined words and phrases.

[0029] The present disclosure is illustrated in the accompanying drawings, in which like reference characters designate corresponding parts throughout the various drawings. Embodiments of the present application will be better understood from the following description taken in conjunction with the drawings, in which: [Brief explanation of the drawings]

[0030] [Figure 1]1 illustrates a basic network model of an AKMA according to the prior art and an interface between the basic network models of the AKMA. [Figure 2a] 1 illustrates an AKMA architecture using a reference point representation according to the prior art. [Figure 2b] 1 illustrates an AKMA architecture using a reference point representation according to the prior art. [Figure 3] 1 illustrates a sequence flow diagram for a generalized method for access token-based authentication between a UE and any AF, where AF refers to an EDGE server / MSGin5G server / any VAL server, according to an embodiment disclosed herein. [Figure 4] 1 illustrates a sequence flow diagram for authenticating a UE by providing an A-KID when the AF is outside a PLMN hosted by an operator or a third party, according to an embodiment disclosed herein. [Figure 5] 10 illustrates a sequence flow diagram for authenticating a UE by providing an A-KID when the AF is hosted inside the PLMN, i.e., in the operator domain, according to an embodiment disclosed herein. [Figure 6] 1 illustrates various hardware components of an NF entity (e.g., an authentication server) according to embodiments disclosed herein. [Figure 7] 2 illustrates various hardware components of a UE according to embodiments disclosed herein. [Figure 8] 1 illustrates various hardware components of an application server (e.g., an edge server or an MSGin5G server) according to an embodiment disclosed herein. [Figure 9] 1 illustrates a flow diagram of a method for application-specific authentication to network services in a wireless network according to an embodiment disclosed herein. [Figure 10] 1 illustrates a flow diagram of a method implemented by a UE for application-specific authentication to network services in a wireless network according to an embodiment disclosed herein. [Figure 11] 1 illustrates a flow diagram of a method implemented by an application server (e.g., an edge server or MSGin5G server) for application-specific authentication to network services in a wireless network according to an embodiment disclosed herein. [Figure 12] 1 illustrates a sequence flow diagram of a method implemented by an MSGin5G server or edge server for application-specific authentication to network services in a wireless network according to an embodiment disclosed herein. DETAILED DESCRIPTION OF THE INVENTION

[0031] 1-12 described below, and the various embodiments used in this patent document to explain the principles of the present disclosure, are for illustrative purposes only and should not be construed as limiting the scope of the present disclosure in any manner. Those of ordinary skill in the art will understand that the principles of the present disclosure may be embodied in any suitably arranged system or device.

[0032] The embodiments of the present application and their various features and advantageous details will be more fully described with reference to the non-limiting embodiments illustrated in the accompanying drawings and described in detail in the following description. Descriptions of well-known components and processing techniques are omitted to avoid unduly obscuring the embodiments of the present application. Furthermore, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments may be combined with one or more other embodiments to form new embodiments. The term "or" used herein means a non-exclusive "or" unless otherwise specified. The examples used herein are merely intended to facilitate understanding of the manner in which the embodiments of the present application may be implemented and to enable those of ordinary skill in the art to implement the embodiments of the present application. Therefore, the examples should not be construed as limiting the scope of the embodiments of the present application.

[0033] As is conventional in the art, the embodiments may be described and illustrated in terms of blocks having described functions or functions. Such blocks, which may be referred to herein as units or modules, may be physically embodied by analog and / or digital circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc., and may optionally be driven by firmware. The circuitry may be embodied, for example, by one or more semiconductor chips or on a substrate support such as a printed circuit board. The circuitry constituting the blocks may be embodied by dedicated hardware, a processor (e.g., one or more programmed microprocessors and associated circuitry), or a combination of dedicated hardware performing some of the block's functions and a processor performing other of the block's functions. Each block of the embodiments may be physically separated as two or more interacting discrete blocks without departing from the scope of the present disclosure. Similarly, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the present disclosure.

[0034] The accompanying drawings are used to facilitate understanding of various technical features, and it should be understood that the embodiments presented in the present application are not limited by the accompanying drawings. Therefore, the present disclosure should be interpreted as extending to modifications, equivalents, and alternatives in addition to those specifically described in the accompanying drawings. In the present application, terms such as "first" and "second" may be used to describe various elements, but such elements should not be limited by such terms. Such terms are generally only used to distinguish one element from another.

[0035] The terms "NF entity" and "authentication server" are used interchangeably in the patent disclosure. The terms "application server," "edge server," and "MSGin5G server" are used interchangeably in the patent disclosure.

[0036] Accordingly, an embodiment of the present application discloses a method for application-specific authentication for network services in a wireless network. The method includes, by a network function entity of the wireless network, establishing a mapping between a service-specific identifier of a user equipment unit (UE) to provide access to a network service of the wireless network. The method further includes, by an application server, receiving a service request from the UE to access a network service provided by the application server in the wireless network. The method further includes, by an NF entity, authenticating at least one identity (ID) of the UE (before providing access to the service request). The method further includes, by the NF entity, verifying the mapping between the service-specific identifier of the service request and an already-authenticated ID of the UE to allow access to a network service provided by the application server in the wireless network.

[0037] In an embodiment, upon receiving a service access request message (having an application ID, e.g., a UE service ID) from the UE, the AF requests the authentication server to provide associated information of the UE. The request message of the AF includes an authentication identity (e.g., the UE's SUPI obtained after successful completion of AKMA).

[0038] The authentication server retrieves the association information using the SUPI of the UE and provides the association information to the AF. Upon receiving the association information, the AF verifies whether the application ID received in the service request is associated with the UE's authenticity verification identity in the association information. If the verification is successful, i.e., if the application ID received in the service request is associated with the UE's authenticity verification identity in the association information, the AF provides access to the service. If the verification is unsuccessful, i.e., if the application ID received in the service request is not associated with the UE's authenticity verification identity in the association information, the AF denies access to the service. In order to use the application layer ID to obtain a service, the application layer ID assigned to the UE (or subscriber or user) is associated with one or more permanent IDs (unique and permanently assigned global identities assigned by the MNO, such as the SUPI, IMSI, IMPI, etc.).

[0039] The provided method uses association information to enable authentication between MSGin5G clients / VAL clients and MSGin5G servers / VAL servers.

[0040] The provided method further enables validation of the UE request based on a UE-specific identifier and / or a service-specific identifier sent in the service access request.

[0041] The provided method may be used for application-specific authentication optimized for 5G services. The method includes managing a UE's identity to verify the UE's authentication when the UE requests service access. The method further includes providing authorized identities while the AF is located inside or outside a public land mobile network (PLMN). The method further includes maintaining a mapping of associated identifiers in an OAuth server, an authentication server, or an identity management server.

[0042] In an embodiment, the present disclosure provides that, in order to use the application layer ID to obtain services, the application layer ID assigned to the UE 110 (or subscriber or user) is associated with one or more permanent IDs (unique and permanently assigned global identities assigned by the MNO, such as SUPI, IMSI, IMPI, etc.) Once the authenticity of the permanent IDs is verified by the network, the network can check / verify the association and allow / authorize the UE 110 to obtain services using the associated application layer ID.

[0043] The terms "service request" and "registration request" are used interchangeably and refer to the initial message from the UE to the application server to access a service.

[0044] Generally, 3GPP (Third Generation Partnership Project) defines security features and mechanisms to support aspects of authentication and key management for applications based on subscription credentials in 5G systems, as defined in TS 33.501. Figure 1 illustrates the basic network model of Authentication and Key Management for Applications (AKMA) according to the prior art disclosed herein, as well as interfaces between the basic network models of AKMA. Figures 2a and 2b illustrate the AKMA architecture using reference point representation according to the prior art.

[0045] The AKMA framework is utilized for various services such as 5GC edge computing (EDGE), proximity-based services (ProSe), and MSG in 5G services. Currently, the AKMA framework defines static authentication, in which a UE identifier must be provided to the AF 170 (e.g., AKMA AF) in order for the AF 170 to authorize the UE 110 (e.g., for billing and / or service authorization purposes). When the AKMA AF is in an operator network, the AKMA Anchor Function (AAnF) 130 provides a Subscription Permanent Identifier (SUPI) directly to the AKMA AF. When the AKMA AF is outside the operator network, the AAnF 130 provides the SUPI to the Network Exposure Function (NEF) 120. The NEF 120 converts the SUPI to a generic public subscription identifier (GPSI) (external ID) and transmits the GPSI to the AF outside the operator network. However, the authorization procedure provided by the AKMA framework is not sufficient to have service-specific authentication using a service-specific identity. The problems for each use case are given below.

[0046] The EDGE service currently uses static authorization for authentication between the EDGE enabler client and the EDGE configuration server.

[0047] Using the authorization framework provided by AKMA, it is not clear how a UE identifier can be associated or linked to a particular service and / or application and / or EDGE enabler client.

[0048] The network does not store the EEC ID, as it is not within the scope of current technology to handle the EEC ID or VAL ID as part of the subscription data.

[0049] In the MSGin5G service, the MSGin5G service utilizes the UE Service ID (same as the VAL User ID in TS 23.434) during authentication and authorization. Using the authorization framework provided by AKMA, it is unclear how a UE identifier can be associated or linked to a particular service and / or application and / or MSG client.

[0050] As shown in Figures 1, 2a, and 2b, the AKMA Anchor Function (AAnF) 130 is deployed as a standalone function. The operator can choose to deploy the AAnF 130 together with the Authentication Server Function (AUSF) 150 or the NEF 120 depending on the deployment scenario. The AKMA service requires a new logical entity called the AKMA Anchor Function (AAnF) 130. The AAnF 130 is the anchor function of the Home PLMN (HPLMN). The AAnF 130 stores the AKMA anchor key (KAKMA) and SUPI for the AKMA service received from the AUSF 150 after the UE 110 successfully completes 5G basic authentication. The AAnF 130 generates key material used between the UE 110 and the Application Function (AF) 170 and maintains the UE AKMA context. The AAnF 130 sends the SUPI of the UE 110 to the AF 170 or the NEF 120 located within the operator's network.

[0051] The AF 170, with additional functionality, is defined in TS 23.501. The AF 170 with AKMA services uses the A-KID to enable requests from the AAnF 130 for an AKMA application key, called the KAF. The AF 170 may be authenticated and authorized by the operator network before providing the KAF to the AF 170. The AF 170, located inside the operator network, performs AAnF selection.

[0052] The NEF 120, with additional functionality, is defined in TS 23.501. The NEF 120 enables and authorizes external AFs to evaluate AKMA services and forwards requests towards the AAnF 130. The NEF 120 performs AAnF selection. The AUSF 150, with additional functionality, is defined in TS 23.501. The AUSF 150 provides the SUPI and AKMA key materials (A-KID, KAKMA) of the UE 110 to the AAnF 130. The AUSF 150 performs AAnF selection. The UDM 140, with additional functionality, is defined in TS 23.501. The UDM 140 stores the subscriber's AKMA subscription data.

[0053] The following interfaces are included in the AKMA network architecture: - Nnef: Service-based interface indicated by NEF120; - a service-based interface represented by Nudm:UDM140, and - Naanf: Service-based interface indicated by AAnF130.

[0054] The AKMA architecture reuses the following reference points from 5GC for the execution of the basic authentication procedure: - N1: Reference point between the UE 110 and the Access and Mobility Management Function (AMF) 160; N2: (R) Reference point between AN180 and AMF160; - N12: Reference point between AMF160 and AUSF150; - N13: Reference point between UDM140 and AUSF150; and - N33: Reference point between NEF120 and external AF.

[0055] The AKMA architecture defines the following reference points: - N61: Reference point between AAnF130 and AUSF150; - N62: Reference point between AAnF130 and internal AF; - N63: Reference point between AAnF130 and NEF120; and - Ua*: Reference point between UE 110 and AF 170.

[0056] Therefore, it is desirable to provide a useful alternative for application-specific authentication (checking of associations) optimized for 5G services.

[0057] Referring now to the drawings, and in particular to Figures 3 to 12, a preferred embodiment will be shown.

[0058] 3 illustrates a sequence flow diagram of a generalized method for authentication between a UE 110 and any application function (AF) 170, where AF 170 refers to an EDGE server 210 / MSGin5G server 200 / any VAL server, etc., according to an embodiment disclosed herein.

[0059] In phase 0, the authentication server 190 is pre-configured with the UE's associated identities (mapping between / to SUPI (UE's globally unique 5G subscription permanent identifier): GPSI (external ID): EEC ID (one or more EDGE client IDs): UE service ID (MSGin5G client ID): V2X service ID: CAA level UAV ID: VAL user ID (all VAL IDs if SEAL framework is supported).

[0060] In an embodiment, for purposes of illustration, it is proposed that the service specific identifier may be an EEC ID (for EDGE) and / or a UE service ID (for MSGin5G services) and / or a VAL user ID (for industries utilizing the SEAL enabler security framework) and / or a VAL service ID (for VAL services) and / or a MSGin5G service ID (for MSGin5G services).

[0061] In another embodiment, the GPSI may be a service specific identifier, where the GPSI type indicates for which service it is being used.

[0062] The terms "Client ID", "External ID", "Service ID", "Public ID" and "Application ID" are used interchangeably throughout this disclosure and refer to an identity used by a UE at the application layer to uniquely identify a client in the application provider domain. The Mobile Network Operator (MNO) and / or the service / application provider (which may be a third party) are responsible for allocating service / application identifiers.

[0063] The OAuth server may be a third party entity or may be an entity hosted by a mobile network operator. In an embodiment, the OAuth server may be an EDGE service provider (in the case of EDGE) and / or an identity management server hosted by the SEAL framework or MNO and / or an NRF and / or NEF 120 and / or authentication server 190 and / or AKMA Anchor Function (AAnF) 130 and / or AUSF 150 specified in TS 33.501 for service-based authentication between NF consumers and NF producers.

[0064] In an embodiment, the identity mapping for the application is maintained solely by the appropriate OAuth server, meaning that multiple entities maintain the corresponding binding of subscription IDs to application IDs in the network, and the UE (application client) requests the appropriate OAuth server to provide the associated token to gain application access.

[0065] In another embodiment, if the AKMA or service / application supports the CAPIF framework, the CAPIF core functionality may be an OAuth server.

[0066] In an embodiment, in step 1, the UE 110 requests the authentication server 190 to provide an access token to access services provided by the EDGE server 210 and / or the MSGin5G server 200.

[0067] In step 2, based on the received access token request, authentication server 190 initiates authentication with UE 110. Client-server certificate-based TLS authentication is used for illustrative purposes. This disclosure does not limit the authentication method used between UE 110 and authentication server 190.

[0068] In step 3, if authentication is successful, the authentication server 190 generates an access token based on the pre-configured association / mapping between the received request and SUPI (UE ID); GPSI (External ID): EEC ID (EDGE Client ID): UE Service ID (MSGin5G Client ID): VAL User ID (all VAL IDs if SEAL framework is supported): VAL Service ID (for VAL service): MSGin5G Service ID (for MSGin5G service): V2X Service ID; CAA Level UAV ID.

[0069] In an embodiment, the UE Service ID acts as the VAL User ID.

[0070] In another embodiment, the service identifier of the MSGin5G service acts as the VAL service ID.

[0071] The access token (Token-A) contains a service-specific claim, i.e., a link between SUPI (UE ID): GPSI (External ID): EEC ID (EDGE Client ID): UE Service ID (MSGin5G Client ID): VAL User ID (all VAL IDs if the SEAL framework is supported). In an embodiment, this access token is utilized by the client to access services from EDGE, MSGin5G, or any vertical service if token validation is successful at the server / network / service provider domain. The authentication server 190 sends the access token to the UE 110 in a response message. In an embodiment, a sequence of messages 1-3 may be exchanged, i.e., after a successful authentication, the UE 110 requests a token.

[0072] For purposes of example, when UE 110 desires to access the MSG in 5G service, UE 110 sends a service request to the MSG server.

[0073] Before presenting the received access token (Token-A) to the MSG server, a secure channel is established between the UE 110 and the MSG server. A TLS secure tunnel based on a pre-shared key (PSK) may be one option. Authentication between the UE 110 and the MSG server 200 is completed based on TLS.

[0074] In step 4, upon successful authentication (verification of the authenticity of the SUPI), the client initiates a service access request. The access token received from the authentication server 190 is sent in the request.

[0075] In step 5, the MSG server validates the access token (Token-A) based on pre-configured mapping information available in local policy. In another embodiment, the authentication server 190 provides a token validation function, and the MSG server utilizes this service. In one embodiment, the MSG server validates the request sent by the UE 110 for an access token (authorization request) (verifying whether the ID included in the request message is associated with a SUPI). More specifically, whether the client ID in the request is present in the UE's 110 token (i.e., whether there is a mapping / association between the UE's SUPI and the client ID) is mapped to the A-KID and / or SUPI and / or GPSI.

[0076] In another embodiment, the MSG server has a dedicated interface with the core network entity. The MSG server contacts the UDM 140 / NRF / NEF 120 / AAnF 130 / AMF 160 / AUSF 150 to validate the received access token. In one embodiment, the UDM 140 stores the mapping information in the subscription data of each service. In another embodiment, the NRF / NEF 120 / AAnF 130 / AMF 160 / AUSF 150 stores the mapping information (UE ID association) in their local policy.

[0077] After successful verification of the client's access token and authorization request (checking the identity association), the MSG server sends a response message acknowledging the MSG server's successful authentication.

[0078] In another embodiment, the UE 110 requests the authentication server 190 to provide an access token in order to access the services provided by the EDGE server 210 .

[0079] Based on the received request for an access token, which includes the A-KID and a service name / code indicating that the token request is for an EDGE service, the authentication server 190 initiates authentication with the UE 110. The UE 110 registers with the 5G network and retrieves AKMA capability information from the 5G network. The AKMA capability indicates that the AF 170 supports AKMA use, and therefore the UE 110 and the 5G network generate AKMA as specified in TS 33.535. The AKMA service is used for illustrative purposes only. As an alternative to the AKMA service, GBA or client-server certificate-based TLS authentication can be used. This disclosure does not limit the authentication method used between the UE 110 and the authentication server 190. In other embodiments, the UE 110 uses a service name / code. The service name / code can take formats such as "EDGE," "MSGin5G," and "VAL service name" (where VAL refers to any vertical service, such as V2X).

[0080] Upon successful authentication (verification of the authenticity of the A-KID and SUPI using the AKMA service), the authentication server 190 generates an access token (Token-B) based on the received request and the pre-configured association / mapping between SUPI (UE ID): GPSI (external ID): EEC ID (EDGE client ID): A-KID (from AKMA): VAL service ID (for VAL service): MSGin5G service ID (for MSGin5G service): V2X service ID: CAA level UAV ID.

[0081] In another embodiment, the UE Service ID acts as the VAL User ID.

[0082] In another embodiment, the service identifier of the MSGin5G service acts as the VAL service ID.

[0083] The access token (Token-B) contains only the mappings associated with the service-specific claim, i.e., the EDGE service: SUPI (UE ID): GPSI (External ID): EEC ID (EDGE Client ID): A-KID (from AKMA): VAL Service ID (for VAL service): MSGin5G Service ID (for MSGin5G service). The authentication server 190 sends the access token to the UE 110 in a response message.

[0084] In an embodiment, the sequence of messages 9-11 may be exchanged, ie, after a successfully authenticated UE 110 requests a token.

[0085] The UE 110 sends a service request to the EDGE server 210 .

[0086] Before presenting the received access token (Token-B) to the EDGE server 210, a secure channel is established between the UE 110 and the EDGE server 210. A TLS secure tunnel based on a pre-shared key (an application key generated as part of the AKMA service) may be one option. Authentication between the UE 110 and the EDGE server 210 is completed based on TLS. Upon successful authentication, the client initiates a service access request (including the application ID).

[0087] The access token (Token-B) received from the authentication server 190 is sent in the request.

[0088] The EDGE server 210 validates the access token (Token-B) based on a pre-configured security certificate (e.g., a root certificate). In another embodiment, the authentication server 190 provides a token validation function, and the EDGE server 210 utilizes the validation function. In one embodiment, the EDGE server 210 verifies the request sent by the UE 110 for an access token authorization request. More specifically, whether the client ID in the request exists in the UE 110's token (i.e., whether there is a mapping / association between the UE's SUPI and the client ID) is mapped to the A-KID and / or SUPI and / or GPSI and / or VAL service ID and / or MSGin5G service ID and / or UE service ID.

[0089] In another embodiment, the EDGE server 210 has a dedicated interface with the core network entities. The MSG server contacts the UDM 140 / NRF / NEF 120 to validate the received access token. In an embodiment, the UDM 140 stores the mapping information in the subscription data for each service.

[0090] In another embodiment, the NRF / NEF 120 stores the mapping information in its local policy.

[0091] After successful verification of the client's access token and authorization request, the EDGE server 210 sends a response message acknowledging successful authentication of the EDGE server 210.

[0092] FIG. 4 illustrates a sequence flow diagram when the AF 170 is outside a PLMN hosted by an operator or a third party, according to an embodiment disclosed herein.

[0093] In Phase 0, as a prerequisite, the OAuth server needs to be pre-configured with a mapping between A-KID, SUPI, GPSI, and Client ID.

[0094] In an embodiment, for the examples provided, the client ID may be an EEC ID (in the case of EDGE) and / or a UE service ID (in the case of MSGin5G services) and / or a VAL user ID (in the case of industries utilizing the SEAL enabler security framework).

[0095] The terms "client ID," "external ID," and "application ID" are used interchangeably throughout this disclosure and refer to an identity used by UE 110 at the application layer to uniquely identify a client in an application provider domain.

[0096] The OAuth server may be a third-party entity or an entity hosted by a mobile network operator. In an embodiment, the OAuth server may be an identity management server hosted by an EDGE service provider (in the case of EDGE) and / or the SEAL framework and / or an NRF and / or NEF 120 and / or authentication server 190 specified in TS 33.501 for service-based authentication between NF consumers and NF producers.

[0097] In an embodiment, the identity mapping for the application is maintained solely by the appropriate OAuth server, meaning that multiple entities maintain corresponding bindings of subscription identities and application identities in the network, and the UE (application client) requests the appropriate OAuth server to provide the associated token to gain application access.

[0098] In another embodiment, if the AKMA or service / application supports the CAPIF framework, the CAPIF core functionality may be an OAuth server.

[0099] In 0b, the UE 110 registers with the 5G network and retrieves AKMA capability information from the 5GC. The AKMA capability indicates that the AF 170 supports AKMA use, and therefore the UE 110 and 5GC generate AKMA as specified in TS 33.535. The AKMA service is used for example purposes only. As an alternative to the AKMA service, GBA or client-server certificate-based TLS authentication can be used.

[0100] Mutual authentication is initiated based on the client and server certificates established using TLS between the client and the OAuth server.

[0101] After successful establishment of the TLS session, the client sends an access token request message to the OAuth server according to the OAuth 2.0 specification. In an embodiment, the request includes the A-KID derived as part of step 0b.

[0102] The OAuth server validates the access token request as specified in the OAuth 2.0 specification. In other embodiments, the OAuth server validates the request based on a pre-configured mapping between the A-KID and a SUPI or GPSI or client ID. In embodiments, a client may first register with the OAuth server before obtaining an access token. In embodiments, the client is issued a client identifier. The client identifier indicates the client registration to the OAuth server and allows the OAuth server to reference parameters associated with that client registration when an access token is requested.

[0103] In an embodiment, the access token is generated by an OAuth server. The access token is opaque to the client and is consumed by an application function (e.g., an EDGE configuration server, MSGin5G server 200, or any line-of-business application layer server). The access token may be encoded as a JSON Web Token as defined in IETF RFC 7519. The access token includes the JSON Web Digital Signature profile defined in IETF RFC 7515. In an embodiment, an extension of the standard claims defined in IETF RFC 7662 with additional claims is provided, as shown in Table 1 below.

[0104] Table 1. Parameters and Descriptions

[0105] [Table 1]

[0106] The OAuth server sends the generated access token in a token response message.

[0107] The UE 110 initiates an application session establishment procedure. The UE 110 communicates with the AF 170 to negotiate a KAF key owned by both the UE and the AF 170. The UE 110 and the AF 170 establish a TLS secure tunnel based on the key KAF. Authentication between the UE 110 and the AF 170 is completed based on TLS.

[0108] Upon successful authentication, the client initiates a service access request. The access token received from the OAuth server is sent in the request.

[0109] The AF 170 validates the access token based on the SUPI or GPSI received from the AAnF 130. In another embodiment, the OAuth server provides the token validation function. In one embodiment, the AF 170 validates the request sent by the client for an authorization request for an access token. More specifically, whether the client ID in the request is present in the UE's 110 token (i.e., whether there is a mapping between the UE's SUPI and the client ID) is mapped to the A-KID and / or SUPI and / or GPSI.

[0110] After successful validation of the client's access token and authorization request, the AF 170 sends a response message acknowledging the successful authentication of the AF 170.

[0111] FIG. 5 illustrates a sequence flow diagram when the AF 170 is hosted inside the PLMN, i.e., in the operator domain, according to the embodiments disclosed herein.

[0112] In phase 0a, as a prerequisite, the OAuth server needs to be pre-configured with a mapping between A-KID, SUPI, GPSI, and client ID.

[0113] In an embodiment, the client ID may be an EEC ID (for EDGE) or a UE service ID (for MSGin5G services) or a VAL user ID (for industries utilizing the SEAL enabler security framework).

[0114] In an embodiment, the UE Service ID acts as the VAL User ID.

[0115] In another embodiment, the service identifier of the MSGin5G service acts as the VAL service ID.

[0116] The OAuth server may be a third-party entity or may be an entity hosted by the operator network. In an embodiment, the OAuth server may be an identity management server hosted by the EDGE service provider (in the case of EDGE) or the SEAL framework or NRF specified in TS 33.501 for service-based authentication between NF consumers and NF producers.

[0117] In another embodiment, if the AKMA or service / application supports the CAPIF framework, the CAPIF core functionality may be an OAuth server.

[0118] In step 0b, the UE 110 registers with the 5G network and retrieves AKMA capability information from the 5GC. The AKMA capability indicates that the AF 170 supports AKMA use, and therefore the UE 110 and the 5GC generate AKMA as specified in TS 33.535. The AKMA service is used for illustrative purposes only. As an alternative to the AKMA service, GBA or client-server certificate-based TLS authentication can be used.

[0119] Mutual authentication is initiated based on the client and server certificates established using TLS between the client and the OAuth server.

[0120] After successful establishment of the TLS session, the client sends an access token request message to the OAuth server according to the OAuth 2.0 specification. In an embodiment, the request includes a client ID. In an embodiment, the client may first register with the OAuth server before obtaining an access token. In an embodiment, the client is issued a client identifier by means not specified in this disclosure. The client identifier indicates the client registration to the OAuth server and allows the OAuth server to reference parameters associated with that client registration when an access token is requested.

[0121] The OAuth server validates the access token request as specified in the OAuth 2.0 specification. In another embodiment, the OAuth server validates the request based on a pre-configured mapping between the SUPI or GPSI and the client ID.

[0122] In an embodiment, the access token is generated by the OAuth server. The access token is opaque to the client and is consumed by an application function (e.g., an EDGE configuration server, MSGin5G server 200, or any line-of-business application layer server). The access token may be encoded as a JSON Web Token as defined in IETF RFC 7519. The access token includes the JSON Web Digital Signature profile defined in IETF RFC 7515. In an embodiment, an extension of the standard claims defined in IETF RFC 7662 with additional claims is provided, as shown in Table 2 below.

[0123] Table 2. Parameters and Descriptions

[0124] [Table 2]

[0125] The OAuth server sends the generated access token in a token response message.

[0126] The UE 110 initiates an application session establishment procedure. The UE 110 communicates with the AF 170 to negotiate a KAF key owned by both the UE and the AF 170. The UE 110 and the AF 170 establish a TLS secure tunnel based on the key KAF. Authentication between the UE 110 and the AF 170 is completed based on TLS.

[0127] Upon successful authentication, the client initiates a service access request. The access token received from the OAuth server is sent in the request.

[0128] The AF 170 validates the access token based on the SUPI or GPSI received from the AAnF 130. In another embodiment, the OAuth server provides the token validation functionality. In an embodiment, if the AF 170 possesses the necessary credentials (e.g., a root certificate) to validate the token, the AF 170 validates the request sent by the client for authorization of the access token.

[0129] After successful verification of the client's access token and authorization request, the AF 170 sends a response message to the UE 110 acknowledging the successful authentication of the AF 170.

[0130] In an embodiment, for privacy reasons, when the AF 170 is located outside the PLMN, the Token-B may not include a permanent ID (e.g., SUPI), and the token request includes only a temporary ID such as the A-KID and associated application IDs (GPSI (External ID): EEC ID (EDGE Client ID)), and a VAL user ID.

[0131] In an embodiment, information about whether the AF 170 is external or internal to the PLMN is identified by the OAuth server using a service code or based on the AF ID (provided by the client in the token request message) or application ID.

[0132] In one embodiment, when the AF 170 is located outside the PLMN, the token is used to verify the associated identity. In this case, the token request does not include the UE's permanent identity (e.g., SUPI), but includes the associated application identity (e.g., GPSI) and a verified identity (e.g., A-KID). The AF 170, which must verify the associated identity, requests the authentication server 190 to verify the token request. The authentication server 190 retrieves the identity association information using the verified identity (e.g., A-KID).

[0133] In an embodiment, the associated identity check is performed using association information when the AF 170 is located inside the PLMN. In this case, the association information is provided to the AF 170 by the authentication server 190, and the AF server verifies the validity of the association in a service request message. Upon receiving a service access request message (having an application ID, e.g., a UE service ID) from the UE 110, the AF 170 requests the authentication server 190 to provide the association information of the UE 110. The request message of the AF 170 includes an authenticity verification identity (e.g., the UE's SUPI obtained after successful completion of the AKMA).

[0134] The authentication server 190 retrieves association information using the SUPI of the UE 110 and provides the association information to the AF 170. Upon receiving the association information, the AF 170 verifies whether the application ID received in the service request is associated with the UE's authenticity verification identity in the association information. If the verification is successful, i.e., if the application ID received in the service request is associated with the UE's authenticity verification identity in the association information, the AF 170 provides access to the service. If the verification is unsuccessful, i.e., if the application ID received in the service request is not associated with the UE's authenticity verification identity in the association information, the AF 170 denies access to the service.

[0135] 6 illustrates various hardware components of an NF entity or authentication server 600 according to an embodiment disclosed herein. The authentication server 600 may be, for example, but not limited to, a UDM entity, an AAA entity, an AUSF entity, a Conf management server, and a MSGin5G configuration function entity. In an embodiment, the authentication server 600 includes a processor 610, a communicator 620, a memory 630, and an application-specific authentication controller 640. The processor 610 is coupled to the communicator 620, the memory 630, and the application-specific authentication controller 640.

[0136] The application specific authentication controller 640 establishes a mapping between the service specific identifiers of the UE 110 to provide access to network services in the wireless network 1000 and stores the mapping in the memory 630. Furthermore, the application specific authentication controller 640 authenticates the UE 110 before providing access to network services provided by an application server in the wireless network 1000, by receiving a service request from the UE 110 for the application server to access the network services provided by the application server in the wireless network. The application specific authentication controller 640 verifies the mapping between the service specific identifier included in the request and the ID of the already authenticated UE 110 to allow access to the network services provided by the application server in the wireless network 1000.

[0137] The application specific authentication controller 640 may be physically embodied in analog and / or digital circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, etc., and may optionally be driven by firmware.

[0138] Additionally, processor 610 is configured to execute instructions stored in memory 630 to perform various processes. Communicator 620 is configured to communicate internally between internal hardware components and with external devices through one or more networks. Memory 630 also stores instructions executed by processor 610. Memory 630 may include a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, flash memory, an electrically programmable memory (EPROM), or an electrically erasable and programmable (EEPROM) form of memory. Note that memory 630 may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may mean that the storage medium is not embodied by a carrier wave or propagated signal. However, the term "non-transitory" should not be interpreted to mean that memory 630 is non-removable. In certain examples, a non-transitory storage medium may store data that may be changed over time (e.g., random access memory (RAM) or cache).

[0139] 6 illustrates various hardware components of authentication server 600, it should be understood that other embodiments are not limited in this regard. In other embodiments, authentication server 600 may include fewer or more components. Furthermore, component labels and names are used for illustrative purposes only and do not limit the scope of the present disclosure. One or more components may be combined together to perform the same or substantially similar functions in authentication server 600.

[0140] 7 illustrates various hardware components of a UE 110 according to an embodiment disclosed herein. In an embodiment, the UE 110 includes a processor 710, a communicator 720, a memory 730, and an application-specific authentication controller 740. The processor 710 is coupled to the communicator 720, the memory 730, and the application-specific authentication controller 740.

[0141] The application-specific authentication controller 740 sends a request to an application server of the wireless network 1000 to access a network service provided by the application server of the wireless network. Furthermore, the application-specific authentication controller 740 establishes a secure channel between the UE 110 and the application server after successful mutual authentication of the UE 110 by the application server. Furthermore, the application-specific authentication controller 740 sends a service request to the application server via the secure channel. Furthermore, the application-specific authentication controller 740 includes a service-specific identifier or a UE-specific identifier in the service request to the application server via the secure channel. Furthermore, the application-specific authentication controller 740 receives a response message from the application server acknowledging successful authorization for the requested service. Furthermore, the application-specific authentication controller 740 accesses the network service from the application server.

[0142] The application specific authentication controller 740 may be physically embodied in analog and / or digital circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, etc., and may optionally be driven by firmware.

[0143] Further, processor 710 is configured to execute instructions stored in memory 730 to perform various processes. Communicator 720 is configured to communicate internally between internal hardware components and with external devices over one or more networks. Memory 730 also stores instructions executed by processor 710. Memory 730 may include a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, flash memory, an electrically programmable memory (EPROM), or an electrically erasable and programmable (EEPROM) form of memory. Note that memory 730 may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may mean that the storage medium is not embodied by a carrier wave or propagated signal. However, the term "non-transitory" should not be interpreted to mean that memory 730 is non-removable. In certain examples, a non-transitory storage medium may store data that can be changed over time (e.g., random access memory (RAM) or cache).

[0144] 7 illustrates various hardware components of the UE 110, it should be understood that other embodiments are not limited in this regard. In other embodiments, the UE 110 may include fewer or more components. Furthermore, component labels and names are used for illustrative purposes only and do not limit the scope of the present disclosure. One or more components may be combined together to perform the same or substantially similar functions in the UE 110.

[0145] 8 illustrates various hardware components of an application server (e.g., edge server 210 or MSGin5G server 200) according to an embodiment disclosed herein. The application server may be, for example, an edge server, MSGin5G server, V2X server, UAS server, or SEAL server, but is not limited thereto. In an embodiment, edge server 210 or MSGin5G server 200 includes a processor 810, a communicator 820, a memory 830, and an application-specific authentication controller 840. Processor 810 is coupled to communicator 820, memory 830, and application-specific authentication controller 840.

[0146] The application-specific authentication controller 840 receives a service request from the UE 110 in the wireless network 1000. In response to receiving the service request, the application-specific authentication controller 840 authenticates the UE ID included in the request. After successful mutual authentication, the application-specific authentication controller 840 establishes a secure channel between the UE 110 and the application server. The application-specific authentication controller 840 transmits a response message acknowledging the successful authentication between the UE 110 and the application server. The application-specific authentication controller 840 provides network services to the UE 110.

[0147] The application-specific authentication controller 240 may be physically embodied in analog and / or digital circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, etc., and may optionally be firmware driven.

[0148] Further, processor 810 is configured to execute instructions stored in memory 830 to perform various processes. Communicator 820 is configured to communicate internally between internal hardware components and with external devices through one or more networks. Memory 830 also stores instructions executed by processor 810. Memory 830 may include a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, flash memory, an electrically programmable memory (EPROM), or an electrically erasable and programmable (EEPROM) form of memory. Moreover, memory 830 may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may mean that the storage medium is not embodied by a carrier wave or propagated signal. However, the term "non-transitory" should not be interpreted to mean that memory 830 is non-removable. In certain examples, a non-transitory storage medium may store data that can be changed over time (e.g., random access memory (RAM) or cache).

[0149] Although FIG. 8 illustrates various hardware components of edge server 210 or MSGin5G server 200, it should be understood that other embodiments are not limited thereto. In other embodiments, edge server 210 or MSGin5G server 200 may include fewer or more components. Furthermore, component labels and names are used for illustrative purposes only and do not limit the scope of the disclosure. One or more components may be combined together to perform the same or substantially similar functions in edge server 210 or MSGin5G server 200.

[0150] FIG. 9 illustrates a flow diagram (S900) of a method for application-specific authentication to network services in a wireless network 1000, according to an embodiment disclosed herein.

[0151] At S902, the method includes setting up a mapping between a service-specific identifier of the UE by the network function entity 600 to provide access to a network service in the wireless network. At S904, the method includes receiving a service request from the UE by the application server to access a network service provided by the application server in the wireless network 1000. At S906, the method includes authenticating at least one identity of the UE 110 by the NF entity before providing access to the service request. At step S908, the method includes verifying, by the NF entity, a mapping between the service-specific identifier of the service request and an already authenticated identity of the UE to allow access to a network service provided by the application server in the wireless network 1000.

[0152] 10 illustrates a flow diagram (S1000) of a method implemented by a UE 110 for application-specific authentication to network services in a wireless network 1000, according to an embodiment disclosed herein. Operations (S1002-S1012) may be handled by an application-specific authentication controller 740.

[0153] At S1002, the method includes sending a request to an application server of the wireless network 1000 to access a network service provided by the application server of the wireless network 1000. At S1004, the method includes establishing a secure channel between the UE 110 and the application server after successful mutual authentication of at least one identity of the UE 110 and the application server. At S1006, the method includes sending a service request to the application server over the secure channel. At S1008, the method includes including a service-specific identifier or a UE-specific identifier in the service request to the application server over the secure channel. At S1010, the method includes receiving a response message acknowledging successful authentication for the requested service based on the service-specific identifier or the UE-specific identifier included by the application server. At S1012, the method includes accessing the network service from the application server.

[0154] 11 illustrates a flowchart (S1100) of a method implemented by an application server (e.g., edge server 210 or MSGin5G server 200) for application-specific authentication to network services in wireless network 1000 according to an embodiment of the present disclosure. Operations (S1102-S1110) may be handled by application-specific authentication controller 840.

[0155] At S1102, the method includes receiving a service request from a UE 110 in a wireless network. At S1104, the method includes authenticating a UE ID included in the service request in response to receiving the service request. At S1106, the method includes establishing a secure channel between the UE 110 and the application server after successful mutual authentication. At S1108, the method includes sending a response message acknowledging the successful authentication and authorization of the UE 110 by the application server. At S1110, the method includes providing network services to the UE 110.

[0156] FIG. 12 illustrates a sequence flow diagram of a method implemented by an MSGin5G server or edge server for application-specific authentication to network services in a wireless network according to an embodiment disclosed herein.

[0157] When the MSGin5G service is used with SEAL, the application architecture described in TS 23.554 is followed. In this case, the MSGin5G UE is authorized by the MSGin5G server by checking the association between the UE service ID and the UE ID (SUPI / GPSI). The UE service ID is obtained by the MSGin5G registration request. The configuration management server or the MSGin5G configuration function maintains the association between the assigned UE service ID and the UE ID. The MSGin5G server searches the association from the configuration management server or the MSGin5G configuration function using the UE ID received from the AAnF and verifies whether the UE service ID received in the registration request message is associated with the UE ID in the searched association information.

[0158] In EDGE services, Edge Configuration Server (ECS) or Edge Enabler Server (EES) authorizes an Edge Enabler Client (EEC) by checking the association between the EEC ID and the UE ID (SUPI / GPSI). The EEC ID is obtained through a session setup request and / or a registration request. The authentication server maintains the association between the EEC ID and the UE ID. The ECS or EES retrieves the association from the authentication server using the UE ID received from the AAnF and verifies whether the EEC ID received in the registration request message is associated with the authenticated UE ID in the retrieved association information. In an embodiment, the ID association is maintained in the AF itself. The AF is the ECS and / or EES.

[0159] Various operations, acts, blocks, steps, etc. in the flowcharts (S900-S1100) may be performed in the order presented, in a different order, or simultaneously. Furthermore, in some embodiments, some of the operations, acts, blocks, steps, etc. may be omitted, added, modified, skipped, etc. without departing from the scope of the present disclosure.

[0160] The embodiments disclosed herein may be implemented for use with at least one hardware device performing network management functions to control elements.

[0161] The foregoing description of specific embodiments is intended to fully illustrate the general characteristics of the embodiments of the present application so that others, by applying their current knowledge, may easily modify and / or adapt such specific embodiments to various applications without departing from the general concept; therefore, such adaptations and modifications should be understood and are intended to be within the meaning and range of equivalents of the disclosed embodiments. It should be understood that the phraseology or terminology used herein is for purposes of description, not limitation. Thus, although the embodiments of the present application have been described in terms of preferred embodiments, those of ordinary skill in the art will recognize that the embodiments of the present application can be modified and practiced within the scope of the embodiments described herein. [Explanation of symbols]

[0162] 110 User Equipment (UE) 120 Network Exposure Function (NEF) 130 Anchor Function (AAnF) 150 Authentication Server Function (AUSF) 160 Mobility Management Function (AMF) 170 Application Functions (AF) 180 (R)AN 190 Authentication Server 200 MSG Server 210 EDGE Server 220 OAuth Server 240 Application Specific Authentication Controller 600 Network Function Entities 610 processor 620 Communication Device 630 memory 640 Application Specific Authentication Controller 710 processor 720 Communication Device 730 memory 740 Application Specific Authentication Controller 810 processor 820 Communication Device 830 memory 840 Application Specific Authentication Controller 1000 Wireless Network

Claims

1. 1. A method performed by an Application Function (AF) server, comprising: receiving a first request message including a terminal service identifier (ID) from a terminal; receiving, from an Authentication and Key Management for Application (AKMA) Anchor Function (AAnF) entity, a terminal ID used to obtain association information for the terminal, the association information being based on the terminal service ID and the terminal ID; sending a second request message to an authentication server to request association information of the terminal, the second request message including the terminal ID received from the AAnF entity; receiving the association information of the terminal from the authentication server when the association information of the terminal is searched based on the terminal ID; and verifying whether the terminal service ID is associated with the terminal ID included in the terminal association information.

2. The method performed by the application function (AF) server of claim 1 , further comprising providing the terminal with access to a service based on the result of the verification.

3. A method performed by an application function (AF) server as described in claim 1, wherein the association information of the terminal is retrieved based on the terminal ID received from the AAnF entity.

4. The step of verifying whether the terminal service ID is associated with the terminal ID includes:

2. The method performed by the application function (AF) server of claim 1, further comprising verifying whether the terminal service ID received in the first request message is associated with the terminal ID in the searched association information of the terminal.

5. The terminal ID includes a SUPI (Subscription Permanent Identifier), 2. The method performed by the application function (AF) server of claim 1, wherein the AF server includes a message service for Massive Internet of Things (MIoT) over 5th Generation (5G) systems (MSGin5G) server.

6. further comprising authenticating the terminal by checking the association between the terminal service ID and the terminal ID; The method performed by the application function (AF) server of claim 1 , wherein the terminal is a MSGin5G terminal.

7. an application functions (AF) server, A walkie-talkie and at least one processor operably coupled to the transceiver, the at least one processor comprising: receiving a first request message including a terminal service identifier (ID) from a terminal via the transceiver; receiving, from an Authentication and Key Management for Application (AKMA) Anchor Function (AAnF) entity, a terminal ID used to obtain association information for the terminal, the association information being based on the terminal service ID and the terminal ID; transmitting a second request message to an authentication server via the transceiver to request association information of the terminal, the second request message including the terminal ID received from the AAnF entity; When the association information of the terminal is searched based on the terminal ID, the association information of the terminal is received from the authentication server via the transceiver; an AF server configured to verify whether the terminal service ID is associated with the terminal ID included in the terminal association information;

8. The at least one processor The AF server of claim 7 , further configured to provide the terminal with access to a service based on the result of the verification.

9. An AF server as described in Claim 7, wherein the association information of the terminal is searched based on the terminal ID received from the AAnF entity.

10. The at least one processor The AF server of claim 7 , further configured to verify whether the terminal service ID received in the first request message is associated with the terminal ID in the searched association information of the terminal.

11. The terminal ID includes a SUPI (Subscription Permanent Identifier), The AF server of claim 7, wherein the AF server includes a message service for Massive Internet of Things (MIoT) over a fifth generation (5G) system (MSGin5G) server.

12. the at least one processor is further configured to authenticate the terminal by checking an association between the terminal service ID and the terminal ID; The AF server according to claim 7, wherein the terminal is a MSGin5G terminal.

13. A method performed by a terminal, comprising: sending a first request message including a terminal service identifier (ID) to an application function (AF) server; receiving a response message from the AF server, the response message including information indicating whether access to the service is provided; The terminal ID used to acquire the association information of the terminal is sent from an AKMA (Authentication and Key Management for Application) AAnF (Anchor Function) entity to the AF server; a second request message for requesting association information of the terminal is sent to an authentication server, the second request message including the terminal ID sent from the AAnF entity to the AF server; When the association information is searched based on the terminal ID, the association information of the terminal is received from the authentication server; A method performed by a terminal, in which it is verified whether the terminal service ID is associated with the terminal ID included in the association information of the terminal.

14. A terminal, A walkie-talkie and at least one processor operably coupled to the transceiver, the at least one processor comprising: Sending a first request message including a terminal service identifier (ID) to an application function (AF) server via the transceiver; configured to receive a response message from the AF server via the transceiver, the response message including information indicating whether access to a service is provided; The terminal ID used to acquire the association information of the terminal is sent from an AKMA (Authentication and Key Management for Application) AAnF (Anchor Function) entity to the AF server; a second request message for requesting association information of the terminal is sent to an authentication server, the second request message including the terminal ID sent from the AAnF entity to the AF server; When the association information is searched based on the terminal ID, the association information of the terminal is received from the authentication server; A terminal, wherein it is verified whether the terminal service ID is associated with the terminal ID included in the association information of the terminal.

15. access to the service is provided based on the result of the verification; The association information of the terminal is retrieved based on the terminal ID received from the AAnF entity; It is verified whether the terminal service ID received in the first request message is associated with the terminal ID in the searched association information of the terminal; The terminal ID includes a SUPI (subscription permanent identifier), The AF server includes a message service for massive Internet of Things (MIoT) via a fifth generation (5G) system (MSGin5G) server; The authorization of the terminal is verified by checking the association between the terminal service ID and the terminal ID; The terminal of claim 14, wherein the terminal is a MSG-in 5G terminal.

Images