System and Method for Multilayer Network Repository Function

Abstract

A system and method for a multi-layer network repository function are provided. The present invention relates to a network repository function architecture for a telecommunications network. The communication network includes a multi-layer network repository function (NRF) architecture that serves one or more network functions (NFs) associated with the communication network. The multi-layer NRF includes a centralized NRF associated with one or more local NRFs. At least one of the one or more local NRFs receives an NF service request associated with a serving public land mobile network (PLMN), determines whether the NF service request can be processed by the local NRF, and transfers the NF service request to the centralized NRF based on the local NRF being unable to process the NF service request.

Description

Technical Field

[0001] Reservation of Rights Part of the disclosure of this patent document includes materials that are the subject of intellectual property rights owned by Jio Platforms Limited (JPL) or its related companies (hereinafter collectively referred to as the patentee), such as, but not limited to, copyrights, designs, trademarks, integrated circuit (IC) layout designs, and / or trade dress protection. The patentee does not object to a third party copying the patent document or patent disclosure described in the patent file or record of the Patent and Trademark Office, but reserves all other rights. All rights to such intellectual property are fully reserved by the patentee.

[0002] Embodiments of the present disclosure generally relate to a core network repository function in a fifth generation (5G) communication system. In particular, the present disclosure relates to a multi-layer network repository function architecture in a 5G communication system.

Background Art

[0003] The following description of related art is intended to provide background information related to the field of the present disclosure. This section may include specific aspects of the technology that may be related to various features of the present disclosure. However, this section is only intended to deepen the reader's understanding of the present disclosure and does not admit prior art.

[0004] In a fifth generation (5G) mobile network, one or more network functions (NFs) are stored in a network repository function (NRF). The NRF is a management function that maintains data and profiles associated with the NFs. A 5G network may include a single NRF or multiple NRFs for managing the NFs associated with the network. In the case of a network having multiple NRFs, there are several issues associated with the management of the multiple NRFs and their interrelationships. Further, NFs within the network may be associated with one or more NRFs, and techniques are needed to manage the interrelationships of NFs associated with different NRFs.

[0005] Therefore, there is a need in the art to provide a system and method that can mitigate problems associated with the prior art.

SUMMARY OF THE INVENTION

MEANS FOR SOLVING THE PROBLEM

[0006] This section is provided to introduce, in a simplified form, specific objects and aspects of the present disclosure that will be described in more detail in the detailed description. This summary is not intended to identify key features or to delimit the scope of the claimed subject matter.

[0007] In one aspect, the present disclosure relates to a system for managing routing in a multi-layer network repository function (NRF) architecture including a centralized NRF associated with one or more local NRFs, the system including one or more processors and a memory operably coupled to the one or more processors, the memory including processor-executable instructions that, when executed, cause the one or more processors to receive an NF service request associated with a serving public land mobile network (PLMN), determine whether the NF service request is to be processed by a local NRF of the one or more local NRFs, and transfer the NF service request to the centralized NRF based on the local NRF being unable to process the NF service request.

[0008] In some embodiments, the first local NRF is unable to process the NF service request because the NF service request is in an interrupted status.

[0009] In some embodiments, the centralized NRF functions as a gateway serving one or more NRFs associated with a communication network and can be an independently deployed centralized NRF or a combined NRF, the combined NRF including a centralized NRF deployed within at least one or more local NRFs. Further, the centralized NRF routes an NF service request associated with the first local NRF to the second local NRF based on one or more routing tables associated with the centralized NRF.

[0010] In some embodiments, the first local NRF and the second local NRF are associated with the same PLMN. In other embodiments, the first local NRF is associated with a first PLMN, the second local NRF is associated with a second PLMN, and the second PLMN is associated with a roaming partner (RP).

[0011] In some embodiments, the centralized NRF routes the NF service request to a second local NRF associated with a second PLMN via a Security Edge Protection Proxy (SEPP).

[0012] In another aspect, the present disclosure relates to a method for routing NF service requests within a local NRF. The method includes receiving, at a PLMN interface, an NF service request associated with a serving PLMN, and determining, by a determination unit, whether the NF service request is to be processed by the local NRF based on one or more parameters, the one or more parameters including at least one of a target PLMN, a single network slice selection assistance information (S-NSSAI), and an NF type (NFType), and transferring, based on the local NRF being unable to process the NF service request, the NF service request to a centralized NRF via a centralized NRF interface. In some embodiments, the method may include processing, by one or more processors, the NF service request at the local NRF based on one or more parameters.

[0013] In another aspect, the present disclosure relates to a method for routing NF service requests at a centralized NRF. The method includes receiving, at a local NRF interface, an NF service request associated with a serving PLMN from a first local NRF, and determining, by a determination unit, a route for the NF service request based on a routing table and PLMN information stored in a database, the routing table including information associated with at least one of a priority value, a target PLMN, an NF type (NFType), a slice number, an action to be performed, and an NRF table, and transferring, based on the determined route, the NF service request to a second local NRF via the local NRF interface.

[0014] In some embodiments, the second local NRF may be associated with at least one of a serving PLMN, a second access technology independent network, and an RP.

[0015] In some other aspects, the present disclosure relates to a non - transient computer - readable medium storing one or more instructions that, when executed by a processor, cause the processor to receive an NF service request associated with a first local NRF within a PLMN, determine a route of the NF service request to a second local NRF based on PLMN information from a routing table and a database, and transfer the NF service request to the second local NRF based on the determined route. Objectives of the Disclosure

[0016] Some of the objectives of the present disclosure satisfied by at least one embodiment herein are listed below.

[0017] An objective of the present disclosure is to provide a hierarchical network repository function (NRF) architecture.

[0018] An objective of the present disclosure is to provide multiple NRFs for a specific public land mobile network (PLMN).

[0019] An objective of the present disclosure is to provide multiple NRFs for the same slice.

[0020] An objective of the present disclosure is to provide a combined NRF for small - scale deployments.

[0021] An objective of the present disclosure is to create an NRF transfer policy.

[0022] An objective of the present disclosure is to provide a centralized inventory of network functions (NFs) associated with all NRFs.

[0023] The object of the present disclosure is to provide centralized NRF management for a local NRF.

[0024] The object of the present disclosure is to provide maintenance of centralized status data.

[0025] The object of the present invention is to enhance network management functions.

[0026] The object of the present invention is to optimize network functions.

Brief Description of the Drawings

[0027] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the disclosed methods and systems, and like reference numerals refer to like parts throughout the different drawings. The components in the drawings are not necessarily to scale, and emphasis has been placed on clearly illustrating the principles of the present disclosure. In some of the drawings, block diagrams are used to show components, and in some cases, the internal circuits of each component are not represented. Those skilled in the art will understand that the disclosure of such drawings includes the disclosure of electrical, electronic, or circuit components commonly used to implement such components.

[0028]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11A

Figure 11B

Figure 12

Figure 13

Figure 14

DETAILED DESCRIPTION OF THE INVENTION

[0029] For the purpose of explanation below, various specific details are described to enable a complete understanding of the embodiments of the present disclosure. However, it is clear that the embodiments of the present disclosure can be implemented without these specific details. Some of the functions described below can be used independently or in combination with other functions. Each individual function may or may not be able to address all of the problems described above, or only some of the problems described above. Some of the aforementioned problems may not be completely solved by any of the features described below.

[0030] The following description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, it is intended to provide an effective explanation for those skilled in the art to implement the exemplary embodiments. It should be understood that various changes can be made to the functions and arrangements of the elements without departing from the spirit and scope of the described disclosure.

[0031] To enable a complete understanding of the embodiments, specific details are set forth in the following description. However, it will be understood by those skilled in the art that the embodiments can be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form so as not to obscure the embodiments with unnecessary details. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail so as not to obscure the embodiments.

[0032] In addition, each of the embodiments may be described as a process represented as a flowchart, a flow diagram, a data flow diagram, a structural diagram, or a block diagram. In a flowchart, operations are described as sequential processes, but many of the operations may be executed in parallel or simultaneously. Also, the order of the operations may be changed. A process ends when the operations are completed, but there may be additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process refers to a function, its end refers to the function returning to the calling function or the main function.

[0033] As used herein, the expressions "exemplary" and / or "illustrative" mean an example, a case, or an illustration. To avoid doubt, the subject matter disclosed herein is not limited by such examples. Further, any aspect or design described as "exemplary" and / or "illustrative" herein should not necessarily be construed as more preferred or advantageous than other aspects or designs, nor is it intended to exclude equivalent exemplary structures and techniques known to those skilled in the art. Further, as long as the terms "comprising," "having," "containing," and other similar words are used in any of the detailed description or claims, such terms are intended to be inclusive in the same manner as the open-ended term "comprising" without excluding additional elements or other elements.

[0034] Throughout this specification, references to "one embodiment", "an embodiment", "one instance", or "an instance" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places in this specification are not necessarily all referring to the same embodiment. Further, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0035] The terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting of the present disclosure. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Further, the terms "comprises" and / or "comprising" as used herein specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It is understood that the expression "and / or" used herein includes any and all combinations of one or more of the associated listed items.

[0036] The present invention provides a robust and effective solution for creating a multi-layer network repository function (NRF) architecture that provides centralized management of local NRFs associated with a public land mobile network (PLMN). The present disclosure also provides a centralized inventory of all network functions (NFs) associated with all NRFs.

[0037] Embodiments of the present disclosure relate to creating a multi-layer NRF architecture for serving NFs associated with different local NRFs across different PLMNs. In one embodiment, a 5th generation (5G) communication network includes a two-layer NRF architecture for each PLMN or access technology independent network present within the 5G network. The two-layer NRF architecture includes an upper layer and a lower layer. The upper layer includes a centralized NRF, and the lower layer includes a plurality of local NRFs. NFs associated with the 5G network, except for the Security Edge Protection Proxy (SEPP), can register only with the local NRFs. The SEPP can register with the centralized NRF and can be connected to the centralized NRF directly or via a Service Communication Proxy (SCP). A centralized NRF present within a particular PLMN or access technology independent network can communicate with other centralized NRFs that may be present within other PLMNs or access technology independent networks. As an example, without limitation, the centralized NRF can communicate with the SEPP.

[0038] In certain embodiments, local NRFs can be classified into two categories: 1. multi-slice or shared slice where a single NRF supports multiple slices, and 2. single-slice or dedicated slice where a single NRF supports a single slice.

[0039] According to some embodiments, the centralized NRF can function as an endpoint that provides services such as subscribe / unsubscribe / discover / access token / notification / list acquisition / profile acquisition / bootstrap to the SEPP and the local NRF, but is not limited thereto. According to some embodiments, the centralized NRF can forward service requests such as discovery / access token / bootstrap / Ping request from an NF associated with a service PLMN to another NRF in the same PLMN or an NRF existing in another PLMN (the other NRF in the other PLMN is associated with another access technology independent network). Further, if the PLMN belongs to another operator, the centralized NRF can forward the service request to the SEPP. The centralized NRF performs the transfer based on a user-defined route transfer table.

[0040] In some embodiments, the centralized NRF can be deployed as an independent entity. In other embodiments, the centralized NRF can be deployed as a separate logical entity within the local NRF, that is, the local NRF can be a single container that holds the functions of both the local NRF and the centralized NRF. The network provider may have the option to select the deployment type of the NRF.

[0041] In some embodiments, the network provider may have a configuration flag associated with the option of using a single NRF per PLMN or using a multi-layer NRF deployment with only a single mode that can function at a particular time.

[0042] Throughout the disclosure, certain terms and phrases are used and have the following meanings in the context of the ongoing disclosure.

[0043] The term "PLMN" can refer to a public land mobile network and forms a cellular network of a mobile operator in a particular country represented by a unique PLMN code.

[0044] The term "NRF" may refer to a Network Repository Function that serves as a central registry for all core network components such as Network Functions (NFs).

[0045] The term "NF" may refer to a network function that provides processing functions in a 5G network.

[0046] The term "SEPP" may refer to a Security Edge Protection Proxy that ensures end-to-end confidentiality and / or integrity between the source network and the destination network of all 5G interconnection roaming messages and enables secure interconnection between 5G networks.

[0047] The term "SCP" may refer to a Service Communication Proxy that provides a distributed solution. The SCP includes a control plane and a data plane, is deployed in parallel with the NFs, and provides routing control, resilience, and observability to the core network.

[0048] The term "access-technology-independent network" may refer to a network infrastructure in which all network operators are connected to a single core with a single infrastructure regardless of the type of access technology employed.

[0049] Various embodiments throughout the present disclosure are described in more detail with reference to FIGS. 1-14.

[0050] FIG. 1 shows an exemplary 5G network (100) including a multi-layer NRF architecture according to an embodiment of the present disclosure.

[0051] FIG. 1 shows a communication network, such as a 5G network (100), including local NRFs (102-1, 102-2... 102-n), centralized NRFs (104-1, 104-2... 104n) corresponding to each access technology independent network (106-1, 106-2... 106-n), and security exchange protection proxies (SEPPs) (108-1... 108-n) connected to roaming partners (RPs) (110). In some embodiments, the local NRFs (102-1, 102-2... 102-n) can be collectively represented as the local NRF (102), and each can be connected to any of the centralized NRFs (104-1, 104-2... 104-n) corresponding to any of the access technology independent networks (106-1, 106-2... 106-n). The centralized NRFs (104-1, 104-2... 104-n) can be collectively represented as the centralized NRF (104). Similarly, one or more access technology independent networks (106-1, 106-2... 106-n) can be collectively represented as the access technology independent network (106), and one or more SEPPs (108-1... 108-n) can be collectively represented as the SEPP (108).

[0052] Referring to FIG. 1, the local NRF (102) is connected to a centralized NRF (104) associated with the access technology independent network (106). The centralized NRF (104) can forward requests from the NFs associated with the local NRF (102) based on the routing table. In one embodiment, the centralized NRF (104) can forward an NF request received via a local NRF (e.g., 102-1) to another local NRF (e.g., 102-2) within the same access technology independent network (106-1), where the local NRF (102), the centralized NRF (104), and the access technology independent network (106-1) belong to the serving PLMN, i.e., the PLMN of the first operator. In another example, the centralized NRF (104-1) can forward an NF request received via a local NRF (102) associated with one access technology independent network (106-1) to another local NRF (not shown) associated with another access technology independent network (106-n) based on the target PLMN data in the received request. The local NRF (102), the access technology independent networks (106-1, 106-n), the centralized NRFs (104-1, 104-n), and the other local NRF are associated with the serving PLMN. In another example, the centralized NRF (104) can forward an NF request received via the local NRF (102) to another NRF (not shown) associated with another PLMN, i.e., a PLMN different from the serving PLMN, i.e., a roaming partner (110) via SEPP (108).

[0053] In some embodiments, the NF request may include, for example, subscribe / discovery / unsubscribe / access token / bootstrap requests (but not limited thereto). In some embodiments, service operations such as subscribe / discovery / unsubscribe / access token / bootstrap requests operate at the associated local NRF (102) and centralized NRF (104), and may not be transferred to other NRFs unless some instructions are provided through the notification uniform resource identifier (URI). For other requests (such as subscribe / discovery / unsubscribe / access token / bootstrap, etc.), the local NRF (102) may determine whether it can process the request locally. If it cannot, the local NRF (102) may transfer the request to the centralized NRF (104). When the local NRF (102) can process the request locally, the local NRF (102) may approve such a request before processing the relevant attributes (reqNfType, reqNfFqdn, reqSnssais, reqPerPlmnSnssais, reqPlmnList, reqSnpnList, etc.). On the other hand, when the local NRF (102) cannot process the NF request, the local NRF (102) may check information such as the target PLMN, NFType processed by the local NRF (102), and network slice processed by the local NRF (102), and may decide to transfer the NF request to the centralized NRF (104). When the local NRF (102) cannot process the NF request locally (or when the null set matches), the request may be transferred to the centralized NRF (104) unless the centralized NRF (104) has previously transferred the request to avoid creating a loop. The local NRF (102) may manually mark NF requests that it cannot process itself as "not discoverable", and the subscribe / discovery responses of those NFs may be considered null matches and may be transferred to the centralized NRF (104).In one embodiment, the centralized NRF (104) may not re - route the request received from the local NRF (102 - 1) back to the same local NRF (102 - 1). In other words, the multi - layer architecture (100) avoids the generation of loops. Also, unless specified by another function, the local NRF (102 - 1) may not transfer the request transferred by the centralized NRF (104) to another local NRF or another centralized NRF.

[0054] According to some embodiments, the local NRF (102) may register, update, or deregister with the centralized NRF (104) during the run - time configuration of the centralized NRF (104) by the user.

[0055] In some embodiments, when the centralized NRF (104) receives an NF request transferred by the local NRF (102), the centralized NRF (104) may check the target PLMN based on the parameters of the service operation associated with the NF request, and determine whether to transfer the request to the SEPP (108) or another access - technology - independent network NRF (106), or to the local NRF (102). If the target PLMN does not exist, the source PLMN of the request, i.e., the PLMN associated with the requested NF, may be considered as the target PLMN. The centralized NRF (104) may include a table containing details necessary to determine how to transfer the NF request. Specifically, for example, an access - technology - independent network NRF table for communicating with or transferring requests to other access - technology - independent network NRFs, a centralized routing table including Internet Protocol (IP) addresses and port numbers associated with the SEPP (108) for transferring requests to PLMNs other than the service PLMN or the home PLMN, and a local NRF table associated with the local NRF (102), etc., are included, but not limited to these. The centralized NRF (104) may build the local NRF table when the local NRF (102) registers with the centralized NRF (104).

[0056] As an example, but not limited to, Table 1 shown below represents a sample table of the Centralized NRF (104). Table 1 includes columns related to a priority value, a target PLMN, NFType, a slice number, an action to be performed, and an NRF table associated with the Local NRF, other access technology independent network NRF, or NRF table of SEPP associated with the Centralized NRF (104). In the priority column, priority values such as P1, P2, P3…PN can be defined, where P1 may have the highest priority and PN may have the lowest priority. Rules with higher priority are checked first. When the priorities of two rules are the same, the two rules are checked based on the serial number or display order. In one embodiment, the serial number or display order may be changed during execution. The target PLMN column includes PLMN numbers (e.g., PLMN1, PLMN2, …PLMNN, etc.) associated with the PLMN to which the NF request is transferred. When there is one or more PLMNs to which the request can be transferred, the PLMN numbers are separated by commas, and the comma represents an OR operation. The target PLMN also includes a wild card operator indicating that the request is to be transferred to any available PLMN. NFType corresponds to the type of NF request, such as, but not limited to, an Access and Mobility Management Function (AMF) request, a Session Management Function (SMF) request, or a 5G Network Data Analytics Function (NWDAF) request that may be executed. The NFType column supports commas representing OR operations and an "ALL" value specifying support for all types of NF requests. The slice column includes slice numbers (such as slice 1, slice 2, …slice N, etc.) specified by single network slice selection assistance information (S-NSSAI) values, but is not limited thereto. One or more S-NSSAI values can be separated by commas representing an OR operation, and further includes a wild card operator indicating any slice to which the request can be transferred. For example, when the fourth column is checking the slice value, the * operator means that the slice value can be anything and the condition of that column is met.However, the values of other columns existing in the same row are checked against the corresponding parameters. In the action column, actions to be executed are specified, such as whether to forward the request or reject the request. For example, when the action is specified as "forward", the centralized NRF (104) may select the NRF table as shown in Table 2 below, and the name of the table referenced for routing is specified in the NRF table column of Table 1. When the action is specified as "reject", a user-defined rejection status code and problem statement may be selected and included in the response to the NF request.

[0057]

Table 1

[0058] Table 2 specifies the columns associated with the NRF table and the corresponding values, such as NRFT1, NRFT2, NRFT3, etc. specified in the NRF table column of Table 1. The sample NRF table (Table 2) includes a first column specifying the name of the NRF table, a second column specifying the NRF associated with a specific NRF table, a priority column specifying the priority value assigned to each NRF, and a weight column specifying the weight given to NRFs with equal priority. The NRF table may include a local NRF and may also include NRFs associated with other access technology-independent networks or SEPP information.

[0059] For example, without limitation, the centralized NRF (104) may forward the NF request based on routing tables 1 and 2. When the centralized NRF (104) receives an NF request with NFType = AMF, the centralized NRF (104) may decide to forward the request to any NRF associated with the NRF table NRFT1. Table NRFT1 (see Table 2) includes NRF1 and NRF2, and the priority of NRF1 is higher than that of NRF2. The centralized NRF (104) may decide to forward the AMF request to NRF1 associated with target PLMN1.

[0060]

Table 2

[0061] Referring to FIG. 1, the roaming partner (110) may include other PLMNs that can be connected to the serving PLMN via the SEPP (108). When it is necessary to forward an NF request to any RP (110), the centralized NRF (104) may forward it based on the IP address and port number associated with the SEPP (108).

[0062] FIG. 1 shows exemplary components of a network architecture (100), but in the network architecture (100) in other embodiments, the number, type, and arrangement of components may be different from those in FIG. 1, or may include additional functions not shown in FIG. 1, but are not limited thereto. Further, or alternatively, the functions described herein as being performed by one or more components of the network architecture (100) may be performed by one or more other components of the network architecture (100).

[0063] FIG. 2A shows an exemplary multi - layer NRF hierarchy (200 - A) according to an embodiment of the present disclosure. FIG. 2A is described with reference to the elements of FIG. 1.

[0064] Figure 2A shows a two-layer or two-level NRF architecture (200-A). The first level includes one or more local NRFs (102), and the second level includes a centralized NRF (104). The local NRF (102) has the option to select an IP / port (active standby mode) for the centralized NRF (104), and can define the IP / ports of multiple NRFs in order of priority so that the secondary IP of the same centralized NRF (104) can be tried when the primary IP of the centralized NRF cannot be reached. NF requests from the local NRF (102) can be transferred by the centralized NRF (104) to other NRFs or SEPPs (108). The centralized NRF (104) can maintain an inventory of all NFs associated with the NF, such as creation, modification, deletion, and status reporting related to the NF.

[0065] In one embodiment, the centralized NRF (104) can maintain subscription status data that is shared in real time among all centralized NRFs (104-1…104-n) within the same PLMN. The centralized NRFs (104-1…104-n) can be registered with each other to enable sharing. The subscription status data can include subscriptions created by the local NRF (102), such as subscription ID data that is associated with the local NRF (102) but requested by the SEPP (108) or other access technology-independent network NRFs (106). The centralized NRF (104) can maintain this data based on a timer value defined as (valid time + delta time), and the delta time can be set by the user. In another embodiment, the subscription ID generated by the local NRF (102) for NFs within the same PLMN (bypassing the centralized NRF (104)) may or may not be stored by the centralized NRF (104).

[0066] As an example, without limitation, when the centralized NRF (104) receives a patch subscribe or unsubscribe request from the SEPP (108) or another access technology independent network NRF (106), it may find the appropriate local NRF (102) using the stored subscription status data and transfer the request accordingly. If the centralized NRF (104) cannot detect the subscription status data, it may reject the request with the status code and problem details set by the user.

[0067] In some embodiments, the centralized NRF (104) may be deployed independently. In such a scenario, the centralized NRF (104) may store subscription status data according to the originator of the NF request and the response method.

[0068] In the scenario of the first example, a subscription ID request from a local NF, i.e., an NF from the serving PLMN, is sent to the local NRF1 (102-1). If the local NRF1 (102-1) can process the subscription request, a response including the associated subscription ID and location header may be returned to the NF.

[0069] In the second scenario, a subscription ID request from the local NF is sent to the local NRF1 (102-1), and if the local NRF1 (102-1) cannot process the request, it may decide to forward the request to the centralized NRF2 (104-2). The centralized NRF2 (104-2) checks its route table (Tables 1 and 2 described above with reference to FIG. 1) and may forward the request to the local NRF3 (102-3). The local NRF3 (102-3) generates a subscription ID along with the corresponding location header (associated with NRF3), returns a response to the local NF via the centralized NRF2 (104-2) and the local NRF1 (102-1), and finally returns a response to the local NF. When the centralized NRF2 (104-2) receives a response from the local NRF3 (102-3), it may store the subscription status data. The centralized NRF2 (104-2) and the local NRF1 (102-1) may not change the subscription ID or the location header as part of the response. When the NF receives the response, it may then forward the subscribe patch / unsubscribe request directly to the application program interface (API) route provided by the location header, i.e., the local NRF3 (102-3).

[0070] In the third scenario, upon receiving a subscription ID request from SEPP (108) or the local NRF associated with another PLMN-NRF, the centralized NRF2 (104-2) may identify the local NRF (102) based on the routing table and transfer the request to the local NRF3 (102-3). The local NRF3 (102-3) may generate a subscription ID and a location header associated with the local NRF3 (102-3), return the response to the centralized NRF2 (104-2), and the centralized NRF2 (104-2) may store the subscription status data. Before transferring the response to SEPP (108) or another PLMN-NRF, the centralized NRF2 (104-2) may change the location header API route to the centralized NRF2 (104-2). Subsequent subscribe patch or unsubscribe requests from SEPP (108) may be received by the centralized NRF (104-2), and the centralized NRF may further check the subscription status data to find the relevant local NRF to transfer the request.

[0071] In the fourth scenario, when a subscription ID request is generated by the local NF to the SEPP (108) or another PLMN NRF via the local NRF1 (102-1) and the centralized NRF2 (104-2), the local NRF1 (102-1) may first receive the subscription request and, based on the PLMN, may decide to transfer the request to the centralized NRF2 (104-2). The centralized NRF2 (104-2) may decide to transfer the request to the SEPP (108) or another access technology independent network NRF (106) based on the target PLMN. The other access technology independent network NRF (106) or the NRF within the RP (110) PLMN may generate a subscription ID and transfer its response to the centralized NRF2 (104-2) either via the SEPP (108) or directly. In this case, the centralized NRF2 (104-2) does not store the subscription status data. Instead, it may add the mobile country code (MCC) / mobile network code (MNC) to the subscription ID and change the location header before transferring the response to the local NRF1 (102-1), and the local NRF1 (102-1) may change the location header before transferring the response to the local NF.

[0072] FIG. 2B shows an exemplary multi-layer NRF hierarchy (200-B) with a combined NRF according to an embodiment of the present disclosure. FIG. 2B is shown with reference to the entities of FIG. 1.

[0073] In Figure 2B, it is shown that two local NRFs (102-1, 102-2) are connected to a combined NRF (202). The combined NRF (202) includes a centralized NRF (104) deployed as a separate logical entity within the local NRF container, that is, a single container that holds both the local NRF and the centralized NRF. In some embodiments, the NRF may provide an option to select the operating mode of the NRF. For example, the NRF can be any of a local NRF, a centralized NRF, or a combined NRF. For example, without limitation, the NRF may provide configurable parameters at startup associated with the NRF deployment mode. This parameter is defined as "NRFDepMode", and the possible values include "Single NRF", "Local NRF", "Centralized NRF", and "Combined NRF". The default value can be "Single NRF". However, when "NRFDepMode" is "Local NRF", the NRF needs to provide the function of a dual-tier local NRF. Similarly, when "NRFDepMode" is "Centralized NRF", the NRF needs to provide the function of a dual-tier centralized NRF. When "NRFDepMode" is "Combined NRF", the NRF needs to provide support for both the local NRF and the centralized NRF.

[0074] As an example, without limitation, in the combined NRF (202), the centralized NRF may have a maximum of two combinations of IP / ports, and the local NRF and the centralized NRF can function as two different NRFs that share a database (DB) in real time. Further, the configuration files and parameters of the centralized NRF can be separated from those of the local NRF. In one embodiment, when the centralized NRF (104) is deployed in an active-active mode or an active-standby mode, the subscription status data can be replicated between the two centralized NRFs (104), enabling communication between the centralized NRFs (104) across vendors.

[0075] Figure 3 shows an exemplary message flow diagram (300) associated with subscription messages between different entities within a 5G network architecture (100) according to an embodiment of the present disclosure.

[0076] Figure 3 shows a message sequence related to registration / update / deregistration / list acquisition / profile acquisition associated with one or more entities of the network (100) in FIG. 1. In one embodiment, the local NRF (102) may send a registration / update / deregistration / list acquisition / profile acquisition request (302) to the centralized NRF1 (104-1) and receive a response (304) to the request. Similarly, the SEPP (108) may register with the centralized NRF1 (104-1) by sending a registration / update / deregistration / list acquisition / profile acquisition request (306), and the centralized NRF1 (104-1) may confirm this with a response (308). In some embodiments, the centralized NRF1 (104-1) may send a registration / update / deregistration / list acquisition / profile acquisition request (310) to the centralized NRF2 (104-2) and receive a response (312) from the centralized NRF2 (104-2). Registering one centralized NRF (e.g., 104-1) with another centralized NRF (e.g., 104-2) enables data sharing for routing NF requests.

[0077] Figure 4 shows an exemplary flow diagram (400) of token verification by the NRF according to an embodiment of the present disclosure.

[0078] FIG. 4 shows the messaging between the local NF (410) associated with the serving PLMN or the home PLMN and the local NRF1 (102-1). In one embodiment, the local NF (410) may initiate a discovery / access token / bootstrap / Ping request (402) with the local NRF1 (102-1). The local NRF1 (102-1) may check one or more information such as the target PLMN, NFType, slice number (S-NSSAI), etc. (but not limited to these) associated with the request (402), and determine whether the NF can serve itself (404). If the local NRF1 (102-1) determines that the NF (410) can be served, it may send a response (406) to the NF (410).

[0079] FIG. 5 shows an exemplary message flow diagram (500) associated with serving a local NF within a PLMN by another local NRF, according to an embodiment of the present disclosure.

[0080] FIG. 5 shows the messaging between a local NF (510), a first local NRF1 (102-1), a centralized NRF2 (104), and a second local NRF3 (102-2). In one embodiment, the local NF (510) initiates a discovery / access token / bootstrap / Ping request (502) towards the first local NRF1 (102-1). The first local NRF1 (102-1) determines (504) based on one or more pieces of information such as the target PLMN, NFType, slice number (S-NSSAI) associated with the request (502), and may process the request (502). In an exemplary embodiment, the first local NRF1 (102-1) may determine (504) to forward the request (502) to the centralized NRF2 (104). The centralized NRF2 (104) determines to forward the request to the second local NRF3 (102-2) (506). At step 508, the second local NRF3 (102-2) determines to process the request based on local information and returns a response (512) to the local NF (510) via the centralized NRF2 (104) and the first local NRF1 (102-1).

[0081] FIG. 6 shows an exemplary message flow diagram (600) associated with serving a local NF within a serving PLMN by a local NRF of another access technology independent network according to an embodiment of the present disclosure.

[0082] FIG. 6 shows the messaging between a local NF (610), a first local NRF1 (102-1), a centralized NRF2 (104), and an access technology independent network NRF (106). In some embodiments, the local NF (610) initiates a discovery / access token / bootstrap / Ping request (602) towards the first local NRF1 (102-1). The first local NRF1 (102-1) determines (604) based on one or more information such as the target PLMN, NFType, slice number (S-NSSAI) associated with the request (602), and may process the request (602). In an exemplary embodiment, the first local NRF1 (102-1) may determine (604) to forward the request (602) to the centralized NRF2 (104). The centralized NRF2 (104) may determine (606) to forward the request to another access technology independent network NRF (106) based on the routing table within the centralized NRF2 (104) and the details of the home PLMN. The centralized NRF2 (104) may forward the request (602) to another access technology independent network (106). The access technology independent network (106) assigns, in step 608, the associated local NRF to process the request (602) and generate a response (612). The response (612) is communicated to the local NF (610) via the centralized NRF2 (104) and the first local NRF1 (102-1).

[0083] FIG. 7 shows an exemplary message flow diagram (700) associated with serving a local NF within a PLMN by a local NRF within another PLMN according to an embodiment of the present disclosure.

[0084] FIG. 7 shows the messaging between a local NF (710), a first local NRF1 (102-1), a centralized NRF2 (104), and a SEPP (108). In some embodiments, the local NF (710) initiates a discovery / access token / bootstrap / Ping request (702) towards the first local NRF1 (102-1). The first local NRF1 (102-1) determines (704) based on one or more information such as the target PLMN, NFType, slice number (S-NSSAI) associated with the request (702), and may process the request (702). In an exemplary embodiment, the first local NRF1 (102-1) may determine (704) to transfer the request (702) to the centralized NRF2 (104). The centralized NRF2 (104) may determine (708) to transfer the request to the SEPP (108) based on the routing table and the details of the home PLMN. The centralized NRF2 (104) may transfer the request (702) to the SEPP (108). The SEPP (108) may, in step 708, assign a local NRF associated with another PLMN, process the request (702), and generate a response (712). The response (712) is communicated to the local NF (710) via the centralized NRF2 (104) and the first local NRF1 (102-1).

[0085] FIG. 8 shows an exemplary message flow diagram (800) associated with another local NRF processing a subscription request from a local NF within a PLMN, according to an embodiment of the present disclosure.

[0086] FIG. 8 shows the messaging between a local NF (810), a first local NRF1 (102-1), a centralized NRF2 (104), and a second local NRF3 (102-2). The local NF (810) initiates a subscription request (802) to the first local NRF1 (102-1). The first local NRF1 (102-1) may locally determine to forward the subscription request (802) to the centralized NRF2 (104) (804). The centralized NRF2 (104) may determine to forward the subscription request (802) to the second local NRF3 (102-2) based on the local routing table (806). The second local NRF3 (102-2) determines in step 808 to respond to the NF request. The second local NRF3 (102-2) sends a response (812) to the local NF (810) via the centralized NRF2 (104) and the first local NRF1 (102-1). The response (812) includes a subscription ID and a location identifier. For example, the location identifier may include the location of the serving local NRF3 (102-2). When receiving the response (812), the local NF (810) may generate a subscribe patch / unsubscribe message (814) and send it to the second local NRF3 (102-2) and may obtain a response (816). In some embodiments, when receiving the response (812) from the second local NRF3 (102-2), the centralized NRF2 (104) may store the subscription status data. The centralized NRF2 (104) and the first local NRF1 (102-1) may not be able to change the subscription ID or the location header within the response (812). When receiving the response (812), the local NF (810) may then directly forward the subscribe patch / unsubscribe request (814) to the API route provided by the location header, that is, the second local NRF3 (102-2).

[0087] FIG. 9 shows an exemplary message flow diagram (900) associated with processing a subscription request from a local NF within a PLMN by a local NRF of another access technology independent network according to an embodiment of the present disclosure.

[0088] Figure 9 shows the messaging between a local NF (910), a local NRF1 (102), a centralized NRF2 (104), and another access technology independent network NRF (106). The local NF (910) initiates a subscription request (902) to the local NRF1 (102). The local NRF1 (102) may locally determine to forward the subscription request (902) to the centralized NRF2 (104) (904). The centralized NRF2 (104) may determine to forward the subscription request (902) to the other access technology independent network NRF (106) based on the local routing table and the serving PLMN (906). The other access technology independent network NRF (106) determines to serve the NF (910) and send a response (908) to the centralized NRF2 (104), where the response (908) includes a subscription ID and location information associated with the other access technology independent network NRF (106). The centralized NRF2 (104) modifies the response (908) to include MCCMNC data associated with another PLMN and changes the location information to its own location. The modified response (912) is sent to the local NRF1 (102), and the local NRF1 (102) further modifies the response (912) to include the location of the local NRF1 (102) in the location information of the response (912). The further modified response (914) is sent to the local NF (910). When receiving the response (914), the local NF (910) may generate a subscribe patch / unsubscribe request (916) and send it to the local NRF1 (102). The local NRF1 (102) forwards the request (916) to the centralized NRF2 (104). The centralized NRF2 (104) modifies the request (916) to delete the MCCMNC data and sends the modified request (918) to the other access technology independent network NRF (106). The other access technology independent network NRF (106) sends a subscribe response message (920) to the local NF (910) via the centralized NRF2 (104) and the local NRF1 (102).

[0089] FIG. 10 shows an exemplary message flow diagram (1000) associated with processing a subscription request from a local NF within a PLMN by a local NRF in another PLMN according to an embodiment of the present disclosure.

[0090] Figure 10 shows the messaging between a local NF (1010) via SEPP (108), a local NRF1 (102), a centralized NRF2 (104), and other PLMNs. The local NF (1010) initiates a subscription request (1002) to the local NRF1 (102). The local NRF1 (102) may locally determine (1004) to forward the subscription request to the centralized NRF2 (104) together with the API route (1006). The centralized NRF2 (104) may determine (1008) to forward the subscription request including the API route (1006) to the SEPP (108) based on the local routing table and the serving PLMN. The SEPP (108) determines to serve the NF (1010) and send a response (1012) to the centralized NRF2 (104), where the response (1012) includes a subscription ID and location information associated with other SCNRFs. The centralized NRF2 (104) modifies the response (1012) to include MCCMNC data associated with another PLMN and changes the location information to its own location. The modified response (1014) is sent to the local NRF1 (102), and the local NRF1 (102) further modifies the response (1014) to include the location of the local NRF1 (102) in the location information of the response (1014). The further modified response (1016) is sent to the local NF (1010). When receiving the response (1016), the local NF (1010) generates a subscribe patch / unsubscribe request (1018) and sends it to the local NRF1 (102). The local NRF1 (102) modifies the patch request (1018) to include the target API route and the fully qualified domain name (FQDN) associated with the remote NRF. The local NRF1 (102) forwards the modified subscribe patch request (1020) to the centralized NRF2 (104). The centralized NRF2 (104) further modifies the modified subscribe patch request (1020) to obtain a further modified patch request (1022) and sends the further modified patch request (1022) to the SEPP (108).Upon receiving the patch request (1022), SEPP (108) sends a response (1024) to the local NF (1010) via the centralized NRF2 (104) and the local NRF1 (102).

[0091] Figure 11A shows an exemplary message flow diagram (1100-A) associated with remote NF detection served by a local NRF according to an embodiment of the present disclosure.

[0092] Figure 11A shows the messaging between the remote NF (1110), the centralized NRF2 (104), and the local NRF1 (102). In one embodiment, an NF request (1102) associated with SEPP (108) / NRF in another PLMN is sent to the centralized NRF2 (104). The NF request (1102) may include a discovery / access token / bootstrap / Ping request. Upon receiving the request (1102), the centralized NRF2 (104) checks the local routing table in step 1104 and forwards the request (1102) to the local NRF1 (102). The local NRF1 (102) sends a response (1106) to the remote NF (1110) via the centralized NRF2 (104), and in the response (1106), it may be specified that the local NRF1 (102) can serve the remote NF (1110).

[0093] Figure 11B shows an exemplary message flow diagram (1100-B) associated with a remote NF subscription request served by a local NRF according to an embodiment of the present disclosure.

[0094] FIG. 11B shows a subscription request message between a remote NF (1110), a centralized NRF2 (104), and a local NRF1 (102). In one embodiment, a subscription request (1108) from a remote NF (1110) associated with a SEPP (108) or an NRF within another PLMN is sent to the centralized NRF2 (104). Upon receiving the request (1108), the centralized NRF (104) checks the local routing table at step 1112 and forwards the request (1108) to the local NRF1 (102). The local NRF1 (102) sends a response (1114) to the centralized NRF2 (104), where the response (1114) includes a subscription ID and a location identifier. For example, the location identifier may include the location of the local NRF1 (102). At step 1116, the centralized NRF2 (104) stores the subscription ID mapped to the local NRF (e.g., 102) that sent the response (1114). The centralized NRF2 (104) modifies the response (1114) to include the location of the centralized NRF2 (104) and forwards the modified response (1118) to the remote NF (1110). Upon receiving the modified response (1118), the remote NF (1110) responds to the centralized NRF2 (104) with a subscribe patch / unsubscribe message (1120). At step 1122, the centralized NRF2 (104) checks the subscription ID within the subscribe patch / unsubscribe message (1120) and forwards it to the local NRF1 (102). The local NRF1 (102) sends a response (1124) to the remote NF (1110) via the centralized NRF2 (104).

[0095] Referring to FIGS. 4 to 11B described above, the terms local NRF1 (102), local NRF1 (102-1), and local NRF (102) can be used interchangeably and refer to any one local NRF within the network (100) of FIG. 1. Similarly, the terms centralized NRF (104), centralized NRF2 (104), and centralized NRF2 (104-2) can be used interchangeably and refer to any one centralized NRF (104) within the network (100). The term local NRF3 (102-2) or local NRF3 can be used interchangeably to represent a second local NRF to which an NF request is routed. In one embodiment, the second local NRF represented by the term local NRF3 can be associated with the same PLMN, a different PLMN, or a different access technology independent network.

[0096] FIG. 12 shows an exemplary representation of a system (1200) according to an embodiment of the present disclosure, and the centralized NRF (104) of FIG. 1 can be implemented by or implemented in the system.

[0097] In one aspect, the system (1200) may include one or more processors (1202). The one or more processors (1202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuits, and / or any device that processes data based on operation instructions. Among other functions, the one or more processors (1202) may be configured to obtain and execute computer-readable instructions stored in the memory (1204) of the system (1200). The memory (1204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, and these instructions or routines may be obtained and executed to create or share data packets via a network service. The memory (1204) may include any non-transitory storage device, including, for example, volatile memory such as random access memory (RAM), or non-volatile memory such as erasable programmable read-only memory (EPROM), flash memory, etc.

[0098] In one embodiment, the system (1200) may include an interface(s) (1206). The interface(s) (1206) may facilitate the communication of the system (1200). The interface(s) (1206) may also provide communication routes to one or more components of the system (1200). Examples of such components may include, but are not limited to, a processing unit / engine(s) (1208) and a database (1216). Further, the interface(s) (1206) may include various interfaces such as a PLMN interface (1206-1), a SEPP interface (1206-2), a local NRF interface (1206-3), an access-technology-independent network interface (1206-4), and other interfaces (1206-5). In one embodiment, the interfaces (1206-1...1206-5) may be used for receiving inputs and transmitting outputs to other components or devices within the network (100) of FIG. 1. By way of example, and not limitation, the PLMN interface (1206-1) functions as a point for interacting with the local PLMN of FIG. 1 and other PLMNs or RPs (110), the SEPP interface (1206-2) may include communicating NF service requests / responses with the NRF within other PLMNs, the local NRF interface (1206-3) may include transmitting and receiving NF requests to and from the local NRF, the access-technology-independent network interface (1206-4) may include communicating NF requests / responses associated with the NRF of the other access-technology-independent network (106) of FIG. 1, and the other interface(s) (1206-5) may include interfaces for data input devices and output devices such as input / output (I / O) devices, storage devices, and the like.

[0099] The processing engine (1208) may be implemented as a combination of hardware and programming (e.g., programmable instructions) to implement one or more functions of the processing engine (1208). In the examples described herein, such a combination of hardware and programming may be implemented in several different ways. For example, the programming of the processing unit (1208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium, and the hardware of the processing unit (1208) may include processing resources (e.g., one or more processors) for executing such instructions. In this embodiment, the machine-readable storage medium may store instructions that, when executed by the processing resources, implement the processing engine (1208). In such an example, the system (1200) may include a machine-readable storage medium that stores instructions and processing resources for executing the instructions, or the machine-readable storage medium may be separate from the system (1200) and the processing resources but accessible from the system (1200) and the processing resources. In other examples, the processing unit (1208) may be implemented by an electronic circuit. In one aspect, the database (1216) may include data stored or generated as a result of functions implemented by any component of the processor (1302) or the processing unit (1208).

[0100] In one embodiment, the processing unit (1208) may include a unit that receives communications from one or more network components within the network (100) of FIG. 1, e.g., a unit that receives a local NF service request associated with a local NRF (serving PLMN), or a unit that receives a remote NF reception request from a SEPP or NRF associated with another PLMN. Data related to such request / response communications may be stored in the database (1216). In one embodiment, the processing unit (1208) may include one or more units / modules, such as, but not limited to, an acquisition unit (1210), a determination unit (1212), and other units (1214) (plural).

[0101] Referring to FIG. 12, the database (1216) may store data associated with request / response communication, such as information associated with root transfer, i.e., the routing table described above with reference to FIG. 1, and information associated with service requests such as subscription IDs associated with one or more NFs. In one embodiment, the database (1216) may or may not be present within the system (1200). In one embodiment, the system (1200) may be operatively coupled to the database (1216).

[0102] Furthermore, in one embodiment, one or more processors (1202) of the system (1200) may cause the acquisition unit (1212) to obtain an NF request / response from the interface (1206), extract the subscription ID and location parameters from the response message transmitted via the centralized NRF (104), and store it in the database (1216). The stored information contributes to routing the NF service request to the appropriate NRF by the centralized NRF (104).

[0103] Referring to FIG. 12, in one embodiment, the determination unit (1212) may determine the type of route for a particular NF service request. The determination unit (1212) may access the routing table (Tables 1 and 2 above) and the PLMN list from the database (1216) to determine the route.

[0104] Those skilled in the art will understand that the exemplary representation (1200) may be modular and flexible to accommodate any type of change in the centralized NRF (104).

[0105] FIG. 13 shows an exemplary representation of a system (1300) according to an embodiment of the present disclosure, where the local NRF (102) can be implemented by or implemented in this system (1300). In one aspect, the system (1300) may include one or more processors (1302). The one or more processors (1302) can be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuits, and / or any device that processes data based on operation instructions. Among other functions, the one or more processors (1302) can be configured to obtain and execute computer-readable instructions stored in the memory (1304) of the system (1300). The memory (1304) can be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, and these instructions or routines can be obtained and executed to create or share data packets via a network service. The memory (1304) can include any non-transitory storage device, including, for example, volatile memory such as random access memory (RAM), or non-volatile memory such as erasable programmable read-only memory (EPROM), flash memory, etc.

[0106] In one embodiment, the system (1300) may include an interface(s) (1306). The interface(s) (1306) can facilitate communication between the system (1300) and other systems or units within the network (100) of FIG. 1. The interface(s) (1306) can also provide communication routes to one or more components of the system (1300). Examples of such components can include, but are not limited to, a processing unit / engine(s) (1308) and a database (1316). Further, the interface(s) (1306) can include various interfaces such as a centralized NRF interface (1306-1), a PLMN interface (1306-2), and other interfaces (1306-3), but is not limited thereto. In one embodiment, the interfaces (1306-1...1306-3) can be used to receive inputs / outputs transmit to other components or devices within the network (100) of FIG. 1. As an example, but not limited to, the centralized NRF interface (1306-1) can include sending and receiving a registration request from the local NRF (102), transferring an NF request for service or routing by the centralized NRF, and receiving a response related to the transferred NF request. The PLMN interface (1306-2) can function as a point to interact with the local PLMN and other PLMNs to receive NF requests, and the other interface(s) (1306-3) can include interfaces for data input devices and output devices, such as input / output (I / O) devices, storage devices, etc.

[0107] The processing unit (1308) may be implemented as a combination of hardware and programming (e.g., programmable instructions) to implement one or more functions of the processing unit (1308). In the examples described herein, such a combination of hardware and programming may be implemented in several different ways. For example, the programming of the processing unit (1308) may be processor-executable instructions stored on a non-transitory machine-readable storage medium, and the hardware of the processing unit (1308) may include processing resources (e.g., one or more processors) for executing such instructions. In this example, the machine-readable storage medium may store instructions that, when executed by the processing resources, implement the processing unit (1308). In such an example, the system (1300) may include a machine-readable storage medium that stores instructions and processing resources for executing the instructions, or the machine-readable storage medium may be separate from the system (1300) and the processing resources but may be accessible from the system (1300) and the processing resources. In other examples, the processing unit (1308) may be implemented by an electronic circuit. In one aspect, the database (1316) may include data that is stored or generated as a result of functions implemented by components of either the processor (1302) or the processing unit (1308).

[0108] In one embodiment, the processing unit (1308) may include a unit that receives communications from one or more network components within the network (100) of FIG. 1, e.g., a unit that receives a local NF service request associated with a serving PLMN. Data related to such request / response communications may be stored in the database (1316). In one embodiment, the processing unit (1308) may include one or more units / modules, such as an acquisition unit (1310), a determination unit (1312), and other unit(s) (1314), but is not limited thereto.

[0109] Referring to FIG. 13, the database (1316) may store data associated with request / response communication, such as information related to root transfer, i.e., the IP address associated with the centralized NRF (104) for transferring NF requests that the local NRF (102) may not be able to process by itself. In one embodiment, the database (1316) may or may not exist within the system (1300). In one embodiment, the system (1300) may be operatively coupled to the database (1316).

[0110] Furthermore, in one embodiment, one or more processors (1302) of the system (1300) may cause the acquisition unit (1312) to acquire NF request / responses from the interface (1306), extract the target PLMN, slice number, NF request type, etc. from the NF service request, and determine whether the NF request can be processed locally. The stored information contributes to routing the NF service request to the centralized NRF (104).

[0111] Referring to FIG. 13, in one embodiment, the determination unit (1312) may determine whether a particular NF service request is to be processed locally or needs to be transferred to the centralized NRF (104). The determination unit (1212) accesses the target PLMN, slice number, and NF request type information from the NF service request and checks whether each request can be serviced locally based on the data parameters associated with the target PLMN, slice number, and NF request type stored in the database (1316).

[0112] Those skilled in the art will understand that the exemplary representation (1300) may be modular and flexible to accommodate any type of change in the system (1300).

[0113] FIG. 14 shows an exemplary computer system (1400), and embodiments of the present invention can be implemented by or in a computer system.

[0114] As shown in FIG. 14, the computer system (1400) may include an external storage device (1410), a bus (1420), a main memory (1430), a read-only memory (1440), a mass storage device (1450), communication ports (plural available) (1460), and a processor (1470). Those skilled in the art will understand that the computer system (1400) may include multiple processors and communication ports. The processor (1470) may include various modules related to embodiments of the present disclosure. The communication ports (plural available) (1460) may be any of an RS-232 port used for a modem-based dial-up connection, a 10 / 100 Ethernet port, a gigabit or 10-gigabit port using copper wire or optical fiber, a serial port, a parallel port, or any other existing or future port. The communication ports (plural available) (1460) may be selected according to a network such as a local area network (LAN), a wide area network (WAN), or any network to which the computer system (1400) is connected. The main memory (1430) is a random access memory (RAM) or other dynamic storage device generally known in the art. The read-only memory (1440) includes, but is not limited to, a programmable read-only memory (PROM) chip for storing static information such as startup or basic input / output system (BIOS) instructions of the processor (1470), and may be any static storage device (plural available). The mass storage device (1450) may be any current or future mass storage device solution that can be used to store information and / or instructions.

[0115] The bus (1420) communicatively couples the processor (1470) to other memory, storage, and communication blocks. The bus (1420) can be, for example, a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus for connecting expansion cards, drives, and other subsystems, a Small Computer System Interface (SCSI), a Universal Serial Bus (USB), or other buses such as a Front Side Bus (FSB) that connects the processor (1470) to the computer system (1400).

[0116] Optionally, an operator and management interface (display, keyboard, cursor control device, etc.) is also connected to the bus (1420) and can support direct interaction between the operator and the computer system (1400). Other operator and management interfaces can be provided through network connections connected via communication port(s) (1460). The exemplary computer system (1400) described above is in no way intended to limit the scope of the present disclosure.

[0117] Although a considerable emphasis is placed here on the preferred embodiments, it is understood that many embodiments are feasible without departing from the principles of the disclosure, and many changes can be made to the preferred embodiments. These and other changes in the preferred embodiments of the present disclosure will be apparent to those skilled in the art from the disclosure herein, and it is clearly understood that the foregoing description is merely illustrative of the present disclosure and not limiting. Advantages of the Present Disclosure

[0118] The present invention provides a multi-layer Network Repository Function (NRF) architecture with multiple NRFs within the same Public Land Mobile Network (PLMN).

[0119] The present invention provides a multi-layer NRF architecture for supporting multi-slices for both shared slices and individual slices with multiple NRFs.

[0120] The present invention provides support for multiple NRFs in the deployment of large-scale mobile network operators (MNOs).

[0121] The present invention provides a solution for routing subscribe update / unsubscribe messages in a multi-NRF scenario.

[0122] The present invention provides a centralized NRF as a network-wide reporter, inventory manager, or configuration manager.

[0123] The present disclosure provides real-time updates because the centralized NRF directly manages data from one or more local NRFs.

[0124] The present disclosure provides a centralized NRF for communication with roaming partners (RPs) and enables future manageability of the RPs.

[0125] The present disclosure provides an NRF transfer policy.

[0126] The present disclosure easily enables scalability of multiple NRF clusters.

[0127] The present disclosure provides a combined NRF for smaller-scale deployments.

[0128] The present invention facilitates the enhancement of network management functions.

[0129] The present disclosure facilitates the optimization of network functions.

Claims

1. A system (1300) for managing routing in a multi-layer network repository function (NRF) architecture including a centralized NRF (104) associated with one or more local NRFs (102), the system (1300) comprising: one or more processors (1302); a memory (1304) operably coupled to the one or more processors (1302), the memory (1304) storing instructions that, when executed, receive an NF service request associated with a serving public land mobile network (PLMN); determine whether the NF service request is to be processed by one of the one or more local NRFs (102); based on the local NRF (102) being unable to process the NF service request, transfer the NF service request to a centralized NRF (104), the processor (1302) being caused to execute the steps. System (1300).

2. The system (1300) according to claim 1, wherein the centralized NRF (104) functions as a gateway serving one or more NFs associated with a communication network (100).

3. The memory (1304) includes processor-executable instructions that, when executed, cause one or more processors (1302) to transfer the NF service request to the centralized NRF (104) based on the NF service request being in a suspended status. The system (1300) according to claim 1.

4. The centralized NRF (104) routes an NF service request associated with the first local NRF (102-1) to a second local NRF (102-2) based on one or more routing tables associated with the centralized NRF (104), the system (1300) according to claim 1.

5. The first local NRF (102-1) and the second local NRF (102-2) are associated with the same PLMN, the system (1300) according to claim 4.

6. The first local NRF (102-1) is associated with a first PLMN and the second local NRF (102-2) is associated with a second PLMN, the system (1300) according to claim 4.

7. The second PLMN is associated with a roaming partner (RP) (110), the system (1300) according to claim 6.

8. The centralized NRF (104) routes an NF service request to a second local NRF (102-2) associated with the second PLMN via a security edge protection proxy (SEPP) (108), the system (1300) according to claim 6.

9. The centralized NRF (104) includes at least one of a separately deployed centralized NRF (104) or a combined NRF (202), the system (1300) according to claim 1.

10. The combined NRF (202) includes a centralized NRF (104) deployed within at least one or more local NRFs (102), the system (1300) according to claim 9.

11. A method for routing a network function (NF) service request within a local network repository function (NRF) (102), the method comprising: At a public land mobile network (PLMN) interface, receiving an NF service request associated with a serving PLMN; Determining, by a determination unit (1312), whether the NF service request is to be processed by a local NRF (102) based on one or more parameters; Transferring the NF service request to a centralized NRF (104) via a centralized NRF interface (1306-1) based on the local NRF (102) being unable to process the NF service request. A method comprising the steps of:

12. By the one or more processors (1302), Processing an NF service request at the local NRF (102) based on the one or more parameters. The method according to claim 11, comprising the step of:

13. The method according to claim 11, wherein the one or more parameters include at least one of a target PLMN, single network slice selection assistance information (S-NSSAI), and an NF type (NFTYPE).

14. A method for routing a network function (NF) service request within a centralized network repository function (NRF) (104), the method comprising: Receiving, at a local NRF interface (1206-3), an NF service request associated with a serving public land mobile network (PLMN) from a first local NRF (102-1); Determining, by a determination unit (1212), a route for the NF service request based on a routing table and PLMN information stored in a database (1216); A method comprising: transferring the NF service request to a second local NRF (102-2) via the local NRF interface (1206-3) based on the determined route. **Claim 15** The method according to claim 14, wherein the routing table includes information associated with at least one of a priority value, a target PLMN, an NF type, a slice number, an action, and an NRF table. **Claim 16** The second local NRF (102-2) is associated with at least one of a serving PLMN, a second access technology independent network (106-2), and a roaming partner (RP) (110). The method according to claim 14. **Claim 17** A non-transitory computer-readable medium storing one or more instructions, which when executed, cause a processor to receive a network function (NF) service request associated with a first local network repository function (NRF) (102-1) within a public land mobile network (PLMN); determine a route for the NF service request to a second local NRF (102-2) based on PLMN information from a routing table and a database (1216); and transfer the NF service request to the second local NRF (102-2) based on the determined route.

Images