DE10310812B4

DE10310812B4 - Dekodiervorrichtung, Trellis-Prozessor und Verfahren

Info

Publication number: DE10310812B4
Application number: DE10310812A
Authority: DE
Inventors: Thomas Herndl; Jens Berkmann; Burkhard Becker
Original assignee: Infineon Technologies AG
Current assignee: Intel Deutschland GmbH
Priority date: 2003-03-12
Filing date: 2003-03-12
Publication date: 2007-11-22
Anticipated expiration: 2023-03-13
Also published as: US7269777B2; DE10310812A1; CN1531212A; US20040199858A1; CN100392987C

Abstract

Dekodiervorrichtung, die zumindest einen Dekodierer (13) sowohl für eine Turbo-Dekodierung als auch für eine Viterbi-Dekodierung aufweist,
mit einem ersten Datenpfad (40, 41, 42, 44) zur Viterbi-Dekodierung eines Faltungs-Codes und mit einem zweiten Datenpfad (40-45) zur Dekodierung eines Turbo-Codes, wobei zumindest Teile des ersten Datenpfades (40-42, 44) und des zweiten Datenpfades (40-45) gemeinsam sowohl zur Turbo-Dekodierung als auch zur Viterbi-Dekodierung nutzbar sind;
mit einem gemeinsamen Speicher (21), der eine Vielzahl von einzelnen Speicherbereichen (31-34) aufweist, vorgesehen ist, wobei zumindest ein Speicherbereich (31-34) sowohl über den ersten Datenpfad (40-42, 44) im Viterbi-Mode als auch über den zweiten Datenpfad (40-45) im Turbo-Mode allokierbar ist.

Description

Die Erfindung betrifft eine Dekodiervorrichtung mit einem Dekodierer sowohl für eine Turbo-Dekodierung als auch eine Viterbi-Dekodierung, einen Trellis-Prozessor sowie ein Verfahren zum Betreiben der Dekodiereinrichtung.
In Kommunikationssystemen, beispielsweise in Mobilfunksystemen, wird das zu übertragende Signal sendeseitig nach einer Aufbereitung einer Kanalkodierung unterzogen. Die Kanalkodierung dient dem Zweck, dem zu übertragenden Signal eine Redundanz zuzufügen, mit deren Hilfe das Signal nach der Übertragung über einen gestörten Kanal möglichst fehlerfrei zurückgewonnen werden kann. Dabei wird durch gezieltes Einbringen von Redundanzen in das zu übertragende Signal ein effektiver Fehlerschutz realisiert.
Zur Kodierung bzw. Dekodierung der zu übertragenden Signale existieren verschiedene Kodier-/Dekodierverfahren:
Herkömmliche Faltungs-Kodierer bzw. Faltungs-Dekodierer (Viterbi-Dekodierer)
Bei herkömmlichen Faltungs-Dekodierern wird zwischen Symbolschätzern – die nach einem symbolweisen Algorithmus arbeiten – und Folgenschätzern unterschieden. Eine spezielle Form eines Symbolschätzers ist ein sogenannter MAP-Symbolschätzer (MAP = Maximum A Posteriori), der nach dem sogenannten MAP-Algorithmus arbeitet. MAP-Symbolschätzer weisen den Vorteil auf, dass mit ihnen ein geringst mögliches Bit-Fehlerverhältnis realisierbar ist.
Ein Entzerrer (bzw. ein Rake-Empfänger) liefert Schätzwerte der übertragenen Symbole oder Bits, die als Soft-Input-Werte (ein Vorzeichen-Bit plus eine Zuverlässigkeitsinformation) an den Dekodierer geliefert werden. Die Soft-Inputwerte enthalten dann immer noch eine Redundanz, aus denen der Dekodierer die ursprünglichen nicht-kodierten Werte ohne Redundanz zurückzugewinnen versucht. Dabei können harte Dekodier-Entscheidungswerte geliefert werden (Hard Outputs), die sich aus der Bitfolge des Maximum-Likelihood-Pfads ergeben. Darüber hinaus können auch weiche Dekodier-Entscheidungswerte (Soft-Outputs), bei denen die Bitfolge des Maximum-Likelihood-Pfads in Relation zu anderen, eventuell vorhanden konkurrierenden Pfaden gesetzt wird, geliefert werden. Es gibt auch weiche Dekodier-Entscheidungswerte, die aufgrund eines Symbol-Schätzers gewonnen werden und dementsprechend auch konkurrierende Übergänge berücksichtigen.
Turbo-Kodierer:
Ein erst in den vergangenen Jahren entwickeltes und eingesetztes Kanalkodierverfahren verwendet binäre, verkettete, rekursive systematische Faltungscodes, für die sich die Bezeichnung „Turbo-Code" eingebürgert hat. Insbesondere bei der Übertragung sehr großer Datenblöcke mit mehr als 1.000 Bits (Symbolen) kann mit Turbo-Kodierern ein erheblich verbesserter Fehlerschutz als mit den üblicherweise verwendeten Faltungs-Kodierern erzielt werden.
Zum Dekodieren solcher Turbo-Codes wird empfängerseitig ein iterativer Turbo-Code-Dekodierer – nachfolgend auch als Turbo-Dekodierer bezeichnet – eingesetzt. Ein Turbo-Dekodierer besteht aus einer Verkettung von mindestens zwei binären, rekursiven Faltungsdekodieren, die rückkopplungsartig miteinander verschachtelt sind. Der Turbo-Dekodierer macht die Turbo-Kodierung rückgängig und benutzt die der systematischen Information aufgeprägten Redundanzwerte, um die systematische Information nach der Übertragung über einen gestörten Ausbreitungspfad möglichst fehlerfrei zurückzugewinnen.
Der genaue Aufbau und die genaue Funktionsweise eines vorstehend beschriebenen Turbo-Dekodierers ist zum Beispiel aus dem als nächstliegenden Stand der Technik angesehenen Buch von Peter Jung „Analyse und Entwurf digitaler Mobilfunksysteme", Stuttgart, B. G. Täubner, 1997, insbesondere auf den Seiten 343 bis 368, beschrieben.
Turbo-Codes weisen die folgenden Vorteile auf:

1. Turbo-Codes erlauben selbst für kurze Datenblöcke eine sehr gute Übertragungsqualität und sind daher insbesondere für die Sprachübertragung geeignet.
2. Mittels Turbo-Codes lässt sich bei der Übertragung sehr großer Datenmengen ein erheblich verbesserter Fehlerschutz realisieren.
3. Turbo-Codes sind besonders für solche Kommunikationssysteme geeignet, die viele unterschiedliche Dienste und Anwendungen flexibel bereitstellen müssen, wie dies bei digitalen zellularen Mobilfunksystemen der Fall ist.

Turbo-Codes haben im Vergleich zu herkömmlichen Kodierern jedoch folgende Nachteile:

1. Die Dekodierung von Turbo-Codes ist sehr viel aufwendiger als die Dekodierung herkömmlicher Faltungs-Codes, bei denen keine rekursiven Iterationsschritte vorgenommen werden.
2. Bei einem Turbo-Dekodierverfahren, das die einzelnen Faltungsdekodierer nach dem (LOG)MAP Prinzip (MAP = Maximum a-Posteriori) auslegt, müssen die möglicherweise zeitvariante Amplitude des Empfangssignals als auch die mögli cherweise zeitvariante Varianz des Störsignals absolut bekannt sein, bzw. mit hinreichender Genauigkeit geschätzt werden, damit die gewünschte Übertragungsqualität realisierbar ist. Für einen MAX-LOG-MAP-Dekodierer ist nur eine relative Kenntnis dieser Größen erforderlich, was allerdings mit einem Performance-Verlust einhergeht. Die Amplituden und die Varianz der additiven weißen normalverteilten Störung müssen dem Turbo-Dekodierer bekannt sein, damit die gewünschte Dekodierqualität realisierbar ist. Dies ist im Mobilfunk wegen der Zeitvarianz des Mobilfunkkanals nicht immer möglich. Sind die Amplituden und die Varianz jedoch nicht genau bekannt, reduzieren sich die mit Turbo-Codes gegenüber konventionellen Faltungs-Codes erreichbare Verbesserungen der Dekodierqualität signifikant.

Aus den genannten Gründen sollte eine Dekodiervorrichtung bei modernen Mobilfunksystemen in der Lage sein, sowohl Turbo-Codes zu dekodieren als auch herkömmliche Faltungs-Codes.
Dieses Problem wird bislang dadurch gelöst, dass für jede unterschiedliche Dekodierung ein eigens dafür vorgesehener Dekodierer bereitgestellt wird. Jeder dieser Dekodierer weist seinen eigenen Datenpfad, in dem die Elemente des Dekodierers angeordnet sind, und einen eigenen Speicher, der jeweils nur von eben diesem Dekodierer allokierbar ist, auf. Neben diesen Elementen enthüllt ein jeweiliger Dekodierer einen ihm zugeordneten eigenen Dateneingang und typischerweise auch einen eigenen Datenausgang auf. Schließlich sind auch andere Funktionselemente des Dekodierers jeweils getrennt voneinander vorgesehen.
An heutige und zukünftige Mobilfunksysteme werden jedoch die Anforderungen gestellt, Systeme mit immer größerer Funktionalität auf immer kleinerem Raum zu integrieren um damit ein kostengünstiges System bereitzustellen. Dies resultiert aus der Tatsache, dass der Kostendruck insbesondere bei Mobil funksystemen mittlerweile der bestimmende Faktor ist, mit dem sich im Wesentlichen funktions- und qualitätsgleiche Systeme auf dem Markt voneinander unterscheiden. Aus diesem Grunde ist es kontraproduktiv und zunehmend nicht mehr akzeptabel, ein System bereitzustellen, bei dem unerwünschte Redundanzen gewissermaßen dadurch entstehen, dass für unterschiedliche Datenkanäle funktionsgleiche Einheiten mehrfach vorhanden sind. Insbesondere bei sehr großen zu übertragenden Datenmengen ist dies bei Speichern besonders gravierend, da diese Speicher somit sehr groß dimensioniert sein müssten. Solche Speicher sind damit der Chipflächen bestimmende Faktor auf dem Halbleiterchip. Es besteht daher der Bedarf, solche Chipflächen bestimmenden Funktionsblöcke zumindest teilweise gemeinsam zu nutzen.
In der Druckschrift US 2002/0119803 A1 ist eine Dekodiervorrichtung beschrieben, die sowohl einen Turbodekodierer als auch einen konventionellen, beispielsweise als Viterbi-Dekodierer ausgebildeten Dekodierer aufweist. Diese getrennt ausgebildeten Dekodierer greifen jeweils auf unterschiedliche Speicherbereiche zu und nutzen auch unterschiedliche Datenpfade.
Auch die WO 02/21699 A2 und die EP 653847 A2 beschreiben jeweils Dekodiervorrichtungen.
Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, eine schaltungstechnisch vereinfachte Dekodiereinrichtung zur Verfügung zu stellen sowie ein Verfahren zum Betreiben dieser Dekodiereinrichtung anzugeben.
Erfindungsgemäß wird diese Aufgabe durch eine Dekodiereinrichtung mit den Merkmalen des Patentanspruchs 1, ein Trellis-Prozessor mit den Merkmalen des Patentanspruchs 20 sowie zwei Verfahren mit den Merkmalen der Patentansprüche 21 und 22 gelöst.
Demgemäß ist vorgesehen:

– Eine Dekodiervorrichtung, die zumindest einen Dekodierer sowohl für eine Turbo-Dekodierung als auch für eine Viterbi-Dekodierung aufweist, mit einem ersten Datenpfad zur Viterbi-Dekodierung eines Faltungs-Codes und mit einem zweiten Datenpfad zur Dekodierung eines Turbo-Codes, wobei zumindest Teile des ersten Datenpfades und des zweiten Datenpfades gemeinsam sowohl zur Turbo-Dekodierung als auch zur Viterbi-Dekodierung nutzbar sind; mit einem gemeinsamen Speicher, der eine Vielzahl von einzelnen Speicherbereichen aufweist, vorgesehen ist, wobei zumindest ein Speicherbereich sowohl über den ersten Datenpfad im Viterbi-Mode als auch über den zweiten Datenpfad im Turbo-Mode allokierbar ist.
– Ein Trellis-Prozessor für eine Dekodiervorrichtung nach wenigstens einem der vorstehenden Ansprüche, bei dem der Trellis-Prozessor sowohl in einem Viterbi-Dekodiermodus für einen Faltungscode als auch in einem Dekodiermodus für einen Turbo-Code betreibbar ist und bei dem der Trellis-Prozessor bei den verschiedenen Betriebsmodi sowohl die Datenpfade wie auch die Speicherbereiche zumindest teilweise gemeinsam nutzt.
– Ein Verfahren zum Betreiben einer solchen Dekodiereinrichtung, bei dem zumindest eine erste Dekodierung unter Verwendung eines exakten Viterbi-Algorithmus implementiert wird und/oder zumindest eine zweite Dekodierung unter Verwendung des MAP-Algorithmus oder eines Turbo-Codes implementiert wird. (Patentanspruch 21)
– Ein Verfahren zum Betreiben einer solchen Dekodiereinrichtung, bei dem die Traceback-Werte des gesamten Trellis-Diagrammes in einem Speicher abgespeichert werden. (Patentanspruch 22)

Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind den Unteransprüchen sowie der Beschreibung unter Bezugnahme auf die Zeichnung entnehmbar.
Die der vorliegenden Erfindung zugrunde liegende Idee besteht darin, alle verschiedenen Dekodierer-Funktionen auf einen gemeinsamen lokalen Speicherbereich operieren zu lassen. Zusätzlich oder alternativ kann auch vorgesehen sein, dass zumindest ein Teil der unterschiedlichen Dekodierer-Funktionen der verschiedenen Betriebsmodi gemeinsam genutzt werden. Der vorliegenden Erfindung liegt die Erkenntnis zugrunde, dass verschiedene Dekodierer-Funktionen redundant sind, das heißt bei verschiedenen Dekodier-Modi doppelt vorhanden sind.
Darüber hinaus ist bei der Dekodier-Einrichtung stets lediglich ein Dekodier-Modus aktiv, so dass auch lediglich ein einziger Speicher für eben den aktiven Dekodier-Modus vorhanden sein muss. Auf das doppelte oder mehrfache Vorsehen eines jeweiligen Speichers für die unterschiedlichen Dekodier-Betriebsmodi kann so verzichtet werden. Es ist lediglich darauf zu achten, dass die Speichergröße auf die maximal erforderliche Speichergröße, typischerweise für die Speichergröße der Turbo-Dekodierung, ausgelegt ist.
Darüber ist eine Steuereinrichtung vorgesehen, über die die Speicherplatzbelegung auf die unterschiedlichen Betriebs-Dekodier-Modi ausgelegt ist. Insbesondere müssen hier eigens für die verschiedenen Dekodierer-Funktionen vorgesehene Speicherbereiche den einzelnen Dekodier-Modi zugeordnet sein. Neben der Verwendung eines gemeinsamen Speichers für die Dekodier-Einrichtung ist es damit möglich, ohnehin vorhandene Hardware-Datenpfade, wie zum Beispiel ACS-Einheiten (ACS = Add-Compare-Select) und Einheiten zur Übergangsmetrik-Bestimmung sowohl für Turbo-Dekodierung als auch für Viterbi-Dekodierung gemeinsam zu nutzen, was sich bei einer hoch parallelisierten Implementierung auf die Reduzierung der Chipfläche auswirkt.
In einer vorteilhaften Ausgestaltung ist insbesondere der Datenpfadbereich des Dekodierers in fest verdrahteter Logik ausgebildet. Denkbar wäre jedoch auch eine andere Ausgestaltung, zum Beispiel eine Implementierung dieser Elemente in einer Programm gesteuerten Einheit.
Der erste Datenpfad ist für eine Viterbi-Dekodierung und der zweite Datenpfad für eine Turbo-Dekodierung ausgelegt.
In einer ersten Ausgestaltung kann der erste Datenpfad zur sogenannten Hard-Output-Viterbi-Algorithmus-Dekodierung ausgelegt sein. In einer besonders vorteilhaften Ausgestaltung kann vorgesehen sein, dass hier ein exakter Hard-Output-Viterbi-Algorithmus vorgesehen ist, bei dem somit keine Fenster basierte Dekodierung vorgenommen wird. In einer zweiten Ausgestaltung kann der erste Datenpfad auch zur Soft-Output-Viterbi-Algorithmus-Dekodierung ausgelegt sein. Unter SOVA und HDVA ist demnach eine spezielle Form einer Viterbi-Dekodierung zu verstehen.
In einer Ausgestaltung kann der zweite Datenpfad in einem Log-MAP-Modus bzw. in einem MAX-Log-MAP-Modus als Bestandteil der Turbo-Dekodierung betrieben werden. Der MAP-Dekodiermodus besteht aus einer Vorwärts- und Rückwärtsrekursion, wobei hier symbolweise geschätzt wird. Der MAP-Dekodiermodus ist somit Bestandteil eines Turbo-Dekodierers, der zwischen zwei MAP-Schritten zusätzlich noch ein Turbo-Block-Interleaving bzw. Turbo-Block-Deinterleaving durchführt. Unter einem MAP, LOG-MAP bzw. MAX-Log-MAP ist demnach eine spezielle Form einer Turbo-Code-Dekodierung zu verstehen.
Bei den gemeinsam genutzten Elementen der Datenpfade der Dekodiereinrichtung kann es sich beispielsweise um ACS-Einheiten oder BM-Einheiten (BM = Branch Metric) handeln, die der Übergangsmetrik-Bestimmung dienen. Bei den gemeinsam genutzten Speicherbereichen, die sowohl im Turbo-Dekodier-Modus als auch im Viterbi-Dekodier-Modus verwendet werden, kann es sich zum Beispiel um Speicherbereiche zur Abspeicherung von Soft-Input-Daten, von Übergangsmetrik-Daten und von sogenannten Log-Likelihood-Ratio-Daten handeln. Darüber hinaus wäre selbstverständlich auch eine andere Speicherbereichaufteilung denkbar.
In einer Ausgestaltung der Erfindung ist ein Speicherbereich des gemeinsamen Speichers zur Abspeicherung von Traceback-Werten ausgelegt. In einer vorteilhaften Weiterbildung werden dort die Traceback-Werte des gesamten Trellis-Diagramms abgelegt, so dass im Fall einer BTFD (Blind Transport Format Detection; zu BTFD siehe 3GPP-Spezifikation unter 3GPP TS 25.212, „Multiplexing and channel coding", Abschnitt 4.3, insbesondere Seite 10) lediglich der Traceback-Schritt von verschiedenen Startzeitpunkten im Trellis-Diagramm erfolgen kann. Eine Vorwärtsrekursion mit der Ermittlung neuer State-Metriken braucht nur einmal ausgeführt werden.
In einer Ausgestaltung der Erfindung ist eine Steuereinrichtung vorgesehen, die den Betriebmodus des Dekodierers festlegt. Über die Speichereinrichtung ist somit eine für einen jeweiligen Betriebsmodus vorher festgelegte Speicheraufteilung implementiert. Diese geschieht typischerweise durch ein Steuersignal, welches von der Steuereinrichtung dem jeweiligen Speicher zugeführt wird. Über die Steuereinrichtung ist darüber hinaus der jeweilige Betriebsmodus des Dekodierers festgelegt. Zu diesem Zwecke enthält die Steuereinrichtung und/oder der Speicher einen Multiplexer oder weist die Funktionalität eines Multiplexers auf. Über diesen Multiplexer ist dem Speicher die jeweilige Speicheraufteilung in Abhängigkeit des jeweiligen Betriebsmodus zuweisbar. Typischerweise, jedoch nicht notwendigerweise, ist der Multiplexer in fest verdrahteter Logik ausgebildet und Bestandteil des Dekodierers.
In einer alternativen Ausgestaltung kann die Funktionalität des Multiplexers auch in der als Programm gesteuerte Einheit ausgebildeten Steuereinrichtung implementiert sein. Eine solche Programm gesteuerte Einheit kann beispielsweise ein Mikrocontroller, ein Mikroprozessor, ein Signalprozessor oder dergleichen sein.
Die Speicherbereichbelegung des Speichers ist in einer vorteilhaften Ausgestaltung über die Steuereinrichtung für einen jeweiligen Datenpfad und damit für einen jeweiligen Betriebsmodus fest vorgegeben.
In einer besonders vorteilhaften Ausgestaltung ist die erfindungsgemäße Dekodiereinrichtung zumindest teilweise, vorteilhafterweise sogar ganz, in Hardware ausgebildet.
In einer weiteren besonders vorteilhaften Ausgestaltung kann in Folge der erfindungsgemäßen Dekodiereinrichtung ein exakter Viterbi-Algorithmus implementiert werden, der sogenannte Traceback-Informationen des gesamten Trellis-Diagrammes speichert, ohne die limitierte Speichergröße zu überschreiten. Die Verwendung eines derartigen exakten, d.h. nicht fenster-basierten Viterbi-Algorithmus hat die folgenden Vorteile:

– Basierend auf der Maximum-Likelihood-Sequenz, die mit Hilfe des herkömmlichen Hard-Decision-Viterbi-Algorithmus gewonnen werden, können in einem weiteren Durchlauf durch das Zustandsdiagramm (Trellis-Diagramm) Zuverlässigkeitsinformationen – sogenannte Soft-Output-Informationen – gewonnen werden. Im Gegensatz zum ursprünglichen, Fenster basierten Soft-Output-Viterbi-Algorithmus müssen hier lediglich die Zuverlässigkeitsinformationen entlang des einzigen konkurrierenden Datenpfades zum Maximum-Likelihood-Datenpfad aktualisiert werden. Der konkurrierende Pfad wird für jede Zeiteinheit im Trellis-Diagramm neu bestimmt.
– Im BTFD-Betriebsmodus (BTFD = Blind Transfer Format Detection) ist dem im Viterbi-Mode betriebenen Empfänger das momentan gesendete Transportformat bestehend aus Transportblockgröße und Anzahl der Transportblöcke unbekannt. Dies muss vielmehr aus einer bekannten Menge von möglichen Transportformaten durch Kanaldekodierung mit anschließender CRC-Kodierung (CRC = Cyclic Redundancy Check) ermittelt werden. Für den im Viterbi-Mode betriebenen Empfänger bedeutet dies, dass von mehreren Endpositionen im Trellis-Diagramm eine Rückkopplung (Traceback) mit anschließender CRC-Dekodierung durchgeführt wird. Dies ist aber bei Verwendung eines exakten Viterbi-Algorithmus vorteilhafterweise besonders einfach, da die Traceback-Informationen über das gesamte Zustandsdiagramm bereits abgespeichert sind. Insbesondere benötigt die Ermittlung der Maximum-Likelihood-Sequenz nach der Bestimmung des korrekten Transportformates nur einen weiteren „Traceback" und keine erneute Dekodierung mit Metric-Akkumulation. Die herkömmliche Fenster basierte, d.h. nicht exakte Viterbi-Dekodierung müsste in diesem Falle nach der Ermittlung des korrekten Transportformates zusätzlich noch einen Viterbi-Durchlauf (mit Metric-Akkumulation) starten, da diese Traceback-Informationen nur über jeweils einem Fenster abgespeichert wurden.

Dieses erfindungsgemäße Verfahren benötigt somit deutlich weniger Zeit und ist darüber hinaus auch hinsichtlich der verwendeten Systemressourcen leistungssparender als herkömmliche Verfahren.
Die Erfindung wird nachfolgend anhand der in den Figuren der Zeichnung angegebenen Ausführungsbeispiele näher erläutert. Es zeigt dabei:
1 eine schematische Darstellung der Luftschnittstelle eines Mobilfunksystems mit zwei Sendern und einem Empfänger;
2 ein Blockschaltbild einer im Empfänger aus 1 angeordneten, erfindungsgemäßen Dekodiereinrichtung;
3(a) eine schematische Darstellung eines in verschiedenen Speicherbereiche aufgeteilten Speichers für eine erfindungsgemäße Dekodiereinrichtung gemäß 2 sowie eine beispielhafte Allokierung dieses Speichers im Falle einer Viterbi-Dekodierung ( 3(b)) und im Falle einer Turbo-Code-Dekodierung ( 3(c)).
In den Figuren der Zeichnung sind gleiche bzw. funktionsgleiche Elemente – sofern nichts anderes angegeben ist – mit gleichen Bezugszeichen versehen worden.
1 zeigt eine schematische Darstellung der Luftschnittstellen eines Mobilfunksystems.
In 1 ist mit Bezugszeichen 1 ein Mobilfunksystem bezeichnet. Das Mobilfunksystem kann zum Beispiel ein UMTS-System (Universal Mobile Telecommunications System) oder ein GSM-System (Global System for Mobile Communications) sein, jedoch sei die Erfindung nicht auf derartige Mobilfunksysteme beschränkt. Das Mobilfunksystem 1 besteht hier aus zwei Sendern 2, 3 und einem Empfänger 4. Die Sender 2, 3 bzw. der Empfänger 4 können sowohl einer Basisstation als auch einer Mobilstation zugeordnet sein. Jeweils ein Sender 2, 3 weist einen Kodierer 5, 6, einen Modulator 7, 8 sowie eine Sendeantenne 9, 10 auf. Der Empfänger weist eine Empfangsantenne 11, einen Demodulator 12 und eine erfindungsgemäße Dekodiereinrichtung 13 auf. Zwischen den beiden Sendern 2, 3 und dem Empfänger 4 ergeben sich somit die beiden Übertragungskanäle 14, 15.
Im vorliegenden Fall sei angenommen, dass der Kodierer 5 im ersten Sender 2 ein Turbo-Kodierer ist, der das Eingabesignal U1 in ein turbo-kodiertes Ausgabesignal D1 umwandelt. Gleichermaßen sei angenommen, dass der Kodierer 6 im zweiten Sender 3 ein konventioneller Faltungskodierer ist, der zum Beispiel das Eingabesignal U2 in ein faltungskodiertes Ausgabesignal D2 wandelt.
Ein jeweiliger Kodierer 5, 6 nimmt ein digitales Eingabesignal U1, U2 in Form einer Folge von Datensymbolen (Bits) entgegen. Das Eingabesignal U1, U2 trägt beispielsweise eine zu übertragende Sprachnachricht. Der jeweilige Kodierer 5, 6 fügt dem digitalen Eingabesignal U1, U2 eine Redundanz zur Fehlerschutzkodierung hinzu. Am Ausgang des Kodierers 5, 6 liegt ein Fehlerschutz kodiertes Datensignal D1, D2 vor, welches anschließend in nicht dargestellter Weise verschachtelt und in Blöcke vorgegebener Länge unterteilt wird. Ein jeweiliger Modulator 7, 8 moduliert das so Fehlerschutz kodierte Datensignal auf ein Trägersignal auf, welches ebenfalls in nicht dargestellter Weise von einem Sendefilter spektral geformt und von einem Sendeverstärker verstärkt wird, bevor es als Funksignal über die jeweiligen Antennen 9, 10 abgestrahlt wird.
Die Empfangsantenne 11 empfängt das durch Umgebungseinflüsse und Interferenzen mit Funksignalen im Übertragungskanal 14, 15 gestörte Funksignal und führt es dem Demodulator 12 zu. Der empfängerseitige Demodulator 12 besteht im einfachsten Fall aus einer Hochfrequenzstufe, die das über die Empfangsantenne 11 empfangene Funksignal entgegen nimmt und es in üblicher Weise durch Heruntermischen in ein analoges Empfangssignal umwandelt. Das analoge Empfangssignal wird von einem Analog/Digital-Umsetzer (AD-Wandler) mit einer ausreichend hohen Abtastfrequenz digitalisiert und ggf. mittels eines nachgeschalteten, digitalen Filters Bandbreiten begrenzt. Der Demodulator 12 entzerrt das empfangene Funksignal unter Berücksichtigung der im Funkkanal erlittenen Signalstörungen.
Das am Ausgang des Demodulators 12 anliegende entzerrte Datensignal D' liegt in Form einer Symbolfolge vor, deren Elemente werte-kontinuierliche Schätzwerte der Symbole des gesendeten Fehlerschutz kodierten Datensignals sind. Das entzerrte Datensignal D' wird der erfindungsgemäßen Dekodiereinrichtung 13 zugeführt, an deren Ausgang ein dekodiertes Ausgabesignal U' anliegt. Zusätzlich ist es auch möglich, in dem Kanal-Dekodierer 13 eine Zuverlässigkeitsinformation zu erzeugen und vorteilhafter Weise bei der Quellendekodierung auszunutzen.
Der Aufbau und die Funktionsweise eines in 1 dargestellten Mobilfunksystems ist in dem Buch von Peter Jung, „Analyse und Entwurf digitaler Mobilfunksysteme", insbesondere in Figur Bild 4.24, beschrieben. Diese Druckschrift wird insbesondere hinsichtlich des Aufbaus und der Funktionsweise der verwendeten Kodierer, der Dekodierer sowie des Übertragungskanals vollinhaltlich in die vorliegende Patentanmeldung mit einbezogen.
Der Aufbau und die Funktionsweise einer erfindungsgemäßen Dekodiereinrichtung 13 soll nachfolgend anhand der 2 und 3 näher erläutert werden. 2 zeigt das Blockschaltbild einer im Empfänger aus 1 angeordneten, erfindungsgemäßen Dekodiereinrichtung.
Die erfindungsgemäße Dekodiereinrichtung 13 weist einen Datenpfadbereich 20, eine Speichereinrichtung 21 sowie eine Steuereinrichtung 22 auf. Der Dekodierer 13 weist ferner einen Eingang 23 auf, über den sogenannte Soft-Input-Eingangssignale D' des vorgeschalteten Demodulators 12 einkoppelbar sind. Der Ausgang bzw. die Ausgänge der Dekodiereinrichtung 13 sind in 2 der Übersichtlichkeit halber nicht dargestellt worden.
Die Speichereinrichtung 21 weist eine Multiplexer-Schaltung 30 auf, die gewissermaßen als Schnittstelle zwischen der Speichereinrichtung 21 einerseits und dem Datenpfadbereich 20, dem Eingang 23 und dem Ausgang der Dekodiereinrichtung 13 andererseits vorgesehen ist. Die Speichereinrichtung 21 weist ferner verschiedene Speicherbereiche 31-34 auf, die über den Datenpfadbereich 20 bzw. den Eingang 23 allokierbar sind.
Im vorliegenden Ausführungsbeispiel ist der Speicherbereich 31 zur Zwischenspeicherung von Soft-Input-Eingangsdaten D' von dem vorgeschalteten Demodulator 12 ausgelegt. Der Speicherbereich 32 ist ein sogenannter Trace-Back-Speicher. In diesen werden für jeden Zustand jeder Zeiteinheit die Entscheidungsresultate bei einem ACS-Schritt abgelegt (das heißt der Zeiger auf den günstigsten Übergang in den betreffenden Zustand der aktuellen Zeiteinheit), so dass nach einem Durchlauf des gesamten Trellis-Diagramms mit Hilfe dieser Entscheidungsresultate der Maximum-Likelihood-Pfad durch den sogenannten Traceback-Schritt ermittelt werden kann. In dem Speicherbereich 33 werden die im Rahmen der Dekodierung berechneten Zustandsmetriken abgelegt. Der Speicherbereich 34 ist ein sogenannter LLR-Speicher (Log-Likelihood-Ratio), in dem zum Beispiel A-Priori-Daten bzw. Zuverlässigkeitsdaten, die im Rahmen der Turbo-Code-Dekodierung gewonnen werden, abgelegt werden. Darüber hinaus kann die Speichereinrichtung 21 zusätzlich oder alternativ noch weitere Speicherbereiche enthalten, in denen beispielsweise Daten zur Eingangs- und Ausgangspufferung abgelegt sind oder bei denen im Rahmen der unterschiedlichen Dekodierverfahren gewonnenen Informationen jeweils für das jeweilige Dekodierverfahren spezifisch abgelegt werden. Speicherbereiche für die ermittelten möglichen Übergangsmetriken innerhalb einer Zeiteinheit müssen ebenfalls berücksichtigt werden, sind aber hier nicht aufgeführt.
Über die Steuereinrichtung 22 kann die jeweilige Speichereinteilung und damit der Betriebsmodus der Dekodiereinrichtung 13 gesteuert werden. Im vorliegenden Fall wird über das Steuersignal X, welches von der Steuereinrichtung 22 in die Multiplexereinrichtung 30 eingekoppelt wird, eine spezifische Speicherbelegung voreingestellt. Eine derartige Speicherbelegung kann zum Beispiel hinsichtlich einer Turbo-Dekodierung oder einer SOVA-Dekodierung spezifisch gewählt werden.
Im vorliegenden Ausführungsbeispiel ist die Multiplexer-Einrichtung 30 Bestandteil der Speichereinrichtung 21 und liegt somit in fest verdrahteter Steuerlogik vor.
Die Steuereinrichtung 22 ist vorzugsweise eine Programm gesteuerte Einheit, beispielsweise ein Mikrocontroller, Mikroprozessor, Signalprozessor oder dergleichen. In einer alternativen Ausgestaltung könnte die Funktionalität des Multiplexers 30 in der Steuereinrichtung 21 mitintegriert sein. Alternativ wäre es allerdings auch denkbar, dass die Funktionalität der Steuereinrichtung 21 in fest verdrahteter Steuerlogik vorliegt.
Im Datenpfadbereich 20 der Dekodiereinrichtung 13 ist eine sogenannte Branch-Metric-Einheit 40, 41 angeordnet. Diese Branch-Metric-Einheit 40, 41 ist über den Soft-Input-Speicherbereich 31 mit dem Eingang 23 zur Einkopplung von Eingangsdaten gekoppelt. Die Branch-Metric-Einheit 40, 41 enthält eine Einheit 40 zur Berechnung der Branch-Metric-Daten, der die Einheit 41 zur Auswahl der Branch-Metric-Daten nachgeschaltet ist. Bei den Branch-Metric-Einheiten 40, 41 handelt es sich somit um Einheiten zur Übergangsmetrik-Bestimmung für die Turbo-Code- und Viterbi-Code-Dekodierung, in denen die Metriken pro Trellis-Zeiteinheit berechnet werden, wobei jeweils eine Metrik auf die nachgeschaltete ACS-Einheit 42 gemappt wird. Es erfolgt hier also eine Zuordnung der ausgewählten Daten.
Den Branch-Metric-Einheiten 40, 41 ist eine sogenannte ACS-Einheit 42 (ACS = Add-Compare-Select) nachgeschaltet. In der ACS-Einheit ist die Berechnung des optimalen Pfades zwischen zwei Zuständen mit Hilfe eines Trellis-Diagramms implementiert, bei dem jeweils für jeden Knoten des Trellis-Diagramms Daten addiert, miteinander verglichen und dann der optimale Pfad ausgewählt wird. Die ACS-Einheit 42 speichert den Zeiger auf den optimalen Übergang zu dem betrachteten Zustand der aktuellen Zeiteinheit (das heißt das Ergebnis der Additions- und Vergleichsoperationen der ACS-Einheit 42) in Form von Traceback-Daten für alle Zustände und für alle Trellis-Zeiteinheiten in dem Speicherbereich 32 ab. Im Speicherbereich 33 werden die bei der ACS-Operation ermittelten Zustandsmetriken abgelegt, die von Zeiteinheit zu Zeiteinheit mit neuen Werten überschrieben werden können.
Es sei angemerkt, dass für den Betrieb einer Dekodiervorrichtung im Log-MAP-Modus die ACS-Einheit geringfügig modifiziert werden müsste. Eine solche Modifizierung ist dem Fachmann jedoch hinreichend bekannt (siehe Steven S. Pietrobon, „Implementation and performance of a Turbo/MAP decoder", International Journal of Sattelite Communications, Ausgabe 16, Seiten 23-46, 1998). Für eine Berechnung der neuen Zustandsmetriken ist die herkömmliche ACS-Einheit mit einer weiteren Addition eines Wertes ausgestattet, der sich als spezielle Funktion der berechneten Differenz aus der Vergleichsoperation (compare) ergibt. Diese spezielle Funktion ist üblicherweise als Lookup-table implementiert. Wird die Lookup-table mit Nullen vorbelegt, ergibt sich die normale ACS-Funktionalität, wie sie für den MAX-Log-MAP, HDVA oder SOVA Modus benötigt wird.
Der ACS-Einheit 42 ist eine sogenannte LLR-Einheit 43 nachgeschaltet angeordnet. In der LLR-Einheit 43 werden geschätzte Daten auf der Basis des Log-Likelihood-Ratio-Verfahrens berechnet. Die LLR-Einheit berechnet Zuverlässigkeitsinformationen, die in dem Speicherbereich 34 abgelegt werden und bei Bedarf über den Turbo-Rückkopplungspfad 45 rückgekoppelt werden. Die ACS-Einheit 42 ist mit der LLR-Einheit 43 über das Iterationsnetzwerk 44 zur Vorwärts- und Rückwärts-Rekursion gekoppelt.
Die LLR-Einheit 43 ist ausgangsseitig mit dem LLR-Speicherbereich 34 gekoppelt, in dem die entsprechenden, von der LLR-Einheit 43 berechneten Daten abgelegt werden. Zusätzlich ist eine Turbo-Rückkopplungsschleife 45 vorgesehen, über die in dem LLR-Speicherbereich 34 abgelegte Soft-Daten in die Branch-Metric-Einheit 40 rückgekoppelt werden.
Die ACS-Einheit 42 ist ausgangsseitig über das Iterationsnetzwerk 44 sowohl mit dem Traceback-Speicherbereich 32 als auch mit dem State-Metric-Speicherbereich 33 verbunden, in denen somit von der ACS-Einheit 42 berechnete Daten (Metrik-Werte der einzelnen Zustände im Trellis) ablegbar sind. Der State-Metric-Speicherbereich 33 ist darüber hinaus über das Iterationsnetzwerk 44 mit dem Eingang der ACS-Einheit 42 gekoppelt, so dass hier wiederum eine Verwendung der bereits berechneten und abgespeicherten Daten (State-Metriken) im nachfolgenden Schritt für die nächste Zeiteinheit im Trellis-Diagramm erfolgt. Im herkömmlichen Viterbi-Algorithmus beschreibt die Verwendung von bereits berechneten State-Metriken der vergangenen Zeiteinheit im Trellis die Vorwärtsrekursion. Im Turbo- oder auch MAP-Dekodierer wird die Wiederverwendung der bereits berechneten State-Metriken in der Vorwärts und in der Rückwärtsrekursion durchgeführt. Die Funktion der Vorwärts- und Rückwärts-Rekursion innerhalb des Iterationsnetzwerkes 45, die insbesondere bei der Turbo-Code-Dekodierung eine besondere Rolle spielt, sind dem Fachmann allgemein bekannt und wird daher nachfolgend nicht detailliert erläutert (siehe hierzu das Buch von Peter Jung).
Die erfindungsgemäße Dekodiereinrichtung 13 ist sowohl zur Dekodierung turbo-kodierter Daten als auch zur herkömmlichen Dekodierung mittels des Viterbi-Algorithmus ausgelegt. Es ergeben sich damit folgende beiden Datenpfade innerhalb des Datenpfadbereiches 20:
Erster Datenpfad für den Turbo-Code:
Im Falle einer Turbo-Codierung werden eingehende zu dekodierende Daten über den Eingang 23 zunächst im Soft-Input-Speicherbereich 31 abgelegt. Zusätzlich oder alternativ könnten eingehende dekodierende Daten (Channel Soft-Inputs) auch direkt, gewissermaßen "on the fly" verarbeitet werden, so dass für diese Applikationen (zum Beispiel für hard-decision Viterbi ohne nachfolgende BTFD-Applikation) die Softinput-Daten gar nicht zwischen gespeichert werden müssten.
Diese im Speicher 31 abgelegten Daten werden bei Bedarf aus dem Soft-Input-Speicherbereich 31 ausgelesen und in den Datenpfadbereich 20 eingekoppelt. Der Turbo-Code-Datenpfad innerhalb des Datenpfadbereiches 20 ergibt sich somit aus den Branch-Metric-Einheiten 40, 41, der ACS-Einheit 42, dem Iterationsnetzwerk 44 sowie der LLR-Einheit 43. Dieser Datenpfad umfasst darüber hinaus die State-Metric-Speichereinheit 33, die der LLR-Einheit 43 nachgeschaltete LLR-Speichereinheit 34 sowie die Rückkopplungs-Turbo-Schleife 45.
Zweiter Datenpfad für Viterbi-Dekodierung
Der Datenpfad für die Viterbi-Dekodierung umfasst neben dem Eingang 23 und dem Soft-Input-Speicherbereich 31 ebenfalls die Branch-Metric-Einheiten 40, 41 und die diesen nachgeschaltete ACS-Einheit 42. Darüber hinaus enthält der Viterbi-Datenpfad Teile des Iterationsnetzwerkes 44, über welches die Daten in die Speicherbereiche 32, 33 abgelegt werden bzw. wieder in den Datenpfad (Daten des Speicherbereichs 33) insbesondere in die ACS-Einheit eingeführt werden.
3(a) zeigt eine schematische Darstellung einer erfindungsgemäßen Speichereinrichtung 21, die im vorliegenden Fall in acht Speichersegmente unterteilt ist. Die acht Segmente der Speichereinrichtung 21 sind hier mit Bezugszeichen 51-58 bezeichnet worden. Über das Steuersignal X, welches von der Steuereinrichtung 22 bereitgestellt wird, kann ein Betriebsmodus der Speichereinrichtung 21 voreingestellt werden.
Im vorliegenden Falle sei lediglich von zwei Betriebsmodi ausgegangen: Im ersten Betriebsmodus werden eingekoppelte Daten über eine Turbo-Dekodierung abgelegt, während im zweiten Betriebsmodus hierzu ein Viterbi-Algorithmus vorgesehen ist. Die Erfindung sei jedoch nicht auf eben diese beiden Dekodiermodi beschränkt, sondern lässt sich selbstverständlich auch auf andere Dekodiermodi bzw. mehr als zwei Dekodiermodi erweitern.
Die Speichereinrichtung 21 ist über bidirektionale Datenleitungen mit dem Eingang 23 bzw. mit den entsprechenden Elementen 40, 42, 43, 44 im Datenpfadbereich 20 der Dekodiereinrichtung 13, die der Übersichtlichkeit halber in 3 nicht dargestellt wurden, verbunden. Nachfolgend wird die unterschiedliche Speicheraufteilung der Speichersegmente 51-58 im Falle des Viterbi-Dekodier-Modus (3(b)) und im Falle des Turbo-Dekodier-Mode (3(c)) näher erläutert:
Viterbi-Modus (3(b))
Im Viterbi-Mode werden Soft-Input-Daten in die Speichersegmente 51, 54 abgelegt, die somit den Speicherbereich 31 bilden. State Metric-Daten werden hier in die Speichersegmente 52, 53 abgelegt, die den Speicherbereich 33 bilden. Im Viterbi-Dekodier-Mode werden ferner Traceback-Daten in die Speichersegmente 55-58 abgelegt, die den Speicherbereich 32 bilden. Im Hard-Decision Viterbi-Dekodier-Mode ist somit kein LLR-Speicherbereich 34 vorgesehen.
Turbo-Modus (3(c)):
Im Turbo-Mode werden Soft-Input-Daten über den Eingang 23 in die Speichersegmente 51, 53 abgelegt. Diese Speichersegmente 51, 53 bilden den Speicherbereich 31. State Metric-Daten werden im Speichersegment 52 abgelegt, der den Speicherbereich 33 bildet. LLR-Daten werden in die Speichersegmente 54-58 abgelegt, die den Speicherbereich 34 bilden. Im Turbo- Dekodier-Mode ist somit kein Trace-Back-Speicherbereich 32 vorgesehen.
Die in den 3(a)-(c) angegebene Speicherplatzsegmentierung sei lediglich beispielhaft angegeben, kann aber selbstverständlich auch auf beliebig andere Weise ausgebildet sein.
In den 3(b) und 3(c) fällt auf, dass die Speichersegmente 51, 52 sowohl im Viterbi- als auch im Turbo-Mode funktionsgleich genutzt werden. Daraus wird ersichtlich, dass insbesondere die Branch-Metric-Einheit 40, 41 die ACS-Einheit 42 und Teile des Iterationsnetzwerkes 44 im Datenpfadbereich 20 gemeinsam sowohl im Turbo-Dekodiermodus als auch im Viterbi-Dekodier-Modus verwendet werden.
Die 3(b), 3(c) zeigen ferner, dass zwar einzelne Speicherbereiche 31, 33 innerhalb der Speichereinrichtung 21 gemeinsam genutzt werden, jedoch muss deren Größe nicht notwendigerweise sowohl im Turbo-Dekodier-Modus als auch im Viterbi-Dekodier-Modus gleich groß sein. Vielmehr können die einzelnen Speicherbereiche für die unterschiedlichen Dekodier-Modi unterschiedlich groß ausgestaltet sein.
Darüber hinaus werden auch die übrigen Speichersegmente in beiden Dekodiermodi gemeinsam genutzt. Dies wird durch eine jeweils für den gewählten Betriebsmodus spezifische Speicherbelegung festgelegt. Auf diese Weise können die Ressourcen des Speichers 21 optimal genutzt werden, indem der Speicher für den maximal erforderlichen Speicherplatzbedarf eines der verwendeten Betriebsmodi ausgelegt wird. Der bzw. die jeweils anderen Dekodier-Betriebsmodi benötigen einen geringeren Speicherplatzbedarf, der somit stets vorhanden ist.
Typischerweise, jedoch nicht notwendigerweise, ist der Turbo-Dekodier-Mode hinsichtlich des Speicherplatzbedarfes der bestimmende Faktor, so dass bei der Auslegung der Speichergröße der Speichereinrichtung 21 zumeist von dem Speicherplatzbedarf im Turbo-Dekodier-Modus ausgegangen werden muss. Nachfolgend sei anhand eines typischen Zahlenbeispiels diese Speicherplatzeinsparung im Vergleich zu einem herkömmlichen Dekodierer, der sowohl für Viterbi- als auch Turbo-Code-Dekodierung ausgelegt ist, dargelegt.
Ohne die erfindungsgemäße Dekodiervorrichtung 13 werden folgende Speicherressourcen (unter der Annahme von 6 Bits für die Soft-Input Auflösung und UMTS-spezifische Codierer und unter der Annahme einer Fensterlänge für Viterbi/SOVA = 5 constraint length) benötigt:

159 000 Bits Turbo-Modus

21 000 Bits Fenster-basierter Viterbi-Modus

138 000 Bits SOVA basierend auf fenster-basiertem Viterbi

318 000 Bits Gesamt
Da mittels des erfindungsgemäßen Verfahrens bzw. der erfindungsgemäßen Dekodiereinrichtung der Speicher lediglich auf die größte Bitanzahl, nicht aber auf die Summe der Bitanzahl ausgelegt sein muss, ergibt sich eine erfindungsgemäße Speichergröße von 159 000 Bits, so dass der Speicher im dargestellten Beispiel etwa um den Faktor ½ kleiner ausgelegt sein kann.
In der vorstehenden Beschreibung der Erfindung wurde die erfindungsgemäße Dekodiereinrichtung anhand eines Mobilfunksystems beschrieben. Die Erfindung sei aber nicht darauf beschränkt, sondern ist in allen Systemen mit Kodier- und Dekodiereinrichtungen sehr vorteilhaft einsetzbar.
Die Erfindung sei nicht auf eine herkömmliche Viterbi-Dekodierung bzw. eine herkömmliche Turbo-Dekodierung beschränkt, sondern lässt sich auf sämtliche, wie auch immer ausgebildete Dekodierarten, die Daten auf der Basis eines Maximum Likelihood (ML)-Log-MAP- bzw. MAX-Log-MAP Algorithmus dekodieren, erweitert werden. Solche Dekodier- bzw. Trellis-Prozessor-Modi sind zum Beispiel neben dem herkömmlichen Viterbi-Dekodiermodus und Turbo-Dekodier-Modus auch die folgenden, wie bereits erwähnten Dekodiermodi: HDVA, SOVA, Log-MAP, MAX-Log-MAP. Die letzteren drei Dekodiermodi können sowohl zur Soft-Output-Dekodierung von herkömmlichen, unverketteten Faltungscodes, als auch zur Dekodierung von parallel verketteten Faltungscodes (d. h. klassische Turbocodes) oder auch von seriell verketteten Faltungscodes verwendet werden. Des Weiteren ist eine Anwendung auf eine ML-, MAP-, Log-MAP- oder MAX-Log-MAP-Entzerrung bzw. auch die iterative Turbo-Entzerrung denkbar und möglich.
Zusammenfassend kann festgestellt werden, dass durch die Erfindung eine sowohl im Turbo-Dekodier-Mode als auch im Viterbi-Dekodier-Mode betreibbare Dekodiereinrichtung bereitgestellt wird, bei der auf sehr elegante, jedoch nichts desto trotz sehr einfache Weise Speicherplatzressourcen und Systemressourcen durch gemeinsame Nutzung in beiden Betriebsmodi eingespart werden können.
Die vorliegende Erfindung wurde anhand der vorstehenden Beschreibung so dargelegt, um das Prinzip der Erfindung und dessen praktische Anwendung bestmöglichst zu erklären, jedoch lässt sich die Erfindung bei geeigneter Abwandlung selbstverständlich in mannigfaltigen anderen Ausführungsformen realisieren.

1: Mobilfunksystem
2, 3: Sender
4: Empfänger
5, 6: Kodierer
7, 8: Modulator
9, 10: Sendeantennen
11: Empfangsantenne
12: Demodulator
13: Dekodier-Einrichtung
14, 15: Übertragungskanäle
20: Datenpfadbereich
21: Speichereinrichtung
22: Steuereinrichtung
23: Eingang
30: Multiplexer
31: (Soft-Input-)Speicherbereich
32: (Trace-Back-)Speicherbereich
33: (State Metric-)Speicherbereich
34: LLR-Speicherbereich
40, 41: Branch-Metric-Einheiten
42: ACS-Einheit
43: (LLR-)Einheit
44: Iterationsnetzwerk
45: Rückkopplungs-Turbo-Schleife
51-58: Speichersegmente
D1, D2: sendeseitig kodierte Datensignale
D': Datensignale
U1, U2: Eingabesignale
U': Ausgabesignal
X: Steuersignal (für Betriebsmodus)

Claims

Dekodiervorrichtung, die zumindest einen Dekodierer (13) sowohl für eine Turbo-Dekodierung als auch für eine Viterbi-Dekodierung aufweist, mit einem ersten Datenpfad (40, 41, 42, 44) zur Viterbi-Dekodierung eines Faltungs-Codes und mit einem zweiten Datenpfad (40-45) zur Dekodierung eines Turbo-Codes, wobei zumindest Teile des ersten Datenpfades (40-42, 44) und des zweiten Datenpfades (40-45) gemeinsam sowohl zur Turbo-Dekodierung als auch zur Viterbi-Dekodierung nutzbar sind; mit einem gemeinsamen Speicher (21), der eine Vielzahl von einzelnen Speicherbereichen (31-34) aufweist, vorgesehen ist, wobei zumindest ein Speicherbereich (31-34) sowohl über den ersten Datenpfad (40-42, 44) im Viterbi-Mode als auch über den zweiten Datenpfad (40-45) im Turbo-Mode allokierbar ist.
Dekodiervorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass die Speichergröße des gemeinsamen Speichers (21) auf die für eine Turbo-Dekodierung erforderliche Speichergröße ausgelegt ist.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Dekodierer (13), insbesondere dessen Datenpfade (20), in fest verdrahteter Logik ausgebildet sind.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der erste Datenpfad (40-42, 44) zur Hard-Output-Viterbi-Algorithmus Dekodierung, insbesondere zur exakten Hard-Output-Viterbi-Algorithmus Dekodierung, ausgelegt ist.
Dekodiervorrichtung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der erste Datenpfad (40-42, 44) zur Soft-Output-Viterbi-Algorithmus Dekodierung ausgelegt ist.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der zweite Datenpfad (40-45) in einem Log-MAP-Modus, insbesondere in einem MAX-Log-MAP-Modus, als Bestandteil der Turbo-Dekodierung betreibbar ist.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zumindest eine der gemeinsam genutzten Elemente der Datenpfade (20) des Dekodierers (13) eine ACS-Einheit (42) ist.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zumindest eine der gemeinsam genutzten Elemente der Datenpfade (20) des Dekodierers (13) eine Branch-Metric-Einheit (40, 41) zur Übergangsmetrikbestimmung ist.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zumindest ein gemeinsam genutzter Speicherbereich (31) zur Abspeicherung von Soft-Input-Daten vorgesehen ist.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zumindest ein gemeinsam genutzter Speicherbereich (32, 33) zur Abspeicherung von Traceback-Werten und/oder Zustandsmetriken vorgesehen ist.
Dekodiervorrichtung nach Anspruch 10, dadurch gekennzeichnet, dass in dem Speicherbereich (32) zur Abspeicherung von Traceback-Werten die Traceback-Werte des gesamten Trellis-Diagrammes ablegbar sind.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zumindest ein gemeinsam genutzter Speicherbereich (34) zur Abspeicherung von Log-Likelihood-Ratio-Daten aus der Turbodekodierung vorgesehen ist.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass eine Steuereinrichtung (22) vorgesehen ist, die den Betriebsmodus des Dekodierers (13) festlegt, die somit festlegt, dass eine Dekodierung über den ersten Datenpfad (40-42, 44) oder über den zweiten Datenpfad (40-45) erfolgt.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass eine Steuereinrichtung (22) vorgesehen ist, die den Betriebsmodus des Dekodierers (13) festlegt und die eine für den jeweiligen Betriebsmodus vorher festgelegt Speicheraufteilung vornimmt.
Dekodiervorrichtung nach einem der Ansprüche 13 oder 14, dadurch gekennzeichnet, dass die Steuereinrichtung (22) und/oder der Speicher (21) einen Multiplexer (30) enthält oder die Funktionalität eines Multiplexers (30) aufweist.
Dekodiervorrichtung einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, dass der Multiplexer (30) und/oder die Steuereinrichtung (22) in festverdrahteter Logik ausgebildet sind und Bestandteil des Dekodierers (13) sind.
Dekodiervorrichtung nach einem der Ansprüche 13 bis 16, dadurch gekennzeichnet, dass als Steuereinrichtung (22) eine Programm gesteuerte Einheit, insbesondere ein Mikrocontroller oder ein Mikroprozessor, vorgesehen ist, die die Funktionalität des Multiplexers aufweist.
Dekodiervorrichtung nach einem der Ansprüche 13 bis 17, dadurch gekennzeichnet, dass die Speicherbereichbelegung des Speichers (13) für den jeweiligen Datenpfad (40-45) über die Steuereinrichtung (22) fest vorgegeben ist.
Dekodiervorrichtung nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Dekodiereinrichtung zumindest teilweise, insbesondere ganz, in Hardware ausgebildet ist.
Trellis-Prozessor für eine Dekodiervorrichtung nach einem der vorstehenden Ansprüche, bei dem der Trellis-Prozessor sowohl in einem Viterbi-Dekodiermodus für einen Faltungscode als auch in einem Dekodiermodus für einen Turbo-Code betreibbar ist und bei dem der Trellis-Prozessor bei den verschiedenen Betriebsmodi sowohl die Datenpfade wie auch die Speicherbereiche zumindest teilweise gemeinsam nutzt.
Verfahren zum Betreiben einer Dekodiereinrichtung (13) bzw. eines Trellis-Prozessors nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zumindest eine erste Dekodierung unter Verwendung eines exakten Viterbi-Algorithmus implementiert wird und/oder zumindest eine zweite Dekodierung unter Verwendung des MAP-Algorithmus oder eines Turbo-Codes implementiert wird.
Verfahren zum Betreiben einer Dekodiereinrichtung (13) bzw. eines Trellis-Prozessors nach einem der Ansprüche 1 bis 20, dadurch gekennzeichnet, dass die Traceback-Werte des gesamten Trellis-Diagrammes in einem Speicher (32) abgespeichert werden.