US11496954B2

US11496954B2 - Methods, systems, and computer readable media for supporting multiple preferred localities for network function (NF) discovery and selection procedures

Info

Publication number: US11496954B2
Application number: US17/200,777
Authority: US
Inventors: Nitin Gupta; Anup Shivarajapura; Raghuvamshi vasudev Singh Thakur; Venkatesh Aravamudhan
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2021-03-13
Filing date: 2021-03-13
Publication date: 2022-11-08
Anticipated expiration: 2041-03-13
Also published as: WO2022197531A1; CN117242764A; EP4305833A1; BR112023018469A2; US20220295384A1

Abstract

A method for supporting multiple locations in a preferred-locality attribute NF discovery and selection includes receiving, from producer NFs, NF registration messages including NF profiles with locality attributes and registering the producer NFs by storing the NF profiles including the locality attributes in an NF registration database local to an NRF. The method further includes receiving, from a requesting NF, an NF discovery request having query parameters for discovering producer NFs, the query parameters including a preferred-locality attribute identifying a plurality of different preferred producer NF locations. The method further includes retrieving NF profiles from the NF registration database having locality attributes that match any of the preferred producer NF locations. The method further includes generating an NF discovery response including the NF profiles retrieved from the NF registration database. The method further includes forwarding the NF discovery response to the requesting NF.

Description

TECHNICAL FIELD

The subject matter described herein relates to NF discovery and selection. More particularly, the subject matter described herein relates to methods, systems, and computer readable media supporting multiple preferred localities in NF discovery and selection procedures.

BACKGROUND

In 5G telecommunications networks, a network function that provides service is referred to as a producer network function (NF) or NF service producer. A network function that consumes services is referred to as a consumer NF or NF service consumer. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function is consuming, producing, or consuming and producing services. 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.

A given producer NF may have many service endpoints, where a service endpoint is the point of contact for one or more NF instances hosted by the producer NF. The service endpoint is identified by a combination of Internet protocol (IP) address and port number or a fully qualified domain name that resolves to an IP address and port number on a network node that hosts a producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF may include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

Producer NFs register with a network function repository function (NRF). The NRF maintains service profiles of available NF instances identifying the services supported by each NF instance. The terms “service profiles” and “NF profiles” are used interchangeably herein. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is a service communications proxy (SCP). The SCP subscribes with the NRF and obtains reachability and service profile information regarding producer NF service instances. Consumer NFs connect to the service communications proxy, and the service communications proxy load balances traffic among producer NF service instances that provide the required services or directly routes the traffic to the destination producer NF instances.

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). The SEPP is the network node used to protect control plane traffic that is 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 that are transmitted between PLMNs.

One problem in 5G communications networks is the inflexibility of the 3GPP-defined NF discovery procedure in discovering other NFs in the same locality or in a locality that is near to a consumer NF. 3GPP TS 29.510 allows each NF to register its own locality with the NRF. 3GPP TS 29.510 also allows consumer NFs to specify a single preferred producer NF location or locality in a preferred-locality attribute as part of an NF discovery request. However, if there are no producer NFs in the locality that matches the locality specified in the preferred-locality attribute in the discovery request, the NRF may return a set of NF profiles in response to a discovery request, some of which may be more preferred than others. The consumer NF may be required to parse through the NF profiles and extract or read the locality attribute of each profile to identify those with more preferred localities than others. Such processing cannot be reduced or avoided given the inflexibility of existing NF discovery procedures.

Accordingly, there exists a need for improved methods, systems, and computer readable media for NF discovery and selection that considers multiple different locality preferences of a consumer NF.

SUMMARY

A method for supporting multiple preferred producer NF locations in a preferred-locality attribute for network function (NF) discovery and selection includes, at an NF repository function (NRF) including at least one processor and a memory, receiving, from producer NFs, NF registration messages including NF profiles with locality attributes and registering the producer NFs by storing the NF profiles including the locality attributes in an NF registration database local to the NRF. The method further includes receiving, from a requesting NF, an NF discovery request having query parameters for discovering producer NFs, the query parameters including a preferred-locality attribute identifying a plurality of different preferred producer NF locations. The method further includes retrieving NF profiles from the NF registration database having locality attributes that match any of the preferred producer NF locations. The method further includes generating an NF discovery response including the NF profiles retrieved from the NF registration database. The method further includes forwarding the NF discovery response to the requesting NF.

According to another aspect of the subject matter described herein, receiving the NF discovery request from a requesting NF includes receiving the NF discovery request from a consumer NF.

According to another aspect of the subject matter described herein, receiving the NF discovery request from a requesting NF includes receiving the NF discovery request from a service communications proxy (SCP) performing delegated discovery on behalf of a consumer NF.

According to another aspect of the subject matter described herein, receiving the NF discovery request includes receiving an NF discovery request that indicates relative preferences of the requesting NF of the preferred NF locations.

According to another aspect of the subject matter described herein, generating the NF discovery response includes indicating, in the NF discovery response, relative preferences of the NF profiles based on the relative preferences indicated in the discovery request.

According to another aspect of the subject matter described herein, indicating the relative preferences of the NF profiles includes one of: setting priority attributes of the NF profiles based on the relative preferences indicated in the discovery request; and ordering the NF profiles in the discovery response based on the relative preferences indicated in the discovery request.

According to another aspect of the subject matter described herein, the method for supporting multiple preferred producer NF locations in the preferred-locality attribute includes retrieving NF profiles from the NF registration database having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations.

According to another aspect of the subject matter described herein, generating the discovery response includes including, in the discovery response, the NF profiles in having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations and indication that the NF profiles having locality attributes that match one of the preferred producer NF locations are more preferred than the NF profiles having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations.

According to another aspect of the subject matter described herein, generating the discovery response includes excluding, from the discovery response NF profiles that do not match any of the preferred producer NF locations.

According to another aspect of the subject matter described herein, the method for supporting plural preferred producer NF locations in the preferred-locality attribute includes, at the requesting NF, receiving the discovery response, selecting one of the NF profiles having a locality attribute that matches one of the preferred NF locations, and sending a service based interface (SBI) service request to a producer NF corresponding to the selected NF profile.

According to another aspect of the subject matter described herein, a system for supporting multiple locations in a preferred-locality attribute for network function (NF) discovery and selection, is provided. The system includes an NF repository function (NRF) including at least one processor and a memory. The system further includes an NF discovery/registration manager implemented by the at least one processor for receiving, from producer NFs, NF registration messages including NF profiles with locality attributes and registering the producer NFs by storing the NF profiles including the locality attributes in an NF registration database local to the NRF, receiving, from a requesting NF, an NF discovery request having query parameters for discovering producer NFs, the query parameters including a preferred-locality attribute identifying a plurality of different preferred producer NF locations, retrieving NF profiles from the NF registration database having locality attributes that match any of the preferred producer NF locations, generating an NF discovery response including the NF profiles retrieved from the NF registration database, and forwarding the NF discovery response to the requesting NF.

According to another aspect of the subject matter described herein, the requesting NF comprises a consumer NF.

According to another aspect of the subject matter described herein, the requesting NF comprises a service communications proxy (SCP) performing delegated discovery on behalf of a consumer NF.

According to another aspect of the subject matter described herein, the NF discovery request indicates relative preferences of the requesting NF of the preferred NF locations.

According to another aspect of the subject matter described herein, in generating the NF discovery response, the NF discovery/registration manager is configured to indicate, in the NF discovery response, relative preferences of the NF profiles based on the relative preferences indicated in the discovery request.

According to another aspect of the subject matter described herein, the NF discovery/registration manager is configured to indicate the relative preferences of the NF profiles in the discovery response by one of: setting priority attributes of the NF profiles based on the relative preferences indicated in the discovery request; and ordering the NF profiles based on the relative preferences indicated in the discovery request.

According to another aspect of the subject matter described herein, the NF discovery/registration manager is configured to retrieve NF profiles from the NF registration database having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations.

According to another aspect of the subject matter described herein, wherein the NF discovery/registration manager is configured to include, in the discovery response, the NF having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations and an indication that the NF profiles having locality attributes that match one of the preferred producer NF locations are more preferred than the NF profiles having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations.

According to another aspect of the subject matter described herein, the indication in the discovery response includes one of: priority attributes in the NF profiles; and an order of the NF profiles in the discovery response.

According to another aspect of the subject matter described herein, 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. The steps include receiving, from producer network functions (NFs), NF registration messages including NF profiles with locality attributes and registering the producer NFs by storing the NF profiles including the locality attributes in an NF registration database local to an NF repository function (NRF). The steps further include receiving, from a requesting NF, an NF discovery request having query parameters for discovering producer NFs, the query parameters including a preferred-locality attribute identifying a plurality of different preferred producer NF locations. The steps further include retrieving NF profiles from the NF registration database having locality attributes that match any of the preferred producer NF locations. The steps further include generating an NF discovery response including the NF profiles retrieved from the NF registration database. The steps further include forwarding the NF discovery response to the requesting NF.

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 implementation, the subject matter described herein can be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the 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, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 2 is a network diagram illustrating NFs located in different localities and an NRF;

FIG. 3 is a network diagram illustrating the NFs of FIG. 2 registering with the NRF;

FIG. 4 is a message flow diagram illustrating exemplary messages exchanged for NF service discovery using a single preferred locality and subsequent NF selection where an NF in the preferred locality is available;

FIG. 5 is a network diagram illustrating one of the NFs in FIGS. 2 and 3 becoming unavailable;

FIG. 6 is a message flow diagram illustrating exemplary messages exchanged for NF discovery and selection using a single preferred locality where no NFs in the preferred locality are available;

FIG. 7 is a message flow diagram illustrating exemplary messages exchanged for NF discovery and selection using a preferred-locality attribute with multiple preferred producer NF locations for the case of direct communication with non-delegated discovery;

FIG. 8 is a message flow diagram illustrating exemplary messages exchanged for NF discovery and selection using a preferred-locality attribute with multiple preferred producer NF locations for the case of indirect communication with delegated discovery;

FIG. 9 is a block diagram illustrating an exemplary architecture for an NRF that supports plural preferred producer NF locations in a preferred-locality attribute for NF discovery;

FIG. 10 is a block diagram of a consumer NF or SCP the supports NF discovery and selection using plural preferred producer NF locations in a preferred-locality attribute;

FIG. 11 is a flow chart illustrating an exemplary process for implementing NF discovery at an NRF using a preferred-locality attribute with plural preferred NF locations; and

FIG. 12 is a flow chart illustrating an exemplary process performed by a consumer NF or SCP for performing NF discovery and selection using a preferred-locality attribute with plural preferred NF locations.

DETAILED DESCRIPTION

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.

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.

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 PCF 102 that performs policy related operations in a network, a UDM function 104 that manages user data, and an application function (AF) 106 that provides application services.

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.

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 (IoT) devices and other UEs attached to the network. NEF 118 performs similar functions to the service capability exposure function (SCEF) in 4G networks.

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.

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.

As described above, one problem that can occur in 5G networks is the inability to provide for fine-grained specification of preferred producer NF localities during the NF discovery process. FIG. 2 is a network diagram illustrating an NRF and a plurality of NFs located in different localities. In FIG. 2, NF1 200 and NF6 210 are located in locality1. NF2 202 and NF3 204 are located in locality2. NF4 206 and NF5 208 are located in locality3. Each of the NFs illustrated in FIG. 2 can register their NF profiles, which include their localities, with NRF 100.

FIG. 3 illustrates each of

NFs

200, 202, 204, 206, 208, and 210 registering with NRF 100. 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 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, because 3GPP TS 29.510 only allows the consumer NF to specify a single preferred locality during NF discovery, the consumer NF may receive NF profiles of producer NFs that are not in the preferred locality, resulting an additional processing burden on the consumer NF to identify and select an optimal producer NF.

FIG. 4 is a message flow diagram illustrating the use of the locality attribute along with the preferred-locality attribute during the NF discovery process. Referring to FIG. 4, in line 1 of the message flow diagram, NF1 200 sends an NF discover message to NRF 100. The NF discover message includes a target NF type and a preferred-locality attribute that indicates a single preferred producer NF location. In the illustrated example, the preferred-locality attribute identifies locality1 as the preferred locality. Upon receiving the NF discover message, NRF 100 searches its NF registration database and identifies any NFs of the target NF type having a locality attribute that matches the locality specified in the NF discover message. In this example, there is one NF, NF6 210, whose locality attribute matches the locality specified in the preferred-locality attribute of the NF discover 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 a discovery request.

TABLE 2

NRF Processing of Preferred-Locality Attribute

Attribute	Data				Applic-
Name	Type	P	Cardinality	Description	ability

Preferred-	String	O	0 . . . 1	Preferred target NF location
locality				(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, win the locality attribute is present, the NRF should prefer NF profiles with the locality that matches the preferred locality. 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. There are two possible interpretations of Note C—one is that the NRF should only return additional NF profiles if no NF profiles matching the preferred locality are present. Another interpretation is that the NRF can return additional NF profiles with lower priority even if NF profiles matching the preferred locality are present.

FIG. 4 assumes that the second interpretation of Note C is implemented where the NRF returns the NF profile of an NF matching the preferred locality along with the NF profiles of NFs not matching the preferred locality. In line 2 of FIG. 4, NRF 100 returns, in response to the discovery request, a 200 OK message with the NF profile of NF6 210, which matches the preferred locality parameter. The discovery response also includes the NF profiles of NF2-NF5 with a priority that is higher (less preferred) than the NF profile of NF6 210.

In line 3 of the message flow diagram in FIG. 4, NF 200 selects NF6 210 to provide the requested service and sends an SBI service request to NF6 210. In line 4 of the message flow diagram, NF6 210 responds to the SBI service request with an SBI service response message. Thus, FIG. 4 illustrates the case where a single preferred locality is used to discover and select a producer NF to provide service to a consumer NF.

The use of a preferred-locality attribute with a single preferred NF location in NF discovery works when the NF matching the consumer NF's preferred locality is available. However, if there are no NFs matching the consumer NF's preferred locality, the consumer NF may receive multiple NF profiles that do not match the preferred locality and may be required to parse each of the profiles, identify their localities, and then select one of the profiles based on the consumer NF's preferred locality.

FIG. 5 illustrates the network of FIGS. 2 and 3 when NF6 210, which is the only producer NF in the preferred locality of NF1 200, becomes unavailable. FIG. 6 illustrates the corresponding message flow for NF discovery and selection when consumer NF1 200 specifies a single preferred locality and there are no NFs with a locality that matches the consumer NF's preferred locality. Referring to FIG. 6, in line 1, consumer NF1 200 sends an NF discover message to NRF 100. The NF discover message specifies a target NF type and a preferred locality of locality1. In response to the NF discover message, NRF 100 does not locate any NF profiles matching the preferred locality. However, NRF 100 may locate other NF profiles that are capable of providing the service but may be unable to set relative locality priorities of the remaining NF profiles that do not match the preferred locality because NRF 100 does not know the consumer NF's relative preferences of the other localities. Accordingly, in line 2, NRF 100 returns a 200 OK message with the NF profiles of NF2-NF5, all with the same priority, because none match the preferred locality of consumer NF1 200.

Consumer NF1

200 receives the discovery response and may be required to parse through large numbers of non-preferred producer NF profiles to select an optimal producer NF to provide a service. In line 3, consumer NF1 200 selects one of NF2-NF5 to provide the service and sends an SBI service request to the selected producer NF. In line 4, the selected producer NF returns an SBI service response message to consumer NF1 200. Thus, FIG. 6 illustrates the case where the specification of a single preferred locality results in extra processing of sub-optimal NF profiles on the part of the consumer NF to select a producer NF to provide a service.

To avoid this difficulty, the subject matter described herein includes enhancing the functionality of a consumer NF to specify multiple preferred localities in the NF discover message and enhancing the functionality of the NRF to select producer NF profiles that match any of the preferred localities and set priorities of producer NF profiles based on the preferred producer NF localities specified in the NF discovery request message. FIG. 7 is a message flow diagram illustrating the use of multiple preferred localities during the NF discovery and selection processes. Referring to FIG. 7, in line 1, consumer NF1 200 sends an NF discover message with the target NF type and a preferred-locality attribute that specifies two different preferred producer NF locations, locality1 and locality2. NRF 100 receives the NF discover message, and, in response, iterates through its NF registration database to identify NF profiles having an NF type attribute that matches the target NF type. From the NF profiles with matching NF type attributes, NRF 100 identifies NF profiles of producer NFs that have locality attributes that match any of the preferred producer NF locations indicated in the preferred-locality attribute. Table 3 shown below illustrates modifications of the process specified in 3GPP TS 29.510 to handle multiple preferred localities.

TABLE 3

Modified NRF Processing to Handle Multiple Preferred Localities

Attribute	Data
Name	Type	P	Cardinality	Description	Applicability

Preferred-	string	O	0 . . . N	Preferred target NF location (e.g.
locality				geographic location, data center).
				When present, the NRF shall
				prefer NF profiles with a locality
				attribute that matches with one of
				the locations identified in the
				preferred-locality attribute.
				E.g. location1 and locartion2,
				The NRF shall iterate through NF
				profiles that match the target NF
				type and set priorities of matching
				NF profiles based on whether or
				not the localities match any of the
				locations identified in the
				preferred-locality attribute.
				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 one of the preferred
				target NF locations.
				The NRF should set a lower
				priority for any additional NFs on
				the response not matching any of
				the preferred target NF locations
				than those matching the preferred
				target NF locations.
				(NOTE 6)

In Table 3, the underlined portion indicates added text to the NRF processing defined in Table 2. From the added text in Table 3, rather than processing a preferred-locality attribute with a single preferred NF location, the NRF iterates through NF profiles that match the target NF type, identifies NF profiles that match with any of the locations specified in the preferred-locality attribute, and sets priority attributes of each NF profile based on whether the localities in the NF profiles match any of the locations identified in the preferred-locality attribute. In one example, NF profiles with a locality attribute matching any of the locations identified in the preferred-locality attribute may be assigned the same priority. In another example, the order of the locations in the preferred-locality attribute in the discovery request may indicate a preference order of the locations, and the NRF may assign priorities to matching NF profiles based on the order in which locations are identified in the preferred-locality attribute (i.e., based on the relative preference of the locations set by the consumer NF). In 5G networks, a lower priority value indicates a higher preference (e.g., priority 0 indicates more preferred than priority 1). In the example illustrated in FIG. 7, locality1 is the most preferred locality, and locality2 is the next most preferred locality. However, in this example, there are no NFs available in locality1. Accordingly, in line 2, NRF 100 sets, in the discovery response the priorities of NF2 and NF3 to be higher (lower in priority value but more preferred) than those of NF4 and NF5, which do not have a locality that matches any of the preferred localities of consumer NF 200. In line 3 of the message flow diagram, NF1 200 selects NF2 202 based on the priorities in the discovery response and sends an SBI service request to NF2 202. In line 4, NF2 202 responds to the SBI service request with an SBI service response. Thus, FIG. 7 illustrates the use of localities in an NF discovery request to optimize NF discovery and subsequent NF selection.

Another change to the processing of the preferred-locality attribute indicated by Table 3 is the change in cardinality from 1 to N. That is, the current 3GPP specified cardinality of the preferred-locality attribute is 1, meaning that the attribute contains one preferred NF location. The proposed modification to the preferred-locality attribute changes the cardinality to N, where N is an integer greater than or equal to 1, meaning that the preferred-locality attribute can contain identifiers of plural preferred NF locations. In one implementation, the preferred-locality attribute contains strings that identify each preferred NF location, and the strings that identify different preferred NF locations are separated from each other by delimiters, such as commas.

In FIG. 7, if NF6 210 in locality1 had been available, then NRF 100 may return in the discovery response the NF profile of NF6 with priority 1, of

NFs

2 and 3 with priority 2, and of

NFs

4 and 5 with priority 3. The specification of relative priorities of producer NF profiles in the discovery response may reduce the processing burden on the consumer NF in selecting a producer NF to provide a service. In an alternate implementation of the subject matter described herein, if the NRF locates NF profiles matching any of the preferred localities specified in the discovery request, the NRF may return only those NF profiles, further reducing the processing burden on the consumer NF in performing NF selection.

If the NRF were configured in this manner, in the example in FIG. 7, only the NF profiles of NF2 and NF3 would be returned in the discovery response, and the NF profiles of NF4 and NF5 would be excluded from the discovery response.

In the example in FIG. 7, consumer NF1 200 performs NF discovery on its own behalf with NRF interaction but without SCP interaction. This type of discovery is referred to as direct communication with NRF interaction and corresponds to Model B in Annex E of 3GPP TS 23.501. In an alternate implementation, a consumer NF may perform indirect communications without delegated discovery, which corresponds to Model C in Annex E of 3GPP TS 23.501. According to Model C, consumer NFs perform NF discovery by querying the NRF. Based on the discovery result, the consumer NF selects an NF set (a group of NF instances identified by the same NF set ID and that provide the same service) or a specific NF instance in NF set. The consumer NF sends the SBI service request to the SCP containing the address of the selected service producer pointing to a NF service instance or a set of NF service instances. In the latter case, the SCP selects an NF service instance. If possible, the SCP interacts with the NRF to get selection parameters such as location, capacity, etc. The SCP routes the request to the selected NF service producer instance.

For the case in Model C where the consumer NF performs service discovery and selects an NF instance to which the service request is forwarded, the discovery request may include a preferred-locality attribute with multiple preferred producer NF locations, and the NRF operates as described above with respect to Table 3 to locate NF profiles with matching localities and set priorities of the NF profiles based on the matching localities. For the case in Model C where the consumer NF performs service discovery, selects an NF set, and forwards the SBI service request to the SCP, and the SCP interacts with the NRF to select a producer NF instance, the NRF may operate as described above with respect to Table 3 to return the NF profiles of NF sets that match any of the preferred producer NF locations specified in the preferred-locality attribute. The SCP may use the preferred localities of the consumer NF to select a producer NF instance from the NF set.

In yet another an alternate implementation, indirect communication with delegated discovery may be performed by an SCP on behalf of a consumer NF. Indirect communication with delegated discovery is referred to as Model D communication in Annex E of 3GPP TS 23.501. According to Model D, consumer NFs do not perform NF selection or discovery. Instead, the consumer NF adds necessary discovery and selection parameters to a service access request that is sent to the SCP. The SCP then performs discovery with an NRF, obtains a discovery response, selects a producer NF from the discovery response, and sends the SBI service request to the selected producer NF. Multiple preferred localities may be specified by the SCP in the discovery request. The use of multiple preferred localities for the case of indirect communication with delegated discovery is illustrated in FIG. 8. Referring to the message flow in FIG. 8, in line 1, consumer NF 200 sends an SBI service access request message with discovery and producer NF selection parameters to SCP 101. The discovery and producer NF selection parameters may include multiple preferred localities of consumer NF 200. In line 2, SCP 101 performs discovery with NRF 100 by sending a discovery request to NRF 100. The discovery request includes the preferred-locality attribute with multiple preferred producer NF locations received from consumer NF 200 in the service access request. In line 3 of the message flow diagram, NRF 100 processes the discovery request, searches its NF registration database using each of the preferred producer NF locations and returns a discovery response with NF profiles having priorities set according to the preferred producer NF locations. In the illustrated example, the NF profiles of NF2 202 and NF3 204 are returned with more preferred priorities than the NF profiles of NF4 206 and NF5 208. Again, in this example, it is assumed that NF6 210 is not available. In line 4 of the message flow diagram, SCP 101 sends an SBI service request to NF2 202, which was selected based on the preferred localities of consumer NF 200. In line 5, NF2 202 sends an SBI service response to SCP 101. In line 6, SCP 101 sends an SBI service access response to consumer NF 200. Thus, FIG. 8 illustrates the use of multiple preferred localities by an SCP for the case of indirect communications with delegated discovery.

FIG. 9 is a block diagram illustrating an exemplary architecture for NRF 100 to support multiple preferred localities in NF discovery. Referring to FIG. 9, NRF 100 includes at least one processor 900 and a memory 902. NRF 100 may also include an NF registration database 904 that stores the NF profiles of NFs that are registered with NRF 100. NRF 100 may further include an NF discovery/registration manager 906 registers NFs by receiving NF registration requests from the NFs and storing their NF profiles in NF registration database 904. NF discovery/registration manager 906 also receives discovery requests from consumer NFs and SCPs, where the discovery requests include multiple preferred localities, iterates through NF registration database 904 to select NF profiles matching any of the preferred localities, generates discovery responses with NF profiles having priorities set according to the preferred localities, and returns the discovery responses to the requesting consumer NFs or SCPs. In one example, NF discovery/registration manager 906 may be implemented using computer executable instructions stored in memory 902 and executed by processor 900.

FIG. 10 is a block diagram illustrating an exemplary architecture of a consumer NF or

SCP

200 or 101 capable of using multiple preferred localities in NF discovery and NF selection. In FIG. 10, consumer NF or

SCP

200 or 101 includes a processor 1000 and a memory 1002. Consumer NF or

SCP

200 or 101 includes a locality-preference attribute 1004 stored in memory 1002 that includes multiple preferred producer NF locations to be used in the NF discovery process. Consumer NF or

SCP

200 or 101 further includes an NF discovery and selection manager for formulating discovery requests using locality-preference attribute 1004, for selecting an NF to provide a service from the NF profiles returned by the NRF based on the preferred NF locations, and for sending an SBI service request to the selected producer NF. In one implementation, NF discovery and selection manager may be implemented by computer executable instructions embodied in memory 1002 and executed by processor 1000.

FIG. 11 is a flow chart illustrating an exemplary process performed by an NRF for supporting multiple locations in a preferred-locality attribute for network function (NF) discovery and selection. Referring to FIG. 11, in step 1100, the process includes, at an NF repository function (NRF) including at least one processor and a memory, receiving, from producer NFs, NF registration messages including NF profiles with locality attributes and registering the producer NFs by storing the NF profiles including the locality attributes in an NF registration database local to the NRF. For example, NRF 100 may receive registration messages from producer NFs that include NF profiles for the producer NFs. Each NF profile may include a locality attribute indicating a locality of the producer NF.

In step 1102, the process includes receiving, from a requesting NF, an NF discovery request having query parameters for discovering producer NFs, the query parameters including a preferred-locality attribute identifying a plurality of different preferred producer NF locations. For example, NRF 100 may receive a discovery request from a consumer NF or SCP with a locality attribute including multiple preferred producer NF locations. In one implementation, the discovery request may indicate the relative preferences on the part of the requesting NF of each of the preferred producer NF locations.

In step 1104, the process includes retrieving NF profiles from an NF registration database having locality attributes that match any of the preferred producer NF locations. For example, NRF 100 may search NF registration database 904 using the query parameters specified in the discovery request and initially locate NF profiles having an NF type attribute that matches the target NF type attribute specified in the discovery request. The NRF may identify, from the NF profiles having an NF type attribute that matches the target NF type specified in the discovery request, NF profiles that have a locality parameter that matches any of the preferred NF locations specified in the discovery requests. In one example, NRF 100 may extract the NF profiles having NF type attributes that match the target NF type and having locality attributes that match any of the preferred NF localities identified in the discovery request as well as NF profiles having NF type attributes that match the target NF type and having locality attributes that do not match any of the preferred NF localities identified in the discovery request. In such an implementation, NRF 100 may indicate, in the discovery response, relative preferences on the part of the consumer NF of the NF profiles having locality attributes that match one of the preferred NF locations and NF profiles having locality attributes that do not match one of the preferred NF locations. In an alternate implementation, NRF 100 may return in the discovery response only the NF profiles having an NF type attribute that matches the target NF type attribute in the discovery request and that have a locality that matches one of the preferred NF locations in the discovery request. In either implementation, NRF 100 may indicate relative preferences on the part of the consumer NF of the NF profiles having locality attributes that match one of the preferred NF locations identified in the discovery request.

In step 1106, the process includes generating an NF discovery response including the NF profiles retrieved from the NF registration database. As indicated in the preceding paragraph, the NF profiles returned in the response may include 1) those with locality attributes that match one of the preferred NF locations or 2) those with locality attributes that match one of the preferred NF locations and those with locality attributes that do not match one of the preferred NF locations. It should also be noted that if no NF profiles having a locality attribute that matches one of the preferred NF locations are located, then NRF 100 may return only the NF profiles with NF type attributes that match the target NF type and locality attributes that do not match any of the preferred NF locations. Relative priorities of the NF profiles returned in the response may optionally be indicated in any of the manners specified in the preceding paragraph. It should also be noted that NRF 100 may utilize the preferred NF locations received in the discovery request in combination with other query parameters in indicating relative priorities of NF profiles to be included in the discovery response.

In step 1108, the process includes forwarding the NF discovery response to the requesting NF. For example, if the requesting NF is a consumer NF performing non-delegated discovery, NRF 100 may return the discovery response to the requesting consumer NF. If the requesting NF is an SCP performing delegated discovery on behalf of a consumer NF, then NRF 100 may forward the NF discovery response to the SCP.

FIG. 12 is a flow chart illustrating an exemplary process performed by a consumer NF or SCP in supporting multiple locality profiles for NF discovery. Referring to FIG. 12, in step 1200, the process includes storing, in memory, a locality-preference attribute including plural preferred producer NF locations to be used in NF discovery. In the case of a consumer NF, the preferred-locality attribute may be populated with preferred locations of producer NFs that are configured by the network operator based on geographic proximity, messaging latency between the consumer NF and the producer NF locations, cost of accessing the producer NF locations, and/or other factor(s). In the case of an SCP, the preferred-locality attribute may be populated using preferred producer NF locations received from consumer NFs in SBI service access request messages. In the SCP case, the SCP may maintain different preferred-locality attributes for different consumer NFs so that the SCP can use the preferred-locality attributes on a per consumer NF basis for delegated discovery.

In step 1202, the process includes generating and sending a discovery request message to the NRF where the discovery request message includes a locality attribute identifying plural preferred NF locations. For example, consumer NF or

SCP

200 or 101 may send an NF discover message to NRF 100, where the NF discover message includes query parameters for selecting producer NF profiles, and the query parameters include a preferred-locality attribute that identifies plural preferred NF locations. The discovery request also identifies the target NF type and may optionally identify the relative preferences of consumer NF 200 of the preferred producer NF locations identified in the preferred-locality attribute.

In step 1204, the process includes receiving a discovery response including NF profiles matching at least some of the query parameters in the discovery request. For example, consumer NF or

SCP

200 or 101 may receive a discovery request from NRF 100 including NF profiles of producer NFs with attributes that match at least the target NF type and that match any of the preferred NF locations identified in the preferred-locality attribute in the discovery request.

In step 1206, the process includes selecting an NF profile from the NF profiles received from the NRF and sending an SBI service request to a producer NF corresponding to the selected NF profile. For example, consumer NF or

SCP

200 or 101 may select, from the discovery response, an NF profile having a locality that matches one of the preferred NF locations indicated in the NF discovery request. If the discovery response indicates relative priorities of the NF profiles, consumer NF or

SCP

200 or 101 may select the NF profile of the producer NF with the most preferred priority (lowest priority value). If the discovery response includes multiple NF profiles with the same priority, any suitable selection algorithm, including round robin selection, may be used.

Exemplary advantages of the subject matter described herein include enhanced NF discovery to efficiently select optimal producer NFs to provide service to a consumer NF, especially when the producer NF is not available in the same locality as the consumer NF. The preferred-locality attribute can be used in conjunction with other attributes, such as time of day, to benefit other use cases. The use of multiple preferred producer NF locations in the preferred-locality attribute in discovery requests provides for better control of NF discovery and more efficient discovery of producer NFs, especially in the case where there are no matches with the most preferred locality. The ability to indicate multiple preferred NF locations in the discovery request provides improved probability of finding or discovering NFs that are closer to the consumer NF.

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

REFERENCES

1. 3GPP TS 23.501 V16.7.0 (2020-12); 3^rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16).
2. 3GPP TS 23.502 V16.7.1 (2021-01); 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 16).
3. 3GPP TS 29.510 V17.0.0 (2020-12); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17).

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.

Claims

What is claimed is:

1. A method for supporting multiple locations in a preferred-locality attribute for network function (NF) discovery and selection, the method comprising: at an NF repository function (NRF) including at least one processor and a memory:

receiving, from producer NFs, NF registration messages including NF profiles with locality attributes and registering the producer NFs by storing the NF profiles including the locality attributes in an NF registration database local to the NRF;

receiving, from a requesting NF, an NF discovery request having query parameters for discovering producer NFs, the query parameters including a preferred-locality attribute identifying a plurality of different preferred producer NF locations;

retrieving NF profiles from the NF registration database having locality attributes that match any of the preferred producer NF locations;

generating an NF discovery response including the NF profiles retrieved from the NF registration database; and

forwarding the NF discovery response to the requesting NF.

2. The method of claim 1 wherein receiving the NF discovery request from a requesting NF includes receiving the NF discovery request from a consumer NF.

3. The method of claim 1 wherein receiving the NF discovery request from a requesting NF includes receiving the NF discovery request from a service communications proxy (SCP) performing delegated discovery on behalf of a consumer NF.

4. The method of claim 1 wherein receiving the NF discovery request includes receiving an NF discovery request that indicates relative preferences of the requesting NF of the preferred NF locations.

5. The method of claim 4 wherein generating the NF discovery response includes indicating, in the NF discovery response, relative preferences of the NF profiles based on the relative preferences indicated in the discovery request.

6. The method of claim 5 wherein indicating the relative preferences of the NF profiles includes one of:

setting priority attributes of the NF profiles based on the relative preferences indicated in the discovery request; and

ordering the NF profiles based on the relative preferences indicated in the discovery request.

7. The method of claim 1 comprising retrieving NF profiles from the NF registration database having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations.

8. The method of claim 7 wherein generating the discovery response includes including, in the discovery response, the NF profiles in having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations and indication that the NF profiles having locality attributes that match one of the preferred producer NF locations are more preferred than the NF profiles having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations.

9. The method of claim 1 wherein generating the discovery response includes excluding, from the discovery response NF profiles that do not match any of the preferred producer NF locations.

10. The method of claim 1 comprising, at the requesting NF:

receiving the discovery response;

selecting one of the NF profiles having a locality attribute that matches one of the preferred NF locations; and

sending a service based interface (SBI) service request to a producer NF corresponding to the selected NF profile.

11. A system for supporting multiple locations in a preferred-locality attribute for network function (NF) discovery and selection, the system comprising:

an NF repository function (NRF) including at least one processor and a memory; and

an NF discovery/registration manager implemented by the at least one processor for:

forwarding the NF discovery response to the requesting NF.

12. The system of claim 11 the requesting NF comprises a consumer NF.

13. The system of claim 11 wherein the requesting NF comprises a service communications proxy (SCP) performing delegated discovery on behalf of a consumer NF.

14. The system of claim 11 wherein the NF discovery request indicates relative preferences of the requesting NF of the preferred NF locations.

15. The system of claim 14 wherein, in generating the NF discovery response, the NF discovery/registration manager is configured to indicate, in the NF discovery response, relative preferences of the NF profiles based on the relative preferences indicated in the discovery request.

16. The system of claim 15 wherein the NF discovery/registration manager is configured to indicate the relative preferences of the NF profiles in the discovery response by one of:

17. The system of claim 11 wherein the NF discovery/registration manager is configured to retrieve NF profiles from the NF registration database having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations.

18. The system of claim 17 wherein the NF discovery/registration manager is configured to include, in the discovery response, the NF having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations and an indication that the NF profiles having locality attributes that match one of the preferred producer NF locations are more preferred than the NF profiles having attributes that match NF selection attributes in the discovery request but that do not have locality attributes that match any of the different preferred producer NF locations.

19. The system of claim 18 wherein the indication in the discovery response includes one of: priority attributes in the NF profiles; and an order of the NF profiles in the discovery response.

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:

receiving, from producer network functions (NFs), NF registration messages including NF profiles with locality attributes and registering the producer NFs by storing the NF profiles including the locality attributes in an NF registration database local to an NF repository function (NRF);

forwarding the NF discovery response to the requesting NF.