5 Protocols Over Service Based Interfaces

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

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

5.1 Protocol Stack Overview

The protocol stack for the service-based interfaces is shown on Figure 5.1-1.

Figure 5.1-1: SBI Protocol Stack

The service-based interfaces use HTTP/2 protocol (see clause 5.2) with JSON (see clause 5.4) as the application layer serialization protocol. For the security protection at the transport layer, all 3GPP NFs shall support TLS and TLS shall be used within a PLMN if network security is not provided by other means, as specified in 3GPP TS 33.501 [17].

5.2 HTTP/2 Protocol

5.2.1 General

HTTP/2 as described in IETF RFC 7540 [7] shall be used in Service based interface.

5.2.2 HTTP standard headers

5.2.2.1 General

This clause lists the HTTP standard headers that shall be supported on SBI, other HTTP standard headers defined in IETF RFCs may be supported by NF.

5.2.2.2 Mandatory to support HTTP standard headers

The HTTP request standard headers and the HTTP response standard headers that shall be supported on SBI are defined in Table 5.2.2.2-1 and in Table 5.2.2.2-2 respectively. Mandatory to support HTTP standard headers does not mean all the HTTP requests and responses carry the identified request and response headers respectively. It only means it is mandatory to support the processing of the identified headers in request and response message.

Table 5.2.2.2-1: Mandatory to support HTTP request standard headers

Name	Reference	Description
Accept	IETF RFC 7231 [11]	This header is used to specify response media types that are acceptable.
Accept-Encoding	IETF RFC 7231 [11]	This header may be used to indicate what response content-encodings (e.g. gzip) are acceptable in the response.
Content-Length	IETF RFC 7230 [12]	This header is used to provide the anticipated size, as a decimal number of octets, for a potential payload body.
Content-Type	IETF RFC 7231 [11]	This header is used to indicate the media type of the associated representation.
Content-Encoding	IETF RFC 7231 [11]	This header may be used in some requests to indicate the content encodings (e.g. gzip) applied to the resource representation beyond those inherent in the media type.
User-Agent	IETF RFC 7231 [11]	This header shall be mainly used to identify the NF type of the HTTP/2 client. This header should be included in every HTTP/2 request sent over any SBI; This header shall be included in every HTTP/2 request sent using indirect communication when target NF (re-)selection is to be performed at SCP. For Indirect communications, the User-Agent header in a request that is: – forwarded by the SCP (with or without delegated discovery) shall identify the NF type of the original NF that issued the request (i.e. the SCP shall forward the header received in the incoming request); – originated by the SCP towards the NRF (e.g. NF Discovery or Access Token Request) shall identify the SCP. The pattern of the content should start with the value of NF type (e.g. "UDM", see NOTE 1) or "SCP" (for a request originated by an SCP) and followed by a "-" and any other specific information if needed afterwards.
Cache-Control	IETF RFC 7234 [20]	This header may be used in some HTTP/2 requests to provide the HTTP cache-control directives that the client is willing to accept from the server.
If-Modified-Since	IETF RFC 7232 [24]	This header may be used in a conditional GET request, for server revalidation. This is used in conjunction with the Last-Modified server response header, to fetch content only if the content has been modified from the cached version.
If-None-Match	IETF RFC 7232 [24]	This header may be used in a conditional GET request. This is used in conjunction with the ETag server response header, to fetch content only if the tag value of the resource on the server differs from the tag value in the If-None-Match header.
If-Match	IETF RFC 7232 [24]	This header may be used in a conditional POST or PUT or DELETE or PATCH request. This is used in conjunction with the ETag server response header, to update / delete content only if the tag value of the resource on the server matches the tag value in the If-Match header.
Via	IETF RFC 7230 [12]	This header shall be inserted by HTTP proxies and it shall be inserted by an SCP and SEPP when relaying an HTTP request. When inserted by an SCP or SEPP, the header field value should be formatted as defined for the Via header in Table 5.2.2.2-2.
Authorization	IETF RFC 7235 [21]	This header shall be used if OAuth 2.0 based access authorization with "Client Credentials" grant type is used as specified in clause 13.4.1 of 3GPP TS 33.501 [17], clause 7 of IETF RFC 6749 [22] and IETF RFC 6750 [23].
NOTE 1: The value of NF type in the User-Agent header shall comply with the enumeration value of Table 6.1.6.3.3-1 in 3GPP TS 29.510 [8].

Table 5.2.2.2-2: Mandatory to support HTTP response standard headers

Name	Reference	Description
Content-Length	IETF RFC 7230 [12]	This header may be used to provide the anticipated size, as a decimal number of octets, for a potential payload body.
Content-Type	IETF RFC 7231 [11]	This header shall be used to indicate the media type of the associated representation.
Location	IETF RFC 7231 [11]	This header may be used in some responses to refer to a specific resource in relation to the response.
Retry-After	IETF RFC 7231 [11]	This header may be used in some responses to indicate how long the user agent ought to wait before making a follow-up request.
Content-Encoding	IETF RFC 7231 [11]	This header may be used in some responses to indicate to the HTTP/2 client the content encodings (e.g. gzip) applied to the resource representation beyond those inherent in the media type.
Cache-Control	IETF RFC 7234 [20]	This header may be used in some responses (e.g. NRF responses to queries) to provide HTTP response cache control directives. The cache directives "no-cache", "no-store", "max-age" and "must-revalidate" values shall be supported.
Age	IETF RFC 7234 [20]	This header may be inserted by HTTP proxies when returning a cached response. The "Age" header field conveys the sender’s estimate of the amount of time since the response was generated or successfully validated at the origin server. The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.
Last-Modified	IETF RFC 7232 [24]	This header may be sent to allow for conditional GET with the If-Modified-Since header.
ETag	IETF RFC 7232 [24]	This header may be sent to allow for conditional GET with the If-If-None-Match header or a conditional POST / PUT / PATCH / DELETE with the If-Match header.
Via	IETF RFC 7230 [12]	This header shall be inserted by HTTP proxies. This header shall be inserted by an SCP or SEPP when relaying an HTTP error response (see clause 6.10.8). It may be inserted when relaying other HTTP responses. When inserted by an SCP or SEPP, the received-protocol portion of the header field value should be set to "HTTP/2.0" or "2.0" and the received-by portion of the header field value should be formatted as follows: – "SCP-<SCP FQDN>" for an SCP – "SEPP-<SEPP FQDN>" for a SEPP See examples in clause 6.10.8.
Allow	IETF RFC 7231 [11]	This header field shall be used to indicate methods supported by the target resource.
WWW-Authenticate	IETF RFC 7235 [21]	This header field shall be included when an NF service producer rejects a request with a "401 Unauthorized" status code (e.g. when a request is sent without an OAuth 2.0 access token or with an invalid OAuth 2.0 access token).
Accept-Encoding	IETF RFC 7694 [33]	See clause 6.9 for the use of this header.
Server	IETF RFC 7231 [11]	This header should be inserted by the originator of an HTTP error response (see clause 6.10.8). It may be inserted otherwise. When inserted by an NF, an SCP or a SEPP, the pattern of the header should be formatted as follows: – "SCP-<SCP FQDN>" for an SCP – "SEPP-<SEPP FQDN>" for a SEPP – "<NFType>-<NF Instance ID>" for an NF

5.2.3 HTTP custom headers

5.2.3.1 General

The list of custom HTTP headers applicable to 3GPP Service Based NFs are specified below.

The ABNF definition of these custom headers is expressed in the following clauses using common syntax components defined in IETF RFC 7230 [12], clause 3.2.6, such as <token> and <tchar>. As indicated there, the following characters (expressed by their UNICODE name) shall not be used as part of a <token>, or as a <tchar>:

– QUOTATION MARK (U+0022): "

– LEFT PARENTHESIS (U+0028): (

– RIGHT PARENTHESIS (U+0029): )

– COMMA (U+002C): ,

– SOLIDUS (U+002F): /

– COLON (U+003A): :

– SEMICOLON (U+003B): ;

– LESS-THAN SIGN (U+003C): <

– EQUALS SIGN (U+003D): =

– GREATER-THAN SIGN (U+003E): >

– QUESTION MARK (U+003F): ?

– COMMERCIAL AT (U+0040): @

– LEFT SQUARE BRACKET (U+005B): [

– REVERSE SOLIDUS (U+005C): \

– RIGHT SQUARE BRACKET (U+005D): ]

– LEFT CURLY BRACKET (U+007B): {

– RIGHT CURLY BRACKET (U+007D): }

If a 3GPP custom HTTP header, whose ABNF syntax definition uses the <token> or <tchar> components, needs to include a value containing a character outside of the character set allowed for <token> or <tchar>, such character shall be encoded using percent-encoding, as follows:

pct-encoded = "%" HEXDIG HEXDIG

The HEXDIG ABNF production rule, originally defined in IETF RFC 5234 [43], shall be considered as if the uppercase hexadecimal digits ‘A’ through ‘F’ are equivalent to the lowercase digits ‘a’ through ‘f’, respectively.

The literal "%" character shall also be encoded as above (i.e. %25).

Percent encoding shall not be used for characters that are in the <token> or <tchar> allowed character set.

EXAMPLE: 3GPP Custom Header "3gpp-Sbi-Oci" (see clause 5.2.3.2.9) can include an optional parameter "snssai". If this parameter takes the value:

{"sst": 1, "sd": "A08923"}

it will be formatted, when included in this custom header, as:

S-NSSAI: %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08923%22%7D

5.2.3.2 Mandatory to support custom headers

5.2.3.2.1 General

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.

Table 5.2.3.2.1-1: Mandatory HTTP custom headers

Name	Reference	Description
3gpp-Sbi-Message-Priority	Clause 5.2.3.2.2	This header is used to specify the HTTP/2 message priority for 3GPP service based interfaces. This header shall be included in HTTP/2 messages when a priority for the message needs to be conveyed (e.g. HTTP/2 messages related to Multimedia Priority Sessions).
3gpp-Sbi-Callback	Clause 5.2.3.2.3	This header is used to indicate if a HTTP/2 message is a callback (e.g. notification). This header shall be included in HTTP POST messages for callbacks towards NF service consumer(s) in another PLMN via the SEPP (See 3GPP TS 29.573 [27]). This header shall also be included in HTTP POST messages for callbacks in indirect communication (See clause 6.10.7). This header should also be included in the HTTP POST message of any event notification request for direct communications. If the header is included in received HTTP request, the SEPP or SCP shall include this header in the HTTP request forwarded to next hop. (NOTE 1)
3gpp-Sbi-Target-apiRoot	Clause 5.2.3.2.4	This header is used by an HTTP client to indicate the apiRoot of the target URI when communicating indirectly with the HTTP server via an SCP. This header is also used by SCP to indicate the apiRoot of the target URI, if a new HTTP server is selected or reselected and there is no Location header included in the response. This header may also be used by an HTTP client towards its local SEPP to indicate the apiRoot of the target URI towards HTTP server in another PLMN. This header may also be used between SEPPs to indicate the apiRoot of the target URI towards HTTP server in another PLMN, when TLS security with the 3gpp-Sbi-Target-apiRoot header is used between the SEPPs.
3gpp-Sbi-Routing-Binding	Clause 5.2.3.2.5	This header is used in a service request to signal binding information to direct the service request to an HTTP server which has the targeted NF Service Resource context (see clause 6.12).
3gpp-Sbi-Binding	Clause 5.2.3.2.6	This header is used to signal binding information related to an NF Service Resource to a future consumer (HTTP client) of that resource (see clause 6.12).
3gpp-Sbi-Discovery-*	Clause 5.2.3.2.7	Headers beginning with the prefix 3gpp-Sbi-Discovery- are used in indirect communication mode to allow the discovery and selection of a suitable NF service producer (e.g. in case of service requests) or NF service consumer (e.g. in case of notifications or callbacks) by the SCP, as specified in clause 5.2.3.2.7, clause 6.5.3 and clause 6.10. Such headers may be included in any SBI message and include information allowing an SCP to find a suitable NF service producer or NF service consumer, as per the discovery and selection parameters provided respectively by the NF service consumer or the NF service producer.
3gpp-Sbi-Producer-Id	Clause 5.2.3.2.8	This header is used in a service response from the SCP to the NF Service Consumer, when using indirect communication, to identify the NF service producer. See clause 6.10.3.4. This header may also be used in a resource creation response from the NF Service Producer to the NF consumer (or SCP), when the resource is created in a different NF Service Producer (e.g. UE Context Create with AMF relocation during inter-PLMN N2 handover procedure).
3gpp-Sbi-Oci	Clause 5.2.3.2.9	This header may be used by an overloaded NF Service Producer in a service response, or in a notification request to signal Overload Control Information (OCI) to the NF Service Consumer. This header may also be used by an overloaded NF Service Consumer in a notification response or in a service request to signal Overload Control Information (OCI) to the NF Service Producer.
3gpp-Sbi-Lci	Clause 5.2.3.2.10	This header may be used by a NF Service Producer to send Load Control Information (LCI) to the NF Service Consumer.
3gpp-Sbi-Client-Credentials	Clause 5.2.3.2.11	This header may be used by an NF Service Consumer to send Client Credentials Assertion to the NRF or to the NF Service Producer. See clause 6.7.5.
3gpp-Sbi-Nrf-Uri	Clause 5.2.3.2.12	This header may be used to indicate the NRF API URIs to be used for a given service request, e.g. in indirect communication with delegated discovery as a result of an NSSF query. It may also indicate whether OAuth2 based authorization is required for accessing the NRF services. This header may also be used to indicate the NRF API URI to be used for a given notification request, e.g. if the NF service producer has received NRF API URI from the NF service consumer and the NF producer delegates NF consumer reselection to the SCP in indirect communication,
3gpp-Sbi-Target-Nf-Id	Clause 5.2.3.2.13	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. See clause 6.10.9.1.
3gpp-Sbi-Max-Forward-Hops	Clause 5.2.3.2.14	This header may be used to indicate the maximum number of allowed hops with specified node type to relay the request message to the target HTTP server. If node type is "scp", its value indicates the maximum number of allowed SCP hops to relay the request message to the target NF as HTTP server when indirect communication is used.
3gpp-Sbi-Originating-Network-Id	Clause 5.2.3.2.15	This header shall be inserted by an NF service consumer or an NF service producer originating an HTTP request message towards a different PLMN or SNPN. It should be inserted by the sending SCP in SBI HTTP request messages towards the SEPP, only if the header is not present in the SBI HTTP request message and the SCP can determine which PLMN-ID value should be included in the header. It shall be inserted by the sending SEPP or the receiving SEPP in SBI HTTP request messages towards the target PLMN or SNPN, only if the header is not present in the SBI HTTP request message and the sending SEPP or the receiving SEPP (respectively) can determine the PLMN ID or SNPN ID of the source PLMN or SNPN. If the SEPP cannot uniquely determine the PLMN-ID or SNPN-ID, it is a configuration/deployment aspect to determine which PLMN-ID or SNPN-ID value should be included in the header by these entities. In such case, the message should either be dropped, or the SEPP shall indicate to the peer that the header is derived based on configuration It shall indicate the PLMN-ID or the SNPN-ID of the source PLMN or SNPN of the HTTP request message (i.e., the PLMN ID or the SNPN ID of the NF Service Consumer or NF Service Producer). See clause 5.9.3.2 of 3GPP TS 33.501 [17] for the handling of this header by the sending NF, the sending SCP, the sending SEPP and the receiving SEPP. (NOTE 2)
3gpp-Sbi-Access-Scope	Clause 5.2.3.2.16	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. See clauses 6.7.3 and 6.10.11.
3gpp-Sbi-Access-Token	Clause 5.2.3.2.17	This header is used in a service response forwarded by the SCP to an NF service consumer to provide an access token for possible re-use in subsequent service requests. See clause 6.10.1.
3gpp-Sbi-Target-Nf-Group-Id	Clause 5.2.3.2.19	This header is used in a service response from the SCP to the NF Service Consumer, when using indirect communication with delegated discovery, to indicate the NF Group ID of the NF service producer selected by the SCP. See clause 6.10.3.4.
3gpp-Sbi-Nrf-Uri-Callback	Clause 5.2.3.2.20	This header may be included in service request (e.g. subscription creation request) from the NF service consumer to the NF service producer, to indicate the NRF API URI to be used to discover an alternative NF service consumer for callback, e.g. during NF service consumer reselection for callback when the original NF service consumer is no longer available. For indirect communication, if the NF service producer delegates NF service consumer reselection to the SCP, the NF service producer should include 3gpp-Sbi-Nrf-Uri header with received NRF API URI in the notification requests to the NF service consumer.
3gpp-Sbi-NF-Peer-Info	Clause 5.2.3.2.21	This header is used in HTTP requests and responses to indicate the sender and receiver of the message. The HTTP client and server should include this header in every HTTP request and response messages. HTTP intermediaries (e.g. SCP) should forward this header, when relaying HTTP messages to next hop, and may update the destination in the header if the receiver NF of the message is (re)selected. The parameters defined for the source and destination of SCPs or SEPPs (as defined in clause 5.2.3.2.21) may also need to be updated according to the source and destination of the HTTP message.
NOTE 1: The callback URI for event subscription may receive event notifications from different NF producers, e.g. UDM may subscribe to AMF/SMF on behalf of NEF with directly reporting mode for certain UDM events in the subscription, which should be inspected with corresponding OpenAPI schema where the notification is defined. For both direct and indirect communications, to include this header in all event notification requests can help NF consumer to identify the type of event notification and select corresponding schema to perform OpenAPI inspection. NOTE 2: The value of this header shall be verified by the sending SEPP and receiving SEPP (see clause 5.9.3.2 of 3GPP TS 33.501 [17])

5.2.3.2.2 3gpp-Sbi-Message-Priority

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 IETF RFC 7230 [12].

3gpp-Sbi-Message-Priority = "3gpp-Sbi-Message-Priority" ":" OWS (DIGIT / %x31-32 DIGIT / "3" %x30-31)

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

An example is: 3gpp-Sbi-Message-Priority: 10.

5.2.3.2.3 3gpp-Sbi-Callback

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 IETF RFC 7230 [12].

3gpp-Sbi-Callback header field = "3gpp-Sbi-Callback" ":" OWS cbtype *1( ";" OWS "apiversion=" majorversion)

cbtype = 1*cbchar

cbchar = "-" / "_" / DIGIT / ALPHA

majorversion = *DIGIT

EXAMPLE 1: 3gpp-Sbi-Callback: Nnrf_NFManagement_NFStatusNotify

EXAMPLE 2: 3gpp-Sbi-Callback: Nudm_SDM_Notification; apiversion=2

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.

NOTE: The apiversion parameter can be used by the SEPP to identify the protection and modification policies applicable to the API version of a notification or callback request, or by the SCP to select a notification endpoint of a NF Service Consumer that supports the API version when forwarding a notification request issued for a default notification subscription.

5.2.3.2.4 3gpp-Sbi-Target-apiRoot

The header contains the apiRoot of the target URI (see clause 4.4 of 3GPP TS 29.501 [5]) 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 SCP selected or reselected a new HTTP server to route the request 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 IETF RFC 7230 [12].

3gpp-Sbi-Target-apiRoot header field = "3gpp-Sbi-Target-apiRoot" ":" OWS scheme "://" authority [ prefix ]

scheme = "http" / "https"

authority = host [ ":" port ]

port = *DIGIT

prefix = path-absolute ; path-absolute production rule from IETF RFC 3986 [14], clause 3.3

An example is: 3gpp-Sbi-Target-apiRoot: https://example.com/a/b/c

5.2.3.2.5 3gpp-Sbi-Routing-Binding

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 IETF RFC 7230 [12].

3gpp-Sbi-Routing-Binding = "3gpp-Sbi-Routing-Binding" ":" OWS "bl=" blvalue 1*(";" OWS parameter)

blvalue = "nf-instance" / "nf-set" / "nfservice-instance" / "nfservice-set"

parameter = parametername "=" token

parametername = "nfinst" / "nfset" / "nfservinst" / "nfserviceset" / "servname" / "backupamfinst" / "backupnf"

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 3GPP TS 29.510 [8]. 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 3GPP TS 23.003 [15]. 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 in 3GPP TS 23.003 [15]. 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 3GPP TS 29.510 [8], 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 in 3GPP TS 29.510 [8]) of the backup NF, i.e. the backup AMF as specified in 3GPP TS 23.501 [3]. 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.

See clause 3.2.6 of IETF RFC 7230 [12] for the "token" type definition. A token’s value is a string, which contains a binding entity ID or a service name.

EXAMPLE 1: Binding to SMF set 1 of MCC 345 and MNC 012:

3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1.smfset.5gc.mnc012.mcc345

EXAMPLE 2: Binding to an SMF instance within SMF set of Example 1:

3gpp-Sbi-Routing-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.smfset.5gc.mnc012.mcc345

EXAMPLE 3: Binding to a SMF Service Set "xyz" within an SMF instance within SMF set of Example 1:

3gpp-Sbi-Routing-Binding: bl=nfservice-set; nfserviceset=setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345; nfset=set1.smfset.5gc.mnc012.mcc345

EXAMPLE 4: Binding to AMF set 1 within AMF region 48 (hexadecimal):
3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345

EXAMPLE 5: Binding for a subscription (i.e. notification requests) to AMF set 1 within AMF region 48 (hexadecimal) and Namf_Communication service:
3gpp-Sbi-Routing-Binding: bl=nf-set; nfset= set1.region48.amfset.5gc.mnc012.mcc345; servname=namf-comm

EXAMPLE 6: Binding to the AMF Instance in addition with backup AMF, where the nfinst carries the Identity of the AMF to which the resource is bound and whose backup AMF is indicated in backupamfinst:
3gpp-Sbi-Routing-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed7; backupamfinst=54804518-4191-46b3-955c-ac631f953ed8

5.2.3.2.6 3gpp-Sbi-Binding

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 IETF RFC 7230 [12].

3gpp-Sbi-Binding = "3gpp-Sbi-Binding" ":" 1#(OWS "bl=" blvalue 1*(";" OWS parameter) [";" OWS recoverytime] [";" OWS notif-receiver] [";" OWS "group=" groupvalue] [1*(";" OWS groupparameter)] [";" OWS "no-redundancy=" no-red-value])

blvalue = "nf-instance" / "nf-set" / "nfservice-instance" / "nfservice-set"

parameter = parametername "=" token

parametername = "nfinst" / "nfset" / "nfservinst" / "nfserviceset" / "servname" / "scope" / "backupamfinst" / "backupnf"

recoverytime = "recoverytime=" OWS DQUOTE date-time DQUOTE

notif-receiver = "nr=" URI ; URI production rule from IETF RFC 3986 [14], Appendix A

groupvalue = "true" / "false"

groupparameter = groupparametername "=" token

groupparametername = "oldgroupid" / "groupid" / "uribase" / "oldnfinst / "oldservset" / "oldservinst" / "guami"

no-red-value = "true"

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 clauses 6.12.4 and 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 3GPP TS 29.510 [8], 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 3GPP TS 23.501 [3] and clause 6.1 of 3GPP TS 23.527 [38]. The date-time type is specified in IETF RFC 5322 [37] and clause 7.1.1.1 of IETF RFC 7231 [11].

– 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 or in 3GPP TS 29.510 [8], 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 3GPP TS 29.571 [13].

– 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 3GPP TS 29.510 [8]. 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 3GPP TS 29.510 [8]. 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 3GPP TS 29.510 [8]. 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 3GPP TS 29.571 [13]. 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 nfservset parameter or the nfinst parameter shall be present. The nfservset 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).

EXAMPLES 1 to 5: Same as EXAMPLES 1 to 5 defined in clause 5.2.3.2.5, with the header name "3gpp-Sbi-Binding" instead of "3gpp-Sbi-Routing-Binding".

EXAMPLE 6: Subscription request from one NF on behalf of another NF, with 2 binding indications:

3gpp-Sbi-Binding: bl= nf-set; nfset=set1.udmset.5gc.mnc012.mcc345; servname=nudm-ee;scope=subscription-events
3gpp-Sbi-Binding: bl= nf-set; nfset=set1.nefset.5gc.mnc012.mcc345; servname=nnef-event-exposure

EXAMPLE 7: Service request with 2 binding indications, for callback requests and for other services the NF Service Consumer may provide later as an NF Service Producer:

3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.smfset.5gc.mnc012.mcc345; servname=nsmf-pdusession
3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.smfset.5gc.mnc012.mcc345; scope=other-service; servname=nsmf-event-exposure

EXAMPLE 8: Service request with one binding indication applying to notification/callback requests and to any other services the NF Service Consumer may provide later as an NF Service Producer:

3gpp-Sbi-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345; scope=callback; scope=other-service

EXAMPLE 9: Service request with one binding indication applying to notification/callback requests together with a recovery time stamp associated with the NF Set indicated in the binding indication and with the binding level set to "nfset":
3gpp-Sbi-Binding: bl=nfset; nfset=set1.region48.amfset.5gc.mnc012.mcc345; scope=callback; recoverytime= "Tue, 04 Feb 2020 08:49:37 GMT"

EXAMPLE 10: Service response with one binding indication applying to the session context with a recovery time stamp associated with the NF Set indicated in "nfset" in the binding indication and with the binding level set to "nfinstance":

3gpp-Sbi-Binding: bl= nfinstance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.smfset.5gc.mnc012.mcc345; recoverytime= "Tue, 04 Feb 2020 08:49:37 GMT"

EXAMPLE 11: Service response with one binding indication applying to the session context with a recovery time stamp associated with the NF Instance included the binding indication and with the binding level set to nfserviceinstance:

3gpp-Sbi-Binding: bl=nfserviceinstance; nfservinst=xyz; nfinst=54804518-4191-46b3-955c-ac631f953ed8; recoverytime= "Tue, 04 Feb 2020 08:49:37 GMT"

EXAMPLE 12: Service response with one binding indication applying to the resource context pertaining to a group identified by "54804518-4191-46b3-955c-ac631f953ed1" together with a backup nf:

3gpp-Sbi-Binding: bl= nfinstance; nfinst=54804518-4191-46b3-955c-ac631f953ed0; nfset=set1.smfset.5gc.mnc012.mcc345; groupid=54804518-4191-46b3-955c-ac631f953ed1; backupnf=54804519-4191-46b3-955c-ac631f953ed2

EXAMPLE 13: A notification request message with one binding indication applying to the resource contexts with the oldgroup identifier "54804518-4191-46b3-955c-ac631f953ed1", where the preferred binding entity is changed to "nfinst=54804519-4191-46b3-955c-ac631f953ed0" together with a new group identifier "54804519-4191-46b3-955c-ac631f953ed3" allocated.

3gpp-Sbi-Binding: bl= nfinstance; nfinst=54804519-4191-46b3-955c-ac631f953ed0; nfset=set1.smfset.5gc.mnc012.mcc345; group=true; oldgroupid=54804518-4191-46b3-955c-ac631f953ed1; groupid=54804519-4191-46b3-955c-ac631f953ed3

EXAMPLE 14: A notification request message with one binding indication applying to the resource contexts identified by an uribase, where the preferred binding entity is changed to "nfinst=54804519-4191-46b3-955c-ac631f953ed0":

3gpp-Sbi-Binding: bl= nfinstance; nfinst=54804519-4191-46b3-955c-ac631f953ed0; nfset=set1.smfset.5gc.mnc012.mcc345; group=true; uribase= http%3A%2F%2F10.10.10.10%2Fstringxyz

EXAMPLE 15: A notification request message with one binding indication applying to the resource contexts served by the NF instance identified by "64804518-4191-46b3-955c-ac631f953ed8" where the preferred binding entity is changed to "nfinst=74804519-4191-46b3-955c-ac631f953ed0".

3gpp-Sbi-Binding: bl= nfinstance; nfinst=74804519-4191-46b3-955c-ac631f953ed0; nfset=set1.smfset.5gc.mnc012.mcc345; group=true; oldnfinst=64804518-4191-46b3-955c-ac631f953ed8

EXAMPLE 16: Service request message with an updated binding indication applying to the UE contexts for GUAMI" <mnc(012)><mcc(345)><AmfId("abcd12")> where the backupamfinst is changed.

3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed7; backupamfinst=54804520-4191-46b3-955c-ac631f953ed8; scope=other-service; group=true; guami={"plmnId":{"mnc":"012","mcc":"345"},"amfId":"abcd12"}

EXAMPLE 17: Service response with a binding indication applying to the resource context which is exclusively bound to a specific NF service instance.

3gpp-Sbi-Binding: bl=nfserviceinstance; nfservinst=xyz; nfinst=54804518-4191-46b3-955c-ac631f953ed8; no-redundancy= true

NOTE: Examples 6 and 7 are formatted as two distinct headers (which improves the readability), but they can also be formatted as a single header with two Binding Indication values separated by a comma.

5.2.3.2.7 3gpp-Sbi-Discovery

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 3GPP TS 29.510 [8], 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 3GPP TS 29.510 [8], 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.

Table 5.2.3.2.7-1: NF service discovery factors headers examples

Header name	Discovery parameter	Header value	Data Model
3gpp-Sbi-Discovery-target-nf-type	target-nf-type (TS 29.510 [8], Table 6.2.3.2.3.1-1)	AMF	NFType: Enumeration as of TS 29.510 [8], Table 6.1.6.3.3-1.
3gpp-Sbi-Discovery-snssais	snssais (TS 29.510 [8], Table 6.2.3.2.3.1-1)	[{"sst": 1, "sd": "A08923"}, {"sst": 1, "sd": "0023F1"}]	array(Snssai), where Snssai is a structured data type as of TS 29.571 [13], Table 5.4.4.2-1
3gpp-Sbi-Discovery-target-nf-instance-id	target-nf-instance-id (TS 29.510 [8], Table 6.2.3.2.3.1-1)	e553cf50-f32b-4638-8a7e-0d416cc60952	NfInstanceId: simple data type as of TS 29.571 [13], Table 5.3.2-1
3gpp-Sbi-Discovery-pdu-session-types	pdu-session-types (TS 29.510 [8], Table 6.2.3.2.3.1-1)	IPV6,IPV4V6	array(PduSessionType), where PduSessionType is a simple data type as of TS 29.571 [13], Table 5.4.3.3-1.

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 3GPP TS 29.510 [8]:

parameters:

– name: 3gpp-Sbi-Discovery-<Discovery parameter name>:

in: header

description: Discovery parameter defined in Table 6.2.3.2.3.1-1 of 3GPP TS 29.510

content:

application/json:

schema:

type: <Data type defined in Table 6.2.3.2.3.1-1 of 3GPP TS 29.510>

– for other parameters:

parameters:

– name: 3gpp-Sbi-Discovery-<Discovery parameter name>:

in: header

description: Discovery parameter defined in Table 6.2.3.2.3.1-1 of 3GPP TS 29.510

schema:

type: <Data type defined in Table 6.2.3.2.3.1-1 of 3GPP TS 29.510>

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 3GPP TS 29.510 [8] shall be formatted using the style "simple", i.e. as comma-separated values.

NOTE 1: The style "form" is not available for header parameters, thus the corresponding 3gpp-Sbi-Discovery-* headers use the default style "simple" defined for header parameters in the OpenAPI Specification [9].

NOTE 2: The percent-encoding described in clause 5.2.3.1 is not applicable to the 3gpp-Sbi-Discovery-* headers since their syntax is not defined using ABNF; such encoding is only applicable to headers whose ABNF syntax is defined in terms of <token> and <tchar> common components.

5.2.3.2.8 3gpp-Sbi-Producer-Id

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 IETF RFC 7230 [12].

3gpp-Sbi-Producer-Id = "3gpp-Sbi-Producer-Id" ":" OWS "nfinst=" nfInstanceIdvalue [OWS ";" "nfservinst=" nfServiceInstanceIdvalue] [OWS ";" "nfset=" nfSetIdvalue] [OWS ";" "nfserviceset=" nfServiceSetIdvalue]

The following parameters are defined:

– nfinst (NF instance): indicates a NF Instance ID, as defined in 3GPP TS 29.510 [8];

– nfservinst (NF service instance): indicates a NF Service Instance ID, as defined in 3GPP TS 29.510 [8];

– nfset (NF set): indicates an NF Set ID, as defined in clause 28.12 in 3GPP TS 23.003 [15];

– nfserviceset (NF service set): indicates an NF Service Set ID as defined in clause 28.13 in 3GPP TS 23.003 [15].

EXAMPLE 1: 3gpp-Sbi-Producer-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8

EXAMPLE 2: 3gpp-Sbi-Producer-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfservinst=xyz

EXAMPLE 3: 3gpp-Sbi-Producer-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfservinst=xyz; nfset=set1.smfset.5gc.mnc012.mcc345

5.2.3.2.9 3gpp-Sbi-Oci

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 IETF RFC 7230 [12].

3gpp-Sbi-Oci = "3gpp-Sbi-Oci:" 1#(RWS timestamp ";" RWS validityPeriod ";" RWS olcMetric ";" RWS olcScope)

timestamp = "Timestamp:" RWS DQUOTE date-time DQUOTE

Mandatory parameter. The date-time type is specified in IETF RFC 5322 [37] and clause 7.1.1.1 of IETF RFC 7231 [11]. It indicates the timestamp at which the overload control information was generated.

validityPeriod = "Period-of-Validity:" RWS 1*DIGIT "s"

Mandatory parameter. Period of validity is a timer that is measured in seconds. Once the timer expires, the OCI becomes invalid.

olcMetric = "Overload-Reduction-Metric:" RWS (DIGIT / %x31-39 DIGIT / "100") "%"

Mandatory parameter. Overload-Reduction-Metric up to 3 digits long decimal string and the value range shall be from 0 to 100.

olcScope = nfProducerScope / nfConsumerScope / scpScope / seppScope

Mandatory structured parameter, which in the actual header is replaced by its sub-parameters.

nfProducerScope = (("NF-Instance:" RWS nfinst)
/ ("NF-Set:" RWS nfset)
/ "(NF-Service-Instance:" RWS nfservinst [; RWS "NF-Inst:" RWS nfinst])
/ ("NF-Service-Set:" RWS nfserviceset)) [";" RWS sNssai ";" RWS dnn]

nfConsumerScope = ("NF-Instance:" RWS nfinst [";" RWS "Service-Name:" RWS servname])
/ ("NF-Set:" RWS nfset [";" RWS "Service-Name:" RWS servname])
/ "(NF-Service-Instance:" RWS nfservinst [; RWS "NF-Inst:" RWS nfinst])
/ ("NF-Service-Set:" RWS nfserviceset)
/ ("Callback-Uri:" RWS URI *( RWS "&" RWS URI))

scpScope = ("SCP-FQDN:" RWS fqdn)

seppScope = ("SEPP-FQDN:" RWS fqdn)

See clause 6.4.3.4.5. The nfinst, nfset, nfservinst, nfserviceset and servname parameters are defined in clause 5.2.3.2.5. fqdn shall encode an FQDN. URI is defined in clause 3 of IETF RFC 3986 [14].

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.

NOTE 1: Implementations complying with earlier versions of the specification can signal overload control information of an NF service instance without including the NF-Inst parameter.

dnn = "DNN:" RWS 1*tchar *(RWS "&" RWS 1*tchar)

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 3GPP TS 23.003 [15].

sNssai= "S-NSSAI:" RWS snssai *(RWS "&" RWS snssai)

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

snssai = 1*tchar

S-NSSAI format is defined in clause 5.4.4.2 of 3GPP TS 29.571 [13]. It shall be encoded as the object format (i.e. not converted to the string pattern defined in clause 5.4.4.2 of 3GPP TS 29.571 [13]).

EXAMPLE 1: Overload Control Information for an NF Instance:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 75s; Overload-Reduction-Metric: 50%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8

EXAMPLE 2: Overload Control Information for an NF Service Set:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 50%; NF-Service-Set: setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345

EXAMPLE 3: Overload Control Information for an SMF instance related to a particular DNN of an S-NSSAI:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 600s; Overload-Reduction-Metric: 50%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs

NOTE 2: The S-NSSAI parameter corresponds to the JSON encoding: {"sst": 1, "sd": "A08923"} (see clause 5.2.3.1)

EXAMPLE 4: Overload Control Information for an SMF instance related to a particular DNN shared by two S-NSSAIs:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 240s; Overload-Reduction-Metric: 50%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08923%22%7D & %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08924%22%7D; DNN: internet.mnc012.mcc345.gprs

NOTE 3: The S- NSSAI parameter corresponds to the JSON encoding: {"sst": 1, "sd": "A08923"} & {"sst": 1, "sd": "A08924"} (see clause 5.2.3.1)

EXAMPLE 5: Overload Control Information sent by a NF service consumer with a scope set to a Callback-Uri:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 25%; Callback-Uri: https://pcf12.operator.com/serviceY

EXAMPLE 6: Overload Control Information sent by a NF service consumer with a scope set to a specific NF Instance and service:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 25%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; Service-Name: nsmf-pdusession

EXAMPLE 7: Overload Control Information sent by an SCP:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 25%; SCP-FQDN: scp1.example.com

EXAMPLE 8: Example with two OCI values, one for an SMF Instance and another one for a specific DNN of an S-NSSAI for the same SMF Instance:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 75s; Overload-Reduction-Metric: 50%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8
3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 600s; Overload-Reduction-Metric: 40%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs

NOTE 4: The S-NSSAI parameter corresponds to the JSON encoding: {"sst": 1, "sd": "A08923"} (see clause 5.2.3.1)

EXAMPLE 9: Overload Control Information sent by an SEPP:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 120s; Overload-Reduction-Metric: 25%; SEPP-FQDN: sepp1.example.com

NOTE 5: Example 8 is formatted as two distinct headers (which improves the readability), but it can also be formatted as a single header with two OCI values separated by a comma.

EXAMPLE 10: Overload Control Information for an NF Service Instance:

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Period-of-Validity: 75s; Overload-Reduction-Metric: 50%; NF-Service-Instance: xyz; NF-Inst: 54804518-4191-46b3-955c-ac631f953ed8

5.2.3.2.10 3gpp-Sbi-Lci

The header contains a comma-delimited list (see IETF RFC 7230 [12]) of Load Control Information (LCI). See clause 6.3.3.

The encoding of the header follows the ABNF as defined in IETF RFC 7230 [12].

3gpp-Sbi-Lci = "3gpp-Sbi-Lci:" 1#(RWS timestamp ";" RWS lcMetric ";" RWS lcScope)

timestamp = "Timestamp:" RWS DQUOTE date-time DQUOTE

Mandatory parameter. The date-time type is specified in IETF RFC 5322 [37] and clause 7.1.1.1 of IETF RFC 7231 [11]. It indicates the timestamp associated with the load control information.

lcMetric = "Load-Metric:" RWS (DIGIT / %x31-39 DIGIT / "100") "%"

Mandatory parameter. Load-Metric is up to 3 digits long decimal string and the value range shall be from 0 to 100.

lcScope = nfProducerScope / scpScope / seppScope

Mandatory structured parameter, which in the actual header is replaced by its sub-parameters.

scpScope = ("SCP-FQDN:" RWS fqdn)

seppScope = ("SEPP-FQDN:" RWS fqdn)

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.

NOTE 1: Implementations complying with earlier versions of the specification can signal load control information of an NF service instance without including the NF-Inst parameter.

dnn = "DNN:" RWS 1*tchar *(RWS "&" RWS 1*tchar)

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 3GPP TS 23.003 [15].

sNssai= "S-NSSAI:" RWS snssai *(RWS "&" RWS snssai)

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

snssai = 1*tchar

relativeCapacity = "Relative-Capacity:" RWS (1*2DIGIT / "100") "%"

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.

EXAMPLE 1: Load Control Information for an NF Instance:

3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8

EXAMPLE 2: Load Control Information for an NF Service Set:

3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; NF-Service-Set : setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345

EXAMPLE 3: Load Control Information for an SMF instance related to a particular DNN of an S-NSSAI (SST=1, SD="A08923"):

3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs; Relative-Capacity: 20%

EXAMPLE 4: Load Control Information for an SMF instance related to a particular S-NSSAI (SST=1, SD="A08923"):

NOTE 2: The S-Nssai parameter corresponds to the JSON encoding: {"sst": 1, "sd": "A08923"} (see clause 5.2.3.1)

EXAMPLE 5: Load Control Information for SCP:

3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; SCP-FQDN: scp1.example.com

EXAMPLE 6: Example with two LCI values, for different DNNs of a same S-NSSAI (SST=1, SD="A08923"):

3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 40%; NF-Instance=54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs; Relative-Capacity: 30%
3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 70%; NF-Instance=54804518-4191-46b3-955c-ac631f953ed8; S-NSSAI: %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08923%22%7D; DNN: ciot.mnc012.mcc345.gprs; Relative-Capacity: 20%

NOTE: The S-Nssai parameter corresponds to the JSON encoding: {"sst": 1, "sd": "A08923"} (see clause 5.2.3.1)

EXAMPLE 7: Load Control Information for SEPP:

3gpp-Sbi-Lci: Timestamp: "Tue, 04 Apr 2021 08:36:42 GMT"; Load-Metric: 25%; SEPP-FQDN: sepp1.example.com

NOTE 3: Example 6 is formatted as two distinct headers (which improves the readability), but it can also be formatted as a single header with two LCI values separated by a comma.

EXAMPLE 8: Load Control Information for an NF Service Instance:

3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; Load-Metric: 25%; NF-Service-Instance: xyz; NF-Inst: 54804518-4191-46b3-955c-ac631f953ed8

5.2.3.2.11 3gpp-Sbi-Client-Credentials

The header contains client credentials assertion (see clause 13.3.8.1 of 3GPP TS 33.501 [17]).

The encoding of the header follows the ABNF as defined in IETF RFC 7230 [12].

3gpp-Sbi-Client-Credentials header field = "3gpp-Sbi-Client-Credentials" ":" OWS string

The client credentials assertion shall be a JSON Web Token (JWT) as specified in IETF RFC 7519 [41], digitally signed using JWS as specified in IETF RFC 7515 [24] and in clause 13.3.8.1 of 3GPP TS 33.501 [15]. 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 clause 4.1.5 of IETF RFC 7515 [26]) 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 clause 4.1.5 of IETF RFC 7515 [26]) 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 clause 7.1 of IETF RFC 7515 [24].

Table 5.2.3.2.11 -1: Definition of type ClientCredentialsAssertion

Attribute name	Data type	P	Cardinality	Description
sub	NfInstanceId	M	1	This IE shall contain the NF instance ID of the NF service consumer, corresponding to the standard "Subject" claim described in IETF RFC 7519 [41], clause 4.1.2.
iat	integer	M	1	This IE shall indicate the time at which the JWT was issued, corresponding to the standard "Issued At" claim described in IETF RFC 7519 [41], clause 4.1.6. This claim may be used to determine the age of the JWT.
exp	integer	M	1	This IE shall contain the expiration time after which the client credentials assertion is considered to be expired, corresponding to the standard "Expiration Time" claim described in IETF RFC 7519 [41], clause 4.1.4.
aud	array(NFType)	M	1..N	This IE shall contain the NF type of the NF service producer and/or "NRF", for which the claim is applicable, corresponding to the standard "Audience" claim described in IETF RFC 7519 [41], clause 4.1.3.

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

ClientCredentialsAssertion:

description: The data structure for the client credentials assertion

type: object

required:

– sub

– iat

– exp

– aud

properties:

sub:

$ref: ‘TS29571_CommonData.yaml#/components/schemas/NfInstanceId’

iat:

type: integer

exp:

type: integer

aud:

type: array

items:

$ref: ‘TS29510_Nnrf_NFManagement.yaml#/components/schemas/NFType’

minItems: 1

5.2.3.2.12 3gpp-Sbi-Nrf-Uri

The header contains a list of NRF API URIs. See clauses 6.10.3.2 and 6.10.5.1.

The encoding of the header follows the ABNF as defined in IETF RFC 7230 [12].

3gpp-Sbi-Nrf-Uri= "3gpp-Sbi-Nrf-Uri" ":" parameter *( OWS ";" parameter)

parameter = parametername ":" RWS parametervalue

parametername = "nnrf-disc" / "nnrf-nfm" / "nnrf-oauth2" / "oauth2-requested-services" / token

NOTE: token is defined for future extensibility.

The parameter value shall comply with the following ABNF:

– for the nnrf-disc, nnrf-nfm and nnrf-oauth2 parameters:

parametervalue = DQUOTE URI DQUOTE

URI shall comply with the URI definition in IETF RFC 3986 [14].

– for the oauth2-requested-services parameter:

parametervalue = (nrfServiceName * ("&" RWS nrfServiceName))

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.

EXAMPLE 1: Header with NRF NF Discovery, NF Management and Access Token API URIs, without indication on whether OAuth2-based authorization is required to access the NRF services:

3gpp-Sbi-Nrf-Uri: nnrf-disc: "https://nrf1.operator.com/nnrf-disc/v1"; nnrf-nfm: "https://nrf1.operator.com/nnrf-nfm/v1"; nnrf-oauth2: "https://nrf1.operator.com/oauth2"

EXAMPLE 2: Header with NRF NF Discovery, NF Management and Access Token API URIs, indication on whether OAuth2-based authorization is required to access the NRF services:

3gpp-Sbi-Nrf-Uri: nnrf-disc: "https://nrf1.operator.com/nnrf-disc/v1"; nnrf-nfm: "https://nrf1.operator.com/nnrf-nfm/v1"; nnrf-oauth2: "https://nrf1.operator.com/oauth2"; oauth2-requested-services: nnrf-disc & nnrf-nfm-oauth2

5.2.3.2.13 3gpp-Sbi-Target-Nf-Id

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 IETF RFC 7230 [12].

3gpp-Sbi-Target-Nf-Id = "3gpp-Sbi-Target-Nf-Id" ":" OWS "nfinst=" nfInstanceIdvalue [ ";" OWS "nfservinst=" nfServiceInstanceIdvalue]

The following parameters are defined:

– nfinst (NF instance): indicates a NF Instance ID, as defined in 3GPP TS 29.510 [8];

– nfservinst (NF service instance): indicates a NF Service Instance ID, as defined in 3GPP TS 29.510 [8];

EXAMPLE: 3gpp-Sbi-Target-Nf-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfservinst=xyz

5.2.3.2.14 3gpp-Sbi-Max-Forward-Hops

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 IETF RFC 7230 [12].

3gpp-Sbi-Max-Forward-Hops = "3gpp-Sbi-Max-Forward-Hops" ":" OWS (DIGIT / %x31-39 DIGIT) ";" OWS "nodetype=" nodetypevalue

nodetypevalue = "scp"

EXAMPLE: Allowed up to 5 SCP hops to relay the request:

3gpp-Sbi- Max-Forward-Hops: 5; nodetype=scp.

5.2.3.2.15 3gpp-Sbi-Originating-Network-Id

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 IETF RFC 7230 [12].

3gpp-Sbi-Originating-Network-Id = "3gpp-Sbi-Originating-Network-Id" ":" RWS 3*3DIGIT "-" 2*3DIGIT ["-" 11*11HEXDIGIT] [";" OWS srcinfo]

srcinfo = "src" ":" RWS srctype "-" srcfqdn

srctype = "SCP" / "SEPP"

srcfqdn = 4*( ALPHA / DIGIT / "-" / "." )

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.

EXAMPLE 1: For a source PLMN:

3gpp-Sbi-Originating-Network-Id: 123-45

EXAMPLE 2: For a source PLMN and the header included by SEPP under the condition when the value of the header is derived based on the configuration and inserted by the SEPP:

3gpp-Sbi-Originating-Network-Id: 123-45; src: SEPP-sepp001.sepp.5gc.mnc045.mcc123.3gppnetwork.org

EXAMPLE 3: For a source SNPN:

3gpp-Sbi-Originating-Network-Id: 123-45-000007ed9d5

5.2.3.2.16 3gpp-Sbi-Access-Scope

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 IETF RFC 7230 [12].

3gpp-Sbi-Access-Scope = "3gpp-Sbi-Access-Scope" ":" OWS scope-token *(SP scope-token)

Scope-token = 1*NQCHAR

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 [22].

NOTE 1: This corresponds to the "scope" syntax defined for OAuth in clauses 3.3 and A.4 of IETF RFC 6749 [22] and also to the syntax of the "scope" parameter in AccessTokenReq in 3GPP TS 29.510 [8]. This enables the SCP to set the scope parameter in the Nnrf_Get Access Token Request to the value of the 3gpp-Sbi-Access-Scope header received in an incoming service request, or to 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 (as registered in its NF profile).

NOTE 2: For indirect communication with delegated discovery (see clause 6.10.11.2), for a specific resource / operation for which the API defines a resource/operation-level scope, the NF service consumer does not and need not know whether the NF service producer is configured to require the resource/operation level scope or not. The setting of the 3gpp-Sbi-Access-Scope header is the same regardless of whether the NF service producer is configured to require the resource/operation level scope or not.

EXAMPLE: 3gpp-Sbi-Access-Scope: nhss-ims-uecm nhss-ims-uecm:authorize:invoke

5.2.3.2.17 3gpp-Sbi-Access-Token

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 IETF RFC 7230 [12].

3gpp-Sbi-Access-Token = "3gpp-Sbi-Access-Token" ":" OWS credentials

See Appendix C of IETF RFC 7235 [21] for the definition of "credentials".

NOTE: The 3gpp-Sbi-Access-Token header is encoded as the Authorization header.

5.2.3.2.18 Void

5.2.3.2.19 3gpp-Sbi-Target-Nf-Group-Id

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 IETF RFC 7230 [12].

3gpp-Sbi-Target-Nf-Group-Id = "3gpp-Sbi-Target-Nf-Group-Id" ":" OWS "nfgid=" nfGroupIdvalue

The following parameter is defined:

– nfgid (NF Group ID): indicates a NF Group ID, as defined in 3GPP TS 29.571 [13].

EXAMPLE: 3gpp-Sbi-Target-Nf-Group-Id: nfgid="udm-group-15"

5.2.3.2.20 3gpp-Sbi-Nrf-Uri-Callback

The header contains the NRF API URI for NF discovery service. See clauses 6.5.3.2.

The encoding of the header follows the ABNF as defined in IETF RFC 7230 [12].

3gpp-Sbi-Nrf-Uri-Callback= "3gpp-Sbi-Nrf-Uri-Callback" ":" parameter *( OWS ";" parameter)

parameter = parametername ":" RWS parametervalue

parametername = "nnrf-disc"/ token

NOTE: token is defined for future extensibility.

parametervalue = DQUOTE URI DQUOTE

URI shall comply with the URI definition in IETF RFC 3986 [14].

EXAMPLE: Header with NRF NF Discovery Service:

3gpp-Sbi-Nrf-Uri-Callback: nnrf-disc: "https://nrf1.operator.com/nnrf-disc/v1"

5.2.3.2.21 3gpp-Sbi-NF-Peer-Info

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 IETF RFC 7230 [12].

3gpp-Sbi-NF-Peer-Info = "3gpp-Sbi-NF-Peer-Info" ":" OWS peerinfo *(";" OWS peerinfo)

peerinfo = peertype "=" token

The following peertype are defined:

– srcinst (Source NF instance): indicates the Source NF Instance ID, as defined in 3GPP TS 29.510 [8];

– srcservinst (Source NF service instance): indicates the Source NF Service Instance ID, as defined in 3GPP TS 29.510 [8]; 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 3GPP TS 29.510 [8];

– dstservinst (Destination NF service instance): indicates the Destination NF Service Instance ID, as defined in 3GPP TS 29.510 [8]; 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.

EXAMPLE: 3gpp-Sbi-NF-Peer-Info: srcinst=54804518-4191-46b3-955c-ac631f953ed8; dstinst=54804518-4191-4453-569c-ac631f74765cd

5.2.3.3 Optional to support custom headers

5.2.3.3.1 General

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.

Table 5.2.3.3-1: Optional HTTP custom headers

Name	Reference	Description
3gpp-Sbi-Sender-Timestamp	Clause 5.2.3.3.2	This header may be used to indicate the date and time (with a millisecond granularity) at which an HTTP request or response is originated. This may be used e.g. for measuring signalling delays between different NF service instances.
3gpp-Sbi-Max-Rsp-Time	Clause 5.2.3.3.3	This header may be used in a HTTP request to indicate the duration during which the HTTP client waits for a response. See clause 6.11.2.
3gpp-Sbi-Correlation-Info	Clause 5.2.3.3.4	This header may be used to contain correlation information (e.g. 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. See clause 6.13.
3gpp-Sbi-Alternate-Chf-Id	Clause 5.2.3.3.5	This header may be used to indicate a primary or secondary CHF instance, e.g. when using indirect communication with delegated discovery. See clause 6.10.3.5.
3gpp-Sbi-Request-Info	Clause 5.2.3.3.12	This header may be used to indicate additional information related to a HTTP request, e.g. if the request is involving a reselection towards an alternative NF, and/or if the request is a retransmission of a request towards an (alternative) NF. This header may be used in a non-idempotent HTTP request message to include an idempotency key to enable the receiver to detect possible duplicated request messages. See clause 5.2.8.
3gpp-Sbi-Notif-Accepted-Encoding	Clause 5.2.3.3.6	This header may be used to indicate the content encodings supported by the NF service Consumer when receiving notifications related to the subscriptions data conveyed by the HTTP request in which the header is included. See clause 6.9.2.1.
3gpp-Sbi-Consumer-Info	Clause 5.2.3.3.7	This header is used in a service request to create a subscription to indicate the API version(s) and feature(s) of the corresponding NF service(s) for the subscribed event(s) and the accepted encodings for notifications of the subscribed event(s), which are supported by the NF consumer. The NF consumer may include this header when subscribing to an intermediate NF for event(s) which may be detected and reported directly by a target NF, e.g. subscribe to Location Reporting event at AMF via UDM with AMF directly reporting the notifications to the NF consumer. See clause 6.2.2. The NF service consumer may include this header when providing a Callback URI when the authority part of the Callback URI is shared by several NF service consumer instances. See clause 6.12.1 for the usage of this parameter.
3gpp-Sbi-Response-Info	Clause 5.2.3.3.8	This header may be used to provide additional information related to an HTTP response, 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 (see clause 6.10.8.1); or – by an alternative HTTP server instance to indicate whether the resource/context has been transferred to the instance sending the response, or by an HTTP server instance to indicate that the failed request shall not be retried (see clause 6.10.3.4, 6.10.5.1 and 6.10.8.1).
3gpp-Sbi-Selection-Info	Clause 5.2.3.3.10	This header may be included in a HTTP request message for indirect communication and may be used by the SCP when performing the (re)selection of the target NF. See clauses 6.10.3.2 and 6.10.5.1.
3gpp-Sbi-Interplmn-Purpose	Clause 5.2.3.3.11	This header is used in HTTP request to indicate the intended purpose for inter-PLMN signaling. The HTTP client may include this header in HTTP request when the target NF is in a different PLMN, and if included shall set the intended purpose of the HTTP request. SEPP shall evaluate the contents of this header against the local policy and continue or reject the request if received. (see clause 6.14.3)

5.2.3.3.2 3gpp-Sbi-Sender-Timestamp

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 IETF RFC 7230 [12].

3gpp-Sbi-Sender-Timestamp = "3gpp-Sbi-Sender-Timestamp" ":" OWS day-name "," SP date1 SP time-of-day "." milliseconds SP GMT

milliseconds = 3DIGIT

day-name, date1, time-of-day shall comply with the definition in clause 7.1.1.1 of IETF RFC 7231 [11].

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.

NOTE: This is the same format as the Date header of clause 7.1.1.2 of IETF RFC 7231 [11], but with the time expressed with a millisecond granularity.

EXAMPLE: 3gpp-Sbi-Sender-Timestamp: Sun, 04 Aug 2019 08:49:37.845 GMT

5.2.3.3.3 3gpp-Sbi-Max-Rsp-Time

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 IETF RFC 7230 [12].

3gpp-Sbi-Max-Rsp-Time = "3gpp-Sbi-Max-Rsp-Time" ":" OWS 1*5DIGIT

EXAMPLE: 3gpp-Sbi-Max-Rsp-Time: 10000

5.2.3.3.4 3gpp-Sbi-Correlation-Info

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 IETF RFC 7230 [12].

3gpp-Sbi-Correlation-Info="3gpp-Sbi-Correlation-Info" ":" OWS correlationinfo *(";" OWS correlationinfo)

correlationinfo = ctype "-" cvalue

ctype = "imsi" / "impi" / "suci" / "nai" / "gci" / "gli" / "impu" / "msisdn" / "extid" / "imei" / "imeisv" / "mac" / "eui" / token

NOTE 1: Only one of each ctype can be included in the 3gpp-Sbi-Correlation-Info header; the possibility to include more than one of the same ctype is kept for future extensibility.

NOTE 2: token is defined for future extensibility. See clause 3.2.6 of IETF RFC 7230 [12] for the "token" type definition.

The token of ctype shall not use the dash ("-") character.

cvalue = 1*tchar

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

Table 5.2.3.3.4-1: cvalue format

ctype	Description
imsi	VarUeId format defined in Table 5.2.2‑1 of TS 29.571 [13] for IMSI and starting after the string "imsi-"
impi	imsUeId format defined in Table 6.1.3.2.2‑1 of TS 29.562 [45] for IMPI and starting after the string "impi-"
suci	SupiOrSuci format defined in Table 5.3.2‑1 of TS 29.571 [13] for SUCI and starting after the string "suci-"
nai	VarUeId format defined in Table 5.2.2‑1 of TS 29.571 [13] for NAI and starting after the string "nai-"
gci	VarUeId format defined in Table 5.2.2‑1 of TS 29.571 [13] for GCI and starting after the string "gci-"
gli	VarUeId format defined in Table 5.2.2‑1 of TS 29.571 [13] for GLI and starting after the string "gli-"
impu	imsUeId format defined in Table 6.1.3.2.2‑1 of TS 29.562 [45] for IMPU and starting after the string "impu-". Depending on whether the IMPU contains a SIP URI or a TEL URI, the corresponding pattern from the definition of imsUeId in Table 6.1.3.2.2‑1 of TS 29.562 [45] shall be used.
msisdn	VarUeId format defined in Table 5.2.2‑1 of TS 29.571 [13] for MSISDN and starting after the string "msisdn-"
extid	VarUeId format defined in Table 5.2.2‑1 of TS 29.571 [13] for External Identifier and starting after the string "extid-"
imei	Pei format defined in Table 5.3.2‑1 of TS 29.571 [13] for IMEI and starting after the string "imei-"
imeisv	Pei format defined in Table 5.3.2‑1 of TS 29.571 [13] for IMEISV and starting after the string "imeisv-"
mac	Pei format defined in Table 5.3.2‑1 of TS 29.571 [13] for MAC address and starting after the string "mac-"
eui	Pei format defined in Table 5.3.2‑1 of TS 29.571 [13] for IEEE Extended Unique Identifier (EUI-64) and starting after the string "eui-"

EXAMPLE 1: When UE identifier used is SUPI and SUPI type is an IMSI:

3gpp-Sbi-Correlation-Info: imsi-345012123123123

EXAMPLE 2: When UE identifier used is PEI and PEI type is an IMEISV:

3gpp-Sbi-Correlation-Info: imeisv-3550121231231230

EXAMPLE 3: When UE identifier used is PEI and PEI type is a MAC address:

3gpp-Sbi-Correlation-Info: mac-00-00-5E-00-53-00

EXAMPLE 4: When UE identifier used is GPSI and GPSI type is an MSISDN:

3gpp-Sbi-Correlation-Info: msisdn-1234567890

EXAMPLE 5: When UE identifier used is GPSI and GPSI type is an External Identifier:

3gpp-Sbi-Correlation-Info: extid-123456789@domain.com

EXAMPLE 6: When UE identifiers used are SUPI and GPSI where SUPI type is an IMSI and GPSI type is an MSISDN:

3gpp-Sbi-Correlation-Info: imsi-345012123123123; msisdn-1234567890

5.2.3.3.5 3gpp-Sbi-Alternate-Chf-Id

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 IETF RFC 7230 [12].

3gpp-Sbi-Alternate-Chf-Id = "3gpp-Sbi-Alternate-Chf-Id":" OWS "nfinst=" nfInstanceIdvalue ";" OWS ("primary" / "secondary")

nfInstanceIdvalue shall indicate an NF Instance ID, as defined in clause 5.2.2.2.2 in 3GPP TS 29.510 [8].

EXAMPLE 1: Service response from a primary CHF instance signalling a secondary CHF instance Id:

3gpp-Sbi-Alternate-Chf-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; secondary

EXAMPLE 2: Service response from a secondary CHF instance signalling a primary CHF instance Id:

3gpp-Sbi-Alternate-Chf-Id: nfinst=54804518-4191-46b3-955c-ac631f953ed8; primary

5.2.3.3.6 3gpp-Sbi-Notif-Accepted-Encoding

The header indicates the content encodings supported when receiving notifications related to the susbcriptions data conveyed by the HTTP request in which the header is included.

This header shall be compliant with Accept-Encoding header defined in IETF RFC 7231 [40] clause 5.3.4.

Example: 3gpp-Sbi-Notif-Accepted-Encoding: gzip;q=1.0, identity;q=0.5, *;q=0

5.2.3.3.7 3gpp-Sbi-Consumer-Info

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 IETF RFC 7230 [12].

3gpp-Sbi-Consumer-Info = "3gpp-Sbi-Consumer-Info" ":" 1#(OWS supportedService ";" OWS supportedVersions [";" OWS supportedFeatures] [";" OWS acceptEncoding] [";" OWS callback-uri-prefix]) [";" OWS intraPlmnCallbackRoot ";" OWS interPlmnCallbackRoot]

supportedService = "service=" servicename

servicename = 1*("-" / %x61–7A)

Mandatory parameter. Supported Service parameter indicates the name of a service, as defined in 3GPP TS 29.510 [8], which is supported by the sender as NF service consumer.

supportedVersions = "apiversion=" "(" OWS [ majorversion *(RWS majorversion) OWS] ")"

majorversion = %x31–39 [*DIGIT]

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 = "supportfeatures=" features

features = *HEXDIG

Optional parameter. Supported Features parameter carries a string containing a bitmask in hexadecimal representation, as specified for SupportedFeatures data type in 3GPP TS 29.571 [13], to indicate the feature(s) of the service API that are supported by the sender as NF service consumer.

acceptEncoding = "acceptencoding=" %x22 acceptencoding %x22

acceptencoding = #( codings [ weight ] )

token "codings" and "weight" are defined in IETF RFC 7231 [40] clause 5.3.4

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.

intraPlmnCallbackRoot = "intraPlmnCallbackRoot=" OWS scheme "://" authority [ prefix ]

interPlmnCallbackRoot = "interPlmnCallbackRoot=" OWS scheme "://" authority [ prefix ]

scheme = "http" / "https"

authority = host [ ":" port ]

port = *DIGIT

prefix = path-absolute ; path-absolute production rule from IETF RFC 3986 [14], clause 3.3

Optional parameter. intra plmn callback root and inter plmn callback root supported by the sender as NF service consumer.

callback-uri-prefix= " callback-uri-prefix=" OWS path-absolute ; path-absolute production rule from IETF RFC 3986 [14], clause 3.3.

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. When present, the "callback-uri-prefix" shall be a path-absolute as specified IETF RFC 3986 [14] (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.

EXAMPLE 1: The NF consumer supports Namf_EventExposure OpenAPI "v1" without any optional feature:

3gpp-Sbi-Consumer-Info: service=namf-evts; apiversion=(1)

EXAMPLE 2: The NF consumer supports Nsmf_EventExposure OpenAPI "v1" and "v2" with optional feature number 1 and accepted encoding "gzip":

3gpp-Sbi-Consumer-Info: service=nsmf-event-exposure; apiversion=(1 2); supportedfeatures=01; acceptencoding="gzip; q=1.0, *;q=0.5"

EXAMPLE 3: The NF consumer supports both Namf_EventExposure OpenAPI "v1" and Nsmf_EventExposure OpenAPI "v2":

3gpp-Sbi-Consumer-Info: service=namf-evts; apiversion=(1), service=nsmf-event-exposure; apiversion=(2)

EXAMPLE 4: An AMF service instance supports Nsmf_PDUSession OpenAPI "v1", provides the callback URI https://amf45.operator.com/servinst123/pdusession, whereby the authority is shared by more than one AMF service instance, while the prefix "/servinst123" uniquely identifies a specific AMF service instance:

3gpp-Sbi-Consumer-Info: service=nsmf-pdusession; apiversion=(1); callback-uri-prefix=%2Fservinst123

EXAMPLE 5: The NF consumer supports Namf_EventExposure OpenAPI "v1" and sends intra PLMN callback root "https://operator.com" and inter PLMN callback root "https://5gc.mnc012.mcc345.3gppnetwork.org" in the header:

3gpp-Sbi-Consumer-Info: service=namf-evts; apiversion=(1); intraPlmnCallbackRoot= https%3A%2F%2Foperator.com; interPlmnCallbackRoot= https%3A%2F%2F5gc.mnc012.mcc345.3gppnetwork.org

5.2.3.3.8 3gpp-Sbi-Response-Info

The header contains a comma-delimited 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 IETF RFC 7230 [12].

3gpp-Sbi-Response-Info = "3gpp-Sbi-Response-Info" ":" 1#(OWS parameter [*(";" OWS parameter)])

parameter = parametername "=" RWS parametervalue

parametername = "request-retransmitted" / "nfinst" / "nfset" / "nfservinst" / "nfserviceset" / "context-transferred" / "no-retry" / token

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.

NOTE: Additional parameters can be defined in future versions of the specification.

EXAMPLE 1: 3gpp-Sbi-Response-Info: request-retransmitted=true

EXAMPLE 2: 3gpp-Sbi-Response-Info: request-retransmitted=true; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfinst=54804518-4191-46b3-955c-ac631f953456; nfinst=54804518-4191-46b3-955c-ac631f953780

EXAMPLE 3: 3gpp-Sbi-Response-Info: context-transferred=false; no-retry=true

5.2.3.3.9 Void

5.2.3.3.10 3gpp-Sbi-Selection-Info

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 IETF RFC 7230 [12].

3gpp-Sbi-Selection-Info = "3gpp-Sbi-Selection-Info" ":" 1#([OWS "reselection=" reselectionvalue] [1*(";" OWS selection-criteria)])

reselectionvalue = "true" / "false"

selection-criteria = selection-criteria "=" token

selection-criteria = "not-select-nfservinst" / "not-select-nfserviceset" / "not-select-nfinst" / "not-select-nfset"

– 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 in 3GPP TS 23.003 [15]. 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 in 3GPP TS 29.510 [8]. 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 3GPP TS 23.003 [15]. 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.

EXAMPLE 1: The SCP may or may not perform reselection, but when doing reselection, it shall not select NF instance as identified by 87654321-4191-46b3-955c-ac631f953ed8.

3gpp-Sbi-Selection-Info: not-select-nfinst=87654321-4191-46b3-955c-ac631f953ed8

EXAMPLE 2: The SCP may or may not perform reselection, but when doing reselection, it shall not select NF service set in the NF instance (as identified in nfi87654321-4191-46b3-955c-ac631f953ed8).

3gpp-Sbi-Selection-Info: not-select-nfserviceset=setxyz.snnsmf-pdusession.nfi87654321-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345;

EXAMPLE 3: The SCP shall perform reselection; and when doing reselection, it shall not select NF instance as identified by 87654321-4191-46b3-955c-ac631f953ed8.

3gpp-Sbi-Selection-Info: reselection=true; not-select-nfinst=87654321-4191-46b3-955c-ac631f953ed8

EXAMPLE 4: The SCP shall perform reselection; and when doing reselection, the SCP shall not select NF service instance xyz1 and xyz2 in the NF instance identified by 87654321-4191-46b3-955c-ac631f953ed8, and NF service instance abc1 and abc2 in the NF instance identified by 12345678-4191-46b3-955c-ac631f953ed8.

3gpp-Sbi-Selection-Info: reselection=true; not-select-nfservinst=xyz1; not-select-nfservinst=xyz2; not-select-nfinst=87654321-4191-46b3-955c-ac631f953ed8, reselection=true; not-select-nfservinst=abc1; not-select-nfservinst=abc2; not-select-nfinst=12345678-4191-46b3-955c-ac631f953ed8

5.2.3.3.11 3gpp-Sbi-Interplmn-Purpose

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 IETF RFC 7230 [12].

3gpp-Sbi-Interplmn-Purpose = "3gpp-Sbi-Interplmn-Purpose" ":" N32Purpose ":" OWS ": additional_info

additional_info = token

– N32Purpose: The parameter for N32Purpose indicates the intended purpose of inter-PLMN signaling, and values specified in 3GPP TS 29.573 [27] clause 6.1.5.3.9 are used.

EXAMPLE: 3gpp-Sbi-Interplmn-Purpose: ROAMING: usecaseA

5.2.3.3.12 3gpp-Sbi-Request-Info

The header contains a comma-delimited 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 IETF RFC 7230 [12].

3gpp-Sbi-Request-Info = "3gpp-Sbi-Request-Info" ":" 1#(OWS parameter [*(";" OWS additionalparameter)])

parameter = parametername "=" RWS parametervalue

parametername = "retrans" / "redirect" / "reason" / "idempotency-key" / token

additionalparameter = "receivedrejectioncause" / token

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 3GPP TS 29.571 [13].

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

– idempotency-key: it is a string and may be encoded using Universally Unique Identifier (UUID), as described in IETF RFC 4122 [47], to uniquely identify a request message (to be received) in the target NF. See clause 5.2.8.

EXAMPLE 1: For a request retransmitted to an alternative NF due to the rejection by the original target NF with a temporary rejection cause:

3gpp-Sbi-Request-Info: retrans=true; redirect=true; reason=temporary-rejection-cause; receivedrejectioncause=INSUFFICIENT_RESOURCES

EXAMPLE 2: For a request sent towards an alternative NF due to the original target NF not reachable:

3gpp-Sbi-Request-Info: redirect=true; reason=unreachable

EXAMPLE 3: For a non-idempotent request:

3gpp-Sbi-Request-Info: idempotency-key=54804518-4191-46b3-955c-ac631f953ed8

5.2.4 HTTP error handling

HTTP/2 connection error and stream error shall be supported as specified in clause 5.4 of IETF RFC 7540 [7].

Guidelines for error responses to the invocation of APIs of NF services are specified in clause 4.8 of 3GPP TS 29.501 [3]. API specific error responses are specified in the respective technical specifications.

5.2.5 HTTP/2 server push

HTTP/2 Server Push as specified in clause 8.2 of IETF RFC 7540 [7] may be supported and may be used by a NF Service Producer to proactively push resources to a NF Service Consumer, see clause 4.9.5 of 3GPP TS 29.501 [5].

A NF Service Consumer may choose to disable HTTP/2 Server Push by setting SETTINGS_ENABLE_PUSH to 0, as specified in clause 8.2 of IETF RFC 7540 [7].

5.2.6 HTTP/2 connection management

The HTTP request / response exchange mechanism as specified in clause 8.1 of IETF RFC 7540 [7] shall be supported between the 3GPP NFs. An HTTP/2 endpoint shall support establishing multiple HTTP/2 connections (at least two) towards a peer HTTP/2 endpoint. The peer HTTP/2 endpoint is identified by host and port pair where the host is derived from the target URI (see clause 6.1.1).

NOTE 1: HTTP/2 connection redundancy allows transporting messages through diverse IP paths and improve 5GC resiliency.

As per clause 8.1 of IETF RFC 7540 [7] a HTTP request / response exchange fully consumes a single stream. When the HTTP/2 Stream IDs on a given HTTP/2connection is exhausted, an HTTP/2 endpoint, shall establish another HTTP/2connection towards that peer HTTP/2 endpoints.

NOTE 2: As per IETF RFC 7540 [7], a stream ID once closed cannot be reused on the same HTTP/2 connection.

The 3GPP NF shall take care to avoid simultaneous stream ID exhaustion on all the available HTTP/2 connections towards each peer.

The 3GPP NF shall support gracefully shutdown of a HTTP/2 connection by sending a GOAWAY frame with "Error Code" field set to "NO_ERROR (0x0)". The HTTP connection should remain "open" (by the sender and receiver of GOAWAY frame) until all in-progress streams numbered lower or equal to the last stream identifier indicated by the "Last-Stream-Id" field in the GOAWAY frame are completed. See clause 6.8 of IETF RFC 7540 [7].

An NF acting as an HTTP/2 client shall support testing whether a connection is still active by sending a PING frame. An NF acting as an HTTP/2 server may test whether a connection is still active by sending a PING frame. An NF acting as an HTTP/2 client or server shall respond to received PING frames as specified in clause 6.7 of IETF RFC 7540 [7]. When and how often a PING frame may be sent is implementation specific but shall be configurable by operator policy. When HTTP server detects the connection failure, it shall follow connection error handling as defined in clause 5.4.1 of RFC 7540 [7].

NOTE 1: The above requirement also applies to network entities such as SCP and SEPP.

A PING frame shall not be sent more often than every 60 s on each path.

5.2.7 HTTP status codes

5.2.7.1 General

This clause describes the HTTP status codes usage on SBI.

HTTP status codes are carried in ":status" pseudo header field in HTTP/2, as defined in clause 8.1.2.4 in IETF RFC 7540 [7].

Table 5.2.7.1-1 specifies HTTP status codes per HTTP method which shall be supported on SBI. Support of an HTTP status code shall be:

– mandatory, which is marked in table as "M". This means that all 3GPP NFs shall support the processing of the specific HTTP status code for the specific HTTP method, when received in a HTTP response message. In such cases the 3GPP NF shall also support the handling of the "ProblemDetails" JSON object with the Content-Type header field set to the value "application/problem+json" for HTTP status codes 4xx and 5xx, if the corresponding API definition in the related technical specification does not specify another response body for the corresponding status code;

– service specific, which is marked in table as "SS" and means that the requirement to process the HTTP status code depends on the definition of the specific API; or

– not applicable, which is marked in table as "N/A". This means that the specific HTTP status code shall not be used for the specific HTTP method within the 3GPP NFs.

Table 5.2.7.1-1: HTTP status code supported on SBI

HTTP status code	HTTP method
HTTP status code	DELETE	GET	PATCH	POST	PUT	OPTIONS
100 Continue	N/A	N/A	N/A	N/A	N/A	N/A
200 OK (NOTE 1, NOTE 2)	SS	M	SS	SS	SS	M
201 Created	N/A	N/A	N/A	SS	SS	N/A
202 Accepted	SS	N/A	SS	SS	SS	N/A
204 No Content (NOTE 2)	M	N/A	SS	SS	SS	SS
300 Multiple Choices	N/A	N/A	N/A	N/A	N/A	N/A
303 See Other	SS	SS	N/A	SS	SS	N/A
307 Temporary Redirect	SS	SS	SS	SS	SS	SS
308 Permanent Redirect	SS	SS	SS	SS	SS	SS
400 Bad Request	M	M	M	M	M	M
401 Unauthorized	M	M	M	M	M	M
403 Forbidden	M	M	M	M	M	M
404 Not Found	M	M	M	M	M	M
405 Method Not Allowed	SS	SS	SS	SS	SS	SS
406 Not Acceptable	N/A	M	N/A	N/A	N/A	SS
408 Request Timeout	SS	SS	SS	SS	SS	SS
409 Conflict	N/A	SS	SS	SS	SS	N/A
410 Gone	SS	SS	SS	SS	SS	SS
411 Length Required	N/A	N/A	M	M	M	SS
412 Precondition Failed	SS	SS	SS	SS	SS	N/A
413 Payload Too Large	N/A	N/A	M	M	M	SS
414 URI Too Long	N/A	SS (NOTE 3)	N/A	N/A	SS	N/A
415 Unsupported Media Type	N/A	N/A	M	M	M	SS
429 Too Many Requests	M	M	M	M	M	M
500 Internal Server Error	M	M	M	M	M	M
501 Not Implemented	SS	SS	SS	SS	SS	SS
502 Bad Gateway	M	M	M	M	M	M
503 Service Unavailable	M	M	M	M	M	M
504 Gateway Timeout	SS	SS	SS	SS	SS	SS
NOTE 1: "200 OK" response used on SBI shall contain body. NOTE 2: If the NF acting as an HTTP Client receives 2xx response code not appearing in table, the NF shall treat the received 2xx response: – as "204 No Content" if 2xx response does not contain body; and – as "200 OK" if 2xx response contains body. NOTE 3: If GET method includes any query parameter, the NF acting as an HTTP Client shall support "414 URI Too Long" status code.

5.2.7.2 NF as HTTP Server

A NF acting as an HTTP server shall be able to generate HTTP status codes specified in clause 5.2.7.1 per indicated HTTP method.

A request using an HTTP method which is not supported by any resource of a given 5GC SBI API shall be rejected with the HTTP status code "501 Not Implemented".

NOTE 1: In this case, the NF does not need to include in the HTTP response the "cause" attribute indicating corresponding error since the HTTP status code "501 Not Implemented" itself provides enough information of the error, i.e. the NF does not recognize the HTTP method.

If the specified target resource does not exist, the NF shall reject the HTTP method with the HTTP status code "404 Not Found".

If the NF supports the HTTP method for several resources in the API, but not for the target resource of a given HTTP request, the NF shall reject the request with the HTTP status code "405 Method Not Allowed" and shall include in the response an Allow header field containing the supported method(s) for that resource.

NOTE 2: In this case, the NF does not need to include in the HTTP response the "cause" attribute indicating corresponding error since the HTTP status code "405 Method Not Allowed" itself provides enough information of the error and hence the Allow header field lists HTTP method(s) supported by the target resource.

If a received HTTP request contains unknown IEs, i.e. Information Elements within the JSON body, the NF may discard such IEs and shall process the rest of the request message, unless the schema definition of the received message prohibits the presence of additional IEs or constrains their types. There are cases (e.g. Nnrf_NFManagement API) where the receiver of certain HTTP requests needs to process unknown IEs (e.g. to store in NRF an NF Profile containing vendor-specific attributes, and send them in NFDiscovery results).

If a received HTTP request contains IEs or query parameters not compliant with the schema defined in the corresponding OpenAPI specification, the NF should reject the request with the appropriate error code, e.g. "400 Bad Request (INVALID_MSG_FORMAT)", even when the failed IEs are defined as optional by the schema.

If a received HTTP PATCH request contains a body with modification instruction(s) for unknown attribute(s) in addition to modification instruction(s) for known attribute(s), the NF shall:

a) implement all the modification(s) for known attribute(s) and unknown attribute(s) if explicitly specified in the corresponding specification of the API; or

b) otherwise, implement the modification(s) for known attribute(s) and discard those modification instruction(s) for unknown attribute(s). The NF may additionally indicate in the response the result of the execution of the PATCH request, i.e. which modification(s) are implemented and/or which modification(s) are discarded, using the "PatchResult" JSON object as defined in 3GPP TS 29.571 [13].

If the NF supports the HTTP method by a target resource but the NF cannot successfully fulfil the received request, the following requirements apply.

A NF as HTTP Server should map status codes to the most similar 3xx/4xx/5xx HTTP status code specified in table 5.2.7.1-1. If no such code is applicable, it should use "400 Bad Request" status code for errors caused by client side or "500 Server Internal Error" status code for errors caused on server side.

If the received HTTP request contains unsupported payload format, the NF shall reject the HTTP request with the HTTP status code "415 Unsupported Media Type". If the HTTP PATCH method is rejected due to unsupported patch document, the NF shall include the Accept-Patch header field set to the value of supported patch document media types for a target resource i.e. to "application/merge-patch+json" if the NF supports "JSON Merge Patch" and to "application/json-patch+json" if the NF supports "JSON Patch". If the received HTTP PATCH request contains both "JSON Merge Patch" and "JSON Patch" documents and the NF supports only one of them, the NF shall ignore unsupported patch document.

NOTE 3: The format problem might be due to the request’s indicated Content-Type or Content-Encoding header fields, or as a result of inspecting the payload body directly.

If the received HTTP request contains payload body larger than the NF is able to process, the NF shall reject the HTTP request with the HTTP status code "413 Payload Too Large".

If the result of the received HTTP POST request used for a resource creation would be equivalent to the existing resource, the NF shall reject the HTTP request with the HTTP status code "303 See Other" and shall include in the HTTP response a Location header field set to the URI of the existing resource.

Protocol and application errors common to several 5GC SBI API specifications for which the NF shall include in the HTTP response a payload body ("ProblemDetails" data structure or application specific error data structure) with the "cause" attribute indicating corresponding error are listed in table 5.2.7.2-1.

Table 5.2.7.2-1: Protocol and application errors common to several 5GC SBI API specifications (HTTP server)

Protocol or application Error	HTTP status code	Description
INVALID_API	400 Bad Request	The HTTP request contains an unsupported API name or API version in the URI.
INVALID_MSG_FORMAT	400 Bad Request	The HTTP request has an invalid format.
INVALID_QUERY_PARAM	400 Bad Request	The HTTP request contains an unsupported query parameter in the URI. (NOTE 1)
MANDATORY_QUERY_PARAM_INCORRECT	400 Bad Request	A mandatory query parameter, or a conditional query parameter but mandatory required, for an HTTP method was received in the URI with semantically incorrect value. (NOTE 1)
OPTIONAL_QUERY_PARAM_INCORRECT	400 Bad Request	An optional query parameter for an HTTP method was received in the URI with a semantically incorrect value that prevents successful processing of the service request. (NOTE 1)
MANDATORY_QUERY_PARAM_MISSING	400 Bad Request	Query parameter which is defined as mandatory, or as conditional but mandatory required, for an HTTP method is not included in the URI of the request. (NOTE 1)
MANDATORY_IE_INCORRECT	400 Bad Request	A mandatory IE (within the JSON body or within a variable part of an "apiSpecificResourceUriPart" or within an HTTP header), or conditional IE but mandatory required, for an HTTP method was received with a semantically incorrect value. (NOTE 1)
OPTIONAL_IE_INCORRECT	400 Bad Request	An optional IE (within the JSON body or within an HTTP header) for an HTTP method was received with a semantically incorrect value that prevents successful processing of the service request. (NOTE 1)
MANDATORY_IE_MISSING	400 Bad Request	A mandatory IE (within the JSON body or within the variable part of an "apiSpecificResourceUriPart" or within an HTTP header), or conditional IE but mandatory required, for an HTTP method is not included in the request. (NOTE 1)
UNSPECIFIED_MSG_FAILURE	400 Bad Request	The request is rejected due to unspecified client error. (NOTE 2)
RESOURCE_CONTEXT_NOT_FOUND	400 Bad Request	The notification request is rejected because the callback URI still exists in the receiver of the notification, but the specific resource context identified within the notification payloadis not found in the NF service consumer.
CCA_VERIFICATION_FAILURE	403 Forbidden	The request is rejected due to a failure to verify the CCA at the receiving entity (e.g. NRF or NF service producer).
TOKEN_CCA_MISMATCH	403 Forbidden	The request is rejected due to a mismatch between the subject claim in the access token and subject claim in the CCA.
MODIFICATION_NOT_ALLOWED	403 Forbidden	The request is rejected because the contained modification instructions attempt to modify IE which is not allowed to be modified.
SUBSCRIPTION_NOT_FOUND	404 Not Found	The request for modification or deletion of subscription is rejected because the subscription is not found in the NF.
RESOURCE_URI_STRUCTURE_NOT_FOUND	404 Not Found	The request is rejected because a fixed part after the first variable part of an "apiSpecificResourceUriPart" (as defined in clause 4.4.1 of 3GPP TS 29.501 [5]) is not found in the NF. This fixed part of the URI may represent a sub-resource collection (e.g. contexts, subscriptions, policies) or a custom operation. (NOTE 5)
INCORRECT_LENGTH	411 Length Required	The request is rejected due to incorrect value of a Content-length header field.
NF_CONGESTION_RISK	429 Too Many Requests	The request is rejected due to excessive traffic which, if continued over time, may lead to (or may increase) an overload situation of the NF instance. (NOTE 7)
NF_SERVICE_CONGESTION_RISK	429 Too Many Requests	The request is rejected due to excessive traffic which, if continued over time, may lead to (or may increase) an overload situation of the NF service instance. (NOTE 7)
INSUFFICIENT_RESOURCES	500 Internal Server Error	The request is rejected due to insufficient resources.
UNSPECIFIED_NF_FAILURE	500 Internal Server Error	The request is rejected due to unspecified reason at the NF. (NOTE 3)
SYSTEM_FAILURE	500 Internal Server Error	The request is rejected due to generic error condition in the NF.
NF_FAILOVER	500 Internal Server Error	The request is rejected due to the unavailability of the NF, and the requester may trigger an immediate re-selection of an alternative NF based on this information. (NOTE 6) (NOTE 8).
NF_SERVICE_FAILOVER	500 Internal Server Error	The request is rejected due to the unavailability of the NF service, and the requester may trigger an immediate re-selection of an alternative NF service based on this information. (NOTE 6) (NOTE 8).
INBOUND_SERVER_ERROR	502 Bad Gateway	The request is rejected due to the receipt of an 5xx error from an inbound server that the NF Service Producer accessed while attempting to fulfil the request (see clause 6.4.2.1).
NF_CONGESTION	503 Service Unavailable	The NF instance experiences congestion and performs overload control, which does not allow the request to be processed. (NOTE 4) (NOTE 7)
NF_SERVICE_CONGESTION	503 Service Unavailable	The NF service instance experiences congestion and performs overload control, which does not allow the request to be processed. (NOTE 4) (NOTE 7)
TARGET_NF_NOT_REACHABLE	504 Gateway Timeout	The request is not served as the target NF is not reachable. (NOTE 6)
TIMED_OUT_REQUEST	504 Gateway Timeout	The request is rejected due a request that has timed out at the HTTP client (see clause 6.11.2).
NOTE 1: "invalidParams" attribute shall be included in the "ProblemDetails" data structure indicating unsupported, missing or incorrect IE(s) or query parameter(s) or 3gpp-Sbi-Discovery-* header(s). NOTE 2: This application error indicates error in the HTTP request and there is no other application error value that can be used instead. NOTE 3: This application error indicates error condition in the NF and there is no other application error value that can be used instead. NOTE 4: If the reason for rejection is a temporary overload, the NF may include in the response a Retry-After header field to indicate how long the service is expected to be unavailable. NOTE 5: If the request is rejected because of an error in an URI before the first variable part of an "apiSpecificResourceUriPart", the "404 Not Found" HTTP status code may be sent without "ProblemDetails" data structure indicating protocol or application error. NOTE 6: The NF service consumer (as receiver of the cause code) should stop sending subsequent requests addressing the resource contexts in the producer’s NF instance (for NF_FAILOVER) or NF service instance (for NF_SERVICE_FAILOVER) to avoid massive rejections. The NF service consumer may reselect an alternative NF service producer as specified clause 6.5 of 3GPP TS 23.527 [38], e.g. using the Binding Indication of resource context. It is implementation specific for the NF service consumer to determine when and whether the NF producer becomes available again, e.g. when there is no other alternative available or at expiry of a local configured timer. NOTE 7: When a NF service producer receives NF_CONGESTION_RISK, NF_SERVICE_CONGESTION_RISK, NF_CONGESTION and NF_SERVICE_CONGESTION from a NF service consumer when sending a request message towards a callback/notification URI, the NF service producer shall identify the NF service consumer that is congested using either the authority of the notification/callback URI or together with the "callback-uri-prefix" if it is provided in 3gpp-Sbi-consumer-info as specified in clause 5.2.3.3.7. NOTE 8: The NF service producer (as receiver of the cause code) should stop sending subsequent notification requests addressing the session contexts towards the consumer NF (service) instance to avoid massive rejections, where the consumer NF (service) instance shall be identified by either the authority of the notification/callback URI or together with the "callback-uri-prefix" if it is provided in 3gpp-Sbi-consumer-info as specified in clause 5.2.3.3.7. The NF service producer may reselect an alternative NF service consumer as specified in clause 6.6 of 3GPP TS 23.527 [38], e.g. using the Binding Indication of the session context. It is implementation specific for the NF service producer to determine when and whether the NF consumer becomes available again, e.g. when there is no other alternative available or at expiry of a local configured timer. Note that if a consumer NF service instance complying with an earlier version of the specification shares the same authority with other consumer NF service instances and sends the NF_FAILOVER and NF_SERVICE_FAILOVER causes to a NF service producer while not supporting the new callback-uri-prefix parameter in 3gpp-Sbi-consumer-info, this can result in the NF service producer no longer sending traffic to these consumer NF service instances sharing the same authority.

5.2.7.3 NF as HTTP Client

Besides the HTTP Status Codes defined in the API specification, a NF as HTTP client should support handling of 1xx, 3xx, 4xx and 5xx HTTP Status Codes specified in table 5.2.7.1-1, following the client behaviour in corresponding IETF RFC where the received HTTP Status Code is defined.

When receiving a not recommended or not recognized 1xx, 3xx, 4xx or 5xx HTTP Status Code, a NF as HTTP client should treat it as x00 status code of the class, as described in clause 6 of IETF RFC 7231 [11].

If 100, 200/204, 300, 400 or 500 response code is not defined by the API specification, the client may follow guidelines below:

a) For 1xx (Informational):

1) Discard the response and wait for final response.

b) For 2xx (Successful):

1) Consider the service operation is successful if no mandatory information is expected from the response payload in subsequent procedure.

2) If mandatory information is expected from response payload in subsequent procedure, parse the payload following description in clause 6.2.1 of IETF RFC 7231 [11]. If parse is successful and mandatory information is extracted, continue with subsequent procedure.

3) Otherwise, consider service operation has failure and start failure handling.

c) For 3xx (Redirection):

1) Retry the request towards the directed resource referred in the Location header, using same request method.

d) For 4xx (Client Error):

1) Validate the request message and make correction before resending. Otherwise, stop process and go to error handling procedure.

e) For 5xx (Server Error):

1) Stop process and go to error handling process.

The handling of unknown, unexpected or erroneous HTTP request message IEs shall provide for the forward compatibility of the HTTP APIs used for the service-based interfaces. Therefore, the sending HTTP entity shall be able to safely include in a message a new optional IE. Such an IE may also have a new type. A receiving HTTP entity shall behave as specified in clause 5.2.7.2.

If a received HTTP response message contains unknown IEs (Information Elements within the JSON body), the NF may discard those IEs and it shall process the rest of the response message, as long as it is compliant with the OpenAPI schema definition of such response message.

If a received HTTP response message contains IEs not compliant with the schema defined in the corresponding OpenAPI specification (e.g., because the schema of the response body prohibits the presence of additional IEs or constrains their types), the NF shall stop processing such response message and go to error handling process.

5.2.7.4 SCP/SEPP

The SCP or SEPP shall be able to forward the HTTP status codes defined in Table 5.2.7.2-1 from HTTP Server to HTTP client. In addition, it shall be able to generate HTTP status codes to indicate failures during indirect communication (e.g. see clauses 6.10.3.2 and 6.10.6), error handling (see clause 6.10.8), detection and handling of loop path (see clause 6.10.10) and SCP or SEPP overload control (see clause 6.4) as defined in Table 5.2.7.4-1 and Table 5.2.7.4-2.

If the SCP or SEPP detects a loop in the routing path of an HTTP request, it should reject the request with the HTTP status code "400 Bad Request (MSG_LOOP_DETECTED)".

If the received HTTP request contains payload body larger than the SCP or SEPP is able to process, the SCP or SEPP shall reject the HTTP request with the HTTP status code "413 Payload Too Large".

An HTTP status code "429 Too Many Requests (NF_CONGESTION_RISK)" is sent, when the SCP or SEPP detects that a given NF Service Consumer is sending excessive traffic which, if continued over time, may lead to (or may increase) an overload situation in the SCP or SEPP. If the SCP or SEPP decides to redirect HTTP requests to another less loaded SCP or SEPP, it may send the HTTP status code "307 Temporary Redirect" or "308 Permanent Redirect" with the cause attribute set to "SCP_REDIRECTION" (see clause 6.10.9) / "SEPP_REDIRECTION" as defined in Table 5.2.7.4-2.

The SCP or SEPP should map status codes to the most similar 3xx/4xx/5xx HTTP status code specified in Table 5.2.7.4-1 and Table 5.2.7.4-2. If no such code is applicable, it should use "400 Bad Request" status code for errors caused by client side or "500 Server Internal Error" status code for errors caused on server side.

Table 5.2.7.4-1: Protocol and application errors generated by the SCP/SEPP

Protocol or application Error	HTTP status code	Description
INVALID_API	400 Bad Request	The HTTP request contains an unsupported API name or API version in the URI.
INVALID_MSG_FORMAT	400 Bad Request	The HTTP request has an invalid format.
INVALID_QUERY_PARAM	400 Bad Request	The HTTP request contains an unsupported query parameter in the URI. (NOTE 1)
MANDATORY_QUERY_PARAM_INCORRECT	400 Bad Request	A mandatory query parameter, or a conditional query parameter but mandatory required, for an HTTP method was received in the URI with semantically incorrect value. (NOTE 1)
OPTIONAL_QUERY_PARAM_INCORRECT	400 Bad Request	An optional query parameter for an HTTP method was received in the URI with a semantically incorrect value that prevents successful processing of the service request. (NOTE 1)
MANDATORY_QUERY_PARAM_MISSING	400 Bad Request	Query parameter which is defined as mandatory, or as conditional but mandatory required, for an HTTP method is not included in the URI of the request. (NOTE 1)
MANDATORY_IE_INCORRECT	400 Bad Request	A mandatory IE (within a variable part of an "apiSpecificResourceUriPart" or within an HTTP header), or conditional IE but mandatory required, for an HTTP method was received with a semantically incorrect value. (NOTE 1)
OPTIONAL_IE_INCORRECT	400 Bad Request	An optional IE (within an HTTP header) for an HTTP method was received with a semantically incorrect value that prevents successful processing of the service request. (NOTE 1)
MANDATORY_IE_MISSING	400 Bad Request	A mandatory IE (within the variable part of an "apiSpecificResourceUriPart" or within an HTTP header), or conditional IE but mandatory required, for an HTTP method is not included in the request. (NOTE 1)
UNSPECIFIED_MSG_FAILURE	400 Bad Request	The request is rejected due to unspecified client error. (NOTE 2)
NF_DISCOVERY_FAILURE	400 Bad Request	The request is rejected by the SCP because no NF Service Producer can be found matching the NF service discovery factors (see clause 6.10.6).
INVALID_DISCOVERY_PARAM	400 Bad Request	The request is rejected by the SCP because it contains an unsupported discovery parameter (i.e. unknown 3gpp-Sbi-Discovery-* header) (see clause 6.10.3.2). (NOTE 1)
MSG_LOOP_DETECTED	400 Bad Request	The request is rejected because message loop is detected.
MISSING_ACCESS_TOKEN_INFO	400 Bad Request	The request is rejected due to missing information in the service request that prevents the SCP from requesting an access token to the Authorization Server. See clause 6.10.3.5.
ACCESS_TOKEN_DENIED	403 Forbidden	The request is rejected due to the Authorization Server rejecting to grant an access token to the SCP. See clause 6.10.3.5.
PLMNID_MISMATCH	403 Forbidden	The request is rejected by the SEPP due to the PLMN ID in the bearer token carried in the "Authorization" header of the reconstructed message does not match the PLMN ID of the N32-f context.
REQUESTED_PURPOSE_NOT_ALLOWED	403 Forbidden	The request is rejected due to requested purpose provided in the HTTP request is not allowed by the policy. See clause 6.14.
INCORRECT_LENGTH	411 Length Required	The request is rejected due to incorrect value of a Content-length header field.
NF_CONGESTION_RISK	429 Too Many Requests	The request is rejected due to excessive traffic which, if continued over time, may lead to (or may increase) an overload situation.
INSUFFICIENT_RESOURCES	500 Internal Server Error	The request is rejected due to insufficient resources.
UNSPECIFIED_NF_FAILURE	500 Internal Server Error	The request is rejected due to unspecified reason at the SCP or SEPP. (NOTE 3)
SYSTEM_FAILURE	500 Internal Server Error	The request is rejected due to generic error condition in the SCP or SEPP.
NF_FAILOVER	500 Internal Server Error	The request is rejected by the SCP due to the unavailability of the NF, and the requester may trigger an immediate re-selection of an alternative NF based on this information.
NF_SERVICE_FAILOVER	500 Internal Server Error	The request is rejected by the SCP due to the unavailability of the NF service, and the requester may trigger an immediate re-selection of an alternative NF service based on this information.
MAX_SCP_HOPS_REACHED	502 Bad Gateway	The request is rejected due to the maximum number of allowed SCP hops has been reached when relaying the request message to the target NF.
NF_DISCOVERY_ERROR	502 Bad Gateway	The request is rejected due to the receipt of an 5xx or 429 response from the NRF during an NF Discovery procedure the SCP initiated to fulfil the request.
NF_CONGESTION	503 Service Unavailable	The SCP or SEPP experiences congestion and performs overload control, which does not allow the request to be processed. (NOTE 4)
TIMED_OUT_REQUEST	504 Gateway Timeout	The request is rejected due a request that has timed out at the HTTP client (see clause 6.11.2).
TARGET_NF_NOT_REACHABLE	504 Gateway Timeout	The request is not served as the target NF is not reachable (see clause 6.10.8.2).
NRF_NOT_REACHABLE	504 Gateway Timeout	The request is not served due to the NRF being unreachable (see clause 6.10.8.2).
NOTE 1: "invalidParams" attribute shall be included in the "ProblemDetails" data structure indicating unsupported, missing or incorrect IE(s) or 3gpp-Sbi-Discovery-* header(s). NOTE 2: This application error indicates error in the HTTP request and there is no other application error value that can be used instead. NOTE 3: This application error indicates error condition in the SCP/SEPP and there is no other application error value that can be used instead. NOTE 4: If the reason for rejection is a temporary overload, the SCP/SEPP may include in the response a Retry-After header field to indicate how long the service is expected to be unavailable.

Table 5.2.7.4-2: Redirect responses generated by the SCP/SEPP

Cause value

HTTP status code

Description

SCP_REDIRECTION

307 Temporary Redirect

308 Permanent Redirect

The request is redirected to a different SCP (see clause 6.10.9).

SEPP_REDIRECTION

307 Temporary Redirect

308 Permanent Redirect

The request is redirected to a different SEPP (see clause 6.10.9).

5.2.8 HTTP/2 request retries

All NF services expose APIs across the service based interfaces and the APIs operate on resources. Invocation of an API though a HTTP method may result in the change of state of a resource depending of the request type. When a HTTP/2 client sends a request and it does not receive a response or it experiences a delay, it does not guarantee that the HTTP/2 request has not been processed by the HTTP/2 server.

A HTTP/2 client may retry the same request that uses an idempotent method any time (see IETF RFC 7231 [11] clause 4.2.2).

Retrying a non-idempotent HTTP/2 request on the same resource before a response for the previous request is received may lead to state changes on the resource with unspecified behaviour. HTTP conditional requests, as specified in IETF RFC 7232 [24] may be used to avoid such situations.

An NF acting as an HTTP/2 client should also retry non-idempotent request if the request has not been processed, i.e. if the identifier of the stream corresponding to the request is larger than the Last-Stream-Id in a GOAWAY frame, or the REFUSED_STREAM error code is included in a RST_STREAM frame for the stream corresponding to the request as specified in clause 8.1.4 of IETF RFC 7540 [7]. API specific mechanisms as specified in respective technical specifications may be used for reconciling the state of resources, if the retry is attempted through a new TCP connection after a TCP connection failure.

The number of retry shall be limited. A client should always prefer to retry requests to an alternative server if the initial server is overloaded. In case of general overload situation where all possible servers are overloaded retry mechanisms should be disabled automatically.

The support of "detection of duplicated request message" is optional for HTTP clients and servers. When it is supported:

– the NF acting as an HTTP/2 client shall:

– include an idempotency key (which shall uniquely identify the request message towards the target NF) in the 3gpp-Sbi-Request-Info header for a non-idempotent request message, e.g. a POST request;

– include the same idempotency key in the 3gpp-Sbi-Request-Info header when subsequently the NF acting as an HTTP/2 client decides to retry the same request towards the same NF acting as an HTTP/2 server or an alternative NF (e.g. from the same NF (service) Set);

– the NF acting as an HTTP/2 server, upon receiving a request message containing an idempotency key in the 3gpp-Sbi-Request-Info header, may:

use the idempotency key to determine if it is a duplicated request message; and if so

– produce a proper response based on the current state of the resource/session context considering the original request has been processed. The SCP shall forward the idempotency key received from the HTTP client unmodified towards the target NF, regardless of whether the SCP performs (re)selection of the target NF.

The idempotency key that is supplied as part of every non-idempotent request shall be unique and shall not be reused with another request other than a retransmission of the same request. The server may consider an idempotency key as expired after an operator configurable timer.

5.2.9 Handling of unsupported query parameters

Unless specified otherwise for an API, a NF Service Producer that receives an HTTP request with one or more unsupported (i.e. not comprehended) query parameters shall:

a) for safe HTTP methods (e.g. HTTP GET request):

– ignore the unsupported query parameters and respond to the request based on the rest of the request (e.g. other supported query parameters); or

– reject the HTTP request as specified below for non-safe HTTP methods, e.g. based on other query parameters in the request or based on a response becoming very large;

b) for non-safe HTTP methods:

– reject the request with a 400 Bad Request including a ProblemDetails IE with:

– the cause attribute set to INVALID_QUERY_PARAM;

– the invalidParams attribute indicating the unsupported query parameters;

– the supportedFeatures attribute listing the features supported by the NF Service Producer, if any, set as specified for HTTP responses in clause 6.6.2.

5.2.10 URL Encoding of data

5.2.10.1 General

As indicated in IETF RFC 3986 [14], the URI syntax defines a set of characters (a subset of the URI allowed characters) as delimiters of syntax components; those characters are called "reserved" and should not be used in URI fields intended to convey generic data (e.g., in the value part of a query parameter, or in the URI path segments), since this would interfere with the original meaning (syntax) of those reserved characters.

In addition, HTTP/2 request body parts encoded with media type "application/x-www-form-urlencoded" shall also escape reserved and unsafe characters, as described in OpenAPI Specification [9].

5.2.10.2 URL Encoding of URI components

When a URI is composed in the 3GPP 5G APIs, the different components (e.g., path segments, values of query parameters, etc.) shall percent-encode (see IETF RFC 3986 [14], section 2.1) the following "reserved" characters:

– EXCLAMATION MARK (U+0021): !

– NUMBER SIGN (U+0023): #

– DOLLAR SIGN (U+0024): $

– AMPERSAND (U+0026): &

– APOSTROPHE (U+0027): ‘

– LEFT PARENTHESIS (U+0028): (

– RIGHT PARENTHESIS (U+0029): )

– ASTERISK (U+002A): *

– PLUS SIGN (U+002B): +

– COMMA (U+002C): ,

– SOLIDUS (U+002F): /

– COLON (U+003A): :

– SEMICOLON (U+003B): ;

– EQUALS SIGN (U+003D): =

– QUESTION MARK (U+003F): ?

– COMMERCIAL AT (U+0040): @

– LEFT SQUARE BRACKET (U+005B): [

– RIGHT SQUARE BRACKET (U+005D): ]

The following characters (not listed as "reserved" in IETF RFC 3986 [14]) shall be percent-encoded:

– QUOTATION MARK (U+0022): "

– PERCENT SIGN (U+0025): %

SPACE (U+0020) character shall be escaped, either by percent-encoding it (as %20), or by replacing it with character PLUS SIGN (U+002B).

The encoding of query parameters consisting of arrays of strings shall follow the guidelines indicated in 3GPP TS 29.501 [5], clause 5.3.13, for the escaping of the COMMA (U+002C) characters.

In addition, implementations may percent-encode other characters, such as:

– LEFT CURLY BRACKET (U+007B): {

– RIGHT CURLY BRACKET (U+007D): }

The receiving entity shall percent-decode the received URI as specified in IETF RFC 3986 [14], section 2.4.

5.2.10.3 URL Encoding of HTTP/2 request bodies

When composing an HTTP/2 request body with media type "application/x-www-form-urlencoded", the OpenAPI Specification [9] requires that the encoding shall follow IETF RFC 1866 [48], section 8.2.1, which indicates:

a) the "reserved" character set described in IETF RFC 1738 [yy], section 2.2, shall be percent-encoded:

– AMPERSAND (U+0026): &

– SOLIDUS (U+002F): /

– COLON (U+003A): :

– SEMICOLON (U+003B): ;

– EQUALS SIGN (U+003D): =

– QUESTION MARK (U+003F): ?

– COMMERCIAL AT (U+0040): @

b) SPACE (U+0020) character shall be escaped by replacing it with character PLUS SIGN (U+002B).

The following characters (not listed as "reserved" in IETF RFC 1738 [yy]) shall be percent-encoded:

– QUOTATION MARK (U+0022): "

– PERCENT SIGN (U+0025): %

– COMMA (U+002C): ,

– LEFT SQUARE BRACKET (U+005B): [

– RIGHT SQUARE BRACKET (U+005D): ]

– LEFT CURLY BRACKET (U+007B): {

– RIGHT CURLY BRACKET (U+007D): }

In addition, implementations may also percent-encode any of the characters listed in clause 5.2.10.2.

5.3 Transport Protocol

The Transmission Control Protocol as described in IETF RFC 793 [6] shall be used as transport protocol as required by HTTP/2 (see IETF RFC 7540 [7]).

NOTE: When using TCP as the transport protocol, an HTTP/2 connection is mapped to a TCP connection.

If a Network Function does not register any port number to the NRF then it shall be prepared to receive connections on default port numbers, i.e. TCP port 80 for "http" URIs and TCP port 443 for "https" URIs as specified in IETF RFC 7540 [7].

5.4 Serialization Protocol

The JavaScript Object Notation (JSON) format as described in IETF RFC 8259 [10] shall be used as serialization protocol.

For transmitting large parts of opaque binary data along with JSON format, multipart messages shall be supported using:

– A multipart/related media type;

– 3gpp vendor specific content subtype; and

– Cross-referencing from the JSON payload using the Content-ID field.

Use of multipart messages is documented in specific specifications.

5.5 Interface Definition Language

OpenAPI Specification [9] shall be used as Interface Definition Language (IDL) of SBI.