METHODS, SYSTEMS, AND COMPUTER READABLE MEDIA FOR USING SERVICE COMMUNICATIONS PROXY (SCP) OR SECURITY EDGE PROTECTION PROXY (SEPP) TO APPLY OR OVERRIDE PREFERRED-LOCALITY ATTRIBUTE DURING NETWORK FUNCTION (NF) DISCOVERY

Abstract

A method for applying or overriding a preferred-locality attribute during network function (NF) discovery includes, at a service communications proxy (SCP) or security edge protection proxy (SEPP) including at least one processor, receiving, from an NF, an NF discovery request including a preferred-locality attribute or lacking a preferred-locality attribute. The method further includes selecting, by the SCP or SEPP, a value for the preferred-locality attribute for the NF discovery request. The method further includes inserting, by the SCP or SEPP, the value for the preferred-locality attribute into the NF discovery request. The method further includes transmitting, by the SCP or SEPP, the NF discovery request to a network function repository function (NRF).

Claims

1. A method for applying or overriding a preferred-locality attribute during network function (NF) discovery, the method comprising: at a service communications proxy (SCP) or security edge protection proxy (SEPP) including at least one processor: receiving, from an NF, an NF discovery request including a preferred-locality attribute or lacking a preferred-locality attribute; selecting, by the SCP or SEPP, for the preferred-locality attribute for the NF discovery request; inserting, by the SCP or SEPP, the value for the preferred-locality attribute into the NF discovery request; and transmitting, by the SCP or SEPP, the NF discovery request to a network function repository function (NRF).

2. The method of claim 1 wherein receiving the NF discovery request includes receiving the NF discovery request with a preferred-locality attribute value set by the NF and wherein inserting the value for the preferred-locality attribute into the NF discovery request includes replacing a value of the preferred-locality attribute set by the NF.

3. The method of claim 1 wherein selecting a value for the preferred-locality attribute includes selecting a value for the preferred-locality attribute that corresponds to a locality of the SCP or SEPP or a locality nearest to the locality of the SCP or SEPP.

4. The method of claim 1 wherein selecting a value for the preferred-locality attribute includes selecting a value for the preferred-locality attribute that is configured by a network operator.

5. The method of claim 1 wherein selecting a value for the preferred-locality attribute includes selecting a value for the preferred-locality attribute that corresponds to a nearest locality to a locality of the SCP or SEPP with at least one heart-beating producer NF capable of providing the service indicated by query parameters in the NF discovery request.

6. The method of claim 1 wherein receiving the NF discovery request includes receiving the NF discovery request without a preferred-locality attribute and wherein inserting the value for the preferred-locality attribute into the NF discovery request includes adding a value of the preferred-locality attribute to the NF discovery request.

7. The method of claim 1 wherein the SCP or SEPP comprises an SEPP and the NF discovery request comprises an inter-PLMN NF discovery request.

8. The method of claim 1 wherein the SCP or SEPP comprises an SCP and the NF discovery request comprises an inter-PLMN NF discovery request.

9. The method of claim 1 wherein the SCP or SEPP comprises an SCP and the NF discovery request comprises an intra-PLMN NF discovery request.

10. The method of claim 1 comprising, at the NRF, using the value of the preferred-locality attribute selected by the SCP or SEPP to prioritize producer NF profiles in an NF discovery response.

11. A system for applying or overriding a preferred-locality attribute during network function (NF) discovery, the system comprising: a service communications proxy (SCP) or security edge protection proxy (SEPP) including at least one processor; and a preferred-locality apply/override module implemented by the at least one processor for receiving, from an NF, an NF discovery request including a preferred-locality attribute or lacking a preferred-locality attribute, selecting a value for the preferred-locality attribute for the NF discovery request, inserting the value for the preferred-locality attribute into the NF discovery request, and transmitting the NF discovery request to a network function repository function (NRF)

12. The system of claim 11 the NF discovery request received by the preferred-locality apply/override module includes a preferred-locality attribute value set by the NF and wherein the preferred-locality apply/override module is configured to replace a value of the preferred-locality attribute set by the NF.

13. The system of claim 11 wherein the preferred-locality apply/override module is configured to select a value for the preferred-locality attribute that corresponds to a locality of the SCP or SEPP or a locality nearest to the locality of the SCP or SEPP.

14. The system of claim 11 wherein the preferred-locality apply/override module is configured to select a value for the preferred-locality attribute that is configured by a network operator.

15. The system of claim 11 wherein the preferred-locality apply/override module is configured to select a value for the preferred-locality attribute that corresponds to a nearest locality to a locality of the SCP or SEPP with at least one heart-beating producer NF capable of providing the service indicated by query parameters in the NF discovery request.

16. The system of claim 11 wherein the NF discovery request received by the preferred-locality apply/override module lacks a preferred-locality attribute and wherein the preferred-locality apply/override module is configured to add a value of the preferred-locality attribute to the NF discovery request.

17. The system of claim 11 wherein the SEPP or SCP comprises an SEPP and the NF discovery request received by the preferred-locality apply/override module comprises an inter-PLMN NF discovery request.

18. The system of claim 11 wherein the SEPP or SCP comprises an SCP and the NF discovery request received by the preferred-locality apply/override module comprises an inter-PLMN NF discovery request.

19. The system of claim 11 wherein the SEPP or SCP comprises an SCP and the NF discovery request received by the preferred-locality apply/override module comprises an intra-PLMN NF discovery request.

20. A non-transitory computer readable medium having stored thereon executable instructions that when executed by a processor of a computer control the computer to perform steps comprising: at a service communications proxy (SCP) or security edge protection proxy (SEPP): receiving, from a network function (NF), an NF discovery request including a preferred-locality attribute or lacking a preferred-locality attribute; selecting, by the SCP or SEPP, for the preferred-locality attribute for the NF discovery request; inserting, by the SCP or SEPP, the value for the preferred-locality attribute into the NF discovery request; and transmitting, by the SCP or SEPP, the NF discovery request to a network function repository function (NRF).

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Exemplary implementations of the subject matter described herein will now be explained with reference to the accompanying drawings, of which:

[0033] FIG. 1 is a network diagram illustrating an exemplary 5G system network architecture;

[0034] FIG. 2A is a network diagram illustrating an inter-PLMN use case for using an SCP or an SEPP to apply or override preferred-locality criteria in NF discovery requests;

[0035] FIG. 2B is a message flow diagram illustrating exemplary messages exchanged between the network entities illustrated in FIG. 2A

[0036] FIG. 3A is a network diagram illustrating an intra-PLMN use case for using an SCP or an SEPP to apply or override a preferred-locality attribute in an NF discovery request;

[0037] FIG. 3B is a message flow diagram illustrating exemplary messages exchanged for the intra-PLMN use case of FIG. 3A;

[0038] FIG. 4 is a message flow diagram illustrating exemplary messages exchanged between a consumer NF and an NRF during NF discovery;

[0039] FIGS. 5A and 5B are flow diagrams illustrating exemplary messages exchanged for the inter-PLMN use case where the SCP or SEPP applies or overrides a preferred-locality attribute in an NF discovery request;

[0040] FIG. 6 is a message flow diagram illustrating exemplary messages exchanged for the intra-PLMN use case where the SCP applies or overrides a preferred-locality attribute in an NF discovery request;

[0041] FIG. 7 is a block diagram illustrating an exemplary architecture for an SCP or SEPP that applies or overrides a preferred-locality attribute in an NF discovery request; and

[0042] FIG. 8 is a flow chart illustrating an exemplary process implemented by an SCP or SEPP in applying or overriding a preferred-locality attribute in an NF discovery request.

DETAILED DESCRIPTION

[0043] FIG. 1 is a block diagram illustrating an exemplary 5G system network architecture. The architecture in FIG. 1 includes NRF 100 and SCP 101, which may be located in the same home public land mobile network (HPLMN). As described above, NRF 100 may maintain profiles of available producer NF service instances and their supported services and allow consumer NFs or SCPs to subscribe to and be notified of the registration of new/updated producer NF service instances. SCP 101 may also support service discovery and selection of producer NF instances. SCP 101 may perform load balancing of connections between consumer and producer NFs.

[0044] NRF 100 is a repository for NF or service profiles of producer NF instances. In order to communicate with a producer NF instance, a consumer NF or an SCP must obtain the NF or service profile of the producer NF instance from NRF 100. The NF or service profile is a JavaScript object notation (JSON) data structure defined in 3GPP TS 29.510. The NF or service profile definition includes at least one of a fully qualified domain name (FQDN), an Internet protocol (IP) version 4 (IPv4) address or an IP version 6 (IPv6) address.

[0045] In FIG. 1, any of the network functions can be consumer NFs, producer NFs, or both, depending on whether they are requesting, providing, or requesting and providing services. In the illustrated example, the NFs include a policy control function (PCF) 102 that performs policy related operations in a network, a user defined management (UDM) 104 that manages user data, and an application function (AF) 106 that provides application services.

[0046] The NFs illustrated in FIG. 1 further include a session management function (SMF) 108 that manages sessions between access and mobility management function (AMF) 110 and PCF 102. 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 (UEs), such as user equipment (UE) 114, seeking access to the network.

[0047] A 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. A network exposure function (NEF) 118 provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (loT) devices and other UEs attached to the network. NEF 118 performs similar functions to the service capability exposure function (SCEF) in 4G networks.

[0048] A radio access network (RAN) 120 connects user equipment (UE) 114 to the network via a wireless link. Radio access network 120 may be accessed using a g-Node B (gNB) (not shown in FIG. 1) or other wireless access point. A user plane function (UPF) 122 can support various proxy functionality for user plane services. One example of such proxy functionality is multipath transmission control protocol (MPTCP) proxy functionality. UPF 122 may also support performance measurement functionality, which may be used by UE 114 to obtain network performance measurements. Also illustrated in FIG. 1 is a data network (DN) 124 through which UEs access data network services, such as Internet services.

[0049] SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN. SEPP 126 may communicate with a SEPP in a foreign PLMN which manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

[0050] As stated above, one problem in 5G networks is that during NF discovery, a consumer NF either doesn't specify a preferred-locality attribute or specifies a preferred-locality attribute that has no meaning in the network of the receiving NRF. As a result, sub-optimal producer NF selection can occur. During registration with the NRF, each producer NF can specify its locality as a registration attribute or parameter, which is stored by the NRF in a data structure referred to as an NF profile or NF profile object. The registration process is conducted according to 3GPP TS 29.510 where each NF sends an NF register message to NRF 100. The NF register message includes the NF profile of each NF. Table 6.1.6.2.2-1 of 3GPP TS 29.510 defines the attributes that may be included in an NF profile. Of interest to the subject matter described herein is the locality attribute of the NF profile. Table 1 shown below is an excerpt from Table 6.1.6.2.2-1 of 3GPP TS 29.510 illustrating the locality attribute.

TABLE-US-00001 TABLE 1 Locality Attribute of NF Profile Attribute Data name type P Cardinality Description Locality string O 0 . . . 1 Operator defined information about the location of the NF instance (e.g. geographic location, data center) (NOTE 3) (NOTE 3): A requester NF may use this information to select a NF instance (e.g. a NF instance preferably located in the same data center).
As illustrated by Table 1, the locality attribute stores operator-defined information about the location of an NF instance, such as geographic location and data center. According to Note 3 of Table 1, the locality 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 locality attribute to specify in a discovery request message, which can result in sub-optimal NF selection.

[0051] The preferred-locality is an optional attribute that may be included in an NF discovery request message. Table 2 shown below is an excerpt from Table 6.2.3.2.3.1-1 of 3GPP TS 29.510 and indicates how the NRF processes the preferred-locality attribute in an NF discovery request.

TABLE-US-00002 TABLE 2 NRF Processing of Preferred-Locality Attribute Attribute Data Appli- Name Type P Cardinality Description cability Preferred- String O 0 . . . 1 Preferred target NF locality location (e.g. geographic location, data center). When present, the NRF shall prefer NF profiles with a locality attribute that matches the preferred-locality. The NRF may return additional NFs in the response not matching the preferred target NF location, e.g. if no NF profile is found matching the preferred target NF location. The NRF should set a lower priority for any additional NFs on the response not matching the preferred target NF location than those matching the preferred target NF location. (NOTE 6)
From Table 2, when the preferred-locality attribute is present, the NRF should prefer NF profiles with a locality attribute that matches the preferred-locality attribute in an NF discovery request. The NRF may also return additional NF profiles in the discovery response not matching the preferred-locality, for example, if no NF profile is found matching the preferred-locality. The NRF may also set a lower priority for additional NF profiles in the discovery response that do not match the preferred-locality.

[0052] Thus, preferred-locality is an optional attribute sent by consumer NFs during discovery that, when present, would be configured by the network operator to indicate a preferred location of a producer NF that would serve the consumer NF. Typically, the preferred-locality of a consumer NF would be the locality of the consumer NF or the locality of a preferred producer NF. The NRF should set a less-preferred (higher in number according to the 3GPP-defined priority numbering scheme where lower priority numbers indicate more preferred priorities) priority for any additional NFs in a discovery response with a registered locality parameter that does not match the preferred-locality identified in an NF discovery request. NF profiles that match the discovery request's search criteria will be ordered or prioritized as follows:

Preferred-Locality

[0053] Registered Priority Challenges associated with current NF discovery methods include the fact that inter-PLMN discovery requests from outside of the PLMN of the NRF processing the discovery requests either don't include a preferred-locality attribute or include a preferred-locality attribute that has no meaning in the PLMN of the NRF. Network operators may be unwilling to share locality attributes across PLMN boundaries. As a result, an NF discovery request may not include a preferred-locality attribute that matches a locality in the PLMN of the NRF.

[0054] In most cases, these inter-PLMN discovery requests land on NRFs in other PLMNs in a region near the consumer NF. In FIG. 2A, Region #1 in PLMN-A is shown to be near Region #1 in PLMN-B and far from Region #2 in PLMN-B. Also, in FIG. 2A, regional NRF 100A and Regional NRF 1008 in PLMN B are geo-redundant NRFs sharing NF profiles of NF registered with the NRFs. Therefore, in most cases, inter-PLMN discovery requests from consumer NF 200 will land on regional NRF 100A in Region #1 of PLMN-B.

[0055] In the absence of a preferred-locality attribute in the NF discovery request, the list of NF profiles of producer NFs returned in the discovery response may prefer producer NFs located farther from the consumer NF than other producer NFs that are less preferred (higher priority) in the list. In FIG. 2A, in the absence of a preferred-locality attribute, the NF profiles of producer NFs returned by 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. SEPPs 126A, 126B, and 126C as well as SCPs 101A and 101B are not involved in setting the preferred-locality attribute in the NF discovery request.

[0056] With this priority order, consumer NF 200 will most likely select producer NF #2 204 (Priority-1) to process a service request, which will result in an unnecessarily costly communication path for consumer NF 200, because producer NF #2 204 is farther from consumer NF 200 than producer NF #1 202.

[0057] FIG. 2B is a message flow diagram illustrating exemplary messages exchanged between the network entities illustrated in FIG. 2A. Referring to FIG. 2B, in line 1, consumer NF 200 initiates an inter-PLMN discovery request to visited SEPP 126A. The NF discovery request may lack a preferred-locality attribute or may include a preferred-locality attribute that has no meaning in the network to which the NF discovery request is destined. In line 2, visited SEPP 126A determines the home SEPP (H-SEPP) for the home public land mobile network (PLMN) and forwards the NF discovery request to H-SEPP 126B. In line 3, H-SEPP 126B either forwards the NF discovery request to SCP 101B in the home network for routing to the regional NRF for the home network or forwards the NF discovery request directly to the regional NRF 100A. Regional NRF 100A processes the NF discovery request and formulates and sends a discovery response to consumer NF 200. The priorities of the producer NF profiles returned in the NF discovery response may be sub-optimal due to the lack of a preferred-locality attribute that has meaning in the network of regional NRF 100A.

[0058] The above-described challenge also applies to intra-PLMN discovery use-cases, as illustrated in FIGS. 3A and 3B, where the intra-PLMN discovery requests that are used in indirect communications via the SCP either don't have preferred-locality attributes or have preferred-locality attributes with no meaning in the region of the NRF. In most cases, the discovery requests will land on the nearest regional NRF. In FIG. 3A, regional NRF 100A and regional NRF 1008 in PLMN B are geo-redundant NRFs sharing NF profiles of NF registered with the NRFs. In FIGS. 3A and 3B, intra-PLMN discovery requests from consumer NF 200 sent via SCP 101A will likely land on regional NRF 100A. Regional NRF 100A will select NF profiles of NFs that match the query parameters in the discovery request and produce a prioritized list of NF profiles that it sends to consumer NF 200 in a discovery response. Because producer NF #2 204 has a lower priority than producer NF #1 202, NRF 100A will prioritize producer NF #2 204 over producer NF #1 202. As with the inter-PLMN discovery case, this will result in sub-optimal producer NF selection as consumer NF 200 will select producer NF #2 204 to process service requests, even though producer NF #1 202 is closer.

[0059] FIG. 4 is a message flow diagram illustrating exemplary messages exchanged between an NF service consumer and an NRF in performing NF discovery. In line 1 of the message flow diagram illustrated in FIG. 4, NF service consumer 200 initiates the NF discovery process by sending and HTTP GET message to NRF 100. The HTTP GET message sent to the NRF to obtain service profiles of NF instances is also referred to as an NFDiscover request or NF discovery request. The HTTP GET message includes query parameters (such as NFtype) that the NRF uses to locate NF profiles of producer NFs that can provide the service identified by the query parameters or attributes. One such parameter or attribute is the preferred-locality attribute. If NF service consumer 200 is capable of formulating and NF discover message with a preferred-locality attribute that corresponds to a region within the PLMN of NRF 100, then the preferred-locality attribute can be effectively used to select a producer NF that is closer to consumer NF 200 than other producer NFs. However, if NF service consumer 200 is incapable of including a preferred-locality attribute or does not include a preferred-locality attribute that has meaning in the PLMN of NRF 100, NRF 100 may prioritize the list of NF profiles returned to consumer NF 200 in the discovery response based on registered producer NF priorities, which can result in sub-optimal NF selection, as illustrated in FIGS. 2A-3B.

[0060] In lines 2a and 2b of the message flow in FIG. 4, if the NF discovery request is successfully processed, NRF 100 responds with a 200 OK message that includes NF profile objects corresponding to the NF profiles of producer NFs that are able to provide the service identified in the discovery request. If the NF discovery process is not successful, NRF 100 may return a 4xx or 5xx message with problem details.

[0061] If the NF discovery request is redirected to another NRF, NRF 100 will return a 3xx message. It should be noted 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 service discovery where an intermediate forwarding NRF receives the NF discovery request from the consumer NF and forwards the NF discovery request to the NRF in another network or region as detailed in Section 5.2.2.2.5 of 3GPP TS 29.510. The NRF that receives the forwarded NF discovery request performs the look up in the NF profiles database to extract NF profiles that match the query parameters in the NF discovery request.

[0062] In order to avoid sub-optimal NF selection, the subject matter described herein includes an SCP or SEPP that can apply or override a preferred-locality attribute in an NF discovery request. In the case where the SCP or SEPP receives an inter-PLMN discovery request without a preferred-locality attribute or with a preferred-locality attribute that the SCP or SEPP chooses to override, the SCP or SEPP can insert or replace the preferred-locality attribute in the NF discovery request with: [0063] the locality of the SCP or SEPP; [0064] the locality nearest to the SCP or SEPP; or [0065] using the nearest locality to the SCP or SEPP having at least one registered (successfully heart-beating) producer NF instance that matches the query parameters in the NF discovery request.

[0066] In the case where the SCP or SEPP receives an intra-PLMN discovery request with or without a preferred-locality attribute, it can again choose to override the preferred-locality attribute in the NF discovery request or apply an SCP or SEPP-selected attribute and forward the NF discovery request message to the NRF.

[0067] The overriding (replacement) or applying (inserting where no preferred-locality attribute exists) of the preferred-locality attribute by the SCP or SEPP applies to indirect communications without delegated discovery where the consumer NF formulates the discovery request, and the SCP or SEPP replaces or adds a preferred-locality attribute to the NF discovery request. The overriding or applying of the preferred-locality attribute by the SCP or SEPP also applies to indirect communications with delegated discovery where the SCP originates the NF discovery request on behalf of a consumer NF and a downstream SCP or SEPP applies or overrides the preferred locality attribute in the NF discovery request.

[0068] FIG. 5A is a message flow diagram illustrating an SCP that applies or overrides a preferred-locality attribute in an inter-PLMN discovery request. Referring to FIG. 5A, when consumer NF 200 located in PLMN-A sends a discovery request to NRF 100A located in PLMN-B, the discovery request may either lack a preferred-locality attribute or may include a preferred-locality attribute that corresponds to the consumer NF's locality in PLMN-A, which has no meaning in PLMN B. The NF discovery request is sent to V-SEPP 126A, which forwards the NF discovery request to H-SEPP 126B. In this example, it is assumed that H-SEPP 126B off-loads regional routing to SCP 101B. Accordingly H-SEPP 126B forwards the NF discovery request to SCP 101B. In response to receiving such a discovery request, SCP 101B may either override the preferred-locality attribute or apply an NRF-selected locality attribute, depending on whether the discovery request has a preferred-locality attribute. For example, if the NF discovery request has a preferred-locality attribute, SCP 101B may override the preferred-locality attribute in the NF discovery request by replacing the value of the preferred-locality attribute with a value selected by SCP 101B. If the NF discovery request lacks a preferred-locality attribute, SCP 101B may insert a preferred-locality attribute selected by SCP 101B and forward the NF discovery request to regional NRF 100A.

[0069] In one example, SCP 101B may use its own locality when overriding or applying the locality to the NF discovery request. In another example, SCP 101B may utilize the closest locality to SCP 101B and/or the closest locality to SCP 101B with a heart-beating producer NF capable of providing the service identified from the query parameters in the NF discovery request. A consumer NF is likely to send an NF discovery request to an SCP 101B that is in a region or PLMN that is close to the requesting consumer NF. As a result, using the SCP's own locality, the closest locality known to the SCP, a locality configured by the network operator, and/or the closest locality to the SCP with a heart-beating producer NF that matches the query parameters to process the discovery request has a good chance of producing a list of NF profiles of producer NFs that are closer to the requesting consumer NF with lower (more preferred) priorities than NF profiles of producer NFs that are farther away from the requesting consumer NF.

[0070] NRF 100A returns a prioritized list of NF profiles with the NF profile of producer NF #1 202 having a lower priority (more preferred) than producer NF #2 204. As a result, when consumer NF 200 selects a producer NF to process a service request, consumer NF 200 will select producer NF #1 202 to process the service request over producer NF #2 204, which will result in more efficient and lower latency service communications in the core network over the scenario illustrated in FIGS. 2A and 2B. As stated above with regard to FIG. 4, it is not necessary that the discovery request originate from consumer NF 200. The discovery request may originate from an NRF on behalf of consumer NF 200 in the redirecting or inter-PLMN cases as described in 3GPP TS 29.510. The NF discovery request may also originate from an SCP. The locality-based override or application processes described herein can be used by the SCP or SEPP in processing NF discovery requests originating from consumer NFs, SCPs, or other NRFs.

[0071] It should be noted that in FIG. 5A, NRF 100A assigns priorities to the NF profiles in the NF discovery response based on the preferred-locality attribute inserted by SCP 101B into the NF discovery request. Assigning priorities to NF profiles using the preferred-locality attribute in an NF discovery request is a 3GPP-compliant behavior (see Section 6.2.3.2.3.1-1 of 3GPP TS 29.510). Because the SCP or SEPP creates or modifies the NF discovery request to include a preferred-locality attribute that has meaning in the region of the processing NRF, the NRF is not required to implement preferred-locality override functionality, thus simplifying discovery request processing performed by the NRF.

[0072] FIG. 5B is a message flow diagram for an inter-PLMN discovery request similar to FIG. 5A except that the home SEPP instead of the SCP overrides or applies the preferred-locality attribute to the NF discovery request. Referring to the message flow in FIG. 5B, H-SEPP 126B receives an NF discovery request from V-SEPP 126A. H-SEPP 126B either overrides (i.e., replaces) the preferred-locality attribute in the NF discovery request or applies (i.e., adds) a preferred-locality attribute to the NF discovery request before forwarding the NF discovery request to NRF 100A. NRF 100A processes the NF discovery request using the preferred-locality attribute inserted into the NF discovery request by H-SEPP 101A and returns a list of NF profiles that are prioritized according to the SEPP-inserted preferred-locality attribute.

[0073] Overriding or applying a preferred-locality to an NF discovery request also applies to an intra-PLMN discovery request, i.e., a discovery request send from an NF to an NRF that are both in the same PLMN. FIG. 6 illustrates this case. Referring to FIG. 6, when consumer NF 200 located in Region #1 of PLMN-B sends a discovery request to NRF 100A, which is also located in Region #1 of PLMN B, the discovery request may either lack a preferred-locality attribute or may include a preferred-locality attribute that corresponds to the consumer NF's locality (Region #1) in PLMN-B. For the case of indirect communications, the NF discovery request may be sent to SCP 101B located in region #2 of PLMN-B. In response to receiving such a discovery request, SCP 101B may either override the preferred-locality attribute or apply an SCP-selected preferred-locality attribute, depending on whether the discovery request has a preferred-locality attribute. For example, if the NF discovery request has a preferred-locality attribute, SCP 101B may override the preferred-locality attribute in the NF discovery request by replacing the value of the preferred-locality attribute in the NF discovery request with an SCP-selected value. If the NF discovery request lacks a preferred-locality attribute, SCP 101B may apply or insert an SCP-selected locality into the NF discovery request before forwarding the NF discovery request to NRF 100A.

[0074] In one example, SCP 101A may use its own locality when overriding or applying the locality to the NF discovery request. In another example, SCP 101B may utilize the closest locality to SCP 101B and/or the closest locality to SCP 101B with a heart-beating producer NF capable of providing the service identified from the query parameters in the discovery request. A consumer NF is likely to send an NF discovery request to an SCP that is in a region or PLMN that is close to the requesting consumer NF. As a result, using the SCP's own locality, the closest locality known to the SCP, and/or the closest locality to the SCP with a heart-beating producer NF that matches the query parameters to process the discovery request has a good chance of producing a list of NF profiles of producer NFs that are closer to the requesting consumer NF with lower (more preferred) priority than NF profiles of producer NFs that are farther away from the requesting consumer NF.

[0075] In response to the NF discovery request, NRF 100A returns a prioritized list of NF profiles with the NF profile of producer NF #1 202 having a lower priority (more preferred) than producer NF #2 204. As a result, when consumer NF 200 selects a producer NF to process a service request, consumer NF 200 will select producer NF #1 202 to process the service request over producer NF #2 204, which will result in more efficient and lower latency service communications in the core network over the scenario illustrated in FIGS. 3A and 3B.

[0076] It should be noted that in FIG. 6, like the inter-PLMN case illustrated in FIGS. 5A and 5B, NRF 100A assigns new priorities based on the preferred-locality attribute in the NF discovery request received by NRF 100A. This is standard NRF behavior, which means that NRF 100A is not required to be modified to support the preferred-locality override or application processing described herein. Implementing preferred-locality override or application processing at the SCP or SEPP thus simplifies the processing performed by the NRF to produce a set of NF profiles that is optimized for the consumer NF.

[0077] FIG. 7 is a block diagram illustrating an exemplary architecture for an SCP or SEPP 101B or 126B that is capable of applying or overriding a preferred-locality during NF discovery. Referring to FIG. 7, SCP or SEPP 101B or 126B includes at least one processor 700 and a memory 702. SCP or SEPP 101B or 126B further includes a preferred-locality apply/override module 704 that performs the steps described herein for applying or overriding a preferred-locality attribute in an NF discovery request. Preferred-locality apply/override module 704 may be implemented using computer executable instructions stored in memory 702 and executed by processor 700.

[0078] FIG. 8 is a flow chart illustrating an exemplary process for applying or overriding a preferred-locality attribute during NF discovery. Referring to FIG. 8, in step 800, the process includes receiving at an SCP or SEPP and from an NF, an NF discovery request including a preferred-locality attribute or lacking a preferred-locality attribute. For example, SCP or SEPP 101B or 126B may receive an NF discovery request from a consumer NF, an SCP, or an SEPP. The NF discovery request may be an inter-PLMN NF discovery request or an intra-PLMN NF discovery request with or without a preferred-locality attribute.

[0079] In step 802, the process includes selecting, by the SCP or SEPP, a value for the preferred-locality attribute for the NF discovery request. For example SCP or SEPP 101B or 126B may select a value for the preferred-locality attribute to insert in the NF discovery request where the value corresponds to a locality of the SCP or SEPP, a value selected by the network operator, a nearest locality to a locality of the SCP or SEPP, or a nearest locality to the locality of the SCP or SEPP with at least one heart-beating NF capable of providing the service identified by query parameters in the NF discovery request. In the case where the SCP or SEPP selects the value of the preferred-locality attribute value to correspond to a nearest locality to the locality of the SCP or SEPP with at least one heart-beating NF capable of providing the service identified by the query parameters in the NF discovery request, the SCP or SEPP may include or have access to an NF profiles database of NF profiles registered with an NRF so that the SCP or SEPP can determine whether the locality includes producer NF capable of providing the identified service.

[0080] In step 804, the process includes inserting, by the SCP or SEPP, the value for the preferred-locality attribute into the NF discovery request. For example, SCP 101B or SEPP 126B may insert the SCP- or SEPP-selected value for the preferred-locality attribute in the NF discovery request where the selected value replaces the value inserted in the NF discovery request by the originating NF or is added to the NF discovery request in the case where the NF discovery request does not include a preferred-locality attribute.

[0081] In step 806, the process includes transmitting, by the SCP or SEPP, the NF discovery request to a network function repository function (NRF). For example, SCP 101B or SEPP 126B may transmit the NF discovery request to the NRF local to SCP 101B or SEPP 126B. The NRF may utilized the SCP- or SEPP-selected preferred-locality attribute value to set priorities of NF profiles to be returned to the NF in the NF discovery response.

[0082] 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 the requesting consumer NF are prioritized according to an SCP- or SEPP-selected locality, the consumer NF is more likely to select a producer NF to provide service that is closer to the consumer NF, resulting in more efficient service messaging in the network. In addition, because the SCP or SEPP applies or overrides the value of the preferred-locality attribute in the NF discovery request prior to forwarding the NF discovery request to the NRF, the NRF is not required to implement preferred-locality attribute applying or overriding functionality and can instead implement standard NRF behavior in processing NF discovery request, for example, as specified in 3GPP TS 28.510.

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

REFERENCES

[0084] 1. 3.sup.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). [0085] 2. 3rd 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).

[0086] It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.