BER, FER, and Packet Loss Explained: How Satellite Link Errors Affect Real Network Performance

When a satellite link degrades, users experience frozen video calls, dropped VPN sessions, and sluggish web applications. The IT team sees packet loss. The RF engineer sees rising bit error rate. The NOC technician sees frame errors on the modem dashboard. They are all looking at the same problem from different layers of the communication stack — and unless everyone understands how these metrics connect, diagnosing and fixing the issue takes far longer than it should.

Bit Error Rate (BER), Frame Error Rate (FER), and packet loss form a chain of cause and effect that runs from the RF layer up through the network layer to the application layer. BER is where errors begin — individual bits flipped by noise, interference, or fading on the satellite link. FER is where the modem first detects that something is wrong — entire frames that cannot be recovered by error correction. Packet loss is what the network and applications experience — IP packets that never arrive at the destination because the underlying frames that carried them were destroyed.

Understanding this chain is essential for anyone operating satellite networks. Without it, you cannot distinguish between RF impairment and network congestion, you cannot predict when a fading link will start dropping packets, and you cannot set meaningful SLA thresholds. This article traces the error propagation path from RF to IP, explains the role of forward error correction in breaking or extending that chain, and provides practical guidance for troubleshooting and monitoring.

What Is BER?

BER stands for Bit Error Rate. It is the ratio of erroneously received bits to the total number of bits transmitted over a given time interval.

BER = Number of bit errors / Total number of bits transmitted

A BER of 10⁻⁶ means one bit in every million is received incorrectly. A BER of 10⁻³ means one bit in every thousand is wrong — a level that would completely destroy any useful data communication.

Where BER Is Measured

BER can be measured at two different points in the receive chain, and the distinction matters enormously:

• Pre-FEC BER — Measured at the output of the demodulator, before forward error correction is applied. This reflects the raw quality of the RF link. A pre-FEC BER of 10⁻³ is entirely normal for a well-designed DVB-S2 link, because the FEC decoder is designed to correct errors at this level.

• Post-FEC BER — Measured after the FEC decoder has corrected as many errors as it can. This reflects the actual data quality delivered to the upper layers. A well-functioning link should have a post-FEC BER of 10⁻⁸ or better — effectively error-free.

When someone says "the BER is 10⁻⁴," you must ask: pre-FEC or post-FEC? A pre-FEC BER of 10⁻⁴ is excellent. A post-FEC BER of 10⁻⁴ means the FEC is failing and the link is in serious trouble.

Relationship to Eb/N0

BER is fundamentally determined by Eb/N0 (energy per bit to noise density ratio). For any given modulation scheme and coding rate, there is a characteristic BER-vs-Eb/N0 curve — the so-called waterfall curve. As Eb/N0 decreases (signal degrades), BER rises. The steepness of this curve means that a drop of just 1–2 dB in Eb/N0 can take a link from essentially error-free to unusable.

In practical terms, BER is the RF engineer's primary indicator of link health. Modem dashboards display it (or the related Es/N0 from which BER can be inferred), and it tracks directly with the physical quality of the received signal.

What Is FER?

FER stands for Frame Error Rate. It is the ratio of frames received in error to the total number of frames transmitted.

FER = Number of errored frames / Total number of frames transmitted

In DVB-S2 and DVB-S2X systems, the relevant frames are BBFRAMEs (baseband frames) and PLFRAMEs (physical layer frames). A frame error occurs when the FEC decoder cannot correct all the bit errors within a frame — the accumulated errors exceed the correction capability of the code, and the entire frame is discarded.

Why Frame-Level Matters

BER treats every bit independently, but real communication systems process data in frames. A single frame in DVB-S2 can carry tens of thousands of bits. If one frame has a cluster of errors that overwhelms the FEC while adjacent frames are clean, the BER might look moderate but the FER tells a different story.

This distinction is especially important because errors in satellite channels are often bursty rather than uniformly distributed. Rain fade, interference, and scintillation can cause concentrated error bursts that destroy specific frames while leaving others untouched. The BER average over a measurement interval may look acceptable, but individual frames within that interval may be completely lost.

QEF Threshold

DVB-S2 defines quasi-error-free (QEF) performance as a packet error rate (PER) of 10⁻⁷ after the outer BCH decoder. This corresponds roughly to a frame error rate below 10⁻⁷ at the BBFRAME level. The MODCOD thresholds published in the DVB-S2 standard are the minimum C/N values required to achieve QEF performance for each combination of modulation and coding.

Operating above QEF means the link is effectively error-free from the perspective of the upper layers. Operating below QEF means frames are being lost at a rate that will produce visible packet loss.

What Is Packet Loss?

Packet loss is the percentage of IP packets that are transmitted but never received at the destination. It is the metric that network engineers, IT teams, and end users experience directly.

Packet Loss (%) = (Packets sent − Packets received) / Packets sent × 100

Unlike BER and FER, which are RF-layer and modem-layer metrics, packet loss operates at the network layer. It is what a ping test measures, what VoIP quality monitors track, and what triggers TCP retransmissions.

Impact on Applications

Different applications have very different sensitivities to packet loss:

Packet Loss vs Delay and Jitter

Packet loss is distinct from latency and jitter, though all three affect application performance. On satellite links, latency is inherently high (~600 ms round trip for GEO), and jitter is typically low. Packet loss is the metric that most directly causes service disruption — a high-latency link with zero packet loss can still deliver usable VoIP, but a low-latency link with 5% packet loss will sound terrible.

How BER, FER, and Packet Loss Are Related

The three metrics form a causal chain that runs from the physical layer to the network layer:

RF degradation → C/N drops → Eb/N0 falls → BER rises
→ FEC correction limit exceeded → Frame errors (FER rises)
→ IP packets carried in errored frames are lost → Packet loss increases

The Error Propagation Chain

Step 1: RF signal degrades. The C/N ratio at the receiver drops due to rain fade, interference, antenna mispointing, LNB degradation, or any other impairment. The Eb/N0 falls accordingly.

Step 2: BER rises. As Eb/N0 drops, the demodulator makes more bit errors. The pre-FEC BER climbs from perhaps 10⁻⁶ toward 10⁻³ or worse.

Step 3: FEC tries to correct. The inner LDPC code and outer BCH code in DVB-S2 can correct a substantial number of bit errors. As long as the error rate stays within the correction capability of the active MODCOD, the post-FEC BER remains near zero and no frames are lost.

Step 4: FEC limit exceeded. When the BER exceeds what the FEC can handle, individual frames begin to fail decoding. The FEC decoder flags these frames as uncorrectable, and they are discarded. FER begins to rise.

Step 5: Packets are lost. Each discarded frame carries payload data that maps to one or more IP packets (or fragments of IP packets). When a frame is dropped, the IP packets it contained are lost. The network layer sees packet loss.

The Cliff Effect

The transition from "essentially error-free" to "significant packet loss" is not gradual — it is a cliff. Because FEC waterfall curves are steep, a C/N drop of just 1–2 dB can take a link from post-FEC BER of 10⁻⁹ (no packet loss) to post-FEC BER of 10⁻³ (massive packet loss). This is why satellite links can seem fine one moment and completely broken the next during a heavy rain event.

ACM systems are designed to avoid this cliff by stepping down to a more robust MODCOD before the current one fails. But ACM has reaction time, and if the C/N drops faster than the ACM can adapt — or if the link is already on the most robust MODCOD — the cliff effect will still occur.

What Causes Errors in Satellite Links?

Rain Fade

Rain fade is the most common cause of error spikes on satellite links, particularly at Ku-band and Ka-band frequencies. Rain absorbs and scatters the satellite signal, reducing C/N at the receiver. The higher the frequency, the greater the attenuation — Ka-band links can lose 10+ dB during heavy rain, enough to push even robust MODCODs past their error thresholds.

Rain fade is time-varying and location-dependent. A tropical site may experience significant fade for dozens of hours per year, while a desert site may see almost none.

Interference

Satellite interference — from adjacent satellites, terrestrial sources, or cross-polarization leakage — adds unwanted energy to the received signal, effectively raising the noise floor and reducing C/N. Unlike rain fade, interference can be persistent and may not correlate with weather conditions, making it harder to diagnose.

Low C/N or Eb/N0

Beyond rain and interference, C/N can be low due to undersized antennas, suboptimal EIRP, poor receiver G/T, or operating at beam edge where satellite power density is lower. These are design issues rather than transient impairments, and they reduce the link margin available to absorb fade events.

Terminal Equipment Issues

Practical error sources at the terminal include:

• Antenna mispointing — Even a fraction of a degree off-axis reduces received signal and can introduce interference from adjacent satellites.
• LNB/BUC degradation — Aging or water-damaged components introduce excess noise or reduce output power.
• Cable and connector problems — Corroded connectors, water ingress, and damaged cables add loss and noise.
• Local oscillator drift — Can cause frequency errors that degrade demodulator performance.

Congestion vs Physical Degradation

Not all packet loss comes from RF impairment. Network congestion — too much traffic for the available bandwidth — causes packet drops at routers, switches, or the satellite modem's queue. This is a critical distinction for troubleshooting:

• RF degradation causes BER to rise first, followed by FER, then packet loss. The modem will show degraded C/N or Es/N0.
• Congestion causes packet loss with no change in BER or FER. The modem shows normal RF metrics, but queue depths and discard counters are high.

The same packet loss symptom has completely different root causes and requires completely different solutions. See QoS over satellite for traffic management approaches.

Error Correction and Recovery

Forward Error Correction (FEC)

FEC is the primary defense against bit errors in satellite communication. DVB-S2 uses a two-layer FEC scheme:

• Inner code: LDPC (Low-Density Parity-Check) — A powerful iterative code that provides the bulk of the coding gain. LDPC codes in DVB-S2 have block lengths of 16,200 or 64,800 bits.
• Outer code: BCH (Bose-Chaudhuri-Hocquenghem) — A shorter algebraic code that catches residual errors after LDPC decoding.

The combination of LDPC and BCH gives DVB-S2 its characteristic performance: the ability to operate at pre-FEC BER levels of 10⁻² to 10⁻³ while delivering post-FEC BER of 10⁻⁸ or better. This coding gain — the difference between the Eb/N0 needed without coding and the Eb/N0 needed with coding — is typically 8–10 dB, meaning FEC effectively multiplies the link's tolerance to noise by a factor of 6–10.

Interleaving

Interleaving rearranges the order of bits or symbols before transmission so that burst errors (which affect consecutive bits) are spread across multiple codewords after de-interleaving. This converts burst errors into distributed errors that the FEC can handle more effectively. DVB-S2 uses bit and symbol interleaving within each frame.

Adaptive Coding and Modulation (ACM)

ACM is the system-level response to changing link conditions. Instead of designing a fixed link for worst-case conditions, ACM continuously adjusts the MODCOD based on measured C/N:

• When C/N is high (clear sky): Use higher-order modulation (16APSK, 32APSK) with high code rates — maximum throughput.
• When C/N drops (rain fade): Step down to lower-order modulation (QPSK) with lower code rates — reduced throughput but maintained link integrity.

ACM prevents the FEC cliff effect by proactively switching to a MODCOD that can handle the current BER. The tradeoff is throughput: a link that steps down from 16APSK 3/4 to QPSK 1/2 loses about 75% of its throughput, but it avoids packet loss entirely.

Protocol-Layer Recovery

When frame errors do occur and IP packets are lost, higher-layer protocols provide additional recovery:

• TCP retransmission — TCP detects lost segments and retransmits them. This works but adds latency (at least one additional round trip, ~600 ms for GEO) and reduces throughput due to congestion control backoff.
• Application-layer ARQ — Some protocols implement their own retransmission at the application layer, independent of TCP.
• Application-layer FEC — Real-time protocols like video streaming may add their own FEC at the application layer (e.g., Pro-MPEG FEC for video contribution) to recover from packet loss without waiting for retransmission.

Real-Time vs Bulk: Why Some Apps Still Suffer

Even with FEC and ACM keeping the link alive, real-time applications are more sensitive to the remaining impairments:

• VoIP and video conferencing cannot wait for TCP retransmissions — they use UDP and simply skip lost packets, resulting in audio gaps or video artifacts.
• VPN tunnels may treat any packet loss as a sign of tampering or network failure, triggering re-keying or session teardown.
• Interactive applications (web, remote desktop) experience increased latency from TCP retransmissions stacked on top of the inherent satellite delay.

Bulk data transfer (file downloads, email) tolerates packet loss better because TCP retransmission recovers the data, and the user does not notice the added delay as directly.

Practical Engineering Examples

Example 1: Clear Sky vs Rain Fade

Consider a Ku-band DVB-S2 link operating at 16APSK 3/4 in clear sky with a C/N of 14 dB and 4 dB of rain fade margin.

Clear sky conditions:

During 6 dB rain fade (exceeds margin by ~2 dB):

ACM steps down to QPSK 3/4 (required C/N ~5.5 dB). C/N is now 8.0 dB with 2.5 dB margin remaining.

The link stays error-free because ACM adapted. Throughput dropped significantly, but no packets were lost. Users experience slower speeds but no interruptions.

If ACM were not available (fixed MODCOD at 16APSK 3/4):

Without ACM, the same fade event causes significant packet loss that disrupts all applications.

Example 2: Congestion vs RF Impairment

Two sites report 3% packet loss. Modem telemetry tells the story:

Site A — RF impairment:

Diagnosis: C/N is degraded, BER is elevated, FER is rising. The modem buffers are not full — this is an RF problem. The rain fade is pushing the link below the FEC correction threshold. Solution: wait for rain to pass, or if persistent, check antenna pointing and drainage.

Site B — Network congestion:

Diagnosis: RF metrics are perfect — C/N is normal, BER is low, no frame errors. But the modem's transmit buffer is full and packets are being dropped before they even reach the RF layer. This is a capacity or QoS problem. Solution: implement traffic shaping, prioritize critical applications, or increase committed information rate.

Why These Metrics Matter for SLAs and Troubleshooting

Link Commissioning

During initial installation and commissioning, the satellite engineer verifies that the link meets its design specifications. The key checks involve RF metrics:

• C/N matches the link budget prediction — within 1–2 dB. If the measured C/N is significantly lower, something is wrong with the installation (antenna pointing, cable loss, LNB performance).
• Pre-FEC BER is at expected levels for the operating C/N — this confirms the demodulator is working correctly.
• Post-FEC BER confirms QEF operation — the FEC is delivering the expected coding gain.
• No frame errors over the commissioning period — verifies sustained error-free operation.

NOC Monitoring

In operations, the Network Operations Center monitors both RF and network metrics:

• BER trending shows gradual degradation (aging equipment, antenna drift, seasonal fade patterns).
• FER alarms indicate that the link has crossed the QEF threshold — immediate attention required.
• Packet loss monitoring provides the application-visible health indicator that correlates with user complaints.

The most effective monitoring correlates all three: a packet loss alarm accompanied by rising BER and FER points to RF impairment. A packet loss alarm with clean BER/FER points to congestion or equipment issues above the modem layer.

SLA Context

Service Level Agreements for satellite links typically specify:

• Link availability — The percentage of time the link operates above a minimum performance threshold (usually QEF).
• Maximum packet loss — Often specified as < 0.1% or < 0.5% during available time.
• Maximum latency and jitter — Relevant but usually stable on satellite links.

Understanding the BER → FER → packet loss chain helps operators interpret SLA metrics correctly. If a link shows 99.5% availability but 2% packet loss during available time, the issue is likely that the availability threshold is set too low, or that congestion (not RF) is causing the loss during nominal operation.

Common Mistakes

1. Treating Packet Loss as Purely an RF Problem

Packet loss can come from congestion, QoS misconfiguration, faulty Ethernet switches, MTU mismatches, or application bugs — none of which show up in BER or FER. Always check modem RF metrics before assuming an RF cause.

2. Ignoring FER When BER Seems Acceptable

Averaged BER can mask burst errors. A link with a 10-second BER average of 10⁻⁵ might have short bursts at 10⁻² that cause frame errors. FER is a more direct indicator of actual data loss than averaged BER.

3. Blaming Applications Without Checking Link Metrics

Users reporting "the internet is slow" may be experiencing packet loss from RF degradation, or they may be experiencing normal satellite latency with a poorly optimized application. Check BER/FER/packet loss before concluding it is an application or server problem.

4. Confusing Pre-FEC and Post-FEC BER

A pre-FEC BER of 10⁻³ is normal and healthy for DVB-S2. A post-FEC BER of 10⁻³ means the link is effectively down. When reading BER from modem dashboards, always verify which measurement point is being reported.

5. Ignoring QoS When Diagnosing Loss

If a satellite link has adequate RF margin but some applications experience loss while others work fine, the issue is likely QoS configuration — low-priority traffic is being dropped in favor of high-priority traffic, which is working as designed. This is not a fault; it is traffic management.

Frequently Asked Questions

What is BER in satellite communication?

BER (Bit Error Rate) is the ratio of incorrectly received bits to total bits transmitted on a satellite link. It is the fundamental RF-layer error metric that reflects the quality of the received signal relative to noise. BER is determined by the Eb/N0 of the link and the modulation and coding scheme in use. A lower BER means better signal quality.

Is low BER enough for good application performance?

Not necessarily. BER is a necessary but not sufficient condition. Even with excellent BER, applications can suffer from network congestion (causing packet loss at the modem or router level), excessive latency (inherent to GEO satellite links), QoS misconfiguration (causing selective packet drops), or insufficient bandwidth allocation. Good application performance requires low BER, adequate bandwidth, and proper traffic management.

What is the difference between BER and packet loss?

BER is an RF-layer metric measured at the demodulator — it counts individual bit errors. Packet loss is a network-layer metric — it counts IP packets that failed to arrive. They are related but not the same: BER can be high while packet loss is zero (if FEC corrects all errors), and packet loss can be high while BER is zero (if the loss is caused by network congestion rather than RF impairment).

Why can a link stay connected but still perform badly?

A satellite modem can maintain lock and demodulate the carrier even when the error rate is high enough to cause application problems. The modem lock threshold is typically several dB below the QEF threshold. In this zone, the modem stays locked but the FEC cannot correct all errors, resulting in frame losses and packet loss. With ACM, the modem may step down to a more robust MODCOD that maintains link quality but at significantly reduced throughput — the link is "up" but slow.

What BER threshold triggers packet loss?

There is no single BER threshold because the FEC correction capability varies by MODCOD. For each MODCOD, there is a specific Eb/N0 (and corresponding pre-FEC BER) below which the FEC can no longer maintain QEF performance. Broadly, when post-FEC BER exceeds approximately 10⁻⁷, frame errors begin occurring and packet loss follows. The pre-FEC BER at which this happens depends on the coding rate — lower code rates (more redundancy) can tolerate higher pre-FEC BER.

How does FEC reduce the effect of bit errors?

FEC adds structured redundancy to the transmitted data. The receiver's FEC decoder uses this redundancy to detect and correct bit errors without requiring retransmission. DVB-S2's LDPC + BCH coding can correct pre-FEC BER levels around 10⁻² to 10⁻³ down to post-FEC BER below 10⁻⁸ — a correction factor of 100,000 to 1,000,000. This coding gain effectively extends the usable range of the link by 8–10 dB compared to uncoded transmission.

What causes sudden spikes in packet loss on a satellite link?

The most common cause is rain fade — a heavy rain cell passing through the signal path causes rapid C/N degradation that can exceed the link margin within minutes. Other causes include interference events (adjacent satellite, terrestrial), equipment failures (LNB, BUC, cable), antenna movement (wind, ice), and sudden traffic spikes causing congestion. Check modem C/N and BER simultaneously with packet loss to determine whether the cause is RF or network-related.

How do you distinguish congestion from RF degradation?

Check the modem's RF telemetry alongside network counters. RF degradation shows degraded C/N, elevated BER, and rising FER — the packet loss tracks with RF metric changes. Congestion shows normal C/N, normal BER, zero FER, but high buffer utilization and queue discard counters. The treatment is completely different: RF issues require physical-layer fixes (antenna, equipment, wait for weather), while congestion requires traffic management (QoS, bandwidth allocation, CIR adjustments).

Key Takeaways

• BER, FER, and packet loss form a causal chain from the RF layer to the network layer — understanding this chain is essential for diagnosing satellite link problems correctly.
• FEC is the bridge between RF-layer errors and network-layer performance. It can absorb BER levels of 10⁻² to 10⁻³ and deliver error-free packets — until it cannot, at which point the link falls off a cliff.
• ACM prevents the cliff by proactively stepping down to more robust MODCODs, trading throughput for link integrity.
• Not all packet loss is RF-related. Congestion causes the same symptom with completely different RF metrics and requires completely different solutions.
• Pre-FEC and post-FEC BER tell different stories. Pre-FEC BER reflects raw link quality; post-FEC BER reflects what the network actually experiences. Confusing them leads to incorrect diagnoses.
• Effective troubleshooting correlates all three metrics. BER alone, FER alone, or packet loss alone tells an incomplete story — the relationship between them identifies the root cause.