Selection of Authentication Server Function in Authentication and Key Management

Abstract

To provide a method for authentication and key management, more particularly, related to secure use of applications in communication networks.SOLUTION: A method performed by a key management node in a communication network includes: receiving, from an application function, a request for a security key specific to an application session for a specific user, the request including a representation of a first identifier for an anchor security key that is not unique to the application and a second identifier related to a network subscription, which are information relevant to the specific user; and identifying an authentication server function that has generated the anchor security key that is not unique to the application based on the representation.SELECTED DRAWING: Figure 14

Description

Technical Field

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

Background Art

[0002] Long Term Evolution (LTE) is an umbrella term for so-called fourth-generation (4G) wireless access technologies that were developed within the Third Generation Partnership Project (3GPP) and first standardized in Releases 8 and 9, also known as evolved UTRAN (E-UTRAN). LTE targets various licensed frequency bands and involves improvements to the non-radio part, generally called System Architecture Evolution (SAE), which includes an evolved packet core (EPC) network. LTE has continued to evolve through subsequent releases. One of the features of Release 11 is the enhanced physical downlink control channel (ePDCCH). The ePDCCH aims to increase capacity, improve spatial reuse of control channel resources, improve inter-cell interference coordination (ICIC), and support antenna beamforming and / or transmit diversity for control channels.

[0003] An overall exemplary architecture of a network with LTE and SAE is shown in FIG. 1. The E-UTRAN 100 includes one or more evolved Node Bs (eNBs) such as eNBs 105, 110, and 115, and one or more user equipments (UEs) such as UE 120. The "user equipment" or "UE" used in 3GPP specifications means any wireless communication device (such as a smartphone or a computing device) that can communicate with network equipment compliant with 3GPP specifications, including E-UTRAN, UTRAN, and / or GERAN, as generally known as third-generation (3G) and second-generation (2G) 3GPP radio access networks.

[0004] As defined by 3GPP, E-UTRAN 100 is responsible for all radio-related functions within the network, including radio bearer control, radio admission control, radio mobility control, scheduling, and dynamic allocation of resources to the UE in the uplink and downlink, as well as the security of communication with the UE. These functions are present in eNBs such as eNB 105, 110, and 115. As shown in FIG. 1, the eNBs within E-UTRAN communicate with each other via the X1 interface. The eNBs also have an E-UTRAN interface to the EPC 130, specifically the S1 interface to the Mobility Management Entity (MME) and Serving Gateway (SGW), which are generically shown as MME / S-GW 134 and 138 in FIG. 1. Generally, the MME / S-GW processes both the overall control of the UE and the data flow between the UE and the rest of the EPC. More specifically, the MME processes the signaling (e.g., control plane) protocol between the UE and the EPC, known as the Non-Access Stratum (NAS) protocol. The S-GW processes all Internet Protocol (IP) data packets (e.g., data or user plane) between the UE and the EPC and functions as a local mobility anchor for the data bearer when the UE moves between eNBs such as eNB 105, 110, and 115.

[0005] The EPC 130 can also include a Home Subscriber Server (HSS) 131 that manages user and subscriber-related information. The HSS 131 can also provide support functions in mobility management, call and session setup, user authentication, and access authorization. The functions of the HSS 131 can be related to the functions of a legacy Home Location Register (HLR) and the functions or operations of an Authentication Center (AuC).

[0006] In some embodiments, the HSS 131 can communicate with the user data repository (UDR) labeled with the EPC-UDR 135 of FIG. 1 via the Ud interface. The EPC-UDR 135 can store user authentication information encrypted by the AuC algorithm. These algorithms are not standardized (i.e., vendor-specific), and the encrypted credentials stored in the EPC-UDR 135 are inaccessible by any vendor other than the vendor of the HSS 131.

[0007] In 3GPP, the study items regarding the new radio interface of the 5th generation (5G) cellular (e.g., wireless) network have been completed, and 3GPP is promoting the standardization of this new radio interface, which is often abbreviated as NR (New Radio). FIG. 2 shows a high-level view of the 5G network architecture consisting of the next-generation RAN (NG-RAN) 299 and the 5G core (5GC) 298. The NG-RAN 299 can include a set of gNodeBs (gNBs) connected to the 5GC via one or more NG interfaces, such as the gNBs 200 and 250 connected via the interfaces 202 and 252, respectively. Further, the gNBs can be connected to each other via one or more Xn interfaces, such as the Xn interface 240 between the gNBs 200 and 250. Regarding the NR interface to the UE, each of the gNBs can support frequency division multiplexing (FDD), time division multiplexing (TDD), or a combination thereof.

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

[0009] The NG RAN logical nodes 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, gNB200 includes gNB-CU210, gNB-DU220, and 230. The CU (e.g., gNB-CU210) is a logical node that hosts upper layer protocols and performs various gNB functions such as controlling the operation of the DUs. Each DU is a logical node that hosts lower layer protocols and can include various subsets of gNB functions depending on the function split. Thus, each of the CU and DU can include various circuits necessary to perform its functions, including processing circuits, transceiver circuits (e.g., for communication), and power supply circuits. Further, the terms "Central Unit" and "centralized unit" are used interchangeably herein, and the same is true for the terms "Distributed Unit" and "decentralized unit".

[0010] The gNB-CU is connected to the gNB-DU via respective F1 logical interfaces such as interfaces 222 and 232 shown in FIG. 3. The gNB-CU and the connected gNB-DU are recognized by other gNBs and the 5GC only as a gNB. That is, the F1 interface in front of the gNB-CU is not recognized (invisible).

[0011] FIG. 3 shows a high-level view of an exemplary 5G network architecture including a Next Generation Radio Access Network (NG-RAN) 399 and a 5G Core (5GC) 398. As shown in the figure, the NG-RAN 399 can include gNBs 310 (e.g., 310a, b) and ng-eNBs 320 (e.g., 320a, b) that are interconnected via respective Xn interfaces. The gNBs and ng-eNBs are also connected to the 5GC 398 via the NG interface. More specifically, the gNBs and ng-eNBs are connected to the Access and Mobility Management Function (AMF) 330 (e.g., AMF 330a, b) via respective NG-C interfaces and to the User Plane Function (UPF) 340 (e.g., UPF 340a, b) via respective NG-U interfaces. Further, the AMF 340a, b can communicate with one or more Policy Control Functions (PCF, e.g., PCF 350a, b) and Network Exposure Functions (NEF, e.g., NEF 360a, b). The AMF, UPF, PCF, and NEF will be further described below.

[0012] Each of the gNBs 310 can support an NR radio interface including Frequency Division Duplexing (FDD), Time Division Duplexing (TDD), or a combination thereof. In contrast, each of the ng-eNBs 320 supports an LTE radio interface and is connected to the 5GC via the NG interface, unlike a conventional LTE eNB (as shown in FIG. 1).

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

[0014] Another change in the 5G network (e.g., in 5GC) is that traditional peer-to-peer interfaces and protocols (such as those found in the LTE / EPC network) are being changed by the so-called service-based architecture (SBA) where a network function (NF) provides one or more services to one or more service consumers. This can be done, for example, by HTTP / REST (Hyper Text Transfer Protocol / Representational State Transfer) application programming interfaces (APIs). Generally, various services are self-contained functions and can be changed and modified in a separated way without affecting other services.

[0015] Furthermore, a service is composed of various "service operations", which are finer-grained divisions of the entire service function. To access a service, it is necessary to specify both the service name and the target service operation. The interaction between a service consumer and a producer can be of the type "request / response" or "subscription / notification". In the 5G SBA, the Network Repository Function (NRF) enables all network functions to discover services provided by other network functions, and the Data Storage Function (DSF) enables all network functions to store their context.

[0016] As described above, a service can be deployed as part of a network function (NF) in the 5G SBA. This SBA model further adopts principles such as modularity, reusability, and self-containment of NFs, enabling deployment leveraging the latest virtualization and software technologies. Figure 4 shows an exemplary non-roaming 5G reference architecture with service-based interfaces within the control plane (CP) and various NFs defined by 3GPP. These include the following NFs, and for those most relevant to this disclosure, a more detailed description will be provided. · Access and Mobility Management Function (AMF) with the Namf interface: Terminates the RAN CP interface and handles all mobility and connection management of the UE (similar to the MME in the EPC). · Session Management Function (SMF) with the Nsmf interface: Interacts with the separated user (or data) plane, including creation, update, and deletion of Protocol Data Unit (PDU) sessions and management of session contexts with User Plane Function (UPF), for example, for event reporting. · User Plane Function (UPF) with the Nupf interface: Supports the processing of user plane traffic based on rules received from the SMF, including packet inspection and various enforcement operations (e.g., event detection and reporting). ·Policy Control Function (PCF) with the Npcf interface: Supports a unified policy framework for managing network behavior, for example, by providing PCC rules to the SMF. ·Network Exposure Function (NEF) with the Nnef interface: Functions as an entry point to the operator's network by securely exposing network capabilities and events provided by 3GPP NFs to the AF, and by providing a way for the AF to securely provide information to the 3GPP network. ·Network Repository Function (NRF) with the Nnrf interface: Provides service registration and discovery, enabling NFs to identify appropriate services available from other NFs. ·Network Slice Selection Function (NSSF) with the Nnssf interface: A "network slice" is, for example, a logical partition of the 5G network that provides specific network capabilities and characteristics in support of a particular service. A network slice instance is a set of NF instances and the network resources (e.g., computing, storage, communication) required to provide the capabilities and characteristics of the network slice. The NSSF enables other NFs (e.g., the AMF) to identify the network slice instance appropriate for the services desired by the UE. ·Authentication Server Function (AUSF) with the Nausf interface: Performs user authentication and calculates security key material for various purposes based on the user's home network (HPLMN). ·Application Function (AF) with the Naf interface: Communicates with the 3GPP CN to provide information to the network operator and subscribe to specific events occurring in the operator's network.

[0017] The integrated data management (UDM) function shown in Figure 4 is similar to the HSS in the above-described LTE / EPC network. The UDM supports the generation of 3GPP AKA authentication credentials, user identification processing, access authorization based on subscription data, and other subscriber-related functions. To provide this function, the UDM uses the subscription data (including authentication data) stored in the 5GC integrated data repository (UDR). In addition to the UDM, the UDR supports the storage and retrieval of policy data by the PCF, as well as the storage and retrieval of application data by the NEF.

[0018] 3GPP Rel-16 introduces a new function called authentication and key management for applications (AKMA) based on 3GPP user credentials in 5G, including IoT use cases. More specifically, AKMA utilizes the user's AKA (authentication and key agreement) certificate to bootstrap the security between the UE and the application function (AF), enabling the UE to securely exchange data with the application server. The AKMA architecture can be regarded as an evolution of the Generic Bootstrapping Architecture (GBA) defined for 5GC in 3GPP Rel-15 and further defined in 3GPP TS 33.535 (v.0.2.0 under revision).

[0019] In addition to the NEF, AUSF, and AF shown and described above in Figure 4, Rel-16 AKMA also utilizes an anchor function for authentication and key management for applications (AAnF). This function is shown in Figure 4 by the Naanf interface. Generally, the AAnF communicates with the AUSF and holds the UE AKMA context for use, for example, in subsequent bootstrap requests by the application function. Generally, the AAnF is similar to the bootstrapping server function (BSF) defined in Rel-15 GBA.

[0020] However, in this architecture, there can be various problems, issues, and / or difficulties regarding the synchronization between the key material generated by the AUSF for a certain user and the key material used by the AAnF to generate an application-specific key for that user's application session. Such problems, issues, and / or difficulties can prevent the establishment of secure communication between a user application (e.g., running on a UE) and the corresponding application function (e.g., a server). SUMMARY OF THE INVENTION

[0021] Certain embodiments of the present disclosure provide a distinct improvement to secure communication between an application (e.g., a client) and an application function (e.g., a server), such as by facilitating solutions to overcome the exemplary problems summarized above and described in more detail below.

[0022] Exemplary embodiments include a method (e.g., a procedure) executed by a key management server (e.g., the AAnF) in a communication network (e.g., 5GC). These embodiments can include receiving, from an application function, a request for a security key (Kaf) specific to an application session for a particular user. The request can include an expression of the following information associated with the particular user, namely a first identifier (KakmaID) of an anchor security key (Kakma) that is not application-specific and a second identifier regarding network subscription. These exemplary methods can also include identifying, based on the expression, an authentication server function (AUSF) that generated the anchor security key (Kakma) that is not application-specific.

[0023] In some embodiments, these exemplary methods may also include obtaining an anchor security key (Kakma) that is not application-specific from a specified AUSF, and generating a security key (Kaf) specific to an application session based on the anchor security key (Kakma) that is not application-specific. In some embodiments, these exemplary methods may also include sending a security key specific to an application session (Kaf) to an application function.

[0024] In some embodiments, the representation may include a third identifier (B-ID) of the binding between the anchor security key (Kakma) that is not application-specific and the AUSF that generated the Kakma. The third identifier may include the representations of the first and second identifiers and information related to the AUSF. In various embodiments, the information associated with the AUSF may include one or more of an AUSF group ID, an AUSF ID, a subscription permanent identifier (SUPI) range, a fully qualified domain name (FQDN), and an IP address.

[0025] In such embodiments, the specific operation may include discovering the identification information of the AUSF using a network repository function (NRF) based on the information related to the AUSF. Further, in such embodiments, the obtaining operation may include sending a request including the third identifier (e.g., B-TID) to the specified AUSF, and receiving a response including the anchor security key (Kakma) that is not application-specific and the second identifier from the specified AUSF.

[0026] In other embodiments, the representation of the first and second identifiers can include the first identifier (e.g., KakmaID) and the second identifier. For example, the second identifier can be any one of an HPLMN ID and a user equipment routing identifier (RID), a subscription concealment identifier (SUCI), a subscription permanent identifier (SUPI), or a general public subscription identifier (GPSI). In a variant, the representation can include only the first identifier (e.g., KakmaID), and the first identifier can include the representation of the second identifier.

[0027] In such embodiments, a specific operation can include selecting an integrated data management (UDM) function in a communication network based on the second identifier, sending a first request for a fourth identifier associated with the AUSF to the UDM, and receiving a first response including the fourth identifier from the UDM. In some embodiments, the first response can also include a further second identifier related to a network subscription associated with a specific user. For example, the further second identifier can be a SUPI, and the second identifier can be an identifier other than a SUPI (e.g., GPSI, SUCI, HPLMN+RID).

[0028] In such embodiments, an acquisition operation can include sending a second request having the second identifier or a further second identifier related to a network subscription associated with a specific user to the AUSF associated with the fourth identifier, and receiving a second response including an anchor security key (Kakma) that is not specific to an application from the AUSF. In some embodiments, either the second request or the second response can also include the second identifier. For example, if the second request includes a further second identifier (e.g., SUPI), the second response can include an identifier other than the second identifier (e.g., SUPI).

[0029] Exemplary embodiments also include another method (e.g., procedure) executed by a key management server (e.g., AAnF) in a communication network (e.g., 5GC). These exemplary methods can include receiving, from an authentication server function (AUSF), information associated with a particular user, namely, an anchor security key (Kakma) not specific to an application, a first identifier of the anchor security key not specific to the application (KakmaID), and a second identifier related to network subscription. In some embodiments, the second identifier can be a subscription permanent identifier (SUPI).

[0030] These exemplary methods can also include receiving, from an application function, a request for a security key (Kaf) specific to an application session for a particular user, the request having a further identifier (KakmaID) of the anchor security key not specific to the application associated with the particular user. The request can include a further identifier (KakmaID) of the anchor security key not specific to the application associated with the particular user. These exemplary methods can also include generating, based on a match between the first identifier and the further identifier (e.g., a matching KakmaID), a security key (Kaf) specific to the application session based on the anchor security key (Kakma) not specific to the application.

[0031] In some embodiments, the key management server can include multiple instances of an anchor function (AAnF) for authentication and key management for an application, each AAnF instance corresponding to a range of user equipment routing indicators (RID). In such embodiments, the request can also include a routing indicator (RID) associated with a particular user, and these exemplary methods can also include selecting an AAnF instance based on the received RID, and generating the security key (Kaf) specific to the application session is performed by the selected AAnF instance.

[0032] In some embodiments, a key management server may be associated with one or more ranges of user equipment routing indicators (RIDs). In such embodiments, these exemplary methods may also include registering with a network repository function (NRF) within a communication network an association between the key management server and one or more ranges.

[0033] Exemplary embodiments also include methods (e.g., procedures) performed by an application function within a communication network (e.g., 5GC). These exemplary methods may include receiving, from a user equipment, a first request for establishment of an application session. The first request may include an expression of information associated with a particular user, namely, a first identifier (KakmaID) of an anchor security key (Kakma) that is not specific to the application and a second identifier regarding network subscription. These exemplary methods may also include sending, to an anchor function (AAnF) for authentication and key management for the application within the communication network, a second request for a security key (Kaf) specific to the application session. The second request may include an expression of the first and second identifiers.

[0034] These exemplary methods may also include receiving, from the AAnF, a security key (Kaf) specific to the application session. In some embodiments, these exemplary methods may also include establishing a secure application session with the user equipment based on the received security key (Kaf).

[0035] In some embodiments, the representation has a third identifier (B-ID) of the binding between the anchor security key (Kakma) that is not specific to the application and the AUSF that generated the Kakma. In particular, the third identifier can include the representations of the first and second identifiers and the information associated with the AUSF. In various embodiments, the information associated with the AUSF can include one or more of an AUSF group ID, an AUSF ID, a subscription permanent identifier (SUPI) range, a fully qualified domain name (FQDN), and an IP address.

[0036] In other embodiments, the representations of the first and second identifiers can include the first identifier and the second identifier. For example, the second identifier can be any one of an HPLMN ID and a user equipment routing identifier (RID), a subscription concealment identifier (SUCI), a subscription permanent identifier (SUPI), or a generic public subscription identifier (GPSI). In a variant, the representation can include only the first identifier (e.g., KakmaID), and the first identifier includes the representation of the second identifier.

[0037] Exemplary embodiments also include a method (e.g., a procedure) performed by an authentication server function (AUSF) in a communication network (e.g., 5GC). These exemplary methods can include receiving, from an anchor function (AAnF) for authentication and key management for an application in the communication network, a request for an anchor security key (Kakma) that is not specific to the application for a particular user. The request can include a first representation of a first identifier (KakmaID) associated with the anchor security key (Kakma) that is not specific to the application and a second identifier associated with the network subscription of the particular user. These exemplary methods can also include sending a response including the requested anchor security key (Kakma) that is not specific to the application to the AAnF.

[0038] In some embodiments, these exemplary methods can include creating an anchor security key (Kakma) and a first identifier (KakmaID) that are not specific to an application for a particular user, and transmitting to an integrated data management (UDM) function within a communication network a fourth identifier (AUSFID) associated with an AUSF and at least a second representation of the first identifier (KakmaID).

[0039] In some embodiments, the first and second representations can include a third identifier (B-ID) of a binding between an anchor security key (Kakma) that is not specific to an application and the AUSF that generated the Kakma. In particular, the third identifier can include the representations of the first and second identifiers and information associated with the AUSF. In various embodiments, the information associated with the AUSF can include one or more of an AUSF group ID, an AUSF ID, a subscription permanent identifier (SUPI) range, a fully qualified domain name (FQDN), an IP address. In such embodiments, the response can further include a subscription permanent identifier (SUPI) associated with a particular user.

[0040] In other embodiments, the first representation of the first and second identifiers can include the first identifier (e.g., KakmaID) and the second identifier, while the second representation can include only the first identifier. In such embodiments, the second identifier can be any one of an HPLMN ID and a user equipment routing identifier (RID), a subscription concealment identifier (SUCI), a subscription permanent identifier (SUPI), or a general public subscription identifier (GPSI). In a variation, the first representation can include only the first identifier, and the first identifier can include a representation of the second identifier.

[0041] Exemplary embodiments also include another method (e.g., procedure) performed by an authentication server function (AUSF) in a communication network (e.g., 5GC). These exemplary methods can include creating an anchor security key (Kakma) that is not specific to an application for a particular user, and the anchor security key that is not specific to an application is associated with a first identifier (KakmaID). These exemplary methods can also include selecting, based on a second identifier related to a particular user's network subscription, an anchor function (AAnF) for authentication and key management for an application within the communication network that is associated with the particular user. In some embodiments, these exemplary methods can also include sending information including the anchor security key (Kakma) that is not specific to an application for a particular user, the first identifier (KakmaID), and the second identifier related to the particular user's network subscription to the identified AAnF. In various embodiments, the second identifier can be a subscription permanent identifier (SUPI) associated with a particular user.

[0042] Exemplary embodiments also include a method (e.g., procedure) performed by an integrated data management (UDM) function in a communication network (e.g., 5GC). These exemplary methods can include receiving, from an authentication server function (AUSF) within the communication network, a fourth identifier (AUSFID) associated with the AUSF and a first identifier (KakmaID) associated with an anchor security key (Kakma) that is not specific to an application for a particular user. These exemplary methods can also include receiving a request for the fourth identifier from an anchor function (AAnF) for authentication and key management for an application within the communication network. These exemplary methods can also include sending a response having the fourth identifier to the AAnF.

[0043] In some embodiments, the request can include a first identifier (KakmaID), and the response can include a second identifier related to a network subscription associated with a particular user. In some of these embodiments, the first identifier can include a representation of the second identifier. In other embodiments of these, the request can include a further second identifier related to a network subscription associated with a particular user. In such embodiments, these exemplary methods can also include determining the second identifier based on the further second identifier. For example, the second identifier can be a Subscription Permanent Identifier (SUPI), and the further second identifier can be an identifier other than SUPI (e.g., SUCI, GPSI).

[0044] In various embodiments, the AUSF can include multiple AUSF instances, and each AUSF instance corresponds to a range of identifiers (e.g., RID, SUPI, etc.) associated with network subscriptions. In such embodiments, these exemplary methods can also include selecting a particular AUSF instance based on the second identifier. In such embodiments, a fourth identifier can correspond to the selected AUSF instance.

[0045] Exemplary embodiments also include a key management server (e.g., AAnF), an application function, an Authentication Server Function (AUSF), and an Unified Data Management (UDM) function within a communication network (e.g., 5GC) configured to perform operations (e.g., using a processing circuit) corresponding to any of the exemplary methods described herein.

[0046] Exemplary embodiments also include a non - transitory computer - readable medium storing computer - executable instructions that, when executed by a processing circuit associated with such key management server, application function, AUSF, and UDM function, configure them to perform operations corresponding to any of the exemplary methods described herein.

[0047] These and other objects, features, and advantages of the embodiments of the present disclosure will become apparent by reading the following detailed description with reference to the drawings briefly described below.

Brief Description of the Drawings

[0048]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Best Mode for Carrying Out the Invention

[0049] Detailed Description Some of the embodiments contemplated in this specification will be described more fully with reference to the accompanying drawings. However, other embodiments are also within the scope of the subject matter disclosed herein and the disclosed subject matter should not be construed as limited to only the embodiments described herein. Rather, these described embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0050] In general, all terms used in this specification should be construed according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or implied from the context in which they are used. All singular references to elements, apparatuses, components, means, steps, etc. should be construed non - limitatively as representing at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. Any steps of any method and / or procedure disclosed herein need not be performed in the disclosed order, unless the steps are explicitly described as following or preceding another step, and / or unless it is implied that the steps must follow or precede another step. Any feature of any embodiment disclosed herein can be applied, as appropriate, to any other embodiment. Similarly, the advantages of any embodiment can be applied to other embodiments, and vice versa. Other objects, features and advantages of the accompanying embodiments will become apparent from the following description.

[0051] Furthermore, the following terms are used in the description below. · Wireless Node: As used herein, a "wireless node" may be either a "wireless access node" or a "wireless device". · Wireless access node: As used herein, a "wireless access node" (similarly for "wireless network node", "wireless access network node", or "RAN node") can be any node within a radio access network (RAN) of a cellular communication network that is operative to transmit and / or receive signals wirelessly. Non-limiting examples of wireless access nodes include base stations in a 3GPP 5th generation (5G) NR network (e.g., a New Radio (NR) base station (gNB) or an evolved or enhanced Node B (eNB) in a 3GPP LTE network), base station distributed components (e.g., CU and DU), high-power or macro base stations, low-power base stations (e.g., micro, pico, femto, or home base stations, etc.), integrated access backhaul (IAB) nodes, transmission points, remote radio units (RRU or RRH), and relay nodes. · Core network node: As used herein, a "core network node" is any type of node within the core network. Some examples of core network nodes include, for example, a mobility management entity (MME), a serving gateway (SGW), a packet data network gateway (P-GW), an access and mobility management function (AMF), a session management function (SMF), a user plane function (UPF), a service capability exposure function (SCEF), etc. · Wireless Device: As used herein, a "wireless device" (or abbreviated as "WD") is any type of device that accesses a cellular communication network (i.e., is served by a cellular communication network) by wirelessly communicating with a network node and / or another wireless device. Wireless communication may involve transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared rays, and / or other types of signals suitable for transmitting information through the atmosphere. Unless otherwise specified, the term "wireless device" is used interchangeably with "user equipment" (or abbreviated as "UE") herein. Non-limiting examples of wireless devices include smartphones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming machines or devices, music storage devices, playback devices, wearable devices, wireless endpoints, mobile machines, tablets, laptops, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, wireless customer premise equipment (CPE), machine type communication (MTC) devices, internet of things (IoT) devices, vehicle-mounted wireless terminal devices, and the like. · Network Node: As used herein, a "network node" is any node that is part of either a radio access network (e.g., the radio access node or equivalent name described above) or a core network (e.g., the core network node described above) of a cellular communication network. Functionally, a network node is a device configured, arranged, and / or operable to communicate directly or indirectly with a wireless device and / or other network nodes or devices within a wireless network to enable and / or provide wireless access to the wireless device and / or perform other functions (e.g., management) in the wireless network.

[0052] In this specification, since the description focuses on 3GPP cellular communication systems, it should be noted that 3GPP terms and terms similar to 3GPP terms are often used. However, the concepts disclosed in this specification are not limited to 3GPP systems. Further, although the term "cell" is used in this specification, (especially with respect to 5G NR) beams can be used instead of cells, and thus it should be understood that the concepts described in this specification apply equally to both cells and beams.

[0053] In the present disclosure, the term "service" is generally used to refer to a set of data that is associated with one or more applications and is transferred over a network with specific delivery requirements that need to be met in order to successfully run the applications. In the present disclosure, the term "component" is generally used to refer to any component necessary for the provision of a service. Examples of components are the RAN (e.g., E-UTRAN, NG-RAN, or a part thereof such as eNB, gNB, base station (BS)), the CN (e.g., EPC, 5GC, or a part thereof including all types of links between the RAN and CN entities), and cloud infrastructure having related resources such as computing and storage. Generally, each component can have a "manager", and this term is used to refer to an entity (e.g., a RAN manager) that can collect historical information regarding the utilization status of resources and provide information regarding the current and predicted future availability of the resources associated with that component.

[0054] As briefly described above, in the Rel-16 AKMA architecture, there may be various problems, issues, and / or difficulties related to the synchronization between the key material generated for the user by the AUSF and the key material used by the AAnF to generate an application-specific key for the user's application session. Such problems, issues, and / or difficulties may prevent the establishment of secure communication between a user application (e.g., running on a UE) and the corresponding application function (e.g., a server). This will be described in more detail below.

[0055] In general, AKMA reuses the results of the 5G primary authentication procedure (also referred to as "implicit bootstrapping") used to authenticate the UE during network registration. In this procedure, the AUSF is responsible for the generation and storage of the key material. In particular, the key hierarchy of AKMA includes the following, which is described in more detail in Figure 5. · Kausf: The root key. It is the output of the primary authentication procedure and is stored in the UE (i.e., the mobile equipment (ME) part) and the AUSF. Further, as defined in TS33.501, the AUSF can report the Ksusf, along with the result, as the output of the primary authentication result to a specific AUSF instance in the UDM. · Kakma: The anchor key derived from Kausf by the ME and the AUSF and used by the AAnF for further AKMA key material generation. The key identifier Kakma ID identifies Kakma. · Kaf: The application key derived from K AKMA by the ME and the AAnF. It is used by the UE and the application to securely exchange application data.

[0056] Figure 6 is a flowchart showing an exemplary procedure for setting up a secure application session between a UE and an AF based on the key hierarchy listed above. First, the UE and the AUSF perform primary authentication to establish the Kakma key. The Kakma key is stored in both the UE and the AUSF. Thereafter, the UE sends an application session establishment request containing the Kakma ID to the AF. Then, the AF sends the received Kakma ID to the AAnF together with the AF identifier, and the AAnF responds with the Kakma corresponding to the provided Kakma ID. The AAnF derives Kaf from the Kakma and provides Kaf to the AF together with the validity period of Kaf. Then, the AF can use the received Kaf to establish a secure application session with the UE.

[0057] As briefly described above, the Generic Bootstrapping Architecture (GBA) was introduced in 3GPP Rel-15 (e.g., 3GPP TS 33.220 v15.4.0) to bootstrap Authentication and Key Agreement (AKA). That is, GBA enables the AF on the network side and the user side to establish a shared key. Figure 7 shows an exemplary GBA for AKA according to the 3GPP specification.

[0058] In GBA, mutual authentication is performed between the UE and the BSF, and the bootstrapping key material is also derived between the UE and the BSF. The BSF also generates a B-TID (Bootstrapping Transaction Identifier) for each bootstrapping transaction that derives the GBA key material. Then, the bootstrapped GBA key material is used for secure access by the UE to the Network Application Function (NAF).

[0059] When the UE starts communicating with the AF, it includes the B-TID in the message. Then, the AF requests the application-specific key from the BSF using the B-TID as the input. The BSF searches for the GBA key material corresponding to the B-TID, derives the application-specific key, and provides it to the AF. Then, secure communication between the UE and the AF is established based on the application-specific key.

[0060] 3GPP TS 23.501 defines the input parameters that can be used for the discovery of the AUSF or UDM (e.g., using the NRF) so that an NF can discover and select the appropriate instance of the AUSF or UDM to process traffic. The relevant excerpts from 3GPP TS 23.501 are as follows. The following abbreviations of UE-related identifiers are used in the excerpts. · Subscriber Permanent Identifier (SUPI), · Subscriber Concealed Identifier (SUCI), and · Generic Public Subscription Identifier (GPSI). *** Excerpt from 3GPP TS 23.501 *** starts The AUSF NF consumer or the AUSF selection function in the SCP shall consider any of the following elements, if available: 1. The home network identifier (e.g., MNC and MCC) and the routing indicator of the SUCI / SUPI (by the NF consumer in the serving PLMN) Note 1: During the initial registration, the UE provides the routing indicator to the AMF as part of the SUCI as specified in TS 23.003

[19] . The AMF can provide the UE's routing indicator to other AMFs as described in TS 23.502 [3]. When the UE's routing indicator is set to the default value as specified in TS 23.003

[19] , the AUSF NF consumer can select any AUSF instance within the home network of the UE. 2. The AUSF Group ID to which the UE's SUPI belongs. Note 2: Based on the result of the AUSF discovery procedure using the NRF, the AMF can infer the AUSF Group ID to which the UE's SUPI belongs. The AMF 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 AMF selects an AUSF instance based on the SUPI range to which the UE's SUPI belongs or based on the result of the discovery procedure by the NRF that uses the UE's SUPI as input for AUSF discovery. The UDM selection function in the NF consumer or SCP shall consider one of the following elements: 1. The home network identifier (e.g., MNC and MCC) of the SUCI / SUPI and the routing indicator of the UE Note 1: During initial registration, the UE provides the routing indicator as part of the SUCI to the AMF as defined in TS 23.003

[19] . The AMF provides the UE's routing indicator to other NF consumers (of the UDM) as described in TS 23.502 [3]. When the UE's routing indicator is set to its default value as defined in TS 23.003

[19] , the UDM NF consumer can select any UDM instance within the home network of the SUCI / SUPI. 2. The UDM Group ID of the UE's SUPI Note 2: Based on the result of the UDM discovery procedure using the NRF, the AMF can infer the UDM Group ID to which the UE's SUPI belongs. The AMF provides the UDM group ID to which the SUPI belongs to other UDM NF consumers as described in 3GPP TS 23.502. 3. SUPI: The UDM NF consumer selects a UDM instance based on the SUPI range to which the UE's SUPI belongs or based on the result of the discovery procedure by the NRF that uses the UE's SUPI as input for UDM discovery. The UDM NF consumer that manages network signaling without relying on GPSI or External Group ID:SUPI / SUCI (e.g., NEF) selects 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 result of the discovery procedure by the NRF that uses the UE's GPSI or External Group ID as input for UDM discovery. End of excerpt from *** 3GPP TS 23.501 ***

[0061] Also, 3GPP TS 23.502 specifies the procedure for the UDM to deliver UE parameter update data to the UE using non-access stratum (NAS) signals after the UE is successfully registered with the 5GC. Figure 8 is a flowchart showing an exemplary procedure for delivering UE parameter update (UPU) from the UDM in the 5GC to the UE. The UDM update data delivered by the UDM to the UE may include any of the following: · One or more UE parameters including: Updated default configured NSSAI (the ultimate consumer of the parameter is the ME). Updated routing indicator data (the ultimate consumer of the parameter is the USIM). · "UE confirmation response required" indicator · "Reregistration required" indicator Also, to support the delivery of the steering information list from the UE's HPLMN to the UE, 3GPP TS 33.501 specifies a similar function called "steering of roaming security mechanisms".

[0062] Returning to the key hierarchy shown in Figure 5, 3GPP TS 33.501 specifies the generation and storage of Kausf in the AUSF and the UE after each primary authentication procedure. However, 3GPP TS 33.501 does not specify the timing at which the AUSF and / or the UE delete or overwrite Kausf, which is the root key implicitly agreed to be used by the UE and the AUSF to derive Kakma. Therefore, over time, different AUSF instances may be used for user authentication. In particular, different AUSF instances may generate and store Kausf for each authentication, but there is only one AUSF instance that holds the latest Kausf for a particular UE (which also holds the latest Kausf). This can lead to various problems, issues, and / or difficulties.

[0063] As an example, Kakma and KakmaID are separately generated by the UE and the AUSF based on Kausf. Therefore, since the UE does not obtain the identification information (e.g., AUSF ID) of the specific AUSF that generates and stores Kakma during primary authentication, the Kakma ID generated by the UE cannot include any reference to the AUSF ID. Thus, even if the UE provides the Kakma ID when attempting to establish a secure application session with the AF (e.g., in Figure 6), the AF (or more specifically, the AAnF associated with the AF) does not recognize the appropriate AUSF instance that generates and holds the Kakma associated with the received Kakma ID. Note that it has previously been unclear how the AF, and / or an intermediate NEF placed between the AF and the AAnF, can discover and select the integrated AUSF / AAnF based on the Kakma ID received from the UE, even if the AAnF is provided at the same location as the AUSF.

[0064] As another example, after being generated by the AUSF, Kakma is obtained by the AAnF to derive the Kaf. During different primary authentication procedures, there may be multiple Kausf generated for the same UE by different AUSF instances. Further, each of these AUSF instances may generate and store different Kakma / Kakma IDs for that UE based on the corresponding Kausf. Since no deletion / erasure procedure is defined, different AUSF instances may store different Kakma / Kakma IDs, but only one of them corresponds to the Kakma / Kakma ID stored in the UE.

[0065] Generally, an agreement between the UE and the network is required to use the latest Kakma. However, during some exceptional cases, the key materials stored in the UE and the network may be asynchronous. For example, the UE can generate and store new versions of Kausf and Kakma, but the network has not yet generated new versions of Kausf and Kakma. In such a case, the KakmaID received from the UE during AKMA session setup may refer to a Kakma that does not yet exist on the network side.

[0066] Exemplary embodiments of the present disclosure address these and other problems, issues, and / or difficulties by providing techniques that facilitate the selection of the AUSF instance that stores the Kakma referred to by the Kakma ID provided by the UE at the start of the AKMA procedure with the AF.

[0067] Some embodiments of the present disclosure can utilize UDM discovery and selection techniques for primary authentication based on an identifier related to a network subscription associated with a UE. For example, the identifier may be any relevant identifier available on the UE, including an HPLMN ID + UE Routing Indicator (R-ID), SUCI, SUPI, or GPSI. The UE can provide the identifier to the AF as part of the Kakma ID or separately from the Kakma ID in a request to establish an application session. When a suitable UDM capable of managing the UE request is found based on the identifier, the AAnF (or NEF / AF) obtains the identification information of the AUSF that stores the latest Kakma from the UDM using a new service operation, such as Nudm_UEAuthentication_ResultStatus. Then, the AAnF can obtain the latest Kakma from the specified AUSF and generate a Kaf based on the obtained Kakma.

[0068] Other embodiments of the present disclosure can utilize existing UE Parameter Update (UPU) techniques to distribute explicit binding information between a Kakma and an AUSF ID that holds the Kausf / Kakma currently used by the UE. Although the AKMA key material is implicitly and independently generated on the UE and network sides, the UE and network can have an explicit binding procedure that agrees on (Kausf, Kakma) version synchronization and reference to the AUSF ID.

[0069] More specifically, the UE can obtain binding information from the UDM and provide it to the AF in a request to establish an application session. Then, the AAnF can use the binding information to find the associated AUSF ID (i.e., the AUSF that stores the latest Kakma for the UE) in a manner similar to the BSF discovery procedure for GBA. Note that if the AAnF is provided at the same location as the AUSF, the binding information is also associated with the AAnF, similar to the binding of the BSF in GBA.

[0070] Other embodiments of the present disclosure can utilize the NRF registration procedure to register the AAnF according to the range of the routing identifier (RID) so that the AUSF can be discovered via the NRF thereafter. When creating a Kakma for a specific UE corresponding to the registered RID, the AUSF can push the Kakma / Kakma ID to the previously discovered AAnF. In this way, the AAnF already has the Kakma required to generate the Kaf when requested by the AF.

[0071] Figures 9 to 11 are flowcharts of various exemplary procedures including authentication support function (AUSF) selection during application session establishment according to various exemplary embodiments of the present disclosure. In particular, the embodiments shown in Figures 9 to 11 utilize the UDM discovery and selection techniques used in primary authentication based on the identifier related to the network subscription associated with the UE. In particular, Figures 9 to 11 show procedures based on the HPLMN ID + UE routing indicator, SUCI / SUPI, and GPSI, respectively.

[0072] Each of FIGS. 9 to 11 includes various messages and operations involving one or more instances of UE 910, AMF 920, AUSF 930 (e.g., 930a, 930b, etc.), UDM / UDR 940, one or more instances of AAnF 950 (e.g., 950a, 950b, etc.), and AApF (or AF) 960. For the sake of brevity, these entities are referred to in the following description without using reference numbers. In addition, FIGS. 9 to 11 show numbered operations, but these numbers are used to facilitate the description of the procedures and do not require or imply a specific order for the operations. That is, the operations shown in FIGS. 9 to 11 can be executed in an order different from that shown, and can be combined and / or divided into operations different from those shown.

[0073] In operation 0 of FIG. 9, the UE performs primary authentication with the network. Kakma and Kakma ID are generated and stored in the UE and the AUSF. The AUSF calls the existing service operation Nudm_UEAuthentication_ResultConfirmation to notify the UDM of the authentication result including the SUPI, AUSF ID, serving network name, authentication type, and timestamp information. In addition, the AUSF provides the Kakma ID generated during primary authentication. The UDM stores all the information together.

[0074] In operation 1, the UE starts the application session setup procedure using the AF. The UE includes the Kakma ID, the home network identifier (HPLMN ID, e.g., mobile network code (MNC) / mobile country code (MCC)), and the RID of the UE. The HPLMN ID and the RID can be included within the Kakma ID or included as separate identifiers in the message. In Operations 2 to 3, the AF selects AAnF based on the HPLM ID and sends a request for Kaf to be used in the application session with the UE to the selected AAnF. The request includes the AF ID, Kakma ID, and HPLMN ID + RID.

[0075] Operation 4 includes AUSF discovery and selection by the AAnF. In Operation 4a, the AAnF discovers and selects the UDM based on the RID received from the AF. In Operation 4b, the AAnF calls the new service operation Nudm_UEAuthentication_ResultStatus to send a request containing the Kakma ID to the selected UDM. The UDM uses the Kakma ID to detect and select an AUSF instance based on the information saved during Operation 0. In Operation 4c, the UDM returns the SUPI and AUSF ID to the requesting AAnF. In Operation 4d, the AAnF discovers and selects the AUSF based on the AUSF ID received from the UDM.

[0076] In Operation 5, the AAnF calls the service operation Nausf_AKMAKey_Get to send a Kakma request including the SUPI and Kakma ID to the selected AUSF. In Operation 6, the AUSF returns Kakma to the AAnF. In Operations 7 to 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 a secure application session with the UE based on the Kaf received in Operation 8.

[0077] Figure 10 shows the same operations as in Figure 9, but is based on a different identifier, namely, SUCI or SUPI instead of HPLMN ID+RID. Operation 0 is the same as operation 0 in Figure 9. In operation 1, the UE starts the application session setup procedure using the AF. The UE includes the KakmaID and the SUCI or SUPI. The SUCI or SUPI can be included within the Kakma ID or included as a separate identifier in the message. In operations 2 to 3, the AF selects the AAnF based on the HPLM ID associated with the SUCI or SUPI and sends a request for Kaf for use in the application session with the UE to the selected AAnF. The request includes the AF ID, Kakma ID, and SUCI or SUPI.

[0078] Operation 4 includes the discovery and selection of the AUSF by the AAnF. In operation 4a, the AAnF discovers and selects the UDM based on the SUCI or SUPI received from the AF. To send a request including the Kakma ID and the SUCI or SUPI to the selected UDM, a new service operation Nudm_UEAuthentication_ResultStatus is invoked. In operation 4c, the UDM uses the SUCI or SUPI to select an AUSF instance based on the information stored during operation 0. The UDM verifies that the Kakma ID 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 originating AAnF. In operation 4e, the AAnF discovers and selects the AUSF based on the AUSF ID received from the UDM. Operations 5 to 9 are the same as operations 5 to 9 in Figure 9.

[0079] Figure 11 shows the same operations as Figures 9 - 10, but is based on the GPSI instead of different identifiers, namely, HPLMN ID + RID, SUCI, or SUPI. Operation 0 is the same as operation 0 shown in Figures 9 - 10. In operation 1, the UE starts the application session setup procedure using the AF. The UE includes the Kakma ID and the GPSI. The GPSI can be included within the Kakma ID or included as a separate identifier in the message. In operations 2 - 3, the AF selects the AAnF based on the HPLM ID associated with the GPSI and sends a request for Kaf for use in the application session with the UE to the selected AAnF. The request includes the AF ID, Kakma ID, and GPSI.

[0080] Operation 4 includes AUSF discovery and selection 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 the new service operation Nudm_UEAuthentication_ResultStatus to send a request including the Kakma ID and the GPSI to the selected UDM. In operation 4c, the UDM converts the received GPSI to the corresponding SUPI and uses the SUPI to select an AUSF instance based on the information stored during operation 0. The UDM verifies that the Kakma ID received from the AAnF is included in the authentication context stored 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, if necessary or desired. In operation 4e, the AAnF discovers and selects the AUSF based on the AUSF ID received from the UDM. Operations 5 - 9 are the same as operations 5 - 9 in Figures 9 - 10.

[0081] Figure 12 is a flowchart of another exemplary procedure involving the selection of an Authentication Support Function (AUSF) during application session establishment according to various exemplary embodiments of the present disclosure. Specifically, the embodiment shown in Figure 12 utilizes an existing UE Parameter Update (UPU) technique to provide explicit binding information between Kakma and the AUSF ID that the UE currently holds for Kausf / Kakma. The entities shown in Figure 12 use the same reference numbers as Figures 9 - 11 and are omitted in the following description for brevity. However, the configuration shown in Figure 12 includes the NRF 970 instead of the AMF 920.

[0082] Figure 12 shows numbered operations, but these numbers are used to facilitate the description of the procedure and do not require or imply a specific order for the operations. That is, the operations shown in Figure 12 can be executed in an order different from that shown, and can be combined and / or divided into operations different from those shown.

[0083] In operation 0a, the AUSF registers its own unique AKMA binding information with the NRF, for example, using the Nnrf_NFManagement_NFRegister service operation. The AKMA binding information can include the AUSF GroupID, SUPI range, AUSF Fully Qualified Domain Name (FQDN), AUSF IP address, and / or AUSF ID. In some embodiments, the AKMA binding information registered in operation 0a can be a hash of the above parameters that can enhance the privacy of the AUSF.

[0084] In operation 0b, the UE performs primary authentication with the network. Kakma and Kakma ID are generated and stored in the UE and the AUSF. The AUSF also generates a binding identifier B-TID that may include the Kakma ID, AKMA binding information (e.g., from operation 0a), and one or more UE identifiers (e.g., GPSI). The AUSF calls the existing service operation Nudm_UEAuthentication_ResultConfirmation to notify the UDM about the authentication result including the SUPI, AUSF ID, serving network name, authentication type, and timestamp information. Further, the AUSF provides the B-TID. The UDM stores all the information together.

[0085] In operation 0c, the AUSF requests the UDM (or the UDM triggers itself) to update the B-TID for a specific UE by using UDM control plane procedures or similar procedures for UE parameter update. In operation 1, the UE starts the application session setup procedure using the AF. The UE includes the B-TID received in operation 0c. In operations 2-3, the AF selects the AAnF based on the HPLM ID associated with the GPSI (e.g., included in the B-TID) and sends a request for Kaf to be used in the application session with the UE to the selected AAnF. The request includes the B-TID received in operation 1. In operation 4, the AAnF discovers and selects the AUSF using the NRF based on the B-TID received from the AF. For example, the AAnF uses the AKMA binding information and / or UE information (e.g., GPSI) within the B-TID* as input to the NRF discovery service.

[0086] In operation 5, AAnF calls service operation Nausf_AKMAKey_Get to send the Kakma request including B-TID to the selected AUSF. In operation 6, the AUSF returns Kakma to AAnF (optionally including the SUPI as well). In other embodiments, AAnF calls an existing service (e.g., Nudm_SDM_GET (identifier conversion)) from the UDM to map the UE information within B-TID* to the corresponding SUPI. Then, AAnF also includes the SUPI in the service operation Nausf_AKMAKey_Get s sent in operation 5.

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

[0088] The procedure shown in FIG. 12 may be modified in operation 0c to piggyback B-TID* onto an existing NAS signal during the primary authentication and / or UE registration procedure and provide it to the UE. The other operations of this variant may be substantially the same as the operations shown in FIG. 12.

[0089] FIG. 13 is a flowchart of another exemplary procedure involving the selection of an Authentication Support Function (AUSF) during application session establishment according to various exemplary embodiments of the present disclosure. Specifically, the embodiment shown in FIG. 13 utilizes the NRF registration procedure for the AAnF to register according to the range of the Routing Identifier (RID) that the AUSF can later discover using the NRF. The entities shown in FIG. 13 use the same reference numerals as FIGS. 9 - 11 and are omitted in the following description for brevity. FIG. 13 shows numbered operations, but these numbers are used to facilitate the description of the procedure and do not require or imply a specific order for the operations. That is, the operations shown in FIG. 13 can be executed in an order different from that shown, and can be combined and / or divided into operations different from those shown.

[0090] As a requirement of the embodiment shown in FIG. 13, the AAnF can be arranged within the HPLMN to use the same Group ID (GID), RID, and / or SUPI range partitioning as used by the AUSF and / or UDM. In some embodiments, multiple AAnF instances can be arranged for individual range partitions. Similar to FIG. 12, the AAnF can register with the NRF (not shown in FIG. 13) in relation to the corresponding range partition.

[0091] Operation 0 is the same as Operation 0 shown in FIGS. 9 to 11. In Operation 1, after primary authentication and Kakma generation, the AUSF discovers the AAnF instance(s) for the UE using the NRF based on the UE's SUPI or RID. Note that there can be multiple AAnF instances for the UE's RID / GID. In Operation 2, the AUSF actively pushes the Kakma, Kakma ID, and SUPI for the UE to the AAnF. If multiple AAnF instances are arranged for the UE's RID / GID, the AUSF provides the Kakma to all such AAnF instances. Operation 3 is the same as Operation 3 in FIG. 9.

[0092] In Operation 4, the AF selects an AAnF instance based on the HPLMN ID and RID received in Operation 3. In Operation 5, the AF calls the service operation Nausf_AKMAKey_Get to send a request for Kakuma including the RID to the selected AUSF. In Operation 6, after receiving the request, the AAnF collates the information received in Operation 2 with the KakmaID to determine that it has the latest Kakma. Operations 7 to 9 are the same as Operations 7 to 9 in FIGS. 9 to 12.

[0093] The above-described embodiments can be further explained by exemplary methods (e.g., procedures) shown in FIGS. 14 to 19 described below. For example, the features of the various embodiments described above are included in the various operations of the exemplary methods shown in FIGS. 14 to 19.

[0094] More specifically, FIG. 14 shows an exemplary method (e.g., procedure) executed by a key management server (e.g., AAnF) in a communication network (e.g., 5GC) according to various exemplary embodiments of the present disclosure. The key management server can be hosted and / or provided by one or more network nodes in the communication network, as described elsewhere herein. The exemplary method is shown by specific blocks in a specific order in FIG. 14, but the operations corresponding to the plurality of blocks can be executed in an order different from the illustration, combined with and / or divided into blocks and / or operations having functions different from the illustration. Further, the exemplary method shown in FIG. 14 can be complementary to other exemplary methods and / or procedures (e.g., FIGS. 9 to 12, 16 to 17, 19) disclosed herein so as to be used cooperatively to provide the advantages, benefits, and / or solutions to the problems described herein. Optional blocks and / or operations are indicated by dashed lines.

[0095] The exemplary method can include the operation of block 1410. In block 1410, the key management server can receive a request for a security key (Kaf) specific to an application session for a specific user from an application function. The request can include an expression of the following information associated with the specific user, i.e., a first identifier (KakmaID) of an anchor security key (Kakma) not specific to the application and a second identifier regarding network subscription. The exemplary method can also include the operation of block 1420. In block 1420, the key management server can identify an authentication server function (AUSF) that generated an anchor security key (Kakma) not specific to the application based on the expression.

[0096] In some embodiments, the exemplary method can further include the operation of block 1430. At block 1430, the key management server can obtain an anchor security key (Kakma) that is not specific to the application from the specified AUSF. In some embodiments, the exemplary method can further include the operation of block 1440. At block 1440, the key management server can generate a security key (Kaf) specific to the application session based on the anchor security key (Kakma) that is not specific to the application.

[0097] Some embodiments of the method shown in FIG. 14 can correspond to the exemplary procedure shown in FIG. 12. In such embodiments, the representation (e.g., received at block 1410) can include a third identifier (B-ID) of the binding between the anchor security key (Kakma) that is not specific to the application and the AUSF that generated the Kakma. In particular, the third identifier can include the representations of the first and second identifiers and the information associated with the AUSF. In various embodiments, the information associated with the AUSF can include one or more of an AUSF group ID, an AUSF ID, a subscription permanent identifier (SUPI) range, a fully qualified domain name (FQDN), and an IP address.

[0098] In such an embodiment, the specific operation of block 1420 can include the operation of sub-block 1421. At block 1421, the key management server can discover the identification information of the AUSF using the Network Repository Function (NRF) based on the information associated with the AUSF. Further, in such an embodiment, the acquisition operation of block 1430 can include the operations of sub-blocks 1431-1432. In sub-block 1431, the key management server can send a request including a third identifier (e.g., B-TID) to the specified AUSF (e.g., from block 1420). In sub-block 1432, the key management server can receive a response including an anchor security key (Kakma) not specific to the application and a second identifier from the specified AUSF.

[0099] Other embodiments of the method shown in FIG. 14 can correspond to the exemplary procedures shown in FIGS. 9-11. In such an embodiment, the representation of the first identifier and the second identifier (e.g., received at block 1410) can include the first identifier (e.g., KakmaID) and the second identifier. For example, the second identifier can be any one of an HPLMN ID and a User Equipment Routing Identifier (RID), a Subscribed Concealed Identifier (SUCI), a Subscribed Permanent Identifier (SUPI), or a General Public Subscription Identifier (GPSI). In a variant, the representation can include only the first identifier (e.g., KakmaID), and the first identifier can include the representation of the second identifier.

[0100] In such an embodiment, the specific operations of block 1420 can include the operations of sub-blocks 1422-1424. In sub-block 1422, the key management server can select an integrated data management (UDM) function within the communication network based on a second identifier. In sub-block 1423, the key management server can send a first request for a fourth identifier associated with the AUSF to the UDM. In sub-block 1424, the key management server can receive a first response including the fourth identifier from the UDM. In some embodiments, the first response can also include a further second identifier regarding a network subscription associated with a specific user. For example, the further second identifier can be a SUPI, and the second identifier can be an identifier other than the SUPI (e.g., GPSI, SUCI, HPLMN+RID).

[0101] In such an embodiment, the acquisition operations of block 1430 can include the operations of sub-blocks 1433-1434. In sub-block 1433, the key management server can send a second request having the second identifier or a further second identifier regarding a network subscription associated with a specific user to the AUSF associated with the fourth identifier. In sub-block 1434, the key management server can receive a second response including an anchor security key (Kakma) that is not specific to the application from the AUSF. In some embodiments, either the second request or the second response can also include the second identifier. For example, if the second request includes a further second identifier (e.g., SUPI), the second response can include an identifier other than the second identifier (e.g., SUPI).

[0102] In some embodiments, the exemplary method can further include the operations of block 1440 where the key management server can send a security key (Kaf) specific to the application session to the application function.

[0103] Further, FIG. 15 shows another exemplary method (e.g., procedure) performed by a key management server (e.g., AAnF) in a communication network (e.g., 5GC) according to various exemplary embodiments of the present disclosure. The key management server can be hosted and / or provided by one or more network nodes within the communication network, as described elsewhere herein. The exemplary method is shown by specific blocks in a specific order in FIG. 15, but operations corresponding to multiple blocks can be executed in an order different from that shown, combined and / or split into blocks and / or operations having functions different from those shown. Further, the exemplary method shown in FIG. 15 can be used in cooperation to provide the advantages, benefits, and / or solutions to the problems described herein, and thus can be complementary to other exemplary methods and / or procedures (e.g., FIGS. 13 and 18) disclosed herein. Optional blocks and / or operations are indicated by dashed lines.

[0104] The exemplary method can include the operation of block 1520. In block 1520, the key management server can receive from an authentication server function (AUSF) the following information associated with a specific user, namely, an anchor security key (Kakma) that is not application-specific, a first identifier (KakmaID) of the anchor security key that is not application-specific, and a second identifier related to network subscription. In some embodiments, the second identifier can be a subscription permanent identifier (SUPI).

[0105] An exemplary method may also include the operation of block 1530. In block 1530, the key management server can receive from the application function a request for a security key (Kaf) specific to an application session for a particular user, the request having an additional identifier (Kakma ID) of an anchor security key that is not specific to the application associated with the particular user. The request can include an additional identifier (Kakma ID) of an anchor security key that is not specific to the application associated with the particular user. An exemplary method may also include the operation of block 1550. In block 1550, the key management server can generate a security key (Kaf) specific to the application session based on an anchor security key (Kakma) that is not specific to the application, based on a match between a first identifier and an additional identifier (e.g., a matching Kakma ID).

[0106] In some embodiments, the key management server can include multiple instances of an anchor function (AAnF) for authentication and key management for the application, each AAnF instance corresponding to a range of user device routing indicators (RIDs). In such embodiments, the request can also include a routing indicator (RID) associated with a particular user, and an exemplary method can also include the operation of block 1540. In block 1540, the key management server can select an AAnF instance based on the received RID (e.g., based on a match between the received RID and one of the RID ranges). In such embodiments (e.g., in block 1550), generating a security key (Kaf) specific to the application session is performed by the selected AAnF instance.

[0107] In some embodiments, a key management server may be associated with one or more ranges of user equipment routing indicators (RIDs). As an example, the key management server may include a plurality of AAnF instances, and each AAnF instance corresponds to a range of user equipment routing indicators (RIDs). An exemplary method in such embodiments may further include the operation of block 1510. In block 1510, the key management server may register the association between the key management server and one or more ranges with a network repository function (NRF) in the communication network.

[0108] Furthermore, FIG. 16 shows an exemplary method (e.g., procedure) executed by an application function in a communication network according to various exemplary embodiments of the present disclosure. The application function may be hosted and / or provided by one or more network nodes in the communication network as described elsewhere herein. The exemplary method is shown by specific blocks in a specific order in FIG. 16, but the operations corresponding to multiple blocks may be executed in an order different from that shown, combined and / or divided into blocks and / or operations having functions different from those shown. Furthermore, the exemplary method shown in FIG. 16 may be complementary to other exemplary methods and / or procedures (e.g., FIGS. 9-15, 17-19) disclosed herein so that they can be used cooperatively to provide solutions to various advantages, benefits, and / or problems described herein. Optional blocks and / or operations are indicated by dashed lines.

[0109] An exemplary method can include the operation of block 1610. At block 1610, the application function can receive, from the user device, a first request for the establishment of an application session. The first request can include an expression of information associated with a particular user, namely, a first identifier (KakmaID) of an anchor security key (Kakma) that is not specific to the application and a second identifier regarding network subscription. The exemplary method can also include the operation of block 1620. At block 1620, the application function can send, to an anchor function (AAnF) for authentication and key management for the application within the communication network, a request for a security key (Kaf) specific to the application session. The second request can include an expression of the first and second identifiers.

[0110] The exemplary method can also include the operation of block 1630. At block 1630, the application function can receive, from the AAnF, a security key (Kaf) specific to the application session. In some embodiments, the exemplary method can further include the operation of block 1640. At block 1640, the application function can establish a secure application session with the user device based on the received security key (Kaf).

[0111] Some embodiments of the method shown in FIG. 16 can correspond to the exemplary procedure shown in FIG. 12. In such embodiments, the representation (received, for example, at block 1610 and transmitted at block 1620) can have a third identifier (B-ID) of the binding between the untrusted security key (Kakma), which is not specific to the application, and the AUSF that generated the Kakma. In particular, the third identifier can include the representations of the first and second identifiers and the information associated with the AUSF. In various embodiments, the information associated with the AUSF can include one or more of an AUSF group ID, an AUSF ID, a subscription permanent identifier (SUPI) range, a fully qualified domain name (FQDN), and an IP address.

[0112] Other embodiments of the method shown in FIG. 16 can correspond to the exemplary procedures shown in FIGS. 9-11. In such embodiments, the representations of the first and second identifiers (received, for example, at block 1410) can include the first identifier (e.g., KakmaID) and the second identifier. For example, the second identifier can be any one of an HPLMN ID and a user equipment routing identifier (RID), a subscription concealment identifier (SUCI), a subscription permanent identifier (SUPI), or a general public subscription identifier (GPSI). In a variant, the representation can include only the first identifier (e.g., KakmaID), and the first identifier can include the representation of the second identifier.

[0113] Furthermore, FIG. 17 shows an exemplary method (e.g., procedure) performed by an Authentication Server Function (AUSF) in a communication network (e.g., 5GC) according to various exemplary embodiments of the present disclosure. The AUSF may be hosted and / or provided by one or more network nodes within the communication network, as described elsewhere herein. The exemplary method is shown by specific blocks in a specific order in FIG. 17, but the operations corresponding to the plurality of blocks may be executed in an order different from that shown, combined with and / or divided into blocks and / or operations having functions different from those shown. Furthermore, the exemplary method shown in FIG. 17 may be complementary to other exemplary methods and / or procedures (e.g., FIGS. 9 - 12, 14, 16, 19) disclosed herein so as to be used cooperatively to provide solutions to various advantages, benefits, and / or problems described herein. Optional blocks and / or operations are indicated by dashed lines.

[0114] The exemplary method may include the operation of block 1730. In block 1730, the AUSF may receive, from an Anchor Function for Authentication and Key Management (AAnF) for an application within the communication network, a request for an anchor security key (Kakma) that is not specific to an application for a particular user. The request may include a first representation of a first identifier (KakmaID) associated with the anchor security key (Kakma) that is not specific to the application and a second identifier regarding the network subscription of the particular user. The exemplary method may also include the operation of block 1740. In block 1740, the AUSF may transmit a response including the requested anchor security key (Kakma) that is not specific to the application to the AAnF.

[0115] In some embodiments, the exemplary method shown in FIG. 17 can include the operations of blocks 1710-1720. In block 1710, the AUSF can generate an anchor security key (Kakma) that is not specific to an application for a particular user and a first identifier (KakmaID). In block 1720, the AUSF can send to an integrated data management (UDM) function in a communication network a fourth identifier (AUSFID) associated with the AUSF and a second representation of at least the first identifier (KakmaID).

[0116] Some embodiments of the method shown in FIG. 17 can correspond to the exemplary procedure shown in FIG. 12. In such embodiments, the first representation (e.g., received at block 1730) and the second representation (e.g., sent at block 1720) can include a third identifier (B-ID) of a binding between an anchor security key (Kakma) that is not specific to an application and the AUSF that generated the Kakma. In particular, the third identifier can include the representations of the first and second identifiers and information associated with the AUSF. In various embodiments, the information associated with the AUSF can include one or more of an AUSF group ID, an AUSF ID, a subscription permanent identifier (SUPI) range, a fully qualified domain name (FQDN), and an IP address. In such embodiments, the response (e.g., sent at block 1740) can further include a subscription permanent identifier (SUPI) associated with a particular user.

[0117] Other embodiments of the method shown in FIG. 17 can correspond to the exemplary procedures shown in FIGS. 9-11. In such embodiments, a first representation of the first and second identifiers (e.g., received at block 1730) can include the first identifier (e.g., KakmaID) and the second identifier, and a second representation (e.g., transmitted at block 1720) can include only the first identifier. In such embodiments, the second identifier can be any one of an HPLMN ID and a user equipment routing identifier (RID), a subscription concealment identifier (SUCI), a subscription permanent identifier (SUPI), or a general public subscription identifier (GPSI). In a variant, the first representation (e.g., received at block 1730) can include only the first identifier (e.g., KakmaID), and the first identifier can include a representation of the second identifier.

[0118] Further, FIG. 18 shows another exemplary method (e.g., procedure) performed by an authentication server function (AUSF) in a communication network (e.g., 5GC) according to various exemplary embodiments of the present disclosure. The AUSF can be hosted and / or provided by one or more network nodes within the communication network, as described elsewhere herein. The exemplary method is shown by specific blocks in a specific order in FIG. 18, but operations corresponding to multiple blocks can be performed in an order different from that shown, combined and / or divided into blocks and / or operations having functions different from those shown. Further, the exemplary method shown in FIG. 18 can be complementary to other exemplary methods and / or procedures (e.g., FIGS. 13 and 15) disclosed herein so as to be used cooperatively to provide the advantages, benefits, and / or solutions to problems described herein. Optional blocks and / or operations are indicated by dashed lines.

[0119] The exemplary method can include the operation of block 1810. In block 1810, the AUSF can generate an anchor security key (Kakma) that is not specific to an application for a particular user, and the anchor security key that is not specific to the application is associated with a first identifier (KakmaID). The exemplary method can also include the operation of block 1820. In block 1820, the AUSF can select an anchor function (AAnF) for authentication and key management for an application within a communication network, associated with a particular user, based on a second identifier regarding the network subscription of the particular user. In some embodiments, the exemplary method can further include the operation of block 1830. In block 1830, the AUSF can send the following information to the specified AAnF, namely, an anchor security key (Kakma) that is not specific to an application for a particular user, a first identifier (KakmaID), and a second identifier regarding the network subscription of the particular user. In various embodiments, the second identifier can be a subscription permanent identifier (SUPI) associated with a particular user.

[0120] Furthermore, FIG. 19 shows an exemplary method (e.g., procedure) performed by an integrated data management (UDM) function in a communication network (e.g., 5GC) according to various exemplary embodiments of the present disclosure. The UDM function may be hosted and / or provided by one or more network nodes within the communication network, as described elsewhere herein. The exemplary method is shown by specific blocks in a specific order in FIG. 19, but operations corresponding to multiple blocks can be executed in an order different from that shown, combined and / or divided into blocks and / or operations having functions different from those shown. Furthermore, the exemplary method shown in FIG. 19 may be complementary to other exemplary methods and / or procedures (e.g., FIGS. 9-11, 14, 16-17) disclosed herein so as to be used cooperatively to provide various advantages, benefits, and / or solutions to problems described herein. Optional blocks and / or operations are indicated by dashed lines.

[0121] The exemplary method can include the operation of block 1910. In block 1910, the UDM function can receive, from an authentication server function (AUSF) within the communication network, a fourth identifier (AUSFID) associated with the AUSF and a first identifier (KakmaID) associated with an anchor security key (Kakma) that is not specific to an application for a particular user. The exemplary method can also include the operation of block 1920. In block 1920, the UDM function can receive a request for the fourth identifier from an anchor function (AAnF) for authentication and key management for an application within the communication network. The exemplary method can also include the operation of block 1950. In block 1950, the UDM function can transmit a response having the fourth identifier to the AAnF.

[0122] In some embodiments, a request (e.g., received at block 1920) can include a first identifier (KakmaID), and a response (e.g., transmitted at block 1950) can include a second identifier related to a network subscription associated with a particular user. In some of these embodiments, the first identifier can include a representation of the second identifier. An example of such an embodiment is shown in the procedure illustrated by FIG. 9.

[0123] In other embodiments of these embodiments, a request can include a further second identifier related to a network subscription associated with a particular user. An exemplary method in such an embodiment can further include the operation of block 1930. In block 1930, the UDM function can determine the second identifier based on the further second identifier. For example, the second identifier can be a subscription permanent identifier (SUPI), and the further second identifier can be an identifier other than SUPI (e.g., SUCI, GPSI). An example of such an embodiment is shown in the procedure illustrated by FIGS. 10 - 11.

[0124] In various embodiments, the AUSF (e.g., the source of the information received at block 1910) can include a plurality of AUSF instances, and each AUSF instance corresponds to a range of identifiers (e.g., RID, SUPI, etc.) associated with network subscriptions. An exemplary method in such an embodiment can further include the operation of block 1940. In block 1940, the UDM function can select a particular AUSF instance based on the second identifier (e.g., received at block 1920). In such an embodiment, a fourth identifier (e.g., transmitted at block 1950) can correspond to the selected AUSF instance.

[0125] The subject matter described in this specification can be implemented in any suitable type of system using any suitable components, but the embodiments disclosed herein are described with respect to a wireless network such as the exemplary wireless network shown in FIG. 20. For simplicity, only network 2006, network nodes 2060 and 2060b, and WDs 2010, 2010b, and 2010c are depicted in the wireless network of FIG. 20. In reality, the wireless network can further include any additional elements suitable for supporting communication between wireless devices or between a wireless device and other communication devices (such as landline telephones, service providers, or other network nodes and end devices). Among the illustrated components, network node 2060 and wireless device (WD) 2010 are shown in more detail. The wireless network can provide one or more wireless devices with communication and other types of services to facilitate access to and / or utilization of services provided by or using the wireless devices.

[0126] The wireless network can be composed of and / or interact with any type of communication, telecommunications, data, cellular, and / or wireless network or other similar type of system. In some embodiments, the wireless network can be configured to operate according to specific standards or other types of predefined rules or procedures. Thus, particular embodiments of the wireless network can implement communication standards such as Global System for Mobile Communications (GSM) for mobile communications, Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, or 5G standards, wireless local area network (WLAN) standards such as IEEE 802.11 standards, and / or any other suitable wireless communication standards such as WiMax (Worldwide Interoperability for Microwave Access), Bluetooth®, Z-Wave, and / or ZigBee standards.

[0127] Network 2006 can be composed of one or more of a backhaul network, a core network, an IP network, a public switched telephone network (PSTN), a packet data network, an optical network, a wide area network (WAN), a local area network (LAN), a wireless local area network (WLAN), a wired network, a wireless network, a metropolitan network, and other networks that enable communication between devices.

[0128] Network node 2060 and WD2010 have various components that will be described in more detail below. These components cooperate to provide the functions of network nodes and / or wireless devices, for example, to provide a wireless connection in a wireless network. In various embodiments, a wireless network may have any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relays, and / or any other components or systems that can facilitate or be involved in the communication of data and / or signals, whether using a wired connection or a wireless connection.

[0129] Examples of network nodes include, but are not limited to, access points (APs) (e.g., wireless access points), base stations (Bs) (e.g., wireless base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)). Base stations may be classified based on the amount of coverage they provide (in other words, the transmission power level), and may also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may also be a relay node or a relay donor node that controls relays. A network node may also include one or more (or all) parts of a distributed radio base station such as a centralized digital unit and / or a remote radio unit (RRU) (also called a remote radio head (RRH)). Such a remote radio unit may or may not be integrated with an antenna as an antenna-integrated radio. Some parts of a distributed radio base station may also be called nodes in a distributed antenna system (DAS).

[0130] Yet another example of a network node includes multi-standard radio (MSR) devices such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), core network nodes (e.g., MSCs, MMEs), O&M nodes, OSS nodes, SON nodes, positioning nodes (e.g., E-SMLC), and / or MDTs. As another example, a network node may be a virtual network node, which will be described in more detail below. However, more generally, a network node can represent any suitable device (or group of devices) that is configured, arranged, and / or operable to enable and / or provide access to a wireless device to a wireless network, or to provide some service to a wireless device accessing the wireless network.

[0131] In FIG. 20, network node 2060 includes a processing circuit 2070, a machine-readable medium 2080, an interface 2090, an auxiliary device 2084, a power supply 2086, a power circuit 2087, and an antenna 2062. The network node 2060 shown in the exemplary wireless network of FIG. 20 can represent a device that includes the illustrated combination of hardware components, although other embodiments can have network nodes with different combinations of components. It should be understood that a network node can have any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. Further, the components of network node 2060 are shown as a single box placed within a larger box or nested within multiple boxes, but in reality, the network node can have a plurality of different physical components that make up a single illustrated component (e.g., the machine-readable medium 2080 can have a plurality of separate hard drives as well as a plurality of RAM modules).

[0132] Similarly, network node 2060 may be composed of a plurality of physically distinct components (e.g., a Node B component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own respective components. In a particular scenario where network node 2060 has a plurality of distinct components (e.g., BTS and BSC components), one or more of the distinct components may be shared among several network nodes. For example, a single RNC may be able to control multiple Node Bs. In such a scenario, each unique pair of Node B and RNC may, in some cases, be regarded as one independent network node. In some embodiments, network node 2060 may be configured to support a plurality of radio access technologies (RATs). In such embodiments, some components may be replicated (e.g., separate device-readable media 2080 for different RATs), and some components may be reused (e.g., the same antenna 2062 may be shared by multiple RATs). Network node 2060 may also include multiple sets of the various illustrated components for different radio technologies integrated into network node 2060, such as, for example, GSM, WCDMA®, LTE, NR, WiFi, or Bluetooth radio technologies. These radio technologies may be integrated into the same or different chips or sets of chips and other components within network node 2060.

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

[0134] The processing circuit 2070 can have one or a combination of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or a combination of hardware, software, and / or encoded logic, which can operate, either alone or in conjunction with other network node 2060 components such as the device-readable medium 2080, to provide the functions of the network node 2060. Such functions can include providing any of the various wireless features, functions, or benefits described herein.

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

[0136] In some embodiments, the processing circuit 2070 can include one or more radio frequency (RF) transceiver circuits 2072 and baseband processing circuits 2074. In some embodiments, the radio frequency (RF) transceiver circuits 2072 and baseband processing circuits 2074 can be on separate chips (or a set of chips), boards, or units (such as a radio unit and a digital unit). In alternative embodiments, some or all of the RF transceiver circuits 2072 and baseband processing circuits 2074 can be on the same chip, or the same set of chips, boards, or units.

[0137] In certain embodiments, some or all of the functions described herein as being provided by a network node, base station, eNB, or other such network device may be performed by a processing circuit 2070 that executes instructions stored in a memory within the apparatus-readable medium 2080 or the processing circuit 2070. In alternative embodiments, some or all of the functions may be provided by the processing circuit 2070 in a hardwired manner, such as without executing instructions stored on a separate or discrete apparatus-readable medium. In any of these embodiments, whether or not instructions stored in an apparatus-readable storage medium are executed, the processing circuit 2070 may be configured to perform the described functions. The advantages provided by such functions are not limited to the processing circuit 2070 alone or other components of the network node 2060, but are enjoyed by the network node 2060 as a whole and / or by the end user and the wireless network as a whole.

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

[0139] Interface 2090 is used for wired or wireless communication of signaling and / or data between network node 2060, network 2006, and / or WD 2010. As shown in the figure, interface 2090 has (one or more) ports / (one or more) terminals 2094 for transmitting and receiving data to and from network 2006, for example, via a wired connection. Interface 2090 may also be connected to antenna 2062 or may include a radio front-end circuit 2092 that is part of antenna 2062 in certain embodiments. The radio front-end circuit 2092 has a filter 2098 and an amplifier 2096. The radio front-end circuit 2092 may be connected to antenna 2062 and processing circuit 2070. The radio front-end circuit may be configured to condition signals communicated between antenna 2062 and processing circuit 2070. The radio front-end circuit 2092 can receive digital data to be transmitted to other network nodes or WDs via a wireless connection. The radio front-end circuit 2092 may use a combination of filter 2098 and / or amplifier 2096 to convert the digital data into a wireless signal having appropriate channel and bandwidth parameters. The wireless signal can then be transmitted via antenna 2062. Similarly, when receiving data, antenna 2062 can collect the wireless signal, which is then converted into digital data by radio front-end circuit 2092. The digital data may be passed to processing circuit 2070. In other embodiments, the interface can include different components and / or different combinations of components.

[0140] In certain alternative embodiments, the network node 2060 may not include a separate radio front-end circuit 2092. Instead, the processing circuit 2070 may include a radio front-end circuit and may be connected to the antenna 2062 without a separate radio front-end circuit 2092. Similarly, in some embodiments, all or part of the RF transceiver circuit 2072 may be regarded as part of the interface 2090. In still other embodiments, the interface 2090 may include one or more ports or terminals 2094, a radio front-end circuit 2092, and an RF transceiver circuit 2072 as part of a wireless unit (not shown), and the interface 2090 may communicate with a baseband processing circuit 2074 that is part of a digital unit (not shown).

[0141] The antenna 2062 may include one or more antennas or an antenna array configured to transmit and / or receive wireless signals. The antenna 2062 may be connected to the radio front-end circuit 2090 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, the antenna 2062 may include one or more omnidirectional, sector, or panel antennas operable to transmit / receive wireless signals, for example, between 2 GHz and 66 GHz. Omnidirectional antennas may be used to transmit / receive wireless signals in any direction, sector antennas may be used to transmit / receive wireless signals with devices within a specific area, and panel antennas may be line-of-sight antennas used to transmit / receive wireless signals in a relatively linear fashion. In some cases, the use of two or more antennas may be referred to as MIMO. In a given embodiment, the antenna 2062 may be separate from the network node 2060 and may be connectable to the network node 2060 via an interface or port.

[0142] Antenna 2062, interface 2090, and / or processing circuit 2070 may be configured to perform any reception operation and / or certain acquisition operations described herein as being performed by a network node. Any information, data, and / or signals may be received from a wireless device, another network node, and / or any other network device. Similarly, antenna 2062, interface 2090, and / or processing circuit 2070 may be configured to perform any transmission operations described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to a wireless device, another network node, and / or any other network device.

[0143] Power supply circuit 2087 may comprise a power management circuit or be connected to a power management circuit, and is configured to supply power for the components of network node 2060 to perform the functions described herein. Power supply circuit 2087 can receive power from power supply 2086. Power supply 2086 and / or power supply circuit 2087 may be configured to supply power to the various components of network node 2060 in forms suitable for their respective components (e.g., the voltage and current levels required for their respective components), and power supply 2086 may be included in power supply circuit 2087 and / or network node 2060, or may be external. For example, network node 2060 may be connectable to an external power supply (e.g., a wall socket) via an input circuit or interface such as an electrical cable, whereby the external power supply supplies power to power supply circuit 2087. As a further example, power supply 2086 may include a power source in the form of a battery or battery pack connected to or integrated with power supply circuit 2087. In the event of a failure of the external power supply, the battery can supply backup power. Other types of power sources such as photovoltaic devices can also be used.

[0144] An alternative embodiment of network node 2060 may serve to provide a given aspect of the functionality of a network node, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein, and may include additional components not shown in FIG. 20. For example, network node 2060 may include a user interface device that enables and / or facilitates the input of information to network node 2060 and enables and / or facilitates the output of information from network node 2060. This may enable and / or facilitate a user to perform diagnostic, maintenance, repair, and other administrative functions of network node 2060.

[0145] In some embodiments, the WD may be configured to transmit and / or receive information without human direct intervention. For example, the WD may be designed to transmit information to the network at a predetermined schedule, when triggered by an internal or external event, or in response to a request from the network. Examples of WDs include, but are not limited to, smartphones, mobile phones, cellular phones, VoIP (voice over IP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premise equipment (CPEs), in-vehicle wireless terminal devices, etc.

[0146] WD can support device-to-device (D2D) communication, also known as D2D communication device in this case, by implementing 3GPP standards for, for example, sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X). As yet another specific example, in an Internet of Things (IoT) scenario, WD can represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another WD and / or network node. In this case, WD may be a machine-to-machine (M2M) device and may be referred to as an MTC device in the context of 3GPP. As one specific example, WD may be a UE implementing the 3GPP narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices include sensors, metering devices such as power meters, industrial machines, or household or personal electrical devices (e.g., refrigerators, televisions, etc.), and personal wearable devices (e.g., watches, fitness trackers, etc.). In other scenarios, WD can represent a vehicle or other device capable of monitoring and / or reporting its own operating state or other functions related to its operation. WD as described above may represent an endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Further, WD as described above may be a mobile entity, in which case WD may also be referred to as a mobile device or mobile terminal.

[0147] As shown, wireless device 2010 includes antenna 2011, interface 2014, processing circuit 2020, device-readable medium 2030, user interface device 2032, auxiliary device 2034, power supply 2036, and power supply circuit 2037. WD 2010 can include multiple combinations of one or more of the illustrated components for various wireless technologies supported by WD 2010, such as, for example, as a very partial example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, NB-IoT, or Bluetooth wireless technologies. These wireless technologies can be integrated into the same or different chips or sets of chips as other components within WD 2010.

[0148] Antenna 2011 can include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals and is connected to interface 2014. In certain alternative embodiments, Antenna 2011 may be separate from WD 2010 and may be connectable to WD 2010 via an interface or port. Antenna 2011, interface 2014, and / or processing circuit 2020 may be configured to perform any of the receive or transmit operations described herein as being performed by the WD. Any information, data, and / or signals may be received from network nodes and / or other WDs. In some embodiments, the radio front-end circuit and / or Antenna 2011 may be regarded as an interface.

[0149] As shown, interface 2014 has a wireless front - end circuit 2012 and an antenna 2011. The wireless front - end circuit 2012 has one or more filters 2018 and amplifiers 2016. The wireless front - end circuit 2014 is connected to the antenna 2011 and the processing circuit 2020 and is configured to condition signals communicated between the antenna 2011 and the processing circuit 2020. The wireless front - end circuit 2012 may be connected to the antenna 2011 or may be part of the antenna 2011. In some embodiments, instead of the WD 2010 including a separate wireless front - end circuit 2012, the processing circuit 2020 may include a wireless front - end circuit and be connected to the antenna 2011. Similarly, in some embodiments, some or all of the RF transceiver circuit 2022 can be considered part of the interface 2014. The wireless front - end circuit 2012 can receive digital data that is transmitted to other network nodes or the WD using a wireless connection. The wireless front - end circuit 2012 may use a combination of filters 2018 and / or amplifiers 2016 to convert the digital data into a wireless signal having appropriate channel and bandwidth parameters. The wireless signal can then be transmitted via the antenna 2011. Similarly, when receiving data, the antenna 2011 collects the wireless signal, and the wireless signal can then be converted into digital data by the wireless front - end circuit 2012. The digital data may be passed to the processing circuit 2020. In other embodiments, the interface may have different components and / or different combinations of components.

[0150] The processing circuit 2020 can have one or more combinations of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application-specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or hardware, software, and / or encoded logic, which can be provided either alone or in combination with other WD 2010 components such as the device-readable medium 2030, the WD 2010 function, etc. Such functions can include providing any of the various wireless functions or advantages described herein.

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

[0152] As shown, processing circuit 2020 includes one or more of RF transceiver circuit 2022, baseband processing circuit 2024, and application processing circuit 2026. In other embodiments, the processing circuit may have different components and / or different combinations of components. In certain embodiments, the processing circuit 2020 of WD2010 may have a system-on-a-chip (SOC). In some embodiments, RF transceiver circuit 2022, baseband processing circuit 2024, and application processing circuit 2026 may be on separate chips or chip sets. In an alternative embodiment, some or all of baseband processing circuit 2024 and application processing circuit 2026 may be integrated on one chip or chip set, and RF transceiver circuit 2022 may be on a separate chip or chip set. In a further alternative embodiment, some or all of RF transceiver circuit 2022 and baseband processing circuit 2024 may be on the same chip or chip set, and application processing circuit 2026 may be on a separate chip or chip set. In yet another alternative embodiment, some or all of RF transceiver circuit 2022, baseband processing circuit 2024, and application processing circuit 2026 may be integrated on the same chip or chip set. In some embodiments, RF transceiver circuit 2022 may be part of interface 2014. RF transceiver circuit 2022 may condition RF signals for processing circuit 2020.

[0153] In certain embodiments, some or all of the functions described herein as being performed by the WD may be provided by processing circuitry 2020 that executes instructions stored on a device-readable medium 2030, which may be a computer-readable storage medium in certain embodiments. In alternative embodiments, some or all of the functions may be provided by the processing circuitry 2020 in a hard-wired manner, such as without executing instructions stored on a separate or discrete device-readable storage medium. In any of these embodiments, whether or not instructions stored on a device-readable medium are executed, the processing circuitry 2020 may be configured to perform the described functions. The advantages provided by such functions are not limited to the processing circuitry 2020 alone or other components of the WD 2010, but are enjoyed by the WD 2010 as a whole and / or by the end user and the entire wireless network.

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

[0155] The apparatus-readable medium 2030 can be operative to store one or more of a computer program, software, logic, rules, code, tables, etc., an application, and / or other instructions executable by the processing circuit 2020. The apparatus-readable medium 2030 can include a computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), a mass storage medium (e.g., a hard disk), a removable storage medium (e.g., a compact disk (CD) or a digital video disk (DVD)), and / or any other volatile or non-volatile, permanent apparatus-readable and / or computer-executable memory device 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 apparatus-readable medium 2030 can be considered to be integrated.

[0156] The user interface device 2032 can provide components that enable a human user to interact with the WD2010. Such interaction can be in many forms, such as visual, auditory, tactile, etc. The user interface device 2032 can be operable to generate output to the user and also to enable the user to provide input to the WD2010. The type of interaction can vary depending on the type of user interface device 2032 installed in the WD2010. For example, if the WD2010 is a smartphone, the interaction can be done using a touch screen. If the WD2010 is a smart meter, the interaction can be done using a screen that provides usage amounts (e.g., number of gallons used) or a speaker that provides an audible alarm (e.g., when smoke is detected). The user interface device 2032 can include an input interface, devices and circuits, as well as an output interface, devices and circuits. The user interface device 2032 is configured to enable and / or facilitate the input of information to the WD2010 and is connected to the processing circuit 2020 to enable and / or facilitate the processing circuit 2020 to process the input information. The user interface device 2032 can include, for example, a microphone, proximity sensor or other sensors, keys / buttons, touch display, one or more cameras, USB port, or other input circuits. The user interface device 2032 is also configured to enable and / or facilitate the output of information from the WD2010 and to enable and / or facilitate the processing circuit 2020 to output information from the WD2010. The user interface device 2032 can include, for example, a speaker, display, vibration circuit, USB port, headphone interface, or other output circuits. Using one or more input / output interfaces, devices, and circuits of the user interface device 2032, the WD2010 can communicate with an end user and / or a wireless network and provide the benefits of the functions described herein to the end user and / or the wireless network.

[0157] The auxiliary device 2034 is operable to provide more specific functions that may not generally be performed by the WD. This may include dedicated sensors for performing measurements for various purposes, interfaces for additional types of communication such as wired communication. The components included in the auxiliary device 2034 and their types may vary depending on the embodiment and / or scenario.

[0158] The power source 2036 may be in the form of a battery or a battery pack in some embodiments. Other types of power sources such as an external power source (e.g., a wall outlet), a photovoltaic device, or a power cell can also be used. The WD 2010 may further include a power supply circuit 2037 that provides power from the power source 2036 to various parts of the WD 2010 that require power to perform any of the functions described or shown herein. The power supply circuit 2037 can have a power management circuit in certain embodiments. The power supply circuit 2037 may additionally or alternatively be operable to receive power from an external power source, in which case the WD 2010 may be connectable to an external power source (such as a wall outlet) via an interface such as an input circuit or a power cable. Also, in certain embodiments, the power supply circuit 2037 may be operable to supply power from an external power source to the power source 2036. This may be, for example, for charging the power source 2036. The power supply circuit 2037 can perform any formatting, conversion, or other modification on the power from the power source 2036 to make it suitable power for each component of the WD 2010 to which power is supplied.

[0159] Figure 21 shows an embodiment of a UE according to various aspects described herein. As used herein, a user equipment or UE does not necessarily have a user in the sense of a human user who owns and / or operates the associated equipment. Instead, a UE can represent a device (e.g., a smart sprinkler control device) that is intended for sale to or operation by a human user but may not be associated with or initially associated with a particular human user. Alternatively, a UE can represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user but can be associated with a user or operated for the benefit of a user. UE21200 can be any UE specified by the 3rd Generation Partnership Project (3GPP), including an NB-IoT UE, a machine type communication (MTC) UE, and / or an extended MTC (eMTC) UE. As shown in Figure 21, UE2100 is an example of a WD configured to communicate according to one or more communication standards promulgated by the 3rd Generation Partnership Project (3GPP), such as the 3GPP's GSM, UMTS, LTE, and / or 5G standards. As described above, the terms WD and UE can be used interchangeably. Thus, Figure 21 shows a UE, but the components described herein are equally applicable to a WD, and vice versa.

[0160] In FIG. 21, UE 2100 includes a processing circuit 2101 operably coupled to an input / output interface 2105, a radio frequency (RF) interface 2109, a network connection interface 2111, a memory 2115 including a random access memory (RAM) 2117, a read-only memory (ROM) 2119, and a storage medium 2121, a communication subsystem 2131, a power supply 2133, and / or any other components, or any combination thereof. The storage medium 2121 includes an operating system 2123, an application program 2125, and data 2127. In other embodiments, the storage medium 2121 may contain other similar types of information. A particular UE may utilize all or only a subset of the components shown in FIG. 21. The level of integration between components may vary from UE to UE. Further, a particular UE may include multiple instances of components, such as multiple processors, multiple memories, multiple transceivers, multiple transmitters, multiple receivers, etc.

[0161] In FIG. 21, the processing circuit 2101 may be configured to process computer instructions and data. The processing circuit 2101 may be implemented as one or more hardware-implemented state machines (such as in discrete logic circuitry, FPGAs, ASICs, etc.), programmable logic circuitry with appropriate firmware, a general-purpose processor such as one or more stored programs, a microprocessor, or a digital signal processor (DSP), and a combination of appropriate software, or any combination thereof, and may be configured to implement any sequential state machine operable to execute machine instructions stored in memory as a machine-readable computer program. For example, the processing circuit 2101 may include two central processing units (CPUs). The data may be information in a form suitable for use by a computer.

[0162] In the illustrated embodiment, the input / output interface 2105 may be configured to provide a communication interface to an input device, an output device, or both an input and an output device. The UE 2100 may be configured to utilize an output device using the input / output interface 2105. The output device may use the same type of interface port as the input device. For example, a USB port may be used to provide an input to the UE 2100 and to provide an output from the UE 2100. The output device may be a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smart card, another output device, or any combination thereof. The UE 2100 may be configured to utilize an input device through the input / output interface 2105 to enable and / or facilitate a user to capture information into the UE 2100. The input device may include a touch-sensing or presence-sensing display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a direction pad, a track pad, a scroll wheel, a smart card, etc. The presence-sensing display may include a capacitive or resistive touch sensor to detect an input from a user. The sensor may be, for example, an accelerometer, a gyroscope, an inclinometer, a force sensor, a magnetometer, an optical sensor, a proximity sensor, other similar sensors, or any combination thereof. For example, the input device may be an accelerometer, a magnetometer, a digital camera, a microphone, and an optical sensor.

[0163] In FIG. 21, the RF interface 2109 can be configured to provide a communication interface to RF components such as transmitters, receivers, and antennas. The network connection interface 2111 can be configured to provide a communication interface to the network 2143a. The network 2143a can include 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 2143a can have a Wi-Fi network. The network connection interface 2111 can be configured to include a receiver and a transmitter interface used to communicate with one or more other devices across a communication network according to one or more communication protocols such as Ethernet (registered trademark), TCP / IP, SONET, ATM, etc. The network connection interface 2111 can implement receiver and transmitter functions suitable for a communication network link (e.g., optical, electrical, etc.). The transmitter function and the receiver function may share circuit components, software, or firmware, or may be implemented individually.

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

[0165] In one example, the storage medium 2121 can be configured to include an application program 2125 such as an operating system 2123, a web browser application, a widget or gadget engine, or other applications, and a data file 2127. The storage medium 2121 can store any one or combination of operating systems for use by the UE 2100. For example, the application program 2125 can include executable program instructions (also referred to as a computer program product) that, when executed by the processor 2101, can configure the UE 2100 to perform operations corresponding to various exemplary methods (e.g., procedures) described herein.

[0166] The storage medium 2121 can be configured to include a plurality of physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, a flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high density digital versatile disc (HD-DVD) optical disc drive, an internal hard disk drive, a Blu-Ray optical disc drive, a holographic digital data storage (HDDS) optical disc drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, a subscriber identity module or removable user identity (SIM / RUIM) module such as a smart card memory, other memories, or any combination thereof. The storage medium 2121 can be tangibly embodied on a storage medium having a device-readable medium, which is a product manufactured to utilize a communication system that enables and / or facilitates the UE 2100 to access computer-executable instructions, application programs, etc. stored in a temporary or permanent memory for offloading or uploading data.

[0167] In FIG. 21, the processing circuit 2101 may be configured to communicate with the network 2143b using the communication subsystem 2131. The network 2143a and the network 2143b may be one or more of the same network or one or more different networks. The communication subsystem 2131 may be configured to include one or more transceivers used to communicate with the network 2143b. For example, the communication subsystem 2131 may be configured to include one or more transceivers for communicating with one or more remote transceivers of other wireless communication-enabled devices, such as other WDs, UEs, or base stations of a radio access network (RAN), according to one or more communication protocols such as IEEE 802.42, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, etc. Each transceiver may include a transmitter 2133 and / or a receiver 2135 to implement the functions of a suitable transmitter or receiver (e.g., frequency allocation, etc.) for the RAN link. Further, the transmitter 2133 and the receiver 2135 of each transceiver may share circuit components, software, or firmware, or may be implemented individually.

[0168] In the illustrated embodiment, the communication functions of the communication subsystem 2131 can include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth (registered trademark), near-field communication, location-based communication such as the use of the Global Positioning System (GPS) for determining location, other similar communication functions, or any combination thereof. For example, the communication subsystem 2131 can include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 2143b can include 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 can be a cellular network, a Wi-Fi network, and / or a short-range wireless network. The power supply 2113 can be configured to supply alternating current (AC) or direct current (DC) power to the components of the UE 2100.

[0169] The features, advantages, and / or functions described herein may be implemented in one of the components of the UE 2100 or may be divided across multiple components of the UE 2100. Further, the features, advantages, and / or functions described herein may be implemented in any combination of hardware, software, or firmware. In one example, the communication subsystem 2131 can be configured to include any of the components described herein. Further, the processing circuit 2101 can be configured to communicate with any of such components via the bus 2102. In another example, any of such components can be represented by program instructions stored in a memory that, when executed by the processing circuit 2101, perform the corresponding functions described herein. In another example, the functions of any of such components may be divided between the processing circuit 2101 and the communication subsystem 2131. In another example, functions of any of such components that are not highly processing-intensive may be implemented in software or firmware, and functions with a high processing load may be implemented in hardware.

[0170] FIG. 22 is a schematic block diagram showing a virtualization environment 2200 that can virtualize functions implemented according to some embodiments. Virtualization means creating a virtual version of a device or equipment, and may include virtualizing a hardware platform, a storage device, and network resources. In this specification, virtualization can be applied to a node (e.g., a virtualized base station or a virtualized radio access node), or a device (e.g., a UE, a wireless device, or any other type of communication device) or its components, and at least a part of the function is implemented as one or more virtual components (e.g., using one or more applications, components, functions, virtual machines, or containers executed on one or more physical processing nodes in one or more networks).

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

[0172] The function may be implemented by one or more applications 2220 (which may also be referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operable to implement some of the features, functions, and / or advantages of some of the embodiments disclosed in this specification. The application 2220 is executed in a virtualization environment 2200 that provides hardware 2230 having a processing circuit 2260 and a memory 2290. The memory 2290 includes instructions 2295 executable by the processing circuit 2260, whereby the application 2220 is operable to provide one or more of the features, advantages, and / or functions disclosed in this specification.

[0173] The virtualized environment 2200 has a general - purpose or special - purpose network hardware device (or node) 2230 having a set of one or more processors or processing circuits 2260, which may be a commercially available off - the - shelf (COTS) processor, a dedicated application - specific integrated circuit (ASIC), or any other type of processing circuit including digital or analog hardware components or dedicated processors. Each hardware device may have a memory 2290 - 1, which can be a non - persistent memory for temporarily storing instructions 2295 or software executed by the processing circuit 2260. For example, the instructions 2295 can include program instructions (also called computer program products) that can configure the hardware node 2220 to perform operations corresponding to various exemplary methods (e.g., procedures) described herein when executed by the processing circuit 2260. Such operations can also be assigned to one or more virtual nodes 2220 hosted by the hardware node 2230.

[0174] Each hardware device may have one or more network interface controllers (NICs) 2270, also known as network interface cards, including a physical network interface 2280. Each hardware device may also further include a non - transient and persistent machine - readable storage medium 2290 - 2 for storing software 2295 and / or instructions executable by the processing circuit 2260. The software 2295 can include any kind of software, including software for instantiating one or more virtualization layers 2250 (also called hypervisors), software for executing virtual machines 2240, and software that enables the execution of functions, features, and / or advantages described in connection with some embodiments described herein.

[0175] The virtual machine 2240 has virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be executed by a corresponding virtualization layer 2250 or hypervisor. Various embodiments of the instances of the virtual appliance 2220 may be implemented on one or more virtual machines 2240, and the implementation may be performed in different ways.

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

[0177] As shown in FIG. 22, the hardware 2230 may be a stand-alone network node with general-purpose or specific components. The hardware 2230 can have an antenna 22225 and can implement some functions using virtualization. Alternatively, the hardware 2230 may be part of a larger hardware cluster (such as within a data center or customer premise equipment (CPE)) where many hardware nodes operate in cooperation and are managed, among other things, by a management and orchestration (MANO) 22100 that oversees the lifecycle management of the application 2220.

[0178] The virtualization of hardware is sometimes referred to as network function virtualization (NFV) in some fields. NFV can be used to integrate many network device types into industry-standard high-volume server hardware, physical switches, and physical storage located within a data center, as well as customer premise equipment.

[0179] In the context of NFV, the virtual machine 2240 may be a software implementation of a physical device that executes a program as if it were running on a physical and non-virtualized device. Each virtual machine 2240, and the portion of the hardware 2230 that executes that virtual machine, is the hardware dedicated to that virtual machine and / or the hardware shared by that virtual machine with other virtual machines 2240, forming individual virtual network elements (VNE).

[0180] Furthermore, in the context of NFV, a virtual network function (VNF) is responsible for processing a specific network function running on one or more virtual machines 2240 in the hardware network infrastructure 2230, corresponding to the application 2220 in FIG. 22.

[0181] In some embodiments, one or more radio units 22200, each including one or more transmitters 22220 and one or more receivers 22210, may be connected to one or more antennas 22225. The radio unit 22200 can communicate directly with the hardware node 2230 via one or more appropriate network interfaces and can be used in combination with virtual components to provide radio functions such as radio access nodes or base stations to virtual nodes. Nodes configured in this way can also communicate with one or more UEs, as described elsewhere in this specification.

[0182] In some embodiments, some signaling may be performed using the control system 22230, which can alternatively be used for communication between the hardware node 2230 and the radio unit 22200.

[0183] Referring to FIG. 23, according to one embodiment, a communication system includes a telecommunication network 2310 such as a 3GPP type cellular network, which consists of an access network 2311 such as a radio access network and a core network 2314. The access network 2311 has a plurality of base stations 2312a, 2312b, 2312c such as NB, eNB, gNB, or other types of radio access points, and the plurality of base stations 2312a, 2312b, 2312c respectively define corresponding coverage areas 2313a, 2313b, 2313c. Each base station 2312a, 2312b, 2312c can be connected to the core network 2314 using a wired or wireless connection 2315. The first UE 2391 located in the coverage area 2313c is configured to wirelessly connect to the corresponding base station 2312c or to be paged by the corresponding base station 2312c. The second UE 2392 within the coverage area 2313a can be wirelessly connected to the corresponding base station 2312A. Although a plurality of UEs 2391, 2392 are shown in this example, the disclosed embodiments are equally applicable to situations where a single UE is within the coverage area or where a single UE is connected to the corresponding base station 2312.

[0184] The telecommunications network 2310 is itself connected to a host computer 2330, which may be implemented in the hardware and / or software of a stand-alone server, a cloud-implemented server, a distributed server, or as processing resources within a server farm. The host computer 2330 may be owned or under the management of a service provider and may be operated by or on behalf of the service provider. The connections 2321 and 2322 between the telecommunications network 2310 and the host computer 2330 may extend directly from the core network 2314 to the host computer 2330 or may pass through an optional intermediate network 2320. The intermediate network 2320 may be one of a public network, a private network, a hosted network, or a combination of two or more, and if there is an intermediate network 2320, the intermediate network 2320 may be a backbone network or the Internet. Specifically, the intermediate network 2320 may have two or more sub-networks (not shown).

[0185] The communication system of FIG. 23 as a whole realizes the connectivity between the connected UEs 2391, 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, 2392 are configured to communicate data and / or signals through the OTT connection 2350 using the access network 2311, the core network 2314, any intermediate network 2320, and optionally further infrastructure (not shown) as a medium. 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 of the uplink communication and the downlink communication. For example, the base station 2312 will not be notified or need not be notified about the past routing of the incoming downlink communication having data transmitted from the host computer 2330 (e.g., handed over) to the connected UE 2391. Similarly, the base station 2312 need not be aware of the future routing of the outgoing uplink communication transmitted from the UE 2391 towards the host computer 2330.

[0186] An exemplary implementation according to one embodiment of the UE, base station, and host computer discussed in the previous paragraph will be described with reference to FIG. 24. In communication system 2400, host computer 2410 has hardware 2415 that includes a communication interface 2416 configured to set up and maintain a wired or wireless connection with interfaces of different communication devices of communication system 2400. Host computer 2410 further has a processing circuit 2418 that can have storage and / or processing capabilities. In particular, processing circuit 2418 may have one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) configured to execute instructions. Host computer 2410 further has software 2411 stored in host computer 2410 or accessible to host computer 2410 and executable by processing circuit 2418. Software 2411 includes host application 2412. Host application 2412 may be operable to provide services to remote users such as UE 2430 that connect via an OTT connection 2450 that terminates at UE 2430 and host computer 2410. When providing services to remote users, host application 2412 can provide user data transmitted using OTT connection 2450.

[0187] The communication system 2400 further includes a base station 2420 provided within the communication system, the base station 2420 having hardware 2425 that enables it to communicate with the host computer 2410 and the UE 2430. The hardware 2425 includes a communication interface 2426 for setting up and maintaining a wired or wireless connection with an interface of different communication devices of the communication system 2400, and may include a wireless interface 2427 for setting up and maintaining at least a wireless connection 2470 with a UE 2430 located within a coverage area (not shown in FIG. 24) served by the base station 2420. The communication interface 2426 may be configured to facilitate a connection 2460 to the host computer 2410. The connection 2460 may be direct, or may be via a core network (not shown in FIG. 24) of the telecommunications system and / or via one or more intermediate networks external to the telecommunications system. In the illustrated embodiment, the hardware 2425 of the base station 2420 further includes a processing circuit 2428 that may have one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) configured to execute instructions.

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

[0189] The communication system 2400 further includes the UE 2430 already mentioned. Its hardware 2435 can include a radio interface 2437 configured to set up and maintain a radio connection 2470 with a base station that provides services to the coverage area where the UE 2430 is currently located. The hardware 2435 of the UE 2430 further includes a processing circuit 2438 having one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) configured to execute instructions.

[0190] The UE 2430 further has software 2431 stored in the UE 2430 or accessible to the UE 2430 and executable by the processing circuit 2438. The software 2431 includes a client application 2432. The client application 2432 is operable to provide services to a human or non-human user via the UE 2430 with the support of the host computer 2410. In the host computer 2410, the running host application 2412 can communicate with the running client application 2432 via an OTT connection 2450 that terminates at the UE 2430 and the host computer 2410. When providing services to the user, the client application 2432 may receive request data from the host 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 to be provided. The software 2431 can also include program instructions (also referred to as a computer program product) that can configure the UE 2430 to perform operations corresponding to various exemplary methods (e.g., procedures) described herein when executed by the processing circuit 2438.

[0191] Note that the host computer 2410, base station 2420, and UE 2430 shown in FIG. 24 may be similar or identical to the host computer 2330, one of the base stations 2312a, 2312b, 2312c, and one of the UEs 2391, 2392 in FIG. 23, respectively. That is, the internal operations of these entities may be the same as those shown in FIG. 24, and independently of that, the surrounding network topology may be the same as that shown in FIG. 16.

[0192] In FIG. 24, the OTT connection 2450 is abstractly depicted to illustrate the communication between the host computer 2410 and the UE 2430 via the base station 2420, and the exact routing of the intermediate devices and messages through these devices is not explicitly shown. The network infrastructure can determine a routing that may be configured to hide from the UE 2430, or from the host computer 2410 operated by the service provider, or from both. While the OTT connection 2450 is active, the network infrastructure can further make a decision to dynamically change the routing (e.g., based on load distribution considerations or network reconfiguration).

[0193] The wireless connection 2470 between the UE 2430 and the base station 2420 follows the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT services provided to the UE 2430 using the OTT connection 2450 in which the wireless connection 2470 forms the last segment. More precisely, the exemplary embodiments disclosed herein relate to the end-to-end service quality (QoS) of a data flow including corresponding radio bearers for a data session between a user equipment (UE) and another entity such as an OTT data application or service external to the 5G network, and can improve the flexibility of the network for monitoring. These and other advantages can facilitate a more timely design, implementation, and deployment of 5G / NR solutions. Further, such embodiments can facilitate flexible and timely control of data session QoS, which can lead to improvements in capacity, throughput, latency, etc., as envisioned by 5G / NR and important for the growth of OTT services.

[0194] Measurement procedures may be provided to monitor data rate, latency, and other network operating modes that are improved by one or more embodiments. Further, there may be an optional network function for reconfiguring the OTT connection 2450 between the host computer 2410 and the UE 2430 in response to variations in the measurement results. The measurement procedures and / or network functions for reconfiguring the OTT connection 2450 may be implemented in the software 2411 and hardware 2415 of the host computer 2410, or the software 2431 and hardware 2435 of the UE 2430, or both. In some embodiments, sensors (not shown) may be provided within or associated with the communication devices through which the OTT connection 2450 passes, and the sensors may participate in the measurement procedures 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. The reconfiguration of the OTT connection 2450 can include message format, retransmission settings, priority routing, etc. The reconfiguration need not affect the base station 2420 and may be unknown or imperceptible to the base station 2420. Such procedures and functions are known in the art and can be practiced. In certain embodiments, the measurement may involve dedicated UE signaling that facilitates measurement of the host computer 2410, such as throughput, propagation time, latency, etc. The measurement can be performed by having the software 2411 and 2431 transmit messages, particularly empty or "dummy" messages, using the OTT connection 2450 while monitoring propagation time, errors, etc.

[0195] FIG. 25 is a flowchart showing a method and / or procedure implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, and in some exemplary embodiments, these may be those described with reference to other drawings herein. For simplicity of the present disclosure, only the drawing reference to FIG. 25 is included in this section. In step 2510, the host computer provides user data. In sub-step 2511 (which may be optional) of step 2510, the host computer provides user data by executing a host application. In step 2520, the host computer starts a transmission to carry the user data to the UE. In step 2530 (which may be optional), the base station transmits the user data carried in the transmission started by the host computer to the UE according to the teachings of the embodiments described throughout the present disclosure. In step 2540 (which may also be optional), the UE executes a client application related to the host application executed by the host computer.

[0196] FIG. 26 is a flowchart showing a method and / or procedure implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, and these may be those described with reference to other drawings herein. For simplicity of the present disclosure, only the drawing reference to FIG. 26 is included in this section. In step 2610 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides user data by executing a host application. In step 2620, the host computer starts a transmission to carry the user data to the UE. The transmission may be passed through the base station according to the teachings of the embodiments described throughout the present disclosure. In step 2630 (which may be optional), the UE receives the user data carried in the transmission.

[0197] FIG. 27 is a flowchart showing an exemplary method and / or procedure implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be those described with reference to other drawings herein. For simplicity of disclosure, only the reference to FIG. 27 is included in this section. In step 2710 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 2720, the UE provides user data. In sub-step 2721 of step 2720 (which may be optional), the UE provides user data by executing a client application. In sub-step 2711 of step 2710 (which may be optional), the UE executes a client application that provides user data in response to the received input data provided by the host computer. When providing user data, the executed client application may further consider user input received from the user. Regardless of the particular method by which user data is provided, the UE starts transmitting the user data to the host computer in sub-step 2730 (which may be optional). In step 2740 of the method, the host computer receives the user data transmitted from the UE according to the teachings of the embodiments described throughout this disclosure.

[0198] FIG. 28 is a flowchart showing an exemplary method and / or procedure implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to other drawings herein. For simplicity of disclosure, only the reference to FIG. 28 is included in this section. In step 2810 (which may be optional), according to the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 2820 (which may be optional), the base station starts transmitting the received user data to the host computer. In step 2830 (which may be optional), the host computer receives the user data carried in the transmission started by the base station.

[0199] As described herein, a device and / or apparatus can be represented by a semiconductor chip, a chipset, or a (hardware) module including such chips or chipset. However, this does not rule out the possibility that the function of the device or apparatus is implemented as a software module such as a computer program or a computer program product having a portion of executable software code for execution by a processor or operating on a processor instead of being implemented in hardware. Further, the function of the device or apparatus can be implemented by any combination of hardware and software. The device or apparatus can also be regarded as an assembly of multiple devices and / or apparatuses, whether they cooperate functionally with each other or are independent of each other. Further, as long as the function is maintained, it is also possible to implement the device or apparatus distributed throughout the system. Such principles and similar principles are considered to be known to those skilled in the art.

[0200] Furthermore, the functions described herein as being performed by a wireless device or a network node may be distributed among a plurality of wireless devices and / or network nodes. That is, the functions of the network nodes and wireless devices described herein are not limited to performance by a single physical device, and in fact, it is contemplated that they can be distributed among a plurality of physical devices.

[0201] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terms used herein should be interpreted as having a meaning consistent with the context of this specification and the related art, and it will be further understood that they should not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0202] Furthermore, certain terms used in this disclosure, including the specification, drawings, and its exemplary embodiments, can be used synonymously in certain instances. Such terms include, but are not limited to, for example, data and information. These terms and / or other terms that may be synonymous with each other can be used synonymously herein, but it should be understood that there may be cases where such terms are not intended to be used synonymously. Additionally, prior art knowledge that is not expressly incorporated by reference herein in its entirety is not incorporated by reference herein. All publications referred to are incorporated by reference herein in their entirety.

[0203] As used herein, unless expressly stated to the contrary, the phrases "at least one" and "one or more" following a concatenated list of items (e.g., "A and B", "A, B, and C") are intended to mean "at least one item selected from the list of items consisting of ~". For example, "at least one of A and B" is intended to mean A, B, or both A and B. Similarly, "one or more of A, B, and C" is intended to mean A, B, C, A and B, B and C, A and C, or A, B, and C.

[0204] As used herein, unless expressly stated otherwise, when a concatenated list of items (e.g., "A and B", "A, B, and C") follows the phrase "a plurality of", it is intended that "there are a plurality of items, each of which is selected from the list of items being enumerated". For example, "a plurality of A and B" is intended to mean more than one A, more than one B, or at least one A and at least one B.

[0205] The foregoing are merely illustrative of the principles of the present disclosure. Various modifications and changes to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. Accordingly, it will be understood that those skilled in the art can devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the present disclosure and are thus within the spirit and scope of the present disclosure. As will be understood by those skilled in the art, various exemplary embodiments can be used together with one another and in a compatible manner with each other.

Claims

1. A method performed by a key management server in a communication network, comprising: Receiving, from an Authentication Server Function (AUSF), information associated with a specific user, wherein the information includes: An anchor security key (Kakma) that is not specific to an application, and A first identifier (KakmaID) of the anchor security key that is not specific to the application, Receiving, from an application function, a request for a security key (Kaf) specific to an application session for the specific user, wherein the request includes a further identifier (KakmaID) of the anchor security key that is not specific to the application and is associated with the specific user, Generating, based on a match between the first identifier and the further identifier, the security key (Kaf) specific to the application session based on the anchor security key (Kakma) that is not specific to the application.

2. The key management server has a plurality of Anchor Authentication and Key Management Function (AAnF) instances for authentication and key management for an application, each AAnF instance corresponding to a range of User Equipment Routing Indicators (RID), The request further includes a routing indicator (RID) associated with the specific user, The method further includes selecting an AAnF instance based on the received RID, The method according to claim 1, wherein generating the security key (Kaf) specific to the application session is performed by the selected AAnF instance.

3. The information associated with the specific user further includes a Subscription Permanent Identifier (SUPI), The method according to claim 1 or 2, further comprising selecting an Integrated Data Management (UDM) function within the communication network based on the SUPI.

4. The key management server is associated with one or more ranges of User Equipment Routing Indicators (RID), The method further includes registering the association between the key management server and the one or more ranges with a Network Repository Function (NRF) within the communication network, The method according to any one of claims 1 to 3.

5. A key management function within a communication network, wherein the key management function an interface circuit configured to communicate with at least an application function and an authentication server function (AUSF) within the communication network; a processing circuit operably connected to the interface circuit, whereby the processing circuit and the interface circuit are configured to perform operations corresponding to the method according to any one of claims 1 to 4. A key management function having **Claim 6** A key management function within a communication network, the key management function being configured to perform operations corresponding to the method according to any one of claims 1 to 4. **Claim 7** A computer-readable medium storing computer-executable instructions that, when executed by a processing circuit associated with a key management function within a communication network, configure the key management function to perform operations corresponding to the method according to any one of claims 1 to 4. **Claim 8** A computer program having computer-executable instructions that, when executed by a processing circuit associated with a key management function within a communication network, configure the key management function to perform operations corresponding to the method according to any one of claims 1 to 4.

Images