WO2025079043A1

WO2025079043A1 - Cross-domain authorization of services in a communication network environment

Info

Publication number: WO2025079043A1
Application number: PCT/IB2024/060002
Authority: WO
Inventors: Saurabh Khare; Chaitanya Aggarwal
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2023-10-13
Filing date: 2024-10-11
Publication date: 2025-04-17
Anticipated expiration: 2026-04-13

Abstract

Techniques for cross-domain authorization of services in a communication network environment are disclosed. For example, a method comprises requesting data or a service, associated with a communication network, via one of a radio access network entity and a core network entity, and performing a cross-domain authorization process between the radio access network entity and the core network entity for the data or the service.

Description

CROSS-DOMAIN AUTHORIZATION OF SERVICES IN A COMMUNICATION NETWORK ENVIRONMENT

Field

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

Background

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.

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.

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.

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.

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).

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).

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.

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, securely implementing authorizations in the communication network environment is a technical challenge.

Summary

Illustrative embodiments provide techniques for cross-domain authorization of services in a communication network environment. While not limited thereto, illustrative embodiments are particularly well suited for use with analytics services such as training and/or utilizing of artificial intelligence/machine learning (AI/ME) models, neural network models, and the like.

In one illustrative embodiment, a method comprises participating in a cross-domain authorization process, via a radio access network entity configured to at least one of provide and facilitate one or more services, with at least one core network entity.

In another illustrative embodiment, a method comprises participating in a cross-domain authorization process, between at least one radio access network entity and at least one core network entity, via an access and mobility management entity associated with a core network, for one or more services.

In yet another illustrative embodiment, a method comprises participating in a crossdomain authorization process, via a core network entity configured to at least one of provide and facilitate one or more services, with one or more radio access network entities. In a further illustrative embodiment, a method comprises participating in a crossdomain authorization process, between at least one radio access network entity and at least one core network entity, via a registration entity associated with a core network, for one or more services.

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.

Advantageously, illustrative embodiments provide authorization techniques for use across a radio access network domain and a core network domain in a communication network environment with respect to services such as analytics services.

These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

Brief Description of the Drawings

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

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

FIG. 3 illustrates a procedure for cross-domain authorization of services in a communication network environment according to an illustrative embodiment.

FIG. 4 illustrates a procedure for cross-domain authorization of services in a communication network environment according to another illustrative embodiment.

Detailed Description

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.

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.

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.

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.

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).

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 (WEAN) access point as will be further explained in illustrative embodiments described herein.

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.

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).

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.

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.”

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.

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, an Authentication Server Function (AUSF), a Unified Data Management (UDM) function, an Application Function (AF), a Network Data Analytics Function (NWDAF), and a Network Repository Function (NRF). These listed network function examples are typically implemented in the home network of the UE subscriber, further explained below. Note that, in a 5GC network, the 4G function of the HSS (home subscriber server) is split into the AUSF, UDM, and a Unified Data Repository (UDR, not expressly shown) functions. Typically, AUSF authenticates UEs and provides any needed cryptographic keys, while UDR stores the user data and UDM manages the user data. The AF exposes the application layer for interaction with 5G NFs and network resources. 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 NRF is a centralized repository that enables other 5G NFs to register and discover each other via a standardized application programming interface. Other network functions 108 may include network functions that can act as service producers (NFp) and/or service consumers (NFc). 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.”

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. 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).

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). 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.

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.

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.

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, AMF, NWDAF, UDM), 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.

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.

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.

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.

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.

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. 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.

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.

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, authentication request/response messages and data, metadata, control data, audio, video, multimedia, consent data, other messages, etc.

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.

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.

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).

Given the above general description of some features of a 5GC network, problems with existing security approaches in authorizing services in a communication network environment, and solutions proposed in accordance with illustrative embodiments, will now be described herein below.

It is to be appreciated that UEs can be configured to participate with a NWDAF and/or a third-party artificial intelligence/machine learning (AI/ML) engine or neural network model trainer. More particularly, model training (i.e., part of analytics services) via an NWDAF model training logical function (MTEF) has been described in the above-referenced TS 23.288. Furthermore, there have been proposals for cross-domain machine learning, wherein the UE and RAN and/or the UE and 5GC collaboratively train an ME model, wherein the domains in this example comprise the RAN domain (more generally, a radio access network domain) and the 5GC domain (more generally, a core network domain). It is realized that cross-domain ML techniques can have a direct impact on security with respect to training data sharing and model training. Still further, it is realized that existing authorization mechanisms only enable NFs within the core network domain to request services from each other. As such, no existing authorization mechanisms enable the radio access network and core network domains to securely interact with each other while requesting and delivering services including, but not limited to, analytics services. More particularly, for example, there exists no cross-domain service authorization mechanism in the case where the RAN makes a service -related request to the 5GC domain. For instance, in existing communication network environments, the RAN can request any type of training data, or trained ML model or analytics, and the 5GC can directly provide it without verifying if the particular RAN node is even authorized to receive the same. Furthermore, in the same way, there is no existing authorization mechanism defined for enabling the RAN accessing services from the 5GC. Additionally, it is realized that in the situation where the 5GC needs to retrieve model/analytics identifiers or other service-related data from the RAN, there is no existing cross-domain authorization mechanism defined.

Illustrative embodiments address the above and other technical challenges and/or technical deficiencies in existing authorization approaches in a communication network environment by providing cross-domain authorization of services in a communication network environment. While not limited thereto, examples of services with which illustrative embodiments will be described include analytics services such as training and/or utilizing of artificial intelligence/machine learning (AI/ML) models, neural network models, and the like.

More particularly, illustrative embodiments address the above-described and other technical challenges with analytics service authorization solutions comprising: (i) a procedure for radio access network node authorization at a core network function (FIG. 3); and (ii) a procedure for core network function authorization at a radio access network node (FIG. 4).

As will be explained in further detail in the context of FIGS. 3 and 4, illustrative embodiments provide a mechanism to enable cross authorization between a core network domain and a radio access network domain via an AMF over the N2 interface. The illustrative use case described herein is for ML model analytics, but it can be expanded to any other service as well.

For example, as will be further illustrated below in the context of a procedure 300 in FIG. 3, a 5GC NF (e.g., NWDAF) provides an NRF with information, during NF registration, for RAN nodes that can consume its resources during NF registration. The RAN node information may include the RAN node’s gNB identifier (ID), Cell ID, Vendor ID, Region ID, PLMN ID, etc.

The RAN node then sends the request to the 5GC via the AMF over the N2 interface, and the AMF performs the discovery of the target NF which can serve the request and sends an access token request to the NRF (on behalf of the RAN node). In the access token request, the AMF addresses the RAN node details. The NRF, after verifying, provides an access token with claims that also include the RAN node information. The AMF then sends the service request to the respective NF (e.g., NWDAF) and after getting the response, provides the response back to the RAN node.

More particularly, as shown in FIG. 3, procedure 300 illustrates cross-domain authorization of services (in this example, analytics services) in a communication network environment according to an illustrative embodiment. As shown, procedure 300 involves a RAN node (e.g., a model training management function) 302, an AMF 304, an NWDAF (e.g., a 5G Core model training management function) 306, and an NRF (e.g., a 5G Core authorization and registration NF) 308.

In step 1, NWDAF 306 (i.e., a 5GC model training NF such as the NWDAF MTLF) when doing its profile registration at the registration server (e.g., NRF 308) updates the information with respect to RAN nodes, including RAN node 302, and what ML services can be consumed by the respective RAN nodes. For instance, the profile information may include: ML model ID/ Analytics ID or Service/Training Data ID for data that can be consumed by a RAN node with attributes including, but not limited to, gNB ID, Cell ID, Vendor ID, Region ID, PLMN ID, and/or the like.

As mentioned, it is to be understood that NWDAF 306 is only one example of a core network function that can be configured, according to illustrative embodiments, to enable authorization of one or more radio access network nodes (e.g., RAN node 302) for one or more services.

In step 2, RAN node 302 sends a service request to AMF 304 to consume analytics services. As mentioned, the service may be a request for a trained ML model, analytics, and/or training data. The request is sent over the N2 interface. This request includes a model ID, analytics ID, and/or a datatype or data ID. If the target NF is known to the RAN node 302, RAN node 302 also provides the same. Further, if RAN node 302 has any previously stored access token, RAN node 302 also provides the same.

In some illustrative embodiments, the message in step 2 can be sent via the NG Application Protocol (NGAP) which provides control plane signaling between an NG-RAN node and an AMF.

In steps 3 and 4, AMF 304 analyzes the request and sends a discovery request to NRF 308. NRF 308 provides the discovery response back based on the Analytics ID, Model ID, or the Target NF details available in the discovery request. In step 5, if an access token is not available, AMF 304 sends an access token request on behalf of RAN node 302 to NRF 308. As shown, the access token request may include: RAN node information (i.e., gNB ID, Cell ID, Vendor ID, Region ID, PLMN ID), Source NF = AMF, Target = NWDAF, Resource Type = ML Model ID/ Analytics ID/Data ID.

In step 6, NRF 308, after successful verification of the request (also using the information updated in step 1), sends the access token to AMF 304 wherein access token claims are added including: Source NF = AMF, Target = NWDAF, Resource Type = ML Model ID/ Analytics ID/Data ID, RAN node Info = gNB ID, Cell ID, Vendor ID, Region ID, PLMN ID.

In steps 7 and 8, AMF 304 sends the service request with the access token received to NWDAF 306, and NWDAF 306, after access token verification including the above added claims, provides the response back to AMF 304.

In step 9, AMF 304 provides the requested ML model (or the uniform resource indicator (URI) of the ML model)/requested analytics or training data, along with the access token provided by NRF 308, to RAN node 302.

In step 10, RAN node 310 processes the response and can cache the access token received in case the same service is required again in future.

Similarly, as will be further illustrated below in the context of a procedure 400 in FIG. 4, a mechanism is defined to enable authorization in the case where a 5GC NF wishes to request any service from a RAN node.

In this case, the AMF registers in the NRF with the information of the connected RAN node, the supported model at the RAN node, and analytics supported at the RAN node. The core network function (e.g., NWDAF) can discover the RAN node information via the AMF NF profile and get the access token to access the RAN node. Each RAN node is configured with an NRF public key and NRF ID to validate the access token. The core NF sends a service request to the AMF along with the access token. The AMF validates the access token (since AMF ID is in the access token), and then forwards the request to the RAN node. The RAN node validates the access token and then provides the service.

More particularly, as shown in FIG. 4, procedure 400 illustrates cross-domain authorization of services (in this example, analytics services) in a communication network environment according to an illustrative embodiment. As shown, procedure 400 involves a RAN node (e.g., a model training management function) 402, an AMF 404, an NWDAF (e.g., a 5G Core model training management function) 406, and an NRF (e.g., a 5G Core authorization and registration NF) 408.

In step 1, RAN node 402 updates AMF 404 over NGAP (as mentioned above) with the following information: ML model ID/ Analytics ID or Service/Training Data ID that can be consumed by the NWDAF 406 with attributes including, but not limited to, gNB ID, Cell ID, Vendor ID, Region ID, PLMN ID.

As mentioned, it is to be understood that NWDAF 406 is only one example of a core network function that, according to illustrative embodiments, can be authorized by a radio access network node (e.g., RAN node 402) for one or more services.

In step 2, AMF 404 updates the information received in step 1 to NRF 408 in its NF profile registration message, i.e., the AMF NF profile contain the supported RAN node and related model details and can also contain the allowed NF ID (if known), the allowed vendor list, and the allowed PLMN details.

In steps 3 and 4, if NWDAF 406 or any core NF wants to retrieve the model from a RAN node, then it sends a discovery request to NRF 408 to discover the AMF supporting the RAN node. NRF 408 provides the discovery response back with AMF profiles based on the Analytics ID, Model ID, or the target RAN node (e.g., RAN node 402) details available in the discovery request.

In step 5, NWDAF 406 sends an access token request to NRF 408. The access token request includes: target RAN node information (i.e., gNB ID, Cell ID, Vendor ID, Region ID, PLMN ID), Source NF = NWDAF, Target = AMF, Resource Type = ML Model ID/Analytics ID/Data ID.

In step 6, NRF 408, after successful verification of the request (also using the information updated in step 1), sends the access token wherein the access token claims include: Source NF = NWDAF, Target = AMF, Resource Type = ML Model ID/Analytics ID/Data ID, RAN Node Info = gNB ID, Cell ID, vendor ID, Region ID, PLMN ID.

In steps 7, 8 and 9, NWDAF 406 sends the service request with the access token received to AMF 404 and AMF 404 validates the same. After that, AMF 404 forwards the request to RAN node 402 over NGAP.

In steps 10, 11 and 12, RAN node 402 validates the access token based on the configured NRF public key and, if validated, provides the response with data to AMF404 which forwards same to NWDAF 406. As used herein, it is to be understood that the term “communication network” in some embodiments can comprise two or more separate communication networks. Further, 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.

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, provisioning and usage 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; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: operate in a core network as an entity configured to at least one of provide and facilitate one or more services; and participate in a cross-domain authorization process for the one or more services with one or more radio access network entities.

2. The apparatus of claim 1, wherein participating in the cross-domain authorization process for the one or more services with the one or more radio access network entities further comprises sending, to a registration entity in the core network, information identifying the one or more radio access network entities and which of the one or more services that the one or more radio access network entities can consume.

3. The apparatus of claims 1 or 2, wherein participating in the cross-domain authorization process for the one or more services with the one or more radio access network entities further comprises receiving a service request for one of the one or more services from one of the one or more radio access network entities, wherein the service request comprises an access token.

4. The apparatus of any one of claims 1-3, wherein participating in the cross-domain authorization process for the one or more services with the one or more radio access network entities further comprises sending a response to the service request in response to verification of the access token.

5. The apparatus of claims 3 or 4, wherein the service request is received from, and the response sent to, an access and mobility management entity associated with the core network.

6. The apparatus of any of claims 1-5, wherein at least one of the one or more services comprises an analytics service.

7. The apparatus of any one of claims 1-5, wherein at least one of the one or more services comprises a collaborative model training service.

8. The apparatus of claim 1, wherein participating in the cross-domain authorization process for the one or more services with the one or more radio access network entities further comprises sending, to a registration entity in the core network, a request to discover an access and mobility management entity associated with one of the one or more radio access network entities that supports data that the core network entity seeks for one of the one or more services.

9. The apparatus of claims 1 or 8, wherein participating in the cross-domain authorization process for the one or more services with the one or more radio access network entities further comprises sending a request for an access token to the registration entity, wherein the request for the access token comprises information specifying the supporting one of the one or more radio access network entities, the data sought, and the access and mobility management entity.

10. The apparatus of any of claims 1, 8 and 9, wherein participating in the cross-domain authorization process for the one or more services with the one or more radio access network entities further comprises receiving an access token from the registration entity, wherein the access token comprises claims specifying the supporting one of the one or more radio access network entities, the data sought, the access and mobility management entity, and the core network entity.

11. The apparatus of any of claims 1 and 8-10, wherein participating in the crossdomain authorization process for the one or more services with the one or more radio access network entities further comprises sending a service request with the access token to the supporting one of the one or more radio access network entities via the access and mobility management entity.

12. The apparatus of any of claims 1 and 8-11, wherein participating in the crossdomain authorization process for the one or more services with the one or more radio access network entities further comprises receiving a response to the service request with the data sought from the supporting one of the one or more radio access network entities via the access and mobility management entity.

13. The apparatus of any of claims 1 and 8-12, wherein at least one of the one or more services comprises an analytics service.

14. The apparatus of any one of claims 1 and 8-12, wherein at least one of the one or more services comprises a collaborative model training service.

15. A method comprising: participating in a cross-domain authorization process, via a core network entity configured to at least one of provide and facilitate one or more services, with one or more radio access network entities.

16. A computer readable non-transitory medium comprising program instructions stored thereon for performing at least the method of claim 15.

17. An apparatus comprising: means for operating in a core network as an entity configured to at least one of provide and facilitate one or more services; and means for participating in a cross-domain authorization process for the one or more services with one or more radio access network entities.

18. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: operate in a radio access network as an entity configured to at least one of provide and facilitate one or more services; and participate in a cross-domain authorization process for the one or more services with at least one core network entity.

19. The apparatus of claim 18, wherein participating in the cross-domain authorization process for the one or more services with the core network entity further comprises sending, to an access and mobility management entity, a request associated with one of the one or more services, wherein the request comprises an indication of data that the radio access network entity seeks for the one of the one or more services.

20. The apparatus of claims 18 or 19, wherein participating in the cross-domain authorization process for the one or more services with the core network entity further comprises receiving, from the access and mobility management entity, a response to the request with the data sought or a link to the data sought, and an access token from the core network.

21. The apparatus of any of claims 18-20, wherein participating in the cross-domain authorization process for the one or more services with the core network entity further comprises processing the response and storing the access token for a subsequent request.

22. The apparatus of any of claims 18-21, wherein at least one of the one or more services comprises an analytics service.

23. The apparatus of any one of claims 18-21, wherein at least one of the one or more services comprises a collaborative model training service.

24. The apparatus of claim 18, wherein participating in the cross-domain authorization process for the one or more services with the core network entity further comprises sending, to an access and mobility management entity associated with the core network, a message indicating data the radio access network entity supports in accordance with the one or more services and entities that are permitted to consume the one or more services.

25. The apparatus of claims 18 or 24, wherein participating in the cross-domain authorization process for the one or more services with the core network entity further comprises receiving, from the access and mobility management entity, a request for supported data from the core network entity and an access token from the core network.

26. The apparatus of any of claims 18, 24 or 25, wherein participating in the crossdomain authorization process for the one or more services with the core network entity further comprises validating the access token with a public key of a registration entity that generated the access token on behalf of the core network entity and providing the supported data to the core network entity via the access and mobility management entity.

27. The apparatus of any of claims 18 and 24-26, wherein at least one of the one or more services comprises an analytics service.

28. The apparatus of any one of claims 18 and 24-26, wherein at least one of the one or more services comprises a collaborative model training service.

29. A method comprising: participating in a cross-domain authorization process, via a radio access network entity configured to at least one of provide and facilitate one or more services, with at least one core network entity.

30. A computer readable non-transitory medium comprising program instructions stored thereon for performing at least the method of claim 29.

31. An apparatus comprising: means for operating in a radio access network as an entity configured to at least one of provide and facilitate one or more services; and means for participating in a cross-domain authorization process for the one or more services with at least one core network entity.

32. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: operate in association with a core network as an access and mobility management entity; and participate in a cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services.

33. The apparatus of claim 32, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises receiving, from the radio access network entity, a request associated with one of the one or more services, wherein the request comprises an indication of data that the radio access network entity seeks for the one of the one or more services.

34. The apparatus of claims 32 or 33, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises analyzing the request and sending a discovery request to a registration entity associated with the core network to discover the core network entity.

35. The apparatus of any of claims 32-34, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises sending a request for an access token to the registration entity on behalf of the radio access network entity including information identifying the radio access network entity, the core network entity, and the data sought by the radio access network entity.

36. The apparatus of any of claims 32-35, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises receiving the access token from the registration entity, wherein the access token comprises claims including information identifying the radio access network entity, the core network entity, and the data sought by the radio access network entity.

37. The apparatus of any of claims 32-36, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises sending the access token to the core network entity.

38. The apparatus of any of claims 32-37, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises receiving the data sought by the radio access network entity in response to the access token being validated.

39. The apparatus of any of claims 32-38, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises sending the data sought and the access token to the radio access network entity.

40. The apparatus of any of claims 32-39, wherein at least one of the one or more services comprises an analytics service.

41. The apparatus of any one of claims 32-39, wherein at least one of the one or more services comprises a collaborative model training service.

42. The apparatus of any of claims 32-39, wherein the radio access network entity and the access and mobility management entity communicate over an N2 interface.

43. The apparatus of claim 32, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises receiving, from the radio access network entity, a message indicating data the radio access network entity supports in accordance with the one or more services and entities that are permitted to consume the one or more services.

44. The apparatus of claims 32 or 43, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises sending, to a registration entity associated with the core network, a message indicating the data the radio access network entity supports in accordance with the one or more services and the entities that are permitted to consume the one or more services.

45. The apparatus of any of claims 32, 43 or 44, wherein participating in the crossdomain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises receiving a service request for supported data from the core network entity with an access token.

46. The apparatus of any of claims 32 and 43-45, wherein participating in the crossdomain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises sending the service request for supported data and the access token to the radio access network entity in response to validating the access token.

47. The apparatus of any of claims 32 and 43-46, wherein participating in the crossdomain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises forwarding supported data received from the radio access network entity to the core network entity.

48. The apparatus of any of claims 32 and 43-47, wherein at least one of the one or more services comprises an analytics service.

49. The apparatus of any one of claims 32 and 43-47, wherein at least one of the one or more services comprises a collaborative model training service.

50. The apparatus of any of claims 32 and 43-47, wherein the radio access network entity and the access and mobility management entity communicate over an N2 interface.

51. A method comprising: participating in a cross-domain authorization process, between at least one radio access network entity and at least one core network entity, via an access and mobility management entity associated with a core network, for one or more services.

52. A computer readable non-transitory medium comprising program instructions stored thereon for performing at least the method of claim 51.

53. An apparatus comprising: means for operating in association with a core network as an access and mobility management entity; and means for participating in a cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services.

54. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: operate in association with a core network as a registration entity; and participate in a cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services.

55. The apparatus of claim 54, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises receiving registration information identifying one of the radio access network entity and the core network entity and data sought by the one of the radio access network entity and the core network entity.

56. The apparatus of claim 55, wherein participating in the cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services further comprises generating an access token in response to receiving a request from one of the core network entity and an access and mobility management entity associated with the radio access network entity, and sending the access token to the one of the core network entity and the access and mobility management entity associated with the radio access network entity.

57. A method comprising: participating in a cross-domain authorization process, between at least one radio access network entity and at least one core network entity, via a registration entity associated with a core network, for one or more services.

58. A computer readable non-transitory medium comprising program instructions stored thereon for performing at least the method of claim 57.

59. An apparatus comprising: means for operating in association with a core network as a registration entity; and means for participating in a cross-domain authorization process between at least one radio access network entity and at least one core network entity for one or more services.

60. A system comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the system at least to: requesting data or a service, associated with a communication network, via one of a radio access network entity and a core network entity; and performing a cross-domain authorization process between the radio access network entity and the core network entity for the data or the service.

61. A system comprising: means for requesting data or a service, associated with a communication network, via one of a radio access network entity and a core network entity; and means for performing a cross-domain authorization process between the radio access network entity and the core network entity for the data or the service.