6.11 Detection and handling of late arriving requests
29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS
6.11.1 General
The procedures specified in this clause aim at handling more efficiently requests which may arrive late at upstream entities, e.g. in networks experiencing processing or transport delays.
These procedures are optional to support. When supported, the use of these procedures is dependent on operator policy.
6.11.2 Detection and handling of requests which have timed out at the HTTP client
6.11.2.1 General
This procedure enables an HTTP server which receives a request to know when the request times out at the HTTP client, and to stop further processing, at the receiver and further upstream NFs, a request which has timed out at the HTTP client.
The HTTP client and HTTP server shall be NTP synchronized. This procedure may be used between NFs pertaining to the same PLMN, and if allowed by operator policy, between NFs pertaining to different PLMNs.
6.11.2.2 Principles
An HTTP client originating a request may include in the request the 3gpp-Sbi-Sender-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers indicating respectively the absolute time at which the request is originated and the maximum time period to complete the processing of the request; both headers together indicate the absolute time at which the request times out at the HTTP client.
When forwarding a request that includes the 3gpp-Sbi-Sender-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers, the SCP or SEPP may forward these headers unmodified; if the SCP or SEPP modifies and sets the 3gpp-Sbi-Sender-Timestamp to the time when it forwards the request, it shall adjust the 3gpp-Sbi-Max-Rsp-Time accordingly such as to properly reflect the time until which the HTTP client waits for a response.
Upon receipt of a request which contains the 3gpp-Sbi-Sender-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers, the HTTP server should check that the request has not already timed out at the originating HTTP client. The HTTP server may perform additional similar checks during the processing of the request, e.g. upon receipt of a response from the next upstream NF service.
Based on local configuration, the HTTP server may reject a request that is known to have timed out with the HTTP status code "504 Gateway Timeout" and the protocol error "TIMED_OUT_REQUEST"; it may alternatively drop the request. If so, the HTTP server should initiate the release of any resource it may have successfully created towards an upstream entity, to avoid hanging resources in the network.