5.3 Nnrf_NFDiscovery Service

29.5103GPP5G SystemNetwork function repository servicesRelease 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.3.1 Service Description

The Nnrf_NFDiscovery service allows a NF or SCP Instance to discover other NF Instances with the potential services they offer, or to discover SEPP instances in the same PLMN, by querying the local NRF.

The Nnrf_NFDiscovery service also allows:

– an SCP to discover other SCP instances,

– an NF or SCP to discover the list of NRF instances that are part of the NRF set with, for each NRF instance, its NRF instance ID and addressing information, if the NRF is part of an NRF set.

It also allows an NRF in a PLMN to re-issue a discovery request towards an NRF in another PLMN (e.g., the HPLMN of a certain UE).

5.3.2 Service Operations

5.3.2.1 Introduction

The service operations defined for the Nnrf_NFDiscovery service are as follows:

– NFDiscover: It provides to the NF service consumer or SCP the profile (including IP address(es) or FQDN) of the NF Instance(s) or NF Service(s) or SEPP instances matching certain input criteria. It also provides to the SCP the profile (including IP address(es) or FQDN) of the SCP Instance(s) matching certain input criteria.

The NFDiscover operation can be invoked by an NF Service Consumer (i.e., "source NF") or SCP requesting to discover NF instances (i.e., "target NFs") located in the same PLMN, or in a different PLMN, or SEPP instances located in the same PLMN. It can also be invoked by an SCP requesting to discover SCP instances located in the same PLMN.

In the description of these operations in clause 5.3.2.2, when the NF instances are located in the same PLMN, both source NF and target NFs are said to be located in the "Serving PLMN" but, in the general case, the functionality is not restricted to the PLMN that is serving a given UE, and it shall be applicable as well to any scenario in which source NF and target NFs belong to the same PLMN.

When source NF and target NFs are located in different PLMNs, the source NF is said to be in the "Serving PLMN", and the target NFs (and the NRF where they are registered) are said to be in the "Home PLMN", similarly to the scenarios described in 3GPP TS 23.502 [3], but the functionality shall be equally applicable to any scenario between any pair of PLMNs (e.g. with the source NF in the Home PLMN and the target NF in the Serving PLMN).

The SCP and SEPP are treated by the Nnrf_NFDiscovery service in the same way as NFs. Specifically, the SCP and SEPP are designated with a specific NF type and NF Instance ID. However, the SCP and SEPP do not support services. Accordingly, references to "NF" or "NF Profile" in the description of the service operations in the following clauses also apply to an SCP and SEPP.

– SCPDomainRoutingInfoGet: It allows a service consumer (e.g. SCP) to fetch the SCP domain routing information (list of all SCP Domains registered by SCPs and the interconnected SCP domains per SCP domain), if both the SCP and the NRF supports the "SCPDRI" feature. It also allows a service consumer (e.g. NRF) to fetch the local SCP domain routing information (based on SCPs registered in the NRF as service producer), if both the NRF as service consumer and NRF as service producer supports the "SCPDRI" feature.

NOTE: Two SCP domains are considered interconnected when at least one SCP belongs to both SCP domains, i.e. at least one SCP can bridge messages between these two SCP domains.

– SCPDomainRoutingInfoSubscribe: It allows a service consumer (e.g. SCP) to create a subscription for changes of the SCP domain routing information, if both the SCP and the NRF supports the "SCPDRI" feature. It also allows a service consumer (e.g. NRF) to create a subscription for changes of local SCP domain routing information, if both the NRF as service consumer and NRF as service producer supports the "SCPDRI" feature.

– SCPDomainRoutingInfoNotify: It allows the NRF to send notification(s) to a service consumer (e.g. SCP) previously subscribed to the changes of the SCP domain routing information, if both the SCP and the NRF supports the "SCPDRI" feature. It also allows the NRF as service producer to send notification(s) to a service consumer (e.g. NRF) previously subscribed to the changes of the local SCP domain routing information, if both the NRF as service consumer and NRF as service producer supports the "SCPDRI" feature.

– SCPDomainRoutingInfoUnsubscribe: It allows a service consumer (e.g. SCP or NRF) to delete a previously created subscription for changes of the SCP domain routing information, if both the service consumer and the NRF as service producer supports the "SCPDRI" feature.

A NRF may be part of an NRF set, whereby all NRF instances of the NRF Set share the same context data (e.g. registered NF profiles, NF status subscriptions). If so, the NF Service Consumer may be configured with the NRF Set ID or it may discover the same in the NRF Bootstrapping response.

If the NRF is part of an NRF set, the NF Service Consumer may retrieve the NRF Set Information from the NRF via the Nnrf_NFDiscovery service, which allows to discover the list of NRF instances that are part of the NRF set with, for each NRF instance, its NRF Instance ID and addressing information (i.e. part of NRF profile).

NOTE: As part of the discovery of NRF instances belonging to an NRF Set, not all attributes in the NFProfile and NFService data structures (typically used for NF Consumer – NF Producer interaction) are needed for the NF Consumer to interact with the instances of the NRF Set, so the discovery response from NRF can be simplified and omit certain parameters.

The NF Service Consumer may register with any of the NRF Instance Id within the NRF Set. If the NRF instance where an NF Service Consumer registered is down, the NF Service Consumer need not re-register to any new NRF instance within the NRF Set. The NRF may provide a binding indication to the NF service consumer, e.g. when the NF Service Consumer registers or updates its NF profile in the NRF or when it issues heartbeat requests, to indicate a preferred binding of the NF Service Consumer to one NRF instance within the NRF set, e.g. based on the location or data center of the registering/registered NF Service Consumer.

5.3.2.2 NFDiscover

5.3.2.2.1 General

This service operation discovers the set of NF Instances (and their associated NF Service Instances), represented by their NF Profile, that are currently registered in NRF and satisfy a number of input query parameters.

Before a service consumer invokes this service operation, it shall consider if it is possible to reuse the results from a previous searching (service discovery).

The service consumer should reuse the previous result if input query parameters in the new service discovery request are the same as used for the previous search and the validity period of the result is not expired.

The service consumer may consider reusing the previous result if the attributes as required for the new query consist of the query attributes from the previous query and additional query attributes. In such case, when the results of a previous query are reused, the service consumer need consider that the previous results will possibly include NF profiles that the new query would not; hence, the service consumer has to complete the filtering itself against the additional filter attributes in the new internal query.

Otherwise, if the query parameters in the new service discovery are different and don’t consist of the previous query attributes and additional ones (i.e. the new query parameters, in general, don’t have any relationship with those of the previous search), the reuse of cached profiles may still be done.

In these two last cases (i.e. where the query parameters of the new query are not identical to the previous query), re-using data from cached profiles may possibly yield to different results than if a new discovery was performed, and thus may be subject to operator’s policy.

NOTE: Certain types of query attributes affect the contents of the NF Profiles returned in the discovery responses (e.g., "preferred-location" typically affects the setting of the "priority" attribute inside the NF Profiles returned by NRF); reusing the results from a previous query, when the new query involves any of such parameters, may not be feasible.

If an SCP receives complete NF profiles (including, e.g. the authorization attributes) from the NRF (see clauses 5.3.2.2.2 and 5.2.2.5.2), the SCP may use these cached profiles to serve new service requests received from NFs with different requester’s information (e.g. different NF type, domain, S-NSSAI), but if it does so, the SCP shall check the authorization parameters of the complete profiles to ascertain that the requesting NFs are authorized to access the related NF services.

The NF Service Consumer should avoid to send multiple NF discovery requests with the same query parameters to NRF simultaneously.

5.3.2.2.2 Service Discovery in the same PLMN

This service operation is executed by querying the "nf-instances" resource. The request is sent to an NRF in the same PLMN of the NF Service Consumer.

Figure 5.3.2.2.2-1: Service Discovery Request in the same PLMN

1. The NF Service Consumer shall send an HTTP GET request to the resource URI "nf-instances" collection resource. The input filter criteria for the discovery request shall be included in query parameters.

An SCP may request to discover the complete profile of NF instances (including, e.g. the authorization attributes) matching the query parameters. Upon receiving such a request, the NRF shall verify that the requesting entity is authorized to discover the complete profile of NF instances, based on local policies or the receipt of an access token granting such permission. If the requesting entity is not authorized to do so, the NRF shall reject the request or handle it as a service discovery request without access to the complete profile.

2a. On success, "200 OK" shall be returned. The response body shall contain a validity period, during which the search result can be cached by the NF Service Consumer, and an array of NF Profile objects, and/or a map of NFInstanceInfo objects of NF instances (if the NF service consumer indicated support of the Enh-NF-Discovery feature in the request) that satisfy the search filter criteria (e.g., all NF Instances offering a certain NF Service name in REGISTERED status, or empty array in case search filter criteria do not match a NF Instance in REGISTERED status). In the latter case, the response may include the noProfileMatchInfo attribute to provide the specific reason for not finding any NF instance that can match the search filter criteria.

2b. On failure or redirection:

– If the NF Service Consumer is not allowed to discover the NF services for the requested NF type provided in the query parameters, the NRF shall return "403 Forbidden" response.

– If the discovery request fails at the NRF due to errors in the input data in the URI query parameters, the NRF shall return "400 Bad Request" status code with the ProblemDetails IE providing details of the error.

– If the discovery request fails at the NRF due to NRF internal errors, the NRF shall return "500 Internal Server Error" status code with the ProblemDetails IE providing details of the error.

– In the case of redirection, the NRF shall return 3xx status code, which shall contain a Location header with an URI pointing to the endpoint of another NRF service instance.

The NF Profile objects returned in a successful result shall contain generic data of each NF Instance, applicable to any NF type, and it may also contain NF-specific data, for those NF Instances belonging to a specific type (e.g., the attribute "udrInfo" is typically present in the NF Profile when the type of the NF Instance takes the value "UDR"). In addition, the attribute "customInfo", may be present in the NF Profile for those NF Instances with custom NF types.

For those NF Instances, the "customInfo" attribute shall be returned by NRF, if available, as part of the NF Profiles returned in the discovery response.

The NRF shall also include, in the returned NF Profile objects, the Vendor-Specific attributes (see 3GPP TS 29.500 [4], clause 6.6.3) that may have been provided by the registered NF Instances.

If the response includes a map of NFInstanceInfo objects of NF instances, the NF Service Consumer may retrieve the NF profiles by issuing a service discovery request with the target-nf-instance-id parameter identifying the target NF Instance ID; the service discovery request shall also include the nrf-disc-uri parameter set to the API URI of the Nnrf_NFDiscovery service of the NRF holding the NF profile, if the nrfDiscApiUri attribute was received in the NFInstanceInfo object and if the service discovery request is addressed to a different NRF than the NRF holding the NF profile.

5.3.2.2.3 Service Discovery in a different PLMN

The service discovery in a different PLMN is done by querying the "nf-instances" resource in the NRF of the Home PLMN.

For that, step 1 in clause 5.3.2.2.2 is executed (send a GET request to the NRF in the Serving PLMN); this request shall include the identity of the PLMN of the home NRF in a query parameter of the URI.

If the NRF in Serving PLMN knows that Oauth2-based authorization is required for accessing the NF Discovery service of the NRF in Home PLMN, e.g. by learning this during an earlier Bootstrapping procedure or local configuration, and if the request received at the NRF in Serving PLMN does not include an access token, the NRF in Serving PLMN may reject the request with a 401 Unauthorized as specified in clause 6.7.3 of 3GPP TS 29.500 [4].

Then, steps 1-2 in Figure 5.3.2.2.3-1 are executed, between the NRF in the Serving PLMN and the NRF in the Home PLMN. In this step, the presence of the PLMN ID of the Home NRF in the query parameter of the URI is not required. The NRF in the Home PLMN returns a status code with the result of the operation. The NRF in the Serving PLMN shall be configured with:

– a telescopic FQDN (see 3GPP TS 23.003 [12] and 3GPP TS 29.500 [4]) of the NRF in the Home PLMN, if TLS protection between the NRF and the SEPP in the serving PLMN relies on using telescopic FQDN; or

NOTE: This is required for the NRF in the serving PLMN to route the NF discovery request to the NRF in the HPLMN through a SEPP in the serving PLMN and the SEPP to terminate the TLS connection with a wildcard certificate.

– with the SEPP FQDN (or the FQDN of the SCP if the communication between the NRF and the SEPP goes through an SCP), if TLS protection between the NRF and the SEPP in the serving PLMN relies on using the 3gpp-Sbi-Target-apiRoot header.

See clause 6.1.4.3 of 3GPP TS 29.500 [4].

Finally, step 2 in clause 5.3.2.2.2 is executed; a status code is returned to the NF Service Consumer in Serving PLMN in accordance to the result received from NRF in Home PLMN.

Figure 5.3.2.2.3-1: Service Discovery in a different PLMN

Steps 1 and 2 are similar to steps 1 and 2 in Figure 5.3.2.2.2-1, where the originator of the service invocation is the NRF in Serving PLMN, and the recipient of the service invocation is the NRF in the Home PLMN.

5.3.2.2.4 Service Discovery with intermediate redirecting NRF

When multiple NRFs are deployed in one PLMN, one NRF may query the "nf-instances" resource in a different NRF so as to fulfil the service discovery request from a NF service consumer. The query between these two NRFs is redirected by a third NRF.

Figure 5.3.2.2.4-1: Service Discovery with intermediate redirecting NRF

1. NRF-1 receives a service discovery request but does not have the information to fulfil the request. Then NRF-1 sends the service discovery request to a pre-configured NRF-2.

2a. Upon receiving a service discovery request, based on the information contained in the service discovery request (e.g. the "supi" query parameter in the URI) and locally stored information NRF-2 shall identify the next hop NRF (see clause 5.2.2.2.3), and redirect the service discovery request by returning HTTP 307 Temporary Redirect response. The locally stored information in NRF-2 may:

a) be preconfigured; or

b) registered by other NRFs (see clause 5.2.2.2.3).

The 307 Temporary Redirect response shall contain a Location header field, the host part of the URI in the Location header field represents NRF-3.

2b. if NRF-2 does not have enough information to redirect the service discovery request, then it responds with 404 Not Found, and the rest of the steps are omitted.

3. Upon receiving 307 Temporary Redirect response, NRF-1 sends the service discovery request to NRF-3 by using the URI contained in the Location header field of the 307 Temporary Redirect response.

4a. Upon success, NRF-3 returns the search result.

4b. On failure or redirection:

– If the NF Service Consumer is not allowed to discover the NF services for the requested NF type provided in the query parameters, the NRF shall return "403 Forbidden" response.

– If the discovery request fails at the NRF due to NRF internal errors, the NRF shall return "500 Internal Server Error" status code with the ProblemDetails IE providing details of the error.

– In the case of redirection, the NRF shall return 3xx status code, which shall contain a Location header with an URI pointing to the endpoint of another NRF service instance.

5.3.2.2.5 Service Discovery with intermediate forwarding NRF

Figure 5.3.2.2.5-1: Service Discovery with intermediate forwarding NRF

1. NRF-1 receives a service discovery request and sends the service discovery request to a pre-configured NRF-2. This may for example include cases where NRF-1 does not have sufficient information as determined by the operator policy to fulfill the request locally.

2a. Upon receiving a service discovery request, based on the information contained in the service discovery request (e.g. the "supi" query parameter in the URI) and locally stored information, NRF-2 shall identify the next hop NRF (see clause 5.2.2.2.3), and forward the service discovery request to that NRF (i.e. NRF-3 in this example) similarly to steps 1 and 2 in Figure 5.3.2.2.2-1 where the originator of the service invocation is NRF-2 and the recipient of the service invocation is NRF-3. The locally stored information in NRF-2 may:

a) be preconfigured; or

b) registered by other NRFs (see clause 5.2.2.2.3).

2b. if NRF-2 does not have enough information to forward the service discovery request, then it responds with 404 Not Found, and the rest of the steps are omitted.

3a. Upon success, NRF-3 returns the search result.

3b. On failure or redirection:

– If the NF Service Consumer is not allowed to discover the NF services for the requested NF type provided in the query parameters, the NRF shall return "403 Forbidden" response.

– If the discovery request fails at the NRF due to NRF internal errors, the NRF shall return "500 Internal Server Error" status code with the ProblemDetails IE providing details of the error.

– In the case of redirection, the NRF shall return 3xx status code, which shall contain a Location header with an URI pointing to the endpoint of another NRF service instance.

4a. NRF-2 forwards the success response to NRF-1.

4b. On failure or redirection:

– NRF-2 forwards the error response to NRF-1.

– In the case of redirection, the NRF shall return 3xx status code, which shall contain a Location header with an URI pointing to the endpoint of another NRF service instance.

NOTE: It is not assumed that there can only be two NRF hierarchies, i.e. the NRF-3 can go on to forward the service discovery request to another NRF.

5.3.2.2.6 Service Discovery with resolution of the target PLMN

This service discovery is done by querying the "nf-instances" resource in the NRF of the target PLMN, similar to the "Service Discovery in a different PLMN", as described in clause 5.3.2.2.3.

The main difference compared with clause 5.3.2.2.3 is that the identity of the target PLMN is not explicitly provided by the NF Service Consumer.

NOTE: This can happen, e.g., when the identity of the UE involved in the service discovery is not based on IMSI, but on GPSI (MSISDN) and, therefore, the MNC/MCC of the target PLMN cannot be derived from the UE identity. It should also be noted that, in these scenarios, the MSISDN may be subject to Mobile Number Portability.

Figure 5.3.2.2.6-1: Service Discovery with resolution of the target PLMN

1. The NF Service Consumer (e.g. an SMS-GMSC) sends a GET request to the NRF in the Local PLMN (i.e., the same PLMN where the NF Service Consumer is located); given that the identity of the target PLMN is not known to the NF Service Consumer, this request shall include as query parameters the identity of the target UE for which NF Service Producers need to be discovered (i.e., the "gpsi" query parameter) and also a parameter indicating that the resolution of the target PLMN must be performed (i.e., "target-nw-resolution" set to true).

2. The NRF in the Local PLMN determines the identity of the Target PLMN, as described in 3GPP TS 23.540 [48], and determines the URI of the Nnrf_NFDiscovery service of the NRF in the Target PLMN.

3. This step is similar to step 1 in Figure 5.3.2.2.3-1, for "Service Discovery in a different PLMN", with the only difference that the "Serving/Home" PLMNs in clause 5.3.2.2.3 are replaced by "Local/Target" PLMNs in the present clause.

4. Steps 4a, 4b are similar to steps 2a, 2b in Figure 5.3.2.2.3-1.

5. Steps 5a, 5b are similar to steps 2a, 2b in Figure 5.3.2.2.2-1.

5.3.2.3 SCPDomainRoutingInfoGet

This service operation retrieves the SCP domain routing information, by sending a HTTP GET request to the resource URI representing the "SCP Domain Routing Information" resource.

Figure 5.3.2.3-1: SCP Domain Routing Information Get

1. The Service Consumer (i.e. SCP) shall send an HTTP GET request to the resource URI "scp-domain-routing-info" document resource.

2a. On success, "200 OK" shall be returned with SCP Domain Routing Information in response body. SCP Domain Routing Information with empty map indicates that no SCP domain is registered in the network.

2b. On failure, the NRF shall return "4xx/5xx" response and the response body may contain a ProblemDetails object describing the detailed information of the failure.

When SCPs are registered to multiple NRFs in the network, any NRF providing SCP domain routing information for the whole network shall retrieve the local SCP domain routing information in other NRF(s) and perform aggregation. This service operation retrieves the local SCP domain routing information, e.g. by another NRF, by sending a HTTP GET request to the resource URI representing the "SCP Domain Routing Information" resource with "local" query parameter set to value "true".

Figure 5.3.2.3-2: Local SCP Domain Routing Information Get

1. The Service Consumer (i.e. SCP) shall send an HTTP GET request to the resource URI "scp-domain-routing-info" document resource with "local" query parameter set to value "true".

2a. On success, "200 OK" shall be returned with local SCP Domain Routing Information in response body. SCP Domain Routing Information with empty map indicates that no SCP domain is registered in the producer NRF.

2b. On failure, the NRF shall return "4xx/5xx" response and the response body may contain a ProblemDetails object describing the detailed information of the failure.

NOTE: In deployments where all SCPs in the network can be managed by the same NRF, i.e. all SCPs register to and discover each other with the same NRF, the NRF managing the SCPs can generate the SCP Domain Routing Information accordingly without involvement of other NRFs.

5.3.2.4 SCPDomainRoutingInfoSubscribe

This service operation is used to create a subscription to get notification when SCP Domain Routing Information is changed, e.g. due to a SCP has registered or updated or deregistered in the network, or to get notification when local SCP Domain Routing Information is changed, e.g. due to a SCP has registered or updated or deregistered in the producer NRF. The operation is invoked by issuing a POST request to the resource URI representing the "SCP Domain Routing Info Subscriptions" collection resource.

Figure 5.3.2.4-1: Subscription to SCP Domain Routing Information change

1. The Service Consumer (i.e. SCP) shall send a POST request to the URI representing the "SCP Domain Routing Info Subscriptions" collection resource. The request body shall contain the callback URI on the Service Consumer to receive the notifications.

To create a subscription for changes of local SCP Domain Routing Information, the request body shall contain the "localInd" with value "true".

2a. On success, "201 Created" shall be returned with "Location" header containing the resource URI to the newly created subscription resource. The response shall contain the data related to the created subscription, including the validity time, as determined by the NRF, after which the subscription becomes invalid. Once the subscription expires, if the Service Consumer wants to keep receiving notifications, it shall create a new subscription in the NRF.

2b. On failure, the NRF shall return "4xx/5xx" response and the response body may contain a ProblemDetails object describing the detailed information of the failure.

5.3.2.5 SCPDomainRoutingInfoNotify

This service operation notifies each subscriber for (local) SCP Domain Routing Information change. The notification is sent to a callback URI that Service Consumer provided during the subscription (see SCPDomainRoutingInfoSubscribe operation in clause 5.3.2.4). The operation is invoked by sending a POST request to the callback URI.

Figure 5.3.2.5-1: Notification of SCP Domain Routing Info Change

1. The NRF shall send a POST request to the callback URI. The request body shall contain the updated SCP Domain Routing Information. The request body shall contain the "localInd" IE with value "true" if the notification is for a change of local SCP Domain Routing Information. SCP Domain Routing Information with empty map indicates that no SCP domain is registered in the network (or in the producer NRF for local SCP Domain Routing Information) after the change.

2a. On success, "204 No content" shall be returned by the NF Service Consumer.

2b. On failure, the NRF shall return "4xx/5xx" response and the response body may contain a ProblemDetails object describing the detailed information of the failure.

5.3.2.6 SCPDomainRoutingInfoUnSubscribe

This service operation removes an existing subscription to SCP (local) Domain Information Change. The operation is invoked by issuing a DELETE request on the resource URI representing the "Individual SCP Domain Routing Info Subscription", which was received in the Location header field of the "201 Created" response received during a successful subscription (see clause 5.3.2.4).

Figure 5.3.2.6-1: Unsubscribe to SCP Domain Routing Information Change

1. The Service Consumer (e.g. SCP or NRF) shall send a DELETE request to the resource URI representing the individual subscription. The request body shall be empty.

2a. On success, "204 No Content" shall be returned. The response body shall be empty.

2b. On failure, the NRF shall return "4xx/5xx" response and the response body may contain a ProblemDetails object describing the detailed information of the failure.