OAuth2 Requirements per PLMN for the Definition of NFService Type

Abstract

A system and method for authorization in a cellular communication system. In one embodiment, the method performed by a network function (NF) includes sending information to another network function indicating whether a particular type of authorization is required per public land mobile network (PLMN) for a particular NF service instance associated with the NF. In one embodiment, the other network function is a network repository function (NRF). In one embodiment, the information is included in an NF profile of the NF. In one embodiment, the particular type of authorization is an Oauth2-based authorization.

Description

Technical Field

[0001] Related Applications This application claims the priority and benefit of PCT / CN2021 / 113266, filed on August 18, 2021, the disclosure of which is incorporated herein by reference in its entirety.

[0002] This disclosure relates to a cellular communication system, and more specifically, to authorization in a cellular communication system.

Background Art

[0003] In Sections 13.3 and 13.4 of the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 33.501 V17.2.1, "Security architecture and procedures for 5G system", two types of authorization are defined. One of the defined types of authorization is static authorization, and the other defined type of authorization is OAuth2.0 token-based authorization.

[0004] Static authorization is based on the local authorization policy in the Network Repository Function (NRF) and the Network Function (NF) service producer. Static authorization can be used when token-based authorization is not used. When static authorization is used within one Public Land Mobile Network (PLMN) and the NF service producer receives a service request, the NF service producer will check the authorization of the NF service consumer based on its local policy. If the NF service consumer is authorized to receive the requested service, the NF service producer will permit the NF service consumer to access the service application programming interface (API).

[0005] The token - based authorization framework uses the OAuth2.0 framework defined in RFC6749. With OAuth2.0 token - based authorization, the NF service producer can authorize requests from the NF service requester based on the access token. The NF service consumer will request an access token from the NRF before accessing the NF service. If the NF service consumer is authorized, the NRF will generate an access token containing appropriate claims. The NF service consumer will include the access token when the NF service consumer requests a service from the NF service producer. The NF service producer will verify the token. If the verification is successful, the NF service producer will execute the requested service and respond to the NF service consumer. Otherwise, the NF service producer will return based on the OAuth2.0 error response defined in RFC6749.

[0006] In 3GPP TS29.510 V17.2.0 "5G System; Network Function Repository Services; Stage3", section 6.1.6.2.3, the type:NFService is defined when the NFService type contains an attribute named oauth2Required. The attribute oauth2Required is defined to indicate whether the NF service instance requires OAuth2 - based authorization.

Summary of the Invention

[0007] A system and method for authorization in a cellular communication system. In one embodiment, a method executed by a network function (NF) includes transmitting information indicating whether a particular type of authorization is required for each public land mobile network (PLMN) for a particular NF service instance associated with the NF to other network functions. In one embodiment, the other network function is a network repository function (NRF).

[0008] In one embodiment, the information is included in the NF profile of the NF.

[0009] In one embodiment, the information is included in the NF service object included in the NF profile of the NF. In one embodiment, transmitting the information includes transmitting the NF profile of the NF to another network node, the NF profile including a list of NF service objects for each NF service instance associated with the NF, and the information being included in the NF service object for a specific NF service instance. In one embodiment, the information is included in a new attribute of the NF service object, the new attribute indicating whether a specific NF service instance requires OAuth2-based authorization for each consumer PLMN ID and / or producer PLMN ID.

[0010] In one embodiment, a specific type of authorization is OAuth2-based authorization.

[0011] In one embodiment, the method further includes receiving, from an NF service consumer, a service request for a specific NF service instance, determining which of two or more authorization mechanisms should be used for the NF service consumer based on information indicating whether a specific type of authorization is required for each PLMN for the specific NF service instance and one or more associated PLMN IDs, where the one or more associated PLMN IDs include the PLMN ID of the PLMN of the NF service consumer and / or the PLMN ID of the PLMN of the specific NF service instance, and further includes proceeding to process the service request based on the determined authorization mechanism.

[0012] In another embodiment, the method performed by the NF includes receiving, from another network function, information indicating whether a particular type of authorization is required for each PLMN for a particular NF service instance associated with another NF. In one embodiment, the NF is the NRF.

[0013] In one embodiment, the information is included in the NF profile of another NF. In one embodiment, the information is included in an NF service object included in the NF profile of another NF.

[0014] In one embodiment, receiving the information includes receiving the NF profile of another NF from another network node, the NF profile including a list of NF service objects for each NF service instance associated with the other NF, and the information being included in an NF service object for a particular NF service instance. In one embodiment, the method further includes storing the NF profile.

[0015] In one embodiment, the information is included in a new attribute of the NF service object, the new attribute indicating whether a particular NF service instance requires OAuth2-based authorization for each consumer PLMN ID and / or producer PLMN ID.

[0016] In one embodiment, the particular type of authorization is OAuth2-based authorization.

[0017] In one embodiment, the method further includes storing the information.

[0018] In one embodiment, the method further includes receiving a discovery request from an NF service consumer, determining that a particular NF service instance satisfies the discovery request, determining specific authorization requirements for the NF service consumer based on information indicating whether a particular type of authorization is required for the particular NF service instance for each PLMN and one or more associated PLMN IDs, and sending a discovery response to the NF service consumer, the discovery response including information indicating the specific authorization requirements for the NF service consumer.

[0019] Embodiments of network nodes are also disclosed herein.

[0020] The accompanying drawings, which are incorporated herein and form a part of this specification, illustrate some aspects of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

Brief Description of the Drawings

[0021]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

[0022] The embodiments described below represent information for enabling those skilled in the art to implement the embodiments and show the best mode of implementing the embodiments. Reading the following description in light of the accompanying drawings, those skilled in the art will understand the concepts of the present disclosure and recognize the uses of these concepts that are not specifically described herein. It should be understood that these concepts and uses fall within the scope of the present disclosure.

[0023] Wireless Node: As used herein, a "wireless node" is either a wireless access node or a wireless communication device.

[0024] Wireless Access Node: As used herein, a "wireless access node" or "wireless network node" or "wireless access network node" is any node within the radio access network (RAN) of a cellular communication network that is operative to transmit and / or receive signals wirelessly. Some examples of wireless access nodes include, but are not limited to, base stations (e.g., a new radio (NR) base station (gNB) in a 3rd Generation Partnership Project (3GPP) 5th Generation (5G) NR network or an evolved Node B or eNode B (eNB) in a 3GPP Long Term Evolution (LTE) network), high-power or macro base stations, low-power base stations (e.g., micro base stations, pico base stations, home eNBs, etc.), relay nodes, network nodes implementing a part of the functionality of a base station or network nodes implementing a gNB distributed unit (gNB-DU), or network nodes implementing a part of the functionality of any other type of wireless access node.

[0025] Core network node: As used herein, a "core network node" is any type of node within a core network or any node that implements core network functions. Some examples of core network nodes include, for example, a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), and the like. Some other examples of core network nodes include nodes that implement an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), and the like.

[0026] Communication device: As used herein, a "communication device" is any type of device that accesses an access network. Some examples of communication devices include, but are not limited to, mobile phones, smartphones, sensor devices, meters, vehicles, home appliances, medical devices, media players, cameras, or any type of home electronics, i.e., for example, but not limited to, televisions, radios, lighting devices, tablet computers, laptops, or personal computers (PCs). A communication device can be a portable, handheld, computer - embedded, or vehicle - mounted mobile device that is capable of communicating voice and / or data via a wireless or wired connection.

[0027] Wireless communication device: One type of communication device is a wireless communication device that can be any type of wireless device that accesses (i.e., is served by) a wireless network, such as a cellular network. Some examples of wireless communication devices include, but are not limited to, user equipment devices (UEs) in a 3GPP network, machine - type communication (MTC) devices, and Internet of Things (IoT) devices. Such wireless communication devices can be, or can be incorporated into, mobile phones, smartphones, sensor devices, meters, vehicles, home appliances, medical devices, media players, cameras, or any type of home electronics, i.e., for example, but not limited to, televisions, radios, lighting devices, tablet computers, laptops, or PCs. A wireless communication device can be a portable, handheld, computer - embedded, or vehicle - mounted mobile device that is capable of communicating voice and / or data via a wireless connection.

[0028] Network node: As used herein, a "network node" is any node that is part of either the RAN or the core network of a cellular communication network / system.

[0029] The description provided in this specification focuses on 3GPP cellular communication systems, and thus it should be noted that 3GPP terms or terms similar to 3GPP terms are often used. However, the concepts disclosed in this specification are not limited to 3GPP systems.

[0030] In the description of this specification, the term "cell" may be referred to, but particularly with respect to the 5G NR concept, beams may be used instead of cells, and thus it is important to note that the concepts described in this specification are equally applicable to both cells and beams.

[0031] Currently, there are several issues. A roaming network function (NF) service consumer within a serving public land mobile network (PLMN) and a non-roaming NF service consumer within a home PLMN may use different authorization mechanisms, but when they desire to consume the same NF service producer within the home PLMN, the NF service producer may require one authorization mechanism that may be different from the authorization mechanism supported / used by the roaming NF service consumer, so there are interoperability issues. Also, the NF service producer generates error signaling to inform the NF service consumer about the details of the failure. If the roaming NF service consumer supports but does not use the required authorization mechanism, the NF service consumer can operate accordingly by switching to the required authorization mechanism and continuing the interworking. Also, if the roaming NF service consumer does not support the required authorization mechanism, the interworking fails.

[0032] Some aspects of the present disclosure and their embodiments may provide solutions to these or other problems. For example, in the definition of NFService types described in 3GPP TS29.510 V17.2.0 Table 6.1.6.2.3-1, a system and method for separately providing different OAuth2 requirements for different PLMNs are disclosed herein. This improves the interoperability between different PLMNs.

[0033] In one embodiment, when the OAuth2 requirements are different for NF service consumers within different PLMNs (i.e., having different PLMN IDs), the NF service producer, during NF service registration, separately indicates the OAuth2 requirements for roaming NF service consumers and non-roaming NF service consumers (e.g., different OAuth2 requirements for different consumer PLMN IDs).

[0034] In another embodiment, when the OAuth2 requirements are different for NF service producers (instances) within different home PLMNs (i.e., having different PLMN IDs), the NF service producer, during NF service registration, separately indicates the OAuth2 requirements for different producer PLMNs.

[0035] In another embodiment, when the OAuth2 requirements are different for different combinations of the PLMN IDs of the consumer and the producer, the NF service producer, during NF service registration, separately indicates the OAuth2 requirements for different combinations of the PLMN IDs of the consumer and the producer.

[0036] In one embodiment, the NRF and NF service producer can distinguish between a roaming NF service consumer and a non-roaming NF service consumer. In other words, the NRF and / or NF service producer can determine whether a particular discovery request or service request is from a roaming NF service consumer or a non-roaming NF service consumer, for example, by checking the consumerPlmnId in each access token or by checking the 3gpp-Sbi-Asserted-Plmn-Id header in the request.

[0037] In one embodiment, the NRF can obtain the producer PLMN ID of the expected NF service producer instance by checking the target-plmn-list in the NF discovery request.

[0038] In one embodiment, the NRF determines the OAuth2 requirements for the NF service consumer upon receiving an NF discovery request from the NF service consumer. The NRF checks the registered OAuth2 requirements of the expected NF service producer instance (i.e., the NF service producer instance to be indicated in the discovery response) with the knowledge of the consumer PLMN ID (i.e., the PLMN ID of the PLMN of the NF service consumer) and the producer PLMN ID (i.e., the PLMN ID of the PLMN of the expected NF service producer instance), determines the exact OAuth2 requirements for the NF service consumer, and returns the indication of the exact OAuth2 requirements for the NF service consumer to the NF service consumer, for example, via the existing IE oauth2Required.

[0039] In one embodiment, the NF service producer determines the OAuth2 requirements for the NF service consumer upon receiving a service request. The NF service producer checks the configured local OAuth2 requirements (also registered with the NRF), along with the knowledge of the consumer PLMN ID and / or the producer PLMN ID, to determine the exact OAuth2 requirements for the NF service consumer and performs authorization verification accordingly.

[0040] In one embodiment, a new optional attribute is introduced into the existing definition of the NFService type, and this new attribute is defined to indicate the OAuth2 requirements per PLMN ID.

[0041] Some embodiments may provide one or more of the following technical advantages. For example, the embodiments disclosed herein may improve the interoperability between different PLMNs that use different authorization mechanisms.

[0042] FIG. 1 shows an example of a cellular communication system 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communication system 100 is a 5G system (5GS) including a next-generation RAN (NG-RAN) and a 5G core (5GC), but the present disclosure is not limited thereto. In this example, the RAN includes base stations 102-1 and 102-2 in the 5GS that control the corresponding (macro) cells 104-1 and 104-2, the NR base station (gNB) and optionally a next-generation eNB (ng-eNB) (e.g., an LTE RAN node connected to the 5GC). The base stations 102-1 and 102-2 are generally collectively referred to as base station 102 herein and individually as base station 102. Similarly, the (macro) cells 104-1 and 104-2 are generally collectively referred to as (macro) cell 104 herein and individually as (macro) cell 104. The RAN may also include several low-power nodes 106-1 to 106-4 that control the corresponding small cells 108-1 to 108-4. The low-power nodes 106-1 to 106-4 can be small base stations (such as pico base stations or femto base stations) or RRHs, etc. In particular, although not shown, alternatively, one or more of the small cells 108-1 to 108-4 may be provided by the base station 102. The low-power nodes 106-1 to 106-4 are generally collectively referred to as low-power node 106 herein and individually as low-power node 106. Similarly, the small cells 108-1 to 108-4 are generally collectively referred to as small cell 108 herein and individually as small cell 108. The cellular communication system 100 also includes a core network 110, which is called 5GC in the 5G system (5GS). The base stations 102 (and optionally the low-power nodes 106) are connected to the core network 110.

[0043] Base station 102 and low-power node 106 provide services to wireless communication devices 112-1 to 112-5 within corresponding cells 104 and 108. Wireless communication devices 112-1 to 112-5 are generally collectively referred to as wireless communication devices 112 herein and individually as wireless communication device 112. In the following description, wireless communication device 112 is often a UE, but the present disclosure is not limited thereto.

[0044] FIG. 2 shows a wireless communication system represented as a 5G network architecture composed of core network functions (NFs), and the interaction between any two NFs is represented by point-to-point reference points / interfaces. FIG. 2 can be regarded as one specific implementation of the system 100 in FIG. 1.

[0045] Viewed from the access side, the 5G network architecture shown in FIG. 2 includes a plurality of UEs 112 connected to either RAN 102 or an access network (AN), and an AMF 200. Usually, R(AN) 102 includes a base station such as an eNB or a gNB. Viewed from the core network side, the 5GC NFs shown in FIG. 2 include an NSSF 202, an AUSF 204, a UDM 206, an AMF 200, an SMF 208, a PCF 210, and an Application Function (AF) 212.

[0046] The reference point representation of the 5G network architecture is used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE112 and the AMF200. The reference points for connecting between the AN102 and the AMF200, and between the AN102 and the UPF214 are defined as N2 and N3 respectively. There is a reference point N11 between the AMF200 and the SMF208, which means that the SMF208 is at least partially controlled by the AMF200. N4 can be used to configure the UPF214 using control signals generated by the SMF208, and is used by the SMF208 and the UPF214 so that the UPF214 can report its status to the SMF208. N9 is a reference point for connecting between different UPF214s, and N14 is a reference point for connecting between different AMF200s respectively. Since the PCF210 applies policies to the AMF200 and the SMF208 respectively, the N15 and N7 are defined. N12 is required for the AMF200 to perform authentication of the UE112. N8 and N10 are defined because subscription data of the UE112 is required for the AMF200 and the SMF208.

[0047] The 5GC network aims to separate the UP and the CP. The UP carries user traffic, while the CP carries signaling within the network. In Figure 2, the UPF214 is within the UP, and all other NFs, namely, the AMF200, the SMF208, the PCF210, the AF212, the NSSF202, the AUSF204, and the UDM206 are within the CP. Separating the UP and the CP ensures that each plane resource is scaled independently. Also, it becomes possible to distribute and place the UPF separately from the CP functions. In this architecture, for some applications that require low latency, the UPF can be placed very close to the UE to shorten the round-trip time (RTT) between the UE and the data network.

[0048] The core 5G network architecture is composed of modularized functions. For example, AMF200 and SMF208 are independent functions at the CP. The separated AMF200 and SMF208 enable independent evolution and scaling. Other CP functions such as PCF210 and AUSF204 can be separated as shown in Figure 2. The modularized function design enables the 5GC network to flexibly support various services.

[0049] Each NF communicates directly with another NF. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as a service, and as a result, its reuse is possible. This service enables support for modularization. The UP supports interactions such as transfer operations between different UPFs.

[0050] Figure 3 shows a 5G network architecture that uses service-based interfaces between NFs within the CP instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 2. However, the NFs described above with reference to Figure 2 correspond to the NFs shown in Figure 3. Services such as those provided by an NF to other authorized NFs can be exposed to the authorized NFs via service-based interfaces. In Figure 3, the service-based interfaces are indicated by the letter "N" following the name of the NF. For example, for the service-based interface of AMF200, it is Namf, and for the service-based interface of SMF208, it is Nsmf, etc. NEF300 and NRF302 in Figure 3 are not shown in Figure 2 above. However, it should be clear that although not explicitly shown in Figure 2, all NFs shown in Figure 2 can communicate with NEF300 and NRF302 in Figure 3 as needed.

[0051] Some of the characteristics of the NFs shown in FIGS. 2 and 3 can be described as follows. The AMF 200 provides UE-based authentication, authorization, mobility management, etc. Since the AMF 200 is independent of the access technology, even a UE 112 using a multi-connection technology is basically connected to a single AMF 200. The SMF 208 is responsible for session management and allocates an Internet Protocol (IP) address to the UE. Also, the SMF 208 selects and controls the UPF 214 for data transfer. When the UE 112 has multiple sessions, different SMF 208s may be allocated to each session to manage them individually and, in some cases, provide different functions for each session. The AF 212 provides information regarding a packet flow to the PCF 210, which is responsible for policy control, in order to support QoS. Based on this information, the PCF 210 determines policies regarding mobility and session management in order to operate the AMF 200 and the SMF 208 appropriately. The AUSF 204 supports an authentication function for the UE, etc., and thus stores data for authentication of the UE, etc., while the UDM 206 stores the subscription data of the UE 112. A data network (DN), which is not part of the 5GC network, provides Internet access or operator services, etc.

[0052] The NF can be implemented either as a network element on dedicated hardware, as a software instance operating on dedicated hardware, or as a virtualized function instantiated on a suitable platform, such as a cloud infrastructure.

[0053] In one embodiment, a new (optional) attribute is added to the definition of the NFService type defined in 3GPP TS 29.510 Table 6.1.6.2.3-1. This new attribute is referred to herein as oauth2RequiredPerPlmn, but the name of this attribute is only an example. Other names for the new attribute may be used. Table 1 - Revised version of Table 6.1.6.2.3 - 1 in 3GPP TS29.510: Definition of NFService Type Note: For simplicity, all attributes not relevant within Table 6.1.6.2.3 - 1 are removed. TIFF0007710603000001.tif229170

[0054] In one embodiment, the new attribute (oauth2RequiredPerPlmn) within the definition of NFService Type can be defined as an array data type or a map data type to indicate whether the NF service instance requires OAuth2 - based authorization per consumer PLMN ID and / or producer PLMN ID.

[0055] In one embodiment, during NF service registration, if the OAuth2 requirements are different for different consumer PLMN IDs, different for different producer PLMN IDs, or different for different combinations of consumer PLMN ID and producer PLMN ID, the NF service producer indicates oauth2RequiredPerPlmn.

[0056] In one embodiment, the NRF and the NF service producer can distinguish between a roaming NF service consumer or a non - roaming NF service consumer by checking, for example, the consumerPlmnId in the access token or the 3gpp - Sbi - Asserted - Plmn - Id header in the request.

[0057] In one embodiment, the NRF can obtain the producer PLMN ID of the expected NF service producer instance by checking the target - plmn - list in the NF discovery request.

[0058] In one embodiment, the NRF determines the OAuth2 requirements for an NF service consumer upon receiving an NF discovery request. The NRF checks the registered OAuth2 requirements of the expected NF service producer instance, along with the knowledge of the consumer PLMN ID and the producer PLMN ID, determines the exact OAuth2 requirements for the NF service consumer, and returns it to the NF service consumer via the existing IE oauth2Required.

[0059] In one embodiment, when an NF service consumer within the serving PLMN receives an Nnrf_NFDiscovery_Response along with the oAuth2Req IE, the NF service consumer uses the required authorization mechanism accordingly when accessing the desired NF service instance.

[0060] In one embodiment, an NF service producer determines the OAuth2 requirements for an NF service consumer upon receiving a service request. The NF service producer checks the configured local OAuth2 requirements (also registered with the NRF), along with the knowledge of the consumer PLMN ID and / or the producer PLMN ID, determines the exact OAuth2 requirements for the NF service consumer, and performs authorization verification accordingly.

[0061] Figure 4 shows the operation of the NF400 and the Network Repository Function (NRF) 402 for NF registration according to one exemplary embodiment of the present disclosure. In this context, the NF400 may also be referred to as the NF service producer of the registration service of the NRF402. However, the NF400 can also be the NF service producer for the NF services indicated in the NF profile of the NF400. As shown, the NF400 sends a PUT request to the NRF402, and the PUT request includes the NF instance ID of the NF400 and the NF profile of the NF400 (step 404). As described in section 6.1.6.2.2 of 3GPP TS23.510 V17.2.0, the NF profile of the NF400 includes many attributes, such as the NF instance ID, NF type, a list of NF services (nfServiceList), etc. The array or list of NF service attributes is a list or array of NF service objects. As defined in section 6.1.6.2.3 of 3GPP TS23.510 V17.2.0, the NFService object includes the NF service instance ID ("serviceInstanceId") of each NF service instance, the oauth2required attribute, and many other attributes. The oauth2required attribute in the current definition of the NF service type indicates whether the NF service instance requires Oauth2-based authorization. In addition, according to one embodiment of the present disclosure, the NFService object further includes a new attribute (oauth2RequiredPerPlmn) that indicates whether the NF service instance requires Oauth2-based authorization for each consumer PLMN ID and / or producer PLMN ID, as described above. The NRF402 stores the NF profile of the NF400 (step 406).

[0062] FIG. 5 shows the operations of an NF service consumer 500 and an NRF 402 for performing an NF discovery procedure according to an embodiment of the present disclosure. As illustrated, the NF service consumer 500 sends an NF discovery request (Nnrf_NFDiscovery_Request) to the NRF 402 (step 502). The NRF 402 determines that a particular NF service instance of the NF 400 satisfies the discovery request (step 504). Note that in this context, the NF 400 is also referred to as an NF service producer 400. The NRF 402 determines specific OAuth2 requirements for the NF service consumer 500 to access the NF service of the particular NF service instance, considering the relevant PLMN ID (i.e., the consumer PLMN ID and / or the producer PLMN ID) (step 506). More specifically, in one embodiment, the NRF 402 obtains the relevant PLMN ID (i.e., the consumer PLMN ID of the NF service consumer 500 and / or the producer PLMN ID of the particular NF service instance that satisfies the discovery request) (step 506A). Then, the NRF 402 determines the specific OAuth2 requirements based on the information stored in the oauth2RequiredPerPlmn attribute of the NFService object for the particular NF service instance in the NF profile of the NF service producer 400 and the relevant PLMN ID (step 506B). The NRF 402 sends an NF discovery response (Nnrf_NFDiscovery_Response) to the NF service consumer 500 (step 508). The NF discovery response includes information indicating the determined specific OAuth2 requirements for the NF service consumer 500. In one embodiment, the determined specific OAuth2 requirements are sent to the NF service consumer 500 via the existing IE oauth2Required attribute.

[0063] FIG. 6 shows the operations of an NF service consumer 600 and an NF service producer 602 (e.g., an NF service producer within a home PLMN) according to an embodiment of the present disclosure. As shown, the NF service consumer 600 determines an authorization mechanism to be used when accessing services provided by a specific NF service instance of the NF service producer 602 (step 604). In one embodiment, the NF service consumer 600 determines the authorization mechanism to be used based on authorization requirements received by the NF service consumer 600 from the NRF (e.g., via the procedure of FIG. 5). The NF service consumer 600 then uses the determined authorization mechanism to send a service request to the NF service instance of the NF service producer 602 (step 606).

[0064] In one embodiment, the NF service producer 602 obtains the PLMN ID of the PLMN of the NF consumer 600 (step 608). The consumer PLMN ID can be obtained, for example, either from the consumerPlmnId in each access token or from the 3gpp-Sbi-Asserted-Plmn-Id header in the service request. The NF service producer 602 can then use the consumer PLMN ID for each NF service instance, its own home PLMN ID, and the information included in the auth2RequiredPerPlmn attribute to determine the authorization mechanism to be used for access to the service requested by the NF service consumer 600 (step 610). The NF service producer 602 then proceeds accordingly (step 612). For example, if it is determined that OAuth2.0 token-based authorization is to be used, the NF service producer 602 authorizes the service request from the NF service consumer 600 based on the access token. Note that the NF service consumer 600 requests an access token from the NRF before accessing the NF service. If the NF service consumer 600 is authorized, the NRF generates an access token containing the appropriate claims. The NF service consumer 600 includes the access token when sending the service request to the NF service producer 602. The NF service producer 602 verifies the token. If the verification is successful, the NF service producer 602 executes the requested service and responds to the NF service consumer 600. Otherwise, the NF service producer 602 returns based on the OAuth2.0 error response defined in RFC6749. Conversely, if it is determined that OAuth2.0 token-based authorization is not to be used, static authorization can be used by the NF service producer 602. When receiving a service request, the NF service producer 602 checks the authorization of the NF service consumer 600 based on its local policy.When the NF service consumer 600 is authorized to receive the requested service, the NF service producer 602 permits the NF service consumer 600 to access the service API, and otherwise rejects the service request.

[0065] FIG. 7 is a schematic block diagram of a network node 700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 700 can be, for example, a base station 102 or 106, or a network node implementing all or part of the functionality of the base station 102 or gNB described herein. As shown, the network node 700 includes a control system 702 that includes one or more processors 704 (e.g., a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc.), a memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as a processing circuit. Additionally, if the network node 700 is a radio access node (e.g., a base station 102, a gNB, or a network node implementing at least some of the functionality of the base station 102 or gNB), the network node 700 can include one or more radio units 710 each including one or more transmitters 712 and one or more receivers 714 coupled to one or more antennas 716. The radio unit 710 can refer to, or be part of, a radio interface circuit. In some embodiments, the radio unit 710 is external to the control system 702 and is connected to the control system 702 via, for example, a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit 710 and optionally the antenna 716 are integrated with the control system 702. The one or more processors 704 operate to provide one or more functions of the network node 700 described herein (e.g., one or more functions of the base station 102 or gNB described herein). In some embodiments, the functions are implemented, for example, in software stored in the memory 706 and executed by the one or more processors 704.

[0066] FIG. 8 is a schematic block diagram showing a virtualized embodiment of network node 700 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a “virtualized” network node is an implementation of network node 700 in which at least some of the functions of network node 700 are implemented as virtual components (e.g., via virtual machines running on physical processing nodes within the network). As shown, in this example, if network node 700 is a wireless access node, network node 700 may include a control system 702 and / or one or more radio units 710 as described above. The control system 702 may be connected to the radio unit 710 via, for example, an optical cable. Network node 700 includes one or more processing nodes 800 coupled to or included as part of network 802. The control system 702 or radio unit, if present, is connected to the processing node 800 via network 802. Each processing node 800 includes one or more processors 804 (e.g., a CPU, ASIC, FPGA, etc.), a memory 806, and a network interface 808.

[0067] In this example, the functionality 810 of the network node 700 described herein (e.g., one or more functions of the base station 102 or gNB described herein) is implemented in one or more processing nodes 800 in any desired manner, or is distributed across one or more processing nodes 800 and the control system 702 and / or the radio unit 710. In some particular embodiments, some or all of the functionality 810 of the network node 700 described herein is implemented as virtual components executed by one or more virtual machines implemented within a virtual environment hosted by the processing node 800. As will be appreciated by those skilled in the art, additional signaling or communication between the processing node 800 and the control system 702 is used to execute at least some of the desired functionality 810. In particular, in some embodiments, the control system 702 may not be included, in which case the radio unit 710 communicates directly with the processing node 800 via an appropriate network interface.

[0068] In some embodiments, a computer program is provided that includes instructions to cause at least one processor to execute the functionality of the network node 700, or a node (e.g., the processing node 800) implementing one or more of the functionality 810 of the network node 700 within a virtual environment according to any of the embodiments described herein, when executed by the at least one processor. In some embodiments, a carrier is provided that includes the aforementioned computer program product. The carrier is one of an electronic signal, an optical signal, a wireless signal, or a computer-readable storage medium (e.g., a non-transitory computer-readable medium such as a memory).

[0069] FIG. 9 is a schematic block diagram of a network node 700 according to some other embodiments of the present disclosure. The network node 700 includes one or more modules 900, each of which is implemented within software. The modules 900 provide the functionality of the network node 700 described herein. This description is equally applicable to the processing node 800 of FIG. 8, and the modules 900 may be implemented in one of the processing nodes 800, or distributed across a plurality of processing nodes 800, and / or distributed across the processing nodes 800 and the control system 702.

[0070] Any suitable steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual devices. Each virtual device may include several of these functional units. These functional units may be implemented via a processing circuit that may include one or more microprocessors or microcontrollers, and other digital hardware that may include a digital signal processor (DSP), dedicated digital logic, etc. The processing circuit may be configured to execute program code stored in a memory that may include one or several types of memory such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in the memory includes program instructions for executing one or more electrical communication protocols and / or data communication protocols, and instructions for executing one or more of the techniques described herein. In some implementations, the processing circuit may be used to cause each functional unit to perform the corresponding function according to one or more embodiments of the present disclosure.

[0071] The processes in the figures may indicate a particular order of operations performed in accordance with some embodiments of the present disclosure, but it should be understood that such order is exemplary (e.g., alternative embodiments may perform operations in a different order, combine some operations, repeat some operations, etc.).

[0072] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered to be within the scope of the concepts disclosed herein.

Claims

1. A method executed by a Network Function (NF) service producer (602), comprising: sending (404) to a Network Repository Function (NRF) (402) information indicating whether a specific type of authorization for a service request from an NF service consumer (600) to the NF service producer (602) is required for each Public Land Mobile Network (PLMN) for a specific NF service instance associated with the NF service producer (602); The method, wherein the specific type of authorization is based on an access token included in the service request.

2. The method according to claim 1, wherein the information is included in an NF profile of the NF service producer (602).

3. The method according to claim 1, wherein the information is included in an NF service object included in an NF profile of the NF service producer (602).

4. The step of sending (404) the information includes sending an NF profile of the NF service producer (602) to the NRF (402), the NF profile including a list of NF service objects for each NF service instance associated with the NF service producer (602), and the information being included in the NF service object for the specific NF service instance; the method according to claim 1.

5. The method according to claim 3, wherein the information is included in a new attribute of the NF service object, the new attribute indicating whether the specific NF service instance requires the specific type of authorization for each consumer PLMN ID of the NF service consumer (600) and / or each producer PLMN ID of the specific NF service instance.

6. The method according to claim 1, wherein the specific type of authorization is OAuth2-based authorization.

7. receiving (606) from the NF service consumer (600) a service request for the specific NF service instance; Determining (610) which one of two or more authorization authorities to use for the NF service consumer (600) based on the information indicating whether the specific type of authorization is required per PLMN for the specific NF service instance, and one or more associated PLMN IDs The method according to claim 1, further comprising **Claim 8** The method according to claim 7, wherein the one or more associated PLMN IDs include the PLMN ID of the PLMN of the NF service consumer (600) and / or the PLMN ID of the PLMN of the specific NF service instance **Claim 9** The method according to claim 7, further comprising proceeding to process the service request based on the determined authorization authority (612) **Claim 10** A method executed by a network repository function (NRF) (402), comprising Receiving (404) from a network function (NF) service producer information indicating whether a specific type of authorization is required for a service request from an NF service consumer (500) to the NF service producer per public land mobile network (PLMN) for a specific NF service instance associated with the NF service producer The method, wherein the specific type of authorization is based on an access token included in the service request **Claim 11** The method according to claim 10, wherein the information is included in the NF profile of the NF service producer **Claim 12** The method according to claim 10, wherein the information is included in an NF service object included in the NF profile of the NF service producer **Claim 13** The method according to claim 10, wherein receiving the information (404) includes receiving from the NF service producer the NF profile of the NF service producer, the NF profile includes a list of NF service objects for each NF service instance associated with the NF service producer, and the information is included in the NF service object for the specific NF service instance **Claim 14** The method according to claim 13, further comprising storing the NF profile (406) **Claim 15** The information is included in a new attribute of the NF service object, and the new attribute indicates whether the specific NF service instance requires the authorization of the specific type for each of the consumer PLMN ID of the NF service consumer (500) and / or the producer PLMN ID of the specific NF service instance. The method according to claim 12.

16. The authorization of the specific type is OAuth2-based authorization. The method according to claim 10.

17. The method according to claim 10, further comprising storing the information (406).

18. Receiving a discovery request from the NF service consumer (500) (502), Determining (504) that the specific NF service instance satisfies the discovery request (504), Based on the information indicating whether the authorization of the specific type is required for each PLMN for the specific NF service instance and one or more related PLMN IDs, determining (506) specific authorization requirements for the NF service consumer (500), Sending a discovery response to the NF service consumer (500) (508) The method further comprising: The discovery response includes information indicating the specific authorization requirements for the NF service consumer (500). The method according to claim 10.

19. A network node (700) adapted to execute the method according to any one of claims 1 to 18.

Images