Hybrid FEC + ARQ vs. 10 x 10 ProMPEG Cop3 FEC performance
The 10 x 10 ProMPEG Cop3 FEC used in the example above has a theoretical error correction performance of 20%. The FEC matrix shape enables packet recovery of 10 consecutive lost IP packets and 10 random lost IP packets provided the lost distribution is one single IP packet per row.
The example above (the Matrix on the left) shows a situation where 15 consecutive IP packets are lost. The FEC can only recover loss of 10 consecutive IP packets and the ARQ must recover the remaining 5 IP packets.
In a TCP (Transmission Control Protocol) friendly environment the accumulated bandwidth (bit-rate) must be kept reasonably constant. In this example, the accumulated transmission bit rate is kept constant by changing the FEC overhead to 10% and to use this bandwidth for the ARQ system to re-transmit the IP packets the FEC could not recover.
The bandwidth limitation for the ARQ system also limits the error correction capability of the ARQ to how many IP packets can be recovered. In the actual example the ARQ is restricted to re-transmit up to 10 IP packets per FEC matrix (100 packets).
Hybrid FEC + ARQ can therefore recover a loss of 20 consecutive IP packets plus a number of random losses of single IP packets. This is an improvement of 100% over a standard 10 x 10 ProMPEG Cop 3 FEC with regards to burst packet loss.
The same size ProMPEG Cop3 FEC with a 20 x 5 Matrix shape and 20% overhead can also recover a loss of 20 consecutive IP packets, but it’s capability to recover random loss of single IP packets is less efficient than a 10 x 10 shaped FEC matrix.
In most cases a service bandwidth is limited by the service provider, which limits the error correction capability for the service regardless of the technology. In other words, the error correction capability of the above mentioned methods are very much the same especially if the channel bandwidth is limited. If the bandwidth is “un-limited” or at least two times the channel bandwidth all the above technologies can correct for very high IP packet loss rates.
The typical overhead is normally kept between 10% and 30% in practical implementations, yielding very similar error correcting capability of the example mentioned above.