Content for  TS 29.500  Word version:  19.2.0

This clause specifies the requirements that shall apply when the discovery and associated selection of NF instances or NF service instances is delegated to an SCP (see clause 6.3 and Model D in Annex E of TS 23.501).

When the NF service consumer is configured to use delegated service discovery, it shall include in the HTTP/2 request message the necessary NF service discovery factors to be used by the SCP to perform the NF service discovery procedures and the Service access authorization procedures (see clause 13.4.1.3.2 of TS 33.501) on behalf of the NF service consumer. The latter shall convey these NF service discovery factors using the"3gpp-Sbi-Discovery-*" request headers. How to set the values of these "3gpp-Sbi-Discovery-*" request headers is detailed in clause 5.2.3.2.7. The NF service consumer should also include at least the target NF type and service name in the corresponding "3gpp-Sbi-Discovery-*" request header(s) in its request to the SCP. The NF service consumer may indicate the NRF to use, e.g. as a result of an NSSF query, by including the 3gpp-Sbi-Nrf-Uri header with the NRF API URIs. If the NF service consumer delegates the reselection of a target NF service instance to the SCP (see clause 6.5 of TS 23.527), the NF service consumer shall also include "3gpp-Sbi-Discovery-*" headers in an HTTP/2 request targeting an existing resource context in the NF service producer, if the "3gpp-Sbi-Routing-Binding" header is not included in the HTTP/2 request message (e.g. when no binding information was received from the NF service producer during the resource creation, or if the NF service consumer does not support the binding procedures), to enable the SCP to reselect an NF service producer instance, e.g. if the NF service producer instance indicated in the "3gpp-Sbi-Target-apiRoot" header or target URI is not reachable. Additionally, regardless of whether a "3gpp-Sbi-Routing-Binding" header is included or not in the HTTP/2 request message, the NF service consumer should include at least the target NF type and the service name in the corresponding "3gpp-Sbi-Discovery-*" request header(s) in its request to the SCP. If the NF service consumer includes more than one service name in the 3gpp-Sbi-Discovery-service-names header, the service name corresponding to the service request shall be listed as the first service name in the header. An NF service consumer should also include "3gpp-Sbi-Discovery-*" headers in an HTTP/2 request targeting an existing resource context in the NF service producer to enable the SCP to perform the Service access authorization procedures (see clause 13.4.1.3.2 of TS 33.501). Likewise, an NF service producer may also include "3gpp-Sbi-Discovery-*" headers in a notification or callback request, if the "3gpp-Sbi-Routing-Binding" header is not included in the HTTP/2 request message, to enable the SCP to reselect a different NF service consumer instance, e.g. if the NF service consumer instance indicated in the "3gpp-Sbi-Target-apiRoot" header or target URI is not reachable. Additionally, regardless of whether a 3gpp-Sbi-Routing-Binding header is included or not in the HTTP/2 request message, the NF service producer should include at least the target NF type (i.e. the type of the NF service consumer) in the corresponding "3gpp-Sbi-Discovery-*" request header(s) in its request to the SCP, if available. See clause 6.6 of TS 23.527. When the 3gpp-Sbi-Selection-Info header is included in a HTTP request message and if the SCP supports this header, the SCP shall use it together with 3gpp-Sbi-Routing-Binding or 3gpp-Sbi-Discovery-* heads whichever available. Based on SCP configuration, an SCP deciding to address a next-hop SCP for a service request may delegate the NF instance and/or service instance discovery and selection to subsequent SCPs, in which case it shall forward the "3gpp-Sbi-Discovery-*" request headers to the next-hop SCP. When receiving a request containing "3gpp-Sbi-Discovery-*" request headers and a selection/reselection of the target NF service instance is required, the SCP shall take into account all the NF service discovery factors contained in the "3gpp-Sbi-Discovery-*" request headers to perform the selection or reselection. The SCP should use the NRF indicated in the 3gpp-Sbi-Nrf-Uri header if this header is present in the request. It is also possible for the SCP to be internally configured to fulfil these service discovery tasks without interacting with the NRF. If the service request contains "3gpp-Sbi-Discovery-*" request header(s) that are not supported by the SCP, the latter should include the corresponding query parameters in the discovery request to the NRF. Based on operator policy, the SCP may alternatively reject the request and return a response with the status code "400 Bad Request" to the NF service consumer with an "INVALID_DISCOVERY_PARAM" error. If the service request does not contain the 3gpp-Sbi-Discovery-preferred-api-versions header, the SCP shall select an NF instance and/or service instance that supports the MAJOR version received in the request URI of the service request message. Otherwise, the preferred API MAJOR version included in the 3gpp-Sbi-Discovery-preferred-api-versions header shall be the same as the MAJOR version of the request URI of the service request message. The SCP shall reject the request and return a response with the status code "400 Bad Request" to the NF service consumer with an "INVALID_API" error if no NF profile is found matching the MAJOR version; in this case, the SCP may indicate in the problem details the MAJOR API version(s) known to be supported by NF service producers for the corresponding service.

An NF may register default notification subscriptions in its NF profile or NF services in the NRF for notifications the NF is prepared to consume, including for each type of notification the corresponding notification endpoint (i.e. callback URI). A NF producer may be configured with the types of notifications corresponding to default notification subscriptions it needs to generate, and send such notifications using indirect communication with delegated discovery, i.e. with an SCP discovering and selecting an NF service consumer with a corresponding default notification subscription. In this case, the NF producer shall include in the notification request:

• the 3gpp-Sbi-Callback header including the name of the notify or callback service operation and the API major version if higher than 1, (see also clause 6.10.7);
• the 3gpp-Sbi-Discovery-notification-type header set to the type of notification being set;
• the 3gpp-Sbi-Discovery-n1-msg-class header set to the N1 Message Class of the target default subscription if notification type is "N1_MESSAGE", or the 3gpp-Sbi-Discovery-n2-info-class header set to the N2 Information Class of the target default subscription if the notification type is "N2_INFORMATION";
• the 3gpp-Sbi-Discovery-target-nf-type header indicating the type of the consumer NF; and
• optionally, additional NF service discovery factors header to be used by the SCP to discover and select the consumer NF.

The SCP shall use these 3gpp-Sbi-Discovery* headers to select/reselect a notification endpoint.

The following requirements shall apply when using indirect communication with delegated discovery, or indirect communication without delegated discovery when the NF service consumer only selects an NF set and delegates the selection of the NF service instance to the SCP (see clause 6.10.5.1):

• an SCP that (re)selected the target NF service instance shall include the 3gpp-Sbi-Producer-Id header and, for indirect communication with delegated discovery, if the target NF service instance pertains to an NF Group, the 3gpp-Sbi-Target-Nf-Group-Id header, in the 2xx HTTP response it forwards towards the NF Service Consumer.
  The 3gpp-Sbi-Producer-Id header shall contain the NF Instance ID and it should contain the NF Service Instance ID and, if the NF service instance pertains to an NF set and/or an NF service set, the NF set ID and/or NF service set ID of the NF Service Producer selected by the SCP.
  The 3gpp-Sbi-Target-Nf-Group-Id shall contain the NF Group ID of the NF Service Producer selected by the SCP (see clause 6.10.3.2); if the SCP received a 4xx/5xx HTTP response including a 3gpp-Sbi-Response-Info header with "context-transferred" parameter set to value "true" from the reselected target NF service instance, which indicates the corresponding resource or context has been transferred to the reselected target NF service instance, the SCP shall also insert a 3gpp-Sbi-Producer-Id header and conditionally a 3gpp-Sbi-Target-Nf-Group-Id header in the HTTP response it forwards to the NF Service Consumer.
  If the SCP receives a service request including the 3gpp-Sbi-Retry-Info header set to "no-retries", and no successful response is received by the SCP after forwarding the request once, the SCP should include the 3gpp-Sbi-Producer-Id header, indicating the NF (service) instance ID that the SCP selected, in a 4xx/5xx HTTP response it sends towards the NF Service Consumer.
• If the 3gpp-Sbi-Producer-Id header or the 3gpp-Sbi-Target-Nf-Group-Id header is already present in an HTTP response (e.g. in scenarios with multiple SCPs between the NF service consumer and NF service producer), the SCP shall forward the respective header unmodified in the response towards the HTTP client (without adding any new such respective header).

The CHF may include the 3gpp-Sbi-Alternate-Chf-Id header in an HTTP response towards its NF Service Consumer, containing an alternate charging server identity (i.e. secondary CHF Instance ID of a primary CHF instance, or primary CHF Instance ID of a secondary CHF instance). The following requirements apply when using indirect communication with delegated discovery, or indirect communication without delegated discovery when the NF service consumer only selects an NF set and delegates the selection of the NF service instance to the SCP (see clause 6.10.5.1):

• an SCP that selected a target CHF service instance may include the 3gpp-Sbi-Alternate-Chf-Id header in the HTTP response it forwards towards the NF Service Consumer, containing either the secondary CHF Instance ID of the primary CHF instance selected by the SCP, or containing the primary CHF Instance ID of the secondary CHF instance selected by the SCP;
• If the 3gpp-Sbi-Alternate-Chf-Id header is already present in an HTTP response (e.g. in scenarios with multiple SCPs between the NF service consumer and CHF service producer, or in scenarios where the header is already included by the CHF producer), the SCP shall forward the header unmodified in the response towards the HTTP client (without adding any new such header).

For Indirect Communication without Delegated Discovery, the NF Service Consumer performs the discovery procedure by querying the NRF and the selection of a NF (Service) Set or a specific NF (service) instance. The selection of the target NF service instance may hence be done either by the NF Service Consumer or the SCP (e.g. based on NF (Service) Set information received from the NF Service Consumer). The NF Service Consumer shall send its request to the SCP containing:

• the 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the selected NF service instance, if the SCP is known to the NF Service Consumer and if the NF Service Consumer has selected a specific NF service instance;
• the identity of the selected NF (Service) Set in the associated "3gpp-Sbi-Discovery-*" request header(s) (see clause 6.10.3.2), if the NF Service Consumer has selected a target NF (Service) Set ID.

If the NF Service Consumer only selected an NF (service) Set, it should also include at least the following information in its request to the SCP:

• the target NF type, the service name, and the requested S-NSSAI in the corresponding "3gpp-Sbi-Discovery-*" request header(s) (see clause 6.10.3.2).

The NF service consumer may indicate the NRF to use, e.g. as a result of an NSSF query, by including the 3gpp-Sbi-Nrf-Uri header with the NRF API URIs. If the NF service consumer includes more than one service name in the 3gpp-Sbi-Discovery-service-names header, the service name corresponding to the service request shall be listed as the first service name in the header. SCPs shall support Indirect Communication without Delegated Discovery, which requires support for the following:

• discovering and selecting a target NF service instance from the target NF (service) set identified in the 3gpp-Sbi-Discovery-target-nf-set-id, 3gpp-Sbi-Discovery-target-nf-service-set-id, 3gpp-Sbi-Discovery-amf-region-id and/or 3gpp-Sbi-Discovery-amf-set-id; and
• at least the following additional discovery headers: 3gpp-Sbi-Discovery-target-nf-type, 3gpp-Sbi-Discovery-service-names, 3gpp-Sbi-Discovery-snssais, 3gpp-Sbi-Discovery-target-plmn-list, 3gpp-Sbi-Discovery-requester-plmn-list.

SCPs shall additionally support reselecting an alternative target NF service instance when a (Routing) Binding Indication is not available, as specified in clauses 6.5.3 and 6.6.3 of TS 23.527 and shall also support the 3gpp-Sbi-Discovery-target-nf-instance-id. If the request does not include the apiRoot of a selected NF service instance, or if the SCP needs to reselect a different NF service instance, the SCP shall select an NF service instance using the NF (Service) Set ID and any additional information (e.g. S-NSSAI, service name, target NF type) received in the corresponding "3gpp-Sbi-Discovery-*" request header(s), if available. If the SCP is to invoke NF service discovery towards the NRF to fulfil this task, the SCP should use the NRF indicated in the 3gpp-Sbi-Nrf-Uri header, if this header is present in the request. The SCP that reselected the target NF service instance shall include the 3gpp-Sbi-Producer-Id header in the 2xx HTTP response it forwards towards the NF Service Consumer, containing the NF Instance ID and the NF Service Instance ID of the NF Service Producer selected by the SCP, as specified in clause 6.10.3.4; if the SCP received a 4xx/5xx HTTP response including a 3gpp-Sbi-Response-Info header with "context-transferred" parameter set to value "true" from the reselected target NF service instance, which indicates the corresponding resource or context has been transferred to the reselected target NF service instance, the SCP shall also insert a 3gpp-Sbi-Producer-Id header in the HTTP response it forwards to the NF Service Consumer. The SCP shall then route the request to the selected NF service instance of the target NF service producer. When the 3gpp-Sbi-Selection-Info header is included in a HTTP request message and if the SCP supports this header, the SCP shall use it together with 3gpp-Sbi-Routing-Binding or 3gpp-Sbi-Discovery-* heads whichever available.

An NF may register default notification subscriptions in its NF profile or NF services in the NRF for notifications the NF is prepared to consume, including for each type of notification the corresponding notification endpoint (i.e. callback URI). The following procedures may be used to support notifications corresponding to default notification subscriptions with indirect communication without delegated discovery. An NF producer may perform a discovery request towards the NRF (possibly through an SCP) to discover default notification subscriptions of an NF consumer, and if so, send notifications to the corresponding notification endpoints, using routing mechanisms specified in clause 6.10.2 / clause 6.10.2A. The NF producer shall include in the notification request:

• the 3gpp-Sbi-Callback header including the name of the notify or callback service operation and the API major version if higher than 1, (see also clause 6.10.7);
• the 3gpp-Sbi-Target-apiRoot which is set to the notification uri, or the target URI is set to the notification uri as specified in clause 6.10.2 or clause 6.10.2A respectively;

If the NF producer does not perform reselection, i.e. the reselection is to be done by SCP, the NF producer shall further include in the notification request:

• the 3gpp-Sbi-Discovery-notification-type header set to the type of notification being set; and
• the 3gpp-Sbi-Discovery-n1-msg-class header set to the N1 Message Class of the target default subscription if notification type is "N1_MESSAGE", or the 3gpp-Sbi-Discovery-n2-info-class header set to the N2 Information Class of the target default subscription if the notification type is "N2_INFORMATION"; and
• the 3gpp-Sbi-Routing-Binding header for the default notification based on the Binding Indication value in the NF profile of the NF Service Consumer if available (see also clause 6.12.4); or when the 3gpp-Sbi-Routing-Binding header is not available, the 3gpp-sbi-discovery* headers containing the NF service discovery factors header to be used by the SCP to reselect a consumer NF (to receive the notification request) and the Callback URI Prefix (if any) included in the 3gpp-Sbi-Request-Info header.

The NF producer or SCP may perform a reselection if it cannot reach the target NF as indicated in the 3gpp-Sbi-Target-apiRoot or the target URI, and if a reselection is performed, the entity responsible for reselection (either SCP or NF producer) shall perform reselection as below:

• the NF producer may use the Binding Information that is associated to the default notification;
• The SCP shall use, if available, the Routing Binding Indication (that is associated to the default notification) or alternatively 3gpp-Sbi-discovery* and the 3gpp-Sbi-Request-Info headers to reselect an alternative NF Service Consumer.

After reselection is performed, the NF producer or the SCP shall fetch the alternative notification endpoint from the corresponding default notification subscription registered by the alternative NF Service Consumer. The SCP shall use the 3gpp-Sbi-Discovery-notification-type header and additionally the 3gpp-Sbi-Discovery-n1-msg-class header (for "N1_MESSAGE" notification type) or the 3gpp-Sbi-Discovery-n2-info-class header (for "N2_INFORMATION" notification type) to locate the corresponding default notification subscription of the alternative NF Service Consumer.