Network-wide Overload Control

The previous discussion in articles Congestion Control Basics and Congestion Control Algorithm focused on standalone implementation of overload control. The effect of the actions of other exchanges was not considered. If indiscriminate call blocking is resorted to on getting overloaded, overload may spread to other exchanges and might eventually bring down the whole network.

Handling Network Overload

Two simple techniques for tracking overloads in the network are described below.

Rejecting Traffic

Traffic rejecting is primarily achieved by blocking of calls by the exchange. If overload is viewed from the network perspective, excess traffic should be rejected as close to the periphery of the network as possible. Thus, if a local exchange is overloaded, blocking of subscriber directly connected to the exchange should be given first priority. Blocking of incoming traffic from the network should be avoided as far as possible because the call is already holding some resources in other exchanges which have forwarded the call to this exchange. In general, while blocking calls, preference should be given to calls that are closer to the subscriber at the network periphery, since they hold lesser resources of the network compared to calls that are being offered from the center of the network. Consider, for example, an overloaded Gateway exchange in New York. If the exchange has to resort to call blocking, it should block outgoing calls from New York more than incoming calls from some other Gateway exchanges, say Washington DC, because an outgoing call from New York holds network resources only in New York, while an incoming call from Washington DC holds network resources in Washington DC and more importantly a trunk circuit between New York and Washington DC.

Diverting Traffic

In a SS7 based network an overloaded exchange can inform other exchanges in the network about the overload, so they can choose a less congested route towards a particular destination. With this approach, traffic can be distributed more evenly throughout the network. Due to load distribution, the BHCA (Busy Hour Call Attempts) rating of the network can be increased.

If there is overload at the center of the network, very soon exchanges in the periphery of the network will be asked to reduce the traffic they are generating. On receiving such instructions from the network, the exchanges can use a combination of both call blocking and traffic diverting.

Preventing Overload

Initiating overload control in an overloaded system itself introduces some load, this severely limits the options available to the exchange for reducing the load. The network can be made more resilient to overload by initiating action before the problem gets out of hand. Various techniques for preventing overload are described below.

Quota System

In the quota system, all possible sources of traffic are allocated a fixed quota of traffic. Any source exceeding its quota is asked to reduce its traffic. The disadvantage of this scheme is that, if all other sources are offering traffic that is much less their quota, one source exceeding its quota will have to reduce its traffic, even though the exchange might be quite capable of handling the excess traffic.

Periodic Delay Measurement

Overload is normally characterized by long message queues and delay in processing the packets. Thus, if every exchange has a process periodically monitoring network wide call setup times, overload in other exchanges can be detected well in advance and any traffic being routed through the overloaded exchange can be diverted to routes on which call setup times are better.

Delays in other nodes in the network can also be found by sending special test messages and observing the time taken for their acknowledgement to come. A database of delays to other nodes can be maintained and it can be consulted while rerouting calls.

Using Traffic Data

Overload patterns in the switch will depend on the day of week and time of day, refer to the figure given above. Overload is also expected on special days like New Year day etc. The peak hour of traffic every day is known in advance. Based on previously collected traffic data, the exchange can make a very good guess about the expected traffic.

Suppose it is known that a particular exchange gets overloaded on every working day between 10 am and 11 am. To prevent overload, the exchange can disable subscriber features that cause a lot of message flow, for this duration. Also, it has been observed that if an exchange goes down and comes up again, the exchange might be faced with a very high traffic due to all subscribers trying to originate almost simultaneously. In such cases, the exchange should start offering service to subscribers in a phased manner to avoid overload.

Measuring Traffic Growth Rate

The above mentioned methods do not take into account overload in the telephone network caused by sudden events like natural calamities or accidents. Overload in this nature can be anticipated in advance if traffic growth rate is measured by the exchange. Consider, for example, an exchange loaded to 80% of its rated capacity facing a traffic growth rate of 5% per minute. If no action is taken, the exchange will get overloaded in a few minutes. If overload control is initiated at this time, overload can be prevented from occurring.