6.1.2 Usage of HTTP

29.5023GPP5G SystemRelease 16Session Management ServicesStage 3TS

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

6.1.2.1 General

HTTP/2, as defined in IETF RFC 7540 [14], shall be used as specified in clause 5 of 3GPP TS 29.500 [4].

HTTP/2 shall be transported as specified in clause 5.3 of 3GPP TS 29.500 [4].

HTTP messages and bodies for the Nsmf_PDUSession service shall comply with the OpenAPI [15] specification contained in Annex A.

6.1.2.2 HTTP standard headers

6.1.2.2.1 General

The usage of HTTP standard headers shall be supported as specified in clause 5.2.2 of 3GPP TS 29.500 [4].

6.1.2.2.2 Content type

The following content types shall be supported:

– the JSON format (IETF RFC 8259 [11]). The use of the JSON format shall be signalled by the content type "application/json". See also clause 5.4 of 3GPP TS 29.500 [4].

– the Problem Details JSON Object (IETF RFC 7807 [23]). The use of the Problem Details JSON object in a HTTP response body shall be signalled by the content type "application/problem+json".

NOTE: "application/json" is used in a response that includes a payload body containing an application-specific data structure, see clause 4.8 of 3GPP TS 29.501 [5].

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.

Table 6.1.2.2.2-1: 3GPP vendor specific content subtypes

content subtype	Description
vnd.3gpp.ngap	Binary encoded payload, encoding NG Application Protocol (NGAP) IEs, as specified in clause 9.3 of 3GPP TS 38.413 [9] (ASN.1 encoded).
vnd.3gpp.5gnas	Binary encoded payload, encoding a 5GS NAS message or 5G NAS IEs, as specified in 3GPP TS 24.501 [7].
vnd.3gpp.pfcp	Binary encoded payload, encoding a PFCP message, as specified in 3GPP TS 29.244 [29]. (NOTE 2)
NOTE 1: Using 3GPP vendor content subtypes allows to describe the nature of the opaque payload (e.g. NGAP or 5GS NAS information) without having to rely on metadata in the JSON payload. NOTE 2: Binary encoded payload 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 payloads supported in the binary body part of multipart messages.

6.1.2.3 HTTP custom headers

6.1.2.3.1 General

In this release of the specification, no specific custom headers are defined for the Nsmf_PDUSession service.

For 3GPP specific HTTP custom headers used across all service based interfaces, see clause 5.2.3 of 3GPP TS 29.500 [4].

6.1.2.3.2 3gpp-Sbi-Origination-Timestamp

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

3gpp-Sbi-Origination-Timestamp = "3gpp-Sbi-Origination-Timestamp" ":" 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 [32].

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

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

6.1.2.4 HTTP multipart messages

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:

– an N1 SM payload, an N2 SM payload or both, over N11 (see clause 6.1.6.4);

– one or two N1 SM payloads, over N16 (see clause 6.1.6.4);

– one or two N2 SM payloads over N11 (see clause 5.2.2.3.3);

– one, two or three N4 payloads over N16a (see clause 6.1.6.4.5).

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 IETF RFC 2387 [10]) specifying the media type of the root body part, i.e. "application/json".

NOTE: The "root" body part (or "root" object) is the first body part the application processes when receiving a multipart/related message, see IETF RFC 2387 [10]. The default root is the first body within the multipart/related message. The "Start" parameter indicates the root body part, e.g. when this is not the first body part in the message.

For each binary body part in a HTTP multipart message, the binary body part shall include a Content-ID header (see IETF RFC 2045 [12]), 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.

6.1.2.5 HTTP/2 request retries

The principles specified in clause 5.2.8 of 3GPP TS 29.500 [4] 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 3GPP TS 29.500 [4];

– 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 3GPP TS 29.500 [4];

– 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 3GPP TS 23.527 [24], 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 3GPP TS 29.500 [4] when reselecting an alternative NF service instance.

The SMF shall support handling repeated retries successfully.

NOTE: See clauses 5.2.2.2 and 5.2.2.7 for the handling by the SMF of an HTTP POST request that would have already been processed by the SMF and that would be retried by the NF Service Consumer.

HTTP conditional requests are not supported by the Nsmf_PDUSession service in this version of the API.