6.10 Support of Indirect Communication

29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS

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

6.10.1 General

NF Service Consumers and NF Service Producers may support or be configured to use Indirect Communication models via SCP as specified in clauses 6.3 and 7.1 of 3GPP TS 23.501 [3]. This clause defines specific requirements to support Indirect Communication models.

An SCP may be known to the NF (e.g. SCP based on independent deployment units) or not (e.g. SCP based on service mesh, with co-located NF and SCP within the same deployment unit). If the SCP is known to the NF, the NF shall be configured with a scheme, authority, and optionally a deployment-specific prefix of the SCP. The scheme may be "http" or "https". If the scheme is "https" then the authority shall contain an FQDN and not a literal IP address. If the scheme is "http" then the authority shall contain either an FQDN or a literal IP address. In either case, the authority may optionally contain a port number. If the SCP is known to the NF, but the NF is not configured with a deployment-specific prefix of the SCP, the NF shall consider the deployment-specific prefix of the SCP to be empty. If the SCP is unknown to the NF, the NF may still be configured to use delegated discovery through the unknown SCP as detailed in Clause 6.10.2A.

NOTE: See Annex G of 3GPP TS 23.501 [3] for SCP deployment examples.

Indirect Communication models shall support the same level of security as Direct Communication ones. Security requirements for Indirect Communications are specified in clauses 5.9.2.4 and 13.3 of 3GPP TS 33.501 [17]. TLS shall be used between the SCP and NFs, if network security is not provided by other means. When co-located, the NF and associated SCP may interact using HTTP. Clause 6.7.5 specifies how to support the client credentials assertion and authentication procedure specified in clause 13.3.8 of 3GPP TS 33.501 [17].

More than one SCP may be present in the communication path between an NF Service Consumer and an NF Service Producer. Clauses 6.2.19 and 6.3.16 of 3GPP TS 23.501 [3] describe how to route messages through SCPs.

6.10.2 Routing Mechanisms with SCP Known to the NF

6.10.2.1 General

The routing mechanisms specified in clause 6.1 shall apply for Indirect Communication models with the additions or modifications specified in this clause. This routing mechanism shall be used when TLS is used between the NF and the SCP, or between two SCPs. This routing mechanism may also be used when TLS is not used, i.e. when network security is provided by other means.

6.10.2.2 HTTP/2 connection management

Separate HTTP(S) connections shall be set up between the HTTP client and the SCP, between SCPs (if there is more than one SCP in the communication path between the HTTP client and the HTTP server), and between the SCP and the HTTP server. HTTP CONNECT requests shall not be used for Indirect Communication models.

The NFs and the SCP shall manage the HTTP/2 connections as defined in clause 5.2.6.

6.10.2.3 Connecting inbound

If the request is not satisfied by a local cache, the NF (acting as an HTTP/2 client) shall connect inbound by establishing (or reusing) a connection to an available SCP as defined in clause 5.2 of IETF RFC 7230 [12] when sending HTTP/2 request.

When forwarding a request to another SCP, an SCP shall connect inbound by establishing (or reusing) a connection to the next hop SCP.

When the SCP forwards the request to the HTTP server, the SCP (acting as an HTTP/2 client) shall connect inbound to an authority server for the target resource. For connecting inbound to an authority not in the same PLMN, the SCP shall connect to the Security Edge Protection Proxy.

6.10.2.4 Pseudo-header setting

For Indirect Communications with or without delegated discovery, when sending a request to the SCP, the HTTP client shall set the pseudo-headers as follows:

– ":scheme"set to "http" or "https";

– ":authority" set to the FQDN or IP address of the SCP (if the scheme is "http"), or to the FQDN of the SCP (if the scheme is "https");

– ":path" including the optional deployment-specific string of the SCP and the path and query components of the target URI excluding the optional deployment-specific string of the target URI.

An HTTP client sending a notification or callback request cannot know whether the callback URI contains any deployment specific string or not. Accordingly, it shall behave assuming that there is no deployment specific string in the callback (i.e. target) URI. When an HTTP client sending a notification request corresponding to default notification subscription where the target URI is unknown (e.g. for Indirect Communication with Delegated Discovery, as specified in clause 6.10.3.3), it shall include the optional deployment-specific string of the SCP and the pseudo target URI for default subscription ("/scp-default-sub-notify-uri") in the ":path".

Additionally, for HTTP requests for which an HTTP client may cache responses (e.g. GET request), the HTTP client should include the cache key (ck) query parameter set to an implementation specific value that is bound to the target NF (see clause 6.10.2.6).

The HTTP client shall include the apiRoot of an authority server for the target resource (including the optional deployment-specific string of the target URI), if available, in the 3gpp-Sbi-Target-apiRoot header (see clause 6.10. 2.5).

When forwarding a request to another SCP, an SCP shall replace the apiRoot of the SCP received in the request URI of the incoming request by the apiRoot of the next hop SCP. The SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource (including the optional deployment-specific string of the target URI), if available, e.g. if the 3gpp-Sbi-Target-apiRoot header was received in the request. The SCP shall set the pseudo-headers as specified in clause 6.1, with the following additions:

– the SCP shall modify the ":authority" HTTP/2 pseudo-header field to the FQDN or IP address of the next hop SCP (if the scheme is "http"), or to the FQDN of the SCP (if the scheme is "https").

– the SCP shall remove any optional deployment-specific string of the SCP in the ":path" HTTP/2 pseudo-header and add any optional deployment-specific string of the next hop SCP;

– the SCP shall remove the cache key query parameter, if this parameter was received in the request;

– if the pseudo target URI for default subscription ("/scp-default-sub-notify-uri") is present in the ":path", the SCP shall replace it with the real path of the target URI registered in the selected default subscription.

When forwarding a request to the HTTP server, the SCP shall replace the apiRoot of the SCP received in the request URI of the incoming request by the apiRoot of the target NF service instance. If the 3gpp-Sbi-Target-apiRoot header was received in the request, the SCP shall use it as the apiRoot of the target NF service instance, if the SCP does not (re)select a different HTTP server, and regardless shall remove it from the forwarded request. The SCP shall set the pseudo-headers as specified in clause 6.1, with the following additions:

– the SCP shall modify the ":authority" HTTP/2 pseudo-header field to the FQDN or IP address of the target NF service instance (if the scheme is "http"), or to the FQDN of the target NF service instance (if the scheme is "https").

– the SCP shall remove any optional deployment-specific string of the SCP in the ":path" HTTP/2 pseudo-header and add any optional deployment-specific string of the target URI;

– the SCP shall remove the cache key query parameter, if this parameter was received in the request;

– f the pseudo target URI for default subscription ("/scp-default-sub-notify-uri") is present in the ":path", the SCP shall replace it with the real path of the target URI registered in the selected default subscription.

EXAMPLE 1: For indirect communication without delegated discovery, if the NF Service Consumer needs to send the request "GET https://example.com/a/b/c/nudm-sdm/v1/{supi}/nssai" to the NF Service Producer (represented by the FQDN "example.com" and where "/a/b/c" is the "apiPrefix" of the NF service producer figured out from NRF discovery):

– the NF service consumer shall send the request "GET https://scp.com/1/2/3/nudm-sdm/v1/{supi}/nssai" to the SCP (where "/1/2/3" is the "apiPrefix" of the SCP), with the "3gpp-sbi-target-apiRoot" header set to "https://example.com/a/b/c".

– the SCP shall send the request "GET https://example.com/a/b/c/nudm-sdm/v1/{supi}/nssai" to the NF Service Producer, without any "3gpp-sbi-target-apiRoot" header.

EXAMPLE 2: For indirect communication, if the NF Service Producer needs to send a notification request "POST https://example.com/a/b/c/notification" to the NF Service Consumer (represented by the FQDN "example.com", i.e. the host part of the callback URI):

– the NF service producer shall send the request "POST https://scp.com/1/2/3/a/b/c/notification" to the SCP (where "/1/2/3" is the "apiPrefix" of the SCP), with the "3gpp-sbi-target-apiRoot" header set to "https://example.com".

– the SCP shall send the request "POST https://example.com/a/b/c/notification" to the NF Service Consumer, without any "3gpp-sbi-target-apiRoot" header.

EXAMPLE 3: For indirect communication with Delegated Discovery, if the NF Service Producer needs to send a notification request to a default subscription and SCP selects a target default notification subscription (with callback URI "https://example.com/a/b/c/notification" registered):

– the NF service producer shall send the request "POST https://scp.com/1/2/3/scp-default-sub-notify-uri" to the SCP (where "/1/2/3" is the "apiPrefix" of the SCP).

– the SCP shall send the request "POST https://example.com/a/b/c/notification" to the selected NF Service Consumer.

6.10.2.5 3gpp-Sbi-Target-apiRoot header setting

For Indirect Communications with or without delegated discovery, the HTTP client shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the SCP. In particular:

– for Indirect Communication without Delegated Discovery, a service request sent to the SCP to create a resource shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the selected NF service instance of the NF Service Producer, if the NF Service Consumer has indeed selected a specific NF service instance;

– after a resource has been created, subsequent service requests sent to the SCP and targeting the resource shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot received earlier in Location header of service responses from the NF Service Producer;

– notifications or callbacks sent via the SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the notification or callback URI (i.e. "http" or "https" scheme, the fixed string "://" and authority (host and optional port) as defined in IETF RFC 3986 [14]).

An SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the next hop SCP. In particular:

– if the received request does not include a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, and NF service discovery is not delegated to a next hop SCP, then the SCP shall select a target NF service instance (performing an NF service discovery with the NRF or based on local configuration (i.e. without interacting with NRF) according to the received "3gpp-Sbi-Discovery-*" request header(s)) and insert a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the selected target NF service instance;

– if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, but the SCP needs to reselect a different NF service instance, the SCP shall modify and set the 3gpp-Sbi-Target-apiRoot header to the apiRoot of the newly selected target NF service instance;

– if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance and the SCP does not reselect a different NF service instance, the SCP shall forward the received 3gpp-Sbi-Target-apiRoot header to the next hop SCP.

When forwarding the request to the HTTP server, the SCP shall set the pseudo-headers as specified in clause 6.10.2.4.

6.10.2.6 Cache key (ck) query parameter

The cache key (ck) query parameter may be used by cache systems in the NF service consumer and/or in the SCP in order to distinguish cache objects.

It shall be set to a string value that is linked to the apiRoot of the target NF, i.e. the same apiRoot shall always produce the same value for the content of the ck parameter. The ck parameter may contain e.g. a short compact hash value of the whole apiRoot of the target NF.

The ck parameter shall only be used in HTTP requests between the NF service consumer and the SCP, it shall not be sent to the actual NF service producer.

The ck parameter is not part of the actual service definition and therefore it is not documented in OpenAPI specification files. It shall comply with the following OpenAPI definition:

paths:

/<resource>:

<method>:

parameters:

– name: ck

in: query

description: cache key parameter

schema:

type: string

6.10.2A Routing Mechanism with SCP Unknown to the NF

6.10.2A.1 Connecting inbound

When indirect communication models are used and a NF sends an HTTP/2 request, this NF (acting as an HTTP/2 client) shall connect directly to an authority for the target resource via an available SCP, which then acts as an "interception proxy" as defined in clause 2.5 of IETF RFC 3040 [36] and also referred to in clause 2.3 of IETF RFC 7230 [12]. This routing mechanism is incompatible with and shall not be used when TLS is used between the NF and the SCP.

6.10.2A.2 HTTP/2 connection management

The NF shall manage the HTTP/2 connections as defined in clause 5.2.6.

6.10.2A.3 Pseudo-header setting

The NF service consumer shall set the following pseudo-headers:

– ":scheme" pseudo-header shall be set to "http";

NOTE: When the SCP is implemented using service mesh technologies (e.g. as described in Annex G.2 in 3GPP TS 23.501 [3]), the SCP needs to be able to read the start line and the header fields of HTTP/2 messages, and https cannot be used by NFs. In this case, mutual authentication and TLS between a NF and its associated SCP can be implicit by physical security; mutual authentication and TLS is then set up between SCP interfaces.

– ":authority" pseudo-header shall be set as follows:

– if delegated discovery is used and has not yet been performed by the SCP, or if the NF Service Consumer only selects a target NF (service) set when in Indirect Communication without delegated discovery: set based on local configuration.

– if delegated discovery is not used or has already been performed by the SCP: set as specified in clause 6.1.4.

– ":path" pseudo-header shall include the path and query components of the target URI as specified in clause 6.1.4.

6.10.3 NF Discovery and Selection for indirect communication with Delegated Discovery

6.10.3.1 General

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 3GPP TS 23.501 [3]).

6.10.3.2 Conveyance of NF Discovery Factors

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 3GPP TS 33.501 [17]) 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 3GPP TS 23.527 [38]), 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.

NOTE 1: Other 3gpp-Sbi-Discovery-*" request header(s) can also be included in any service request sent to an SCP, regardless of whether the 3gpp-Sbi-Routing-Binding" header is included or not in the HTTP/2 request message, to convey requester’s information necessary for the NRF to validate whether the requester is allowed to discover and access a given NF (see NOTE 12 of Table 6.2.3.2.3.1-1 of 3GPP TS 29.510 [8]).

NOTE 2: A request including a 3gpp-Sbi-Routing-Binding header needs not include the requested S-NSSAI in the corresponding 3gpp-Sbi-Discovery-*" request header, since if the NF service producer supports different sets of NF service instances serving different network slices, the NF Service Set ID in the binding indicaton is available for reselecting an NF service instance (see clauses 5.2.3.2.5 and 6.12.1).

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.

NOTE 3: The SCP can assume that the service request corresponds to 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 3GPP TS 33.501 [17]).

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 3GPP TS 23.527 [38].

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.

6.10.3.3 Notifications corresponding to default notification subscriptions

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).

NOTE: This can be used e.g. by an AMF to discover the notification endpoint of other AMFs to forward N1 or N2 messages, or by an AMF to notify location information to a GMLC, or by an UDR to notify data change or removal to an UDM.

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.

6.10.3.4 Returning the Producer’s NF Instance ID and NF Group ID to the NF Service Consumer

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 IDof 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 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).

NOTE 1: This allows to support deployments where not all NF Service Producers or NF Service Consumers have been upgraded to support the binding procedures.

NOTE 2: In scenarios where the same NF Service Producer needs to be selected when creating new resources, e.g. when the AMF needs to establish a new PDU session towards the same SMF as the one selected for a previous PDU session, the NF Service Consumer can include the 3gpp-Sbi-Discovery-target-nf-instance-id header set to the NF Instance ID of the NF Service Producer in the request creating the new resource.

NOTE 3: An SCP needs not insert a 3gpp-Sbi-Producer-Id header nor a 3gpp-Sbi-Target-Nf-Group-Id header in an HTTP response if it received a 3gpp-Sbi-Target-apiRoot header in the related HTTP request and it did not reselect a different NF Service Producer.

NOTE 4: Inserting the NF Service Instance ID, NF Set ID and/or NF Service Set ID in the 3gpp-Sbi-Producer-Id header enables NF service consumers to perform overload control towards a specific NF producer service instance, NF set or NF service set when the NF service producer advertises overload control with a scope set to a specific NF service instance, NF set or NF service set (see clause 6.4.3). It also enables NF service consumers to reselect another NF service instance in the same NF instance, NF set or NF service set when so required (see e.g. clause 6.12.1 and clause 6.5.3 of 3GPP TS 23.527 [38]).

6.10.3.5 Returning an Alternate CHF instance ID to the NF Service Consumer

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).

NOTE 1: Subsequently, if the CHF service consumer needs to reselect the alternate CHF instance, it can send its request with the 3gpp-Sbi-Discovery-target-nf-instance-id set to the alternate CHF instance ID and with no 3gpp-Sbi-Target-apiRoot header. This leads the SCP to route the request towards the secondary CHF instance, and the SCP includes in the response the 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the alternate CHF instance as specified in clause 6.10.4.

NOTE 2: The SCP remains agnostic of applicative requirements on failure handling and retry handling. Accordingly, failure handling and retry handling is controlled by CHF’s consumers.

6.10.4 Authority and/or deployment-specific string in apiRoot of resource URI

For Indirect Communications with or without delegated discovery, the SCP may select or reselect the specific NF (service) instance towards which to send a request.

NOTE 1: For Indirect Communications without delegated discovery, the SCP selects for instance a specific (service) instance within a NF (Service) Set that was selected by the NF Service Consumer.

Consequently, NF as HTTP client shall be capable to receive and process an authority and/or deployment-specific string in the apiRoot of the created or updated resource URI that differs from the authority and/or deployment-specific string of the apiRoot of the Request URI.

If the NF Service Producer includes a relative URI (see IETF RFC 3986 [14]) in the "Location" header of an HTTP response creating a resource, the SCP shall resolve the URI reference using the target URI included in the HTTP POST request sent to the NF Service Producer as base URI, and return an absolute URI in the "Location" header in the HTTP response sent to the NF Service consumer, unless the SCP did not change the target URI when forwarding the HTTP POST request from the NF Service Consumer to the NF Service Producer.

NOTE 2: The target URI can remain unchanged when forwarding an HTTP POST request from the NF Service Consumer to the NF Service Producer if indirect communication without delegated discovery and without TLS is used between the NF Service Consumer and the SCP, and the SCP uses the NF (service) instance of the NF Service Producer that is selected by the NF Service Consumer.

If the SCP changed the target URI when forwarding the request from the HTTP client to HTTP server and no "Location" header is included in the HTTP response (e.g. subsequent service request towards a created resource), the SCP shall include a "3gpp-Sbi-Target-apiRoot" header with value set to the apiRoot of the target HTTP server when forwarding the 2xx HTTP response, or an 4xx/5xx HTTP response including a 3gpp-Sbi-Response-Info header with "context-transferred" parameter set to value "true", to the NF as HTTP client.

NOTE 3: To avoid further reselection of HTTP server by SCP, the NF as HTTP client updates the locally stored URI (e.g. resource URI or notification callback URI) used in the request with the target apiRoot received in the HTTP response, and thus send subsequent request to the updated target URI.

6.10.5 NF / NF service instance selection for Indirect Communication without Delegated Discovery

6.10.5.1 General

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).

NOTE 1: This is to allow the SCP to discover and select a target NF service instance from the target NF (service) set for the corresponding service request and supporting the requested S-NSSAI, e.g. when the NF service producer supports different NF service instances serving different network slices. Likewise, other "3gpp-Sbi-Discovery-*" request header(s), e.g. target-plmn-list, requester-plmn-list, can also be included for the same purpose.

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.

NOTE 2: The SCP can assume that the service request corresponds to 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.

NOTE 3: The SCP can derive the requester NF type from the User-Agent header.

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 3GPP TS 23.527 [38] and shall also support the 3gpp-Sbi-Discovery-target-nf-instance-id.

NOTE 4: The inclusion of the 3gpp-Sbi-Discovery-target-nf-instance-id in an HTTP request enables the SCP to discover the profile of the target NF instance and to possibly reselect a different target NF service instance from the same NF instance or from a different NF instance in the same set, e.g. when the target NF instance is not reachable, as specified in 3GPP TS 23.527 [38].

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.

NOTE 5: For Indirect Communication without Delegated Discovery, the NF Service Consumer decides if it will perform the reselection or delegate the SCP to perform the reselection as specified in clause 6.5 of 3GPP TS 23.527 [38].

6.10.5.2 Notifications corresponding to default notification subscriptions

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 / 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 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-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).

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* headers to reselect an alternative notification endpoint.

6.10.6 Feature negotiation for Indirect Communication with Delegated Discovery

The requirements specified in clause 6.6.2 for feature negotiation shall apply with the following additions.

With Indirect Communications with Delegated Discovery, the NF Service Consumer cannot discover the features supported by the NF Service Producer via the NRF.

The NF Service Consumer shall include in HTTP PUT or POST requests to create a resource that requires specific features to be supported by the NF Service Producer, the 3gpp-Sbi-Discovery-required-features header set to the required features to be supported.

The SCP shall reject the request with the HTTP status code "400 Bad Request" and the protocol error "NF_DISCOVERY_FAILURE" if no NF Service Producer supporting the required features can be discovered.

6.10.7 Notification and callback requests sent with Indirect Communication

Notification and callback requests that are sent using indirect communication shall include a 3gpp-Sbi-Callback header including the name of the notification or callback service operation (see Annex B) and the API major version if higher than 1.

The SCP shall derive from the presence of this header that a service request is a notification or callback request.

NOTE: This can be used by the SCP to apply differentiated treatments for notification and callback requests compared to other service requests, e.g. for authorization (access token is not used in notification / callback, see clause 6.7.3).

The NF service producer should include the NRF API URI for NF service consumer reselection in 3gpp-Sbi-Nrf-Uri header, if previously received from the NF service consumer in 3gpp-Sbi-Nrf-Uri-Callback header (see clause 6.5.3.2) and the NF service producer delegates the NF service consumer reselection to the SCP.

Editor’s Note: NRF API URI usage for NF service consumer reselection in inter-PLMN scenarios are FFS.

6.10.8 Error Handling

6.10.8.1 General

A request from an HTTP client (i.e. a service request from an NF service consumer, or a notification request from an NF service producer) may traverse one or more SCPs and/or SEPPs and may fail at an SCP, SEPP or at the HTTP server.

The HTTP client should be able to figure out whether the request failed at its next hop SCP or SEPP, or at the HTTP server, e.g. to be able to adapt its behaviour for the on-going request or subsequent request accordingly. For instance, the HTTP client may retry the request or send subsequent requests towards the same HTTP server via a different SCP or SEPP if an SCP or SEPP rejected a request due to insufficient resources, or towards a different HTTP server (via the same or a different SCP or SEPP) if the HTTP server rejected the request due to insufficient resources.

NOTE: An SCP or SEPP can also retry a request towards a different SCP or SEPP, or towards a different HTTP server, instead of relaying the response back to the originator, if a next hop SCP or SEPP or if the HTTP server rejected a request e.g. due to insufficient resources.

If the SCP or HTTP client receives an error response including the 3gpp-Sbi-Response-Info header with the "no-retry" parameter set to "true", the SCP or HTTP client shall consider that the request cannot be served anywhere and should not retry the request at the original HTTP server instance or at any other alternative HTTP server instance; the SCP shall forward the error response to the HTTP client including the 3gpp-Sbi-Response-Info header.

When receiving an error response, the HTTP client should be able to figure out whether the SCP attempted to retransmit the request to an alternative HTTP server instance. To enable so, if the SCP attempted to retransmit the request to an alternative HTTP server instance, it shall indicate so in the error response by including the 3gpp-Sbi-Response-Info header with the "request-retransmitted" parameter set to "true" and by optionally including the list of NF instances, NF sets, NF service instances or NF service sets that it attempted. The SCP may indicate in the error response that it did not attempt to retransmit the request to an alternative HTTP server instance by including the 3gpp-Sbi-Response-Info header with the "request-retransmitted" parameter set to "false". The HTTP client may use this information to determine whether it may retransmit the request to an alternative HTTP server instance.

If an SCP or SEPP receives an error response including the 3gpp-Sbi-Response-Info header with the "request-retransmitted" parameter set to "true" (e.g. in a scenario with two SCPs between the HTTP client and HTTP server), the SCP (if it does not reselect a target NF) or SEPP shall forward the error response with the the 3gpp-Sbi-Response-Info header unmodified towards the HTTP client; alternatively, the SCP may reselect a target NF and, if the NF reselection fails, the SCP may add the list of of NF instances, NF sets, NF service instances or NF service sets that it attempted in the 3gpp-Sbi-Response-Info header returned in the error response towards the HTTP client.

NOTE 1: This can correspond to errors originated by the SCP or by an HTTP server.

NOTE 2: Rel-17 onwards compliant SCPs support and can be configured (or not) to reselect a different NF service producer or consumer, e.g. when the target URI of a service request (or notification request) is not reachable, as specified in 3GPP TS 23.527 [38].

6.10.8.2 Requirements for the originator of an HTTP error response

To enable an HTTP client to determine the originator of an HTTP error response, the originator of an error (e.g. HTTP server, SCP or SEPP) should include a Server header in the HTTP error response with the following information:

– the type of the NF or network entity generating the error, set to the NFType value as defined in clause 6.1.6.3.3 of 3GPP TS 29.510 [8], e.g. "SCP", "SEPP", "SMF";

– the identity of the NF or network entity generating the error, set to the FQDN of the SCP or SEPP, or to the NF Instance ID of the HTTP server.

NOTE: The information carried in the Server header can also be useful for trouble-shooting.

EXAMPLE 1: Error generated by an SCP: Server: SCP-scp1.operator.com

EXAMPLE 2: Error generated by a SEPP: Server: SEPP-sepp1.operator.com

EXAMPLE 3: Error generated by an SMF: Server: SMF-54804518-4191-46b3-955c-ac631f953ed8

The presence of a Server header set to the next hop SCP or SEPP or to the HTTP server in an HTTP error response shall be an indication for the HTTP client that the next hop SCP or SEPP or the HTTP server is the originator of the error.

If neither the target NF nor alternative NFs that the SCP tries to (re)select based on the Routing Binding Indication or Discovery headers are reachable, the SCP shall return a HTTP 504 Gateway Timeout response including the "problemDetails" with the "cause" attribute set to "TARGET_NF_NOT_REACHABLE" and the Server header which is set to the FQDN of the SCP.

If the cSEPP receives the HTTP request from the NF with "encBlockIndex" included as specified in clause 5.9.3.2 of 3GPP TS 33.501 [17], the cSEPP shall return a HTTP 400 Bad Request response including the "problemDetails" with the "cause" attribute set to "MANDATORY_IE_INCORRECT" or "OPTIONAL_IE_INCORRECT" and the "invalidParams" attribute indicates the incorrect IE. The Server header which is set to the FQDN of the cSEPP shall also be returned.

If the SCP cannot fulfill a service request due to NRF related errors, the SCP shall originate an error towards the HTTP client as follows:

– If the NRF is not reachable, the SCP shall reject the request with a 504 Gateway Timeout including the "problemDetails" with the "cause" attribute set to "NRF_NOT_REACHABLE";

– If the NRF rejected an NF discovery request with a 5xx or 429 response, the SCP shall reject the request with a 502 Bad Gateway including the "problemDetails" with the "cause" attribute set to "NF_DISCOVERY_ERROR";

– If the NRF rejected an NF discovery request with a 4xx response, the SCP shall reject the request with a 4xx response including the "problemDetails" with an appropriate "cause" attribute (e.g. same response code and cause as received from the NRF).

– If the NRF returned a NF Discovery 200 OK response without any NF service producer matching the query parameters, the SCP shall reject the request with a "400 Bad Request" and the protocol error "NF_DISCOVERY_FAILURE" as specified in clause 6.10.6;

– see also clause 6.10.11.2 for SCP error handling requirements for errors due to NF service access authorization.

In either case, the SCP shall include the Server header in the error response set with its own identity (i.e. SCP FQDN) as specified in this clause.

6.10.8.3 Requirements for an SCP or SEPP relaying an HTTP error response

To enable an HTTP client to determine the originator of an HTTP error response, e.g. when an HTTP server does not include a Server header in an HTTP error response, the SCP or SEPP that forwards the HTTP error response towards the HTTP client shall include a Via header in the HTTP error response with the following information:

– the received-protocol portion of the Via header as defined in clause 5.7.1 of IETF RFC 7230 [12];

– the type of the network entity forwarding the error, set to the NFType value as defined in clause 6.1.6.3.3 of 3GPP TS 29.510 [8], i.e. "SCP" or "SEPP";

– the identity of the network entity forwarding the error, set to the FQDN of the SCP or SEPP.

NOTE: The information carried in the Via header can also be useful for trouble-shooting.

EXAMPLE 1: Error forwarded by an SCP: Via: HTTP/2.0 SCP-scp1.operator.com or Via: 2.0 SCP-scp1.operator.com

EXAMPLE 2: Error forwarded by a SEPP: Via: HTTP/2.0 SEPP-sepp1.operator.com or Via: 2.0 SEPP-sepp1.operator.com

The presence of a Via header set to the next hop SCP or SEPP in an HTTP error response shall be an indication for the HTTP client that the next hop SCP or SEPP is not the originator of the error.

6.10.9 HTTP redirection

6.10.9.1 General

An HTTP request sent using indirect communication may be redirected either to a different target NF service instance (from a same NF service set or NF set) or to a different SCP.

When an HTTP server or SCP redirects an HTTP request (i.e. service request or notification/callback request) to a different target NF service instance, the URI of the target NF service instance towards which the request is redirected shall be given by the Location header field of the 307 Temporary Redirect or 308 Permanent Redirect response. When redirecting a request to a different NF instance (e.g. in a same NF set), the NF (service) instance ID of the target NF (service) instance towards which the request is redirected should be indicated in the 3gpp-Sbi-Target-Nf-Id header of the 307 Temporary Redirect or 308 Permanent Redirect response; it may be indicated otherwise (e.g. when redirecting a request to a different NF service instance of the same NF instance and overload control is to be performed per NF service instance). The HTTP client should then send the HTTP request towards the new target NF service instance using the same or a different SCP. Based on local policies, when appropriate (e.g. HTTP request creating a resource), the SCP may send the HTTP request towards the new target NF service instance instead of forwarding the 307/308 response to the HTTP client.

An SCP may redirect an HTTP request towards a different SCP by sending a 307 Temporary Redirect or 308 Permanent Redirect response to the HTTP client including a RedirectResponse data structure (see 3GPP TS 29.571 [13]) with the cause attribute set to "SCP_REDIRECTION" and with the targetSCP attribute indicating the apiRoot of the SCP towards which the request is redirected. In this scenario, the 307 Temporary Redirect or 308 Permanent Redirect response shall not include any Location header field. The HTTP client should then send the HTTP request towards the target NF service instance using the SCP indicated indicated in the response. An HTTP client shall ignore the information received in the Location header field if it receives a 307 Temporary Redirect or 308 Permanent Redirect response with the cause attribute set to "SCP_REDIRECTION and including a Location header field ".

NOTE 1: The SCP can alternatively forward the request message to another SCP when there is a failure between the SCP and the target NF, and if the SCP knows that another SCP can reach the target NF and the 3gpp-Sbi-Max-Rsp-Time included the request message has not expired.

A SEPP may redirect an HTTP request towards a different SEPP by sending a 307 Temporary Redirect or 308 Permanent Redirect response to the HTTP client including a RedirectResponse data structure (see 3GPP TS 29.571 [13]) with the cause attribute set to "SEPP_REDIRECTION" and with the targetSEPP attribute indicating the apiRoot of the SEPP towards which the request is redirected. In this scenario, the 307 Temporary Redirect or 308 Permanent Redirect response shall not include any Location header field. The HTTP client should then send the HTTP request towards the target NF service instance using the SEPP indicated in the response. An HTTP client shall ignore the information received in the Location header field if it receives a 307 Temporary Redirect or 308 Permanent Redirect response with the cause attribute set to "SEPP_REDIRECTION" and including a Location header field.

5GC NFs that support indirect communications, SCPs and SEPPs shall support receiving a 307 Temporary Redirect or 308 Permanent Redirect response not including a Location header field, as described above.

NOTE 2: 5GC NF APIs technical specifications indicate that a Location header field is included in 307 Temporary Redirect or 308 Permanent Redirect response with the cause attribute set to "SCP_REDIRECTION" or "SEPP_REDIRECTION". However, the use of this information can result to misbehaviours and is not needed for the HTTP client during a redirection to an SCP or SEPP.

6.10.10 Detection and handling of loop path when relaying message with indirect communication

6.10.10.1 General

For indirect communications, request messages may be forwarded through multiple SCPs. In case of misconfiguration or error processing on intermediate SCPs, request messages may be relayed via unexpected paths or trapped in loops.

The following two optional solutions may be used to enable the SCPs to detect and handle dead looping when relaying request messages in the network with indirect communication.

6.10.10.2 Message Forwarding Depth Control

If Message Forwarding Depth Control is enabled, an HTTP client, or an SCP if the 3gpp-Sbi-Max-Forward-Hops header is not received in an incoming request, shall include in the request the 3gpp-Sbi-Max-Forward-Hops header with the node type "scp" indicating the maximum number of allowed intermediate SCPs to relay the message, before reaching the target HTTP server.

When forwarding a request that includes the 3gpp-Sbi-Max-Forward-Hops header with node type "scp" to a next hop SCP, the SCP shall check whether the value of the header is zero or not, then

– if the value of 3gpp-Sbi-Max-Forward-Hops header with node type "scp" is zero, the SCP shall reject the request with the HTTP status code "502 Bad Gateway" and the protocol error "MAX_SCP_HOPS_REACHED";

– otherwise, the SCP shall decrement the value of the 3gpp-Sbi-Max-Forward-Hops header with node type "scp" by 1 before forwarding the request.

6.10.10.3 Loop Detection with Via header

The Via header shall be inserted by HTTP proxies, SCPs and SEPPs when relaying an HTTP message (see clause 5.2.2.2).

Upon receiving a request message, if Loop Detection through Via header is enabled, the SCP shall check the presence of itself, i.e. whether an "SCP-<SCP FQDN>" with its own FQDN is included in the Via headers received. If present, the SCP shall reject the request with the HTTP status code "400 Bad Request" and the protocol error "MSG_LOOP_DETECTED".

NOTE: If topology hiding is applied within the network, entities in Via header may be replaced at domain borders.

6.10.11 Authorization of NF service access

6.10.11.1 General

Service access authorization for indirect communication shall be supported as specified in clause 13.4.1.3 of 3GPP TS 33.501 [17].

6.10.11.2 Authorization for indirect communication with delegated discovery

6.10.11.2.1 General

When the NF service consumer is configured to use delegated service discovery, requirements in clause 13.4.1.3.2 of 3GPP TS 33.501 [17] shall apply with the following additions.

If the NF service consumer received an access token in a previous service response that is valid for the new service request, the NF service consumer should include the access token in the Authorization header in the service request. An access token received in a previous service response is valid for the new service request if:

– it has a matching scope, or it has a matching service-level scope only (i.e. the new service request also requires a resource/operation-level scope that is not present in the scope of the access token received in the previous service response);

– it has a matching audience (i.e. matching producer’s NF type or NF instance ID);

– it has a matching producer’s NF set ID, S-NSSAI, NSI and PLMN ID, if the access token contains a producer NF set ID, S-NSSAI, NSI and PLMN ID respectively; and

– the access token has not expired.

NOTE 1: If the NF service consumer has multiple cached access tokens that are valid for a service request, it is left for implementation how to select the access token to include in the request. Access tokens with a matching scope, if any, are to be used in preference to access tokens with a matching service-level scope only.

NOTE 2: Including an access token that has a matching service-level scope only but not a matching resource/operation-level scope enables the reuse of the access token when the NF service producer is not configured to require the resource/operation-level scope.

If the NF service consumer does not include an access token in the service request, or if it does but the access token has a matching service-level scope only but not a matching resource/operation-level scope, or if does but the access token is NF instance specific and reselection of a different producer instance may apply at the SCP (e.g. a routing binding header or a discovery header provides the producer’s NF set ID), the NF service consumer shall include in the service request:

– the necessary NF service discovery factors to be used by the SCP for the Service access authorization procedures, as specified in clause 6.10.3.2; and

– the 3gpp-Sbi-Access-Scope header indicating the access scope of the service request for access authorization, as defined for the specific resource/operation in the corresponding API (see clause 5.2.3.2.16).

The NF service consumer may also include its Client Credentials Assertion as specified in clause 6.7.5.

The SCP should use the access scope information received in the 3gpp-Sbi-Access-Scope header to determine the access scope required for access authorization for an incoming service request. The SCP may also use the scopes required by the NF service producer (as registered in its NF profile) for this determination and, if a new access token is required, request an access token to the NRF for a list of scopes that is the intersection of the scopes indicated in the 3gpp-Sbi-Access-Scope header and the scopes expected by the NF Service producer.

If the NF service consumer has included an access token in the service request without including the 3gpp-Sbi-Access-Scope header, or if the SCP has a cached granted access token that matches the service request, the SCP should reuse the available access token. If the NF service consumer has included an access token in the service request and the 3gpp-Sbi-Access-Scope header, the 3gpp-Sbi-Access-Scope header contains multiple scopes, and the access token has a matching scope only for a subset of the scopes present in the 3gpp-Sbi-Access-Scope header, the SCP should consider that the access token has a valid scope for the service request if the NF service producer does not require any scope not granted in the Access Token (as determined from its NF profile); otherwise, the SCP shall request a new access token for the service request.

NOTE 3: This allows the SCP to consider that an access token has a valid scope if the 3gpp-Sbi-Access-Scope header contains a service-level scope and a resource/operation-level scope, the access token has a scope matching only the service-level scope, and the NF service producer is not configured to require the resource/operation-specific scope.

When the NRF receives a request to obtain an access token for a list of scopes, but the NF service producer’s profile does not allow to grant a token for all the requested scopes, the NRF should grant an access token but restricted to the allowed scope, unless the request cannot be authorized for other reasons.

NOTE 4: This allows the NRF to grant an access token for a service-level scope, in response to an access token request for a list of scopes including a service-level scope and a resource/operation-level scope, when the NF service producer’s profile is not configured to require the resource/operation-level scope.

When the SCP requests an access token for a service request, the SCP may include the access token it has obtained from the NRF in the service response it forwards to the NF service consumer, by including the 3gpp-Sbi-Access-Token header, for possible re-use in subsequent service requests by the NF service consumer. The NF service consumer should store the access token received in a service response and use it in subsequent service requests as defined above.

6.10.11.2.2 Error handling when the SCP fails to obtain an access token

If the SCP cannot issue an Access Token Request towards the NRF due to missing information in the incoming service request, e.g. if the 3gpp-Sbi-Discovery-requester-nf-instance header is missing, the SCP shall reject the service request with a 400 Bad Request response including a ProblemDetails IE with:

– the cause attribute set to MISSING_ACCESS_TOKEN_INFO;

– the invalidParams attribute indicating the missing parameters (e.g. missing discovery header).

If the SCP can issue an Access Token Request towards the NRF, but the NRF rejects the request (e.g. because the validation of the Client Credentials Assertion fails at the NRF or because the NF service consumer is not authorized to access the requested service), the SCP shall reject the service request towards the NF service consumer with a 403 Forbidden response including a ProblemDetails IE with the cause attribute set to ACCESS_TOKEN_DENIED. The ProblemDetails IE should also contain:

– the accessTokenError attribute set to the accessTokenErr payload received from the NRF;

and it may contain:

– the accessTokenRequest attribute set to the Access Token Request payload sent to the NRF;

– the nrfId attribute set to the FQDN of the NRF that rejected the access token request.

In either case, the SCP shall include the Server header in the error response set with its own identity (i.e. SCP FQDN) as specified in clause 6.10.8.2.

6.10.11.2.3 Error handling when SCP receives a "401 Unauthorized" response or a "403 Forbidden" response with a "WWW-Authenticate" header

If the NF service producer rejects the service request with a "401 Unauthorized" response or with a "403 Forbidden" response with a "WWW-Authenticate" header containing "Bearer" as the scheme for challenge:

– if the SCP had included an access token received from the NF service consumer in the service request to the NF service producer, the SCP shall forward the response to the NF service consumer; the NF service consumer shall then delete the corresponding access token and may repeat the request without an access token or with a different access token;

– if the SCP had included an access token it had cached or obtained from the NRF, the SCP shall not repeat the request with the access token that was used; the SCP may repeat the request with a new access token; otherwise, or if the repeated request fails, the SCP shall forward the response to the NF service consumer;

– if the SCP had not included an access token in the service request to the NF service producer, the SCP should request an access token to the NRF and repeat the request; otherwise, the SCP shall forward the response to the NF service consumer.

6.10.11.3 Authorization for indirect communication without delegated discovery

Requirements in clause 13.4.1.3.1 of 3GPP TS 33.501 [17] shall apply with the following additions.

If selection or reselection of a producer’s NF instance may apply at the SCP (e.g. initial service request containing the target NF Set ID, or service request containing a routing binding header or a discovery header with the producer’s NF set ID), the NF service consumer shall include in the service request an access token that is valid for any producer’s NF instance that the SCP may select or reselect, i.e. an access token that is not specific to a particular producer’s NF instance. This shall be an access token valid for the target NF type and producer’s NF set.