6.1.2 Usage of HTTP

29.5183GPP5G SystemAccess and Mobility Management ServicesRelease 18Stage 3TS

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

6.1.2.1 General

HTTP/2, as defined in IETF RFC 7540 [19], 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 Namf_Communication service shall comply with the OpenAPI [23] 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:

– JSON, as defined in IETF RFC 8259 [8], shall be used as content type of the HTTP bodies specified in the present specification as indicated in clause 5.4 of 3GPP TS 29.500 [4].

– The Problem Details JSON Object (IETF RFC 7807 [36]). 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 more 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.4 of 3GPP TS 38.413 [12] (ASN.1 encoded).
vnd.3gpp.5gnas	Binary encoded payload, encoding a 5GS NAS message, as specified in 3GPP TS 24.501 [11].
NOTE: 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.

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 this specification, no custom headers specific to the Namf_Communication service are defined. 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.4 HTTP multipart messages

HTTP multipart messages shall be supported, to transfer opaque N1 Information (e.g. SM, LPP) and/or N2 Information (e.g. SM, NRPPa, PWS), in the following service operations (and HTTP messages):

– N1N2MessageTransfer Request and Response (POST);

– NonUeN2MessageTransfer Request and Response (POST);

– N1MessageNotify (POST);

– N2InfoNotify (POST);

– NonUeN2InfoNotify (POST);

– UEContextTransfer (POST);

– CreateUEContext (PUT)

HTTP multipart messages shall include one JSON body part and one or more binary body parts comprising:

– N1payload, and/or N2 payload (see clause 6.1.6.4).

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 [9]) 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 [9]. 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 [10]), 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.