-
Die Offenbarung bezieht sich auf ein Verfahren und eine Vorrichtung zum iterativen Decodieren einer Datentransferstruktur, insbesondere eines Transportblocks, der mehrere Codeblöcke umfasst, und insbesondere auf ein hybrides Abbruchkriterium unter Verwendung eines Schwellenwerts für die Decodierung bei Hochleistungs-Turbodecodierern zwecks Verbesserung der Batterielebensdauer bei mobilen Geräten.
-
Ein iterativer Decodierer wie z.B. ein Turbodecodierer beruht auf einem iterativen Algorithmus, der die Wahrscheinlichkeitsabschätzungen bei jeder Iteration verbessert. In den guten Fällen ist der Decodierer in der Lage, den ursprünglichen übertragenen Codeblock nach einer gewissen Anzahl von Iterationen wiederherzustellen. Es gibt aber auch andere Fälle, bei denen das empfangene Signal so verfälscht ist, dass der Decodierer nicht in der Lage sein wird, den ursprünglichen Codeblock wiederherzustellen, selbst wenn der Decodierer mehrere Iterationen vornimmt. Im Allgemeinen hängt die Anzahl der benötigten Iterationen von der Coderate ebenso wie von dem Ausmaß der Verfälschung auf Grund des Übertragungskanals ab.
-
Turbodecodierer verwenden einen Schwellenwert, der die Decodierung abbricht, wenn eine Maximalanzahl von pro Codeblock erlaubten Iterationen erreicht ist. Als Ergebnis sind für eine Transportblockübertragung die Turbodecodierer so dimensioniert, dass sie eine Gesamtzahl von Iterationen unterstützen, die der Maximalanzahl der Iterationen pro Codeblock mal der Anzahl der Codeblöcke entspricht. Der Codeblock-Schwellenwert ist als ein Kompromiss zwischen den Korrekturmöglichkeiten des Turbodecodierers und dem Umfang der verwendbaren Ressourcen definiert, z.B. Hardware, MIPS, Zeit, Leistungsverbrauch, Taktfrequenz etc. Eine Verringerung des Umfangs der verwendbaren Ressourcen, zum Beispiel der Taktfrequenz, hat eine negative Auswirkung auf die Performance des Turbodecodierers.
-
Eine der Erfindung zugrunde liegende Aufgabenstellung kann darin gesehen werden, ein Verfahren zum iterativen Decodieren sowie einen interativen Decodierer zu schaffen, das bzw. der ressourcenschonend ist.
-
Die Aufgabenstellung wird durch die Merkmale der unabhängigen Ansprüche gelöst. Ausführungsformen und Weiterbildungen sind Gegenstand der abhängigen Ansprüche.
-
Die Zeichnungen liefern ein besseres Verständnis der Ausführungsformen. Die Zeichnungen stellen Ausführungsformen dar und dienen zusammen mit der Beschreibung zur Erläuterung der Prinzipien der Ausführungsformen. Weitere Ausführungsformen und viele der beabsichtigten Vorteile der Ausführungsformen werden besser verständlich, wenn sie im Zusammenhang mit der folgenden eingehenden Beschreibung gesehen werden. Gleiche Bezugsziffern bezeichnen entsprechende ähnliche Teile.
-
1 zeigt ein schematisches Diagramm, das ein Kommunikationssystem 100 darstellt, in welchem ein Decodierer für die iterative Decodierung einer Datentransferstruktur gemäß der Offenbarung eingesetzt werden kann.
-
2 zeigt ein Blockdiagramm, das einen iterativen Decodierer 200 für die Decodierung eines Codes darstellt.
-
3 zeigt ein Blockdiagramm, das einen iterativen Decodierer 300 für die Decodierung eines Turbocodes darstellt.
-
4 zeigt ein schematisches Diagramm, das einen Transportblock 400 gemäß einem Mobilfunkstandard darstellt.
-
5 zeigt ein Blockdiagramm, das einen iterativen Decodierer 500 für die Decodierung einer Datentransferstruktur darstellt.
-
6 zeigt ein schematisches Diagramm, das ein Verfahren 600 für die iterative Decodierung einer Datentransferstruktur darstellt.
-
7 zeigt ein schematisches Diagramm, das ein Verfahren 700 für die iterative Decodierung einer Datentransferstruktur darstellt.
-
8 zeigt ein beispielhaftes Histogramm 800, das eine Wahrscheinlichkeit des Auftretens für eine Anzahl von Halb-Iterationen darstellt, die zum Decodieren eines Transportblocks benötigt werden.
-
9 zeigt ein Performance-Diagramm 900, das einen beispielhaften Durchsatz für einen iterativen Decodierer gemäß der Offenbarung für verschiedene Charakteristiken von Abbruchkriterien darstellt.
-
In der folgenden Beschreibung wird Bezug auf die beigefügten Zeichnungen genommen, in welchen illustrativ spezifische Aspekte gezeigt sind, in welchen die Offenbarung ausgeführt werden kann. Es versteht sich, dass weitere Aspekte verwendet werden können, und strukturelle oder logische Änderungen vorgenommen werden können, ohne vom Konzept der vorliegenden Offenbarung abzuweichen. Die folgende eingehende Beschreibung ist daher nicht in einem einschränkenden Sinn anzusehen.
-
Die diversen aufgeführten Aspekte können in diversen Formen realisiert werden. Die folgende Beschreibung zeigt illustrativ diverse Kombinationen und Konfigurationen, in welchen die Aspekte ausgeführt werden können. Es versteht sich, dass die beschriebenen Aspekte und/oder Ausführungsformen lediglich Beispiele sind, und dass weitere Aspekte und/oder Ausführungsformen verwendet werden können sowie strukturelle und funktionale Modifikationen vorgenommen werden können, ohne vom Konzept der vorliegenden Offenbarung abzuweichen. Insbesondere versteht es sich, dass die Merkmale der diversen hierin beschriebenen beispielhaften Ausführungsformen miteinander kombiniert werden können, falls nicht ausdrücklich anders angegeben.
-
Wie in dieser Beschreibung verwendet, sollen die Ausdrücke "verbunden" und/oder "elektrisch verbunden" nicht bedeuten, dass die Elemente direkt verbunden sein müssen; Zwischenelemente können zwischen den "verbundenen" oder "elektrisch verbundenen" Elementen vorgesehen sein.
-
Die hierin beschriebenen iterativen Decodierer können in Vorrichtungen von drahtlosen Kommunikationssystemen eingesetzt werden, insbesondere in Empfängern und Transceivern. Sie können in Basisstationen ebenso wie in mobilen Stationen eingesetzt werden.
-
Die hierin beschriebenen iterativen Decodierer können ausgelegt sein zum Decodieren aller Arten von Fehlerkorrekturcodes, für welche eine iterative Decodierung verwendet werden kann, welche eine Vorwärtsrekursion und eine Rückwärtsrekursion anwendet. Insbesondere können die hierin beschriebenen iterativen Decodierer ausgelegt sein zum Decodieren von Faltungscodes und/oder verketteten Codes, z.B. parallel verketteten Faltungscodes wie z.B. Turbocodes. Derartige Decodierer können in Telekommunikationssystemen auf Grundlage des UMTS(Universal Mobile Telecommunications System)-Standards, z.B. HSDPA (High Speed Downlink Packet Access) oder HSUPA (High Speed Uplink Packet Access) und Long Term Evolution (LTE) verwendet werden.
-
Im Folgenden werden Datentransferstrukturen beschrieben. Eine Datentransferstruktur ist ein Datenpaket, das mehrere Datenunterpakete umfasst, z.B. mehrere Datenblöcke. Ein Transportblock, der mehrere Codeblocks umfasst, z.B. wie weiter unten mit Bezug auf 4 beschrieben, ist ein Beispiel für eine Datentransferstruktur. Eine Datentransferstruktur kann für den Datentransfer zwischen verschiedenen physikalischen oder logischen Einheiten verwendet werden, zum Beispiel für einen Transfer über einen Kommunikationskanal, wie weiter unten in 1 gezeigt.
-
Die im Folgenden beschriebenen Verfahren und Vorrichtungen können auf zyklischen Redundanzprüfungen beruhen. Eine zyklische Redundanzprüfung (CRC) ist ein Fehlererkennungscode zum Erkennen zufälliger (unbeabsichtigter) Änderungen an Rohdaten. In diese Systeme eintretende Datenblöcke bekommen einen kurzen Prüfwert angehängt (den so genannten CRC-Wert), der auf dem Rest einer Polynom-Division ihrer Inhalte beruhen kann. Bei Abruf wird die Berechnung wiederholt, und eine Korrekturmaßnahme kann gegen die vermutliche Datenverfälschung vorgenommen werden, falls die Prüfwerte nicht übereinstimmen.
-
1 zeigt ein schematisches Diagramm, das ein Kommunikationssystem 100 darstellt, in welchem ein Decodierer für die iterative Decodierung einer Datentransferstruktur gemäß der Offenbarung eingesetzt werden kann. Das Kommunikationssystem 100 umfasst einen Sender 101 und einen Empfänger 102, welche durch einen Funkkanal verbunden sind. Im Sender 101 werden aufeinanderfolgende Datenpakete aus einzelnen Datenbits durch eine bekannte Codiertechnik codiert (am Codierer 110). Jede dieser Codiertechniken bewirkt eine Zunahme der Bits von jedem Paket, zum Beispiel kann eine Turbocodierung in LTE eine Verdreifachung der Bitanzahl bewirken. Die codierten Datenpakete werden dann durch ein bekanntes Modulationsschema moduliert (am Modulator 120), und der modulierte Bitstrom wird einer Antenne zur Übertragung zugeführt.
-
Auf der Empfängerseite wird der empfangene Bitstrom demoduliert (am Demodulator 130), und der Empfänger 102 berechnet Softbits für jedes empfangene und demodulierte Bit (logarithmierte Wahrscheinlichkeits-Verhältnisse – Log-Likelihood Ratios), welche ein Zuverlässigkeitsmaß für das empfangene Datenpaket darstellen. Das Vorzeichen eines Softbits entspricht der Wahrscheinlichkeit eines demodulierten Bits, 0 oder 1 zu sein. Die Größe eines Softbits ist ein Maß für die Zuverlässigkeit der betreffenden Vorzeicheninformation (zum Beispiel in einem Bereich von +/–7 entsprechend einer Auflösung von 4 Bits). Die Softbits werden nun decodiert (am Decodierer 140), und die decodierten Datenpakete werden auf Decodierfehler geprüft, z.B. durch Auswerten einer zyklischen Redundanzprüfsumme (CRC).
-
Der Decodierer 140 kann einem der Decodierer für die iterative Decodierung einer Datentransferstruktur entsprechen, wie im Folgenden beschrieben. Die Berechnung einer CRC-Prüfsumme ist ein Beispiel für die Bestimmung einer Größe, die einen Decodierfehler oder einen Decodiererfolg anzeigt, wie weiter unten mit Bezug auf 5 bis 7 beschrieben. Ein weiteres derartiges Beispiel verwendet eine Decodiermetrik zum Entscheiden über einen Fehler bei oder den Erfolg der Decodierung.
-
2 zeigt einen beispielhaften iterativen Decodierer 200. Der iterative Decodierer 200 umfasst einen Decodierer 1 und eine Abbruchstufe 2. Der Decodierer 1 decodiert an einem Eingang 3 empfangene Codeblocks und weist einen Ausgang 5 auf, um eine Folge von Zuverlässigkeitsdaten zu liefern, die für Abschätzungen der ursprünglich übertragenen (systematischen) Datenbits repräsentativ sind. Weiterhin weist der Decodierer 1 einen Eingang 4 für A-priori-Informationen auf.
-
Der Decodierer 1 decodiert die am Eingang 3 empfangenen Codeblocks. Typischer Weise wird ein Codeblock durch eine Folge von Softwerten repräsentiert, welche systematische Informationen und Paritätsinformationen umfassen. Die systematische Information entspricht der ursprünglichen übertragenen Datenfolge. Die Paritätsinformation entspricht der Paritätsinformation, die von einem oder mehreren Codierern (z.B. Faltungs-Codierern) am Sender erzeugt wird.
-
Bei einer iterativen Decodierung werden die Decodierungsergebnisse, wie z.B. die am Ausgang 5 gelieferten Abschätzungen, zum Eingang 4 des Decodierers 1 zurückgeführt und werden als A-priori-Information bei der nächsten Decodierungsiteration verwendet. Diese Iteration wird fortgesetzt, bis eine Maximalanzahl der erlaubten Iterationen erreicht ist oder ein anderes Abbruchkriterium erfüllt ist.
-
Die am Ausgang 5 gelieferten Abschätzungen werden in die Abbruchstufe 2 eingegeben. Wenn das Abbruchkriterium erfüllt ist, wird der iterative Decodierprozess abgebrochen, und die Abschätzungen der systematischen Daten werden von der Abbruchstufe 2 ausgegeben. Zum Beispiel kann ein Abbruchkriterium erfüllt sein, wenn ein ausreichender Wert von Konvergenz der in folgenden Iterationen erzeugten Abschätzungen am Ausgang 5 erreicht ist.
-
Der Decodierer 1 kann als ein Symbol-für-Symbol A-posteriori-Wahrscheinlichkeits(APP)-Decodierer gestaltet sein. APP-(a-posteriori probability)-Decodierer können mit einem Trellis-Diagramm arbeiten. Ein Trellis-Diagramm ist eine Darstellung der Codiererzustände gegen die diskrete Zeit. Zum Beispiel kann der Decodierer 1 als SISO(Soft-Input-Soft-Output)-Decodierer gestaltet sein.
-
Der Decodierer 200 kann einem der Decodierer für die iterative Decodierung einer Datentransferstruktur entsprechen, wie im Folgenden beschrieben. Die Abbruchstufe 2 kann ein Abbruchkriterium verwenden, wie weiter unten mit Bezug auf 5 bis 7 beschrieben, um über den Abbruch der Decodierung zu entscheiden.
-
3 stellt den prinzipiellen Aufbau eines iterativen Decodierers 300 für die Decodierung eines Turbocodes dar. Der iterative Decodierer 300 ist gemäß den Prinzipien des in 2 gezeigten iterativen Decodierers 200 gestaltet. Genauer gesagt, kann der iterative Decodierer 300 einen ersten Komponenten-Decodierer 301, einen zweiten Komponenten-Decodierer 302 und einen Interleaver 303 umfassen, der zwischen einen Ausgang des ersten Komponenten-Decodierers 301 und einen Eingang des zweiten Komponenten-Decodierers 302 geschaltet ist.
-
Der erste Komponenten-Decodierer 301 und der zweite Komponenten-Decodierer 302 können z.B. als APP-Decodierer gestaltet sein, d.h. sie können mit dem Decodierer 1 in 2 identisch sein. Zum Beispiel können der erste Komponenten-Decodierer 301 und der zweite Komponenten-Decodierer 302 als SISO(Soft-Input-Soft-Output)-Decodierer gestaltet sein. Jeder SISO-Decodierer 301, 302 schätzt die Symbol-für-Symbol A-posteriori-Wahrscheinlichkeit ab.
-
Der iterative Decodierer 300 kann ferner einen Interleaver 304, einen De-Interleaver 305 und eine Abbruchstufe 306 umfassen. Die Abbruchstufe 306 kann ähnlich zur Abbruchstufe 2 im iterativen Decodierer 300 sein, und Bezug wird auf die entsprechende Beschreibung genommen.
-
Der erste Komponenten-Decodierer 301 empfängt am Eingang 3 systematische Daten und Paritätsdaten, die von einem Turbocodierer im Sender erzeugt werden und von einem Demodulator (nicht gezeigt) im Empfänger wiederhergestellt werden. Da das am Empfänger empfangene Signal normalerweise durch Rauschen und Störungen verzerrt ist, kann der Demodulator nur Abschätzungen der systematischen Daten und der durch den Turbocodierer erzeugten Paritätsdaten liefern. Typischerweise werden diese Abschätzungen dem Turbodecodierer 300 in Form von logarithmierten Wahrscheinlichkeitsverhältnissen (LLRs) zugeführt. LLRs drücken das Verhältnis zwischen den Wahrscheinlichkeiten der übertragenen Bits, 0 und 1 zu sein, bei gegebenem empfangenem Analogsignal aus.
-
Der erste Komponenten-Decodierer 301 arbeitet in natürlicher Reihenfolge an der Folge der systematischen Daten und der Paritätsdaten, die am Eingang 3 empfangen werden. Der erste Komponenten-Decodierer 301 berechnet die A-posteriori-Wahrscheinlichkeiten der übertragenen systematischen Daten aus den LLRs der systematischen Daten und der zugehörigen, am Eingang 3 empfangenen Paritätsdaten und aus der am Eingang 4 empfangenen A-priori-Information. Der zweite Komponenten-Decodierer 301 berechnet die A-posteriori-Wahrscheinlichkeiten der Interleaving unterzogenen systematischen Daten aus den am A-priori-Informationseingang 4 empfangenen LLRs und den zugehörigen, am Eingang 3 empfangenen, Interleaving unterzogenen Paritätsdaten. Somit wird der Ausgang des Interleavers 203 als A-priori-Information im zweiten Komponenten-Decodierer 302 verwendet.
-
In den folgenden Iterationen verwendet jeder Komponenten-Decodierer 301, 302 die von dem anderen Komponenten-Decodierer 301, 302 in der vorhergehenden Halb-Iteration ausgegebene, sogenannte extrinsische Information als A-priori-Information.
-
Es ist anzumerken, dass 3 ein vereinfachtes Blockdiagramm eines Turbodecodierers zeigt. Wie in der Technik bekannt ist, können der erste und zweite Komponenten-Decodierer 301, 302 an verschiedenen Teilen der Codeblock-Daten arbeiten. Zum Beispiel kann ein empfangener Codeblock c = (u, p1, p2) die systematische Folge u, eine erste Paritätsfolge p1 und eine zweite Paritätsfolge p2 umfassen. (Alle diese Folgen sind typische Weise durch Rauschen und Störungen verzerrt.) In diesem Fall können zum Beispiel die systematische Folge u und die erste Paritätsfolge p1 am Eingang 3 des ersten Komponenten-Decodierers 301 verwendet werden, und die Interleaving unterzogene systematische Folge uT und die zweite Paritätsfolge p2 können am Eingang 3 des zweiten Komponenten-Decodierers 301 verwendet werden.
-
Der optimale Algorithmus zum Erzeugen der APP ist der sogenannte Bahl-Cocke-Jelinek-Raviv(BCJR)-Algorithmus. Gemäß dem theoretischen BCJR-Algorithmus oder anderen sub-optimalen Algorithmen berechnet der APP-Decodierer 1, 301, 302 die Vorwärtsmetrik α und die Rückwärtsmetrik β und dann die Ausgangsmetrik (d.h. die Folge der Zuverlässigkeitsdaten; beim Decodierer 1 entspricht diese Folge den Abschätzungen der ursprünglichen übertragenen Datenfolge). Die α- und β-Metrik wird in einer Vorwärts- bzw. Rückwärtsrekursion gesammelt.
-
Der iterative Decodierer 300 kann einem der Decodierer für die iterative Decodierung einer Datentransferstruktur entsprechen, wie weiter unten mit Bezug auf 5 bis 7 beschrieben. Die Abbruchstufe 306 kann ein Abbruchkriterium verwenden, wie weiter unten mit Bezug auf 5 bis 7 beschrieben, um über den Abbruch der Decodierung zu entscheiden.
-
4 stellt einen Transportblock 400 gemäß einem Mobilfunkstandard als ein Beispiel für eine Datentransferstruktur dar. Der Transportblock 400 umfasst mehrere Codeblocks 401, 402, 413. Ein jeweiliges CRC-Feld, zum Beispiel ein einzelnes Bit oder ein Feld von Bits, das die CRC über den jeweiligen Codeblock auswertet, kann z.B. an jedem Codeblock 401, 402, 413 angebracht sein, und ein Transportblock-CRC-Feld, das die CRC über den gesamten Transportblock auswertet, kann z.B. am Transportblock angebracht sein. Der Transportblock kann gemäß einem Mobilfunkstandard spezifiziert sein, z.B. LTE (Long Term Evolution).
-
5 zeigt ein Blockdiagramm, das einen iterativen Decodierer 500 für die Decodierung einer Datentransferstruktur darstellt, die mehrere Codeblocks umfasst.
-
Der iterative Decodierer 500 weist einen Codeblock-Decodierer 501 auf, der ausgelegt ist zur iterativen Decodierung eines Codeblocks der Datentransferstruktur. Die Datentransferstruktur kann einem Daten-Transportblock 400 entsprechen, wie weiter oben in 4 gezeigt. Der iterative Decodierer 500 weist eine Berechnungsschaltung einer Größe 502 auf, die mit einem Ausgang 5 des Codeblock-Decodierers 501 verbunden ist. Die Berechnungsschaltung einer Größe 502 berechnet eine Größe, die ein (Leistungs-)Ergebnis der Decodierung des Codeblocks anzeigt, z.B. eine CRC-Prüfsumme oder eine Metrik der Decodierung wie z.B. eine Softbit-Metrik. Der iterative Decodierer 500 weist eine Berechnungsschaltung eines Abbruchkriteriums 503 zur Berechnung eines Abbruchkriteriums für die iterative Codeblock-Decodierung auf Grundlage einer vorbestimmten Anzahl der Iterationen pro Codeblock und einer vorbestimmten Anzahl der Iterationen pro Datentransferstruktur auf. Falls das Abbruchkriterium einen Fehler anzeigt, kann die Decodierung des Codeblocks in folgenden Iterationen wiederholt werden. Falls das Abbruchkriterium einen Erfolg anzeigt, kann die Decodierung des nächsten Codeblocks durchgeführt werden.
-
Der Codeblock-Decodierer 501 kann dem weiter oben mit Bezug auf 2 beschriebenen Decodierer 1 oder dem weiter oben mit Bezug auf 3 beschriebenen iterativen Decodierer 300 (ohne Abbruchstufe 306) entsprechen. Die Berechnungsschaltung des Abbruchkriteriums 503 kann der weiter oben mit Bezug auf 3 beschriebenen Abbruchstufe 306 entsprechen.
-
Die Berechnungsschaltung der Größe 502 kann eine CRC-Schaltung zur Berechnung einer zyklischen Redundanzprüfung über mindestens einen Teil des Codeblocks aufweisen. Die Berechnungsschaltung der Größe 502 kann eine Metrik-Berechnungsschaltung zur Berechnung einer Metrik der Decodierung des Codeblocks aufweisen. In einem Beispiel ist der Codeblock-Decodierer 501 ein Turbodecodierer.
-
6 zeigt ein schematisches Diagramm, das ein beispielhaftes Verfahren 600 für die iterative Decodierung einer Datentransferstruktur darstellt.
-
Die Decodierung beginnt bei 601 mit dem ersten Codeblock der Datentransferstruktur. Die Decodierung 602 führt jedes Mal eine Iteration aus. Einige Systeme beziehen sich auf zwei Halb-Iterationen, die lineare Halb-Iteration und die Interleaving unterzogene Halb-Iteration. Nach jeder Iteration prüft die Realisierung 603, ob der Codeblock korrekt decodiert werden konnte. In einigen Systemen, wie z.B. LTE-Systemen, kann dies durch Prüfen der Codeblock-CRC erreicht werden. Falls der Codeblock korrekt decodiert worden ist (CRC OK), schreitet die Decodierung 608 mit dem nächsten Codeblock der Datentransferstruktur fort, falls nicht alle Codeblocks decodiert 607 worden sind. Falls alle Codeblocks decodiert sind, kann die Decodierung erfolgreich beendet werden 609.
-
Nach jeder Iteration wird, falls der Codeblock nicht korrekt decodiert werden konnte (z.B. CRC Fehler), in einer ersten Prüfung 604 geprüft, ob die Maximalanzahl MAX_TB_IT der erlaubten Iterationen pro Datentransferstruktur erreicht worden ist. Diese Prüfung 604 zählt die bis dahin akkumulierten Iterationen für alle Codeblocks der gegenwärtigen Datentransferstruktur und vergleicht sie mit der Maximalanzahl MAX_TB_IT der erlaubten Iterationen pro Datentransferstruktur. Falls diese Maximalanzahl MAX_TB_IT erreicht ist, wird die Decodierung des Codeblocks und der gegenwärtigen Datentransferstruktur abgebrochen 606. Falls diese Maximalanzahl MAX_TB_IT nicht erreicht ist, wird in einer zweiten Prüfung 605 nach der ersten Prüfung 604 geprüft, ob die Maximalanzahl MAX_CB_IT der erlaubten Iterationen pro Codeblock erreicht worden ist. Falls die Maximalanzahl MAX_CB_IT erreicht ist, wird angenommen, dass die Decodierung des Codeblocks einen Fehler erfahren hat, und daher wird die Decodierung der Datentransferstruktur abgebrochen 606. Ansonsten führt die Decodierung eine neue Iteration 602 an demselben Codeblock durch. Die erste Prüfung 604 und die zweite Prüfung 605 können ausgetauscht werden. In einem Beispiel gelten die folgenden Beziehungen: MAX_TB_IT « NUM_CB·MAX_CB_IT, wobei NUM_CB die Anzahl der Codeblocks in einer Datentransferstruktur ist.
-
Das Verfahren 600 kann auf einen iterativen Decodierer 500 angewendet werden, wie weiter oben mit Bezug auf 6 beschrieben. Insbesondere kann die Decodierung 602 durch den Codeblock-Decodierer 501 durchgeführt werden, die Prüfung 603, ob der Codeblock korrekt decodiert worden ist, kann durch die Berechnungsschaltung der Größe 502 durchgeführt werden, und die erste Prüfung 604 mit Bezug auf MAX_TB_IT und die zweite Prüfung 605 mit Bezug auf MAX_CB_IT können durch die Berechnungsschaltung des Abbruchkriteriums 503 durchgeführt werden.
-
7 zeigt ein schematisches Diagramm, das ein Verfahren 700 zur iterativen Decodierung einer Datentransferstruktur darstellt, die mehrere Codeblocks umfasst.
-
Das Verfahren 700 ist eine Verallgemeinerung der Decodierung 602, der Prüfung 603, ob der Codeblock korrekt decodiert worden ist, und der ersten Prüfung 604 und zweiten Prüfung 605, wie weiter oben mit Bezug auf 6 beschrieben.
-
Das Verfahren 700 umfasst die Decodierung 702 eines Codeblocks der Datentransferstruktur in einer ersten Iteration. Das Verfahren 700 umfasst die Bestimmung einer Größe 703, die ein (Leistungs-)Ergebnis der Decodierung des Codeblocks anzeigt. Falls die Größe einen Decodierfehler anzeigt, umfasst das Verfahren 700 die nochmalige Decodierung des Codeblocks in folgenden Iterationen, bis ein Abbruchkriterium erreicht ist 704. Das Abbruchkriterium beruht auf (bzw. ist abhängig von) einer vorbestimmten Anzahl der Iterationen pro Codeblock und einer vorbestimmten Anzahl der Iterationen pro Datentransferstruktur, z.B. entsprechend MAX_TB_IT von der ersten Prüfung 604 und MAX_CB_IT von der zweiten Prüfung 605, wie weiter oben mit Bezug auf 6 beschrieben.
-
Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann kleiner sein als die vorbestimmte Anzahl MAX_CB_IT der Iterationen pro Codeblock mal einer Anzahl NUM_CB der in der Datentransferstruktur enthaltenen Codeblocks. Die Bestimmung der Größe 703 kann die Ausführung einer zyklischen Redundanzprüfung über mindestens einen Teil des Codeblocks beinhalten. Das Verfahren 700 kann die Decodierung eines nächsten Codeblocks der Datentransferstruktur umfassen, falls die Größe einen Erfolg anzeigt. Das Verfahren 700 kann den Abbruch 704 der Decodierung der Datentransferstruktur (Ende mit Fehler) umfassen, falls entweder die vorbestimmte Anzahl MAX_CB_IT der Iterationen pro Codeblock oder die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur erreicht ist. Die Decodierung des Codeblocks kann auf Grundlage einer Turbodecodierung stattfinden.
-
Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann variabel sein. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von einer Coderate der Decodierung abhängen. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von einer Anzahl der erneuten Übertragungen der Codeblöcke abhängen. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von einer Übertragungsbandbreite abhängen. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von einem Durchsatz der Decodierung abhängen. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von einer Taktfrequenz der Decodierung abhängen. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von einer Netzlast oder einer wahrgenommenen Netzlast am UE (User Equipment, Teilnehmergerät) abhängen. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von einem Übertragungsschema abhängen, z.B. LTE, WiFi etc. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von mindestens einem von einer Schicht, einem Kanal und einem Träger abhängen, über welche der Codeblock übertragen wird. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von einer Auswertung der Statistik der Anzahl der Iterationen abhängen, die für die Decodierung einer Datentransferstruktur benötigt werden. Die Datentransferstruktur kann ein Transportblock in einem Mobilfunkstandard sein, wie weiter oben mit Bezug auf 4 beschrieben. Die vorbestimmte Anzahl MAX_TB_IT der Iterationen pro Datentransferstruktur kann von mehreren der oben erwähnten Parameter abhängen.
-
Das Verfahren 700 kann bei einem iterativen Decodierer 500 angewendet werden, wie weiter oben mit Bezug auf 6 beschrieben. Insbesondere kann die Decodierung 702 durch den Codeblock-Decodierer 501 durchgeführt werden, die Prüfung 703, ob der Codeblock korrekt decodiert worden ist, kann durch die Berechnungsschaltung der Größe 502 durchgeführt werden, und die Prüfung des Abbruchkriteriums 704 kann durch die Berechnungsschaltung des Abbruchkriteriums 503 durchgeführt werden.
-
Die in der Offenbarung beschriebenen Verfahren und Vorrichtungen für die iterative Decodierung erlauben die Gestaltung des Systems, um ein bestimmtes begrenztes Budget von Iterationen zu unterstützen. Das gesamte Systembudget wird dann auf die Codeblöcke aufgeteilt. Das Budget muss nicht gleichmäßig unter den Codeblöcken aufgeteilt sein. Im Gegenteil kann ein bestimmter Codeblock durchaus eine größere Anzahl der Iterationen verwenden als andere Codeblöcke, falls benötigt, selbst wenn dies bedeutet, dass dann weniger Iterationen für die restlichen Codeblöcke verfügbar sind. Mit anderen Worten, die in der Offenbarung beschriebenen Verfahren und Vorrichtungen für die iterative Decodierung können statistische Diversität einsetzen und das Budget unter den Codeblöcken aufteilen bzw. ausgleichen.
-
Das Verfahren 700 kann erweitert werden, um das gesamte Systembudget der Iterationen auch zwischen verschiedenen Datentransferstrukturen aufzuteilen. Zum Beispiel kann das gesamte Systembudget für alle Schichten und/oder für alle Träger etc. definiert werden. Dann können sich die Codeblöcke verschiedener Schichten oder Träger das gleiche Systembudget von Iterationen teilen, wie im Folgenden beschrieben.
-
Das Verfahren 700 kann auf die iterative Decodierung einer Datentransferstruktur von mehreren Datentransferstrukturen erweitert werden, wobei die Datentransferstruktur mehrere Codeblöcke umfasst. Ein derartiges erweitertes Verfahren 700 umfasst: die Decodierung 702 eines Codeblocks der Datentransferstruktur in einer ersten Iteration; die Bestimmung einer Größe 703, die ein (Leistungs-)Ergebnis der Decodierung des Codeblocks anzeigt; und, falls die Größe einen Decodierfehler anzeigt, die nochmalige Decodierung des Codeblocks in folgenden Iterationen, bis ein Abbruchkriterium 704 erreicht ist. Für das erweiterte Verfahren 700 kann ein derartiges Abbruchkriterium die gesamten verfügbaren Systemressourcen auswerten. Das Abbruchkriterium 704 kann zum Beispiel auf einer vorbestimmten Anzahl MAX_CB_IT der Iterationen pro Codeblock und einer verfügbaren Gesamtanzahl der Iterationen mit Bezug auf die mehreren Datentransferstrukturen beruhen. Die verfügbare Gesamtanzahl der Iterationen mit Bezug auf die mehreren Datentransferstrukturen kann definiert werden als MAX_TB_IT·NUM_TB, wobei MAX_TB_IT die Maximalanzahl der pro Datentransferstruktur erlaubten Iterationen angibt und NUM_TB die Anzahl der Datentransferstrukturen angibt, die in den mehreren zu decodierenden Datentransferstrukturen enthalten sind.
-
In einem Beispiel ist die verfügbare Gesamtanzahl der Iterationen mit Bezug auf die mehreren Datentransferstrukturen kleiner als die vorbestimmte Anzahl MAX_CB_IT der Iterationen pro Codeblock mal einer Anzahl NUM_CB der in einer Datentransferstruktur enthaltenen Codeblöcke mal einer Anzahl NUM_TB der Datentransferstrukturen der mehreren Datentransferstrukturen.
-
Die verfügbare Gesamtanzahl der Iterationen kann zwischen den Codeblöcken von verschiedenen Schichten und/oder den Codeblöcken von verschiedenen Trägern aufgeteilt werden.
-
Das erweiterte Verfahren 700 kann ferner umfassen: die Bestimmung einer Kanalqualität der Datentransferstruktur; und die Decodierung der Codeblocks der Datentransferstruktur auf Grundlage der bestimmten Kanalqualität. Die Decodierung der Datentransferstruktur kann in Abhängigkeit von (bzw. auf Grundlage) der bestimmten Kanalqualität priorisiert werden.
-
Das erweiterte Verfahren 700, wie weiter oben beschrieben, kann bei einem iterativen Decodierer 500 angewendet werden, wie weiter oben mit Bezug auf 6 beschrieben. Insbesondere kann die Decodierung 702 durch den Codeblock-Decodierer 501 durchgeführt werden, die Prüfung 703, ob der Codeblock korrekt decodiert worden ist, kann durch die Berechnungsschaltung der Größe 502 durchgeführt werden, und die Prüfung des Abbruchkriteriums 704 kann durch die Berechnungsschaltung des Abbruchkriteriums 503 durchgeführt werden.
-
8 zeigt ein beispielhaftes Histogramm 800, das eine Wahrscheinlichkeit des Auftretens für eine Anzahl der Halb-Iterationen darstellt, die zum Decodieren eines Transportblocks unter Verwendung eines Turbodecodierers benötigt werden. 8 zeigt das Histogramm der Anzahl der Halb-Iterationen, die in einer 20 MHz-Zelle mit 100 PRBs (physikalische Ressourcenblöcke) und einem zugeordneten MCS (Modulationscodierschema) in einem LTE-Übertragungs-Szenario benötigt werden. In diesem Beispiel sind 16 Halb-Iterationen pro Codeblock erlaubt. Das bedeutet, dass der Turbodecodierer gestaltet sein kann, im schlechtesten Fall 16 Halb-Iterationen mal 13 Codeblöcke zu erlauben, d.h. 208 Halb-Iterationen pro Transportblock. Daher ist es möglich, dass der Turbodecodierer während der Decodierung 208 Halb-Iterationen pro Transportblock durchführen kann. Jedoch ist, wie man im Histogramm sehen kann, die Wahrscheinlichkeit, dass dies auftritt, äußerst gering. Mehr noch, es kann beobachtet werden, dass nur in sehr seltenen Fällen der Turbodecodierer mehr als, sagen wir, 150 Halb-Iterationen verwenden wird.
-
Die Verfahren und Vorrichtungen, wie in dieser Offenbarung beschrieben, können dieses statistische Verhalten ausnutzen. So können der iterative Decodierer 500 und die Verfahren 600, 700 für die iterative Decodierung, wie weiter oben mit Bezug auf 5 bis 7 beschrieben, gestaltet sein, um eine Maximalanzahl der Halb-Iterationen von viel weniger als die 208 Halb-Iterationen pro Transportblock zu unterstützen, die im Worst-Case-Szenario benötigt werden. Stattdessen kann nur eine bestimmte Anzahl Halb-Iterationen (zum Beispiel 150 Halb-Iterationen) pro Datentransferstruktur oder Transportblock erlaubt sein. Dies bedeutet eine große Einsparung an Hardware-Ressourcen mit einem sehr kleinen Einfluss auf die Performance.
-
9 zeigt ein Performance-Diagramm 900, das einen beispielhaften Durchsatz für einen iterativen Decodierer gemäß der Offenbarung für verschiedene Charakteristiken von Abbruchkriterien darstellt.
-
Das Übertragungs-Szenario ist eine 20 MHz-LTE-Zelle mit 100 zugeordneten PRBs. Der Einfluss auf das zugeteilte MCS wird durch die Darstellung von fünf Kurven mit verschiedenen Parametern für die Charakteristiken von Abbruchkriterien gezeigt. Die Datentransferstruktur ist durch einen Transportblock realisiert, wie durch den LTE-Mobilfunkstandard definiert.
-
Die erste Kurve 901 zeigt die Performance eines Referenz-Decodierers. 16 Halb-Iterationen pro Codeblock sind erlaubt. Das bedeutet, dass maximal 16 Halb-Iterationen mal 13 Codeblöcke, d.h. 208 Halb-Iterationen pro Transportblock erlaubt sind.
-
Die zweite Kurve 902 begrenzt die Anzahl der Halb-Iterationen pro Transportblock auf 150 Halb-Iterationen unter Verwendung eines Verfahrens, wie in dieser Offenbarung beschrieben. Der Einfluss auf die Performance ist sehr gering, und der Leistungsverbrauch des Turbodecodierers kann auf 150/208, d.h. 72%, reduziert werden.
-
Die dritte Kurve 903 begrenzt die Anzahl der Halb-Iterationen pro Transportblock auf 130 Halb-Iterationen unter Verwendung eines Verfahrens, wie in dieser Offenbarung beschrieben. Der Einfluss auf die Performance ist immer noch gering, und der Leistungsverbrauch des Turbodecodierers kann auf 130/208, d.h. 62%, reduziert werden.
-
Die vierte Kurve 904 begrenzt die Anzahl der Halb-Iterationen pro Transportblock auf 100 Halb-Iterationen unter Verwendung eines Verfahrens, wie in dieser Offenbarung beschrieben. Der Einfluss auf die Performance ist groß, wenn auch der Leistungsverbrauch des Turbodecodierers auf 100/208, d.h. 48%, reduziert werden kann.
-
Die fünfte Kurve 905 zeigt den Einfluss auf die Performance bei einem Turbodecodierer, der ein auf dem schlechtesten Fall beruhendes Abbruchkriterium verwendet, d.h. die Anzahl der erlaubten Iterationen entspricht der Maximalanzahl MAX_CB_IT der pro Codeblock erlaubten Iterationen mal der Anzahl NUM_CB der Codeblöcke in einem Transportblock, um ähnliche Leistungseinsparungen zu erzielen. Für derartige ähnliche Leistungseinsparungen muss die Anzahl MAX_CB_IT der pro Codeblock erlaubten Iterationen auf 11 vermindert werden. Mit 11 Halb-Iterationen pro Codeblock ist die Maximalanzahl der benötigten Halb-Iterationen 143. Es kann beobachtet werden, dass für eine ähnliche Leistungseinsparung der Einfluss auf die Performance viel größer als bei den Verfahren und Vorrichtungen ist, wie in dieser Offenbarung beschrieben.
-
In Szenarios mit hohem Durchsatz werden relativ gute Kanalbedingungen erwartet. Daher tendieren die Standards dazu, ziemlich hohe Coderaten für derartige Szenarios zu spezifizieren. Mehr noch, auch die erneuten Übertragungen tendieren dazu, einen Energiegewinn größer als einen Codiergewinn beizutragen. Dies ist der Fall für LTE mit einer Bandbreite von 20 MHz. Für den maximalen Durchsatz und höhere Coderaten definiert der LTE-Standard einen begrenzten Ratenanpassungspuffer (Limited Buffer Rate Matching, LBRM). Als Ergebnis ist bei derartigen Szenarios mit hohem Durchsatz die durchschnittliche Anzahl der benötigten Iterationen am Turbodecodierer geringer als in Fällen mit geringerer Coderate. Im Allgemeinen kann, je größer der Codiergewinn (je geringer die Coderate) ist, desto größer der Turbodecodierergewinn durch Durchführen von mehr Iterationen sein. Daher können unter derartigen Bedingungen (LTE, 20 MHz, LBRM) die Verfahren und Vorrichtungen, wie in dieser Offenbarung beschrieben, eine bessere Anpassung liefern, wie man in 9 sehen kann.
-
In dieser Offenbarung wird ein iterativer Decodierungs-Algorithmus beschrieben, der eine Verminderung der benötigten Gesamtanzahl der Iterationen über eine Datentransferstruktur oder einen Transportblock erlaubt. Die Verfahren und Vorrichtungen, wie in dieser Offenbarung beschrieben, können auf einem hybriden Schwellenwertverfahren für das Abbruchkriterium der Decodierung in Verbindung mit einem frühen Codeblock-Abbruchkriterium beruhen. Der iterative Decodierer kann die Decodierung eines Codeblocks abbrechen, wenn der Codeblock erfolgreich decodiert ist (frühes Abbruchkriterium), und kann mit dem folgenden Codeblock fortfahren. Der iterative Decodierer kann einen ersten Schwellenwert für die Maximalanzahl der Iterationen pro Codeblock an jedem Codeblock implementieren. Ein zweiter Schwellenwert kann dann für eine maximale Summe der Iterationen über die gesamte Datentransferstruktur zugefügt werden. Somit kann während des Decodierprozesses die Decodierung zu jedem Zeitpunkt abbrechen, an dem die Summe der Iterationen für die bereits verarbeiteten Codeblöcke die Maximalanzahl der erlaubten Iterationen pro Datentransferstruktur überschreitet, oder zu jedem Zeitpunkt, an dem die Iterationen für einen Codeblock die Maximalanzahl der erlaubten Iterationen pro Codeblock überschreiten. Dieser Schwellenwert für die Datentransferstruktur kann signifikant kleiner als die Maximalanzahl der Iterationen pro Codeblock mal der Anzahl der Codeblöcke sein. Damit können die verwendeten Ressourcen, d.h. Hardware, MIPS, Zeit, Leistungsverbrauch, Taktfrequenz etc., signifikant verringert werden, während sehr ähnliche Korrekturfähigkeiten beibehalten werden.
-
BEISPIELE
-
Beispiel 1 ist ein Verfahren zum iterativen Decodieren einer Datentransferstruktur, die mehrere Codeblöcke umfasst, wobei das Verfahren umfasst: die Decodierung eines Codeblocks der Datentransferstruktur in einer ersten Iteration; die Bestimmung einer Größe, die ein (Leistungs-)Ergebnis der Decodierung des Codeblocks anzeigt; falls die Größe einen Decodierfehler anzeigt, die nochmalige Decodierung des Codeblocks in folgenden Iterationen, bis ein Abbruchkriterium erreicht ist, wobei das Abbruchkriterium auf einer vorbestimmten Anzahl der Iterationen pro Codeblock und einer vorbestimmten Anzahl der Iterationen pro Datentransferstruktur beruht (bzw. hiervon abhängig ist).
-
In Beispiel 2 kann der Gegenstand von Beispiel 1 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur kleiner ist als die vorbestimmte Anzahl der Iterationen pro Codeblock mal einer Anzahl der in der Datentransferstruktur enthaltenen Codeblöcke.
-
In Beispiel 3 kann der Gegenstand eines der Beispiele 1–2 optional beinhalten, dass die Bestimmung der Größe die Ausführung einer zyklischen Redundanzprüfung über mindestens einen Teil des Codeblocks umfasst.
-
In Beispiel 4 kann der Gegenstand eines der Beispiele 1–3 optional die Decodierung eines nächsten Codeblocks der Datentransferstruktur beinhalten, falls die Größe einen Erfolg anzeigt.
-
In Beispiel 5 kann der Gegenstand eines der Beispiele 1–4 optional den Abbruch der Decodierung der Datentransferstruktur beinhalten, falls entweder die vorbestimmte Anzahl der Iterationen pro Codeblock oder die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur erreicht ist.
-
In Beispiel 6 kann der Gegenstand eines der Beispiele 1–5 optional beinhalten, dass die Decodierung des Codeblocks auf einer Turbodecodierung beruht.
-
In Beispiel 7 kann der Gegenstand eines der Beispiele 1–6 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur variabel ist.
-
In Beispiel 8 kann der Gegenstand eines der Beispiele 1–7 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur von einer Coderate der Decodierung abhängt.
-
In Beispiel 9 kann der Gegenstand eines der Beispiele 1–8 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur von einer Anzahl von erneuten Übertragungen der Codeblöcke abhängt.
-
In Beispiel 10 kann der Gegenstand eines der Beispiele 1–9 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur von einer Übertragungsbandbreite abhängt.
-
In Beispiel 11 kann der Gegenstand eines der Beispiele 1–10 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur von einem Durchsatz der Decodierung abhängt.
-
In Beispiel 12 kann der Gegenstand eines der Beispiele 1–11 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur von einer Taktfrequenz der Decodierung abhängt.
-
In Beispiel 13 kann der Gegenstand eines der Beispiele 1–12 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur von einem Übertragungsschema abhängt.
-
In Beispiel 14 kann der Gegenstand eines der Beispiele 1–13 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur von mindestens einem von einer Schicht, einem Kanal und einem Träger abhängt, über welche der Codeblock übertragen wird.
-
In Beispiel 15 kann der Gegenstand eines der Beispiele 1–14 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur von einer Auswertung der Statistik der Anzahl der Iterationen abhängt, welche für die Decodierung einer Datentransferstruktur benötigt werden.
-
In Beispiel 16 kann der Gegenstand eines der Beispiele 1–15 optional beinhalten, dass die Datentransferstruktur ein Transportblock in einem Mobilfunkstandard ist.
-
Beispiel 17 ist ein iterativer Decodierer für die iterative Decodierung einer Datentransferstruktur, die mehrere Codeblöcke enthält, wobei der iterative Decodierer umfasst: einen Codeblock-Decodierer, der ausgelegt ist zur iterativen Decodierung eines Codeblocks der Datentransferstruktur; eine Berechnungsschaltung einer Größe, die ausgelegt ist zur Berechnung einer Größe, die ein (Leistungs-)Ergebnis der Decodierung des Codeblocks anzeigt; eine Berechnungsschaltung eines Abbruchkriteriums, die ausgelegt ist zur Berechnung eines Abbruchkriteriums für die iterative Codeblock-Decodierung auf Grundlage einer vorbestimmten Anzahl der Iterationen pro Codeblock und einer vorbestimmten Anzahl der Iterationen pro Datentransferstruktur.
-
In Beispiel 18 kann der Gegenstand von Beispiel 17 optional beinhalten, dass die Berechnungsschaltung der Größe eine CRC-Schaltung umfasst, die ausgelegt ist zur Berechnung einer zyklischen Redundanzprüfung über mindestens einen Teil des Codeblocks.
-
In Beispiel 19 kann der Gegenstand von Beispiel 17 optional beinhalten, dass die Berechnungsschaltung der Größe eine Metrik-Berechnungsschaltung umfasst, die ausgelegt ist zur Berechnung einer Metrik der Decodierung des Codeblocks.
-
In Beispiel 20 kann der Gegenstand eines der Beispiele 17–19 optional beinhalten, dass der Codeblock-Decodierer einen Turbodecodierer umfasst.
-
Beispiel 21 ist ein Verfahren zum iterativen Decodieren einer Datentransferstruktur von mehreren Datentransferstrukturen, wobei die Datentransferstruktur mehrere Codeblöcke umfasst, wobei das Verfahren umfasst: die Decodierung eines Codeblocks der Datentransferstruktur in einer ersten Iteration; die Bestimmung einer Größe, die ein (Leistungs-)Ergebnis der Decodierung des Codeblocks anzeigt; und falls die Größe einen Decodierfehler anzeigt, die nochmalige Decodierung des Codeblocks in folgenden Iterationen, bis ein Abbruchkriterium erreicht ist, wobei das Abbruchkriterium auf einer vorbestimmten Anzahl der Iterationen pro Codeblock und einer verfügbaren Gesamtanzahl der Iterationen mit Bezug auf die mehreren Datentransferstrukturen beruht.
-
In Beispiel 22 kann der Gegenstand von Beispiel 21 optional beinhalten, dass die verfügbare Gesamtanzahl der Iterationen kleiner ist als die vorbestimmte Anzahl der Iterationen pro Codeblock mal einer Anzahl der in der Datentransferstruktur enthaltenen Codeblöcke mal einer Anzahl der Datentransferstrukturen der mehreren Datentransferstrukturen.
-
In Beispiel 23 kann der Gegenstand eines der Beispiele 21–22 optional beinhalten, dass die verfügbare Gesamtanzahl der Iterationen zwischen den Codeblöcken von verschiedenen Schichten und/oder den Codeblöcken von verschiedenen Trägern aufgeteilt ist.
-
In Beispiel 24 kann der Gegenstand eines der Beispiele 21–23 optional die Bestimmung einer Kanalqualität der Datentransferstruktur beinhalten; und die Decodierung der Codeblöcke der Datentransferstruktur auf Grundlage der bestimmten Kanalqualität.
-
In Beispiel 25 kann der Gegenstand von Beispiel 24 optional beinhalten, dass die Decodierung der Datentransferstruktur in Abhängigkeit von der bestimmten Kanalqualität priorisiert wird.
-
Beispiel 26 ist ein computerlesbares Medium, auf welchem Computeranweisungen gespeichert sind, welche bei Ausführung durch einen Computer bewirken, dass der Computer das Verfahren gemäß einem der Beispiele 1 bis 16 und 21 bis 25 ausführt.
-
Beispiel 27 ist ein iterativer Decodierer für die iterative Decodierung einer Datentransferstruktur, die mehrere Codeblöcke umfasst, wobei der iterative Decodierer umfasst: ein Decodierungsmittel für die Decodierung eines Codeblocks der Datentransferstruktur in einer ersten Iteration; ein Bestimmungsmittel für die Bestimmung einer Größe, die ein (Leistungs-)Ergebnis der Decodierung des Codeblocks anzeigt; falls die Größe einen Decodierfehler anzeigt, ist das Decodierungsmittel ausgelegt zum nochmaligen Decodieren des Codeblocks in folgenden Iterationen, bis ein Abbruchkriterium erreicht ist, wobei das Abbruchkriterium auf einer vorbestimmten Anzahl der Iterationen pro Codeblock und einer vorbestimmten Anzahl der Iterationen pro Datentransferstruktur beruht.
-
In Beispiel 28 kann der Gegenstand von Beispiel 27 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur kleiner ist als die vorbestimmte Anzahl der Iterationen pro Codeblock mal einer Anzahl der in der Datentransferstruktur enthaltenen Codeblöcke.
-
In Beispiel 29 kann der Gegenstand eines der Beispiele 27–28 optional beinhalten, dass das Bestimmungsmittel ausgelegt ist zum Ausführen einer zyklischen Redundanzprüfung über mindestens einen Teil des Codeblocks.
-
In Beispiel 30 kann der Gegenstand eines der Beispiele 27–29 optional beinhalten, dass das Decodierungsmittel ausgelegt ist zum Decodieren eines nächsten Codeblocks der Datentransferstruktur, falls die Größe einen Erfolg anzeigt.
-
In Beispiel 31 kann der Gegenstand eines der Beispiele 27–30 optional ein Abbruchmittel für den Abbruch der Decodierung der Datentransferstruktur beinhalten, falls entweder die vorbestimmte Anzahl der Iterationen pro Codeblock oder die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur erreicht ist.
-
In Beispiel 32 kann der Gegenstand eines der Beispiele 27–31 optional beinhalten, dass das Decodierungsmittel ausgelegt ist zum Decodieren des Codeblocks auf Grundlage einer Turbodecodierung.
-
In Beispiel 33 kann der Gegenstand eines der Beispiele 27–32 optional beinhalten, dass die vorbestimmte Anzahl der Iterationen pro Datentransferstruktur variabel ist.
-
Beispiel 34 ist ein Übertragungssystem, welches umfasst: einen Sender, der ausgelegt ist zum Senden einer Datentransferstruktur über einen Übertragungskanal, und einen Empfänger, wobei der Empfänger einen iterativen Decodierer gemäß einem der Beispiele 17–20 umfasst.
-
In Beispiel 35 kann der Gegenstand von Beispiel 34 optional beinhalten, dass der Sender ein OFDM-Sender ist, und der Empfänger ein OFDM-Empfänger ist.
-
In Beispiel 36 kann der Gegenstand eines der Beispiele 34–35 optional beinhalten, dass der Empfänger ausgelegt ist zum Verarbeiten einer an einem Empfangsanschluss des Empfängers empfangenen Datentransferstruktur in Reaktion auf eine am Sender gesendete Datentransferstruktur.
-
In Beispiel 37 kann der Gegenstand eines der Beispiele 34–36 optional beinhalten, dass der Sender einen Codierer umfasst, der ausgelegt ist zum Codieren eines Datenpakets, was ein codiertes Datenpaket ergibt; und einen Modulator, der ausgelegt ist zum Modulieren des die Datentransferstruktur liefernden codierten Datenpakets.
-
In Beispiel 38 kann der Gegenstand eines der Beispiele 34–37 optional beinhalten, dass der Empfänger einen Demodulator umfasst, der ausgelegt ist zum Demodulieren der empfangenen Datentransferstruktur; und einen Decodierer, der ausgelegt ist zum Decodieren der demodulierten Datentransferstruktur.
-
Weiterhin kann, wenn ein bestimmtes Merkmal oder ein bestimmter Aspekt der Offenbarung mit Bezug auf nur eine von mehreren Realisierungen offenbart worden sein kann, ein derartiges Merkmal oder ein derartiger Aspekt mit einem oder mehreren anderen Merkmalen oder Aspekten der anderen Realisierungen kombiniert werden, wie es für eine gegebene Anwendung gewünscht oder vorteilhaft sein kann. Weiterhin sollen in dem Maße, in dem die Ausdrücke "beinhalten", "aufweisen", "mit" oder andere Varianten davon in entweder der eingehenden Beschreibung oder den Ansprüchen verwendet werden, derartige Ausdrücke einschließend sein, ähnlich dem Ausdruck "umfassen". Weiterhin versteht es sich, dass Aspekte der Offenbarung in diskreten Schaltungen, teilweise integrierten Schaltungen oder vollständig integrierten Schaltungen oder Programmiermitteln realisiert werden können. Ebenso sollen die Ausdrücke "beispielhaft", "zum Beispiel" und "z.B." lediglich ein Beispiel bezeichnen, und nicht das Beste oder Optimale.
-
Obwohl spezifische Aspekte dargestellt und hierin beschrieben worden sind, ist dem Fachmann bekannt, dass eine Vielzahl von alternativen und/oder äquivalenten Realisierungen die spezifischen gezeigten und beschriebenen Aspekte ersetzen kann, ohne vom Konzept der vorliegenden Offenbarung abzuweichen.