Methods, systems, and computer readable media for leveraging network function (NF) service attributes associated with NF service producers registered in hierarchical network

Abstract

Methods, systems, and computer readable media are disclosed for utilizing network function (NF) service attributes associated with network function service producers registered in a hierarchical network. In one embodiment, a 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 region NRF operating in a first region of the hierarchical network, where the NF registration message or the NF update message includes an NrfInfo structure including one or more NF service attributes, the one or more NF service attributes specify one or more NF services provided by at least one NF service producer registered with the regional NRF. The method further includes extracting, by the root NRF, one or more NF service attributes from the NrfInfo structure, and creating, by the root NRF, one or more index entries containing the one or more NF service attributes in a local state information database.

Description

[0001] Priority claim

[0002] This application claims priority to U.S. Patent Application No. 17 / 751,584, filed on May 23, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The subject matter described herein relates to registration and management of network function (NF) service producers in fifth generation (5G) communication networks. More specifically, the subject matter described herein relates to methods, systems, and computer-readable media for utilizing NF service attributes associated with registered NF service producers in a hierarchical network. Background Art

[0004] In telecommunications networks, a service endpoint is an address on a network node that uniquely identifies an entity that provides services to service consumers. A service endpoint may include an Internet Protocol (IP) address or a combination of an IP address and a transport layer port number, also known as an IP endpoint.

[0005] In the fifth generation (5G) telecommunication network, the network node that provides services is called a network function (NF) service producer. The network node that consumes services is called an NF service consumer. Depending on whether the network function is consuming services or providing services, it can be either an NF service producer or an NF service consumer.

[0006] A given NF service producer can have many service endpoints. NF service producers register with the Network Repository Function (NRF). NRF maintains NF profiles of available NF instances and the services they support. Consumer NFs can subscribe to receive information about NF service producer instances that have registered with NRF. Once registered, NF instances in a 5G network can establish sessions with one or more Network Exposure Functions (NEFs). It is worth noting that NEF is a 3rd Generation Partnership Project (3GPP) network function that provides a method to securely expose services and capabilities provided by producer network functions serving the network.

[0007] In many instances, a 5G network may be divided into multiple regions based on a hierarchical deployment. In such a configuration, a root NRF must be designated and configured to communicate with multiple regional NRFs located 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. Per 3GPP 29.510, if an NRF receives an Nnrf service request (e.g., a service request such as a subscription request, a discovery request, or an access token service request) and the NRF does not have the information required to satisfy the request, the NRF forwards the service request to a preconfigured NRF. In a hierarchical deployment, the root NRF is assigned as a preconfigured NRF.

[0008] In some embodiments, the root NRF prepares state data from NF updates received from regional NRFs. In addition, for each Nnrf service or discovery request forwarded from a regional NRF to the root NRF, the root NRF uses its state data to determine and specify a target regional NRF that can service the request. In particular, the root NRF is configured to process the forwarded Nnrf service request and attempt to identify a regional NRF that has a registered NF service producer that can service the request (e.g., the root NRF references a stored <nf-type>Info and <nf-type>InfoList attribute data and a mapped nf instance identifier associated with the NF service producer). As used herein, <nf-type>Info and <nf-type>InfoList can also be expressed as xxxinfo and xxxinfolist. <nf-type>Info or "xxx" indicates a specific NF type according to 3GPP 29.510 section 6.1.6.3.3.

[0009] However, because the Root NRF is typically not provided with information detailing the specific services supported / provided by the NF Service Producer, the Root NRF may unnecessarily forward the Nnrf Service Request to multiple Regional NRFs in an attempt to locate an appropriate Regional NRF (and NF Service Producer) that can adequately handle the Service Request. More specifically, the ability of the Root NRF to determine the target Regional NRF that can serve the request is limited by the information previously provided by the Regional NRF. <nf-type>Info and <nf-type>The content of the attribute data in the InfoList structure. However, <nf-type>Info and <nf-type>The InfoList structure obviously does not contain any information about the NF Services registered by the NF (whose information has been synchronized to the Root NRF by the Regional NRF). Without knowing which NF Services a given NF (and Regional NRF) supports, the Root NRF would need to ignore any NF Service parameters in the request and determine the target Regional NRF based solely on the NF-Type information. As described above, this deficiency forces the Root NRF to repeatedly reroute the request to another Regional NRF. Therefore, this behavior of the Root NRF is considered inefficient and creates considerable transaction delays in the network.

[0010] Therefore, there is a need for improved methods and systems for utilizing network function service attributes associated with registered network function service producers in a hierarchical network. Summary of the invention

[0011] The present application discloses a method, system and computer-readable medium for utilizing network function (NF) service attributes associated with a network function service producer registered in a hierarchical network. A method includes receiving, by a root network function repository function (NRF) operating in a hierarchical network, a NF registration message or a NF update message from a regional NRF operating in a first region of the hierarchical network, wherein the NF registration message or the NF update message includes an NrfInfo structure, the NrfInfo structure containing one or more NF service attributes, the 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 also includes extracting, by the root NRF, the one or more NF service attributes from the NrfInfo structure, and creating, by the root NRF, one or more index entries containing the one or more NF service attributes in a local state information database.

[0012] 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.

[0013] 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.

[0014] According to another aspect of the method described herein, the regional NRF is configured to insert one or more NF service attributes as custom attributes into the NrfInfo structure.

[0015] According to another aspect of the method described herein, the customized attributes include a customized NF service structure specifying one or more NF services.

[0016] According to another aspect of the method described herein, the NrfInfo structure is provided to the root NRF via a NF Profile Update message sent by the regional NRFs.

[0017] According to another aspect of the method described herein, the NrfInfo structure is a JavaScript Object Notation (JSON) data structure.

[0018] According to another aspect of the disclosed subject matter described herein, a system for utilizing one or more NF service attributes associated with a network function service producer registered in a hierarchical network includes a regional NRF operating in a first region of the hierarchical network, configured to generate an NF registration message or an NF update message. The system also includes a root NRF operating in the hierarchical network and including a local state information database, the root network function repository function (NRF) configured to receive the NF registration message or the NF update message from the regional NRF, wherein the NF registration message or the NF update message includes an NrfInfo structure containing one or more NF service attributes, the 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, extracting the one or more NF service attributes from the NrfInfo structure, and creating one or more index entries containing the one or more NF service attributes in the local state information database.

[0019] 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 a local state information database.

[0020] According to another aspect of the system 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.

[0021] According to another aspect of the system described herein, the regional NRF is configured to insert one or more NF service attributes as custom attributes into the NrfInfo structure.

[0022] According to another aspect of the system described herein, the customized attributes include a customized NF service structure specifying one or more NF services.

[0023] According to another aspect of the system described herein, the NrfInfo structure is provided to the root NRF via a NF Profile Update message sent by a regional NRF.

[0024] According to another aspect of the system described herein, the NrfInfo structure is a JSON data structure.

[0025] The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. Therefore, the terms "function", "node", or "module" as used herein refer to hardware used to implement the described features, which may also include software and / or firmware components. In an example embodiment, the subject matter described herein may be implemented using one or more computer-readable media having computer-executable instructions stored thereon, which, when executed by a processor of a computer, control the computer to perform steps. Example computer-readable media suitable for implementing the subject matter described herein include non-transient computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. In addition, the computer-readable media that implement the subject matter described herein may be located on a single device or computing platform, or may be distributed across multiple devices or computing platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The subject matter described herein will now be explained with reference to the accompanying drawings:

[0027] Figure 1 is a network diagram illustrating an example of a fifth generation (5G) network architecture;

[0028] Figure 2 is a block diagram illustrating a network including a plurality of network function repository functions (NRFs) operating in a hierarchical deployment;

[0029] Figure 3 is a block diagram illustrating a network including multiple NRFs utilizing NF service attributes while operating in a hierarchical deployment;

[0030] Figure 4 is a diagram showing an exemplary NrfInfo, <nf-type>Diagram of Info data structure and NF service attribute structure;

[0031] Figure 5 is a diagram showing an exemplary schema of an NrfInfo structure including NF service attributes transmitted to a root NRF; and

[0032] Figure 6 is a flow chart illustrating an exemplary method for utilizing network function service attributes associated with a registered network function service producer in a hierarchical network. DETAILED DESCRIPTION

[0033] The subject matter described herein relates to methods, systems, and computer-readable media for utilizing network function service attributes associated with network function service producers registered in a hierarchical network. In particular, the disclosed subject matter includes methods and systems that enable regional NRFs in a hierarchical network to share NF service information of each registered NF with a root NRF via an NF configuration file update. In some embodiments, the root NRF is configured to store the supported NF service information of each NF (shared by the regional NRFs) in its local state information database. Upon subsequent receipt of NF discovery, subscription, and access token requests indicating the requested service, the root NRF accesses its local state information database to identify matching NFs and the corresponding regional NRFs with which these NFs are registered, and sends a heartbeat message. It is noteworthy that the root NRF only routes and / or reroutes to the identified regional NRFs to avoid unnecessary and / or wasteful communication attempts.

[0034] Reference will now be made in detail to various embodiments of the subject matter described herein, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or like parts.

[0035] Figure 1 is a block diagram illustrating an example of a 5G system network architecture, such as a home 5G core (5GC) network. Figure 1 The architecture in includes NRF 100 and SCP 101, which can be located in the same home PLMN public land mobile network (PLMN). As described above, NRF 100 can maintain the profiles of available NF service producer service instances and the services they support, and allow consumer NF or SCP to subscribe to new / updated NF service instances and get notifications of registration of new / updated NF service instances. SCP101 can also support service discovery and selection of NF instances. SCP 101 can perform load balancing of connections between consumers and NF service producers. In addition, using the method described herein, SCP 101 can perform preferred selection and routing based on NF location.

[0036] The NRF 100 is a repository of service profiles of NFs or NF instances. In order to communicate with NF instances, a consumer NF or SCP must obtain a NF service profile or NF instance from the NRF 100. The NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP Technical Specification (TS) 29.510. The NF or service profile definition includes at least one of a fully qualified domain name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address. Figure 1 In the example shown, any node (except NRF 100) can be a consumer NF or a NF service producer, depending on whether they are requesting or providing services. In the example shown, the nodes include a policy control function (PCF) 102 that performs policy-related operations in the network, a unified data management (UDM) function 104 that manages user data, and an application function (AF) 106 that provides application services. Figure 1 The nodes shown in FIG. 1 also 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 user equipment (UE) 114) seeking access to the network.

[0037] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices seeking to access specific network capabilities and features associated with a network slice. The Network Exposure Function (NEF) 118 provides an Application Programming Interface (API) for application functions seeking to obtain information about Internet of Things (IoT) devices and other UEs attached to the network. The NEF 118 performs functions similar to the Service Capability Exposure Function (SCEF) in 4G networks.

[0038] Radio access network (RAN) 120 connects UE 114 to the network via a wireless link. g-Node B (gNB) ( Figure 1 The UE 114 may use a wireless access point (not shown) or other wireless access point to access the radio access network 120. The user plane function (UPF) 122 may support various proxy functions for user plane services. An example of such a proxy function is a multipath transmission control protocol (MPTCP) proxy function. The UPF 122 may also support a performance measurement function that the UE 114 may use to obtain network performance measurements. Figure 1 Also shown is a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0039] Security edge protection proxy (SEPP) 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with SEPP in the external PLMN that manages the security of the external PLMN. Therefore, traffic between NFs in different PLMNs may pass through two SEPP functions, one SEPP function for the home PLMN and another SEPP function for the external PLMN. In some embodiments, the SEPP is a gateway device located at the edge of the network.

[0040] SEPP 126 can utilize N32-c interface and N32-f interface. N32-c interface is a control plane interface between two SEPPs, which can be used to perform initial handshake (e.g., TLS handshake) and negotiate various parameters of N32-f interface connection and related message forwarding. N32-f interface is a forwarding interface between two SEPPs, which can be used to forward various communications (e.g., 5GC requests) between consumer NF and NF service producer after applying application-level security protection.

[0041] As mentioned above, when two or more NRF segments are supported in a given network, such as a public land mobile network (PLMN), it is usually necessary to deploy an NRF layered system. Figure 2 A hierarchical network 200 including multiple regional NRFs 201-203 and a root NRF 204 is depicted. Notably, each of the regional NRFs 201-203 is located in a separate network segment or region. Each regional NRF is configured to provide management, discovery, and access token services to registered regional NFs (e.g., NF profile updates for both NF service consumers and NF service producers). The regional NRFs 201-203 may also be configured to forward Nnrf discovery, subscription, and access token service requests to the root NRF 204 if a particular service request from a NF service consumer cannot be serviced by the regional NRF (and / or its registered NF service producer in the region) that originally received the service request from the NF service consumer.

[0042] In some embodiments, the root NRF 204 may be part of and / or reside in any segment of the hierarchical network 200. For high availability purposes, the root NRF 204 may also be deployed as a geographically redundant element. Figure 2 Each of the regional NRFs 201-203 and the root NRF 204 depicted in FIG. 2 includes redundant failover backups (e.g., three instances of each regional NRF in each region). That is, Figure 2 The failover backup shown in represents a three-way redundancy measure employed by the operator(s) of the hierarchical network 200.

[0043] In some embodiments, the root NRF 204 is designated and configured to communicate with each of a plurality of regional NRFs 201-203 located and / or operating in various regions of the PLMN. More specifically, each of the regional NRFs 201-203 is configured to register itself with the root NRF 204. It is noteworthy that the registration message and / or NF update message sent by the regional NRF to the root NRF 204 contains an NF profile, including "NrfInfo attribute" information. As used herein, NrfInfo attribute information refers to the minimum amount of data that describes the regional NRF, its registered NF service producers, and the services provided by the registered NF service producers. In some embodiments, the NrfInfo attribute information is an array that contains a list of NF instance identifiers (i.e., NF instance IDs) corresponding to the various NF service producers registered with the regional NRF.

[0044] According to the 3GPP 29.510 standard, if a regional NRF receives an Nnrf service request (e.g., a service request such as an Nnrf subscription request, an Nnrf discovery request, or an Nnrf access token request) and does not have the information required to satisfy the request (e.g., an NF service producer identifier), the regional NRF is configured to forward the service request to another preconfigured NRF. In a hierarchical deployment, the preconfigured NRF is designated as the "root NRF" of the network (e.g., root NRF 204). Specifically, the root NRF is configured to process the received service request from the regional NRF in the first region and attempt to identify another regional NRF in a different region that includes a registered NF service producer that can provide the requested service. More specifically, the root NRF 204 may then attempt to forward the service request to the target regional NRF, which may further process the service request. Although the root NRF may store information including NF type information (e.g., <nf-type>Info and / or <nf-type>InfoList structure), but the NF Service Attributes are usually not provided to the Root NRF and / or the Root NRF usually does not store the NF Service Attributes mapped to the NF Service Producer Instance Identifier.

[0045] Figure 3 A block diagram of a hierarchical network 300 is depicted, which includes regional NRFs 301-303 that provide NF service attributes (e.g., NF service name information or NF service attribute data) in custom attributes contained in the NrfInfo structure sent to the root NRF. As described above, the service information (i.e., NF service attributes) of registered NF service producers are generally not propagated or provided to the root NRF by the regional NRFs. Therefore, in a hierarchical deployment, NF services (e.g., Nnrf service operations) provided by NF service producers cannot be quickly discovered by the root NRF of NF service consumers operating in other regions supported by other regional NRFs (because the NF service attributes are not forwarded to the root NRF). To illustrate an example scenario, consider that NF service producer 3131 registers with regional NRF 303 in region 3. It is worth noting that NF service producer 3131 registers with regional NRF 303. In some embodiments, the NF Service Producer 3131 registers by sending a registration message (to the Regional NRF 303), the registration message containing the NF profile, the NF profile including the NF instance identifier (i.e., instance ID), other NF profile attributes (as defined in 3GPP TS 29.510 Section 6.1.6.2.2 "Type: NF profile"), information attributes (such as <nf-type>info and / or <nf-type>InfoList structure) and a list of one or more NF Service structures including the service name and other NF service attributes provided by the NF Service Producer (as defined in 3GPP TS29.510 Section 6.1.6.2.3 "Type: NF Service"). After receiving the NF Profile from the registered NF Service Producer, the Regional NRF 303 can be configured to send an NRF's NF Registration Request (or an NRF's NF Update Registration Request) to the Root NRF 304. It is worth noting that the NRF's NF Registration Request or NRF's NF Update Registration Request (i.e., NRF's NF Profile Update) sent by the regional NRF to the root NRF contains the instance ID of the regional NRF itself, the NF profile attributes of other regional NRFs (as defined in 3GPP TS29.510 Section 6.1.6.2.2 "Type: NF profile"), the NrfInfo attribute containing the information attribute update of the producer NF registered with the regional NRF (as defined in 3GPP TS29.510 Section 6.1.6.2.31), and the NF service attribute list (i.e., NF Service Information) provided by the producer NF 3131 to the regional NRF.

[0046] At some point after the NF service producer 3131 registers with the regional NRF 303, the NF service consumer 3111 in region 1 sends a Nnrf discovery service request for a specific NF service producer to the regional NRF 301. If the regional NRF 301 does not include a registration for the requested NF service producer (e.g., there is no NF service producer in region 1 that matches the discovery criteria (such as service type) in the discovery service request), the NRF 301 is configured to forward the Nnrf discovery service request to the root NRF 304. In some embodiments, the Nnrf discovery service request includes multiple mandatory parameters, including a target NF type parameter and a requester NF type parameter. The Nnrf discovery service request may also include an optional "service name" parameter that indicates a list of specific NF services that the NF service consumer is requesting.

[0047] After receiving the forwarded discovery request from NRF 301, the root NRF is usually configured to propagate the Nnrf discovery service request to the regional NRF 302 or regional NRF 303, because the root NRF is not aware of (i.e., does not understand) the NF services provided by the NF service producers in the hierarchical network. It is worth noting that the root NRF usually does not receive the NF service information or service name corresponding to the NF service producer via the NF configuration file update sent by the regional NRF.

[0048] To remedy the lack of NF service name visibility at the root NRF, the disclosed subject matter provides a mechanism where one or more NF service attributes (e.g., a list of service names) provided by one or more NF service producer instances via the regional NRFs are provided to the root NRF 304. A scenario depicting an exemplary solution can also be used Figure 3 For example, the NF service producer 3131 may initiate registration with the regional NRF 303 in region 3. It is worth noting that the NF service producer 3131 registers with the regional NRF 303 by sending a registration request, which includes NF profile information (i.e., NF instance identifier (i.e., instance ID), other NF profile attributes (as defined in 3GPP TS 29.510 Section 6.1.6.2.2 "Type: NF profile"), information attributes (e.g., <nf-type>info and / or <nf-type>The regional NRF 303 may include a list of one or more NF service structures including a service name and other NF service attributes provided by the NF service producer during the registration process (as defined in 3GPP TS29.510 Section 6.1.6.2.3 "Type: NF Service"), and a list of one or more NF service structures including a service name and other NF service attributes provided by the NF service producer during the registration process. After receiving the NF profile information in the registration request including one or more NF service attributes from the NF service producer 3131, the regional NRF 303 may be configured to include the NF service attributes in the 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 custom attributes (e.g., NF service structures) to be included in the NrfInfo structure to be sent to the root NRF 304.

[0049] An example of adding a custom NF service structure is as follows Figure 4 As shown, the figure depicts exemplary NrfInfo attribute entries. For example, column 401 of NrfInfo structure 400 includes multiple NrfInfo attribute entries. Each of these entries includes "Served <nf-type>Info", as shown in attribute structure 400. For illustration, the first entry in NrfInfo structure 400 is "servedAmfInfo", which may include multiple different AMFs registered with the regional NRF in a particular region. In addition, column 403 of data structure 402 lists multiple NF instance identifiers corresponding to the corresponding multiple AMFs registered with the regional NRF. If the AMF supports <nf-type>Info and <nf-type>InfoList attribute, the instance ID of the AMF is added to column 403, and the corresponding InfoStructure information (i.e. <nf-type>Info and / or <nf-type>InfoList attribute data) to column 404 (e.g., <nf-type>InfoStructure1 is mapped to the "InstanceID1" of the AMF in the identification column 403). Similarly, if the AMF Service Producer provides the Regional NRF with (one or more) NF Service Attributes corresponding to the AMF Instance ID, they are added to column 406 (e.g., Service Name Attribute). More specifically, the Regional NRF is configured to build and add a customized structure that links or maps to the InfoStructure information in column 404 and / or the "InstanceIDs" specified in column 403 (e.g., <nf-service>).

[0050] Back to Figure 3 , the regional NRF 303 builds one or more customized NrfInfo structures (in the NF Profile Update message of the regional NRF) <nf-service>Then, the regional NRF 303 sends the NF service attribute information and / or <nf-service>The structure is inserted into the NrfInfo structure as a sub-section and / or entry. Afterwards, the regional NRF 303 sends a registration request and / or NF update request (e.g., NF profile update) containing NrfInfo to the root NRF 304. An example NrfInfo schema containing a built customized NF service structure is described below, such as Figure 5 shown.

[0051] After providing the NrfInfo to the root NRF 304, the root NRF 304 is configured to store the supported NF services of each registered NF (shared by the regional NRFs) and other information attributes shared for each registered NF in its local state database 306. In some embodiments, the root NRF 304 is configured to extract the customized information including the 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, which contains the NF profile information and (one or more) NF service attributes. It is worth noting that the NF service attributes are indexed or mapped to the instance ID of the NF service producer that provides the NF service. It should be noted that the storage and / or indexing of the 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 shown herein. After storing and indexing the NF service attributes, the root NRF 304 will have the regional NRF profile of the regional NRF 303 and the nf instance IDs of all NF service producers registered with the regional NRF 303 and the list of NF services provided by each of these registered NF service producers.

[0052] As described above, after the root NRF 304 configures the local state database 306 with NF service attributes, the NF service consumer 311 in region 1 may send an Nnrf service request (e.g., a discovery request) for a specific NF service producer to the NRF 301. In some embodiments, the service request message may include i) the target NF type, ii) the requester NF type, and iii) the service name. If the regional NRF 301 does not have a registration of a NF service producer that can support the requested service (e.g., there is no NF service producer in region 1 that matches the discovery criteria in the discovery request from the NF service consumer 3111), the regional NRF 301 is configured to forward the discovery request to the root NRF 304. In addition to providing the target NF type information that is typically included in the forwarded discovery request message, the regional NRF will also provide the associated service attributes in the request message.

[0053] Upon receiving the forwarded discovery request from the regional NRF 301, the root NRF 304 is configured to access its local state information database, which contains the NrfInfo from the regional NRFs 301-303. In particular, the root NRF 304 is configured to attempt to find a database entry that includes an index entry associated with an NF service identifier that matches the NF service name included in the forwarded discovery request message (as a parameter service name). It is worth noting that the root NRF 304 is configured to check the state information database to check all NrfInfo data using intelligent logic. For example, the root NRF 304 is configured to use a matching NF service name and a corresponding instance identifier to identify / select a specific regional NRF with an identified NF service producer that can provide the service indicated by the NF service name.

[0054] In some instances, the root NRF 304 may identify multiple NF service producers (e.g., hosted by the regional NRFs 302 and 303). In this case, when more than one NF service consumer is 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 process the service request message. After generating the list including the ordered NF service producer information, the root NRF 304 is able to forward the Nnrf service request to the appropriate regional NRF (e.g., regional NRF 303) for further processing. Notably, the root NRF 304 is able to quickly identify NF service producers that support the requested NF service, which operate in different regions in a hierarchical network deployment.

[0055] Figure 5 is a diagram showing the schema of the NrfInfo structure, which includes the NF Service structure (with the Service Name attribute) and is transmitted to the Root NRF. Figure 5 As shown, the NrfInfo structure 500 includes a PcfInfo instance. Specifically, the PcfInfo instance 502 includes the nf instance ID of a specific PCF instance operating in the local area (e.g., 5e23ebb0-c493...). It is worth noting that the regional NRF is configured to construct the NrfInfo structure 500 in the NF registration message or NF update message toward the root NRF using the customized data of all registered NFs (e.g., the PcfInfo instance 502), and the customized data includes the nfServices or nfServiceList structure 504 of all registered NFs. It is worth noting that the NrfInfo structure 500 with the nfServices structure 504 is an example of information inserted into the NF profile update message pointing to the root NRF. The content of the nfServices or nfServiceList structure 504 should comply with 3GPP TS29.510.

[0056] Figure 6 A flowchart illustrating an example 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. Figure 6 The method 600 shown in is an algorithm, program or script stored in a memory that, when executed by a processor, performs the steps described in blocks 602-606. In some embodiments, the method 600 represents a list of steps embodied in a state machine (e.g., programmed via software code or via a set of rules) and / or logic of the NRF and / or host computing device.

[0057] In block 602, the method includes receiving, by a root NRF operating in a hierarchical network, a NF registration message or a NF update message from a regional NRF operating in a first region of the hierarchical network. Notably, the NF registration message or the NF update message includes an NrfInfo structure containing one or more NF service attributes, the 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. In some embodiments, the root NRF operating in the hierarchical network receives a NF profile update message including a list of NF services supported by a NF service consumer registered with a particular regional NRF.

[0058] In block 604, the method includes extracting, by the root NRF, one or more NF service attributes from the NrfInfo structure. In some embodiments, the root NRF is configured to parse the NrfInfo structure in the request message and extract one or more NF service attributes from the NF profile update message.

[0059] In block 606, the method includes creating, by the root NRF, one or more index entries in the local state information database containing the one or more NF service attributes. In some embodiments, the root NRF is configured to construct a customized data entry in its local state information database to record the extracted (one or more) NF service attributes of each NF service.

[0060] It should be noted that the modified regional NRFs, modified root NRFs and / or functionality described herein may constitute or be facilitated by a dedicated computing device. In addition, the modified NRFs and / or functionality described herein may improve the technical field of network visibility by allowing the root NRF to store (one or more) NF service attributes, which can be used to quickly identify NF service producers that can support the requested NF service. Notably, the root NRF will only route and / or reroute discovery request messages to regional NRFs that support NF service consumers identified as providing the requested service. In particular, because the number of random attempts to locate NF service consumers (without NF service attributes) is eliminated, the ability to utilize NF service attributes in the manner described herein significantly reduces unnecessary packet traffic.

[0061] The disclosures of the following referenced documents are incorporated herein by reference in their entirety.

[0062] References

[0063] 1.3rd 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) (3rd Generation Partnership Project; 5G Technical Specification; 5G System; Network function repository services; Stage 3 (Release 16) 3GPP TS 29.510 V16.5.0 (2020-11))

[0064] 2.3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Technical Realization of Service Based Architecture; Stage 3 (Release 16) 3GPP TS29.500 V16.5.0 (2020-11) (3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Technical Realization of Service Based Architecture; Stage 3 (Release 16) 3GPP TS29.500 V16.5.0 (2020-11))

[0065] It should be understood that various details of the subject matter of the present disclosure may be changed without departing from the scope of the subject matter of the present disclosure.In addition, the above description is for illustrative purposes only, not for limiting purposes.

Claims

1. A method for utilizing network function (NF) service attributes associated with a registered NF service producer in a hierarchical network, the method comprising: receiving, by a root network function repository function (NRF) operating in a hierarchical network, a NF registration message or a NF update message from a regional NRF operating in a first region of the hierarchical network, wherein the NF registration message or the NF update message comprises an NrfInfo structure containing one or more NF service attributes, the 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; Extracting, by the root NRF, the one or more NF service attributes from the NrfInfo structure; as well as One or more index entries containing the one or more NF service attributes are created in a local state information database by the root NRF.

2. The method of 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.

3. The method of claim 2, wherein the service request message comprises at least one of an Nnrf subscription request message, an Nnrf discovery request message, or an Nnrf access token request message.

4. A method according to any of the preceding claims, wherein the regional NRF is configured to insert the one or more NF service attributes as custom attributes into the NrfInfo structure. 5 . The method of claim 4 , wherein the custom attributes include a custom NF service structure that specifies the one or more NF services.

6. A method according to any one of the preceding claims, wherein the NrfInfo structure is provided to the root NRF via a NF Profile Update message sent by the regional NRF.

7. A method according to any of the preceding claims, wherein the NrfInfo structure is a JavaScript Object Notation (JSON) data structure.

8. A system for utilizing network function (NF) service attributes associated with a registered NF service producer in a hierarchical network, the system comprising: an area NRF operating in a first area of ​​the hierarchical network, the area NRF configured to generate an NF registration message or an NF update message; as well as A root network function repository function (NRF) operating in a hierarchical network and comprising a local state information database, the root network function repository function (NRF) being configured to receive the NF registration message or the NF update message from the regional NRF, wherein the NF registration message or the NF update message comprises an NrfInfo structure, the NrfInfo structure comprising one or more NF service attributes, the 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, extract the one or more NF service attributes from the NrfInfo structure, and create one or more index entries comprising the one or more NF service attributes in the local state information database.

9. The system of 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.

10. The system of claim 9, wherein the service request message comprises at least one of an Nnrf subscription request message, an Nnrf discovery request message, or an Nnrf access token request message.

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 as custom attributes into the NrfInfo structure.

12. The system of claim 11, wherein the custom attributes include a custom 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 a NF Profile Update message sent by the regional NRF.

14. The system of 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 having executable instructions stored thereon, which, when executed by at least one processor of a computer, cause the computer to perform steps comprising: receiving, by a root network function repository function (NRF) operating in a hierarchical network, a NF registration message or a NF update message from a regional NRF operating in a first region of the hierarchical network, wherein the NF registration message or the NF update message comprises an NrfInfo structure containing one or more NF service attributes, the 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; Extracting, by the root NRF, the one or more NF service attributes from the NrfInfo structure; as well as One or more index entries containing the one or more NF service attributes are created in a local state information database by the root NRF.

16. The one or more non-transitory computer-readable media of 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 of claim 16, wherein the service request message comprises at least one of an Nnrf subscription request message, an Nnrf discovery request message, or an Nnrf access token request message.

18. 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 as custom attributes into the NrfInfo structure.

19. The one or more non-transitory computer-readable media of claim 18, wherein the customized attributes include a customized NF service structure that specifies the one or more NF services.

20. The one or more non-transitory computer-readable media of any one of claims 15 to 19, wherein the NrfInfo structure is provided to the root NRF via a NF Profile Update message sent by the regional NRF.

Images