WO2025166716A1

WO2025166716A1 - Secure retrieval of user equipment identifier

Info

Publication number: WO2025166716A1
Application number: PCT/CN2024/076904
Authority: WO
Inventors: Divya G Nair; Edoardo GIORDANO; Jing PING; German PEINADO GOMEZ; Laurent Thiebaut; Shubhranshu Singh
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy; Nokia Technologies Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy; Nokia Technologies Oy
Priority date: 2024-02-08
Filing date: 2024-02-08
Publication date: 2025-08-14
Anticipated expiration: 2026-08-08

Abstract

Various example embodiments relate to devices, methods, apparatuses and computer readable mediums for securely retrieving an identifier of a user equipment to provide an edge computing service to the user equipment. A user equipment may be configured to send, to an application server, an application service request including at least one of a temporary identifier of the user equipment associated with a protocol data unit session supporting the application service, or an authentication and key management for applications, AKMA, key identifier, and to receive an application service response from the application server.

Description

SECURE RETRIEVAL OF USER EQUIPMENT IDENTIFIER

TECHNICAL FIELD

Various example embodiments described herein generally relate to wireless communication technologies, and more particularly, to devices, methods, apparatuses and computer readable mediums for securely retrieving an identifier of a user equipment (UE) to provide an edge computing service to the UE.

BACKGROUND

Certain abbreviations that may be found in the description and/or in the figures are herewith defined as follows:

AAnF AKMA Anchor Function

AF Application Function

AKMA Authentication and Key Management for Applications

API Application Programming Interface

AUSF Authentication Server Function

DN Data Network

EAS Edge Application Server

EEC Edge Enabler Client

GPSI Generic Public Subscription Identifier

IP Internet Protocol

MAC Medium Access Control

NEF Network Exposure Function

PDU Protocol Data Unit

SMF Session Management Function

SUPI Subscription Permanent Identifier

UDM Unified Data Management

UDR Unified Data Repository

Edge computing is a network architecture concept that enables cloud computing capabilities and service environments, which are deployed at the “edge” of the network close to user equipment (UEs) . The most prominent benefit of edge computing is the reduced latency. For example, an application can transmit and receive data through an edge application server (EAS) installed geographically close to a base station, without passing through a server located in an external data network (DN) e.g. the Internet. When the edge computing service is provided to a UE in the mobile communication network, the EAS may need to retrieve an identifier (ID) of the UE from the network.

SUMMARY

A brief summary of exemplary embodiments is provided below to provide basic understanding of some aspects of various embodiments. It should be noted that this summary is not intended to identify key features of essential elements or define scopes of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as a preamble for a more detailed description provided below.

In a first aspect, an example embodiment of an application client is provided. The applicant client may comprise instructions for sending an application service request to an application server and receiving an application service response from the application server. The application service request may contain a temporary identifier of a user equipment on which the application client is running.

In a second aspect, an example embodiment of a user equipment is provided. The user equipment may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the user equipment at least to send an application service request to an application server and to receive an application service response from the application server. The application service request may contain at least one of a temporary identifier of the user equipment associated with a protocol data unit session supporting the application service, or an authentication and key management for applications, AKMA, key identifier.

In a third aspect, an example embodiment of an application server is provided. The application server may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the application server at least to receive, from a user equipment, an application service request including a temporary identifier of the user equipment associated with a protocol data unit session supporting the application service, to send a user equipment identifier request including the temporary identifier to a network exposure function entity, to receive a user equipment identifier response including an application specific user equipment identifier from the network exposure function entity, to send a user equipment information request including the application specific user equipment identifier to the network exposure function entity, to receive a user equipment information response including the requested user equipment information from the network exposure function entity, and to send an application service response to the user equipment.

In a fourth aspect, an example embodiment of a session management function entity is provided. The session management function entity may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the session management function entity at least to receive a protocol data unit session request from a user equipment, to send information of a protocol data unit session associated with the protocol data unit session request to a unified data management function entity, to receive a temporary identifier associated with the protocol data unit session from the unified data management function entity, and to send a message including the temporary identifier to the user equipment. The message including the temporary identifier may be a protocol data unit session establishment or modification response message or an extended protocol configuration option (ePCO) message.

In a fifth aspect, an example embodiment of a network exposure function entity is provided. The network exposure function entity may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the network exposure function entity at least to receive a user equipment identifier request including a temporary identifier of a user equipment from an application server, to retrieve a user equipment identifier from a unified data management function entity based on the temporary identifier, to retrieve an application specific user equipment identifier from the unified data management function entity based on the user equipment identifier and an application function identifier, and to send a user equipment identifier response including the application specific user equipment identifier to the application server.

In a sixth aspect, an example embodiment of a unified data management function entity is provided. The unified data management function entity may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the unified data management function entity at least to receive information of a protocol data unit session from a session management function entity, to generate a temporary identifier for the protocol data unit session, the temporary identifier containing information identifying a unified data management group identifier associated with the unified data management function entity, to store a mapping between the temporary identifier and a user equipment identifier in a unified data repository function entity, the user equipment identifier representing a user equipment associated with the protocol data unit session, and to send the temporary identifier to the session management function entity.

In a seventh aspect, an example embodiment of a unified data management function entity is provided. The unified data management function entity may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the unified data management function entity at least to receive a user equipment identifier retrieval request containing a temporary identifier of a user equipment from a network exposure function entity, to send a user equipment identifier retrieval response including a user equipment identifier mapping to the temporary identifier to the network exposure function entity, to receive an application specific user equipment identifier retrieval request containing the user equipment identifier and an application function identifier from the network exposure function entity, and to send an application specific user equipment identifier retrieval response including an application specific user equipment identifier corresponding to the user equipment identifier and the application function identifier to the network exposure function entity.

In an eighth aspect, an example embodiment of an application server is provided. The application server may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the application server at least to receive an application service request including an authentication and key management for applications, AKMA, key identifier from a user equipment, to send an application key request including the AKMA key identifier to a network exposure function entity, to receive an application key response including an application key for the application server and a generic public subscription identifier of the user equipment from the network exposure function entity, to send a user equipment information request including the generic public subscription identifier to the network exposure function entity, to receive a user equipment information response including the requested user equipment information from the network exposure function entity, and to send an application service response to the user equipment.

In a ninth aspect, an example embodiment of a network exposure function entity is provided. The network exposure function entity may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the network exposure function entity at least to receive an application key request including an authentication and key management for applications, AKMA, key identifier from an application server, to retrieve an application key for the application server and a subscription permanent identifier from an AKMA anchor function entity based on the AKMA key identifier, to translate the subscription permanent identifier into a generic public subscription identifier, to send an application key response including the application key for the application server and the generic public subscription identifier to the application server, to receive a user equipment information request including the generic public subscription identifier from the application server, and to send a user equipment information response to the application server.

In a tenth aspect, an example embodiment of an application server is provided. The application server may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the application server at least to receive, from a user equipment, an application service request including at least one of a temporary identifier of the user equipment or an authentication and key management for applications, AKMA, key identifier, to send a user equipment information request including the at least one of the temporary identifier and the AKMA key identifier to a network exposure function entity, to receive a user equipment information response including the requested user equipment information from the network exposure function entity, and to send an application service response to the user equipment.

In an eleventh aspect, an example embodiment of a network exposure function entity is provided. The network exposure function entity may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the network exposure function entity at least to receive, from an application server, a user equipment information request including a temporary identifier of a user equipment, to retrieve a user equipment identifier from a unified data management function entity based on the temporary identifier, to retrieve the requested user equipment information based on the user equipment identifier, and to send a user equipment information response to the application server.

In a twelfth aspect, an example embodiment of a network exposure function entity is provided. The network exposure function entity may comprise at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, cause the network exposure function entity at least to receive, from an application server, a user equipment information request including an authentication and key management for applications, AKMA, key identifier, to retrieve a subscription permanent identifier from an AKMA anchor function entity based on the AKMA key identifier, to retrieve the requested user equipment information based on the subscription permanent identifier, and to send a user equipment information response to the application server.

Example embodiments of methods, apparatuses and computer readable mediums are also provided. The example embodiments of methods, apparatuses and computer readable mediums generally correspond to the above example embodiments of the first to twelfth aspects, and a repetitive description thereof is omitted here for convenience.

Other features and advantages of the example embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of example embodiments of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

Some example embodiments will now be described, by way of non-limiting examples, with reference to the accompanying drawings.

Fig. 1 is a message flow diagram illustrating a process of providing an application service to a user equipment.

Fig. 2 is a schematic flow diagram illustrating a process of generating a temporary identifier for a user equipment according to an example embodiment of the present disclosure.

Fig. 3 is a schematic flow diagram illustrating a process of providing an application service to a user equipment according to an example embodiment of the present disclosure.

Fig. 4 is a schematic flow diagram illustrating a process of providing an application service to a user equipment according to an example embodiment of the present disclosure.

Fig. 5 is a schematic flow diagram illustrating a process of providing an application service to a user equipment according to an example embodiment of the present disclosure.

Fig. 6 is a schematic flow diagram illustrating a process of providing an application service to a user equipment according to an example embodiment of the present disclosure.

Fig. 7 is a schematic flow diagram illustrating a process of providing an application service to a user equipment according to an example embodiment of the present disclosure.

Fig. 8 is a schematic flow diagram illustrating a process of providing an application service to a user equipment according to an example embodiment of the present disclosure.

Fig. 9A is a schematic block diagram illustrating a terminal device according to an example embodiment of the present disclosure.

Fig. 9B is a schematic block diagram illustrating a core network device according to an example embodiment of the present disclosure.

Fig. 9C is a schematic block diagram illustrating an application server device according to an example embodiment of the present disclosure.

Throughout the drawings, same or similar reference numbers indicate same or similar elements. A repetitive description on the same elements would be omitted.

DETAILED DESCRIPTION

Herein below, some example embodiments are described in detail with reference to the accompanying drawings. The following description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known circuits, techniques and components are shown in block diagram form to avoid obscuring the described concepts and features.

Fig. 1 is a message flow diagram illustrating a process 100 of providing an application service to a user equipment (UE) 102. An application client (AC) 101, e.g. an edge application client (EAC) , may be installed in the UE 102 and receives a service provided by an application server (AS) 103, e.g. an edge application server (EAS) . Referring to Fig. 1, the UE 102 (or the application client 101) may send at 110 an application service request (or “application request” for short) to the application server 103. To provide the service to the UE 102, the application server 103 may need to know some information about the UE 102. For example, assuming a case where a user is using the UE 102 to enjoy a hiking game, the game server needs to know the location of the user. The game server may invoke an application programming interface (API) exposed by a network exposure function (NEF) 105 to obtain the UE information from the mobile/cellular network serving the UE 102. The NEF 105 serves as an entry point into the operator’s network by exposing to application functions/servers the network capabilities and events provided by network functions (NFs) and by providing ways for the application functions/servers to provide information to the network. In the process 100, the application server 103 may invoke a NEF exposed API to send a UE information (e.g. location) request to the NEF 105 at 112. The request contains a UE identifier (ID) identifying the UE 102. The NEF 105 may get the requested UE information from other network functions or nodes based on the UE ID at 114, and return the UE information to the application server 103 in a NEF response message at 116. With the UE information, the application server 103 can provide at 118 the service in an application response message to the UE 102.

In the process 100, the application server 103 needs to know the UE ID that identifies the UE 102 in the mobile/cellular network, in order to acquire the UE information e.g. location from the mobile network. According to the current 3GPP specifications, the application server 103, acting as an application function (AF) , can use a network identifier e.g. IP address, MAC address of the UE 102 to retrieve the UE ID to be used in the subsequent API calls. More specifically, the application server (AS) or application function (AF) 103 can use the Nnef_UEId_Get service with the required input of the UE address (i.e. IP address or MAC address) and the AS/AF identifier (AF_ID) to obtain an AF specific UE identifier (AF_UE_ID) of the UE 102. The AF specific UE identifier may be represented as a general public subscription identifier (GPSI) in the form of an External Identifier. When used as the AF specific UE identifier, the External Identifier provided by the core network shall be different for different AFs.

Privacy issues may occur at the provision of the actual service by the Nnef_UEId API that the edge application use case utilizes. When the application client on the UE, which may not be trusted, sends the network UE identifier (e.g., private IP address) to the application server as a part of the application layer protocol, the UE may not provide its own identifier, but that of another UE. Hence it is not a secure solution. Without proper security mechanisms in place, the Nnef_UEId service can be abused so that the UE ID may be disclosed to un-authorized entities, enabling them for example to track UEs, thus compromising the privacy of the UE. Any application server/function knowing the UE’s IP address can leverage the Nnef_UEId service to get the AF specific UE identifier, even though it is not entitled to get it. Even if the API is subject to existing authentication and authorization procedures provided by the network operator and the service provider, sensitive privacy UE/subscriber information such as IP address, UE ID, etc., could be exposed to third party applications in between, that violates the need-to-know security principle.

Some solutions have been proposed to secure the UE IP address and prevent multiple attacks. For example, the user information (e.g., private UE IP address) provided by an edge enabler client (EEC) in the UE or an edge enabler server (EES) in the edge data network should be verified and the EEC, EES should be authorized to use the information. The core network generated random or token, or authentication and key management for applications (AKMA) feature can be leveraged to assist the network to verify the IP address provided by the EEC or EES. Unfortunately, the solutions do not address the main security concerns related to the compromise of the UE privacy because the IP address and identifier of the UE are still unnecessarily exposed to all applications in the chain of edge service producers, and of course the use of UE IP address is always subject to spoofing type of attacks. Indeed, using the UE IP address allows the application server to gain additional information regarding the UE that can be abused. For example, the application server could use the IP address to track the UE, or to aggregate similar IPs, which would correspond to similar location, and make additional analysis over groups of UEs.

Another security issue concerns to the possibility for a malicious application server to perform replay-attacks. Indeed, after retrieving the UE ID the first time, the application server can reuse it even if there is no new request from the application client. In general, any approach/solution based on the use of a long-lived UE identifier that the application server can utilize to get access to services exposed by the network, and correlate with a network UE identifier, is prone to security/privacy breaches exploited by compromised or malicious application servers.

Example embodiments of the present disclosure propose a secure mechanism to retrieve UE ID from the core network without using private UE information e.g. IP or MAC address, and to protect the NEF APIs from a compromised or malicious application server. The mechanism can provide authentication and privacy protection of UE information provided by the UE (or an EEC in the UE) for requesting the UE ID from the core network, and prevent the abuse of the requested UE ID. It can protect the system from replay attacks since the application server that gets to know the UE ID cannot use it without permission. Some example embodiments are described in the context of edge computing, but it would be appreciated that the example embodiments can be easily extrapolated, generalized or applied to other contexts where an application client on a UE is consuming a service provided by an application server and, as a part of the service delivery, the application server needs to access a network northbound API.

In some example embodiments, a temporary identifier associated with a protocol data unit (PDU) session can be assigned to a UE (or an EEC in the UE) and provided, in substitution for IP or MAC address, by the UE (or EEC) to an application server for requesting UE ID from the core network via NEF. Fig. 2 illustrates an example process 200 of temporary identifier generation according to an example embodiment of the present disclosure.

Referring to Fig. 2, an application client (AC) 101 running on a UE 102 may trigger a temporary identifier request to the UE 102 at 210. For instance, when the AC 101 initiate a communication with the application server 103, the AC 101 may request the UE 102 for a new temporary identifier temp_ID.

In response to the temporary identifier request, the UE 102 may optionally retrieve at 212 an application server or function identifier AF_ID of the application client 101. The application server/function identifier AF_ID identifies the application server/function 103 that provides the service to the application client 101. In an example embodiment, the UE 102 may initiate the operation 212 on its own initiative, without being triggered by the temporary identifier request.

Optionally, the UE 102 may generate at 214 a preliminary temporary identifier pre_temp_ID. For instance, the UE 102 may generate a unique random value as the preliminary temporary identifier pre_temp_ID.

At 216, the UE 102 may send a protocol data unit (PDU) session establishment or modification request to a session management function (SMF) 104 to establish a new PDU session or modify an existing PDU session to support the service of the application client 101. The PDU session establishment or modification request may include the application server/function identifier AF_ID of the application client 101. If the UE 102 has generated the preliminary temporary identifier pre_temp_ID, the PDU session establishment or modification request may also include the preliminary temporary identifier pre_temp_ID of the UE 102. Since the PDU session can support multiple application services, in an example embodiment, the UE 102 may send a list of ID pairs (pre_temp_ID, AF_ID) for the multiple application services that the PDU session is intended to support in the PDU session request.

If the received PDU session request does not include the preliminary temporary identifier pre_temp_ID generated at the UE 102, the SMF 104 may generate a preliminary temporary identifier pre_temp_ID instead at 218. For instance, the SMF 104 may generate a network internal random unique value as the preliminary temporary identifier pre_temp_ID for the PDU session. In an example embodiment, the operation 218 may be omitted, no matter the received PDU session request includes the preliminary temporary identifier pre_temp_ID or not.

In response to the PDU session establishment or modification request, the SMF 104 may establish a new PDU session or modify an existing PDU session to support the application service of the application client 101. The SMF 104 may store information of the PDU session in a unified data management function (UDM) 106 by sending the PDU session information via a Nudm_UECM_Registration request for the new PDU session or a Nudm_UECM_Update request for the modified PDU session to the UDM 106 at 220. The PDU session information may include either the preliminary temporary identifier pre_temp_ID generated at the UE 102 or the preliminary temporary identifier pre_temp_ID generated at the SMF 104, and the application server/function identifier AF_ID. If neither the UE 102 nor the SMF 104 has generated the preliminary temporary identifier pre_temp_ID, the PDU session information sent to the UDM 106 may include only the application server/function identifier AF_ID.

Upon receiving the PDU session information, the UDM 106 may generate a temporary identifier temp_ID for the PDU session and the UE 102 at 222. The temporary identifier temp_ID may contain information for identifying a UDM group identifier of the UDM 106. In an example, the temporary identifier temp_ID may contain the UDM group identifier of the UDM 106. If the received PDU session information includes the preliminary temporary identifier pre_temp_ID generated at the UE 102 or the SMF 104, the UDM 106 may generate the temporary identifier temp_ID per the pre_temp_ID. For example, the UDM 106 may generate the temporary identifier temp_ID by combining the preliminary temporary identifier pre_temp_ID and the information identifying the UDM group identifier of the UDM 106. If the received PDU session information does not include the preliminary temporary identifier pre_temp_ID, the UDM 106 may generate a preliminary temporary identifier pre_temp_ID first, e.g. a network internal random unique value, and then combine the generated preliminary temporary identifier pre_temp_ID with the information identifying the UDM group identifier of the UDM 106 to generate the temporary identifier temp_ID. In an example, the temp_ID may include a combination of the pre_temp_ID and the UDM group ID. The UDM 106 may store the temporary identifier temp_ID for the PDU session and the UE 102 in a unified data repository (UDR) . In an example embodiment, the UDM 106 may store a mapping of the temporary identifier temp_ID, an identifier UE_ID of the UE 102, and optionally the application server/function identifier AF_ID in the UDR. The UE_ID may be a subscription permanent identifier (SUPI) of the UE 102.

Then the UDM 106 may send the temporary identifier temp_ID to the SMF 104 at 224. For instance, the UDM 106 may send the temporary identifier temp_ID in a Nudm_UECM_Registration/Update response message to the SMF 104.

At 226, the SMF 104 may send the temporary identifier temp_ID in a PDU session establishment/modification accept message to the UE 102. In an example embodiment, the SMF 104 may use any other messages to convey the temporary identifier temp_ID to the UE 102. For example, the SMF 104 may send the temporary identifier temp_ID in an extend protocol configuration option (ePCO) message to the UE 102.

At 228, the UE 102 may send the temporary identifier temp_ID in a temporary identifier response message to the application client 101. Then the application client 101 may use the temporary identifier temp_ID to initiate a communication with the application server 103, which will be described below.

In the process 200, the temporary identifier temp_ID of the UE 102, which is associated with the PDU session supporting the service of the application client 101, can be partly generated at the UE 102 or the SMF 104, or entirely generated at the UDM 106. It can prevent possible attacks in cases where the application client 101 is malicious or has been compromised. In addition, the optional use of the application server/function identifier AF_ID can also increase the over security since the temporary identifier temp_ID is generated per AF_ID and there may be multiple applications conveyed within the same PDU session.

Fig. 3 illustrates a process 300 of providing an application service to the UE 102 or the application client 101 in the UE 102 according to an example embodiment of the present disclosure. The temporary identifier temp_ID generated in the process 200 may be used in the process 300.

Referring to Fig. 3, at 310, the UE 102 or the application client 101 in the UE 102 may send an application service request to the application server 103. The application service request may contain the temporary identifier temp_ID of the UE 102 associated with the PDU session supporting the application service.

Upon receiving the application service request, the application server 103 may request an authorization token from an authorization server 107 at 312. In an example embodiment, the application server 103 may send an authorization token request to the authorization server 107, and receive an authorization token response containing a token from the authorization server 107. The token may contain the application server/function identifier AF_ID of the application server 103. It would be appreciated that the token request and response messages are described as an example, and any other method to authenticate and authorize the application server 103 before a network exposure function (NEF) 105 can be performed instead at 312.

At 314, the application server 103 may send a request for identifier of the UE 102 to the NEF 105. In an example embodiment, the application server 103 may request to retrieve the UE ID via the Nnef_UEId_Get service operation. The request message may contain the temporary identifier temp_ID, instead of the IP or MAC address of the UE 102. Optionally, the request may also contain the token acquired at 312.

Upon receiving the UE ID request containing the temporary identifier temp_ID, the NEF 105 may determine at 316 the UDM 106 to retrieve the UE ID based on the information identifying the UDM group identifier in the temporary identifier temp_ID.

Then the NEF 105 may retrieve the UE ID from the UDM 106 based on the temporary identifier temp_ID. For instance, the NEF 105 may send a UE ID retrieval request containing the temporary identifier temp_ID to the UDM 106 at 318, and receive a UE ID retrieval response containing the identifier UE_ID of the UE 102 at 320. The UDM 106 may determine the UE_ID e.g. SUPI corresponding to the received temporary identifier temp_ID and send the UE_ID in the retrieval response message to the NEF 105. Optionally, the retrieval response message may further contain the application server/function identifier AF_ID corresponding to the temporary identifier temp_ID. The NEF 105 may verify at 321 the AF_ID received from the UDM 106 by comparing it with the AF_ID received from the application server 103 (e.g. the AF_ID contained in the token received from the application server 103) . If the two AF_IDs match with each other, the NEF 105 may proceed to the next step with the received UE_ID. If the two AF_IDs do not match with each other, the NEF 105 may send a request rejected message containing the rejection cause to the application server 103. The application server 103 may forward the request rejected message to the UE 102 or the application client 101 in the UE 102. In response to the message, the application client 101 or the UE 102 can re-trigger the process 200 to create the temporary identifier temp_ID corresponding to the application server/function identifier AF_ID of the application server 103.

In case the validity of the AF_ID received from the UDM 106 is verified at 321, the NEF 105 may retrieve an application specific UE identifier AF_UE_ID from the UDM 106 based on the UE_ID and the AF_ID. In an example embodiment, the UDM 106 may request to retrieve the application specific UE identifier AF_UE_ID via the Nudm_SDM_Get service operation. The NEF 105 may send a Nudm_SDM_Get request message containing the UE_ID and the AF_ID to the UDM 106 at 322, and receive a Nudm_SDM_Get response message containing the AF_UE_ID e.g. a generic public subscription identifier (GPSI) of the UE 102 at 324.

At 326, the NEF 105 may send the application specific UE identifier AF_UE_ID in a UE ID response message to the application server 103.

The application server 103 may request an authorization token from the authorization server 107 at 328. The operation 328 may be similar to the operation 312 discussed above, and a repetitive description is omitted here. Also, any other method to authenticate and authorize the application server 103 before the NEF 105 can be performed instead at 328.

At 330, the application server 103 may send a UE information request containing the AF_UE_ID to the NEF 105. For instance, the application server 103 may request UE location via the NEF location service operation. The request message may further include the authorization token acquired at 328.

If the token successfully authenticates and authorizes the application server 103, or the application server 103 acquires authentication and authorization in any other way, the NEF 105 may retrieve the requested UE information from a corresponding network function or node based on the AF_UE_ID and return the UE information in a response message to the application server 103 at 332. For instance, the NEF 105 may retrieve the UE location from a location management function (LMF) and return the UE location to the application server 103.

With the UE information, the application server 103 may determine the service data for the UE 102 or the application client 101, and send an application service response message to the UE 102 or the application client 101 at 334.

In the process 300, instead of private UE information e.g. IP or MAC address, the temporary identifier temp_ID of the UE 102 is used to retrieve UE information e.g. location needed from the core network. It can prevent sensitive privacy UE information from being exposed to and abused by third party applications and hence protect the system from replay-attacks.

Fig. 4 illustrates a process 300a according to an example embodiment of the present disclosure. The process 300a is a variant of the process 300 discussed above, and it may include operations identical to those in the process 300. Now description will be given to only different operations in the process 300a.

Referring to Fig. 4, after the NEF 105 receives the application specific UE identifier AF_UE_ID from the UMD 106 at 324, the NEF 105 may select at 325 one or more access control policies (also referred to as security policy) , e.g. a role based access control (RBAC) policy, for the AF_UE_ID. The access control policy can enforce control over multiple attributes such as expiration time, usage, scope, etc. of the AF_UE_ID. The NEF 105 may store a mapping between the AF_UE_ID (e.g. GPSI) , the selected access control policy (ies) , and optionally the UE ID (e.g. SUPI) . The mapping may be stored locally at the NEF 105 or in the UDM/UDR.

Then when the NEF 105 receives the UE information request containing the AF_UE_ID from the application server 103 at 330, the NEF 105 may verify whether the AF_UE_ID contained in the UE information request is compliant with the access control policy (ies) or not. If the AF_UE_ID is compliant with the access control policy (ies) , the NEF 105 may proceed to retrieve the requested UE information using the AF_UE_ID and send the UE information in the UE information response message to the application server 103. If the AF_UE_ID violates one or more of the access control policies, the NEF 105 may send a UE information request rejected message (not shown) containing the rejection cause to the application server 103, and the application server 103 may forward the request rejected message containing the rejection cause to the UE 102 or the application client 101. Then the UE 102 or the application client 101 may re-initiate the process 300a to select the access control policy for the AF_UE_ID.

In the process 300a, the access control policies can provide flexible and fine-grained control over the AF_UE_ID. By introducing the access control policies for the AF_UE_ID, the NEF 105 can prevent the abuse of the AF_UE_ID by a malicious or comprised application server and protect the system from the replay-attacks that are possible in the current API workflows as the UE_ID and AF_UE_ID are relatively static. It can further improve the security of the system.

Fig. 5 illustrates a process 400 according to an example embodiment of the present disclosure. In the example embodiment, the authentication and key management for applications (AKMA) protocol and an AKMA key identifier A-KID are leveraged to identify the original caller of the API. A-KID is an application specific identifier derived from the long term symmetric pre-shared key between the UE and the network, and it is used by the AKMA protocol to identify an application function/server in non-trusted scenarios. The A-KID may be sent from the UE along with an application service request. The edge application/enabler server, as another non-trusted application function (AF) connected to the NEF, will then use the AKMA protocol to request the external UE ID to the NEF.

Referring to Fig. 5, as a precondition, a primary authentication procedure is performed at 402 to authenticate a UE 102 during network registration, followed by an AKMA key derivation procedure 404 to generate keys including for example a root key K_AUSF, an anchor key K_AKMA, and an AKMA key identifier A-KID of K_AKMA. An authentication server function (AUSF) 109 is responsible for the key generation. Then at 406, an AKMA anchor function (AAnF) 108 may create and maintain UE AKMA contexts including SUPI, GPSI, K_AKMA and A-KID to be used for security communication between the UE 102 and an application server/function 103.

At 410, the UE 102 or an application client (AC) 101 in the UE 102 may send an application service request containing the AKMA key identifier A-KID to the application server 103.

Upon receiving the application service request containing the A-KID, the application server 103 may request the KAMA application key K_AF associated with the A-KID from the AAnF 108 by sending the A-KID to the AAnF 108 via the NEF 105. More specifically, the application server 103 may request the AKMA application key K_AF by sending a Nnef_AKMA_ApplicationKey_Get request message including the A-KID to the NEF 105 at 412. Optionally, the K_AF request message may also contain the application server/function identifier AF_ID and the authorization token of the application server 103. If the application server 103 is authorized by the NEF 105 to request K_AF, the NEF 105 may discover and select the AAnF 108 for the application server 103 and request the AKMA application key K_AF by sending a Naanf_AKMA_ApplicationKey_Get request message including the A-KID and optionally the AF_ID to the AAnF 108 at 414. The AAnF 108 may calculate the AKMA application key K_AF, its expiration time, retrieve the SUPI (i.e. UE_ID) of the UE 102 based on the A-KID or K_AF, and then send a response message with the K_AF, its expiration time and the SUPI to the NEF 105 at 416. In an example embodiment, the AAnF 108 may bind the K_AF calculation to an application session identifier so that the calculated K_AF is different for each application session. It can prevent the K_AF being reused after the application session between the UE 102 and the application server 103 ends.

At 418, the NEF 105 may translate the SUPI of the UE 102 received from the AAnF 108 into GPSI (external ID) . In an example embodiment, the NEF 105 may interact with the UDM 106 (shown in Figs. 2-4) to retrieve the GPSI (i.e. AF_UE_ID) via the Nudm_SDM_Get service operation. The service request may include the SUPI and at least one of an application port ID, machine type communication (MTC) provider information, or the AF_ID. Then the NEF 105 may send the GPSI, the K_AF and its expiration time in a Nnef_AKMA_ApplicationKey_Get response message to the application server 103 at 420.

The application server 103 may request an authorization token from the authorization server 107 at 422. In an example embodiment, the application server 103 may send an authorization token request to the authorization server 107, and receive an authorization token response containing a token from the authorization server 107. The token may contain the application server/function identifier AF_ID of the application server 103. It would be appreciated that the token request and response messages are described as an example, and any other method to authenticate and authorize the application server 103 before the NEF 105 can be used instead.

At 424, the application server 103 may send a UE information request containing the GPSI (i.e., AF_UE_ID) and optionally the K_AF, the token to the NEF 105. For instance, the application server 103 may request UE location via the NEF location service operation. If the K_AF or token is verified, the NEF 105 may retrieve the requested UE information from a corresponding network function or node based on the GPSI and return the UE information in a response message to the application server 103 at 426. For instance, the NEF 105 may retrieve the UE location from a location management function (LMF) and return the UE location to the application server 103.

With the UE information, the application server 103 may determine the service data for the UE 102 or the application client 101, and send an application service response message to the UE 102 or the application client 101 at 428.

In the process 400, the A-KID is reused to retrieve the application specific UE identifier via AKMA operations from the AAnF 108. It can also prevent sensitive privacy UE information e.g. IP or MAC address being exposed to and abused by third party applications and hence protect the system from replay-attacks. In addition, the overall process is simplified because the process 200 for generating the temporary identifier temp_ID is not needed.

Fig. 6 illustrates a process 400a according to an example embodiment of the present disclosure. The process 400a is a variant of the process 400 discussed above, and it may include operations identical to those in the process 400. Now description will be given to only different operations in the process 400a.

Referring to Fig. 6, after the NEF 105 translates the SUPI of the UE 102 into the GPSI at 418, the NEF 105 may select at 419 one or more access control policies (also referred to as security policy) , e.g. a role based access control (RBAC) policy, for the GPSI. The access control policy can enforce control over multiple attributes such as expiration time, usage, scope, etc. of the GPSI. The NEF 105 may store a mapping between the GPSI, the selected access control policy (ies) , and optionally the UE ID (e.g. SUPI) . The mapping may be stored locally at the NEF 105 or in the UDM/UDR.

Then when the NEF 105 receives the UE information request containing the GPSI and optionally the K_AF, the token from the application server 103 at 424, the NEF 105 may verify whether the GPSI contained in the UE information request is compliant with the access control policy (ies) or not. If the GPSI is compliant with the access control policy (ies) , the NEF 105 may proceed to retrieve the requested UE information using the GPSI and send the UE information in the UE information response message to the application server 103. If the GPSI violates one or more of the access control policies, the NEF 105 may send a UE information request rejected message (not shown) containing the rejection cause to the application server 103, and the application server 103 may forward the request rejected message containing the rejection cause to the UE 102 or the application client 101. Then the UE 102 or the application client 101 may re-initiate the process 400a to select the access control policy for the GPSI.

In the process 400a, the access control policies can provide flexible and fine-grained control over the GPSI of the UE 102. By introducing the access control policies for the GPSI, the NEF 105 can prevent the abuse of the GPSI by a malicious or comprised application server and protect the system from the replay-attacks that are possible in the current API workflows as the UE_ID and AF_UE_ID are relatively static. It can further improve the security of the system.

Fig. 7 illustrates a process 500 according to an example embodiment of the present disclosure. The process 500 includes some operations similar to those in the process 300 and the similar operations will be described below in a simple way.

Referring to Fig. 7, at 510, the UE 102 or the application client 101 may send an application service request containing a temporary identifier temp_ID to the application server 103. For instance, the temporary identifier temp_ID may be generated in the process 200 discussed above with respect to Fig. 2.

Upon receiving the application service request, the application server 103 may acquire an authorization token from the authorization server 107 at 512 by for example sending an authorization token request to the authorization server 107 and receiving an authorization token response containing the token from the authorization server 107. The token may contain the application server/function identifier AF_ID of the application server 103. It would be appreciated that any other method to authenticate and authorize the application server 103 before the NEF 105 may be used instead at 512.

At 514, the application server 103 may send a UE information request containing the temporary identifier temp_ID and optionally the token to the NEF 105. For instance, the application server 103 may request UE location via the NEF location service operation. Instead of the application specific UE identifier AF_UE_ID or GPSI, the temporary identifier temp_ID is used in the request message to retrieve the UE location. The token contains the application server/function identifier AF_ID of the application server 103, or the request message may directly include the AF_ID.

In case the token successfully authenticates and authorizes the application server 103, the NEF 105 may determine at 516 the UDM 106 to retrieve the UE ID of the UE 102 based on the information identifying the UDM group identifier in the temporary identifier temp_ID. Then the NEF 105 may send a UE identifier retrieval request containing the temporary identifier temp_ID to the UDM 106 at 518. In response to the request, the UDM 106 may retrieve the UE ID e.g. SUPI based on the temporary identifier temp_ID and send the UE ID in a UE ID retrieval response message to the NEF 105 at 520. Optionally, the retrieval response message may further contain the application server/function identifier AF_ID corresponding to the temporary identifier temp_ID. The NEF 105 may verify at 521 the AF_ID received from the UDM 106 by comparing it with the AF_ID received from the application server 103 (e.g. the AF_ID contained in the token received from the application server 103) . If the two AF_IDs match with each other, the NEF 105 may proceed to the next step with the received UE_ID. If the two AF_IDs do not match with each other, the NEF 105 may send a request rejected message containing the rejection cause to the application server 103. The application server 103 may forward the request rejected message to the UE 102 or the application client 101. In response to the message, the application client 101 or the UE 102 can re-trigger the process 200 to create the temporary identifier temp_ID corresponding to the application server/function identifier AF_ID of the application server 103.

In case the validity of the AF_ID received from the UDM 106 is verified at 521, the NEF 105 may retrieve the requested UE information from a corresponding network function or node based on the UE_ID and optionally the AF_ID at 522, and return the UE information in a response message to the application server 103 at 524. For instance, the NEF 105 may retrieve the UE location from a location management function (LMF) and return the UE location to the application server 103.

With the UE information, the application server 103 may determine the service data for the UE 102 or the application client 101, and send an application service response message to the UE 102 or the application client 101 at 526.

The process 500 can reduce the number of API calls required to retrieve a service. When receiving the application service request containing the temporary identifier temp_ID, the application server 103 does not need to retrieve a UE ID first. Instead, the application server 103 can directly use the temporary identifier temp_ID to retrieve the service. It can eliminate the need to disclose the UE ID to the application server or any other intermediate server which is not required to retrieve the desired service, and thereby prevent the replay-attacks that are possible in the current API workflows as the UE ID or SUPI, even the application specific UE ID or GPSI, are relatively static.

Fig. 8 illustrates a process 600 according to an example embodiment of the present disclosure. The process 600 is similar to the process 500 in the sense that a temporary identifier (A-KID in the process 600) is directly used to retrieve UE information but retrieval of UE ID based on the temporary identifier is omitted. The difference is AKMA feature is leveraged in the process 600.

Referring to Fig. 8, at 610, the UE 102 or the application client (AC) 101 may send an application service request containing the AKMA key identifier A-KID to the application server 103.

Upon receiving the application service request containing the A-KID, the application server 103 may acquire an authorization token from the authorization server 107 at 612 by for example sending an authorization token request to the authorization server 107 and receiving an authorization token response containing the token from the authorization server 107. The token may contain the application server/function identifier AF_ID of the application server 103. It would be appreciated that any other method to authenticate and authorize the application server 103 before the NEF 105 may be used instead at 612.

At 614, the application server 103 may send a UE information request containing the A-KID and optionally the AF_ID, the token to the NEF 105. For instance, the application server 103 may request UE location via the NEF location service operation. Instead of the application specific UE identifier AF_UE_ID or GPSI, the A-KID is used in the request message to retrieve the UE location.

In case the token successfully authenticates and authorizes the application server 103, the NEF 105 may discover and select an AAnF 108 for the application server 103 and request an AKMA application key K_AF by sending a Naanf_AKMA_ApplicationKey_Get request message including the A-KID and optionally the AF_ID to the AAnF 108 at 616. In response to the request, the AAnF 108 may calculate the AKMA application key K_AF, its expiration time, retrieve the SUPI (i.e. UE_ID) of the UE 102 based on the A-KID or K_AF, and then send a response message with the K_AF, its expiration time and the SUPI to the NEF 105 at 618. In an example embodiment, the AAnF 108 may bind the K_AF calculation to an application session identifier so that the calculated K_AF is different for each application session. It can prevent the K_AF being reused after the application session between the UE 102 and the application server 103 ends.

After receiving the SUPI from the AAnF 108, the NEF 105 may retrieve the requested UE information from a corresponding network function or node based on the SUPI and optionally the AF_ID at 620, and return the UE information in a response message to the application server 103 at 622. For instance, the NEF 105 may retrieve the UE location from a location management function (LMF) and return the UE location to the application server 103.

With the UE information, the application server 103 may determine the service data for the UE 102 or the application client 101, and send an application service response message to the UE 102 or the application client 101 at 624.

The process 600 can reduce the number of API calls required to retrieve a service because, when receiving the application service request containing the A-KID, the application server 103 does not need to retrieve a UE ID first. Instead, the application server 103 can directly use the A-KID to retrieve the service. It can eliminate the need to disclose the UE ID to the application server or any other intermediate server which is not required to retrieve the desired service, and thereby prevent the replay-attacks that are possible in the current API workflows as the UE ID or SUPI, even the application specific UE ID or GPSI, are relatively static. By reusing the A-KID, the process 600 also eliminates the need for a dedicated temporary identifier and simplify the overall procedure because the process 200 for generating the dedicated temporary identifier is not needed.

The example embodiments of the processes 200, 300, 300a, 400, 400a, 500 and 600 have been described above with respect to Figs. 2-8. The SMF 104, the NEF 105, the UDM 106, the authorization server 107, the AAnF 108 and the ASUF 109 involved in the processes 200-600 each may be implemented as a network function (NF) , or as a network entity/device for performing the function. The UE 102, the application server 103, the network functions/entities/devices 104-109 each may be implemented to comprise a plurality of components, modules, means or elements for performing relevant operations in the processes 200-600. The plurality of components, modules, means or elements may be implemented in various manners including but not limited to for example software, hardware, firmware or any combination thereof.

Fig. 9A, 9B, 9C illustrate internal blocks of a terminal device 700, a core network device 800, and an application server device 900 according to example embodiments of the present disclosure, respectively. In an example embodiment, the terminal device 700 may be implemented as the UE 102 discussed above, the core network device 800 may be implemented as one or more of the network functions/entities/devices 104-109 discussed above, and the application server device 900 may be implemented as the application server 103 discussed above.

Referring to Fig. 9A, the terminal device 700 may comprise one or more processors 710, one or more memories 720 and one or more transceivers 730 interconnected through one or more buses 740. The one or more transceivers 730 each may comprise a receiver and a transmitter, which are connected to one or more antennas 750. The terminal device 700 may wirelessly communicate with a base station (not shown) through the one or more antennas 750. The one or more memories 720 may include instructions 722 which, when executed by the one or more processors 710, may cause the terminal device 700 to perform operations relating to the UE 102 as described above.

Referring to Fig. 9B, the core network device 800 may comprise one or more processors 810, one or more memories 820, and one or more network interfaces 830 interconnected through one or more buses 840. The one or more network interfaces 830 may provide wired or wireless communication links through which the core network device 800 may communicate with other network devices, entities, nodes, functions or elements. For instance, the core network device 800 may communicate with a base station (not shown) serving the terminal device 700 (Fig. 9A) via backhaul links. The one or more memories 820 may include instructions 822 which, when executed by the one or more processors 810, may cause the core network device 800 to perform operations relating to one or more of the network functions/entities/devices 104-109 as described above.

Referring to Fig. 9C, the application server device 900 may comprise one or more processors 910, one or more memories 920, and one or more network interfaces 930 interconnected through one or more buses 940. The one or more network interfaces 930 may provide wired or wireless communication links through which the application server device 900 may communicate with other terminal or network devices, entities, nodes, functions or elements. The one or more memories 920 may include instructions 922 which, when executed by the one or more processors 910, may cause the application server device 900 to perform operations relating to the application server 103 as described above.

The one or more processors 710, 810 and 910 discussed above may be of any appropriate type that is suitable for the local technical network, and may include one or more of general purpose processors, special purpose processor, microprocessors, a digital signal processor (DSP) , one or more processors in a processor based multi-core processor architecture, as well as dedicated processors such as those developed based on Field Programmable Gate Array (FPGA) and Application Specific Integrated Circuit (ASIC) . The one or more processors 710, 810 and 910 may be configured to control other elements of the terminal/core network/application server devices and operate in cooperation with them to implement the processes discussed above.

The one or more memories 720, 820 and 920 may include at least one storage medium in various forms, such as a transitory memory and/or a non-transitory memory. The transitory memory may include, but not limited to, for example, a random access memory (RAM) or a cache. The non-transitory memory may include, but not limited to, for example, a read only memory (ROM) , a hard disk, a flash memory, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) . Further, the one or more memories 720, 820 and 920 may include but not limited to an electric, a magnetic, an optical, an electromagnetic, an infrared, or a semiconductor system, apparatus, or device or any combination of the above.

It would be understood that blocks in the drawings may be implemented in various manners, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more blocks/operations may be implemented using software and/or firmware, for example, machine-executable instructions stored in the storage medium. In addition to or instead of machine-executable instructions, parts or all of the blocks in the drawings may be implemented, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs) , Application-Specific Integrated Circuits (ASICs) , Application-Specific Standard Products (ASSPs) , System-on-Chip systems (SOCs) , Complex Programmable Logic Devices (CPLDs) , etc.

Some exemplary embodiments further provide a computer program including instructions which, when executed by one or more processors, may cause a device or apparatus to perform the procedures described above. The program instructions for carrying out procedures of the exemplary embodiments may be written in any combination of one or more programming languages. The program instructions may be provided to one or more processors or controllers of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program instructions, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program instructions may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

Some exemplary embodiments further provide a computer program product or a computer readable medium having the program instruction or instructions stored therein. The computer readable medium may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or all the elements.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

Although the subject matter has been described in a language that is specific to structural features and/or method actions, it is to be understood the subject matter defined in the appended claims is not limited to the specific features or actions described above. On the contrary, the above-described specific features and actions are disclosed as an example of implementing the claims.

Claims

An application client, comprising instructions for performing at least the following:

sending, to an application server, an application service request including a temporary identifier of a user equipment on which the application client is running; and

receiving, from the application server, an application service response.
The application client of claim 1, further comprising instructions for performing at least the following:

sending, to the user equipment, a temporary identifier request; and

receiving, from the user equipment, a temporary identifier response including the temporary identifier.
A user equipment, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the user equipment at least to perform:

sending, to an application server, an application service request including at least one of:

a temporary identifier of the user equipment associated with a protocol data unit session supporting the application service, or

an authentication and key management for applications, AKMA, key identifier; and receiving, from the application server, an application service response.
The user equipment of claim 3, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the user equipment at least to perform:

sending, to a session management function entity, a protocol data unit session request to establish or modify a protocol data unit session to support the application service; and

receiving, from the session management function entity, a message including the temporary identifier.
The user equipment of claim 4, wherein the temporary identifier is received in a protocol data unit session establishment or modification response message or an extended protocol configuration option message from the session management function entity.
The user equipment of claim 4 or 5, wherein the protocol data unit session request is triggered by a temporary identifier request from an application client running on the user equipment, and the temporary identifier is sent in a temporary identifier response to the application client.
The user equipment of any of claims 4-6, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the user equipment at least to perform:

generating a preliminary temporary identifier; and

providing the preliminary temporary identifier to the session management function entity.
The user equipment of any of claims 4-7, wherein the protocol data unit session request further includes an application function identifier.
An application server, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the application server at least to perform:

receiving, from a user equipment, an application service request including a temporary identifier of the user equipment associated with a protocol data unit session supporting the application service;

sending, to a network exposure function entity, a user equipment identifier request including the temporary identifier;

receiving, from the network exposure function entity, a user equipment identifier response including an application specific user equipment identifier;

sending, to the network exposure function entity, a user equipment information request including the application specific user equipment identifier;

receiving, from the network exposure function entity, a user equipment information response including the requested user equipment information; and

sending, to the user equipment, an application service response.
The application server of claim 9, wherein the user equipment information is location of the user equipment.
A session management function entity, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the session management function entity at least to perform:

receiving, from a user equipment, a protocol data unit session request;

sending, to a unified data management function entity, information of a protocol data unit session associated with the protocol data unit session request;

receiving, from the unified data management function entity, a temporary identifier associated with the protocol data unit session; and

sending, to the user equipment, a message including the temporary identifier.
The session management function entity of claim 11, wherein the temporary identifier is sent in a protocol data unit session establishment or modification response message or an extended protocol configuration option message to the user equipment.
The session management function entity of claim 11 or 12, wherein the protocol data unit session request includes a preliminary temporary identifier, and the session management function entity includes the preliminary temporary identifier in the protocol data unit session information sent to the unified data management function entity.
The session management function entity of any of claims 11-13, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the session management function entity at least to perform:

generating a preliminary temporary identifier; and

providing the preliminary temporary identifier to the unified data management function entity.
A network exposure function entity, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the network exposure function entity at least to perform:

receiving, from an application server, a user equipment identifier request including a temporary identifier of a user equipment;

retrieving a user equipment identifier from a unified data management function entity based on the temporary identifier;

retrieving an application specific user equipment identifier from the unified data management function entity based on the user equipment identifier and an application function identifier; and

sending, to the application server, a user equipment identifier response including the application specific user equipment identifier.
The network exposure function entity of claim 15, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the network exposure function entity at least to perform:

determining the unified data management function entity to retrieve the user equipment identifier, based on information identifying a unified data management group identifier contained in the temporary identifier.
The network exposure function entity of claim 15 or 16, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the network exposure function entity at least to perform:

verifying an application function identifier retrieved along with the user equipment identifier from the unified data management function entity by comparing it with an application function identifier received in the user equipment identifier request from the application server.
The network exposure function entity of any of claims 15-17, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the network exposure function entity at least to perform:

after retrieving the application specific user equipment identifier from the unified data management function entity, selecting an access control policy for the application specific user equipment identifier;

receiving, from the application server, a user equipment information request including the application specific user equipment identifier;

verifying the application specific user equipment identifier included in the user equipment information request being compliant with the access control policy; and

sending, to the application server, a user equipment information response including the requested user equipment information.
A unified data management function entity, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the unified data management function entity at least to perform:

receiving, from a session management function entity, information of a protocol data unit session;

generating a temporary identifier for the protocol data unit session, the temporary identifier containing information identifying a unified data management group identifier associated with the unified data management function entity;

storing a mapping between the temporary identifier and a user equipment identifier in a unified data repository function entity, the user equipment identifier representing a user equipment associated with the protocol data unit session; and

sending, to the session management function entity, the temporary identifier.
The unified data management function entity of claim 19, wherein the protocol data unit session information received from the session management function entity contains a preliminary temporary identifier, and the unified data management function entity generates the temporary identifier per the preliminary temporary identifier.
A unified data management function entity, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the unified data management function entity at least to perform:

receiving, from a network exposure function entity, a user equipment identifier retrieval request containing a temporary identifier of a user equipment;

sending, to the network exposure function entity, a user equipment identifier retrieval response including a user equipment identifier mapping to the temporary identifier;

receiving, from the network exposure function entity, an application specific user equipment identifier retrieval request containing the user equipment identifier and an application function identifier; and

sending, to the network exposure function entity, an application specific user equipment identifier retrieval response including an application specific user equipment identifier corresponding to the user equipment identifier and the application function identifier.
An application server, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the application server at least to perform:

receiving, from a user equipment, an application service request including an authentication and key management for applications, AKMA, key identifier;

sending, to a network exposure function entity, an application key request including the AKMA key identifier;

receiving, from the network exposure function entity, an application key response including an application key for the application server and a generic public subscription identifier of the user equipment;

sending, to the network exposure function entity, a user equipment information request including the generic public subscription identifier;

receiving, from the network exposure function entity, a user equipment information response including the requested user equipment information; and

sending, to the user equipment, an application service response.
A network exposure function entity, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the network exposure function entity at least to perform:

receiving, from an application server, an application key request including an authentication and key management for applications, AKMA, key identifier;

retrieving an application key for the application server and a subscription permanent identifier from an AKMA anchor function entity based on the AKMA key identifier;

translating the subscription permanent identifier into a generic public subscription identifier;

sending, to the application server, an application key response including the application key for the application server and the generic public subscription identifier;

receiving, from the application server, a user equipment information request including the generic public subscription identifier; and

sending, to the application server, a user equipment information response.
The network exposure function entity of claim 23, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the network exposure function entity at least to perform:

after translating the subscription permanent identifier into the generic public subscription identifier, selecting an access control policy for the generic public subscription identifier; and

in response to the user equipment information request including the generic public subscription identifier received from the application server, verifying the generic public subscription identifier included in the user equipment information request being compliant with the access control policy.
An application server, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the application server at least to perform:

receiving, from a user equipment, an application service request including at least one of a temporary identifier of the user equipment or an authentication and key management for applications, AKMA, key identifier;

sending, to a network exposure function entity, a user equipment information request including the at least one of the temporary identifier and the AKMA key identifier;

receiving, from the network exposure function entity, a user equipment information response including the requested user equipment information; and

sending, to the user equipment, an application service response.
The application server of claim 25, wherein in case the application service request received from the user equipment includes the AKMA key identifier, the user equipment information request sent to the network exposure function entity includes the AKMA key identifier and an application function identifier.
A network exposure function entity, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the network exposure function entity at least to perform:

receiving, from an application server, a user equipment information request including a temporary identifier of a user equipment;

retrieving a user equipment identifier from a unified data management function entity based on the temporary identifier;

retrieving the requested user equipment information based on the user equipment identifier; and

sending, to the application server, a user equipment information response.
The network exposure function entity of claim 27, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the network exposure function entity at least to perform:

verifying an application function identifier retrieved along with the user equipment identifier from the unified data management function entity by comparing it with an application function identifier received in the user equipment identifier request from the application server.
A network exposure function entity, comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the network exposure function entity at least to perform:

receiving, from an application server, a user equipment information request including an authentication and key management for applications, AKMA, key identifier;

retrieving a subscription permanent identifier from an AKMA anchor function entity based on the AKMA key identifier;

retrieving the requested user equipment information based on the subscription permanent identifier; and

sending, to the application server, a user equipment information response.
A method, comprising:

sending, from an application client to an application server, an application service request including a temporary identifier of a user equipment on which the application client is running; and

receiving, from the application server, an application service response.
The method of claim 30, further comprising:

sending, to the user equipment, a temporary identifier request; and

receiving, from the user equipment, a temporary identifier response including the temporary identifier.
A method, comprising:

sending, to an application server, an application service request including at least one of:

a temporary identifier of a user equipment associated with a protocol data unit session supporting the application service, or

an authentication and key management for applications, AKMA, key identifier; and receiving, from the application server, an application service response.
The method of claim 32, further comprising:

sending, to a session management function entity, a protocol data unit session request to establish or modify a protocol data unit session to support the application service; and

receiving, from the session management function entity, a message including the temporary identifier.
The method of claim 33, wherein the temporary identifier is received in a protocol data unit session establishment or modification response message or an extended protocol configuration option message from the session management function entity
The method of claim 33 or 34, wherein the protocol data unit session request is triggered by a temporary identifier request from an application client running on the user equipment, and the temporary identifier is sent in a temporary identifier response to the application client.
The method of any of claims 33-35, further comprising:

generating a preliminary temporary identifier; and

providing the preliminary temporary identifier to the session management function entity.
The method of any of claims 33-36, wherein the protocol data unit session request further includes an application function identifier.
A method, comprising:

receiving, from a user equipment, an application service request including a temporary identifier of the user equipment associated with a protocol data unit session supporting the application service;

sending, to a network exposure function entity, a user equipment identifier request including the temporary identifier;

receiving, from the network exposure function entity, a user equipment identifier response including an application specific user equipment identifier;

sending, to the network exposure function entity, a user equipment information request including the application specific user equipment identifier;

receiving, from the network exposure function entity, a user equipment information response including the requested user equipment information; and

sending, to the user equipment, an application service response.
The method of claim 38, wherein the user equipment information is location of the user equipment.
A method, comprising:

receiving, from a user equipment, a protocol data unit session request;

sending, to a unified data management function entity, information of a protocol data unit session associated with the protocol data unit session request;

receiving, from the unified data management function entity, a temporary identifier associated with the protocol data unit session; and

sending, to the user equipment, a message including the temporary identifier.
The method of claim 40, wherein the temporary identifier is sent in a protocol data unit session establishment or modification response message or an extended protocol configuration option message to the user equipment.
The method of claim 40 or 41, wherein the protocol data unit session request includes a preliminary temporary identifier, and the preliminary temporary identifier is included in the protocol data unit session information sent to the unified data management function entity.
The method of any of claims 40-42, further comprising:

generating a preliminary temporary identifier; and

providing the preliminary temporary identifier to the unified data management function entity.
A method, comprising:

receiving, from an application server, a user equipment identifier request including a temporary identifier of a user equipment;

retrieving a user equipment identifier from a unified data management function entity based on the temporary identifier;

retrieving an application specific user equipment identifier from the unified data management function entity based on the user equipment identifier and an application function identifier; and

sending, to the application server, a user equipment identifier response including the application specific user equipment identifier.
The method of claim 44, further comprising:

determining the unified data management function entity to retrieve the user equipment identifier, based on information identifying a unified data management group identifier contained in the temporary identifier.
The method of claim 44 or 45, further comprising:

verifying an application function identifier retrieved along with the user equipment identifier from the unified data management function entity by comparing it with an application function identifier received in the user equipment identifier request from the application server.
The method of any of claims 44-46, further comprising:

after retrieving the application specific user equipment identifier from the unified data management function entity, selecting an access control policy for the application specific user equipment identifier;

receiving, from the application server, a user equipment information request including the application specific user equipment identifier;

verifying the application specific user equipment identifier included in the user equipment information request being compliant with the access control policy; and

sending, to the application server, a user equipment information response including the requested user equipment information.
A method, comprising:

receiving, from a session management function entity, information of a protocol data unit session;

generating a temporary identifier for the protocol data unit session, the temporary identifier containing information identifying a unified data management group identifier associated with a unified data management function entity;

storing a mapping between the temporary identifier and a user equipment identifier in a unified data repository function entity, the user equipment identifier representing a user equipment associated with the protocol data unit session; and

sending, to the session management function entity, the temporary identifier.
The method of claim 48, wherein the protocol data unit session information received from the session management function entity contains a preliminary temporary identifier, and the temporary identifier is generated per the preliminary temporary identifier.
A method, comprising:

receiving, from a network exposure function entity, a user equipment identifier retrieval request containing a temporary identifier of a user equipment;

sending, to the network exposure function entity, a user equipment identifier retrieval response including a user equipment identifier mapping to the temporary identifier;

receiving, from the network exposure function entity, an application specific user equipment identifier retrieval request containing the user equipment identifier and an application function identifier; and

sending, to the network exposure function entity, an application specific user equipment identifier retrieval response including an application specific user equipment identifier corresponding to the user equipment identifier and the application function identifier.
A method, comprising:

receiving, from a user equipment, an application service request including an authentication and key management for applications, AKMA, key identifier;

sending, to a network exposure function entity, an application key request including the AKMA key identifier;

receiving, from the network exposure function entity, an application key response including an application key for an application server and a generic public subscription identifier of the user equipment;

sending, to the network exposure function entity, a user equipment information request including the generic public subscription identifier;

receiving, from the network exposure function entity, a user equipment information response including the requested user equipment information; and

sending, to the user equipment, an application service response.
A method, comprising:

receiving, from an application server, an application key request including an authentication and key management for applications, AKMA, key identifier;

retrieving an application key for the application server and a subscription permanent identifier from an AKMA anchor function entity based on the AKMA key identifier;

translating the subscription permanent identifier into a generic public subscription identifier;

sending, to the application server, an application key response including the application key for the application server and the generic public subscription identifier;

receiving, from the application server, a user equipment information request including the generic public subscription identifier; and

sending, to the application server, a user equipment information response.
The method of claim 52, further comprising:

after translating the subscription permanent identifier into the generic public subscription identifier, selecting an access control policy for the generic public subscription identifier; and

in response to the user equipment information request including the generic public subscription identifier received from the application server, verifying the generic public subscription identifier included in the user equipment information request being compliant with the access control policy.
A method, comprising:

receiving, from a user equipment, an application service request including at least one of a temporary identifier of the user equipment or an authentication and key management for applications, AKMA, key identifier;

sending, to a network exposure function entity, a user equipment information request including the at least one of the temporary identifier and the AKMA key identifier;

receiving, from the network exposure function entity, a user equipment information response including the requested user equipment information; and

sending, to the user equipment, an application service response.
The method of claim 54, wherein in case the application service request received from the user equipment includes the AKMA key identifier, the user equipment information request sent to the network exposure function entity includes the AKMA key identifier and an application function identifier.
A method, comprising:

receiving, from an application server, a user equipment information request including a temporary identifier of a user equipment;

retrieving a user equipment identifier from a unified data management function entity based on the temporary identifier;

retrieving the requested user equipment information based on the user equipment identifier; and

sending, to the application server, a user equipment information response.
The method of claim 56, further comprising:

verifying an application function identifier retrieved along with the user equipment identifier from the unified data management function entity by comparing it with an application function identifier received in the user equipment identifier request from the application server.
A method, comprising:

receiving, from an application server, a user equipment information request including an authentication and key management for applications, AKMA, key identifier;

retrieving a subscription permanent identifier from an AKMA anchor function entity based on the AKMA key identifier;

retrieving the requested user equipment information based on the subscription permanent identifier; and

sending, to the application server, a user equipment information response.
An apparatus for a user equipment, comprising means for performing the method of any of claims 30-37.
An apparatus for an application server, comprising means for performing the method of any of claims 38-39, 51, 54-55.
An apparatus for a session management function entity, comprising means for performing the method of any of claims 40-43.
An apparatus for a network exposure function entity, comprising means for performing the method of any of claims 44-47, 52-53, 56-58.
An apparatus for a unified data management function entity, comprising means for performing the method of any of claims 48-50.
A computer readable medium comprising instructions that, when executed by an apparatus for a user equipment, cause the user equipment to at least perform the method of any of claims 30-37.
A computer readable medium comprising instructions that, when executed by an apparatus for an application server, cause the application server to at least perform the method of any of claims 38-39, 51, 54-55.
A computer readable medium comprising instructions that, when executed by an apparatus for a session management function entity, cause the session management function entity to at least perform the method of any of claims 40-43.
A computer readable medium comprising instructions that, when executed by an apparatus for a network exposure function entity, cause the network exposure function entity to at least perform the method of any of claims 44-47, 52-53, 56-58.
A computer readable medium comprising instructions that, when executed by an apparatus for a unified data management function entity, cause the unified data management function entity to at least perform the method of any of claims 48-50.