Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  17.1.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3   5.2.4…   6…   6.4…   6.5…   6.6…   6.7…   6.10…   6.11…   A…

 

5  Protocols Over Service Based InterfacesWord‑p. 13

5.1  Protocol Stack Overview

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

5.2.1  General

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

5.2.2  HTTP standard headersWord‑p. 14

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.
Name Reference Description
Accept RFC 7231This header is used to specify response media types that are acceptable.
Accept-Encoding RFC 7231This header may be used to indicate what response content-encodings (e.g. gzip) are acceptable in the response.
Content-Length RFC 7230This header is used to provide the anticipated size, as a decimal number of octets, for a potential payload body.
Content-Type RFC 7231This header is used to indicate the media type of the associated representation.
Content-Encoding RFC 7231This 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 7231This header shall be mainly used to identify the NF type of the HTTP/2 client.
The pattern of the content should start with the value of NF type (e.g. udm, see NOTE 1) and followed by a "-" and any other specific information if needed afterwards.
Cache-Control RFC 7234This 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 7232This 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 7232This 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 7232This 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 7230This header shall be inserted by HTTP proxies and it may be inserted by an SCP and SEPP when relaying an HTTP request.
Authorization RFC 7235 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, clause 7 of IETF RFC 6749 and IETF RFC 6750 [23].
 
Name Reference Description
Content-Length RFC 7230This header may be used to provide the anticipated size, as a decimal number of octets, for a potential payload body.
Content-Type RFC 7231This header shall be used to indicate the media type of the associated representation.
Location RFC 7231This header may be used in some responses to refer to a specific resource in relation to the response.
Retry-After RFC 7231This 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 7231This 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 7234This 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 7234This 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 7232This header may be sent to allow for conditional GET with the If-Modified-Since header.
ETag RFC 7232This 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 7230This 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 pattern of the header should be formatted as follows:
  • "SCP-<SCP FQDN>" for an SCP
  • "SEPP-<SEPP FQDN>" for a SEPP
Allow RFC 7231This header field shall be used to indicate methods supported by the target resource.
WWW-Authenticate RFC 7235This 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 7694See clause 6.9 for the use of this header.
Server RFC 7231This 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