Method, system, and computer-readable medium for utilizing NF service attributes related to a network function (NF) service producer registered in a hierarchical network
By extracting and storing NF service attributes in a local database, the root NRF in a hierarchical 5G network can efficiently route service requests to appropriate regional NRFs, addressing the inefficiencies caused by lacking service information.
Patent Information
- Application Number
- JP2024569144
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-05-23
- Filing Date
- 2023-05-11
- Publication Date
- 2025-06-12
AI Technical Summary
In a hierarchical 5G network, the root Network Function Repository Function (NRF) lacks information about the specific services supported by Network Function (NF) service producers, leading to inefficient service request routing and increased transaction latency.
The root NRF receives NF registration or update messages from regional NRFs, extracts NF service attributes from the NrfInfo structure, and stores them in a local state information database. This allows the root NRF to direct service requests to the appropriate regional NRF based on available NF services.
This solution enables the root NRF to efficiently route service requests to regional NRFs that can provide the requested services, reducing unnecessary forwarding and transaction latency in the network.
Smart Images

Figure 2025517972000001_ABST
Abstract
Description
Technical Field
[0001] Claims of Priority This application claims the benefit of priority of U.S. Patent Application No. 17 / 751,584, filed on May 23, 2022, the entire disclosure of which is incorporated herein by reference.
[0002] Technical Field The subject matter described herein relates to the registration and management of network function (NF) service producers in a fifth generation (5G) communication network. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for utilizing NF service attributes associated with NF service producers registered in a hierarchical network.
Background Art
[0003] Background In a telecommunications network, a service endpoint is an address on a network node that uniquely identifies an entity that provides a service to a service consumer. A service endpoint can include an Internet Protocol (IP) address, or a combination of an IP address and a transport layer port number, which is also referred to as an IP endpoint.
[0004] In a fifth generation (5G) telecommunications network, a network node that provides a service is called a network function (NF) service producer. A network node that consumes a service is called an NF service consumer. A network function can be both an NF service producer and an NF service consumer, depending on whether it consumes or provides a service.
[0005] A given NF service producer may have multiple service endpoints. The NF service producer registers with the Network Function Repository Function (NRF). The NRF maintains the NF profiles of the available NF instances and the supported services of the NF instances. A consumer NF can subscribe to receive information about the NF service producer instances registered with the NRF. Once registered, an NF instance in a 5G network can establish a session with one or more Network Exposure Functions (NEF). It should be noted that the NEF is a network function of the 3rd Generation Partnership Project (3GPP (registered trademark)) that provides a means to securely expose the services and capabilities provided by the producer network functions that offer services to the network.
[0006] In many cases, a 5G network can be segmented into multiple regions according to a hierarchical deployment. In such a configuration, a root NRF needs to be specified and configured to communicate with multiple regional NRFs deployed in various regions of the network (e.g., a Public Land Mobile Network (PLMN)). More specifically, each regional NRF is configured to register itself with the root NRF using the "NrfInfo" attribute. According to 3GPP 29.510, when an NRF receives an Nnrf service request (e.g., a subscription request, a discovery request, an access token service request, etc.) and the NRF does not have the information required to fulfill that request, the NRF forwards the service request to a pre-configured NRF. In a hierarchical deployment, the root NRF is assigned as the pre-configured NRF.
[0007] In some implementations, the root NRF prepares state data from the NF updates received from the regional NRF. Further, for each Nnrf service request or discovery request transferred from the regional NRF to the root NRF, the root NRF uses its state data to determine and specify the target regional NRF that can service that request. In particular, the root NRF is configured to process the transferred Nnrf service request and attempts to identify the regional NRF in which the NF service producer that can service that request is registered (e.g., the root NRF <nf-type>Info and <nf-type>(refer to the attribute data of the InfoList and the mapped nfinstance identifier associated with the NF service producer). As used herein, <nf-type>Info and <nf-type>InfoList can also be represented as xxxinfo and xxxinfolist respectively, where <nf-type>Info or "xxx" represents a specific NF-type according to section 6.1.6.3.3 of 3GPP 29.510.
[0008] However, since the root NRF is usually not provisioned with information detailing the specific services supported / provided by NF service producers, the root NRF may attempt to find an appropriate regional NRF (and NF service producer) that can adequately handle the service request, unnecessarily forwarding the Nnrf service request to multiple regional NRFs. More specifically, the ability of the root NRF to determine the target regional NRF that can provide the service for the request is provided in advance by the regional NRF <nf-type>Info structure and <nf-type>It is limited to the content of the attribute data in the InfoList structure. However, <nf-type>Info structure and <nf-type>In the InfoList structure, notably, the information of NF services registered by the NF is not included at all (such information is synchronized from the regional NRF to the home NRF by the regional NRF). When it is not known which NF services are supported by a given NF (and the regional NRF), the home NRF needs to ignore any NF service parameters in the request and determine the target regional NRF based only on the NF-Type information. As described above, due to such deficiencies, the home NRF may be forced to repeatedly re-route the request to another regional NRF. Thus, this behavior of the home NRF is considered inefficient and causes a significant transaction latency in the network.
[0009] Therefore, there is a need for an improved method and system for utilizing network function service attributes related to network function service producers registered in a hierarchical network. Summary of the Invention Means for Solving the Problems
[0010] Overview Disclosed are a method, a system, and a computer-readable medium for utilizing network function (NF) service attributes associated with a registered network function service producer in a hierarchical network. One method includes receiving, by a root network function repository function (NRF) operating in a hierarchical network, an NF registration message or an NF update message from a regional NRF operating in a first region of the hierarchical network, the NF registration message or the NF update message including an NrfInfo structure that includes one or more NF service attributes that specify one or more NF services provided by at least one NF service producer registered with the regional NRF. The method further includes the root NRF extracting one or more NF service attributes from the NrfInfo structure and the root NRF creating one or more indexed entries including the one or more NF service attributes in a local state information database.
[0011] According to another aspect of the method described herein, the root NRF is configured to direct a service request message received from a second regional NRF to the regional NRF using one or more NF service attributes stored in a local state information database.
[0012] According to another aspect of the method described herein, the service request message includes at least one of an Nnrf subscription request message, an Nnrf discovery request message, or an Nnrf access token request message.
[0013] According to another aspect of the method described herein, the regional NRF is configured to insert one or more NF service attributes into the NrfInfo structure as customized attributes.
[0014] According to another aspect of the method described herein, the customized attributes include a customized NF service structure that specifies one or more NF services.
[0015] According to another aspect of the method described herein, the NrfInfo structure is provided to the root NRF via an NF profile update message sent by the regional NRF.
[0016] According to another aspect of the method described herein, the NrfInfo structure is a JavaScript (registered trademark) Object Notation (JSON) data structure.
[0017] According to another aspect of the disclosed subject matter described herein, one system for utilizing one or more NF service attributes associated with a network function service producer registered in a hierarchical network operates in a first region of the hierarchical network and is configured to generate an NF registration message or an NF update message, and includes a regional NRF. The system also operates in the hierarchical network and receives an NF registration message or an NF update message from the regional NRF, where the NF registration message or the NF update message includes an NrfInfo structure that includes one or more NF service attributes that specify one or more NF services provided by at least one NF service producer registered with the regional NRF, extracts one or more NF service attributes from the NrfInfo structure, and is configured to create one or more indexed entries including the one or more NF service attributes in a local state information database, and also includes a root NRF that includes the local state information database.
[0018] According to another aspect of the system described herein, the root NRF is configured to direct a service request message received from a second regional NRF to the regional NRF using one or more NF service attributes stored in the local state information database.
[0019] According to another aspect of the system described in this specification, the service request message includes at least one of an Nnrf subscription request message, an Nnrf discovery request message, or an Nnrf access token request message.
[0020] According to another aspect of the system described in this specification, the regional NRF is configured to insert one or more NF service attributes into the NrfInfo structure as customized attributes.
[0021] According to another aspect of the system described in this specification, the customized attribute includes a customized NF service structure that specifies one or more NF services.
[0022] According to another aspect of the system described in this specification, the NrfInfo structure is provided to the home NRF via an NF profile update message sent by the regional NRF.
[0023] According to another aspect of the system described in this specification, the NrfInfo structure is a JSON data structure.
[0024] The subject matter described herein can be implemented in hardware, software, firmware, or any combination thereof. Accordingly, the terms "function," "node," or "module" as used herein refer to hardware for implementing the recited features, which may include software and / or firmware components. In one exemplary implementation, the subject matter described herein can be implemented using one or more computer-readable media storing computer-executable instructions that, when executed by a computer's processor, cause the computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, application specific integrated circuits, and the like. Further, the computer-readable media on which the subject matter described herein is implemented may be disposed on a single device or computing platform, or may be distributed across multiple devices or computing platforms.
[0025] Reference will now be made to the following accompanying drawings to describe the subject matter described herein.
Brief Description of the Drawings
[0026]
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Mode for Carrying Out the Invention
[0027] Detailed Description The subject matter described in this specification relates to a method, system, and computer-readable medium for utilizing network function service attributes related to a network function service producer registered in a hierarchical network. In particular, the disclosed subject matter includes methods and systems that enable a regional NRF in a hierarchical network to share NF service information of each registered NF with a root NRF via an NF profile update. In some embodiments, the root NRF is configured to store the supported NF service information of each NF (shared by the regional NRF) in its local state information database. After receiving an NF discovery request, a subscription request, and an access token request indicating a subsequently requested service, the root NRF accesses its local state information database to identify the matching NFs and the corresponding regional NRFs in which these NFs are registered, and sends a heartbeat message. It should be noted that the root NRF performs routing and / or re-routing only to the identified regional NRFs in order to avoid unnecessary and / or wasted communication attempts.
[0028] Various embodiments of the subject matter described in this specification are referred to in detail below, examples of which are shown in the accompanying drawings. Whenever possible, the same or similar parts are denoted by the same reference numerals throughout the drawings.
[0029] FIG. 1 is a block diagram showing an exemplary 5G system network architecture, e.g., a home 5G core (5GC) network. The architecture of FIG. 1 includes an NRF 100 and an SCP 101, which may be located within the same home public land mobile network (PLMN). As described above, the NRF 100 maintains profiles of service instances of available NF service producers and the services they support, and enables a consumer NF or SCP to subscribe to the registration of new / updated NF service instances and receive notification of such registration. The SCP 101 can also support service discovery and NF instance selection. The SCP 101 may perform load balancing in the connection between the consumer and the NF service producer. Further, using the methodologies described herein, the SCP 101 can perform selection and routing based on prioritized NF locations.
[0030] The NRF100 is a repository of NF or service profiles of NF instances. To communicate with NF instances, a consumer NF or SCP has to obtain NF service profiles or NF instances from the NRF100. The NF profile or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP Technical Specification (TS) 29.510. The NF profile or service profile definition includes at least one of a Fully Qualified Domain Name (FQDN), Internet Protocol (IP) version 4 (IPv4) address, or IP version 6 (IPv6) address. In Figure 1, any of the nodes (other than the NRF100) can be either a consumer NF or an NF service producer depending on whether it is requesting or providing a service. In the example shown, the nodes include a Policy Control Function (PCF) 102 that performs policy-related operations in the network, an Integrated Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. The nodes shown in Figure 1 further include a Session Management Function (SMF) 108 that manages sessions between an Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in a 4G network. An Authentication Server Function (AUSF) 112 performs authentication services for user devices such as a User Equipment (UE) 114 seeking access to the network.
[0031] The Network Slice Selection Function (NSSF) 116 provides network slicing services to devices attempting to access specific network functions and characteristics related to network slices. The Network Exposure Function (NEF) 118 provides an Application Programming Interface (API) to application functions attempting to obtain information about Internet of Things (IoT) devices and other UEs connected to the network. The NEF 118 performs a function similar to the Service Capability Exposure Function (SCEF) in a 4G network.
[0032] The Radio Access Network (RAN) 120 connects the UE 114 to the network via a wireless link. The Radio Access Network 120 can be accessed using a g-Node B (gNB) (not shown in Figure 1) or other wireless access points. The User Plane Function (UPF) 122 can support various proxy functionalities for user plane services. An example of such proxy functionality is Multipath Transmission Control Protocol (MPTCP) proxy functionality. The UPF 122 can also support performance measurement functionality that can be used by the UE 114 to obtain network performance measurements. Also shown in Figure 1 is the Data Network (DN) 124 that the UE uses to access data network services such as Internet services.
[0033] The Security Edge Protection Proxy (SEPP) 126 filters incoming traffic from another PLMN and performs topology hiding on traffic going out from the home PLMN. The SEPP 126 can communicate with the SEPP within the external PLMN that manages the security of the external PLMN. Thus, traffic between NFs in different PLMNs may pass through two SEPP functions, one for the home PLMN and the other for the external PLMN. In some embodiments, the SEPP is a gateway device located at the edge of the network.
[0034] SEPP126 can utilize the N32-c interface and the N32-f interface. The N32-c interface is a control plane interface between two SEPPs that can execute an initial handshake (e.g., TLS handshake) and negotiate various parameters for N32-f interface connection and related message transfer. The N32-f interface is a transfer interface between two SEPPs that can transfer various communications (e.g., 5GC requests) between the consumer NF and the NF service producer after applying application-level security protection.
[0035] As described above, the deployment of the NRF hierarchical system is usually required when two or more NRF segments are supported within a given network such as a public land mobile network (PLMN). To explain, Figure 2 depicts a hierarchical network 200 including a plurality of regional NRFs 201 to 203 and a root NRF 204. It should be noted that each of the regional NRFs 201 to 203 is located within a separate network segment or region. Each regional NRF is configured to provide management services, discovery services, and access token services (e.g., NF profile updates for both NF service consumers and NF service producers) to the registered regional NFs. The regional NRFs 201 to 203 can also be configured to transfer service requests for Nnrf discovery, subscription, and access tokens to the root NRF 204 when the regional NRF (and / or its registered NF service producer within the region) that first receives the service request from the NF service consumer cannot provide the service for a specific service request from the NF service consumer.
[0036] In some embodiments, the root NRF204 can be a part of and / or exist within any of the network segments of the hierarchical network 200. The root NRF204 can also be deployed as a geographically redundant element for high availability purposes. Further, each of the regional NRFs 201 - 203 and the root NRF204 is depicted in FIG. 2 as including redundant failover backups (e.g., three instances of each regional NRF within each region). That is, the failover backups shown in FIG. 2 represent triple side redundancy measures employed by the operator of the hierarchical network 200.
[0037] In some embodiments, the root NRF204 is designated and configured to communicate with each of the plurality of regional NRFs 201 - 203 that are located in and / or operate in various regions of the PLMN. More specifically, each of the regional NRFs 201 - 203 is configured to register itself with the root NRF204. Notably, the registration messages and / or NF update messages sent by the regional NRF to the root NRF204 include an NF profile that contains "NrfInfo attribute" information. As used herein, the NrfInfo attribute information refers to a minimal amount of data that describes the regional NRF, its registered NF service producer, and the services provided by the registered NF service producer. In some embodiments, the NrfInfo attribute information is an array that includes a list of nfinstance identifiers (i.e., nfinstanceID) corresponding to the various NF service producers registered with the regional NRF.
[0038] In accordance with the 3GPP 29.510 specification, when a regional NRF receives an Nnrf service request (e.g., Nnrf subscription request, Nnrf discovery request, Nnrf access token request, etc.) and does not have the information (e.g., NF service producer identifier) necessary to satisfy the request, the regional NRF is configured to forward the service request to another pre-configured NRF. In a hierarchical deployment, the pre-configured NRF is designated as the "root NRF" (e.g., root NRF 204) of the network. Specifically, the root NRF is configured to process service requests received from regional NRFs within the first region and attempt to identify another regional NRF within a different region that includes a registered NF service producer capable of providing the requested service. More specifically, the root NRF 204 then attempts to forward the service request to a target regional NRF that can further process the service request. The root NRF has NF type information (e.g., <nf-type>Info structure and / or <nf-type>It can store an (InfoList structure), but the root NRF usually does not provide NF service attributes and / or usually does not store NF service attributes mapped to NF service producer instance identifiers.
[0039] Figure 3 depicts a block diagram of a hierarchical network 300 including regional NRFs 301 - 303 that provide NF service attributes (e.g., NF service name information or NF service attribute data) among the customized attributes included in the NrfInfo structure sent to the root NRF. As described above, the service information of a registered NF service producer (i.e., NF service attributes) is not usually propagated or provided to the root NRF by the regional NRF. As a result, in a hierarchical deployment, the root NRF for NF service consumers operating within other regions supported by other regional NRFs cannot quickly discover the NF services (e.g., Nnrf service operations) provided by the NF service producer (because the NF service attributes are not transferred to the root NRF). To illustrate an exemplary scenario, consider an NF service producer 313 1 registering with the regional NRF 303 within region 3. Note that the NF service producer 313 1 is registered with the regional NRF 303. In some embodiments, the NF service producer 313 1 includes an NF profile containing an NF instance identifier (i.e., instance ID), other NF profile attributes (defined in Type: NF Profile in section 6.1.6.2.2 of 3GPP TS 29.510), an info attribute (e.g., <nf-type>Info structure and / or <nf-type>The registration is performed by sending a registration message that includes an InfoList structure, as well as a list of one or more NF service structures (defined in 3GPP TS 29.510, Type: NF Service in Section 6.1.6.2.3) that include the service name provided by the NF service producer and other NF Service attributes, to the (Regional NRF303). After receiving the NF profile from the registered NF service producer, the Regional NRF303 may be configured to send the NF registration request of the NRF (or the NF update registration request of the NRF) to the Route NRF304. It should be noted that the NF registration request of the NRF or the NF update registration request of the NRF (i.e., the NF profile update of the NRF) sent by the Regional NRF to the Route NRF includes the instance ID of the Regional NRF itself, the NF profile attributes of other Regional NRFs (defined in 3GPP TS 29.510, Type: NF Profile in Section 6.1.6.2.2), the NrfInfo attribute (defined in 3GPP TS 29.510, Section 6.1.6.2.31) that includes the update of the info attribute of the producer NF registered with this Regional NRF, and the NF service attributes (i.e., NF service information) provided by the producer NF313 1 A list of NF service attributes (i.e., NF service information) provided by the producer NF313 to the Regional NRF is included.
[0040] NF service producer 313 1 At a certain point after the NF service producer 313 registers with the Regional NRF303, the NF service consumer 311 within Region 1 1 transmits the Nnrf discovery service request for a specific NF service producer to the regional NRF301. NRF301 is configured to transfer the Nnrf discovery service request to the root NRF304 if the regional NRF301 does not include the registration of the NF service producer requested (for example, there is no NF service producer in region 1 that conforms to the discovery criteria in the discovery service request, such as the service type). In some embodiments, the Nnrf discovery service request includes a plurality of mandatory parameters, including a target NF type parameter and a requester NF type parameter. The Nnrf discovery service request can also include an optional "service name" parameter, which indicates a list of specific NF services requested by the NF service consumer.
[0041] After receiving the discovery request transferred from NRF301, the root NRF is typically configured to propagate the Nnrf discovery service request to the regional NRF302 or regional NRF303, because the root NRF does not have knowledge (i.e., does not know about) the NF services provided by the NF service producers in the hierarchical network. It should be noted that the root NRF usually does not receive NF service information or the service names corresponding to the NF service producers through the NF profile updates sent by the regional NRF.
[0042] To address this lack of visibility of the NF service names at the root NRF, the disclosed subject matter provides a mechanism for the root NRF304 to be provided with one or more NF service attributes (such as a list of service names) provided by one or more NF service producer instances via the regional NRF. One scenario depicting an exemplary solution can be similarly depicted using FIG. 3. For example, the NF service producer 313 1 can initiate registration with the regional NRF303 within region 3. It should be noted that the NF service producer 313 1 is the NF profile information (i.e., NF instance identifier (i.e., instance ID)), other NF profile attributes (defined in 3GPP TS 29.510, Section 6.1.6.2.2, Type: NF Profile), info attributes (e.g., <nf-type>Info structure and / or <nf-type>Register with the regional NRF 303 by sending a registration request that includes an InfoList structure, as well as a list of one or more NF service structures (defined in 3GPP TS 29.510, section 6.1.6.2.3, Type: NF Service) that includes the service name and other NF Service attributes provided by the NF service producer during the registration process. NF service producer 313 1 After receiving the NF profile information in the registration request that includes one or more NF service attributes from 1 , the regional NRF 303 may be configured to include the NF service attributes within an NrfInfo structure. Specifically, in response to detecting the presence of NF service attribute information in the received request message, the regional NRF 303 is configured to construct customized attributes (e.g., NF service structures) that are included in the NrfInfo structure that will be sent to the root NRF 304.
[0043] An example of adding a customized NF service structure is shown in FIG. 4, which depicts exemplary NrfInfo attribute entries. For example, column 401 of the NrfInfo structure 400 includes a plurality of NrfInfo attribute entries. Each of these entries is "Served" as shown in the attribute structure 400 <nftype>includes "Info". To explain, the first entry in the NrfInfo structure 400 is "servedAmfInfo", which may include several different AMFs registered with the regional NRF within a specific region. Further, in column 403 of data structure 402, a plurality of NF instance identifiers corresponding to each of the plurality of AMFs registered with the regional NRF are enumerated. The AMF is <nf-type>Info attribute and <nf-type>When supporting the InfoList attribute, the AMF instance ID is added to column 403, and its corresponding InfoStructure information (i.e., <nf-type>Info and / or <nf-type>The attribute data of InfoList) is added to column 404 (for example, in column 404 <nf-type>InfoStructure1 is mapped to "InstanceID1" that identifies the AMF in column 403). Similarly, the NF service attributes corresponding to the AMF instance ID are added to column 406 when provided from the AMF service producer to the regional NRF (e.g., service name attribute). More specifically, the regional NRF is configured to construct and add a customized structure (e.g., <NF service>) that is linked or mapped to the InfoStructure information in column 404 and / or the "InstanceIDs" specified in column 403.
[0044] Returning to FIG. 3, the regional NRF 303 includes, within the NrfInfo structure (in the NF profile update message of the regional NRF), one or more customized <nf-services>Construct the structure. The regional NRF303 then has NF service attribute information and / or <nf-services>Insert the structure as a subsection and / or entry into the NrfInfo structure. Thereafter, a registration request and / or an NF update request (e.g., NF profile update) containing NrfInfo is sent by the regional NRF303 to the root NRF304. An example of an NrfInfo schema containing a constructed and customized NF service structure is described below and illustrated in FIG. 5.
[0045] After NrfInfo is provided to the root NRF304, the root NRF304 is configured to store, in its local state database 306, the supported NF services of each registered NF (shared by the regional NRF), along with other info attributes shared for each registered NF. In some embodiments, the root NRF304 is configured to extract custom information including NF service attributes from the registration request and / or NF update request received from the regional NRF and create a new entry in the local state database 306 including NF profile information and NF service attributes. It should be noted that the NF service attributes are indexed or mapped to the instance ID of the NF service producer providing the NF service. Note that the storage and / or indexing of NF service attributes in the local state database depends on the implementation, and the disclosed subject matter is not limited in scope by the examples presented herein. After storing and indexing the NF service attributes, the root NRF304 will then, as a result, own a list of the NF services provided by each of these registered NF service producers, in addition to the regional NRF profile of the regional NRF303 and the nfinstanceID of all NF service producers registered with the regional NRF303.
[0046] After the root NRF304 provisions the NF service attributes in the local state database 306 as described above, an NF service consumer 311 within region 1 can send an Nnrf service request (e.g., a discovery request) for a specific NF service producer to the NRF301. In some embodiments, the service request message may include i) a target NF type, ii) a requester NF type, and iii) a service name. The regional NRF301 is configured to forward the discovery request to the root NRF304 if the regional NRF301 does not have a registration of an NF service producer that can support the requested service (e.g., there is no NF service producer in region 1 that meets the discovery criteria in the discovery request from the NF service consumer 311 1 ). In addition to providing the target NF type information generally included in the forwarded discovery request message, the regional NRF will also provide the relevant service attributes in the request message.
[0047] After receiving the discovery request forwarded from the regional NRF301, the root NRF304 is configured to access its local state information database that includes NrfInfo from the regional NRFs 301 - 303. In particular, the root NRF304 is configured to attempt to find a database entry that includes an indexed entry associated with an NF service identifier that matches the NF service name (as a parameter service name) included in the forwarded discovery request message. It should be noted that the root NRF304 is configured to inspect the state information database to check all NrfInfo data using smart logic. For example, the root NRF304 is configured to identify / select a specific regional NRF that has a specific NF service producer that can provide the service indicated by the NF service name, using the matching NF service name and the corresponding instance identifier.
[0048] In some cases, the root NRF 304 may identify multiple NF service producers (hosted, for example, by the regional NRFs 302 and 303). In a scenario where two or more NF service consumers are identified as being able to provide the service corresponding to the service name, the root NRF 304 may be configured to generate an ordered list indicating the specific NF service producers (and their respective NRFs) that handle the service request message. After generating the list containing the ordered NF service producer information, the root NRF 304 can transfer the Nnrf service request to the appropriate regional NRF (for example, regional NRF 303) for further processing. In particular, the root NRF 304 can quickly identify the NF service producers that support the requested NF service while operating in different regions in a hierarchical network deployment.
[0049] Figure 5 shows a schema of the NrfInfo structure communicated to the root NRF, including an NF service structure (with a service name attribute). As shown in Figure 5, the NrfInfo structure 500 includes a PcfInfo instance. In particular, the PcfInfo instance 502 includes the nfinstanceID (for example, 5e23ebb0-c493...) of a specific PCF instance operating in the local region. It should be noted that the regional NRF is configured to construct the NrfInfo structure 500 using the custom data of all registered NFs (such as the PcfInfo instance 502) including its nfServices structure or nfServiceList structure 504 in the NF registration message or NF update message directed to the root NRF. Note that the NrfInfo structure 500 with the nfServices structure 504 is an example of the information inserted into the NF profile update message directed to the root NRF. The content of the nfServices structure or nfServiceList structure 504 shall comply with 3GPP TS 29.510.
[0050] Figure 6 is a flowchart illustrating an exemplary process for utilizing network function service attributes associated with a network function service producer registered in a hierarchical network, according to an embodiment of the subject matter described herein. In some embodiments, method 600 depicted in Figure 6 is an algorithm, program, or script stored in memory that, when executed by a processor, performs the steps described in blocks 602-606. In some embodiments, method 600 represents a list of steps that are embodied in a state machine and / or in the logic of the NRF and / or in a host computing device (e.g., either via software code programming or via a set of rules).
[0051] In block 602, the method includes a root NRF operating in a hierarchical network receiving an NF registration message or an NF update message from a regional NRF operating within a first region of the hierarchical network. Notably, the NF registration message or the NF update message includes an NrfInfo structure that includes one or more NF service attributes that specify one or more NF services provided by at least one NF service producer registered with the regional NRF. In some embodiments, the root NRF operating in the hierarchical network receives an NF profile update message that includes a list of NF services supported by an NF service consumer registered with a particular regional NRF.
[0052] In block 604, the method includes the root NRF extracting one or more NF service attributes from the NrfInfo structure. In some embodiments, the root NRF is configured to parse the NrfInfo structure in a request message and extract one or more NF service attributes from the NF profile update message.
[0053] In block 606, the method includes the root NRF creating one or more indexed entries in the local state information database that include one or more NF service attributes. In some embodiments, the root NRF is configured to construct customized data entries in its local state information data to record the extracted NF service attributes for each NF service.
[0054] Note that the modified regional NRF, modified root NRF, and / or functionality described herein may constitute, or may be facilitated by, a dedicated computing device. Further, the modified NRF and / or functionality described herein can improve the technical field of network visibility by enabling the root NRF to store NF service attributes that can be used to quickly identify NF service producers that can support the required NF services. Notably, the root NRF will route and / or re-route discovery request messages only to the regional NRF that supports the NF service consumer identified as providing the requested service. In particular, implementing the use of NF service attributes in the manner described herein eliminates some of the random trials to find NF service consumers (without NF service attributes), significantly reducing unnecessary packet traffic.
[0055] The disclosure of each of the following references is hereby incorporated by reference in its entirety. References 1. 3 rd Generation Partnership Project; Technical Specification 5G; 5G System; Network function repository services; Stage 3 (Release 16) 3GPP TS 29.510 V16.5.0 (2020-11) 2.3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Technical Realization of Service Based Architecture; Stage 3 (Release 16) 3GPP TS 29.500 V16.5.0 (2020-11) It will be understood that various details of the subject matter disclosed herein may be changed without departing from the scope of the subject matter disclosed herein. Further, the foregoing description is for illustrative purposes only and not for purposes of limitation. < / nftype>
Claims
Claim 1 In a hierarchical network, a method for using network function (NF) service attributes associated with a registered network function service producer, comprising: A root network function repository function (NRF) operating in the hierarchical network receives an NF registration message or an NF update message from a regional NRF operating within a first region of the hierarchical network, the NF registration message or NF update message including an NrfInfo structure including one or more NF service attributes specifying one or more NF services provided by at least one NF service producer registered with the regional NRF; The method further comprises: The root NRF extracts the one or more NF service attributes from the NrfInfo structure; and The root NRF creates one or more indexed entries including the one or more NF service attributes in a local state information database. Claim 2 The method according to claim 1, wherein the root NRF is configured to direct a service request message received from a second regional NRF to the regional NRF using the one or more NF service attributes stored in the local state information database. Claim 3 The method according to claim 2, wherein the service request message includes at least one of an Nnrf subscription request message, an Nnrf discovery request message, or an Nnrf access token request message. Claim 4 The method according to any of the preceding claims, wherein the regional NRF is configured to insert the one or more NF service attributes into the NrfInfo structure as customized attributes. Claim 5 The method according to claim 4, wherein the customized attributes include a customized NF service structure specifying the one or more NF services. Claim 6 The method according to any of the preceding claims, wherein the NrfInfo structure is provided to the root NRF via an NF profile update message transmitted by the regional NRF. Claim 7 The method according to any one of the preceding claims, wherein the NrfInfo structure is a JavaScript Object Notation (JSON) data structure. **Claim 8** A system for utilizing network function (NF) service attributes associated with a registered network function service producer in a hierarchical network, the system comprising: A regional NRF that operates within a first region of the hierarchical network and is configured to generate an NF registration message or an NF update message; A root network function repository function (NRF) that operates in a hierarchical network and includes a local state information database; The local state information database is configured to receive the NF registration message or the NF update message from the regional NRF, the NF registration message or NF update message including an NrfInfo structure including one or more NF service attributes specifying one or more NF services provided by at least one NF service producer registered with the regional NRF, the local state information database being configured to extract the one or more NF service attributes from the NrfInfo structure and create one or more indexed entries including the one or more NF service attributes in the local state information database. **Claim 9** The system according to claim 8, wherein the root NRF is configured to direct a service request message received from a second regional NRF to the regional NRF using the one or more NF service attributes stored in the local state information database. **Claim 10** The system according to claim 9, wherein the service request message includes at least one of an Nnrf subscription request message, an Nnrf discovery request message, or an Nnrf access token request message. **Claim 11** The system according to any one of claims 8 to 10, wherein the regional NRF is configured to insert the one or more NF service attributes into the NrfInfo structure as customized attributes. **Claim 12** The system according to claim 11, wherein the customized attribute includes a customized NF service structure that specifies the one or more NF services.
13. The system according to any one of claims 8 to 12, wherein the NrfInfo structure is provided to the root NRF via an NF profile update message transmitted by the regional NRF.
14. The system according to any one of claims 8 to 13, wherein the NrfInfo structure is a JavaScript Object Notation (JSON) data structure.
15. One or more non-transitory computer-readable media storing executable instructions that, when executed by at least one processor of a computer, cause the computer to perform steps, the steps comprising: A root network function repository function (NRF) operating in a hierarchical network receives an NF registration message or an NF update message from a regional NRF operating within a first region of the hierarchical network, the NF registration message or NF update message including an NrfInfo structure including one or more NF service attributes that specify one or more NF services provided by at least one NF service producer registered with the regional NRF. The steps include: The root NRF extracting the one or more NF service attributes from the NrfInfo structure. One or more non-transitory computer-readable media, the steps comprising the root NRF creating one or more indexed entries including the one or more NF service attributes in a local state information database.
16. The one or more non-transitory computer-readable media according to claim 15, wherein the root NRF is configured to direct a service request message received from a second regional NRF to the regional NRF using the one or more NF service attributes stored in the local state information database.
17. The one or more non-transitory computer-readable media according to claim 16, wherein the service request message includes at least one of an Nnrf subscription request message, an Nnrf discovery request message, or an Nnrf access token request message.
18. The one or more non-transitory computer-readable media according to any one of claims 15 to 17, wherein the regional NRF is configured to insert the one or more NF service attributes into the NrfInfo structure as customized attributes.
19. The one or more non-transitory computer-readable media according to claim 18, wherein the customized attribute includes a customized NF service structure that specifies the one or more NF services.
20. The one or more non-transitory computer-readable media according to any one of claims 15 to 19, wherein the NrfInfo structure is provided to the root NRF via an NF profile update message transmitted by the regional NRF.