Content for  TS 29.500  Word version:  19.0.0

The 3GPP NF Services may support the HTTP custom headers specified in Table 5.2.3.3-1 below. A description of each custom header and the normative requirements on when to include them are also provided in Table 5.2.3.3-1.

The header contains the date and time (with a millisecond granularity) at which an HTTP request or response is originated. The encoding of the header follows the ABNF as defined in RFC 9110.

day-name, date1, time-of-day shall comply with the definition in Section 5.6.7 of RFC 9110. When a 3gpp-Sbi-Sender-Timestamp header field is generated, the sender should generate its field value as the best available approximation of the date and time of message generation.

The header indicates the duration, expressed in milliseconds since the request was originated, during which the HTTP client waits for a response. See clause 6.11.2. The encoding of the header follows the ABNF as defined in RFC 9110.

The header contains correlation information e.g. UE identifier related to the HTTP request or response. The encoding of the header follows the ABNF as defined in RFC 9110.

The format of cvalue shall comply with the data type description provided in Table 5.2.3.3.4-1.

The header indicates a primary or a secondary CHF Instance ID. See clause 6.10.3.5. The encoding of the header follows the ABNF as defined in RFC 9110.

Parameter "nfinst" shall indicate an NF Instance ID, as defined in clause 5.2.2.2.2 in TS 29.510; the ABNF is defined in clause 5.2.3.2.8.

The header indicates the content encodings supported when receiving notifications related to the subscriptions data conveyed by the HTTP request in which the header is included. This header shall be compliant with Accept-Encoding header defined in Section 12.5.3 of RFC 9110.

This header contains a comma-delimited list of NF service consumer information from an HTTP client (as NF service consumer). The encoding of the header follows the ABNF as defined in RFC 9110.

"service" (Mandatory parameter): Supported Service parameter indicates the name of a service, as defined in TS 29.510, which is supported by the sender as NF service consumer. "apiversion" (Mandatory parameter): Supported Versions parameter indicates the major version(s) of the service API that are supported by the sender as NF service consumer. "supportedfeatures" (Optional parameter): Supported Features parameter carries a string containing a bitmask in hexadecimal representation, as specified for SupportedFeatures data type in TS 29.571, to indicate the feature(s) of the service API that are supported by the sender as NF service consumer. "acceptencoding" (Optional parameter): Accept Encoding carries a string indicating the accepted content encodings supported by the sender as NF service consumer, when receiving notifications defined by the service. In the ABNF definition, "codings" and "weight" are defined in Section 12.5.3 of RFC 9110 and Section 12.4.2 of RFC 9110. "intraPlmnCallbackRoot", "interPlmnCallbackRoot" (Optional parameters): intra plmn callback root and inter plmn callback root supported by the sender as NF service consumer, for the indicated service. "callback-uri-prefix" (Optional parameter): The NF service consumer may include this parameter when providing a Callback URI when the authority part of the Callback URI is shared by several NF service consumer instances. The NF service consumer may also include this header when providing a Callback URI including a prefix, for use during NF service consumer reselection, when binding procedures are not supported. When present, the "callback-uri-prefix" shall be a path-absolute as specified RFC 3986 (i.e. the first path segment(s) after the authority) which is part of the Callback URI provided by a NF service consumer in the corresponding service request message sent to a NF service producer. The authority and "callback-uri-prefix" in the Callback URI shall uniquely identify a consumer service instance. See clause 6.12.1 for the usage of this parameter "intermediate-nf" (Optional parameter): The intermediate NF indication parameter is a boolean set to true indicating that the header is provided by an intermediate NF as the NF service consumer.

The header contains a list of additional information related to an HTTP response. It may be included e.g. in a 4xx or 5xx response sent:

• by an SCP to indicate whether it attempted to retransmit the request to alternative HTTP server instances; or
• by an alternative HTTP server instance to indicate whether the corresponding resource or context has been transferred to the alternative HTTP server instance, or by an HTTP server instance to indicate that the failed request shall not be retried.

The encoding of the header follows the ABNF as defined in RFC 9110.

The following parameters are defined:

• "request-retransmitted": this parameter indicates, in an error response, whether the SCP attempted to (re)transmit the request to alternative HTTP server instances. When present, it shall be set to "true" if so, and to "false" otherwise. See clause 6.10.8.1.
• "nfinst", "nfset", "nfservinst", "nfserviceset": one or more of these parameters may be present in an error response, when the request-retransmitted is set to "true". When present, it shall indicate the NF Instances, NF Sets, NF Service Instances or NF Service Sets that were attempted to serve the request. See clause 6.10.8.1. The value of the nfinst, nfset, nfservinst and nfserviceset parameters shall be encoded as defined for the corresponding parameters in clause 5.2.3.2.5.
• "context-transferred": this parameter indicates, in an error response, whether the corresponding resource or context has been transferred to the HTTP server instance sending the response. When present, it shall be set to "true" if the request has been transferred, i.e. the subsequent requests towards the resource or context shall be sent to the HTTP server instance sending the response, and to "false" otherwise.
• "no-retry": this parameter indicates, in an error response, whether the failed request can be retried at other alternative HTTP server instance or not. When present, it shall be set to "true" if the failed request shall not be retried at other alternative NF instances, and to "false" otherwise.

The header contains a comma-delimited list of additional (re)selection information for an HTTP request message. It may be included by a NF service consumer or a NF service producer in a HTTP request message for indirect communication. If the header is received by the SCP and the SCP supports the header, the SCP shall:

• avoid forwarding the request message to the target NF as indicated in the 3gpp-Sbi-Target-apiRoot (if present in the request) or the request URI (otherwise) if reselection is set "true", i.e., the SCP shall perform a reselection; and
• use the selection-criteria included in this header together with 3gpp-Sbi-Routing-Binding or 3gpp-Sbi-Discovery-* headers whichever available, when the SCP performs the (re)selection of the target NF.

The encoding of the header follows the ABNF as defined in RFC 9110.

• reselection: it is a boolean and set to "false" by default. When it is set to "true", it indicates that the SCP shall perform a reselection, i.e., the SCP shall not forward the request message towards the target as indicated in the target uri or in the 3gpp-Sbi-Target-ApiRoot. When this parameter occurs multiple times in the comma-delimited list, all parameters shall have the same value.
• not-select-nfservinst (the NF service instance(s) that shall not be selected): indicates an NF Service Instance ID. This parameter shall be present if the sender of the request message knows that the target NF or other potential target NF service instance that shall not be selected, e.g., when the target NF service instance is overloaded, or some NF service instances are out of service. (see also clause 6.4.3.4.5.2.1) When this parameter is present, one of not-select-nfserviceset or not-select-nfinst shall be present to enable the SCP to identify the nfservinst.
• not-select-nfserviceset (the NF service instance pertaining to a NF service set in a NF instance that shall not be selected): indicates an NF Service Set ID as defined in clause 28.13 of TS 23.003. This parameter shall be present if the sender of the request message knows that all NF service instances in the NF service set shall not be selected, e.g., when target NF service instance has indicated its overload and the overload scope is NF service set level, in this case, not-select-nfservinst shall not be present. (see also clause 6.4.3.4.5.2.1)
• not-select-nfinst (the NF instance(s) that shall not be selected): indicates an NF Instance ID, as defined in clause 5.2.2.2.2 of TS 29.510. This parameter shall be present if the sender of the request message knows the target NF instance or other potential target NF instance that shall not be selected, e.g., when the target NF instance is overloaded, or other NF instance(s) is out of service, in this case, not-select-nfservinst shall not be present. (see also clause 6.4.3.4.5.2.1)
• not-select-nfset (the NF set that shall not be selected): indicates an NF Set ID, as defined in clause 28.12 in TS 23.003. This parameter may be present, e.g., during an initial resource creation with Delegated Discovery (Indirect Communication Mode D), the NF service consumer knows certain NF set shall not be selected.

The header contains the intended purpose for inter-PLMN signaling. See clauses 6.14. The encoding of the header follows the ABNF as defined in RFC 9110.

• N32Purpose: The parameter for N32Purpose indicates the intended purpose of inter-PLMN signaling, and values specified in clause 6.1.5.3.9 of TS 29.573 are used.

The header contains a list of additional information related to a HTTP request which may be included by a NF or a SCP, to indicate e.g.:

• whether the HTTP request message is involving a reselection of an alternative NF;
• whether the HTTP request message is a retransmission of the message, i.e. the request message has been sent but being rejected with a temporary failure or timeout;

When the header is included by a NF acting as a HTTP client, an idempotency-key may be included for a non-idempotent request to enable the receiver to detect possible duplicated request messages as specified in clause 5.2.8. The receiving NF may use the header, e.g. to determine whether to accept the request. The encoding of the header follows the ABNF as defined in RFC 9110.

The following parameters are defined:

• "reason": indicates the reason for which the NF resends or redirects the HTTP request message. This may take one of the following values:
  • "unreachable": indicates that the HTTP request is redirected to an alternative NF due to the request URI (e.g. the resource URI or Notification/callback URI) is not reachable;
  • "overloaded": indicates that the HTTP request is redirected to an alternative NF as result of overload control enforcement, by doing redirection towards an alternative NF (see clause 6.4.3.5.1);
  • "3xx-redirect": indicates that the HTTP request is redirected to an alternative NF as result of receiving a 3xx status code.
  • "temporary-rejection-cause": indicates the HTTP request is retransmitted towards the same or alternative NF due to a temporary rejection.
• "receivedrejectioncause": indicates a temporary rejection application cause received from the NF or SCP (for last attempt) as defined in clause 5.2.7.2, when the "retrans" parameter is set to "true" and the reason is set to "temporary-rejection-cause". The cause data type is specified in clause 5.2.4.1 of TS 29.571.
• "retrans": it is a boolean and shall be set to "true" to indicate that the request message has been retransmitted e.g. when the request didn't get any response or get a temporary failure cause, otherwise the "retrans" shall not be present.
• "redirect": it is a boolean and shall be set to "true" to indicate that the request message has been redirected to an alternative NF.
• "nfinst": indicates the NF Instance ID of the NF instance towards which the request was sent previously, as defined in TS 29.510; the ABNF is defined in clause 5.2.3.2.8. This parameter may be present if the "reason" parameter is present to indicate the NF instance which was not reachable, or which redirected or rejected the request.
• "nfservinst": indicates the NF Service Instance ID of the NF service instance towards which the request was sent previously, as defined in TS 29.510; the ABNF is defined in clause 5.2.3.2.8. This parameter may be present if the "reason" parameter is present to indicate the NF service instance which was not reachable, or which redirected or rejected the request.
• "redirection-cause": indicates the redirection cause received in the 3xx redirect, when the "reason" parameter is set to "3xx-redirect". The redirection cause is defined as the cause attribute received in the RedirectResponse data type as specified in clause 5.2.4.21 of TS 29.571.
• "idempotency-key": it is a string and may be encoded using Universally Unique Identifier (UUID), as described in RFC 4122, to uniquely identify a request message (to be received) in the target NF. See clause 5.2.8.
• "callback-uri-prefix": path-absolute as specified RFC 3986 (i.e. the first path segment(s) after the authority) which is part of the Callback URI. The ABNF is defined in clause 5.2.3.3.7.

The header may be included in a HTTP request message for indirect communication to indicate that the request shall only be sent once and shall not be retried. The encoding of the header follows the ABNF as defined in RFC 9110.

The following value is defined:

• "no-retries" indicates that the request shall only be sent once and shall not be retried to the same nor alternative endpoints of the same target NF service instance nor towards another target NF service instance once the request has been forwarded once.

The header indicates other access scopes that are desired to be obtained for the access token, in addition to the scopes indicated in the 3gpp-Sbi-Access-Scope, that are not required for the service request itself but that may be required for further service requests. It enables the SCP to request access tokens that can be reused in further service requests, for NF service access authorization as defined in clauses 6.7.3 and 6.10.11. The encoding of the header follows the ABNF as defined in RFC 9110.

The following value is defined: Scope-token shall consist of a list of space-delimited, case-sensitive strings, containing one or more NF service name(s) of the NF service producer and/or additional resource/operation-level scope(s) for these API(s) that are not already contained in the 3gpp-Sbi-Access-Scope header. The ABNF is defined in clause 5.2.3.2.16. NQCHAR is defined in Appendix A of RFC 6749.