DE69931862T2

DE69931862T2 - Vorwärtsfehlerkorrektur für hochratige optische Übertragungssysteme

Info

Publication number: DE69931862T2
Application number: DE69931862T
Authority: DE
Inventors: Mark Aldo North Andover Bordogna; Ralf Dohmen; Wolfram Sturm
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1998-08-31
Filing date: 1999-08-23
Publication date: 2006-11-30
Anticipated expiration: 2019-08-24
Also published as: CA2278820A1; JP3547660B2; US6683855B1; DE69931862D1; CN1249577A; JP2000115107A; CN1151617C; EP0984575B1; EP0984575A2; AU4483699A; CA2278820C; EP0984575A3

Description

GEBIET DER ERFINDUNG
Diese Erfindung betrifft allgemein optische Übertragungssysteme und spezieller Fehlerkorrekturschemata für hochratige optische Übertragungssysteme.
ALLGEMEINER STAND DER TECHNIK
Optische Übertragungssysteme, welche mit hohen Übertragungsgeschwindigkeiten arbeiten, wie etwa Systeme vom Typ Synchrones optisches Netzwerk/Synchrone digitale Hierarchie (Synchronous Optical Network/Synchronous Digital Hierarchy, SONET/SDH), die mit 10 Gb/s arbeiten, sind bekanntlich anfällig für Signal-Rauschabstand-Verschlechterungen sowie Beeinträchtigungen, die mit optischen Verstärkern zusammenhängen. Neben anderen Problemen können diese Beeinträchtigungen inakzeptable Bitfehlerraten auf hochratigen optischen Leitungen verursachen, welche sowohl Sprach- als auch Datenverkehr transportieren. Wenn zum Beispiel mehrere Lichtwellenleiter-Verstärkern einem optischen Weitverkehrs-Kommunikationssystem hintereinandergeschaltet werden, so setzt die resultierende Rauschakkumulation von den Lichtwellenleiter-Verstärkern eine untere Grenze für die Bitfehlerratenleistung einer Leitung (d.h. niedrigste erreichbare Bitfehlerrate).
Vorwärtsfehlerkorrektur (Forward Error Correction, FEC) wird seit vielen Jahren angewendet, um die Kanalzuverlässigkeit in Kommunikationssystemen zu verbessern. Die Anwendung von Vorwärtsfehlerkorrektur in SONET/SDH-Systemen ist jedoch mit vielen Schwierigkeiten verbunden. Insbesondere ist das Einfügen eines Vorwärtsfehlerkorrekturcodes in SONET/SDH-Übertragungsrahmen in Anbetracht der begrenzter Menge an ungenutztem Overhead sehr schwierig. Ferner erfordern Vorwärtsfehlerkorrekturschemata eine beträchtliche Menge an Speicher zum Puffern großer Datenmengen am Empfänger in einem SONST/SDH-System. Verzögerungen, die mit dem Verarbeiten von Vorwärtsfehlerkorrektur in einem SONST/SDH-System zusammenhängen, sind ebenfalls ein Problem, insbesondere für höherratige Systeme.
In einem vorgeschlagenen Schema, das von W. Grover et al. in Design and Characterization of an Error-Correcting Code for the SONST STS-1 Tributary, IEEE Transactions on Communications, Bd. 38, Nr. 4, April 1990, beschrieben wurde, wird Vorwärtsfehlerkorrektur auf einer Basis des Synchronous Transport Signals angewendet, wobei ein ganzer STS-1-Rahmen in einen Vorwärtsfehlerkorrekturblock abgebildet wird. Da ein ganzer Rahmen gepuffert werden muss, beträgt die Verzögerung ungefähr 125 μs oder mehr. Dieses Schema erfordert außerdem ungenutzte Overheadbytes in einem STS-1-Rahmen zum Transportieren des Vorwärtsfehlerkorrekturcodes. Bekanntlich ist der ungenutzte Overhead in einem STS-1-Rahmen sehr begrenzt. Das Skalieren auf höhere Raten unter Verwendung dieses auf STS-1 basierenden Fehlerkorrekturschemas ist aufgrund der Komplexität der Implementierung, der Anforderungen an die Pufferung und der Verarbeitungsverzögerungen problematisch. Insbesondere erhöht sich, wenn sich die Übertragungsgeschwindigkeit erhöht, die Anzahl der erforderlichen Vorwärtsfehlerkorrekturblöcke, wodurch sich die Anforderungen an die Pufferung und die damit zusammenhängenden Verarbeitungsverzögerungen erhöhen. Zum Beispiel würde das Anwenden dieses Fehlerkorrekturschemas auf ein STS-192-Signal 192 Blöcke (d.h. unabhängige Vorwärtsfehlerkorrektur-Algorithmen) und 192 logische Puffer mit einer Gesamtpuffergröße, die sich einer Million Bit nähert, erfordern.
In einem anderen vorgeschlagenen Schema wird ein Vorwärtsfehlerkorrekturcode auf drei Zeilen eines SONET STS-3-Signals (z.B. ein Drittel eines Rahmens) angewendet. Obwohl diese Vorgehensweise im Vergleich zu der vorhergehenden Vorgehensweise weniger Overhead erfordert, erfordert dieses Schema noch immer die Pufferung für ein Drittel eines Rahmens mit einer damit zusammenhängenden Verzögerung von ungefähr 45 μs. Ferner erfordert dieses Schema auch mehrere Vorwärtsfehlerkorrektur-Algorithmen zur Verarbeitung des 3-Zeilen-Blockes. Das Skalieren auf höhere Raten ist aus denselben Gründen, die oben dargelegt wurden, ebenfalls problematisch. Zum Beispiel würde die Anwendung dieses Fehlerkorrekturschemas auf ein STS-192-Signal eine parallele Verarbeitung von mindestens 64 Vorwärtsfehlerkorrektur-Algorithmen und eine Pufferung für ungefähr 414.720 Bits erfordern.
Das US-Patent Nr. 5,574,717 beschreibt eine Vorgehensweise zur Anwendung einer Fehlerkorrektur auf eine Synchronous Digital Hierarchy (SDH) Synchronous Transport Module (STM-1) Signalisierungsstruktur, welche hinsichtlich der Übertragungsgeschwindigkeit zu einem SONET STS-3c-Signal äquivalent ist (z.B. 155 MB/s). Das Skalieren auf höhere Übertragungsgeschwindigkeiten, wie etwa ein STS-64-Signal, welches hinsichtlich der Übertragungsgeschwindigkeit zu einem SONET STS-192-Signal äquivalent ist, ist ebenfalls problematisch aufgrund der Anforderungen an die Pufferung (z.B. ein ganzer Rahmen) und der Verzögerung (z.B. ungefähr 125 μs). Außerdem würde dieses Schema die parallele Verarbeitung von 64 Vorwärtsfehlerkorrektur-Algorithmen erfordern.
In "Error-Correction Coding for High-Speed Optical Transmission Systems Based on the Synchronous Digital Hierarchy" von V. Paxal et al. (European Transactions on Telecommunications and related Technologies, Bd. 4, Nr. 6, November 1993) wird ein Codierungsschema für einen STM-1-Rahmen in einem SDH-System offenbart. Wie offenbart wird, werden einige der existierenden freien Bitpositionen in einem STM-1-Rahmen verwendet, um redundante Bits einzufügen, die durch Blockcodierung der STM-1-Nutzlast-Envelope erhalten werden. Der Code wird auf den STM-1-Rahmen "dreizeilenweise" angewendet.
KURZDARSTELLUNG DER ERFINDUNG
Ein Verfahren und eine Vorrichtung gemäß der vorliegenden Erfindung sind in den unabhängigen Ansprüchen dargelegt, auf welche der Leser nun verwiesen wird. Bevorzugte Merkmale sind in den abhängigen Ansprüchen dargelegt.
Die Speicheranforderungen und Verarbeitungsverzögerungen, die mit der Anwendung von Vorwärtsfehlerkorrektur bei hochratigen optischen Übertragungen zusammenhängen, werden gemäß den Prinzipien der Erfindung wesentlich reduziert, indem ein Vorwärtsfehlerkorrekturcode zeilenweise in ungenutzte Overheadbytes in einem Signalrahmen mit hoher Bitrate abgebildet wird. Durch Anwenden des Vorwärtsfehlerkorrekturcodes auf eine ganze Zeile des Signalrahmens zeilenweise muss jeweils ungefähr eine Zeile gleichzeitig gespeichert werden, wodurch der Gesamtspeicherbedarf für die Vorwärtsfehlerkorrektur-Verarbeitung reduziert wird. Bei Verwendung von SONET als eine beispielhafte Anwendung muss ungefähr 1/9 des gesamten SONET-Rahmens (z.B. eine von neun Zeilen) für die Vorwärtsfehlerkorrektur-Verarbeitung gepuffert werden, gegenüber einem ganzen SONET-Rahmen oder einem Drittel eines SONET-Rahmens, wie bei den vorhergehenden Anwendungen. weniger Speicher bedeutet niedrigere Kosten und geringere Komplexität für das Implementieren der Vorwärtsfehlerkorrektur. Ferner wird im Ergebnis der geringeren Anforderungen an die Pufferung und reduzierten Verarbeitung die Verzögerung verringert.
Bei einer der Veranschaulichung dienenden Ausführungsform der Erfindung sind vier Vorwärtsfehlerkorrektur- (Forward Error Correction, FEC-) Blöcke für jede Zeile vorgesehen, also insgesamt 36 FEC-Blöcke für einen Rahmen. Jeder FEC-Block weist vier Bytes von Korrekturbits auf, was insgesamt 32 Korrekturbits ergibt. Diese 32 Korrekturbits werden auf ungenutzten Overhead abgebildet und werden zum Korrigieren von Fehlern in einem Block einer Zeile eines Signalrahmens verwendet, wobei ein Block 1/4 der Zeile überdeckt. Andere ungenutzte Overheadbytes in der Zeile können verwendet werden, um Fehlererkennungscodes zu transportieren, um die wohlüberlegte Steuerung der Vorwärtsfehlerkorrektur zu erleichtern. Insbesondere können Fehlererkennungstechniken, wie etwa bitverschachtelte Parität (Bit Interleaved Parity, BIP), zyklische Redundanzprüfungen (Cyclic Redundancy Checks, CRC) und ähnliches, zum Erkennen von mehreren Fehlern in einer Zeile verwendet werden, um zu bestimmen, wann Vorwärtsfehlerkorrektur gesperrt werden sollte. Wenn zum Beispiel ein Einbit-Fehlerkorrekturcode angewendet wird, kann die Fehlerkorrektur gesperrt werden, um falsche Korrekturen zu vermeiden, wenn mehr als ein Fehler erkannt wird. Andere nicht genutzte Overheadbytes können auch verwendet werden, um Inband-Wartungskapazitäten zur Verfügung zu stellen, z.B. um Steuerbytes zu transportieren, um zu bewirken, dass die Fehlerkorrektur auf geeignete weise am Empfänger freigegeben oder gesperrt wird.
Die Anwendung einer Vorgehensweise mit zeilenweiser Abbildung bewirkt eine erhebliche Verringerung der Verzögerung und verringert im Vergleich mit den früheren Anordnungen die Menge an Speicher, die für die Fehlerkorrektur-Verarbeitung benötigt wird. Zum Beispiel kann, da immer nur jeweils eine Zeile gleichzeitig gepuffert und verarbeitet werden muss, die Verzögerung für ein 10 Gb/s STS-192-Signal auf ungefähr 15 μs oder weniger reduziert werden (ungefähr 1/9 eines 125 μs Rahmens), und der Speicherbedarf kann auf ungefähr 17 KByte verringert werden, was beides eine erhebliche Verbesserung gegenüber den existierenden Schemata der Vorwärtsfehlerkorrektur darstellt, die für SONET/SDH-Systeme in Frage kommen. Außerdem verwendet das Abbildungsschema gemäß den Prinzipien der Erfindung wesentlich weniger Overhead und erfordert keine parallele Verarbeitung einer großen Anzahl von Vorwärtsfehlerkorrektur-Algorithmen, wie bei früheren Anordnungen. Vorteilhafterweise behält das Abbildungsschema die Struktur des Signals bei und ist für verschiedene Nutzlastraten geeignet, z.B. STS-3/3c, STS-12/12c, STS-48/48c, STS-192/192c, sowie für höherratige Signale, die in zukünftigen Anwendungen verwendet werden können.
KURZBESCHREIBUNG DER ZEICHNUNG
Ein umfassenderes Verständnis der Prinzipien der Erfindung kann durch das Studium der nachfolgenden ausführlichen Beschreibung in Verbindung mit der Zeichnung erreicht werden, wobei gleiche Elemente mit gleichen Bezugszeichen bezeichnet sind und wobei:
1 ein vereinfachtes Blockschaltbild ist, das ein Beispiel eines typischen SONET STS-192-Signalrahmens zeigt;
2 ein vereinfachtes Blockschaltbild ist, das eine der Veranschaulichung dienende Ausführungsform des Vorwärtsfehlerkorrektur-Abbildungsschemas für ein SONET STS-192-Signal gemäß den Prinzipien der Erfindung zeigt;
3A, 3B und 3C vereinfachte Blockschaltbilder der Bytezuordnugen der Vorwärtsfehlerkorrektur gemäß einer beispielhaften Ausführungsform der Erfindung sind;
4 ein Beispiel eines Vorwärtsfehlerkorrektur-Startbytes gemäß den Prinzipien der Erfindung zeigt;
5 ein Beispiel eines typischen SONET STS-192-Bytes zeigt, das für die Platzierung von Vorwärtsfehlerkorrektur-Bits gemäß einer beispielhaften Ausführungsform der Erfindung verwendet wird;
6 ein vereinfachtes Blockschaltbild ist, das eine andere der Veranschaulichung dienende Ausführungsform des Abbildungsschemas zum Platzieren ausgewählter Vorwärtsfehlerkorrekturbits in einem SONET STS-192-Signal gemäß den Prinzipien der Erfindung zeigt;
7 und 8 vereinfachte Flussdiagramme sind, welche die Codierungs- bzw. Decodierungsfunktion zeigen, die mit der Sende- bzw. Empfangsfunktion des Systems verknüpft ist;
9 ein Diagramm ist, das die Bitfehlerraten zeigt, die gemäß einer beispielhaften Ausführungsform der Erfindung erreicht wurden;
10 ein Diagramm ist, das die Signal-Rausch-Verhältnisse zeigt, die gemäß einer beispielhaften Ausführungsform der Erfindung erreicht wurden; und
11 ein vereinfachtes Schema ist, das eine Verschachtelungsfolge für das Abbildungsschema gemäß den Prinzipien der Erfindung zeigt.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Obwohl die hier beschriebenen, der Veranschaulichung dienenden Ausführungsformen für eine SONET/SDH STS-192/STM-64 (10 Gb/s) Signalstruktur besonders gut geeignet sind und in diesem beispielhaften Kontext beschrieben werden, wird für Fachleute anhand der hier dargelegten Lehren klar werden, dass die Prinzipien der Erfindung auch bei anderen Signalraten sowie anderen Signalstrukturen angewendet werden können. Dementsprechend sollen die hier dargestellten und beschriebenen Ausführungsformen nur der Veranschaulichung dienen und nicht einschränkend sein. Es ist jedoch anzumerken, dass, obwohl die Prinzipien der Erfindung auch auf SONET/SDH-Signale mit niedrigerer Bitrate angewendet werden können, es gewöhnlich klar ist, dass Signale mit niedrigerer Bitrate möglicherweise nicht so anfällig gegenüber optischen Beeinträchtigungen sind wie die Signale mit höherer Bitrate.
Im Allgemeinen ist die Anwendung von Vorwärtsfehlerkorrektur mit zwei primären Überlegungen verbunden. Erstens muss ein geeigneter Vorwärtsfehlerkorrektur-Algorithmus ausgewählt werden, welcher die entsprechende Datenredundanz zum Korrigieren von Fehlern gewährleistet, um die Gesamt-Bitfehlerratenleistung des Systems zu verbessern. Es gibt viele wohlbekannte Vorwärtsfehlerkorrektur-Algorithmen, welche in Verbindung mit den Prinzipien der Erfindung verwendet werden können, um Einbit-Fehlerkorrektur, Mehrbit-Fehlerkorrektur und so weiter zu gewährleisten. Zu diesen wohlbekannten Algorithmen gehören, lediglich als Beispiel, Hamming-Codes, Reed-Solomon-Codes, BCH- (Bose-Chaudhuri-Hocquenghem-) Codes und ähnliche. Die Auswahl eines geeigneten Vorwärtsfehlerkorrektur-Algorithmus wird von dem Niveau der Bitfehlerkorrektur abhängen, das für die Anwendung erforderlich ist, sowie von anderen Faktoren, welche den Fachleuten wohlbekannt sind.
Zweitens muss eine Vorgehensweise zum Abbilden des Vorwärtsfehlerkorrektur-Algorithmus auf die Signalisierungsstruktur des Netzes ausgewählt werden. Die hier dargestellten und beschriebenen Ausführungsformen der Erfindung betreffen die zweite Überlegung, das heißt, ein Abbildungsschema zum Platzieren von Vorwärtsfehlerkorrektur in einem hochratigen optischen Signal. Lediglich für Zwecke der Veranschaulichung ist die hier beschriebene Signalisierungsstruktur des Netzes ein SONET STS-192 (10 Gb/s) Signal, auch andere Signalraten und Strukturen für die Lehren der Erfindung in Betracht kommen.
1 zeigt einen typischen SONET STS-192-Signalrahmen 100, dessen Dauer 125 μs beträgt und der 9 Zeilen und 17.280 Spalten (d.h. Bytes) aufweist. Das Format des Rahmens 100 ist wohlbekannt und in zahlreichen auf SONET basierenden Standards gut dokumentiert. Wie dargestellt, transportieren die ersten 576 Spalten der Zeilen 1-9 Bytes für den Transport-Overhead 101, während die restlichen Spalten Bytes für die synchrone Nutzlast-Envelope (Synchronous Payload Envelope, SPE) 102 transportieren. Bekanntlich weist der Transport-Overhead 101 Abschnittsoverhead (Section Overhead) 105 in den Zeilen 1-3 und Verbindungsoverhead (Live Overhead) 110 in den Zeilen 4-9 auf, während die synchrone Nutzlast-Envelope 102 Wegoverhead 120 in den ersten 192 Spalten und Nutzlastdaten 125 in den restlichen Spalten enthält. Der SONET STS-192-Rahmen 100 weist eine Signalrate von ungefähr 10 Gb/s auf.
2 ist ein vereinfachtes Blockschaltbild, das eine der Veranschaulichung dienende Ausführungsform des Vorwärtsfehlerkorrektur-Abbildungsschemas zeigt, das auf den SONET STS-192-Signalrahmen 100 angewendet wird. Allgemein wird Vorwärtsfehlerkorrektur auf einen Signalrahmen 100 angewendet, indem Vorwärtsfehlerkorrekturbytes in den Transport-Overhead 101 zeilenweise wie folgt abgebildet werden. Vier (4) Vorwärtsfehlerkorrektur- (Forward Error Correction, FEC-) Blöcke 205 sind für jede Zeile vorgesehen, was insgesamt 36 FEC-Blöcke für einen Rahmen 100 ergibt. Die FEC-Blöcke 205 sind als FEC dargestellt, wobei X die Zeilennummer darstellt (mit 1-9 bezeichnet) und Y die Blocknummer innerhalb der Zeile darstellt (mit A, B, C und D bezeichnet). Beispielsweise stellt FEC 1A-1D die FEC-Blöcke für Zeile 1 dar, FEC 2A-2D für Zeile 2 und so weiter. Wie dargestellt, werden die FEC-Blöcke 205 in einer bestimmten Zeile auf die unmittelbar vorangehende Zeile angewendet, d.h., die FEC-Blöcke 1A bis 1D decken Zeile 9 des vorhergehenden Rahmens ab, die FEC-Blöcke 2A bis 2D decken Zeile 1 des aktuellen Rahmens ab, und so weiter. Die Lage der FEC-Blöcke 205 innerhalb des Transportoverheads 101 wird weiter unten ausführlicher beschrieben.
Gemäß den Prinzipien der Erfindung kann Vorwärtsfehlerkorrektur auf den gesamten Rahmen 100 angewendet werden, derart, dass Fehler sowohl im Transport-Overhead 101 als auch in der Nutzlast 102 korrigiert werden können, mit einigen Ausnahmen, die weiter unten vermerkt sind. Da 4 FEC-Blöcke jeweils eine Zeile überdecken, überdeckt jeder FEC-Block somit 1/4 einer Zeile oder 34.560 Bits, d.h.
Beispielsweise deckt der FEC-Block 2A in Zeile 2 1/4 der Bits ab, die in Zeile 1 zu finden sind. Wie weiter unten ausführlicher beschrieben wird, deckt der FEC-Block 2A in Zeile 2 die FEC-Korrekturbits in Zeile 2 und nicht die FEC-Korrekturbits von Zeile 1 ab.
Es ist anzumerken, dass 2 nur eine beispielhafte Ausführungsform gemäß den Prinzipien der Erfindung zeigt. Andere Änderungen und Modifikationen sind für Fachleute offensichtlich und werden durch die hier dargelegten Lehren mit in Betracht gezogen. Zum Beispiel können mehr als vier (4) FEC-Blöcke verwendet werden, oder es kann auch nur ein (1) FEC-Block für jede Zeile verwendet werden. Die Entscheidung über die geeignete Anzahl von FEC-Blöcken für jede Zeile hängt von verschiedenen Überlegungen ab, darunter vom Typ des Vorwärtsfehlerkorrekturcodes, der verwendet wird, vom verfügbaren Overhead in der Zeile und von dem Zustand der Technik, die für die Geräteimplementierung verwendet wird, um nur einige zu nennen. In jedem Falle wird die Komplexität, die mit der parallelen Verarbeitung von Vorwärtsfehlerkorrektur-Algorithmen verknüpft ist, gemäß den Prinzipien der Erfindung im Vergleich mit den früheren Anordnungen wesentlich verringert. Wenn beispielsweise vier (4) FEC-Blöcke pro Zeile verwendet werden, müssen jeweils nur vier Vorwärtsfehlerkorrektur-Prozesse gleichzeitig ausgeführt werden, da die zeilenweise Verarbeitung die Wiederverwendung derselben Vorwärtsfehlerkorrektur-Schaltungsanordnung für jede Zeile ermöglicht.
3A zeigt ein Beispiel von Bytezuordnungen für einen einzelnen FEC-Block 300 gemäß einer der Veranschaulichung dienenden Ausführungsform der Erfindung. Wie dargestellt, weist der FEC-Block 300 vier (4) Bytes 301-304 von Korrekturbits auf, also insgesamt 32 Korrekturbits. Diese 32 Korrekturbits werden verwendet, um Fehler in einem Block einer STS-192-Zeile zu korrigieren, wobei ein Block 1/4 der Zeile oder 34.560 Bits umfasst. Demzufolge werden vier (4) FEC-Blöcke 300 verwendet, um in der gesamten STS-192-Zeile Fehler zu korrigieren. Es ist anzumerken, dass 32 Korrekturbits nur eine beispielhafte Ausführungsform für einen FEC-Block darstellen und auch mehr Korrekturbits verwendet werden können, in Abhängigkeit vom Typ und von der Leistungsfähigkeit des ausgewählten Vorwärtsfehlerkorrekturcodes.
Zusätzlich zu den Korrekturbits, welche zum Korrigieren von Fehlern in den entsprechenden Datenblöcken innerhalb jeder Zeile verwendet werden, kann ein Fehlererkennungscode auch zusammen mit den Korrekturbits in den entsprechenden Transport-Overhead der Zeilen abgebildet werden. Zum Beispiel können Fehlererkennungstechniken, wie etwa bitverschachtelte Parität (Bit Interleaved Parity, BIP), zyklische Redundanzprüfungen (Cyclic Redundancy Checks, CRC) und andere wohlbekannte Codierungsverfahren zum Erkennen von mehreren Fehlern angewendet werden, um sicherzustellen, dass Vorwärtsfehlerkorrektur nur dann freigegeben wird, wenn die Anzahl der Fehler in einer Zeile nicht die Bitfehlerkorrektur-Fähigkeit des verwendeten Vorwärtsfehlerkorrekturcodes übersteigt. Im Interesse der Einfachheit der Erläuterung wird eine 8-Bit bitverschachtelte Parität (BIP-8) als eine beispielhafte Ausführungsform verwendet. Es ist jedoch anzumerken, dass diese spezielle Ausführungsform nur der Veranschaulichung dienen und keine Einschränkung darstellen soll.
3B zeigt eine mögliche Implementierung für bitverschachtelte Parität (hier als BIP-8 dargestellt), welche verwendet werden kann, um Parität über die entsprechenden Datenblöcke plus die FEC-Korrekturbits zu gewährleisten. Wie dargestellt, weist der BIP-8 Block 325 vier (4) Bytes 326-329 von BIP-8 Paritätsbits auf, wobei jedes Byte von BIP-8 Paritätsbits einem der FEC-Blöcke 300 in einer Zeile, d.h. der FEC-Blöcke A, B, C und D, entspricht. Demzufolge gewährleistet jedes BIP-8 Paritätsbyte 326-329 Parität über 34.560 Bits in einer Zeile, darunter 32 FEC-Korrekturbits, die einem FEC-Block entsprechen. Wie weiter unten ausführlicher beschrieben wird, kann BIP-8 Parität verwendet werden, um wohlüberlegt zu steuern, wann Vorwärtsfehlerkorrektur freigegeben und gesperrt wird. Wenn zum Beispiel BIP-8 Parität mehrere Fehler in einer Zeile erkennt, welche die Fähigkeit des Vorwärtsfehlerkorrektur-Algorithmus übersteigen, d.h., es werden 3 Fehler erkannt, wenn der Algorithmus eine Fehlerkorrektur-Fähigkeit von 2 Bits hat, dann kann Vorwärtsfehlerkorrektur gesperrt werden, um eventuelle Fehlkorrekturen oder falsche Korrekturen zu verhindern.
3C zeigt eine beispielhafte FEC-Abbildung 350, die einer ganzen Zeile des STS-192-Signals entspricht. Wie bei dieser Ausführungsform dargestellt, enthält die FEC-Abbildung 350 insgesamt 20 FEC-Bytes, die in jede Zeile abgebildet werden. Genauer, die FEC-Abbildung 350 umfasst vier (4) FEC-Blöcke 300, von denen jeder vier (4) FEC-Bytes aufweist, die in 3A dargestellt sind und 1/4 einer Zeile entsprechen, und einen BIP-8 Block 325, welcher vier (4) BIP-8 Paritätsbytes enthält, wie in 3B dargestellt, um Parität über die vier (4) FEC-Blöcke 300 und die entsprechenden Daten zu gewährleisten. Daher sind 20 Bytes Transport-Overhead in jeder STS-192-Zeile erforderlich, um die FEC-Korrekturbits und BIP-8 Paritätsbits in der FEC-Abbildung 350 zu transportieren.
Es ist anzumerken, dass die obigen Bytedefinitionen nur ein Beispiel für die Abbildung einer Vorwärtsfehlerkorrektur in ein STS-192-Signal veranschaulichen. Andere Modifikationen können mit den hier dargelegten Lehren in Einklang gebracht werden. Zum Beispiel können die Bytedefinitionen in Abhängigkeit von der Leistungsfähigkeit des speziellen ausgewählten Vorwärtsfehlerkorrektur-Algorithmus variieren. Für die effizienteste Verwendung von ungenutztem Overhead, um Vorwärtsfehlerkorrekturbytes gemäß diesem Abbildungsschema zu transportieren, ist es denkbar, dass der ausgewählte Vorwärtsfehlerkorrektur-Algorithmus nicht mehr als 24 Overhead-Bytes pro Zeile verwenden sollte, obwohl mehr ungenutzter Overhead verfügbar ist, wie weiter unten beschrieben wird.
Es wird erneut auf 2 Bezug genommen; sie zeigt eine der Veranschaulichung dienende Ausführungsform für die spezielle Platzierung, d.h. Zeilen-/Spalten-Abbildung, der FEC-Bytes in den Transport-Overhead des STS-192-Rahmens 100. Die spezielle Platzierung von FEC-Bytes, die in dieser Ausführungsform dargestellt ist, liefert eine optimierte Lösung für die Abbildung von Vorwärtsfehlerkorrektur; diese Ausführungsform soll jedoch lediglich der Veranschaulichung dienen und keine Einschränkung darstellen, da auch andere Platzierungen möglich sind. Für eine optimale Abbildung der FEC-Bytes im STS-192-Rahmen 100 sollte die Platzierung der FEC-Bytes in Zeile 4 anders gehandhabt werden als die Platzierung des FEC-Bytes in den Zeilen 1-3 und 5-9, wegen des Mangels an ungenutztem Overhead in Zeile 4 des STS-192-Rahmens 100.
Wie in 2 dargestellt, werden die FEC-Bytes in ungenutztem Abschnittsoverhead für die Zeilen 1-3 und in ungenutztem Verbindungsoverhead für die Zeilen 5-9 des STS-192-Rahmens 100 platziert. Um der Vollständigkeit willen werden die detaillierten Platzierungen der FEC-Bytes in diesen Zeilen auch bezüglich des SDH-Signals mit äquivalenter Bitrate, d.h. des 10 Gb/s STM-64-Signals, beschrieben. Das Format eines SDH STM-64-Rahmens ist wohlbekannt und in SDH betreffenden Standards gut dokumentiert. Daher sind Verweise auf spezielle Abbildungspositionen sowohl im SONET- als auch im SDH-Format für Fachleute verständlich.
Insbesondere werden die FEC-Bytes 205, die dem Block A in den Zeilen 1-3 und 5-9 entsprechen (d.h. FEC 1A, 2A, 3A, 5A, 6A, 7A, 8A, 9A), auf die Spalten 449 bis 452 (384 + 65 bis 384 + 68) und die Spalte 465 (384 + 81) abgebildet. Für das SDH äquivalente STM-64-Signal werden diese FEC-Bytes auf Positionen S (1-3 und 5-9, 8, 1-4 und 17) abgebildet, wobei S(x, y, z) definiert ist mit x = Zeile (1-9), y = Mehrfach-Spalte (1-9) und z = Tiefe (1-64). Ähnlich werden die FEC-Bytes 205, die dem Block B in den Zeilen 1-3 und 5-9 entsprechen (d.h. FEC 1B, 2B, 3B, 5B, 6B, 7B, 8B, 9B), auf die Spalten 453 bis 456 (384 + 69 bis 384 + 72) und die Spalte 466 (384 + 82) abgebildet. Für das SDH äquivalente STM-64-Signal werden diese FEC-Bytes auf Positionen S (1-3 und 5-9, 8, 5-8 und 18) abgebildet. Die FEC-Bytes 205, die dem Block C in den Zeilen 1-3 und 5-9 entsprechen (d.h. FEC 1C, 2C, 3C, 5C, 6C, 7C, 8C, 9C), werden auf die Spalten 457 bis 460 (384 + 73 bis 384 + 76) und die Spalte 467 (384 + 83) abgebildet. Für das SDH äquivalente STM-64-Signal werden diese FEC-Bytes auf Positionen S (1-3 und 5-9, 8, 9-12 und 19) abgebildet. Schließlich werden die FEC-Bytes 205, die dem Block D in den Zeilen 1-3 und 5-9 entsprechen (d.h. FEC 1D, 2D, 3D, 5D, 6D, 7D, 8D, 9D), auf die Spalten 461 bis 464 (384 + 77 bis 384 + 80) und die Spalte 468 (384 + 84) abgebildet. Für das SDH äquivalente STM-64-Signal werden diese FEC-Bytes auf Positionen S (1-3 und 5-9, 8, 13-16 und 20) abgebildet.
Ein FEC-Startbyte 400 (auch als ein FEC-Korrektur-Steuerbyte bezeichnet) kann verwendet werden, um das Freigeben/Sperren von Vorwärtsfehlerkorrektur für alle 36 Blöcke in dem SONET-Rahmen zu steuern. In einem beispielhaften Abbildungsschema kann das FEC-Startbyte 400 auf Zeile 1, Spalte 469 (384 + 85) des STS-192-Rahmens oder in die äquivalente STM-64-Position S (1, 8, 21) abgebildet werden. Wie in 4 dargestellt, umfasst eine beispielhafte Bytedefinition für das FEC-Startbyte 400 acht (8) Aktivitätsbits 401. In Betrieb kann das FEC-Startbyte 400 vorteilhaft verwendet werden, wenn eine Anwendung erfordert, dass Korrekturen während des Betriebs freigegeben oder gesperrt werden, ohne Auswirkungen auf den Verkehr zu verursachen.
2, 5 und 6 zeigen zusammen eine optimale Abbildung für FEC-Bytes in Zeile 4 von Rahmen 100. Da Zeile 4 keinen ungenutzten Overhead enthält, wie in Zeile 1-3 und 5-9, wird ein anderes Abbildungsschema in Betracht gezogen, welches die H1-Bytes in Zeile 4 verwendet. 5 zeigt eine typische Bytekonfiguration für das H1-Byte 500 in Zeile 4. Für die Zwecke dieses Abbildungsschema ist es denkbar, dass die FEC-Bytes in SO-Bitpositionen 501 von H1-Bytes 500 in Zeile 4 transportiert werden können. Genauer, es müssen SO-Bits in 160 aufeinanderfolgenden H1-Bytes im Verbindungsoverhead von Zeile 4 verwendet werden, um die 20 FEC-Bytes für Zeile 4 zu transportieren (d.h. 20 Bytes × 8 Bits/Byte). 6 zeigt ein vereinfachtes Abbildungsschema für einen einzelnen FEC-Block 600 in Zeile 4, wobei die 32 Korrekturbits den Inhalt der S0-Bits an den Positionen 601 ersetzen.
Es ist anzumerken, dass die Auswahl des H1-Bytes und die Auswahl des SO-Bits innerhalb des H1-Bytes, um die FEC-Bytes für Zeile 4 zu transportieren, nur eine der Veranschaulichung dienende Ausführungsform darstellen. Zum Beispiel könnten andere Overhead-Bytes verwendet werden. Außerdem könnte auch das S1-Bit in dem H1-Byte auf eine ähnliche Weise verwendet werden, wie es für das S0-Bit beschrieben wurde. Bei einer weiteren Ausführungsform könnten sowohl das S0- als auch das S1-Bit zusammen verwendet werden, so dass nur eine halb so große Anzahl aufeinanderfolgender H1-Byte-Rahmen (d.h. 80) erforderlich wäre.
Es wird erneut auf 2 Bezug genommen; die FEC-Bytes 205, die den Blöcken A bis D in Zeile 4 entsprechen (d.h. FEC 4A, 4B, 4C, 4D), werden auf die S0-Bitposition der letzten 160 H1-Bytes in dem Verbindungsoverhead abgebildet, der den Spalten 33-192 des STS-192-Rahmens 100 entspricht, oder im äquivalenten SDH Signalformat auf die Positionen S (4, 1, 33) bis S (4, 3, 64). Genauer, die FEC-Bytes, die Block A in Zeile 4 entsprechen (d.h. FEC 4A), werden auf die Spalten 33-64 und 161-168 abgebildet, die FEC-Bytes, die FEC 4B entsprechen, werden auf die Spalten 65-96 und 169-176 angebildet, die FEC-Bytes, die FEC 4C entsprechen, werden auf die Spalten 97-128 und 177-184 abgebildet, und die FEC-Bytes, die FEC 4D entsprechen, werden auf die Spalten 129-160 und 185-192 abgebildet. Es ist anzumerken, dass für SDH-Anwendungen die SS-Bit-Fehlanpassung möglicherweise für STM-64 Schnittstellen gemäß den zutreffenden Standards gesperrt werden muss.
Obwohl die S0-Overhead-Bits in Zeile 4 mit FEC-Bytes überschrieben werden, können diese überschriebenen Bytes erhalten bleiben, indem Umordnungen angewendet werden, die weiter unten beschrieben sind. Umordnungen können auch in einer vorausschauenden Weise angewendet werden, um zukünftigen Änderungen in Standards Rechnung zu tragen, welche zur Folge haben können, dass ein gegenwärtig undefiniertes Overheadbyte für eine bestimmte Verwendung definiert wird. Ein Beispiel ist das Z0 Wachstums-Byte, welches weiter unten beschrieben wird. Eine Umordnung ist ein relativ unkomplizierter Prozess, in welchem die Inhalte von überschriebenen Byte- und Bitpositionen kopiert und auf andere Timeslots, z.B. in einer anderen Zeile, abgebildet werden und dann nochmals kopiert und zu den ursprünglichen Timeslots zurückbewegt werden, nachdem die FEC-Verarbeitung abgeschlossen ist. Mit diesem Umordnungsverfahren können daher die Inhalte von überschriebenem Overhead (z.B. S0-Bits) bewahrt werden, ebenso wie gegenwärtig undefinierter Overhead, welcher möglicherweise in der Zukunft definiert wird (z.B. Z0 Wachstums-Bytes). Dementsprechend können die Prinzipien der Erfindung im Hinblick auf zukünftige Änderungen der Signalisierungsstruktur und ähnliches gewissermaßen "zukunftsfest" gemacht werden.
Zum Beispiel überschreibt das Abbilden des FEC-Startbytes 400 (4) und der FEC-Bytes 205 für die Blöcke A bis D in Zeile 1 (d. h. FEC 1A, 1B, 1C, 1D) die Z0 Wachstums-Bytes. Wenn diese Z0 Wachstums-Bytes später definiert werden, kann es wünschenswert werden, die Inhalte ankommender Z0-Bytes zu erhalten. Dies kann durch Umordnungen bewerkstelligt werden, bei denen die Inhalte der überschriebenen Z0-Bytes auf ungenutzten Overhead in einer anderen Zeile kopiert werden, z.B. die Bytes "nationale Verwendung" in Zeile 2. Nachdem die FEC-Decodierung abgeschlossen ist, können die Inhalte der Z0-Bytes auf umgekehrte Weise zu den ursprünglichen Timeslots in Zeile 1 zurückbewegt werden.
In ähnlicher Weise überschreibt das Abbilden der FEC-Bytes 205 für Zeile 4 die S0-Zeiger-Bits, wie zuvor beschrieben wurde. Falls es erforderlich wird, die Inhalte ankommender S0-Bits aufzubewahren, können die Inhalte zu ungenutztem Overhead in einer anderen Zeile, z.B. Zeile 5, bewegt werden. Nachdem die FEC-Decodierung abgeschlossen ist, können die Inhalte zurück in die S0-Bitpositionen in Zeile 4 kopiert werden. Die obigen Beispiele dienen lediglich der Veranschaulichung für zwei mögliche Umordnungs-Szenarien zur Erhaltung der Inhalte von überschriebenen Bits und Bytes.
7 und 8 sind vereinfachte Flussdiagramme, welche die Funktionsweise einer Vorwärtsfehlerkorrektur-Abbildung gemäß einer der Veranschaulichung dienenden Ausführungsform der Erfindung zeigen. Insbesondere zeigt 7 FEC-Codierungsfunktionen, die von einem FEC-Codierer 725 bezüglich der Sendefunktion ausgeführt werden, während 8 FEC-Decodierungsfunktionen zeigt, die von einem FEC-Decodierer 825 bezüglich der Empfangsfunktion ausgeführt werden.
In Betrieb werden, wie in 7 dargestellt, die Verarbeitung des Verbindungsoverhead-Sendebytes (Block 701), die Berechnung und Einfügung des B2-Bytes (Block 702) und die Verarbeitung des Abschnittsoverhead-Sendebytes (Block 703) unter Anwendung wohlbekannter Verarbeitungstechniken gemäß SONET/SDH betreffenden Standards ausgeführt. Nach der Verarbeitung des Abschnittsoverhead-Sendebytes (Block 703) werden die Z0-Bytes auf die zuvor beschriebene Weise umgeordnet (Block 704), z.B. die Inhalte der Z0-Bytes von Zeile 1 werden kopiert und in Timeslots in Zeile 2 eingefügt. In ähnlicher Weise werden die S0-Bits von den H1-Bytes in Zeile 4 aufbewahrt (Block 705), indem die Inhalte dieser Bits kopiert und in Zeile 5 eingefügt werden. Nachdem die S0-Bits umgeordnet worden sind, wird eine Kompensation des B2-Bytes wegen der S0-Umordnungen ausgeführt (Block 706). Die Kompensation des B2-Bytes wird weiter unten ausführlicher beschrieben.
Danach werden die FEC-Korrekturbits berechnet und in den Rahmen eingefügt, wie in Block 707 dargestellt. Insbesondere werden die 16 FEC-Korrekturbytes (d.h. 4 FEC-Korrekturbytes für jeden Block in einer Zeile) in die entsprechenden Positionen abgebildet. Es ist anzumerken, dass die FEC BIP-8 Paritätsbytes zu diesem Zeitpunkt nicht eingefügt werden. Nach dem Einfügen der FEC-Korrekturbits wird eine Kompensation des B2-Bytes wegen der Einfügung der FEC-Korrekturbits ausgeführt (Block 708). Danach werden die FEC BIP-8 Paritätsbytes über die entsprechenden FEC-Blöcke eingefügt, wie in Block 709 dargestellt. Wegen der Einfügung der FEC BIP-8 Paritätsbytes wird erneut eine Kompensation des B2-Bytes ausgeführt (Block 710). Da der Overhead von Zeile 1 nicht wie in den anderen Zeilen verwürfelt ist, werden die FEC-Blöcke für Zeile 1, d.h. FEC 1A bis 1D, einer EXKLUSIV-ODER-Verknüpfung (XOR) mit einem schaltbaren festen Muster unterzogen (wie in Block 711 dargestellt), um das Auftreten einer nur aus Nullbits bestehenden Zeichenkette zu verhindern. Zum Beispiel könnte das feste Muster ein Muster sein, indem sich Einsen und Nullen abwechseln ("10"). Anschließend wird das FEC-Startbyte eingefügt, wie in Block 712 dargestellt. Wenn ein Regenerator-Umgehungsmodus anwendbar ist, der durch Block 713 dargestellt ist, so würden die FEC-Overheadbytes, das FEC-Startbyte und die umgeordneten Z0-Bytes und S0-Bits unverändert durchlaufen.
Danach werden die Einfügung des B1-Bytes (Block 714) und eine SONET-Verwürfelung (Block 715) unter Anwendung wohlbekannter SONET/SDH Verarbeitungstechniken ausgeführt. Für die hier dargestellte und beschriebene Ausführungsform ist anzumerken, dass die Kompensation des B2-Bytes (d.h. die Schritte 706, 708, 710) und die Berechnung und Einfügung des B1-Bytes (Schritt 714) nach Einfügung der Prüfbits vorgenommen werden, um die Bytes B1 und B2 für das Senden intakt zu halten.
Wie in 7 dargestellt, können die Funktionen der Blöcke 704 bis 713 in einem FEC-Codierer integriert und ausgeführt sein, der hier funktional als Block 725 dargestellt ist. Der FEC-Codierer (Block 725) kann unter Anwendung wohlbekannter Verfahren implementiert werden, die durch Hardware, Software, anwendungsspezifische Schaltkreise (ASICs) oder eine Kombination davon ausgeführt werden.
Es wird auf 8 Bezug genommen; die FEC-Decodierungsfunktionen sind bezüglich der Empfangsfunktionen des Systems dargestellt. In Betrieb werden SONST/SDH Rahmenbildung (Block 801) und SONST/SDH Entwürfelung (Block 802) unter Anwendung wohlbekannter Verarbeitungstechniken gemäß SONST/SDH betreffenden Standards ausgeführt. Nach der Entwürfelung wird das FEC-Startbyte positioniert (Block 803), und in Abhängigkeit vom Wert des Startbytes wird, wie dargestellt, Vorwärtsfehlerkorrektur entweder freigegeben, um Korrekturen zu ermöglichen, oder gesperrt. Die FEC-Blöcke für Zeile 1, d.h. FEC 1A bis 1D, werden einer EXKLUSIV-ODER-Verknüpfung (XOR) mit einem schaltbaren festen Muster unterzogen, wie in Block 804 dargestellt und wie oben beschrieben wurde. Danach wird das FEC BIP-8 Paritätsbyte über seinen entsprechenden Datenblock berechnet (Block 805). Wie oben beschrieben, kann FEC BIP-8 Parität verwendet werden, um mehrfache Fehler zu erkennen und entsprechend Vorwärtsfehlerkorrektur freizugeben oder zu sperren, in Abhängigkeit davon, ob die Anzahl der erkannten Fehler innerhalb der Korrekturfähigkeit des gewählten Vorwärtsfehlerkorrektur-Algorithmus liegt.
Nachdem die Daten gespeichert wurden (Block 806), werden dann die FEC-Korrekturbits berechnet (Block 807), um die Position eventueller Fehler zu bestimmen. Danach kann unter der Voraussetzung, dass die Fehlerkorrektur nicht gesperrt wurde, die Korrektur von Bitfehlern erfolgen, wie in Block 808 dargestellt. Nach Beendigung der Fehlerkorrektur wird dann unter Anwendung wohlbekannter SONST/SDH Verarbeitungstechniken das B1-Byte berechnet und verglichen (Block 809). Anschließend werden die Z0-Bytes und SO-Bits umgeordnet, wie in den Blöcken 810 bzw. 811 dargestellt ist, indem die Inhalte zurück in ihre jeweiligen Zeilen kopiert werden. Nachdem die S0-Bits umgeordnet worden sind, wird die Kompensation des B2-Bytes wegen der S0-Umordnungen ausgeführt (Block 812). Zum Beispiel erfordert das B2-Byte eine Kompensation zum Entfernen der FEC-Korrekturbits aus Zeile 4. Die nachfolgende Verarbeitung des Abschnittsoverhead-Empfangsbytes (Block 813), die Berechnung des B2-Bytes (Block 814) und die Verarbeitung des Verbindungsoverhead-Empfangsbytes (Block 815) werden anschließend unter Anwendung wohlbekannter SONST/SDH Verarbeitungstechniken ausgeführt.
Wie in 8 dargestellt, können die Funktionen der Blöcke 803 bis 812 in einem FEC-Decoder integriert und ausgeführt sein, der hier funktional als Block 825 dargestellt ist. Der FEC-Decoder (Block 825) kann unter Anwendung wohlbekannter Verfahren implementiert werden, die durch Hardware, Software, anwendungsspezifische Schaltkreise (ASICs) oder eine Kombination davon ausgeführt werden.
Wie oben beschrieben, werden die Bytes B1 und B2 bei dieser Ausführungsform für die Übertragung intakt gehalten. Daher muss das B2-Byte kompensiert werden, um die Umordnungen und die Einfügung der FEC-Bytes zu berücksichtigen. Zum Beispiel ist die Kompensation des B2-Bytes wegen der S0-Umordnungen (Block 706) erforderlich, weil das Bewegen der Inhalte der S0-Bits in Zeile 4 zu Zeile 5 zur Folge hat, dass die Inhalte der betreffenden Bitpositionen von Zeile 5, z.B. Timeslots, überschrieben werden. Demzufolge ist eine Kompensation des B2-Bytes erforderlich, um die exakte Parität innerhalb von Zeile 5 aufrechtzuerhalten, z.B. durch Subtrahieren der überschriebenen Timeslots von Zeile 5 von der B2-Parität. In ähnlicher Weise ist eine Kompensation des B2-Bytes erforderlich, um die exakte Parität innerhalb von Zeile 4 aufrechtzuerhalten, nachdem die FEC-Bytes eingefügt worden sind (Block 708). Außerdem ist anzumerken, dass bei bestimmten Implementierungen das Verschieben von Inhalten zwischen Timeslots sich möglicherweise nicht unbedingt auf die B2-Parität auswirkt, je nachdem, welche Timeslots zum Ausführen der Verschiebung ausgewählt werden.
Wie bereits erwähnt, sind die hier dargestellten und beschriebenen Ausführungsformen nur als der Veranschaulichung dienend und nicht als einschränkend zu betrachten. Zum Beispiel werden bei den oben beschriebenen Ausführungsformen 5 FEC-Bytes (4 Bytes von Korrekturbits und 1 Byte von BIP-8 Parität) für jeden der 4 Blöcke in einer gegebenen Zeile abgebildet, so dass insgesamt 20 FEC-Bytes in jede Zeile abgebildet werden. Es ist jedoch anzumerken, dass das Abbildungsschema gemäß den Prinzipien der Erfindung verwendet werden kann, um bis zu 48 FEC-Bytes pro Zeile abzubilden. Dementsprechend kann die Anzahl der Blöcke pro Zeile und die Anzahl der FEC-Bytes pro Block variieren, in Abhängigkeit von dem speziellen Vorwärtsfehlerkorrekturcode, der für die Anwendung gewählt wurde, und anderen Faktoren, die weiter oben beschrieben wurden. Eines von vielen Beispielen eines geeigneten Vorwärtsfehlerkorrektur-Algorithmus, welcher gemäß den Prinzipien der Erfindung auf ein STS-192-Signal abgebildet werden kann, ist ein Doppelbitfehlerkorrektur-BCH-Code (d.h. BCH-2). Einige der die Leistung betreffenden Vorteile, die mit der Verwendung eines BCH-2-Codes in Verbindung mit dem Abbildungsschema der Erfindung verknüpft sind, sind in den 9 und 10 dargestellt. Insbesondere zeigt 9 eine graphische Darstellung der Eingangs-Bitfehlerrate (Bit Error Rate, BER) und Ausgangs-BER nach Korrekturen unter Verwendung eines BCH-2-Codes, der eine Codelänge von 16 aufweist, d.h. 16 Korrekturbytes. 10 zeigt die Bitfehlerrate, sowohl korrigiert als auch unkorrigiert, als eine Funktion des Signal-Rausch-Verhältnisses (Signal to Noise Ratio, SNR). In der Abbildung stellt die Kurve 901 eine unkorrigierte Bitfehlerrate dar, die Kurve 902 stellt eine Bitfehlerrate dar, die unter Verwendung eines Einzelfehler korrigierenden Hamming-Codes gemäß den Prinzipien der Erfindung korrigiert wurde, und die Kurve 903 stellt eine Bitfehlerrate dar, die unter Verwendung eines Doppelbitfehlerkorrektur-BCH-2-Codes gemäß den Prinzipien der Erfindung korrigiert wurde. Die Vorteile hinsichtlich der Leistung variieren natürlich in Abhängigkeit vom Typ und von der Leistungsfähigkeit des gewählten Vorwärtsfehlerkorrekturcodes. Demzufolge sind die in 9 und 10 dargestellten Vorteile hinsichtlich der Leistung nur als der Veranschaulichung dienend und nicht als einschränkend anzusehen.
Gemäß einem anderen Aspekt der Erfindung kann eine Burstfehler-Korrekturfähigkeit durch Bitverschachtelung der Vorwärtsfehlerkorrekturblöcke erreicht werden, wie in 11 dargestellt. Insbesondere verbessert eine Bitverschachtelung die Burstfehler-Korrekturfähigkeit, da mehrere benachbarte Bitfehler auf verschiedene Vorwärtsfehlerkorrekturblöcke abgebildet werden und jeder Vorwärtsfehlerkorrekturblock mehrere Fehler korrigieren kann.
Wie oben erwähnt, kann Vorwärtsfehlerkorrektur auf einen ganzen SONET-Rahmen angewendet werden, so dass Fehler sowohl im Transport-Overhead als auch in der Nutzlast korrigiert werden können, mit einigen Ausnahmen. Im Allgemeinen sollten die FEC-Blöcke nicht das FEC-Startbyte, die FEC BIP-8 Bytes, den Abschnittsoverhead in den Zeilen 1-3, die B2-Bytes und die umgeordneten Z0-Bytes und S0-Bits überdecken. Zum Beispiel kann das FEC-Startbyte während der Übertragung Werte ändern, zum Beispiel infolge eines Defektes der Einrichtung. Daher kann die Anwendung von FEC auf das Startbyte eine falsche Korrektur zur Folge haben.
Der Abschnittsoverhead sollte ebenfalls nicht von FEC-Blöcken überdeckt werden, wenn eine Fähigkeit "Verbindungsabschlusselement zu Verbindungsabschlusselement" gewünscht wird. Zum Beispiel kann Abschnittsoverhead an Regeneratoren (z.B. Abschnittsabschlusselementen) überschrieben werden, was falsche Korrekturen verursachen könnte, wenn FEC-Blöcke diese überschriebenen Bytes überdecken würden. Folglich müssten, wenn eine Abschnittsoverhead-Zeile von einem FEC-Block überdeckt würde, Regeneratoren immer FEC-Decodierung und -Codierung sicherstellen, was eine zusätzliche Verzögerung verursachen würde. Abschnittsoverhead kann daher wie folgt behandelt werden.
Bei einer der Veranschaulichung dienenden Ausführungsform wird angenommen, dass die Abschnittsoverhead-Bytes für die Zeilen 1-3 für die Zwecke der FEC-Codierung und -Decodierung null sind. Das heißt, für jedes FEC-Korrekturbit, das den Abschnittsoverhead-Bytes entspricht, wird eine null zugeordnet. Daher kann ein Regenerator einfach die FEC-Korrekturbytes und auch das FEC-Startbyte, die umgeordneten Z0-Bytes und die FEC BIP-8 Bytes durchlaufen lassen, ohne irgendeine FEC-Codierung oder Kompensation des B2-Bytes auszuführen. Obwohl bei Anwendung dieser Vorgehensweise Fehler im Abschnittsoverhead nicht korrigiert werden, wird eine zusätzliche Verzögerung vermieden, welche andernfalls infolge einer FEC-Decodierung und -Codierung an Regeneratoren auftreten würde.
Bei manchen Anwendungen kann es wünschenswert sein, dass FEC-Blöcke wegen der Umordnungen nicht die B2- und Z0-Bytes und die S0-Bits überdecken. Es wird angenommen, dass die B2-Bytes sowohl für die FEC-Codierung als auch für die FEC-Decodierung null sind. Diese Implementierung dient dazu, einige Rückführungswege von B2, nachdem es kompensiert worden ist, für die FEC-Berechnungsfunktion zu eliminieren. Die Z0-Bytes (Zeile 1) und S0-Bits (Zeile 4) werden umgeordnet, um die Inhalte zu erhalten, wie oben beschrieben wurde. Daher überschreiben in der Empfangsrichtung die erhaltenen Werte, welche nicht korrigiert werden, die Z0- und S0-Inhalte.
Es wird angenommen, dass die FEC BIP-8 Bytes vom Standpunkt der Codierung und Decodierung aus ebenfalls null sind, da FEC BIP-8 verwendet wird, um zu bestimmen, ob eine Korrektur ausgeführt werden soll oder nicht. Somit werden in der Empfangsrichtung die FEC BIP-8 Bytes vor der FEC-Decodierung und Korrektur verarbeitet. Folglich wird durch Korrigieren. der FEC BIP-8 Paritätsbytes kein Wert hinzugefügt.
Ähnliche Ausnahmen können für die Anwendung eines Vorwärtsfehlerkorrekturschemas auf andere Typen von Signalen notwendig sein, in Abhängigkeit von betrieblichen oder die Signalstruktur betreffenden Einschränkungen, die für das jeweilige Signal spezifisch sind. Demzufolge können Verfahren, welche den oben beschriebenen ähnlich sind, angewendet werden, um die Vorgehensweise bei der Abbildung und die Anwendung von Vorwärtsfehlerkorrektur für eine gegebene Signalstruktur in Abhängigkeit von den jeweiligen Ausnahmen zu modifizieren. Es ist außerdem anzumerken, dass die oben beschriebenen Verfahren nur als der Veranschaulichung dienend und nicht als einschränkend anzusehen sind. Zum Beispiel kann eine Vorgehensweise "alles Einsen" anstelle einer Vorgehensweise "alles Nullen" angewendet werden.
Gemäß einem anderen Aspekt der Erfindung kann Vorwärtsfehlerkorrektur auch auf der Basis anderer Kriterien oder Ereignisse freigegeben und gesperrt werden. Zum Beispiel kann Vorwärtsfehlerkorrektur auf der Basis des Wertes des FEC-Startbytes, von Defekten der Einrichtung, der Anzahl der FEC BIP-8 Fehler, von FEC Syndrom-Fehlern, von Hardware-/Softwarebefehlen und ähnlichem freigegeben/gesperrt werden. Neben anderen Vorteilen kann eine wohlüberlegte Steuerung der Vorwärtsfehlerkorrektur gemäß den Prinzipien der Erfindung daher Fehlkorrekturen verhindern, z.B. Fehlermultiplikationen, und die Genauigkeit der Leistungsüberwachungs-Zählung verbessern.
Das Minimieren der Verzögerung in einem Vorwärtsfehlerkorrekturschema ist für viele SONET-Anwendungen eine wesentliche Überlegung. Zum Beispiel erfordert eine virtuelle Verkettung, welche eine Möglichkeit ist, um viele STS-1-Signale als eine Gruppe zu behandeln, ohne sie als ein zusammenhängendes Bündel zu transportieren, eine minimale Verzögerungsdifferenz zwischen den STS-1-Signalen. Schutzumschaltung ist eine weitere Anwendung, welche sehr empfindlich gegenüber Verzögerungen ist. Zum Beispiel müssen Umschaltentscheidungen in Schemata der hardwarebasierten Schutzumschaltung und schlupflosen Schutzumschaltung (Hitless Protection Switching) mit minimaler Verzögerung getroffen werden. Manche Schutzumschaltungsschemata, wie etwa bidirektionale leitungsgeschaltete Ringe, erfordern ein Handshaking-Protokoll, welches in den K1/K2-Bytes des SONET-Overheads transportiert wird. Folglich müssen diese Bytes so schnell wie möglich zwischen den Netzelementen gesendet werden. Wenn sich die Laufzeit erhöht, dauert die Übertragung der K1/K2-Bytes länger, und somit ergeben sich längere Umschaltzeiten. In Anbetracht dieser und anderer verzögerungsempfindlicher Anwendungen kann das Abbildungsschema gemäß den Prinzipien der Erfindung vorteilhaft angewendet werden, um extrem geringe Verzögerungen zu erzielen und dabei gleichzeitig die Gesamt-Bitfehlerratenleistung eines Systems zu verbessern.
Gemäß einem anderen Aspekt der Erfindung wird eine "bereitstellbare" Vorwärtsfehlerkorrektur-Fähigkeit bereitgestellt, bei welcher eine Vorwärtsfehlerkorrektur-Verarbeitung auf der SONET-Abschnittsschicht oder der SONET-Verbindungsschicht erfolgen kann, in Abhängigkeit von der Anwendung. Zum Beispiel kann eine Vorwärtsfehlerkorrektur-Verarbeitung auf der Verbindungsschicht vorteilhaft sein, wenn die Gesamt-Netzverzögerung die wesentlichste Überlegung ist. Wenn zum Beispiel eine Verarbeitung auf der Verbindungsschicht gemäß den Prinzipien der Erfindung erfolgt, wird eine Durchgangsfunktion an Regeneratoren angewendet, wodurch die Vorwärtsfehlerkorrekturbytes in den ersten drei Zeilen eines SONET-Rahmens durchlaufen gelassen werden. Umgekehrt kann eine Vorwärtsfehlerkorrektur-Verarbeitung auf der Abschnittsschicht vorteilhaft sein, wenn die Gesamt-Netzverzögerung nicht so wichtig ist wie das Erreichen der niedrigsten möglichen Bitfehlerrate.
Die hier dargestellten und beschriebenen Ausführungsformen für die Abbildung von Vorwärtsfehlerkorrektur auf einer zeilenweisen Basis kann in Vorrichtungen und Systemen unter Anwendung von Verfahren implementiert werden, welche dem Fachmann wohlbekannt sind. Zum Beispiel kann das Abbildungsschema der Vorwärtsfehlerkorrektur in einem anwendungsspezifischen Schaltkreis (ASIC) unter Anwendung der VLSI-Technologie für ein SONET- oder SDH-End-Netzelement implementiert werden.
Es versteht sich, dass die oben beschriebenen speziellen Ausführungsformen und Anwendungen nur der Veranschaulichung der Prinzipien der Erfindung dienen. Fachleute können für andere Signalstrukturen und Übertragungsgeschwindigkeiten andere geeignete Implementierungen entwickeln, ohne den Schutzbereich der hier dargelegten Lehren zu verlassen. Zum Beispiel können die Prinzipien der Erfindung für andere SONET- und SDH-Signalraten als STS-192/STM-64 verwendet werden, indem die Abbildungspositionen für die verschiedenen FEC-Korrekturbits und bitverschachtelten Paritätsbits im Einklang mit den Lehren dieser Erfindung modifiziert werden. Ferner können die Prinzipien der Erfindung auf einen beliebigen Typ von Signalstruktur angewendet werden, welcher eine zeilenweise Abbildung von Vorwärtsfehlerkorrektur begünstigt, um die Bitfehlerratenleistung zu verbessern, bei gleichzeitiger Minimierung der Speicheranforderungen und der zugehörigen Verzögerung. Dementsprechend wird der Schutzbereich der Erfindung nur durch die nachfolgenden Ansprüche begrenzt.

Claims

Verfahren zum Verbessern der Bitfehlerratenleistung eines optischen Übertragungssystems, wobei ein von dem System geliefertes Signal mehrere Signalrahmen (100) umfaßt, wobei jeder Signalrahmen eine vorbestimmte Anzahl von Zeilen aufweist, gekennzeichnet durch die folgenden Schritte: Einfügen einer vorbestimmten Anzahl von Vorwärtsfehlerkorrekturbyte (205, 300) in vorbestimmte Overheadbytes (101) in einem Signalrahmen (100) zeilenweise; und Erkennen und Korrigieren von Fehlern in dem Signalrahmen zeilenweise durch Verarbeiten der jeder Zeile entsprechenden Vorwärtsfehlerkorrekturbyte (205, 300).
Verfahren nach Anspruch 1, ferner mit dem folgenden Schritt: Partitionieren jeder Zeile in einem Signalrahmen in eine vorbestimmte Anzahl von Segmenten, wobei für jedes Segment in einer Zeile eine vorbestimmte Anzahl von Vorwärtsfehlerkorrekturbyte (205, 300) gelten.
Verfahren nach Anspruch 1 oder Anspruch 2, ferner mit dem Schritt des Speicherns ungefähr einer Zeile des Signalrahmens vor der Verarbeitung der Vorwärtsfehlerkorrekturbyte in einer Zeile.
Verfahren nach Anspruch 2, wobei die vorbestimmte Anzahl von Segmenten vier ist, so daß jedes Segment ungefähr ein Viertel einer Zeile von Daten repräsentiert.
Verfahren nach Anspruch 4, wobei die vorbestimmte Anzahl von Vorwärtsfehlerkorrekturbyte vier beträgt.
Verfahren nach einem der Ansprüche 2, 4 oder 5, wobei jedes Segment ungefähr 34.560 Bit umfaßt.
Verfahren nach einem der Ansprüche 2, 4 oder 5, wobei für eine bestimmte Zeile in dem Signalrahmen der Schritt des Einfügens der Vorwärtsfehlerkorrekturbyte umfaßt, die Vorwärtsfehlerkorrekturbyte zeilenweise in mindestens eine Bitposition einer nachfolgenden Anzahl von Overheadbyte (500, 501, 600, 601) einzufügen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Vorwärtsfehlerkorrekturbyte in einer bestimmten Zeile für die Daten in der unmittelbar vorhergehenden Zeile in dem Signalrahmen gelten.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das optische Übertragungssystem ein System ist, das aus der Gruppe bestehend aus einem auf SONET basierenden System und einem auf SDH basierenden System ausgewählt wird.
Verfahren nach Anspruch 9, wobei das Signal aus der Gruppe bestehend aus einem STS-192-Signal und einem STM-64-Signal, die beide mit einer Übertragungsrate von ungefähr 10 Gb/s arbeiten, ausgewählt wird.
Verfahren nach Anspruch 2, ferner mit dem Schritt des Einfügens von Fehlerdetektionsbyte (325-329) in vorbestimmte Overheadbyte des Signalrahmens zeilenweise, wobei eine vorbestimmte Anzahl von Fehlerdetektionsbyte für jedes Segment in einer Zeile gelten.
Verfahren nach Anspruch 11, wobei die Fehlerdetektionsbyte (325-329) verarbeitet werden, um eine Gesamtzahl von Fehlern in jedem Segment zu erkennen, und wobei Vorwärtsfehlerkorrekturverarbeitung zeilenweise als Funktion der Anzahl der in einer Zeile erkannten Fehler freigegeben und gesperrt wird.
Verfahren nach Anspruch 12, wobei, wenn die Gesamtzahl der erkannten Fehler eine vorbestimmte Schwelle übersteigt, Vorwärtsfehlerkorrekturverarbeitung gesperrt wird, um falsche Korrekturen zu vermeiden, und wobei die Gesamtzahl der erkannten Fehler kleiner oder gleich der vorbestimmten Schwelle ist, die Vorwärtsfehlerkorrekturverarbeitung freigegeben wird.
Verfahren nach Anspruch 13, wobei die Fehlerdetektionsbyte bitverschachtelte Paritätsbyte umfassen.
Verfahren nach Anspruch 11, ferner mit dem Schritt des Kompensierens bestimmter Overheadbyte, um Paritätsänderungen zu berücksichtigen, die sich aus dem Einfügen der Vorwärtsfehlerkorrekturbyte und dem Einfügen der Fehlerdetektionsbyte ergeben.
Verfahren nach Anspruch 2, ferner mit den folgenden Schritten: Einfügen eines Vorwärtsfehlerkorrektur-Startbyte (400) in ein vorbestimmtes Overheadbyte in dem Signalrahmen; und Freigeben und Sperren der Vorwärtsfehlerkorrekturverarbeitung als Funktion des Werts des Startbyte.
Verfahren nach Anspruch 2, ferner mit den folgenden Schritten: Umordnen von Overheadbyte in gewählten Zeilen in dem Signalrahmen, um deren Inhalt zu erhalten, wobei der Schritt des Umordnens das Kopieren und Verschieben von Inhalten von Overheadbyte zwischen gewählten Zeilen in dem Signalrahmen vor dem Einfügen der Vorwärtsfehlerkorrekturbyte in die gewählten Zeilen umfaßt; und Kompensieren bestimmter Overheadbyte, um Paritätsänderungen zu berücksichtigen, die sich aus der Umordnung der Overheadbyte in gewählten Zeilen ergeben.
Verfahren nach Anspruch 2, wobei die Vorwärtsfehlerkorrekturbyte entsprechend jedem der Segmente in einer Zeile in den vorbestimmten Overheadbyte bitverschachtelt werden, wobei jedes Vorwärtsfehlerkorrekturbyte Vorwärtsfehlerkorrekturbit aus jedem der Segmente in der Zeile enthält, so daß mehrere zusammenhängende Fehler in einer Zeile des Signalrahmens erkennbar und korrigierbar sind.
Verfahren nach Anspruch 7, wobei Vorwärtsfehlerkorrekturverarbeitung in einer Sektionsschicht oder in einer Linienschicht selektiv freigegeben und gesperrt werden kann.
Vorrichtung zum Verbessern der Bitfehlerratenleistung eines optischen Übertragungssystems, wobei die Vorrichtung Mittel zum Ausführen der Schritte des Verfahrens nach einem der vorhergehenden Ansprüche umfaßt.