6.4 Overload Control

29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.4.1 General

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 [16], 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 [7].

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, an SCP or an SEPP 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 , SCP or an SEPP 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).

The NF that performs overload control enforcement may either reject a fraction of request messages, or redirect some request messages towards an alternative NF if possible, to reduce sending HTTP requests towards an overloaded NF. (see clause 6.4.3.5).

6.4.2 Overload Control based on HTTP status codes

6.4.2.1 General

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.

When an NF Service Consumer (e.g. AMF) issues a service request to an NF Service Producer (e.g. SMF), but the NF Service Producer cannot fulfil the request due to receiving a 503 or 429 status code from another NF Service Producer (e.g. PCF), the former NF Service Producer shall reject the service request from the NF Service Consumer with a 502 Bad Gateway HTTP error response including the "problemDetails" with the "cause" attribute set to "INBOUND_SERVER_ERROR". As an exception, the 503 or 429 status code shall be relayed by a V-SMF/I-SMF between AMF and H-SMF/SMF with the remoteError attribute set to "true" as specified in clause 6.1.7.1 of 3GPP TS 29.502 [28].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.

6.4.2.2 HTTP Status Code "503 Service Unavailable"

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.

6.4.2.3 HTTP Status Code "429 Too Many Requests"

This status code may be sent, if supported by the server, when the NF Service Producer detects that NF Service Consumers are sending excessive traffic which, if continued over time, may lead to (or may increase) an overload situation in the NF Service Producer.

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.

6.4.2.4 HTTP Status Code "307 Temporary Redirect"

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.

This status code should also be sent when the SCP or SEPP decides to redirect HTTP requests to another less loaded SCP or SEPP to offload some part of the incoming traffic if it knows the load status of the alternative SCP or SEPP.

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.

6.4.3 Overload Control based on OCI Header

6.4.3.1 General

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 6.4.3.4) 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 6.4.3.5. The OCI is piggybacked in HTTP request or response messages such that the exchange of the OCI does not trigger extra signaling.

An SCP/SEPP experiencing an overload may additionally piggyback OCI with a scope set to the SCP FQDN/SEPP FQDN in HTTP request or response messages, so as to adapt the signaling traffic sent towards the SCP/SEPP.

NOTE 1: Overload control and load control can be supported and activated independently in the network, based on operator policy.

In scenarios with multiple SCPs or with SCP(s) and SEPPs between the NF service producer and the NF service consumer, an SCP or SEPP that receives in an HTTP request or response an OCI with a scope set to an SCP or SEPP FQDN, shall remove this OCI header when forwarding the message to the next hop, and shall perform overload control to reduce sending subsequent service requests or notification requests to the next hop overloaded SCP or SEPP according to the received LCI information.

NOTE 2: An NF service consumer can only receive OCI with a scope set to an SCP or SEPP FQDN from its next hop SCP or SEPP.

The SCPs and SEPPs shall forward OCI headers with a scope set to NF Service Producer or NF Service Consumer received in an HTTP request or response when forwarding the message to the next hop. The NF consumer shall perform overload control to reduce sending subsequent service requests to the overloaded NF Service Producer according to the received OCI information. The NF Service Producer shall perform overload control to reduce sending subsequent notification requests to the overloaded NF Service Consumer according to the received OCI information.

A SEPP may advertize its own OCI information to a next hop NF or SCP in the same PLMN, and/or to the peer SEPP based on operator’s policy. In the latter case, OCI may be advertized in N32-f signalling; when PRINS is used over N32-f, the OCI header for the SEPP FQDN shall be inserted in the outer N32-f message, i.e. not within the N32-f payload.

6.4.3.2 Conveyance of Overload Control Information

OCI shall be conveyed within the 3gpp-Sbi-Oci HTTP header. When an NF Service Producer/Consumer/SCP/SEPP detects overload conditions, it shall send OCI within the 3gpp-Sbi-Oci HTTP header (i.e. OCI header, see clause 5.2.3.2.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/SEPP shall send the "3gpp-Sbi-Oci" header, regardless of whether the peer supports the feature (see clause 6.4.3.6). The header is ignored by the receiver if the latter does not support the OLC-H feature.

6.4.3.3 Frequency of Conveyance

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.

6.4.3.4 Overload Control Information

6.4.3.4.1 General Description

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).

6.4.3.4.2 Overload Control Timestamp

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.

NOTE: An NF Service Producer/Consumer can receive OCI for the same target scope from different NF service Consumers/Producers, when the scope of the OCI corresponds to an NF set or NF service set.

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.

6.4.3.4.3 Overload Reduction Metric

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.

6.4.3.4.4 Overload Control Period of Validity

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.

6.4.3.4.5 Scope of OCI

6.4.3.4.5.1 Introduction

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.

6.4.3.4.5.2 Scope of OCI signalled by an NF Service Producer

6.4.3.4.5.2.1 General

The OCI sent by an NF Service Producer shall include one and only one of the parameters defined in Table 6.4.3.4.5.2-1.

Table 6.4.3.4.5.2-1: Supported scopes for OCI signalled by an NF Service Producer

Parameter	Value	OCI scope (i.e. OCI applies to)	Examples
NF-Instance	NF Instance ID	All services of the NF instance identified by the NF Instance ID.	NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8
NF-Set	NF Set ID	All services of all NF instances of the NF set identified by the NF Set ID.	NF-Set: set1.udmset.5gc.mnc012.mcc345
NF-Service-Instance (and NF-Inst)	NF Service Instance ID (and NF Instance ID)	The service instance identified by the NF Service Instance ID and the NF instance Id (if available) or the last known NF instance ID.	NF-Service-Instance: serv1.smf1; NF-Inst: 54804518-4191-46b3-955c-ac631f953ed8
NF-Service-Set	NF Service Set ID	All service instances of the NF service set identified by the NF service set ID.	NF-Service-Set: setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345

6.4.3.4.5.2.2 Additional scope parameters for S-NSSAI/DNN based overload control by SMF

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).

NOTE 1: When all the internal and external resources, applicable to the S-NSSAI/DNNs, are available for all the S-NSSAI/DNNs served by an SMF, overload control at SMF (service) set or SMF (service) instance level is exactly the same as S-NSSAI/DNN level overload information of that SMF, for each of its S-NSSAIs/DNNs, and hence, performing overload control at SMF (service) set or SMF (service) instance level is sufficient.

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 6.4.3.4.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).

NOTE 2: It is not allowed to report OCI for a DNN only or for an S-NSSAI only.

See Table 6.4.3.4.5.2.2-1.

Table 6.4.3.4.5.2.2-1: Additional scope parameters for S-NSSAI/DNN based overload control by SMF

Parameter	Value	OCI scope (i.e. OCI applies to)	Examples
S-NSSAI	One or more S-NSSAI values	DNN(s) from indicated S-NSSAI(s), for the service(s) of NF instance(s) as defined in Table 6.4.3.4.5.2-1.	S-NSSAI: %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs
DNN	One or more DNN values
NOTE 1: Both the S-NSSAI and DNN parameters shall be present. The S-NSSAI and DNN parameters shall be provided with either the NF-Instance, NF-Set, NF-Service-Instance or NF-Service-Set parameter (see Table 6.4.3.4.5.2-1). NOTE 2: The S-NSSAI parameter in the Example corresponds to the JSON encoding: {"sst": 1, "sd": "A08923"} (see clause 5.2.3.1).

An SMF shall advertise S-NSSAI/DNN based overload control for at most 10 DNNs.

NOTE 3: Considering various aspects such as the processing and storage requirements at the overloaded SMF entity and the receiver, the number of important DNNs for which overload control advertisement could be necessary, interoperability between the NFs of different vendors, it was chosen to define a limit on the maximum number of DNNs for advertising the overload control information.

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 advertised 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.

6.4.3.4.5.3 Scope of OCI signalled by an NF Service Consumer

The OCI sent by an NF Service Consumer shall include one and only one of the parameters defined in Table 6.4.3.4.5.3-1.

Table 6.4.3.4.5.3-1: Supported scopes for OCI signalled by an NF Service Consumer

Parameter	Value	OCI scope (i.e. OCI applies to)	Examples
Callback-Uri	One or more URI(s) including a scheme, authority and an optional path	All notifications (or callbacks) with a notification (or callback) URI matching the Callback-Uri parameter value. (NOTE 1)	Callback-Uri: https://pcf12.operator.com Callback-Uri: https://pcf12.operator.com/serviceY Callback-Uri: https://pcf12.operator.com/serviceY/abc & https://pcf12.operator.com/serviceY/def
NF-Instance	NF Instance ID	All notifications (or callbacks) bound to: – the NF Instance ID; or – an NF service instance or an NF service set of this NF Instance ID. (NOTE 2)	NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8
NF-Set	NF Set ID	All notifications (or callbacks) bound to: – the NF Set ID; – an NF instance of the NF Set ID; or – an NF service instance or an NF service set of an NF Instance of the NF Set ID. (NOTE 2)	NF-Set: set1.udmset.5gc.mnc012.mcc345
NF-Service-Instance (and NF-Inst)	NF Service Instance ID (and NF Instance ID)	All notifications (or callbacks) bound to: – the NF service instance identified by the NF Service Instance ID and the NF instance Id (if available) or the last known NF instance ID. (NOTE 2)	NF-Service-Instance: serv1.smf1; NF-Inst: 54804518-4191-46b3-955c-ac631f953ed8
NF-Service-Set	NF Service Set ID	All notifications (or callbacks) bound to: – the NF Service Set ID; or – an NF service instance of the NF Service Set ID. (NOTE 2)	NF-Service-Set: setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345
NF-Instance or NF-Set and Service-Name	As defined above and as defined for servname in clause 5.2.3.2.5	All notifications (or callbacks) bound to the service indicated in Service-Name within the NF instance ID or NF Set ID, as defined above (NOTE 2)	NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8; Service-Name:def
NOTE 1: A notification (or callback) URI matches the Callback-Uri parameter value if the former contains the same scheme, the same authority and has a path that encompasses the path of the latter. NOTE 2: Notification (or callbacks) may be bound to an NF instance, an NF set, an NF service instance or an NF service set by a request creating a subscription or a callback resource with a Binding Indication as specified in clauses 6.12.4 and 6.12.5.

EXAMPLE 1: Assuming that a PCF has created the following subscriptions in an AMF:

– subscription 1: notification URI=https://pcf12.example.com/serviceX/1234

– subscription 2: notification URI=https://pcf12.example.com/serviceY/abc

– subscription 3: notification URI=https://pcf12.example.com/serviceY/def

When experiencing overload, if the PCF signals the following OCI scope:

– Callback-Uri=https://pcf12.example.com, the OCI applies to notifications of all the subscriptions;

– Callback-Uri=https://pcf12.example.com/serviceY, the OCI applies to notifications of subscriptions 2 and 3;

– Callback-Uri=https://pcf12.example.com/serviceY/abc, the OCI applies to notifications of subscription 2.

EXAMPLE 2: Assuming that a PCF has created the following subscriptions in an AMF:

– subscription 1: notifications bound to PCF service set X, within PCF12 Instance ID, within PCF Set Z

– subscription 2: notifications bound to PCF service set Y, within PCF12 Instance ID, within PCF Set Z

– subscription 3: notifications bound to PCF12 Instance ID and service "def", within PCF Set Z

When experiencing overload, if the PCF signals the following OCI scope:

– NF-Instance=PCF12 Instance ID, the OCI applies to notifications of all the subscriptions;

– NF-Service-Set=Service Set Y of PCF12 Instance ID, the OCI applies to notifications of subscription 2;

– NF-Instance=PCF12 Instance ID and Service="def", the OCI applies to notifications of subscription 3.

6.4.3.4.5.4 Scope of OCI signalled by an SCP

The OCI sent by an SCP shall include one and only one of the parameters defined in Table 6.4.3.4.5.4-1.

Table 6.4.3.4.5.4-1: Supported scopes for OCI signalled by an SCP

Parameter	Value	OCI scope (i.e. OCI applies to)	Examples
SCP-FQDN	SCP FQDN	All requests towards the SCP identified by the SCP FQDN.	SCP-FQDN: scp1.example.com

6.4.3.4.5.5 Scope of OCI signalled by an SEPP

The OCI sent by an SEPP shall include one of the parameters defined in Table 6.4.3.4.5.5-1.

Table 6.4.3.4.5.5-1: Supported scopes for OCI signalled by an SEPP

Parameter	Value	LCI scope (i.e. LCI applies to)	Examples
SEPP-FQDN	SEPP FQDN	All requests towards the SEPP identified by the SEPP FQDN.	SEPP-FQDN: sepp1.example.com

6.4.3.5 Overload Control Enforcement

6.4.3.5.1 Message Throttling

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.

6.4.3.5.2 Loss Algorithm

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.

NOTE: For example, if an NF Service Producer/Consumer/SCP/SEPP requests a peer to reduce the traffic by 10%, then that peer throttles 10% of the traffic that would have otherwise been sent to this NF Service Producer/Consumer/SCP/SEPP.

6.4.3.6 OLC-H feature support

6.4.3.6.1 Indicating supports for the OLC-H feature

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 3GPP TS 29.510 [8]).

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 3GPP TS 29.510 [8]).