Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  17.5.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3…   5.2.3.3…   5.2.4…   6…   6.4…   6.5…   6.6…   6.7…   6.10…   6.11…   A…

 

5.2.4  HTTP error handlingWord‑p. 44

HTTP/2 connection error and stream error shall be supported as specified in Section 5.4 of RFC 7540.
Guidelines for error responses to the invocation of APIs of NF services are specified in clause 4.8 of TS 29.501. API specific error responses are specified in the respective technical specifications.

5.2.5  HTTP/2 server pushWord‑p. 44

HTTP/2 Server Push as specified in Section 8.2 of RFC 7540 may be supported and may be used by a NF Service Producer to proactively push resources to a NF Service Consumer, see clause 4.9.5 of TS 29.501.
A NF Service Consumer may choose to disable HTTP/2 Server Push by setting SETTINGS_ENABLE_PUSH to 0, as specified in Section 8.2 of RFC 7540.
Up

5.2.6  HTTP/2 connection managementWord‑p. 44

The HTTP request / response exchange mechanism as specified in Section 8.1 of RFC 7540 shall be supported between the 3GPP NFs. An HTTP/2 endpoint shall support establishing multiple HTTP/2 connections (at least two) towards a peer HTTP/2 endpoint. The peer HTTP/2 endpoint is identified by host and port pair where the host is derived from the target URI (see clause 6.1.1).
As per Section 8.1 of RFC 7540 a HTTP request / response exchange fully consumes a single stream. When the HTTP/2 Stream IDs on a given HTTP/2connection is exhausted, an HTTP/2 endpoint, shall establish another HTTP/2connection towards that peer HTTP/2 endpoints.
The 3GPP NF shall take care to avoid simultaneous stream ID exhaustion on all the available HTTP/2 connections towards each peer.
The 3GPP NF shall support gracefully shutdown of a HTTP/2 connection by sending a GOAWAY frame with "Error Code" field set to "NO_ERROR (0x0)". The HTTP connection should remain "open" (by the sender and receiver of GOAWAY frame) until all in-progress streams numbered lower or equal to the last stream identifier indicated by the "Last-Stream-Id" field in the GOAWAY frame are completed. See Section 6.8 of RFC 7540.
An NF acting as an HTTP/2 client shall support testing whether a connection is still active by sending a PING frame. An NF acting as an HTTP/2 server may test whether a connection is still active by sending a PING frame. An NF acting as an HTTP/2 client or server shall respond to received PING frames as specified in Section 6.7 of RFC 7540. When and how often a PING frame may be sent is implementation specific but shall be configurable by operator policy. When HTTP server detects the connection failure, it shall follow connection error handling as defined in Section 5.4.1 of RFC 7540.
A PING frame shall not be sent more often than every 60 s on each path.
Up

5.2.7  HTTP status codesWord‑p. 44

5.2.7.1  GeneralWord‑p. 44

This clause describes the HTTP status codes usage on SBI.
HTTP status codes are carried in ":status" pseudo header field in HTTP/2, as defined in Section 8.1.2.4 in RFC 7540.
Table 5.2.7.1-1 specifies HTTP status codes per HTTP method which shall be supported on SBI. Support of an HTTP status code shall be:
  • mandatory, which is marked in Table as "M". This means that all 3GPP NFs shall support the processing of the specific HTTP status code for the specific HTTP method, when received in a HTTP response message. In such cases the 3GPP NF shall also support the handling of the "ProblemDetails" JSON object with the Content-Type header field set to the value "application/problem+json" for HTTP status codes 4xx and 5xx, if the corresponding API definition in the related technical specification does not specify another response body for the corresponding status code;
  • service specific, which is marked in Table as "SS" and means that the requirement to process the HTTP status code depends on the definition of the specific API; or
  • not applicable, which is marked in Table as "N/A". This means that the specific HTTP status code shall not be used for the specific HTTP method within the 3GPP NFs.
HTTP status code HTTP method
DELETE GET PATCH POST PUT OPTIONS
100 Continue N/AN/AN/AN/AN/AN/A
200 OK (NOTE 1, NOTE 2) SSMSSSSSSM
201 Created N/AN/AN/ASSSSN/A
202 Accepted SSN/ASSSSSSN/A
204 No Content (NOTE 2) MN/ASSSSSSSS
300 Multiple Choices N/AN/AN/AN/AN/AN/A
303 See Other SSSSN/ASSSSN/A
307 Temporary Redirect SSSSSSSSSSSS
308 Permanent Redirect SSSSSSSSSSSS
400 Bad Request MMMMMM
401 Unauthorized MMMMMM
403 Forbidden MMMMMM
404 Not Found MMMMMM
405 Method Not Allowed SSSSSSSSSSSS
406 Not Acceptable N/AMN/AN/AN/ASS
408 Request Timeout SSSSSSSSSSSS
409 Conflict N/ASSSSSSSSN/A
410 Gone SSSSSSSSSSSS
411 Length Required N/AN/AMMMSS
412 Precondition Failed SSSSSSSSSSN/A
413 Payload Too Large N/AN/AMMMSS
414 URI Too Long N/ASS (3)N/AN/ASSN/A
415 Unsupported Media Type N/AN/AMMMSS
429 Too Many Requests MMMMMM
500 Internal Server Error MMMMMM
501 Not Implemented SSSSSSSSSSSS
502 Bad Gateway MMMMMM
503 Service Unavailable MMMMMM
504 Gateway Timeout SSSSSSSSSSSS
NOTE 1:
"200 OK" response used on SBI shall contain body.
NOTE 2:
If the NF acting as an HTTP Client receives 2xx response code not appearing in table, the NF shall treat the received 2xx response:
  • as "204 No Content" if 2xx response does not contain body; and
  • as "200 OK" if 2xx response contains body.
NOTE 3:
If GET method includes any query parameter, the NF acting as an HTTP Client shall support "414 URI Too Long" status code.
Up

5.2.7.2  NF as HTTP ServerWord‑p. 45

A NF acting as an HTTP server shall be able to generate HTTP status codes specified in clause 5.2.7.1 per indicated HTTP method.
A request using an HTTP method which is not supported by any resource of a given 5GC SBI API shall be rejected with the HTTP status code "501 Not Implemented".
If the specified target resource does not exist, the NF shall reject the HTTP method with the HTTP status code "404 Not Found".
If the NF supports the HTTP method for several resources in the API, but not for the target resource of a given HTTP request, the NF shall reject the request with the HTTP status code "405 Method Not Allowed" and shall include in the response an Allow header field containing the supported method(s) for that resource.
If a received HTTP request contains unknown IEs, i.e. Information Elements within the JSON body, the NF may discard such IEs and shall process the rest of the request message, unless the schema definition of the received message prohibits the presence of additional IEs or constrains their types. There are cases (e.g. Nnrf_NFManagement API) where the receiver of certain HTTP requests needs to process unknown IEs (e.g. to store in NRF an NF Profile containing vendor-specific attributes, and send them in NFDiscovery results).
If a received HTTP request contains IEs or query parameters not compliant with the schema defined in the corresponding OpenAPI specification, the NF should reject the request with the appropriate error code, e.g. "400 Bad Request (INVALID_MSG_FORMAT)", even when the failed IEs are defined as optional by the schema.
If a received HTTP PATCH request contains a body with modification instruction(s) for unknown attribute(s) in addition to modification instruction(s) for known attribute(s), the NF shall:
  1. implement all the modification(s) for known attribute(s) and unknown attribute(s) if explicitly specified in the corresponding specification of the API; or
  2. otherwise, implement the modification(s) for known attribute(s) and discard those modification instruction(s) for unknown attribute(s). The NF may additionally indicate in the response the result of the execution of the PATCH request, i.e. which modification(s) are implemented and/or which modification(s) are discarded, using the "PatchResult" JSON object as defined in TS 29.571.
If the NF supports the HTTP method by a target resource but the NF cannot successfully fulfil the received request, the following requirements apply.
A NF as HTTP Server should map status codes to the most similar 3xx/4xx/5xx HTTP status code specified in Table 5.2.7.1-1. If no such code is applicable, it should use "400 Bad Request" status code for errors caused by client side or "500 Server Internal Error" status code for errors caused on server side.
If the received HTTP request contains unsupported payload format, the NF shall reject the HTTP request with the HTTP status code "415 Unsupported Media Type". If the HTTP PATCH method is rejected due to unsupported patch document, the NF shall include the Accept-Patch header field set to the value of supported patch document media types for a target resource i.e. to "application/merge-patch+json" if the NF supports "JSON Merge Patch" and to "application/json-patch+json" if the NF supports "JSON Patch". If the received HTTP PATCH request contains both "JSON Merge Patch" and "JSON Patch" documents and the NF supports only one of them, the NF shall ignore unsupported patch document.
If the received HTTP request contains payload body larger than the NF is able to process, the NF shall reject the HTTP request with the HTTP status code "413 Payload Too Large".
If the result of the received HTTP POST request used for a resource creation would be equivalent to the existing resource, the NF shall reject the HTTP request with the HTTP status code "303 See Other" and shall include in the HTTP response a Location header field set to the URI of the existing resource.
Protocol and application errors common to several 5GC SBI API specifications for which the NF shall include in the HTTP response a payload body ("ProblemDetails" data structure or application specific error data structure) with the "cause" attribute indicating corresponding error are listed in Table 5.2.7.2-1.
Protocol or application Error HTTP status code Description
INVALID_API400 Bad RequestThe HTTP request contains an unsupported API name or API version in the URI.
INVALID_MSG_FORMAT400 Bad RequestThe HTTP request has an invalid format.
INVALID_QUERY_PARAM400 Bad RequestThe HTTP request contains an unsupported query parameter in the URI. (NOTE 1)
MANDATORY_QUERY_PARAM_INCORRECT400 Bad RequestA mandatory query parameter, or a conditional query parameter but mandatory required, for an HTTP method was received in the URI with semantically incorrect value. (NOTE 1)
OPTIONAL_QUERY_PARAM_INCORRECT400 Bad RequestAn optional query parameter for an HTTP method was received in the URI with a semantically incorrect value that prevents successful processing of the service request. (NOTE 1)
MANDATORY_QUERY_PARAM_MISSING400 Bad RequestQuery parameter which is defined as mandatory, or as conditional but mandatory required, for an HTTP method is not included in the URI of the request. (NOTE 1)
MANDATORY_IE_INCORRECT400 Bad Request A mandatory IE (within the JSON body or within a variable part of an "apiSpecificResourceUriPart" or within an HTTP header), or conditional IE but mandatory required, for an HTTP method was received with a semantically incorrect value. (NOTE 1)
OPTIONAL_IE_INCORRECT400 Bad RequestAn optional IE (within the JSON body or within an HTTP header) for an HTTP method was received with a semantically incorrect value that prevents successful processing of the service request. (NOTE 1)
MANDATORY_IE_MISSING400 Bad Request A mandatory IE (within the JSON body or within the variable part of an "apiSpecificResourceUriPart" or within an HTTP header), or conditional IE but mandatory required, for an HTTP method is not included in the request. (NOTE 1)
UNSPECIFIED_MSG_FAILURE400 Bad RequestThe request is rejected due to unspecified client error. (NOTE 2)
RESOURCE_CONTEXT_NOT_FOUND400 Bad RequestThe notification request is rejected because the callback URI still exists in the receiver of the notification, but the specific resource context identified within the notification payloadis not found in the NF service consumer.
CCA_VERIFICATION_FAILURE403 ForbiddenThe request is rejected due to a failure to verify the CCA at the receiving entity (e.g. NRF or NF service producer).
TOKEN_CCA_MISMATCH403 ForbiddenThe request is rejected due to a mismatch between the subject claim in the access token and subject claim in the CCA.
MODIFICATION_NOT_ALLOWED403 ForbiddenThe request is rejected because the contained modification instructions attempt to modify IE which is not allowed to be modified.
SUBSCRIPTION_NOT_FOUND404 Not FoundThe request for modification or deletion of subscription is rejected because the subscription is not found in the NF.
RESOURCE_URI_STRUCTURE_NOT_FOUND404 Not Found The request is rejected because a fixed part after the first variable part of an "apiSpecificResourceUriPart" (as defined in clause 4.4.1 of TS 29.501) is not found in the NF.
This fixed part of the URI may represent a sub-resource collection (e.g. contexts, subscriptions, policies) or a custom operation. (NOTE 5)
INCORRECT_LENGTH411 Length RequiredThe request is rejected due to incorrect value of a Content-length header field.
NF_CONGESTION_RISK429 Too Many RequestsThe request is rejected due to excessive traffic which, if continued over time, may lead to (or may increase) an overload situation of the NF instance. (NOTE 7)
NF_SERVICE_CONGESTION_RISK429 Too Many RequestsThe request is rejected due to excessive traffic which, if continued over time, may lead to (or may increase) an overload situation of the NF service instance. (NOTE 7)
INSUFFICIENT_RESOURCES500 Internal Server ErrorThe request is rejected due to insufficient resources.
UNSPECIFIED_NF_FAILURE500 Internal Server ErrorThe request is rejected due to unspecified reason at the NF. (NOTE 3)
SYSTEM_FAILURE500 Internal Server ErrorThe request is rejected due to generic error condition in the NF.
NF_FAILOVER500 Internal Server ErrorThe request is rejected due to the unavailability of the NF, and the requester may trigger an immediate re-selection of an alternative NF based on this information. (NOTE 6) (NOTE 8).
NF_SERVICE_FAILOVER500 Internal Server ErrorThe request is rejected due to the unavailability of the NF service, and the requester may trigger an immediate re-selection of an alternative NF service based on this information. (NOTE 6) (NOTE 8).
INBOUND_SERVER_ERROR502 Bad GatewayThe request is rejected due to the receipt of an 5xx error from an inbound server that the NF Service Producer accessed while attempting to fulfil the request (see clause 6.4.2.1).
NF_CONGESTION503 Service UnavailableThe NF instance experiences congestion and performs overload control, which does not allow the request to be processed. (NOTE 4) (NOTE 7)
NF_SERVICE_CONGESTION503 Service UnavailableThe NF service instance experiences congestion and performs overload control, which does not allow the request to be processed. (NOTE 4) (NOTE 7)
TARGET_NF_NOT_REACHABLE504 Gateway TimeoutThe request is not served as the target NF is not reachable. (NOTE 6)
TIMED_OUT_REQUEST504 Gateway TimeoutThe request is rejected due a request that has timed out at the HTTP client (see clause 6.11.2).
NOTE 1:
"invalidParams" attribute shall be included in the "ProblemDetails" data structure indicating unsupported, missing or incorrect IE(s) or query parameter(s) or 3gpp-Sbi-Discovery-* header(s).
NOTE 2:
This application error indicates error in the HTTP request and there is no other application error value that can be used instead.
NOTE 3:
This application error indicates error condition in the NF and there is no other application error value that can be used instead.
NOTE 4:
If the reason for rejection is a temporary overload, the NF may include in the response a Retry-After header field to indicate how long the service is expected to be unavailable.
NOTE 5:
If the request is rejected because of an error in an URI before the first variable part of an "apiSpecificResourceUriPart", the "404 Not Found" HTTP status code may be sent without "ProblemDetails" data structure indicating protocol or application error.
NOTE 6:
The NF service consumer (as receiver of the cause code) should stop sending subsequent requests addressing the resource contexts in the producer's NF instance (for NF_FAILOVER) or NF service instance (for NF_SERVICE_FAILOVER) to avoid massive rejections. The NF service consumer may reselect an alternative NF service producer as specified clause 6.5 of TS 23.527, e.g. using the Binding Indication of resource context. It is implementation specific for the NF service consumer to determine when and whether the NF producer becomes available again, e.g. when there is no other alternative available or at expiry of a local configured timer.
NOTE 7:
When a NF service producer receives NF_CONGESTION_RISK, NF_SERVICE_CONGESTION_RISK, NF_CONGESTION and NF_SERVICE_CONGESTION from a NF service consumer when sending a request message towards a callback/notification URI, the NF service producer shall identify the NF service consumer that is congested using either the authority of the notification/callback URI or together with the "callback-uri-prefix" if it is provided in 3gpp-Sbi-consumer-info as specified in clause 5.2.3.3.7.
NOTE 8:
The NF service producer (as receiver of the cause code) should stop sending subsequent notification requests addressing the session contexts towards the consumer NF (service) instance to avoid massive rejections, where the consumer NF (service) instance shall be identified by either the authority of the notification/callback URI or together with the "callback-uri-prefix" if it is provided in 3gpp-Sbi-consumer-info as specified in clause 5.2.3.3.7. The NF service producer may reselect an alternative NF service consumer as specified in clause 6.6 of TS 23.527, e.g. using the Binding Indication of the session context. It is implementation specific for the NF service producer to determine when and whether the NF consumer becomes available again, e.g. when there is no other alternative available or at expiry of a local configured timer. Note that if a consumer NF service instance complying with an earlier version of the specification shares the same authority with other consumer NF service instances and sends the NF_FAILOVER and NF_SERVICE_FAILOVER causes to a NF service producer while not supporting the new callback-uri-prefix parameter in 3gpp-Sbi-consumer-info, this can result in the NF service producer no longer sending traffic to these consumer NF service instances sharing the same authority.
Up

5.2.7.3  NF as HTTP ClientWord‑p. 50

Besides the HTTP Status Codes defined in the API specification, a NF as HTTP client should support handling of 1xx, 3xx, 4xx and 5xx HTTP Status Codes specified in Table 5.2.7.1-1, following the client behaviour in corresponding RFC where the received HTTP Status Code is defined.
When receiving a not recommended or not recognized 1xx, 3xx, 4xx or 5xx HTTP Status Code, a NF as HTTP client should treat it as x00 status code of the class, as described in Section 6 of RFC 7231.
If 100, 200/204, 300, 400 or 500 response code is not defined by the API specification, the client may follow guidelines below:
  1. For 1xx (Informational):
    1. Discard the response and wait for final response.
  2. For 2xx (Successful):
    1. Consider the service operation is successful if no mandatory information is expected from the response payload in subsequent procedure.
    2. If mandatory information is expected from response payload in subsequent procedure, parse the payload following description in Section 6.2.1 of RFC 7231. If parse is successful and mandatory information is extracted, continue with subsequent procedure.
    3. Otherwise, consider service operation has failure and start failure handling.
  3. For 3xx (Redirection):
    1. Retry the request towards the directed resource referred in the Location header, using same request method.
  4. For 4xx (Client Error):
    1. Validate the request message and make correction before resending. Otherwise, stop process and go to error handling procedure.
  5. For 5xx (Server Error):
    1. Stop process and go to error handling process.
The handling of unknown, unexpected or erroneous HTTP request message IEs shall provide for the forward compatibility of the HTTP APIs used for the service based interfaces. Therefore, the sending HTTP entity shall be able to safely include in a message a new optional IE. Such an IE may also have a new type. A receiving HTTP entity shall behave as specified in clause 5.2.7.2.
Up

5.2.7.4  SCP/SEPP |R16|Word‑p. 51

The SCP or SEPP shall be able to forward the HTTP status codes defined in Table 5.2.7.2-1 from HTTP Server to HTTP client. In addition, it shall be able to generate HTTP status codes to indicate failures during indirect communication (e.g. see clauses 6.10.3.2 and 6.10.6), error handling (see clause 6.10.8), detection and handling of loop path (see clause 6.10.10) and SCP or SEPP overload control (see clause 6.4) as defined in Table 5.2.7.4-1 and Table 5.2.7.4-2.
If the SCP or SEPP detects a loop in the routing path of an HTTP request, it should reject the request with the HTTP status code "400 Bad Request (MSG_LOOP_DETECTED)".
If the received HTTP request contains payload body larger than the SCP or SEPP is able to process, the SCP or SEPP shall reject the HTTP request with the HTTP status code "413 Payload Too Large".
An HTTP status code "429 Too Many Requests (NF_CONGESTION_RISK)" is sent, when the SCP or SEPP detects that a given NF Service Consumer is sending excessive traffic which, if continued over time, may lead to (or may increase) an overload situation in the SCP or SEPP. If the SCP or SEPP decides to redirect HTTP requests to another less loaded SCP or SEPP, it may send the HTTP status code "307 Temporary Redirect" or "308 Permanent Redirect" with the cause attribute set to "SCP_REDIRECTION" (see clause 6.10.9) / "SEPP_REDIRECTION" as defined in Table 5.2.7.4-2.
The SCP or SEPP should map status codes to the most similar 3xx/4xx/5xx HTTP status code specified in Table 5.2.7.4-1 and Table 5.2.7.4-2. If no such code is applicable, it should use "400 Bad Request" status code for errors caused by client side or "500 Server Internal Error" status code for errors caused on server side.
Protocol or application Error HTTP status code Description
INVALID_API400 Bad RequestThe HTTP request contains an unsupported API name or API version in the URI.
INVALID_MSG_FORMAT400 Bad RequestThe HTTP request has an invalid format.
INVALID_QUERY_PARAM400 Bad RequestThe HTTP request contains an unsupported query parameter in the URI. (NOTE 1)
MANDATORY_QUERY_PARAM_INCORRECT400 Bad RequestA mandatory query parameter, or a conditional query parameter but mandatory required, for an HTTP method was received in the URI with semantically incorrect value. (NOTE 1)
OPTIONAL_QUERY_PARAM_INCORRECT400 Bad RequestAn optional query parameter for an HTTP method was received in the URI with a semantically incorrect value that prevents successful processing of the service request. (NOTE 1)
MANDATORY_QUERY_PARAM_MISSING400 Bad RequestQuery parameter which is defined as mandatory, or as conditional but mandatory required, for an HTTP method is not included in the URI of the request. (NOTE 1)
MANDATORY_IE_INCORRECT400 Bad Request A mandatory IE (within a variable part of an "apiSpecificResourceUriPart" or within an HTTP header), or conditional IE but mandatory required, for an HTTP method was received with a semantically incorrect value. (NOTE 1)
OPTIONAL_IE_INCORRECT400 Bad RequestAn optional IE (within an HTTP header) for an HTTP method was received with a semantically incorrect value that prevents successful processing of the service request. (NOTE 1)
MANDATORY_IE_MISSING400 Bad Request A mandatory IE (within the variable part of an "apiSpecificResourceUriPart" or within an HTTP header), or conditional IE but mandatory required, for an HTTP method is not included in the request. (NOTE 1)
UNSPECIFIED_MSG_FAILURE400 Bad RequestThe request is rejected due to unspecified client error. (NOTE 2)
NF_DISCOVERY_FAILURE400 Bad RequestThe request is rejected by the SCP because no NF Service Producer can be found matching the NF service discovery factors (see clause 6.10.6).
INVALID_DISCOVERY_PARAM400 Bad RequestThe request is rejected by the SCP because it contains an unsupported discovery parameter (i.e. unknown 3gpp-Sbi-Discovery-* header) (see clause 6.10.3.2). (NOTE 1)
MSG_LOOP_DETECTED400 Bad RequestThe request is rejected because message loop is detected.
MISSING_ACCESS_TOKEN_INFO400 Bad RequestThe request is rejected due to missing information in the service request that prevents the SCP from requesting an access token to the Authorization Server. See clause 6.10.3.5.
ACCESS_TOKEN_DENIED403 ForbiddenThe request is rejected due to the Authorization Server rejecting to grant an access token to the SCP. See clause 6.10.3.5.
INCORRECT_LENGTH411 Length RequiredThe request is rejected due to incorrect value of a Content-length header field.
NF_CONGESTION_RISK429 Too Many RequestsThe request is rejected due to excessive traffic which, if continued over time, may lead to (or may increase) an overload situation.
INSUFFICIENT_RESOURCES500 Internal Server ErrorThe request is rejected due to insufficient resources.
UNSPECIFIED_NF_FAILURE500 Internal Server ErrorThe request is rejected due to unspecified reason at the SCP or SEPP. (NOTE 3)
SYSTEM_FAILURE500 Internal Server ErrorThe request is rejected due to generic error condition in the SCP or SEPP.
NF_FAILOVER500 Internal Server ErrorThe request is rejected by the SCP due to the unavailability of the NF, and the requester may trigger an immediate re-selection of an alternative NF based on this information.
NF_SERVICE_FAILOVER500 Internal Server ErrorThe request is rejected by the SCP due to the unavailability of the NF service, and the requester may trigger an immediate re-selection of an alternative NF service based on this information.
MAX_SCP_HOPS_REACHED502 Bad GatewayThe request is rejected due to the maximum number of allowed SCP hops has been reached when relaying the request message to the target NF.
NF_DISCOVERY_ERROR502 Bad GatewayThe request is rejected due to the receipt of an 5xx or 429 response from the NRF during an NF Discovery procedure the SCP initiated to fulfil the request.
NF_CONGESTION503 Service UnavailableThe SCP or SEPP experiences congestion and performs overload control, which does not allow the request to be processed. (NOTE 4)
TIMED_OUT_REQUEST504 Gateway TimeoutThe request is rejected due a request that has timed out at the HTTP client (see clause 6.11.2).
TARGET_NF_NOT_REACHABLE504 Gateway TimeoutThe request is not served as the target NF is not reachable (see clause 6.10.8.2).
NRF_NOT_REACHABLE504 Gateway TimeoutThe request is not served due to the NRF being unreachable (see clause 6.10.8.2). structure indicating unsupported, missing or incorrect IE(s) or 3gpp-Sbi-Discovery-* header(s).
NOTE 1:
"invalidParams" attribute shall be included in the "ProblemDetails" data
NOTE 2:
This application error indicates error in the HTTP request and there is no other application error value that can be used instead.
NOTE 3:
This application error indicates error condition in the SCP/SEPP and there is no other application error value that can be used instead.
NOTE 4:
If the reason for rejection is a temporary overload, the SCP/SEPP may include in the response a Retry-After header field to indicate how long the service is expected to be unavailable.
Cause value HTTP status code Description
SCP_REDIRECTION307 Temporary Redirect
308 Permanent Redirect
The request is redirected to a different SCP (see clause 6.10.9).
SEPP_REDIRECTION307 Temporary Redirect
308 Permanent Redirect
The request is redirected to a different SEPP (see clause 6.10.9).
Up

5.2.8  HTTP/2 request retriesWord‑p. 54

All NF services expose APIs across the service based interfaces and the APIs operate on resources. Invocation of an API though a HTTP method may result in the change of state of a resource depending of the request type. When a HTTP/2 client sends a request and it does not receive a response or it experiences a delay, it does not guarantee that the HTTP/2 request has not been processed by the HTTP/2 server.
A HTTP/2 client may retry the same request that uses an idempotent method any time (see Section 4.2.2 of RFC 7231).
Retrying a non-idempotent HTTP/2 request on the same resource before a response for the previous request is received may lead to state changes on the resource with unspecified behaviour. HTTP conditional requests, as specified in RFC 7232 may be used to avoid such situations.
An NF acting as an HTTP/2 client should also retry non-idempotent request if the request has not been processed, i.e. if the identifier of the stream corresponding to the request is larger than the Last-Stream-Id in a GOAWAY frame, or the REFUSED_STREAM error code is included in a RST_STREAM frame for the stream corresponding to the request as specified in Section 8.1.4 of RFC 7540. API specific mechanisms as specified in respective technical specifications may be used for reconciling the state of resources, if the retry is attempted through a new TCP connection after a TCP connection failure.
The number of retry shall be limited. A client should always prefer to retry requests to an alternative server if the initial server is overloaded. In case of general overload situation where all possible servers are overloaded retry mechanisms should be disabled automatically.
Up

5.2.9  Handling of unsupported query parametersWord‑p. 55

Unless specified otherwise for an API, a NF Service Producer that receives an HTTP request with one or more unsupported (i.e. not comprehended) query parameters shall:
  1. for safe HTTP methods (e.g. HTTP GET request):
    • ignore the unsupported query parameters and respond to the request based on the rest of the request (e.g. other supported query parameters); or
    • reject the HTTP request as specified below for non-safe HTTP methods, e.g. based on other query parameters in the request or based on a response becoming very large;
  2. for non-safe HTTP methods:
    • reject the request with a 400 Bad Request including a ProblemDetails IE with:
      • the cause attribute set to INVALID_QUERY_PARAM;
      • the invalidParams attribute indicating the unsupported query parameters;
      • the supportedFeatures attribute listing the features supported by the NF Service Producer, if any, set as specified for HTTP responses in clause 6.6.2.
Up

5.3  Transport ProtocolWord‑p. 55

The Transmission Control Protocol as described in RFC 793 shall be used as transport protocol as required by HTTP/2 (see RFC 7540).
If a Network Function does not register any port number to the NRF then it shall be prepared to receive connections on default port numbers, i.e. TCP port 80 for "http" URIs and TCP port 443 for "https" URIs as specified in RFC 7540.
Up

5.4  Serialization ProtocolWord‑p. 55

The JavaScript Object Notation (JSON) format as described in RFC 8259 shall be used as serialization protocol.
For transmitting large parts of opaque binary data along with JSON format, multipart messages shall be supported using:
  • A multipart/related media type;
  • 3gpp vendor specific content subtype; and
  • Cross-referencing from the JSON payload using the Content-ID field.
Use of multipart messages is documented in specific specifications.

5.5  Interface Definition LanguageWord‑p. 55

OpenAPI Specification [9] shall be used as Interface Definition Language (IDL) of SBI.

Up   Top   ToC