OSNR, BER und FEC Errors lesen (praxisnaher Transport-Guide)

OSNR, BER und FEC Errors zu lesen ist eine der wichtigsten Fähigkeiten im Transport- und Backbone-Betrieb, weil sich optische Degradation selten als „Link down“ ankündigt. In der Praxis kippen Strecken oft schleichend: OSNR sinkt langsam, FEC-Korrekturen steigen, und erst später erscheinen CRC-Fehler, Paketverlust oder Routing-Symptome. Wer diese Kennzahlen praxisnah interpretiert, kann Incidents früher erkennen, den Blast Radius klein halten und Wartungsarbeiten gezielt planen. Gleichzeitig sind OSNR, BER und FEC stark kontextabhängig: Werte unterscheiden sich je nach Modulation, Baudrate, Kanalbandbreite, Verstärkerkette, ROADM-Pfad, Temperatur, Steckverbinderzustand und Messpunkt (z. B. am Transponder, am Inline-EDFA oder am Analyzer). Ohne diesen Kontext werden Zahlen schnell falsch gelesen: Ein hoher FEC-Counter wird als „sofortiger Defekt“ interpretiert, obwohl er stabil ist; oder ein scheinbar guter OSNR-Wert wird als Entwarnung verstanden, obwohl der Pfad durch Nichtlinearitäten oder Filter-Fehlstellungen degradiert. Dieser praxisnahe Transport-Guide erklärt, was OSNR, BER und FEC-Fehler wirklich aussagen, wie Sie Trend und Baseline richtig nutzen, welche typischen Muster auf welche Ursachen hinweisen und wie Sie daraus sichere Diagnose- und Eskalationsschritte ableiten.

Begriffe sauber trennen: OSNR, BER und FEC sind unterschiedliche „Blickwinkel“

Im optischen Transport greifen mehrere Qualitätskennzahlen ineinander, aber sie messen nicht dasselbe. OSNR ist eine optische Signalqualität im analogen Sinn (Signal zu Rauschen), BER ist eine digitale Qualitätskennzahl (Bitfehler-Rate), und FEC beschreibt die Fehlerkorrektur, die aus fehlerhaften Bits wieder korrekte Daten rekonstruiert. Eine praktische Daumenregel lautet: OSNR und optische Parameter erklären, warum die Strecke schlechter wird; BER und FEC zeigen, wie sehr sich das auf die Datenübertragung auswirkt.

• OSNR: Verhältnis von optischer Signalleistung zu optischer Rauschleistung (in dB), gemessen in einem Referenzband.
• BER (Bit Error Rate): Anteil fehlerhafter Bits an allen übertragenen Bits in einem Zeitfenster.
• FEC (Forward Error Correction): Mechanismus zur Korrektur von Bitfehlern; liefert Zähler und daraus abgeleitete Fehlerraten.

OSNR verstehen: Was gemessen wird und warum dB hier nicht „einfach so“ ist

OSNR (Optical Signal-to-Noise Ratio) wird üblicherweise in dB angegeben und beschreibt, wie stark das Nutzsignal gegenüber dem hinzugefügten optischen Rauschen ist. In klassischen DWDM-Systemen ist das Rauschen häufig amplified spontaneous emission (ASE) aus EDFAs. Der OSNR-Wert hängt vom Messverfahren und der Referenzbandbreite ab (häufig 0,1 nm oder 12,5 GHz), weshalb ein Vergleich nur dann sinnvoll ist, wenn die Messdefinition identisch ist. Für eine grundlegende Orientierung zu DWDM- und optischen Begriffen sind herstellerneutrale Einführungen hilfreich, etwa IEEE 802.3 (für optische PHY-Kontexte) und faserbezogene Spezifikationen wie ITU-T G.652 (Fasergrundlagen).

OSNR als Verhältnis (MathML)

$\mathrm{OSNR}\left(\mathrm{dB}\right)=10\times {\log }_{10}\left(\frac{P\_\mathrm{signal}}{P\_\mathrm{noise}}\right)$

Praxisentscheidend ist: OSNR ist nur ein Teil der Wahrheit. Moderne kohärente Systeme nutzen zusätzlich digitale Signalverarbeitung; dadurch können Effekte wie Nichtlinearitäten, Polarisationseffekte oder Filterkaskaden eine Strecke verschlechtern, obwohl der OSNR „noch gut“ aussieht. Umgekehrt kann ein OSNR-Sink zwar ein Frühwarnsignal sein, aber erst zusammen mit FEC/BER zeigt er, ob bereits Nutzdatenqualität leidet.

BER richtig lesen: Pre-FEC vs. Post-FEC

BER ist der klassische „Digitalindikator“: Wie viele Bits kommen falsch an? In Transportplattformen und Transceivern sehen Sie oft zwei Ebenen:

• Pre-FEC BER: Bitfehler-Rate vor der Fehlerkorrektur. Das ist der empfindliche Indikator für Degradation.
• Post-FEC BER: Bitfehler-Rate nach der Fehlerkorrektur. Das ist der Kundensicht-Indikator – solange dieser sehr niedrig ist, „läuft“ der Link aus Datensicht.

Im Betrieb ist Pre-FEC BER häufig der bessere Frühindikator, weil Post-FEC BER durch FEC lange „perfekt“ bleiben kann, während die Korrektur bereits ansteigt. Sobald Post-FEC BER steigt oder gar „uncorrectables“ auftreten, ist die Strecke meist bereits deutlich degradiert und kann in kurzer Zeit kippen.

BER als Quote (MathML)

$\mathrm{BER}=\frac{\mathrm{bit\_errors}}{\mathrm{total\_bits}}$

FEC in der Praxis: Was „Corrected“ und „Uncorrected“ wirklich bedeuten

FEC ist in modernen Transportnetzen der zentrale Brückenindikator zwischen Optik und Dienstqualität. Praktisch sehen Sie typischerweise Zähler wie „Corrected Bits/Blocks“, „Uncorrectable Blocks“, „FEC Symbol Errors“, manchmal auch eine „FEC Margin“. Auch wenn die Begrifflichkeiten je nach Hersteller variieren, ist die Interpretation meistens ähnlich:

• Corrected: Fehler wurden erkannt und durch FEC korrigiert. Das ist nicht automatisch schlecht, aber der Trend ist wichtig.
• Uncorrected/Uncorrectable: Fehler waren zu groß für die Korrektur. Das ist ein rotes Signal, weil Nutzdaten beschädigt sind.
• FEC Margin: „Abstand“ zur FEC-Grenze; je kleiner, desto näher am Kipp-Punkt.

FEC-Korrekturrate als operative Kennzahl (MathML)

$\mathrm{FEC}\_\mathrm{CorrectedRate}=\frac{\mathrm{corrected\_blocks}}{\mathrm{time\_window}}$

Wichtig: Ein „großer“ Corrected-Counter allein ist nicht aussagekräftig, wenn er seit Monaten stetig in derselben Größenordnung steigt. Entscheidend ist der Trend: Steigt die Korrekturrate plötzlich an, oder driftet sie langsam hoch? Beides deutet auf unterschiedliche Ursachen hin (z. B. plötzliche Steckerverschmutzung vs. schleichende Verstärkerdrift).

Die wichtigste Betriebsregel: Baseline und Trend schlagen Absolutwerte

Viele Teams suchen nach „magischen Zahlen“: OSNR muss > X dB sein, Pre-FEC BER muss < Y, FEC darf nicht steigen. In der Praxis ist das zu grob, weil unterschiedliche Modulationsformate und Pfadlängen sehr unterschiedliche Normalwerte haben. Eine robuste Betriebsstrategie arbeitet daher mit Baselines pro Strecke und betrachtet Abweichungen.

• Baseline pro Link: „Normalbereich“ von OSNR, Pre-FEC BER und FEC-Rate in stabilen Wochen.
• Abweichung: Verhältnis oder Differenz zur Baseline statt absoluter Grenzwert.
• Stabilitätsdauer: kurze Spikes anders bewerten als anhaltende Drift (z. B. > 10 Minuten).

Abweichung zur Baseline (MathML)

$\mathrm{Delta}\_\mathrm{OSNR}=\mathrm{OSNR}\_\mathrm{current}-\mathrm{OSNR}\_\mathrm{baseline}$

Diagnose-Muster: Was typische Kombinationen bedeuten

Ein einzelner Wert ist selten genug. In Transportnetzen sind Kombinationen aus OSNR, BER und FEC wesentlich aussagekräftiger. Die folgenden Muster sind als praktische Heuristiken gedacht.

Muster A: OSNR sinkt, FEC Corrected steigt, Post-FEC bleibt gut

• Interpretation: Strecke degradiert, FEC kompensiert noch. Das ist ein Frühwarnsignal.
• Typische Ursachen: Verstärkerdrift, zusätzlicher Dämpfungsbeitrag (Stecker, Patch), Filter-/ROADM-Drift.
• Aktion: Trend beobachten, Pfad prüfen, Maintenance planen, Evidence Pack vorbereiten.

Muster B: OSNR stabil, aber Pre-FEC BER steigt und FEC Margin sinkt

• Interpretation: Nicht-OSNR-dominierte Beeinträchtigung: Nichtlinearitäten, Filterkaskade, Polarisationseffekte oder Modulations-/DSP-Themen.
• Typische Ursachen: zu hohe Launch Power (Nichtlinearität), Kanalinterferenzen, falsches ROADM-Filterprofil.
• Aktion: Launch Power/Channel Plan prüfen, ROADM-Pfad verifizieren, vendor-spezifische KPIs (z. B. Q-Factor, SNR) hinzuziehen.

Muster C: FEC Uncorrectables treten auf, Post-FEC BER steigt

• Interpretation: Kritischer Zustand, Nutzdatenfehler; der Link steht kurz vor Ausfall oder verursacht bereits Paketloss.
• Typische Ursachen: plötzlicher Defekt (Transceiver, Linecard), starke Dämpfungsänderung, Faserproblem, massives Störsignal.
• Aktion: Sofortmaßnahmen: Schutzpfad aktivieren, Traffic umleiten, Field/Vendor eskalieren.

Muster D: OSNR und BER springen stufenweise, korrelieren mit Wetter/Temperatur

• Interpretation: Temperatur-/Umweltabhängigkeit oder mechanische Instabilität (Stecker, Patchkabel, Gehäuse).
• Typische Ursachen: schlechte Steckverbindung, Mikrobiegung, mechanische Belastung, Klimatisierungsprobleme im PoP.
• Aktion: physische Prüfung, Reinigung, Patchwechsel, Environment-Alarme korrelieren.

OSNR ist nicht gleich „SNR“: Messpunkt und Messmethode beachten

In kohärenten Systemen sehen Sie häufig zusätzlich SNR, Q-Factor oder ähnliche Qualitätsmetriken. Diese sind nicht identisch mit OSNR, weil sie oft aus DSP-Informationen abgeleitet werden und damit Effekte erfassen können, die ein klassisches OSNR-Messverfahren nicht sauber abbildet. Für den Betrieb bedeutet das:

• OSNR: gut zur Beurteilung von Rauschdominanz (ASE) und Verstärkerkette.
• DSP-basierte Metriken: gut zur Beurteilung von Modulationsqualität, Nichtlinearitäten, Filtereffekten.
• Regel: Werte nicht blind mischen; immer dokumentieren, wo und wie gemessen wurde.

Von Transport zu IP-Symptomen: Wie optische Fehler als Paketprobleme erscheinen

Ein klassischer NOC-Fehler ist, optische Degradation erst dann ernst zu nehmen, wenn auf IP-Ebene Paketverlust oder Routinginstabilität sichtbar wird. In Wirklichkeit sind OSNR/BER/FEC oft die Ursache, während IP-Effekte nur Symptome sind. Typische Übersetzungen:

• FEC Uncorrectables: korreliert häufig mit CRC-Fehlern und anschließendem Paketloss auf Ethernet/IP.
• Hohe FEC CorrectedRate: kann zu Latenzspitzen führen, wenn Buffering oder Retransmissions auf höheren Ebenen zunehmen.
• Link-Flaps durch Optik: führen zu Routing-Konvergenz, BGP/IGP-Flaps und scheinbar „Control-Plane-Problemen“.

Praktisches Runbook: OSNR/BER/FEC im Incident schnell auswerten

Im Incident brauchen Sie eine kurze, wiederholbare Reihenfolge. Ziel ist, in Minuten zu entscheiden: beobachten, planen oder sofort mitigieren.

• 1) Zeitfenster fixieren (UTC): Start/Peak/aktueller Zustand.
• 2) Baseline vergleichen: Delta OSNR, Delta Pre-FEC BER, Delta FEC Rate.
• 3) Kritikalität klassifizieren: gibt es Uncorrectables oder Post-FEC BER Anstieg?
• 4) Fault Domain bestimmen: betrifft es einen Kanal, ein Band, einen Span, einen ROADM-Pfad, einen PoP?
• 5) Mitigation entscheiden: Protection switching, Traffic Reroute, Kanalpower anpassen, Field/Vendor eskalieren.
• 6) Validieren: FEC Uncorrectables müssen auf 0 zurückfallen; Trends müssen stabil werden.

Alerting ohne Alarmrauschen: Welche Schwellen sinnvoll sind

Transportmetriken können leicht Alarmfluten erzeugen, wenn sie zu granular oder ohne Baseline alarmiert werden. Eine praxistaugliche Strategie ist, Alarme auf Trend-Änderungen und Kipp-Punkt-Nähe zu bauen, nicht auf einzelne Messwerte.

• Frühwarnung: FEC CorrectedRate steigt über Baseline und bleibt X Minuten erhöht.
• Kritisch: FEC Uncorrectables > 0 oder Post-FEC BER > Schwelle.
• Scope-Alarm: mehrere Wellenlängen im gleichen Pfad degradieren gleichzeitig (Hinweis auf Verstärker/ROADM).
• Maintenance-Alarm: Werte springen nach Wartungsfenster (Hinweis auf Patch/Stecker/Filter).

Maintenance und Sign-off: Vorher/Nachher ist die beste Beweisführung

Bei geplanten Arbeiten (Spleiß, Patch, Transceiverwechsel, ROADM-Umstellung) ist die wichtigste Praxismaßnahme ein Vorher/Nachher-Vergleich. Damit können Sie nicht nur bestätigen, dass der Link wieder „grün“ ist, sondern dass er wieder im Baseline-Bereich liegt oder besser geworden ist. Das ist auch für Carrier/Vendor-Eskalationen entscheidend, weil Sie saubere Evidenz liefern können.

• Vorher: OSNR, Pre-FEC BER, FEC CorrectedRate, Uncorrectables im definierten Zeitfenster dokumentieren.
• Nachher: dieselben Werte im gleichen Fenster nach der Arbeit vergleichen.
• Stabilitätsfenster: mindestens 30 Minuten ohne neue Drift, bei kritischen Strecken länger.

Typische Ursachen und passende nächste Schritte

Damit aus Kennzahlen Handlungen werden, hilft eine Zuordnung „Symptom → wahrscheinlichste Ursache → nächster Schritt“. Diese Zuordnung ersetzt keine Expertise, verkürzt aber die Zeit bis zur richtigen Eskalation.

• OSNR sinkt langsam: Verstärkerdrift, zusätzlicher Loss → Verstärkerkette/ROADM/Stecker prüfen, Power-Level auditieren.
• FEC Corrected steigt sprunghaft: Steckerverschmutzung, Patchproblem → Reinigung/Neu-Patch, DOM/Power-Meter gegenprüfen.
• Uncorrectables: harter Defekt oder starker Pfadfehler → sofort Protection/Traffic Shift, Field/Vendor einbinden.
• OSNR ok, BER schlecht: Nichtlinearität/Filter → Launch Power/Channel Plan/Filterprofil prüfen, vendor-spezifische Diagnose nutzen.

Evidence Pack für Transport-Eskalation: Pflichtdaten für OSNR/BER/FEC

Wenn Sie an Carrier, Field Service oder Vendor eskalieren, beschleunigt ein kleines Pflichtdatenpaket die Bearbeitung erheblich. Es sollte nicht aus Screenshots bestehen, sondern aus klaren Werten und Zeitfenstern.

• Identifikatoren: Span/Route, Kanal/Wellenlänge, A/Z-Ende, Port/Transponder-ID, ROADM-Pfad (falls relevant).
• Zeitfenster (UTC): Start/Peak/aktueller Status, plus Vorher/Nachher bei Maintenance.
• OSNR/BER/FEC: aktuelle Werte, Baseline, Delta, Trend (min/median/max im Fenster).
• Fehlerklasse: corrected vs. uncorrected, pre-FEC vs. post-FEC.
• Kontext: letzte Changes, Temperatur/Environment-Anomalien, gleichzeitige Kanäle betroffen?

Outbound-Ressourcen für Grundlagen und Praxis

• ITU-T G.652 (Single-mode optical fibre and cable)
• IEEE 802.3 (Ethernet Standards und optische PHY-Kontexte)
• Cisco: Transceiver- und Optik-Guides (DOM, Betrieb, Troubleshooting)
• Juniper Documentation (Transport/Optics/Operational Monitoring)
• Infinera Resources (Optical Transport Grundlagen und Betriebshinweise)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.