WO2021090171A1

WO2021090171A1 - Authorization in a service communication proxy

Info

Publication number: WO2021090171A1
Application number: PCT/IB2020/060318
Authority: WO
Inventors: Nagendra S Bykampadi; Suresh Nair; Anja Jerichow
Original assignee: Nokia Technologies Oy
Priority date: 2019-11-04
Filing date: 2020-11-03
Publication date: 2021-05-14

Abstract

Techniques for authorization in a service communication proxy in a communication system are provided. For example, a method comprises configuring a service communication proxy in a communication system to participate in an authorization process in the communication system by selectively setting a first parameter in the service communication proxy to enable the service communication proxy to participate. Further, when the service communication proxy is enabled to participate in the authorization process, the method may further configure the service communication proxy to prioritize a service communication proxy-based authorization or a network component-based authorization by selectively setting a second parameter in the service communication proxy to prioritize one authorization over the other authorization.

Description

AUTHORIZATION IN A SERVICE COMMUNICATION PROXY

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 authorization in a service communication proxy in a communication system.

For example, in one illustrative embodiment, a method comprises configuring a service communication proxy in a communication system to participate in an authorization process in the communication system by selectively setting a first parameter in the service communication proxy to enable the service communication proxy to participate.

Further, when the service communication proxy is enabled to participate in the authorization process, the method may further configure the service communication proxy to prioritize a service communication proxy-based authorization or a network component-based authorization by selectively setting a second parameter in the service communication proxy to prioritize one authorization over the other authorization.

By way of further example, when the first service communication proxy is enabled to participate in the authorization process and set to prioritize a network component-based authorization, the service communication proxy performs the steps of: receiving a request from a first network component in the communication system; determining a second network component in the communication system based on the received request; and sending a request to the second network component including an access token received with the request from the first network component.

Still further, when the first service communication proxy is enabled to participate in the authorization process and set to prioritize a service communication proxy-based authorization, the service communication proxy performs the steps of: receiving a request from a first network component in the communication system; determining a second network component in the communication system based on the received request; obtaining an access token for authorization of the first network component; and sending a request to the second network component including the obtained access token.

In another example, even when the service communication proxy is set to prioritize a service communication proxy-based authorization, the service communication proxy can use an access token obtained in the request from the first network component rather than obtaining a new access token.

Further, in yet another example, the service communication proxy can also dynamically decide to obtain an access token even when it receives an access token from the first network component.

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

FIG. 2 illustrates network elements/functions for providing authorization in a service communication proxy with which one or more illustrative embodiments may be implemented.

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

FIG. 4 illustrates indirect communication between network functions or elements within a public land mobile network with multiple service communication proxies, according to one or more illustrative embodiments.

FIG. 5 illustrates a methodology for authorization in a service communication proxy, according to an illustrative embodiment. FIG. 6 illustrates a methodology for authorization in a service communication proxy, according to another illustrative embodiment.

Detailed Description

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for authorization in a service communication proxy 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. 1 shows a communication system 100 within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system 100 are intended to represent 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. 1 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. 1. 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 arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements/functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

It is also to be noted that while FIG. 1 illustrates system elements as singular functional blocks, the various subnetworks that make up the 5G network are partitioned into so-called network slices. Network slices (network partitions) 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.

FIG. 2 is a block diagram of network elements/functions for providing authorization in a service communication proxy in a communication system in an illustrative embodiment. System 200 is shown comprising a first network element/function 202 and a second network element/function 204. It is to be appreciated that the network elements/functions 202 and 204 represent any network elements/functions 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 element/function 202 and the second network element/function 204 may also represent a Service Communication Proxy (SCP) element, which will be described in further detail below.

The network element/function 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. The processor 212 of the network element/function 202 includes an authorization management 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 authorization in a service communication proxy as described in conjunction with subsequent figures and otherwise herein. The memory 216 of the network element/function 202 includes an authorization management storage module 218 that stores data generated or otherwise used during service communication proxy operations.

The network element/function 204 comprises a processor 222 coupled to a memory 226 and interface circuitry 220. The processor 222 of the network element/function 204 includes an authorization management 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 authorization in a service communication proxy as described in conjunction with subsequent figures and otherwise herein. The memory 226 of the network element/function 204 includes an authorization management storage module 228 that stores data generated or otherwise used during service communication proxy operations.

The processors 212 and 222 of the respective network elements/functions 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 elements/functions 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, authorization management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 212 and 222.

A given one of the memories 216 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 elements/functions 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 element/function 202 is configured for communication with network element/function 204 and vice-versa via their respective interface circuitries 210 and 220. This communication involves network element/function 202 sending data to the network element/function 204, and the network element/function 204 sending data to the network element/function 202. However, in alternative embodiments, other network elements may be operatively coupled between the network elements/functions 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 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 elements/functions 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 element/function 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 (SBA). FIG. 3 illustrates a general 5G SBA implementation 300 as further described in 3GPP TS 23.501. Note that the network elements/functions in FIG. 3 are the same or similar to those described above in the context of FIGS. 1 and 2. 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 a 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 the service 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. More particularly, Annex E describes multiple communications models (direct and indirect) for NF/NF service interaction as follows:

Model A - Direct communication without NRF interaction: Neither NRF nor SCP are used. Consumers are configured with producers’ “NF profiles” and directly communicate with a producer of their choice.

Model B - Direct communication with NRF interaction: Consumers do discovery by querying the NRF. Based on the discovery result, the consumer does the selection. The consumer sends the request to the selected producer.

Model C - Indirect communication without delegated discovery: Consumers do discovery by querying the NRF. Based on the discovery result, the consumer does the selection of an NF Set or a specific NF instance of an NF instance set. The consumer sends the request to the SCP containing the address of the selected service producer pointing to an NF service instance or a set of NF service instances. In the latter case, the SCP selects an NF Service instance. If possible, the SCP interacts with the NRF to get selection parameters such as location, capacity, etc. The SCP routes the request to the selected NF service producer instance.

Model D - Indirect communication with delegated discovery: Consumers do not do any discovery or selection. The consumer adds any necessary discovery and selection parameters required to find a suitable producer to the service request. The SCP uses the request address and the discovery and selection parameters in the request message to route the request to a suitable producer instance. The SCP can perform discovery with an NRF and obtain a discovery result.

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.

Thus, it is realized that a communication system such as the 5G SB A could potentially allow two authorization methods:

1. Rel-15 method which is based on authorization by the NF; and

2. An additional Rel-16 method which is based on authorization by SCP (delegated authorization).

However, it is realized herein that when both authorization methods are specified in Rel-16, there will be two methods that will be available for NFs and SCPs to use when model D is used for communicating between NFs. The issue is how do the NFs and SCPs know which one to use. An operator might want to change the mechanism from Rel-15 to Rel-16, in which case there needs to be an update mechanism available. Illustrative embodiments address these and other issues related to authorization method selection.

FIG. 4 depicts a 5G SBA scenario where authorization in an SCP can be implemented. More particularly, FIG. 4 illustrates an intra-Public Land Mobile Network (PLMN) inter-SCP scenario. In this scenario, the NF Service Consumer or NFc 402 and NF Service Producer or NFp 404 are in a same PLMN 400. The NFc 402 is connected to SCP-c 406-1 and the NFp 404 is connected to SCP-p 406-2. The SCP-c 406-1 is connected to NRF1 408-1 and the SCP- p 406-2 is connected to NRF2 408-2. The SCP-c 406-1 and SCP-p 406-2 are also connected to one another. This scenario is equivalent to the above-mentioned Model D since the NF service consumer instance (NFc 402) uses the SCP (SCP-c 406-1) for delegated routing of NF requests to the selected NF service producer instance (NFp 404), 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 406-1 in FIG. 4). 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 (402) is unaware and not impacted.

Before describing illustrative message flows in FIGS. 5 and 6, SCP-based authorization according to illustrative embodiments is generally described as follows: a) 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). b) If authorization is enabled in an SCP on the consumer side (SCP-c 406-1 in FIG. 4):

• In scenarios where the NF service consumer (NFc 402) is in possession of an active/valid access token from its previous execution of an access token request (e.g., when it was using Model C or other non-model D scenarios), the NF service consumer may decide to use that access token in the service request. The SCP-c decides whether to use this access token or not: o Under certain conditions (examples discussed below), if the SCP-c decides not to use the access token received from NFc, the SCP-c obtains a new access token from NRF (NRF1 408-1) after discovery/selection procedure is executed. o If SCP-c decides to use the access token provided by NF-c, SCP-c uses it when forwarding the service request to the selected NF producer (NFp 404) (after discovery/selection procedure). o SCP-c may report back, in the service response message to NFc, the access token used.

• When NF-c issues a service request without any access token, the SCP-c obtains an access token from the associated NRF (NRF1 408-1) once the producer is selected.

• The access token may also be cached in SCP-c for future use. c) If authorization is disabled on the consumer side, this means it is assumed that the NF will obtain the access token and perform necessary verification on the producer side.

• SCP only performs discovery/selection and reuses an access token coming from NF-c.

• This is the Rel-15 mechanism.

As mentioned above, under certain conditions, the SCP-c decides not to use the access token from the NFc. For example, such conditions can include but are not limited to: i) If an NFc already has an active token, there is usually no reason to neglect that and get a new token in SCP. Flowever, there could be cases where the active token is going to expire soon, or the token is issued by an NRF that is currently disabled for some reason and the SCP can decide that it is better to get a new token from an (new) NRF. ii) Applicability of the access token can change - it could be for a specific NFc instance, but the SCP decides to make it applicable for a group of NFc instances (e.g., an NF Set). This requires it to obtain a new token for the required level/granularity. iii) SCP functionality is not fully specified in 3GPP. There could be implementation of load balancing of NF producers. In this case, a new access token may be required.

The decision by the SCP to obtain a new access token could be for many other factors, which are dynamically determined during implementation.

The behavior of the SCP on the producer side (SCP-p 406-2 in FIG. 4) is as proposed in TR 33.855 clause 6.21: a) If authorization is enabled on the producer side (SCP-p 406-2), SCP-p 406-2 executes access token verification procedure, which is the existing Rel-16 procedure. b) If authorization is disabled on the producer side, SCP-p 406-2 forwards the service request to NF producer (NFp 404).

Illustrative embodiments of the above-described SCP-based authorization method selection will be further described below in the context of the following parts:

Part 1 : Configuration parameters in SCP

SCP (consumer side SCP-c, the SCP associated with the NF service consumer) is configured with the following information: la) Selectable parameter enabling or disabling authorization in SCP

• When enabled, the SCP on the consumer side initiates an access token request to obtain an access token from its NRF (OAuth server), the SCP on the producer side (SCP-p) verifies the access token it receives from the consumer side. Note that the authorization process used in illustrative embodiments can be OAuth 2.0 authorization. However, other authorization processes can be employed.

• When disabled, the NF consumer is responsible for obtaining an access token from the NRF and the NF producer is responsible for verifying the access token. lb) Selectable parameter whether to prioritize SCP-based authorization over NF-based authorization, or vice versa.

By default, when authorization is enabled in the SCP (see la above), the SCP performs authorization on behalf of the NF.

However, there may be cases where the operator may need additional control and prioritize NF-based authorization over SCP-based authorization (while keeping authorization in SCP enabled).

When the SCP-based authorization has priority over NF-based authorization, the SCP obtains a new access token instead of using the access token it (may) receive(s) from the NF consumer.

When the NF has priority over SCP-based authorization, the SCP reuses the access token supplied by the NF consumer, and delegates verification. lc) OAuth server contact information

If required, the SCP may be configured with the Internet Protocol (IP) address or the fully qualified domain nameFQDN of the OAuth server (i.e., the NRF that is also playing the role of the OAuth server). Id) Whether to cache access tokens

While the SCP is a stateless entity that does not necessarily cache access tokens, there may be deployments where it is useful for the SCP to cache access tokens on behalf of the NF consumer.

Part 2: Authorization is enabled in an SCP-c. but it reuses the access token it receives from the NFc

As discussed above in Part lb, when NF-based authorization has priority over SCP- based authorization, the SCP-c uses the access token provided by the NF consumer.

FIG. 5 depicts this scenario in methodology 500. As shown, the message flow comprises NFc 502, SCP-c 504, SCP-p 506 and NFp 508. It is assumed that the SCPs on both the consumer side (SCP-c 504) and the producer side (SCP-p 506) are configured to have authorization enabled (step 510) and prioritize NF authorization over its own (step 512). This configuration is selected by parameters depicted in the SCPs 504 and 506. Note that any SCP can be on a consumer side in one case and a producer side in another case, thus such selectable parameters are present in each SCP.

SCP-c 504 receives an access token in an NF Service request from NFc 502 in step 514. In step 516, SCP-c 504 performs discover and selection of an appropriate NF service producer, assumed in this example to be NFp 508. SCP-c 504 reuses (518) the access token obtained from NFc 502, and sends the access token in an NF Service request to SCP-p 506 in step 520. SCP-p 506 forwards (522) the access token in an NF Service request to NFp 508 in step 524 for verification and processing. NFp 508 performs access token verification in step 526. If verified, NFc 502 is given access to whatever the requested service is via NFp 508.

Part 3: Authorization is enabled in an SCP and it obtains a new access token from the NRF once the producer is determined

In the following scenario, the SCPs on both the consumer side and the producer side are configured to prioritize SCP-based authorization over NF-based authorization. This configuration is selected by parameters depicted in the SCPs (604 and 606 in FIG. 6 to be discussed below). Again, note that any SCP can be on a consumer side in one case and a producer side in another case, thus such selectable parameters are present in each SCP. In this configuration, SCP-c obtains a new access token once it selects an appropriate NF producer/NF Set.

Likewise. SCP-p verifies the access token before forwarding the request to NF producer. FIG. 6 depicts this new access token scenario in methodology 600. As shown, the message flow comprises NFc 602, SCP-c 604, SCP-p 606, NRF (OAuth server) 607 and NFp 608. It is assumed that the SCPs on both the consumer side (SCP-c 604) and the producer side (SCP-p 606) are configured to have authorization enabled (step 610) and prioritize SCP-based authorization over NF-based authorization (step 612).

SCP-c 604 receives an Access Token 1 in an NF Service request from NFc 602 in step 614. In step 616, SCP-c 604 performs discover and selection of an appropriate NF service producer, assumed in this example to be NFp 608. SCP-c 604 (in step 618), based on its configuration in step 612, obtains a new access token from NRF 607 (step 620), and sends the new access token (Access Token 2) in an NF Service request to SCP-p 606 in step 622. SCP- p 606, as per step 612, performs verification of Access Token 2 in step 624. If verified, an NF Service request is sent from SCP-p 606 to NFp 608 in step 626. NFc 602 is given access to the requested service via NFp 608.

Note that illustrative embodiments also comprise a scenario where SCP-c 604 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 602. 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.

The particular processing operations and other system functionality described in conjunction with the message flow diagrams of FIGS. 5 and 6 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 configured to, with the at least one processor, cause the apparatus to implement a service communication proxy in a communication system, the service communication proxy being configured to participate in an authorization process in the communication system when a first parameter in the service communication proxy is selectively set to enable the service communication proxy to participate.

2. The apparatus of claim 1, wherein, when the service communication proxy is enabled to participate in the authorization process, the service communication proxy is further configured to prioritize a service communication proxy-based authorization or a network component-based authorization when a second parameter in the service communication proxy is selectively set to prioritize one authorization over the other authorization.

3. The apparatus of claim 2, wherein, when the first service communication proxy is enabled to participate in the authorization process and set to prioritize a network component-based authorization, the service communication proxy is further configured to: receive a request from a first network component in the communication system; determine a second network component in the communication system based on the received request; and send a request to the second network component including an access token received with the request from the first network component.

4. The apparatus of claim 2, wherein, when the first service communication proxy is enabled to participate in the authorization process and set to prioritize a service communication proxy-based authorization, the service communication proxy is further configured to: receive a request from a first network component in the communication system; determine a second network component in the communication system based on the received request; obtain an access token for authorization of the first network component; and send a request to the second network component including the obtained access token.

5. The apparatus of claim 4, wherein the service communication proxy is further configured to obtain the access token for authorization of the first network component from a third network component.

6. The apparatus of claim 4, wherein the service communication proxy is further configured to report the obtained access token to the first network component.

7. The apparatus of claim 4, wherein the first service communication proxy is further configured to store the obtained access token for subsequent use.

8. The apparatus of claim 2, wherein, when the first service communication proxy is enabled to participate in the authorization process and set to prioritize a service communication proxy-based authorization, the service communication proxy is further configured to: receive a request from a first network component in the communication system; determine a second network component in the communication system based on the received request; and send a request to the second network component including an access token received with the request from the first network component.

9. The apparatus of claim 2, wherein, when the first service communication proxy is enabled to participate in the authorization process, the service communication proxy is further configured to: receive a request from a network component in the communication system; determine one or more target network components in the communication system based on the received request; obtain an access token for authorization of the one or more target network components; and send a request to at least one of the one or more target network components including the obtained access token.

10. The apparatus of claim 1, wherein the first network component is a service consumer function requesting authorization to access a service producer function.

11. A method comprising: configuring a service communication proxy in a communication system to participate in an authorization process in the communication system by selectively setting a first parameter in the service communication proxy to enable the service communication proxy to participate.

12. The method of claim 11, wherein, when the service communication proxy is enabled to participate in the authorization process, further configuring the service communication proxy to prioritize a service communication proxy-based authorization or a network component- based authorization by selectively setting a second parameter in the service communication proxy to prioritize one authorization over the other authorization.

13. The method of claim 12, wherein, when the first service communication proxy is enabled to participate in the authorization process and set to prioritize a network component-based authorization, the service communication proxy performs the steps of: receiving a request from a first network component in the communication system; determining a second network component in the communication system based on the received request; and sending a request to the second network component including an access token received with the request from the first network component.

14. The method of claim 12, wherein, when the first service communication proxy is enabled to participate in the authorization process and set to prioritize a service communication proxy-based authorization, the service communication proxy performs the steps of: receiving a request from a first network component in the communication system; determining a second network component in the communication system based on the received request; obtaining an access token for authorization of the first network component; and sending a request to the second network component including the obtained access token.

15. The method of claim 14, wherein the service communication proxy obtains the access token for authorization of the first network component from a third network component.

16. The method of claim 14, wherein the service communication proxy further performs the step of reporting the obtained access token to the first network component.

17. The method of claim 14, wherein the first service communication proxy further performs the step of storing the obtained access token for subsequent use.

18. The method of claim 12, wherein, when the first service communication proxy is enabled to participate in the authorization process and set to prioritize a service communication proxy-based authorization, the service communication proxy performs the steps of: receiving a request from a first network component in the communication system; determining a second network component in the communication system based on the received request; and sending a request to the second network component including an access token received with the request from the first network component.

19. The method of claim 12, wherein, when the first service communication proxy is enabled to participate in the authorization process, the service communication proxy performs the steps of: receiving a request from a network component in the communication system; determining one or more target network components in the communication system based on the received request; obtaining an access token for authorization of the one or more target network components; and sending a request to at least one of the one or more target network components including the obtained access token.