Authorization of set of entities for process in communication network environment

Abstract

Techniques are disclosed for authorization of a set of network entities for a process in a communication network environment. By way of one example, a method includes sending to an authorization entity, from the consumer network entity of a set of consumer network entities, an authorization request in response to a service request from another one of the set of consumer network entities, for permission to request that a producer network entity participate in a process. The method further includes receiving, at the consumer network entity of the set of consumer network entities, an authorization response from the authorization entity, wherein the authorization response comprises data indicative of whether the set of consumer network entities are authorized.

Description

[0001] AUTHORIZATION OF SET OF ENTITIES FOR PROCESS IN COMMUNICATION NETWORK ENVIRONMENT

[0002] Field

[0003] The field relates generally to communication networks, and more particularly, but not exclusively, to security management in such communication networks.

[0004] Background

[0005] This section introduces aspects that may be helpful in facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0006] Fourth generation (4G) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high-capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (5G) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (loT) networks.

[0007] While 5G networks are intended to enable massive loT services (e.g., very large numbers of limited capacity devices) and mission-critical loT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services providing improved wireless Internet access for mobile devices.

[0008] In an example communication system, user equipment (5G UE in a 5G network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point of an access network referred to as a 5G AN in a 5G network. The access point (e.g., gNB) is illustratively part of an access network of the communication system.

[0009] For example, in a 5G network, the access network referred to as a 5G AN is described in 5G Technical Specification (TS) 23.501, entitled “Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” and TS 23.502, entitled “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS),” the disclosures of which are incorporated by reference herein in their entireties. In general, the access point (e.g., gNB) provides access for the UE to a core network (CN or 5GC), which then provides access for the UE to other UEs and / or a data network such as a packet data network (e.g., Internet).

[0010] TS 23.501 goes on to define a 5G Service-Based Architecture (SBA) which models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs).

[0011] Furthermore, TS 33.501, entitled “Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety, further describes security management details associated with a 5G network.

[0012] Security management is an important consideration in any communication network environment. However, due to continuing attempts to improve the architectures and protocols associated with a 5G network in order to increase network efficiency and / or subscriber convenience, security management issues associated with data exchanged in the communication network environment can present a significant challenge. For example, implementing network analytics functionalities in the communication network environment is a technical challenge.

[0013] Summary

[0014] Illustrative embodiments provide techniques for authorization of a set of network entities in a process in a communication network environment.

[0015] In one illustrative embodiment, from a consumer network entity perspective, a method comprises sending to an authorization entity, from the consumer network entity of a set of consumer network entities, an authorization request in response to a service request from another one of the set of consumer network entities, for permission to request that a producer network entity participate in a process. The method further comprises receiving, at the consumer network entity of the set of consumer network entities, an authorization response from the authorization entity, wherein the authorization response comprises data indicative of whether the set of consumer network entities are authorized.

[0016] In one illustrative embodiment, from an authorization entity perspective, a method comprises receiving, at the authorization entity, an authorization request from a consumer network entity of a set of consumer network entities, based on a service request initiated from one of the other consumer network entities, for permission to request that a producer network entity participate in a process. The method further comprises sending, from the authorization entity, an authorization response to the consumer network entity of the set of consumer network entities, wherein the authorization response comprises data indicative of whether the set of consumer network entities are authorized.

[0017] In one illustrative embodiment, from a producer network entity perspective, a method comprises receiving, at the producer network entity, a service request with authorization data, generated by an authorization entity, from a consumer network entity of a set of consumer network entities based on a request initiated from one of the other consumer network entities, wherein the service request is a request that the producer network entity participate in a process. The method further comprises performing, at the producer network entity, an authorization of the set of consumer network entities based on the authorization data. The method further comprises responding, by the producer network entity, to the service request based on results of the authorization.

[0018] Advantageously, authorization of a set of consumer network entities can occur in the context of a variety of different processes including, but not limited to, one or more of: (i) a process for training a model; (ii) a process for sharing a model; (iii) a process for sharing an output of a model; and (iv) a process for sharing analytics data. Authorization can occur in accordance with other processes. Further, authorization can occur in either a non-roaming or roaming scenario. By way of example only, in one or more illustrative embodiments, authorization techniques verify information of each of a set of consumer network entities for training a model, particularly but not limited to in a federated learning process context, wherein a given one of the set of consumer network entities can directly or indirectly request for a service in either a non-roaming or roaming scenario.

[0019] Further illustrative embodiments are provided in the form of a non-transitory computer readable medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above and / or other steps, operations, and the like. Still further illustrative embodiments comprise an apparatus with a processor and a memory configured to perform the above and / or other steps, operations, and the like. Some illustrative embodiments comprise a system configured to perform the above and / or other steps, operations, and the like. Further, some illustrative embodiments comprise an apparatus or a system comprising means for performing the above and / or other steps, operations, and the like. These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

[0020] Brief Description of the Drawings

[0021] FIG. 1 illustrates a communication network environment with which one or more illustrative embodiments may be implemented.

[0022] FIG. 2 illustrates user equipment and entities with which one or more illustrative embodiments may be implemented.

[0023] FIG. 3 illustrates an authorization procedure for federated learning-based network analytics in a non-roaming communication network environment according to an illustrative embodiment.

[0024] FIG. 4 illustrates an authorization procedure for federated learning-based network analytics in a roaming communication network environment according to an illustrative embodiment.

[0025] Detailed Description

[0026] Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for security management in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and / or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing the 3rd Generation Partnership Project (3GPP) system elements such as a 3GPP next generation system (5G), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems such as 6G communication systems.

[0027] In accordance with illustrative embodiments implemented in a 5G communication system environment, one or more 3GPP technical specifications (TS) and technical reports (TR) may provide further explanation of network elements / functions and / or operations that may interact with parts of the inventive solutions, e.g., the above-referenced 3GPP TS 23.501, TS 23.502, and TS 33.501. Other 3GPP TS / TR documents may provide other details that one of ordinary skill in the art will realize, for example, 3GPP TS 23.288, entitled “Technical Specification Group Services and System Aspects; Architecture Enhancements for 5G System (5GS) to Support Network Data Analytics Services,” the disclosure of which is incorporated by reference herein in its entirety. Note that 3GPP TS / TR documents are non-limiting examples of communication network standards (e.g., specifications, procedures, reports, requirements, recommendations, and the like). However, while well-suited for 5G-related 3GPP standards, embodiments are not necessarily intended to be limited to any particular standards.

[0028] It is to be understood that the term 5G network, and the like (e.g., 5G system, 5G communication system, 5G environment, 5G communication environment etc.), in some illustrative embodiments, may be understood to comprise all or part of an access network and all or part of a core network. However, the term 5G network, and the like, may also occasionally be used interchangeably herein with the term 5GC network, and the like, without any loss of generality, since one of ordinary skill in the art understands any distinctions.

[0029] Prior to describing illustrative embodiments, a general description of certain main components of a 5G network will be described below in the context of FIGS. 1 and 2.

[0030] FIG. 1 shows a communication system 100 within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system 100 are intended to represent some main functions provided within the system, e.g., control plane functions, user plane functions, etc. As such, the blocks shown in FIG. 1 reference specific elements in 5G networks that provide some of these main functions. However, other network elements may be used to implement some or all of the main functions represented. Also, it is to be understood that not all functions of a 5G network are depicted in FIG. 1. Rather, at least some functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures may depict some additional elements / functions (i.e., network entities).

[0031] Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface 103 with an access point 104. It is to be understood that UE 102 may use one or more other types of access points (e.g., access functions, networks, etc.) to communicate with the 5GC network other than a gNB. By way of example only, the access point 104 may be any 5G access network (gNB), an untrusted non-3GPP access network that uses an Non-3GPP Interworking Function (N3IWF), a trusted non-3GPP network that uses a Trusted Non-3GPP Gateway Function (TNGF) or wireline access that uses a Wireline Access Gateway Function (W-AGF) or may correspond to a legacy access point (e.g., eNB). Furthermore, access point 104 may be a wireless local area network (WLAN) access point as will be further explained in illustrative embodiments described herein.

[0032] The UE 102 may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, an loT device, or any other type of communication device. The term “user equipment” as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

[0033] In one illustrative embodiment, UE 102 is comprised of a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores a permanent subscription identifier and its related key, which are used to uniquely identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions. Alternative illustrative embodiments may not use UICC-based authentication, e.g., a Non-Public (Private) Network (NPN).

[0034] Note that, in one example, the permanent subscription identifier is an International Mobile Subscriber Identity (IMSI) unique to the UE. In one embodiment, the IMSI is a fixed 15 -digit length and consists of a 3 -digit Mobile Country Code (MCC), a 3 -digit Mobile Network Code (MNC), and a 9-digit Mobile Station Identification Number (MSIN). In a 5G communication system, an IMSI is referred to as a Subscription Permanent Identifier (SUPI). In the case of an IMSI as a SUPI, the MSIN provides the subscriber identity. Thus, only the MSIN portion of the IMSI typically needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information, used by the serving network to route to the correct home network. When the MSIN of a SUPI is encrypted, it is referred to as Subscription Concealed Identifier (SUCI). Another example of a SUPI uses a Network Access Identifier (NAI). NAI is typically used for loT communication.

[0035] The access point 104 is illustratively part of a radio access network or RAN of the communication system 100. Such a radio access network may comprise, for example, a 5G System having a plurality of base stations. Components of a radio access network may, more generally, be considered “radio access entities.”

[0036] Further, the access point 104 in this illustrative embodiment is operatively coupled to an Access and Mobility Management Function (AMF / SEAF) 106. In a 5G network, the AMF / SEAF supports, inter alia, mobility management (MM) and security anchor (SEAF) functions.

[0037] AMF / SEAF 106 in this illustrative embodiment is operatively coupled to (e.g., uses the services of) other network functions 108. As shown, some of these other network functions 108 include, but are not limited to, a Network Repository Function (NRF), a Network Data Analytics Function (NWDAF), and a Secure Edge Protection Proxy (SEPP). These listed network function examples are typically implemented in the home network of the UE subscriber in a non-roaming context, but can also be implemented in a visited network in a roaming context. The NRF is a centralized repository for all the 5G network functions (NFs) in the operator’s network. The NWDAF is a 5G network function that collects data from various 5GC network functions, application functions, as well as operations, administration, and management (0AM) systems, and operational support systems. The NWDAF is configured to facilitate the way 5GC data is produced and consumed, as well as to generate analytical insights and take actions based on the analytical insights. It is also realized that third- party applications can also be enabled to operate with one or more network functions in the 5GC. The SEPP is configured to protect NF specific content in the messages that are sent over a roaming inter-network interface and typically resides at the perimeter of the PLMN network to protect the PLMN from outside traffic and additionally implements transport layer security and application layer security for all the data and signalling exchanged between two internetwork network functions at the service layer.

[0038] Other network functions 108 may include network functions that can act as service producers (NFp) and / or service consumers (NFc). By way of example only, NWDAFs (and / or logical functions therein, e.g., AnLF, MTLF, etc.) can act as NFc functions and / or NFp functions. Note that any network function can be a service producer for one service and a service consumer for another service. Further, when the service being provided includes data, the data-providing NFp is referred to as a data producer, while the data-requesting NFc is referred to as a data consumer. A data producer may also be an NF that generates data by modifying or otherwise processing data produced by another NF. Note that NFs may, more generally, be considered “network entities” whereby a network entity that consumes one or more of data and a service can be considered a “consumer network entity” and a network entity that produces one or more of data and a service can be considered a “producer network entity.” Note that a UE, such as UE 102, is typically subscribed to what is referred to as a Home Public Land Mobile Network (HPLMN) in which some or all of the functions 106 and 108 reside. Alternatively the UE, such as UE 102, may receive services from an NPN where these functions may reside. The HPLMN is also referred to as the Home Environment (HE). If the UE is roaming (not in the HPLMN), it is typically connected with a Visited Public Land Mobile Network (VPLMN) also referred to as a visited network, while the network that is currently serving the UE is also referred to as a serving network. In the roaming case, some of the functions 106 and 108 can reside in the VPLMN, in which case, functions in the VPLMN communicate with functions in the HPLMN as needed. Communication between the HPLMN and the VPLMN can be protected by respective SEPPs. However, in a non-roaming scenario, access and mobility management functions 106 and the other network functions 108 reside in the same communication network, i.e., HPLMN. Embodiments described herein, unless otherwise specified, are not necessarily limited by which functions reside in which PLMN (i.e., HPLMN or VPLMN).

[0039] The access point 104 is also operatively coupled (via one or more of functions 106 and / or 108) to a Session Management Function (SMF) 110, which is operatively coupled to a User Plane Function (UPF) 112. UPF 112 is operatively coupled to a Packet Data Network, e.g., Internet 114. Note that the thicker solid lines in this figure denote a user plane (UP) of the communication network, as compared to the thinner solid lines that denote a control plane (CP) of the communication network. It is to be appreciated that network (e.g., Internet) 114 in FIG. 1 may additionally or alternatively represent other network infrastructures including, but not limited to, cloud computing infrastructure and / or edge computing infrastructure. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative embodiments and may be found in appropriate 3GPP 5G documentation. Note that functions shown in 106, 108, 110 and 112 are examples of network functions (NFs).

[0040] It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the communication system 100 may comprise other elements / functions not expressly shown herein.

[0041] Accordingly, the FIG. 1 arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements / functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

[0042] It is also to be noted that while FIG. 1 illustrates system elements as singular functional blocks, the various subnetworks that make up the 5G network are partitioned into so-called network slices. Network slices (network partitions) are logical networks that provide specific network capabilities and network characteristics that can support a corresponding service type, optionally using network function virtualization (NFV) on a common physical infrastructure. With NFV, network slices are instantiated as needed for a given service, e.g., eMBB service, massive loT service, and mission-critical loT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE 102 is configured to access one or more of these services via access point 104.

[0043] FIG. 2 is a block diagram illustrating computing architectures for various participants in methodologies according to illustrative embodiments. More particularly, system 200 is shown comprising user equipment (UE) 202 and a plurality of entities 204-1, . . . . , 204-N. For example, in illustrative embodiments and with reference back to FIG. 1, UE 202 can represent UE 102, while entities 204-1, . . . , 204-N can represent functions 106 and 108 (i.e., network entities such as, but not limited to, NRF, NWDAF, SEPP), as well as access point 104 (i.e., radio access entity such as, but not limited to, a RAN node or gNB). It is to be appreciated that the UE 202 and entities 204-1, . . . . , 204-N are configured to interact to provide security management and other techniques described herein.

[0044] The user equipment 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. The processor 212 of the user equipment 202 includes a security management processing module 214 that may be implemented at least in part in the form of software executed by the processor. The security management processing module 214 performs security management described in conjunction with subsequent figures and otherwise herein. The memory 216 of the user equipment 202 includes a security management storage module 218 that stores data generated or otherwise used during security management operations.

[0045] Each of the entities (individually or collectively referred to herein as 204) comprises a processor 222 (222-1, . . . , 222-N) coupled to a memory 226 (226-1, . . . , 226-N) and interface circuitry 220 (220-1, . . . , 220-N). Each processor 222 of each entity 204 includes a security management processing module 224 (224-1, . . . , 224-N) that may be implemented at least in part in the form of software executed by the processor 222. The security management processing module 224 performs security management operations described in conjunction with subsequent figures and otherwise herein. Each memory 226 of each entity 204 includes a security management storage module 228 (228-1, . . . , 228-N) that stores data generated or otherwise used during security management operations.

[0046] The processors 212 and 222 may comprise, for example, microprocessors such as central processing units (CPUs), application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

[0047] The memories 216 and 226 may be used to store one or more software programs that are executed by the respective processors 212 and 222 to implement at least a portion of the functionality described herein. For example, security management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 212 and 222.

[0048] A given one of the memories 216 and 226 may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a computer or processor readable (non-transitory or storage) medium that has executable program code embodied therein. Other examples of computer or processor readable media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other computer or processor readable media.

[0049] Further, the memories 216 and 226 may more particularly comprise, for example, electronic random- access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phasechange RAM (PC-RAM) or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

[0050] The interface circuitries 210 and 220 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

[0051] It is apparent from FIG. 2 that user equipment 202 and plurality of entities 204 are configured for communication with each other as security management participants via their respective interface circuitries 210 and 220. This communication involves each participant sending data to and / or receiving data from one or more of the other participants. The term “data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between participants including, but not limited to, identity data, key pairs, key indicators, tokens, secrets, security management messages, registration request / response messages and data, request / response messages, authorization and / or authentication request / response messages and data, metadata, control data, audio, video, multimedia, consent data, other messages, etc.

[0052] It is to be appreciated that the particular arrangement of components shown in FIG. 2 is an example only, and numerous alternative configurations may be used in other embodiments. For example, any given network element / function and / or access point can be configured to incorporate additional or alternative components and to support other communication protocols.

[0053] Other system elements such as access point 104, SMF 110, and UPF 112 may each be configured to include components such as a processor, memory and network interface. Also, entities such as third-party applications and network operators can participate in methodologies described herein via computing devices configured to include components such as a processor, memory and network interface. These elements and devices need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform. More generally, FIG. 2 can be considered to represent processing devices configured to provide respective security management functionalities and operatively coupled to one another in a communication system. By way of example only, all or parts of each of UE 202 and the plurality of entities 204 (e.g., processor and memory) can be considered examples of means for performing one or more operations, one or more steps, one or more functions, one or more processes, etc. as described herein.

[0054] As mentioned above, the 3GPP TS 23.501 defines the 5GC network architecture as service-based, e.g., Service-Based Architecture (SBA). It is realized herein that in deploying different NFs, there can be many situations where an NF may need to interact with an entity external to the SBA-based 5GC network (e.g., including the corresponding PEMN(s), e.g., HPEMN and VPEMN). Thus, the term “internal” as used herein illustratively refers to operations and / or communications within the SBA-based 5GC network (e.g., SBA-based interfaces) and the term “external” illustratively refers to operations and / or communications outside the SBA-based 5GC network (non-SBA interfaces).

[0055] 5GC networks can also be configured with network data analytics capabilities via one or more NWDAFs. In some cases, such network data analytics capabilities can be utilized to train machine learning (ME) models and / or other models (e.g., artificial intelligence (Al) models) in accordance with a federated learning (FL) mechanism. As outlined in the abovereferenced TS 23.288, federated learning (FL) among multiple NWDAFs is a machine learning technique in a 5GC network that trains an ML model across multiple decentralized entities holding local data set, without exchanging / sharing local data set. The FL mechanism stands in contrast to centralized machine learning techniques where all the local datasets are uploaded to one server, thus allowing to address critical issues such as data privacy, data security, and data access rights.

[0056] By way of example only, for FL supported by multiple NWDAFs each containing a Model Training Logical Function (MTLF), assume there is one NWDAF containing an MTLF acting as an FL server and one NWDAF containing an MTLF acting as an FL client. Main functionalities of the FL server include: discovering and selecting one or more FL clients to participate in the FL mechanism; requesting FL clients to do local model training and to report local model information; generating a global ML model by aggregating local model information from the one or more FL clients; and sending the global ML model back to the one or more FL clients and repeating the training iteration if needed. Main functionalities of the FL client include: locally training the ML model that is tasked by the FL server with available local data set (which includes the data that is not allowed to be shared with others due to, e.g., data privacy, data security, and data access rights); reporting the trained local ML model information to the FL server; receiving the global ML model feedback from the FL server and repeating the training iteration if needed. The FL server and the one or more FL clients register their respective FL capabilities with an NRF.

[0057] Assume further, by way of example only, that the NWDAF containing the MTLF determines to train an ML model either based on local configuration or when it receives a request from an NWDAF containing an Analytics Logical Function (AnLF). The NWDAF containing the MTLF further determines whether the ML model should be trained via the FL mechanism based on, e.g., an analytic ID, a service area / data network access identifier (DNAI) or when data cannot be obtained directly from a data producer NF (e.g., due to data privacy, data security, etc.). The NWDAF containing the AnLF is not aware whether the ML model is trained based on the FL mechanism or not.

[0058] Given the above general description of some features of a 5GC network and the FL mechanism, problems with existing authorization approaches in a communication network environment, and solutions proposed in accordance with illustrative embodiments, will now be described herein below.

[0059] An FL authorization schema defined in the above -referenced TS 33.501 Annex X addresses the authorization issue when there is a single FL server (e.g., NWDAF MTLF) requesting for the FL process directly to the FL clients. However, it is realized that there is a need to authorize an MTLF to request ML models on behalf of an AnLF to another MTLF (e.g., FL server). In other words, the current authorization mechanism does not take into account whether the request comes originally from another ANLF to the MTLF, and then that MTLF further requests an NWDAF MTLF acting as an FL server to request an FL process from an FL client. More particularly, the FL server in this scenario will not know the vendor information of the ANLF, and further the FL client does not know which final consumers have requested the FL process. Therefore, an FL client can accept the FL process even if the ANLF or the MTLF originator of the request are not authorized for the same.

[0060] The problem scenario can be generalized to any exchange / sharing model authorization procedure and also to the context of analytics exchange in roaming environments. Further, the problem statement can be generalized to the authorization of analytics and / or ML model consumers when they use an intermediary(-ies) MTLF(s) to make the request(s) to the producer (s).

[0061] Illustrative embodiments overcome the above and other technical problems by providing authorization techniques for federated learning-based network analytics processes in communication network environments. By way of example only, one or more illustrative embodiments provide a mechanism for the authorization server (e.g. NRF) and the NFp to know and verify the information (e.g., NF instance, type, slice, vendor ID, PLMN, etc.) of all the consumers which can directly or indirectly request for a service (especially, but not limited to, the case where there are more than two consumers for a single resource request). For example, an access token request and the access token generated by the authorization server is enhanced to ensure a successful authorization of all the consumers. Further, illustrative embodiments provide solutions for both non-roaming and roaming scenarios.

[0062] FIG. 3 illustrates an authorization procedure 300 for federated learning-based network analytics in a non-roaming communication network environment according to an illustrative embodiment. As shown, authorization procedure 300 involves a first NF consumer (NFc-1) 302 (e.g., AnLF), a second NF consumer (NFc-2) 304 (e.g., MTLF), a third NF consumer (NFc- 3) 306 (e.g., MTLF / FL server), an authorization server (e.g., NRF) 308, and an NF producer (NFp) 310. Note that, in illustrative embodiments, NFc-1, NFc-2, NFc-3, and NFp are each NWDAFs. Further, it is assumed that NFc-1, NFc-2, NFc-3, NRF, and NFp operate in accordance with the same PLMN.

[0063] Step 0. NFc-1 (e.g., NWDAF AnLF) requests analytics from NFc-2 (e.g., NWDAF MTLF), and NFc-2 (e.g., NWDAF MTLF) requests NFc-3( e.g., NWDAF MTLF acting as FL server) to initiate the FL process. More particularly, NFc-1 and NFc-2 send their client credential assertions (CCAs) to NFc-3 which contain their respective vendor identifiers (IDs). The service request sent by NFc-2 to NFc-3 may also include the notification end point where the ML model after the FL process is finalized will be sent.

[0064] Step 1. NFc-3 sends an enhanced access token request to NRF (i.e., authorization server 308). The enhanced access token request includes a set of details of the NF consumers which have requested the services for the NFp. Thus, as shown, the request is specified as:

[0065] Nnrf_AccessToken_Get Request

[0066] (Consumer NF= NFc-3, Consumer details: Slice, Vendor

[0067] AdditionalConsumersDetails ( NFcInstanceld: NFc-1 { NFcSlice:Slicel, NFcVendor=Vendorl, Interoperability Indicator of NFc-1, NFc-lTAI = TAI1, CCAc-l(Vendor-a)}

[0068] NFcInstanceld: NFc-2 {NFcSlice:Slicel, NFcVendor=Vendor2, Interoperability Indicator of NFc-2, NFc-2TAI = TAI2, CCAc-2(Vendor-2)}

[0069] Target =NFp (NFp FL client)

[0070] Note that, by way of example, TAI refers to a Tracking Area Identity (TAI) which is used by the 5GC network to identify tracking areas and is composed of a Tracking Area Code (TAC), along with the above-mentioned MNC and MCC.

[0071] Further, note that, by way of example, an Interoperability Indicator (or ML model interoperability indicator) may comprise a list of NWD AF providers (vendors) that are allowed to retrieve ML models from a given NWDAF containing MTLF. An interoperability indicator may also indicate that the NWDAF containing MTLF supports the interoperable ML models requested by the NWDAFs from the vendors in the list.

[0072] Step 2. NRF authenticates NFc-1, NFc-2, and NFc-3 using the respective CCAs provided, and verifies whether or not NFp has, in its profile maintained by NRF, allowed NFc- 1, NFc-2, and NFc-3 to access NFp’s services, i.e., allowed Slice ID, allowed Instance ID, allowed PLMN, allowed Vendor ID (or interoperable indicator), etc. In this case, NRF verifies whether the interoperability indicator of NFp (i.e. NWDAF MTLF acting as FL client) has the vendor ID of NFc-1, NFc-2, and NFc-3 listed or not. In other words, the NRF provides the authorization access token knowing who is the originator of the request. In case of successful verification, NRF generates the enhanced access token with additional claims. For example, if any of the consumers (NFc-1, NFc-2, and NFc-3) are not authorized to access the NFp service, the NRF shall reject the access token request, or does not include that consumer in the claim, or includes that consumer with access token grant with an indication that it is not authorized.

[0073] Step 3. NRF sends the enhanced access token with additional claims to NFc-3. Thus, as shown, the response is specified as:

[0074] Nnrf_AccessToken_Get Response

[0075] AT(Consumer= NFc-3, Producer= NFp

[0076] AdditionalConsumer=NFc-l {NFcSlice:Slicel, NFc Vendor= Vendor 1, Interoperability Indictor of NFc-1, NFc-lTAI = TAI1 }

[0077] AdditionalConsumer=NFc-2 {NFcSlice:Slicel, NfcVendor=Vendor2, Interoperability

[0078] Indicator of NFc-2, NFc-2TAI = TAI2} Step 4. NFc-3 sends the service request to NFp (NWDAF MTLF acting as FL client), with the enhanced access token received from NRF along with the CCAs received from NFc- 1 and NFc-2.

[0079] Step 5. NFp: (i) verifies the access token received with enhanced access token claims and may also additionally verify directly if the interoperability indicator of all the NFc(s) present in the access token claims matches the vendor IDs present in its own interoperability indicator; (ii) verifies the TAIs of all the NFc(s) are amongst the TAIs wherein the data or model or model parameters can be shared; (iii) authenticates and authorizes each consumer, i.e., NFc-1, NFc-2 and NFc-3 based on their CCAs received; and (iv) in case of successful verification, initiates the FL process.

[0080] If the access token does not contain any of the NFc details which are including the service request (e.g., NFc-2) or the access token contains NFc-2 details marked as not granted, the NFp rejects the request.

[0081] FIG. 4 illustrates an authorization procedure 400 for federated learning-based network analytics in a roaming communication network environment according to an illustrative embodiment. As shown, authorization procedure 400 involves a first NF consumer (NFc-1) 402 (e.g., AnLF), a second NF consumer (NFc-2) 404 (e.g., MTLF), a third NF consumer (NFc- 3) 406 (e.g., MTLF / FL server), a first NRF (e.g., NRF1) 408, a first SEPP (SEPPI) 410, a second SEPP (SEPP2) 412, an authorization server (e.g., NRF2) 414, and an NF producer (NFp) 416. Note that, in illustrative embodiments, NFc-1, NFc-2, NFc-3, and NFp are each NWDAFs. Further, it is assumed that NFc-1, NFc-2, NFc-3, NRF1, and SEPP 1 operate in accordance with PLMN1 (e.g., VPLMN), while SEPP2, NRF2 and NFp operate in accordance with PLMN2 (e.g., HPLMN).

[0082] Step 0. NFc-1 (e.g., NWDAF AnLF) requests analytics from NFc-2 (e.g., NWDAF MTLF), and NFc-2 (e.g., NWDAF MTLF) requests NFc-3( e.g., NWDAF MTLF acting as FL server) to initiate the FL process. More particularly, NFc-1 and NFc-2 send their client credential assertions (CCAs) to NFc-3 which contain their respective vendor identifiers (IDs). The service request sent by NFc-2 to NFc-3 may also include the notification end point where the ML model after the FL process is finalized will be sent.

[0083] Step 1. NFc-3 in PLMN1 sends an access token request to NRF1 in PLMN1. NRF1 in PLMN1 forwards the request to SEPPI in PLMN1 after verification. SEPP2 in PLMN2 then forwards this request to NRF2 (Authorization Server) of PLMN2. The enhanced access token requests is as follows:

[0084] Nnrf_AccessToken_Get Request

[0085] (Consumer NF= NFc-3, Consumer details: Slice, Vendor

[0086] AdditionalConsumersDetails (

[0087] NFcInstanceld: NFc-1 {NFcSlice:Slicel, NFcVendor=Vendorl, Interoperability Indicator of NFc-1, NFc-lTAI = TAI1, CCAc-l(Vendor-a)}

[0088] NFcInstanceld: NFc-2 {NFcSlice:Slicel, NFcVendor=Vendor2, Interoperability Indicator of NFc-2, NFc-2TAI = TAI2, CCAc-2(Vendor-2)}

[0089] Target =NFp (NFpclient)

[0090] TargetPLMN=PLMN2

[0091] Step 2. NRF2 verifies the details of NFc-1, NFc-2, and NFc-3 via the information provided by SEPP2 in PLMN2. In the case of successful verification, NRF2 generates an enhanced access token with additional claims.

[0092] Step 3. NRF2 then sends this access token with additional claims in a response to SEPP2 in PLMN2 to forward the response to NFc-3 via SEPPI in PLMN1. The enhanced access token response content is as follows:

[0093] Nnrf_AccessToken_Get Response

[0094] AT(Consumer= NFc-3, Producer= NFp

[0095] AddtionalConsumer=NFc-l {NFcSlice:Slicel, NFcVendor=Vendorl, Interoperability Indictor of NFc-1, NFc-1 TAI = TAI1 }

[0096] AddtionalConsumer=NFc-2 {NFcSlice:Slicel, NfcVendor=Vendor2, Interoperability

[0097] Indicator of NFc-2, NFc-2TAI = TAI2}

[0098] Step 4. NFc-3 then sends a service request to NFp (i.e., NWDAF MTLF acting as FL client) in PLMN2 via SEPP1 / SEPP 2 along with the enhanced access token received earlier. The service request send to NFp is enhanced as follows:

[0099] AT(Consumer= NFc3, Producer= NFp

[0100] AddtionalConsumer=NFc-l {NFcSlice:Slicel, NFcVendor=Vendorl, Interoperability Indictor of NFc-1, NFc-1 TAI = TAI1 }

[0101] AddtionalConsumer=NFc-2 {NFcSlice:Slicel, NFcVendor=Vendor2, Interoperability Indicator of NFc-2, NFcTAI = TAI2}, along with the other parameters for the request as shown. Step 5. NFp: (i) verifies the access token received with the service request; (ii) verifies the information regarding additional consumers received via SEPP2; and (iii) in case of successful verification, initiates the FL process.

[0102] Similar to authorization procedure 300 of FIG. 3, if the access token does not contain any of the NFc details which are including the service request (e.g., NFc-2) or the access token contains NFc-2 details marked as not granted, the NFp rejects the request.

[0103] Advantageously, as described herein, illustrative embodiments provide techniques for authorization in a federated learning-based network analytics process in a communication network environment.

[0104] By way of example only, from a consumer network entity perspective, a method comprises sending to an authorization entity (e.g., hNRF or authorization server), from the consumer network entity (e.g., NFc-3 functioning as an FL server) of a set of consumer network entities (e.g., NFc-1, NFc-2, and NFc-3), an authorization request in response to a service request from another one of the set of consumer network entities (e.g., NFc-1 or NFc-2), for permission to request that a producer network entity (e.g., NFp functioning as an FL client) participate in a federated learning process for training a model. The method further comprises receiving, at the consumer network entity of the set of consumer network entities, an authorization response from the authorization entity, wherein the authorization response comprises data (e.g., access or authorization token) indicative of whether the set of consumer network entities are authorized.

[0105] In some examples, data in the authorization token may comprise information indicating the consumer network entity (e.g., NFc-3) is a server of the federated learning process, and information associated with the other consumer network entities (e.g., NFc-1 and NFc-2) comprising, for each of the other consumer network entities, one or more of: a model interoperability indicator, a vendor identifier (e.g., vendor ID), a credential assertion (e.g., CCA), and a logical network partition identifier (e.g., slice ID).

[0106] By way of another example, from an authorization entity perspective, a method comprises receiving, at the authorization entity, an authorization request from a consumer network entity of a set of consumer network entities, based on a service request initiated from one of the other consumer network entities, for permission to request that a producer network entity participate in a federated learning process for training a model. The method further comprises sending, from the authorization entity, an authorization response to the consumer network entity of the set of consumer network entities, wherein the authorization response comprises data indicative of whether the set of consumer network entities are authorized.

[0107] By way of yet another example, from a producer network entity perspective, a method comprises receiving, at the producer network entity, a service request with authorization data, generated by an authentication entity, from a consumer network entity of a set of consumer network entities based on a request initiated from one of the other consumer network entities, wherein the service request is a request that the producer network entity participate in a federated learning process for training a model. The method further comprises performing, at the producer network entity, an authentication of the set of consumer network entities based on the authorization data. The method further comprises responding, by the producer network entity, to the service request based on results of the authentication.

[0108] It is to be appreciated that the particular processing operations and other system functionality described in conjunction with the diagrams described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations and messaging protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another.

[0109] It should again be emphasized that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments can utilize different communication system configurations, user equipment configurations, base station configurations, authorization processes, messaging protocols and message formats than those described above in the context of the illustrative embodiments. These and numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

Claims:

1. An apparatus comprising:At least one processor; andAt least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:Send an authorization request to an authorization entity, in response to a service request from a consumer network entity of a set of consumer network entities including the apparatus, for permission to request that a producer network entity participate in a process; andReceive an authorization response from the authorization entity, wherein the authorization response comprises data indicative of whether the set of consumer network entities are authorized.

2. The apparatus of claim 1, wherein the process comprises at least one of: (i) a process for training a model; (ii) a process for sharing a model; (iii) a process for sharing an output of a model; and (iv) a process for sharing analytics data.

3. The apparatus of claim 1, wherein the authorization request comprises information indicating the producer network entity is a target client of a federated learning process for training the model and the apparatus is a server of the federated learning process.

4. The apparatus of claim 1 , wherein the authorization request comprises information associated with at least a subset of the consumer network entities comprising, for each of the subset of the consumer network entities, one or more of: a model interoperability indicator, a vendor identifier, a tracking area identifier, a credential assertion, and a logical network partition identifier.

5. The apparatus of claim 1, wherein one of the set of consumer network entities is configured with an analytics function and others of the set of consumer network entities are each configured with a model training function.

6. The apparatus of claim 1, wherein the data indicative of whether the set of consumer network entities are authorized comprises an authorization token, and wherein the apparatus is further caused to send the authorization token to the producer network entity.

7. The apparatus of claim 6, wherein the authorization token comprises information associated with the set of consumer network entities comprising:For the apparatus, information indicating the apparatus is a server of a federated learning process for training the model; andFor each of the other authorized consumer network entities, information indicating one or more of: a vendor identifier, a tracking area identifier, a credential assertion, and a logical network partition identifier.

8. The apparatus of claim 1, wherein the set of consumer network entities, the authorization entity, and the producer network entity operate in the same communication network.

9. The apparatus of claim 1, wherein the set of consumer network entities operate in a first communication network and the authorization entity and the producer network entity operate in a second communication network.

10. The apparatus of claim 9, wherein communications between the first communication network and the second communication network are protected by a set of security network entities.

11. A method comprising:Sending to an authorization entity, from a consumer network entity of a set of consumer network entities, an authorization request in response to a service request from another one of the set of consumer network entities, for permission to request that a producer network entity participate in a process; andReceiving, at the consumer network entity of the set of consumer network entities, an authorization response from the authorization entity, wherein the authorization response comprises data indicative of whether the set of consumer network entities are authorized.

12. An apparatus comprising:At least one processor; andAt least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:Receive an authorization request from a consumer network entity of a set of consumer network entities, based on a service request initiated from one of the other consumer network entities, for permission to request that a producer network entity participate in a process; andSend to an authorization response the consumer network entity of the set of consumer network entities, wherein the authorization response comprises data indicative of whether the set of consumer network entities are authorized.

13. The apparatus of claim 12, wherein the process comprises at least one of: (i) a process for training a model; (ii) a process for sharing a model; (iii) a process for sharing an output of a model; and (iv) a process for sharing analytics data.

14. The apparatus of claim 12, wherein the authorization request comprises information indicating the producer network entity is a target client of a federated learning process for training the model and the consumer network entity that sent the authorization request is a server of the federated learning process.

15. The apparatus of claim 12, wherein the authorization request comprises information associated with the other consumer network entities comprising, for each of the other consumer network entities, one or more of: a model interoperability indicator, a vendor identifier, a tracking area identifier, a credential assertion, and a logical network partition identifier.

16. The apparatus of claim 12, wherein one of the set of consumer network entities is configured with an analytics function and others of the set of consumer network entities are each configured with a model training function.

17. The apparatus of claim 12, wherein the apparatus is further caused to perform an authentication of the set of consumer network entities, and wherein the apparatus is further caused to generate an authorization token based on results of the authentication.

18. The apparatus of claim 17, wherein the apparatus is further caused to send the authorization token to the consumer network entity that sent the authorization request.

19. The apparatus of claim 12, wherein the set of consumer network entities, the authorization entity, and the producer network entity operate in the same communication network.

20. The apparatus of claim 12, wherein the set of consumer network entities operate in a first communication network and the authorization entity and the producer network entity operate in a second communication network.

21. The apparatus of claim 20, wherein communications between the first communication network and the second communication network are protected by a set of security network entities.

22. A method comprising:Receiving, at an authorization entity, an authorization request from a consumer network entity of a set of consumer network entities, based on a service request initiated from one of the other consumer network entities, for permission to request that a producer network entity participate in a process; andSending, from the authorization entity, an authorization response to the consumer network entity of the set of consumer network entities, wherein the authorization response comprises data indicative of whether the set of consumer network entities are authorized.

23. An apparatus comprising:At least one processor; andAt least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:Receive a service request with authorization data generated by an authorization entity, from a consumer network entity of a set of consumer network entities, based on a request initiated from one of the other consumer network entities, wherein the service request is a request that the apparatus participate in a process;Perform an authorization of the set of consumer network entities based on the authorization data; andRespond to the service request based on results of the authorization.

24. The apparatus of claim 23, wherein the process comprises at least one of: (i) a process for training a model; (ii) a process for sharing a model; (iii) a process for sharing an output of a model; and (iv) a process for sharing analytics data.

25. The apparatus of claim 23, wherein the authorization data comprises information indicating the consumer network entity is a server of a federated learning process for training the model, and information associated with the other consumer network entities comprising, for each of the other consumer network entities, one or more of: a model interoperability indicator, a vendor identifier, a tracking area identifier, a credential assertion, and a logical network partition identifier.

26. The apparatus of claim 23, wherein the set of consumer network entities, the authorization entity, and the apparatus operate in the same communication network.

27. The apparatus of claim 23, wherein the set of consumer network entities operate in a first communication network and the authorization entity and the apparatus operate in a second communication network.

28. The apparatus of claim 26, wherein communications between the first communication network and the second communication network are protected by a set of security network entities.

29. A method comprising:Receiving, at a producer network entity, a service request with authorization data, generated by an authorization entity, from a consumer network entity of a set of consumer network entities based on a request initiated from one of the other consumer network entities, wherein the service request is a request that the producer network entity participate in a process;Performing, at the producer network entity, an authorization of the set of consumer network entities based on the authorization data; andResponding, by the producer network entity, to the service request based on results of the authorization.

Images