6.3.1 General

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

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

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. The NRF in the local PLMN reaches the NRF in the remote PLMN by forming a target PLMN specific query using the PLMN ID provided by the requester NF. The NF/NF service discovery procedure across PLMNs is specified in clause 4.17.5 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.

For topology hiding, see clause 6.2.17.

6.3.1.0 Principles for Binding, Selection and Reselection

Binding can be used to indicate suitable target NF producer instance(s) for NF service instance selection, reselection and routing of subsequent requests associated with a specific NF producer resource (context) and NF service. This allows the NF producer to indicate that the NF consumer, for a particular context, should be bound to an NF service instance, NF instance, NF service set or NF set depending on local policies and other criteria (e.g. at what point it is in the middle of a certain procedure, considering performance aspects etc).

Binding can also be used by the NF consumer to indicate suitable NF consumer instance(s) for notification target instance reselection and routing of subsequent notification requests associated with a specific notification subscription and for providing Binding Indication for service(s) that the NF consumer produces for the same data context and the NF service producer is subsequently likely to invoke.

The Binding Indication contains the information in Table 6.3.1.0-1.

The Routing Binding Indication may be included in Request, Subscribe or Notification messages (see clause 7.1.2). It may be used in the case of indirect communication by the SCP to route the message. The Routing Binding Indication is a copy of the information in the Binding Indication and also contains the information in Table 6.3.1.0-1.

NOTE 1: Subscription request messages can contain both a Binding Indication and a Routing Binding Indication.

The NF service producer may provide a Binding Indication to the NF service consumer as part of the Direct or Indirect Communication procedures, to be used in subsequent related service requests. The level of Binding Indication provided by the NF service producer to the NF consumer indicates if the resource in the NF service producer is either bound to NF service instance, NF instance, NF Service Set or NF set as specified in Table 6.3.1.0-1. The Binding Indication may include NF Service Set ID, NF Set ID, NF instance ID, or NF service instance ID, for use by the NF consumer or SCP for NF Service Producer (re-)selection. If the resource is created in the NF Service Producer, the NF Service Producer provides resource information which includes the endpoint address of the NF service producer. For indirect communication, the NF service consumer copies the Binding Indication into the Routing Binding Indication in Request or Subscribe message, unless the NF service consumer performs a reselection for indirect communication without delegated discovery.

During explicit or implicit notification subscription, a Binding Indication may be provided by the NF service consumer to NF service producer; the NF service consumer will also provide a Notification Endpoint. The NF service consumer may also provide a Binding Indication in response to notification requests. The level of Binding Indication provided by the NF service consumer to the NF service provider indicates if the Notification Endpoint is either bound to NF service instance, NF instance, NF Service Set or NF set as specified in Table 6.3.1.0-1. The Binding Indication shall include at least one of NF Set ID, NF instance ID, NF Service Set ID and/or NF service instance ID, and may also include the service name. The NF Service Set ID, NF service instance ID, and service name relate to the service of the NF service consumer that will handle the notification.

NOTE 2: The NF service can either be a standardised service as per this specification or a custom service. The custom service can be used for the sole purpose of registering endpoint address(es) to receive notifications at the NRF.

The Binding Indication is used by the NF service producer as notification sender to reselect an endpoint address and construct the Notification Endpoint, i.e. the URI where the notification is to be sent, e.g. if the provided Notification Endpoint of the NF service consumer included in the subscription cannot be reached, according to the following:

– If the service name in the Binding Indication is omitted and the binding for notification is on NF Set or NF Instance level, the endpoint address registered in the NRF at NF Profile level of the NF(s) selected according to the Binding Indication shall be used to construct a new Notification Endpoint.

– If the service name is included in the Binding Indication, an endpoint address registered in the NRF for that service in the NF profile(s) selected according to the Binding Indication shall be used to construct a new Notification Endpoint.

For indirect communication, the NF service producer copies the Binding Indication into the Routing Binding Indication that is included in the Notification request, to be used by the SCP to discover an alternative endpoint address and construct a Notification Endpoint e.g. if the Notification Endpoint that the request targets cannot be reached, according to the following:

– If the service name in the Routing Binding Indication is omitted and the binding for notification is on NF Set or NF Instance level, the endpoint address registered in the NRF at NF Profile level of the NF(s) selected according to the Binding Indication shall be used to construct a new Notification Endpoint.

– If the service name is included in the Routing Binding Indication, an endpoint address registered in the NRF for that service in the NF profile(s) selected according to the Binding Indication shall be used to construct a new Notification Endpoint.

For subscription to notifications via another network function, a separate Binding Indication for subscription related events may be provided by the NF service consumer (see clause 4.17.12.4 of TS 23.502 [3]) and if provided shall be associated with an applicability indicating notification for subscription related events.

If the NF as an NF consumer provides a Binding Indication for services that the NF produces in service requests, the Binding Indication shall be associated with an applicability indicating other service and may contain the related service name(s), in addition to the other parameters listed in Table 6.3.1.0-1. If no service name(s) are provided, the Binding Indication relates to all services that the NF produces.

For NF Set or NF Instance level of binding, a Binding Indication for notifications and other services may be combined if it relates to the same service, and that combined Binding Indication shall then be associated with an applicability indicating all scenarios that the Binding Indication relates to (For this purpose, the applicability can indicate a combination of values).

If no applicability is indicated in a request or subscribe messages, a Binding Indication in that messages is applicable for notification to all events except for the subscription related event (see clause 4.17.12.4 of TS 23.502 [3]).

NOTE 3: Such a request message can be used for implicit subscription.

NOTE 4: Request messages can contain both the Binding Indications for services and for notifications, and in addition, the Routing Binding Indication in the case of indirect communication.

A Binding Indication may be shared by a group of resources (e.g. contexts) identified by a group identifier. This enables a NF Service consumer or producer to update the binding indication for this group of resources in a single request or notification towards a given peer NF service instance, e.g. when a group of resources need to be taken over by a different NF within an NF set. See clause 6.12.1 of TS 29.500 [49].

Table 6.3.1.0-1 defines the selection and reselection behaviour of NF services consumers and SCPs depending on the Binding Indication provided by an NF service producer. The detailed procedures refer to clause 4.17.11 and 4.17.12 of TS 23.502 [3].

Table 6.3.1.0-1: Binding, selection and reselection

Level of Binding Indication	The NF Consumer / Notification sender / SCP selects	The NF Consumer / Notification sender / SCP can reselect e.g. when selected producer is not available	Binding information for selection and re-selection
NF Service Instance	The indicated NF Service Instance	An equivalent NF Service instance: – within the NF Service Set (if applicable) – within the NF instance – within the NF Set (if applicable)	NF Service Instance ID, NF Service Set ID, NF Instance ID, NF Set ID, Service name (NOTE 4)
NF Service Set	Any NF Service instance within the indicated NF Service Set	Any NF Service instance within an equivalent NF Service Set within the NF Set (if applicable) (Note 2)	NF Service Set ID, NF Instance ID, NF Set ID, Service name (NOTE 4)
NF Instance	Any equivalent NF Service instance within the NF instance.	Any equivalent NF Service instance within a different NF instance within the NF Set (if applicable)	NF Instance ID, NF Set ID, Service name (NOTE 4)
NF Set	Any equivalent NF Service instance within the indicated NF Set	Any equivalent NF Service instance within the NF Set	NF Set ID, Service name (NOTE 4)
NOTE 1: if the Binding Indication is not available, the NF Consumer routes the service request to the target based on routing information available. NOTE 2: NF Service Sets in different NFs are considered equivalent if they include same type and variant (e.g. identical NF Service Set ID) of NF Services. NOTE 3: If a Routing Binding Indication is not available, the SCP routes the service request to the target based on available routing information. NOTE 4: The service name is only applicable if the Binding Indication relates to a notification target or If the NF as a NF consumer provides a Binding Indication for services that the NF produces.

6.3.1.1 NF Discovery and Selection aspects relevant with indirect communication

For indirect communication shown in Annex E, the SCP performs the following functionalities regarding Network Function and Network Function Service discovery and selection:

– If the request includes a Routing Binding Indication, the SCP shall route the service request to the requested target as specified in Table 6.3.1.0-1. If the Routing Binding Indication does not exist, the SCP may get the NF Set ID from the NRF or local configuration (if available).

– If the request recipient had previously provided a Binding Indication, then the request sender shall include a Routing Binding Indication with the same contents in subsequent related requests.

6.3.1.2 Location information

The location information describes the network location of the NF instance. It can consist of one or more levels. Each level describes one location aspect, such as geographic location, data centre, cluster, etc. An NF instance has only one location.

The location information may be used to select the NF service instance or NF instance from a particular network location based on local configuration.

NOTE: The location information in TS 29.510 [58] specifies the granularity of location information. It is up to each deployment to determine the granularity of location information to be used.