6.3 Load Control

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

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

6.3.1 General

Load control enables an NF Service Producer to signal its load information to NF Service Consumers, either via the NRF (as defined in clause 6.3.2) or directly to the NF Service Consumer (as defined in clause 6.3.3). The load information reflects the operating status of the resources of the NF Service Producer.

Load control allows for better balancing of the load across NF Service Producers, so as to attempt to prevent their overload in first place (preventive action). Load control does not trigger overload mitigation actions, even if the NF Service Producer reports a high load.

NOTE: the load information can be used along similar principles as those described for node-level load control in clause 4A.2 in 3GPP TS 29.303 [39], but with the priority and capacity parameters of candidate NFs obtained from the NRF.

6.3.2 Load Control based on load signalled via the NRF

This clause specifies details of the Load Control based on load signalled via the NRF solution.

During NF discovery procedures (see clause 4.17.4 and 4.17.5 of 3GPP TS 23.502 [4]), the NRF may provide the NF instance and/or the NF service instance information with the NF capacity information advertised during NF Service Registration and/or NF Service Update procedures (see clause 4.17.1 and 4.17.2 of 3GPP TS 23.502 [4] and clause 6.2.6 of 3GPP TS 23.501 [3]). The NRF may also provide load information of the NF instance and/or the NF service instance in NF discovery response.

The NF service consumer that is discovering the NF service producer, may use the available information (e.g. NF capacity information, load information) to select the appropriate NF instance as specified in 3GPP TS 29.510 [8].

6.3.3 Load Control based on LCI Header

6.3.3.1 General

This clause specifies details of the Load Control based on LCI Header solution (LC-H). The solution extends the Load Control based on load signalled via the NRF solution by enabling a direct exchange of the LCI between the NF Service Producer and NF Service Consumer.

Support for the LC-H solution is optional, but if the feature is supported, the requirements specified in the following clauses shall apply.

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

An NF Service Producer that supports the LC-H feature shall signal its load information as further specified in this clause. An NF Service Consumer supporting the LC-H feature shall utilize the load information, for a given scope, that is received with the most recent timestamp from the NRF or from the NF Service Producer via direct signalling, to adaptively balance the load across the candidate NF Service Producers according to their effective load e.g. when creating a resource at an NF Service Producer.

NOTE 2: An NF Service Consumer supporting the LC-H feature can receive the load information without a timestamp from the NRF and an LCI (with a timestamp) from the NF Service Producer. It is an implementation matter how the NF Service Consumer determines which of these contains the most recent load information.

An SCP/SEPP that supports the LC-H feature may additionally piggyback its LCI with a scope set to the SCP FQDN/SEPP FQDN, in HTTP request or response messages, as further specified in this clause. An HTTP client supporting the LC-H feature shall utilize the load information of the SCP/SEPP, which is received with the most recent timestamp, to adaptively balance the load across the available SCPs/SEPPs to reach the HTTP server.

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 a service response or in a notification request an LCI with a scope set to an SCP or SEPP FQDN, shall remove this LCI header when forwarding the message to the next hop, and shall perform load control to adaptively balance the load across the available next hop SCPs/SEPPs for the subsequent service requests according to the received LCI information.

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

The SCPs and SEPPs shall forward LCI headers with a scope set to NF Producer received in a service response or notification request when forwarding the message to the next hop. The NF consumer shall perform the load control to adaptively balance the load across the available NF Producers for the subsequent service requests according to the received LCI information.

A SEPP may advertize its own LCI 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, LCI may be advertized in N32-f signalling; when PRINS is used over N32-f, the LCI header for the SEPP FQDN shall be inserted in the outer N32-f message, i.e. not within the N32-f payload.

6.3.3.2 Conveyance of Load Control Information

LCI shall be conveyed within the 3gpp-Sbi-Lci HTTP header. When conditions for generating an LCI are met, an NF Service Producer, SCP or SEPP shall include the 3gpp-Sbi-Lci header, or LCI header, see clause 5.2.3.2.10) to its peer entities (NF Service Consumers). The LCI header shall be piggybacked on a signalling message that is sent to the NF Service Consumer.

The NF Service Producer, SCP or SEPP shall send the 3gpp-Sbi-Lci header, regardless of whether the peer NF Service Consumer supports the feature (see clause 6.3.3.5). The header is ignored by the NF Service Consumer if the latter does not support the LC-H feature.

6.3.3.3 Frequency of Conveyance

How often or when the sender conveys the LCI is implementation specific. The sender shall ensure that new or updated Load Control Information is conveyed to the target receivers with an acceptable delay, such that the purpose of the information (i.e. the effective load balancing) is achieved.

Considering the processing requirement of the receiver of the LCI (e.g. handling of the new information), the sender should refrain from advertising every small variation (e.g. with the granularity of 1 or 2), in the Load Metric which does not result in useful improvement in NF service producer selection logic at the receiver. A larger variation in the Load Metric, e.g. 5 or more units, should be considered as reasonable enough for advertising the new Load Control Information.

6.3.3.4 Load Control Information

6.3.3.4.1 General Description

A NF Service Producer may include one or more LCI header(s) in a service response or in a notification/callback request message sent to a NF Service Consumer. An NF Service Producer may report LCI with different scopes, e.g.:

– to report LCIs for an NF service instance, an NF service set and/or an NF instance;

– to report LCIs at the level of an SMF (service) instance or SMF (service) set, and for specific S-NSSAI/DNNs;

– to report LCIs for different S-NSSAI/DNNs of an SMF (service) instance or SMF (service) set.

A NF Service Producer may also include LCI header(s) with different scopes in different messages, e.g. an SMF may report LCI for the SMF instance first, and then report LCI for both the SMF instance and for specific S-NSSAI/DNN(s), if S-NSSAI/DNN based load control is enabled.

An NF Service Consumer that receives LCI headers with different scopes, in the same message or in different messages, shall handle each LCI independently from each other. For instance, if an NF Service Consumer receives one LCI with the scope of an NF (Service) Set and then another LCI with the scope of an NF (Service) instance that pertains to the NF (Service) Set, the NF Service Consumer shall store the latter LCI and also consider that the former LCI is still valid for the NF (Service) Set.

For S-NSSAI/DNN based load control (see clause 6.3.3.4.4.2.2), when signalling LCI for an SMF (service) instance or an SMF (service) set in a message, the SMF shall always include the full set of load control information applicable to the SMF (service) instance or SMF (service) set, i.e. LCI for the SMF (service) instance or the SMF (service) set level and/or LCI for specific S-NSSAI/DNNs, even if only a subset of the LCI has changed; these LCIs shall contain the same Load Control Timestamp.

An SCP or SEPP may additionally include one LCI in a service request or response, or in a notification request or response, sent towards a NF Service Consumer or NF Service Producer.

Each LCI shall always include the Timestamp, Load Metric and Scope parameters (see clause 5.2.3.2.10 for the complete list of parameters).

6.3.3.4.2 Load Control Timestamp

The Timestamp parameter indicates the time when the LCI was generated. It shall be used by the receiver of the LCI to properly collate out-of-order LCI, e.g. due to HTTP/2 stream multiplexing, prioritization and flow control, and to determine whether the newly received load control information has changed compared to load control information previously received for the same scope.

The receiver shall overwrite any stored load control information of a peer NF, NF set, NF service, NF service set, SCP or SEPP (according to the scope of the new received LCI) with the newly received load control information, if the new load control information is more recent than the stored information. For instance, for S-NSSAI/DNN based load control, if the receiver had stored LCI for a peer SMF instance and LCI for a specific S-NSSAI/DNN of that SMF instance, it shall overwrite these LCIs with the new LCI received in a message carrying LCI for the same SMF instance.

If the newly received LCI has the same or an older Timestamp as the previously received LCI for the same scope (e.g. from the same NF, NF Set, NF Service, NF Service Set, SCP or SEPP), then the receiver shall discard the newly received LCI whilst continuing to apply the load control procedures according to the previously stored value.

NOTE: An NF Service Consumer can receive LCI for the same target scope from different NF service producers, when the scope of the LCI corresponds to an NF set or NF service set.

6.3.3.4.3 Load Metric

The Load Metric shall indicate the current load level for the scope of the LCI, e.g. current load level of the NF instance if the scope indicated in the LCI indicates an NF instance, as a percentage within the range of 0 to100, where 0 means no or 0% load and 100 means maximum or 100% load reached (i.e. no further load is desirable). The computation of the load metric is implementation specific.

6.3.3.4.4 Scope of LCI

6.3.3.4.4.1 Introduction

The scope of LCI indicates the applicability of the LCI, i.e. it identifies the components of the LCI sender to which the LCI relates to.

The following clauses provide a detailed description of the parameters that define the scope of the LCI header.

6.3.3.4.4.2 Scope of LCI signalled by an NF Service Producer

6.3.3.4.4.2.1 General

The LCI sent by an NF Service Producer shall include one of the parameters defined in Table 6.3.3.4.4.2.1-1.

Table 6.3.3.4.4.2.1-1: Supported scopes for LCI signalled by an NF Service Producer

Parameter	Value	LCI scope (i.e. LCI 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

If an NF Service Consumer receives more than one LCI with overlapping scopes, i.e. one with NF (service) instance scope and another with NF (service) Set scope, the NF Service Consumer should perform load balancing considering the LCI received with the finer scope for each candidate NF instance or NF service instance (i.e. in this example the load of the NF (service) instance).

6.3.3.4.4.2.2 Additional scope parameters for S-NSSAI/DNN based load control by SMF

It is optional for the SMF to support S-NSSAI/DNN based load control. When supported, the following requirements shall apply.

S-NSSAI/DNN level load control refers to advertising of the load information at S-NSSAI and DNN level granularity and selection of the target SMF service instance based on this information. It helps to achieve an evenly load balanced network at S-NSSAI/DNN granularity by the use of the dynamic load information provided within the Load Control Information with the S-NSSAI/DNN scope. Only an SMF may advertise S-NSSAI/DNN level load information.

NOTE 1: When all the resources of an SMF (service) instance are available for all the S-NSSAI/DNNs served by that SMF (service) instance, load 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 load control at SMF (service) set or SMF (service) instance level is sufficient.

The "Load Metric" shall indicate the current resource utilization for the indicated S-NSSAI/DNN(s), as a percentage, as compared to the total resources configured for the indicated S-NSSAI/DNNs s at the SMF.

When performing S-NSSAI/DNN based load control, the LCI scope shall indicate, in addition to either an NF-Instance, NF-Set, NF-Service-Instance or NF-Service-Set (see Table 6.3.3.4.2.2.1-1), the combinations of S-NSSAI and DNN for which the LCI sender wants to advertise the load information using the following parameters:

– the S-NSSAI parameter, indicating one or more S-NSSAI values; and

– the DNN parameter, indicating one or more DNN values from the indicated S-NSSAI(s).

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

See Table 6.3.3.4.4.2.2.1-1.

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

Parameter	Value	LCI scope (i.e. LCI 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.3.3.4.4.2.1-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.3.3.4.4.2.1-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 load 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 load control information.

The SMF may advertise load information for different DNNs of one or more S-NSSAIs in a single LCI header (if the same LCI information, e.g. load metric or relative capacity, applies to all the DNNs of the S-NSSAI(s)) or in up to 10 LCI headers (if different LCI information needs to be advertised for different DNNs).

6.3.3.4.4.3 Scope of LCI signalled by an SCP

The LCI sent by an SCP shall include one of the parameters defined in Table 6.3.3.4.4.3-1.

Table 6.3.3.4.4.3-1: Supported scopes for LCI signalled by an SCP

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

6.3.3.4.4.4 Scope of LCI signalled by an SEPP

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

Table 6.3.3.4.4.4-1: Supported scopes for LCI signalled by an SEPP

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

6.3.3.4.5 S-NSSAI/DNN Relative Capacity

When applying S-NSSAI/DNN based load control (see clause 6.3.3.4.4.2.2), the LCI shall include the S-NSSAI/DNN relative capacity indicating the resources configured for the combinations of S-NSSAIs and DNNs reported in the LCI, compared to the total resources configured at the SMF (service) instance or SMF (service) set, as a percentage.

This parameter enables the NF selecting an SMF service instance to determine the available resources for a given S-NSSAI/DNN for different candidate SMF service instances (considering the static capacity of the SMF service instance, the S-NSSAI/DNN relative capacity and the load of the S-NSSAI/DNN).

6.3.3.5 LC-H feature support

6.3.3.5.1 Indicating supports for the LC-H feature

When registering with the NRF (NFRegister) or updating the NRF (NFUpdate), an NF that supports the LC-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 LC-H feature (see clause 6.2.6.2.3 in 3GPP TS 29.510 [8]).

6.3.3.5.2 Utilizing the LC-H feature support indication

When selecting an NF Service Producer that supports the LC-H feature, the NF Service Consumer should not subscribe at the NRF to notifications triggered by the changes in the load of the selected NF Service Producer (see clause 5.2.2.5 in 3GPP TS 29.510 [8]).