Section: 12.3.5.1.2 Parameters
Content: 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.