DE60203690T2

DE60203690T2 - Verfahren und Vorrichtung zur Übertragung eines SDH/SONET Client-Signals als Dienstleistung

Info

Publication number: DE60203690T2
Application number: DE60203690T
Authority: DE
Inventors: Manfred Alois Loeffler; Jan Hendrik Steinvoort; Oliver Tamm
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 2002-02-12
Filing date: 2002-02-12
Publication date: 2006-03-02
Anticipated expiration: 2022-02-13
Also published as: DE60203690D1; US7324563B2; EP1335514A1; US20030152079A1; EP1335514B1

Description

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Transport von SDH/SONET-Client-Signalen als einen Dienst, wobei das zugeordnete SDH/SONET-Client-Nutzsignal in ein SDH/SONET-Serversignal eingebettet ist.
Es ist allgemein bekannt, daß in Systemen und/oder Netzwerken, die den derzeitigen SDH- und SONET-Standards entsprechen, insbesondere gemäß der Signale auf der Basis von SDH (Synchron-Digital-Hierarchie) und/oder SONET (Synchrones Optisches Netzwerk) betreffenden internationalen Telekommunikationsunion ITU, das Multiplexen und Demultiplexen solcher Signale auf die in diesen SDH/SONET-Signalen integrierten Nutzsignaldaten beschränkt ist. Die Overhead-Daten, die Informationen insbesondere bezüglich Wartung und Multiplexschutz führen, werden also immer durch die in den jeweiligen Netzwerkelementen implementierte assoziierte Abschnittsabschlußfunktion abgeschlossen.
Die Wartungs- und Schutzfähigkeiten werden folglich auf die jeweiligen Abschnitte, in denen sie geführt werden, beschränkt, insbesondere den optischen Abschnitt, den Regeneratorabschnitt und/oder den Multiplexabschnitt, nicht aber entlang dem Dienstweg selbst.
Ein Funktionalmodell eines SDH/SONET-Multiplexers gemäß diesem bekannten Stand der Technik mit Standard-SDH/SONET-Abschlüssen ist zum Beispiel in der angefügten 10 gezeigt. Daraus ist zu sehen, daß für jeden Standardport 1 bis "n" die optische, die Regenerator- und die Multiplex-Abschnittsschicht der SDH/SONET-Signale immer durch die Abschlußfunktionen des assoziierten standardmäßigen optischen Abschnitts OS, Regeneratorabschnitts RS bzw. Multiplexabschnitts MS abgeschlossen werden. Die Konnektivität auf der Basis der Verbindungsfunktionen für STS/VC (S3/S4) und der transparente Transport von Daten werden deshalb auf das Nutzsignal des VC/STS (Virtueller Behälter/Synchrones Transportsignal) beschränkt, das in den Serversignalen von Trägern, insbesondere in optischen Trägern, eingebettet wird.
Ein Nachteil dieser Architektur ist jedoch, daß SDH/SONET-Systeme nicht in der Lage sind, die SDH/SONET-Signale als einen Dienst, insbesondere als einen Ende-zu-Ende-Dienst, zu transportieren. Ende-zu-Ende-Dienste über SDH/SONET-Netzwerke sind bekanntlich immer auf das assoziierte Nutzsignal beschränkt.
Mit Bezug auf die übliche Anwendung gemäß dem bekannten Stand der Technik zeigt 11 darüberhinaus eine Trägeranwendung mit gemeinsamen Trägern auf der Basis von SDH/SONET im Stand der Technik und alle optischen Übertragungslösungen. Gemäß der abgebildeten beispielhaften Anwendung besitzt ein städtischer Netzwerkbetreiber zwei städtische SDH/SONET-Netzwerke N_CA, die über einen zweiten Betreiber verbunden sind, der ein Kernnetzwerk N_CC besitzt, das aus SDH/SONET-Netzwerkelementen 10 und aus Geräten 20 für optischen Crossconnect und/oder DWDM (dichter Wellenlängenmultiplex) besteht. Die städtischen Netzwerke N_CA bestehen lediglich aus SDH/SONET-Geräten 10, insbesondere einem SONET/SDH-Crossconnect und/oder Add/Drop-Multiplexernetzwerkelementen 10.
Da die Signale in dem Träger-Trägernetzwerk N_CC mindestens an den Weiterreichungspunkten 202 zwischen den jeweiligen Netzwerken Standard-SDH/SONET-Geräte 10 überqueren müssen, ist nur SDH/SONET-Nutzsignalkonnektivität zwischen den beiden städtischen Netzwerken N_CA möglich. Folglich sind die beiden Netzwerke N_CA im Hinblick auf Netzwerkverwaltung und Anschlußschutzschemata Inseln. Da der Betreiber des städtischen Netzwerks N_CA nur SDH/SONET-Geräte 10 verwendet, ist der Dienst, den er zwischen den jeweiligen Dienstschnittstellen 201 anbieten kann, darüberhinaus auch nur auf SDH/SONET-Nutzsignale beschränkt, gleichgültig, ob der Dienst das Träger-Trägernetzwerk N_CC überqueren muß oder nicht.
Die Notwendigkeit, auch die SDH/SONET-Signale selbst als einen Dienst zu transportieren, wird also vorhergesagt und bereits stark von mehreren Netzwerkbetreibern angefordert. Ein Ansatz, um dies zu unterstützen, könnte deshalb die Einführung einer separaten optischen Schicht sein, wodurch jedoch der Nachteil entsteht, daß die völlig neue Produktfamilie eingeführt wird.
Auch wenn das Träger-Trägernetzwerk N_CC in ein gänzlich optisches Netzwerk verwandelt wird, wie in 12 gezeigt, d.h. lediglich optische Crossconnect- und/oder DWDM-Geräte 20 aufweist, die die SDH/SONET-Signale, die die SDH/SONET-Overhead-Daten enthalten, transportieren können, können die beiden städtischen Netzwerke N_CA darüberhinaus immernoch keine SDH/SONET-Signale als einen Ende-zu-Ende-Dienst zwischen den Dienstschnittstellen 201 anbieten, weil die Standard-SDH/SONET-Crossconnect- und/oder Add/Drop-Multiplexgeräte 10 verwendet werden. Der Betreiber der städtischen Netzwerke N_CA erhält jedoch die Möglichkeit, die beiden Netzwerkinseln N_CA im Hinblick auf Netzwerkverwaltungs- und Anschlußschutzschemata zu verbinden, wenn das Träger-Trägernetzwerk N_CC ein solches gänzlich optisches Netzwerk gemäß 12 einführt, und erhält keine Vorteile mehr aus dem auf SDH/SONET basierenden Netzwerk N_CC (siehe 11).
Zusätzlich zu diesen oben erwähnten Träger-Trägerproblemen existiert ferner ein weiteres sehr wichtiges Problem bei traditionellen SDH/SONET-Systemen bei der transozeanischen Übertragung. Es ist allgemein bekannt, daß transozeanische Übertragungssysteme Standard-SDH/SONET-Rahmensignale als Eingabe benötigen, die in einen proprietären Rahmen verpackt werden, der Verfahren für sehr starke Vorwärtsfehlerkorrektur (FEC) enthält, wodurch diese ohne Notwendigkeit der Signalregeneration über sehr große Distanzen übertragen werden können. Der Umstand, daß die Bandbreite pro Lambda auch die Kosten der transozeanischen Übertragung bestimmt, drängt transozeanische Systeme jedoch in die Richtung von 10 Gigabit Übertragung pro Lambda. Andererseits besteht auf dem Markt ein großer Bedarf, transparente 2,5-Gigabit-SDH/SONET-Dienste über den Ozean zu unterstützen.
Das vorbekannte Verfahren zur Unterstützung von transparenten 2,5-Gigabit-Diensten besteht jedoch darin, 4 mal 2,5 G-SDH/SONET-Signale proprietär heraufzumultiplexen und dieses 10 G-Signal dann einschließlich zusätzlicher hinzugefügter FEC zu verpacken, um dieses Signal auf ein Lambda zu legen. Da das 10 G-Ausgangssignal jedoch nicht mit einem 10 G-SDH/SONET-Signal kompatibel ist, besteht keine Möglichkeit zum Transport dieses Signals über transozeanische Systeme.
Eine Aufgabe der Erfindung besteht deshalb darin, in bezug auf den Stand der Technik einen neuen und verbesserten Ansatz zum Transport von SDH/SONET-Signalen bereitzustellen, der den Transport von SDH/SONET-Signalen als einen Dienst, einschließlich Nutzsignal und Overhead-Informationen, ermöglicht.
Aus dem US-Patent US-B1-6169754 ist ein Verfahren zum Transport von SDH/SONET-Client-Signalen als einen Dienst bekannt, mit dem Schritt des Einbettens des zugeordneten SDH/SONET-Client-Nutzsignals in ein SDH/SONET-Serversignal und weiterhin mit den folgenden Schritten:

– Abbilden von Overhead-Informationen des mindestens einen SDH/SONET-Client-Signals in das SDH/SONET-Serversignal, wobei die Client- Overhead-Informationen des mindestens einen SDH/SONET-Client-Signals in freie Overhead-Positionen des SDH/SONET-Serversignals abgebildet werden, und
– Transportieren des SDH/SONET-Serversignals mit den Nutzsignalinformationen und den abgebildeten Client-Overhead-Informationen des mindestens einen darin eingebetteten SDH/SONET-Client-Signals.

Die vorliegende Erfindung ist gegenüber der Offenlegung von US-B1-6169754 dadurch gekennzeichnet, daß vor dem Schritt des Abbildens eine Datenratenanpassung bestimmter SDH/SONET-Client-Overhead-Informationen durchgeführt wird, um die Aufrechterhaltung des logischen Inhalts davon sicherzustellen, wobei die bestimmten SDH/SONET-Client-Overhead-Informationen Byte des Datenkommunikationskanals (DCC) führen, die HDLC-Rahmen führen, wobei die Datenratenanpassung durchgeführt wird, indem Idle/Flag-Byte der HDLC-Rahmen gemäß den folgenden Regeln eingefügt oder gelöscht werden:

– ein Flat-Byte kann direkt vor oder direkt nach einem einzigen Flag eingesetzt werden,
– ein Idle-Flag kann direkt vor oder direkt nach einem anderen Idle-Flag-Byte oder direkt zwischen zwei Flags eingefügt werden,
– ein Flag kann entfernt werden, wenn ihm direkt ein anderes Flag vorausgeht oder folgt und
– ein Idle-Flag kann immer entfernt werden.

Die erfindungsgemäße Lösung wird durch ein Verfahren gemäß Anspruch 1 erreicht.
Vorteilhafte und/oder bevorzugte Ausführungsformen oder Verbesserungen sind der Gegenstand der jeweiligen abhängigen Ansprüche.
Gemäß der Erfindung wird vorgeschlagen, assoziierte Nutzsignaldaten oder Informationen und gewählte assozierte Overhead-Daten oder Informationen mindestens eines in ein SDH/SONET-Serversignal zu transportierenden SDH/SONET-Client-Signals abzubilden, wobei die Client-Overhead-Informationen des mindestens einen SDH/SONET-Client-Signals in freie Overhead-Positionen dieses SDH/SONET-Serversignals abgebildet werden, und dieses SDH/SONET-Serversignal mit dem mindestens einen SDH/SONET-Client-Signal einschließlich darin eingebetteter assoziierter Nutzsignal- und Overhead-Informationen zu transportieren.
Da das SDH/SONET-Serversignalformat nicht geändert werden muß, kann die erfindungsgemäße Funktionalität also in SDH/SONET-Systeme integriert werden, ohne das grundlegende Übertragungskonzept zu ändern, und daher ermöglicht der erfindungsgemäße Ansatz den Transport von SDH/SONET-Client-Signalen als einen transparenten oder nativen Dienst sogar über existierende transozeanische Systeme, die Standard-SDH/SONET-Rahmensignale erforderten.
Gemäß einer bevorzugten Verfeinerung der Erfindung umfaßt die Abbildung von Overhead-Daten oder -Informationen folglich das Routen mindestens von Overhead-Informationen für Wartungs-, Verwaltungs- und Schutzzwecke des mindestens einen Client-Signals durch eine STS-VC-Querverbindungsmatrix zur weiteren Verbesserung einer leichten Integration in existierende SDH/SONET-Netzwerkelementkonzepte.
Da jedoch eine Standardisierung davon in den SDH/SONET-Standards nicht gegeben wird, wird weiter vorgeschlagen, Overhead-Positionen des mindestens einen Client-Signals zu wählen, wobei die Positionen spezifische Standard-Overhead-Informationen umfassen, und solche spezifischen Standard-Overhead-Informationen der gewählten Positionen auf bestimmbare Client-Overhead-Positionen des jeweiligen assoziierten Client-Nutzsignals abzubilden, um ein solches angepaßtes Client-Nutzsignal in das SDH/SONET-Serversignal zu multiplexen. Vorteilhafterweise ermöglicht dieser Ansatz physisch eine Verwendung derselben, auf Spalten basierenden Crossconnectfuktion zum Verbinden sowohl von STS/VC-Nutzsignal- als auch von SDH/SONET-Client-Signalen.
Insbesondere wird in asynchronen Netzwerkumgebungen vorzugsweise eine Zeitsynchronisation und/oder Datenratenanpassung bestimmter SDH/SONET-Client-Overhead-Daten oder -Informationen vor dem Schritt des Abbildens durchgeführt, um die Aufrechterhaltung des logischen Inhalts davon und daher einen reibungslosen Betrieb über Zeitsteuerungsdomänen hinweg sicherzustellen.
Folglich wird das erfindungsgemäße Verfahren vorzugsweise insofern realisiert, als der Schritt des Abbildens der gewählten Client-Overhead-Informationen am Eingang eines Netzwerks mittels Multiplexen der Overhead-Informationen in ein Serversignal mit einer höheren Bitrate im Vergleich zu dem mindestens einen Client-Signal durchgeführt wird, sodaß die Client-Overhead-Informationen transparent in Serversignal-Overhead-Positionen transportiert werden können, die von den Standards nicht definiert werden, sodaß sichergestellt wird, daß an einem Ausgang eines Netzwerks die abgebildeten Client-Overhead-Informationen zumindest teilweise verarbeitet und in die jeweiligen definierten Standard-Overhead-Positionen mindestens eines SDH/SONET-Client-Signals zurück abgebildet werden können.
Gemäß einer weiteren bevorzugten Verfeinerung der Erfindung wird vorgeschlagen, die transparente SDH/SONET-Signaltransportfunktionalität zusammen mit Transportfunktionen auf SDH/SONET-Nutzsignalbasis in einem Netzwerkelement zu kombinieren, um insbesondere den Abschluß von in das Serversignal eingebetteten SDH/SONET-Client-Overhead-Informationen zu ermöglichen und daher einen Kunden dabei zu unterstützen, durch die verursachte Verringerung der Komplexität die Gerätekosten zu verringern.
Bezüglich einer bevorzugten erfindungsgemäßen Vorrichtung, die insbesondere als ein Netzwerkelement ausgelegt wird, das zur Verwendung für das erfindungsgemäße Verfahren angepaßt wird, wird vorgeschlagen, eine Add/Drop-Multiplexereinheit zu integrieren, die folgendes umfaßt: Mittel zum Querverbinden von Overhead-Informationen eines SDH/SONET-Client-Signals in einem SDH/SONET-Serversignal, ein Client-Portmittel zum Eintreten in und/oder Verlassen von SDH/SONET-Client-Signalen, die transparent transportiert werden müssen, ein Server-Portmittel für ein SDH/SONET-Serversignal mit mindestens einem eingebetteten Client-Signal und/oder Mittel zur Durchführung von Querverbindungen für Entitäten jeweils derselben logischen Schicht.
Weiterhin wird vorgeschlagen, das Netzwerkelement durch folgendes anzupassen: Mittel zum selektiven oder teilweisen Abschließen der Overhead-Informationen des SDH/SONET-Client-Signals, das in dem Serversignal eingebettet werden soll, Mittel zum zeitlichen Synchronisieren und/oder Anpassen der Datenrate der selektiv oder teilweise abgeschlossenen SDH/SONET-Client-Overhead-Informationen und/oder Mittel zum Multiplexen der selektiv oder teilweise abgeschlossenen Overhead-Informationen in vorzugsweise ein Serversignal mit höherer Rate, um sicherzustellen, daß die integrierten SDH/SONET-Client-Overhead-Informationen transparent oder nativ transportiert und an einem Netzwerkausgang demultiplexiert werden können.
Darüberhinaus wird gemäß den bevorzugten Verfeinerungen vorzugsweise vorgeschlagen, ein Netzwerkelement bereitzustellen, das folgendes umfaßt: Mittel zum Abschließen von SDH/SONET-Client-Overhead-Informationen, die in ein SDH/SONET-Signal eingebettet sind, und/oder Mittel zum Erkennen der Struktur eines empfangenen Serversignals mit eingebetteten SDH/SONET-Client-Overhead-Informationen insbesondere auf der Basis eines durch Zeigerbyte identifizierten Verkettungsschemas. Darüberhinaus wird ein Implementierungssoftwareprodukt vorgeschlagen, das für die Verwendung mit dem erfindungsgemäßen Verfahren ausgelegt ist und insbesondere in dem oben erwähnten Netzwerkelement implementiert wird.
Durch die Integration des erfindungsgemäßen transparenten Transports von SDH/SONET-Signalen und/oder -Rahmen als einen Dienst einschließlich Nutzsignal- und Overhead-Informationen in existierende SDH/SONET-Systeme und -Systemkonzepte und aufgrund der Möglichkeit der Koexistenz mit standard-entsprechenden SDH/SONET-Nutzsignal-Dienstfunktionen wird also ein signifikanter Wert zu diesen Netzwerken und/oder Systemen hinzugefügt. Da eine Änderung des Server- oder Serverleitungssignalformats vermieden wird, wird das Multiplexen von SDH/SONET-Signalen und/oder -Rahmen in SDH/SONET-Signale mit höherer Bitrate und der Transport dieser SDH/SONET-Signale mit höherer Bitrate über existierende transozeanische Systeme des Stands der Technik ermöglicht, während das Abbilden von Funktionalität der zusätzlichen transportierten Overhead-Informationen mit existierenden SDH/SONET-Regeneratoren, transozeanischen Systemen und standardisierten Mehrbit-Vorwärtskorrekturansätzen kompatibel ist. Auf der Basis der leichten Integration in existierende SDH/SONET-Netzwerkelemente werden zusätzlich Faserkomponenten gespart, insbesondere in kooperierenden Doppelringanwendungen, und der Gewinn des Handhabens der neuen Funktionalität als ein zusätzlicher Dienst wird ermöglicht.
Die Erfindung wird im folgenden ausführlicher auf der Basis bevorzugter Ausführungsformen und in bezug auf die beigefügten Zeichnungen beschrieben. Es zeigen:
1 schematisch ein SDH/SONET-Funktionalmodell von Transparenz auf Netzwerkelementebene gemäß der Erfindung,
2 schematisch einen transparenten optischen Gesamtkern der SDH/SONET-Träger-Trägervernetzung gemäß der Erfindung,
3 schematisch eine transparente SDH/SONET-Träger-Trägervernetzung über einen gemischten transparenten SDH/SONET- und optischen Kern gemäß der Erfindung,
4 schematisch ein System-Architekturblockschaltbild gemäß der Erfindung,
5a, 5b ein Beispiel für den erfindungsgemäßen Abbildungsansatz in STM-64/STS-192-Serversignale,
6a, 6b ein weiteres Beispiel für den erfindungsgemäßen Abbildungsansatz in STM-256/STS-768-Serversignale,
7a, 7b und 7c bevorzugte Beispiele für erfindungsgemäße Multiplexschemata,
8a die Funktionalität eines transparenten Multiplexens mit einem getrennten Add/Drop-Multiplexer gemäß der Erfindung,
8b die Kombination der Funktionalität des transparenten Multiplexens und des Add/Drop-Multiplexens,
9 schematisch eine Anwendung der erfindungsgemäßen TADM/TMUX-Funktionalität gemäß der Erfindung,
10 schematisch ein Standard-SONET/SDH-Übertragungsfunktionalmodell,
11 schematisch eine SDH/SONET-Träger-Trägervernetzung über SDH/SONET und optischen Kern gemischt gemäß dem Stand der Technik und
12 schematisch einen optischen Gesamtkern der SDH/SONET-Träger-Trägervernetzung gemäß dem Stand der Technik.
Zuerst Bezug nehmend auf 1, worin schematisch ein bevorzugtes Funktionalmodell der erfindungsgemäßen transparenten Transportfunktionalität auf der Ebene eines Netzwerkelements gezeigt ist, werden drei Arten von Ports als ein Standardport, ein Serverport oder ein Client-Port definiert.
Der Porttyp Standard bezieht sich auf Standard-Add/Drop-Multiplexbetrieb und der Server-Porttyp dient für Signale mit höherer Rate, wie zum Beispiel 10 G- oder 40 G-Signale mit den erfindungsgemäß eingebetteten Signalen der Clients. Ein solches SDH/SONET-Signal, das halbtransparent über das SDH/SONET-Netzwerk als ein Ende-zu-Ende-Dienst transportiert werden muß, tritt an dem Client-Port in den Multiplexer ein und verläßt diesen dort. Dieses Signal ist zum Beispiel ein 2,5G- oder eine 10G-Signal.
Die Entitäten, die in 1 mit dem Bezugszeichen OS, RS oder MS identifiziert werden, liefern die Standard-Abschnittabschlußfunktionen, d.h. die Abschlußfunktion OS für den optischen Abschnitt, die Abschlußfunktion RS für den Regeneratorabschnitt und die Abschlußfunktion MS für den Multiplexabschnitt. Mit dem Client-Port werden ein angepaßter Client-Regeneratorabschnitt RS'' und eine angepaßte Client-Multiplexabschnittsentität M5'' zur Durchführung nur eines teilweisen Abschlusses des Overheads des SDH/SONET-Signals implementiert. Für bevorzugte Anwendungen wird der Client-Regeneratorabschnitt RS'' für den Overhead-Abschluß der Byte B1, NU_RS vorgesehen, und die Client-Multiplex-Abschnittsentität MS'' wird für den Client-Overhead-Abschluß der Byte S1, NU_MS vorgesehen. Die Overhead-Byte der Client-Overhead-Informationen, die für Verwaltung, Wartung und Schutz wichtig sind, werden also nicht abgeschlossen oder abgeschlossen und neu erzeugt. Diese Overhead-Byte werden aus dem Client-Signal wie nachfolgend ausführlicher beschrieben auf das Serversignal umabgebildet.
Zur weiteren Ermöglichung der Fähigkeit des Multiplexens und Demultiplexens des teilweise abgeschlossenen SDH/SONET-Signals als ein Klient mit einem SDH/SONET-Aggregatserversignal höherer Rate, die weiterhin als TMUX-Funktionalität (transparentes Multiplexen) bezeichnet wird, und zur Ermöglichung der Fähigkeit des Abschließens des MS/RS-Overheads des mindestens einen SDH/SONET-Client-Signals, das in das Serversignal höherer Rate eingebettet ist, das den Dienst führt, und die weiterhin als die TADM-Funktionalität (transparenter ADD/Drop-Multiplexer) bezeichnet wird, wird eine zusätzliche Unterstützungsentitätsschicht eingeführt, durch die die SDH/SONET-Signale in dem Netzwerkelement quer verbunden werden. Wie aus 1 ersichtlich ist, weist diese Unterstützungsschicht vorzugsweise drei Werte auf, d.h. Standard zur Durchführung der Standard ADM-Operation (Add/Drop-Multiplexen) und TMUX oder TADM für die beiden verschiedenen Betriebsarten der transparenten Client-Konnektivität (in bezug auf das synchrone Client-Transportmodul cSTM) durch den Multiplexer mux.
Darüberhinaus werden zum Abschluß der in das Serversignal eingebetteten MS/RS-Client-Overhead-Daten eine Client-Regenerations-Abschnitts-Entität cRS und ein Client-Multiplexerabschnitt cMS zum Zwecke des Verwaltens des Client-Overhead eingeführt, wobei die Entität cRS den Client-Regenerations-Abschnitts-Overhead-Abschluß von (T)DCCR, T(E1), (T)F1 und (T)J0 durchführt und die Entität cMS den Client-Multiplex-Abschnitt-Overhead-Abschluß von (T)DCCM, T(E2), (T)K1, (T)K2, T(M0), T(M1) und T(B2) durchführt. Der Index bzw. das Zeichen "T" identifiziert dadurch die Transparenz der Client-Overhead-Byte.
Das Funktionalmodell gemäß 1 zeigt ferner die Verbindungsfunktionsmittel S3/S4 und Sc2G5/Sc10G zur Bereitstellung des STS/HO-VCs-Nutzsignals oder der SONET/SDH-Client-Signale als separate Entitäten, auch wenn bei einer physischen Implementierung die Verbindungsfunktionsmittel vorzugsweise durch dieselbe Hardware durchgeführt werden.
Im wesentlichen auf der Basis dieses bevorzugten Funktionalmodells von 1 zeigt 2 ein Szenario, bei dem ein städtischer Netzwerkbetreiber seine Netzwerke N_CA oder die jeweiligen integrierten Netzwerkelemente 30 aufrüstet, um so in der Lage zu sein, auch die Overhead-Information der SDH/SONET-Signale mittels Overhead-Transparenz-Funktionalität zu transportieren. Auf der Basis des in 12 gezeigten Standard-Träger-Trägernetzwerks, d.h. mit optischen Crossconnect- und/oder DWDM-Geräten 20, die die SDH/SONET-Signale einschließlich der SDH/SONET-Overhead-Daten, wie in dem Einführungsteil beschrieben, transportieren können, kann der Träger des Netzwerks N_CA nun Ende-zu-Ende-Transparenz anbieten, d.h. transparente oder native SDH/SONET-Dienste zusätzlich zu traditionellen SDH/SONET-Nutzsignaldiensten als Ergebnis der Anpassung der Netzwerkelemente 30, sodaß sie entsprechend SDH/SONET-Querverbindungs- oder Add/Drop-Multiplexerfunktionalität zusammen mit transparenter Querverbindungs- und/oder Multiplexfunktionalität durchführen.
Wenn das Träger-Trägernetzwerk N_CC jedoch nicht auf ein gänzlich optisches Netzwerk aufgerüstet wird, wobei die Netzwerkelemente 20 optische Querverbindungs- und/oder DWDM-Leitungssystemfunktionalität durchführen, können existierende SDH/SONET-Netzwerkelemente 10 des Träger-Trägernetzwerks N_CC (siehe 11) als Alternative zu entsprechenden SDH/SONET-Netzwerkelementen 30 gemäß der Erfindung aufgerüstet werden, um auch Overhead-Transparenz zu unterstützen. In einem solchen Szenario, das in 3 abgebildet ist, können die Kundennetzwerke N_CA durch das Träger-Trägernetzwerk N_CC mit transparenten SDH/SONET-Diensten ausgestattet werden, wodurch bei den Netzwerken N_CA dieselben Vorteile oder Dienste wie in 2 abgebildet möglich werden.
Darüberhinaus ist solche in ein Serversignal integrierte erfindungsgemäße Client-Overhead-Transparenz zu transozeanischen Übertragungssystemen kompatibel, weil das Ausgangssignal ein natives SDH/SONET-Signal ist. Somit kann der erfindungsgemäße Ansatz als 4 mal 2G5-Multiplexfunktionalität für auf 10 G basierende transozeanische Systeme verwendet werden.
Insbesondere wird zur Vereinfachung die RS/MS-Overhead-Transparenz vorzugsweise auf die Overhead-Byte beschränkt, die für Verwaltung, Wartung und Schutz wichtig sind. Für Fachleute ist erkennbar, daß diese Byte in bezug auf die RS-Overhead-Byte folgendermaßen lauten:

Y0: führt eine Abschnittsspurkennung (STI – Section Trace Identifier) in einem 1-, 16- oder 64-Byte-Zeichenkettenformat,
D[1-3]: wird für 192 kbit/s-Datenkommunikations kanäle benutzt,
E1: wird für 64 kbit/s-Ordnung über Kanäle verwendet,
F1: wird für 64 kbit/s-Benutzerkanäle verwendet,

K1/K2: wird für automatische Schutzumschaltung (APS) verwendet,
D[4-12]: wird für 576 kbit/s-Datenkommunikationskanäle benutzt,
E2: wird für 64 kbit/s-Ordnungs-Drahtkanäle verwendet,
B2: wird für die MS-Fehlerüberwachung mit einer BIP-8-N-Parität und N=48 für STS-48/STM-16 und N=192 für STS-192/STM-64 benutzt,
M1: wird für MS-Fernfehleranzeige verwendet und
M0: wird für erweiterte Fernfehleranzeige verwendet.

Um die erfindungsgemäße halbtransparente Multiplexfunktionalität leicht in die grundlegende SDH/SONET-Übertragungsarchitektur zu integrieren, was eine Hauptfrage der bevorzugten Verfeinerungen der Erfindung ist, wird im folgenden eine Systemarchitektur beschrieben, und zwar insbesondere mit Bezug auf 4, worin die Integration von Standard-SDH/SONET- und transparenten Transportfunktionen gemäß der Erfindung vom Systemarchitekturstandpunkt aus gesehen abgebildet ist.
Im allgemeinen wird die Querverbindungsmatrix höherer Ordnung für STS/HO-VC-Nutzsignal durch einen Spaltenschalter in einer SDH/SONET-Multiplexerentität implementiert. Alle Spalten des STS/HO-VC müssen dann durch diesen Schalter geroutet werden, einschließlich der Overhead-Spalten, die die Zeiger-Byte H1/H2/H3 halten. Die RS- und MS-Overheadpositionen, die jedem STS/HO-VC-Nutzsignal zugeordnet sind, werden durch die Matrix zusammen mit dem Nutzsignal geroutet.
Da für ein Standard-SONET/SDH-Multiplexermittel die Overhead-Bytepositionen, die durch den Spaltenschalter geroutet werden, keine Overheaddaten enthalten, da die Overhead-Byte gemäß dem Stand der Technik vor der Matrix abgeschlossen und nicht durch eine Zeigerverarbeitungsfunktion geleitet werden, die das Nutzsignal synchronisiert, um eine Spaltenumschaltung zu ermöglichen, ist das Netzwerkelement vorzugsweise jedoch so ausgelegt, daß es folgendermaßen vorgeht.
Für SONET/SDH-Signale, die als Ende-zu-Ende-SONET/SDH-Client-Signal transportiert werden müssen, werden die Overhead-Byte dieser Clients in die Overhead-Positionen der assoziierten STS-1/VCs dergestalt umabgebildet, daß das Client-Overhead bei dem zugeordneten Nutzsignal erhalten wird, während es durch eine auf Spalten basierende STS/VC-Crossconnectmatrix geroutet wird. Durch diesen bevorzugten Ansatz wird es möglich, physisch dieselbe auf Spalten basierende Crossconnectfunktion zur Verbindung sowohl von STS/VC-Nutzsignalen als auch von Client-SONET/SDH-Signalen zu verwenden.
Praktisch wird am Eingang eines Netzwerks das Standard-Overhead des Clients auf Client-Overhead-Positionen des zugeordneten Nutzsignals abgebildet. Das Multiplexen des Client-Nutzsignals in das Serversignal führt dann dazu, daß das Client-Overhead in dem Overhead des Serversignals enthalten ist, sodaß das Serversignal das Overhead des Client-Signals bzw. der Client-Signale zusätzlich zu dem Overhead des Serversignals selbst führt, wobei die Client-Overhead-Byte in Serversignal-Overhead-Positonen transportiert werden, die nicht von den Standards definiert werden. Die Abbildung eines Standard-Overhead auf ein transparentes Client-Overhead wird so vorgeschlagen, wie es in dem folgenden Diagramm gezeigt ist, worin das Zeichen "T" die transparenten Client-Overhead-Byte identifiziert:
Am Ausgang eines Netzwerks wird das Client-Overhead teilweise verarbeitet und in die Standard-Overhead-Positionen des transparenten Client zurück abgebildet.
Eine bevorzugte Abbildung der Client-Overhead-Daten in dem beispielhaften Overhead von STM-64/STS-192- und STM-256/STS-786-Serversignalen ist in 5a, 5b oder 6a, 6b gezeigt.
Insbesondere zeigen 5a und 5b ein Beispiel für die erfindungsgemäße Abbildung in STM-64/STS-192-Serversignale mit den Overhead-Byte aus 2,5 G-Client-Signalen, die in unbenutzte Byte des Multiplexabschnitts eines 10 G-Transportsignals abgebildet werden, wobei 5a die Client-Overhead-Definitionen und 5b die Abbildung des Client-Overhead in FEC-Blöcken des STM-64/STS-192-Signals ohne jeglichen negativen Einfluß auf die standardisierte Struktur darstellt. Wie oben erwähnt, identifiziert das Zeichen "T" die transparenten Client-Overhead-Byte.
6a und 6b zeigen eine entsprechende beispielhafte erfindungsgemäße Abbildung in STM-256/STS-768-Serversignale, d.h. in 40 G-Serversignale.
Gewöhnlich läuft die lokale Crossconnectfunktion der Standard-SONET/SDH-Multiplexerentität auf einer zentralen Zeitsteuerungsreferenz, um einen Spaltenschalter implementieren zu können, der die verschiedenen STS/VC-Nutzsignale verbindet und zu einem SONET/SDH-Signal multiplext. Da jedoch die in das System eintretenden SONET/SDH-Signale verschiedene Zeitsteuerungsquellen aufweisen können, findet vorzugsweise eine Synchronisation des STS/VC-Nutzsignals in Richtung der Systemzeitsteuerungsreferenz mittels einer Zeigerverarbeitung in der MS-Anpassungsfunktion statt.
Für die Anpassung des RS/MS-Overheads des Client-Signals in Richtung der Systemzeitsteuerungsreferenz sind jedoch keine standardisierten Anpassungsfunktionen verfügbar.
Auf der Basis der Tatsache, daß ein Teil der Overhead-Byte serielle Datenprotokolle enthält, kann eine Implementierung einfacher Byte-Slip/Skip-Mechanismen für diese Byte den logischen Inhalt dieser Daten in asynchronen Netzwerkumgebungen zerstören. Deshalb schlägt die Erfindung bevorzugte besondere Anpassungsalgorithmen für einen Teil der transparent transportierten Overhead-Byte vor.
Zusätzlich werden für Overhead-Byte, die Fehlerzählwerte enthalten, wie zum Beispiel B2 und M0/M1, Algorithmen unterstützt, die sicherstellen, daß Fehlerzählwerte einheitlich durch das Netzwerk weitergeleitet werden und daher logische Transparenz bereitstellen.
Inbesondere werden mit Bezug auf 4 die folgenden Synchronisations- und Anpassungsprotokolle vorzugsweise definiert:
Bezüglich des Overhead-Byte J0. Wie bereits erwähnt, führt J0 eine Abschnittbasiskennung (STI), deren Länge 1, 16 oder 64 Byte betragen kann. Die Länge der STI-Zeichenkette hängt von dem durch den Benutzer bereitgestellten STI-Modus ab. In jedem Rahmen wird ein Byte übertragen. Da eine Slip/Skip-Funktion eines Byte dieser Zeichenkette eine vollständige Zeichenkette unterbrechen kann, wird somit vorzugsweise ein Anpassungsprotokoll für J0 implementiert, das eine Verfälschung der Zeichenkette vermeidet.
Am Eingang des Client-Ports wird das empfangene J0-Byte vorzugsweise mittels eines Protokolls, das aus drei Byte besteht, an die Systemzeitsteuerungsreferenz angepaßt:

– Ein Steuerbyte (C) und zwei Datenbyte (TJ01 und TJO2), wobei
– nominal ein Byte J0-Informationen in jedem Rahmen in TJ01 transportiert wird.
– Wenn ein Rahmen-Slip/Skip vorliegt, wird ein Stopfen der J0-Informationen durchgeführt, indem entweder 0 oder 2 Datenbyte in dem aktuellen Rahmen gesendet werden.
– Wenn zwei Byte gesendet werden, enthalten sowohl TJ01 als auch TJ02 J0-Informationen, wobei
– die Anzahl von durch TJ01/TJ02 transportierten Byte durch das Steuerbyte (C) angegeben wird.

Dann können dazwischenliegende Netzwerkelemente, die Serversignale mit eingebetteten Clients behandeln, die Zeitsteuerungsdifferenz zwischen der empfangenen und lokalen Systemzeitsteuerung berücksichtigen, indem das Client-J0-Protokoll in C/TJ01/TJ02 verarbeitet wird, wobei die Steuerung und Datenbyte vorzugsweise so ausgelegt sind, daß die J0-Informationen einheitlich bleiben.
In der Client-Port-Quellenfunktionsentität wird die C/TJ01/TJ02-Nachricht interpretiert und die ursprüngliche J0-Zeichenkette wird wiederhergestellt und in die J0-Position des Client-Signals eingefügt, auch wenn die J0-Einfügungsrate von der wiederhergestellten Client-J0-Rate verschieden sein kann, da diese Differenz leicht durch Entfernung oder Duplikation einer vollständigen wiederhergestellten STI-Zeichenkette angepaßt werden kann.
Bezüglich der Overhead-Byte DCCR/DCCM. Da die DCC-Byte Verwaltungsinformationen führen und aus in das HDLC-Protokoll eingebetteten Nachrichten bestehen, werden diese HDLC-Protokolle vorzugsweise analysiert, und es können Stopfinformationen hinzugefügt oder entfernt werden.
Es wird vorgeschlagen, diese Schritte durchzuführen, indem Idle/Flag-Byte an den entsprechenden Positionen in dem HDLC-Rahmen gemäß den folgenden Regeln eingefügt oder gelöscht werden:

– Ein Flag-Byte kann vor oder nach einem einzigen Flag eingefügt werden,
– ein Idle-Flag kann vor oder nach einem anderen Idle-Flag-Byte oder zwischen zwei Flags eingefügt werden,
– ein Flag kann entfernt werden, wenn ihm ein anderes Flag vorausgeht oder folgt, und
– ein Idle-Flag kann immer entfernt werden.

Zum Beispiel ist die Definition eines Flags ein "0"-Bit, gefolgt durch sechs zusammenhängende "1"-Bit und ein "0"-Bit. Ein Idle-Byte ist zum Beispiel definiert als eine Sequenz von acht "1"-Bit.
Dazwischenliegende Netzwerkelemente, die Serversignale mit eingebettetem Client-Overhead verarbeiten, müssen dann vorzugsweise dieselbe Protokollanalyse über die transparenten Client-Overhead-Byte, d.h. über die TDCC-Byte des Client-Signals hinweg durchführen.
Bezüglich der Overhead-Byte E1/E2/F1. Bekanntlich werden E1/E2/F1-Byte für 64 kbit/s-Benutzer- und Ordnungs-Drahtkanäle verwendet. Da diese Kanäle keinen Verkehr mit hoher Priorität enthalten, wird ein Schlupf oder Springen (Slip/Skip) dieser Daten als akzeptabel betrachtet, und ein Byte-Slip/Skip-Mechanismus reicht aus.
Dieser Mechanismus garantiert jedoch vorzugsweise die Einheitlichkeit verarbeiteter Byte für sich, ist jedoch nicht notwendig, um den Verlust bestimmter Byte oder eine verdoppelte Übertragung von Byte im Fall von Frequenzabweichungen zwischen System- und Empfangsfrequenzen zu verhindern.
Bezüglich der Overhead-Byte K1/K2. Ein Byte-Slip/Skip-Mechanismus kann auch für die Byte K1 und K2 verwendet werden, weil der Inhalt dieser Byte naturgemäß halbstatisch ist.
Das Slip/Skip-Protokoll behandelt die Byte K1 und K2 als eine Entität, d.h. diese beiden Byte werden vorzugsweise immer zusammen slip/skip-verarbeitet, sodaß nur K1/K2-Informationen, die zu einem Rahmen gehören, zusammen in die Daten eines abgehenden Rahmens eingefügt werden. Es wird erwähnt, daß gemäß den SONET/SDH-Standards die Akzeptanz von K1/K2 darauf basiert, daß gleiche Werte für drei aufeinanderfolgende Rahmen empfangen wurden, und dieser leichte Mechanismus kann daher unterstützt werden.
Bezüglich der Overhead-Byte M0/M1. Diese Byte M0/M1 enthalten MS-Fernfehlerzählinformationen (MS-REI), wodurch die ankommenden Bitfehler, so wie sie an dem Clientporteingang empfangen werden, an dem Clientportausgang nach ihrem Transport durch das Netzwerk wieder hergestellt werden.
Um die logische Ende-zu-Ende-Transparenz zu erzielen, werden vorzugsweise zwei Funktionalmechanismen implementiert:

– Ein Addierermechanismus, der dafür sorgt, daß Fehlerzählwerte, die aufgrund von Rahmenschlupf nicht transportiert werden können, zu dem in den nächsten Rahmen eingefügten MD-REI-Wert addiert werden. Wenn das Addiererergebnis den maximalen Fehlerzählwert übersteigt, wird der TM0/TM1-Wert auf dem maximalen Fehlerzählwert gehalten, wie zum Beispiel auf 1536 für STM-64/OC-192-Clients und 384 für STM-16/OC-48-Client-Signale.
– Wenn die TM0/TM1-Byte aufgrund von Rahmenschlupf dupliziert werden müssen, werden die duplizierten Byte auf Null gesetzt.

Es hat sich herausgestellt, daß M1 vorzugsweise für STM-16/STS-48 und STM-64/STS-192-Client-Signale unterstützt werden, wobei eine M0-Unterstützung eine konfigurierbare Option für STM-64/STS-192-Clients ist.
Bezüglich des Overhead-Byte B2. Bekanntlich enthalten diese B2-Byte BIP-Informationen der MS-Schicht, wodurch die ankommenden Bitfehler, so wie sie an dem Clientporteingang empfangen werden, an dem Clientportausgang nach ihrem Transport durch das Netzwerk wieder hergestellt werden.
BIP-Fehler, die während des Client-Transports an dem Serversignal auftreten und die dem Client-Teil des Serversignals zugeordnet sind, werden vorzugsweise an dem Clientportausgang des Netzwerks reflektiert.
Ankommende B2-Fehler an dem Clientporteingang werden erkannt, wodurch ein Fehlerzählwert in die TB2a/TB2b-Overhead-Byte des Client-Signals eingefügt wird, und dadurch besteht TB2 aus zwei Byte, um in der Lage zu sein, die maximale Anzahl von B2-Fehlern für STM-64/STS-192 zu transportieren, die, wie bereits erwähnt, 1536 beträgt.
Wenn B2-Fehler, die dem Client-Teil des Serversignals zugeordnet sind, in dem Netzwerk auf dem Serversignal auftreten, werden diese Fehler zu den empfangenen Client-TB2-Informationen addiert und als der neue TB2-Wert weitergeleitet.
Dann wird auf dem Clientportausgang ein neues B2 berechnet, wobei dieser B2-Wert gemäß der Anzahl von Fehlern (bereitgestellt durch TB2) verfälscht ist. Die Verfälschung wird vorzugsweise durchgeführt, indem korrekte Paritätsbit invertiert werden. Zum Beispiel werden für den Fall eines berechneten B2=11001101 und TB2=2 zwei Bit von B2 invertiert, sodaß 1100111 resultiert.
Für TB2 kann ein ähnlicher Addierermechanismus wie für M0/M1 vorgesehen werden, um die logische Transparenz zu erreichen. Wenn also TB2 den maximalen möglichen Fehlerzählwert für das zugeordnete Client-Signal übersteigt, wird TB2 auf den maximalen Wert abgeschnitten, der zum Beispiel für STM-64/OC-192-Clients 1563 und für STM-16/OC-48-Client-Signale 384 beträgt.
Durch Verwendung der oben beschriebenen Overhead-Byte-Synchronisations- und Ratenanpassungsprotokolle in der erfindungsgemäß angepaßten Systemarchitektur werden zum Beispiel der Transport von transparenten STM-16/STS-48-Signalen und der Transport von transparenten STM-64/STS-192-Signalen unterstützt.
Außerdem wird das Multiplexen von bis zu 4x STM-16/STS-48-Client-Signalen (T2G5) oder einer beliebigen Kombination von T2G5 und regulären VC/STS-Nutzsignalen in ein STM-64/STS-192-Signal und zum Beispiel das Multiplexen von bis zu 16xSTM-16/STS-48-Client-Signalen (T2G5), oder von bis zu 4xSTM-64/STS-192-Client-Signalen (T10G) oder einer beliebigen Kombination von T2G5, T10G und regulären VC/STS-Nutzsignalen in ein STM-256/STS-768-Signal unterstützt. 7a, 7b und 7c zeigen beispielhafte Ausführungsformen von Multiplexschemata. 7a zeigt schematisch einen vierfachen transparenten STM-16-Dienst über STM-64-Serversignalen, 7b zeigt gemischte transparente STM-16/STM-64-Dienste über STM-256-Serversignalen und 7c zeigt gemischte VC-Dienste bzw. transparente STM-16/STM-64-Dienste über ein STM-256-Transportsignal jeweils über drei Netzwerkentitäten NE_A, NE_B und NE_C mit einem transparent angepaßten Querverbindungsmittel XC zwischen den jeweiligen Eingangsport und Ausgangsport.
Um zu vermeiden, daß ein Netzwerkbenutzer die STS/VC-Nutzsignalstruktur des Signals zur Handhabung der transparent transportierten SONET/SDH-Signale als eine reale Pipeline bereitstellen muß, bevorzugt die Erfindung eine Netzwerkelementanpassung insofern, als dieses reale Pipelineverhalten durch die Zeigerprozessoren des Netzwerkelements, das in einem adaptiven Modus arbeitet, erzielt wird. In der Praxis wird vorgeschlagen, einen adaptiven Modus zu verwenden, wobei die Zeiger-Interpreter die Nutzsignalstruktur der Pipeline gemäß dem in dem Zeiger-Byte vorliegenden Verkettungsschema erkennen und sich die zugeordneten Zeigerverarbeitungsfunktionen automatisch gemäß dieser erkannten Nutzsignalstruktur anpassen.
Dementsprechend stellt bezüglich der erfindungsgemäßen Funktionalität in bezug auf die Leistungsüberwachung die beschriebene Architektur die Leistungsüberwachung der in das Serversignal mit höherer Rate eingebetteten Client-SONET/SDH-Signale sicher. Auf der Client-MS-Schicht kann somit die Fehlerleistung von TB2 und T(M0), T(M1) überwacht werden, ohne daß das Client-Signal abgeschlossen wird. Aufgrund der Integration der transparenten Client-Funktionalität mit existierender SONET/SDH-Funktionalität wird darüberhinaus auch die Leistungsüberwachung auf der STS/HO-VC-Schicht des Clients unterstützt.
Mit Bezug auf das Störungsmanagement wird das transparente Client-Signal jedoch als eine untergeordnete Schicht des Serversignals, das den Dienst führt, behandelt. Folglich führt ein Signalausfall des Serversignals zu Signalausfall bzw. Signalausfällen für das eingebettete Client-Signal bzw. die eingebetteten Client-Signale.
Bezüglich der Netzwerkverwaltungsunterstützung wird normalerweise für die Verwaltung eines Netzwerkelements ein logisches Übertragungsmodell verwendet, das die Übertragungskonnektivität in dem Netzwerkelement so beschreibt, wie sie von einem externen Benutzer gesehen wird. Fachleuten ist bekannt, daß durch Verwendung eines solchen Modells im allgemeinen beschrieben wird, welche Entitäten eine Rolle spielen und wie sie bei der Bereitstellung von Konnektivität zwischen Signalen in an das System angeschlossenen Übertragungsschnittstellen in Wechselwirkung treten.
Für einen Standard-Add-Drop-Multiplexer (ADM) können somit die folgenden logischen Entitäten definiert werden:

– Die logische Entität eines Ports, die in dem Netzwerkelement die Funktion des physischen Ports und die Schichtfunktionen des Regeneratorabschnitts RS und des Multiplexabschnitts MS, die dem Port zugeordnet sind, modelliert. Bekanntlich ist eine Schlüsselkenngröße eines solchen Ports gewöhnlich seine Bandbreite.
– Die logische Entität eines Port-Zubringers, die in dem Netzwerkelement die Funktion eines physischen Portzubringers und die zugeordnete Verarbeitung, d.h. zum Beispiel für SONET einen STS-1, 3...-Port-Zubringer und für SDH einen VC-3, 4...-Port-Zubringer, modelliert.

Auf der Basis der obigen Beschreibung der zugrundeliegenden bevorzugten Ausführungsformen zur Integration der erfindungsgemäßen Funktionalität transparenter SONET/SDH-Client-Signale in das existierende Logikmodell eines ADM wird somit vorzugsweise folgendermaßen vorgegangen:

– Eine neue Schicht wird eingeführt, die die Unterstützungsschicht ist, die eine Entität ist, durch die SONET/SDH-Client-Signale in einem Netzwerkelement quer verbunden werden können, wobei der Unterstützungstyp vorzugsweise drei Werte aufweist: Standard, TMUX und TADM. Dadurch beziehen sich der TMUX- und TADM-Typ auf die verschiedenen Betriebsarten transparenter Client-Konnektivität, während sich der Unterstützungstyp Standard auf Standard-ADM-Betrieb bezieht;
– ein Atribut wird zu der Portentität hinzugefügt, das ein Porttyp ist, der auch drei verschiedene Werte aufweisen kann: Standard, Client und Server. Dadurch bezieht sich der Porttyp Standard auf Standard-ADM-Betrieb, der Porttyp Client wird für Ports verwendet, bei denen das SONET/SDH-Signal, das transparent transportiert werden muß, in das System eintritt und dieses verläßt;
– ein Logikmodell, das Querverbindungen für Entitäten nur derselben Schicht erlaubt, d.h. Zubringer mit Zubringern und Unterstützungen mit Unterstützungen, wird zu dem Standardmodell hinzugefügt.

Als Ergebnis des erfindungsgemäßen Ansatzes und als Hauptvorteil der integrierten Overhead-Transparenz wird die Möglichkeit des Kombinierens des erfindungsgemäßen transparenten SDH/SONET-Signaltransports zusammen mit auf SDH/SONET-Nutzsignalen basierenden Transportfunktionen in demselben Netzwerkelement, was als transparentes Add/Drop-Multiplexen oder Multiplexfunktionalität (TADM) bezeichnet werden kann, wie in 8b gezeigt, worin dieser Vorteil im Vergleich mit einer separaten TMUX-Funktionalität und ADM-Funktionalität in verschiedenen Netzwerkelementen wie in 8a abgebildet implementiert wird.
Insbesondere ermöglicht die Funktionalität des transparenten Multiplexens TMUX, daß ein Netzwerkelement SONET/SDH-Client-Signale in Serversignalen höherer Rate transparent transportieren und querverbinden kann, wobei der Abschluß, insbesondere der Overhead-Abschluß der eingebetteten Client-Signale, nicht unterstützt wird. Im Vergleich dazu ermöglicht die transparente ADD/Drop-Multiplexfunktionalität TADM zusätzlich den Abschluß des Client-Signals, das in das Serversignal höherer Rate eingebettet ist bzw. der Client-Signale, die in das Serversignal höherer Rate eingebettet sind, und kombiniert daher die TMUX- und ADM-Funktionalität, wodurch zum Beispiel die Durchführung eines Übertragungsschutzes an dem eingebetteten Client-Signal bzw. den eingebetteten Client-Signalen möglich wird.
Durch Verwendung des implementierten erfindungsgemäßen Ansatzes werden in 9 bevorzugte Anwendungen der TMUX- und ADM-Funktionalität in der Praxis auf der Basis eines Beispiels eines Fasermangelproblems in einem gestapelten Ringnetzwerk abgebildet.
Das Beispiel gemäß 9 zeigt ein Netzwerk dreier gestapelter Legacy-Ringe 101, 102 und 103 und einen Fasermangel zwischen dem Standort A und dem Standort C. Bei diesem beispielhaften Netzwerk sind die Netzwerkelemente 30 so ausgelegt, daß sie die TADM-Funktionalität 31 und die TMUX-Funktionalität zusammen mit der TADM-Funktionalität 32 durchführen, und sind daher gemäß der Erfindung so ausgelegt, daß sie SONET/SDH-Querverbindungs- oder ADD/Drop-Multiplexfunktionalität mit der erfindungsgemäßen transparenten Crossconnect- und/oder Multiplexfunktionalität bereitstellen. Die abgebildeten Netzwerkelemente 40 identifizieren Elemente, die 2,5 G/10 G-Legacy-ADM-Funktionalität bereitstellen. 9 zeigt einen möglichen Nutzsignaltransport über TADM durch die Doppelfehler 203, und die ADD/Drop-Funktionalität ist durch die Doppelfehler 204 angedeutet. Somit kann der Ring 101 in dem TADM-Modus betrieben werden, und alle anderen Ringe 102 und 103 oder Ringteile werden in dem TMUX-Modus betrieben.
Als Folge kann die integrierte SDH/SONET-Transparenz zusammen mit hohen Aggregatbitraten die folgenden Probleme lösen:
Durch transparentes Auf-Muxen bzw. -Multiplexen des Rings 101, der ein 2,5 G-Ring ist, auf ein Leitungssignal mit höherer TDM-Bitrate (Zeitmultiplex) von zum Beispiel 10 G oder 40 G und durch dessen Betrieb im Overhead-Transparenz-Modus kann das Fasermangelproblem zwischen dem Standort A und B gelöst werden. Für die Legacy-Geräte 40 in dem Ring 101 ist dieses Muxen, d.h. das transparente Multiplexen, nicht sichtbar, sodaß existierende Netzwerkverwaltungsfunktionen und Leitungs- oder Ringschutzschemata ohne Änderung immernoch arbeiten. Für die Ringe 102 und 103, die zum Beispiel entsprechend für ein 10 G- oder 40 G-Bitratensignal ausgelegt sind, führt die Integration des transparenten Multiplexens und des Abschlußes der gemultiplexten Signale zu dem Vorteil der Unterstützung des Ein- oder Auskoppelns (ADD/Drop) von Nutzsignalverkehr an den Standorten A, B oder C.
Folglich kann TADM als eine einzigartige Fähigkeit angesehen werden, die den Kunden dabei unterstützt, Gerätekosten zu verringern, da im Vergleich dazu ein einschrittiger Ansatz zum Abschluß transparenter Clients in einem Serversignal nicht ohne einen TADM-Modus möglich ist. Anders ausgedrückt ist, wenn die TMUX-Funktionalität zum Multiplexen und Demultiplexen des Client-Signals zu oder aus dem Serversignal verwendet wird, eine zusätzliche ADM-Funktionalität notwendig, um dieses Client-Signal abzuschließen.
Daher ermöglicht die Erfindung leicht den Transport von SONET/SDH-Signalen oder -Rahmen als einen Dienst, insbesondere als einen Ende-zu-Ende-Dienst, einschließlich Nutzsignal- und Overhead-Informationen, und fügt daher existierenden Netzwerken oder Systemen aufgrund der beschriebenen Integration in existierende SDH/SONET-Systeme und -Systemkonzepte und aufgrund der Möglichkeit der Koexistenz mit standard-beschwerten-SDH/SONET-Nutzsignaldienstfunktionen signifikanten Wert hinzu. Da sich das Server-(Leitungs-)Signalformat nicht ändert, ermöglicht die Erfindung, wie Fachleuten ersichtlich ist, ein Multiplexen von SDH/SONET-Signalen oder -Rahmen zu SDH/SONET-Signalen mit höherer Bitrate und den Transport dieser SDH/SONET-Signale mit höherer Bitrate über existierende transozeanische Systeme des Stands der Technik. Durch Unterstützen der leichten Integration in existierende SDH/SONET-Netzwerkelementkonzepte und indem aufgrund der Ratenanpassungsfunktionen der reibungslose Betrieb über Zeitsteuerungsdomänen hinweg sichergestellt wird, ist die erfindungsgemäße Abbildungsfunktionalität des zusätzlichen transportierten Client-Overhead mit existierenden SDH/SONET-Regeneratoren, transozeanischen Systemen und standardisierter Mehrbit-Vorwärtsfehlerkorrektur wie oben beschrieben kompatibel.

Claims

Verfahren zum Transport von SDH/SONET-Client-Signalen als einen Dienst mit dem Schritt des Einbettens des assoziierten SDH/SONET-Client-Nutzsignals in ein SDH/SONET-Serversignal, und weiterhin. mit den folgenden Schritten: – Abbilden von Overhead-Informationen des mindestens einen SDH/SONET-Client-Signals in das SDH/SONET-Serversignal, wobei die Client-Overhead-Informationen des mindestens einen SDH/SONET-Client-Signals in freie Overhead-Positionen des SDH/SONET-Serversignals abgebildet werden, – Transportieren des SDH/SONET-Serversignals mit den Nutzsignalinformationen und den abgebildeten Client-Overhead-Informationen des mindestens einen SDH/SONET-Client-Signals, die darin eingebettet sind, und Ratenanpassen von Daten bestimmter SDH/SONET-Client-Overhead-Informationen vor dem Schritt des Abbildens zur Sicherstellung der Aufrechterhaltung des logischen Inhalts davon, dadurch gekennzeichnet, daß die bestimmten SDH/SONET-Client-Overhead-Informationen, die Byte des Datenkommunikationskanals (DCC) umfassen, die HDLC-Rahmen führen, ratenangepaßt werden, indem Idle- oder Flag-Byte an Positionen im HDLC-Rahmen gemäß den folgenden Regeln eingefügt oder entfernt werden: – ein Flag-Byte kann direkt vor oder direkt nach einem einzelnen Flag eingefügt werden, – ein Idle-Flag kann direkt vor oder direkt nach einem anderen Idle-Flag-Byte oder direkt zwischen zwei Flags eingefügt werden, – ein Flag kann entfernt werden, wenn ihm direkt ein anderes Flag vorausgeht oder folgt und – ein Idle-Flag kann immer entfernt werden.
Verfahren nach Anspruch 1, wobei der Schritt des Abbildens weiterhin das Routen von Overhead-Informationen für Wartung, Verwaltung und Schutz des mindestens einen SDH/SONET-Client-Signals durch eine STS-VC-Querverbindungsmatrix umfaßt.
Verfahren nach Anspruch 1 oder 2, weiterhin mit den folgenden Schritten: – Wählen von Overhead-Positionen des mindestens einen SDH/SONET-Client-Signals, wobei die Positionen spezifische Standard-Overhead-Informationen des mindestens einen SDH/SONET-Client-Signals umfassen, – Abbilden der spezifischen Standard-Overhead-Informationen der gewählten Positionen auf Client-Overhead-Positionen des jeweiligen assoziierten SDH/SONET-Client-Nutzsignals des mindestens einen SDH/SONET-Client-Signals und – Multiplexen des SDH/SONET-Client-Nutzsignals in das SDH/SONET-Serversignal.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Abbildens von Overhead-Informationen des mindestens einen SDH/SONET-Client-Signals in das SDH/SONET-Serversignal mindestens in der Nähe einer Eingangsschnittstelle eines Netzwerks mittels Multiplexen der Overhead- Informationen in ein SDH/SONET-Serversignal mit einer im Vergleich zu dem mindestens einen SDH/SONET-Client-Signal höheren Bitrate durchgeführt wird, und/oder wobei mindestens in der Nähe einer Ausgangsschnittstelle eines Netzwerks die abgebildeten Overhead-Informationen des mindestens einen SDH/SONET-Client-Signals teilweise verarbeitet und in jeweils definierte Standard-Overhead-Positionen des mindestens einen SDH/SONET-Client-Signals zurück abgebildet werden.
Verfahren nach einem der vorhergehenden Ansprüche, mit dem Schritt des Abschließens von in das SDH/SONET-Serversignal eingebetteten SDH/SONET-Client-Overhead-Informationen.