What is so special about collisions that they deserve that much attention? Well, they are a special case of interference (“friendly fire”, a military reporter would say), which may very seriously harm network performance.
A collision happens, when two (or more) transmissions in the network overlap in time. Radio modem A transmits a packet for B, C transmits for D. In well designed network the respective signal levels (i.e. A received at B, C received at D) do ensure error-less reception. For the period of time when these two transmissions overlap, signal from C at receiver input B and signal A at D act as interference signals, reducing the SNR (Signal to Noise Ratio). If B and D are in the same area, the difference in signal strength is small and so is the resulting SNR at both receivers. Consequently the BER (Bit Error Rate) at both receivers jumps to unacceptable level and none of the packets is successfully received. That is the basic principle of a collision.
There are two very harming features of collisions:
The first is a systematic repeated collision. No application generates a totally random traffic pattern. So it may happen (and it does happen), that a certain sequence of packets in a certain network layout generates a collision and it generates this collision repeatedly, in fact always. The result is that certain specific packets are never delivered, regardless of number of retries set at the application level. Imagine a SCADA system never capable of performing one specific task, while all communication tests report that links are in perfect shape. It would be very tempting to blame the SCADA, while the true problem is a systematic collision, i.e. wrong network design. Ways to avoid such collisions are described further in this document.
The second dangerous feature of collisions is just a direct consequence of probability laws. The most effective communication scheme for many applications is the report-by-exception mode, which can vastly reduce the amount of mainly useless traffic generated by polling-type systems. Report-by-exception means though, that collisions can never be ruled out completely, hence a collision-solving system must be an integral part of the protocol in the radio channel (RipEX in router mode provides such protocol of course). Solving a collision means retransmission, typically a delayed retransmission. Consequently the probability of another packet being generated by the application in the meantime increases by the delay, and it increases at both parties involved in the collision. That results in an increased probability of next collision to happen…and so on. This principle makes report-by-exception networks very sensitive to bursty loads. Whenever the load increases over certain limit (we may say “normal” network capacity), number of collisions grows exponentially, reducing the instant network capacity well below normal situation. Series of lost packets and very long delivery times are the result from the application point of view. While the network for report-by-exception application has to be designed to provide maximum capacity possible, it is recommended to take measures to avoid burst load generation at the application level. Limiting the possible load generated by a single device can help to avoid the whole network collapse just because one remote unit goes suddenly “crazy” (e.g. generates hundreds of “exceptions” per second).