6.9 Discovering the supported communication options

29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS

6.9.1 General

The OPTIONS method, as described in clause 4.3.7 of IETF RFC 7231 [11], may be used by a NF Service Consumer to determine the communication options supported by a NF Service Producer for a target resource.

Clause 6.9.2.1 describes example communication options that may be discovered using the OPTIONS method.

The Accept-Encoding header, as described in clause 5.3.4 of IETF RFC 7231 [11], may be used by a NF Service Producer to determine the communication options supported by a NF Service Consumer.

Clause 6.9.2.2 describes example communication options that may be discovered using the Accept-Encoding header.

6.9.2 Discoverable communication options

6.9.2.1 Content-encodings supported in HTTP requests

Certain service operations may result in large HTTP request payloads, e.g. to register NF profiles in the NRF (see 3GPP TS 29.510 [8]) or to update the NSSF with the available S-NSSAIs supported by Tracking Areas (see 3GPP TS 29.531 [32]). Gzip coding (see IETF RFC 1952 [34]) may be supported to optimally reduce the payload size of HTTP requests in this case.

A NF Service Consumer may determine the content-encodings supported by the NF Service Producer in HTTP requests targeting a particular resource by:

– sending an HTTP OPTIONS request targeting the resource of the NF Service Producer; and/or

– receiving an "Accept-Encoding" header in HTTP responses from the NF Service Producer for requests targeting the resource.

A NF Service Producer that receives an HTTP OPTIONS request for a target resource shall include an "Accept-Encoding" header in the HTTP 200 OK response (see IETF RFC 7694 [33]), if specific content-encodings, e.g. Gzip coding (e.g. see IETF RFC 1952 [34]) are supported in HTTP requests targeting the resource.

A NF Service Producer that receives an HTTP request with a content-encoding that it does not support shall reject the request with the status code "415 Unsupported Media Type" and include an "Accept-Encoding" header in the response indicating the supported encodings in HTTP requests, as described in clause 3 of IETF RFC 7694 [33].

A NF Service Producer may include an "Accept-Encoding" header in the HTTP 2xx response for requests other than HTTP OPTIONS if specific content-encodings, e.g. Gzip coding (e.g. see IETF RFC 1952 [34]), are supported in HTTP requests targeting the resource, to optimize future interactions, e.g. when the request payload was big enough to justify use of a compression coding but the client did not do so.

For notification requests, a NF Service Producer may determine the content-encodings supported by the NF Service Consumer from the 3gpp-Sbi-Notif-Accepted-Encoding HTTP header, defined in clause 5.2.3.3.6, included in the received subscription request.

6.9.2.2 Content-encodings supported in HTTP responses

Certain service operations may result in large HTTP response payloads, e.g. to send NF profiles by the NRF (see 3GPP TS 29.510 [8]) or to send the available S-NSSAIs supported by Tracking Areas by the NSSF (see 3GPP TS 29.531 [32]). Gzip coding (see IETF RFC 1952 [34]) may be supported to optimally reduce the payload size of HTTP responses in this case (see "Content-Encoding" header in Table 5.2.2.2-2).

A NF Service Consumer may include an "Accept-Encoding" header in HTTP requests to indicate the content-encodings, e.g. Gzip coding (e.g. see IETF RFC 1952 [34]), that are supported for the associated HTTP responses, as specified in Table 5.2.2.2-1 and in clause 5.3.4 of IETF RFC 7231 [11].

A NF Service Producer may determine the content-encodings supported by the NF Service Consumer in HTTP responses by receiving an "Accept-Encoding" header in the associated HTTP requests from the NF Service Consumer.