Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 29.500  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3…   5.2.3.3…   5.2.4…   6…   6.3…   6.4…   6.5…   6.6…   6.7…   6.10…   6.10.3…   6.10.6…   6.10.11…   6.11…   A   B   C   D… 
5 Protocols Over Service Based Interfaces  5.1 Protocol Stack Overview  5.2 HTTP/2 Protocol  5.2.1 General  5.2.2 HTTP standard headers  5.2.2.1 General  5.2.2.2 Mandatory to support HTTP standard headers 
...

 

5  Protocols Over Service Based Interfaces  p. 14

5.1  Protocol Stack Overview  p. 14

The protocol stack for the service-based interfaces is shown on Figure 5.1-1.
Reproduction of 3GPP TS 29.500, Fig. 5.1-1: SBI Protocol Stack
Figure 5.1-1: SBI Protocol Stack
Up
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 TS 33.501.
Up

5.2  HTTP/2 Protocol  p. 14

5.2.1  General  p. 14

HTTP/2 as described in RFC 9113 shall be used in Service based interface.

5.2.2  HTTP standard headers  p. 14

5.2.2.1  General  p. 14

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  p. 15

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.
Name Reference Description
Accept RFC 9110 This header is used to specify response media types that are acceptable.
Accept-Encoding RFC 9110 This header may be used to indicate what response content-encodings (e.g. gzip) are acceptable in the response.
Content-Length RFC 9110 This header is used to provide the anticipated size, as a decimal number of octets, for a potential content.
Content-Type RFC 9110 This header is used to indicate the media type of the associated representation.
Content-Encoding RFC 9110 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 RFC 9110 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 RFC 9111 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 RFC 9110 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 RFC 9110 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 RFC 9110 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 RFC 9110 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 RFC 9110 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 TS 33.501, Section 7 of RFC 6749 and RFC 6750.
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 TS 29.510.
Name Reference Description
Content-Length RFC 9110This header may be used to provide the anticipated size, as a decimal number of octets, for a potential content.
Content-Type RFC 9110This header shall be used to indicate the media type of the associated representation.
Location RFC 9110This header may be used in some responses to refer to a specific resource in relation to the response.
Retry-After RFC 9110This 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 RFC 9110This 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 RFC 9111 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 RFC 9111 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 RFC 9110This header may be sent to allow for conditional GET with the If-Modified-Since header.
ETag RFC 9110This 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 RFC 9110This 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 RFC 9110This header field shall be used to indicate methods supported by the target resource.
WWW-Authenticate RFC 9110 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 RFC 9110See clause 6.9 for the use of this header.
Server RFC 9110 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
Up

Up   Top   ToC