D.2 GTP-C interfaces not supporting Overload Control
29.2743GPP3GPP Evolved Packet System (EPS)Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)Release 18Stage 3TS
Overload Control has been designed as a generic mechanism possibly applicable to any GTP-C based interface and any direction. However for the reasons clarified below, in the current release, Overload Control is not supported for the following GTP-C based interfaces:
– S3, S10, S16 (see considerations below, to minimize impact to MME and S4-SGSN);
– most of the S3 traffic would remain internal to the combo-node with the deployment of combo-MME/S4-SGSN nodes. The traffic over S10/S16 is also reduced with the deployment of MME and SGSN pools. It is therefore not essential to throttle the traffic on these interfaces when an MME or S4-SGSN experiences overload;
– throttling signalling on these interfaces resulting from a user’s mobility (inter-MME/S4-SGSN TAU, RAU and Handover) would result in bad end user’s perception (handover failure, loss of PDN connections) and so needs to be avoided as far as possible;
– an MME or S4-SGSN in overload may drop locally incoming RIM messages without causing GTP-C retransmissions (although this may cause the RAN to retransmit the message).
– S11/S4 (from an MME/S4-SGSN to an SGW, with SGW as consumer; see consideration below);
– by allowing the SGW to throttle DDN requests for normal priority traffic, the overload control of the messages originated by the SGW towards the MME/S4-SGSN is covered and hence, an SGW performing overload control towards the MME/S4-SGSN using Overload Control Information would be redundant.
– S5/S8 (from a PGW to an SGW, with the SGW as a consumer; no signalling message, originated by the SGW towards the PGW, that is identified as requiring overload control);
– Sm, Sn (no overload scenario identified, limited GTP-C traffic, to avoid impact to the MBMS GW);
– Sv (no overload scenario identified, to avoid impact to the legacy CS products);
– S101, S121 (no overload scenario identified, to avoid impact to the legacy HRPD products);
– Gn/Gp (to avoid impact to the legacy Gn-SGSN/GGSN products and GTPv1-C protocol);