Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  16.4.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3   5.2.4…   6…   6.4…   6.5…   6.6…   6.7…   6.10…   6.11…   A…

 

6.10  Support of Indirect Communication |R16|
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 TS 23.501. 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.
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 TS 33.501. 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 TS 33.501.
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 TS 23.501 describe how to route messages through SCPs.
Up
6.10.2  Routing Mechanisms with SCP Known to the NFWord‑p. 63
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.
Up
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.
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 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 of the next hop SCP.
  • 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.
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 of the target NF service instance.
  • 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.
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 Producer, without any "3gpp-sbi-target-apiRoot" header.
Up
6.10.2.5  3gpp-Sbi-Target-apiRoot header settingWord‑p. 65
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]).
When forwarding the request to the HTTP server, the SCP shall set the pseudo-headers as specified in clause 6.10.2.4.
Up
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
Up
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";
  • ":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.
Up
6.10.3  NF Discovery and Selection for indirect communication with Delegated DiscoveryWord‑p. 66
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 TS 23.501).
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 NF service discovery procedures 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.
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 from the NF service consumer a service request containing "3gpp-Sbi-Discovery-*" request headers, and the SCP is to invoke NF service discovery towards the NRF to fulfil this task, then it shall take into account all the NF service discovery factors contained in the "3gpp-Sbi-Discovery-*" request headers. 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.
Up
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).
The following procedures may be used to support notifications corresponding to default notification subscriptions:
  • an NF producer may perform a discovery request towards the NRF (possibly through an SCP) to discover default notification suscriptions of an NF consumer, and if so, send notifications to the corresponding notification endpoints, using routing mechanisms specified in clause 6.1; or
  • an NF producer may be configured with the types of notifications corresponding to default notification subscriptions it needs to generate, and send such notifications using delegated discovery, i.e with an SCP discovering and selecting an NF service consumer with a corresponding default notification subscription. To enable the latter, 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;
    • the 3gpp-Sbi-Discovery-notification-type header set to the type of notification being set;
    • the 3gpp-Sbi-Discovery-target-nf-type header indicating the type of the consumer NF;
    • optionally, additional NF service discovery factors header to be used by the SCP to discover and select the consumer NF.
Up
6.10.3.4  Returning the NF Service Producer ID to the NF Service ConsumerWord‑p. 67
When using delegated discovery, if and only if the NF Service Producer does not return a Binding Indication in a service response creating a resource, the SCP that (re)selected the target NF service instance shall include the 3gpp-Sbi-Producer-Id header in the HTTP response it forwards towards the NF Service Consumer, containing the NF Instance ID of the NF Service Producer selected by the SCP (see clause 6.10.3.2).
Up
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 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 received in the corresponding "3gpp-Sbi-Discovery-*" request header(s), if available.
The SCP shall then route the request to the selected NF service instance of the target NF service producer.
Up
6.10.6  Feature negotiation for Indirect Communication with Delegated DiscoveryWord‑p. 68
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.
Up
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 notify or callback service operation (see Annex B) and the API major version if higher than 1.
The SCP may derive from the presence of this header that a service request is a notification or callback request.
Up
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.
Up
6.10.8.2  Requirements for the originator of an HTTP error responseWord‑p. 69
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 TS 29.510, 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.
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.
Up
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 type of the network entity forwarding the error, set to the NFType value as defined in clause 6.1.6.3.3 of TS 29.510, i.e. "SCP" or "SEPP";
  • the identity of the network entity forwarding the error, set to the FQDN of the SCP or SEPP.
EXAMPLE 1:
Error forwarded by an SCP: Via: SCP-scp1.operator.com
EXAMPLE 2:
Error forwarded by a SEPP: Via: 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.
Up
6.10.9  HTTP redirection
6.10.9.1  General
An HTTP request sent using indirect communication may be redirected to a different target NF service instance (from a same NF service set or NF set) and/or a different SCP.
When an HTTP server or SCP redirects an HTTP 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. 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 ProblemDetails data structure 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. The HTTP client should then send the HTTP request towards the target NF service instance using the SCP indicated in the response.
Up

Up   Top   ToC