Difference between revisions of "Exercise 2.5: DSL Error Protection"
m (Guenter verschob die Seite 2.5 DSL–Fehlersicherungsmaßnahmen nach Aufgabe 2.5: DSL–Fehlersicherungsmaßnahmen) |
|
(No difference)
|
Revision as of 07:59, 4 January 2018
Um die Bitfehlerrate der xDSL–Systeme entscheidend zu senken, wurden in den Spezifikationen verschiedene Sicherungsverfahren vorgeschlagen, um den zwei häufigsten Fehlerursachen entgegen zu wirken:
- Bitfehler aufgrund von Impuls– und Nebensprechstörungen auf der (Zweidraht–)Leitung,
- Abschneiden von Signalspitzen aufgrund mangelnder Dynamik der Sendeverstärker (Clipping).
Die Grafik zeigt die Fehlerschutzmaßnahmen bei ADSL/DMT. Diese sind in zwei verschiedenen Pfaden realisiert:
- Beim Fast–Path setzt man auf geringe Wartezeiten.
- Beim Interleaved–Path wird eine niedrige Bitfehlerrate erwartet.
Die Zuordnung der Bits zu diesen Pfaden übernimmt dabei ein Multiplexer (MUX) mit Synchronisationskontrolle.
Hinweis: Die Aufgabe gehört zu Kapitel Verfahren zur Senkung der Bitfehlerrate bei DSL.
Fragebogen
Musterlösung
(2) Richtig sind die Aussagen 1, 3 und 4. Sowohl das CRC–Verfahren (Cyclic Redundancy Check) als auch Scrambler/De–Scrambler werden mit Schieberegistern der Länge $8$ bzw. $23$ realisiert. Der Scrambler ist redundanzfrei (das heißt, er hat genau so viele Ausgangsbits wie Eingangsbits) und ist nach kurzer Einlaufzeit selbstsynchronisierend. Die Redundanz von CRC ist sehr gering. Es handelt sich dabei nicht um eine Fehlerkorrektur im eigentlichen Sinn, sondern um die Kontrolle besonders wichtiger Daten, zum Beispiel solcher zur Rahmensynchronisierung.
(3) Richtig sind die Aussagen 2, 3 und 5. Im Fachbuch „Einführung in die Kanalcodierung” finden Sie ausführliche Kapitel über Trellis–codierte Modulation (TCM) und zu den Reed–Solomon–Codes. Bei letzteren handelt es sich um Blockcodes – also keine symbolweise Codierung – auf Byte–Ebene.
(4) Richtig sind hier die beiden ersten Aussagen im Gegensatz zu den beiden letzten: Das Interleaving ist redundanzfrei und führt zu großen Latenzzeiten und Verzögerungen, so dass bei Echtzeitanwendungen darauf verzichtet werden sollte.
(5) Alle hier gemachten Aussagen sind richtig, wie auf der Seite Gain Scaling und Tone Ordering im Detail nachgelesen werden kann.