WO2020254925A1

WO2020254925A1 - Policy-based authorization for indirect communications between network functions in a communication system

Info

Publication number: WO2020254925A1
Application number: PCT/IB2020/055505
Authority: WO
Inventors: Nagendra Bykampadi; Suresh Nair; Anja Jerichow
Original assignee: Nokia Technologies Oy
Priority date: 2019-06-15
Filing date: 2020-06-11
Publication date: 2020-12-24

Abstract

In a communication system wherein a first service communication proxy element is coupled to a first network function, a method includes receiving at the first service communication proxy element a request from a second network function of the communication system for one or more services provided by the first network function. The method also includes determining, at the first service communication proxy element, a network function type of the second network function. The method further includes authorizing, by the first service communication proxy element, access by the second network function to one or more services provided by the first network function based at least in part on the network function type of the second network function.

Description

POLICY-BASED AUTHORIZATION FOR INDIRECT COMMUNICATIONS BETWEEN NETWORK FUNCTIONS IN A COMMUNICATION SYSTEM

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 or N3IWF or TNGF or W-AGF depending on the type of 5G Access Network: supporting NR radio defined by 3GPP, supporting an Untrusted Non 3GPP access to 5GC, supporting a Trusted Non 3GPP access to 5GC (5G Core) or supporting a Wireline access to 5GC) 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.0.2, 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 or N3IWF or TNGF or W-AGF depending on the type of 5G Access Network) 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, V15.4.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 improved techniques for policy-based authorization of indirect communications between network functions or elements in communication systems.

For example, in one illustrative embodiment, a method comprises the following steps. In a communication system comprising a first service communication proxy element coupled to a first network function, the method comprises receiving at the first service communication proxy element a request from a second network function of the communication system for one or more services provided by the first network function. The method also comprises determining, at the first service communication proxy element, a network function type of the second network function. The method further comprises authorizing, by the first service communication proxy element, access by the second network function to one or more services provided by the first network function based at least in part on the network function type of the second network function.

Authorizing access by the second network function to the one or more services provided by the first network function may comprise utilizing a set of policy files defining how resources and data managed by the one or more services provided by the first network function are accessed by one or more other network functions.

The first service communication proxy element may be provisioned with (i) one or more policy files specifying permissions for how one or more resources of one or more services of the first network function can be accessed and (ii) one or more permission-to- network function type binding policy files specifying a set of rules for binding network function types to one or more permissions.

Further illustrative embodiments are provided in the form of 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 policy-based authorization for indirect communications with which one or more illustrative embodiments may be implemented.

FIG. 3 illustrates direct communication between network functions or elements in a communication system and indirect communication between network functions or elements through a service communication proxy, according to one or more illustrative embodiments.

FIG. 4 illustrates indirect communication between network functions or elements in a communication system with discovery and selection delegated to the service communication proxy, according to one or more illustrative embodiments.

FIG. 5 illustrates indirect communication between network functions or elements in a communication system with routing by the service communication proxy, according to one or more illustrative embodiments. FIG. 6 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. 7 illustrates indirect communication between network functions or elements within a public land mobile network using a single service communication proxy, according to one or more illustrative embodiments.

FIG. 8 illustrates indirect communication between network functions or elements in two different public land mobile networks with multiple service communication proxies, according to one or more illustrative embodiments.

FIG. 9 illustrates policy-based service access authorization of a network function consumer using service communication proxies and a policy database, according to one or more illustrative embodiments.

FIG. 10 illustrates policy-based service access authorization for an access and mobility management network function, according to one or more illustrative embodiments.

FIG. 11 illustrates a methodology for policy-based service access authorization of network elements or functions using one or more service communication proxies, according to one or more illustrative embodiments.

Detailed Description

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for policy-based authorization of indirect communications between network functions or elements 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 femto 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.

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 policy-based authorization for indirect communication between network functions of 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 policy-based authorization for indirect communications 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 policy-based authorization management for indirect communications 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 policy-based authorization management 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 policy-based authorization management for indirect communications 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 policy-based authorization management 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, policy-based 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.

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.

Given the general concepts described above, illustrative embodiments that address certain authorization management issues will now be described. More particularly, illustrative embodiments provide authorization management techniques 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).

3GPP Release 16 of TS 23.501 introduces what is referred to as an indirect communication model in which network functions (NFs) communicate via a 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.

FIG. 3 illustrates direct communication 300 between NFs 302 and 304, as well as indirect communication 305 between the NFs 302 and 304 via a SCP 306. Various communication models or architectural options may be used for indirect communication 305 between the NFs 302 and 304 via the SCP 306. One such model, referred to as Model D in Release 16 of 3GPP TS 23.501, has NFs implement application logic with non-application logic (e.g., including discovery of a target NF, selection of a target NF from a list of available NFs, etc.) delegated to the SCP.

Model D may be contrasted with Model C, where the NF Consumer selects an NF instance or a specific NF instance and sends a request to the SCP containing the address of the selected NF Service Producer pointing to a NF service instance or a set of NF service instances. The SCP selects the NF service instance, if not already selected by the NF Service Consumer, and routes the request to the selected NF Service Producer instance. In Model D, discovery and associated selection is delegated to an SCP using discovery and selection parameters in a service request with routing via the SCP. The NF Service Consumer in Model D does not do any discovery or selection, and instead adds any necessary discovery and selection parameters required to find a suitable NF Service Producer to service a request. The SCP uses the request address, as well as any discovery and selection parameters provided in the request message, to route the request to a suitable NF Service Producer instance. The SCP can perform discovery with an NRF and obtain a discovery result.

FIG. 4 illustrates the Model D communication model 400, where a NF Service Consumer 402 provides a service request and discovery and selection parameters to a SCP 406. The SCP 406 uses the provided parameters to communicate with an NRF 408 to select and route the request from the NF Service Consumer 402 to the NF Service Producer 404 instance. Responses and subsequent requests may then be passed between the NF Service Consumer 402 and NF Service Producer 404 via the SCP 406.

FIG. 5 illustrates the Model C communication model 500, where a NF Service Consumer 502 sends a discovery request to NRF 508 and receives NF profiles. The NF Service Consumer 502 utilizes the NF profiles to generate a NF Service Request that is provided to the SCP 506. The SCP 506 routes the service request to the NF Service Producer 504. Responses and subsequent requests may then be passed between the NF Service Consumer 402 and NF Service Producer 404 via the SCP 406.

Additional details regarding communication models for NF and NF services interaction, including Model C and Model D discussed above, are described in Annex E of 3GPP TS 23.501.

As noted above, 3GPP TS 23.501 Release 16 of 5G SBA introduces the architectural model for service communication referred to as Model D. In this model, the functionality of target NF discovery, target NF selection based on load balancing, etc., are delegated to a common NF called the SCP. Model D is based on indirect communication between NFs. In other words, the NFs do not directly communicate with each other. This includes interactions between a NF and the NRF. The result is that OAuth-based service access authorization, described in clause 1.4 of 3GPP TS 33.501 Release 15, does not work. The OAuth client authentication is based on underlying Transport Layer Security (TLS) between the OAuth Client (e.g., a NF Service Consumer or NFc) and an OAuth Server (e.g., the NRF). This, however, is no longer possible with Model D. In 3GPP TS 33.501 Release 15, the OAuth Client or NFc directly obtains an access token from the NRF, once it discovers and selects which target NF Producer(s) or NFp(s) it uses to obtain a desired service. In Model D, the discovery and selection of the target NFp(s) are delegated to the SCP. Therefore, the NFc cannot obtain access tokens directly. The OAuth service access authorization solution therefore will not work for indirect communication where one or more SCPs are present such as in the Model D architectural option.

For direct communication models, an NF may use NRF APIs to obtain an OAuth 2.0 JavaScript Object Notation (JSON) Web Token (JWT)-based access token and perform self validation of the access token as described in clause 13.4 of 3GPP TS 33.501 Release 15. 3GPP TR 33.844 also describes use of an OAuth-based service access authorization for indirect communications.

Illustrative embodiments provide techniques for implementing policy-based service access authorization for indirect communication between NFs in a 5G or other communication system. In some embodiments, the NF Service Producer offloads authorization of NF Service Consumer requests to the SCP that the NF Service Producer is connected to. The SCP is configured with a set of policy files that define how resources and data managed by services within the NF Service Producer are accessed by other NFs such as the NF Service Consumer. When a request from the NF Service Consumer comes to the SCP connected to the NF Service Producer, an authorization function in the SCP evaluates the request against current authorization policies and returns an authorization result (e.g., ALLOW or DENY). The SCP then applies appropriate treatment to the request. If the authorization result is ALLOW, the SCP forwards the request to the NF Service Producer.

The policy-based service access authorization for indirect communication between NFs may be utilized in various different application scenarios, examples of which will now be described with respect to FIGS. 6-8.

FIG. 6 illustrates an intra-Public Land Mobile Network (PLMN) inter-SCP scenario. In this scenario, the NF Service Consumer or NFc 602 and NF Service Producer or NFp 604 are in a same PLMN 600. The NFc 602 is connected to SCPc 606-1 and the NFp 604 is connected to SCPp 606-2. The SCPc 606-1 is connected to NRF 608-1 and the SCPp 606-2 is connected to NRF 608-2. The SCPc 606-1 and SCPp 606-2 are also connected to one another.

FIG. 7 illustrates an intra-PLMN intra-SCP scenario. In this scenario, the NF Service Consumer or NFc 702 and NF Service Producer or NFp 704 are in a same PLMN 700 and are connected to a same SCP 706. The SCP 706 is connected to NRF 708.

FIG. 8 illustrates an inter-PLMN roaming scenario. In this scenario, the NF Service Consumer or NFc 802 is in a first PLMN 800-1 and the NF Service Producer or NFp 804 is in a second PLMN 800-2. The NFc 802 is connected to SCPc 806-1 and the NFp 804 is connected to SCPp 806-2. The SCPc 806-1 is connected to NRF 808-1 and the SCPp 806-2 is connected to NRF 808-2. The SCPc 806-1 and SCPp 808-1 are connected to one another via respective Security Edge Protection Proxies (SEPPs) 810-1 and 810-2 in the PLMNs 800- 1 and 800-2. The SEPPs 810-1 and 810-2 communicate over a roaming inter-network interface (e.g., an N32 interface) between the PLMNs 800-1 and 800-2, such as via Inter network Packet exchange (IPX) providers 812. In 5G SB A, the PLMN operator deploys a SEPP at the edge of its network to interoperate and obtain services from network functions in its roaming partner networks. The SEPP interfaces with one or more other SEPPs in one or more other networks over the N32 interface.

The SCP(s) in some embodiments are provisioned (e.g., by a Mobile Network Operator (MNO)) so as to configure the SCP(s) with policy files that allow the SCP connected with a NF Service Producer to authorize incoming NF Service Consumer requests. This allows the NF Service Producer to recognize an incoming service request from the NF Service Consumer, and to determine whether to allow the request and which services can be allowed for the requesting NF Service Consumer.

FIG. 9 illustrates a processing flow for policy-based service access authorization of a NF Service Consumer or NFc 902 requesting services from a NF Service Producer or NFp 904. The NFc 902 and NFp 904 are connected to respective SCPs, SCPc 906-1 and SCPp

906-2. The SCPp 906-2 is connected to a policy database 914. In step 1, the NFc 902 of a certain NF type is invoking an API request on the selected target NFp 904. The message is routed via SCPc 906-1. In step 2, the SCPc 906-1 routes the message to a peer SCPp 906-2 that is proxying on behalf of the NFp 904. In step 3, the SCPp 906-2 associated with the NFp 904 checks if the NF type to which the NFc 902 belongs is authorized to obtain services from the NFp 904. In step 4, if the NFc 902 is authorized, the SCPp 906-2 forwards the API request to the NFp 904. In step 5, the NFp 904 provides the requested services to the NFc 902, with message routing performed by the SCPc 906-1 and SCPp 906-2.

The policy database 914 is provisioned with a set of policy files needed for the SCPp 906-2 to authorize the NFc 902. The set of policy files may include multiple sets of information, including permissions and permissions-to-NF type binding information. The permissions define how resources within a particular service belonging to the NFp 904 can be accessed. This refers to the resources managed by a service and sets of operations that can be performed on them (e.g., Create, Delete, etc.). For example, Table 1 below provides a list of available resources and applicable FlyperText Transfer Protocol (HTTP) methods for an AUSF’s UE-authentication service (Nausf_UEAuthentication).

Table 1: AUSF UE- Authentication Service Resources

The POST operation used to provide the EAP response to the AUSF in a sub-resource (Document) is generated by the first POST operation. As this operation is not idempotent (e.g., it triggers subsequent EAP operations), a PUT is not adequate.

The permissions policy file in some embodiments is a repository for all resources along with the applicable operations.

Permissions-to-NF type binding information binds NF Service Consumers to permissions. The permissions-to-NF type binding information may be part of a policy file that dictates, for each NF type: (i) which resources a NF of that NF type can access within the NF Service Producer; and (ii) applicable operations of the NF Service Producer that can be performed. Using an Attribute Based Access Control (ABAC) method, the combination of the permissions policy file and permissions-to-NF type binding policy file specifies which NF Service Consumer is allowed to do what in a NF Service Producer. This approach can be used for both Model C and Model D indirect communication options described above in which a SCP is used between NFs.

FIG. 10 illustrates a policy-based service access authorization flow for an AMF 1002 (e.g., an example of a NF Service Consumer) accessing services of an AUSF 1004 (e.g., an example of a NF Service Producer). SCPc 1006-1 and SCPp 1006-2 are used for authorization of the AMF 1002 on behalf of the AUSF 1004. FIG. 10 depicts a scenario where the AMF 1002 is initiating an authentication process in the AUSF 1004 using the POST HTTP method or operation on the“/ue-authentications” resources in the AUSF 1004’s Nausf_UEAuthentication service.

In step 1, the NF Service Consumer or AMF 1002 sends a POST request to the AUSF 1004’s authentication resource, as pointed to be the resource uniform resource identifier (URI)“//{apiRoot}/nausf-auth/vl/ue-authentications”. The POST HTTP method is used to initiate the authentication process in AUSF 1004. While FIG. 10 depicts an example of indirect communication in the Model C scenario, if the indirect communication were in the Model D scenario the AMF 1002 sends a POST request without selecting the AUSF 1004 instance and the SCPs 1006-1 and 1006-2 discover and select an appropriate AUSF instance to process the service request.

In step 2, the SCPc 1006-1 connected to the AMF 1002 routes the message to the SCPp 1006-2 proxying the AUSF 1004. As noted above, FIG. 10 depicts an example of indirect communication in the Model C scenario. If the indirect communication were in the Model D scenario, the SCPc 1006-1 first discovers appropriate AUSF instances that can service the AMF 1002’s request and selects one AUSF instance (e.g., AUSF 1004). The SCPc 1006-1 would then route the message to the SCPp 1006-2 proxying the selected AUSF instance 1004.

In step 3, the SCPp 1006-2 refers to the permissions-to-NF type binding policy file to check if the AMF 1002 is authorized to perform the requested POST operation on the ue- authentications resource.

In steps 4 and 5, if the service request from the AMF 1002 is allowed, the SCPp 1006- 2 forwards the POST method to AUSF 1004.

In step 6, the service between the AMF 1002 and AUSF 1004 takes place.

FIG. 11 illustrates a methodology 1100 for policy-based service access authorization of network elements or functions using one or more service communication proxies. The methodology 1100 is assumed to be performed by a first service communication proxy element (e.g., SCP 306, SCP 406, SCP 506, SCPp 606-2, SCP 706, SCPp 806-2, SCPp 906- 2, SCPp 1006-2) that is coupled to a first network function (e.g., NF B 304, NF Service Producer 404, NF Service Producer 504, NFp 604, NFp 704, NFp 804, NFp 904, AUSF 1004) in a communication system (e.g., a 5G communication system). The methodology 1100 comprises, in step 1102, receiving at the first service communication proxy element a request from a second network function (e.g., NF A 302, NF Service Consumer 402, NF Service Consumer 502, NFc 602, NFc 702, NFc 802, NFc 902, AMF 1002) of the communication system for one or more services provided by the first network function.

In step 1104, the first service communication proxy element determines a network function type of the second network function. The first service communication proxy element in step 1106 authorizes access by the second network function to one or more services provided by the first network function based at least in part on the network function type of the second network function. In some embodiments, the first service communication proxy element in step 1106 is configured to authorize access by the second network function to the one or more services provided by the first network function utilizing a set of policy files defining how resources and data managed by the one or more services provided by the first network function are accessed by one or more other network functions.

The first service communication proxy element may be provisioned with one or more policy files specifying permissions for how one or more resources of one or more services of the first network function can be accessed. A given one of the permissions specifies a set of operations that can be performed on a given one of the resources of a given one of the services of the first network function. The first service communication proxy element may be provisioned with one or more permission-to-network function type binding policy files specifying a set of rules for binding network function types to one or more permissions. A given one of the set of rules specifies, for a given network function type: (i) at least a given one of the one or more resources of a given one of the one or more services of the first network function that other network functions of the given type have permission to access; and (ii) one or more operations that the other network functions of the given type have permission to perform on the given resource of the given service of the first network function.

The request from the second network function may be received at the first service communication proxy element from a second service communication proxy element (e.g., SCPc 606-1, SCPc 806-1, SCPc 906-1, SCPc 1006-1) associated with the second network function. The first service communication proxy element and the second service communication proxy element may be located in a same public land mobile network of the communication system (e.g., as illustrated in FIG. 6 described above). In other embodiments, the first service communication proxy element and the first network function are located in a first public land mobile network of the communication system and the second service communication proxy element and the second network function are located in a second public land mobile network of the communication system (e.g., as illustrated in FIG. 8 described above).

In some embodiments, the first service communication proxy element is further configured to route one or more messages to the first network function for providing the requested service.

The request received in step 1102 may specify a designated instance of the first network function. For example, the request may comprise an address of the designated instances of the first network function. In other embodiments, the request received in step 1102 delegates selection of an instance of the second network function to the first service communication proxy element, such as where the first service communication proxy element is also connected to the second network function (e.g., SCP 706). In other embodiments, the request from the second network function delegates selection of an instance of the first network function to a second service communication proxy element (e.g., SCPc 606-1, SCPc 806-1, SCPc 906-1, SCPc 1006-1) connected to the second network function. The service communication proxy element to which selection has been delegated may be further configured to identify the first network function from the received request, to discover one or more instances of the first network function, and to select a given one of the discovered instances of the first network function for processing the received request.

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 coupled to a memory and configured to implement a first service communication proxy element of a first network in a communication system, the first service communication proxy element being operatively coupled to a first network function of the communication system;

the first service communication proxy element being configured:

to receive a request from a second network function of the communication system for one or more services provided by the first network function;

to determine a network function type of the second network function;

to authorize access by the second network function to one or more services provided by the first network function based at least in part on the network function type of the second network function.

2. The apparatus of claim 1, wherein the first service communication proxy element is configured to authorize access by the second network function to the one or more services provided by the first network function utilizing a set of policy files defining how resources and data managed by the one or more services provided by the first network function are accessed by one or more other network functions.

3. The apparatus of claim 1, wherein the first service communication proxy element is provisioned with one or more policy files specifying permissions for how one or more resources of one or more services of the first network function can be accessed.

4. The apparatus of claim 3, wherein a given one of the permissions specifies a set of operations that can be performed on a given one of the resources of a given one of the services of the first network function.

5. The apparatus of claim 3, wherein the first service communication proxy element is provisioned with one or more permission-to-network function type binding policy files specifying a set of rules for binding network function types to one or more permissions.

6. The apparatus of claim 5, wherein a given one of the set of rules specifies, for a given network function type:

at least a given one of the one or more resources of a given one of the one or more services of the first network function that other network functions of the given type have permission to access; and

one or more operations that the other network functions of the given type have permission to perform on the given resource of the given service of the first network function.

7. The apparatus of claim 1, wherein the request from the second network function is received at the first service communication proxy element from a second service communication proxy element associated with the second network function.

8. The apparatus of claim 7, wherein the first service communication proxy element and the second service communication proxy element are located in a same public land mobile network of the communication system.

9. The apparatus of claim 7, wherein the first service communication proxy element and the first network function are located in a first public land mobile network of the communication system and the second service communication proxy element and the second network function are located in a second public land mobile network of the communication system.

10. The apparatus of claim 1, wherein the first service communication proxy element is further configured to route one or more messages to the first network function for providing the requested service.

11. The apparatus of claim 1, wherein the request specifies a designated instance of the first network function.

12. The apparatus of claim 1, wherein the request from the second network function delegates selection of an instance of the first network function to the first communication proxy element, the first communication proxy element being connected to the second network function.

13. The apparatus of claim 1, wherein the request from the second network function delegates selection of an instance of the first network function to a second service communication proxy element connected to the second network function.

14. The apparatus of claim 13, wherein the second service communication proxy element is further configured:

to identify the first network function from the received request;

to discover one or more instances of the first network function; and

to select a given one of the discovered instances of the first network function for processing the received request.

15. A method comprising :

in a communication system comprising a first service communication proxy element coupled to a first network function, receiving at the first service communication proxy element a request from a second network function of the communication system for one or more services provided by the first network function;

determining, at the first service communication proxy element, a network function type of the second network function; and

authorizing, by the first service communication proxy element, access by the second network function to one or more services provided by the first network function based at least in part on the network function type of the second network function.

16. The method of claim 15, wherein authorizing access by the second network function to the one or more services provided by the first network function comprises utilizing a set of policy files defining how resources and data managed by the one or more services provided by the first network function are accessed by one or more other network functions.

17. The method of claim 15, wherein the first service communication proxy element is provisioned with (i) one or more policy files specifying permissions for how one or more resources of one or more services of the first network function can be accessed and (ii) one or more permission-to-network function type binding policy files specifying a set of rules for binding network function types to one or more permissions.

18. An article of manufacture comprising 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 steps of:

19. The article of manufacture of claim 18, wherein authorizing access by the second network function to the one or more services provided by the first network function comprises utilizing a set of policy files defining how resources and data managed by the one or more services provided by the first network function are accessed by one or more other network functions.

20. The article of manufacture of claim 18, wherein the first service communication proxy element is provisioned with (i) one or more policy files specifying permissions for how one or more resources of one or more services of the first network function can be accessed and (ii) one or more permission-to-network function type binding policy files specifying a set of rules for binding network function types to one or more permissions.