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.502  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   5…   5.2.2…   5.2.2.2.4…   5.2.2.3…   5.2.2.3.2…   5.2.2.3.3…   5.2.2.3.6…   5.2.2.3.8…   5.2.2.3.10…   5.2.2.3.17…   5.2.2.3.23…   5.2.2.4…   5.2.2.8…   5.2.2.8.2…   5.2.2.8.2.7…   5.2.2.8.2.12…   5.2.2.8.2.20…   5.2.2.8.3…   5.2.2.8.3.6…   5.2.2.9…   5.2.3…   6…   6.1.2…   6.1.3…   6.1.3.3…   6.1.3.5…   6.1.3.6…   6.1.3.7…   6.1.4…   6.1.6…   6.1.6.2…   6.1.6.2.5…   6.1.6.2.11…   6.1.6.2.18…   6.1.6.2.27…   6.1.6.2.40…   6.1.6.2.54…   6.1.6.2.65…   6.1.6.3…   6.1.6.4…   6.1.7…   A…   B…   C… 
6.1.2 Usage of HTTP  6.1.2.1 General  6.1.2.2 HTTP standard headers  6.1.2.2.1 General  6.1.2.2.2 Content type  6.1.2.3 HTTP custom headers  6.1.2.3.1 General  6.1.2.3.2 3gpp-Sbi-Origination-Timestamp  6.1.2.4 HTTP multipart messages  6.1.2.5 HTTP/2 request retries 
...

 

6.1.2  Usage of HTTP  p. 98

6.1.2.1  General  p. 98

HTTP/2, as defined in RFC 9113, shall be used as specified in clause 5 of TS 29.500.
HTTP/2 shall be transported as specified in clause 5.3 of TS 29.500.
HTTP messages and bodies for the Nsmf_PDUSession service shall comply with the OpenAPI [15] specification contained in Annex A.
Up

6.1.2.2  HTTP standard headers  p. 98

6.1.2.2.1  General  p. 98
The usage of HTTP standard headers shall be supported as specified in clause 5.2.2 of TS 29.500.
6.1.2.2.2  Content type  p. 98
The following content types shall be supported:
  • the JSON format (RFC 8259). The use of the JSON format shall be signalled by the content type "application/json". See also clause 5.4 of TS 29.500.
  • the Problem Details JSON Object (RFC 9457). The use of the Problem Details JSON object in a HTTP response body shall be signalled by the content type "application/problem+json".
Multipart messages shall also be supported (see clause 6.1.2.4) using the content type "multipart/related", comprising:
  • one JSON body part with the "application/json" content type; and
  • one or two binary body parts with 3gpp vendor specific content subtypes.
The 3gpp vendor specific content subtypes defined in Table 6.1.2.2.2-1 shall be supported.
content subtype Description
vnd.3gpp.ngapBinary encoded content, encoding NG Application Protocol (NGAP) IEs, as specified in clause 9.3 of TS 38.413 (ASN.1 encoded).
vnd.3gpp.5gnasBinary encoded content, encoding a 5GS NAS message or 5G NAS IEs, as specified in TS 24.501.
vnd.3gpp.pfcpBinary encoded content, encoding a PFCP message, as specified in TS 29.244. (NOTE 2)
NOTE 1:
Using 3GPP vendor content subtypes allows to describe the nature of the opaque content (e.g. NGAP or 5GS NAS information) without having to rely on metadata in the JSON content.
NOTE 2:
Binary encoded content in vnd.3gpp.pfcp content subtype shall include application layer headers for PFCP and shall not include transport layer headers, i.e. IP and UDP.
See clause 6.1.2.4 for the binary contents supported in the binary content part of multipart messages.
Up

6.1.2.3  HTTP custom headers  p. 98

6.1.2.3.1  General  p. 98
For 3GPP specific HTTP custom headers used across all service based interfaces, see clause 5.2.3 of TS 29.500.
Additional HTTP custom headers applicable to the Nsmf_PDUSession service are specified in the following clauses.
6.1.2.3.2  3gpp-Sbi-Origination-Timestamp |R16|  p. 99
The header contains the date and time (with a millisecond granularity) when the originating entity initiated the request.
The encoding of the header follows the ABNF as defined in RFC 9110.
day-name, date1, time-of-day shall comply with the definition in Section 5.6.7 of RFC 9110.
EXAMPLE:
3gpp-Sbi-Origination-Timestamp: Sun, 04 Aug 2019 08:49:37.845 GMT
Up

6.1.2.4  HTTP multipart messages  p. 99

HTTP multipart messages shall be supported, to transfer opaque N1 and/or N2 SMpayloads or N4 information, in the following service operations (and HTTP messages):
  • Create SM Context Request and Response (POST);
  • Update SM Context Request and Response (POST);
  • Release SM Context Request (POST);
  • Create Request and Response (POST);
  • Update Request and Response (POST (modify)).
HTTP multipart messages shall include one JSON body part and one or two binary body parts comprising:
The JSON body part shall be the "root" body part of the multipart message. It shall be encoded as the first body part of the multipart message. The "Start" parameter does not need to be included.
The multipart message shall include a "type" parameter (see RFC 2387) specifying the media type of the root body part, i.e. "application/json".
For each binary body part in a HTTP multipart message, the binary body part shall include a Content-ID header (see RFC 2045), and the JSON body part shall include an attribute, defined with the RefToBinaryData type, that contains the value of the Content-ID header field of the referenced binary body part.
Examples of multipart/related messages can be found in Annex B.
Up

6.1.2.5  HTTP/2 request retries  p. 99

The principles specified in clause 5.2.8 of TS 29.500 shall be applied with the following modifications.
The NF Service Consumer of Nsmf_PDUSession service, e.g. the AMF, shall retry the same HTTP request in the following scenarios through a new TCP connection towards an (alternative) service endpoint pertaining to the same NF (Service) instance or set if the corresponding procedure triggering the service request allows such retries, e.g. before the timeout of the corresponding N1 or N2 procedure:
  • If the stream for the service request has not been processed in the SMF as specified in clause 5.2.8 of TS 29.500;
  • if the request is rejected by a HTTP status code indicating a temporary failure in the SMF, e.g. the status code 429, 500 and 503, as specified in clause 5.2.7 of TS 29.500;
  • if the request is timeout (i.e. the NF Service consumer doesn't receive any response after an implementation specific timer expires).
The NF Service Consumer shall determine an alternative service instance as specified in clause 6.5 of TS 23.527, i.e. using Binding Indication if supported/available or the NF (service) set or service persistency info from NF profile. The NF Service Consumer should also consider the Load control Information and the Overload Control Information if available as specified in clauses 6.3 and 6.4 in TS 29.500 when reselecting an alternative NF service instance.
The SMF shall support handling repeated retries successfully.
HTTP conditional requests are not supported by the Nsmf_PDUSession service in this version of the API.
Up

Up   Top   ToC