Diskussion:Synchrone Digitale Hierarchie

Tippfehler im Bild

In der Abbildung des SDH-Ringes ist ein Tippfehler aufgetreten, nämlich "stand bye" statt "stand by". Da das Bild von Commons eingebunden ist und mein Accout bei Commons leider zu neu ist, um das Bild einfach zu ersetzen, habe ich eine korrigierte Version mal hier als Bild:SDH-Synchronous optical networking Doppelring typofixed.JPG (siehe Thumb)

Korrigiertes Bild

hochgeladen. Wer kann und mag, kann gerne dieses Bild bei Commons hochladen und den Tippfehler dadurch korrigieren, dass er/sie das Bild mit dem gleichen Namen wie das Ursprungsbild (also ohne "_typofixed") hochlädt. --Wiegand 17:43, 6. Feb 2006 (CET)

Kritik

Das ist doch eine Beschreibung der PDH-Technik und nicht der SDH-Technik ! Die Überschrift muß lauten: "Plesiochrone Digitale Hierarchie", dann stimmt es. Die Text ist so allgemein, dass er für SDH auch noch stimmen würde. Aber die Tabelle mit den Bitraten der verschiedenen Hierarchiestufen ist nichts als die altehrwürdige PDH-Technik, die mit fortschreitender Tendenz aus allen Netzen aller Netzbetreiber entfernt und durch SDH-Technik ersetzt wird !

Die SDH-Technik hat andere vorwiegend höhere Bitraten. Die SDH-Technik basiert auf der synchronen Übertragung von sogenannten Transportmodulen STM mit einheitlicher Struktur. Das Basistransportmodul ist der STM-1-Rahmen mit 155 Mbit/s, das nächstgrößere Transportmodul ist der STM-4-Rahmen mit 622 MBit/s.

Hat jemand eine andere Meinung ? -- Sadduk 24. Mär 2004 22:41

Du hast Recht, ich habe das mal geändert. Mwka 23:10, 5. Apr 2004 (CEST)

sollte nicht bei der SDH auch die ITU-Spinne und die Struktur der Ramen und der einzelnen Bytes genannt werden ??? --145.253.209.244 3. Okt 2004 20:22

Überarbeiten

Habe "(potentiell unendlich)" in ",welche seriell gesendet werden." geändert. 18.10.05, N. Python

grob unverständlich, Weblinks warten auf fachliche Überprüfung, sachliche Fehler noch vorhanden? --80.145.253.94 8. Jul 2005 19:20 (CEST)

Ich finde die Beschreibung für Laien ganz OK. Sicherlich kann man noch mehr Details einfügen, wie z.Bsp. den SDH-Rahmen. - Habe übrigens die Kommas bei den Übertragungsraten eingefügt - Beispiel: bei VC 12 Mapping handelt es sich nicht um 2048 MBit/s sondern um 2,048 MBit/s, so auch bei allen anderen Bitraten in dem Kasten "SDH Multiplexstruktur nach ITU-T G.709".

Von mir aus kann man die "Überarbeiten"-Vorlage durchaus noch drin lassen, auch wenn der Artikel bereits mehrmals angefasst und erweitert worden ist, seitdem die Anregung zum Überarbeiten kam. Man kann den Text bestimmt noch besser gliedern (z.B. die Verkettung von VCs in einen eigenen Abschnitt weiter unten tun) und manches in einer Einleitung etwas einfacher ausdrücken. Ein paar kleine Dinge gefallen mir auch noch nicht. zB. ist mir noch nie ein VC13 begegnet. Das ist mE noch ein Tippfehler. Oder diese Tabelle, die "Schichten" von SDH benennt. Die muss auch noch komplett überarbeitet werden (SDH kennt nun mal keine Schichten im OSI-Sinn). Also, es gibt durchaus noch einiges zu tun hier. Fink 12:21, 5. Aug 2005 (CEST)

RSOH Abkürzung wofür ? Repeater-Section-Overhead bzw. Regenerator Section Overhead

Hi, danke für deine Änderungen Fink ! Bei einem Punkt kann ich momentan mangels direkten Zugriff auf die ITU-T Dokumente leider nicht verifizieren. Einmal finde ich RSOH als Abkürzung für Repeater-Section-Overhead bei http://jgae.de/sdh.htm (auch im Taschenbuch Rechnernetze und Internet von Erich Stein ISBN 3-446-22573-0) oder als Regenerator Section Overhead wie von dir genutzt (http://www.uni-muenster.de/ZIV/Lehre/2000-4/RechnernetzeTechnischeGrundlagen/PDHSDH.pdf). Hast du Zugriff auf die originalen ITU-T Dokumente G.707, G.708 und G.709 um dies endgültig zu klären ? Danke im voraus ... ITU will nämlich 1090 CHF für Ihre Empfehlungen Pierre gronau 09:51, 5. Aug 2005 (CEST)

Ja, ITU ist teuer, und deswegen können manchmal sogar FHs und THs sich die Dokumente nicht leisten, und machen dann Fehler in ihren Skripten. Ich habe Zugriff auf die 3 Original-Doks (berufsbedingt), die Abkürzung RSOH steht u.a. in der G.707, und ist als "Regenerator section overhead" definiert. Für solche Abkürzungen und Definitionen bietet ITU-T eine Online-Datenbank mit Suchfunktion an, die ganz umsonst ist: [1]. Allerdings besteht die Erläuterung selten aus mehr als 5-10 Worten. Du kannst da ja mal "RSOH" eingeben und gucken, in welchem ITU-T - Standard der Begriff ursprünglich definiert ist: G.780. Fink 12:08, 5. Aug 2005 (CEST)

Danke für deine Mitarbeit ! Ich bin immerhin drei FH und TH Dokumenten aufgesessen ... naja so ist das Leben ... vielleicht schreibe ich noch was an dem Artikel mal sehen ... Pierre gronau 16:03, 5. Aug 2005 (CEST)

Kleine Anmerkung: Man kann sich beim ITU-Bookshop registrieren und pro Jahr 3 Dokumente kostenlos herunterladen.

Danke mach ich mal ... Pierre gronau 17:19, 15. Aug 2005 (CEST)

Hallo, Anmerkung zu Regenerator und Repeater: Die SDH sieht vor, dass das Signal nicht nur Verstärkt wird (Repeater) sondern auch im Timing (mittels Taktrückgewinnung und Zeitentscheider)wieder erstellt wird (Regenerator). Gruß Hans-Otto Kersten

Das würde ich auch so sehen, leider wird auch in der Wikipedia kein Unterschied zwischen (Zwischen-)Regenerator und Repeater gemacht, da auf den gleichen Artikel verwiesen wird. Aber ne gute Anregung, den Unterschied dort nochmals zu präzisieren. --Fuexle 23:10, 10. Nov. 2008 (CET)

kleinere Fehler

ich habe mal die Erweiterungen der letzten Tage gelesen. Schön, dass der Artikel sich um etliche Details vergrößert. Dabei sind mir ein Paar kleinere Punkte aufgefallen, die mE geändert werden sollten:
1)"einzelne Bitfehler können gezählt werden": das stimmt so nicht. Bei SDH gibt es die BIP-X - Fehlerüberwachung (BIP = Bit Interleaved Parity). Wieviele Bitfehler erkannt werden, hängt von ihr ab. Bei BIP-2 wird nur ein BIP-Wert von 2 Bit mitübertragen, der natürlich nicht so gut ist wie ein BIP-24 aus 24 Bits. Welches Signal nun mit welchem BIP-Wert definiert wurde, hängt einfach von der Größe des VCs ab. Viel VC braucht viel BIP. Die Standardisierer haben die BIPs einfach so festgelegt, dass für jede VC-Größe etwa dieselbe Bitfehlerrate noch detektierbar ist (1E -10)
2) Nicht jedes Multiplexschema führt über den VC4. Es ist auch möglich, 3 VC3 nicht über TUG-3 in einen VC4 zu multiplexen, sondern direkt in eine AUG.
3) Die Protectionzeit von Millisekunden ist nicht richtig. Wie schnell umgeschaltet wird, ist ein herstellerspezifischer Parameter. 50 msec war mal ein Ziel der Standardisierer bei ITU-T, aber da gab es amerikanische Hersteller, die schafften das nicht mit ihren Geräten. Deswegen wurde die Protectionzeit nicht normiert. Die alte Formulierung im Artikel "unter einer Sekunde" trifft besser zu.

---

Danke für's Kommentieren, hier was ich meinte:

1) natürlich können mit BIP-X einzelne Bitfehler erkannt werden, schwierig wird's erst bei größeren BER, wenn mehrere Bitfehler in einem Block auftreten. Da stimmt die Anzahl der BIP-violations nicht mehr mit der Anzahl der Bitfehler überein...

Das ist schon richtig, ein einzelner Bitfehler in einem Block kann erkannt werden. Aber das ist ein akademischer Labor-Fall. In der Praxis gibt es gar keine Fehler, oder gleich sehr viele Fehler. Deswegen taugt der Satz im Artikel nicht so recht.

Ganz genau: du kannst sehen, ob die Verbindung auch nur einen einzigen! Bitfehler hatte. Wenn es so viele sind, daß die BIPs nicht mehr ausreichen, bist du schon weit im SD und die Protection ist getriggert... Es ist auch in der Praxis scheißegal, ob das 15-min bin nun 10 oder 100 BBEs hat. Alles was nicht NULL ist, wird "repariert". Daher ist es aus meiner Sicht vollkommen unrelevant für die PRAXIS, ob du bei 1e-2 physikalischer BER noch 1e-2 BIP violations festsellen kannst - viel wichtiger ist, bei geringer BER (1e-12) eine einzige Violation feststellen zu können. Und genau das sagt der Satz im Artikel...

Aus dem Gesichtspunkt der Praxis kann ich Dir leider nur teilweise zustimmen. Eine BER von 1e-12 interessiert keinen. Was soll ein Servicetechniker machen, wenn eine derart kleine BER auftritt ? Überhaupt nichts. Da ist es interessanter, wenn in China ein Blatt vom Baum fällt. Alles ist gut mit 1e-12. Wichtig sind die Grenzwerte für SD (signal degraded) und eBER (extended BER). Und die liegen nun mal bei 1e-6/7 und 1e-3. Die leiten sich nämlich von der Fehlertoleranz der Dienste ab, die über die SDH-Strecken laufen. Der Bereich von BERs , die geringer als 1e-7 ist, ist nur aus einem Grund interessant: Alterungsprozesse der Laser kündigen sich mit langsam steigender BER an. Inzwischen wächst allerdings die Lebensdauer der Laser, sodaß der ganze hochempfindliche Bereich ständig uninteressanter wird. Das ist natürlich Pech für die Hersteller von Muxes, deren HW-Zähler zu dürftig und nur für diesen Bereich ausgelegt sind. Fink 21:55, 13. Nov 2005 (CET)

2) Da hast Du natürlich Recht. Dennoch ist in der Praxis die AU3 als Ausnahmeform und eher als Kompatibilität zu Sonet zu werten. In deR Regel gibt es keine SDH Multiplexer (mit LO-access), die AU3 verschalten würden (wie gesagt, die HO-Kisten mal ausgespart)- eher wird am SDH-Port die AU3<->TUG3 Konversion eingesetzt, um die Kompatibilität herzustellen. Diese Funktionalität wird von allen gängichen chipsets der pointerprocessoren unerstützt.

AU3 wird in Deutschland für die live-Video-Übertragung von Fernsehsignalen mit 34 Mbit/sec benutzt. Das hat mit SONET nun garnichts zu tun. In Deutschland haben Siemens und Marconi tausende von SDH-Muxen an die DTAG geliefert, die 3 AU-3 in AUG multiplexen können. Das war Lieferbedingung. Die AUG wird danach natürlich noch in einen STM-N-Rahmen gepackt. Deine Aussage stimmt also so nicht.

Für den Backbone Bereich T-COM war/ist AU3 definitiv NICHT Lieferbedingung, sonst wären unsere X-tausend Kisten nicht dort gelandet.

Für den access Bereich hast Du Recht. Beim Eintritt ins Backbone wird jedoch dann die Pointerumwandlung von AU3 nach TU vollzogen... Vielleicht fügst du einfach den VC3 zu den HOPfaden hinzu?

mach Du das mal ruhig selbst.Habe auch nochmal nachgeschaut: auch Dein Verweis auf SONET ist nicht korrekt. Das Multiplexschema von ITU-T sieht den Weg über AU-3 durchaus vor. Fink 21:55, 13. Nov 2005 (CET)

3) Dieser Satz bezieht sich auf die SNCP/MSP/MS-SPRING Gruppen, die vorher genannt wurden. Diese sind in den Standards verbindlich mit 50 msec switching time für APS performance geregelt (von Ausnahmen, wie "unclean Ring" oder extra traffic mal abgesehen). diese Zeit ist auch tatsächlich in die Requirements aller Netzbetreiber übernommen wurden. diese 50 msec sind allerdings die reine APS performance, d.h. die Fehler-detection Zeit ist noch zu addieren. diese ist je nach Signalrate unterschiedlich (ein E1-LOS ist langsamer detektiert, als ein 10G LOS) und nicht verbindlich geregelt. In der Praxis wir jedoch verreitet eine detection Zeit von 10msec für Transmission-Defekte angenommen, d.h. 60msec sind für SNC/MSP/MS-SPRing die gängigen requirements für Faserbruch ect und 50 msec für externe switch requests. Mit hardware/equipment protection sieht die Sache schon ganz anders aus. Dort ist ebenfalls nur die switching performance von 50msec (z.Bsp bei manuellem switch) geregelt - hier sind die detection Zeiten allerdings absolut unvorhersebar (z.T. im sekunden-bereich). der gängige Test, das Ziehen einer Einsteckkarte im laufenden (Test-)Betrieb kann herstellerabängig zw. 10ms und 1s ausfallzeit zur Folge haben. Es ist eben nicht so einfach, alle devices und jeden sw-code auf einer Baugruppe zu überwachen. Die meisten (cleveren) Hersteller überwachen daher den Latch (Einsteck-Verriegelung) der Steckkarte und schalten sofort beim Öffnen der Verriegelung um. Wenn die Baugruppe allerdings direkt im Wirkbetrieb ausfällt (z.Bsp Komponentenfehler) sind die Detektion Zeiten nicht vorhersehbar....

Du schreibst es selbst, die Protection-Zeit ist in der Praxis wesentlich länger als die 50 msec. Dazu gehört eben die bitratenabhängige Detectionzeit und natürlich auch die Zeit, die die Steuerung eines Mux braucht, um umzuschalten. Die 50 msec interessieren nur im Labor. Dass die 50 msec in den Lieferbedingungen diverser Netzbetreiber zu finden sind, ist richtig. Aber solange es keine präzise Meßvorschrift gibt,... Auch die SNCP/MSP/MS-SPRING Gruppen sind nun mal in den real existierenden Netzen wirklich nicht die vorwiegenden. Mengenmäßig sind regionale SDH-Netze weit überwiegend, und die sind in der Regel keine reinen Ringe.

Bei der Mehrzahl der transeuropäischen, asiatischen und amerikanischen Netzwerke sind die Backbones (STM-16/STM-64) ringförmig und MS-SPRing/BLSR geschützt. Die Anbindung der Access-Boxen (STM1/STM4) geschieht in der Regel linear (dann MSP) oder ringförmig (dann SNC).

Die von diesen Schutzmaßnahmen sind nicht mehr Equipment protected. Die überwiegende Mehrzahl der Protection switches wird durch Maintenance-arbeiten (Austausch ausgefallener Baugruppen), SW-Bugs und Bedienfehler verursacht. Durch die hohe (in der Praxis deutlich unterhalb vo 10msec) lieende Umschaltperformance merkt der Endkunde nichts. Daher ist die überwiegende Anzahl der switches vom Operator initiert (i.d.R unter 2msec) oder durch Faserbruch oder DWDM-Ausfall verursacht und fällt daher unter das 50+X "Gesetz". ie Equipment Protection umfaßt immer das Koppelfeld/Timing/Powersupply und die elektrischen interfaces E1/E3/STM1e. Diese Baugruppen allerdings haben eine deutlich geringere Ausfallrate verglichen mit den Optischen Baugruppen. Und auch hier gilt 50 msec maximum für vom Operator angesetzte switches! Also 99% aller APS vorgänge in SDH Netzte fallen unter die 50 oder 50+10msec.

Die Backbones machen einen sehr kleinen Teil der SDH-Netze aus, wenn man die Anzahl der benutzten Fasern als Maßstab nimmt.Möglich, dass dort 99% aller APS-Vorgänge auftreten. Dass optische Baugruppen eine höhere Ausfallrate haben, kann ich aus meiner Sicht nicht bestätigen. Das mag vom Hersteller abhängen...

Für die Messungen der APS Performance gibt es äußerst präzise und standardisierte Meßvorschriften. Sei versichert, daß dieses (50msec) Kriterium bei jeder Typmusterprüfung sorgfältig getestet wird.

wenn ichs denn aus eigener Praxis nicht besser wüsste...

Die 50msec ein praxisrelevanter Wert und ein Alleinstellungsmerkmal von SDH ->vergleich doch mal die APS performce von Ethernet switches...

Der häufigste Port an den SDH-Muxen der DTAG ist der 2-Mbit/s- PDH-Port.

Du kannst davon ausgehen, das bei DTAG ALLE Pfade SNCP geschützt sind. MSP und MS-SPRing haben sich bei denen noch nicht eingeschlichen - das Netz ist aufgrund der Vermaschung mit SNC deutlich effektiver ausnutzbar.

MSP gibt es bei Pfaden nie, die gibt es nur bei sections. Fink 22:17, 13. Nov 2005 (CET)

I.d.R sind die E1 Ports über 1:n Equipment protection geschützt, der VC12 ab dem Koppelfeld über 1+1 SNCP.

das ist für SDH über Funk etwas anders.

Die Netze selbst haben alle möglichen Topologien, die sich an Trassenverläufen orientieren und am Bandbreitenbedarf. Reine Ringe habe ich noch nie gesehen.

Geografische Topologie ist noch lange nicht die Netztopologie ;-)

Summa-Sumarum denke ich, das 3 Punkte ok sind.

ich eigentlich nicht. Fink 22:48, 10. Nov 2005 (CET)

Sorry, für das Denglish, aber es ist mühsam für alles nen deutschen Begriff zu finden.... Selbtst die T-COM fängt an, Englische Begriffe zu verwenden ;-)

Struktur

A) Ich denke, die nicht genormten SDH Raten (z.Bsp STM32, 128 usw.) sollten nicht erwähnt werden. sind in der Praxis eh nie zu finden und verwirren eher, oder? B) Die Zeilen zur contiguous/virtual concatenation im Übersichtsteil ist m.E. dort zu speziell. Ein seperater Abschnitt wäre wohl angebracht. C) Momentan schreckt der Einführungsteil eher ab, als zum Weiterlesen zu animieren. Klar ist der SONET Bezug wichtig, aber gleich mit STS anzufangen?

SDH Stopftechnik

Auch in der SDH kann/wird gestopft. Wenn der Synchronismus verloren geht, dann kann in der SDH immer noch eine Taktanpassung durchgeführt werden. Das H3-Byte des Pointers steht für das "Negative Stopfen" zur Verfügung. Die unmittelbar an den Pointern in der Payload liegenden Bytes stehen für das "Positive Stopfen" zur Verfügung. Der Pointer muss entsprechend korrigiert werden! Zunächst mittels dekrement oder inkrement. Im darauf folgenden Rahmen wieder mit Pointeradresse. Hans-Otto Kersten

Im Prinzip nicht falsch, nur wird die Anpassung des Pointers gewöhnlich nicht als "Stopfen" oder "Stopftechnik" bezeichnet. Fink 09:27, 8. Mai 2006 (CEST)

In der SDH wird nicht gestopft, sondern der Pointer verschoben, dass ist ein sehr großer Unterschied!!! T3172 18:13, 1. September 2010 (CEST)

Begriff "synchron"

Der Begriff "synchron" wird im ganzen Artikel großzügig verwendet, aber einleitend nicht erklärt. Kann man den wenigstens auf irgendwas verlinken, wo er erklärt wird? Desgleichen für "plesiochron" weiter unten, wird vermutlich an gleicher Stelle irgendwo in der WP erklärt. Danke -- 131.220.5.34 12:24, 27. Mai 2008 (CEST)

Synchron ist das Netz deswegen, da alle Netzelemente einen hochgenauen Takt bekommen, das ist bei der plesiochronen Technik nicht der Fall, dort ist nur die 2MBit/s synchron, alle höheren Ebenen laufen mit internen Takten, die immmer etwas nach oben abweichen, um nicht negativ stopfen zu müssen. --Fuexle 23:28, 10. Nov. 2008 (CET)

Crossconnect-Multiplexer

Im Artikel wird mehrfach auf den Artikel Crossconnect-Multiplexer verlinkt, der jedoch nur eine Weiterleitung auf den Artikel Synchrone Digitale Hierarchie ist. Ich habe einen der Links entfernt und einen anderen auf die Sektion Synchrone Digitale Hierarchie#SDH-Netzelemente geändert. --MajorR 14:54, 6. Dez. 2008 (CET)

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.alcatel.com/products/productsummary.jhtml?repositoryID=/com/en/appxml/opgproduct/alcatel1850transportserviceswitchtcm228288321635.jhtml
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Dieser Link ist vermutlich nicht mehr im Quelltext des Artikels vorhanden; falls insgesamt weg, dann diesen Eintrag löschen.
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://www.alcatel.com/products/productsummary.jhtml?repositoryID=/com/en/appxml/opgproduct/alcatel1850transportserviceswitchtcm228288321635.jhtml
• http://www.alcatel.com/products/productsummary.jhtml?relativePath=/com/en/appxml/opgproduct/alcatel1678metrocoreconnecttcm228121601635.jhtml
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://www.alcatel.com/products/productsummary.jhtml?relativePath=/com/en/appxml/opgproduct/alcatel1678metrocoreconnecttcm228121601635.jhtml
• http://www.alcatel.com/products/productsummary.jhtml?repositoryID=/x/opgproduct/Alcatel_1660_SM.jhtml
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://www.alcatel.com/products/productsummary.jhtml?repositoryID=/x/opgproduct/Alcatel_1660_SM.jhtml
• http://fibers.org/articles/fs/9/3/3/1
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Dieser Link ist vermutlich nicht mehr im Quelltext des Artikels vorhanden; falls insgesamt weg, dann diesen Eintrag löschen.
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://fibers.org/articles/fs/9/3/3/1

– GiftBot (Diskussion) 07:45, 30. Nov. 2015 (CET)