WO2022018580A1

WO2022018580A1 - Service authorization in communication systems

Info

Publication number: WO2022018580A1
Application number: PCT/IB2021/056348
Authority: WO
Inventors: Saurabh Khare; Nagendra S Bykampadi; Anja Jerichow; Belling THOMAS; Bruno Landais
Original assignee: Nokia Technologies Oy
Priority date: 2020-07-22
Filing date: 2021-07-14
Publication date: 2022-01-27

Abstract

Techniques for service authorization in communication systems are provided. For example, a method comprises receiving, from a first network node at a second network node, a request for an access token for services to be provided by a third network node, the request for the access token comprising at least one target domain and target supported feature provided by the third network node. The method also comprises determining whether the first network node is permitted to utilize the at least one target domain and target supported feature, and providing from the first network node to the second network node the access token responsive to determining that the first network node is permitted to utilize the at least one target domain and target supported feature.

Description

SERVICE AUTHORIZATION IN COMMUNICATION SYSTEMS

Field

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

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 (IoT) networks.

While 5G networks are intended to enable massive IoT services (e.g., very large numbers of limited capacity devices) and mission-critical IoT 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, V16.2.0, entitled “Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety. 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, 5G Technical Specification (TS) 33.501, V16.0.0, 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 system. 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 can present a significant challenge.

Summary

Illustrative embodiments provide techniques for service authorization in communication systems.

For example, in one illustrative embodiment, a method comprises receiving, from a first network node in a communication system at a second network node in the communication system, a request for an access token for services to be provided by a third network node in the communication system, the request for the access token comprising at least one of one or more target domains of the third network node and one or more target supported features provided by the third network node. The method also comprises determining, at the second network node, whether the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node. The method further comprises providing, from the first network node to the second network node, the access token responsive to determining that the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node. In another illustrative embodiment, a method comprises receiving, from the first network node at the second network node, a request for an access token for services to be provided by the third network node, the request for the access token comprising at least one of one or more target domains of the third network node and one or more target supported features provided by the third network node. The method also comprises providing, from the first network node to the second network node, the access token responsive to the second network node determining that the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

The first network node may comprise a network function service consumer in a 5G communication system, the second network node may comprise an authorization server in the 5G communication system, and the third network node may comprise a network function service producer in the 5G communication system. The authorization server in the 5G communication system may comprise a Network Repository Function (NRF).

One or both of the first network node and the third network node may be a Service Communication Proxy (SCP) in a 5G communication system.

Further, the method may comprise registering, at the second network node, a profile of the third network node. The profile of the third network node may specify at least one of: one or more types of network nodes configured to access said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node; and one or more network node instances configured to access said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

The one or more target domains may comprise one or more Service Communication Proxy (SCP) domains. At least one of the one or more SCP domains may comprise a group of one or more SCPs that can reach at least one of one or more network nodes and one or more SCPs directly without passing through an intermediate SCP. The access token may comprise one or more claims specifying at least one of: ones of the one or more SCP domains that the first network node is permitted to access; and ones of the one or more SCP domains that the first network node is not permitted to access.

The one or more target supported features provided by the third network node may comprise one or more resource-specific features for resources provided by the third network node. The access token may comprise one or more claims specifying ones of the one or more resource-specific features that the first network node is permitted to access.

In a further illustrative embodiment, a method comprises providing, from a first network node in a communication system to a third network node in the communication system, a request for one or more services provided by the third network node, the request comprising an access token issued by a second network node in the communication system, the requested one or more services comprising at least one of one or more target domains and one or more target supported features. The method also comprises receiving, at the first network node from the third network node, access to the requested one or more services responsive to verification of the access token, the access token comprising information indicating at least one of one or more target domains that the first network node is permitted to access and one or more target supported features that the first network node is permitted to access.

In yet another illustrative embodiment, a method comprises receiving, from a first network node in a communication system at a third network node in a communication system, a request for one or more services provided by the third network node, the request comprising an access token issued by a second network node in the communication system, the requested one or more services comprising at least one of one or more target domains and one or more target supported features. The method also comprises determining, at the third network node, whether the first network node is permitted to utilize said at least one of the one or more target domains and the one or more target supported features based at least in part on verifying the access token, the access token comprising information indicating at least one of one or more target domains that the first network node is permitted to access and one or more target supported features that the first network node is permitted to access. The method further comprises providing, from the third network node to the first network node, access to the requested one or more services responsive to verification of the access token. The first network node may comprise a network function service consumer in a 5G communication system, the second network node may comprise an authorization server in the 5G communication system, and the third network node may comprise a network function service producer in the 5G communication system. The authorization server in the 5G communication system may comprise a Network Repository Function (NRF).

The one or more target domains may comprise one or more Service Communication Proxy (SCP) domains. The access token may comprise one or more claims specifying at least one of: ones of the one or more SCP domains that the first network node is permitted to access; and ones of the one or more SCP domains that the first network node is not permitted to access.

The one or more target supported features may comprise one or more resource- specific features for resources provided by the third network node. The access token may comprise one or more claims specifying ones of the one or more resource-specific features that the first network node is permitted to access.

Further illustrative embodiments are provided in the form of a non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further illustrative embodiments comprise apparatus with a processor and a memory configured to perform the above steps.

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. 1A illustrates a communication system with which one or more illustrative embodiments may be implemented.

FIG. IB illustrates a service-based architecture for a communication system within which one or more illustrative embodiments may be implemented.

FIG. 2 illustrates network nodes for service authorization in communication systems with which one or more illustrative embodiments may be implemented. FIG. 3 illustrates a set of interconnected service communication proxy domains for a communication system, according to one or more illustrative embodiments.

FIG. 4 illustrates a methodology for an enhanced access token request procedure, according to one or more illustrative embodiments.

FIGS. 5A and 5B illustrate a table of definition types for the FIG. 4 enhanced access token request, according to one or more illustrative embodiments.

FIG. 6 illustrates a table of definition types for enhanced access token claims for the FIG. 4 enhanced access token request, according to one or more illustrative embodiments.

FIG. 7 illustrates a data storage architecture for a unified data repository, according to one or more illustrative embodiments.

FIG. 8 illustrates a table of definition types for network function services, according to one or more illustrative embodiments.

FIG. 9 illustrates a methodology for another enhanced access token request procedure, according to one or more illustrative embodiments.

FIGS. 10A and 10B illustrate a table of definition types for the FIG. 9 enhanced access token request, according to one or more illustrative embodiments.

FIG. 11 illustrates a table of definition types for enhanced access token claims for the FIG. 9 enhanced access token request, according to one or more illustrative embodiments.

FIG. 12 illustrates a methodology for yet another enhanced access token request, according to one or more illustrative embodiments.

FIG. 13 illustrates a methodology for access services using an enhanced access token, according to one or more illustrative embodiments.

Detailed Description

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for service authorization 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 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.

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 and 3GPP TS 33.501. Other 3GPP TS/TR documents may provide other conventional details that one of ordinary skill in the art will realize. However, while well-suited for 5G-related 3GPP standards, embodiments are not necessarily intended to be limited to any particular standards.

Illustrative embodiments are related to service authorization in 5G networks. Prior to describing such illustrative embodiments, a general description of main components of a 5G network will be described below in the context of FIGS. 1 and 2.

FIG. 1A 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 main functions provided within the system, e.g., UE access functions, mobility management functions, authentication functions, serving gateway functions, etc. As such, the blocks shown in FIG. 1A reference specific elements in 5G networks that provide 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. 1A. Rather, functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures may depict some additional elements/functions.

Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface 103 with an access point (gNB) 104. The UE 102 may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, 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 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 the permanent subscription identifier and its related key, which are used to 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.

Note that, in one example, the permanent subscription identifier is an International Mobile Subscriber Identity (IMSI) of a 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).

The access point 104 is illustratively part of an access network of the communication system 100. Such an access network may comprise, for example, a 5G System having a plurality of base stations and one or more associated radio network control functions. The base stations and radio network control functions may be logically separate entities, but in a given embodiment may be implemented in the same physical network element, such as, for example, a base station router or cellular access point.

The access point 104 in this illustrative embodiment is operatively coupled to mobility management functions 106. In a 5G network, the mobility management function is implemented by an Access and Mobility Management Function (AMF). A Security Anchor Function (SEAF) can also be implemented with the AMF connecting a UE with the mobility management function. A mobility management function, as used herein, is the element or function (i.e., entity) in the core network (CN) part of the communication system that manages or otherwise participates in, among other network operations, access and mobility (including authentication/authorization) operations with the UE (through the access point 104). The AMF may also be referred to herein, more generally, as an access and mobility management entity.

The AMF 106 in this illustrative embodiment is operatively coupled to home subscriber functions 108, i.e., one or more functions that are resident in the home network of the subscriber. As shown, some of these functions include the Unified Data Management (UDM) function, as well as an Authentication Server Function (AUSF). The AUSF and UDM (separately or collectively) may also be referred to herein, more generally, as an authentication entity. In addition, home subscriber functions may include, but are not limited to, Network Slice Selection Function (NSSF), Network Exposure Function (NEF), Network Repository Function (NRF), Policy Control Function (PCF), and Application Function (AF).

The access point 104 is also operatively coupled to a serving gateway function, i.e., 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. 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 system 100 may comprise other elements/functions not expressly shown herein.

Accordingly, the FIG. 1 A 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. 1A 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 A 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) comprise a series of network function (NF) sets (i.e., function chains) for each corresponding service type using network function virtualization (NFV) on a common physical infrastructure. The network slices are instantiated as needed for a given service, e.g., eMBB service, massive IoT service, and mission-critical IoT 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 gNB 104.

The architecture for 5G systems is currently being standardized in 3GPP. As mentioned above, the 3GPP TS 23.501 defines the 5G system architecture as service- based, e.g., Service-Based Architecture (SB A). FIG. IB illustrates a general 5G SB A implementation 120 as further described in 3GPP TS 23.501. Note that the network elements/functions in FIG. IB are the same or similar to those described above in the context of FIG. 1A. The notation of a capital “N” in front of the network entity name (e.g., Nausf) denotes the SBA-based interface within the core network used to access the particular network entity (e.g., AUSF).

FIG. 2 is a block diagram of network nodes for service authorization in a communication system in an illustrative embodiment. System 200 is shown comprising a first network node 202 (e.g., a first network element/function) and a second network node 204 (e.g., a second network element/function). It is to be appreciated that the network nodes 202 and 204 represent any network nodes that are configured to provide authorization and other techniques described herein, for example, but not limited to, AMF, SEAF, UDM, AUSF, NSSF, NEF, NRF, PCF and AF. Further, one or both of the first network node 202 and the second network node 204 may represent a Service Communication Proxy (SCP) element, which will be described in further detail below. In some embodiments, it is assumed that the first network node 202 is a network function service consumer and the second network node 204 is an authorization server such as an NRF.

The network node 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. The processor 212 of the network node 202 includes a service authorization processing module 214 that may be implemented at least in part in the form of software executed by the processor. The processing module 214 performs operations associated with service authorization as described in conjunction with subsequent figures and otherwise herein. The memory 216 of the network node 202 includes a service authorization storage module 218 that stores data generated or otherwise used during service authorization operations.

The network node 204 comprises a processor 222 coupled to a memory 226 and interface circuitry 220. The processor 222 of the network node 204 includes a service authorization processing module 224 that may be implemented at least in part in the form of software executed by the processor 222. The processing module 224 performs operations associated with service authorization as described in conjunction with subsequent figures and otherwise herein. The memory 226 of the network node 204 includes a service authorization storage module 228 that stores data generated or otherwise used during service authorization operations.

The processors 212 and 222 of the respective network nodes 202 and 204 may comprise, for example, microprocessors, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) or other types of processing devices or integrated circuits, as well as portions or combinations of such elements. Such integrated circuit devices, as well as portions or combinations thereof, are examples of “circuitry” as that term is used herein. A wide variety of other arrangements of hardware and associated software or firmware may be used in implementing the illustrative embodiments.

The memories 216 and 226 of the respective network nodes 202 and 204 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, service authorization 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 or 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 processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage 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 processor-readable storage media.

The memory 216 or 226 may more particularly comprise, for example, an 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), phase-change 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 of the respective network nodes 202 and 204 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 network node 202 is configured for communication with network node 204 and vice-versa via their respective interface circuitries 210 and 220. This communication involves network node 202 sending data to the network node 204, and the network node 204 sending data to the network node 202. However, in alternative embodiments, other network elements may be operatively coupled between the network nodes 202 and 204. 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 network nodes (e.g., network elements/functions, as well as between user equipment and a core network) including, but not limited to, messages, identifiers, keys, indicators, user data, control data, etc. Each of network nodes 202 and 204, as well as other parts of communication systems mentioned herein, are considered examples of “a network component,” “a network node,” “a network entity” (all of which can be used interchangeably herein). 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 node can be configured to incorporate additional or alternative components and to support other communication protocols.

Other system elements such as UE 102 and gNB 104 may each also be configured to include components such as a processor, memory and network interface. These elements 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.

Illustrative embodiments provide authorization techniques in a service communication proxy for 5G systems. The architecture for 5G systems is currently being standardized in 3GPP. As mentioned above, the 3GPP TS 23.501 defines the 5G system architecture as service-based, e.g., Service-Based Architecture (SB A). The notation of a capital “N” in front of the network element/function name (e.g., Nudm) denotes the interface within the core network used to access the particular network element/function (e.g., (UDM)).

Given the general concepts described above, illustrative embodiments that address certain authorization issues will now be described. 3GPP Release 16 (Rel-16) of TS 23.501 introduces what is referred to as an indirect communication model in which network functions (NFs) communicate via an SCP, which is an intermediate NF configured to route control plane messages between two NFs (e.g., in a manner similar to that of a Diameter Routing Agent (DRA) in a 3G or 4G communication system).

Section 6.2.19 of 3GPP TS 23.501 defines an SCP as including various functionality, which may be supported in a single instance of an SCP or multiple instances of an SCP. Such functionality includes, but is not limited to, indirect communication, delegated discovery, message forwarding and routing to a destination NF or NF service, communication security (e.g., authorization of a NF Service Consumer to access a NF Service Producer Application Programming Interface (API)), load balancing, monitoring, overload control, etc. The functionality of an SCP may also or alternatively include optional interaction with other entities, such as a Unified Data Repository (UDR) to resolve a group identifier (ID) (e.g., a UDM Group ID, a USF Group ID, a PCF Group ID) based on a UE identity such as a SUPI. Communication security, such as authorization of the NF Service Consumer to access the NF Service Producer’s API, is specified in 3GPP TS 33.501. Load balancing, monitoring and overload control functionality provided by the SCP may be implementation-dependent. In some cases, the SCP is deployed in a distributed manner, and more than one SCP may be present in a communication path between NF Services. Further details about the SCP are described in 3GPP TR 33.855, VI.8.0, entitled “Technical Specification Group Services and System Aspects; Security Aspects; Study on Security Aspects of the 5G Service Based Architecture,” the disclosure of which is incorporated by reference herein in its entirety.

Note that as used herein, an NF that consumes a particular network service is referred to as a “service consumer,” while an NF that produces the particular network service is referred to as the “service producer.” The NF service consumer typically has to be authorized to access service(s) of the NF service producer. This authorization process typically involves use of an access token to authorize the NF service consumer. Note that an NF can be a consumer for one service and a producer for another service.

Further details of deploying an SCP for communication between NFs and NF services are described in Annex E of TS 23.501.

Note that the SCP defined above in SA WG2 is referred in SA WG3 as SECOP for avoiding collision with other functionalities. A SECOP is considered a service communication proxy as illustratively used herein.

A 5G SBA scenario where authorization in an SCP can be implemented will now be described in the context of an intra-Public Land Mobile Network (PLMN) inter-SCP scenario. In this scenario, the NF Service Consumer or NFc and NF Service Producer or NFp are in a same PLMN. The NFc is connected to an SCP-c and the NFp is connected to an SCP-p. The SCP-c is connected to an NRF1 and the SCP-p is connected to an NRF2. The SCP-c and SCP-p are also connected to one another. In this scenario, the NF service consumer instance (NFc) uses the SCP (SCP-c) for delegated routing of NF requests to the selected NF service producer instance (NFp), along with delegated target NF producer discovery and selection. As illustratively used herein, “determining” a target NF producer comprises one or more of discovery and selection of a target NF producer. As will be further explained below, SCP-based authorization applies to the SCP on the consumer side (SCP-c). That is, in one or more illustrative embodiments, the SCP on the consumer side determines which authorization method to use (based on configuration parameters set therein), and NFc is unaware and not impacted.

An SCP has a parameter configurable to enable or disable authorization in the SCP. For example, in one illustrative embodiment, the SCP has a parameter associated therewith that can be set to one of two values: “enabled” or “disabled.” Based on the operator policy (which can be influenced by various factors such as, but not limited to, location, NF load, SCP load, etc.), authorization is enabled or disabled in the SCP by setting the parameter. The authorization capability of the SCP is at the SCP level (each SCP may be configured differently) or at PLMN level (all SCPs within the PLMN share the same configuration setting).

Note that illustrative embodiments also comprise a scenario where SCP-c is enabled to participate in the authorization process and algorithmically decides that it needs to obtain an access token, regardless of whether it received an access token from NFc. One of the factors determining this step can be that the SCP-c can dynamically decide to service the request with a “set” of producers (NF Set in 3GPP terminology). Using a “set” enables SCP-c to obtain an access token for an NF Set, and use it with any of the target NF producer instances within the “set”.

Note that as used herein, the phrase “service communication proxy-based authorization” illustratively refers to one or more scenarios wherein the SCP executes an authorization procedure to obtain an access token on behalf of the consumer and may then verify the access token on behalf of the producer. The phrase “network component-based authorization” illustratively refers to one or more scenarios wherein an authorization procedure is performed to obtain an access token (e.g., at the NF consumer) and verify the access token (e.g., at the NF producer).

Note that a given NF may be an NFc in one instance and an NFp in another instance as it may provide services to other network functions, but also requests and needs services from other network functions. As such, the SCP associated with the given NF (referred to as a trusted SCP) can function as an SCPc or an SCPp depending on the context.

In some embodiments, there are multiple SCPs in a signalling path. FIG. 3, for example, illustrates a communication system 300 that includes a set of interconnected SCP domains 1-7, with a number of SCPs 1-10 and NFs 1-14. An SCP domain is a configured group of one or more SCPs that can reach certain NF instances or SCPs directly (e.g., without passing through an intermediate SCP). In such scenarios, solutions for SCP discovery are needed. A solution for SCP discovery includes enhancing the NRF with a new SCP profile that the SCP registers and can discover using existing NRF services. The SCP domains include directly interconnected SCPs. An SCP profile for a given SCP lists all SCP domains that the given SCP is interconnected to, and thus also identifies SCPs that interconnect domains. In the FIG. 3 system, for example, SCP1 interconnects SCP domains 1 and 2. An SCP domain can be associated with multiple NFs and SCPs. An NF consumer or NFc, or an SCP performing delegated discovery on behalf of the SCP, can learn the SCP domain of a target NF (e.g., a NF producer or NFp) or SCP via NRF discovery procedures. The SCP domain may also be added to the NF profile of other NFs.

Techniques are also needed for securing connections between SCPs as well as connections from NFs to SCPs. In some embodiments, transport layer security (TLS) is used. TLS provides a means for verifying the identity of peers to communicate with. Policies are used to decide which peers are allowed to communicate with each other, and can be built on top of the TLS layer. While PLMN-wide trust between NFs and SCPs is an option, more restrictions may be used as desired (e.g., such as in complex multi-vendor networks). Such restrictions may be based, for example, at least in part on compute center boundaries, on operators of subnetworks, etc.

While SCP domains are standardized in 3GPP TS 23.501, domain-level authorization is needed. SCP domains may be used to describe finer-granular regions of trust than a PLMN. A region of trust may be built out of one or multiple SCP domains. This includes associating some NF producer(s) domain(s) or SCP domain(s) to some set of users or NF service consumers (e.g., a set of corporate users, public safety users, etc.) and to restrict access to NF instances. Using SCP domains, it is possible to restrict NF service consumer access as per an NF service producer’s domain or an SCP’s domain. The following related aspects may be used in various combinations:

1. The NRF has knowledge about the SCP domains that a NF service consumer or SCP may access, and uses this knowledge for at least one of: a. For discovery requests of that NF service consumer or SCP, to authorize the requests based on whether the expected NF or SCP instances are within the SCP domain; b. For discovery requests of that NF service consumer or SCP, to restrict the NF instances of SCP instances provided to that NF service consumer or SCP in response to the discovery requests accordingly; and c. In response to an access token request, to provide access tokens authorized for some or all of those SCP domains only.

2. OAuth 2.0 procedures are enhanced to convey additional information for the “domain” in a JavaScript Object Notation (JSON) Web Token, which enables the NF service producer or SCP to verify whether the requesting NF (e.g., a NF service consumer) is authorized to access the NF service producer or SCP.

As part of the discovery procedure, the NRF checks whether the NF service consumer is allowed to access the requested NF. 3GPP TS 33.501, clause 13.3.1.3, provides (in part) as follows:

In the non-roaming scenario, the NRF authorizes the Nnrf_NFDiscovery_Request based on the profile of the expected NF/NF service and the type of the NF service consumer, as described in clause 4.17.4 of TS23.502 [8]. In the roaming scenario, the NRF of the NF Service Provider shall authorize the Nnrf_NFDiscovery_Request based on the profile of the expected NF/NF Service, the type of the NF service consumer and the serving network ID.

If the NRF finds NF service consumer is not allowed to discover the expected NF instances(s) as described in clause 4.17.4 of TS 23.502[8],

NRF shall support error handling, and may send back an error message.

The NRF has knowledge about the SCP domains an NF service consumer or SCP may access (e.g., based on configuration). Based on the profile of the expected NF or NF service, the type of the NF service consumer, and on the requested domain (e.g., SCP domain), the NRF determines whether the NF service consumer is allowed to discover the expected NF instance(s) in the same or a different PLMN.

When access to the requested domain is not allowed for the NF type of the NF service consumer, the NRF rejects the discovery request. If the discovery domain does not indicate the SCP domain, the NRF restricts the NF instances or SCP instances provided to that NF service consumer or SCP in response to the discovery request (e.g., to NF instances of SCP instances in SCP domains that the NF service consumer or SCP is allowed to access).

FIG. 4 illustrates a methodology 400 for an enhanced access token request procedure that includes a target requested domain (e.g., a requested SCP domain). The methodology 400 includes a NF service consumer 402 and an authorization server (e.g., NRF) 404. In an access token request sent in step 1 (e.g., an Nnrf_AccessToken_Get request), the NF service consumer 402 includes a target domain (e.g., a target SCP domain) that the NF service consumer 402 would like to access. Step 1 includes the NF service consumer 402 requesting an access token from the NRF 404 in the same PLMN using the Nnrf_AccessToken_Get request operation. The message illustratively includes the NF instance identifier(s) (IDs) of the NF service consumer 402, the requested “scope” including the expected NF service name(s) and optionally “additional scope” information (e.g., requested resources and requested actions, such as service operations, on the resources), and the NF type of the expected NF service provider instance and the NF service consumer 402. The NF service consumer 402 may also include a list of Network Slice Selection Assistance Information (NSSAIs) and/or a list of Network Slice Instance (NSI) IDs for the expected NF service producer instances. The message in step 1 may also include a NF set ID of the expected NF service producer instances. The message in step 1 further includes a target domain (e.g., a target SCP domain) that the NF service consumer 402 would like to access.

In step 2 of the methodology 400, the NRF 404 optionally authorizes the NF service consumer 402 based on the requested domain (e.g., the target SCP domain in the Nnrf_AccessToken_Get request). The NRF 404 then generates an access token with appropriate claims included. The NRF 404 digitally signs the generated access token based on a shared secret or private key (e.g., as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 7515). The claims in the access token include the NF instance ID of the NRF 404 (e.g., the issuer), the NF instance ID of the NF service consumer 402 (e.g., the subject), the NF type of the NF service producer (e.g., the audience), the expected service name(s), scope (e.g., the scope), expiration time (e.g., the expiration) and optionally “additional scope” information (e.g., allowed resources and allowed actions such as service operations on the resources). The claims may include the NF set ID of the expected NF service producer instances. The claims may also include the allowed SCP domain(s) and/or forbidden SCP domain(s) of the expected NF service producer or SCP.

In step 3 of the methodology 400, if the authorization of step 2 is successful, the NRF 404 sends the generated access token to the NF service consumer 402 in a response message (e.g., an Nnrf_AccessToken_Get response operation). If the authorization of step 2 is not successful, the NRF 404 replies based on OAuth 2.0 error responses as defined in IETF RFC 6749. The step 3 response message may include various other parameters (e.g., the expiration time, allowed scope, etc.) sent by the NRF 404 in addition to the access token. Examples of such other parameters are described in 3GPP TS 29.510. The NF service consumer 402 may store the received access tokens. The stored access tokens may be re-used for accessing service(s) from producer NF types list in the claims (e.g., the scope, the audience) during their validity time.

FIGS. 5 A and 5B show respective portions 500-1 and 500-2, respectively, of a table of definition types for the enhanced access token request described above with respect to FIG. 4. The table of FIGS. 5 A and 5B represent an enhancement of Table 6.3.5.2.2-1 of 3GPP TS 29.510 for including target domain information. More particularly, the last row of the table includes the attribute name “TargetDomain” with a data type of “SCPDomain,” and a description of “indicates the SCP domain to be supported by the target.”

As noted above, the access token claims may be updated to include allowed resources within the NF service producer. The type “AccessTokenClaims” may be enhanced to include one or more new claims, such as “AllowedDomain” and “ForbiddenDomain” which contain a whitelist of allowed SCP domains that the NF service consumer is allowed to target and a blacklist of disallowed SCP domains that the NF service consumer is not allowed to target, respectively. In this way, NF service consumer access may be restricted on a per-NF service producer or per-SCP domain. Thus, the chance of a NF service consumer asking for a token for the wrong SCP domain are reduced. If a NF service consumer asks for a wrong domain access token, the NRF 404 can reject the token request.

FIG. 6 shows a table 600 of definition types for access token claims for the enhanced access token request described above with respect to FIG. 4. The table 600 represents an enhancement of Table 6.3.5.2.4-1 of 3GPP TS 29.510 for including lists of allowed and forbidden SCP domains. More particularly, the last two rows of the table 600 include rows with attribute names of “AllowedDomains” and “ForbiddenDomains” with data types of “Array(SCPDomain),” and description of a “whitelist of allowed SCP domains that the NF service consumer is allowed to target” and a “blacklist of SCP domains that the NF service consumer is not allowed to target.”

3GPP SA2 has defined the UDR as the network entity in the 5GC that stores various types of data, including UE subscription-related information, the information needed for exposure, policy-related information, etc. FIG. 7 illustrates a data storage architecture 700 for a UDR 702 that includes a data access provider 704 and a data store 706 (e.g., including subscription data, policy data, structured data for exposure, application data, etc.). The Nudr interface is used by various network functions (e.g., such as UDM 708, PCF 710 and NEF 712 over N35, N36 and N37 interfaces) to access a particular set or portion of the data stored in the UDR 702. The UDR 702, via the data access provider 704, offers an Nudr_DataRepository service via the Nudr interface. Using this service, various operations may be performed on data stored in the data store 706. The service also allows NF service consumers to retrieve, create, update, modify and delete data stored in the data store 706 of UDM 702.

3GPP WG CT4 defines stage 3 details of the UDR network function. UE subscription information is stored in a resource called “Subscription Data.” This resource manages UE authentication data, including an encrypted long-term key (K), a sequence number, etc. 3GPP SA2 has also agreed on the CR, where resource-level authorization is possible. In 3GPP TS 29.500, Section 6.6.2 defines features negotiation. A versioning of services in a request Uniform Resource Identifier (URI) is supported by 3GPP 5G APIs, but version upgrades are only applied for non backward compatible changes or the introduction of new mandatory features. In some embodiments, mechanisms are provided for negotiating applicable optional features to be used by 5G APIs. This mechanism may be applied separately for each API. For any API that defines resources, suitable resources associated with or representing the NF service consumer (e.g., a top-level resource or a sub-resource representing the NF service consumer) is identified in each API to support the negotiation of applicable optional features between the NF service consumer and NF service producer for that resource. Each such resource for a 5G API contains an attribute (e.g., “SupportedFeatures”) of the SupportedFeatures data type defined in 3GPP TS 29.571 containing a bitmask to indicate supported features. The features and their positions in that bitmask are defined separately for each API.

In 5G SBA, service access authorization based on OAuth is at the service level and the resource or dataset level. In other words, 3GPP TS 23.501 and 23.502 allows for restrictions at the service level and the dataset or resource level to control which NFs are allowed to consume a service or resource. Each service allows a set of operations (e.g., methods), but access and update is regulated on the service level only. In such an arrangement, there is no way to check whether the NF service consumer is authorized to access specific attributes or resource-specific features of datasets or resources. This creates fundamental issues, specifically with the UDR NF. The UDR provides an Nudr_DataRepository service to all NF service consumers. Any NF can use the Nudr interface to access resources managed by the UDR, including UE subscription data. There is no specific access permission to UDR operations with the Nudr_DataRepository service.

Some use cases where attribute-level access restriction is required will now be described. Consider an example where Vz has asked for custom features where the UDM stores custom data attributes such as “aaaAddress,” “SelfActivationStatus,” etc., and custom attributes inside the “SessionManagementSubscriptionData” resource. When the AMF indicates a supported feature bit set for “VzCustomerFeature,” the UDM shall send this to the AMF. Since there is no mechanism available in the OAuth framework to authorize NFs for attribute level (e.g., sub-resource level) access, any NF can access such custom data. More generally, consider an operator that has deployed VendorX AMFs and VendorY AMFs in the network. VendorX has implemented a feature which requires certain keys or data to be stored in the UDR as part of an existing resource. Again, the UDM/UDR is not able to validate the AMF or other NFs which are allowed to access the custom attribute and which are not. In general, different types of sub-resource level data or attribute level data within a NF may have different data access authorizations. Techniques are thus needed for the NF to be able to have an authorization management mechanism to guarantee safety of data access.

If an operator implements a custom feature at an NF where only restricted NF service consumers are allowed to access the service, then that NF registers in the NRF via a supported feature bit set where the custom feature bit(s) are set. Any consumer can download the NF profile and consume the service, as there is no authorization available in OAuth for the same. Consider, as an example, an SMF that supports a custom feature for OperatorX and that when an AMF invokes the custom feature and creates a PDU session service at the SMF and provides an additional flag, the SMF provides additional information to the AMF as a response. It should be noted that this may be a non-3GPP specific feature as it is not defined in 3GPP. This custom feature is implemented at the SMF. However, due to the limitations of OAuth, the SMF is not able to recognize which AMF is allowed to invoke the resource-specific service or not. In other words, any AMF can give the flags in a create PDU session request towards the SMF, and the SMF will provide additional data to that AMF without authorizing that AMF.

In some embodiments, OAuth 2.0 procedures are enhanced to convey additional information in the JSON Web Token, which enables a NF service producer to verify whether a requesting NF (e.g., a NF service consumer instance, a NF service consumer set, etc.) is authorized to access resource-specific features managed by the NF service producer. To enable such functionality for 3GPP, various changes are required in the 3GPP TS 33.501 and 29.501 specifications.

As part of a registration procedure, a NF registers in its NF profile in the NRF additional information indicating the NF types or NF instances that are allowed to use resource-specific features. This information is used by the NF service consumer in order to discover the additional access token authorizations (e.g., resource-specific features) that might be required to invoke a certain feature for a certain service operation or resource, based on the authorization information registered in the NRF by the NF service producer in its NF profile. This may be registered in the NRF within an NFService attribute of a NF service producer’s NF profile. FIG. 8 shows a table 800 of definition types for NF services. The table 800 may represent an enhancement of Table 6.1.6.2.3-1 of 3GPP TS 29.510 for including information related to allowed resource- specific features on a per-NF type and/or per- NF instance level. It should be noted that the table 800 of FIG. 8 illustrates only added rows for the Table 6.1.6.2.3-1 of 3GPP TS 29.510. The table 800 includes a first row with an attribute name of “AllowedResourceSpecificFeaturePerNfType” with a data type of “map(map(array(SupportedFeatures)))” and a description that is a map of allowed resource-specific features for each type of NF. The key of the map is the NF type, and the value is a map where the key is an additional scope or is a resource name and the value is an array of allowed features. The additional scope may be any of those defined in the API that defines the current service (e.g., as identified by a “ServiceName” attribute).

The table 800 also includes a second row with an attribute name of “AllowedResourceSpecificFeaturePerNflnstance” with a data type of “map(map(array(SupportedFeatures)))” and a description that is a map of allowed resource-specific features for a given NF instance. The key of the map is the NF instance ID, and the value is a map where the key is an additional scope or is a resource name and the value is an array of allowed features. The additional scope may be any of those defined in the API that defines the current service (e.g., as identified by a “ServiceName” attribute).

It is noted that the attributes of the first and second rows of table 800 are used by NF service consumers in order to discover the additional authorization (e.g., for resource-specific features) that might be required to invoke a certain feature for a certain service operation or resource, based on the authorization information registered in an NRF by the NF service producer in its NF profile.

As a part of the discovery procedure, the NRF checks whether the NF service consumer is allowed to access the requested NF. Based on the profile of the expected NF or NF service, the type of the NF service consumer, and the requested supported feature (e.g., a requested Supported-Feature, also referred to as a RequiredFeature in an Nnrf_NFDiscovery query), the NRF determines whether the NF service consumer is allowed to discover the expected NF instance(s) and is allowed to use the requested features. When access to the requested supported feature is not allowed for the NF type of the NF service consumer, the NRF rejects the discovery request. Parameters such as an allowed resource-specific feature NF type (e.g., allowedResourceSpecificFeatureNFType) and an allowed resource-specific feature NF instances (e.g., allowedResourceSpecificFeatureNFInstance) are considered by the NF and/or NRF while selecting the specific NF service instance for the requested feature. Such parameters are detailed in FIG. 8, discussed above.

An enhanced access token request procedure is utilized to include the requested or required supported feature. FIG. 9 illustrates a methodology 900 for the enhanced access token request procedure that includes target requested or required supported feature(s). The methodology 900 includes a NF service consumer 902 and an authorization server (e.g., NRF) 904. In step 0, the NF service consumer 902 registers with the NRF 904.

In an access token request sent in step 1 (e.g., an Nnrf_AccessToken_Get request), the NF service consumer 902 includes target supported features (e.g., Supported-Feature, also referred to as RequiredFeature) that the NF service consumer 902 would like to access. Step 1 includes the NF service consumer 902 requesting an access token from the NRF 904 using the Nnrf_AccessToken_Get request operation. The message illustratively includes the NF instance IDs of the NF service consumer 902, the requested “scope” including the expected NF service name(s) and optionally “additional scope” information (e.g., requested resources and requested actions, such as service operations, on the resources), and the NF type of the expected NF service provider instance and the NF service consumer 902. The NF service consumer 902 may also include a list of NSSAIs and/or a list of NSI IDs for the expected NF service producer instances. The message in step 1 may also include a NF set ID of the expected NF service producer instances. The message in step 1 further includes the target supported features that the NF service consumer 902 would like to access.

In step 2 of the methodology 900, the NRF 904 optionally authorizes the NF service consumer 902 based on the requested supported features (e.g., the Supported- Feature^) or RequiredFeature(s) in the Nnrf_AccessToken_Get request). The NRF 904 then generates an access token with appropriate claims included. The NRF 904 digitally signs the generated access token based on a shared secret or private key (e.g., as described in IETF RFC 7515). The claims in the access token include the NF instance ID of the NRF 904 (e.g., the issuer), the NF instance ID of the NF service consumer 902 (e.g., the subject), the NF type of the NF service producer (e.g., the audience), the expected service name(s), scope (e.g., the scope), expiration time (e.g., the expiration) and optionally “additional scope” information (e.g., allowed resources and allowed actions such as service operations on the resources). The claims may include the NF set ID of the expected NF service producer instances. The claims may also include the allowed resource- specific features per NF type and the allowed resource-specific features per NF instance.

In step 3 of the methodology 900, if the authorization of step 2 is successful, the NRF 904 sends the generated access token to the NF service consumer 902 in a response message (e.g., an Nnrf_AccessToken_Get response operation). If the authorization of step 2 is not successful, the NRF 904 replies based on OAuth 2.0 error responses as defined in IETF RFC 6749. The step 3 response message may include various other parameters (e.g., the expiration time, allowed scope, etc.) sent by the NRF 904 in addition to the access token. Examples of such other parameters are described in 3GPP TS 29.510. The NF service consumer 902 may store the received access tokens. The stored access tokens may be re-used for accessing service(s) from producer NF types list in the claims (e.g., the scope, the audience) during their validity time.

FIGS. 10A and 10B show respective portions 1000-1 and 1000-2, respectively, of a table of definition types for the enhanced access token request described above with respect to FIG. 9. The table of FIGS. 10A and 10B represent an enhancement of Table 6.3.5.2.2-1 of 3GPP TS 29.510 for including target supported features information. More particularly, the last row of the table includes the attribute name “TargetSupportedFeature” with a data type of a description of “indicates the target features (e.g., Supported-Feature) requested to be used for a resource” and “may be included if the NFs supporting Supported-Feature.”

As noted above, the access token claims may be updated to include allowed resources within the NF service producer. The type “AccessTokenClaims” may be enhanced to include one or more new claims, such as “AllowedSupported-Feature” which contains resource supported features that the NF service consumer 902 can access in an NF service producer.

FIG. 11 shows a table 1100 of definition types for access token claims for the enhanced access token request described above with respect to FIG. 4. The table 1100 represents an enhancement of Table 6.3.5.2.4-1 of 3GPP TS 29.510 for including lists of allowed resources within an NF service producer. More particularly, the last row of the table 1100 includes an attribute name of “AllowedSupportedFeature” with data type of “String” and a description of “when present, contains the supported features that the NF service consumer is allowed to access.”

Although described separately for ease of illustration, it should be appreciated that in some embodiments a NF service consumer may both request a target domain and target supported features, such that the methodology 400 and methodology 900 are combined. FIG. 12 shows an example of such a combined methodology 1200 for an enhanced access token request procedure that is utilized to include a target domain and requested or required supported features. Step 0 of the methodology 1200 is similar to step 0 of methodology 900. The methodology 1200 proceeds in a manner similar to that of methodologies 400 and 900, though in step 1 the access token request (e.g, the Nnrf_AccessToken_Get request) includes both target domain(s) and target requested supported feature(s), in addition to the other parameters such as the requested “scope” including the expected NF service name(s) and optionally “additional scope” information (e.g., requested resources and requested actions, such as service operations, on the resources), the NF type of the expected NF service provider instance and the NF service consumer 1202, a list of NSSAIs and/or a list of NSI IDs for the expected NF service producer instances, a NF set ID of the expected NF service producer instances, etc.

In step 2 of the methodology 1200, the NRF 1204 optionally authorizes the NF service consumer 1202 based on the requested target domain and the requested target supported features. The NRF 1204 then generates an access token with appropriate claims included. The NRF 1204 digitally signs the generated access token based on a shared secret or private key (e.g., as described in IETF RFC 7515). The claims in the access token include the NF instance ID of the NRF 1204 (e.g., the issuer), the NF instance ID of the NF service consumer 1202 (e.g., the subject), the NF type of the NF service producer (e.g., the audience), the expected service name(s), scope (e.g., the scope), expiration time (e.g., the expiration) and optionally “additional scope” information (e.g., allowed resources and allowed actions such as service operations on the resources). The claims may include the NF set ID of the expected NF service producer instances. The claims may also include the allowed SCP domain(s) and/or forbidden SCP domain(s) of the expected NF service producer or SCP, as well as the allowed resource-specific features per NF type and the allowed resource-specific features per NF instance.

In step 3 of the methodology 1200, if the authorization of step 2 is successful, the NRF 1204 sends the generated access token to the NF service consumer 1202 in a response message (e.g., an Nnrf_AccessToken_Get response operation). If the authorization of step 2 is not successful, the NRF 1204 replies based on OAuth 2.0 error responses as defined in IETF RFC 6749. The step 3 response message may include various other parameters (e.g., the expiration time, allowed scope, etc.) sent by the NRF 1204 in addition to the access token. Examples of such other parameters are described in 3GPP TS 29.510. The NF service consumer 1202 may store the received access tokens. The stored access tokens may be re-used for accessing service(s) from producer NF types list in the claims (e.g., the scope, the audience) during their validity time. It should be noted that, in the combined methodology 1200, the tables of FIGS. 5A-5B and 10A-10B may be combined and the tables of FIGS. 6 and 11 may be combined.

A request for access to services utilizing enhanced access tokens will now be described with respect to FIG. 13. FIG. 13 illustrates a methodology 1300 for utilizing an enhanced access token (e.g., which is generated utilizing any of the methodologies 400, 900 and 1200 described herein) for requesting or accessing services. The methodology 1300 includes first network node 1302 (e.g., a NF service consumer or SCP) and a second network node 1304 (e.g., a NF service producer or SCP).

In some embodiments of the methodology 1300, the first network node 1302 may be a NF service consumer and the second network node 1304 is a NF service producer. In such embodiments, the NF service consumer 1302 in step 1 sends a request for access to services to be provided by the NF service producer 1304. The request includes an enhanced access token as described herein, such as an access token that includes claims relating to allowed resource-specific features (e.g., per NF type, per NF instance) and/or allowed SCP domains (e.g., lists of allowed and/or forbidden SCP domains). The NF service producer 1304 in step 2 verifies the received access token. This may include the NF service producer 1304 verifying the claims in the received access token to determine whether the NF service consumer 1302 is allowed to access requested resource-specific features and/or requested SCP domains. In step 3, the NF service producer 1304 provides the requested services to the NF service consumer 1302 if the verification of the access token is successful in step 2.

In other embodiments of the methodology 1300, the first network node 1302 may be a NF service consumer and the second network node 1304 is a SCP. In such embodiments, the NF service consumer 1302 in step 1 sends a request for access to services to be provided by the SCP 1304. The request includes an enhanced access token as described herein, such as an access token that includes claims relating to allowed resource-specific features (e.g., per NF type, per NF instance) and/or allowed SCP domains (e.g., lists of allowed and/or forbidden SCP domains). The SCP 1304 in step 2 verifies the received access token. This may include the SCP 1304 verifying the claims in the received access token to determine whether the NF service consumer 1302 is allowed to access requested resource-specific features and/or requested SCP domains. In step 3, the SCP 1304 provides the requested services to the NF service consumer 1302 if the verification of the access token is successful in step 2.

In still other embodiments of the methodology 1300, the first network node 1302 and the second network node 1304 may both by SCPs. In such embodiments, the SCP 1302 in step 1 sends a request for access to services to be provided by the SCP 1304. The request includes an enhanced access token as described herein, such as an access token that includes claims relating to allowed resource-specific features (e.g., per NF type, per NF instance) and/or allowed SCP domains (e.g., lists of allowed and/or forbidden SCP domains). The SCP 1304 in step 2 verifies the received access token. This may include the SCP 1304 verifying the claims in the received access token to determine whether the SCP 1302 is allowed to access requested resource- specific features and/or requested SCP domains. In step 3, the SCP 1304 provides the requested services to the SCP 1302 if the verification of the access token is successful in step 2.

In yet other embodiments of the methodology 1300, the first network node 1302 is an SCP and the second network node is an NF service producer. In such embodiments, the SCP 1302 in step 1 sends a request for access to services to be provided by the NF service producer 1304. The request includes an enhanced access token as described herein, such as an access token that includes claims relating to allowed resource-specific features (e.g., per NF type, per NF instance) and/or allowed SCP domains (e.g., lists of allowed and/or forbidden SCP domains). The NF service producer 1304 in step 2 verifies the received access token. This may include the NF service producer 1304 verifying the claims in the received access token to determine whether the SCP 1302 is allowed to access requested resource-specific features and/or requested SCP domains. In step 3, the NF service producer 1304 provides the requested services to the SCP 1302 if the verification of the access token is successful in step 2.

It should be appreciated that various combinations of the above are embodiments of the methodology 1300 are possible.

The particular processing operations and other system functionality described in conjunction with the figures 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, key pair 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

I/We Claim:

1. An apparatus comprising: at least one processor; at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to: receive, from a first network node in a communication system at a second network node in the communication system, a request for an access token for services to be provided by a third network node in the communication system, the request for the access token comprising at least one of one or more target domains of the third network node and one or more target supported features provided by the third network node; determine, at the second network node, whether the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node; and provide, from the first network node to the second network node, the access token responsive to determining that the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

2. The apparatus of claim 1 , wherein the first network node comprises a network function service consumer in a 5G communication system, the second network node comprises an authorization server in the 5G communication system, and the third network node comprises a network function service producer in the 5G communication system.

3. The apparatus of claim 2, wherein the authorization server in the 5G communication system comprises a Network Repository Function (NRF).

4. The apparatus of claim 1 , wherein at least one of the first network node and the third network node comprises a Service Communication Proxy (SCP) in a 5G communication system.

5. The apparatus of claim 1, further comprising registering, at the second network node, a profile of the third network node.

6. The apparatus of claim 5, wherein the profile of the third network node specifies at least one of: one or more types of network nodes configured to access said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node; and one or more network node instances configured to access said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

7. The apparatus of claim 1, wherein the one or more target domains comprise one or more Service Communication Proxy (SCP) domains.

8. The apparatus of claim 7, wherein at least one of the one or more SCP domains comprises a group of one or more SCPs that can reach at least one of one or more network nodes and one or more SCPs directly without passing through an intermediate SCP.

9. The apparatus of claim 8, wherein the access token comprises one or more claims specifying at least one of: ones of the one or more SCP domains that the first network node is permitted to access; and ones of the one or more SCP domains that the first network node is not permitted to access.

10. The apparatus of claim 1, wherein the one or more target supported features provided by the third network node comprise one or more resource-specific features for resources provided by the third network node.

11. The apparatus of claim 10, wherein the access token comprises one or more claims specifying ones of the one or more resource-specific features that the first network node is permitted to access.

12. A method comprising: receiving, from a first network node in a communication system at a second network node in the communication system, a request for an access token for services to be provided by a third network node in the communication system, the request for the access token comprising at least one of one or more target domains of the third network node and one or more target supported features provided by the third network node; determining, at the second network node, whether the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node; and providing, from the first network node to the second network node, the access token responsive to determining that the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

13. An article of manufacture comprising a non-transitory computer- readable storage medium having embodied therein executable program code that when executed by a processor operatively coupled to the computer-readable storage medium cause the processor to perform steps of: receiving, from a first network node in a communication system at a second network node in the communication system, a request for an access token for services to be provided by a third network node in the communication system, the request for the access token comprising at least one of one or more target domains of the third network node and one or more target supported features provided by the third network node; determining, at the second network node, whether the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node; and providing, from the first network node to the second network node, the access token responsive to determining that the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

14. An apparatus comprising: at least one processor; at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to: receive, from a first network node in a communication system at a second network node in the communication system, a request for an access token for services to be provided by a third network node in the communication system, the request for the access token comprising at least one of one or more target domains of the third network node and one or more target supported features provided by the third network node; and provide, from the first network node to the second network node, the access token responsive to the second network node determining that the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

15. The apparatus of claim 14, wherein the first network node comprises a network function service consumer in a 5G communication system, the second network node comprises an authorization server in the 5G communication system, and the third network node comprises a network function service producer in the 5G communication system.

16. The apparatus of claim 15, wherein the authorization server in the 5G communication system comprises a Network Repository Function (NRF).

17. The apparatus of claim 14, wherein determining that the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node is based at least in part on a profile of the third network node registered at the second network node.

18. The apparatus of claim 17, wherein the profile of the third network node specifies at least one of: one or more types of network nodes configured to access said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node; and one or more network node instances configured to access said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

19. The apparatus of claim 14, wherein the one or more target domains comprise one or more Service Communication Proxy (SCP) domains.

20. The apparatus of claim 19, wherein at least one of the one or more SCP domains comprises a group of one or more SCPs that can reach at least one of one or more network nodes and one or more SCPs directly without passing through an intermediate SCP.

21. The apparatus of claim 19, wherein the access token comprises one or more claims specifying at least one of: ones of the one or more SCP domains that the first network node is permitted to access; and ones of the one or more SCP domains that the first network node is not permitted to access.

22. The apparatus of claim 14, wherein the one or more target supported features provided by the third network node comprise one or more resource-specific features for resources provided by the third network node.

23. The apparatus of claim 22, wherein the access token comprises one or more claims specifying ones of the one or more resource-specific features that the first network node is permitted to access.

24. A method comprising: receiving, from a first network node in a communication system at a second network node in the communication system, a request for an access token for services to be provided by a third network node in the communication system, the request for the access token comprising at least one of one or more target domains of the third network node and one or more target supported features provided by the third network node; and providing, from the first network node to the second network node, the access token responsive to the second network node determining that the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

25. An article of manufacture comprising a non-transitory computer- readable storage medium having embodied therein executable program code that when executed by a processor operatively coupled to the computer-readable storage medium cause the processor to perform steps of: receiving, from a first network node in a communication system at a second network node in the communication system, a request for an access token for services to be provided by a third network node in the communication system, the request for the access token comprising at least one of one or more target domains of the third network node and one or more target supported features provided by the third network node; and providing, from the first network node to the second network node, the access token responsive to the second network node determining that the first network node is permitted to utilize said at least one of the one or more target domains of the third network node and the one or more target supported features provided by the third network node.

26. An apparatus comprising: at least one processor; at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to: provide, from a first network node in a communication system to a third network node in the communication system, a request for one or more services provided by the third network node, the request comprising an access token issued by a second network node in the communication system, the requested one or more services comprising at least one of one or more target domains and one or more target supported features; and receive, at the first network node from the third network node, access to the requested one or more services responsive to verification of the access token, the access token comprising information indicating at least one of one or more target domains that the first network node is permitted to access and one or more target supported features that the first network node is permitted to access.

27. The apparatus of claim 26, wherein the first network node comprises a network function service consumer in a 5G communication system, the second network node comprises an authorization server in the 5G communication system, and the third network node comprises a network function service producer in the 5G communication system.

28. The apparatus of claim 26, wherein at least one of the first network node and the third network node comprises a Service Communication Proxy (SCP) in a 5G communication system.

29. The apparatus of claim 26, wherein the one or more target domains comprise one or more Service Communication Proxy (SCP) domains.

30. The apparatus of claim 29, wherein the access token comprises one or more claims specifying at least one of: ones of the one or more SCP domains that the first network node is permitted to access; and ones of the one or more SCP domains that the first network node is not permitted to access.

31. The apparatus of claim 26, wherein the one or more target supported features comprise one or more resource-specific features for resources provided by the third network node.

32. The apparatus of claim 31, wherein the access token comprises one or more claims specifying ones of the one or more resource-specific features that the first network node is permitted to access.

33. A method comprising: providing, from a first network node in a communication system to a third network node in the communication system, a request for one or more services provided by the third network node, the request comprising an access token issued by a second network node in the communication system, the requested one or more services comprising at least one of one or more target domains and one or more target supported features; and receiving, at the first network node from the third network node, access to the requested one or more services responsive to verification of the access token, the access token comprising information indicating at least one of one or more target domains that the first network node is permitted to access and one or more target supported features that the first network node is permitted to access.

34. An article of manufacture comprising a non-transitory computer- readable storage medium having embodied therein executable program code that when executed by a processor operatively coupled to the computer-readable storage medium cause the processor to perform steps of: providing, from a first network node in a communication system to a third network node in the communication system, a request for one or more services provided by the third network node, the request comprising an access token issued by a second network node in the communication system, the requested one or more services comprising at least one of one or more target domains and one or more target supported features; and receiving, at the first network node from the third network node, access to the requested one or more services responsive to verification of the access token, the access token comprising information indicating at least one of one or more target domains that the first network node is permitted to access and one or more target supported features that the first network node is permitted to access.

35. An apparatus comprising: at least one processor; at least one memory including computer program code; the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to: receive, from a first network node in a communication system at a third network node in a communication system, a request for one or more services provided by the third network node, the request comprising an access token issued by a second network node in the communication system, the requested one or more services comprising at least one of one or more target domains and one or more target supported features; determine, at the third network node, whether the first network node is permitted to utilize said at least one of the one or more target domains and the one or more target supported features based at least in part on verifying the access token, the access token comprising information indicating at least one of one or more target domains that the first network node is permitted to access and one or more target supported features that the first network node is permitted to access; and provide, from the third network node to the first network node, access to the requested one or more services responsive to verification of the access token.

36. The apparatus of claim 35, wherein the first network node comprises a network function service consumer in a 5G communication system, the second network node comprises an authorization server in the 5G communication system, and the third network node comprises a network function service producer in the 5G communication system.

37. The apparatus of claim 35, wherein at least one of the first network node and the third network node comprises a Service Communication Proxy (SCP) in a 5G communication system.

38. The apparatus of claim 35, wherein the one or more target domains comprise one or more Service Communication Proxy (SCP) domains.

39. The apparatus of claim 38, wherein the access token comprises one or more claims specifying at least one of: ones of the one or more SCP domains that the first network node is permitted to access; and ones of the one or more SCP domains that the first network node is not permitted to access.

40. The apparatus of claim 35, wherein the one or more target supported features comprise one or more resource-specific features for resources provided by the third network node.

41. The apparatus of claim 40, wherein the access token comprises one or more claims specifying ones of the one or more resource-specific features that the first network node is permitted to access.

42. A method comprising: receiving, from a first network node in a communication system at a third network node in a communication system, a request for one or more services provided by the third network node, the request comprising an access token issued by a second network node in the communication system, the requested one or more services comprising at least one of one or more target domains and one or more target supported features; determining, at the third network node, whether the first network node is permitted to utilize said at least one of the one or more target domains and the one or more target supported features based at least in part on verifying the access token, the access token comprising information indicating at least one of one or more target domains that the first network node is permitted to access and one or more target supported features that the first network node is permitted to access; and providing, from the third network node to the first network node, access to the requested one or more services responsive to verification of the access token.

43. An article of manufacture comprising a non-transitory computer- readable storage medium having embodied therein executable program code that when executed by a processor operatively coupled to the computer-readable storage medium cause the processor to perform steps of: receiving, from a first network node in a communication system at a third network node in a communication system, a request for one or more services provided by the third network node, the request comprising an access token issued by a second network node in the communication system, the requested one or more services comprising at least one of one or more target domains and one or more target supported features; determining, at the third network node, whether the first network node is permitted to utilize said at least one of the one or more target domains and the one or more target supported features based at least in part on verifying the access token, the access token comprising information indicating at least one of one or more target domains that the first network node is permitted to access and one or more target supported features that the first network node is permitted to access; and providing, from the third network node to the first network node, access to the requested one or more services responsive to verification of the access token.