SELECTION OF AUTHENTICATION SERVER ROLE IN AUTHENTICATION AND KEY MANAGEMENT

Abstract

The methods include those carried out by a key management node in a communication network. These methods may include receiving, from an application function, a request for a security key 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 of a non-application-specific anchor security key and a second identifier related to a network subscription. These methods may also include, based on the representation, determining an authentication server function that generated the non-application-specific anchor security key. Other methods include complementary methods carried out by application functions, authentication server functions, and unified data management functions in the communication network.Other modalities include network nodes configured to carry out such methods.

Description

SELECTING THE AUTHENTICATION SERVER ROLE IN AUTHENTICATION AND KEY MANAGEMENT TECHNICAL FIELD This application relates generally to the field of communication networks and more specifically to authentication and key management techniques in relation to the secure use of applications on a communication network. BACKGROUND Long-Term Evolution (LTE) is an umbrella term for so-called fourth-generation (4G) radio access technologies developed within the Third Generation Partnership Project (3GPP) and initially standardized in versions 8 and 9, also known as Evolved UTRAN (E-UTRAN). LTE targets several licensed frequency bands and is accompanied by improvements in non-radio aspects commonly referred to as System Architecture Evolution (SAE), which includes the Evolved Packet Core (EPC). LTE continues to evolve through subsequent versions.One of the features of version 11 is an 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. Figure 1 shows an example of a general network architecture comprising LTE and SAE. E-UTRAN 100 includes one or more evolved Node Bs (eNBs), such as eNBs 105, 110, and 115, and one or more user equipment (UEs), such as UE 120. As used within the 3GPP standards, user equipment or UE means any wireless communication device (e.g., a smartphone or computing device) that is capable of communicating with network equipment compliant with the 3GPP standard, including EUTRAN as well as UTRAN and / or GERAN, as the third-generation (3G) and second-generation (2G) 3GPP radio access networks are commonly known. As specified by 3GPP, E-UTRAN 100 is responsible for all radio-related functions in the network, including radio carrier control, radio admission control, radio mobility control, scheduling and dynamic allocation of resources to UEs in uplink and downlink, as well as UE communications security. These functions reside in the eNBs, such as eNBs 105, 110, and 115. The EUTRAN eNBs communicate with each other via interface XI, as shown in Figure 1. The eNBs are also responsible for the E-UTRAN interface to EPC 130, specifically interface SI to the Mobility Management Entity (MME) and Service Gateway (SGW), which are collectively shown as MME / S-GW 134 and 138 in Figure 1. In general terms, the MME / S-GW handles both overall UE control and the data flow between the UE and the rest of the EPC.More specifically, the MME processes signaling protocols (e.g., control plane) between the UE and the EPC, which are known as non-accessible layer protocols (NAS). 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 carriers when the UE moves between eNBs, such as eNBs 105, 110, and 115. The EPC 130 can also include a Home Subscriber Server (HSS) 131, which manages user and subscriber-related information. The HSS 131 can also provide support functions for mobility management, call and session configuration, user authentication, and access authorization. The functions of the HSS 131 can be related to the functions or operations inherited from the Home Location Registry (HLR) and the Authentication Center (AuC). In some configurations, HSS 131 can communicate with a user data repository (UDR), labeled EPCUDR 135 in Figure 1, via a Ud interface. EPCUDR 135 can store user credentials after they have been encrypted using AuC algorithms. These algorithms are not standardized (i.e., vendor-specific), so the encrypted credentials stored in EPCUDR 135 are inaccessible to any vendor other than the HSS 131 vendor. In 3GPP, a study element on a new radio interface for a fifth-generation (5G) cellular (i.e., wireless) network was completed, and 3GPP is now standardizing this new radio interface, often abbreviated as NR (New Radio). Figure 2 illustrates a high-level view of the 5G network architecture, which consists of a Next-Generation RAN (NG-RAN) 299 and a 5G Core (5GC) 298. NG-RAN 299 may include a set of gNodesB (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs 200 and 250 connected via interfaces 202 and 252, respectively. Furthermore, the gNBs can be connected to each other via one or more Xn interfaces, such as the Xn 240 interface between the gNBs 200 and 250. Regarding the NR interface to the UEs, each of the gNBs can support frequency division duplexing (FDD), time division duplexing (TDD), or a combination of both. NG-RAN 299 is divided into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture—that is, the logical NG-RAN nodes and the interfaces between them—is defined as part of the RNL. The associated TNL protocol and functionality are specified for each NG-RAN interface (NG, Xn, Fl). The TNL provides user plane transport and signaling transport services. In some example configurations, each gNB is connected to all 5GC nodes within an AMF region, which is defined in 3GPP TS 23.501. If security protection for CP and UP data is supported in the TNL of NG-RAN interfaces, NDS / IP (3GPP TS 33.401) will apply. The logical nodes of NG RAN shown in Figure 2 (and described in 3GPP TS 38.401 and 3GPP TR 38.801) include 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 and 230. The CUs (e.g., gNB-CU 210) are logical nodes that host upper-layer protocols and perform various gNB functions, such as controlling the operation of the DUs. Each DU is a logical node that hosts lower-layer protocols and may include, depending on the functional division, several subsets of gNB functions. In this way, each of the CUs and DUs can include several circuits necessary to carry out their respective functions, including processing circuits, transceiver circuits (for example, for communication) and power supply circuits.Furthermore, the terms central unit and centralized unit are used interchangeably in this document, as are the terms distributed unit and decentralized unit. A gNB-CU connects to the gNB-DUs via their respective Fl logical interfaces, such as interfaces 222 and 232 shown in Figure 3. The connected gNB-CU and gNB-DUs are only visible to other gNBs and the 5GC as a gNB. In other words, the Fl interface is not visible beyond the gNB-CU. Figure 3 shows a high-level view of an example 5G network architecture, which includes a Next Generation Radio Access Network (NG-RAN) 399 and a 5G Core (5GC) 398. As shown in the figure, NG-RAN 399 may include gNBs 310 (e.g., 310a,b) and ng-eNBs 320 (e.g., 320a,b) that are interconnected with each other through their respective Xn interfaces. The gNBs and ng-eNBs are also connected via NG interfaces to 5GC 398, more specifically to the AMF (Access and Mobility Management Function) 330 (e.g., AMFs 330a,b) via the respective NG-C interfaces and the UPF (User Plane Function) 340 (e.g., UPFs 340a,b) via the respective NG-U interfaces. In addition, the AMFs 340a,b can communicate with one or more Policy Control Functions (PCFs, e.g., PCFs 350a,b) and network exposure functions (NEFs, e.g., NEFs 360a,b).AMFs, UPFs, PCFs and NEFs are described below. Each of the gNBs 310 can support the NR radio interface, including frequency division mirroring (FDD), time division mirroring (TDD), or a combination thereof. In contrast, each of the ng-eNBs 320 supports the LTE radio interface but, unlike conventional LTE eNBs (as shown in Figure 1), connects to the 5GC via the NG interface. Implementations 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 network (e.g., PLMN). Generally, a UE that supports 5GC NAS procedures is assumed to also support EPC NAS procedures (e.g., as defined in 3GPP TS 24.301) when operating on legacy networks, such as during roaming. Thus, the UE will use either EPC NAS or 5GC NAS procedures depending on the core network (CN) through which it is served. Another change in 5G networks (for example, in 5GC) is that traditional peer-to-peer interfaces and protocols (for example, those found in LTE / EPC networks) are replaced by a service-based architecture (SBA) in which network functions (NFs) provide one or more services to one or more service consumers. This can be done, for example, through application programming interfaces (APIs) of the Hypertext Transfer Protocol / Representational State Transfer (HTTP / REST). In general, the various services are independent functionalities that can be changed and modified in isolation without affecting other services. 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 the request / response or subscription / notification type. In 5G SBA, Network Repository Functions (NRFs) allow each network function to discover the services offered by other network functions, and Data Storage Functions (DSFs) allow each network function to store its context. As discussed previously, services can be implemented as part of a network function (NF) in a 5G SBA. This SBA model, which further adopts principles such as coreness, reusability, and self-containment of NFs, can enable implementations to leverage the latest virtualization and software technologies. Figure 4 shows an example of a 5G non-roaming reference architecture with service-based interfaces and several 3GPP-defined NFs within the control plane (CP). These include the following NFs, with additional details provided for those most relevant to the present invention: • Access and Mobility Management (AMF) function with Namf interface: terminates the RAN CP interface and handles all UE connection and mobility management (similar to MME in EPC). • 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 the session context with the user plane function (UPF), for example, for event notification. • User plane function (UPF) with Nupf interface: Supports handling user plane traffic based on rules received from SMF, including packet inspection and various compliance actions (e.g., event detection and notification). • Policy Control Function (PCF) with Npcf interface: Supports a unified policy framework to govern network behavior, for example, by providing PCC rules to the SMF. inaLa / a / zuzz / ui • Network Exposure Function (NEF) with Nnef interface: Acts as the entry point to the operator's network, securely exposing AFs to network capabilities and events provided by 3GPP NFs and providing ways for AFs to securely provide information to the 3GPP network. • Network Repository Function (NRF) with Nnrf interface: Provides service registration and discovery, enabling NFs to identify appropriate services available from other NFs. • Network Segment Selection Function (NSSF) with Nnssf interface: A network segment is a logical partition of a 5G network that provides specific network capabilities and characteristics, for example, in support of a particular service. A network segment instance is a set of NF instances and the necessary network resources (e.g., compute, storage, communication) that provide the capabilities and characteristics of the network segment. The NSSF allows other NFs (e.g., AMF) to identify a network segment instance that is appropriate for a UE's desired service. • Authentication server function (AUSF) with Nausf interface: Based on a user's home network (HPLMN), it performs user authentication and calculates key security materials for various purposes. inaLa / a / zuzz / ui • Application Function (AF) with Naf interface: interacts with the 3GPP CN to provide information to the network operator and to subscribe to certain events that happen on the operator's network. The Unified Data Management (UDM) function shown in Figure 4 is similar to HSS in the LTE / EPC networks discussed earlier. UDM supports the generation of 3GPP authentication credentials, user ID management, subscription database access authorization, and other subscriber-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 the storage and retrieval of policy data by PCF, as well as the storage and retrieval of application data by NEF. 3GPP Rel-16 introduces a new feature called Authentication and Key Management for Applications (AKMA), which is based on 3GPP user credentials in 5G, including for IoT use cases. More specifically, AKMA leverages the user's AKA (Authentication and Key Agreement) credentials to initiate security between the UE (Enterprise User) and an Application Function (AF), enabling the UE to securely exchange data with an application server. The AKMA architecture can be considered an evolution of GBA (Generic Boot Architecture) specified for 5GC in 3GPP Rel-15 and is further specified in 3GPP TS 33.535 (v.0.2.0, currently under review). In addition to the NEF, AUSF, and AF functions shown in Figure 4 and described above, Rel-16 AKMA also uses an anchor function for application authentication and key management (AAnF). This function is shown in Figure 4 with a Naanf interface. In general, AAnF interacts with the AUSF and maintains AKMA UE contexts that will be used for subsequent boot requests, for example, by application functions. Overall, AAnF is similar to a boot server function (BSF) defined in Rel-15 GBA. In this architecture, however, several problems, issues, and / or difficulties can arise related to synchronizing the key material generated for a user by an AUSF and the key material used by an AAnF to generate application-specific keys for the user's application sessions. These problems, issues, and / or difficulties can prevent the establishment of secure communication between a user application (e.g., running in a UE) and a corresponding application function (e.g., a server). ινΐΛ / a / zuzz / uii BRIEF DESCRIPTION OF THE INVENTION Certain embodiments of the present invention provide specific improvements to ensure communication between applications (e.g., clients) and application functions (e.g., servers), for example, by facilitating solutions to overcome the example problems summarized above and described in more detail below. Example methods include procedures performed by a key management server (e.g., AAnF) on a communication network (e.g., 5GC). These methods 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 an application-nonspecific anchor security key (Kakma) and a second identifier related to a network subscription. These example methods may also include, based on the representation, determining an authentication server function (AUSF) that generated the application-nonspecific anchor security key (Kakma). In some embodiments, these example methods may also include obtaining the application-nonspecific anchor security key (Kakma) from the specified AUSF and generating the application-session-specific security key (Kaf) based on the application-nonspecific anchor security key (Kakma). In some embodiments, these example methods may also include sending the application-session-specific security key (Kaf) to the application function. In some modes, the representation may include a third identifier (B-ID) of a link between the application-nonspecific anchoring security key (Kakma) and the AUSF that generated Kakma. The third identifier may include the representation of the first and second identifiers, and information associated with the AUSF. In several modes, 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 these modes, the determination operations may include discovering an AUSF identity through a network deposit function (NRF) based on information associated with the AUSF. Furthermore, in these modes, the retrieval operations may include sending a request to the determined AUSF that includes the third identifier (e.g., B-TID) and receiving a response from the determined AUSF that includes the application-non-specific anchoring security key (Kakma) and the second identifier. In other configurations, the representation of the first and second identifiers may include the first identifier (for example, KakmaID) and the second identifier. For example, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Hidden Subscription Identifier (SUCI); Permanent Subscription Identifier (SUPI); or Generic Public Subscription Identifier (GPSI). In one variant, the representation may include only the first identifier (for example, KakmaID), which may include a representation of the second identifier. In such modalities, the determination operations may include selecting a Unified Data Management (UDM) function on the communication network based on the second identifier; sending the UDM an initial request for a fourth identifier associated with the AUSF; and receiving an initial response from the UDM that includes the fourth identifier. In some modalities, the initial response may also include an additional second identifier related to the network subscription associated with the particular user. For example, the additional second identifier may be a SUPI, and the second identifier may be a different identifier than SUPI (e.g., GPSI, SUCI, HPLMN+RID). In these modes, the retrieval operations may include sending a second request to the AUSF associated with the fourth identifier, comprising either the second identifier or an additional second identifier related to the network subscription associated with the particular user; and receiving a second response from the AUSF, which includes the application-nonspecific anchoring security key (Kakma). In some modes, the second request or the second response may also include the second identifier. For example, if the second request includes the additional second identifier (e.g., SUPI), the second response may include the second identifier (e.g., an identifier other than SUPI). The example modalities also include other methods (e.g., procedures) carried out by a key management server (e.g., AAnF) on a communication network (e.g., 5GC). These example methods might include receiving, from an Authentication Server Function (AUSF), the following information associated with a particular user: an application-nonspecific anchor security key (Kakma); a first identifier (KakmaID) of the application-nonspecific anchor security key; and a second identifier related to a network subscription. In some modalities, the second identifier might be a permanent subscription identifier (SUPI). These example methods may also include receiving, from an application function, a request for a security key (Kaf) specific to an application session for a particular user, where the request comprises an additional identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user. The request may include an additional identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user. These example methods may also include, based on a match between the first identifier and the additional identifier (for example, matching KakmaIDs), generating the security key (Kaf) specific to the application session based on the non-application-specific anchor security key (Kakma). In some configurations, the key management server may include multiple anchoring functions for application authentication and key management (AAnF) instances, with each AAnF instance corresponding to a range of user device routing indicators (RIDs). In such configurations, the request may also include a routing indicator (RID) associated with the particular user, and these example methods may also include selecting an AAnF instance based on the received RID, where generating the specific security key (Kaf) for the application session is performed by the selected AAnF instance. In some configurations, the key management server can be associated with one or more user equipment routing indicator (RID) ranges. In such configurations, these example methods can also include registering an association between the key management server and one or more ranges with a network repository function (NRF) in the communication network. The example methods also include methods (e.g., procedures) carried out by an application function on a communication network (e.g., 5GC). These example methods might include receiving, from a user computer, an initial request to establish an application session. The initial request might 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 related to a network subscription. These example methods might also include sending, to an application authentication and key management (AAnF) anchor function on the communication network, a second request for an application-specific security key (Kaf) for the application session. The second request might include a representation of the first and second identifiers. These example methods may also include receiving the application session-specific security key (Kaf) from AAnF. In some modes, these example methods may also include establishing a secure application session with the user's computer based on the received security key (Kaf). In some modes, the representation includes a third identifier (B-ID) of a link between the application-nonspecific anchoring security key (Kakma) and the AUSF that generated Kakma. Specifically, the third identifier may include representations of the first and second identifiers, and information associated with the AUSF. In several modes, 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 other configurations, 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); Hidden Subscription Identifier (SUCI); Permanent subscription identifier (SUPI); or generic public subscription identifier (GPSI). In one variant, the representation may include only the first identifier (e.g., KakmaID), which includes a representation of the second identifier. The example methods also include methods (e.g., procedures) carried out by an Authentication Server Function (AUSF) in a communication network (e.g., 5GC). These example methods might include receiving, from an Application Authentication and Key Management Anchor Function (AAnF) in the communication network, a request for an Application Non-Specific Anchor Security Key (Kakma) for a particular user. The request might include a first representation of the following: the first identifier (KakmaID) associated with the Application Non-Specific Anchor Security Key (Kakma) and a second identifier related to a network subscription of the particular user. These example methods might also include sending a response to the AAnF that includes the requested Application Non-Specific Anchor Security Key (Kakma). In some modalities, these example methods may include creating the application-nonspecific anchor security key (Kakma) for the particular user, as well as the first identifier (KakmaID); and sending, to a unified data management (UDM) function in the communication network, a fourth identifier (AUSFID) associated with the AUSF and a second representation of at least the first identifier (KakmaID). In some modes, the first and second representations may include a third identifier (B-ID) linking the application-nonspecific anchoring security key (Kakma) to the AUSF that generated Kakma. Specifically, the third identifier may include representations of the first and second identifiers, as well as information associated with the AUSF. In several modes, 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 such modes, the response may also include a Subscription Permanent Identifier (SUPI) associated with the specific user. In other modes, the first representation of the first and second identifiers may include the first identifier (for example, KakmaID) and the second identifier, while the second representation may include only the first identifier. In such modes, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Hidden Subscription Identifier (SUCI); Permanent Subscription Identifier (SURI); or Generic Public Subscription Identifier (GPSI). In one variant, the first representation may include only the first identifier, which may include a representation of the second identifier. The example methods also include other methods (e.g., procedures) carried out by an Authentication Server Function (AUSF) on a communication network (e.g., 5GC). These example methods might include creating an application-nonspecific anchor security key (Kakma) for a particular user, where the application-nonspecific anchor security key is associated with a first identifier (KakmaID). These example methods might also include, based on a second identifier related to a particular user's network subscription, selecting an application authentication and key management (AAnF) anchor function on the communication network associated with the particular user.In some modalities, these example methods may also include sending the following information to the identified AAnF: the application-nonspecific anchoring security key (Kakma) for the particular user, the first identifier (KakmaID), and the second identifier related to the particular user's network subscription. In several modalities, the second identifier can be a permanent subscription identifier (SUPI) associated with the particular user. The example methods also include methods (e.g., procedures) carried out by a unified data management (UDM) function in a communication network (e.g., 5GC). These example methods might include receiving, from an Authentication Server Function (AUSF) in the communication network, a fourth identifier (AUSFID) associated with the AUSF and a first identifier (KakmaID) associated with an application-nonspecific anchor security key (Kakma) for a particular user. These example methods might also include receiving, from an Application Authentication and Key Management (AAnF) anchor function in the communication network, a request for the fourth identifier. These example methods might also include sending a response to the AAnF that includes the fourth identifier. In some modes, the request may include the first identifier (KakmaID), and the response may include a second identifier related to a network subscription associated with the particular user. In some of these modes, the first identifier may include a representation of the second identifier. In another mode, the request may include yet another second identifier related to the network subscription associated with the particular user. In such modes, these example methods may also include determining the second identifier based on the additional second identifier. For example, the second identifier may be a permanent subscription identifier (SUPI), and the additional second identifier may be an identifier other than SUPI (e.g., SUCI, GPSI). In several configurations, the AUSF may include multiple AUSF instances, with each AUSF instance corresponding to a range of identifiers associated with network subscriptions (e.g., RID, SUPI, etc.). In such configurations, these example methods may also include selecting a particular AUSF instance based on the second identifier. In such configurations, the fourth identifier may correspond to the selected AUSF instance. The example modalities also include key management servers (e.g., AAnF), application functions, authentication server functions (AUSF), and unified data management (UDM) functions on a communication network (e.g., 5GC) that are configured to perform operations (e.g., using processing circuits) corresponding to any of the example methods described in this document. The example modalities also include non-transient computer-readable media that store computer-executable instructions that, when executed by processing circuits associated with such key management servers, application functions, AUSF functions, and UDMs, configure them to perform operations corresponding to any of the example methods described in this document. These and other objects, features and advantages of the embodiments of the present invention will become evident upon reading the following detailed description in view of the drawings briefly described below. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a high-level block diagram of an example architecture of the Evolved UTRAN (E-UTRAN) and Evolved Packet Core (EPC) of Long-Term Evolution (LTE), as standardized by 3GPP. Figures 2 and 3 illustrate two different high-level views of a 5G network architecture. Figure 4 shows an example of non-roaming 5G reference architectures with service-based interfaces and multiple network functions (NF) in a core network, as described in more detail in 3GPP TS 23.501 (vl6.1.0). Figure 5 is a block diagram illustrating an example of an application key management and authentication (AKMA) key hierarchy. Figure 6 is a flowchart that illustrates an example procedure for setting up a secure application session between a user computer (UC) and an application function (AF). Figure 7 shows an example of a generic boot architecture (GBA) for authentication and key agreement (AKA) for application security. Figure 8 is a flowchart illustrating an example procedure for delivering UE parameter updates (UPU) from a unified data management (UDM) function in a 5GC. Figures 9-13 are flowcharts of various example procedures involving the selection of the Authentication Server Function (AUSF) during application session establishment, according to various example modalities of the present invention. Figures 14-15 illustrate several example methods (e.g., procedures) carried out by an authentication and key management server (e.g., AAnF) on a communication network (e.g., 5GC), according to several example embodiments of the present invention. Figure 16 illustrates an example method (e.g., procedure) carried out by an application function (AF) in a communication network (e.g., 5GC), according to various example embodiments of the present invention. Figures 17-18 illustrate several example methods (e.g., procedures) carried out by an Authentication Server Function (AUSF) on a communication network (e.g., 5GC), according to several example embodiments of the present invention. Figure 19 illustrates an example method (e.g., procedure) carried out by the unified data management (UDM) function in a communication network (e.g., 5GC), according to various example embodiments of the present invention. Figure 20 illustrates an example modality of a wireless network, according to several example modality of the present invention. Figure 21 illustrates an example embodiment of a UE, according to several example embodiments of the present invention. Figure 22 is a block diagram illustrating a sample virtualization environment usable for the implementation of various modalities described in this document. Figures 23-24 are block diagrams of various example communication systems and / or networks, according to various example modalities of the present invention. Figures 25-28 are flowcharts of example methods and / or procedures for the transmission and / or reception of user data, according to various example modalities of the present invention. DETAILED DESCRIPTION Some of the modalities covered in this document will now be described in more detail with reference to the accompanying drawings. However, while other modalities are contained within the scope of the subject matter disclosed herein, the subject matter disclosed should not be interpreted as being limited solely to the modalities set forth in this document; rather, these modalities are provided as examples to convey the scope of the subject matter to those skilled in the art. In general, all terms used in this document should be interpreted according to their current meaning in the relevant technical field, unless a different meaning is clearly given and / or implied by the context in which they are used. All references to an element, apparatus, component, means, step, etc. These terms should be interpreted openly as references to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of the methods and / or procedures described herein do not have to be carried out in the exact order described, unless a step is explicitly described as following or preceding another step and / or where it is implied that one step must follow or precede another. Any feature of any of the modalities described herein may be applied to any other modality, where appropriate. Likewise, any advantage of any modality may be applied to any other modality, and vice versa. Other objectives, features, and advantages of the attached modalities will become apparent from the following description. In addition, the following terms are used throughout the description provided below: • Radio node: As used in this document, a radio node can be a radio access node or a wireless device. • Radio access node: As used in this document, a radio access node (or equivalently, radio network node, radio access network node, or RAN node) can be any node in a radio access network (RAN) of a cellular communications network that functions to wirelessly transmit and / or receive signals. Examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) (gNB) base station in a 3GPP fifth-generation (5G) NR network or an enhanced or evolved (eNB) Node B in a 3GPP LTE network), distributed base station components (e.g., CU and DU), a macro or high-power base station, a low-power base station (e.g., micro, pico, femto, or home base station, or similar), an integrated access backend (IAB) node, a transmit point, a remote radio unit (RRU or RRH), and a relay node. • Core network node: As used herein, a core network node is any type of node in a core network. Examples of a core network node include, for instance, an AME, a user plane function (UPE), a service capacity exposure function (SCEF), or similar. • Wireless Device: As used herein, a wireless device (or WD for short) is any type of device that has access to (i.e., is served by) a cellular communications network by communicating wirelessly with network nodes and / or other wireless devices. Wireless communication may involve the transmission and / or reception of wireless signals by means of electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information through the air. Unless otherwise specified, the term wireless device is used interchangeably herein with user equipment (or UE for short).Some examples of a wireless device include, but are not limited to, smartphones, mobile phones, cell phones, Voice over IP (VoIP) phones, cordless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable devices, wireless terminals, mobile stations, tablets, laptops, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, customer premises wireless equipment (CPE), mobile-type communication (MTC) devices, Internet of Things (IoT) devices, vehicle-mounted wireless terminal devices, etc. • Network node: As used herein, a network node is any node that is part of the radio access network (e.g., a radio access node or the equivalent name discussed above) or the core network (e.g., a core network node discussed above) of a cellular communications network. Functionally, a network node is equipment capable, configured, arranged, and / or operable to communicate directly or indirectly with a wireless device and / or other network nodes or equipment in the cellular communications network, to enable and / or provide wireless access to the wireless device, and / or to perform other functions (e.g., management) in the cellular communications network. It should be noted that the description provided in this document focuses on a 3GPP cellular communications system and, as such, often uses 3GPP terminology or terminology similar to 3GPP terminology. However, the concepts presented here are not limited to a 3GPP system. Furthermore, although the term "cell" is used in this document, it should be understood that (particularly with regard to 5G NR) "beams" can be used instead of "cells," and thus the concepts described here apply equally to both cells and beams. In the present invention, the term "service" is generally used to refer to a set of data, associated with one or more applications, that will be transferred over a network with certain specific delivery requirements that must be met for the successful operation of the applications. In the present invention, the term "component" is generally used to refer to any component necessary for the provision of the service. Examples of components are RANs (e.g., E-UTRAN, NG-RAN, or portions thereof, such as eNBs, gNBs, base stations (BS), etc.), CNs (e.g., EPC, 5GC, or portions thereof, including all types of links between RAN and CN entities), and cloud infrastructure with related resources, such as computing and storage.In general, each component can have an administrator, a term that is generally used to refer to an entity that can collect historical information about resource utilization, as well as provide information about the current and anticipated future availability of resources associated with that component (e.g., a RAN administrator). As briefly mentioned earlier, in the Rel-16 AKMA architecture, there can be several issues and difficulties related to synchronizing the key material generated for a user by an AUSF with the key material used by an AAnF to generate application-specific information keys for the user's application sessions. These issues and difficulties can prevent the establishment of secure communication between a user application (e.g., running in a UE) and a corresponding application function (e.g., a server). This is discussed in more detail below. In general, ARMA reuses the output of the primary 5G authentication procedure used to authenticate a UE during network registration (also known as implicit boot). In this procedure, the AUSF is responsible for generating and storing the key material. Specifically, the key hierarchy in ΆΚΜΆ includes the following, which are illustrated in more detail in Figure 5: • Kausf: root key, output of the main authentication procedure and stored in UE (i.e., mobile device, ME, party) and AUSF. Additionally, AUSF can report the result and the particular instance of AUSF that Kausf generates as the output of the main authentication result in UDM, as defined in TS33.501. • Kakma: anchor key derived by ME and AUSF from Kausf and used by AAnF to generate more AKMA key material. The key identifier KakmaID identifies Kakma. • Kaf: application key derived by ME and AAnF from KAKMA and used by UE and the application to securely exchange application data. Figure 6 is a flowchart illustrating a sample procedure for establishing a secure application session between a UE and an AF, based on the key hierarchy listed above. Initially, the UE and the AUSF perform primary authentication and establish the Kakma key, which is stored in both the UE and the AUSF. Subsequently, the UE sends an application session establishment request to the AF, which includes the KakmaID. The AF then sends the received KakmaID along with an AF identifier to the AAnF, which responds with the Kakma corresponding to the provided KakmalD. The AAnF derives the Kaf from the Kakma and provides the Kaf to the AF along with a Kaf expiration time. The AF can then use the received Kaf to establish a secure application session with the UE. As briefly mentioned earlier, Generic Boot Architecture (GBA) was introduced in 3GPP Rel-15 (e.g., 3GPP TS 33.220 vl5.4.0) for boot authentication and key agreement (AKA) for application security. In other words, GBA allows AFs on the network and user side to establish shared keys. Figure 7 shows an example of GBA for AKA according to the 3GPP specifications. In GBA, mutual authentication takes place between the UE and the BSF, and boot key material is also derived between the UE and the BSF. The BSF also generates a BTID (Boot Transaction Identifier) ​​for each boot transaction that derives key material from GBA. The bootable GBA key material is then used for secure UE access to Network Application Functions (NAFs). When the UE initiates communication with an AF, it includes B-TID in the message. The AF then requests an application-specific key from BSF using B-TID as input. BSF locates the GBA key material corresponding to B-TID, obtains the application-specific key, and provides it to the AF. Secure communication is then established between the UE and AF based on the application-specific key. To enable a Network Facility (NF) to discover and select a suitable AUSF or UDM instance to handle traffic, 3GPP TS 23.501 defines input parameters that can be used for AUSF or UDM discovery (for example, via NRF). Relevant excerpts from 3GPP TS 23.501 are provided below. The following UE-related identifier abbreviations are used in the exception: • Permanent subscription identifier (SUPI), • Hidden subscription identifier (SUCI), and • Generic public subscription identifier (GPSI). * ** Start of 3GPP extract TS 23.501 *** The AUSF selection function on AUSF NF or SCP consumers must consider one of the following factors when available: 1. SUCI / SUPI local network identifier (e.g., MNC and MCC) (by an NF consumer on the service PLMN) and routing indicator. NOTE 1: The UE provides the Routing Indicator to the AME as part of the SUCI as defined in TS 23.003

[19] during initial registration. The AME may provide the UE's Routing Indicator to other AMFs as described in TS 23.502 [3]. When the UE routing flag is set to its default value as defined in TS 23.003

[19] , the AUSF NF consumer can select any AUSF instance within the home network for the UE. 2. ID of the AUSF Group to which the EU SUPI belongs. NOTE 2: The AME can infer the AUSF group ID to which the UE's SUPI belongs, based on the results of AUSF discovery procedures using NRF. The AME provides the AUSF group ID to which the SUPI belongs to other AMFs, as described in TS 23.502 [3]. 3. SUPI; for example, the AME selects an AUSF instance based on the SUPI range to which the UE's SUPI belongs or based on the results of a discovery procedure with NRF using the UE's SUPI as input for AUSF discovery. The UDM selection functionality in the NF consumer or in SCP must consider one of the following factors: 1. SUCI / SUPI local network identifier (e.g., MNC and MCC) and UE routing indicator. NOTE 1: The UE provides the Routing Indicator to the AMF as part of the SUCI as defined in TS 23.003

[19] during initial registration. The AMF provides the UE's Routing Indicator to other NF (from UDM) consumers as described in TS 23.502 [3]. When the UE 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 SUCI / SUPI home network. 2. UE SUPI UDM Group ID. NOTE 2: The AMF can infer the UDM group ID to which the EU's SUPI belongs, based on the results of NRF UDM discovery procedures. The AMF provides the UDM group ID to which the SUPI belongs to other NF UDM consumers as described in 3GPP TS 23.502. 3. SUPI: The UDM NF consumer selects a UDM instance according to the SUPI range to which the UE's SUPI belongs or according to the results of a discovery procedure with NRF using the UE's SUPI as input for UDM discovery. 4. GPSI or External Group ID: UDM NF consumers that manage non-SUPI / SUCI-based network signaling (e.g., NEF) select a UDM instance based on the GPSI or External Group ID range to which the UE's GPSI or External Group ID belongs, or based on the results of an NRF discovery procedure using the UE's GPSI or External Group ID as input for UDM discovery. *** End of 3GPP TS 23.501 statement *** In addition, 3GPP TS 23.502 defines a procedure for delivering UE parameter update data from the UDM to the UE using Non-Access Stratum Signaling (NAS) after the UE has successfully registered with the 5GC. Figure 8 is a flowchart illustrating a sample procedure for delivering UE parameter updates (UPUs) from a UDM to a 5GC. The UDM update data that the UDM delivers to the UE can contain any of the following: • one or more EU parameters that include: or NSSAI configured by default updated (the final consumer of the parameter is the ME). or Updated routing indicator data (the final consumer of the parameter is the USIM). • an indication of receipt of EU ινΐΛ / a / zuzz / uii requested. • an indication of requested re-registration. In addition, 3GPP TS 33.501 defines a similar function called the roaming security mechanism address to support the delivery of an address information list to a UE from the UE's HPLMN. Returning to the key hierarchy shown in Figure 5, 3GPP TS 33.501 defines the generation and storage of the Kausf in the AUSF and UE after each primary authentication procedure. However, 3GPP TS 33.501 does not specify when the AUSF and / or the UE delete or overwrite the Kausf, which is the implicitly agreed-upon root key used by the UE and AUSF to derive Kakma. Thus, it is possible for different instances of the AUSF to be used to authenticate the user over time. In particular, different instances of the AUSF can generate and store Kausfs for their respective authentications, but only one instance of the AUSF contains the most recent Kausf for a given UE (which also contains the most recent Kausf). This can lead to various problems, issues, and / or difficulties. As an example, Kakma and KakmaID are generated separately in the UE and AUSF according to Kausf. In this way, the UE does not obtain the identity of a particular AUSF (e.g., AUSF ID) that generates and stores Kakma during primary authentication, so the KakmaID generated by the UE cannot contain any reference to the AUSF ID. Consequently, even if the UE provides a KakmaID when the UE attempts to establish a secure application session with the AF (e.g., in Figure 6), the AF (or more specifically, an AAnF associated with the AF) does not know the appropriate AUSF instance that generated and maintains Kakma associated with the received KakmaID. Note that even if AAnF is located alongside AUSF, it is still unclear how the AF and / or the intermediate NEF deployed between AF and AAnF can discover and select the embedded AUSF / AAnF based on the KakmaID received from the UE. As another example, Kakma is generated in AUSF and AAnF obtains it to derive Kaf. There could be several Kausf generated for the UE by different AUSF instances during different primary authentication procedures. Furthermore, each of these AUSF instances could generate and store a different Kakma / KakmaID for the UE based on the corresponding Kausf. Without any specified removal / delete procedures, different Kakma / KakmaIDs can be stored in different AUSF instances, with only one corresponding to the Kakma / KakmaID stored in the UE. In general, an agreement between the UE and the network is required to use the latest Kakma. However, in some exceptional cases, the key materials stored in the UE and on the network may not be synchronized. For example, a new version of Kausf and Kakma may be generated and stored in the UE, but the new version of Kausf and Kakma has not yet been generated or stored on the network. In such a case, the KakmaID received from the UE during the AKMA session setup could refer to a Kakma that does not yet exist on the network side. The example embodiments of the present invention address these and other problems, issues and / or difficulties by providing techniques that facilitate the selection of the AUSF instance that stores Kakma referenced by the KakmaID provided by the UE at the start of an AKMA procedure with an AF. Some embodiments of the present invention can leverage the UDM detection and selection techniques used in primary authentication based on an identifier related to a network subscription associated with the UE. For example, the identifier can be any relevant identifier available in the UE, including the HPLMN ID plus the UE's routing indicator (R-ID), SUCI, SUPI, or GPSI. The UE can provide the identifier to the AF as part of, or separate from, the KakmaID in a request to establish an application session. Once a suitable UDM is located that can handle the UE's request based on the identifier, the AAnF (or NEF / AF) obtains the identity of the AUSF that stores the UDM's most recent Kakma through a new service operation, for example, Nudm_UEAuthentication_ResultStatus. The AAnF can then obtain the most recent Kakma from the identified AUSF and generate Kaf based on the obtained Kakma. Other embodiments of the present invention may leverage existing UE parameter update (UPU) techniques to deliver explicit linking information between Kakma and the AUSF ID containing Kausf / Kakma that the UE is currently using. Although the AKMA key material is generated implicitly and independently on the network and UE sides, the UE and the network may have an explicit linking procedure to agree on version synchronization (Kausf, Kakma) and the reference to the AUSF ID. More specifically, the UE can obtain the binding information from the UDM and provide it to AF in a request to establish an application session. The AAnF can then use the binding information to locate the associated AUSF ID (i.e., the AUSF stores the most recent Kakma for the UE), similar to the BSF discovery procedure for GBA. Note that if the AAnF is located alongside the AUSF, the binding information is also associated with the AAnF, which is similar to BSF binding in GBA. Other embodiments of the present invention can leverage NRF registration procedures to register the AAnF according to a range of routing identifiers (RIDs), which the AUSF can later discover via NRF. When the AUSF creates a Kakma for a particular UE corresponding to the registered RIDs, the AUSF can send the Kakma / KakmaID to the previously discovered AAnF. In this way, the AAnF already has the necessary Kakma to generate Kaf when requested by an AF. Figures 9-11 are flowcharts of various example procedures involving the selection of the Authentication Support Function (AUSF) during application session establishment, according to various example embodiments of the present invention. In particular, the embodiments illustrated in Figures 9-11 leverage the UDM selection and discovery techniques used in primary authentication based on an identifier related to a network subscription associated with the UE. Specifically, Figures 9-11 illustrate procedures based on HPLMN ID plus UE routing indicator, SUCI / SUPI, and GPSI, respectively. Each of Figures 9-11 involves several messages and operations that include a UE 910, AMF 920, one or more instances of AUSF 930 (e.g., 930a, 930b, etc.), UDM / UDR 940, one or more instances of AAnF 950 (e.g., 950a, 950b, etc.), and an AAPF (or AF) 960. For brevity, these entities will be referred to without reference numbers in the following description. Furthermore, although Figures 9-11 show numbered operations, these numbers are used to facilitate the description of the procedures and do not require or imply a particular order of operations. In other words, the operations shown in Figures 9-11 can be performed in a different order than shown, and can be combined and / or split into operations different from the one shown. In operation 0 of Figure 9, the UE performs primary authentication with the network. Kakma and KakmaID are generated and stored in the UE and AUSF. The AUSF calls the existing service operation Nudm_UEAuthentication_ResultConfirmation to inform the UDM about the authentication result, including SUPI, AUSF ID, service network name, authentication type, and timestamp information. Additionally, the AUSF provides the KakmaID generated during primary authentication. The UDM then stores all the information together. In operation 1, the UE initiates an application session establishment procedure with the AF. The UE includes the KakmaID and the local network identifier (HPLMN ID, for example, mobile network code / mobile country code, MNC / MCC) and the UE's RID. The HPLMN ID and RID can be included within the KakmaID or as a separate identifier in the message. In operations 2-3, the AF selects AAnF based on the HPLM ID and sends the selected AAnF a request for Kaf to use in the application session with the UE. The request includes AF ID, KakmaID, and HPLMN ID + RID. Operation 4 involves the discovery and selection of the Authentication Unit (AUSF) by the Authentication Authority (AAnF). In operation 4a, the AAnF discovers and selects the Unit Domain Manager (UDM) based on the Registry Identification Number (RID) received from the Authentication Authority (AF). In operation 4b, the AAnF calls a new service operation, Nudm_UEAuthentication_ResultStatus, to send a request to the selected UDM, including the KakmaID in the request. The UDM uses the KakmaID to discover and select the AUSF instance based on the information stored during operation 0. In operation 4c, the UDM returns the SUPI and AUSF IDs to the requesting AAnF. In operation 4d, the AAnF discovers and selects the AUSF based on the AUSF ID received from the UDM. In operation 5, the AAnF calls a Nausf AKMAKey Get service operation to send a request to the selected AUSF for Kakma, including SUPI and KakmaID in the request. In operation 6, the AUSF returns Kakma to the AAnF. In operations 7-8, the AAnF generates Kaf based on the Kakma received from the AUSF and provides Kaf to the AF. In operation 9, the AF establishes the secure application session with the UE based on the Kaf received in operation 8. Figure 10 shows operations similar to those in Figure 9, but based on a different identifier, namely SUCI or SUPI instead of HPLMN ID+RID. Operation 0 is identical to operation 0 in Figure 9. In the operation 1. The UE initiates an application session establishment procedure with the AF. The UE includes the KakmaID and the SUCI or SUPI. The SUCI or SUPI can be included within the KakmaID or as a separate identifier in the message. In steps 2-3, the AF selects the AAnF based on the HPLM ID associated with the SUCI or SUPI and sends the selected AAnF a request for Kaf to use in the application session with the UE. The request includes the AF ID, KakmaID, and SUCI or SUPI. Operation 4 involves the discovery and selection of the Auth Auth System (AUSF) by the Auth Auth Administrator (AAnF). In operation 4a, the AAnF discovers and selects the UDM based on the SUCI or SUPI received from the Auth Administrator (AF). In operation 4b, the AAnF calls a new service operation, Nudm_UEAuthentication_ResultStatus, to send a request to the selected UDM, including the KakmaID and either the SUCI or SUPI in the request. In operation 4c, the UDM uses the SUCI or SUPI to select the AUSF instance based on the information stored during operation 0. The UDM verifies that the KakmaID received from the AAnF is included in the authentication context stored for the UE. In operation 4d, the UDM returns the SUPI and the AUSF ID to the requesting AAnF. In operation 4e, the AAnF discovers and selects the AUSF based on the AUSF ID received from the UDM. Operations 5-9 are identical to operations 5-9 in Figure 9. ινΐΛ / a / zuzz / uii Figure 11 shows operations similar to Figures 9-10, but based on a different identifier—namely, GPSI instead of HPLMN ID+RID, SUCI, or SUPI. Operation 0 is identical to Operation 0 shown in Figures 9-10. In Operation 1, the UE initiates an application session establishment procedure with the AF. The UE includes KakmaID and GPSI. The GPSI can be included within the KakmaID or as a separate identifier in the message. In Operations 2-3, the AF selects AAnF based on the HPLM ID associated with the GPSI and sends the selected AAnF a request for Kaf to use in the application session with the UE. The request includes the AF ID, KakmaID, and GPSI. Operation 4 involves the discovery and selection of the Auth Auth System (AUSF) by the AAnF. In operation 4a, the AAnF discovers and selects the UDM based on the GPSI received from the AF. In operation 4b, the AAnF calls a new service operation, Nudm_UEAuthentication_ResultStatus, to send a request to the selected UDM, including the KakmaID and GPSI in the request. In operation 4c, the UDM translates the received GPSI to the corresponding SUPI and uses the SUPI to select the AUSF instance based on the information stored during operation 0. The UDM verifies that the KakmaID received from the AAnF is included in the stored authentication context for the UE. In operation 4d, the UDM returns the SUPI (corresponding to the GPSI) and the AUSF ID to the requesting AAnF. The provided SUPI can be used by the AAnF for subsequent key requests for the same UE, as needed or desired.In operation 4e, AAnF discovers and selects AUSF based on the AUSF ID received from the UDM. Operations 5-9 are identical to operations 5-9 in Figures 9-10. Figure 12 is a flowchart of another example procedure involving the selection of the Authentication Support Function (AUSF) during application session establishment, according to several example embodiments of the present invention. In particular, the embodiments illustrated in Figure 12 leverage existing UE parameter update (UPU) techniques to provide explicit linking information between Kakma and the AUSF ID containing Kausf / Kakma that the UE is currently using. The entities shown in Figure 12 use the same reference numbers as in Figures 9-11, which are omitted from the following description for brevity. However, the arrangement shown in Figure 12 includes an NRF 970 instead of an AME 920. Although Figure 12 shows numbered operations, these numbers are used to facilitate the description of the procedure and do not require or imply a particular order of operations. In other words, the operations shown in Figure 12 can be performed in a different order and can be combined and / or divided into operations other than the one shown. In operation 0a, the AUSF registers its specific AKMA binding information with NRF, for example, through a service operation Nnrf_NFManagement_NFRegister. The AKMA binding information may contain the AUSF GroupID, SUPI range, AUSF fully qualified domain name (FQDN), AUSF IP address, and / or AUSF ID. In some modalities, the AKMA binding information registered in operation Oa could be a hash of the aforementioned parameters, which may enhance AUSF privacy. In operation 0b, the UE performs primary authentication with the network. Kakma and KakmaID are generated and stored in the UE and AUSF. The AUSF also generates a binding identifier B-TID, which can include KakmaID, binding information from AKMA (for example, from operation 0a), and UE identifiers (for example, GPSI). The AUSF calls the existing service operation. The `Nudm_UEAuthentication` ResultConfirmation command informs UDM of the authentication result, including SUPI, AUSF ID, service network name, authentication type, and timestamp information. Additionally, AUSF provides the BTID. UDM then stores all this information together. In operation Oc, AUSF requests UDM (or UDM triggers itself) to update the B-TID for a particular UE by updating UE parameters through the UDM control plane procedure or a similar procedure. In operation 1, the UE initiates an application session establishment procedure with the AF. The UE includes the B-TID received in operation Oc. In operations 2-3, the AF selects AAnF based on the HPLM ID associated with the GPSI (e.g., included in BTID) and sends the selected AAnF a request for Kaf to use in the application session with the UE. The request includes the B-TID received in operation 1. In operation 4, the AAnF discovers and selects AUSF via NRF, based on the B-TID received from the AF. For example, AAnF uses AKMA linking information and / or UE information (e.g., GPSI) within B-TID* as input for the NRF discovery service. In operation 5, the AAnF calls a Nausf_AKMAKey_Get service operation to send a request to the selected AUSF for Kakma, including the B-TID in the request. In operation 6, the AUSF returns Kakma to the AAnF, optionally along with SUPI. In other modes, the AAnF calls an existing UDM service (e.g., Nudm SDM GET (Identifier Translation)) to map the UE information within B-TID* to the corresponding SUPI. The AAnF then includes SUPI in the service operation as well. Nausf AKMAKey Get send in operation 5. In operations 7-8, AAnF generates Kaf based on Kakma received from AUSF and provides Kaf to the AF. In operation 9, the AF establishes the secure application session with the UE based on Kaf received in operation 8. In a variant of the procedure shown in Figure 12, in operation 0c, the B-TID* can be provided to the UE overlaid on the existing NAS signaling during the UE primary authentication and / or registration procedures. The other operations in this variant can be substantially identical to those shown in Figure 12. Figure 13 is a flowchart of another example procedure involving the selection of the Authentication Support Function (AUSF) during application session establishment, according to several example embodiments of the present invention. In particular, the embodiments illustrated in Figure 13 leverage NRF registration procedures to register the AAnF according to a range of routing identifiers (RIDs), which the AUSF can later discover via NRF. The entities shown in Figure 13 use the same reference numbers as in Figures 9-11, which are omitted from the following description for brevity. Although Figure 13 shows numbered operations, these numbers are used to facilitate the description of the procedure and do not require or imply a particular order of operations.In other words, the operations shown in Figure 13 can be carried out in a different order than shown, and can be combined and / or divided into operations different from the one shown. As a prerequisite for the modes illustrated in Figure 13, an AAnF can be implemented within the HPLMN to use a GroupID (GID), RID, and / or SUPI range partitioning similar to that used by AUSF and / or UDM. In some modes, multiple AAnF instances can be implemented for each range partition. Similar to Figure 12, the AAnF can be registered with an NRF (not shown in Figure 13) in relation to its corresponding range partition. Operation 0 is similar to Operation 0 shown in Figures 9-11. In Operation 1, after primary authentication and Kakma generation, the AUSF discovers the AAnF instance(s) for the UE via NRF based on the UE's SUPI or RID. Note that multiple AAnF instances may be present for the UE's RID / GID. In Operation 2, the AUSF proactively pushes Kakma, KakmaID, and SUPI for the UE to the AAnF. If multiple AAnF instances are deployed for the UE's RID / GID, the AUSF provides Kakma to all of those AAnF instances. Operation 3 is similar to Operation 3 in Figure 9. In operation 4, the AF selects the AAnF instance(s) based on the HPLMN ID and RID received in operation 3. In operation 5, the AF calls a Nausf_AKMAKey_Get service operation to send a request to the selected AAnF for Kakma, including the KakmaID and RID in the request. In operation 6, after receiving the request, the AAnF compares the KakmaID with the information received in operation 2 to determine which instance has the most recent Kakma. Operations 7-9 are identical to those in Figures 9-12. The modes described above can be further illustrated by the example methods (e.g., procedures) shown in Figures 14-19, which are described below. For example, the characteristics of several modes discussed above are incorporated into various operations of the example methods shown in Figures 14-19. More specifically, Figure 14 illustrates an example method (e.g., procedure) carried out by a key management server (e.g., AAnF) in a communication network (e.g., 5GC), according to various example embodiments of the present invention. The key management server may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere in this document. Although the example method is illustrated in Figure 14 by means of specific blocks in a particular order, the operations corresponding to the blocks may be carried out in different orders than those shown and may be combined and / or divided into blocks and / or operations that have a different functionality than that shown.Furthermore, the example method shown in Figure 14 can be complementary to other example methods and / or procedures described in this document (e.g., Figures 9-12, 16-17, 19), such that they can be used together to provide benefits, advantages, and / or solutions to the problems described herein. Optional blocks and / or operations are indicated by dashed lines. The example method may include the operations in block 1410, where the key management server may receive, from an application function, a request 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 related to a network subscription. The example method may also include the operations in block 1420, where the key management server may, based on the representation, determine an authentication server function (AUSF) that generated the non-application-specific anchor security key (Kakma). In some modes, the example method may also include operations in block 1430, where the key management server can obtain the application-nonspecific anchoring security key (Kakma) from the specified AUSF. In some modes, the example method may also include operations in block 1440, where the key management server can generate the application-specific security key (Kaf) for the application session based on the application-nonspecific anchoring security key (Kakma). Certain variations of the method shown in Figure 14 may correspond to the example procedure shown in Figure 12. In such variations, the representation (e.g., received in block 1410) may include a third identifier (B-ID) of a link between the non-key application-specific anchoring security (Kakma) and the AUSF that generated the Kakma. In particular, the third identifier may include the representation of the first and second identifiers, and information associated with the AUSF. In several variations, 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 such modes, block 1420 determination operations may include subblock 1421 operations, where the key management server can discover an AUSF identity through a Network Repository Function (NRF) based on information associated with the AUSF. Furthermore, in these modes, block 1430 retrieval operations may include subblock 1431-1432 operations. In subblock 1431, the key management server may send a request to the determined AUSF (e.g., from block 1420) that includes the third identifier (e.g., B-TID). In subblock 1432, the key management server may receive a response from the determined AUSF that includes the application-nonspecific anchoring security key (Kakma) and the second identifier. Other variations of the method shown in Figure 14 may correspond to the example procedures shown in Figures 9-11. In such variations, the representation of the first and second identifiers (e.g., received in block 1410) may include the first identifier (e.g., KakmaID) and the second identifier. For example, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Hidden Subscription Identifier (SUCI); Permanent Subscription Identifier (SUPI); or Generic Public Subscription Identifier (GPSI). In one variant, the representation may include only the first identifier (e.g., KakmaID), which includes a representation of the second identifier. In such modes, the block 1420 determination operations may include operations in subblocks 1422-1424. In subblock 1422, the key management server may select a Unified Data Management (UDM) function on the communication network based on the second identifier. In subblock 1423, the key management server may send the UDM an initial request for a fourth identifier associated with the AUSF. In subblock 1424, the key management server may receive an initial response from the UDM that includes the fourth identifier. In some modes, the initial response may also include an additional second identifier related to the network subscription associated with the particular user. For example, the additional second identifier may be a SUPI, and the second identifier may be an identifier other than a SUPI (e.g., GPSI, SUCI, HPLMN+RID). In such modes, the operations to obtain block 1430 may include operations in subblocks 1433-1434. In subblock 1433, the key management server may send a second request to the AUSF associated with the fourth identifier, comprising either the second identifier or an additional second identifier related to the network subscription associated with the particular user. In subblock 1434, the key management server may receive a second response from the AUSF that includes the application-nonspecific anchoring security key (Kakma). In some modes, the second request or the second response may also include the second identifier. For example, if the second request includes the additional second identifier (e.g., SUPI), the second response may include the second identifier (e.g., an identifier other than SUPI). In some modes, the example method may also include block 1440 operations, where the key management server can send the application function the application session-specific security key (Kaf). Furthermore, Figure 15 illustrates another example method (e.g., procedure) carried out by a key management server (e.g., AAnF) in a communication network (e.g., 5GC), in accordance with various example embodiments of the present invention. The key management server may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere in this document. Although the example method is illustrated in Figure 15 by means of specific blocks in a particular order, the operations corresponding to the blocks may be carried out in different orders than those shown and may be combined and / or divided into blocks and / or operations that have a different functionality than that shown.Furthermore, the example method shown in Figure 15 can be used in conjunction with other example methods described herein (e.g., Figures 13 and 18), allowing them to be used together to provide benefits, advantages, and / or solutions to the problems described herein. Optional blocks and / or operations are indicated by dashed lines. The example method may include the operations in block 1520, where the key management server may receive, from an Authentication Server Function (AUSF), the following information associated with a particular user: an application-nonspecific anchor security key (Kakma); a first identifier (KakmaID) of the application-nonspecific anchor security key; and a second identifier related to a network subscription. In some modes, the second identifier may be a permanent subscription identifier (SUPI). The example method can also include operations from blog 1530, where the key management server can receive, from an application function, a request for a security key (Kaf) specific to an application session for a particular user, where the request includes an additional identifier (KakmaID) of a non-application-specific anchor security key associated with the particular user.The example method may also include block 1550 operations, where the key management server can, based on a match between the first identifier and the additional identifier (e.g., a KakmaID match), generate the application session-specific security key (Kaf) based on the non-application-specific anchor security key (Kakma). In some modes, the key management server may include multiple anchoring functions for application authentication and key management (AAnF) instances, with each AAnF instance corresponding to a range of user device routing indicators (RIDs). In such modes, the request may also include a routing indicator (RID) associated with the particular user, and the example method may also include operations in block 1540, where the key management server can select an AAnF instance based on the received RID (for example, based on a match between the received RID and one of the RID ranges). In such modes, the generation of the security key (Kaf) specific to the application session (for example, in block 1550) is performed by the selected AAnF instance. In some configurations, the key management server can be associated with one or more user equipment routing indicator (RID) ranges. For example, the key management server might include multiple instances of AAnF, with each instance corresponding to a user equipment routing indicator (RID) range. In such configurations, the example method might also include block 1510 operations, where the key management server can register an association between itself and one or more ranges with a network repository function (NRF) in the communication network. Furthermore, Figure 16 illustrates an example method (e.g., a procedure) carried out by an application function in a communication network, according to various example embodiments of the present invention. The application function may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere in this document. Although the example method is illustrated in Figure 16 by means of specific blocks in a particular order, the operations corresponding to the blocks may be carried out in different orders than those shown and may be combined and / or divided into blocks and / or operations that have a different functionality than that shown.Furthermore, the example method shown in Figure 16 can be used in conjunction with other example methods described herein (e.g., Figures 9-15, 17-19), allowing them to be used together to provide various benefits, advantages, and / or solutions to the problems described. Optional blocks and / or operations are indicated by dashed lines. The example method may include the operations in block 1610, where the application function may receive, from a user computer, a first request to establish an application session. The first 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 related to a network subscription. The example method may also include the operations in block 1620, where the application function may send, to an application authentication and key management anchor function (AAnF) on the communication network, a second request for a security key (Kaf) specific to the application session. The second request may include the representation of the first and second identifiers. The example method may also include the operations in block 1630, where the application function can receive, from the AAnF, the security key (Kaf) specified for the application session. In some modes, the example method may also include the operations in block 1640, where the application function can establish a secure application session with the user computer based on the received security key (Kaf). Certain variations of the method shown in Figure 16 may correspond to the example procedure shown in Figure 12. In such variations, the representation (e.g., received in block 1610 and sent in block 1620) comprises a third identifier (B-ID) of a link between the application-nonspecific anchoring security key (Kakma) and the AUSF that generated Kakma. In particular, the third identifier may include the representation of the first and second identifiers, and information associated with the AUSF. In several variations, 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. Other variations of the method shown in Figure 16 may correspond to the example procedures shown in Figures 9-11. In such variations, the representation of the first and second identifiers (e.g., received in block 1410) may include the first identifier (e.g., KakmaID) and the second identifier. For example, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Hidden Subscription Identifier (SUCI); Permanent Subscription Identifier (SUPI); or Generic Public Subscription Identifier (GPSI). In one variant, the representation may include only the first identifier (e.g., KakmaID), which includes a representation of the second identifier. Furthermore, Figure 17 illustrates an example method (e.g., procedure) carried out by an Authentication Server Function (AUSF) in a communication network (e.g., 5GC), according to various example embodiments of the present invention. The AUSF may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere in this document. Although the example method is illustrated in Figure 17 by means of specific blocks in a particular order, the operations corresponding to the blocks may be carried out in different orders than those shown and may be combined and / or divided into blocks and / or operations that have a different functionality than that shown.Furthermore, the example method shown in Figure 17 can be used in conjunction with other example methods described herein (e.g., Figures 9-12, 14, 16, 19), allowing them to be used together to provide various benefits, advantages, and / or solutions to the problems described. Optional blocks and / or operations are indicated by dashed lines. The example method may include operations in block 1730, where the AUSF can receive, from an Application Authentication and Key Management (AAnF) anchor function on the communication network, a request for an application-nonspecific anchor security key (Kakma) for a particular user. The request may include a first representation of the following: the first identifier (KakmaID) associated with the application-nonspecific anchor security key (Kakma) and a second identifier related to a network subscription of the particular user. The example method may also include operations in block 1740, where the AUSF can send a response to the AAnF that includes the requested application-nonspecific anchor security key (Kakma). In some modalities, the example method shown in Figure 17 may include operations in blocks 1710–1720. In block 1710, the AUSF may create the application-nonspecific anchor security key (Kakma) for the particular user, as well as the first identifier (KakmaID). In block 1720, the AUSF may send, to a unified data management (UDM) function on the communication network, a fourth identifier (AUSFID) associated with the AUSF and a second representation of at least the first identifier (KakmaID). Certain variations of the method shown in Figure 17 may correspond to the example procedure shown in Figure 12. In such variations, the first representation (e.g., received in block 1730) and the second representation (e.g., sent in block 1720) may include a third identifier (B-ID) of a link between the application-nonspecific anchoring security key (Kakma) and the AUSF that generated Kakma. In particular, the third identifier may include the representation of the first and second identifiers, and information associated with the AUSF. In several variations, 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 such modes, the response (e.g., sent in block 1740) may also include a permanent subscription identifier (SUPI) associated with the particular user. Other variations of the method shown in Figure 17 may correspond to the example procedures shown in Figures 9-11. In these variations, the first representation of the first and second identifiers (e.g., received in block 1730) may include the first identifier (e.g., KakmaID) and the second identifier, while the second representation (e.g., sent in block 1720) may include only the first identifier. In such variations, the second identifier may be any of the following: HPLMN ID and User Equipment Routing Identifier (RID); Hidden Subscription Identifier (SUCI); Permanent Subscription Identifier (SUPI); or Generic Public Subscription Identifier (GPSI).In one variant, the first representation (e.g., received in block 1730) may include only the first identifier (e.g., KakmaID), which may include a representation of the second identifier. Furthermore, Figure 18 illustrates another example method (e.g., procedure) carried out by the Authentication Server Function (AUSF) in a communication network (e.g., 5GC), in accordance with various example embodiments of the present invention. The AUSF may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere in this document. Although the example method is illustrated in Figure 18 by means of specific blocks in a particular order, the operations corresponding to the blocks may be carried out in different orders than those shown and may be combined and / or divided into blocks and / or operations that have a different functionality than that shown.Furthermore, the example method shown in Figure 18 can be complementary to other example methods described herein (e.g., Figures 13 and 15), such that they can be used together to provide benefits, advantages, and / or solutions to the problems described herein. Optional blocks and / or operations are indicated by dashed lines. The example method may include operations in block 1810, where the AUSF can create an application-nonspecific anchor security key (Kakma) for a particular user, and the application-nonspecific anchor security key is associated with a first identifier (Kakma ID). The example method may also include operations in block 1820, where the AUSF can, based on a second identifier related to a network subscription of the particular user, select an anchor function for application authentication and key management (AAnF) in the network communication associated with the particular user.In some modes, the example method may also include block 1830 operations, where the AUSF may send the identified AAnF the following information: the application-nonspecific anchoring security key (Kakma) for the particular user, the first identifier (KakmaID), and the second identifier related to the particular user's network subscription. In several modes, the second identifier may be a permanent subscription identifier (SUPI) associated with the particular user. Furthermore, Figure 19 illustrates an example method (e.g., procedure) carried out by a unified data management (UDM) function in a communication network (e.g., 5GC), according to various example embodiments of the present invention. The UDM function may be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere in this document. Although the example method is illustrated in Figure 19 by means of specific blocks in a particular order, the operations corresponding to the blocks may be carried out in different orders than those shown and may be combined and / or divided into blocks and / or operations that have a different functionality than that shown.Furthermore, the example method shown in Figure 19 can be used in conjunction with other example methods described in this document (e.g., Figures 9-11, 14, 16-17), allowing them to be used together to provide various benefits, advantages, and / or solutions to the problems described herein. Optional blocks and / or operations are indicated by dashed lines. The example method may include operations in block 1910, where the UDM function can receive, from an Authentication Server Function (AUSF) on the communication network, 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 particular user. The example method may also include operations in block 1920, where the UDM function can receive, from an Application Authentication and Key Management Anchor Function (AAnF) on the communication network, a request for the fourth identifier. The example method may also include operations in block 1950, where the UDM function can send a response to the AAnF that includes the fourth identifier. In some modes, the request (for example, received in block 1920) may include the first identifier (KakmalD), and the response (for example, sent in block 1950) may include a second identifier related to a network subscription associated with the particular user. In some of these modes, the first identifier may include a representation of the second identifier. An example of such modes is shown in the procedure illustrated by Figure 9. In another of these modes, the request may include a second identifier related to the network subscription associated with the particular user. In such modes, the example method may also include operations in block 1930, where the UDM function can determine the second identifier based on the additional second identifier. For example, the second identifier may be a permanent subscription identifier (SUPI), and the additional second identifier may be an identifier other than SUPI (e.g., SUCI, GPSI). Examples of such modes are shown in the procedures illustrated by Figures 10-11. ινΐΛ / a / zuzz / ui In several modes, the AUSF (e.g., from which the information was received in block 1910) can include multiple AUSF instances, each AUSF instance corresponding to a range of identifiers associated with network subscriptions (e.g., RID, SUPI, etc.). In such modes, the example method can also include operations in block 1940, where the UDM function can select a particular AUSF instance based on the second identifier (e.g., received in block 1920). In such modes, the fourth identifier (e.g., sent in block 1950) can correspond to the selected AUSF instance. Although the subject matter described in this document can be implemented in any appropriate type of system using any suitable component, the modalities described herein are described in relation to a wireless network, such as the example wireless network illustrated in Figure 20. For simplicity, the wireless network in Figure 20 shows only the 2006 network, the 2060 and 2060b network nodes, and the 2010, 2010b, and 2010c wireless devices. In practice, a 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, a service provider, or any other network node or end device. Of the components illustrated, the 2060 network node and the 2010 wireless device (WD) are shown in additional detail.The wireless network can provide communication and other types of services to one or more wireless devices to facilitate access by wireless devices and / or the use of services provided by, or through, the wireless network. A wireless network can encompass and / or interact with any type of communication, telecommunications, data, cellular, and / or radio network, or other similar system. In some configurations, a wireless network can be configured to operate according to specific standards or other predefined rules or procedures. Therefore, particular wireless network configurations may implement communication standards such as the Global System for Mobile Communications (GSM), the Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards such as IEEE 802.11; and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth, Z-Wave, and / or ZigBee standards. The 2006 network may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTNs), 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 to enable communication between devices. The 2060 network node and the WD 2010 comprise several components, which are described in more detail below. These components work together to provide network node and / or wireless device functionality, such as providing wireless connections in a wireless network. In various configurations, the wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, repeater stations, and / or any other component or system that can facilitate or participate in the communication of data and / or signals, whether through wired or wireless connections. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, B-nodes, evolved B-nodes (eNBs), and NR B-nodes (gNBs)). Base stations can be classified based on the amount of coverage they provide (or, in other words, their transmit power level) and may also be called femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node that controls a relay. A network node may also include one or more (or all) parts of a distributed radio base station, such as centralized digital units and / or remote radio units (RRUs), sometimes called remote radio heads (RRHs). Such remote radio units may or may not be integrated with an antenna, such as an integrated radio antenna.The parts of a distributed radio base station can also be referred to as nodes in a distributed antenna system (DAS). Other examples of network nodes include multi-standard radio equipment (MSRs) such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmit points, transmit nodes, multicast / multicell coordination entities (MCEs), core network nodes (e.g., MSCs, MMEs), operations and maintenance nodes, OSS nodes, SON nodes, positioning nodes (e.g., E-SMLCs), and / or MDTs. As another example, a network node can be a virtual network node, as described in more detail below.However, more generally, network nodes can represent any suitable device (or group of devices) capable, configured, arranged and / or operable to enable and / or provide a wireless device with access to the wireless network or to provide some service to a wireless device that has accessed the wireless network. In Figure 20, network node 2060 includes processing circuitry 2070, device-readable medium 2080, interface 2090, auxiliary equipment 2084, power supply 2086, power circuitry 2087, and antenna 2062. Although the network node 2060 illustrated in the example wireless network in Figure 20 may represent a device that includes the illustrated combination of hardware components, other configurations may comprise network nodes with different combinations of components. It should be understood that a network node comprises any suitable combination of hardware and / or software necessary to perform the tasks, features, functions, and methods and / or procedures described in this document.Furthermore, while the components of the 2060 network node are represented as individual boxes located within a larger box, or nested within several boxes, in practice, a network node may comprise several different physical components that form a single illustrated component (e.g., the 2080 device-readable media may comprise several independent hard drives, as well as several RAM modules). Similarly, the 2060 network node can be composed of several phase-separated components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own respective components. In certain scenarios where the 2060 network node comprises several separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among multiple network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB-RNC pair may, in some cases, be considered a single, separate network node. In some configurations, the 2060 network node can be configured to support various radio access technologies (RATs).In such configurations, some components can be duplicated (for example, a separate 2080 device-readable medium for different RATas) and some components can be reused (for example, the same 2062 antenna can be shared by the RATas). The 2060 network node can also include multiple sets of the various components illustrated for different wireless technologies integrated into the 2060 network node, such as GSM, WCDMA, LTE, NR, Wi-Fi, or Bluetooth. These wireless technologies can be integrated on the same chip or chipset, or on different chips and components within the 2060 network node. The 2070 processing circuit can be configured to perform any determination, calculation, or similar operation (e.g., certain retrieval operations) described herein as provided by a network node. These operations performed by the 2070 processing circuit may include processing the information obtained by the 2070 processing circuit, for example, converting the obtained information into other information, comparing the obtained or converted information with information stored in the network node, and / or performing one or more operations based on the obtained or converted information, and as a result of such processing, making a determination. The 2070 processing circuit may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or coded logic operable to provide various functions of the 2060 network node, either alone or in conjunction with other components of the 2060 network node (e.g., the 2080 device-readable media). Such functionality may include any of the various wireless features, functions, or benefits discussed in this document. For example, the 2070 processing circuit can execute instructions stored on the 2080 device-readable medium or in memory within the 2070 processing circuit. In some configurations, the 2070 processing circuit may include a system-on-a-chip (SoC). As a more specific example, the instructions (also known as software products) stored on the 2080 medium may include instructions that, when executed by the 2070 processing circuit, can configure the 2060 network node to perform operations corresponding to various example methods (e.g., procedures) described in this document. In some configurations, the 2070 processing circuit may include one or more 2072 radio frequency (RF) transceiver circuits and 2074 baseband processing circuits. In some configurations, the 2072 radio frequency (RF) transceiver circuits and the 2074 baseband processing circuits may be on separate chips (or chipsets), boards, or units, such as radio units and digital units. In alternative configurations, some or all of the 2072 RF transceiver circuits and the 2074 baseband processing circuits may be on the same chip or chipset, board, or unit. In certain configurations, some or all of the functions described herein provided by a network node, base station, eNB, or other similar network device may be performed by the 2070 processing circuit by executing instructions stored on the 2080 device-readable medium or memory within the 2070 processing circuit. In alternative configurations, some or all of the functionality may be provided by the 2070 processing circuit without executing instructions stored on a separate or discrete device-readable medium, such as in a hardwired manner. In either configuration, whether executing instructions stored on a device-readable storage medium or not, the 2070 processing circuit may be configured to perform the described functionality.The benefits provided by this functionality are not limited to the 2070 processing circuitry alone or to other components of the 2060 network node, but are enjoyed by the 2060 network node as a whole and / or end users and the wireless network in general. Device-readable media 2080 may comprise any form of volatile or non-volatile computer-readable memory, including but not limited to persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random-access memory (RAM), read-only memory (ROM), mass storage media (e.g., a hard disk), removable storage media (e.g., a flash drive, compact disc (CD), or digital video disc (DVD)), and / or any other non-volatile, non-transient, computer-readable and executable memory devices that store information, data, and / or instructions that can be used by the 2070 processing circuit. Device-readable media 2080 may store any suitable instruction, data, or information, including a computer program, software, or an application that includes one or more logic, rules, code, tables, etc.and / or other instructions that can be executed by the 2070 processing circuit and used by the 2060 network node. The 2080 device-readable medium can be used to store any calculations performed by the 2070 processing circuit and / or any data received through the 2090 interface. In some configurations, the 2070 processing circuit and the 2080 device-readable medium can be considered integrated. The 2090 interface is used for wired or wireless signaling and / or data communication between the 2060 network node, the 2006 network, and / or the 2010 WDs. As illustrated, the 2090 interface comprises 2094 port(s) / terminal(s) for sending and receiving data, for example, to and from the 2006 network via a wired connection. The 2090 interface also includes a radio front-end circuit 2092 that can be coupled to, or in certain modes be part of, the antenna 2062. The radio front-end circuit 2092 comprises filters 2098 and amplifiers 2096. The radio front-end circuit 2092 can be connected to the antenna 2062 and processing circuit 2070. The radio front-end circuit can be configured to condition the signals communicated between the antenna 2062 and the processing circuit 2070.The radio front-end circuit 2092 can receive digital data to be sent to other network nodes or WDs via a wireless connection. The radio front-end circuit 2092 can convert the digital data into a radio signal with the appropriate channel and bandwidth parameters using a combination of filters 2098 and / or amplifiers 2096. The radio signal can then be transmitted via antenna 2062. Similarly, when receiving data, antenna 2062 can collect radio signals that are then converted into digital data by the radio front-end circuit 2092. The digital data can then be passed to the processing circuit 2070. In other configurations, the interface may comprise different components and / or different combinations of components. In certain alternative configurations, the 2060 network node may not include a separate 2092 radio front-end circuit; instead, the 2070 processing circuit may comprise a radio front-end circuit and may connect to the 2062 antenna without a separate 2092 radio front-end circuit. Similarly, in some configurations, all or some of the 2072 RF transceiver circuits may be considered part of the 2090 interface. In other configurations, the 2090 interface may include one or more 2094 ports or terminals, 2092 radio front-end circuits, and 2072 RF transceiver circuits, as part of a radio unit (not shown), and the 2090 interface may communicate with the 2074 baseband processing circuit, which is part of a digital unit (not shown). The 2062 antenna can include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The 2062 antenna can be coupled to the 2090 radio front-end circuit and can be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some configurations, the 2062 antenna can comprise one or more omnidirectional, sector, or panel antennas operable to transmit / receive radio signals between, for example, 2 GHz and 66 GHz. An omnidirectional antenna can be used to transmit / receive radio signals in any direction, a sector antenna can be used to transmit / receive radio signals from devices within a particular area, and a panel antenna can be a line-of-sight antenna used to transmit / receive radio signals in a relatively straight line. In some cases, the use of more than one antenna may be referred to as MIMO.In certain configurations, the 2062 antenna can be separate from the 2060 network node and can be connected to the 2060 network node via an interface or port. Antenna 2062, interface 2090, and / or processing circuit 2070 can be configured to perform any receive operation and / or certain obtain operations 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 equipment. Similarly, antenna 2062, interface 2090, and / or processing circuit 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 equipment. Power circuit 2087 may comprise, or be coupled to, a power management circuit and may be configured to supply power to network node 2060 components to perform the functionality described herein. Power circuit 2087 may receive power from power source 2086. Power source 2086 and / or power circuit 2087 may be configured to provide power to the various network node 2060 components in a manner suitable for the respective components (e.g., at a voltage and current required by each respective component). Power source 2086 may be included within or external to power circuit 2087 and / or network node 2060.For example, network node 2060 can be connected to an external power source (e.g., a power outlet) via an input circuit or interface, such as an electrical cable, where the external power source supplies power to power circuit 2087. As another example, power source 2086 can comprise a power source in the form of a battery or battery pack that is connected to or integrated into power circuit 2087. The battery can provide backup power in the event of a failure of the external power source. Other types of power sources, such as photovoltaic devices, can also be used. Alternative configurations of the 2060 network node may include additional components beyond those shown in Figure 20. These components may be responsible for providing certain aspects of the network node's functionality, including any of the functions described herein and / or any functionality necessary to support the subject matter described herein. For example, the 2060 network node may include user interface equipment to enable and / or facilitate the input of information into the 2060 network node and to enable and / or facilitate the output of information from the 2060 network node. This may enable and / or facilitate a user to perform diagnostics, maintenance, repair, and other administrative functions for the 2060 network node. In some configurations, a wireless device (such as the WD 2010) can be configured to transmit and / or receive information without direct human interaction. For example, a WD device can be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to network requests.Examples of WDs include, but are not limited to, smartphones, mobile phones, cell phones, voice over IP (VoIP) phones, cordless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or laptops, music storage devices, playback devices, wearable devices, wireless terminals, mobile stations, tablets, laptops, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, customer premises wireless equipment (CPE), mobile-type communication (MTC) devices, Internet of Things (IoT) devices, vehicle-mounted wireless terminal devices, etc. A device-to-device (D2D) device can support device-to-device (D2D) communication, for example, by implementing a 3GPP standard for sidelink, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X) communication, and in this case, it can be called a D2D communication device. As another specific example, in an Internet of Things (IoT) scenario, a D2D device can represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another D2D device and / or a network node. In this case, the D2D device can be a machine-to-machine (M2M) device, which in a 3GPP context can be called an MTC device. As a particular example, the D2D device can be a UE implementing the 3GPP narrowband Internet of Things (NB-IoT) standard.Specific examples of such machines or devices include sensors, measuring devices such as energy meters, industrial machinery, or household appliances (e.g., refrigerators, televisions, etc.), and portable personal devices (e.g., watches, fitness trackers, etc.). In other scenarios, a WD may represent a vehicle or other equipment capable of monitoring and / or reporting its operational status or other functions associated with its operation. A WD as described above may represent the endpoint of a wireless connection, in which case the device may be called a wireless terminal. Furthermore, a WD as described above may be mobile, in which case it may also be called a mobile device or mobile terminal. As illustrated, the WD 2010 wireless device includes antenna 2011, interface 2014, processing circuitry 2020, device-readable medium 2030, user interface equipment 2032, auxiliary equipment 2034, power source 2036, and power circuitry 2037. The WD 2010 may include multiple assemblies of one or more of the illustrated components for different wireless technologies supported by the WD 2010, such as GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, to name a few. These wireless technologies may be integrated on chips or chipsets that are the same as or different from other components within the WD 2010. Antenna 2011 may include one or more antennas or antenna arrays, configured to send and / or receive wireless signals, and is connected to interface 2014. In certain alternative configurations, antenna 2011 may be separate from WD 2010 and 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 operation described herein as being performed by a WD. Any information, data, and / or signal may be received from a network node and / or another WD. In some configurations, the radio front-end circuitry and / or antenna 2011 may be considered an interface. As illustrated, the interface 2014 comprises a radio front-end circuit 2012 and an antenna 2011. The radio front-end circuit 2012 comprises one or more filters 2018 and amplifiers 2016. The radio front-end circuit 2014 is connected to the antenna 2011 and the processing circuit 2020 and can be configured to condition signals communicated between the antenna 2011 and the processing circuit 2020. The radio front-end circuit 2012 may be coupled to or form part of the antenna 2011. In some embodiments, the WD 2010 may not include a separate radio front-end circuit 2012. Rather, the processing circuit 2020 may comprise a radio front-end circuit and may be connected to the antenna 2011. Similarly, in some modalities, some or all of the RF transceiver circuits 2022 may be considered part of the interface 2014.The radio front-end circuit 2012 can receive digital data to be sent to other network nodes or WDs via a wireless connection. The radio front-end circuit 2012 can convert the digital data into a radio signal with the appropriate channel and bandwidth parameters using a combination of filters 2018 and / or amplifiers 2016. The radio signal can then be transmitted via antenna 2011. Similarly, upon receiving data, antenna 2011 can collect radio signals that are then converted into digital data by the radio front-end circuit 2012. The digital data can then be passed to the processing circuit 2020. In other embodiments, the interface may comprise different components and / or different combinations of components. The 2020 processing circuit may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any other computing device, resource, or combination of hardware, software, and / or coded logic operable to provide the functionality of the WD 2010, either alone or in combination with other WD 2010 components, such as the 2030 device-readable media. Such functionality may include any of the various wireless features or benefits discussed herein. For example, the processing circuit 2020 can execute instructions stored on the device-readable medium 2030 or in memory within the processing circuit 2020 to provide the functionality described in this document. More specifically, the instructions (also referred to as a computer program product) stored on the medium 2030 can include instructions that, when executed by the processing circuit 2020, can configure the wireless device 2010 to perform operations corresponding to various example methods (for example, procedures) described in this document. As illustrated, the 2020 processing circuit includes one or more 2022 RF transceiver circuits, 2024 baseband processing circuits, and 2026 application processing circuits. In other embodiments, the processing circuits may comprise different components and / or different combinations of components. In certain embodiments, the 2020 processing circuit of WD 2010 may comprise a System-on-a-Chip (SOC). In some embodiments, the 2022 RF transceiver circuit, 2024 baseband processing circuit, and 2026 application processing circuit may be on separate chips or chipsets. In alternative embodiments, some or all of the 2024 baseband processing circuit and 2026 application processing circuit may be combined on one chip or chipset, and the 2022 RF transceiver circuit may be on a separate chip or chipset.In still alternative configurations, part or all of the RF transceiver circuit 2022 and the 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 still other alternative configurations, part or all of the RF transceiver circuits 2022, the baseband processing circuits 2024, and the application processing circuits 2026 may be combined on the same chip or chipset. In some configurations, the RF transceiver circuit 2022 may be part of the interface 2014. The RF transceiver circuit 2022 may condition the RF signals for the processing circuit 2020. In certain embodiments, some or all of the functions described herein performed by a WD may be provided by a processing circuit 2020 executing instructions stored on a device-readable medium 2030, which in certain embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuit 2020 without executing instructions stored on a separate or discrete device-readable storage medium, such as, for example, in a hardwired manner. In either of these particular embodiments, whether or not executing instructions stored on a device-readable storage medium, the processing circuit 2020 may be configured to perform the described functionality.The benefits provided by this functionality are not limited to the 2020 processing circuitry alone or other components of the WD 2010, but are enjoyed by the WD 2010 in its entirety and / or end users and the wireless network in general. The 2020 processing circuit can be configured to perform any determination, calculation, or similar operation (e.g., certain retrieval operations) described herein as being performed by a WD. These operations, performed by the 2020 processing circuit, may include processing information obtained by the 2020 processing circuit, for example, converting the obtained information into other information, comparing the obtained or converted information with information stored by the 2010 WD, and / or performing one or more operations based on the obtained or converted information, and as a result of such processing, making a determination. The device-readable medium 2030 can be operated to store a computer program, software, or application that includes one or more logic, rules, code, tables, etc., and / or other instructions that can be executed by processing circuits 2020. The device-readable medium 2030 can include computer memory (e.g., random-access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., a hard disk), removable storage media (e.g., a compact disc (CD) or a digital video disc (DVD)), and / or any other computer-readable and / or executable memory device, volatile or non-volatile, non-transient, that stores information, data, and / or instructions that can be used by the processing circuit 2020. In some embodiments, the processing circuit 2020 and the device-readable medium 2030 can be considered integrated. User interface equipment (UIE) 2032 may include components that enable and / or facilitate human user interaction with the WD 2010. Such interaction may take many forms, such as visual, auditory, tactile, etc. UIE 2032 may operate to produce results for the user and to enable and / or facilitate the user to provide information to the WD 2010. The type of interaction may vary according to the type of UIE 2032 installed in the WD 2010. For example, if the WD 2010 is a smartphone, the interaction may be through a touchscreen; if the WD 2010 is a smart meter, the interaction may be through a display that provides usage (e.g., the number of liters used) or a speaker that provides an audible alert (e.g., if smoke is detected).User interface equipment 2032 may include input interfaces, devices, and circuitry, and output interfaces, devices, and circuitry. User interface equipment 2032 may be configured to enable and / or facilitate the input of information into the WD 2010 and is connected to processing circuitry 2020 to enable and / or facilitate the processing circuitry 2020 to process the input information. User interface equipment 2032 may include, for example, a microphone, a proximity sensor, keys / buttons, a touchscreen, one or more cameras, a USB port, or other input circuitry. User interface equipment 2032 is also configured to enable and / or facilitate the output of information from the WD 2010 and to enable and / or facilitate the processing circuitry 2020 to send information from the WD 2010.The 2032 user interface equipment may include, for example, a speaker, a display, a vibration circuit, a USB port, a headphone interface, or other output circuitry. By using one or more of the 2032 user interface equipment's interfaces, devices, and input / output circuitry, the WD 2010 can communicate with end users and / or the wireless network and enable and / or facilitate the functionality described herein. The 2034 auxiliary equipment can operate to provide more specific functionality that WDs typically cannot perform. This may include specialized sensors for taking measurements for various purposes, interfaces for additional types of communication, such as wired communications, and so on. The inclusion and type of components in the 2034 auxiliary equipment may vary depending on the modality and / or scenario. The power source 2036 may, in some embodiments, 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 (for example, a wall outlet), photovoltaic devices, or energy cells. The WD 2010 may further comprise a power circuit 2037 to supply power from the power source 2036 to the various parts of the WD 2010 that require power from the power source 2036 to perform any functionality described or indicated herein. The power circuit 2037 may, in certain embodiments, comprise a power management circuit.Power circuit 2037 can also operate as an alternative to receiving power from an external power source. In this case, the WD 2010 can be connected to the external power source (such as a wall outlet) via an input circuit or interface such as a power cable. Power circuit 2037 can also operate in certain modes to supply power from an external power source to power source 2036. This may be, for example, for charging power source 2036. Power circuit 2037 can perform any conversion or other modification to the power from power source 2036 to make it suitable for supplying power to the respective components of the WD 2010. Figure 21 illustrates one modality of a user equipment (UE) according to several aspects described in this document. As used here, a user equipment or UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale or operation by a human user, but which may not be associated, or may not initially be associated, with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale or operation by an end user, but which may be associated with or operated for the benefit of a user (e.g., a smart energy meter).The UE 2100 can be any UE identified by the Third Generation Partnership Project (3GPP), including an NB-IoT UE, a Machine-Type Communication (MTC) UE, and / or an Enhanced MTC (eMTC) UE. The UE 2100, as illustrated in Figure 21, is an example of a WD configured for communication in accordance with one or more communication standards promulgated by the Third Generation Partnership Project (3GPP), such as the 3GPP GSM, UMTS, LTE, and / or 5G standards. As mentioned earlier, the terms WD and UE can be used interchangeably. Consequently, although Figure 21 is a UE, the components discussed here are equally applicable to a WD and vice versa. In Figure 21, the UE 2100 includes a processing circuit 2101 that is operatively coupled to the input / output interface 2105, the radio frequency (RF) interface 2109, the network connection interface 2111, memory 2115 including random access memory (RAM) 2117, read-only memory (ROM) 2119, and storage medium 2121 or similar, communication subsystem 2131, power supply 2133, and / or any other component, or any combination thereof. The storage medium 2121 includes the operating system 2123, application program 2125, and data 2127. In other embodiments, the storage medium 2121 may include other similar types of information. Certain UEs may use all of the components shown in Figure 21, or only a subset of the components. The level of integration between components may vary from one UE to another.In addition, certain UEs can contain multiple instances of a component, such as several. 100 processors, memories, transceivers, transmitters, receivers, etc. In Figure 21, the 2101 processing circuit can be configured to process computer instructions and data. The 2101 processing circuit can be configured to implement any operational sequential state machine for executing machine instructions stored as machine-readable computer programs in memory, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC, etc.); programmable logic together with appropriate firmware; one or more stored programs; general-purpose processors, such as a microprocessor or a digital signal processor (DSP), together with appropriate software; or any combination thereof. For example, the 2101 processing circuit can include two central processing units (CPUs). Data can be information in a form suitable for use by a computer. In the mode shown, the 2105 input / output interface can be configured to provide a communication interface to an input device, an output device, or an input / output device. The UE 2100 can be configured to use an output device through the 2105 input / output interface. 101 An output device can use the same type of interface port as an input device. For example, a USB port can be used to provide both input and output from the UE 2100. The output device can be a speaker, sound card, video card, display, monitor, printer, actuator, emitter, smart card, another output device, or any combination thereof. The UE 2100 can be configured to use an input device through the 2105 input / output interface to enable and / or facilitate a user to capture information on the UE 2100. The input device can 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 directional pad, a trackpad, a scroll wheel, a smart card, and similar devices.The presence-sensitive display may include a capacitive or resistive touch sensor to detect user input. A sensor could be, for example, an accelerometer, gyroscope, tilt sensor, force sensor, magnetometer, optical sensor, proximity sensor, or any combination thereof. For example, the input device could be an accelerometer, a magnetometer, a digital camera, a microphone, and an optical sensor. 102 In Figure 21, the RF interface 2109 can be configured to provide a communication interface to RF components, such as a transmitter, receiver, and antenna. The network connection interface 2111 can be configured to provide a communication interface to the network 2143a. The network 2143a can 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 2143a could comprise a Wi-Fi network. The network connection interface 2111 can be configured to include a receiver and transmitter interface used to communicate with one or more devices across a communication network in accordance with one or more communication protocols, such as Ethernet, TCP / IP, SONET, ATM, or similar protocols.The 2111 network connection interface can implement the appropriate receiver and transmitter functionality for communication network links (e.g., optical, electrical, and similar). The transmitter and receiver functions can share circuit components, software, or firmware, or alternatively, they can be implemented separately. The RAM 2117 can be configured to interface via bus 2102 with processing circuit 2101 to provide data storage or caching 103 or computer instructions during the execution of software programs such as the operating system, application programs, and device drivers. ROM 2119 can be configured to provide computer instructions or data to the processing circuit 2101. For example, ROM 2119 can be configured to store low-level system code or data that is invariant for basic system functions, such as basic input / output (I / O), startup, or receiving keystrokes from a keyboard that are stored in non-volatile memory. Storage medium 2121 can be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), programmable and rechargeable read-only memory (EPROM), electrically programmable and rechargeable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, or flash drives. In one example, storage medium 2121 can be configured to include the operating system 2123; application program 2125, such as a web browser application, widget or gadget engine, or other application; and data file 2127. Storage medium 2121 can store, for use by UE 2100, any of a variety of operating systems or combinations of operating systems. For example, application program 2125 can include instructions for executable programs (also called 104 software products) that, when executed by the 2101 processor, can configure the UE 2100 to perform operations corresponding to various example methods (for example, procedures) described in this document. The 2121 storage medium can be configured to include various physical disk drives, such as a redundant array of independent disks (RAID), floppy disk drive, flash memory, USB flash drive, external hard disk drive, USB memory stick, pen drive, key, high-density digital versatile disc (HD-DVD) optical drive, internal hard disk drive, Blu-ray optical drive, holographic digital data storage (HDDS) optical drive, external dual mini-in-line memory module (DIMM), synchronous dynamic random-access memory (SDRAM), external microDIMM SDRAM, smart card memory such as a subscriber identity module or removable user identity module (SIM / RUIM), other memory, or any combination thereof.Storage medium 2121 may enable and / or facilitate the UE 2100 to access executable computer instructions, application programs, or similar items stored on transient or non-transient memory media, for the purpose of downloading or uploading data. A manufactured item, such as one that uses a communication system, may be tangibly incorporated into storage medium 2121, which may comprise a medium. 105 device readable. In Figure 21, the processing circuit 2101 can be configured to communicate with network 2143b using the communication subsystem 2131. Network 2143a and network 2143b can be the same network or networks, or different networks. The communication subsystem 2131 can be configured to include one or more transceivers used to communicate with network 2143b. For example, the communication subsystem 2131 can be configured to include one or more transceivers used to communicate with one or more remote transceivers of another wirelessly communicative device, such as another WD, UE, or 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, or similar protocols.Each transceiver may include transmitter 2133 and / or receiver 2135 to implement the appropriate transmitter or receiver functionality for the RAN links (e.g., frequency allocations and the like). Furthermore, the transmitter 2133 and receiver 2135 of each transceiver may share circuit components, software, or firmware, or alternatively, they may be implemented separately. In the illustrated mode, the communication functions of the 2131 communication subsystem may include data communication, voice communication, and other communication functions. 106 Multimedia, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the Global Positioning System (GPS) to determine a location, other similar communication functions, 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, other similar networks, 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 UE 2100 components. The features, advantages, and / or functions described herein may be implemented in one of the UE 2100 components or distributed across several UE 2100 components. Furthermore, the features, advantages, and / or functions described herein may be implemented in any combination of hardware, software, or firmware. For example, the 2131 communication subsystem may be configured to include any of the components described herein. Additionally, the 2101 processing circuit may 107 can be configured to communicate with any of these components via bus 2102. Alternatively, any of these components can be represented by program instructions stored in memory which, when executed by processing circuit 2101, perform the corresponding functions described herein. Alternatively, the functionality of any of these components can be divided between processing circuit 2101 and communication subsystem 2131. Finally, the non-computation-intensive functions of any of these components can be implemented in software or firmware, and the computation-intensive functions can be implemented in hardware. Figure 22 is a schematic block diagram illustrating a 2200 virtualization environment where the functions implemented by certain modalities can be virtualized. In this context, virtualization means creating virtual versions of appliances or devices, which can include the virtualization of hardware platforms, storage devices, and network resources. As used here, virtualization can be applied to a node (e.g., a virtualized base station or a virtualized radio access node) or to a device (e.g., a UE, a wireless device, or any other type of communication device) or components thereof, and refers to a 108 implementation in which at least some of the functionality is implemented as one or more virtual components (for example, through one or more applications, components, functions, virtual machines or containers running on one or more physical processing nodes on one or more networks). In some modes, some or all of the functions described in this document may be implemented as virtual components executed by one or more virtual machines deployed in one or more 2200 virtual environments hosted by one or more 2230 hardware nodes. Additionally, in modes where the virtual node is not a radio access node or does not require radio connectivity (for example, a core network node), then the network node may be fully virtualized. The functions can be implemented by one or more 2220 applications (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operating to implement some of the features, functions, and / or benefits of some of the modes described in this document. The 2220 applications run in the 2200 virtualization environment provided by 2230 hardware comprising the 2260 processing circuit and the 2290 memory. The 2290 memory contains 2295 instructions executable by the 2260 processing circuit through the 109 which application 2220 is operational to provide one or more of the features, benefits and / or functions disclosed in this document. The 2200 virtualization environment may include general-purpose or special-purpose 2230 network hardware devices (or nodes) comprising a set of one or more 2260 processors or processing circuits, which may be commercially available (COTS) processors, dedicated application-specific integrated circuits (ASICs), or any other type of processing circuit, including analog or digital hardware components or special-purpose processors. Each hardware device may comprise a 2290-1 memory, which may be non-persistent memory for temporarily storing 2295 instructions or software executed by the 2260 processing circuit.For example, instructions 2295 may include program instructions (also called computer program product) that, when executed by processing circuit 2260, can configure hardware node 2220 to perform operations corresponding to various example methods (for example, procedures) described in this document. Such operations can also be assigned to virtual nodes 2220 hosted on hardware node 2230. Each hardware device may comprise one or ινΐΛ / a / zuzz / ui 110 plus network interface controllers (NICs) 2270, also known as network interface cards, which include a physical network interface 2280. Each hardware device may also include non-transient, persistent, machine-readable storage media 2290-2 having stored therein the software 2295 and / or instructions executable by the processing circuit 2260. The software 2295 may include any type of software, including software for instantiating one or more virtualization layers 2250 (also called hypervisors), software for running virtual machines 2240, as well as software that enables you to execute functions, features, and / or benefits described in connection with some of the modes described herein. Virtual machines 2240 comprise virtual processing, virtual memory, virtual networking or interface, and virtual storage, and can be run by a corresponding virtualization layer 2250 or hypervisor. Different modes of the virtual appliance 2220 instance can be implemented on one or more virtual machines 2240, and these implementations can be carried out in various ways. During operation, the processing circuit 2260 runs the software 2295 to instantiate the hypervisor or virtualization layer 2250, which may sometimes be referred to as 111 Virtual Machine Monitor (VMM). The virtualization layer 2250 can present a virtual operating platform that appears as network hardware to the virtual machine 2240. As shown in Figure 22, the 2230 hardware can be a standalone network node with generic or specific components. The 2230 hardware can include the 22225 antenna and can implement some functions through virtualization. Alternatively, the 2230 hardware can be part of a larger hardware group (for example, in a data center or customer premises equipment (CPE)) where many hardware nodes work together and are managed through 22100 management and orchestration (MANO), which, among other things, oversees the lifecycle management of 2220 applications. Hardware virtualization is sometimes called network functions virtualization (NFV). NFV can be used to consolidate many types of network equipment onto industry-standard, high-volume server hardware, physical switches, and physical storage, which can be located in data centers and on-premises at the customer's site. In the context of NFV, a 2240 virtual machine can be a software implementation of a physical machine that runs programs as if they were running on a non-virtualized physical machine. Each of the machines 112 virtual 2240s, and that part of the 2230 hardware that runs that virtual machine, whether hardware dedicated to that virtual machine and / or hardware shared by that virtual machine with other virtual 2240 machines, forms separate virtual network elements (VNEs). Even within the context of NFV, the virtual network function (VNF) is responsible for handling specific network functions that run on one or more virtual machines 2240 over the hardware networking infrastructure 2230 and corresponds to application 2220 in Figure 22. In some embodiments, one or more 22200 radio units, including one or more 22220 transmitters and one or more 22210 receivers, may be coupled to one or more 22225 antennas. The 22200 radio units may communicate directly with the 2230 hardware nodes via one or more appropriate network interfaces and may be used in combination with virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. Nodes arranged in this manner may also communicate with one or more UEs, as described elsewhere in this document. In some modes, some signals can be carried out through the 22230 control system, which can alternatively be used for communication between the 2230 hardware nodes and the 22200 radio units. 113 With reference to Figure 23, according to one modality, a communication system includes a telecommunications network 2310, such as a 3GPP-type cellular network, comprising an access network 2311, such as a radio access network, and a core network 2314. The access network 2311 comprises a plurality of base stations 2312a, 2312b, 2312c, such as NBs, eNBs, gNBs, or other types of wireless access points, each of which defines a corresponding coverage area 2313a, 2313b, 2313c. Each base station 2312a, 2312b, 2312c can be connected to the core network 2314 via a wired or wireless connection 2315. A first UE 2391 located in the coverage area 2313c can be configured to wirelessly connect to or be searched for by the corresponding base station 2312c. A second UE 2392 in the coverage area 2313a can wirelessly connect to the corresponding base station 2312a.Although this example illustrates a plurality of UEs 2391, 2392, the modalities described are equally applicable to a situation in which a single UE is in the coverage area or in which a single UE connects to it. The 2310 telecommunications network itself is connected to the main computer 2330, which can be incorporated into the hardware and / or software of a standalone server, a cloud-deployed server, a distributed server, or as processing resources in a inala / a / zuzz / ui farm 114 servers. The main computer 2330 may be owned or controlled by a service provider or may be operated by or on behalf of the service provider. The connections 2321 and 2322 between the telecommunications network 2310 and the main computer 2330 may extend directly from the core network 2314 to the main computer 2330 or may go through an optional intermediate network 2320. The intermediate network 2320 may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network 2320, if any, may be a backbone or the Internet; in particular, the intermediate network 2320 may comprise two or more subnets (not shown). The communication system in Figure 23, 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 communicate data and / or signaling via the OTT connection 2350, using the access network 2311, the core network 2314, any intermediate networks 2320, and any additional infrastructure (not shown) as intermediaries. The OTT connection 2350 can be transparent in the sense that the participating communication devices through which the OTT connection 2350 passes are unaware of the routing. 115 of uplink and downlink communications. For example, base station 2312 may not or does not need to be informed about the past routing of an incoming downlink communication with data originating from host computer 2330 to be forwarded (e.g., delivered) to a connected UE 2391. Similarly, base station 2312 does not need to be aware of the future routing of an outgoing uplink communication originating from UE 2391 to host computer 2330. Example implementations, according to one modality, of the UE, base station, and main computer discussed in the preceding paragraphs will now be described with reference to Figure 24. In the communication system 2400, the main computer 2410 comprises hardware 2415, including the communication interface 2416, configured to establish and maintain a wired or wireless connection with an interface of a communication device other than the communication system 2400. The main computer 2410 further comprises a processing circuit 2418, which may have storage and / or processing capabilities. In particular, the processing circuit 2418 may comprise one or more programmable processors, application-specific integrated circuits, field-programmable gate assemblies, or combinations thereof (not shown) adapted for 116. Execute instructions. The main computer 2410 further comprises software 2411, which is stored on or accessible by the main computer 2410 and executable by processing circuit 2418. Software 2411 includes main application 2412. Main application 2412 can operate to provide a service to a remote user, such as UE 2430, which connects via OTT connection 2450 terminating at UE 2430 and the main computer 2410. In providing the service to the remote user, main application 2412 can provide user data that is transmitted via OTT connection 2450. The communication system 2400 may also include the base station 2420 provided in a telecommunications system and comprising the hardware 2425 that enables it to communicate with the main computer 2410 and the UE 2430. The hardware 2425 may include the communication interface 2426 for configuring and maintaining a wired or wireless connection with an interface of a communication device other than the communication system 2400, as well as the radio interface 2427 for establishing and maintaining at least one wireless connection 2470 with the UE 2430 located within a coverage area (not shown in Figure 24) served by the base station 2420. The communication interface 2426 may be configured to facilitate the connection 2460 to the main computer 2410. The connection 2460 may be direct or it may 117 pass through a core network (not shown in Figure 24) of the telecommunications system and / or through one or more intermediate networks outside the telecommunications system. In the embodiment shown, the hardware 2425 of the base station 2420 may also include a processing circuit 2428, which may comprise one or more programmable processors, application-specific integrated circuits, field-programmable gate assemblies, or combinations thereof (not shown) adapted to execute instructions. The 2420 base station also includes software 2421 stored internally or accessible via an external connection. For example, the 2421 software may include program instructions (also called computer program product) that, when executed by the 2428 processing circuit, can configure the 2420 base station to perform operations corresponding to various example methods (e.g., procedures) described in this document. The communication system 2400 may also include the aforementioned UE 2430, whose hardware 2435 may include a radio interface 2437 configured to establish and maintain a wireless connection 2470 with a base station serving a coverage area in which the UE 2430 is currently located. The hardware 2435 of the UE 2430 may also include processing circuitry 2438, which may 118 comprising one or more programmable processors, application-specific integrated circuits, field-programmable gate assemblies, or combinations thereof (not shown) adapted to execute instructions. The UE 2430 also includes software 2431, which is stored in or accessible by the UE 2430 and executable by the processing circuit 2438. Software 2431 includes client application 2432. Client application 2432 can operate to provide a service to a human or non-human user through the UE 2430, with support from the main computer 2410. On the main computer 2410, a running main application 2412 can communicate with the running client application 2432 through the OTT connection 2450, which terminates at the UE 2430 and the main computer 2410. When providing the service to the user, client application 2432 can receive request data from the main application 2412 and provide user data in response to the request data. The OTT connection 2450 can transfer both the request data and the user data.The client application 2432 can interact with the user to generate the user data they provide. The software 2431 can also include program instructions (also called a computer program product) which, when executed by the processing circuit 2438, can configure the UE 2430 for carry. 119 Carry out operations corresponding to various example methods (e.g., procedures) described in this document. It can be observed that the main computer 2410, base station 2420, and UE 2430 illustrated in Figure 24 may be similar or identical to the main computer 1230, one of the base stations 1612a, 1612b, 1612c, and one of the UEs 1691, 1692 in Figure 16, respectively. That is, the internal operation of these entities may be as shown in Figure 24, and, regardless, the surrounding network topology may be that of Figure 16. In Figure 24, the OTT connection 2450 is drawn abstractly to illustrate communication between the host computer 2410 and the UE 2430 via the base station 2420, without explicit reference to any intermediary devices and the precise routing of messages through these devices. The network infrastructure can determine the routing, which can be configured to be hidden from the UE 2430, the service provider operating the host computer 2410, or both. While the OTT connection 2450 is active, the network infrastructure can make decisions that dynamically change the routing (for example, based on load balancing or network reconfiguration). The 2470 wireless connection between the UE 2430 and the 2420 base station is in accordance with the teachings of the 120 modes are described throughout this invention. One or more of the various modes enhance the performance of OTT services provided to the UE 2430 using the OTT connection 2450, in which the wireless connection 2470 forms the final segment. More precisely, the example modes described herein can improve the network's flexibility to monitor the end-to-end Quality of Service (QoS) of data streams, including their corresponding radio carriers, associated with data sessions between a user equipment (UE) and another entity, such as an OTT data application or a service external to the 5G network. These and other advantages can facilitate more timely design, implementation, and deployment of 5G / NR solutions. Furthermore, such modes can facilitate flexible and timely control of the data session's QoS, which can lead to improvements in capacity, performance, latency, etc.which anticipates 5G / NR and which are important for the growth of OTT services. A measurement procedure can be provided to monitor data rate, latency, and other operational aspects of the network where one or more modes are improved. Additionally, there may be optional network functionality to reconfigure the OTT 2450 connection between the 2410 host computer and the 2430 UE in response to variations in measurement results. The procedure The measurement and / or network functionality for reconfiguring the OTT connection 2450 can be implemented in the software 2411 and hardware 2415 of the main computer 2410 or in the software 2431 and hardware 2435 of the UE 2430, or both. In some modes, sensors (not shown) can be implemented in, or in association with, communication devices through which the OTT connection 2450 passes. The sensors can participate in the measurement procedure by providing values ​​of the monitored quantities exemplified above, or by providing values ​​of other physical quantities from which the software 2411, 2431 can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 2450 can include message format, relay settings, preferred routing, etc. The reconfiguration does not have to affect base station 2420, and may be unknown or imperceptible to base station 2420.These procedures and functionalities can be learned and practiced in the art. In certain modalities, the measurements may involve proprietary UE signaling that facilitates measurements of performance, propagation times, latency, and the like from the host computer 2410. The measurements may be implemented by having the software 2411 and 2431 transmit messages, in particular empty or 'fake' messages, using the OTT connection 2450 while monitoring times. 122 propagation, errors, etc. Figure 25 is a flowchart illustrating an example method and / or procedure implemented in a communication system, according to a specific modality. The communication system includes a main computer, a base station, and a UE, which, in some example modalities, may be those described with reference to other figures in this document. For the sake of simplicity, this section will only include references to the drawings in Figure 25. In step 2510, the main computer provides user data. In substep 2511 (which may be optional) of step 2510, the main computer provides the user data by executing a main application. In step 2520, the main computer initiates a transmission that carries the user data to the UE.In step 2530 (which may be optional), the base station transmits to the UE the user data that was carried in the transmission initiated by the host computer, according to the modalities described throughout this description. In step 2540 (which may also be optional), the UE runs a client application associated with the main application run by the host computer. Figure 26 is a flowchart illustrating an example method and / or procedure implemented in a system 123 of communication, according to one modality. The communication system includes a main computer, a base station, and a UE, which may be those described with reference to other figures in this document. To simplify the present invention, only references to the drawings in Figure 26 will be included in this section. In step 2610 of the method, the main computer provides user data. In an optional substep (not shown), the main computer provides the user data by executing a main application. In step 2620, the main computer initiates a transmission that carries the user data to the UE. The transmission may pass through the base station, according to the teachings of the modalities described throughout this description. In step 2630 (which may be optional), the UE receives the user data carried in the transmission. Figure 27 is a flowchart illustrating an example method and / or procedure implemented in a communication system, according to a modality. The communication system includes a main computer, a base station, and a UE, which may be those described with reference to other figures in this document. To simplify the present invention, this section will only include references to the drawings in Figure 27. In step 2710 (which may be optional), the UE receives input data provided by the 124 host computer. Alternatively, in step 2720, the UE provides user data. In substep 2721 (which may be optional) of step 2720, the UE provides the user data by running a client application. In substep 2711 (which may be optional) of step 2710, the UE runs a client application that provides the user data in response to input data received from the host computer. To provide the user data, the running client application may also consider user input received from the user. Regardless of the specific way in which the user data was provided, the UE initiates, in substep 2730 (which may be optional), the transmission of the user data to the host computer.In step 2740 of the method, the main computer receives the user data transmitted from the UE, in accordance with the teachings of the modalities described throughout this description. Figure 28 is a flowchart illustrating an example method and / or procedure implemented in a communication system, according to a modality. The communication system includes a main computer, a base station, and a UE, which may be those described with reference to other figures in this document. To simplify the present invention, this section will only include references to the 125 drawings of Figure 28. In step 2810 (which may be optional), in accordance with the teachings of the modalities described throughout this invention, the base station receives user data from the UE. In step 2820 (which may be optional), the base station initiates the transmission of the received user data to the main computer. In step 2830 (which may be optional), the main computer receives the user data carried in the transmission initiated by the base station. As described herein, the device and / or apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such a chip or chipset; however, this does not preclude the possibility that a device or apparatus's functionality, instead of being implemented in hardware, may be implemented as a software module, such as a computer program or a computer program product comprising portions of executable software code for execution on a processor. 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 several devices and / or apparatuses, either functionally cooperating or operating independently of one another. Moreover, devices and apparatuses may 126. These principles may be implemented in a distributed manner throughout a system, provided that the functionality of the device or apparatus is preserved. These and similar principles are considered to be known by an expert in the field. Furthermore, the functions described in this document as being performed by a wireless device or network node can be distributed among a plurality of wireless devices and / or network nodes. In other words, the network node and wireless device functions described in this document are not limited to the performance of a single physical device and can, in fact, be distributed among several physical devices. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by a person skilled in the art to which this invention pertains. It is further understood that terms used herein should be interpreted in a way that is consistent with their meaning in the context of this specification and the relevant art, and not in an idealized or overly formal sense unless expressly defined herein. Furthermore, certain terms used in the present invention, including the specification, drawings, and exemplary embodiments thereof, may be used as 127 synonyms in certain cases, including, but not limited to, data and information. It should be understood that, while these words and / or other words that may be synonymous with each other may be used as synonyms in this document, there may be instances where such words are not intended to be used as synonyms. Furthermore, to the extent prior art knowledge has not been explicitly incorporated by reference herein, it is explicitly incorporated herein in its entirety. All publications referenced herein are incorporated herein by reference in their entirety. As used in this document, unless expressly stated otherwise, the phrases "at least one of" and "one or more of," followed by a joint list of enumerated items (e.g., A and B, A, B, and C), are intended to mean at least one item, with each item selected from the list consisting of the enumerated items. For example, "at least one of A and B" means any of the following: A; B; A and B. Likewise, "one or more of A, B, and C" means any of the following: A; B; C; A and B; B and C; A and C; A, B, and C. As used in this document, unless expressly stated otherwise, the phrase "a plurality of" followed by a joint list of enumerated items (e.g., A and B, A, B and C) is intended to mean several items, with each item selected from the list consisting of the 128 items listed. For example, a plurality of A and B means any of the following: more than one A; more than one B; or at least one A and at least one B. The foregoing merely illustrates the principles of the invention. Several modifications and alterations to the described embodiments will be evident to those skilled in the art in view of the teachings of this document. It will therefore be appreciated that those skilled in the art may devise numerous systems, arrangements, and procedures which, although not explicitly shown or described herein, incorporate the principles of the invention and may thus be within the spirit and scope of the present invention. Several exemplary embodiments may be used together, as well as interchangeably with each other, as those skilled in the art should understand.

Claims

1. A method carried out by an anchor function for application authentication and key management (AAnF) in a communication network, the method comprising: receiving, from an application function, a request for a security key (Kaf) specific to an application session for a particular user, wherein the request comprises a representation of the following information associated with the particular user: a first identifier (KakmaID) of an application-non-specific anchor security key (Kakma), and a second identifier related to a network subscription; and based on the representation, determining an authentication server function (AUSF) that generated the application-non-specific anchor security key (Kakma).

2. The method according to claim 1, further comprising: obtaining the application-nonspecific anchor security key (Kakma) from the determined AUSF; and generating the application-session-specific security key (Kaf) based on the application-nonspecific anchor security key (Kakma). inaLa / a / zuzz / uii 130 3. The method according to any of claims 1-2, wherein: the representation comprises a third identifier (B-ID) of a link between the application-nonspecific anchor security key (Kakma) and the AUSF that generated Kakma; and the third identifier comprises: the representation of the first and second identifiers, and information associated with the AUSF.

4. The method according to claim 3, wherein the information associated with the AUSF comprises one or more of the following: AUSF group ID, AUSF ID, Subscription Permanent Identifier (SUPI) range, fully qualified domain name (FQDN), IP address.

5. The method according to any of claims 3-4, wherein determining the AUSF that generated the application-nonspecific anchor security key (Kakma) comprises discovering an AUSF identity, through a network repository function (NRF), based on information associated with the AUSF.

6. The method according to any of claims 3-5, wherein obtaining the application-nonspecific anchor security key (Kakma) from the specified AUSF comprises: sending, to the specified AUSF, a request that includes the third identifier; and receiving, from the specified AUSF, a response that includes the application-nonspecific anchor security key (Kakma) and the second identifier.

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

8. The method according to claim 7, wherein the second identifier comprises one of the following: HPLMN ID and User Equipment Routing Identifier (RID); Hidden Subscription Identifier (SUCI); Permanent Subscription Identifier (SUPI); or Generic Public Subscription Identifier (GPSI).

9. The method according to any of claims 7-8, wherein determining the AUSF comprises: selecting a unified data management (UDM) function, in the communication network, based on the second identifier; 132 sending to the UDM a first request for a fourth identifier associated with the AUSF; and receiving, from the UDM, a first response that includes the fourth identifier.

10. The method according to claim 9, wherein the first response also includes a second additional identifier related to the network subscription associated with the particular user.

11. The method according to any of claims 9-10, wherein obtaining the application-nonspecific anchoring security key (Kakma) comprises: sending, to the AUSF associated with the fourth identifier, a second request comprising the second identifier or an additional second identifier related to the network subscription associated with the particular user; and receiving, from the AUSF, a second response including the application-nonspecific anchoring security key (Kakma).

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

13. The method according to any of claims 10 or 12, wherein: the second additional identifier is a permanent subscription identifier (SUPI); and the second identifier is a non-SUPI identifier.

14. The method in accordance with any of claims 1-13, further comprising sending, to the application function, the application session-specific security key (Kaf).

15. A method, carried out by a key management server in a communications network, wherein the method comprises: receiving, from an authentication server function (AUSF), the following information associated with a particular user: an application-nonspecific anchor security key (Kakma); a first identifier (KakmaID) of the application-nonspecific anchor security key; and a second identifier related to a network subscription; receiving, from an application function, a request for an application session-specific security key (Kaf) for the particular user, wherein the request comprises an additional identifier (KakmaID) of an application-nonspecific anchor security key associated with the particular user;and based on a match between the first identifier and the additional identifier, generating the application session-specific security key (Kaf) based on the non-application-specific anchor security key (Kakma).; 16. The method according to claim 15, wherein: the key management server comprises a plurality of anchoring functions for application authentication and key management (AAnF) instances, wherein each AAnF instance corresponds to a range of user equipment routing indicators (RIDs); the request also includes a routing indicator (RID) associated with the particular user; the method further comprises selecting an AAnF instance based on the received RID; and the generation of the application session-specific security key (Kaf) is carried out by the selected AAnF instance.

17. The method in accordance with any of claims 15-16, wherein the second identifier is a permanent subscription identifier (SUPI).

18. The method according to any of claims 15-17, wherein: the key management server is associated with one or more user equipment routing indicator (RID) ranges; and the method further comprises registering an association between the key management server and one or more ranges with a network repository function (NRF) in the communication network.

19. A method carried out by an application function in a communication network, wherein the method comprises: receiving, from a user computer, a first request to establish an application session, wherein the first request comprises a representation of the following information associated with the particular user: a first identifier (KakmaID) of an application-nonspecific anchoring security key (Kakma), and a second identifier related to a network subscription; sending, to an application authentication and key management anchoring function (AAnF) in the communication network, a second request for an application session-specific security key (Kaf), wherein the second request comprises the representation of the first and second identifiers; and receiving, from the AAnF, the application session-specific security key (Kaf).

20. The method according to claim 19, wherein: the representation comprises a third identifier (B-ID) of a link between the application-nonspecific anchor security key (Kakma) and the AUSF that generated Kakma; and the third identifier comprises: the representation of the first and second identifiers, and information associated with the AUSF.

21. The method according to claim 20, wherein the information associated with the AUSF comprises one or more of the following: AUSF group ID, AUSF ID, Subscription Permanent Identifier (SUPI) range, fully qualified domain name (FQDN), IP address.

22. The method according to claim 19, wherein the representation comprises one of the following: the first identifier and the second identifier; or the first identifier, which includes a representation of the second identifier.

23. The method according to claim 137 22, wherein the second identifier comprises one of the following: HPLMN ID and user equipment routing identifier (RID); hidden subscription identifier (SUCI); permanent subscription identifier (SUPI); or generic public subscription identifier (GPSI).

24. The method in accordance with any of claims 19-23, further comprising establishing a secure application session with the user's equipment based on the received security key (Kaf).

25. A method carried out by an Authentication Server Function (AUSF) in a communication network, wherein the method comprises: receiving, from an Application Authentication and Key Management Anchor Function (AAnF) in the communication network, a request for an Application Non-Specific Anchor Security Key (Kakma) for a particular user, wherein the request comprises a first representation of the following: the first identifier (KakmaID) associated with the Application Non-Specific Anchor Security Key (Kakma), and a second identifier related to a subscription to the particular user's network; and sending, to the AAnF, a response that includes the requested Application Non-Specific Anchor Security Key (Kakma).

26. The method according to claim 25, further comprising: creating the application-nonspecific anchor security key (Kakma) and the first associated identifier (KakmaID); and sending, to a unified data management (UDM) function in the communication network, a fourth identifier (AUSFID) associated with the AUSF and a second representation of at least the first identifier (KakmaID).

27. The method according to claim 26, wherein: the first and second representations include a third identifier (B-ID) of a link between the application-nonspecific anchor security key (Kakma) and the AUSF that generated Kakma; and the third identifier comprises: a representation of the first and second identifier, and information associated with the AUSF.

28. The method according to claim 27, wherein the information associated with the AUSF comprises one or more of the following: AUSF group ID, AUSF ID, Subscription Permanent Identifier (SUPI) range, fully qualified domain name (FQDN), IP address.

29. The method in accordance with any of claims 27-28, wherein the response also comprises a permanent subscription identifier (SUPI) associated with the particular user.

30. The method according to claim 26, wherein: the second representation comprises the first identifier; and the first representation comprises the first identifier and the second identifier.

31. The method according to any of claims 25-30, wherein the second identifier comprises one of the following: HPLMN ID and User Equipment Routing Identifier (RID); Hidden Subscription Identifier (SUCI); Permanent Subscription Identifier (SUPI); or Generic Public Subscription Identifier (GPSI).

32. A method carried out by an Authentication Server Function (AUSF) in a communication network, wherein the method comprises: 140 creating an application-nonspecific anchor security key (Kakma) for a particular user, wherein the application-nonspecific anchor security key is associated with a first identifier (KakmaID); and based on a second identifier related to a subscription to the particular user's network, selecting an application authentication and key management anchor function (AAnF) in the communication network associated with the particular user.

33. The method according to claim 32, further comprising sending the following information to the identified AAnF: the application-non-specific anchoring security key (Kakma) for the particular user, the first identifier (KakmaID), and the second identifier related to the particular user's network subscription.

34. A method carried out by a unified data management (UDM) function in a communication network, wherein the method comprises: receiving, from an authentication server function (AUSF) in the communication network, a fourth identifier (AUSFID) associated with the AUSF and a first identifier (KakmaID) associated with an application-nonspecific anchor security key (Kakma) for a particular user 141; receiving, from an application authentication and key management anchor function (AAnF) in the communication network, a request for the fourth identifier; and sending, to the AAnF, a response comprising the fourth identifier.

35. The method according to claim 34, wherein: the request comprises the first identifier; and the response also includes a second identifier related to a network subscription associated with the particular user.

36. The method according to claim 35, wherein the first identifier (KakmaID) includes a representation of the second identifier.

37. The method according to claim 35, wherein: the application comprises a second additional identifier related to the subscription to the network associated with the particular user; and the method further comprises determining the second identifier based on the second additional identifier.

38. The method according to claim 37, wherein: the second identifier is a permanent subscription identifier (SUPI); and the second additional identifier is a non-SUPI identifier.

39. The method according to any of claims 34-38, wherein: the AUSF comprises a plurality of AUSF instances, each AUSF instance corresponding to a range of identifiers associated with network subscriptions; the method further comprises selecting a particular AUSF instance based on the second identifier; and the fourth identifier corresponds to the selected AUSF instance.

40. A key management function in a communication network, wherein the key management function comprises: interface circuits configured to communicate with at least one application function and one authentication server function (AUSF) in the communication network; and a processing circuit operatively coupled to the interface circuit, wherein the processing circuit and the interface circuit are configured to carry out operations corresponding to any of the methods in accordance with claims 1-18.

41. A key management function in a communications network, wherein the key management function 143 is arranged to carry out operations corresponding to any of the methods in accordance with claims 1-18.

42. A non-transient, computer-readable medium that stores computer-executable instructions that, when executed by processing circuits associated with a key management function in a communication network, configure the key management function to carry out operations corresponding to any of the methods in accordance with claims 1-18.

43. A computer program product comprising computer-executable instructions that, when executed by processing circuits associated with a key management function in a communication network, configure the key management function to carry out operations corresponding to any of the methods according to claims 1-18.

44. An application function in a communication network, wherein the application function comprises: interface circuits configured to communicate with at least one key management function in the communication network and with a user device; and a processing circuit operatively coupled to the interface circuit, wherein the processing circuit and the interface circuit are configured to perform operations corresponding to any of the methods in accordance with claims 19-24.

45. An application function in a communications network, wherein the application function is arranged to carry out operations corresponding to any of the methods in accordance with claims 19-24.

46. ​​A non-transient, computer-readable medium that stores computer-executable instructions that, when executed by processing circuits associated with an application function in a communication network, configure the application function to carry out operations corresponding to any of the methods in accordance with claims 19-24.

47. A computer program product comprising computer-executable instructions that, when executed by processing circuits associated with an application function in a communication network, configure the application function to carry out operations corresponding to any of the methods in accordance with claims 19-24.

48. An Authentication Server Function (AUSF) in a communication network, wherein the AUSF comprises: interface circuits configured to communicate with at least one key management function and one unified data management (UDM) function in the communication network and with a user device; and a processing circuit operatively coupled to the interface circuit, wherein the processing circuit and the interface circuit are configured to carry out operations corresponding to any of the methods in accordance with claims 25-33.

49. An authentication server function (AUSF) in a communications network, wherein the AUSF is arranged to carry out operations corresponding to any of the methods in accordance with claims 25-33.

50. A non-transient, computer-readable medium that stores computer-executable instructions that, when executed by processing circuits associated with an Authentication Server Function (AUSF) in a communication network, configure the AUSF to carry out operations corresponding to any of the methods in modalities 25-33.

51. A computer program product comprising computer-executable instructions that, when executed by processing circuits associated with an authentication server function (AUSF) in a communication network, configure the AUSF to perform operations corresponding to any of the methods in accordance with claims 25-33. 146 52. A unified data management (UDM) function in a communication network, wherein the UDM function comprises: interface circuits configured to communicate with at least one key management function and one authentication server function (AUSF) in the communication network; and a processing circuit operatively coupled to the interface circuit, wherein the processing circuit and the interface circuit are configured to carry out operations corresponding to any of the methods in accordance with claims 34-39.

53. A unified data management (UDM) function in a communications network, wherein the UDM function is arranged to carry out operations corresponding to any of the methods in accordance with claims 34-39.

54. A non-transient, computer-readable medium that stores computer-executable instructions that, when executed by processing circuits associated with a unified data management (UDM) function in a communication network, configure the UDM function to carry out operations corresponding to any of the methods in accordance with claims 34-39.

55. A computer program product comprising 147 computer-executable instructions that, when executed by a processing circuit associated with a unified data management (UDM) function in a communication network, configure the UDM function to carry out operations corresponding to any of the methods in accordance with claims 34-39.

Images