12 GTP-C load & overload control mechanism

29.2743GPP3GPP Evolved Packet System (EPS)Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)Release 18Stage 3TS

12.1 General

12.1.1 GTP-C overload problem

GTP-C entities can communicate with other GTP-C peers in direct contact (e.g. MME and SGW) or remote GTP-C peers through intermediate GTP-C entities (e.g. MME and PGW via the SGW). In normal conditions, requests sent by a GTP-C entity can be processed by the receiving GTP-C entity which can send back a message indicating the result of the request (success/failure).

Overload situations in a GTP-C entity occur when the number of incoming requests exceeds the maximum request throughput supported by the receiving GTP-C entity, e.g. when the internal available resources of the GTP-C entity, such as processing power or memory, are not sufficient to serve the number of incoming requests. As a consequence of the overload situation, the receiving GTP-C entity cannot successfully process the exceeding proportion of requests. These requests can be either simply dropped or extremely delayed in the processing. At best, the GTP-C entity may have enough internal resources to send back to the request initiator a message indicating that the requests cannot be successfully processed. Whatever the behaviour of the overloaded GTP-C entities, the rate of successfully processed requests and consequently the overall performances of the network decrease.

NOTE: GTP-C overload control does not target to address transport network congestion. It assumes a transport network that is still capable to exchange signalling traffic.

Given the nature of GTP-C protocol in how it relies on retransmissions of unacknowledged requests (GTP-C is carried over UDP transport), when a GTP-C entity experiences overload (or severe overload) the number of unacknowledged GTP-C messages compounds exponentially and can lead to a node congestion or even collapse. An overload or failure of a node can lead to an increase of the load on the other nodes in the network and, in the worst case, turn into a complete network issue via a snowball effect.

The impact of GTP-C overload to services can be such as:

– loss of PDN connectivity (IMS, Internet …) and associated services;

– loss of ability to setup and release radio and core network bearers necessary to support services e.g. GBR bearers for VoLTE or dedicated bearers for Voice over WLAN;

– loss of ability to report to the PGW/PCRF user’s information changes, e.g. location information for emergency services and lawful intercept, changes in RAT or QoS;

– and billing errors and a loss of revenue.

12.1.2 Scenarios leading to overload

Reasons for these temporary overload cases can be many and various in an operational network, such as insufficient internal resource capacity of a GTP-C entity faced with a sudden burst of requests, e.g. after network failure/restart procedures affecting a large number of users, deficiency of a GTP-C entity component leading to a drastic reduction of the overall performances of the GTP-C entity.

Examples of GTP-C signalling based scenarios which can cause GTP-C overload are:

– a traffic flood resulting from the failure of a network element, inducing a signalling spike, e.g. when the network needs to re-establish the PDN connections affected by the failure of an EPC node;

– a traffic flood resulting from a large number of users performing TAU/RAU or from frequent transitions between idle and connected mode;

– an exceptional event locally generating a traffic spike, e.g. a large amount of calls (and dedicated bearers) being setup almost simultaneously upon a catastrophic event or an exceptional but predictable event (e.g. Christmas, New year) via a 3GPP access or a WLAN access;

– Frequent RAT-reselection due to scattered non-3GPP (e.g. WiFi) coverage or massive mobility between 3GPP and non-3GPP coverage may potentially cause frequent or massive intersystem change activities, i.e. UEs trying to either create PDN connections over the new access or moving PDN connections between 3GPP and non-3GPP coverage.

Besides, GTP-C load balancing based only on semi-static DNS weights can lead to a load imbalance and thus GTP-C signalling scenarios, such as those mentioned above, may result in an overload of the SGWs or PGWs with the highest load while there is still remaining capacity on other SGWs or PGWs.

12.1.3 Load & overload control concepts

Load control refers to "GTP-C signalling based Load Control" as defined in clause 4.3.7.1a.1 of 3GPP TS 23.401 [3] and clause 5.3.6.1a of 3GPP TS 23.060 [35].

Overload control refers to "GTP-C signaling based Overload Control" as defined in clause 4.3.7.1a.2 of 3GPP TS 23.401 [3] and clause 5.3.6.1a of 3GPP TS 23.060 [35].

Load control and overload control are two distinct but complementary concepts:

– load control enables a GTP-C entity (e.g. an SGW/PGW) to send its load information to a GTP-C peer (e.g. an MME/SGSN, ePDG, TWAN) to adaptively balance the session load across entities supporting the same function (e.g. an SGW cluster) according to their effective load. The load information reflects the operating status of the resources of the GTP-C entity.

– overload control enables a GTP-C entity becoming or being overloaded to gracefully reduce its incoming signalling load by instructing its GTP-C peers to reduce sending traffic according to its available signalling capacity to successfully process the traffic. A GTP-C entity is in overload when it operates over its signalling capacity which results in diminished performance (including impacts to handling of incoming and outgoing traffic).

Load control allows for better balancing of the session load, so as to attempt to prevent overload in the first place (preventive action). 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 nodes in the network for signalling that would anyhow be discarded by the overloaded node.

Load control does not trigger overload mitigation actions even if the GTP-C entity reports a high load.

Load control and overload control may be supported and activated independently in the network.

12.2 Load control solution

12.2.1 Principles of load control

The stage 2 requirements on GTP-C load control solution are defined in clause 4.3.7.1a.1 of 3GPP TS 23.401 [3] and clause 5.3.6.1a of 3GPP TS 23.060 [35]. The high level principles are summarized below:

a) Load Control is an optional feature;

b) a GTP-C node may signal its Load Control Information to reflect the operating status of its resources, allowing the receiving GTP-C peer node to use this information to augment the existing GW selection procedures;

c) the calculation of the Load Control Information is implementation dependent and its calculation and transfer shall not add significant additional load to the node itself and to its corresponding peer nodes;

d) the Load Control Information may provide load information of a GTP-C node (e.g. a PGW) or, if the APN level load control feature is supported, may provide the load information about specific APN(s);

e) the SGW may send its Load Control Information to the MME/S4-SGSN. The PGW may send its Load Control Information to the MME/S4-SGSN via the SGW. For non-3GPP access based interfaces, the PGW may send its Load Control Information to the ePDG and TWAN;

f) the Load Control Information shall be piggybacked in GTP-C request or response messages such that the exchange of Load Control Information does not trigger extra signalling;

NOTE: The inclusion of Load Control Information in existing messages means that the frequency of transmission of load control information increases as the session load increases, allowing for faster feedback and thus better regulation of the load.

g) a node supporting Load Control sends Load Control Information to a peer GTP-C node based on local configuration (see clause 12.2.6);

h) the format of the Load Control Information shall be specified with enough precision to guarantee a common interpretation of this information allowing interoperability between nodes of different vendors;

i) for the inter-PLMN case, local configuration may restrict the exchange and use of Load Control Information across PLMNs;

j) the GTP-C node may decide to send different values of Load Control Information on inter-network (roaming) and on intra-network (non-roaming) interfaces based on local configuration, i.e. the values sent on intra-network interfaces may differ from the values sent on inter-network interfaces. However, on intra-network interfaces, the node should send the same values between the 3GPP and non-3GPP access based interfaces.

k) the Load Control Information received via GTP-C signalling shall be used in conjunction with the information received from the DNS, during the node selection procedure. Refer to 3GPP TS 29.303 [32] for further details.

12.2.2 Applicability to 3GPP and non-3GPP access based interfaces

Load Control may be supported on the 3GPP & non-3GPP access based interfaces and nodes as summarized by the Table 12.2.2-1.

Table 12.2.2-1: Applicability of Load Control to GTP-C interfaces and nodes

Originator	Consumer	Applicable Interfaces
PGW	MME	S5/S8, S11 SGW relays Load Control Information from S5/S8 to S11 interface.
PGW	S4-SGSN	S5/S8, S4 SGW relays Load Control Information from S5/S8 to S4 interface.
SGW	MME	S11
SGW	S4-SGSN	S4
PGW	ePDG	S2b
PGW	TWAN	S2a

NOTE: Refer to Annex D.1 for information on the GTP-C interfaces for which Load Control is not supported.

12.2.3 Node level load control

Node level load control refers to advertising of the load information at node level – i.e. load information at node level granularity – and selection of the target node based on this information. It helps to achieve an evenly load balanced network by the use of the dynamic load information provided within the Load Control Information.

12.2.4 APN level load control

12.2.4.1 General

APN level load control refers to advertising of the load information at APN level granularity and selection of the target node based on this information. It helps to achieve an evenly load balanced network at APN granularity by the use of the dynamic load information provided within the Load Control Information with the APN scope. Only a PGW may advertise APN level load information.

APN level load control is an optional feature that may be supported when the following pre-condition is applicable.

Pre-Condition:

In the given network, when the ratio of the configured APN resource to the overall capacity of the PGW is not the same across all the PGWs in the network.

NOTE: In other cases, e.g. when all the resources of the PGW are available for all the APNs served by that PGW, the node level load information is exactly the same as APN level load information, for each of its APNs, and hence performing node load control is sufficient.

If APN load control is supported and activated at the PGW, the PGW should advertise the APN load information. If the APN level load control feature is supported at the node performing the PGW selection, i.e. an MME, S4-SGSN, ePDG, TWAN, the node shall utilize this information when selecting the PGW.

12.2.4.2 Justifications for APN load control support

Following are the justifications to support the APN level load control in the network when the pre-condition specified in 12.2.3.1 is applicable:

1) To achieve load balancing at the APN level granularity: The PGW may be configured to handle more than one APN in the network. In such a case, the PGW may be additionally configured to allocate different resources for each of the configured APNs, e.g. the PGW may be configured to handle "X" number of sessions for the "consumer" APN and to handle "Y" number of session for the "corporate" APN. The ratio of this limit, i.e. "X" and "Y", to the PGW’s capacity may not be the same across all the PGWs in the network. In this case, the load information with node level granularity is not sufficient and could result in a network where one PGW has more sessions for the "consumer" APN while another PGW has more sessions for the "corporate" APN. Thus, an evenly load balanced network at APN level load granularity cannot be realized.

2) To ensure effective overload control in the network: If the distribution of sessions at APN level is uneven, then there is a higher risk of overload of some PGWs, as compared to other PGWs, e.g. the PGW handling more sessions for "consumer" APN may have to handle more messages, (e.g. generated due to mobility events resulting from a change of ULI, RAT type, Serving GW, etc.) as compared to the PGW handling more sessions for the "stationary-machine" APN. Hence, the PGW handling "consumer" APN sessions may be at higher risk of overload, as compared to the other PGWs in the network, and hence, this situation may result in poor overload control of the network.

3) To ensure an efficient node selection algorithm: Based on the node level load information, the source node, (e.g. the MME) may end-up selecting the PGW for a new session for the given APN. However, the selected PGW may reject the new session request, if it is running at 100% load capacity for the given APN, or the new session request may be throttled by the source node based on the overload information of the APN for the given PGW. Thus the new session request may be denied, (i.e. rejected by the selected PGW or throttled by the source node based on PGW’s APN level overload information) while the other PGW may have the capacity to handle the same. Thus, the lack of APN level load information may result in inefficient node selection algorithm by the source node.

12.2.4.3 Elements of APN load control

To allow for an effective APN load control, at least the following information (in addition to the other applicable information for load control as defined in clause 12.2.5.1.2) is required to be advertised by the PGW, as part of the APN level load information:

APN: The APN for which the PGW wants to advertise the load information.

APN-Load-Metric: It indicates the current resource utilization for a particular APN, as a percentage, compared to the total resources reserved for that APN at the target PGW. Its computation is implementation dependent and it has same characteristics as "Load-Metric", as described in clause 12.2.5.1.2.2, when applied at the APN level.

APN-relative-capacity: It indicates the total resources configured for a given APN, compared to the total resources of the target PGW, as a percentage. It is a static parameter and does not change unless the resources configured for the APN change. Using APN-relative-capacity and the DNS weight-factor of the given PGW, the source node can judge the PGW’s APN related resources as compared other PGWs in the network, i.e. the PGW’s APN-weight-factor can be calculated by multiplying the APN-relative-capacity and DNS-weight-factor of the PGW (PGW’s-APN-weight-factor = PGW’s-APN-relative-capacity X DNS-weight-factor).

For the following example configuration:

PGW1-APN1-relative-capacity = 50%; PGW2-APN1- relative-capacity = 20%; PGW3-APN1- relative-capacity = 10%

PGW1-weight-factor = 20; PGW2-weight-factor = 20; PGW3-weight-factor = 60;

The APN level weight-factor for each of the PGWs can be calculated as below:

PGW1-APN1-weight-factor = 50% X 20 = 10.

PGW2-APN1-weight-factor = 20% X 20 = 4.

PGW3-APN1-weight-factor = 10% X 60 = 6.

Thus, based on the APN-weight-factor it can be concluded that the PGW1 has highest APN1 related resources reserved, as compared to the other PGWs in the network. Hence the source node should use this information to favour PGW1 over other PGWs for APN1 related new session requests.

12.2.5 Load Control Information

12.2.5.1 Definition

12.2.5.1.1 General description

Within a message, one or multiple instances of the Load Control Information (LCI) IE may be included by the same GTP-C entity.

When providing load control information in a message for the first time or subsequently, the GTP-C entity shall always include the full set of load control information, i.e. all the node level and APN Level applicable instances of the Load Control Information, even if only a subset of the load control information has changed. All the instances of the LCI IE provided by a given GTP-C entity in a message shall contain the same Load-Control-Sequence-Number. The Load Control Sequence Number shall be incremented whenever the load control information is changed (see clause 12.2.5.1.2.1).

The receiver shall overwrite any stored load control information of a peer with the newly received load control information (via one or multiple instances) from the same peer node if the new load control information is more recent than the old information as indicated by the Load Control Sequence Number, e.g. if the receiver has stored ‘X’ instances of the load control information for a peer node, it overwrites those ‘X’ instances with the new set of ‘Y’ instances received in a message from the same peer node, where X, Y are any integer number.

The receiver shall consider all the parameters received in the same instance of the LCI IE in conjunction while using this information for node selection. When more than one instance of the LCI IE is received, the receiver shall consider the parameters included in each instance independently, when using this information for node selection.

The parameters are further defined in clauses 12.2.5.1.2 and 12.2.5.1.3.

Load control information may be extended with new parameters in future versions of the specification. Any new parameter will have to be categorized as:

– Non-critical optional parameters: the support of these parameters is not critical for the receiver. The receiver can successfully and correctly comprehend the load control information instance, containing one or more of these parameters, by using the other parameters and ignoring the non-critical optional parameter.

– Critical optional parameters: the support of these parameters is critical for the receiver to correctly comprehend the instance of the load control information containing one or more of these parameters.

The sender may include one or more non-critical optional parameters within any instance of the LCI IE without having the knowledge of the receiver’s capability to support the same. However, the sender shall only include one or more critical optional parameter in any instance of the LCI IE towards a receiver if the corresponding receiver is known to support those parameters. The sender may be aware of this either via signalling methods or by configuration; (this will have to be defined when introducing any such new parameter in future).

Each instance of the LCI IE shall be associated to the node identity (FQDN or IP address of the GW node received from the HSS or the DNS) of the serving SGW or PGW, i.e. the identity determined during the SGW or PGW selection.

NOTE: The Node type is derived based on the instance number of the LCI IE.

12.2.5.1.2 Parameters

12.2.5.1.2.1 Load Control Sequence Number

The Load Control Sequence number contains a value that indicates the sequence number associated with the LCI IE. This sequence number shall be used to differentiate any two LCI IEs generated at two different instances by the same GTP-C entity. The Load Control Sequence Number shall be supported (if load control is supported) and shall always be present in the LCI IE.

The GTP-C entity generating this information shall increment the Load Control Sequence Number whenever modifying some information in the Load Control Information IE. The Load Control Sequence Number shall not be incremented otherwise. The node may use the time, represented in an unsigned integer format, of the generation of the Load Control Information to populate the Load Control Sequence Number.

When multiple instances of the LCI IE are provided in a message by a given GTP-C node, each of them shall contain the same Load Control Sequence Number value.

This parameter shall be used by the receiver of the Load Control Information IE to properly collate out-of-order load control information, e.g. due to GTP-C retransmissions. This parameter shall also be used by the receiver of the LCI IE to determine whether the newly received load control information has changed compared to load control information previously received from the same node earlier.

NOTE: The GTP-C sequence number cannot be used for collating out-of-order load control information as e.g. load control information may be sent in both GTP-C requests and responses, using independent GTP-C sequence numbering.

If the receiving entity has already received and stored load control information from the peer GTP-C entity, the receiving entity shall update its load control information only if the Load Control Sequence Number received in the new load control information is higher than the stored value of the Load Control Sequence Number associated with the peer GTP-C entity. However due to roll-over of the Load Control Sequence Number or restart of the node, the Load Control Sequence Number may be reset to an appropriate base value by the peer GTP-C entity, hence the receiving entity shall be prepared to receive (and process) a Load Control Sequence Number parameter whose value is less than the previous value.

12.2.5.1.2.2 Load Metric

The Load Metric parameter shall indicate the current load level of the originating node. The computation of the Load Metric is left to implementation. The node may consider various aspects, such as: the used capacity of the node based on activated bearers in relationship to maximum number of bearers the node can handle, the load that these active bearers produce in the node (e.g. memory/CPU usage in relationship to the total memory/CPU available, etc.).

The Load Metric represents the current load level of the sending node 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 Load Metric shall be supported (if load control is supported). The Load Metric shall always be included in the Load Control Information.

Considering the processing requirement of the receiver of the Load Control Information (e.g. handling of the new information, tuning the node selection algorithm to take the new information into account), 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 node selection logic at the receiver. During the typical operating condition of the sender, 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 and thus justifying the processing requirement (to handle the new information) of the receiver.

NOTE: The range of the Load Metric, i.e. 0 to 100, does not mandate the sender to collect its own load information at every increment/decrement and hence to advertise the change of Load Metric with a granularity of 1%. Based on various implementation specific criteria, such as: the architecture, session and signalling capacity, the current load and so on, the sender is free to define its own logic and periodicity with which its own load information is collected.

12.2.5.1.2.3 List-of-APN_and_Relative Capacity

The List-of-APN_and_Relative Capacity parameter contains a list of the tuple (APN, Relative Capacity) and this indicates one or more APNs for which the Load Control Information is applicable. The "APN" contains the name of the APN and the Relative Capacity indicates the resources configured for a given APN, compared to the total resources configured at the target PGW, as a percentage.

When present in the LCI IE, the scope of the load information shall be the list of indicated APNs for the PGW that sends the load control information. In that case, the "Load Metric" shall be interpreted as an "APN-Load-Metric" and shall indicate the current resource utilization for the indicated APNs, as a percentage, as compared to the total resources configured for the indicated APNs at the target PGW.

Its computation is implementation dependent and it has the same characteristics as "Load Metric". Only one instance of the List-Of-APN_and_Relative Capacity IE may be included within one Load Control Information instance.

NOTE 1: The maximum number of tuples (APN, Relative Capacity) in the List-of-APN_and_Relative Capacity IE is set to 10. More than 10 occurrences of (APN, Relative Capacity), within one single instance of the List-of-APN_and_Relative Capacity IE is treated as protocol error by the receiver.

If the List-of-APN_and_Relative Capacity IE has not been included, the scope of the Load Control Information shall be the entire PGW node (unless restricted by other parameters in the LCI IE).

This parameter may be supported (if load control is supported) and shall be supported when APN level load control is supported.

The receiver shall handle this parameter, when it is received, if it supports APN level load control. The receiver shall ignore a Load Control Information instance applicable for an APN, if it does not support APN level load control.

NOTE 2: The PGW encodes the APN level load information and node level load information using different instance numbers in the message, so that the receiver will ignore the APN level load information, if it does not support the APN level load control feature.

The maximum number of APNs, for which the PGW may advertise the Load Control Information, shall be limited to 10, i.e. the maximum number of occurrences of the tuple (APN, Relative Capacity) within and across various instances of the LCI IE shall be limited to 10, for a given PGW. Hence, if the PGW supports more than 10 APNs, it shall advertise the load control information for at most 10 of the most important APNs. In future, if needed, this limit may be increased to allow the PGW to advertise the load information for more APNs. In that case, the receiver not supporting the higher limit shall handle the first 10 APNs and shall ignore the load information for the remaining APNs.

NOTE 3: The limit of the number of APN’s takes into account various aspects such as: the processing and storage requirements at the overloaded node and the receiver, the number of important APNs for which load control advertisement will be necessary and interoperability between the nodes.

When including load control information for some APN(s), the PGW shall also provide node level load control information by providing one instance of the Load Control Information without the List-of-APN_and_Relative Capacity parameter.

A node selecting a PGW for a given APN shall apply the APN level load information, if available for that APN. If this parameter is not received for a given APN but it has been received for other APN(s) from the same PGW, then for this given APN, the node performing PGW selection shall calculate the load metric, as described in 3GPP TS 29.303 [32], for the target PGW.

12.2.5.1.3 Handling of parameters

If the PLMN supports the Load Control feature (see clause 12.2.6), the support, inclusion and handling of the parameters, within Load Control Information, is summarized in table 12.2.5.1.3-1.

Table 12.2.5.1.3-1: Parameters of the Load Control Information

Parameter	Support by the sender	Support by the receiver	Inclusion by the sender	Handling by the receiver
Load Control sequence number (as defined in clause 12.2.5.1.2.1)	Mandatory	Mandatory	Mandatory	Mandatory
Load Metric (as defined in clause 12.2.5.1.2.2)	Mandatory	Mandatory	Mandatory	Mandatory
List-of-APN_and_Relative Capacity (as defined in clause 12.2.5.1.2.3)	Optional (NOTE 1)	Optional (NOTE 1)	Optional (NOTE 2)	Conditional (NOTE 3)
NOTE 1: This is an optional parameter that shall be supported, if APN level load control is supported. NOTE 2: The PGW shall send this parameter whilst providing APN level load control information, if the APN level load control feature is supported and enabled. NOTE 3: If this parameter is received, the receiver supporting the APN load control feature shall handle and process APN load control information.

12.2.5.2 Frequency of inclusion

How often the sender includes the load control information is implementation specific. The sender shall ensure that new/updated load control information is propagated to the target receivers within an acceptable delay, such that the purpose of the information (i.e. effective load balancing) is achieved. The sender may include the LCI IE e.g. as follows:

– the sender may include Load Control Information towards a peer only when the new/changed value has not already been provided to that peer;

– the sender may include the Load Control Information in each and every message (extended with LCI IE) towards the peer;

– the sender may include Load Control Information periodically, i.e. include the information during a first period then cease to do so during a second period.

The sender may also implement a combination of one or more of the above approaches. Besides, the sender may also decide to include the Load Control Information only in a subset of the applicable GTP-C messages.

The receiver shall be prepared to receive the load control information in any of the GTP-C messages extended with an LCI IE and upon such reception, shall be able act upon the received load control information.

12.2.5.3 Limit on maximum number of instances

A GTP-C entity may signal one or multiple instances of the LCI IE, with each providing load control information for a different scope. In order to limit the processing of the message on the receiver side and the size of the message on transport level, the number of load control information instances shall be limited:

– at message level: there shall be at most one instance of node level LCI IE per node (i.e. per SGW or PGW) and at most 10 APN level instances.

– at node level: the maximum number of instances of LCI IE which may be provided across multiple messages by a given node shall be the same as the maximum number of instances of LCI IE at message level.

12.2.6 Discovery of the support of the feature by the peer node

A GTP-C entity shall determine whether to use the load control feature (i.e. provide or handle load control information)

– within the PLMN, based on the operator’s policy (local PLMN-wide configuration);

– across the PLMN boundaries, based on the operator’s policy (local configuration per PLMN).

NOTE: The feature may be activated when all or some of the nodes in the PLMN support the feature. The GTP-C entity assumes that all of the peer nodes support this feature when the feature is activated, i.e. it does not need to determine which peers support the feature.

The above operator policy/local configuration may allow the use of load control at node level, load control at node level and APN level, or none.

12.2.7 Issues in the network with partial support of the feature

The Load Control feature should be supported homogenously across all the SGWs and PGWs in the network. Not supporting this feature homogeneously across the SGWs and PGWs may result in poor load balancing in the network such that the SGWs or PGWs not supporting the feature may operate near their maximum capacity (thus being more vulnerable to overload conditions) while SGWs or PGWs supporting the feature have free capacity.

The Load Control feature should be supported homogenously across all the MMEs, S4-SGSNs, ePDGs and TWANs. However, use of the feature when not all of these nodes support the feature may not necessarily create a problem since the load may remain fairly balanced across the SGWs and PGWs assuming that the network imbalance caused by the non-supporting node may get rectified by the supporting nodes making use of dynamic load information while selecting the SGWs and PGWs.

12.3 Overload control solution

12.3.1 Principles of overload control

The stage 2 requirements on GTP-C overload control are defined in clause 4.3.7.1a.2 of 3GPP TS 23.401 [3] and clause 5.3.6.1a of 3GPP TS 23.060 [35]. The high level principles are summarized below:

a) Overload control is an optional feature;

b) a GTP-C entity may signal its overload to its GTP-C peers by including Overload Control Information in GTP-C signalling which provides guidance to the receiving GTP-C entity to decide actions which lead to signalling traffic mitigation towards the sender of the information;

c) the Overload Control Information may provide the overload information of a GTP-C entity, e.g. a PGW, or a specific APN(s) associated with the GTP-C entity;

d) an MME/S4-SGSN may signal an overload to the PGW, via the SGW. An SGW may signal an overload to the MME/S4-SGSN and to the PGW. A PGW may signal an overload to the MME/S4-SGSN, via the SGW. For non-3GPP access based interfaces, a PGW may signal an overload to the ePDG and the TWAN; the ePDG and the TWAN may signal an overload to the PGW.

NOTE 1: An MME/S4-SGSN will not signal an overload to the SGW (i.e. the SGW will not perform overload control towards the MME/S4-SGSN), as this is redundant with DDN throttling (see clause 12.3.3).

e) the overload control feature should continue to allow for preferential treatment of priority users (eMPS) and emergency services;

f) the Overload Control Information is piggybacked in GTP control plane request or response messages such that the exchange of the Overload Control Information does not trigger extra signalling;

NOTE 2: The inclusion of Overload Control Information in existing messages means that the frequency increases as the signalling load increases, thus allowing faster feedback and better regulation.

g) the computation and transfer of the Overload Control Information shall not add significant additional load to the GTP-C entity itself and to its corresponding peer GTP-C entities. The calculation of Overload Control Information should not severely impact the resource utilization of the GTP-C entity, especially considering the overload situation;

h) clause 4.3.7.1a.2 of 3GPP TS 23.401 [3] and clause 4.5 of 3GPP TS 23.402 [45] provides examples of various potential overload mitigation actions based on the reception of the overload related information exchanged between GTP-C entities, for 3GPP access based interfaces and non-3GPP access based interfaces, respectively. However, the exact internal processing logics of a GTP-C entity will not be standardized;

i) for the inter-PLMN case, local configuration may restrict the exchange and use of Overload Control Information across PLMNs;

j) the GTP-C entity may decide to send different values of Overload Control Information on inter-network (roaming) and on intra-network (non-roaming) interfaces based on local configuration, i.e. the values sent on intra-network interfaces may differ from the values sent on inter-network interfaces. However, on intra-network interfaces, the GTP-C entity should send the same values between the 3GPP and non-3GPP access based interfaces;

12.3.2 Applicability to 3GPP and non-3GPP access based interfaces

The Overload Control feature may be supported on the 3GPP & non-3GPP access based interfaces and nodes as summarized by the Table 12.3.2-1.

Table 12.3.2-1: Applicability of overload control to 3GPP & non-3GPP access based GTP-C interfaces and nodes

Originator	Consumer	Applicable Interfaces
MME	PGW	S11, S5/S8 SGW relays Overload Control Information from S11 to S5/S8 interface.
S4-SGSN	PGW	S4, S5/S8 SGW relays Overload Control Information from S4 to S5/S8 interface.
SGW	MME	S11
SGW	S4-SGSN	S4
SGW	PGW	S5/S8 (in MME/S4-SGSN originated signalling towards the PGW)
PGW	MME	S5/S8, S11 SGW relays Overload Control Information from S5/S8 to S11 interface.
PGW	S4-SGSN	S5/S8, S4 SGW relays Overload Control Information from S5/S8 to S4 interface.
PGW	TWAN	S2a (Trusted WLAN access)
PGW	ePDG	S2b (Untrusted WLAN access)
TWAN	PGW	S2a (Trusted WLAN access)
ePDG	PGW	S2b (Untrusted WLAN access)

NOTE: Refer to Annex D.2 for information on the GTP-C interfaces for which Overload Control is not supported.

12.3.3 Node level overload control

Node level overload control refers to advertising of the overload information at node level, i.e. overload information at node level granularity, and applying the mitigation policies towards the target node based on this information. This helps in preventing severe overload and hence potential breakdown of the GTP-C node.

When a GTP-C entity determines that the offered incoming signalling traffic is growing (or is about to grow) beyond its nominal capacity, it may signal an Overload Control Information IE to instruct its GTP-C peers to reduce the offered load accordingly.

Overload Control is performed independently for each direction between two GTP-C entities. Overload Control may run concurrently, but independently, for each direction between the two GTP-C entities.

Overload control of SGW originated traffic towards the MME/S4-SGSN shall rely on Downlink Data Notification throttling, as specified in clause 4.3.7.4.1a of 3GPP TS 23.401 [3] and 5.3.6.5 of 3GPP TS 23.060 [35], with the addition that the SGWs should be allowed, by configuration, to throttle DDN requests for low priority, as well as normal priority traffic (the SGW shall then throttle by priority DDN requests for low priority traffic).

12.3.4 APN level overload control

12.3.4.1 General

APN level overload control refers to advertising of the overload information at APN level granularity and hence applying the mitigation policies based on this information to the signalling traffic related to this APN only. Only a PGW may advertise APN level overload information when it detects overload for certain APNs, e.g. based on shortage of internal or external resources for an APN (e.g. IP address pool).

NOTE: When all the internal and external resources, applicable to the APNs, are available for all the APNs served by a PGW, the node level overload information is exactly the same as APN level overload information of that PGW, for each of its APNs, and hence, performing node overload control can be sufficient.

12.3.4.2 Elements of APN overload control

For allowing the effective APN overload control, at least the following information (in addition to the other applicable information for overload control as defined in clause 12.3.5.1.2) are required to be advertised by the source node, as part of the APN level overload information:

APN: The APN for which the source node wants to advertise the overload information;

APN-Overload-Reduction-Metric: It indicates the requested overload reduction for the signalling traffic corresponding to a particular APN, as a percentage. Its computation is implementation dependent and it has the same characteristics as the "Overload-Reduction-Metric", described in clause12.3.5.1.2.1, when applied at APN level.

12.3.5 Overload Control Information

12.3.5.1 Definition

12.3.5.1.1 General description

Within a message, one or multiple instances of the Overload Control Information (OCI) IE may be included by the same GTP-C entity. Each instance shall provide information about the overload condition to allow the receiver to apply mitigation actions which will result in an efficient alleviation of the overload condition at the sender.

The GTP-C entity shall always include the full set of overload control information, i.e. all the node level and/or APN level applicable instances of the OCI IE, when signalling overload control information in a message for the first time or subsequently towards the receiver, even when only a subset of the overload control information has changed. All the instances of the OCI IE provided by a given GTP-C entity in a message shall contain the same Overload Control Sequence Number. The Overload Control Sequence Number shall be incremented whenever the overload control information is modified (see clause 12.3.5.1.2.1).

When including overload control information for some APN(s), the PGW should not provide any node level Overload Control Information unless the node level information is also applicable.

The receiver shall overwrite any stored overload control information of a peer with the newly received overload control information (received via one or multiple instances of OCI IE) from the same GTP-C peer entity, if the new information is more recent than the old information as indicated by the Overload Control Sequence Number, e.g. if the receiver has stored ‘X’ instances of the OCI IE for a peer GTP-C entity, it shall overwrite those ‘X’ instances with the new set of ‘Y’ instances received in a message from the same GTP-C peer entity, where X, Y are any integer numbers.

The receiver shall consider all the parameters received in the same instance of the OCI IE in conjunction while applying the overload mitigation action. When more than one instance of the OCI IE is included, the receiver shall consider the parameters included in each instance independently, while applying the overload mitigation action.

The parameters are further described in clauses 12.3.5.1.2 and 12.3.5.1.3.

Overload control information may be extended with new parameters in future versions of the specification. Any new parameter will have to be categorized as:

– Non-critical optional parameters: the support of these parameters is not critical for the receiver. The receiver can successfully and correctly comprehend the Overload Control Information instance, containing one or more of these parameters, by using the other parameters and ignoring the non-critical optional parameters.

– Critical optional parameters: the support of these parameters is critical for the receiver to correctly comprehend the instance of the Overload Control Information containing one or more of these parameters.

The sender may include one or more non-critical optional parameter(s) within any instance of Overload Control Information, without having the knowledge of the receiver’s capability to support the same. However, the sender shall only include one or more critical optional parameter(s) in any instance of Overload Control Information towards a receiver, if the corresponding receiver is known to support these parameter(s). The sender may be aware of this either via signalling methods or by configuration; this will have to be defined when introducing any such new parameter in the future.

Each instance of the OCI shall be associated by default to the GTP-C entity corresponding to the peer node’s IP address of the PDN connection, over which the OCI IE is received, i.e. to the IP address received within the "Sender F-TEID for control plane" IE, the "PGW S5/S8/ S2a/S2b F-TEID for PMIP based interface or for GTP based Control Plane interface" IE or within the "MME/S4-SGSN Identifier" IE.

Alternatively, the GW (i.e. SGW and PGW) nodes may send Overload Control Information which is associated with the GW node’s identity, i.e. the FQDN or IP address of the GW node received from the HSS (for a PGW) or the DNS (for an SGW or PGW), the identity determined during the GW selection. In that case, the GW node shall provide an explicit indication that the OCI IE included in the message belongs to the GW node’s identity.

12.3.5.1.2 Parameters

12.3.5.1.2.1 Overload Control Sequence Number

The GTP-C protocol requires retransmitted messages to have the same contents as the original message (see clause 7.6). Due to GTP-C retransmissions, the overload control information received by a GTP-C entity at a given time may be less recent than the overload control information already received from the same GTP-C entity. The Overload Control Sequence Number aids in sequencing the overload control information received from an overloaded GTP-C entity. The Overload Control Sequence Number contains a value that indicates the sequence number associated with the Overload Control Information IE. This sequence number shall be used to differentiate between two OCI IEs generated at two different instants, by the same GTP-C entity.

The Overload Control Sequence Number parameter shall be supported (when supporting the overload control feature) and shall always be present in the Overload Control Information IE.

The GTP-C entity generating this information shall increment the Overload Control Sequence Number whenever modifying some information in the OCI IE. The Overload Control Sequence Number shall not be incremented otherwise. The GTP-C entity may use the time, represented in an unsigned integer format, of the generation of the overload control information, to populate the Overload Control Sequence Number.

When multiple instances of the OCI IE are provided in the same message by a given GTP-C entity, each of the Overload Control Sequence Numbers shall have the same value.

This parameter shall be used by the receiver of the OCI IE to properly collate out-of-order OCI IEs, e.g. due to GTP-C retransmissions. This parameter shall also be used by the receiver of the OCI IE to determine whether the newly received overload control information has changed compared to the overload control information previously received from the same GTP-C entity. If the newly received overload control information has the same Overload Control Sequence Number as the previously received overload control information from the same GTP-C peer, then the receiver may simply discard the newly received overload control information whilst continuing to apply the overload abatement procedures, as per the previous value.

NOTE 1: The timer corresponding to the Period of Validity (see 12.3.5.1.2.2) is not restarted if the newly received overload control information has the same Overload Control Sequence Number as the previously received overload control information. If the overload condition persists and the overloaded GTP-C entity needs to extend the duration during which the overload information applies, the sender needs to provide a new overload control information with an incremented Overload Control Sequence Number (even if the parameters within the overload control information have not changed).

NOTE 2: The GTP-C Sequence Number cannot be used for collating out-of-order overload information as e.g. overload control information may be sent in both GTP-C requests and responses, using independent GTP-C sequence numbering.

If the receiving GTP-C entity already received and stored overload control information, which is still valid, from the overloaded GTP-C entity, the receiving entity shall update its overload control information, only if the Overload-Sequence-Number received in the new overload control information is larger than the value of the Overload Control Sequence Number associated with the stored information. However due to roll-over of the Overload Control Sequence Number or restart of the GTP-C entity, the Overload Control Sequence Number may be reset to an appropriate base value by the peer GTP-C entity, hence the receiving entity shall be prepared to receive (and process) an Overload Control Sequence Number parameter whose value is less than the previous value.

12.3.5.1.2.2 Period of Validity

The Period of Validity indicates the length of time during which the overload condition specified by the OCI IE is to be considered as valid (unless overridden by subsequent new overload control information).

An overload condition shall be considered as valid from the time the OCI IE is received until the period of validity expires or until another OCI IE with a new set of information (identified using the Overload Control Sequence Number) is received from the same GTP-C entity (at which point the newly received overload control information shall prevail). The timer corresponding to the period of validity shall be restarted each time an OCI IE with a new set of information (identified using the Overload Control Sequence Number) is received. When this timer expires, the last received overload control information shall be considered outdated and obsolete, i.e. any associated overload condition shall be considered to have ceased.

The Period of Validity parameter shall be supported (when supporting overload control).

The Period of Validity parameter achieves the following:

– it avoids the need for the overloaded GTP-C entity to include the Overload Control Information IE in every GTP-C messages it signals to its GTP-C peers when the overload state does not change; thus it minimizes the processing required at the overloaded GTP-C entity and its GTP-C peers upon sending/receiving GTP-C signalling;

– it allows to reset the overload condition after some time in the GTP-C peers having received an overload indication from the overloaded GTP-C entity, e.g. if no signalling traffic takes place between these GTP-C entities for some time due to overload mitigation actions. This also removes the need for the overloaded GTP-C entity to remember the list of GTP-C entities to which it has sent a non-null overload reduction metric and to which it would subsequently need to signal when the overload condition ceases, if the Period of Validity parameter was not defined.

12.3.5.1.2.3 Overload Reduction Metric

The Overload Reduction Metric shall have a value in the range of 0 to 100 (inclusive) which indicates the percentage of traffic reduction the sender of the overload control information requests the receiver to apply. An Overload Reduction Metric of "0" always indicates that the GTP-C entity is not in overload (that is, no overload abatement procedures need to be applied) for the indicated scope.

Considering the processing requirement of the receiver of the Overload Control Information, e.g. to perform overload control based on the updated Overload Reduction Metric, the sender should refrain from advertising every small variation, e.g. with the granularity of 1 or 2, in the Overload Reduction Metric which does not result in useful improvement for mitigating the overload situation. During the typical operating condition of the sender, a larger variation in the Overload Reduction Metric, e.g. 5 or more units, should be considered as reasonable enough for advertising a new Overload Reduction Metric Information and thus justifying the processing requirement (to handle the new information) of the receiver.

NOTE: The range of Overload Reduction Metric, i.e. 0 to 100, does not mandate the sender to collect its own overload information at every increment/decrement and hence to advertise the change of Overload Reduction Metric with a granularity of 1%. Based on various implementation specific criteria, such as the architecture, session and signalling capacity, the current load/overload situation and so on, the sender is free to define its own logic and periodicity with which its own overload control information is collected.

The computation of the exact value for this parameter is left as an implementation choice at the sending GTP-C entity.

The Overload Reduction Metric shall be supported (when supporting overload control) and shall always be present in the OCI IE.

The inclusion of the OCI IE signals 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 IE in a message does not mean that the overload has abated.

12.3.5.1.2.4 List of APNs

The List of APNs IE indicates one or more APNs for which the Overload Control Information is applicable. When present in the OCI IE, the scope of the overload control information shall be the list of the indicated APNs for the PGW that sends the overload control information. At most one instance of the List of APNs IE shall be included within one Overload Control Information instance.

NOTE 1: The maximum number of APNs in the List of APNs is set to 10. More than 10 occurrences of APN within one single instance of the List of APNs IE is treated as a protocol error by the receiver.

If the List of APNs IE has not been included, the scope of the Overload Control Information shall be the entire GTP-C entity (unless restricted by other parameters in the Overload Control Information IE).

The List of APNs parameter shall be supported (when supporting overload control). The List of APNs may be present or absent in the Overload Control Information IE (depending on the scope of the reported overload control information).

NOTE 2: The instance number of both the node-level and APN-level overload control information is "0" and the instance number is therefore not used to indicate if the scope of the overload control information is on PGW node level or APN level.

This parameter may be provided by the PGW only and it shall be used by the MME/S4-SGSN and the TWAN/ePDG only.

The maximum number of APNs, for which the PGW may advertise the Overload Control Information, shall be limited to 10, i.e. the maximum number of occurrences of APNs within and across various instances of the Overload Control Information IE shall be limited to 10 for a given PGW. Hence, if the PGW supports more than 10 APNs, it shall advertise the overload control for at most 10 of the most important APNs. In future, if needed, this limit may be increased to allow the PGW to advertise the overload information for more APNs. In that case, the receiver that does not support the higher limit shall only handle the first 10 APNs and ignore the overload information for the remaining APNs to enable future compatibility.

NOTE 3: Considering various aspects such as: the processing and storage requirements at the overloaded GTP-C entity and the receiver, the number of important APNs for which overload control advertisement could be necessary, interoperability between the nodes of various vendors, etc. it was decided to define a limit on maximum number of APNs for advertising the overload control information. It was decided to fix this limit to 10 whilst also ensuring that the mechanism exists to extend this limit in future releases, if required.

12.3.5.1.3 Handling of parameters

If the PLMN supports the Overload Control feature (see clause 12.3.11), the support, inclusion and handling of the parameters, within overload control information, is summarized in table 12.3.5.1.3-1.

Table 12.3.5.1.3-1: Parameters of the Overload Control Information

Parameter	Support by the sender	Support by the receiver	Inclusion by the sender	Handling by the receiver
Overload Control Sequence Number (as defined in clause 12.3.5.1.2.1)	Mandatory	Mandatory	Mandatory	Mandatory
Period of Validity (as defined in clause 12.3.5.1.2.2)	Mandatory	Mandatory	Mandatory	Mandatory
Overload Reduction Metric (as defined in clause 12.3.5.1.2.3)	Mandatory	Mandatory	Mandatory	Mandatory
List of APNs (as defined in clause 12.3.5.1.2.4)	Mandatory	Mandatory	Optional (NOTE 1)	Conditional (NOTE 2)
NOTE 1: The PGW shall send this parameter whilst providing APN level overload control information. NOTE 2: If this parameter is received, the receiver shall handle and process APN level overload control information.

12.3.5.2 Frequency of inclusion

How often or when the sender includes the overload control information is implementation specific. The sender shall ensure that new/updated overload control information is propagated to the target receivers with an acceptable delay, such that the purpose of the information, (i.e. the effective overload control protection) is achieved. The following are some of the potential approaches the sender may implement for including the OCI IE:

– the sender may include OCI IE towards a receiver only when the new/changed value has not already been provided to the given receiver;

– the sender may include the OCI IE in a subset of the messages towards the receiver;

– the sender may include the OCI IE periodically, i.e. include the information during a first period then cease to do so during a second period.

The sender may also implement a combination of one or more of the above approaches. Besides, the sender may also include the OCI IE only in a subset of the applicable GTP-C messages.

The receiver shall be prepared to receive the overload control information received in any of the GTP-C messages extended with an OCI IE and upon such reception, shall be able act upon the received information.

12.3.5.3 Limit on maximum number of instances

A GTP-C entity may signal one or multiple instances of the OCI IE, each instance providing overload control information for a different scope. The receiver shall handle all these instances, from each of the peer GTP-C entities, by processing, storing and acting upon the same foroverload control. In order to limit the processing of the message on the receiver side and the size of the message, the number of overload control information instances shall be limited:

– at message level: there shall be at most one instance of node-level Overload Control Information IE per node and at most 10 APN-level instances.

– at node level: the maximum number of instances of the OCI IE which may be provided across multiple messages by a given node shall be the same as the maximum number of instances of the OCI IE at message level.

12.3.6 Propagating the MME/S4-SGSN identity to the PGW

When the Overload Control feature is supported by the MME/S4-SGSN and the SGW, and it is also activated for the PLMN to which the PGW belongs (see clause 12.3.11), the following shall apply:

– The MME/S4-SGSN shall include the MME/S4-SGSN identity towards the SGW during:

– the PDN connection establishment, any mobility with an MME/S4-SGSN change or any SGW change procedures;

– the dedicated bearer activation procedure, PGW initiated bearer modification procedure and PGW initiated bearer deactivation procedure as per the conditions specified in the corresponding messages.

– The SGW shall forward the MME/S4-SGSN identifier to the PGW if it is received in the Create/Update/Delete Bearer Response messages. When it is received in other GTP-C messages, the SGW shall store the received MME/S4-SGSN identity and shall include the currently serving MME/S4-SGSN’s identity in subsequent Modify Bearer Request messages which are sent over the S5/S8 interface, whenever there is signalling over the S5/S8 interface.

NOTE: This allows updating of the PGW with the identity of the new MME/S4-SGSN during inter-MME/SGSN mobility scenarios as early as possible and without generating extra signalling over the S5/S8 interface. Inter-MME/inter-SGSN intra SGW mobility scenarios not requiring to send any S5/S8 signalling could result in the PGW not being updated with the currently serving MME/S4-SGSN’s identity, for a given subscriber, until subsequent S5/S8 signalling takes place for the same PDN connection. However, considering these scenarios are not so frequent and considering that several features anyway require S5/S8 signalling during these scenarios (e.g. for user location reporting), the PGW will most often get the identity of the currently serving MME/S4-SGSN. Hence the risk that the PGW wrongly throttles PGW initiated signalling for that PDN connection, if the old MME/S4-SGSN is in overload, is low.

– The PGW shall store the currently serving MME/S4-SGSN identity, received from the SGW, to be able to reduce the PGW initiated signalling messages for the PDN connections during an overload situation at the serving MME/S4-SGSN.

12.3.7 Updating the PGW with overload control information of the target MME/S4-SGSN

During inter-MME/S4-SGSN mobility without SGW change scenarios, the SGW shall forward the MME/S4-SGSN’s overload control information over the S5/S8 interface only if the Modify Bearer Request message needs to be sent over the S5/S8 for another reason, e.g. if the ULI, CGI, Serving Network, needs to be reported to the PGW, i.e. the SGW shall not generate a Modify Bearer Request message over the S5/S8 interface for the sole purpose of reporting the MME/S4-SGSN’s overload control information. This avoids generating extra signalling over the S5/S8 interface.

NOTE: If the MME/S4-SGSN provides overload control information during the scenarios which do not result in S5/S8 signaling, e.g. during an inter MME/S4-SGSN and intra SGW mobility, when no other information such as: the ULI, CGI or Serving Network, needs to be reported to the PGW, the overload information will not be relayed on to the PGW. Hence, the MME/S4-SGSN needs consider this when including overload control information.

12.3.8 The interaction with APN congestion control using the PGW Back-Off Time

When detecting that a given APN is congested, the PGW shall either use the PGW Back-Off Time mechanism (see clause 4.3.7.5 of 3GPP TS 23.401 [3]) or the APN level overload control mechanism (i.e. providing an Overload Control Information IE with an APN-List included) for that APN, but not both together for the same APN, e.g. if the PGW provides an Overload Control Information IE with an APN-List set to "APN1", it shall not reject Create Session Request messages for "APN1" with a PGW Back-Off Time until the Period-Of-Validity of the overload information previously sent has expired.

The PGW may however use both mechanisms concurrently for different APNs, e.g. the PGW may reject Create Session Request messages for the"APN2" with a PGW Back-Off Time IE, if the APN2 is also congested and if there is no on-going APN-level overload control mechanism for that APN.

When rejecting a Create Session Request due to APN congestion, the PGW shall set the "APN Congestion" cause, regardless of the aforementioned mechanisms.

If the MME/S4-SGSN or ePDG/TWAN has one mechanism active for a given APN and PGW, (e.g. an MME has received a PGW Back-Off Time) and if subsequently it receives information for the same APN and PGW for another mechanism, (e.g. the MME receives an Overload Control Info IE with APN-List included for the same APN), then it shall deactivate/stop the earlier mechanism and consider only the information received for the latter mechanism.

Different PGWs may use concurrently different mechanisms for the same APN.

12.3.9 Message throttling

12.3.9.1 General

As part of the overload mitigation, a GTP-C entity shall reduce the total number of messages, which would have been sent otherwise, towards the overloaded peer based on the information received within the Overload Control Information. This shall be achieved by discarding a fraction of the messages in proportion to the overload level of the target peer. This is called message throttling.

Message throttling shall only apply to initial messages. Triggered request or response messages should not be throttled since that would result in the retransmission of the corresponding request message by the sender.

Before piggybacking the initial message over a response message, the initial message should be subject to the message throttling in the similar manner as any other non-piggybacked initial message. If the node decides to throttle this initial message then the response message should be sent without any piggyback message.

A GTP-C entity supporting GTP-C overload control shall support and use the "Loss" algorithm as specified in this clause, for message throttling.

12.3.9.2 Throttling algorithm – "Loss"

12.3.9.2.1 Description

An overloaded GTP-C entity shall ask its peers to reduce the number of requests they would ordinarily send by signalling Overload Control Information including the requested traffic reduction, as a percentage, within the "Overload-Reduction-Metric", as specified in clause 12.3.5.1.2.1.

The recipients of the "Overload-Reduction-Metric" shall reduce the number of requests sent by that percentage, either by redirecting them to an alternate destination if possible (e.g. the Create Session Request message may be redirected to an alternate SGW/PGW), or by failing the request and treating it as if it was rejected by the destination GTP-C entity.

For example, if a sender requests another peer to reduce the traffic it is sending by 10%, then that peer shall throttle 10% of the traffic that would have otherwise been sent to this GTP-C entity.

The overloaded GTP-C entity should periodically adjust the requested traffic reduction based e.g. on the traffic reduction factor that is currently in use, the current system utilization (i.e. the overload level) and the desired system utilization (i.e. the target load level), and/or the rate of the current overall received traffic.

Annex D.3.1 provides an (informative) example of a possible implementation of the "Loss" algorithm, amongst other possible methods.

NOTE 1: This algorithm does not guarantee that the future traffic towards the overloaded GTP-C entity will be less than the past traffic but it ensures that the total traffic sent towards the overloaded GTP-C entity is less than what would have been sent without any throttling in place. If after requesting a certain reduction in traffic, the overloaded GTP-C entity receives more traffic than in the past, whilst still in overload, leading to the worsening rather than an improvement in the overload level, then the overloaded GTP-C entity can request for more reduction in traffic. Thus, by periodically adjusting the requested traffic reduction, the overloaded node can ensure that it receives, approximately, the amount of traffic which it can handle.

NOTE 2: Since the reduction is requested as a percentage, and not as an absolute amount, this algorithm achieves a good useful throughput towards the overloaded node when the traffic conditions vary at the source nodes (depending upon the events generated towards these source nodes by other entities in the network), as a potential increase of traffic from some source nodes can possibly be compensated by a potential decrease of traffic from other source nodes.

12.3.9.3 Message prioritization

12.3.9.3.1 Description

When performing message throttling:

– GTP requests related to priority traffic (i.e. eMPS as described in 3GPP TS 22.153 [62]) and emergency have the highest priority. Depending on regional/national requirements and network operator policy, these GTP requests shall be the last to be throttled, when applying traffic reduction, and the priority traffic shall be exempted from throttling due to GTP overload control up to the point where the requested traffic reduction cannot be achieved without throttling the priority traffic;

– for other types of sessions, messages throttling should consider the relative priority of the messages so that the messages which are considered as low priority are considered for throttling before the other messages. The relative priority of the messages may be derived from the relative priority of the procedure for which the message is being sent (as specified in clause 12.3.9.3.2) or may be derived from the session parameters (as specified in clause 12.3.9.3.3).

NOTE: A random throttling mechanism, i.e. discarding the messages without any special consideration, could result in an overall poor congestion mitigation mechanism and bad user experience.

An overloaded node may also apply these message prioritization schemes when handling incoming initial messages during an overloaded condition, as part of the self-protection mechanism (see clause 12.3.10.2.3).

12.3.9.3.2 Based on procedures

Message prioritization may be performed based on the relative priority of the procedure for which the message is being sent. Procedures are grouped into various categories and each of these categories is assigned a priority. Additionally, within a given category of procedures, messages may be further prioritized based on session parameters such as: APN, QCI, ARP and/or LAPI (as described in clause 12.3.9.3.3).

Subsequently, messages with a high priority shall be given lower preference to throttle and messages with low priority shall be given higher preference to throttle.

The grouping of the procedures is not performed based on an individual GTP-C entity but whilst considering all the procedures in general. A GTP-C entity should consider the procedures applicable to it and apply prioritized message throttling based on the category of the procedure, as described below. The categories are listed in decreasing order of priority with category 1 having the highest priority. For each category a non-exhaustive list of messages is provided. Any existing or newly defined message in future should be considered based on the category (as specified below) of the procedure for which the message is sent.

1. UE session mobility within and across 3GPP or non-3GPP access: Procedures involving active or idle mode UE mobility, such that GTP-C signalling is involved, shall be classified under this category. Some examples are X2/S1 based handover with/without an SGW change, TAU/RAU with a change of MME/SGSN with/without an SGW change, 3GPP access to trusted non-3GPP access handover, etc. Throttling of these messages, during the procedures related to UE session mobility, would result in the failure of the corresponding procedures. This could result potentially in the loss of the PDN connection and/or the interruption of the services. Hence, the messages, as identified below, when sent during the procedures belonging to this category, shall be considered with the highest priority and hence, shall be given the lowest preference to throttle.

– Create Session Request,

– Create Session Request with "handover" indication bit set,

– Modify Bearer Request,

– Modify Bearer Request with "handover" indication bit set,

– Modify Access Bearer Request.

2. Release of PDN connection or bearer resources: Procedures resulting in the deactivation of an existing PDN connection, the deactivation of bearer(s) or of data forwarding tunnel of an UE leads to freeing up of the resources at the overloaded node and hence, can potentially ease the overload situation, since the freed up resources can be used for serving the remaining of the UEs. Thus, the messages belonging to this category resulting in the deactivation of PDN connection or bearer(s) or data forwarding tunnel(s), as identified below, shall be treated with the next lower level of priority and hence shall be given the corresponding preference whilst throttling:

– Delete Session Request,

– Delete Bearer Request,

– Delete Bearer Command,

– Delete Indirect Data Forwarding Tunnel Request.

3. Miscellaneous session management procedures: This category shall consist of the session management procedures, except PDN connection creation and bearer creation/modification procedures. Some examples are location reporting, when it is not combined with other mobility procedures, Service request and S1 release procedure. These procedures do not severely impact the on-going service of the UE. Hence, the messages, as identified below, when sent during the procedures identified under this category, shall be treated with the next lower level of priority and hence, shall be given the corresponding preference whilst throttling:

– Release Access Bearer Request,

– Modify Bearer Request,

– Change Notification,

– Suspend Notification,

– Resume Notification.

4. Request for new PDN Connection or bearer resources: Procedures requesting the creation of PDN connection, creation or modification of bearer(s) or creation of data forwarding tunnel shall be classified in this category. Throttling of the messages belonging to this category would result in denial of new services while continuing with the existing services. However, this is the natural outcome of an overload condition, i.e. the overloaded node, due to lack of resources, is not able to provision new services while the trying to maintain the existing services and hence, the messages, as identified below, when sent during the procedures belonging to this category, shall be considered with the lowest level of priority and hence shall be given highest preference to throttle:

– Create Session Request during PDN connection request,

– Create Bearer Request,

– Update Bearer Request,

– Bearer Resource Command,

– Modify Bearer Command,

– Create Indirect Data Forwarding Tunnel Request.

12.3.9.3.3 Based on session parameters

Message prioritization may be performed based on the session parameters, such as: APN, QCI, ARP and/or Low Access Priority Indicator (LAPI). The procedures and messages associated with the higher priority sessions shall be given lesser preference whilst throttling, as compared to the procedures and messages associated with the lower priority sessions. Within each group of sessions, the messages may be further prioritized based on the category of the procedure for which the message is being sent (as described in clause 12.3.9.3.2).

NOTE: This type of prioritization scheme ensures a good handling of all the messages and procedures related to higher priority sessions but can lead to throttle messages related to a critical procedure, e.g. UE mobility, for lower priority sessions over messages related to less critical procedures, e.g. location reporting, for a higher priority session.

12.3.9.3.4 Based on the Message Priority signalled in the GTP-C message

Message prioritization may be performed by an overloaded node, when handling incoming messages during an overloaded condition, based on the relative GTP-C message priority signalled in the GTP-C header (see clauses 5.4 and 5.5).

A GTP-C entity shall determine whether to set and use the message priority in GTP-C signalling within the PLMN and/or across the PLMN boundaries, based on operator policy and roaming agreements. The following requirements shall apply if being used.

A sending GTP-C entity shall determine the relative message priority to signal in the message according to the principles specified in clause 12.3.9.3.1. If the message affects multiple bearers (e.g. Modify Bearer Request), the relative message priority should be determined considering the highest priority ARP among all the bearers.

A GTP-C entity should set the same message priority in a Triggered message or Triggered Reply message as received in the corresponding Initial message or Triggered message respectively.

The message priority values sent on intra-network interfaces may differ from the values sent on inter-network interfaces. When messages cross PLMN boundaries, the Message Priority in the GTP-C header may be stripped or modified in these messages.

NOTE : This is to take into account that the priority definitions can vary between PLMNs and avoid messages from a foreign PLMN to gain unwarranted preferential treatment.

For incoming GTP-C messages that do not have a message priority in the GTP-C header, the receiving GTP-C entity:

– shall apply a default priority, if the incoming message is an Initial message;

– should apply the message priority sent in the Initial message or Triggered message, if the incoming message is a Triggered or Triggered Reply message (respectively).

This feature should be supported homogenously across the nodes in the network, otherwise an overloaded node will process initial messages received from the non-supporting nodes according to the default priority while initial messages received from supporting nodes will be processed according to the message priority signalled in the GTP-C message.

12.3.10 Enforcement of overload control

12.3.10.1 General

When a GTP-C entity receives Overload Control Information from its peer, it shall apply the overload abatement algorithm, based on the received information, for the messages sent towards the peer GTP-C entity. This is called "enforcement of overload control" and it involves throttling of the messages targeted for the overloaded peer.

12.3.10.2 Aspects related to enforcement of the overload control

12.3.10.2.1 Good throughput of the network

A source GTP-C entity should avoid any mechanism resulting in over throttling of the messages. Enforcement of the overload control whilst ensuring that good throughput (i.e. measured in terms of the rate of total number of messages the overloaded GTP-C entity can successfully process) of the network remains consistent to that when no overload control is applied, should be one of the prime objective of the source GTP-C entity.

NOTE: Over throttling of messages would negatively affect end user services and cause potential additional signalling in the network e.g. if the corresponding procedure is retried at a later time.

12.3.10.2.2 Message processing efficiency at the source GTP-C entity

Enforcement of overload control requires extra logic and extra processing at the source GTP-C entity. This is an overhead since the source GTP-C entity has to spend its resources in an activity other than processing of the messages. Hence, the implementation as well as the processing complexity of the enforcement of the overload control, should not result in a significantly poorer efficiency of the source GTP-C entity.

12.3.10.2.3 Self-protection by the overloaded GTP-C entity

A source GTP-C entity enforcing the overload control cannot ensure that the overloaded peer will not receive more messages than what it can handle during the overload condition, e.g. the "loss" algorithm does not guarantee that the future traffic reaches perfectly that requested by the overloaded GTP-C entity. Hence, the overloaded target GTP-C entity shall protect itself from the risk of meltdown even in a network where all the sending GTP-C entities support the overload control mechanism. As a part of this self-protection, the overloaded target GTP-C entity may reject the messages which it cannot handle during an overloaded state. A GTP-C entity which decides to not process an incoming request message due to overload should still send a reject response message, if possible, indicating the temporary unavailability of the resources; otherwise the request message may be dropped.

NOTE: Without a response message, the source GTP-C entity cannot determine whether the request did not reach the target GTP-C entity due to a network error or whether the target GTP-C entity was in overload and not able to process the request and send a response message. This will cause the source GTP-C entity to retransmit the request message and hence will increase further the overload at the target node.

The GTP-C entity may apply message prioritization as described in clause 12.3.9.3 when selecting the incoming request messages to be throttled.

While rejecting the message due to overload, the GTP-C entity shall set the cause to "GTP-C Entity Congestion" or "APN congestion" (for node level or APN level overload respectively) and may include the Overload Control Information in the rejection response as specified in clauses 12.3.5.1.1 and 12.3.11.

12.3.10.3 Enforcement of overload control between GTP-C entities in direct contact

A source GTP-C entity shall enforce overload control for traffic destined to a GTP-C entity in direct contact based on the overload reduction metric received from that peer, e.g. the MME applies the overload control for the messages targeted for the SGW based on the overload information of the SGW.

12.3.10.4 Enforcement of overload control between remote GTP-C entities

12.3.10.4.1 Description

For messages destined to a remote GTP-C entity (i.e. a GTP-C entity not in direct contact but reached via an intermediate GTP-C entity), the source GTP-C entity shall enforce the overload control based on the overload information of the target of the message, as well as the overload information of the intermediate GTP-C entity, e.g. the MME applies the overload control for messages targeted for the PGW based on the overload information of the SGW and PGW.

For the received messages, the intermediate GTP-C entity shall not further enforce any overload control and hence, shall not reject any message towards the source GTP-C entity.

Annex D.4.1 provides an (informative) example of a possible implementation.

NOTE 1: This approach ensures the overload protection of the Target as well as Intermediate GTP-C entities.

NOTE 2: The source GTP-C entity may be connected to the same Target GTP-C entity via multiple different Intermediate GTP-C entities. The exact algorithm used at the source GTP-C entity to enforce the overload control, as per the aforementioned requirements, is implementation specific.

12.3.11 Discovery of the support of the feature by the peer node

A GTP-C entity shall determine whether to use the overload control feature:

– within the PLMN, based on operator’s policy (local PLMN-wide configuration);

– across the PLMN boundaries, based on operator’s policy (local configuration per PLMN).

NOTE: The feature can be activated when all or some of the nodes in the PLMN support the feature. The GTP-C entity assumes that all the peer nodes support this feature when the feature is activated, i.e. it does not need to determine which peers support the feature.

The above operator policy/local configuration may allow the use of overload control at node level and APN level, or none.

12.3.12 Issues in the network with partial support of the feature

The Overload Control feature should be supported homogenously across the nodes in the network, otherwise:

– an overloaded node will get messages beyond its acceptable processing capacity, even after announcing its overload status. This may result in severe overload and possibly a breakdown of the node;

– a non-supporting node will get an unfair advantage in sending all the messages to an overloaded node, whereas a supporting node, would be requested to throttle more messages.

12.3.13 Implicit overload control mechanisms

Implicit overload control mechanisms are mechanisms used between GTP-C entities when GTP-C overload control is not supported or not enabled between them, e.g. across PLMN boundary based on operator’s policy, to help reducing the overload at the overloaded node:

– a GTP-C entity which decides to not process an incoming request message due to overload should still send a reject response message, if possible, indicating the temporary unavailability of the resources, e.g. No resources available; otherwise the GTP-C entity may drop the incoming request message.

NOTE: Without a response message, the source GTP-C entity cannot determine whether the request did not reach the target GTP-C entity due to a network error or whether the target GTP-C entity was in overload and not able to process the request and send a response message. This will cause the source GTP-C entity to retransmit the request message and hence will increase further the overload at the target node.

– a GTP-C entity in overload may support messages throttling as a self protection mechanism and may apply message prioritization as described in clause 12.3.9.3 when selecting the incoming request messages to be throttled;

– based on the number and rate of reject responses indicating temporary unavailability of resources, e.g. No resources available, a source GTP-C entity should try to assess the overload level of the target GTP-C entity and apply correspondingly message throttling as described in clause 12.3.9 to reduce the amount of traffic sent towards the overloaded GTP-C entity.