Method and related devices for authentication server function selection in authentication and key management

Abstract

Embodiments include methods performed by a key management node in a communication network. Such methods can include receiving, from an application function, a request for a security key specific to an application session for a particular user. The request can include a representation of information associated with the particular user: a first identifier of a non-application-specific anchor security key, and a second identifier related to a network subscription. Such methods can also include determining, based on the representation, an authentication server function to generate the non-application-specific anchor security key. Other embodiments include complementary methods performed by an application function, an authentication server function, and a unified data management function in a communication network. Other embodiments include network nodes configured to perform such methods.

Description

Technical Field

[0001] This application generally relates to the field of communication networks, and more specifically, to techniques for authentication and key management for secure use in relation to applications in communication networks. Background Technology

[0002] Long Term Evolution (LTE) is an umbrella term for the so-called fourth-generation (4G) radio access technology developed within the 3rd Generation Partnership Project (3GPP) and initially standardized in Releases 8 and 9, also known as Evolved UTRAN (EUTRAN). LTE targets a variety of licensed frequency bands and is accompanied by improvements to non-radio aspects commonly referred to as System Architecture Evolution (SAE), which includes the Evolved Packet Core (EPC) network. LTE continues to evolve through subsequent releases. One of the features of Release 11 is the Enhanced Physical Downlink Control Channel (ePDCCH), which aims to increase capacity and improve spatial reuse of control channel resources, improve inter-cell interference coordination (ICIC), and support antenna beamforming and / or transmit diversity for the control channel.

[0003] Figure 1 A general example architecture of a network including LTE and SAE is shown. E-UTRAN 100 includes one or more evolved Node Bs (eNBs) (such as eNB 105, 110, and 115) and one or more User Equipments (UEs) (such as UE 120). As used within 3GPP standards, "User Equipment" or "UE" means any wireless communication device (e.g., a smartphone or computing device) capable of communicating with network equipment compliant with 3GPP standards, including E-UTRAN as well as UTRAN and / or GERAN, since third-generation ("3G") and second-generation ("2G") 3GPP radio access networks are well-known.

[0004] As specified by 3GPP, E-UTRAN 100 is responsible for all radio-related functions in the network (including radio bearer control, radio admission control, radio mobility control, scheduling, and dynamic resource allocation to UEs in uplink and downlink) and the security of communications with UEs. These functions reside in eNBs, such as eNBs 105, 110, and 115. eNBs in E-UTRAN communicate with each other via X1 interfaces, such as... Figure 1 As shown. The eNB is also responsible for the E-UTRAN interface to the EPC 130, specifically the S1 interface to the Mobility Management Entity (MME) and the Serving Gateway (SGW), which are collectively shown as Figure 1The MME / S-GW134 and 138 are used in this context. Generally, the MME / S-GW handles the overall control of the UE and the remaining data flow between the UE and the EPC. More specifically, the MME handles the signaling (e.g., control plane) protocols between the UE and the EPC, which are referred to as Non-Access Stratum (NAS) protocols. The S-GW handles all Internet Protocol (IP) data packets (e.g., data or user plane) between the UE and the EPC and serves as a local mobility anchor for data bearer when the UE moves between eNBs (such as eNBs 105, 110, and 115).

[0005] EPC 130 may also include a Home Subscriber Server (HSS) 131, which manages user-related information and subscriber-related information. HSS 131 may also provide support for mobility management, call and session settings, user authentication, and access authorization. The functionality of HSS 131 may be related to the functionality or operation of a traditional Home Location Register (HLR) and Authorization Center (AuC).

[0006] In some embodiments, the HSS 131 can connect to the User Data Storage Library (UDR) via a Ud interface. Figure 1 The EPC-UDR 135 is labeled as EPC-UDR 135 - Communications. The EPC-UDR 135 can store user credentials encrypted using the AuC algorithm. These algorithms are not standardized (i.e., vendor-specific) to ensure that the encrypted credentials stored in the EPC-UDR 135 cannot be accessed by any other vendor besides the one using the HSS 131.

[0007] Within 3GPP, a research project on a new radio interface for fifth-generation (5G) cellular (e.g., wireless) networks has been completed, and 3GPP is now standardizing this new radio interface (often abbreviated as NR (New Radio)). Figure 2 A high-level view of the 5G network architecture is shown, including a next-generation RAN (NG-RAN) 299 and a 5G core (5GC) 298. The NG-RAN 299 may include a group of gNodeBs (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs 200 and 250 connected via interfaces 202 and 252, respectively. Additionally, gNBs may connect to each other via one or more Xn interfaces, such as Xn interface 240 between gNBs 200 and 250. Regarding the NR interface to the UE, each gNB may support frequency division duplex (FDD), time division duplex (TDD), or a combination thereof.

[0008] NG-RAN 299 is layered into the Radio Network Layer (RNL) and the Transport Network Layer (TNL). The NG-RAN architecture (i.e., NG-RAN logical nodes and the interfaces between them) is defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the associated TNL protocols and functions are specified. The TNL provides services for user plane transport and signaling transport. In some example configurations, each gNB is connected to all 5GC nodes within the “AMF area” defined in 3GPP TS 23.501. If security protection for CP and UP data on the TNL for NG-RAN interfaces is supported, then NDS / IP (3GPP TS 33.401) should be applied.

[0009] exist Figure 2 The NG RAN logical node shown (and described in 3GPP TS 38.401 and 3GPP TR 38.801) includes a central (or centralized) unit (CU or gNB-CU) and one or more distributed (or decentralized) units (DU or gNB-DU). For example, gNB 200 includes gNB-CU 210 and gNB-DU 220, 230. A CU (e.g., gNB-CU 210) is a logical node that hosts higher-level protocols and performs various gNB functions, such as controlling the operation of the DU. Each DU is a logical node that hosts lower-level protocols and may include various subsets of gNB functions (depending on the function segmentation). Thus, each of the CU and DU may include various circuitry required to perform its respective function, including processing circuitry, transceiver circuitry (e.g., for communication), and power supply circuitry. Furthermore, the terms "central unit" and "centralized unit" are used interchangeably herein, as are the terms "distributed unit" and "decentralized unit".

[0010] gNB-CU communicates through the corresponding F1 logic interface (such as...) Figure 3 Interfaces 222 and 232 shown are connected to the gNB-DU. The gNB-CU and the connected gNB-DU are visible to other gNBs and 5GCs only as gNBs. In other words, the F1 interface is not visible outside of the gNB-CU.

[0011] Figure 3A high-level view of an example 5G network architecture is shown, including a Next-Generation Radio Access Network (NG-RAN) 399 and a 5G Core (5GC) 398. As shown, the NG-RAN 399 may include gNBs 310 (e.g., 310a, b) and ng-eNBs 320 (e.g., 320a, b), which are interconnected with each other via corresponding Xn interfaces. The gNBs and ng-eNBs are also connected to the 5GC 398 via NG interfaces, and more specifically, to the AMF (Access and Mobility Management Functions) 330 (e.g., AMF 330a, b) via corresponding NG-C interfaces, and to the UPF (User Plane Functions) 340 (e.g., UPF 340a, b) via corresponding NG-U interfaces. Moreover, the AMF 340a, b can communicate with one or more Policy Control Functions (PCFs, e.g., PCF 350a, b) and Network Open Functions (NEFs, e.g., NEF 360a, b). The AMF, UPF, PCF, and NEF are further described below.

[0012] Each of the gNB 310s can support an NR radio interface, including Frequency Division Duplex (FDD), Time Division Duplex (TDD), or a combination thereof. Conversely, each of the ng-eNB 320s supports an LTE radio interface, but not with traditional LTE eNBs (such as...). Figure 1 Unlike the one shown, it connects to the 5GC via the NG interface.

[0013] Deployments based on different 3GPP architecture options (e.g., EPC-based or 5GC-based) and UEs with different capabilities (e.g., EPC NAS and 5GC NAS) can coexist within a single network (e.g., a PLMN). It is generally assumed that a UE capable of supporting 5GC NAS procedures can also support (e.g., as defined in 3GPP TS 24.301) EPC NAS procedures to operate in legacy networks, such as during roaming. Therefore, the UE will depend on the core network (CN) serving it to use either the EPC NAS or 5GC NAS procedures.

[0014] Another change in 5G networks (e.g., 5GC) is the modification of traditional peer-to-peer interfaces and protocols (e.g., those found in LTE / EPC networks) to a so-called Service-Based Architecture (SBA), in which a Network Function (NF) provides one or more services to one or more service consumers. This can be accomplished, for example, through a Hypertext Transfer Protocol / Representation State Transfer (HTTP / REST) ​​Application Programming Interface (API). Typically, the various services are self-contained functions that can be changed and modified in an isolated manner without affecting other services.

[0015] Furthermore, services are composed of various "service operations," which are more granular divisions of the overall service functionality. To access a service, both the service name and the target service operation must be specified. Interactions between service consumers and producers can be of "request / response" or "subscription / notification" type. In 5G SBA, the Network Library Function (NRF) allows each network function to discover services provided by other network functions, while the Data Storage Function (DSF) allows each network function to store its context.

[0016] As discussed above, in 5G SBA, services can be deployed as part of network functions (NFs). This SBA model further adopts principles similar to the modularity, reusability, and self-containment of NFs, enabling deployments to leverage the latest virtualization and software technologies. Figure 4 An example non-roaming 5G reference architecture is shown, which has service-based interfaces and various NFs defined in the control plane (CP). These include the following NFs, with additional details provided for those most relevant to this disclosure:

[0017] • Access and Mobility Management Functions (AMF) with Namf Interface — terminates the RAN CP interface and handles all mobility and connectivity management for the UE (similar to the MME in the EPC).

[0018] • Session Management Function (SMF) with Nsmf interface — Interacts with the decoupled user (or data) plane, including creating, updating, and deleting Protocol Data Unit (PDU) sessions and managing session context with User Plane Functions (UPF), such as for event reporting.

[0019] • User plane function (UPF) with Nupf interface — Supports processing user plane services based on rules received from SMF, including packet inspection and various execution actions (e.g., event detection and reporting).

[0020] • Policy control function (PCF) with NPCF interface — Supports a unified policy framework to manage network behavior, for example, by providing PCC rules to the SMF.

[0021] • Network Open Function (NEF) with Nnef interface — Acts as an entry point to the operator's network by securely opening up network capabilities and events provided by 3GPP NF to the AF and providing the AF with a way to provide information to the 3GPP network security.

[0022] • Network Repository Function (NRF) with Nnrf interface — provides service registration and discovery, enabling NFs to identify the appropriate services available from other NFs.

[0023] • Network Slice Selection Function (NSSF) with Nnssf Interface — A “network slice” is a logical partition of a 5G network that provides specific network capabilities and features, such as supporting specific services. A network slice instance is a set of NF instances and the network resources (e.g., compute, storage, communication) required to provide the capabilities and features of a network slice. NSSF enables other NFs (e.g., AMFs) to identify network slice instances suitable for the UE's desired services.

[0024] • Authentication Server Functionality with Nausf Interface (AUSF) — Located on the user’s home network (HPLMN), it performs user authentication and calculates security key material for various purposes.

[0025] • Application Functions (AF) with Naf Interface — Interacts with 3GPP CN to provide information to network operators and subscribe to certain events occurring in the operator's network.

[0026] Figure 4 The Unified Data Management (UDM) entity shown (also referred to as UDM or UDM function in this document) is similar to the HSS in the LTE / EPC network discussed above. UDM supports the generation of 3GPP AKA authentication credentials, user identification processing, access authorization based on subscription data, and other user-related functions. To provide this functionality, UDM uses subscription data (including authentication data) stored in the 5GC Unified Data Repository (UDR). In addition to UDM, UDR supports PCF storage and retrieval of policy data and NEF storage and retrieval of application data.

[0027] 3GPP Rel-16 introduced a new feature called Application Authentication and Key Management (AKMA), which is based on 3GPP user credentials in 5G, including IoT use cases. More specifically, AKMA utilizes the user's AKA (Authentication and Key Protocol) credentials to bootstrap security between the UE and the Application Function (AF), allowing the UE to securely exchange data with the application server. The AKMA architecture can be considered an evolution of the GBA (General Bootstrap Architecture) specified for 5GC in 3GPP Rel-15 and is further specified in 3GPP TS33.535 (v.0.2.0 is under revision).

[0028] Apart from Figure 4 In addition to NEF, AUSF, and AF shown and described above, Rel-16 AKMA also utilizes the Anchor Function (AAnF) for application authentication and key management. This function... Figure 4As shown, it has a Naanf interface. Typically, AAnF interacts with AUSF and maintains the UE AKMA context for use by application functions, for example, in subsequent boot requests. Generally, AAnF is similar to the Boot Server Function (BSF) defined in Rel-15 GBA.

[0029] However, within this architecture, various challenges, problems, and / or difficulties may arise related to the synchronization of key materials generated by AUSF for users and key materials used by AAnF to generate application-specific keys for user application sessions. These challenges, problems, and / or difficulties can prevent (e.g., on the UE) the establishment of secure communication between user applications and corresponding application functions (e.g., servers). Summary of the Invention

[0030] Certain embodiments of this disclosure provide specific improvements to secure communication between an application (e.g., a client) and application functions (e.g., a server), such as by facilitating solutions to overcome the example problems summarized above and described in more detail below.

[0031] Example embodiments include methods (e.g., procedures) performed by a key management server (e.g., AAnF) in a communication network (e.g., 5GC). These embodiments may include receiving a request from an application function for a security key (Kaf) specific to an application session for a particular user. The request may include a representation of the following information associated with the particular user: a first identifier (KakmaID) of a non-application-specific anchor security key (Kakma), and a second identifier associated with a network subscription. These example methods may also include, based on this representation, determining an authentication server function (AUSF) that generates a non-application-specific anchor security key (Kakma).

[0032] In some embodiments, these example methods may further include: obtaining a non-application-specific anchor security key (Kakma) from the determined AUSF, and generating an application session-specific security key (Kaf) based on the non-application-specific anchor security key (Kakma). In some embodiments, these example methods may further include: sending the application session-specific security key (Kaf) to an application function.

[0033] In some embodiments, the representation may include a third identifier (B-ID) that may include a non-application-specific anchor security key (Kakma) and the AUSF that generated the Kakma. The third identifier may include representations of the first and second identifiers and information associated with the AUSF. In various embodiments, the information associated with the AUSF may include one or more of the following: AUSF group ID, AUSF ID, Subscribed Permanent Identifier (SUPI) range, Fully Qualified Domain Name (FQDN), and IP address.

[0034] In this embodiment, the determination operation may include: discovering the identifier of the AUSSF via a Network Repository Function (NRF) based on information associated with the AUSSF. Furthermore, in this embodiment, the acquisition operation may include: sending a request to the determined AUSSF including a third identifier (e.g., B-TID); and receiving a response from the determined AUSSF including a non-application-specific anchor security key (Kakma) and a second identifier.

[0035] In other embodiments, the representation of the first and second identifiers may include a first identifier (e.g., KakmaID) and a second identifier. For example, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Subscription Hidden Identifier (SUCI); Subscription Permanent Identifier (SUPI); or General Public Subscription Identifier (GPSI). In variations, the representation may include only the first identifier (e.g., KakmaID), which may include a representation of the second identifier.

[0036] In this embodiment, the determination operation may include: selecting a Unified Data Management (UDM) entity in the communication network based on a second identifier; sending a first request to the UDM entity for a fourth identifier associated with AUSF; and receiving a first response from the UDM entity including the fourth identifier. In some embodiments, the first response may also include another second identifier related to a network subscription associated with a specific user. For example, the other second identifier may be SUPI, and the second identifier may be an identifier different from SUPI (e.g., GPSI, SUCI, HPLMN+RID).

[0037] In this embodiment, the acquisition operation may include: sending a second request to an AUSF associated with a fourth identifier, the second request including the second identifier or another second identifier related to a network subscription associated with a specific user; and receiving a second response from the AUSF including a non-application-specific anchor security key (Kakma). In some embodiments, the second request or the second response may also include the second identifier. For example, if the second request includes another second identifier (e.g., SUPI), the second response may include the second identifier (e.g., an identifier different from SUPI).

[0038] Example embodiments also include other methods (e.g., procedures) performed by a key management server (e.g., AAnF) in a communication network (e.g., 5GC). These example methods may include receiving, from an Authentication Server Function (AUSF), the following information associated with a specific user: a non-application-specific anchor security key (Kakma); a first identifier (KakmaID) of the non-application-specific anchor security key; and a second identifier associated with a network subscription. In some embodiments, the second identifier may be a subscription persistent identifier (SUPI).

[0039] These example methods may also include: receiving a request from an application function for a security key (Kaf) specific to an application session for a specific user, wherein the request includes another identifier (KakmaID) of a non-application-specific anchor security key associated with the specific user. The request may include another identifier (KakmaID) of a non-application-specific anchor security key associated with the specific user. These example methods may also include: generating an application session-specific security key (Kaf) based on a match between a first identifier and another identifier (e.g., a matching KakmaID).

[0040] In some embodiments, the key management server may include multiple Anchor Function (AAnF) instances for application authentication and key management, each AAnF instance corresponding to a range of User Equipment Routing Indicators (RIDs). In this embodiment, the request may also include a Routing Indicator (RID) associated with a specific user, and these example methods may further include selecting an AAnF instance based on the received RID, wherein the generation of an application session-specific security key (Kaf) is performed by the selected AAnF instance.

[0041] In some embodiments, the key management server may be associated with one or more ranges of a user equipment routing indicator (RID). In such embodiments, these example methods may further include registering the association between the key management server and one or more ranges with a network repository function (NRF) in the communication network.

[0042] Example embodiments also include methods (e.g., procedures) performed by application functions in a communication network (e.g., 5GC). These example methods may include: receiving a first request from a user equipment for establishing an application session. The first request may include a representation of information associated with a specific user: a first identifier (KakmaID) of a non-application-specific anchor security key (Kakma), and a second identifier associated with a network subscription. These example methods may also include: sending a second request for an application session-specific security key (Kaf) to an anchor function (AAnF) in the communication network for application authentication and key management. The second request may include representations of the first and second identifiers.

[0043] These example methods may also include receiving an application session-specific security key (Kaf) from AAnF. In some embodiments, these example methods may also include establishing a secure application session with the user device based on the received security key (Kaf).

[0044] In some embodiments, a third identifier (B-ID) represents the binding between a non-application-specific anchor security key (Kakma) and the AUSF that generated the Kakma. Specifically, the third identifier may include representations of the first and second identifiers, as well as information associated with the AUSF. In various embodiments, the information associated with the AUSF may include one or more of the following: AUSF group ID, AUSF ID, Subscribed Permanent Identifier (SUPI) range, Fully Qualified Domain Name (FQDN), and IP address.

[0045] In other embodiments, the representation of the first and second identifiers may include both the first and second identifiers. For example, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Subscription Hidden Identifier (SUCI); Subscription Permanent Identifier (SUPI); or General Public Subscription Identifier (GPSI). In variations, the representation may include only the first identifier (e.g., KakmaID), which includes a representation of the second identifier.

[0046] Example embodiments also include methods (e.g., procedures) performed by an Authentication Server Function (AUSF) in a communication network (e.g., 5GC). These example methods may include: receiving a request from an Anchor Function (AAnF) for Application Authentication and Key Management (AAnF) in the communication network for a non-application-specific anchor security key (Kakma) for a particular user. The request may include a first representation of a first identifier (KakmaID) associated with the non-application-specific anchor security key (Kakma), and a second identifier associated with the user's network subscription. These example methods may also include: sending a response to the AAnF including the requested non-application-specific anchor security key (Kakma).

[0047] In some embodiments, these example methods may include: creating a non-application-specific anchor security key (Kakma) and a first identifier (KakmaID) for a specific user; and sending a second representation of a fourth identifier (AUSFID) and at least the first identifier (KakmaID) associated with AUSF to a unified data management (UDM) entity in the communication network.

[0048] In some embodiments, the first and second representations may include a third identifier (B-ID) that binds a non-application-specific anchor security key (Kakma) to the AUSF that generated the Kakma. Specifically, the third identifier may include representations of the first and second identifiers, as well as information associated with the AUSF. In various embodiments, the information associated with the AUSF may include one or more of the following: AUSF group ID, AUSF ID, Subscription Permanent Identifier (SUPI) range, Fully Qualified Domain Name (FQDN), and IP address. In this embodiment, the response may also include a Subscription Permanent Identifier (SUPI) associated with a specific user.

[0049] In other embodiments, the first representation of the first and second identifiers may include both the first identifier (e.g., KakmaID) and the second identifier, while the second representation may include only the first identifier. In this embodiment, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Subscription Hidden Identifier (SUCI); Subscription Permanent Identifier (SUPI); or General Public Subscription Identifier (GPSI). In a variant, the first representation may include only the first identifier, but may include a representation of the second identifier.

[0050] Example embodiments also include other methods (e.g., procedures) performed by an Authentication Server Function (AUSF) in a communication network (e.g., 5GC). These example methods may include: creating a non-application-specific anchor security key (Kakma) for a particular user, wherein the non-application-specific anchor security key is associated with a first identifier (KakmaID). These example methods may also include: selecting an anchor function for Application Authentication and Key Management (AAnF) associated with a particular user in the communication network based on a second identifier associated with the user's network subscription. In some embodiments, these example methods may further include: sending the following information to the identified AAnF: the non-application-specific anchor security key (Kakma) for the particular user, the first identifier (KakmaID), and the second identifier associated with the user's network subscription. In various embodiments, the second identifier may be a Subscription Persistent Identifier (SUPI) associated with the particular user.

[0051] Example embodiments also include methods (e.g., procedures) performed by a Unified Data Management (UDM) entity in a communication network (e.g., 5GC). These example methods may include: receiving a fourth identifier (AUSFID) associated with the AUSF and a first identifier (KakmaID) associated with a non-application-specific anchor security key (Kakma) for a specific user from an Authentication Server Function (AUSF) in the communication network. These example methods may also include: receiving a request for the fourth identifier from an Anchor Function (AAnF) for application authentication and key management in the communication network. These example methods may also include: sending a response including the fourth identifier to the AAnF.

[0052] In some embodiments, the request may include a first identifier (KakmaID), and the response may include a second identifier associated with a network subscription associated with a specific user. In some embodiments of these embodiments, the first identifier may include a representation of the second identifier. In other embodiments of these embodiments, the request may include another second identifier associated with a network subscription associated with a specific user. In such embodiments, these example methods may also include determining the second identifier based on the other second identifier. For example, the second identifier may be a Subscription Permanent Identifier (SUPI), and the other second identifier may be an identifier different from the SUPI (e.g., SUCI, GPSI).

[0053] In various embodiments, an AUSF may include multiple AUSF instances, each corresponding to a range of identifiers (e.g., RID, SUPI, etc.) associated with a network subscription. In such embodiments, these example methods may further include selecting a specific AUSF instance based on a second identifier. In such embodiments, a fourth identifier may correspond to the selected AUSF instance.

[0054] Example embodiments also include key management servers (e.g., AAnF), application functions, authentication server functions (AUSF), and unified data management (UDM) entities in a communication network (e.g., 5GC), which are configured (e.g., using processing circuitry) to perform operations corresponding to any of the example methods described herein.

[0055] Example embodiments also include a non-transitory computer-readable medium storing computer-executable instructions configured to perform operations corresponding to any of the example methods described herein when executed by processing circuitry associated with such a key management server, application function, AUSF, and UDM entity.

[0056] These and other objects, features, and advantages of the embodiments of this disclosure will become apparent after reading the following detailed description in conjunction with the accompanying drawings. Attached Figure Description

[0057] Figure 1 This is a high-level block diagram of an example architecture for an Evolved UTRAN (E-UTRAN) and Evolved Packet Core (EPC) network, as standardized by 3GPP for Long Term Evolution (LTE).

[0058] Figures 2 to 3 Two different high-level views of the 5G network architecture are shown.

[0059] Figure 4 An example non-roaming 5G reference architecture with service-based interfaces and various network functions (NFs) in the core network is shown, as further described in 3GPP TS 23.501 (v16.1.0).

[0060] Figure 5 This is a block diagram illustrating the key hierarchy of the example application's Authentication and Key Management (AKMA).

[0061] Figure 6 This is a flowchart illustrating an example process for establishing a secure application session between a user equipment (UE) and an application function (AF).

[0062] Figure 7 An example generic boot architecture (GBA) for application security authentication and key protocol (AKA) is shown.

[0063] Figure 8 This is a flowchart illustrating an example process for delivering UE parameter updates (UPUs) from a Unified Data Management (UDM) entity in the 5GC.

[0064] Figures 9 to 13 These are flowcharts illustrating various example processes involving the selection of the Authentication Server Function (AUSF) during application session establishment, according to various example embodiments of this disclosure.

[0065] Figures 14 to 15 Various example methods (e.g., processes) performed by an authentication and key management server (e.g., AAnF) in a communication network (e.g., 5GC) according to various example embodiments of the present disclosure are shown.

[0066] Figure 16 Example methods (e.g., processes) performed by application functions (AFs) in a communication network (e.g., 5GC) according to various example embodiments of this disclosure are shown.

[0067] Figures 17 to 18Various example methods (e.g., processes) performed by the Authentication Server Function (AUSF) in a communication network (e.g., 5GC) according to various example embodiments of the present disclosure are shown.

[0068] Figure 19 Example methods (e.g., procedures) performed by a unified data management (UDM) entity in a communication network (e.g., 5GC) according to various example embodiments of the present disclosure are shown.

[0069] Figure 20 Example embodiments of wireless networks according to various exemplary embodiments of this disclosure are shown.

[0070] Figure 21 Example embodiments of a UE according to various example embodiments of this disclosure are shown.

[0071] Figure 22 This is a block diagram illustrating example virtualization environments that can be used to implement the various embodiments described herein.

[0072] Figures 23 to 24 These are block diagrams of various example communication systems and / or networks according to various example embodiments of this disclosure.

[0073] Figures 25 to 28 This is a flowchart of an example method and / or process for sending and / or receiving user data according to various example embodiments of this disclosure. Detailed Implementation

[0074] Some embodiments of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided merely as examples to convey the scope of the subject matter to those skilled in the art.

[0075] Generally, all terms used herein will be interpreted according to their common meaning in the relevant art, unless a different meaning is explicitly given and / or implied in the context of their use. Unless otherwise expressly stated, all references to elements, devices, components, methods, steps, etc., will be openly interpreted as referring to at least one instance of an element, device, component, method, step, etc. The steps of any method and / or process disclosed herein are not necessarily to be performed in the exact order disclosed, unless a step is explicitly described as occurring after or before another step and / or it is implied that a step must occur after or before another step. Any feature of any embodiment disclosed herein may be applied to any other embodiment, where appropriate. Similarly, any advantage of any embodiment may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the disclosed embodiments will be apparent from the following description.

[0076] In addition, the terms used throughout this article are given below:

[0077] • Radio node: As used in this document, “radio node” can be a “radio access node” or a “wireless device”.

[0078] • Radio Access Node: As used herein, a “radio access node” (or equivalently, a “radio network node,” “radio access network node,” or “RAN node”) can be any node in the radio access network (RAN) of a cellular communication network used for wirelessly transmitting and / or receiving signals. Some examples of radio access nodes include, but are not limited to, base stations (e.g., NR base stations (gNB) in 3GPP fifth-generation (5G) new radio (NR) networks or enhanced or evolved Node B (eNB) in 3GPP LTE networks), base station distributed components (e.g., CU and DU), high-power or macro base stations, low-power base stations (e.g., micro base stations, pico base stations, femto base stations, or femto base stations), integrated access backhaul (IAB) nodes, transmission points, remote radio units (RRU or RRH), and relay nodes.

[0079] • Core Network Node: As used in this document, a “core network node” is any type of node in the core network. Some examples of core network nodes include, for example, Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (P-GW), Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Service Capability Exposure Function (SCEF), etc.

[0080] • Wireless Device: As used herein, a “wireless device” (or “WD” for short) is any type of device that can access a cellular communication network (i.e., is served by a cellular communication network) by wirelessly communicating with network nodes and / or other wireless devices. Wireless communication may involve sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information through the air. Unless otherwise stated, the term “wireless device” is used interchangeably with “user equipment” (or “UE” for short) herein. Some examples of wireless devices include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop-mounted devices (LMEs), smart devices, wireless client terminal equipment (CPEs), mobile type communication (MTC) devices, Internet of Things (IoT) devices, in-vehicle wireless terminal equipment, etc.

[0081] • Network Node: As used herein, a “network node” is any node that is part of a radio access network (e.g., a radio access node or equivalent term discussed above) or core network (e.g., a core network node discussed above) of a cellular communication network. Functionally, a network node is a device that is capable of, configured, positioned, and / or operable to communicate directly or indirectly with wireless devices and / or with other network nodes or devices in the cellular communication network to enable and / or provide wireless access to wireless devices and / or perform other functions (e.g., management) in the cellular communication network.

[0082] Note that the descriptions presented herein focus on 3GPP cellular communication systems; therefore, 3GPP terminology or similar terms are frequently used. However, the concepts disclosed herein are not limited to 3GPP systems. Furthermore, although the term "cell" is used herein, it should be understood that (particularly for 5G NR) a beam can be used instead of a cell; therefore, the concepts described herein apply equally to cells and beams.

[0083] In this disclosure, the term "service" is generally used to refer to a set of data associated with one or more applications, which will be transmitted over a network with certain specific delivery requirements that need to be met for the applications to succeed. In this disclosure, the term "component" is generally used to refer to any component required for the delivery of a service. Examples of components include RANs (e.g., E-UTRAN, NG-RAN, or portions thereof, such as eNBs, gNBs, base stations (BSs), etc.), CNs (e.g., EPCs, 5GCs, or portions thereof, including all types of links between RAN and CN entities), and cloud infrastructure with associated resources such as computing and storage. Typically, each component may have a "manager," a term generally used to refer to an entity (e.g., a RAN manager) that can collect historical information about resource utilization and provide information about the current and predicted future availability of resources associated with that component.

[0084] As briefly mentioned above, in the Rel-16 AKMA architecture, there may be various challenges, problems, and / or difficulties related to the synchronization of key material generated by AUSF for users and key material used by AAnF to generate application-specific keys for user application sessions. These challenges, problems, and / or difficulties can prevent (e.g., on the UE) the establishment of secure communication between user applications and corresponding application functions (e.g., servers). This is discussed in more detail below.

[0085] Typically, AKMA reuses the results of the 5G master authentication process (also known as "implicit bootstrapping") used to authenticate the UE during network registration. In this process, AUSF is responsible for the generation and storage of key materials. Specifically, the key hierarchy in AKMA includes the following, which... Figure 5 The middle part is further shown:

[0086] • Kausf: The root key, the output of the master authentication process, and stored in the UE (i.e., the mobile device ME portion) and AUSF. Furthermore, the AUSF can report the results and the specific AUSF instance that generated the Kausf as the output of the master authentication result in the UDM, as defined in TS33.501.

[0087] • Kakma: An anchor key derived from Kausf by ME and AUSF and generated by AAnF for further AKMA key material. The key identifier KakmaID identifies the Kakma.

[0088] ·Kaf: From K by ME and AAnF AKMA Export the application key and use it by the UE and the application to securely exchange application data.

[0089] Figure 6This is a flowchart illustrating an example procedure for establishing a secure application session between the UE and the AF based on the key hierarchy listed above. Initially, the UE and AUSF perform master authentication and establish a Kakma key, which is stored in both the UE and AUSF. Subsequently, the UE sends an application session establishment request to the AF, including the KakmaID. The AF then sends the received KakmaID along with its AF identifier to the AAnF, which responds with a Kakma corresponding to the provided KakmaID. The AAnF derives the Kaf from the Kakma and provides the Kaf along with its expiration time to the AF. The AF can then use the received Kaf to establish a secure application session with the UE.

[0090] As briefly mentioned above, the General Bootstrap Architecture (GBA) was introduced in 3GPP Rel-15 (e.g., 3GPP TS 33.220v15.4.0) to bootstrap the Authentication and Key Protocol (AKA) for Application Security. In other words, the GBA enables AFs in the network and the establishment of shared keys on the user side. Figure 7 An example GBA for AKA is shown according to the 3GPP specification.

[0091] In GBA, mutual authentication is performed between the UE and the BSF, where boot key material is also exported between the UE and the BSF. The BSF also generates a B-TID (Boot Transaction Identifier) ​​for each boot transaction that exports GBA key material. The booted GBA key material is then used by the UE for secure access to Network Application Functions (NAF).

[0092] When the UE initiates communication with the AF, it includes the B-TID in the message. The AF then uses the B-TID as input to request an application-specific key from the BSF. The BSF locates the GBA key material corresponding to the B-TID, derives the application-specific key, and provides it to the AF. Secure communication between the UE and the AF is then established based on the application-specific key.

[0093] To enable the NF to discover and select appropriate instances of AUSF or UDM to handle services, 3GPP TS23.501 defines input parameters that can be used (e.g., via NRF) to discover AUSF or UDM. The following is an excerpt from 3GPP TS23.501. The following abbreviations for UE-related identifiers are used in the excerpt:

[0094] ·Sign Permanent Identifier (SUPI)

[0095] • Subscribed Hidden Identifier (SUCI), and

[0096] • General Public Contract Identifier (GPSI).

[0097] ***Beginning of an excerpt from 3GPP TS 23.501***

[0098] The AUSF selection functionality in the AUSF NF consumer or SCP should take one of the following factors into account when it is available:

[0099] 1. Home network identifiers (e.g., MNC and MCC) and routing indicators for SUCI / SUPI (for NF consumers in the service PLMN).

[0100] Note 1: During initial registration, the UE provides a routing indicator to the AMF as part of the SUCI as defined in TS 23.003

[19] . The AMF may provide the UE's routing indicator to other AMFs as described in TS 23.502 [3].

[0101] When the UE’s routing indicator is set to its default value as defined in TS 23.003

[19] , the AUSFNF consumer can select any AUSF instance within the home network for the UE.

[0102] 2. The AUSF group ID to which the UE's SUPI belongs.

[0103] Note 2: The AMF can infer the ASF group ID to which the UE's SUPI belongs based on the results of the ASF discovery process with the NRF. The AMF provides the ASF group ID to which the SUPI belongs to other AMFs, as described in TS 23.502 [3].

[0104] 3. SUPI; For example, AMF selects an AUSF instance based on the SUPI range to which the UE's SUPI belongs, or based on the result of the NRF discovery process using the UE's SUPI as input for AUSF discovery.

[0105] The UDM selection function in the NF consumer or SCP should consider one of the following factors:

[0106] 1. Home network identifiers (e.g., MNC and MCC) of SUCI / SUPI and routing indicators of the UE.

[0107] Note 1: During initial registration, the UE provides a routing indicator to the AMF as part of the SUCI as defined in TS 23.003

[19] . The AMF provides the UE's routing indicator to other NF consumers (UDMs) as described in TS 23.502 [3].

[0108] When the UE’s routing indicator is set to its default value as defined in TS 23.003

[19] , the UDM NF consumer can select any UDM instance within the home network of SUCI / SUPI.

[0109] 2. UE's SUPI UDM group ID.

[0110] Note 2: The AMF can infer the UDM group ID to which the UE's SUPI belongs based on the results of the UDM discovery process with the NRF. The AMF provides the UDM group ID to which the SUPI belongs to other UDM NF consumers, as described in 3GPP TS 23.502.

[0111] 3. SUPI— The UDM NF consumer selects a UDM instance based on the SUPI range to which the UE's SUPI belongs, or based on the result of the NRF discovery process using the UE's SUPI as input for UDM discovery.

[0112] 4. GPSI or External Group ID — UDM NF consumers (e.g., NEF) that do not rely on SUPI / SUCI-based management network signaling select a UDM instance based on the range of GPSI or external group ID to which the UE's GPSI or external group ID belongs, or based on the result of the NRF discovery process using the UE's GPSI or external group ID as input for UDM discovery.

[0113] ***End of excerpt from 3GPP TS 23.501***

[0114] In addition, 3GPP TS 23.502 defines the process of delivering UE parameter update data from UDM to UE via Non-Access Stratum (NAS) signaling after UE has successfully registered with 5GC. Figure 8 This is a flowchart illustrating an example procedure for delivering UE parameter updates (UPUs) from the UDM in the 5GC. The UDM update data delivered to the UE by the UDM can contain any of the following:

[0115] • One or more UE parameters, including:

[0116] The updated default configuration of NSSAI (the final consumer of this parameter is ME).

[0117] Updated routing indicator data (the final consumer of this parameter is USIM).

[0118] • "Request UE confirmation" instruction.

[0119] • "Request re-registration" instruction.

[0120] Furthermore, a similar function called “Roaming Security Mechanism Guidance” is defined in 3GPP TS 33.501 to support the delivery of guidance information lists from the UE’s HPLMN to the UE.

[0121] Return to Figure 5 As shown in the key hierarchy, 3GPP TS 33.501 defines the generation and storage of Kausf in both the AUSF and UE after each main authentication process. However, 3GPP TS 33.501 does not specify when the AUSF and / or UE delete or overwrite the Kausf, which is the root key implicitly agreed upon by the UE and AUSF to derive the Kakma. Therefore, over time, different AUSF instances may be used for user authentication. Specifically, different AUSF instances may generate and store Kausf for the corresponding authentication, but only one AUSF instance holds the latest Kausf for a given UE (which also holds the latest Kausf). This can lead to various puzzles, problems, and / or difficulties.

[0122] As an example, Kakma and KakmaID are generated based on Kausf in the UE and AUSF respectively. Therefore, during primary authentication, the UE does not obtain the identifier of the specific AUSF that generated and stored the Kakma (e.g., AUSF ID), and thus, the KakmaID generated by the UE cannot contain any references to the AUSF ID. Therefore, even when the UE attempts to establish a secure application session with the AF, the UE provides the KakmaID (e.g., in...). Figure 6 In the AF (or more specifically, the AAnF associated with the AF), the AF is unaware of the appropriate AUSF instance that generates and holds the Kakma associated with the received KakmaID. Note that even if the AAnF is co-located with the AUSF, it remains unaware of how the AF and / or an intermediate NEF deployed between the AF and the AAnF can discover and select the integrated AUSF / AAnF based on the KakmaID received from the UE.

[0123] As another example, the Kakma is generated in the AUSF and obtained by the AAnF to derive the Kaf. During different main authentication processes, multiple Kausfs may be generated for the UE by different AUSF instances. Furthermore, each of these AUSF instances can generate and store different Kakma / KakmaIDs for the UE based on the corresponding Kausf. Without any specified deletion / removal procedures, different Kakma / KakmaIDs can be stored in different AUSF instances, with only one corresponding to the Kakma / KakmaID stored at the UE.

[0124] Typically, an agreement needs to be reached between the UE and the network to use the latest Kakma. However, in some exceptional cases, the key materials stored in the UE and the network may be out of sync. For example, a new version of Kausf and Kakma may be generated and stored in the UE, but this new version of Kausf and Kakma has not yet been generated and stored in the network. In this case, the KakmaID received from the UE during AKMA session establishment may refer to a Kakma that does not yet exist on the network side.

[0125] The exemplary embodiments of this disclosure address these and other challenges, problems, and / or difficulties by providing techniques to facilitate the selection of an AUSF instance of the Kakma referenced by the KakmaID provided by the UE during the initiation of an AKMA with the AF.

[0126] Some embodiments of this disclosure can utilize UDM discovery and selection techniques used in primary authentication based on identifiers associated with the network subscription linked to the UE. For example, the identifier can be any relevant identifier available in the UE, including HPLMN ID plus UE routing indicator (R-ID), SUCI, SUPI, or GPSI. The UE can provide the identifier to the AF in a request to establish an application session, either as part of or separate from the KakmaID. Once a suitable UDM for managing UE requests is located based on the identifier, the AAnF (or NEF / AF) obtains the identifier of the AUSF storing the latest Kakma from the UDM via a new service operation (e.g., Nudm_UEAuthentication_ResultStatus). The AAnF can then obtain the latest Kakma from the identified AUSF and generate a Kaf based on the obtained Kakma.

[0127] Other embodiments of this disclosure may utilize existing UE Parameter Update (UPU) techniques to deliver explicit binding information between Kakma and the AUSF ID holding the Kausf / Kakma currently used by the UE. Even if the AKMA key material is generated implicitly and independently on the UE and network side, the UE and network can have an explicit binding process to agree on (Kausf, Kakma) version synchronization and references to the AUSF ID.

[0128] More specifically, the UE can obtain binding information from the UDM and provide it to the AF in the request used to establish an application session. The AAnF can then use the binding information to locate the associated AUSF ID (i.e., the AUSF that stores the latest Kakma for the UE) in a manner similar to the BSF discovery process used in the GBA. Note that if the AAnF is co-located with the AUSF, the binding information is also associated with the AAnF, similar to the binding of BSFs in the GBA.

[0129] Other embodiments of this disclosure may utilize the registration process in the NRF to register an AAnF based on a range of Routing Identifiers (RIDs), which the AAnF can later discover via the NRF. When the AAnF creates a Kakma for a specific UE corresponding to the registered RID, the AAnF can push the Kakma / KakmaID to the previously discovered AAnF. In this way, the AAnF already possesses the Kakma required to generate a Kaf when requested by the AF.

[0130] Figures 9 to 11 These are flowcharts illustrating various example procedures for selecting the Authentication Support Function (AUSF) during application session establishment, according to various example embodiments of this disclosure. In particular, Figures 9 to 11 The illustrated embodiment utilizes UDM discovery and selection techniques used in primary authentication, based on an identifier associated with the network subscription linked to the UE. Specifically, Figures 9 to 11 The process of adding UE routing indicator, SUCI / SUPI, and GPSI based on HPLMN ID is shown respectively.

[0131] Figures 9 to 11 Each diagram in the diagram relates to various messages and operations associated with one or more instances of UE 910, AMF 920, AUSF 930 (e.g., 930a, 930b, etc.), UDM / UDR 940, AAnF 950 (e.g., 950a, 950b, etc.), and AAPF (or AF) 960. For brevity, these entities will be referred to without reference numerals in the following description. Additionally, although... Figures 9 to 11 The operations are shown with numbers, but these numbers are used to facilitate the description of the process, not to require or imply a specific order of operations. In other words, Figures 9 to 11 The operations shown may be performed in a different order than those shown, and may be combined and / or divided into operations different from those shown.

[0132] exist Figure 9In Operation 0, the UE performs primary authentication with the network. Kakma and KakmaID are generated and stored in both the UE and AUSF. AUSF invokes the existing service operation Nudm_UEAuthentication_ResultConfirmation to notify the UDM of the authentication result, which includes SUPI, AUSF ID, service network name, authentication type, and timestamp information. Additionally, AUSF provides the KakmaID generated during primary authentication. The UDM then stores all the information together.

[0133] In Operation 1, the UE initiates the application session establishment procedure with the AF. The UE includes its KakmaID, Home Network Identifier (HPLMN ID, such as Mobile Network Code / Mobile Country Code MNC / MCC), and UE RID. The HPLMN ID and RID can be included within the KakmaID or can be included as separate identifiers in the message. In Operations 2-3, the AF selects an AAnF based on the HPLMID and sends a request to the selected AAnF for the Kaf to be used in the application session with the UE. The request includes the AF ID, KakmaID, and HPLMMN ID + RID.

[0134] Operation 4 involves the AAnF's discovery and selection of an AUSF. In operation 4a, the AAnF discovers and selects a UDM based on the RID received from the AF. In operation 4b, the AAnF invokes a new service operation, Nudm_UEAuthentication_ResultStatus, to send a request to the selected UDM, including the KakmaID. Based on the information stored during operation 0, the UDM uses the KakmaID to discover and select an AUSF instance. In operation 4c, the UDM returns the SUPI and AUSF ID to the requesting AAnF. In operation 4d, the AAnF discovers and selects an AUSF based on the AUSF ID received from the UDM.

[0135] In operation 5, AAnF invokes the service operation Nausf_AKMAKey_Get to send a request for Kakma to the selected AUSF, which includes SUPI and KakmaID. In operation 6, the AUSF returns the Kakma to AAnF. In operations 7-8, AAnF generates a Kaf based on the Kakma received from the AUSF and provides the Kaf to the AF. In operation 9, the AF establishes a secure application session with the UE based on the Kaf received in operation 8.

[0136] Figure 10 It shows the relationship with Figure 9Similar operations, but based on different identifiers, namely SUCI or SUPI, instead of HPLMNID+RID. Operation 0 and Figure 9 Operation 0 is the same as in Operation 1. In Operation 1, the UE initiates the application session establishment procedure with the AF. The UE includes KakmaID and SUCI or SUPI. SUCI or SUPI can be included within KakmaID, or it can be included as a separate identifier in the message. In Operations 2-3, the AF selects an AAnF based on the HPLM ID associated with SUCI or SUPI, and sends a request to the selected AAnF for the Kaf to be used in the application session with the UE. The request includes the AF ID, KakmaID, and SUCI or SUPI.

[0137] Operation 4 involves the AAnF's discovery and selection of an AUSF. In operation 4a, the AAnF discovers and selects a UDM based on the SUCI or SUPI received from the AF. In operation 4b, the AAnF invokes a new service operation, Nudm_UEAuthentication_ResultStatus, to send a request to the selected UDM, including the KakmaID and either SUCI or SUPI. In operation 4c, based on the information stored during operation 0, the UDM selects an AUSF instance using either SUCI or SUPI. The UDM verifies whether the KakmaID received from the AAnF is included in the stored authentication context for the UE. In operation 4d, the UDM returns the SUPI and AUSF ID to the requesting AAnF. In operation 4e, the AAnF discovers and selects an AUSF based on the AUSF ID received from the UDM. Operations 5-9 are related to... Figure 9 Operations 5-9 are the same.

[0138] Figure 11 It shows the relationship with Figures 9 to 10 Similar operations, but based on a different identifier, namely GPSI, instead of HPLMNID+RID, SUCI, or SUPI. Operation 0 and Figures 9 to 10 The operation shown is the same as operation 0. In operation 1, the UE initiates an application session establishment procedure with the AF. The UE includes KakmaID and GPSI. GPSI can be included within KakmaID or can be included as a separate identifier in the message. In operations 2-3, the AF selects AAnF based on the HPLM ID associated with GPSI and sends a request to the selected AAnF for the Kaf to be used in the application session with the UE. The request includes the AF ID, KakmaID, and GPSI.

[0139] Operation 4 involves AAnF's discovery and selection of an AUSF. In operation 4a, AAnF discovers and selects a UDM based on the GPSI received from the AF. In operation 4b, AAnF invokes a new service operation, Nudm_UEAuthentication_ResultStatus, to send a request to the selected UDM, which includes the KakmaID and GPSI. In operation 4c, the UDM converts the received GPSI into the corresponding SUPI and selects an AUSF instance using the SUPI based on the information stored during operation 0. The UDM verifies whether the KakmaID received from AAnF is included in the stored authentication context for the UE. In operation 4d, the UDM returns the SUPI (corresponding to the GPSI) and AUSF ID to the requesting AAnF. The provided SUPI can be used by AAnF for subsequent key requests for the same UE as needed or desired. In operation 4e, AAnF discovers and selects an AUSF based on the AUSF ID received from the UDM. Operations 5-9 are related to... Figures 9 to 10 Operations 5-9 are the same.

[0140] Figure 12 This is a flowchart of another example process involving the selection of the Authentication Support Function (AUSF) during application session establishment, according to various example embodiments of this disclosure. In particular, Figure 12 The illustrated embodiment utilizes existing UE parameter update (UPU) technology to provide explicit binding information between Kakma and the AUSF ID of the Kausf / Kakma currently being used by the UE. Figure 12 The entities shown are used with Figures 9 to 11 For the sake of brevity, the same reference marks are omitted in the following description. However, Figure 12 The arrangement shown includes the NRF 970, not the AMF 920.

[0141] although Figure 12 The operations are shown with numbers, but these numbers are used for ease of process description, not to require or imply a specific order of operations. In other words, Figure 12 The operations shown can be performed in a different order than those shown, and can be combined and / or divided into operations different from those shown.

[0142] In Operation 0a, AUSF registers its specific AKMA binding information with the NRF, for example, via the Nnrf_NFManagement_NFRegister service. The AKMA binding information may include the AUSF group ID, SUPI range, AUSF fully qualified domain name (FQDN), AUSF IP address, and / or AUSF ID. In some embodiments, the AKMA binding information registered in Operation 0a may be a hash of the parameters mentioned above, which can enhance AUSF privacy.

[0143] In Operation 0b, the UE performs primary authentication with the network. Kakma and KakmaID are generated and stored in both the UE and the AUSF. The AUSF also generates a binding identifier B-TID, which may include the KakmaID, AKMA binding information (e.g., from Operation 0a), and one or more UE identifiers (e.g., GPSI). The AUSF invokes the existing service operation Nudm_UEAuthentication_ResultConfirmation to notify the UDM of the authentication result, which includes SUPI, AUSF ID, service network name, authentication type, and timestamp information. Additionally, the AUSF provides the B-TID. The UDM then stores all the information together.

[0144] In Operation 0c, the AUSF requests the UDM (or is triggered by the UDM itself) to update the B-TID for a specific UE via a UDM control plane procedure or similar procedure through UE parameter updates. In Operation 1, the UE initiates an application session establishment procedure with the AF. The UE includes the B-TID received in Operation 0c. In Operations 2-3, the AF selects an AAnF based on the HPLM ID associated with (e.g., the GPSI included in the B-TID) and sends a request to the selected AAnF for the Kaf to be used in the application session with the UE. The request includes the B-TID received in Operation 1. In Operation 4, the AAnF selects an AUSF via NRF discovery based on the B-TID received from the AF. For example, the AAnF uses the AKMA binding information and / or UE information (e.g., GPSI) within the B-TID* as input for the NRF discovery service.

[0145] In operation 5, AAnF invokes the service operation Nausf_AKMAKey_Get to send a request for Kakma to the selected AUSF, which includes the B-TID. In operation 6, the AUSF returns the Kakma to AAnF, optionally along with the SUPI. In other embodiments, AAnF invokes an existing service from the UDM (e.g., Nudm_SDM_GET (Identifier Translation)) to map the UE information within the B-TID* to the corresponding SUPI. AAnF then includes the SUPI in the service operation Nausf_AKMAKey_Get sent in operation 5.

[0146] In operations 7-8, AAnF generates Kaf based on the Kakma received from AUSF and provides Kaf to AF. In operation 9, AF establishes a secure application session with UE based on the Kaf received in operation 8.

[0147] exist Figure 12 In a variant of the process shown, during operation 0c, the B-TID* can be embedded in existing NAS signaling and provided to the UE during the primary authentication and / or UE registration process. Other operations of this variant can be combined with... Figure 12 The operations shown are essentially the same.

[0148] Figure 13 This is a flowchart of another example process involving the selection of the Authentication Support Function (AUSF) during application session establishment, according to various example embodiments of this disclosure. In particular, Figure 3 The illustrated embodiment utilizes the NRF registration process to register an AAnF based on the range of the Routing Identifier (RID), which the AAnF can later discover via the NRF. Figure 13 The entities shown are used with Figures 9 to 11 The same reference numerals are omitted in the following description for the sake of brevity. Although Figure 13 The operations are shown with numbers, but these numbers are used for ease of process description, not to require or imply a specific order of operations. In other words, Figure 13 The operations shown can be performed in a different order than those shown, and can be combined and / or divided into operations different from those shown.

[0149] As Figure 13 As a prerequisite for the illustrated embodiments, AAnF can be deployed within an HPLMN to use group IDs (GIDs), RIDs, and / or SUPI range partitions similar to those used by AUSF and / or UDM. In some embodiments, multiple AAnF instances can be deployed for each range partition. Figure 12 Similarly, AAnF can send data to NRF ( Figure 13(Not shown in the image) Register the corresponding range partition.

[0150] Operation 0 and Figures 9 to 11 Operation 0 is similar to the one shown. In Operation 1, after primary authentication and Kakma generation, AUSF discovers one or more AAnF instances for the UE via NRF based on the UE's SUPI or RID. Note that multiple AAnF instances can exist for the UE's RID / GID. In Operation 2, AUSF proactively pushes the Kakma, KakmaID, and SUPI for the UE to the AAnF. If multiple AAnF instances are deployed for the UE's RID / GID, AUSF provides the Kakma to all such AAnF instances. Operation 3 is similar to... Figure 9 The operation is similar to step 3.

[0151] In Operation 4, the AF selects one or more AAnF instances based on the HPLMN ID and RID received in Operation 3. In Operation 5, the AF invokes the service operation Nausf_AKMAKey_Get to send a request for the Kakma to the selected AAnF, including the KakmaID and RID. In Operation 6, upon receiving the request, the AAnF matches the KakmaID with the information received in Operation 2 to determine if it has the latest Kakma. Operations 7-9 are related to... Figures 9 to 12 Operations 7-9 are the same.

[0152] The embodiments described above can be described below. Figures 14 to 19 The example methods (e.g., procedures) shown are used to further illustrate this. For example, features of the various embodiments discussed above are included. Figures 14 to 19 In the various operations of the example method shown.

[0153] More specifically, Figure 14 Example methods (e.g., procedures) performed by a key management server (e.g., AAnF) in a communication network (e.g., 5GC) according to various example embodiments of this disclosure are illustrated. The key management server may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere herein. Although the example methods are in... Figure 14 The boxes are shown in a specific order, but the operations corresponding to these boxes can be performed in a different order than shown, and can be combined and / or divided into boxes and / or operations with different functions than those shown. Furthermore, Figure 14 The example methods shown can be used in conjunction with other example methods and / or procedures disclosed herein (e.g., Figures 9 to 12 , Figures 16 to 17 , Figure 19They are complementary so that they can be used together to provide benefits, advantages, and / or solutions to the problems described herein. Optional boxes and / or operations are indicated by dashed lines.

[0154] Example methods may include the operation of box 1410, wherein a key management server may receive a request from an application function for a security key (Kaf) specific to an application session for a particular user. This request may include a representation of the following information associated with the particular user: a first identifier (KakmaID) of a non-application-specific anchor security key (Kakma), and a second identifier associated with the network subscription. Example methods may also include the operation of box 1420, wherein the key management server may determine the Authentication Server Function (AUSF) for generating the non-application-specific anchor security key (Kakma) based on the representation.

[0155] In some embodiments, the example method may further include the operation at block 1430, wherein the key management server can obtain a non-application-specific anchor security key (Kakma) from the determined AUSF. In some embodiments, the example method may further include the operation at block 1440, wherein the key management server can generate an application session-specific security key (Kaf) based on the non-application-specific anchor security key (Kakma).

[0156] Figure 14 Some embodiments of the method shown may correspond to Figure 12 The example process is shown. In this embodiment, the representation (e.g., received in block 1410) may include a third identifier (B-ID) binding a non-application-specific anchor security key (Kakma) to the AUSF that generated the Kakma. Specifically, the third identifier may include representations of the first and second identifiers, as well as information associated with the AUSF. In various embodiments, the information associated with the AUSF may include one or more of the following: AUSF group ID, AUSF ID, Subscribed Permanent Identifier (SUPI) range, Fully Qualified Domain Name (FQDN), and IP address.

[0157] In this embodiment, the determination operation of block 1420 may include the operation of sub-block 1421, wherein the key management server may discover the identifier of the AUSF via a Network Store Function (NRF) based on information associated with the AUSF. Furthermore, in this embodiment, the acquisition operation of block 1430 may include the operations of sub-blocks 1431-1432. In sub-block 1431, the key management server may send a request including a third identifier (e.g., B-TID) to the determined AUSF (e.g., from block 1420). In sub-block 1432, the key management server may receive a response from the determined AUSF including a non-application-specific anchor security key (Kakma) and a second identifier.

[0158] Figure 14 Other embodiments of the method shown may correspond to Figures 9 to 11 The example process is shown. In this embodiment, the representation of the first and second identifiers (e.g., received in block 1410) may include a first identifier (e.g., KakmaID) and a second identifier. For example, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Subscription Hidden Identifier (SUCI); Subscription Permanent Identifier (SUPI); or General Public Subscription Identifier (GPSI). In a variant, the representation may include only the first identifier (e.g., KakmaID), which includes a representation of the second identifier.

[0159] In this embodiment, the determination operation of block 1420 may include the operations of sub-blocks 1422-1424. In sub-block 1422, the key management server may select a Unified Data Management (UDM) entity in the communication network based on a second identifier. In sub-block 1423, the key management server may send a first request to the UDM entity for a fourth identifier associated with AUSF. In sub-block 1424, the key management server may receive a first response from the UDM entity including the fourth identifier. In some embodiments, the first response may also include another second identifier related to the network subscription associated with a specific user. For example, the other second identifier may be SUPI, and the second identifier may be an identifier different from SUPI (e.g., GPSI, SUCI, HPLMN+RID).

[0160] In this embodiment, the acquisition operation of block 1430 may include the operations of sub-blocks 1433-1434. In sub-block 1433, the key management server may send a second request to the AUSF associated with the fourth identifier, including a second identifier or another second identifier associated with a network subscription associated with a specific user. In sub-block 1434, the key management server may receive a second response from the AUSF including a non-application-specific anchor security key (Kakma). In some embodiments, the second request or the second response may also include a second identifier. For example, if the second request includes another second identifier (e.g., SUPI), the second response may include a second identifier (e.g., an identifier different from SUPI).

[0161] In some embodiments, the example method may further include the operation of block 1440, wherein the key management server may send an application session-specific security key (Kaf) to the application function.

[0162] in addition, Figure 15 Example methods (e.g., procedures) performed by a key management server (e.g., AAnF) in a communication network (e.g., 5GC) according to various example embodiments of this disclosure are illustrated. The key management server may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere herein. Although the example methods are in... Figure 15 The boxes are shown in a specific order, but the operations corresponding to these boxes can be performed in a different order than shown, and can be combined and / or divided into boxes and / or operations with different functions than those shown. Furthermore, Figure 15 The example methods shown can be used in conjunction with other example methods disclosed herein (e.g., Figure 13 and Figure 18 They are complementary so that they can be used together to provide benefits, advantages, and / or solutions to the problems described herein. Optional boxes and / or operations are indicated by dashed lines.

[0163] Example methods may include the operation of box 1520, wherein the key management server may receive the following information associated with a specific user from the Authentication Server Function (AUSF): a non-application-specific anchor security key (Kakma); a first identifier of the non-application-specific anchor security key (KakmaID); and a second identifier associated with the network subscription. In some embodiments, the second identifier may be a subscription persistent identifier (SUPI).

[0164] The example method may also include the operation at box 1530, wherein the key management server may receive a request from an application function for a security key (Kaf) specific to an application session for a particular user, wherein the request includes another identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user. The request may include another identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user. The example method may also include the operation at box 1550, wherein the key management server may generate an application session-specific security key (Kaf) based on a non-application-specific anchor security key (Kakma) based on a match between a first identifier and another identifier (e.g., a matching KakmaID).

[0165] In some embodiments, the key management server may include multiple Anchor Function (AAnF) instances for application authentication and key management, each AAnF instance corresponding to a range of User Equipment Routing Indicators (RIDs). In this embodiment, the request may also include a Routing Indicator (RID) associated with a specific user, and the example method may further include the operation at box 1540, wherein the key management server may select an AAnF instance based on a received RID (e.g., based on a match between a received RID and one of the ranges of RIDs). In this embodiment, the generation of an application session-specific security key (Kaf) (e.g., in box 1550) is performed by the selected AAnF instance.

[0166] In some embodiments, the key management server may be associated with one or more ranges of a User Equipment Routing Indicator (RID). As an example, the key management server may include multiple AAnF instances, each corresponding to a range of a User Equipment Routing Indicator (RID). In this embodiment, the example method may also include the operation at block 1510, wherein the key management server may register the association between the key management server and one or more ranges with a Network Store Function (NRF) in the communication network.

[0167] in addition, Figure 16 Example methods (e.g., procedures) performed by application functions in a communication network according to various example embodiments of this disclosure are illustrated. The application functions may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere herein. Although the example methods are... Figure 16 The boxes are shown in a specific order, but the operations corresponding to these boxes can be performed in a different order than shown, and can be combined and / or divided into boxes and / or operations with different functions than those shown. Furthermore, Figure 16 The example methods shown can be used in conjunction with other example methods disclosed herein (e.g., Figures 9 to 15 , Figures 17 to 19 They are complementary so that they can be used together to provide a variety of benefits, advantages, and / or solutions to the problems described herein. Optional boxes and / or operations are indicated by dashed lines.

[0168] The example method may include the operation of box 1610, wherein the application function may receive a first request from a user equipment for establishing an application session. The first request may include a representation of the following information associated with a specific user: a first identifier (KakmaID) of a non-application-specific anchor security key (Kakma), and a second identifier associated with a network subscription. The example method may also include the operation of box 1620, wherein the application function may send a second request for an application session-specific security key (Kaf) to an anchor function (AAnF) in the communication network used for application authentication and key management. The second request may include representations of the first and second identifiers.

[0169] The example method may also include the operation at box 1630, wherein the application function can receive an application session-specific security key (Kaf) from AAnF. In some embodiments, the example method may also include the operation at box 1640, wherein the application function can establish a secure application session with the user equipment based on the received security key (Kaf).

[0170] Figure 16 Some embodiments of the method shown may correspond to Figure 12 The example process is shown. In this embodiment, (e.g., received in block 1610 and transmitted in block 1620) represents a third identifier (B-ID) indicating a binding between a non-application-specific anchor security key (Kakma) and the AUSF that generated the Kakma. Specifically, the third identifier may include representations of the first and second identifiers, as well as information associated with the AUSF. In various embodiments, the information associated with the AUSF may include one or more of the following: AUSF group ID, AUSF ID, Subscribed Permanent Identifier (SUPI) range, Fully Qualified Domain Name (FQDN), and IP address.

[0171] Figure 16 Other embodiments of the method shown may correspond to Figures 9 to 11The example process is shown. In this embodiment, the representation of the first and second identifiers (e.g., received in block 1410) may include a first identifier (e.g., KakmaID) and a second identifier. For example, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Subscription Hidden Identifier (SUCI); Subscription Permanent Identifier (SUPI); or General Public Subscription Identifier (GPSI). In a variant, the representation may include only the first identifier (e.g., KakmaID), which includes a representation of the second identifier.

[0172] in addition, Figure 17 Example methods (e.g., procedures) performed by an Authentication Server Function (AUSF) in a communication network (e.g., 5GC) according to various example embodiments of this disclosure are illustrated. The AUSF may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere herein. Although the example methods are... Figure 17 The boxes are shown in a specific order, but the operations corresponding to these boxes can be performed in a different order than shown, and can be combined and / or divided into boxes and / or operations with different functions than those shown. Furthermore, Figure 17 The example methods shown can be used in conjunction with other example methods disclosed herein (e.g., Figures 9 to 12 , Figure 14 , Figure 16 , Figure 19 These are complementary, allowing them to be used synergistically to provide a variety of benefits, advantages, and / or solutions to the problems described herein. Optional boxes and / or operations are indicated by dashed lines.

[0173] The example method may include the operation of box 1730, wherein the AUSF may receive a request for a non-application-specific anchor security key (Kakma) for a specific user from the Anchor Function for Application Authentication and Key Management (AAnF) in the communication network. The request may include a first representation of: a first identifier (KakmaID) associated with the non-application-specific anchor security key (Kakma), and a second identifier associated with the specific user's network subscription. The example method may also include the operation of box 1740, wherein the AUSF may send a response to the AAnF including the requested non-application-specific anchor security key (Kakma).

[0174] In some embodiments, Figure 17The example method shown may include the operations in boxes 1710-1720. In box 1710, the AUSF may create a non-application-specific anchor security key (Kakma) and a first identifier (KakmaID) for a specific user. In box 1720, the AUSF may send a fourth identifier (AUSFID) associated with the AUSF and a second representation of at least the first identifier (KakmaID) to a Unified Data Management (UDM) entity in the communication network.

[0175] Figure 17 Some embodiments of the method shown may correspond to Figure 12 The example process is illustrated. In this embodiment, the first representation (e.g., received in box 1730) and the second representation (e.g., sent in box 1720) may include a third identifier (B-ID) binding a non-application-specific anchor security key (Kakma) to the AUSF that generated the Kakma. Specifically, the third identifier may include representations of the first and second identifiers, as well as information associated with the AUSF. In various embodiments, the information associated with the AUSF may include one or more of the following: AUSF group ID, AUSF ID, Subscription Permanent Identifier (SUPI) range, Fully Qualified Domain Name (FQDN), and IP address. In this embodiment, the response (e.g., sent in box 1740) may also include a Subscription Permanent Identifier (SUPI) associated with a specific user.

[0176] Figure 17 Other embodiments of the method shown may correspond to Figures 9 to 11 The example process is shown. In this embodiment, the first representation of the first and second identifiers (e.g., received in box 1730) may include both the first identifier (e.g., KakmaID) and the second identifier, while the second representation (e.g., transmitted in box 1720) may include only the first identifier. In this embodiment, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Subscription Hidden Identifier (SUCI); Subscription Permanent Identifier (SUPI); or General Public Subscription Identifier (GPSI). In a variant, the first representation (e.g., received in box 1730) may include only the first identifier (e.g., KakmaID), which may include a representation of the second identifier.

[0177] in addition, Figure 18 Another example method (e.g., process) performed by an Authentication Server Function (AUSF) in a communication network (e.g., 5GC) according to various example embodiments of this disclosure is illustrated. The AUSF may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere herein. Although the example method... Figure 18 The boxes are shown in a specific order, but the operations corresponding to these boxes can be performed in a different order than those shown, and can be combined and / or divided into boxes and / or operations with different functions than those shown. Furthermore, Figure 18 The example methods shown can be compared with other example methods disclosed in this document (e.g., Figure 13 and Figure 15 These are complementary, allowing them to be used synergistically to provide benefits, advantages, and / or solutions to the problems described herein. Optional boxes and / or operations are indicated by dashed lines.

[0178] The example method may include the operation at box 1810, whereby the AUSF can create a non-application-specific anchor security key (Kakma) for a specific user, wherein the non-application-specific anchor security key is associated with a first identifier (KakmaID). The example method may also include the operation at box 1820, whereby the AUSF can select an anchor function (AAnF) for application authentication and key management associated with the specific user in the communication network based on a second identifier associated with the specific user's network subscription. In some embodiments, the example method may further include the operation at box 1830, whereby the AUSF can send the following information to the identified AAnF: the non-application-specific anchor security key (Kakma) for the specific user, the first identifier (KakmaID), and the second identifier associated with the specific user's network subscription. In various embodiments, the second identifier may be a subscription persistent identifier (SUPI) associated with the specific user.

[0179] in addition, Figure 19 Example methods (e.g., procedures) performed by a Unified Data Management (UDM) entity in a communication network (e.g., 5GC) according to various example embodiments of this disclosure are illustrated. The UDM entity may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere herein. Although the example methods are... Figure 19 The boxes are shown in a specific order, but the operations corresponding to these boxes can be performed in a different order than shown, and can be combined and / or divided into boxes and / or operations with different functions than those shown. Furthermore, Figure 19 The example methods shown can be compared with other example methods disclosed in this document (e.g., Figures 9 to 11 , Figure 14 , Figures 16 to 17 They are complementary so that they can be used together to provide a variety of benefits, advantages, and / or solutions to the problems described herein. Optional boxes and / or operations are indicated by dashed lines.

[0180] The example method may include the operation of box 1910, wherein the UDM entity may receive a fourth identifier (AUSFID) associated with the AUSF and a first identifier (KakmaID) associated with a non-application-specific anchor security key (Kakma) for a specific user from an Authentication Server Function (AUSF) in the communication network. The example method may also include the operation of box 1920, wherein the UDM entity may receive a request for the fourth identifier from an Anchor Function (AAnF) for Application Authentication and Key Management in the communication network. The example method may also include the operation of box 1950, wherein the UDM entity may send a response including the fourth identifier to the AAnF.

[0181] In some embodiments, (e.g., received in box 1920) the request may include a first identifier (KakmaID), and (e.g., sent in box 1950) the response may include a second identifier associated with a network subscription specific to the user. In some embodiments of these embodiments, the first identifier may include a representation of the second identifier. Examples of such embodiments are shown in... Figure 9 The process is shown in the diagram.

[0182] In other embodiments of these embodiments, the request may include another second identifier related to the network subscription associated with a specific user. In this embodiment, the example method may also include the operation at block 1930, where the UDM entity may determine the second identifier based on the other second identifier. For example, the second identifier may be a Subscription Permanent Identifier (SUPI), and the other second identifier is an identifier different from the SUPI (e.g., SUCI, GPSI). Examples of this embodiment are provided in... Figures 10 to 11 The process is shown in the diagram.

[0183] In various embodiments, the AUSF (from which information is received, for example, in box 1910) may include multiple AUSF instances, each corresponding to a range of identifiers (e.g., RID, SUPI, etc.) associated with a network subscription. In this embodiment, the example method may also include the operation of box 1940, where the UDM entity may select a specific AUSF instance based on a second identifier (e.g., received in box 1920). In this embodiment, a fourth identifier (e.g., sent in box 1950) may correspond to the selected AUSF instance.

[0184] While the topics described herein can be implemented in any suitable type of system using any appropriate components, the embodiments disclosed herein are relative to wireless networks (such as...). Figure 20 The example wireless network shown is described. For simplicity, Figure 20The wireless network depicted only includes network 2006, network nodes 2060 and 2060b, and WD 2010, 2010b, and 2010c. In practice, the wireless network may also include any additional elements suitable for supporting communication between wireless devices or between a wireless device and another communication device (such as a landline telephone, service provider, or any other network node or terminal device). Among the components shown, network node 2060 and wireless device (WD) 2010 are shown in additional detail. The wireless network can provide communication and other types of services to one or more wireless devices to facilitate wireless device access to the wireless network and / or use of services provided by or via the wireless network.

[0185] Wireless networks may include or interface with any type of communications, telecommunications, data, cellular, and / or radio network or other similar system. In some embodiments, a wireless network may be configured to operate according to a specific standard or other type of predefined rules or procedures. Thus, specific embodiments of a wireless network may implement communication standards such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards such as the IEEE 802.11 standard; and / or any other suitable wireless communication standards such as WiMax, Bluetooth, Z-Wave, and / or ZigBee standards.

[0186] Network 2006 may include one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTN), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks that enable communication between devices.

[0187] Network node 2060 and WD 2010 include various components described in more detail below. These components work together to provide network node and / or wireless device functionality, such as providing wireless connectivity in a wireless network. In different embodiments, the wireless network may include any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components or systems that may facilitate or participate in communication of data and / or signals via wired or wireless connections.

[0188] Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points) and base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)). Base stations can be classified based on the coverage they provide (or, in other words, their transmit power levels) and can then be referred to as femtocells, picocells, microcells, or macrocells. A base station can be a relay node or a relay donor node that controls a relay. Network nodes can also include one or more (or all) portions of a distributed radio base station, such as centralized digital units and / or remote radio units (RRUs), sometimes referred to as remote radio heads (RRHs). Such remote radio units may or may not be integrated with an antenna as antenna-integrated radios. Portions of a distributed radio base station can also be referred to as nodes in a distributed antenna system (DAS).

[0189] Further examples of network nodes include multi-standard radio (MSR) equipment (such as an MSR BS), network controllers (such as a radio network controller (RNC) or base station controller (BSC)), base transceiver stations (BTS), transport points, transport nodes, multi-cell / multicast coordination entities (MCEs), core network nodes (e.g., MSC, MME), O&M nodes, OSS nodes, SON nodes, location nodes (e.g., E-SMLC), and / or MDTs. As another example, a network node can be a virtual network node, as described in more detail below. However, more generally, a network node can represent any suitable device (or group of devices) capable of, configured, deployed, and / or operable to enable and / or provide access to a wireless network to wireless devices or to provide some service to wireless devices already connected to the wireless network.

[0190] exist Figure 20 In the network node 2060, processing circuitry 2070, device-readable medium 2080, interface 2090, auxiliary equipment 2084, power supply 2086, power supply circuitry 2087, and antenna 2062 are included. Although in Figure 20 The network node 2060 shown in the example wireless network can represent a device including the illustrated combination of hardware components; however, other embodiments may include network nodes with different combinations of components. It should be understood that a network node includes any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods and / or processes disclosed herein. Furthermore, while the components of network node 2060 are depicted as single boxes located within larger boxes or nested within multiple boxes, in practice, a network node may include multiple different physical components that make up a single illustrated component (e.g., device-readable medium 2080 may include multiple separate hard disk drives and multiple RAM modules).

[0191] Similarly, network node 2060 may include multiple physically separate components (e.g., node B components and RNC components, or BTS components and BSC components, etc.), each of which may have its own corresponding components. In some scenarios where network node 2060 includes multiple separate components (e.g., BTS and BSC components), one or more separate components may be shared among several network nodes. For example, a single RNC may control multiple node Bs. In such scenarios, in some instances, each unique node B and RNC pair may be considered a single, separate network node. In some embodiments, network node 2060 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate device-readable media 2080 for different RATs), and some components may be reused (e.g., the same antenna 2062 may be shared by RATs). Network node 2060 may also include multiple sets of illustrated components for various wireless technologies integrated into network node 2060, such as, for example, GSM, WCDMA, LTE, NR, WiFi, or Bluetooth wireless technologies. These wireless technologies can be integrated into the same or different chips or chip sets within network node 2060.

[0192] Processing circuitry 2070 can be configured to perform any determination, calculation, or similar operation (e.g., certain acquisition operations) described herein as being provided by a network node. These operations performed by processing circuitry 2070 may include processing information acquired by processing circuitry 2070 (by, for example, converting the acquired information into other information, comparing the acquired or converted information with information stored in the network node, and / or performing one or more operations based on the acquired or converted information), and making a determination as a result of said processing.

[0193] Processing circuitry 2070 may include one or more of the following: a microprocessor, a controller, a central processing unit, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or any other suitable computing device or resource; or it may include a combination of hardware, software, and / or coded logic operable to provide various functions of network node 2060, either alone or in combination with other network node 2060 components (device-readable medium 2080). Such functions may include any of the various wireless features, capabilities, or benefits discussed herein.

[0194] For example, processing circuitry 2070 may execute instructions stored in device-readable medium 2080 or in memory within processing circuitry 2070. In some embodiments, processing circuitry 2070 may include a system-on-a-chip (SOC). As a more specific example, instructions (also referred to as a computer program product) stored in medium 2080 may include instructions that, when executed by processing circuitry 2070, may configure network node 2060 to perform operations corresponding to the various example methods (e.g., procedures) described herein.

[0195] In some embodiments, processing circuitry 2070 may include one or more of radio frequency (RF) transceiver circuitry 2072 and baseband processing circuitry 2074. In some embodiments, RF transceiver circuitry 2072 and baseband processing circuitry 2074 may be on separate chips (or chipsets), boards, or units (such as radio units and digital units). In other alternative embodiments, a portion or all of RF transceiver circuitry 2072 and baseband processing circuitry 2074 may be on the same chip or chipset, board, or unit.

[0196] In some embodiments, some or all of the functions described herein as being provided by a network node, base station, eNB, or other such network device may be performed by processing circuitry 2070 executing instructions stored in memory within device-readable medium 2080 or processing circuitry 2070. In alternative embodiments, some or all of the functions may be provided by processing circuitry 2070 without executing instructions stored on a separate or independent device-readable medium, such as in a hard-wired manner. In any of those embodiments, processing circuitry 2070 may be configured to perform the described functions regardless of whether instructions stored on a device-readable storage medium are executed. The benefits provided by such functions are not limited solely to processing circuitry 2070 or other components of network node 2060, but are enjoyed by network node 2060 as a whole and / or generally by end users and the wireless network.

[0197] Device-readable medium 2080 may include any form of volatile or non-volatile computer-readable storage, including but not limited to persistent storage devices, solid-state storage, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drives, optical discs (CDs), or digital video discs (DVDs)), and / or any other volatile or non-volatile non-transitory device-readable storage device and / or computer-executable memory device that stores information, data, and / or instructions usable by processing circuitry 2070. Device-readable medium 2080 may store any suitable instructions, data, or information, including computer programs, software, applications including one or more of logic, rules, code, tables, etc., and / or other instructions executable by processing circuitry 2070 and usable by network node 2060. Device-readable medium 2080 may be used to store any calculations performed by processing circuitry 2070 and / or any data received via interface 2090. In some embodiments, the processing circuitry 2070 and the device-readable medium 2080 may be considered integrated.

[0198] Interface 2090 is used in wired or wireless communication of signaling and / or data between network node 2060, network 2006, and / or WD 2010. As shown, interface 2090 includes, for example, one or more ports / terminals 2094 for sending and receiving data to and from network 2006 via a wired connection. Interface 2090 also includes radio front-end circuitry 2092, which may be coupled to antenna 2062 or, in some embodiments, is part of antenna 2062. Radio front-end circuitry 2092 includes filter 2098 and amplifier 2096. Radio front-end circuitry 2092 may be connected to antenna 2062 and processing circuitry 2070. Radio front-end circuitry 2092 may be configured to modulate the signal transmitted between antenna 2062 and processing circuitry 2070. Radio front-end circuitry 2092 may receive digital data to be transmitted wirelessly to other network nodes or WD. The radio front-end circuit 2092 can use a combination of filter 2098 and / or amplifier 2096 to convert digital data into radio signals with appropriate channel and bandwidth parameters. The radio signals can then be transmitted via antenna 2062. Similarly, when receiving data, antenna 2062 can collect radio signals, which are then converted into digital data by the radio front-end circuit 2092. The digital data can be passed to processing circuitry 2070. In other embodiments, the interface may include different components and / or different combinations of components.

[0199] In some alternative embodiments, network node 2060 may not include a separate radio front-end circuitry 2092; instead, processing circuitry 2070 may include radio front-end circuitry and be connectable to antenna 2062 without requiring a separate radio front-end circuitry 2092. Similarly, in some embodiments, all or part of RF transceiver circuitry 2072 may be considered part of interface 2090. In other embodiments, interface 2090 may include one or more ports or terminals 2094, radio front-end circuitry 2092, and RF transceiver circuitry 2072 as part of a radio unit (not shown), and interface 2090 may communicate with baseband processing circuitry 2074, which is part of a digital unit (not shown).

[0200] Antenna 2062 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 2062 may be coupled to radio front-end circuitry 2092 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 2062 may include one or more omnidirectional, sector, or planar antennas operable to transmit / receive radio signals, for example, between 2 GHz and 66 GHz. Omnidirectional antennas can be used to transmit / receive radio signals in any direction, sector antennas can be used to transmit / receive radio signals from devices within a specific area, and planar antennas can be line-of-sight antennas for transmitting / receiving radio signals along a relatively straight line. In some instances, the use of more than one antenna may be referred to as MIMO. In some embodiments, antenna 2062 may be detachable from network node 2060 and can be connected to network node 2060 via an interface or port.

[0201] Antenna 2062, interface 2090, and / or processing circuitry 2070 can be configured to perform any receive operation and / or certain acquisition operation described herein as being performed by a network node. Any information, data, and / or signals can be received from a wireless device, another network node, and / or any other network device. Similarly, antenna 2062, interface 2090, and / or processing circuitry 2070 can be configured to perform any transmit operation described herein as being performed by a network node. Any information, data, and / or signals can be transmitted to a wireless device, another network node, and / or any other network device.

[0202] Power supply circuitry 2087 may include or be coupled to power management circuitry and may be configured to supply power to components of network node 2060 for performing the functions described herein. Power supply circuitry 2087 may receive power from power source 2086. Power source 2086 and / or power supply circuitry 2087 may be configured to supply power to various components of network node 2060 in a manner suitable for the respective components (e.g., at the voltage and current levels required by each respective component). Power source 2086 may be included in power supply circuitry 2087 and / or network node 2060, or may be external to power supply circuitry 2087 and / or network node 2060. For example, network node 2060 may be connected to an external power source (e.g., an electrical outlet) via input circuitry or an interface (such as a cable), whereby the external power source supplies power to power supply circuitry 2087. As another example, power source 2086 may include a power source in the form of a battery or battery pack, which is connected to or integrated into power supply circuitry 2087. The battery can provide backup power in the event of an external power failure. Other types of power sources, such as photovoltaic devices, may also be used.

[0203] Alternative embodiments of network node 2060 may include, in addition to Figure 20 Additional components, other than those shown, may be responsible for providing certain aspects of the functionality of the network node (including any of the functions described herein and / or any functionality required to support the subject matter described herein). For example, network node 2060 may include user interface devices that allow and / or facilitate the input of information into network node 2060 and allow and / or facilitate the output of information from network node 2060. This may allow and / or facilitate users to perform diagnostic, maintenance, repair, and other management functions for network node 2060.

[0204] In some embodiments, a wireless device (WD, such as WD 2010) may be configured to send and / or receive information without direct human interaction. For example, a WD may be designed to send information to a network according to a predetermined schedule when triggered by an internal or external event or in response to a request from the network. Examples of wireless devices include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop-mounted devices (LMEs), smart devices, wireless client premises equipment (CPEs), mobile type communication (MTC) devices, Internet of Things (IoT) devices, in-vehicle wireless terminal devices, etc.

[0205] A WD can support device-to-device (D2D) communication, for example by implementing 3GPP standards for secondary link communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X), and in this case, it can be referred to as a D2D communication device. As another specific example, in the Internet of Things (IoT) scenario, a WD can represent a machine or other device that performs monitoring and / or measurement and sends the results of such monitoring and / or measurement to another WD and / or network node. In this case, the WD can be a machine-to-machine (M2M) device, which can be referred to as an MTC device in the 3GPP context. As a specific example, a WD can be a UE that implements the 3GPP Narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices (such as power meters), industrial machinery, or home or personal appliances (e.g., refrigerators, televisions, etc.), and personal wearable devices (e.g., watches, fitness trackers, etc.). In other scenarios, a WD can represent a vehicle-to-everything (V2X) or other device capable of monitoring and / or reporting its operational status or other functions associated with its operation. As described above, WD can represent a wireless connection endpoint, in which case the device can be referred to as a wireless terminal. Furthermore, as described above, WD can be mobile, in which case the WD can also be referred to as a mobile device or mobile terminal.

[0206] As shown in the figure, the wireless device 2010 includes an antenna 2011, an interface 2014, processing circuitry 2020, a device-readable medium 2030, a user interface device 2032, auxiliary devices 2034, a power supply 2036, and a power circuitry 2037. WD 2010 may include multiple sets of components for one or more of the different wireless technologies supported by WD 2010, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, to name just a few. These wireless technologies may be integrated into the same or different chipsets or chipsets within WD 2010.

[0207] Antenna 2011 may include one or more antennas or an antenna array, configured to transmit and / or receive wireless signals, and connected to interface 2014. In some alternative embodiments, antenna 2011 may be detached from WD 2010 and may be connected to WD 2010 via an interface or port. Antenna 2011, interface 2014, and / or processing circuitry 2020 may be configured to perform any receive or transmit operations described herein as being performed by a WD. Any information, data, and / or signals may be received from a network node and / or another WD. In some embodiments, radio front-end circuitry and / or antenna 2011 may be considered an interface.

[0208] As shown in the figure, interface 2014 includes radio front-end circuitry 2012 and antenna 2011. Radio front-end circuitry 2012 includes one or more filters 2018 and amplifiers 2016. Radio front-end circuitry 2012 is connected to antenna 2011 and processing circuitry 2020, and can be configured to modulate the signal transmitted between antenna 2011 and processing circuitry 2020. Radio front-end circuitry 2012 may be coupled to antenna 2011 or a portion thereof. In some embodiments, WD 2010 may not include a separate radio front-end circuitry 2012; instead, processing circuitry 2020 may include radio front-end circuitry and may be connected to antenna 2011. Similarly, in some embodiments, all or some of RF transceiver circuitry 2022 may be considered part of interface 2014. Radio front-end circuitry 2012 can receive digital data to be transmitted wirelessly to other network nodes or WD. Radio front-end circuitry 2012 may use a combination of filters 2018 and / or amplifiers 2016 to convert digital data into radio signals with appropriate channel and bandwidth parameters. The radio signals can then be transmitted via antenna 2011. Similarly, when receiving data, antenna 2011 can collect the radio signals, which are then converted into digital data by radio front-end circuitry 2012. The digital data can then be passed to processing circuitry 2020. In other embodiments, the interface may include different components and / or different combinations of components.

[0209] The processing circuitry 2020 may include one or more of the following: a microprocessor, a controller, a central processing unit, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or any other suitable computing device or resource; or it may include a combination of hardware, software, and / or coding logic operable to provide WD 2010 functionality, alone or in combination with other WD 2010 components, such as device-readable media 2030. Such functionality may include any of the various wireless features or benefits discussed herein.

[0210] For example, processing circuitry 2020 may execute instructions stored in device-readable medium 2030 or in memory within processing circuitry 2020 to provide the functionality disclosed herein. More specifically, instructions stored in medium 2030 (also referred to as a computer program product) may include instructions that, when executed by processing circuitry 2020, may configure wireless device 2010 to perform operations corresponding to the various example methods (e.g., procedures) described herein.

[0211] As shown in the figure, the processing circuit 2020 includes one or more of the following: RF transceiver circuit 2022, baseband processing circuit 2024, and application processing circuit 2026. In other embodiments, the processing circuit may include different components and / or different combinations of components. In some embodiments, the processing circuit 2020 of WD 2010 may include a System-on-a-Chip (SOC). In some embodiments, the RF transceiver circuit 2022, baseband processing circuit 2024, and application processing circuit 2026 may be on a separate chip or chipset. In alternative embodiments, a portion or all of the baseband processing circuit 2024 and application processing circuit 2026 may be combined into a single chip or chipset, and the RF transceiver circuit 2022 may be on a separate chip or chipset. In other alternative embodiments, a portion or all of the RF transceiver circuit 2022 and baseband processing circuit 2024 may be on the same chip or chipset, and the application processing circuit 2026 may be on a separate chip or chipset. In other alternative embodiments, some or all of the RF transceiver circuitry 2022, baseband processing circuitry 2024, and application processing circuitry 2026 may be combined in a single chip or chipset. In some embodiments, the RF transceiver circuitry 2022 may be part of interface 2014. The RF transceiver circuitry 2022 may modulate the RF signals used for processing circuitry 2020.

[0212] In some embodiments, some or all of the functions described herein as being performed by WD may be provided by processing circuitry 2020 that executes instructions stored on device-readable medium 2030, which in some embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by processing circuitry 2020 without executing instructions stored on a separate or independent device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, processing circuitry 2020 may be configured to perform the described functions regardless of whether instructions stored on the device-readable storage medium are executed. The benefits provided by such functions are not limited solely to processing circuitry 2020 or other components of WD 2010, but are enjoyed by WD 2010 as a whole and / or generally by end users and wireless networks.

[0213] The processing circuitry 2020 can be configured to perform any determination, calculation, or similar operation (e.g., certain acquisition operations) described herein as being performed by WD. Such operations performed by the processing circuitry 2020 may include processing information acquired by the processing circuitry 2020 (by, for example, converting the acquired information into other information, comparing the acquired or converted information with information stored by WD 2010, and / or performing one or more operations based on the acquired or converted information), and making a determination as a result of the processing.

[0214] Device-readable medium 2030 may be operable to store computer programs, software, applications including one or more of logic, rules, code, tables, etc., and / or other instructions executable by processing circuitry 2020. Device-readable medium 2030 may include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., hard disk), removable storage media (e.g., optical disc (CD) or digital video disc (DVD)), and / or any other volatile or non-volatile non-transitory computer-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by processing circuitry 2020. In some embodiments, processing circuitry 2020 and device-readable medium 2030 may be considered integrated.

[0215] User interface device 2032 may include components that allow and / or facilitate human user interaction with WD 2010. Such interaction can take many forms, such as visual, auditory, tactile, etc. User interface device 2032 may be operable to produce output to the user and allow and / or facilitate input from the user to WD 2010. The type of interaction may vary depending on the type of user interface device 2032 installed in WD 2010. For example, if WD 2010 is a smartphone, interaction may be via a touchscreen; if WD 2010 is a smart meter, interaction may be via a screen providing usage (e.g., the number of gallons used) or a speaker providing an audible alarm (e.g., if smoke is detected). User interface device 2032 may include input interfaces, devices, and circuitry, as well as output interfaces, devices, and circuitry. User interface device 2032 may be configured to allow and / or facilitate information input to WD 2010 and connected to processing circuitry 2020 to allow and / or facilitate processing of the input information by processing circuitry 2020. User interface device 2032 may include, for example, a microphone, proximity or other sensors, keys / buttons, a touch display, one or more cameras, a USB port, or other input circuitry. User interface device 2032 is also configured to allow and / or facilitate the output of information from WD 2010, and to allow and / or facilitate the output of information from WD 2010 by processing circuitry 2020. User interface device 2032 may include, for example, a speaker, display, vibration circuitry, a USB port, a headphone jack, or other output circuitry. Using one or more input and output interfaces, devices, and circuitry of user interface device 2032, WD 2010 can communicate with end users and / or wireless networks, and allow and / or facilitate them to benefit from the functionality described herein.

[0216] The auxiliary device 2034 is operable to provide more specific functions that may not typically be performed by the WD. This may include specialized sensors for measurements for various purposes, interfaces for additional types of communication such as wired communication, etc. The inclusion and type of components of the auxiliary device 2034 may vary depending on the embodiment and / or scenario.

[0217] In some embodiments, power supply 2036 may be in the form of a battery or battery pack. Other types of power sources may also be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery. WD 2010 may also include power circuitry 2037 for supplying power from power supply 2036 to various parts of WD 2010 that require power from power supply 2036 to perform any of the functions described or indicated herein. In some embodiments, power circuitry 2037 may include power management circuitry. Additionally or alternatively, power circuitry 2037 may be operable to receive power from an external power source; in this case, WD 2010 may be connected to an external power source (such as an electrical outlet) via input circuitry or an interface such as a power cable. In some embodiments, power circuitry 2037 may also be operable to supply power from an external power source to power supply 2036. This may be used, for example, for charging power supply 2036. Power circuitry 2037 may perform any conversion or other modification on the power from power supply 2036 to suit its use in powering corresponding components of WD 2010.

[0218] Figure 21 An embodiment of a UE according to the aspects described herein is illustrated. As used herein, a user equipment or UE may not necessarily have to be a user in the sense of a human user who owns and / or operates the associated equipment. Instead, a UE may represent a device intended for sale to a human user or operated by a human user but which may not or initially may not be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device not intended for sale to an end user or operated by an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter). UE 2100 may be a UE identified by the 3rd Generation Partnership Project (3GPP), including NB-IoT UEs, Machine-Type Communication (MTC) UEs, and / or Enhanced MTC (eMTC) UEs. Figure 21 As shown, UE 2100 is an example of a WD configured to communicate according to one or more communication standards (such as 3GPP's GSM, UMTS, LTE, and / or 5G standards) issued by the 3rd Generation Partnership Project (3GPP). As previously mentioned, the terms WD and UE can be used interchangeably. Therefore, although Figure 21 It is a UE, but the components discussed in this article also apply to WD, and vice versa.

[0219] exist Figure 21In this embodiment, UE 2100 includes processing circuitry 2101 operatively coupled to an input / output interface 2105, a radio frequency (RF) interface 2109, a network connectivity interface 2111, a memory 2115 (including random access memory (RAM) 2117, read-only memory (ROM) 2119, and storage medium 2121, etc.), a communication subsystem 2131, a power supply 2113, and / or any other component, or any combination thereof. Storage medium 2121 includes an operating system 2123, application programs 2125, and data 2127. In other embodiments, storage medium 2121 may include other similar types of information. Some UEs may utilize... Figure 21 The components shown may be all or only a subset of the components. The degree of integration between components may vary depending on the UE. Furthermore, some UEs may contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0220] exist Figure 21 In this embodiment, processing circuitry 2101 can be configured to process computer instructions and data. Processing circuitry 2101 can be configured to implement any sequential state machine operable to execute machine instructions stored in memory as a machine-readable computer program, such as one or more hardware-implemented state machines (e.g., discrete logic, FPGA, ASIC, etc.); programmable logic along with appropriate firmware; one or more stored programs, a general-purpose processor, such as a microprocessor or digital signal processor (DSP), along with appropriate software; or any combination of the foregoing. For example, processing circuitry 2101 may include two central processing units (CPUs). Data may be information in a form suitable for use by a computer.

[0221] In the depicted embodiments, the input / output interface 2105 can be configured to provide a communication interface to an input device, an output device, or both. The UE 2100 can be configured to use an output device via the input / output interface 2105. The output device can use an interface port of the same type as the input device. For example, a USB port can be used to provide input to and output from the UE 2100. The output device can be a speaker, sound card, video card, display, monitor, printer, actuator, transmitter, smart card, another output device, or any combination thereof. The UE 2100 can be configured to use an input device via the input / output interface 2105 to allow and / or facilitate the user to capture information into the UE 2100. The input device may include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, digital video camera, webcam, etc.), a microphone, a sensor, a mouse, a trackball, a steering wheel, a scroll wheel, a smart card, etc. A presence-sensitive display may include a capacitive or resistive touch sensor that senses input from the user. Sensors can be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, another similar sensor, or any combination thereof. For example, input devices can be accelerometers, magnetometers, digital cameras, microphones, and optical sensors.

[0222] exist Figure 21 In this configuration, RF interface 2109 can be configured to provide a communication interface to RF components such as transmitters, receivers, and antennas. Network connectivity interface 2111 can be configured to provide a communication interface to network 2143a. Network 2143a may encompass wired and / or wireless networks, such as local area networks (LANs), wide area networks (WANs), computer networks, wireless networks, telecommunications networks, another similar network, or any combination thereof. For example, network 2143a may include a Wi-Fi network. Network connectivity interface 2111 can be configured to include receiver and transmitter interfaces for communicating with one or more other devices over the communication network according to one or more communication protocols such as Ethernet, TCP / IP, SONET, ATM, etc. Network connectivity interface 2111 can implement receiver and transmitter functions suitable for communication network links (e.g., optical, electrical, etc.). Transmitter and receiver functions may share circuit components, software, or firmware, or alternatively, may be implemented separately.

[0223] RAM 2117 can be configured to interface to processing circuitry 2101 via bus 2102 to provide storage or cache of data or computer instructions during the execution of software programs (such as operating systems, application programs, and device drivers). ROM 2119 can be configured to provide computer instructions or data to processing circuitry 2101. For example, ROM 2119 can be configured to store immutable low-level system code or data for basic system functions (such as basic input and output (I / O), booting, or receiving keystrokes from a keyboard stored in non-volatile memory). Storage medium 2121 can be configured to include memories such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, floppy disk, hard disk, removable disk, or flash drive.

[0224] In one example, storage medium 2121 may be configured to include operating system 2123; application program 2125, such as a web browser application, widget or accessory engine, or another application; and data file 2127. Storage medium 2121 may store any of a variety of different operating systems or combinations of operating systems for use by UE 2100. For example, application program 2125 may include executable program instructions (also referred to as computer program products) that, when executed by processor 2101, can configure UE 2100 to perform operations corresponding to the various example methods (e.g., procedures) described herein.

[0225] Storage medium 2121 can be configured to include multiple physical drive units, such as redundant array of independent disks (RAID), floppy disk drive, flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital universal optical disc (HD-DVD) drive, internal hard disk drive, Blu-ray disc drive, holographic digital data storage (HDDS) disc drive, external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory (such as a user identity module or removable user identity (SIM / RUIM) module), other memory, or any combination thereof. Storage medium 2121 can allow and / or facilitate UE 2100 to access computer-executable instructions, applications, etc., stored on transient or non-transient storage media to unload or upload data. Articles of manufacture (such as articles utilizing communication systems) can be tangibly implemented in storage medium 2121, which may include device-readable media.

[0226] exist Figure 21In this embodiment, processing circuitry 2101 can be configured to communicate with network 2143b using communication subsystem 2131. Networks 2143a and 2143b can be the same one or more networks or different one or more networks. Communication subsystem 2131 can be configured to include one or more transceivers for communicating with network 2143b. For example, communication subsystem 2131 can be configured to include one or more remote transceivers for communicating wirelessly with another device (such as another WD, UE, or a base station of a radio access network (RAN)) according to one or more communication protocols (such as IEEE 802.21, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, etc.). Each transceiver can include transmitter 2133 and / or receiver 2135, respectively implementing transmitter or receiver functions suitable for the RAN link (e.g., frequency allocation, etc.). Further, transmitter 2133 and receiver 2135 of each transceiver can share circuit components, software, or firmware, or alternatively can be implemented separately.

[0227] In the illustrated embodiment, the communication functions of the communication subsystem 2131 may include data communication, voice communication, multimedia communication, short-range communication (such as Bluetooth, near-field communication), location-based communication (such as using a Global Positioning System (GPS) to determine location), another similar communication function, or any combination thereof. For example, the communication subsystem 2131 may include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 2143b may encompass wired and / or wireless networks, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 2143b may be a cellular network, a Wi-Fi network, and / or a near-field network. The power supply 2113 may be configured to provide alternating current (AC) or direct current (DC) power to the components of the UE 2100.

[0228] The features, benefits, and / or functions described herein may be implemented in one of the components of UE 2100 or distributed across multiple components of UE 2100. Further, the features, benefits, and / or functions described herein may be implemented in any combination of hardware, software, or firmware. In one example, the communication subsystem 2131 may be configured to include any of the components described herein. Further, the processing circuitry 2101 may be configured to communicate with any of such components via bus 2102. In another example, any such component may be represented by program instructions stored in memory that, when executed by the processing circuitry 2101, perform the corresponding functions described herein. In another example, the functionality of any such component may be distributed between the processing circuitry 2101 and the communication subsystem 2131. In yet another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0229] Figure 22 This is a schematic block diagram illustrating a virtualized environment 2200 that can virtualize functionality implemented by some embodiments. In this context, virtualization means creating virtual versions of apparatuses or devices that may include virtualized hardware platforms, storage devices, and network resources. As used herein, virtualization can be applied to nodes (e.g., virtualized base stations or virtualized radio access nodes) or devices (e.g., UEs, wireless devices, or any other type of communication device) or components thereof, and at least a portion of the functionality is implemented as an implementation of one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, or containers executed on one or more physical processing nodes in one or more networks).

[0230] In some embodiments, some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 2200 hosted in one or more hardware nodes 2230. Further, in embodiments where the virtual node is not a radio access node or does not require a radio connection (e.g., a core network node), the network node may be fully virtualized.

[0231] The functionality may be implemented by one or more applications 2220 (which may alternatively be referred to as software instances, virtual devices, network functions, virtual nodes, virtual network functions, etc.), which are operable to implement some of the features, functions, and / or benefits of the embodiments disclosed herein. Application 2220 runs in a virtualization environment 2200 that provides hardware 2230 including processing circuitry 2260 and memory 2290. Memory 2290 contains instructions 2295 executable by processing circuitry 2260, wherein application 2220 is operable to provide one or more of the features, benefits, and / or functions disclosed herein.

[0232] The virtualization environment 2200 may include general-purpose or special-purpose network hardware devices (or nodes) 2230, which include one or more processors or processing circuitry 2260, which may be commercial off-the-shelf (COTS) processors, application-specific integrated circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special-purpose processors. Each hardware device may include memory 2290-1, which may be non-persistent memory for temporarily storing instructions 2295 or software executed by the processing circuitry 2260. For example, instructions 2295 may include program instructions (also known as computer program products) that, when executed by the processing circuitry 2260, can configure the hardware node 2230 to perform operations corresponding to the various example methods (e.g., procedures) described herein. Such operations may also be considered as one or more virtual nodes 2220 hosted by the hardware node 2230.

[0233] Each hardware device may include one or more network interface controllers (NICs) 2270 (also referred to as network interface cards), which include a physical network interface 2280. Each hardware device may also include a non-transitory persistent machine-readable storage medium 2290-2 in which software 2295 and / or instructions executable by processing circuitry 2260 are stored. The software 2295 may include any type of software, including software for instantiating one or more virtualization layers 2250 (also referred to as a hypervisor), software executing a virtual machine 2240, and software that allows the performance of the functions, features, and / or benefits described in connection with some embodiments described herein.

[0234] Virtual machine 2240 includes virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and can be run by a corresponding virtualization layer 2250 or hypervisor. Different embodiments of instances of virtual device 2220 may be implemented on one or more virtual machines 2240, and these implementations may be carried out in different ways.

[0235] During operation, processing circuitry 2260 executes software 2295 to instantiate a hypervisor or virtualization layer 2250, which may sometimes be referred to as a virtual machine monitor (VMM). The virtualization layer 2250 can present a virtual operating platform that appears to be network hardware to the virtual machine 2240.

[0236] like Figure 22 As shown, hardware 2230 can be a standalone network node with general or specific components. Hardware 2230 may include antenna 22225 and may implement some functions via virtualization. Alternatively, hardware 2230 may be part of a larger hardware cluster (e.g., in a data center or customer premises equipment (CPE)) in which many hardware nodes work together and are managed via management and orchestration (MANO) 22100, which in particular oversees the lifecycle management of application 2220.

[0237] Hardware virtualization is sometimes referred to as Network Functions Virtualization (NFV). NFV can be used to consolidate many types of network devices into industry-standard high-capacity server hardware, physical switches, and physical storage devices, which can reside in data centers and client terminal devices.

[0238] In the context of NFV, virtual machine 1040 can be a software implementation of a physical machine, and its running programs are as if they were executed on a physical, non-virtualized machine. Each virtual machine 2240 and the portion of hardware 2230 that executes that virtual machine (i.e., hardware dedicated to that virtual machine and / or hardware shared by that virtual machine and other virtual machines 2240) form a separate virtual network element (VNE).

[0239] Still within the context of NFV, a Virtual Network Function (VNF) is responsible for handling specific network functions running in one or more virtual machines 2240 on top of the hardware network infrastructure 2230, and corresponds to Figure 22 Application 2220 in the context of this.

[0240] In some embodiments, one or more radio units 22200, each including one or more transmitters 22220 and one or more receivers 22210, may be coupled to one or more antennas 22225. The radio unit 22200 may communicate directly with the hardware node 2230 via one or more suitable network interfaces and may be combined with virtual components to provide a radio-capable virtual node, such as a radio access node or base station. A node arranged in this manner may also communicate with one or more UEs, as described elsewhere herein.

[0241] In some embodiments, some signaling may be executed via control system 22230, which may alternatively be used for communication between hardware node 2230 and radio unit 22200.

[0242] refer to Figure 23 According to an embodiment, the communication system includes a telecommunications network 2310, such as a 3GPP-type cellular network, which includes an access network 2311 (such as a radio access network) and a core network 2314. The access network 2311 includes multiple base stations 2312a, 2312b, and 2312c, such as NBs, eNBs, gNBs, or other types of wireless access points, each base station 2312a, 2312b, and 2312c defining a corresponding coverage area 2313a, 2313b, and 2313c. Each base station 2312a, 2312b, and 2312c can be connected to the core network 2314 via a wired or wireless connection 2315. A first UE 2391 located in coverage area 2313c can be configured to wirelessly connect to or be called by the corresponding base station 2312c. A second UE 2392 located in coverage area 2313a can wirelessly connect to the corresponding base station 2312a. Although multiple UEs 2391 and 2392 are shown in this example, the disclosed embodiments are equally applicable to situations where a single UE is in a coverage area or a single UE is connected to a corresponding base station.

[0243] Telecommunications network 2310 connects itself to host computer 2330, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as a processing resource in a server cluster. Host computer 2330 may be owned or controlled by a service provider, or may be operated by or on behalf of the service provider. Connections 2321 and 2322 between telecommunications network 2310 and host computer 2330 may extend directly from core network 2314 to host computer 2330 or may be made via optional intermediate network 2320. Intermediate network 2320 may be one or more public, private, or host networks; if any, intermediate network 2320 may be a backbone network or the Internet; in particular, intermediate network 2320 may include two or more subnetworks (not shown).

[0244] Figure 23The communication system as a whole enables connectivity between the connected UEs 2391 and 2392 and the host computer 2330. This connectivity can be described as an over-the-top (OTT) connection 2350. The host computer 2330 and the connected UEs 2391 and 2392 are configured to use access network 2311, core network 2314, any intermediate network 2320, and possibly further infrastructure (not shown) as intermediaries to transmit data and / or signaling via the OTT connection 2350. The OTT connection 2350 can be transparent in the sense that the participating communication devices traversing the OTT connection 2350 are unaware of the routes of uplink and downlink communications. For example, the base station 2312 may not be informed, or need not be informed, of the past routes of incoming downlink communications originating from the host computer 2330 that are to be forwarded (e.g., handed over) to the connected UE 2391. Similarly, base station 2312 does not need to know the future route of outgoing uplink communication originating from UE 2391 toward host computer 2330.

[0245] Now refer to Figure 24 Example implementations of the UE, base station, and host computer discussed in the preceding paragraphs according to embodiments are described. In the communication system 2400, the host computer 2410 includes hardware 2415 including a communication interface 2416 configured to establish and maintain wired or wireless connections with different communication devices of the communication system 2400. The host computer 2410 also includes processing circuitry 2418, which may have storage and / or processing capabilities. In particular, the processing circuitry 2418 may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) suitable for executing instructions. The host computer 2410 also includes software 2411, which is stored in or accessible by the host computer 2410 and executable by the processing circuitry 2418. The software 2411 includes a host application 2412. Host application 2412 is operable to provide services to remote users, such as UE 2430 connected via OTT connection 2450 terminated at UE 2430 and host computer 2410. When providing services to remote users, host application 2412 can provide user data sent using OTT connection 2450.

[0246] The communication system 2400 also includes a base station 2420, which is provided in the telecommunications system and includes hardware 2425 enabling the base station 2420 to communicate with the host computer 2410 and the UE 2430. Hardware 2425 may include a communication interface 2426 for establishing and maintaining wired or wireless connections with different communication devices of the communication system 2400, and for establishing and maintaining connections at least with areas within the coverage area served by the base station 2420 (in... Figure 24 The radio interface 2427 of the UE 2430 (not shown) is for the wireless connection 2470. The communication interface 2426 can be configured to facilitate a connection 2460 to the host computer 2410. The connection 2460 can be direct, or it can traverse the core network of the telecommunications system (in...). Figure 24 (not shown) and / or one or more intermediate networks outside the telecommunications system. In the illustrated embodiment, the hardware 2425 of the base station 2420 may also include processing circuitry 2428, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations of these (not shown) adapted to execute instructions.

[0247] Base station 2420 also includes software 2421 stored internally or accessible via an external connection. For example, software 2421 may include program instructions (also referred to as a computer program product) that, when executed by processing circuitry 2428, can configure base station 2420 to perform operations corresponding to the various example methods (e.g., procedures) described herein.

[0248] The communication system 2400 may also include the previously mentioned UE 2430, whose hardware 2435 may include a radio interface 2437 configured to establish and maintain a radio connection 2470 with a base station serving the coverage area where the UE 2430 is currently located. The hardware 2435 of the UE 2430 may also include processing circuitry 2438, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) suitable for executing instructions.

[0249] UE 2430 also includes software 2431, which is stored in or accessible by UE 2430 and executable by processing circuitry 2438. Software 2431 includes a client application 2432. Client application 2432 is operable to provide services to human or non-human users via UE 2430 with the support of host computer 2410. In host computer 2410, host application 2412, executing, can communicate with client application 2432 via OTT connection 2450 terminated at UE 2430 and host computer 2410. When providing services to a user, client application 2432 can receive request data from host application 2412 and provide user data in response to the request data. OTT connection 2450 can transmit both request data and user data. Client application 2432 can interact with the user to generate the user data it provides. Software 2431 may also include program instructions (also known as computer program products) that, when executed by processing circuitry 2438, can configure UE 2430 to perform operations corresponding to the various example methods (e.g., procedures) described herein.

[0250] It should be noted that Figure 24 The host computer 2410, base station 2420, and UE 2430 shown can be respectively connected to Figure 16 One of the host computer 1230, base stations 1612a, 1612b, and 1612c, and one of the UEs 1691 and 1692 are similar to or the same. That is to say, the internal workings of these entities can be as follows: Figure 24 As shown, and independently, the surrounding network topology can be Figure 16 The network topology.

[0251] exist Figure 24 In this diagram, the OTT connection 2450 is abstractly depicted to illustrate communication between the host computer 2410 and the UE 2430 via the base station 2420, without explicitly referencing any intermediate devices and the precise routes of messages via those devices. The network infrastructure can determine the route, which can be configured to conceal it from the UE 2430 or the service provider operating the host computer 2410, or both. While the OTT connection 2450 is active, the network infrastructure can also make decisions to dynamically change the route (e.g., based on network load balancing considerations or reconfiguration).

[0252] The radio connection 2470 between UE 2430 and base station 2420 is based on the teachings of the embodiments described throughout this disclosure. One or more improvements in various embodiments utilize radio connection 2470 to form the final segment of OTT connection 2450, providing performance for OTT services to UE 2430. More precisely, the exemplary embodiments disclosed herein can improve the flexibility of end-to-end Quality of Service (QoS) for network monitoring data streams, including their corresponding radio bearers associated with data sessions between user equipment (UE) and another entity, such as OTT data applications or services outside the 5G network. These and other advantages can facilitate more timely design, implementation, and deployment of 5G / NR solutions. Furthermore, such embodiments can facilitate flexible and timely control over data session QoS, which can lead to improvements in capacity, throughput, latency, etc., which are envisioned for 5G / NR and are important for the growth of OTT services.

[0253] The measurement process can be provided for the purpose of monitoring data rates, latency, and other network operational aspects improved in one or more embodiments. Optional network functions may also be available for reconfiguring the OTT connection 2450 between the host computer 2410 and the UE 2430 in response to changes in the measurement results. The measurement process and / or the network functions for reconfiguring the OTT connection 2450 may be implemented in the software 2411 and hardware 2415 of the host computer 2410, or in the software 2431 and hardware 2435 of the UE 2430, or both. In embodiments, sensors (not shown) may be deployed in or associated with communication equipment through which the OTT connection 2450 passes; the sensors may participate in the measurement process by supplying values ​​of the monitored quantities illustrated above, or by supplying values ​​of other physical quantities from which the software 2411, 2431 can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 2450 may include message formatting, retransmission settings, preferred routing, etc.; reconfiguration does not need to affect the base station 2420, and the reconfiguration may be unknown or imperceptible to the base station 2420. Such processes and functions may be known and practiced in the art. In some embodiments, measurement results may involve proprietary UE signaling that facilitates measurements of throughput, propagation time, latency, etc., of the host computer 2410. Measurements can be implemented because software 2411 and 2431 enable messages (especially empty or "dummy" messages) to be sent using the OTT connection 2450 while monitoring propagation time, errors, etc.

[0254] Figure 25This is a flowchart illustrating an example method and / or process implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which in some example embodiments may be the host computer, base station, and UE described with reference to other figures herein. For the sake of simplicity in this disclosure, only [the following are included in this section] Figure 25 Reference numerals are used in the accompanying drawings. In step 2510, the host computer provides user data. In sub-step 2511 of step 2510 (which may be optional), the host computer provides user data by executing a host application. In step 2520, the host computer initiates a transmission carrying user data to the UE. In step 2530 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station sends the user data carried in the transmission initiated by the host computer to the UE. In step 2540 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0255] Figure 26 This is a flowchart illustrating an example method and / or process implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be the host computer, base station, and UE described with reference to other accompanying drawings herein. For the sake of simplicity in this disclosure, only [the following are included in this section] Figure 26 Reference numerals are used in the accompanying drawings. In step 2610 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides user data by executing a host application. In step 2620, the host computer initiates a transmission carrying user data to the UE. Based on the teachings of the embodiments described throughout this disclosure, the transmission may be carried out via a base station. In step 2630 (which may be optional), the UE receives the user data carried in the transmission.

[0256] Figure 27 This is a flowchart illustrating an example method and / or process implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be the host computer, base station, and UE described with reference to other accompanying drawings herein. For the sake of simplicity in this disclosure, only [the following are included in this section] Figure 27Reference numerals are used in the accompanying drawings. In step 2710 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 2720, the UE provides user data. In sub-step 2721 of step 2720 (which may be optional), the UE provides user data by executing a client application. In sub-step 2711 of step 2710 (which may be optional), the UE executes a client application that provides user data as a response to the received input data provided by the host computer. When providing user data, the executed client application may also consider user input received from the user. Regardless of the specific manner in which user data is provided, in sub-step 2730 (which may be optional), the UE initiates the transmission of user data to the host computer. In step 2740 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the host computer receives user data sent from the UE.

[0257] Figure 28 This is a flowchart illustrating an example method and / or process implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be the host computer, base station, and UE described with reference to other accompanying drawings herein. For the sake of simplicity in this disclosure, only [the following are included in this section] Figure 28 Reference numerals are used in the accompanying drawings. In step 2810 (which may be optional), the base station receives user data from the UE in accordance with the teachings of the embodiments described throughout this disclosure. In step 2820 (which may be optional), the base station initiates a transmission of the received user data to the host computer. In step 2830 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0258] As described herein, devices and / or apparatuses may be represented by semiconductor chips, chipsets, or (hardware) modules including such chips or chipsets; however, this does not preclude the possibility that the functionality of a device or apparatus may be implemented as a software module (such as a computer program or computer program product including executable software code portions for execution or running on a processor) instead of being implemented in hardware. Furthermore, the functionality of a device or apparatus may be implemented by any combination of hardware and software. A device or apparatus may also be considered as an assembly of multiple devices and / or apparatuses, whether functionally cooperative or independent of each other. Moreover, devices and apparatuses may be implemented in a distributed manner within a system, provided that the functionality of the devices or apparatuses is preserved. Such and similar principles are considered to be known to those skilled in the art.

[0259] Furthermore, the functions described herein as being performed by wireless devices or network nodes can be distributed across multiple wireless devices and / or network nodes. In other words, it should be anticipated that the functions of the network nodes and wireless devices described herein are not limited to being performed by a single physical device, and in fact, can be distributed among multiple physical devices.

[0260] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that, unless expressly defined herein, the terms used herein shall be interpreted as having the same meaning as they mean in the context of this specification and the relevant field, and shall not be interpreted in an idealized or overly formal sense.

[0261] Furthermore, certain terms used in this disclosure (including the specification, drawings, and example embodiments) may be used synonymously in certain instances, including but not limited to, data and information. It should be understood that while these words and / or other words that are synonymous with each other may be used synonymously herein, there may also be situations where such words are intended to be used differently. Further, to the extent that prior art knowledge has not been expressly incorporated herein by reference, it is expressly incorporated in its entirety. All disclosures referenced are incorporated herein by reference in their entirety.

[0262] As used herein, unless explicitly stated otherwise, the phrases “at least one of…” and “one or more of…” followed by a connected list of enumerated items (e.g., “A and B”, “A, B and C”) are intended to mean “at least one item, each of which is selected from the list of enumerated items.” For example, “at least one of A and B” is intended to mean any of the following: A; B; A and B. Similarly, “one or more of A, B and C” is intended to mean any of the following: A; B; C; A and B; B and C; A and C; A, B and C.

[0263] As used herein, unless explicitly stated otherwise, the phrase “multiple” followed by a connected list of enumerated items (e.g., “A and B”, “A, B and C”) is intended to mean “multiple items, each of which is selected from a list including the enumerated items.” For example, “multiple A and B” is intended to mean any of the following: more than one A; more than one B; or at least one A and at least one B.

[0264] The foregoing has only illustrated the principles of this disclosure. Various modifications and variations of the described embodiments will be apparent to those skilled in the art in light of the teachings herein. Therefore, it will be understood that, although not explicitly shown or described herein, those skilled in the art will be able to design numerous systems, arrangements, and processes that embody the principles of this disclosure and thus fall within its spirit and scope. Various exemplary embodiments may be used together with and interchangeably with each other, as should be understood by those skilled in the art.

Claims

1. A method performed by an anchor function (AAnF) for application authentication and key management in a communication network, the method comprising: Receive a request from the application function for a security key Kaf specific to an application session for a specific user, wherein the request includes a representation of the following information associated with the specific user: The first identifier of the non-application-specific anchor security key Kakma, KakmaID, and The second identifier related to the online contract; and Based on the representation, the authentication server function AUSF that generates the non-application-specific anchor security key Kakma is determined.

2. The method according to claim 1, further comprising: Obtain the non-application-specific anchor security key Kakma from the determined AUSF; as well as Based on the non-application-specific anchor security key Kakma, generate the application session-specific security key Kaf.

3. The method according to any one of claims 1 to 2, wherein: The representation includes a third identifier B-ID that binds the non-application-specific anchor security key Kakma to the AUSF that generated Kakma; as well as The third identifier includes: The representations of the first identifier and the second identifier, and Information associated with the AUSF.

4. The method according to claim 3, wherein, The information associated with the AUSF includes one or more of the following: AUSF group ID, AUSF ID, Subscribed Permanent Identifier (SUPI) range, Fully Qualified Domain Name (FQDN), and IP address.

5. The method according to claim 3, wherein, Determining the AUSF that generates the non-application-specific anchor security key Kakma includes: discovering the identifier of the AUSF via a Network Refuge Function (NRF) based on the information associated with the AUSF.

6. The method according to claim 3, wherein, Obtaining the non-application-specific anchor security key Kakma from the determined AUSF includes: Send a request including the third identifier to the identified AUSF; and Receive a response from the determined AUSF including the non-application-specific anchor security key Kakma and the second identifier.

7. The method according to any one of claims 1 to 2, wherein, The representation includes one of the following: The first identifier and the second identifier; or The first identifier includes a representation of the second identifier.

8. The method according to claim 7, wherein, The second identifier includes one of the following: HPLMN ID and User Equipment Routing Identifier (RID); The hidden identifier SUCI is a contractual agreement. The permanent identifier SUPI is signed; or General Public Contract Identifier (GPSI).

9. The method according to claim 7, wherein, Determining the AUSF includes: Based on the second identifier, select the Unified Data Management (UDM) entity in the communication network; Send a first request to the UDM entity for the fourth identifier associated with the AUSF; and Receive a first response from the UDM entity, including the fourth identifier.

10. The method according to claim 9, wherein, The first response also includes another second identifier associated with the network subscription associated with the specific user.

11. The method according to any one of claims 9 to 10, wherein, Obtaining the non-application-specific anchor security key Kakma includes: Send a second request to the AUSF associated with the fourth identifier, the second request including the second identifier or another second identifier related to the network subscription associated with the specific user; and Receive a second response from the AUSF including the non-application-specific anchor security key Kakma.

12. The method according to claim 11, wherein, One of the following situations applies: The second request also includes the first identifier; or The second response also includes the first identifier.

13. The method according to any one of claim 10 or 12, wherein: The other second identifier is the contract permanent identifier SUPI; and The second identifier is different from the identifier of SUPI.

14. The method according to any one of claims 1 to 2, further comprising: Send the security key Kaf, which is specific to the application session, to the application function.

15. A method performed by a key management server in a communication network, the method comprising: The following information associated with a specific user is received from the authentication server function AUSF: The non-application-specific anchor security key Kakma; The first identifier KakmaID of the non-application-specific anchor security key; and A second identifier related to online contract signing; Receive a request from the application function for a security key Kaf specific to the application session for the particular user, wherein the request includes another identifier, KakmaID, for a non-application-specific anchor security key associated with the particular user; and Based on the matching between the first identifier and the other identifier, the security key Kaf specific to the application session is generated based on the non-application-specific anchor security key Kakma.

16. The method of claim 15, wherein: The key management server includes multiple Anchor Function (AAnF) instances for application authentication and key management, each AAnF instance corresponding to a range of User Equipment Routing Indicator (RID). The request also includes a routing identifier (RID) associated with the specific user; The method further includes: selecting an AAnF instance based on the received RID; and The generation of the security key Kaf, which is specific to the application session, is performed by the selected AAnF instance.

17. The method according to any one of claims 15 to 16, wherein, The second identifier is the contract permanent identifier SUPI.

18. The method according to any one of claims 15 to 16, wherein: The key management server is associated with one or more ranges of User Equipment Routing Indicator (RID); as well as The method further includes: registering the association between the key management server and the one or more scopes with the Network Repository Function (NRF) in the communication network.

19. A method performed by an authentication server function (AUSF) in a communication network, the method comprising: The anchor function AAnF in the communication network, used for application authentication and key management, receives a request for a non-application-specific anchor security key Kakma for a specific user, wherein the request includes a first representation of the following: The first identifier KakmaID associated with the non-application-specific anchor security key Kakma, and A second identifier associated with the network subscription of the specific user; and Send a response to the AAnF including the requested non-application-specific anchor security key Kakma; Specifically, AAnF is configured to derive a security key Kaf specific to the application session of the particular user, based on the requested non-application-specific anchor security key Kakma.

20. The method of claim 19, further comprising: Create the non-application-specific anchor security key Kakma and the associated first identifier KakmaID; as well as Send a second representation of the fourth identifier AUSFID and at least the first identifier KakmaID associated with the AUSF to the Unified Data Management (UDM) entity in the communication network.

21. The method of claim 20, wherein: The first and second representations include a third identifier, B-ID, which binds the non-application-specific anchor security key Kakma to the AUSF that generated Kakma; as well as The third identifier includes: The representation of the first identifier and the second identifier, and Information associated with the AUSF.

22. The method according to claim 21, wherein, The information associated with the AUSF includes one or more of the following: AUSF group ID, AUSF ID, Subscribed Permanent Identifier (SUPI) range, Fully Qualified Domain Name (FQDN), and IP address.

23. The method according to claim 21, wherein, The response also includes a subscription permanent identifier (SUPI) associated with the specific user.

24. The method of claim 20, wherein: The second representation includes the first identifier; and The first representation includes the first identifier and the second identifier.

25. The method according to any one of claims 19 to 24, wherein, The second identifier includes one of the following: HPLMN ID and User Equipment Routing Identifier (RID); The hidden identifier SUCI is a contractual agreement. The permanent identifier SUPI is signed; or General Public Contract Identifier (GPSI).

26. A method performed by an authentication server function (AUSF) in a communication network, the method comprising: Create a non-application-specific anchor security key, Kakma, for a specific user, wherein the non-application-specific anchor security key is associated with a first identifier, KakmaID; and Based on a second identifier associated with the network subscription of the specific user, select an anchor function AAnF for application authentication and key management associated with the specific user in the communication network; Specifically, AAnF is configured to derive a security key Kaf specific to the application session of the particular user, based on the requested non-application-specific anchor security key Kakma.

27. The method of claim 26, further comprising: Send the following information to the identified AAnF: The non-application-specific anchor security key Kakma used for the specific user. The first identifier, KakmaID, and The second identifier associated with the network subscription of the specific user.

28. A method performed by a Unified Data Management (UDM) entity in a communication network, the method comprising: The authentication server function AUSF in the communication network receives a fourth identifier AUSFID associated with the AUSF and a first identifier KakmaID associated with the non-application-specific anchor security key Kakma for a specific user; Receive a request for the fourth identifier from the anchor function AAnF in the communication network used for application authentication and key management; as well as Send a response including the fourth identifier to the AAnF.

29. The method according to claim 28, wherein: The request includes the first identifier; and The response also includes a second identifier related to the network subscription associated with the specific user.

30. The method according to claim 29, wherein, The first identifier, KakmaID, includes a representation of the second identifier.

31. The method according to claim 29, wherein: The request includes another second identifier related to the network subscription associated with the specific user; as well as The method further includes: determining the second identifier based on the other second identifier.

32. The method according to claim 31, wherein: The second identifier is the subscription permanent identifier SUPI; and The other second identifier is an identifier that is different from SUPI.

33. The method according to any one of claims 29 to 32, wherein: The AUSF includes multiple AUSF instances, each AUSF instance corresponding to a range of identifiers associated with a network subscription; The method further includes: selecting a specific AUSF instance based on the second identifier; and The fourth identifier corresponds to the selected AUSF instance.

34. A key management server in a communication network, the key management server comprising: An interface circuit is configured to communicate at least with the application functions and authentication server functions AUSF in the communication network. as well as A processing circuit operatively coupled to the interface circuit, wherein the processing circuit and the interface circuit are configured to perform operations corresponding to the method according to any one of claims 1 to 18.

35. A key management server in a communication network, the key management server being configured to perform operations corresponding to the method according to any one of claims 1 to 18.

36. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by processing circuitry associated with a key management server in a communication network, configure the key management server to perform operations corresponding to the method according to any one of claims 1 to 18.

37. A computer program product comprising computer-executable instructions, which, when executed by processing circuitry associated with a key management server in a communication network, configure the key management server to perform operations corresponding to the method according to any one of claims 1 to 18.

38. An Authentication Server Function (AUSF) in a communication network, the AUSF comprising: An interface circuit is configured to communicate at least with the key management server and the unified data management UDM entity in the communication network, as well as with user equipment. as well as A processing circuit operatively coupled to the interface circuit, wherein the processing circuit and the interface circuit are configured to perform operations corresponding to the method according to any one of claims 19 to 27.

39. An authentication server function (AUSF) in a communication network, the AUSF being configured to perform operations corresponding to the method according to any one of claims 19 to 27.

40. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by processing circuitry associated with an authentication server function (AUSF) in a communication network, configure the AUSF to perform operations corresponding to the method according to any one of claims 19 to 27.

41. A computer program product comprising computer-executable instructions, which, when executed by processing circuitry associated with an authentication server function (AUSF) in a communication network, configure the AUSF to perform operations corresponding to the method according to any one of claims 19 to 27.

42. A unified data management (UDM) entity in a communication network, the UDM entity comprising: An interface circuit is configured to communicate at least with the key management server and authentication server functions AUSF in the communication network; as well as A processing circuit operatively coupled to the interface circuit, wherein the processing circuit and the interface circuit are configured to perform operations corresponding to the method according to any one of claims 28 to 33.

43. A unified data management (UDM) entity in a communication network, the UDM entity being configured to perform operations corresponding to the method according to any one of claims 28 to 33.

44. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by processing circuitry associated with a unified data management (UDM) entity in a communication network, configure the UDM entity to perform operations corresponding to the method according to any one of claims 28 to 33.

45. A computer program product including computer-executable instructions, which, when executed by processing circuitry associated with a unified data management (UDM) entity in a communication network, configure the UDM entity to perform operations corresponding to the method according to any one of claims 28 to 33.

Images