Service Based Interfaces use HTTP/2 over TCP for communication between the NF Services. TCP provides transport level congestion control mechanisms as specified in IETF RFC 5681 , which may be used for congestion control between two TCP endpoints (i.e., hop by hop). HTTP/2 also provides flow control mechanisms and limitation of stream concurrency that may be configured for connection level congestion control, as specified in IETF RFC 7540 .
In addition to TCP and HTTP/2 congestion control mechanisms, the following end to end application-level overload control mechanisms are defined.
Overload control enables an NF Service Producer, an NF Service Consumer or an SCP becoming or being overloaded to gracefully reduce its incoming signalling load, by instructing NF Service Consumers to reduce sending service requests or by instructing NF Service Producers to reduce sending notification requests respectively, according to its available signalling capacity to successfully process the requests. An NF Service Producer, NF Service Consumer or SCP is in overload when it operates over its signalling capacity.
When being instructed by a NF Service Consumer to apply overload control, the NF Service Producer shall perform the signaling reduction towards the NF Service Consumer only for the notifications or callback requests according to the overload scope, and not for any NF services which may be produced by the same NF (for which separate OCI may be advertised by the NF when acting as NF producer), even when the overload scope is on NF Instance level or NF Set level.
Overload control aims at shedding the incoming traffic as close to the traffic source as possible generally when an overload has occurred (reactive action), so to avoid spreading the problem inside the network and to avoid using resources of intermediate entities in the network for signalling that cannot anyhow be served by the overloaded entity.
Overload control should continue to allow for preferential treatment of priority users (e.g. MPS) and emergency services.
Overload control may be performed based on HTTP status codes returned in HTTP responses (as defined in clause 6.4.2) or based on Overload Control Information (OCI) signalled in HTTP request or response (as defined in clause 6.4.2).
Overload control based on HTTP status code shall be supported per NF service / API according to the principles defined in this clause.
An NF Service Producer may mitigate a potential overload status by sending the NF Service Consumer the following HTTP status codes as a response to requests received during, or close to reaching, an overload situation:
503 Service Unavailable;
429 Too Many Requests; or
307 Temporary Redirect
The first 2 status codes (503 and 429) are intended to inform the NF Service Consumer that the server cannot handle the current received traffic rate, so it shall abate the traffic sent to the NF Service Producer by throttling part of this traffic locally at the NF Service Consumer, or diverting it to an alternative destination (another NF Service Producer where an alternative resource exists) that is not overloaded. If possible, traffic diversion shall always be preferred to throttling; the result of the throttling is a permanent rejection of the transaction.
If the client needs to abate a certain part of the available traffic, it shall do it based on the determined priority of each message.
Depending on regional/national requirements and network operator policy, requests related to priority traffic (e.g. MPS) and emergency shall be the last to be throttled by the client, and shall be exempted from throttling due to overload control up to the point where the required traffic reduction cannot be achieved without throttling the priority requests.
The last status code (307) is intended to inform the NF Service Consumer about the availability of other endpoints where the service offered by the NF Service Producer is available, so the NF Service Consumer does not need to discard traffic locally.
This status code should be sent when the NF Service Producer undergoes an overload situation, and it needs to reject HTTP requests. The NF Service Producer may include detailed information about its status in the ProblemDetails JSON element, in the HTTP response body. Also, the HTTP header field "Retry-After" may be added in the response to convey an estimated time (in number of seconds) for the recovery of the service.
As for all 5xx status codes, this indicates a server-related issue (not limited to a specific client, or HTTP method), and it indicates that the server is incapable of performing the request.
Upon receipt of a "503 Service Unavailable" status code, the NF Service Consumer shall monitor the amount of rejected and timed-out traffic, in comparison to the accepted traffic by the NF Service Producer, and it shall abate (by divertion or throttling) the traffic sent to the NF Service Producer in such a way that the rate between accepted and rejected traffic improves with time, and eventually reaches a situation where the server accepts all requests once the overload status ceases at the server. The mechanism to achieve this is implementation-specific; Annex A contains a description of an example algorithm based on "adaptive throttling" of the traffic sent by the NF Service Consumer towards an NF Service Producer.
This status code may be sent, if supported by the server, when the NF Service Producer 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 NF Service Producer.
How the NF Service Producer detects that the incoming traffic comes from a same NF Service Consumer, and therefore subject to a given traffic rate limit, is out of the scope of this specification. The HTTP header field "Retry-After" may be added in the response to indicate how long the NF Service Consumer has to wait before making a new request.
As for all 4xx status codes, this indicates a client-related issue (not limited to a specific HTTP method), and it indicates that the client seems to be misbehaving.
This status code should be sent when the NF Service Producer decides to redirect HTTP requests to another less loaded server, or HTTP/2 end point, to offload some part of the incoming traffic, with the goal to avoid entering (or to mitigate) an overload situation. The NF Service Producer shall not use it if it does not know the load status of the alternative server.
How the NF Service Producer becomes aware of the load levels of other servers or HTTP/2 end points is deployment-specific, and out of the scope of this specification. The URI for the temporary redirection shall be given by the Location header field of the response.
As for all 3xx status codes (redirection), this indicates a client-related action; the client shall be responsible of the detection of infinite redirection loops.
This clause specifies details of the Overload Control based on OCI Header (OLC-H) solution. The solution is independent from the Overload Control based on HTTP status codes solution.
Support of OLC-H is optional, but if the feature is supported, the requirements specified in the following clauses shall apply.
Overload conditions are detected by an NF Service Producer/Consumer when the number of incoming service requests exceeds the maximum number of messages supported by the receiving entity, e.g. when the internally available resources of the NF Service Producer/Consumer, such as processing power or memory, are not sufficient to serve the number of incoming requests. How an NF Service Producer/Consumer identifies that it is overloaded is implementation specific.
When an NF Service Producer/Consumer reaches an implementation dependent overload threshold, the NF Service Producer/Consumer shall convey the Overload Control Information (OCI, see clause 188.8.131.52) to its peer entity (Consumer or Producer, respectively). Based on the received OCI, the peer shall adjust the signaling it sends to the overloaded entity according to the OCI as specified in clause 184.108.40.206. The OCI is piggybacked in HTTP request or response messages such that the exchange of the OCI does not trigger extra signaling.
An SCP experiencing an overload may additionally piggyback OCI with a scope set to the SCP FQDN in HTTP request or response messages, so as to adapt the signaling traffic sent towards the SCP.
OCI shall be conveyed within the 3gpp-Sbi-Oci HTTP header. When an NF Service Producer/Consumer/SCP detects overload conditions, it shall send OCI within the 3gpp-Sbi-Oci HTTP header (i.e. OCI header, see clause 220.127.116.11.9) to the peer entity (Consumer or Producer, respectively). The OCI header shall be piggybacked on a signalling message that is sent to the peer.
The NF Service Producer/Consumer/SCP shall send the "3gpp-Sbi-Oci" header, regardless of whether the peer supports the feature (see clause 18.104.22.168). The header is ignored by the receiver if the latter does not support the OLC-H feature.
How often or when the sender conveys the OCI is implementation specific. The sender shall ensure that new or updated OCI is conveyed to the target receivers with an acceptable delay, such that the purpose of the information (i.e. effective overload control protection) is achieved. The following are some of the potential approaches the sender may implement for conveying the OCI:
the sender may convey the OCI towards a receiver only when the new/changed value has not already been conveyed to the given receiver;
the sender may convey the OCI periodically;
the sender may convey the OCI towards a receiver to restart the OCI period of validity.
The sender may also implement a combination of one or more of the above approaches.
A NF Service Producer may include one or more OCI header(s) in a service response with any HTTP status code (e.g. 2xx, 3xx, 4xx), or in a notification request message sent to a NF Service Consumer. An NF Service Producer may report OCI for different scopes, e.g.:
to report OCIs for an NF service instance, an NF service set and/or an NF instance;
to report OCIs at the level of an SMF (service) instance or SMF (service) set, and for specific S-NSSAI/DNNs;
to report OCIs for different S-NSSAI/DNNs of an SMF (service) instance or SMF (service) set.
A NF Service Producer may also include OCI header(s) with different scopes in different messages, e.g. an SMF may report OCI for the entire SMF instance first, and then for a specific S-NSSAI/DNN only, if the overload conditions have changed and the SMF ends up with an overload only affecting a specific S-NSSAI/DNN.
An NF that receives OCI headers with different scopes, in the same message or in different messages, shall handle each OCI independently from each other. For instance, if an NF service consumer receives one OCI with the scope of an NF (Service) Set and then another OCI with the scope of an NF (Service) instance that pertains to the NF (Service) Set, the NF shall store the latter OCI and also consider that the former OCI is still valid for the NF (Service) Set until the related period of validity expires.
If an NF Service Consumer receives more than one OCI with overlapping scopes, e.g. one OCI with NF (service) instance scope and another OCI with NF (service) Set scope, the NF Service Consumer should perform overload control towards a target NF service instance considering the OCI received with the finer scope (i.e. in this example the overload of the NF (service) instance). For instance, if an AMF receives one OCI with an SMF instance scope and with an overload reduction metric of 20%, and one OCI with the scope of a specific SMF service set of the same SMF instance and with an overload reduction of 50%, the AMF should throttle 50% of the traffic targeting the specific SMF service set and 20% of the traffic targeting other SMF services instances of the SMF instance (if no valid OCI is available for the other SMF service instances).
For S-NSSAI/DNN based overload control (see clause 22.214.171.124.5.2.2), when signalling OCI for an SMF (service) instance or an SMF (service) set in a message, the SMF shall always include the full set of overload control information applicable to the SMF (service) instance or SMF (service) set, i.e. OCI for the SMF (service) instance or an SMF (service) set level and/or OCI for specific S-NSSAI/DNNs, even if only a subset of the OCI has changed; these OCIs shall contain the same Overload Control Timestamp. When including OCI for some S-NSSAI/DNN(s), the SMF should not provide any OCI for the SMF (service) instance or an SMF (service) set level unless OCI for such level is also applicable.
If an NF Service Consumer receives OCIs with overlapping scopes for an SMF (service) instance or an SMF (service) set level and for specific S-NSSAI/DNNs, the NF Service Consumer should perform overload control towards a target SMF service instance and S-NSSAI/DNN considering the OCI received with the finer scope. For instance, if an AMF receives an OCI for an SMF instance with an overload reduction metric of 20%, and one OCI for a specific S-NSSAI/DNN of the same SMF instance with an overload reduction of 50%, the AMF should throttle 50% of the traffic targeting the specific S-NSSAI/DNN and 20% of the traffic targeting other S-NSSAI/DNNs of the SMF instance (if no valid OCI is available for the other S-NSSAI/DNN).
A NF Service Consumer may include one OCI header in a notification response sent with any HTTP status code (e.g. 2xx, 3xx, 4xx), or in a service request sent to a NF Service Producer.
An SCP may additionally include one OCI in any service request or response, or notification request or response, sent towards a NF Service Consumer or NF Service Producer.
The OCI shall always include the Overload Timestamp, Overload Reduction Metric, OCI Period of Validity and Scope parameters (see clause 126.96.36.199.2 for the complete list of parameters).
The Timestamp parameter indicates the time when the OCI was generated. It shall be used by the receiver of the OCI to properly collate out-of-order OCI headers, e.g. due to HTTP/2 stream multiplexing, prioritization and flow control, and to determine whether the newly received OCI has changed compared to the OCI previously received for the same scope.
The receiver shall overwrite any stored OCI for a peer NF, NF set, NF service, NF service set or Callback URI or SCP (according to the scope of the new received OCI) with the newly received OCI, if the new OCI is more recent than the stored information. For instance, for S-NSSAI/DNN based overload control, if the receiver had stored OCI for a peer SMF instance and OCI for a specific S-NSSAI/DNN of that SMF instance, it shall overwrite these OCIs with the new OCI received in a message carrying OCI for the same SMF instance.
If the newly received OCI has the same or an older Timestamp than the previously received OCI for the same scope (e.g. for the same NF, NF Set, NF Service, NF Service Set, Callback URI or SCP), then the receiver shall discard the newly received OCI and continue to apply the overload control procedures based on the previously received OCI values with the most recent Timestamp value.
An entity generating an OCI shall update the Overload Control Timestamp whenever it modifies some information in the OCI or whenever it wants to extend the period of validity of the OCI. The Overload Control Timestamp shall not be updated otherwise.
The Overload Reduction Metric parameter shall have a value in the range from 0 to 100 and shall indicate the percentage of traffic reduction the OCI sender requests the receiver to apply. An Overload Reduction Metric of "0" indicates that the OCI sender is not overloaded (i.e. overload control enforcement procedures are not necessary). The computation of the overload metric is implementation specific.
Considering the processing requirement of the OCI receiver, e.g. to perform overload control enforcement based on the updated Overload Reduction Metric, the sender should refrain from advertising every small variation, e.g. with the granularity up to 5 percentage units. Larger variations should be considered as reasonable enough for advertising a new Overload Reduction Metric and thus justifying the processing requirement (to handle the new information) of the receiver. The exact granularity of the Overload Reduction Metric is an implementation matter.
The conveyance of the OCI signals that an overload situation is occuring, unless the Overload Reduction Metric is set to "0", which signals that the overload condition has ceased. Conversely, the absence of the OCI header in a message does not mean that the overload has abated.
The Period of Validity parameter is a timer, which shall indicate the length of time during which the overload condition specified by the OCI header shall be considered as valid (unless overridden by subsequent new OCI).
An overload condition shall be considered as valid from the time the OCI is received until the Overload Control Period of Validity expires or until another OCI with a new set of information (identified by a more recent Timestamp) is received for the same scope. The timer corresponding to the Period of Validity shall be restarted each time an OCI with a new set of information is received for the same scope. When this timer expires, the last received OCI shall be considered outdated and obsolete (i.e. any associated overload condition shall be considered to have ceased) and the overload control enforcement shall be stopped.
The Period of Validity parameter achieves the following:
it avoids the need for the overloaded NF Service Producer/Consumer/SCP to convey the OCI frequently to its peers when the overload state does not change. Therefore, this minimizes the processing required at the overloaded NF Service Producer/Consumer/SCP and its peers upon sending/receiving HTTP/2 signalling;
it allows to reset the overload condition after some time the NF Service Consumer/Producer having received an overload indication from the overloaded peer, e.g. if no signalling traffic takes place between these HTTP peers for some time due to overload mitigation actions. This also removes the need for the overloaded NF Service Producer/Consumer/SCP to remember the list of its peers to which it has sent a non-null overload reduction percentage and to which it would subsequently need to convey when the overload condition ceases.
The scope of OCI indicates the service requests or notification requests to which the OCI applies, i.e. it identifies the traffic that the OCI sender requests the receiver to process in accordance with the OCI.
The following clauses provide a detailed description of the parameters that define the scope of the OCI header.
It is optional for the SMF to support S-NSSAI/DNN based overload control. When supported, the following requirements shall apply.
S-NSSAI/DNN level overload control refers to advertising of the overload information at S-NSSAI and DNN level granularity and hence applying the mitigation policies based on this information to the signalling traffic related to this S-NSSAI and DNN only. Only an SMF may advertise S-NSSAI/DNN level overload information when it detects overload for certain S-NSSAI/DNNs, e.g. based on shortage of internal or external resources for an S-NSSAI/DNN (e.g. IP address pool).
When performing S-NSSAI/DNN based overload control, the OCI scope shall indicate, in addition to either an NF-Instance, NF-Set, NF-Service-Instance or NF-Service-Set (see Table 188.8.131.52.5.2-1), the combinations of S-NSSAI and DNN for which the OCI sender wants to advertise the overload information using the following parameters: - the S-NSSAI parameter, indicating one or more S-NSSAI values; and
the DNN parameter, indicating one or more associated DNN values from the indicated S-NSSAI(s).
An SMF shall advertise S-NSSAI/DNN based overload control for at most 10 DNNs.
The SMF may advertise overload information for different DNNs of one or more S-NSSAIs in a single OCI header (if the same OCI information, e.g. overload reduction metric, applies to all the DNNs of the S-NSSAI(s)) or in up to 10 OCI headers (if different OCI information needs to be advertized for different DNNs).
An NF selecting an SMF service instance for a given S-NSSAI/DNN shall apply the S-NSSAI/DNN level overload information, if available for that S-NSSAI/DNN.
As part of the overload mitigation, an entity that receives OCI (with a non-null overload reduction metric) shall reduce the total number of request messages, which would have been sent otherwise, towards the overloaded peer(s) corresponding to the received scope, e.g. towards all the NF instances of the NF Set when the scope indicates an NF Set ID and shall not redirect its requests to another entity pertaining to the same scope. This shall be achieved by discarding a fraction of the service request messages in proportion to the overload level of the peer. This is called request message throttling.
Message throttling shall apply to HTTP requests only (any service request including notification request).
Network Functions shall support and use the "Loss" algorithm as specified in clause 184.108.40.206.2.
An overloaded NF Service Producer/Consumer/SCP shall ask its peers to reduce the number of HTTP requests they would otherwise send by conveying in the OCI header the requested traffic reduction percentage within the Overload Reduction Metric parameter, as specified in clause 220.127.116.11.3.
The recipients of the Overload Reduction Metric shall reduce the number of request messages by that percentage, either by redirecting them to an alternate destination if possible (e.g. an HTTP POST request for the Nsmf_PDUSession_CreateSMContext service operation can be sent to an alternate SMF in the same SMF set, if the olcScope is at the NF instance level and the binding indication of the service resource is for an SMF set), or by failing the request and treating it as if it was rejected by the destination entity.
When registering with the NRF (NFRegister) or updating the NRF (NFUpdate), an NF that supports the OLC-H feature shall indicate the feature support (see clause 18.104.22.168.2 in TS 29.510).
When an NF Service Consumer queries an NRF (NFDiscover) to discover services offered by NF Service Producers, the NRF shall indicate to the NF Service Consumer, if the NF Service Producers support the OLC-H feature (see clause 22.214.171.124.3 in TS 29.510).