Section: 12.3.9.2.1 Description
Content: 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.