Content for  TS 29.500  Word version:  19.0.0

The 3GPP NF Services shall support the HTTP custom headers specified in Table 5.2.3.2.1-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.2.1-1.

The header contains the HTTP/2 message priority value from 0 to 31, as defined in clause 6.8.4. The encoding of the header follows the ABNF as defined in RFC 9110.

A message with 3gpp-Sbi-Message-Priority "0" has the highest priority.

The header contains the type of notification. The value for the notification type is a string used identifying a particular type of callback (e.g. a notification, typically the name of the notify service operation). The encoding of the header follows the ABNF as defined in RFC 9110.

The list of valid values for the cbtype is specified in Annex B. The apiversion parameter should be present if the major version is higher than 1.

The header contains the apiRoot of the target URI (see clause 4.4 of TS 29.501) in a request sent to an SCP when using Indirect Communication. This header contains the apiRoot of the selected or changed target URI in a response sent to an HTTP client, when the SCP selected or reselected a new HTTP server to route the request (or when the SCP sends the request to an alternative HTTP Server upon receiving a 3xx redirect message, see clause 6.10.9.1) and no Location HTTP header is included in the HTTP response. It may also be used in a request sent to a SEPP and in a request between SEPPs (see clause 6.1.4.3.2). The encoding of the header follows the ABNF as defined in RFC 9110.

This header contains a Routing Binding Indication used to direct a service request to an HTTP server which has the targeted NF service resource context (see clause 6.12). The encoding of the header follows the ABNF as defined in RFC 9110.

The following parameters are defined:

• bl (binding level): the value of this parameter (blvalue) indicates a preferred binding to a binding entity, i.e. either to an NF Instance, an NF set, an NF Service Instance or an NF Service Set. If the binding level is set to an NF Service Instance (nfservice-instance), then either NF Service Set ID or NF Instance ID shall also be present to unambiguously identify the NF Service Instance.
• nfinst (NF instance): indicates an NF Instance ID, as defined in clause 5.2.2.2.2 in TS 29.510. This parameter shall be present if the binding level is set to "nf-instance", or if the binding level is set to "nfservice-instance" and the nfserviceset parameter is not included.
• nfset (NF set): indicates an NF Set ID, as defined in clause 28.12 in TS 23.003. This parameter shall be present if the binding level is set to "nf-set". It may be present otherwise (see clause 6.12.1).
• nfservinst (NF service instance): indicates an NF Service Instance ID. This parameter shall be present if the binding level is set to "nfservice-instance".
• nfserviceset (NF service set): indicates an NF Service Set ID as defined in clause 28.13 of TS 23.003. This parameter shall be present if the binding level is set to "nfservice-set". It shall also be present if the binding level is set to "nfservice-instance" and the NF service instance indicated by the nfservinst parameter is part of an NF service set (see clause 6.12.1).
• servname (service name): indicates the name of a service, as defined in TS 29.510, or a custom service that handles a notification or a callback request. It may be present in a Routing Binding Indication in a notification or a callback request.
• backupamfinst (backup NF Instance): indicates the NF Instance ID (as defined in clause 5.2.2.2.2 of TS 29.510) of the backup NF, i.e. the backup AMF as specified in TS 23.501. The backupamfinst may be present only when the binding level is nf-instance or nfservice-instance or nfservice-set. When backupamfinst is present, no binding entity corresponding to NF set shall be present. When the binding level is nf-set, backupamfinst shall not be present.
• for the definition and encoding of the backupnf see clause 5.2.3.2.6.
• for the definition and encoding of the callback-uri-prefix see clause 5.2.3.2.6. The ABNF is defined in clause 5.2.3.3.7.

See Section 5.6.2 of RFC 9110 for the "token" type definition. A token's value is a string, which contains a binding entity ID or a service name.

This header contains a comma-delimited list of Binding Indications from an HTTP server for storage and subsequent use by an HTTP client (see clause 6.12). The encoding of the header follows the ABNF as defined in RFC 9110.

The following parameters are defined:

• scope: indicates the applicability of a Binding Indication in a service request other than a notification request, or in a notification or callback response. This may take one of the following values:
  • "other-service": the binding information applies to other service(s) that the NF Service Consumer may later on provide as an NF Service Producer (see clause 6.12.3);
  • "subscription-events": the binding information applies to subscription change event notifications (see clause 6.12.4);
  • "callback": the binding information applies to notification or callback requests (see clause 6.12.4 and clause 6.12.5).
  The absence of this parameter in a Binding Indication in a service request other than a notification request, or in a notification or callback response, shall be interpreted as "callback".
  Two scope parameters may be present in a Binding Indication if the binding information applies to notification/callback requests and to other services.
• servname (service name): indicates the name of a service, as defined in TS 29.510, or a custom service, i.e.:
  • the name of the service that handles a notification or a callback request, when present in a Binding Indication for a subscription or a callback, i.e. with a scope parameter absent or set to "callback"; or
  • the name of the other service(s) for which the binding applies, when present in a Binding Indication in a service request for the other services the NF Service Consumer can provide later on as an NF Service Producer, i.e. with the scope parameter set to "other-service". More than one servname parameter may be present to represent multiple such services. The absence of this parameter in a Binding Indication with the scope parameter set to "other-service" shall be interpreted as binding information that applies to all the services that the NF Service Consumer may provide later as an NF Service Producer.
• recoverytime: indicates the recovery timestamp of the entity corresponding to the highest resiliency level supported for the resource, that is, the higher level binding entity indicated in the Binding Indication. See Table 6.3.1.0-1 of TS 23.501, and clause 6.1 of TS 23.527. The date-time type is specified in RFC 5322 and Section 5.6.7 of RFC 9110.
• nr: indicates the URI of the notification endpoint when this binding information is applicable; it applies to callback requests (see clause 6.12.4); if the notification URI does not contain a correlationID in the path (i.e. it is a common notification URI for multiple subscriptions), the correlationID shall be added as a fragment component of the URI (i.e. following the "#" character) at the end of the URI.
• for the definition and encoding of the blvalue, nfinst, backupamfinst, nfset, nfservinst and nfserviceset see clause 5.2.3.2.5.
• backupnf: indicates the backup NF service instance identifier and/or the backup NF identifier as defined in clause 5.2.2.2.2 in TS 29.510, which shall be used when preferred binding entity is not reachable if supported.
• group: it is a boolean indicating if the binding indication is for a group of resource/session contexts.
• groupid (group id): indicates the group identifier allocated by the NF (service) instance, one ore more resource/session contexts are sharing the same groupid. The groupid is optional and it may be allocated when the resource/session context is created and then be updated afterwards. The groupid is global unique and it may be encoded using the same mechnaism for the NfInstanceId as specificed in TS 29.571.
• oldgroupid (old group id): indicates the group identifier allocated by the NF (service) instance previously and to be replaced by the groupid, hence it shall only be present when to update a Binding Indication for multiple contexts. When the if the oldgroupid is present, the groupid shall also be present to indicate the new groupid allocated.
• uribase: identify the apiroot and path segments part in the resource URI or notification/callback URI which is common to multiple contexts. This parameter may only be present when to update a Binding Indication for multiple contexts and when the "group" is set to "true". When included, it indicates that all resources or notification contexts with this uribase will use the updated Binding Indication subsequently. More than one uribase may be present.
• oldnfinst: indicates the NF Instance ID of the NF instance where the group of resource/session contexts are currently served (i.e. the Binding Indication allocated previously for the group of resource/session contexts includes the information of the NF instance), as defined in clause 5.2.2.2.2 in TS 29.510. When included, it indicates that all the resource/session contexts served by this NF instance will use the updated Binding Indication subsequently.
• oldservset: indicates the NF Service Set ID of the NF Service Set where the group of resource/session contexts are currently served (i.e. the Binding Indication allocated previously for the group of resource/session contexts includes the information of the NF Service Set), as defined in clause 5.2.2.2.2 in TS 29.510. When included, it indicates that all the resource/session contexts served by this NF Service Set will use the updated Binding Indication subsequently.
• oldservinst: indicates the NF Service Instance ID of the NF service instance where the group of resource/session contexts are currently served (i.e. the Binding Indication allocated previously for the group of resource/session contexts includes the information of the NF service instance), as defined in clause 5.2.2.2.2 in TS 29.510. When included, it indicates that all the resource/session contexts served by this NF service instance will use the updated Binding Indication subsequently.
• guami (GUAMI): indicates the GUAMI of the AMF currently serving UE contexts, as defined in clause 5.3.4.1 of TS 29.571. When included, it indicates that all the UE contexts associated with the GUMAI will use the updated Binding Indication subsequently.
• no-redundancy: it is a boolean set to true indicating that the resource is exclusively bound to the NF service instance identified in the binding indication. It may be present in a binding with any scope, i.e. "other-service", "subscription-events" or "callback", or with no scope parameter. When this parameter is present, the blvalue shall be set to "nfservice-instance", the nfservinst parameter shall be present and either the nfserviceset parameter or the nfinst parameter shall be present. The nfserviceset or nfinst parameter included in the binding indication shall only be used to identify the NF service instance and shall not be considered as a binding entity for reselection. The no-redundancy parameter shall only be signaled if the receiver of this information is known to support this parameter (see clause 6.12.1). Subsequently, when sending further requests targeting a resource with no-redundancy, the HTTP client shall not include any routing binding indication in the request message (to prevent the SCP from performing any reselection).
• callback-uri-prefix: The NF service consumer may include this parameter when providing a Callback URI when the Callback URI contains a prefix. 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. This parameter is relevant when the "scope" parameter is either "subscription-events" or "callback". See clauses 6.12.4 and 6.12.5 for the usage of this parameter. The ABNF is defined in clause 5.2.3.3.7.

These headers shall be used to convey NF service discovery factors to the SCP in indirect communication models. They contain discovery parameters to be conveyed by an NF service consumer or an NF service producer to the SCP or by an SCP to the next hop SCP and they shall be used by the SCP to select or reselect a suitable NF service producer instance to create or update a (existing) resource context, or a suitable NF service consumer instance towards which to send a notification or a callback request, e.g. by performing the NF service discovery procedure with the NRF on behalf of the NF consumer in case of indirect communication with delegated discovery model. The name of each NF service discovery factors header shall be constructed by concatenating the string "3gpp-Sbi-Discovery-" with the name of the conveyed discovery parameter, i.e. "3gpp-Sbi-Discovery-<discovery parameter>". The discovery headers shall be used to include any of the discovery query parameters listed in TS 29.510, Table 6.2.3.2.3.1-1. The value of each NF service discovery header shall be encoded in the same way as the corresponding discovery parameter (i.e. with the same data type, cardinality and format). Thus, the values of these headers may be validated with the same data model as that of the corresponding discovery parameters. The discovery headers shall comply with the condition of presence of the discovery parameters defined in Table 6.2.3.2.3.1-1 of TS 29.510, e.g. discovery headers shall be included for discovery parameters defined as mandatory in this table. Table 5.2.3.2.7-1 lists examples of NF service discovery headers.

  The 3gpp-Sbi-Discovery-* header is not documented in OpenAPI specification files. It shall comply with the following OpenAPI definition:

• for parameters defined with a "content:" block and specifying the "application/json" media type in clause A.3 of TS 29.510:

• for other parameters:

3gpp-Sbi-Discovery-* headers corresponding to query parameters defined with the "style" keyword set to "form" and the "explode" keyword set to false in clause A.3 of TS 29.510 shall be formatted using the style "simple", i.e. as comma-separated values.

This header contains the NF Service Producer Instance ID (see clause 6.10.3.4). The encoding of the header follows the ABNF as defined in RFC 9110.

The following parameters are defined:

• nfinst (NF instance): indicates a NF Instance ID, as defined in TS 29.510;
• nfservinst (NF service instance): indicates a NF Service Instance ID, as defined in TS 29.510;
• nfset (NF set): indicates an NF Set ID, as defined in clause 28.12 in TS 23.003;
• nfserviceset (NF service set): indicates an NF Service Set ID as defined in clause 28.13 in TS 23.003.

The header contains a comma-delimited list of Overload Control Information (OCI). See clause 6.4.3. The encoding of the header follows the ABNF as defined in RFC 9110.

"Timestamp" (Mandatory parameter): The date-time type is specified in RFC 5322 and Section 5.6.7 of RFC 9110. It indicates the timestamp at which the overload control information was generated. "Period-of-Validity" (Mandatory parameter): Period of validity is a timer that is measured in seconds. Once the timer expires, the OCI becomes invalid. "Overload-Reduction-Metric" (Mandatory parameter): Overload-Reduction-Metric up to 3 digits long decimal string and the value range shall be from 0 to 100. The Overload Control Scope is a mandatory header component, and it shall contain one of the parameters: "NF-Instance", "NF-Set", "NF-Service-Instance" or "NF-Service-Set" (for NF consumers or NF producers), "Callback-URI" (for NF consumers), "SCP-FQDN" (for SCP), or "SEPP-FQDN" (for SEPP). See clause 6.4.3.4.5. The nfinst, nfset, nfservinst, nfserviceset and servname parameters are defined in clause 5.2.3.2.8. fqdn shall encode an FQDN. URI is defined in Section 3 of RFC 3986. When signaling overload control information of an NF service instance, the "NF-Inst" parameter shall be present to identify the NF service instance unambiguously. If the "NF-Inst" parameter is absent, the receiving NF should assume the last known NF instance ID of NF service producer or consumer, if available. "DNN" (Optional parameter): Used for S-NSSAI/DNN based overload control by SMF, see clause 6.4.3.4.5.2.2, that refers to one or more specific DNN(s). DNN format is defined in TS 23.003. "S-NSSAI" (Optional parameter): Used for S-NSSAI/DNN based overload control by SMF, see clause 6.4.3.4.5.2.2, that refers to one or more specific S-NSSAI(s). S-NSSAI format is defined in clause 5.4.4.2 of TS 29.571. It shall be encoded as the object format (i.e. not converted to the string pattern defined in clause 5.4.4.2 of TS 29.571).

The header contains a comma-delimited list (see RFC 9110) of Load Control Information (LCI). See clause 6.3.3. The encoding of the header follows the ABNF as defined in RFC 9110.

"Timestamp" (Mandatory parameter): The date-time type is specified in RFC 5322 and Section 5.6.7 of RFC 9110. It indicates the timestamp associated with the load control information. "Load-Metric" (Mandatory parameter): Load-Metric is up to 3 digits long decimal string and the value range shall be from 0 to 100. The Load Control Scope is a mandatory header component, and it shall contain one of the parameters: "NF-Instance", "NF-Set", "NF-Service-Instance" or "NF-Service-Set" (for NF producers), "SCP-FQDN" (for SCP), or "SEPP-FQDN" (for SEPP). See clause 6.3.3.4.4. The nfinst, nfset, nfservinst and nfserviceset parameters are defined in clause 5.2.3.2.5. fqdn shall encode an FQDN. When signaling load control information of an NF service instance, the NF-Inst parameter shall be present to identify the NF service instance unambiguously. If the NF-Inst parameter is absent, the receiving NF should assume the last known NF instance ID of the NF service producer, if available. "DNN" (Optional parameter): Used for S-NSSAI/DNN based load control by SMF, see clause 6.3.3.4.4.2.2, that refers to one or more specific DNN(s). DNN format is defined in TS 23.003. "S-NSSAI" (Optional parameter): Used for S-NSSAI/DNN based load control by SMF, see clause 6.3.3.4.4.2.2, that refers to one or more specific S-NSSAI(s). S-NSSAI format is defined in clause 5.4.4.2 of TS 29.571. It shall be encoded as the object format (i.e. not converted to the string pattern defined in clause 5.4.4.2 of TS 29.571). "Relative-Capacity" (Optional parameter): Used for S-NSSAI/DNN based load control by SMF, see clause 6.3.3.4.5. Up to 3 digits long decimal string with value range from 0 to 100. The value applies to all combinations of S-NSSAIs and DNNs indicated in the LCI.

3The header contains client credentials assertion (see clause 13.3.8.1 of TS 33.501). The encoding of the header follows the ABNF as defined in RFC 9110.

The client credentials assertion shall be a JSON Web Token (JWT) as specified in RFC 7519, digitally signed using JWS as specified in RFC 7515 and in clause 13.3.8.1 of TS 33.501. It shall include:

• the claims defined in Table 5.2.3.2.11-1 encoded as a JSON object; and
• one of the following JOSE headers:
  • the X.509 URL (x5u) header (see Section 4.1.5 of RFC 7515) referring to a resource for the X.509 public key certificate or certificate chain used for signing the client authentication assertion, or
  • the X.509 Certificate Chain (x5c) header (see Section 4.1.5 of RFC 7515) including the X.509 public key certificate or certificate chain used for signing the client authentication assertion.

The digitally signed client credentials assertion shall be converted to the JWS Compact Serialization encoding as a string as specified in Section 7.1 of RFC 7515.

  The JSON object containing the client credentials assertion shall comply with the following OpenAPI definition:

The header contains a list of NRF API URIs. See clause 6.10.3.2 and clause 6.10.5.1. The encoding of the header follows the ABNF as defined in RFC 9110.

• for the nnrf-disc, nnrf-nfm and nnrf-oauth2 parameters:
  URI shall comply with the URI definition in RFC 3986.
• for the oauth2-requested-services parameter:
  nrfServiceName shall encode an NRF API name, e.g. "nnrf-disc" or "nnrf-nfm".
  When present, the oauth2-requested-services parameter shall indicate the list of NRF services for which OAuth2 based authorization is required for accessing the respective NRF services.
  If OAuth2 based authorization is required for accessing the respective NRF services, the nnrf-oauth2 parameter shall be present and shall be used to request access token for NRF services.
  The absence of the oauth2-requested-services parameter means that no indication is provided about the potential usage of Oauth2 for authorization.

This header contains the target NF (Service) Instance ID in an HTTP 307/308 response (see clause 6.10.9). The encoding of the header follows the ABNF as defined in RFC 9110.

The following parameters are defined:

• nfinst (NF instance): indicates a NF Instance ID, as defined in TS 29.510; the ABNF is defined in clause 5.2.3.2.8.
• nfservinst (NF service instance): indicates a NF Service Instance ID, as defined in TS 29.510; the ABNF is defined in clause 5.2.3.2.8.

The header contains the value of maximum number of allowed hops with specified node type to relay the request message to the target NF. The encoding of the header follows the ABNF as defined in RFC 9110.

The header contains the PLMN Identity (MCC-MNC) of the source PLMN or the SNPN ID (MCC-MNC-NID) of the source SNPN of the received HTTP messages. The encoding of the header follows the ABNF as defined in RFC 9110.

The srcinfo shall only be present when SCP or SEPP was unable to uniquely determine the value, i.e. PLMN ID, and has decided to insert the header with the value derived by configuration as described in Table 5.2.3.2.1-1. The srcfqdn shall indicate FQDN of SCP or SEPP that inserted the header when srcinfo is present.

The header indicates the access scope of the service request 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.

Scope-token shall consist of a list of space-delimited, case-sensitive strings, containing the NF service name of the NF service producer corresponding to the service request and, if defined for the specific resource/operation in the corresponding API, the additional resource/operation-level scope. NQCHAR is defined in Appendix A of IETF RFC 6749.

The header contains an Access Token in a service response, for possible re-use in subsequent service requests, as defined in clause 6.10.11. The encoding of the header follows the ABNF as defined in RFC 9110.

See Section 11.4 of RFC 9110 for the definition of "credentials".

This header contains the NF Group ID (e.g. UDM, HSS, AUSF, UDR, CHF, PCF Group ID) of the NF service producer. The encoding of the header follows the ABNF as defined in RFC 9110.

The following parameter is defined:

• nfgid (NF Group ID): indicates a NF Group ID, as defined in TS 29.571.

The header contains the NRF API URI of the NF discovery service and may contain the NRF API URI of the NF management service. See clauses 6.5.3.2. The encoding of the header follows the ABNF as defined in RFC 9110.

URI shall comply with the URI definition in RFC 3986.

This header contains the IDs of the NF (service) instance as HTTP client and the NF (service) instance as HTTP server. The encoding of the header follows the ABNF as defined in RFC 9110.

The following peertype are defined:

• srcinst (Source NF instance): indicates the Source NF Instance ID, as defined in TS 29.510;
• srcservinst (Source NF service instance): indicates the Source NF Service Instance ID, as defined in TS 29.510; if this parameter is present, srcinst shall also be present;
• srcscp (Source SCP): indicates the FQDN of the Source SCP, the format is "SCP-<SCP FQDN>"; this parameter shall only be included by an SCP, i.e. when the HTTP request or response message is originated or relayed by an SCP;
• srcsepp (Source SEPP): indicates the FQDN of the Source SEPP, the format is "SEPP-<SEPP FQDN>"; this parameter shall only be included by a SEPP, i.e. when the HTTP request or response message is originated or relayed by a SEPP;
• dstinst (Destination NF instance): indicates the Destination NF Instance ID, as defined in TS 29.510;
• dstservinst (Destination NF service instance): indicates the Destination NF Service Instance ID, as defined in TS 29.510; if this parameter is present, dstinst shall also be present;
• dstscp (Destination SCP): indicates the FQDN of the Destination SCP, the format is "SCP-<SCP FQDN>"; this parameter shall contain the next-hop SCP of the HTTP request or response message to be included by an SCP or SEPP or by clients/servers sending requests/responses to an SCP;
• dstsepp (Destination SEPP): indicates the FQDN of the Destination SEPP, the format is "SEPP-<SEPP FQDN>"; this parameter shall be included by an SCP or by clients/servers sending requests/responses to a SEPP; it may also be included by a SEPP, based on operator's policy.

The header shall contain the source peer information, and should contain the destination peer information if available.

The header contains client credentials assertion of a source NF instance (e.g. NWDAF, NWDAF containing AnLF) in a service request that is sent from an NF Service Consumer (e.g., DCCF, NWDAF containing MTLF) to an NF Service Producer (e.g. AMF, SMF, NWDAF containing MTLF). The purpose is to enable the authorization of NF service consumers for data access via DCCF or NWDAF containing MTLF (see clause 13.3.8.1 and Annex X of TS 33.501). The encoding of the header follows the ABNF as defined in RFC 9110.

The client credentials assertion shall be a JSON Web Token (JWT) as defined in clause 5.2.3.2.11, with the sub claim identifying the source NF instance, i.e. corresponding to the sourceNfInstanceId claim specified in Table 6.3.5.2.4-1 of TS 29.510. The ABNF of the JSON Web Token (JWT) is defined in clause 5.2.3.2.11.

The header contains the apiRoot of an SCP in the target PLMN (see clause 4.4 of TS 29.501) in a request sent from a source PLMN to a target PLMN when using indirect communication with or without delegated discovery between different PLMNs with possible NF selection at target PLMN and the apiRoot of the SCP in the target PLMN is known by the source PLMN (see clause 6.10.12). The encoding of the header follows the ABNF as defined in RFC 9110.

The ABNF of sbi-scheme, sbi-authority and prefix is defined in clause 5.2.3.2.4.