6.3.1 General

The NF discovery and NF service discovery enable Core Network entities (NFs or Service Communication Proxy (SCP)) to discover a set of NF instance(s) and NF service instance(s) for a specific NF service or an NF type. NF service discovery is enabled via the NF discovery procedure, as specified in clauses 4.17.4, 4.17.5, 4.17.9 and 4.17.10 of TS 23.502 [3].

Unless the expected NF and NF service information is locally configured on the requester NF, e.g. when the expected NF service or NF is in the same PLMN as the requester NF, the NF and NF service discovery is implemented via the Network Repository Function (NRF). NRF is the logical function that is used to support the functionality of NF and NF service discovery and status notification as specified in clause 6.2.6.

NOTE 1: NRF can be colocated together with SCP e.g. for communication option D, depicted in Annex E.

In order for the requested NF type or NF service to be discovered via the NRF, the NF instance need to be registered in the NRF. This is done by sending a Nnrf_NFManagement_NFRegister containing the NF profile. The NF profile contains information related to the NF instance, such as NF instance ID, supported NF service instances (see clause 6.2.6 for more details regarding the NF profile). The registration may take place e.g. when the producer NF instance and its NF service instance(s) become operative for the first time. The NF service registration procedure is specified in clause 4.17.1 of TS 23.502 [3].

In order for the requester NF or SCP to obtain information about the NF and/or NF service(s) registered or configured in a PLMN/slice, based on local configuration the requester NF or SCP may initiate a discovery procedure with the NRF by providing the type of the NF and optionally a list of the specific service(s) it is attempting to discover. The requester NF or SCP may also provide other service parameters e.g. slicing related information. For the detailed service parameter(s) used for specific NF and NF service discovery refer to clause 5.2.7.3.2 of TS 23.502 [3]. The requester NF may also provide NF Set related information to enable reselection of NF instances within the NF set. The requester NF may also provide the required supported features of the NF.

For some Network Functions which have access to the subscription data (e.g. HSS, UDM) the NRF may need to resolve the NF Group ID corresponding to a subscriber identifier. If the NRF has no stored configuration mapping identity sets/ranges to NF Group ID locally, the NRF may retrieve the NF Group ID corresponding to a specific subscriber identifier from the UDR using the Nudr_GroupIDmap_Query service operation.

In the case of Indirect Communication, a NF Service Consumer employs an SCP which routes the request to the intended target of the request.

If the requester NF is configured to delegate discovery, the requester NF may omit the discovery procedure with the NRF and instead delegate the discovery to the SCP; the SCP will then act on behalf of the requester NF. In this case, the requester NF adds any necessary discovery and selection parameters to the request in order for the SCP to be able to do discovery and associated selection. The SCP may interact with the NRF to perform discovery and obtain discovery result and it may interact with the NRF or UDR to obtain NF Group ID corresponding to subscriber identifier.

NOTE 2: For delegated discovery of the HSS or the UDM, the SCP can rely on the NRF to discover the group of HSS/UDM instance(s) serving the provided user identity, or in some deployments the SCP can first query the UDR for the HSS/UDM Group ID for the provided user identity. It is expected that the stage 3 defines a single encoding for the user identity provided by the service consumer that can be used for both variants of delegated discovery to avoid that the service consumer needs to be aware of the SCP behaviour.

The NRF provides a list of NF instances and NF service instances relevant for the discovery criteria. The NRF may provide the IP address or the FQDN of NF instance(s) and/or the Endpoint Address(es) of relevant NF service instance(s) to the NF Consumer or SCP. The NRF may also provide NF Set ID and/or NF Service Set ID to the NF Consumer or SCP. The response contains a validity period during which the discovery result is considered valid and can be cached. The result of the NF and NF service discovery procedure is applicable to any subscriber that fulfils the same discovery criteria. The entity that does the discovery may cache the NF profile(s) received from the NF/NF service discovery procedure. During the validity period, the cached NF profile(s) may be used for NF selection for any subscriber matching the discovery criteria.

NOTE 3: Refer to TS 29.510 [58] for details on using the validity period.

In the case of Direct Communication, the requester NF uses the discovery result to select NF instance and a NF service instance that is able to provide a requested NF Service (e.g. a service instance of the PCF that can provide Policy Authorization).

In the case of Indirect Communication without Delegated Discovery, the requester NF uses the discovery result to select a NF instance while the associated NF service instance selection may be done by the requester NF and/or an SCP on behalf of the requester NF.

In both the cases above, the requester NF may use the information from a valid cached discovery result for subsequent selections (i.e. the requester NF does not need to trigger a new NF discovery procedure to perform the selection).

In the case of Indirect Communication with Delegated Discovery, the SCP will discover and select a suitable NF instance and NF service instance based on discovery and selection parameters provided by the requester NF and optional interaction with the NRF. The NRF to be used may be provided by the NF consumer as part of the discovery parameters, e.g. as a result of a NSSF query. The SCP may use the information from a valid cached discovery result for subsequent selections (i.e. the SCP does not need to trigger a new NF discovery procedure to perform the selection).

NOTE 4: In a given PLMN, Direct Communication, Indirect Communication, or both may apply.

The requester NF or SCP may subscribe to receive notifications from the NRF of a newly updated NF profile of an NF (e.g. NF service instances taken in or out of service), or newly registered de-registered NF instances. The NF/NF service status subscribe/notify procedure is defined in clauses 4.17.7 and 4.17.8 of TS 23.502 [3].

For NF and NF service discovery across PLMNs, the NRF in the local PLMN interacts with the NRF in the remote PLMN to retrieve the NF profile(s) of the NF instance(s) in the remote PLMN that matches the discovery criteria. If the NRF in the local PLMN indicated support, for the local PLMN, of indirect communication with delegated discovery with NF (re)selection at target PLMN (Model D in Annex E with SCP in target PLMN doing NF (re)selection) and/or of indirect communication without delegated discovery with NF (re)selection at target PLMN (Model C in Annex E with SCP in target PLMN doing NF (re)selection), based on operator's policy and the capabilities of the local PLMN, the NRF in the remote PLMN may also return an indication that indirect communication with delegated discovery with NF (re)selection at target PLMN is requested or that indirect communication without delegated discovery with NF (re)selection at target PLMN is requested and, for delegated discovery in target PLMN, omit NF profiles. The NRF in the local PLMN reaches the NRF in the remote PLMN by forming a remote PLMN specific query using the PLMN ID provided by the requester NF. The remote PLMN NRF may further interact with a target PLMN NRF as specified in clause 6.2.6.1. Based on operator's policy and configuration, the NRF in the local PLMN may also determine without interaction with the NRF in the remote PLMN that indirect communication with delegated discovery with NF (re)selection at target PLMN is requested for communication for that remote PLMN. The NF/NF service discovery procedure across PLMNs is specified in clauses 4.17.5, 4.17.10 and 4.17.10a of TS 23.502 [3].

NOTE 5: See TS 29.510 [58] for details on using the target PLMN ID specific query to reach the NRF in the remote PLMN.

NOTE 6: The NRF in the local PLMN can interact with NRFs in target PLMNs already before receiving related discovery requests to inquire the support of indirect communication by those target PLMNs, cache the received information and use it for subsequent discovery requests.

For topology hiding, see clause 6.2.17.

The NRF may take appropriate action, upon detection of certain local events, e.g. NF load that NF resource usage is abnormal, or from notification of subscription to signalling storm analytics to predict signalling storm from NWDAF.