11 Supported Headers

The following tables list the headers supported by SCP:

Table 11-1 Supported 3GPP Custom Headers

Custom Header Name Description
3gpp-Sbi-Message-Priority This header is used to specify the HTTP/2 message priority for 3GPP service based interfaces.
3gpp-Sbi-Callback The header is used to identify a particular type of callback, for example, notification.
3gpp-Sbi-Target-apiRoot The header contains the apiRoot of the target URI in a message request sent to an SCP instance when using indirect communication such as Model C and Model D. SCP uses this header to indicate the apiRoot of the target URI if a new HTTP server is selected or reselected and if there is no location header in the message response.

SCP adds this header to message responses when:

  • 3gpp-Sbi-Discovery-target-nf-set-id is present in the message request and producer selection is done by SCP.
  • 3gpp-Sbi-Target-apiRoot and 3GPP-Sbi-Discovery-target-NfSetid are present in the message request and SCP has done producer reselection.
  • 3gpp-Sbi-Target-apiRoot and 3gpp-sbi-routing-binding are present in the message request and SCP has done producer reselection.
3gpp-Sbi-Routing-Binding This header is used in a service request to signal binding information to direct the service request to an HTTP server that has the targeted NF service resource context.
3gpp-Sbi-Binding This header is used to signal binding information related to an NF service resource to a future consumer, such as an HTTP client, of that resource.
3gpp-Sbi-Discovery-* This header, which begins with the prefix 3gpp-Sbi-Discovery, is used in indirect communication mode for discovery and selection of a suitable producer by the SCP. Such headers can be included in any SBI message and include information allowing an SCP to find a suitable producer based on the consumer's included delegated discovery parameters.
3gpp-Sbi-Oci This header is utilized by overloaded SCPs, SEPPs, consumer NFs, and producer NFs to transmit Overload Control Information (OCI) within message requests and responses to peers. The OCI includes attributes such as Overload Timestamp, Overload-Reduction-Metric, Period-of-Validity, and Scope within the 3gpp-Sbi-Oci header.
3gpp-Sbi-Producer-Id This header contains Instance ID of the producer NF. In case of producer selection or reselection (i.e. alternate routing) in indirect communication modes such as Model C or Model D, this header is used in a message response from SCP to the consumer NF to identify the producer NF.
SCP adds this header to message responses when:
  • 3gpp-Sbi-Discovery-target-nf-set-id is present in the message request and producer selection is done by SCP.
  • 3gpp-Sbi-Target-apiRoot and 3GPP-Sbi-Discovery-target-NfSetid are present in the message request and SCP has done producer reselection.
  • 3gpp-Sbi-Target-apiRoot and 3gpp-sbi-routing-binding are present in the message request and SCP has done producer reselection.
3gpp-Sbi-Lci This header is used by a producer NF to send Load Control Information (LCI) to the consumer NF.
3gpp-Sbi-Client-Credentials This header is used by a consumer NF to send a Client Credential Assertion (CCA) to the NRF or to the producer NF.
3gpp-Sbi-Target-Nf-Id This header is used in a 307 Temporary Redirect or 308 Permanent Redirect response to identify the target NF service instance towards which the request is redirected.
3gpp-Sbi-Access-Scope This header is used in a service request for indirect communication to indicate the access scope of the service request for NF service access authorization.
3gpp-Sbi-Access-Token This header is used in a service response forwarded by the SCP to an NF service consumer to provide an access token for possible reuse in subsequent service requests.
3gpp-Sbi-Correlation-Info This header may be used to contain correlation information, for example, UE identity, that may be used by an operator in various offline network management, performance analysis and troubleshooting tools/applications to identify messages (requests, responses, subscriptions, notifications) related to a particular subscriber.

SCP also supports the HTTP standard headers. For more information, see 3GPP TS 29.500 V16.10.0, Table 5.2.2.2-1.

Table 11-2 Standard Headers Supported by SCP

Header Name Description
Mandatory to Support HTTP Request Standard Headers
Accept This header specifies acceptable response media types.

SCP forwards it as it is.

Accept-Encoding This header indicates the type of response content encoding, for example, GZIP, is acceptable in the response.

GZIP compresses data in a message body. SCP decompresses the GZIP data when required, and then compresses it while forwarding it.

Content-Length This header provides the anticipated size, as a decimal number of octets, for a potential content.
Content-Type This header indicates the media type of the associated representation.
User-Agent This header identifies the NF type of the HTTP/2 client.
Cache-Control This header is used in some HTTP/2 requests to provide the HTTP cache-control directives that the client can accept from the server.

SCP forwards it as it is.

If-Modified-Since This header is used in a conditional GET request to re-validate server. This is used in conjunction with the LastModified server response header to retrieve content if the content has been modified from the cached version.

SCP forwards it as it is.

If-None-Match This header is used in a conditional GET request. This is used in conjunction with the ETag server response header to retrieve content if the tag value of the resource on the server differs from the tag value in the If-None-Match header.

SCP forwards it as it is.

If-Match This header is used in a conditional POST, PUT, DELETE, or PATCH request. This is used in conjunction with the ETag server response header to update or remove content if the tag value of the resource on the server matches the tag value in the If-Match header.

SCP forwards it as it is.

Via This header is inserted by HTTP proxies.

SCP adds its own information in this header while forwarding.

Authorization This header is used if OAuth 2.0 based access authorization with "Client Credentials" grant type is used as specified in subclause 13.4.1 of 3GPP TS 33.501 [17], clause 7 of IETF RFC 6749 [22] and IETF RFC 6750 [23].
Mandatory to Support HTTP Response Standard Headers
Content-Length This header provides the anticipated size, as a decimal number of octets, for a potential content.
Content-Type This header indicates the media type of the associated representation.
Retry-After This header indicates the waiting period for the user agent before making a follow-up request.
Content-Encoding This header indicates to the HTTP/2 client the content encodings, for example, gzip, applied to the resource representation beyond those inherent in the media type.
Location This header is used in some responses to refer to a specific resource pertaining to the response.

It is updated by SCP to absolute URI if the location header in response has relative URI.

Cache-Control This header is used in some responses such as NRF responses to queries, to provide HTTP response cache control directives. The cache directives "no-cache", "no-store", "maxage", and "must-revalidate" values are supported.

It is not supported by SCP and is forwarded as it is.

Age This header is inserted by HTTP proxies when returning a cached response. This header conveys the sender's estimate of the amount of time since the response was generated or successfully validated at the origin server.

It is not supported by SCP.

Last-Modified This header is sent to allow for conditional GET with the IfModified-Since header.

SCP forwards it as it is.

ETag This header is sent to allow for conditional GET with the IfIf-None-Match header or a conditional POST, PUT, PATCH, or DELETE with the If-Match header.

SCP forwards it as it is.

Via This header is inserted by HTTP proxies.
Allow This header is used to indicate methods supported by the target resource.

SCP forwards it as it is.

WWW-Authenticate This header is included when a producer NF rejects a request with a "401 Unauthorized" status code, for example, when a request is sent without an OAuth 2.0 access token or with an invalid OAuth 2.0 access token.