Content for  TS 29.500  Word version:  19.0.0

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 6.4.3.4.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/SEPP 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 6.4.3.4.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, Callback URI, SCP or SEPP (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, SCP or SEPP), 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 occurring, 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/SEPP 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/SEPP 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/SEPP 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.

As part of the overload mitigation, the overload control enforcement NF, i.e. 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 request messages in proportion to the overload level of the peer, which is called request message throttling. The message throttling shall be achieved either by rejecting the request messages, or by redirecting some of request messages to an alternative NF if possible, e.g. when a binding indication was received for the target resource/session context containing binding entities which have not been reported as overloaded. When sending (i.e. redirecting) the request towards an alternative NF to address an existing resource/session context, the sending NF may include a 3gpp-Sbi-Request-Info header in the request to indicate whether the request is redirected to an alternative NF as result of overload enforcement (see clause 5.2.3.3.12). The alternative NF may use this header to determine whether to accept the request, e.g. when accepting the request will not further overload the overloaded NF. 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 6.4.3.5.2.

An overloaded NF Service Producer/Consumer/SCP/SEPP 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 6.4.3.4.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 6.1.6.2.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 6.2.6.2.3 in TS 29.510).