Method, system and computer readable medium for applying or overriding recommended location criteria when processing a network function (NF) discovery request - Patents.com

Abstract

A method for applying or overriding recommended location criteria when processing an NF discovery request includes, in an NRF including at least one processor, maintaining an NF profile database including NF profiles of producer NFs registered to provide services to other NFs; receiving an NFDiscover request from an NF including a recommended location attribute or lacking a recommended location attribute; accessing the NF profile database to identify NF profiles of producer NFs that can provide the service indicated by a query parameter in the NFDiscover request; generating an NFDiscover response including the NF profiles identified as capable of providing the service indicated by the query parameter in the NFDiscover request; overriding the recommended location attribute in the NFDiscover request or prioritizing NF profiles in the NFDiscover response in a manner that applies the recommended location attribute selected by the NRF; and sending the NFDiscover response to the NF that sent the NFDiscover request.

Description

[Technical field]

[0001] Priority claim This application claims the benefit of priority to U.S. Patent Application No. 17 / 337,356, filed June 2, 2021, the entire disclosure of which is incorporated herein by reference.

[0002] Technical Field The subject matter described herein relates to processing NF discovery requests. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for applying or overriding recommended location criteria when processing NF discovery requests. [Background technology]

[0003] background In a 5G telecommunications network, a network function that provides a service is referred to as a producer NF or an NF service producer. A network function that consumes a service is referred to as a consumer NF or an NF service consumer. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function consumes, generates, or consumes and generates a service. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0004] A given producer NF may have many service endpoints, which are connection points for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and a port number, or a fully qualified domain name that translates to an IP address and a port number on the network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF may include two or more NF instances. It should also be noted that multiple NF instances can share the same service endpoint.

[0005] A producer NF registers with a Network Function Repository Function (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably herein. A consumer NF can subscribe to receive information about producer NF instances that are registered with the NRF.

[0006] In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the service communication proxy (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the service communication proxy, which load balances traffic among producer NF service instances that offer the required service or routes traffic directly to the destination producer NF instance.

[0007] In addition to the SCP, another example of an intermediate proxy node that routes traffic between producer and consumer NFs is the Security Edge Protection Proxy (SEPP). A SEPP is a network node used to protect the control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). As such, the SEPP performs message filtering, policing and topology hiding for all Application Programming Interface (API) messages sent between PLMNs.

[0008] One problem in 5G communication networks is that during NF discovery, a consumer NF may specify a preferred location parameter in an NF discovery request that has no meaning to the NRF in the NRF's network, or the consumer NF may not specify a preferred location parameter in the NF discovery request. In either case, the NRF receiving the NF discovery request may utilize the query parameters in the NF discovery request to generate a prioritized list of NF profiles of producer NFs that match the query parameters. In generating the prioritized list, the NRF uses each producer NF's registered priority and preferred location information, if any, to set the priority of producer NF profiles to be returned to the consumer NF in the discovery response. For example, the NRF may prioritize producer NFs with locations that match the preferred location attributes in the discovery request over producer NFs with locations that do not match the preferred location attributes in the discovery request. If the preferred location parameter is not present in the NF discovery request, or if the preferred location parameter has no meaning to the NRF since it identifies a location in another network, the priority in the list is set solely based on the registered priority of the producer NF, resulting in producer NFs that are further away from the consumer NF being assigned a lower priority (and may be more recommended) than producer NFs that are closer to the consumer NF. As a result, when selecting a producer NF from the list to provide a service, the consumer NF may select a producer that is further away from the consumer NF over other producer NFs, resulting in increased delay in service communication.

[0009] In view of these and other considerations, a need exists for a method, system, and computer-readable medium for applying or overriding recommended location criteria when processing an NF discovery request. Summary of the Invention [Means for solving the problem]

[0010] overview A method for applying or overriding a recommended location criterion when processing a Network Function (NF) discovery request includes the steps of maintaining, in an NF Repository Function (NRF) including at least one processor, an NF profile database including NF profiles of producer NFs that are registered to provide services to other NFs; receiving an NFDiscover request from an NF that includes a recommended location attribute or lacks a recommended location attribute; accessing the NF profile database to identify NF profiles of producer NFs that can provide the service indicated by a query parameter in the NFDiscover request; generating an NFDiscover response including the NF profiles identified as capable of providing the service indicated by the query parameter in the NFDiscover request; prioritizing NF profiles in the NFDiscover response in a manner that overrides the recommended location attribute in the NFDiscover request or applies a recommended location attribute selected by the NRF when the NFDiscover request does not include the recommended location attribute; and sending the NFDiscover response to the NF that sent the NFDiscover request.

[0011] According to other aspects of the subject matter described herein, receiving an NFDiscover request includes receiving an NFDiscover request including a recommended location attribute set by the NF, and prioritizing the NF profile includes overriding the recommended location attribute selected by the NF with the recommended location attribute selected by the NRF.

[0012] According to other aspects of the subject matter described herein, overriding a recommended location attribute set by the NF with a recommended location attribute selected by the NRF includes overriding a recommended location attribute selected by the NF with a recommended location attribute selected by the NRF that indicates the location of the NRF.

[0013] According to other aspects of the subject matter described herein, overriding a recommended location attribute set by the NF with a recommended location attribute selected by the NRF includes overriding a recommended location attribute selected by the NF with a recommended location attribute selected by the NRF indicating a location closest to the NRF's location or the NRF's own location or any other operator-configured location to be overridden.

[0014] According to other aspects of the subject matter described herein, the step of overriding the recommended location attribute set by the NF with a recommended location attribute selected by the NRF includes a step of overriding the recommended location attribute selected by the NF with a recommended location attribute selected by the NRF indicating a location closest to the NRF, or the location of the NRF itself, or any other operator configured location to be overridden, that has at least one heartbeat producer NF that can provide the service indicated by the query parameter in the NFDiscover request.

[0015] According to other aspects of the subject matter described herein, receiving an NFDiscover request includes receiving an NFDiscover request without a recommended location attribute, and prioritizing the NF profile includes applying the recommended location attribute selected by the NRF.

[0016] According to another aspect of the subject matter described herein, applying the set of recommended location attributes selected by the NRF includes applying recommended location attributes selected by the NRF that indicate the location of the NRF.

[0017] According to another aspect of the subject matter described herein, applying the recommended location attributes selected by the NRF includes applying the recommended location attributes selected by the NRF that indicate a location closest to the location of the NRF.

[0018] According to other aspects of the subject matter described herein, applying the recommended location attribute selected by the NRF includes applying a recommended location attribute selected by the NRF indicating a location closest to the NRF's location that has at least one heartbeat producer NF that can provide the service indicated by the query parameter in the NFDiscover request.

[0019] According to other aspects of the subject matter described herein, receiving an NFDiscover request includes receiving an inter-public land mobile network (PLMN) NFDiscover request or an intra-PLMN NFDiscover request.

[0020] According to another aspect of the subject matter described herein, a system is provided for applying or overriding a recommended location criterion when processing a network function (NF) discovery request. The system includes an NF repository function (NRF) including at least one processor and a memory. The system further includes an NF profile database stored in the memory and including NF profiles of producer NFs that are registered to provide services to other NFs. The system further includes an NF profile manager implemented by the at least one processor for: receiving an NFDiscover request from an NF including a recommended location attribute or lacking a recommended location attribute; accessing the NF profile database to identify NF profiles of producer NFs that can provide the service indicated by a query parameter in the NFDiscover request; generating an NFDiscover response including the NF profiles identified as capable of providing the service indicated by the query parameter in the NFDiscover request; overriding the recommended location attribute in the NFDiscover request or applying the recommended location attribute selected by the NRF when the NFDiscover request does not include the recommended location attribute; and sending the NFDiscover response to the NF that sent the NFDiscover request.

[0021] According to other aspects of the subject matter described herein, the NFDiscover request includes a recommended location attribute set by the NF, and in the step of prioritizing the NF profile, the NF profile manager is configured to override the recommended location attribute selected by the NF with the recommended location attribute selected by the NRF.

[0022] According to another aspect of the subject matter described herein, the location attribute of the recommendation selected by the NRF indicates the location of the NRF.

[0023] According to another aspect of the subject matter described herein, the location attribute of the recommendation selected by the NRF indicates the location closest to the location of the NRF.

[0024] According to other aspects of the subject matter described herein, the recommended location attribute selected by the NRF indicates a location that is closest to the location of an NRF that has at least one heartbeat producer NF that can provide the service indicated by the query parameters in the NFDiscover request.

[0025] According to another aspect of the subject matter described herein, the location attribute of the recommendation selected by the NRF is indicative of an operator configured location.

[0026] According to another aspect of the subject matter described herein, the NFDiscover request does not include a recommended location attribute, and in the step of prioritizing the NF profile, the NF profile manager is configured to apply the recommended location attribute selected by the NRF.

[0027] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having executable instructions stored thereon, the instructions, when executed by a processor of the computer, controlling the computer to perform steps. The steps are performed in a Network Function (NF) Repository Function (NRF). The steps include maintaining an NF profile database including NF profiles of producer NFs that are registered to provide services to other NFs. The steps further include receiving an NFDiscover request from an NF that includes a recommended location attribute or lacks a recommended location attribute. The steps further include accessing the NF profile database to identify NF profiles of producer NFs that can provide the service indicated by a query parameter in the NFDiscover request. The steps further include generating an NFDiscover response including the NF profiles identified as capable of providing the service indicated by the query parameter in the NFDiscover request. The steps further include prioritizing NF profiles in the NFDiscover response in a manner that overrides the recommended location attribute in the NFDiscover request or applies the recommended location attribute selected by the NRF when the NFDiscover request does not include the recommended location attribute. The steps further include transmitting the NFDiscover response to the NF that sent the NFDiscover request.

[0028] The subject matter described herein can be implemented in software, in combination with hardware and / or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In one exemplary embodiment, the subject matter described herein can be implemented using a non-transitory computer-readable medium that stores computer-executable instructions, which, when executed by a processor of a computer, control the computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. In addition, the computer-readable medium implementing the subject matter described herein can be located on a single device or computing platform or distributed across multiple devices or computing platforms.

[0029] Exemplary embodiments of the subject matter described herein are described below with reference to the accompanying drawings. [Brief description of the drawings]

[0030] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G system network architecture. [Diagram 2] FIG. 13 is a network diagram illustrating inter-PLMN use cases for applying or overriding recommended location criteria when processing an NF discovery request. [Diagram 3] FIG. 13 is a network diagram illustrating a use case within a PLMN for applying or overriding recommended location criteria when processing an NF discovery request. [Figure 4] FIG. 13 is a message flow diagram illustrating example messages exchanged between a consumer NF and an NRF during NF discovery. [Diagram 5]FIG. 13 is a message flow diagram showing example messages exchanged for an inter-PLMN use case in which the NRF applies or overrides the recommended location criteria when processing an NF discovery request. [Figure 6] FIG. 13 is a message flow diagram showing example messages exchanged for an intra-PLMN use case, in which the NRF applies or overrides the recommended location criteria when processing an NF discovery request. [Figure 7] FIG. 1 is a block diagram illustrating an example architecture for an NRF that applies or overrides recommended location criteria when processing an NF discovery request. [Figure 8] 11 is a flowchart illustrating an example process performed by the NRF to apply or override recommended location criteria when processing an NF discovery request. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] Detailed Description FIG. 1 is a block diagram illustrating an example 5G system network architecture. The architecture of FIG. 1 includes an NRF 100 and an SCP 101, which may be located in the same Home Public Land Mobile Network (HPLMN). As described above, the NRF 100 may maintain a profile of available producer NF service instances and their supported services, and enable consumer NFs or SCPs to subscribe and be notified of new / updated producer NF service instance registrations. The SCP 101 may also support service discovery and selection of producer NF instances. The SCP 101 may perform load balancing of connections between consumer NFs and producer NFs.

[0032] The NRF 100 is a repository for the service profiles of NFs or producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the service profile of the NF or producer NF instance from the NRF 100. An NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS 29.510. An 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.

[0033] In Figure 1, any of the network functions can be a consumer NF, a producer NF, or both, depending on whether they are requesting, providing, or both, a service. In the illustrated example, the NFs include a Policy Control Function (PCF) 102 that performs policy-related operations within the network, a Unified Data Manager (UDM) 104 that manages user data, and an Application Function (AF) 106 that provides application services.

[0034] 1 further includes 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 4G networks. An Authentication Server Function (AUSF) 112 performs authentication services for user equipment (UE) such as user equipment (UE) 114 seeking access to the network.

[0035] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice. The Network Exposure Function (NEF) 118 provides application programming interfaces (APIs) 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.

[0036] The Radio Access Network (RAN) 120 connects the User Equipment (UE) 114 to the network via wireless links. The Radio Access Network 120 may be accessed using a g-NodeB (gNB) (not shown in FIG. 1) or other wireless access points. The User Plane Function (UPF) 122 may support various proxy functions for user plane services. One example of such a proxy function is a Multi-Path Transmission Control Protocol (MPTCP) proxy function. The UPF 122 may support a performance measurement function that may be used by the UE 114 to obtain network performance measurements. Also shown in FIG. 1 is a Data Network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0037] The SEPP 126 filters traffic coming from other PLMNs and performs topology hiding for traffic going out from the home PLMN. The SEPP 126 may communicate with a SEPP in the foreign PLMN that manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and another for the foreign PLMN.

[0038] As mentioned above, one problem in 5G networks is that during NF discovery, consumer NFs do not specify a preferred location attribute or specify a preferred location attribute that has no meaning in the receiving NRF's network. As a result, suboptimal producer NF selection may occur. During registration with the NRF, each producer NF may specify its location as a registration attribute or parameter that is stored by the NRF in a data structure called an NF profile or NF profile object. The registration process is performed according to 3GPP TS 29.510, where each NF sends an NF registration message to the NRF 100. The NF registration message includes the NF profile of each NF. Table 6.1.6.2.2-1 of 3GPP TS 29.510 defines attributes that may be included in an NF profile. The location attributes of the NF profile are of interest to the subject matter described herein. Table 1 shown below is an excerpt from Table 6.1.6.2.2-1 of 3GPP TS 29.510 showing location attributes.

[0039] [Table 1]

[0040] As shown in Table 1, the location attribute stores operator-defined information about the location, e.g., geographic location and data center, of an NF instance. According to Note 3 in Table 1, the location attribute can be used during NF discovery to select a producer NF that is in the same data center as the requesting consumer NF. However, the consumer NF may not know the correct location attribute to specify in the discovery request message, which may result in suboptimal NF selection.

[0041] The preferred location is an optional attribute that may be included in an NFDiscover request message. Table 2 shown below is an excerpt from Table 6.2.3.2.3.1-1 of 3GPP TS 29.510 and shows how the NRF processes the preferred location attribute in an NFDiscover request.

[0042] [Table 2]

[0043] From Table 2, when a preferred location attribute is present, the NRF MUST prefer NF profiles with location attributes that match the preferred location in the NFDiscover request. For example, if no NF profile is discovered that matches the preferred location, the NRF MAY also return additional NF profiles that do not match the preferred location in the discovery response. The NRF MAY also set a lower priority in the discovery response for additional NF profiles that do not match the preferred location.

[0044] Thus, during NF discovery, the preferred location is an optional attribute sent by a consumer NF during discovery and configured by the network operator to indicate, when present, the preferred location of the producer NF that serves the consumer NF. Typically, the preferred location of a consumer NF is the location of the consumer NF or the location of the preferred producer NF. The NRF MUST set a less preferred (higher numbered according to the 3GPP-defined priority numbering scheme, where lower priority numbers indicate more preferred) priority in the discovery response for any additional NFs with registered location parameters that do not match the preferred location identified in the NFDiscover request. NF profiles that match the search criteria of the discovery request are ordered as follows: Recommended locations Registered priority Challenges associated with current NF discovery methods include the following: Inter-PLMN discovery requests from outside the PLMN of the NRF processing the discovery request do not contain the recommended location attributes or contain recommended location attributes that have no meaning within the PLMN of the NRF. Network operators may be reluctant to share location attributes across PLMN boundaries. As a result, NFDiscover requests may not contain recommended location attributes that match locations within the PLMN of the NRF. In most cases, these inter-PLMN discovery requests reach NRFs in other PLMNs in areas close to the consumer NF. In Fig. 2, area #1 in PLMN-A is shown close to area #1 in PLMN-B and far from area #2 in PLMN-B. Therefore, in most cases, inter-PLMN discovery requests from the consumer NF 200 reach NRF 100A in area #1 of PLMN-B. In the absence of a preferred location attribute in the NF discovery request, the list of NF profiles of producer NFs returned in the discovery response may prefer producer NFs located further away from the consumer NF than other less preferred (higher priority) producer NFs in the list. In FIG. 2, in the absence of a preferred location attribute, the NF profiles of producer NFs returned by the NRF 100A may be in the following order {Producer NF#2 204 (priority-1), Producer NF#1 202 (priority-2)}, i.e., based on priority. With this priority order, the consumer NF 200 will likely select the producer NF#2 204 (priority -1) to process the service request, which will result in an unnecessarily costly communication path for the consumer NF 200, because the producer NF#2 204 is farther from the consumer NF 200 than the producer NF#1 202. The above mentioned challenges also apply to intra-PLMN discovery use cases, as shown in Fig. 3, where intra-PLMN discovery has no preferred location attributes or has non-meaning preferred location attributes in the NRF's domain. In most cases, the discovery request reaches the nearest regional NRF. In Fig. 3, an intra-PLMN discovery request from a consumer NF 200 will likely reach the regional NRF 100A. The regional NRF 100A selects NF profiles of NFs matching the query parameters in the discovery request and generates a prioritized list of NF profiles to send to the consumer NF 200 in a discovery response. Since producer NF#2 204 has a lower priority than producer NF#1 202, the NRF 100A prioritizes producer NF#2 204 over producer NF#1 202. Similar to the inter-PLMN discovery case, even if producer NF#1 202 is closer, the consumer NF 200 will select producer NF#2 204 to process the service request, resulting in a suboptimal producer NF selection.

[0045] FIG. 4 is a message flow diagram illustrating exemplary messages exchanged between an NF service consumer and an NRF when performing NF discovery. At line 1 of the message flow diagram shown in FIG. 4, the NF service consumer 200 initiates the NF discovery process by sending an HTTP GET message to the NRF 100. The HTTP GET message sent to the NRF to obtain the service profile of an NF instance is also referred to as an NFDiscover request or an NF discovery request. The HTTP GET message includes a query parameter (e.g., NFtype) that the NRF uses to locate the NF profiles of producer NFs that can provide the service identified by the query parameter or attribute. One such parameter or attribute is a preferred location attribute. If the NF service consumer 200 can create an NF discovery message with a preferred location attribute that corresponds to an area in the PLMN of the NRF 100, the preferred location attribute can be effectively used to select a producer NF that is closer to the consumer NF 200 than other producer NFs. However, if the NF service consumer 200 cannot include the recommended location parameters or does not include the recommended location parameters that have meaning within the PLMN of the NRF 100, the NRF 100 may prioritize the list of NF profiles returned to the consumer NF 200 in the discovery response based on the registered producer NF priorities, which may result in suboptimal NF selection, as shown in Figures 2 and 3.

[0046] In lines 2A and 2B of the message flow diagram of Figure 4, if the NF discovery request is processed successfully, the NRF 100 responds with a 200OK message that includes an NF profile object that corresponds to the NF profile of the producer NF that can provide the service identified in the discovery request. If the NF discovery process is not successful, the NRF 100 may return a 4xx or 5xx message with details of the problem.

[0047] If the NF discovery request is redirected to another NRF, the NRF 100 returns a 3xx message. Note that the subject matter described herein applies to NF discovery requests from an NRF in a PLMN serving a consumer NF to an NRF in a home PLMN, as detailed in section 5.3.2.2.3 of 3GPP TS 29.510, and to service discovery, where an intermediate forwarding NRF receives an NF discovery request from a consumer NF and forwards the NF discovery request to an NRF in another network or domain, as detailed in section 5.2.2.2.5 of 3GPP TS 29.510. The NRF receiving the forwarded NF discovery request consults an NF profile database and retrieves an NF profile that matches the query parameters in the NF discovery request.

[0048] To avoid suboptimal NF selection, the subject matter described herein includes an NRF that can process NF discovery requests both with and without recommended location parameters, and can apply or override the recommended location information in the NF discovery request when processing the NF discovery request using location information maintained by the NRF. When the NRF receives a discovery request between PLMNs that does not have the recommended location parameters or has the recommended location parameters that the NRF chooses to override, the NRF can choose to process a list of matching producer NFs, which can include: Using the location of NRF, Using the location closest to the NRF, or This is done using the closest NRF that has at least one registered (successful heartbeat) producer NF instance matching the query parameters in the NF discovery request.

[0049] If the NRF receives a discovery request in a PLMN with or without the recommended location parameters, it can choose to override the recommended location parameters in the NF discovery request or to apply the NRF selected parameters again and process a list of matching producer NFs, which includes: Using the location of NRF, Using the location closest to the NRF, or This is done using the closest NRF that has at least one registered (successful heartbeat) producer NF instance matching the query parameters in the NF discovery request.

[0050] In any of the above cases, processing the list of matching NFs means that the NRF sets priorities in the list of NF profiles returned to the NF service consumer using its own location, the closest location (to the NRF) or the closest location with a matching heartbeat producer NF.

[0051] FIG. 5 is a message flow diagram illustrating an NRF applying or overriding a recommended location attribute when processing an inter-PLMN discovery request. Referring to FIG. 5, producer NFs 202 and 204 are located in area #1 and area #2 of PLMN-B, respectively, and consumer NF 200 is located in area #1 of PLMN-A. Area #1 of PLMN B is geographically closer to area #1 of PLMN-A than area #2 of PLMN-B is to area #1 of PLMN-A. Producer NF#1 202 has registered its NF profile with NRF 100 with a priority of 2. Producer NF#2 204 has registered its NF profile with NRF 100A with a priority of 1, which means that in the absence of a mechanism to override the priority, NRF 100A would indicate in the discovery response to consumer NF 200 that producer NF#2 204 is preferred over producer NF#1 202, which would result in a suboptimal producer NF selection.

[0052] In the illustrated example, when a consumer NF 200 located in PLMN-A transmits a discovery request to an NRF 100A located in region #1 of PLMN B, the discovery request may lack a recommended location attribute or may include a recommended location attribute corresponding to the location of the consumer NF in PLMN-A (region #1) that has no meaning in PLMN B. In response to receiving this type of discovery request, the NRF 100A may override the recommended location attribute or apply an NRF-selected location attribute depending on whether the discovery request has a recommended location attribute. For example, if the NF discovery request has a recommended location attribute, the NRF 100A may override the recommended location attribute in the NF discovery request when returned to the consumer NF 200 in preference to an NF profile in the list of NF profiles. If the NF discovery request lacks a recommended location attribute, the NRF 100A may apply or use the NRF-selected location attribute when returned to the consumer NF 200 in preference to an NF profile in the list of NF profiles.

[0053] In one example, the NRF 100A may override or apply the location and use its own location when processing the discovery request. In another example, the NRF 100A may utilize the location closest to the NRF and / or the location closest to the NRF that has a heartbeat producer NF that can provide the service identified from the query parameter in the discovery request. A consumer NF is likely to send an NF discovery request to an NRF that is in an area or PLMN close to the requesting consumer NF. As a result, using the NRF's own location, the closest location known to the NRF, the location configured by the network operator, and / or the location closest to the NRF that has a heartbeat producer NF that matches the query parameter to process the discovery request has a good chance of generating a list of NF profiles of producer NFs closer to the requesting consumer NF with a lower (more recommended) priority than NF profiles of producer NFs that are further away from the requesting consumer NF.

[0054] In the illustrated example, the NRF 100A returns a preferred list of NF profiles with the NF profile of producer NF#1 202 having a lower priority (more recommended) than that of producer NF#2 204. As a result, when the consumer NF 200 selects a producer NF for processing a service request, the consumer NF 200 will select producer NF#1 202 over producer NF#2 204 to process the service request, resulting in more efficient and lower latency service communication in the core network than the scenario shown in FIG. 2. As described above with reference to FIG. 4, it is not necessary that the discovery request originates from the consumer NF 200. Instead of the consumer NF 200, the discovery request may originate from an NRF in case of redirection or inter-PLMN, as described in 3GPP TS 29.510. The NF discovery request may also originate from an NCP. The location-based invalidation or adaptation process described herein can be used by an NRF when processing NF discovery requests originating from a consumer NF, an SCP or another NRF.

[0055] 5, it should be noted that the NRF 100A assigns priorities to the NF profiles in the NF discovery response that override the priorities registered for the NF profiles in the NRF 100A. Overriding the priorities means that the NRF 100A assigns new priorities based on the location of the NRF 100A or the location of the nearest producer NF that is available and can handle the service identified in the discovery request. When multiple NFs that can handle or provide the service identified in the NF discovery request are co-located, the priorities registered by the producer NFs 202 and 204 may be taken into account.

[0056] Overriding or applying the preferred location for NF discovery requests also applies to intra-PLMN discovery requests, i.e., discovery requests sent from NFs to NRFs that are both in the same PLMN. Figure 6 illustrates this case. Referring to Figure 6, producer NFs 202 and 204 are located in area #1 and area #2 of PLMN-B, respectively, and consumer NF 200 is located in area #1 of PLMN-B. Producer NF#1 202 has registered its NF profile with NRF 100 having a priority of 2. Producer NF#2 204 has registered its NF profile with NRF 100A having a priority of 1, which means that in the absence of a mechanism to override the priority, NRF 100A would indicate in the discovery response to consumer NF 200 that producer NF#2 204 is preferred over producer NF#1 202, which would result in a suboptimal producer NF selection.

[0057] In the illustrated example, when a consumer NF 200 located in region #1 of PLMN-B transmits a discovery request to an NRF 100A also located in region #1 of PLMN B, the discovery request may lack a recommended location attribute or may include a recommended location attribute corresponding to the location of the consumer NF in PLMN-B (region #1). In response to receiving such a discovery request, the NRF 100A may override the recommended location attribute or apply an NRF-selected recommended location attribute depending on whether the discovery request has a recommended location attribute. For example, if the NF discovery request has a recommended location attribute, the NRF 100A may override the recommended location attribute in the NF discovery request when returned to the consumer NF 200 in preference to an NF profile in the list of NF profiles. If the NF discovery request lacks a recommended location attribute, the NRF 100A may apply or use an NRF-selected location attribute when returned to the consumer NF 200 in preference to an NF profile in the list of NF profiles.

[0058] In one example, the NRF 100A may override or apply the location and use its own location when processing the discovery request. In another example, the NRF 100A may utilize the location closest to the NRF and / or the location closest to the NRF that has a heartbeat producer NF that can provide the service identified from the query parameter in the discovery request. A consumer NF is likely to send an NF discovery request to an NRF that is in a region or PLMN close to the requesting consumer NF. As a result, using the NRF's own location, the location closest to the NRF known to the NRF and / or the location closest to the NRF that has a heartbeat producer NF that matches the query parameter to process the discovery request has a good chance of generating a list of NF profiles of producer NFs closer to the requesting consumer NF with a lower (more recommended) priority than NF profiles of producer NFs that are further away from the requesting consumer NF.

[0059] In the illustrated example, the NRF 100A returns a preferred list of NF profiles with the NF profile of producer NF#1 202 having a lower priority (more recommended) than producer NF#2 204. As a result, when the consumer NF 200 selects a producer NF for processing a service request, the consumer NF 200 will select producer NF#1 202 over producer NF#2 204 to process the service request, resulting in more efficient and lower latency service communication in the core network than the scenario shown in FIG.

[0060] Note that in FIG. 6, similar to the inter-PLMN case shown in FIG. 5, the NRF 100A assigns priorities to NF profiles in the NF discovery response that override the priorities registered for the NF profiles in the NRF 100A. Overriding the priorities means that the NRF 100A assigns new priorities based on the location of the NRF 100A or the location of the nearest producer NF that can use and handle the service identified in the discovery request. When multiple NFs that can handle or provide the service identified in the NF discovery request are co-located, the priorities registered by the producer NFs 202 and 204 may be taken into account.

[0061] FIG. 7 is a block diagram illustrating an example architecture for an NRF 100 that can apply or override a recommended location during NF discovery. With reference to FIG. 7, the NRF 100 includes at least one processor 700 and a memory 702. The NRF 100 further includes an NF profile database 704 that stores NF profiles of producer NFs that are registered by the NRF 100. The NRF 100 further includes an NF profile manager 706, which registers producer NFs with the NRF 100 by receiving and processing NF registration request messages and storing NF profiles in the memory 702. The NF profile manager 706 may also perform steps described herein for processing an NF discovery request, including applying or overriding a recommended location when processing an NF discovery request. The NF profile manager 706 may be implemented with computer-executable instructions stored in the memory 702 and executed by the processor 700. The NRF 100 illustrated in FIG. 7 may be one of many instances expanded within a single NRF deployment. In this case, the NF profile database 704 replicates the NF profiles of producer NFs registered by other NRF instances.

[0062] FIG. 8 is a flow chart illustrating an example process for applying or overriding a recommended location during NF discovery. With reference to FIG. 8, in step 800, the process includes maintaining an NF profile database including NF profiles of producer NFs that are registered to provide services to other NFs. For example, the NRF 100 may maintain an NF profile database 704 that stores NF profiles of NFs that are registered by the NRF. The NF profiles may include parameters or attributes described in 3GPP TS 29.510, including location attributes.

[0063] In step 802, the process includes receiving an NFDiscover request from an NF that includes or lacks recommended location attributes. As described above, the NFDiscover request may originate from a consumer NF, an SCP, or another NRF.

[0064] In step 804, the process includes accessing an NF profile database to identify an NF profile of a producer NF that can provide the service indicated by the query parameters in the NFDiscover request. For example, the NRF 100 performs a search in the NF profile database 704 using the query parameters from the NFDiscover request. The query parameters specified in the NFDiscover request may include any of the query parameters specified in Table 6.1.3.2.3.1-1 of 3GPP TS 29.510. Examples of query parameters that may be used include NFType, e.g., UDM, PCF, etc., which identifies the type of NF to provide the service required by the consumer NF.

[0065] In step 806, the process includes generating an NFDiscover response that includes the NF profiles identified as capable of providing the service indicated by the query parameters in the NFDiscover request. For example, the NRF 100 may generate an NFDiscover response and may include the NF profiles located in step 804 in the NFDiscover response.

[0066] In step 808, the process includes prioritizing NF profiles in the NFDiscover response in a manner that overrides the recommended location attribute in the NFDiscover request or applies a location attribute selected by the NRF. For example, the NRF 100 may apply its own location, the location closest to the NRF, or the location closest to the NRF that has a heartbeat producer NF that can provide the service identified in the NFDiscover request when prioritizing the NF profiles in a list and returning them to the requesting NF. The priorities may be set in a manner that favors producer NFs closer to the location used by the NRF to process the NFDiscover request over producer NFs that are further away from the location used by the NRF to process the NFDiscover request.

[0067] In step 810, the process includes sending an NFDiscover response to the NF that sent the NFDiscover request. For example, the NRF 100 may send an NFDiscover response to the requesting NF that includes a prioritized list or array of NRF selected locations of NF profile objects.

[0068] Advantages of the subject matter described herein include enhanced NF discovery for both inter-PLMN and intra-PLMN discovery requests. Because the list of NF profiles returned to a requesting consumer NF is prioritized according to the NRF selected location, the consumer NF is more likely to select a producer NF to provide services closer to the consumer NF, resulting in more efficient service messaging in the network.

[0069] The disclosure of each of the following references is incorporated herein by reference in its entirety.

[0070] References 1. 3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 17) 3GPP TS 23.501 V17.0.0 (2021-03) twenty three rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17) 3GPP TS 29.510 V17.1.0 (2021-03) It should be understood that various details of the subject matter described herein may be changed without departing from the spirit of the subject matter described herein. Moreover, the above description is illustrative only and not limiting of the subject matter described herein, as defined by the claims below.

Claims

1. 1. A method for applying or overriding recommended location criteria when processing a Network Function (NF) discovery request, the method comprising: In a NF Repository Function (NRF) including at least one processor, maintaining a NF profile database containing NF profiles of producer NFs that are registered to provide services to other NFs; receiving an NFDiscover request from an NF, the NFDiscover request including or lacking a recommended location attribute; accessing the NF profile database to identify a NF profile of a producer NF that can provide the service indicated by a query parameter in the NFDiscover request; generating an NFDiscover response that includes the NF profiles identified as capable of providing the service indicated by the query parameters in the NFDiscover request; prioritizing the NF profile in the NFDiscover response in a manner that overrides a recommended location attribute in the NFDiscover request or applies a recommended location attribute selected by the NRF when the NFDiscover request does not include a recommended location attribute; sending the NFDiscover response to the NF that sent the NFDiscover request.

2. receiving the NFDiscover request includes receiving the NFDiscover request including a recommended location attribute set by the NF; The method of claim 1 , wherein prioritizing the NF profile comprises overriding a preferred location attribute selected by the NF with a preferred location attribute selected by the NRF.

3. 3. The method of claim 2, wherein overriding a recommended location attribute set by the NF with a recommended location attribute selected by the NRF comprises overriding a recommended location attribute selected by the NF with a recommended location attribute selected by the NRF that indicates a location of the NRF or a location closest to the location of the NRF.

4. The method of claim 2 or claim 3, wherein overriding a recommended location attribute set by the NF with a recommended location attribute selected by the NRF comprises overriding a recommended location attribute selected by the NF with a recommended location attribute selected by the NRF configured by a network operator.

5. The method of claim 2 or claim 3, wherein the step of overriding a recommended location attribute set by the NF with a recommended location attribute selected by the NRF includes the step of overriding a recommended location attribute selected by the NF with a recommended location attribute selected by the NRF indicating a location closest to the NRF's location that has at least one heartbeat producer NF that can provide the service indicated by the query parameter in the NFDiscover request.

6. The method according to any one of claims 1 to 3, wherein the step of receiving an NFDiscover request includes a step of receiving the NFDiscover request without a recommended location attribute, and the step of prioritizing the NF profile includes a step of applying a recommended location attribute selected by the NRF.

7. 7. The method of claim 6, wherein applying a recommended location attribute selected by the NRF comprises applying a recommended location attribute selected by the NRF that indicates a location of the NRF or a location closest to the location of the NRF.

8. The method of claim 6 , wherein applying the NRF selected recommended location attributes comprises applying the NRF selected recommended location attributes configured by a network operator.

9. 7. The method of claim 6, wherein applying the recommended location attribute selected by the NRF includes applying the recommended location attribute selected by the NRF indicating a location closest to the NRF location that has at least one heartbeat producer NF that can provide the service indicated by the query parameter in the NFDiscover request.

10. The method according to any one of claims 1 to 3, wherein the step of receiving an NFDiscover request comprises the step of receiving an inter-Public Land Mobile Network (PLMN) NFDiscover request or an intra-PLMN NFDiscover request.

11. 1. A system for applying or overriding recommended location criteria when processing a network function (NF) discovery request, the system comprising: a NF Repository Function (NRF) including at least one processor and a memory; a NF profile database stored in the memory and including NF profiles of producer NFs that are registered to provide services to other NFs; a NF profile manager, the NF profile manager comprising: receiving an NFDiscover request from an NF, the NFDiscover request including or lacking a recommended location attribute; accessing the NF profile database to identify an NF profile of a producer NF that can provide a service indicated by a query parameter in the NFDiscover request; generating an NFDiscover response that includes the NF profiles identified as capable of providing the service indicated by the query parameters in the NFDiscover request; prioritizing the NF profile in the NFDiscover response in a manner that overrides a recommended location attribute in the NFDiscover request or applies a recommended location attribute selected by the NRF when the NFDiscover request does not include a recommended location attribute; and sending the NFDiscover response to the NF that sent the NFDiscover request.

12. 12. The system of claim 11, wherein the NFDiscover request includes a recommended location attribute set by the NF, and in the step of prioritizing the NF profile, the NF profile manager is configured to override a recommended location attribute selected by the NF with a recommended location attribute selected by the NRF.

13. The system of claim 12 , wherein a location attribute of a recommendation selected by the NRF indicates a location of the NRF or a location closest to the location of the NRF.

14. The system of claim 12 or claim 13, wherein the recommended location attributes selected by the NRF include recommended location attributes configured by a network operator.

15. The system of claim 12 or claim 13, wherein the recommended location attribute selected by the NRF indicates a location closest to the NRF's location that has at least one heartbeat producer NF that can provide the service indicated by the query parameter in the NFDiscover request.

16. The system of any one of claims 11 to 13, wherein the NFDiscover request does not include a recommended location attribute, and in the step of prioritizing the NF profile, the NF profile manager is configured to apply a recommended location attribute selected by the NRF.

17. The system of claim 16 , wherein a location attribute of a recommendation selected by the NRF indicates a location of the NRF or a location closest to the NRF's location.

18. 20. The system of claim 16, wherein the recommended location attributes selected by the NRF include recommended location attributes configured by a network operator.

19. The system of claim 16, wherein the recommended location attribute selected by the NRF indicates a location closest to the NRF's location that has at least one heartbeat producer NF that can provide the service indicated by the query parameter in the NFDiscover request.

20. A computer readable program storing executable instructions that, when executed by a processor of a computer, In the Network Function (NF) Repository Function (NRF), maintaining a NF profile database containing NF profiles of producer NFs that are registered to provide services to other NFs; receiving an NFDiscover request from an NF, the NFDiscover request including or lacking a recommended location attribute; accessing the NF profile database to identify a NF profile of a producer NF that can provide the service indicated by a query parameter in the NFDiscover request; generating an NFDiscover response that includes the NF profiles identified as capable of providing the service indicated by the query parameters in the NFDiscover request; prioritizing the NF profile in the NFDiscover response in a manner that overrides a recommended location attribute in the NFDiscover request or applies a recommended location attribute selected by the NRF when the NFDiscover request does not include a recommended location attribute; sending the NFDiscover response to the NF that sent the NFDiscover request.

Images