Chris_BLN hat geschrieben:
Bitte die ganzen Gedankenspiele nochmals durchspielen mit der Tatsache im Hintergrund, daß DAB ein System mit Multiplexbildung ist. Und wenn ich auch nur ein Slide in einer Slideshow eines übertragenen Services ändere, hat der gesamte Mux eine andere Datenstruktur. Das gleiche gilt natürlich für Austausch einer Regionalisierung eines einzigen Services. Diese andere Datenstruktur (ETI-Stream) macht mir zwangsweise am Sender anderen Modulator-Output. Und damit völlig andere HF.
Hier wäre es zu lesen, wie es technisch funktionieren soll. Leider nur gegen Bezahlung:
http://ieeexplore.ieee.org/document/7986171/
Der Abschlussbericht kommt wohl erst Ende 2017.
Es gab dazu aber einen Zwischenbericht, der ganz interessant ist:
http://www.nlm.de/fileadmin/dateien/pdf ... 161212.pdf
Man hat daraus vermutlich Ansatz 4.5 weiter verfolgt.
Chris_BLN hat geschrieben:
Das Thema "Synchronisation im SFN" ist damit obsolet, denn wo nichts identisches ist, kann ich auch nichts synchronisieren.
Für die Synchronisation gibt es ja den von den Nutzdaten (MSC) getrennten Synchronisationskanal und auch die FIC mit den Verwaltungsdaten ist unabhängig von den Nutzdaten. Das hat man also schon mal sicher, egal welcher Mumpitz in den Nutzdaten steckt. Der Empfänger kann also schon mal an der richtigen Stelle nach den Trägern der MSC-Übertragungsframes suchen.
Diese sind also der eigentliche Knackpunkt. Jeder MSC-Frame enthält im Transmission Mode I also 4 sog. CIFs, von denen jeder einzelne CIF jeweils die kompletten 864 CUs des Ensembles für eine Dauer von 24ms enthalten sollte. Fehlerschutz passiert schon vorher, getrennt nach Services (EEP/UEP/Reed-Solomon usw.).
Vor dem Time Interleaving sind die Daten, die für das regionalisierte Programm zuständig sind, also noch eindeutig zu identifizieren und zu trennen von denen der anderen Programme. Aber auch nach dem Time Interleaving sollten die Bits des regionalisierten Programms noch eindeutig von den anderen zu trennen sein, denn sie werden ja nur auf der Zeitachse verteilt (die zeitliche Reihenfolge ändert sich, aber es werden keine korrekten/inkorrekten Bits miteinander vernudelt).
Die zuletzt durchgeführte zufällige Verteilung der QPSK-Symbole auf die OFDM-Träger halte ich auch nicht für kritisch. Ob ein fehlerhaftes Symbole nun an der einen Stelle, oder an der anderen Stelle steht, beeinflusst ja nicht, dass die restlichen Symbole weiterhin korrekt sind.
Problematisch scheinen also wohl nur das Interleaving auf Bitstrombasis bzw. die differentielle Modulation dazwischen zu sein, da man hier Abhängigkeiten zwischen Bits bekommt, die nicht zueinander gehören, sprich fehlerhafte Bits können hier eigentlich korrekte nachfolgende Bits kaputt machen. Das scheint man wohl mit der in 4.5 geschilderten Maßnahme beheben zu können.
Zusammengefasst würde ich vermuten, dass die Störungen sich also tatsächlich nur auf einzelne Träger beschränken, die dann auch wirklich nur für das regionalisierte Programm zuständig sind.