Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3…   5.2.3.3…   5.2.4…   6…   6.3…   6.4…   6.5…   6.6…   6.7…   6.10…   6.10.3…   6.10.6…   6.10.11…   6.11…   A   B   C   D…

 

5.2.4  HTTP error handlingp. 53

HTTP/2 connection error and stream error shall be supported as specified in Section 5.4 of RFC 9113.
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 pushp. 53

HTTP/2 Server Push as specified in Section 8.4 of RFC 9113 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.4 of RFC 9113.
Up

5.2.6  HTTP/2 connection managementp. 53

The HTTP request / response exchange mechanism as specified in Section 8.1 of RFC 9113 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 9113 a HTTP request / response exchange fully consumes a single stream. When the HTTP/2 Stream IDs on a given HTTP/2 connection 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 9113.
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 9113. 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 9113.
A PING frame shall not be sent more often than every 60 s on each path.
Up

5.2.7  HTTP status codesp. 54

5.2.7.1  Generalp. 54

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 9113.
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 Content 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 (NOTE 4) 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.
NOTE 4:
A 5GC Network Function acting as an HTTP Client and supporting indirect communications shall support "504 Gateway Timeout" status code with "ProblemDetails" (see clause 6.10.8.2).
Up

5.2.7.2  NF as HTTP Serverp. 55

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 content 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 content larger than the NF is able to process, the NF shall reject the HTTP request with the HTTP status code "413 Content 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 content a "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)
ACCESS_TOKEN_CLAIM_MISSING401 UnauthorizedThe request is rejected due to one or more missing claim(s) in the OAuth2.0 access token.
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 content is not found in the NF service consumer.
CCA_VERIFICATION_FAILURE403 ForbiddenThe request is rejected due to a failure to verify the 3gpp-Sbi-Client-Credentials at the receiving entity (e.g. NRF or NF service producer).
SOURCE_NF_CCA_VERIFICATION_FAILURE403 ForbiddenThe request is rejected due to a failure to verify the 3gpp-Sbi-Source-NF-Client-Credentials 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 3gpp-Sbi-Client-Credentials.
TOKEN_SOURCE_NF_CCA_MISMATCH403 ForbiddenThe request is rejected due to a mismatch between the sourceNfInstanceId claim in the access token and subject claim in the 3gpp-Sbi-Source-NF-Client-Credentials.
MODIFICATION_NOT_ALLOWED403 ForbiddenThe request is rejected because the contained modification instructions attempt to modify IE which is not allowed to be modified.
MISSING_PARAMETER403 ForbiddenThe request is rejected because one or more information elements of the requester required to authorize the requester are missing. (NOTE 1)
SUBSCRIPTION_NOT_FOUND404 Not FoundThe request for modification or deletion of a subscription, or the notification request, 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 Clientp. 60

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 15 of RFC 9110.
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 content in subsequent procedure.
    2. If mandatory information is expected from response content in subsequent procedure, parse the content following description in Section 15.2.1 of RFC 9110. 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.
If a received HTTP response message contains unknown IEs (Information Elements within the JSON body), the NF may discard those IEs and it shall process the rest of the response message, as long as it is compliant with the OpenAPI schema definition of such response message.
If a received HTTP response message contains IEs not compliant with the schema defined in the corresponding OpenAPI specification (e.g., because the schema of the response body prohibits the presence of additional IEs or constrains their types), the NF shall stop processing such response message and go to error handling process.
Up

5.2.7.4  SCP/SEPP |R16|p. 61

The SCP or SEPP shall be able to forward the HTTP status codes defined in Table 5.2.7.1-1 and 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 content 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 Content 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.
PLMNID_MISMATCH403 Forbidden The request is rejected by the SEPP due to the PLMN ID in the bearer token carried in the "Authorization" header of the reconstructed message does not match the PLMN ID of the N32-f context.
REQUESTED_PURPOSE_NOT_ALLOWED403 ForbiddenThe request is rejected due to requested purpose provided in the HTTP request is not allowed by the policy. See clause 6.14.
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).
TARGET_PLMN_NOT_REACHABLE504 Gateway TimeoutThe request is not delivered due to issues on interconnect with another PLMN (e.g. issues on N32 connection including contractual reasons).
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 retriesp. 64

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 9.2.2 of RFC 9110).
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 9110 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.7 of RFC 9113. 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.
The support of "detection of duplicated request message" is optional for HTTP clients and servers. When it is supported:
  • the NF acting as an HTTP/2 client shall:
    • include an idempotency key (which shall uniquely identify the request message towards the target NF) in the 3gpp-Sbi-Request-Info header for a non-idempotent request message, e.g. a POST request;
    • include the same idempotency key in the 3gpp-Sbi-Request-Info header when subsequently the NF acting as an HTTP/2 client decides to retry the same request towards the same NF acting as an HTTP/2 server or an alternative NF (e.g. from the same NF (service) Set);
  • the NF acting as an HTTP/2 server, upon receiving a request message containing an idempotency key in the 3gpp-Sbi-Request-Info header, may:
    use the idempotency key to determine if it is a duplicated request message; and if so
  • produce a proper response based on the current state of the resource/session context considering the original request has been processed. The SCP shall forward the idempotency key received from the HTTP client unmodified towards the target NF, regardless of whether the SCP performs (re)selection of the target NF.
The idempotency key that is supplied as part of every non-idempotent request shall be unique and shall not be reused with another request other than a retransmission of the same request. The server may consider an idempotency key as expired after an operator configurable timer.
Up

5.2.9  Handling of unsupported query parametersp. 65

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.2.10  URL Encoding of data |R17|p. 66

5.2.10.1  Generalp. 66

As indicated in IETF RFC 3986, the URI syntax defines a set of characters (a subset of the URI allowed characters) as delimiters of syntax components; those characters are called "reserved" and should not be used in URI fields intended to convey generic data (e.g., in the value part of a query parameter, or in the URI path segments), since this would interfere with the original meaning (syntax) of those reserved characters.
In addition, HTTP/2 request body parts encoded with media type "application/x-www-form-urlencoded" shall also escape reserved and unsafe characters, as described in OpenAPI Specification [9].
Up

5.2.10.2  URL Encoding of URI componentsp. 66

When a URI is composed in the 3GPP 5G APIs, the different components (e.g., path segments, values of query parameters, etc.) shall percent-encode the following "reserved" characters (see Section 2.1 of RFC 3986):
EXCLAMATION MARK (U+0021)!
NUMBER SIGN (U+0023)#
DOLLAR SIGN (U+0024)$
AMPERSAND (U+0026)&
APOSTROPHE (U+0027)'
LEFT PARENTHESIS (U+0028)(
RIGHT PARENTHESIS (U+0029))
ASTERISK (U+002A)*
PLUS SIGN (U+002B)+
COMMA (U+002C),
SOLIDUS (U+002F)/
COLON (U+003A):
SEMICOLON (U+003B);
EQUALS SIGN (U+003D)=
QUESTION MARK (U+003F)?
COMMERCIAL AT (U+0040)@
LEFT SQUARE BRACKET (U+005B)[
RIGHT SQUARE BRACKET (U+005D)]
The following characters (not listed as "reserved" in IETF RFC 3986) shall be percent-encoded:
QUOTATION MARK (U+0022)"
PERCENT SIGN (U+0025)%
SPACE (U+0020) character shall be escaped, either by percent-encoding it (as %20), or by replacing it with character PLUS SIGN (U+002B).
The encoding of query parameters consisting of arrays of strings shall follow the guidelines indicated in clause 5.3.13 of TS 29.501 for the escaping of the COMMA (U+002C) characters.
In addition, implementations may percent-encode other characters, such as:
LEFT CURLY BRACKET (U+007B){
RIGHT CURLY BRACKET (U+007D)}
The receiving entity shall percent-decode the received URI as specified in Section 2.4 of RFC 3986.
Percent-encoding of reserved characters in the URI fields as described in this clause shall also apply to JSON attributes defined as URI and to HTTP header parameters whose ABNF definition uses production rules defined as URI or path-absolute (e.g. prefix parameter of the 3gpp-Sbi-Target-apiRoot header).
Up

5.2.10.3  URL Encoding of HTTP/2 request bodiesp. 67

When composing an HTTP/2 request body with media type "application/x-www-form-urlencoded", the OpenAPI Specification [9] requires that the encoding shall follow Section 8.2.1 of RFC 1866, which indicates:
a)
the "reserved" character set described in Section 2.2 of RFC 1738, shall be percent-encoded:
AMPERSAND (U+0026)&
SOLIDUS (U+002F)/
COLON (U+003A):
SEMICOLON (U+003B);
EQUALS SIGN (U+003D)=
QUESTION MARK (U+003F)?
COMMERCIAL AT (U+0040)@
b)
SPACE (U+0020) character shall be escaped by replacing it with character PLUS SIGN (U+002B).
The following characters (not listed as "reserved" in IETF RFC 1738) shall be percent-encoded:
QUOTATION MARK (U+0022)"
PERCENT SIGN (U+0025)%
COMMA (U+002C),
LEFT SQUARE BRACKET (U+005B)[
RIGHT SQUARE BRACKET (U+005D)]
LEFT CURLY BRACKET (U+007B){
RIGHT CURLY BRACKET (U+007D)}
In addition, implementations may also percent-encode any of the characters listed in clause 5.2.10.2.
Up

5.3  Transport Protocolp. 67

The Transmission Control Protocol as described in RFC 793 shall be used as transport protocol as required by HTTP/2 (see RFC 9113).
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 9113.
Up

5.4  Serialization Protocolp. 68

The JavaScript Object Notation (JSON) format as described in RFC 8259 shall be used as serialization protocol.
The content of JSON attributes of string type shall be encoded as UTF-8.
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 content using the Content-ID field.
Use of multipart messages is documented in specific specifications.
Up

5.5  Interface Definition Languagep. 68

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

Up   Top   ToC