Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  16.4.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 Interfaces
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 ProtocolWord‑p. 13
5.2.1  General
HTTP/2 as described in RFC 7540 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.
Name
Reference
Description

Accept
RFC 7231
This header is used to specify response media types that are acceptable.
Accept-Encoding
RFC 7231
This header may be used to indicate what response content-encodings (e.g gzip) are acceptable in the response.
Content-Length
RFC 7230
This header is used to provide the anticipated size, as a decimal number of octets, for a potential payload body.
Content-Type
RFC 7231
This header is used to indicate the media type of the associated representation.
Content-Encoding
RFC 7231
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 7231
This 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 7234
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 7232
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 7232
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 7232
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 7230
This 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 [22] and IETF RFC 6750 [23].


 
Name
Reference
Description

Content-Length
RFC 7230
This header may be used to provide the anticipated size, as a decimal number of octets, for a potential payload body.
Content-Type
RFC 7231
This header shall be used to indicate the media type of the associated representation.
Location
RFC 7231
This header may be used in some responses to refer to a specific resource in relation to the response.
Retry-After
RFC 7231
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
RFC 7231
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
RFC 7234
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 7234
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 7232
This header may be sent to allow for conditional GET with the If-Modified-Since header.
ETag
RFC 7232
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
RFC 7230
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.x). 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 7231
This header field shall be used to indicate methods supported by the target resource.
WWW-Authenticate
RFC 7235
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 7694
See clause 6.9 for the use of this header.
Server
RFC 7231
This header should be inserted by the originator of an HTTP error response (see clause 6.10.x). 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