Section: 12.1.1 GTP-C overload problem
Content: 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.