Section: 12.1.2 Scenarios leading to overload
Content: 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.