4.25 Support of Overload Control

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

4.25.1 General

Network elements within the IP Multimedia CN subsystem may have to cope with high volume of signalling traffic with significant traffic peaks. An IMS network may therefore implement overload control functionality in IMS network elements to prevent overload situations.

For that purpose, two different mechanisms are provided:

– A mechanism based on next-hop monitoring of overload, where an IMS node acting as a SIP server may provide overload control feedback to its neighbours. This mechanism is described in clause 4.25.2.

NOTE 1: This mechanism is well suited for preventing overload of core network servers (CSCF) where overload is not due to calls to a specific application/destination.

– A filter-based mechanism where an IMS node acting as SIP server, may send load control filters to another IMS node that has subscribed for receiving this information. This mechanism is described in clause 4.25.3.

NOTE 2: This mechanism is particularly well suited for application servers when the source of overload is due to calls to a specific destination (e.g. a 800 application overloaded by mass calling to a particular destination).

Emergency calls shall not be affected by the overload traffic restrictions due to overload control and MPS priority information shall be taken into account when applying by the overload traffic restrictions based on received indications.

4.25.2 Next-hop monitoring of overload

For IMS entities supporting next-hop monitoring of overload, these IMS entities shall support a mechanism for monitoring overload of neighbour nodes with minimal overhead, to enable scenarios where the overload status needs to be adjusted frequently.

IMS entities supporting SIP, e.g. S-CSCF, shall be able to provide overload control feedback to their neighbours by providing load reduction directives within SIP responses. The neighbour nodes shall be able to adapt the traffic sent to the overloaded node by restricting the traffic offered to the overloaded neighbour node in accordance with the overload status information received.

It is recommended that when next-hop monitoring of overload is deployed for a specific function, all neighbour nodes also support the feedback of overload control status and support the overload traffic restriction procedures towards the specific function being monitored.

The next hop monitoring of overload procedures should at least be possible to use for the following scenarios:

– Network internal overload control between core functions, e.g., between different CSCFs.

– Application Server overload control (i.e., between CSCF and AS).

– Roaming and Interconnect (e.g., between IBCFs of two different networks).

– Transit scenarios (e.g., between IBCF and Transit function).

4.25.3 Filter based Overload Control

When filter based Overload Control is deployed, an IMS entity supporting SIP overload control (e.g. originating AS or S-CSCF) may subscribe to traffic filter information of specific IMS SIP server destination which may be subject to overload (e.g. an 800 application overloaded by mass calling to a specific number), and perform overload traffic restriction according to the information received. Alternatively, when the destination is not in IMS, the IMS entity performing the overload traffic restrictions may subscribe to an IMS SIP server providing traffic filter information related to the destination, or can have configured overload traffic filter information for the specific destination.

IMS entities supporting this mechanism shall match all SIP requests they send against received traffic filter information.

If such a filter based mechanism is used, it is recommended that the function performing the overload traffic restrictions be as close to originating party as possible, while still having sufficiently aggregated traffic to perform restrictions on, e.g., by allowing the originating AS/S-CSCF to subscribe to the traffic filter information from a terminating AS.