-
Verfahren und Architektur zur Übergabe
von Symbolen einer Rake-Finger-Struktur an aufgabenspezifische Hardware-Module
Die Erfindung betrifft ein Verfahren zur Übergabe von Symbolen, die von einer
Mehrzahl von Rake-Fingern ausgegeben werden, an aufgabenspezifische
Hardware-Module.
-
Im Mobilfunk unterliegen Funksignale
der Mehrwege-Ausbreitung, d.h. durch Reflexion, Streuung und Beugung
des gesendeten Funksignals an diversen Hindernissen im Ausbreitungsweg
treten am Empfänger
mehrere Empfangssignalversionen auf, die zeitlich zueinander verschoben
und unterschiedlich abgeschwächt
sind. Das Funktionsprinzip eines Rake-Empfängers beruht darauf, die energiereichsten
Empfangssignalversionen getrennt auszuwerten und dann zeitrichtig
zu überlagern.
Die Bezeichnung Rake (Rechen) beschreibt dabei in bildhafter Weise die
Struktur eines solchen Empfängers,
wobei die Zinken des Rechens die Rake-Finger repräsentieren und
der Stiel des Rechens das ausgangsseitig bereitgestellte überlagerte
Empfangssignal darstellt.
-
Rake-Empfänger sind bekannt und werden in
Mobilfunkstationen häufig
eingesetzt.
-
Die Signalübertragung von einer Basisstation
zu einer Mobilstation (Downlink) sowie von einer Mobilstation zu
einer Basisstation (Uplink) erfolgt über sogenannte physikalische
Kanäle.
Die physikalischen Kanäle
eines Mobilfunksystems sind durch Standardisierung vorgegeben. Jeder
physikalische Kanal ist durch eine bestimmte Trägerfrequenz, Vorschriften für die Spreizcodierung
und eine bestimmte Datenstruktur gekennzeichnet. Man unterscheidet zwischen
dedizierten physikalischen Kanälen, über welche
Teilnehmer-spezifische Daten gesendet werden, und gemeinsamen physikalischen
Kanäle, über welche
für alle
Teilnehmer bestimmte Daten übertragen
werden. Die in UMTS (Universal Mobile Telecommunication System)
vorgesehenen physikalischen Kanäle
sind in der UMTS-Spezifikation 3GPP TS 25.211 V4.2.0 (2001-09) definiert.
-
Die über die verschiedenen physikalischen Kanäle übertragenen
Daten werden alle von dem Rake-Empfänger demoduliert. Für jeden
zu demodulierenden physikalischen Kanal müssen dabei die entsprechenden
zeitlichen Verzögerungen
der Mehrwege-Komponenten bestimmt und einzelnen Fingern des Rake-Empfängers zugeordnet
werden. Die Rake-Finger, die zeitlich justierbare Spreizcode-Korrelatoren
sind, werden auf die ermittelten Mehrwege-Verzögerungen des empfangenen Signals
eingestellt und mit dem jeweiligen Spreizcode des zu demodulierenden
physikalischen Kanals betrieben. Die Ausgänge der Rake-Finger werden
anschließend
kanalweise kombiniert und liefern die gesuchten Signale.
-
Die aus der Gesamtheit der Rake-Finger
bestehende Struktur wird im Folgenden als Rake-Demodulator bezeichnet.
Prinzipiell lassen sich alle von dem Empfänger durchzuführenden
Aufgaben (Datenempfang, Empfang von Kontrollinformationen für Überwachungs-
und Identifikationsaufgaben, Durchführung von Messungen) mit einem
derartigen Rake-Demodulator lösen.
Typischerweise werden in einer Mobilstation mehrere Kanäle gleichzeitig
empfangen, beispielsweise ein dedizierter Kanal, über welchen
die für
den Empfänger
bestimmten Nutzdaten übertragen
werden, ein oder mehrere gemeinsame Pilotkanäle, deren (im Empfänger bekannte)
Pilotsymbole für
Synchronisations- und
Messzwecke verwendet werden, und Kontrollkanäle, die zum Austausch von Steuerinformation
(z.B. Anweisungen für die
Leistungssteuerung) eingesetzt werden. Hinzu kommt, dass auch innerhalb
eines Kanals unterschiedliche Symboltypen vorhanden sein können (z.B.
umfasst der dedizierte Downlink-Kanal DPCH im UMTS-Standard sowohl
die Teilnehmer-spezifischen Nutzdaten als auch die dedizierten Pilotsymbole),
so dass mehrere Mobilfunk-Aufgaben an ein und demselben Kanal ausgeführt werden
müssen.
-
Die einfachste Möglichkeit, die von dem Rake-Demodulator
ausgegebenen Symbole ordnungsgemäß weiterzuverarbeiten,
besteht darin, sämtliche von
dem Rake-Demodulator ausgegebenen Symbole einem digitalen Signalprozessor
(DSP) zuzuführen.
Da der DSP die Zuteilung der einzelnen Rake-Finger zu den unterschiedlichen
Kanälen
und Ausbreitungswegen vornimmt, und ferner die jedem Kanal zugrunde
liegende Datenstruktur kennt, kann er aus dem einlaufenden Symbolstrom
gezielt diejenigen Symbole identifizieren, die zur Ausführung der jeweiligen
Aufgaben benötigt
werden. Der Nachteil dieser Vorgehensweise besteht darin, dass ein
mit allen Mobilfunk-Aufgaben betrauter DSP eine sehr hohe Rechenleistung
benötigt,
d.h. teuer ist, und außerdem
eine zu hohe Leistungsaufnahme für
Mobilfunk-Anwendungen hat.
-
Um DSPs mit geringeren Rechenleistungen einsetzen
zu können,
werden bestimmte, immer wiederkehrende Rechenabläufe in Hardware ausgelagert.
Dieses auch als "Hardware-Tuning" bezeichnete Konzept ermöglicht eine
deutliche Entlastung des Prozessors. Die ausgelagerte, aufgabenspezifische Hardware
wird in der Literatur häufig
als periphere "dedicated hardware", "hardware Support" oder "(dedicated)
datapath" bezeichnet. Im Folgenden wird der Begriff "(aufgabenspezifisches)
Hardware-Modul"
verwendet.
-
Aufgrund der Vielzahl unterschiedlicher
Applikationen ist in modernen Mobilfunkempfängern der Einsatz von aufgabenspezifischen
Hardware-Modulen unerlässlich,
um leistungsfähige
und kostengünstige
Empfänger
mit geringer Stromaufnahme zu schaffen.
-
In dem Artikel "New DSPs for next
Generation Mobile Telecommunications", von U. Walther, Global Telecommunications
Conference-Globecom, 1999, ist ein Rake-Empfänger für UMTS beschrieben, bei dem
u.a. auch die einzelnen Rake-Finger als Hardware-Module realisiert
sind.
-
Bei Verwendung von Hardware-Modulen
für Messaufgaben
im Signalweg hinter dem Rake-Demodulator stellt sich das Problem,
dass die einzelnen Hardware-Module die "richtigen" Symbole geliefert bekommen
müssen,
d.h. genau jene Symbole, anhand welcher die spezielle Mess- bzw.
Berechnungsaufgabe des Moduls durchzuführen ist.
-
Eine denkbare Vorgehensweise besteht
darin, sämtliche
demodulierten Symbole (egal von welchem Rake-Finger sie erzeugt
wurden und für
welche Applikation sie bestimmt sind) in einem zentralen Speicherbereich
zwischenzuspeichern. Mittels des DSPs werden dann Tabellen angelegt,
die eine eindeutige Zuordnung der gespeicherten Symbole zu den Fingernummern,
zum detektierten Ausbreitungsweg, zu der jeweiligen (Mobilfunk-)Zelle,
usw. erlauben. Unter Verwendung dieser Tabellen und weiterer Informationen
wie z.B. der Kenntnisse der Datenformate, die den einzelnen physikalischen
Kanälen
zugrunde liegen, werden die demodulierten Symbole gezielt (d.h.
Modulspezifisch) aus dem Speicherbereich ausgelesen. Der DSP übernimmt
hier in Bezug auf die Zuordnung der Symbole zu den einzelnen Hardware-Modulen
also hauptsächlich
Verwaltungsaufgaben. Die Nachteile dieser Vorgehensweise bestehen
in dem Zwischenspeicher-Schritt (großer Speicherplatzbedarf) und
dem Sortiervorgang mittels mehrerer Tabellen (relativ hoher Verwaltungsaufwand
für den
DSP).
-
Der Erfindung liegt die Aufgabe zugrunde, ein
Verfahren und eine Schaltung anzugeben, welche eine aufwandsgünstige Ankopplung
von Hardware-Modulen an einen Rake-Demodulator schaffen. Insbesondere
soll ein geringer Speicherplatzbedarf erreicht und eine den DSP
möglichst
wenig belastende Zuteilung von Symbolen zu den einzelnen Hardware-Modulen
erreicht werden.
-
Die der Erfindung zugrunde liegende
Aufgabenstellung wird durch die Merkmale der unabhängigen Ansprüche gelöst.
-
Bei dem erfindungsgemäßen Verfahren
zur Übergabe
von Symbolen, die von einer Mehrzahl von Rake-Fingern ausgegeben
werden, an mehrere aufgabenspezifische Hardware-Module stehen die Hardware-Module über jeweilige
Modul-zugeordnete Schnittstellen mit dem Ausgang des Rake-Demodulators
in Verbindung. Für
ein von einem bestimmten Rake-Finger ausgegebenes Symbol wird in
der Schnittstelle eine Finger-spezifische Auswahlinformation ermittelt
oder von dieser entgegengenommen. In der Schnittstelle wird das
Symbol in Abhängigkeit
von der Finger-spezifischen Auswahlinformation an das Modul weitergegeben
oder verworfen.
-
Demnach verfolgt das erfindungsgemäße Verfahren
ein dezentrales Konzept, bei welchem die Auswahl der von jedem Hardware-Modul benötigen Symbole
zumindest teilweise "vor Ort" in jeder Modul-zugeordneten Schnittstelle
erfolgt. Die Auswahl wird anhand der Finger- und Modul-spezifischen Auswahlinformation
durchgeführt.
-
Die Auswahlinformation ist Finger-spezifisch,
da im Betrieb jeder (aktive) Finger einem bestimmten physikalischen
Kanal zugeordnet ist. Da unterschiedliche Module unterschiedliche
Symbole verarbeiten, ist die Auswahlinformation in der Regel auch
Modul-spezifisch.
-
Ein wesentlicher Vorteil des erfindungsgemäßen Verfahrens
besteht darin, dass eine Zwischenspeicherung der von dem Rake-Demodulator ausgegebenen
Symbole nicht erforderlich ist. Die Symbole werden "on the fly"
in den Modul-zugeordneten Schnittstellen überprüft und entweder verworfen oder
an das zugehörige
Hardware-Modul weitergeleitet. Dadurch wird eine erhebliche Einsparung von
Speicherplatz erreicht. Ein weiterer, ebenfalls im Hardware-Bereich
auftretender Vorteil ist darin zu sehen, dass das erfindungsgemäße Verfahren
skalierbare Schaltungsentwürfe
ermöglicht.
D.h., dass beim Hinzufügen
eines weiteren Hardware-Moduls zu einem Schaltungsentwurf lediglich
dessen Modul-zugeordnete Schnittstelle implementiert werden muss. Die
Arbeitsweise der anderen Schnittstellen und Module wird hierdurch
nicht beeinflusst.
-
Gemäß einer bevorzugten Ausführungsvariante
des erfindungsgemäßen Verfahrens
wird für
ein von einem bestimmten Rake-Finger ausgegebenes Symbol in der
Modul-zugeordneten Schnittstelle Finger-spezifische Verarbeitungsinformation
ermittelt oder von dieser entgegengenommen, wobei die Fingerspezifische
Verarbeitungsinformation eine bestimmte Berechnungsvorschrift in
dem Hardware-Modul festlegt. Auf diese Weise wird nicht nur die
Auswahl der geeigneten Symbole für
das Hardware-Modul sondern zusätzlich
auch die Verarbeitung der Symbole in dem Hardware-Modul durch die übermittelte
Information gesteuert.
-
Vorzugsweise handelt es sich bei
der Finger-spezifischen Auswahlinformation um eine Formatangabe
des diesem Rake-Finger aktuell zugeordneten physikalischen Kanals.
Die jeweilige Schnittstelle kann anhand der Formatangabe die für das nachgeordnete
Modul bestimmten Symbole aus dem Symbolstrom extrahieren.
-
Nach einer bevorzugten Verfahrensausführung wird
zunächst
in einem vorgelagerten Verfahrensschritt überprüft, ob ein Rake-Finger aktiv ist
und einen für
das Hardware-Modul vorgesehenen Kanal demoduliert. Nur wenn diese Überprüfung positiv ausfällt, wird
gemäß dem erfindungsgemäßen Verfahren
in der Schnittstelle die Auswahlinformation ermittelt oder entgegengenommen
und die einlaufenden Symbole werden an das Hardware-Modul weitergeleitet
oder verworfen. Der Vorteil dieser Vorgehensweise besteht darin,
dass die Schnittstelle sowie das zugehörige Hardware-Modul abgeschaltet
bleiben können,
solange die in dem vorgelagerten Verfahrensschritt stattfindende Überprüfung negativ ausfällt.
-
Bei einer ersten vorteilhaften Verfahrensvariante
werden sämtliche
von den Rake-Fingern ausgegebenen Symbole ohne Zwischenspeicherung
direkt den Modul-zugeordneten Schnittstellen zugeleitet. Anschaulich
gesprochen greift sich bei diesem Verfahren jedes Hardware-Modul
mittels seiner Schnittstelle die benötigten Symbole aus dem von
dem Rake-Demodulator gelieferten Gesamt-Symbolstrom heraus. Die
Symbolauswahl erfolgt in diesem Fall vollständig dezentral am jeweiligen
Hardware-Modul.
-
Eine alternative Vorgehensweise kennzeichnet
sich dadurch, dass den Modul-zugeordneten Schnittstellen jeweils
nur diejenigen Symbole zugeleitet werden, die von einem Rake-Finger
ausgegeben werden, der einen für
das Hardware-Modul vorgesehenen Kanal demoduliert. In diesem Fall
wird hinsichtlich der Symbole, die der Modul-zugeordneten Schnittstelle
des Hardware-Moduls zugeleitet werden, bereits eine Finger-bezogene
Vorauswahl getroffen. Die abschließende Entscheidung, welche der
an der Modul-zugeordneten Schnittstelle erhaltenen Symbole im Hardware-Modul
prozessiert werden, wird wiederum anhand der Auswahlinformation in
der Schnittstelle des Hardware-Moduls
getroffen.
-
Die erfindungsgemäße Schaltung zur Übergabe
von Symbolen, die von einer Mehrzahl von Rake-Fingern ausgegeben
werden, an mehrere aufgabenspezifische Hardware-Module umfasst eine
dem jeweiligen Modul zugeordnete Schnittstelle. Diese weist ein
Logikmittel zum Überprüfen einer
Finger-spezifischen Auswahlinformation und ein Mittel zum Verwerfen
eines Symbols oder Weiterleiten desselben an das Hardware-Modul
in Abhängigkeit
von dem Ergebnis der Überprüfung der
Finger-spezifischen Auswahlinformation auf.
-
Die Erfindung wird nachfolgend anhand
von Ausführungsbeispielen
unter Bezugnahme auf die Zeichnung näher erläutert; in dieser zeigt:
-
1 eine
schematische Darstellung des Aufbaus eines Multicode-Rake-Fingers;
-
2 eine
schematische Darstellung der Architektur einer erfindungsgemäßen Schaltung
nach einem ersten Ausführungsbeispiel;
-
3 eine
Tabelle, die die für
die SINR-Schätzung
benötigten
Parametersätze
zur Ansteuerung einer erfindungsgemäßen Schnittstelle verdeutlicht;
-
4 eine
Schaltungsdarstellung der in 2 dargestellten
Schnittstelle für
die SINR-Schätzung;
-
5 eine
Variante der in 2 gezeigten Architektur
der erfindungsgemäßen Schaltung;
und
-
6 eine
schematische Darstellung der Architektur einer erfindungsgemäßen Schaltung
nach einem zweiten Ausführungsbeispiel
der Erfindung.
-
In 1 ist
ein 4-kanaliger Multicode-(MC-)Rake-Finger MC_RF_1 sowie weitere perspektivisch
dahinter liegend dargestellte MC-Rake-Finger MC_RF_2, ..., MC_RF_p
identischen Aufbaus dargestellt (p ist eine ganze Zahl). Den MC-Rake-Fingern
MC_RF_1, ..., MC_RF_p werden über
einen Eingang 11 Abtastwerte rn zugeführt (n ist
der Index der diskretisierten Zeit), welche in üblicher Weise durch Quantisierung
eines über
eine Antenne empfangenen, gefilterten, verstärkten und ins Zwischen- oder
Basisband heruntergemischten analogen Empfangssignals gewonnen werden.
-
Im folgenden wird exemplarisch der
MC-Rake-Finger MC_RF_1 beschrieben. Er weist eingangsseitig eine
einzige, gemeinsame Verzögerungskompensationseinheit
auf, welche aus einer Einheit 12 zur Schätzung der
Mehrwegeverzögerung,
einer Verzögerungsstufe 13,
einer Einheit 20 zur Berechnung von Interpola tionsparametern
und einem Interpolator 21 besteht. Der 4-kanalige MC-Rake-Finger MC_RF_1
entspricht somit vier einzelnen Rake-Fingern mit identischer Verzögerung.
-
Das Ausgangssignal 18 der
Verzögerungskompensationseinheit 12, 13, 20, 21 wird
vier parallel angeordneten Korrelatoren 14.1, 14.2, 14.3, 14.4 zugeleitet.
Den Korrelatoren 14.1, 14.2, 14.3, 14.4 sind vier
parallel liegende Akkumulatoren 15.1, 15.2, 15.3, 15.4 nachgeordnet,
von denen jeder ein Ausgangssignal eines der Korrelatoren 14.1, 14.2, 14.3, 14.4 empfängt. Die
Ausgangssignale der Akkumulatoren 15.1, 15.2, 15.3 werden
drei parallel angeordneten Gewichtungseinheiten (Multiplizierern) 16.1, 16.2, 16.3 zugeleitet.
Die Ausgänge 17.1, 17.2 und 17.3 der
drei Gewichtungseinheiten 16.1, 16.2, 16.3 und der
Ausgang 17.4 des Akkumulators 15.4 stellen die vier
Ausgänge
des MC-Rake-Fingers MC_RF_1 dar.
-
Alternativ können auch die vier Ausgänge der
Akkumulatoren 15.1, 15.2, 15.3, 15.4 die
Ausgänge
des MC-Rake-Fingers MC_RF_1 darstellen. Die Gewichtung entsprechend
der Gewichtungseinheiten 16.1, 16.2, 16.3 erfolgt
in diesem Fall mittels eines peripheren Hardware-Moduls. In diesem
Fall wird der Symbolbus SB (siehe 2)
von den Ausgängen
der Akkumulatoren 15.1, 15.2, 15.3, 15.4 gespeist.
-
Die Einzelfinger 14.1, 15.1, 16.1 bzw. 14.2, 15.2, 16.2 bzw. 14.3, 15.3, 16.3 bzw. 14.4, 15.4 des MC-Rake-Fingers
MC_RF_1 werden im folgenden als Code-Komponenten MC1, MC2, MC3 bzw.
MC4 des MC-Rake-Fingers MC_RF_1 bezeichnet.
-
Die Arbeitsweise des MC-Rake-Fingers MC_RF_1
ist wie folgt: Zunächst
wird der MC-Rake-Finger MC_RF_1 auf eine bestimmte Mehrwegeverzögerung (Delay)
eingestellt, d.h. auf einen bestimmten Ausbreitungsweg des zu demodulierenden Funksignals
gesetzt. Die zeitliche Justage des MC-Rake-Fingers MC_RF_1 erfolgt
zweistufig. Die Einheit 12 führt eine Schätzung der
Mehrwegeverzögerung
im Abtastzeitraster, das heißt
mit einer durch die Abtastrate (entspricht z.B. der doppelten Chiprate)
begrenzten Genauigkeit, durch. Hierzu wird zunächst das Kanalprofil bestimmt
(d.h. es werden die Energien der über die verschiedenen Ausbreitungswege übertragenen
Signale ermittelt) und anhand des Kanalprofils werden die Verzögerungen
der energiereichsten Ausbreitungswege bestimmt. Die auf diese Weise
ermittelte Grob-Verzögerungseinstellung
wird von der Verzögerungsstufe 13 vorgenommen.
Eine genauere zeitliche Auflösung
der Mehrwegeverzögerung
wird anschließend
mit der Einheit 20 zur Berechnung eines Interpolationsparameters
(d.h. eines Abtastzeitfehlers) erreicht. Bei der Einheit 20 kann
es sich beispielsweise um einen Early/Late-Korrelator handeln. Mit
dem von der Einheit 20 berechneten Interpolationsparameter
wird ein Interpolator 21 angesteuert. Dieser erzeugt interpolierte
Datenwerte an den von dem Interpolationsparameter bestimmten Stützstellen.
-
Am Ausgang 18 des Interpolators 21 liegt das
Signal mit einer zeitlichen Auflösung
vor, die kleiner als die halbe Chipzeitdauer (im UMTS-Standard beträgt die Chipzeitdauer
2.6 μs)
ist. Da der MC-Rake-Finger MC_RF_1 lediglich die über einen
einzigen Ausbreitungsweg übertragenen
Signalanteile demoduliert, reicht eine einzige Verzögerungskompensationseinheit 12, 13, 20, 21 aus,
um sämtliche
Code-Komponenten MC1, MC2, MC3, MC4 des MC-Rake-Fingers MC_RF_1
zeitrichtig zu justieren.
-
Die Korrelatoren 14.1, 14.2, 14.3, 14.4 stehen
in nicht dargestellter Weise mit Spreizcode- und Scrambling-Code-Generatoren
in Verbindung. Jeder Korrelator 14.1, 14.2, 14.3, 14.4 wird
mit einem bestimmten Teilnehmer- oder Kanal-spezifischen Spreizcode
und einem Zell-spezifischen Scrambling-Code betrieben, um die gewünschten
Signale (genauer: deren Wegekomponenten) aus dem diskretisierten
Empfangssignal rn zu demodulieren. Dies wird
auch als Entspreizung ("despreading") bzw. Entscrambeln ("descrambling")
bezeichnet. Die Zuteilung der jeweiligen Spreiz- und Scramblingcodes
zu den einzelnen Korrelatoren 14.1, 14.2, 14.3, 14.4 erfolgt
zentral durch eine nicht dargestellte Steuerung (DSP).
-
Die Akkumulatoren 15.1 bis 15.4 stellen
die Integrate&Dump-Einheiten der Code-Komponenten MC1,
MC2, MC3, MC4 dar. Es wird stets eine Akkumulation über sf Chips
vorgenommen, wobei sf den Spreizfaktor des jeweiligen Spreizcodes
bezeichnet. Am Ausgang der Akkumulatoren 15.1 bis 15.4 liegen die
Daten als Symbole im (jeweiligen) Symboltakt vor.
-
Die Gewichtungseinheiten 16.1, 16.2, 16.3 multiplizieren
die Symbole innerhalb der Code-Komponenten MC1, MC2, MC3 mit Gewichtsfaktoren, welche
in ständiger
Wiederholung von einem Kanalschätzer
(nicht dargestellt) ermittelt und aktualisiert werden.
-
Die identisch aufgebauten Code-Komponenten
MC1, MC2, MC3 dienen zur Rekonstruktion von Nutzdaten für verschiedene
physikalische Kanäle, wobei
sowohl die verwendeten Spreizcodes (Scramblingcodes) als auch die
Spreizfaktoren sf dieser Kanäle
unterschiedlich sein können.
Die weitere Code-Komponente MC4 ist bei dem hier gezeigten Beispiel
nicht für
den (Nutz-)Datenempfang vorgesehen (da sie keine Gewichtungseinheit
aufweist), sondern ist zur Erzeugung von Messdaten für die Kanalschätzung unter
Zuhilfenahme eines Pilotsignals ausgelegt. Im UMTS-Standard können beispielsweise
die ersten drei Code-Komponenten MC1, MC2, MC3 zum Demodulieren
der physikalischen Datenkanäle DPCH
(Dedicated Physical Channel), DSCH (Downlink Shared Channel), SCCPCH
(Secondary Common Control Physical Channel) und die vierte Code-Komponente
MC4 zur Demodulation des ersten und/oder zweiten gemeinsamen Pilotkanals
pCPICH (primary Common Pilot Channel) oder sCPICH (secondary Common
Pilot Channel) vorgesehen sein.
-
Die weiteren MC-Rake-Finger MC_RF_2,
..., MC_RF_p weisen bezüglich
der in dem Rahmen 22 dargestellten Baugruppen 21,
MC1, MC2, MC3, MC4 einen identischen Aufbau auf. Sie werden entsprechend
dem bekannten Funktionsprinzip eines Rake-Demodulators in gleicher Weise, jedoch
mit einer anderen (anhand des Kanalprofils von der Einheit 12 ermittelten)
Verzögerung
betrieben.
-
2 zeigt
die Anbindung von aufgabenspezifischen Hardware-Modulen an den MC-Rake-Finger MC_RF_1.
-
Der MC-Rake-Finger MC_RF_1 ist über einen
Parallel-zu-Seriell Wandler P/S mit einem Symbolbus SB verbunden.
Von den Code-Komponenten MC1,
MC2, MC3, MC4 gleichzeitig ausgegebene Symbole werden von dem Parallel-zu-Seriell
Wandler P/S nacheinander an den Symbolbus SB ausgegeben.
-
Der gesamte Rake-Demodulator kann
z.B. aus p = 32 derartigen MC-Rake-Fingern MC_RF_1, ..., MC_RF_32
bestehen, wobei der Rake-Demodulator in diesem Fall 128 einzelne
Code-Komponenten MC1, MC2, MC3, MC4 beinhaltet. Die Anzahl der physikalischen
MC-Rake-Finger muss jedoch nicht der Anzahl p der MC-Rake-Finger MC_RF_1, ..., MC_RF_p
entsprechen. Sie kann wesentlich kleiner sein. Beim vorliegenden
Beispiel ist z.B. nur ein einziger physikalischer MC-Rake-Finger
MC_RF_1 vorhanden, der 32-fach Zeit-gemultiplext wird. Das bedeutet,
dass dieser (einzige) physikalische MC-Rake-Finger MC_RF_1 fortwährend – z.B. immer
nach der Verarbeitung von 4 Chips – umprogrammiert wird. Ist
z.B. sf = 4, werden die Rake-Finger MC_RF_1, ..., MC_RF_p nach jedem
Symbol umprogrammiert. Durch die Umprogrammierung, die sowohl die
Verzögerungseinstellung
als auch die Demodulation betrifft, werden die restlichen 31 MC-Rake-Finger als virtuelle
MC-Rake-Finger MC_RF_2, ..., MC_RF_32 realisiert.
-
Für
die Ausgabe der Symbole an den Symbolbus SB wird das folgende Schema
gewählt,
wobei die Ziffern System-Takte bezeichnen, zu denen die Symbole
der 4 Code-Komponenten MC1, MC2, MC3, MC4 auf den Symbolbus SB gelegt
werden. Ob zu den angegebenen System-Takten 1, 2, 3, 4,
die Code-Komponenten MC1, MC2, MC3, MC4 der MC-Rake-Finger MC_RF_r,
r = 1, 2, ..., 32, tatsächlich
Symbole ausgeben, hängt
von den jeweiligen Spreizfaktoren der Code-Komponenten MC1, MC2, MC3,
MC4 ab. Ein Symbol kann erst dann ausgegeben werden, wenn es in
dem jeweiligen Akkumulator 15.1, 15.2, 15.3, 15.4 fertiggestellt
ist, d.h. die Integration über
sf Chips abgeschlossen ist. Mit sf = 4 können alle 4 System-Takte 4 demodulierte
Symbole (für
die vierte Code-Komponente MC4, die den gemeinsamen Pilotkanal CPICH
mit 256 Chips pro Pilotsequenz demoduliert, nur alle 256 System-Takte) an
den Systembus SB angelegt werden.
-
Die Symbole, sofern vorhanden, werden
zyklisch in der folgenden Reihenfolge der Code-Komponenten und MC-Rake-Finger
MC_RF_r an den Symbolbus SB ausgegeben:
-
Ferner müssen nicht ständig sämtliche MC-Rake-Finger
MC_RF_1, ..., MC_RF_32 aktiv sein. Werden (aus Energiespargründen) einzelne MC-Rake-Finger
abgeschaltet, treten zu den für
diese Finger reservierten Zeiten keine Symbole auf dem Symbolbus
SB auf. Jeder MC-Rake-Finger MC_RF_r kennzeichnet ein gültiges Symbol
auf dem Symbolbus SB mit einem Signal symb_ready.
-
Der Symbolbus SB steht mit mehreren
zueinander parallel angeordneten peripheren, aufgabenspezifischen
Hardware-Modulen in Verbindung, und zwar einer Einheit zur automatischen
Frequenzkorrektur AFC, einer Einheit zur Schätzung von Kanalgewichten CWE,
einer Einheit zur Schätzung
des Signal-zu-Stör-Verhältnisses
SINR, einer Einheit zur Verarbeitung von Zellenspezifischen TPC-(Transmit Power
Control-)Symbolen sowie einer Einheit zum Kombinieren von Symbolen
MRC. Die Verbindung zu den einzelnen Hardware-Modulen AFC, CWE,
SINR, TPC und MRC erfolgt über
jeweilige Schnittstellen IF_AFC, IF_CWE, IF_SINR, IF_TPC und IF_MRC.
-
Das Modul AFC berechnet eine Frequenzkorrektur
des erhaltenen Signals auf der Basis von gemeinsamen Pilotsymbolen,
welche (hier) von der vierten Code-Komponente MC4 ausgegeben werden.
-
Das Modul CWE berechnet Kanalgewichte auf
der Basis von dedizierten Pilotsymbolen und/oder gemeinsamen Pilotsymbolen.
Die dedizierten Pilotsymbole werden von derjenigen Code-Komponente MC1,
MC2, MC3 geliefert, welche den dedizierten Downlink-Kanal DPCH demoduliert.
Im folgenden wird angenommen, dass dies stets die Code-Komponente
MC1 ist. Die gemeinsamen Pilotsymbole werden wiederum von der Code-Komponente
MC4 bei Demodulation des gemeinsamen Pilotkanals CPICH zur Verfügung gestellt.
-
Die SINR-Schätzung durch das Modul SINR wird
ebenfalls auf der Basis der dedizierten Pilotsymbole (Kanal DPCH)
oder der gemeinsamen Pilotsymbole (Kanal CPICH) durchgeführt. Wiederum
werden hierfür
die Symbole der ersten Code-Komponente MC1 und der vierten Code-Komponente
MC4 verwendet.
-
Das Modul TPC führt eine Vorverarbeitung von
TPC-Symbolen zur Berechnung von Leistungssteuersignalen für die Basisstation
durch. Es besteht aus drei Untermodulen: Das Untermodul TPC1 führt eine
Datenverarbeitung in Abhängigkeit
von dem gewählten
Antennenmodus – STTD
(der UMTS-Zwei-Antennenmodus STTD wird im folgenden noch näher erläutert) oder
Normalmodus – durch.
Das Modul TPC2 führt
eine Kombination der von dem Modul TPC1 erhaltenen Daten innerhalb
einer Zelle durch. Das Modul TPC3 normiert die von dem Modul TPC2
erhaltenen Zellenspezifischen Symbole. Die Berechnung der Leistungssteuersignale
beruht auf den demodulierten TPC Symbolen des dedizierten Downlink-Kanals
DPCH, welche wie bereits erwähnt,
von der Code-Komponente MC1 ausgegeben werden. Die TPC-Symbole werden
im DPCH-Rahmen bekanntlich direkt hinter dem ersten Datenfeld Datal
gesendet. Die in 3GPP TS 25.211 V4.2.0 (2001-09), Kapitel 5.3.2,
festgelegte Rahmenstruktur des DPCH-Rahmens wird durch Bezugnahme
dem Offenbarungsgehalt der vorliegenden Schrift hinzugefügt.
-
Das Modul MRC weist vier Untermodule
auf: Das erste Untermodul MRC1 führt
eine Datenverarbeitung in Abhängigkeit
von dem Antennenmodus (STTD oder Normalmodus) des zu kombinierenden Signals
durch. In dem Modul MRC2 wird eine Zellen-spezifische Kombination
der erhaltenen Symbole durchgeführt.
Das Modul MRC3 führt
eine Normierung der für
jede Zelle erhaltenen Symbole durch die Rauschvarianz durch. In
dem Untermodul MRC4 werden schließlich Symbole, die demselben
Kanal angehören
aber aus unterschiedlichen Zellen empfangen wurden, kombiniert.
-
Das Modul MRC stellt den "Combiner"
des Rake-Demodulators dar (der hier aus dem einen physikalischen
MC-Rake-Finger MC_RF_1 und den 31 virtuellen MC-Rake-Fingern MC_RF_2,
..., MC_RF_32, insgesamt also aus 128 Rake-Fingern, besteht). Der
Combiner hat bekanntlich die Aufgabe, die wegeindividuell entspreizten
Signalkomponenten kanalweise wieder zusammenzuführen. Der Kombination liegen
sämtliche
Symbole zugrunde, die von den Code-Komponenten MC1, MC2, MC3 und
MC4 geliefert werden.
-
Die Module MRC1, MRC2 und MRC3 stellen gleichzeitig
eine Vorverarbeitung zur Auswertung von TFCI-(Transport Format Combination
Identificator-)Symbolen dar. Die über eine Zelle kombinierten TFCI-Symbole
werden am Ausgang der Untereinheit MRC3 aus dem Modul MRC ausgekoppelt.
Der (nicht dargestellten) Auswerteeinheit für die TFCI-Symbole ist eine
Schnittstelle IF_TFCI vorgeordnet. Die TFCI-Symbole werden im DPCH-Rahmen bekanntlich
direkt hinter den TPC-Symbolen gesendet. Also werden für die Auswertung
nur Symbole benötigt,
die von der Code-Komponente MC1 ausgegeben werden.
-
Ferner stellt die Schaltung über die
Schnittstelle IF_PIL auch bereits zellenweise kombinierte gemeinsame
Pilotsymbole des CPICH-Kanals für Auswertezwecke
zur Verfügung.
Die von der Schnittstelle IF_PIL weitergeleiteten zellenweise kombinierten
gemeinsamen Pilotsymbole stammen von der Code-Komponente MC4, welche den Kanal CPICH demoduliert.
-
Die Hardware-technische Ausführung der Module
AFC, CWE, SINR, TPC und MRC (sowie der oben genannten nicht dargestellten
Auswerteeinheiten) ist für
die vorliegende Erfindung nicht von Bedeutung, und es wird darauf
hingewiesen, dass auch andere bzw. weitere Module an dem Symbolbus
SB angeschlossen sein können.
Wichtig ist lediglich, dass die Signalverarbeitung der einzelnen
Module auf zumindest teilweise unterschiedlichen Symbolen (die zumindest
teilweise in unterschiedlichen Kanälen gesendet werden) beruht.
-
Die Auswahl der für die Module AFC, CWE, SINR,
TPC und MRC benötigten
Symbole erfolgt über
die jeweiligen Schnittstellen IF_AFC, IF_CWE, IF_SINR, IF_TPC und
IF_MRC. Sämtlichen
Schnittstellen IF_AFC, IF_CWE, IF_SINR, IF_TPC, IF_MRC wird ein
Signal r, r = 1, ..., p, zugeleitet, das angibt, von welchem (gegebenenfalls
virtuellen) MC-Rake-Finger MC_RF_r das aktuell im Symbolbus SB anstehende
Symbol stammt. Darüber
hinaus wird den Schnittstellen IF_AFC, IF_CWE, IF_SINR, IF_TPC und
IF_MRC ein Zählimpuls
main_cnt zugeleitet, welcher im 4-Chip Takt (d.h. alle 4 Chips ein
Impuls) auftritt und es wird ein Rücksetzsignal slot_sync übermittelt,
welches den Rahmen-Beginn des DPCH-Kanals mitteilt. Zusätzlich gibt
ein weiteres Signal symb_cnt für
jeden MC-Rake-Finger MC_RF_r die CPICH Symbol-Nummer bezogen auf
den Rahmen-Beginn des jeweiligen CPICH-Kanals (ist für jede Zelle
verschieden) an. Dieses Signal wird lediglich von der Schnittstelle
IF_AFC benötigt.
Die Signale r, symb_ready, main_cnt und slot_sync sind in 2 durch das Gesamtsignal
s_info zusammengefasst.
-
Die Auswahl der in den jeweiligen
Modulen benötigen
Symbole erfolgt anhand von Tabellen. In 3 ist in beispielhafter Weise die Tabelle
dargestellt, anhand der die Schnittstelle IF_SINR die von dem Modul
SINR benötigten
Symbole auswählt.
-
Das Beispiel geht von einer Anzahl
von 32 MC-Rake-Fingern MC_RF_1, ..., MC_RF_32. Eine Vereinfachung
wird durch die bereits erwähnte
Vorgabe erreicht, dass stets nur die erste Code-Komponente MC1 jedes
MC-Rake-Fingers für
die Lieferung der dedizierten Pilotsymbole und die vierte Code-Komponente
MC4 für
die Lieferung der gemeinsamen Pilotsymbole vorgesehen sind. Da das
Modul SINK für
seine Zwecke nur Pilotsymbole (dedizierte oder gemeinsame) benötigt, brauchen
die zweiten und dritten Code-Komponenten MC2 und MC3 nicht überwacht
zu werden.
-
In der ersten Spalte ENA_SINR der
oberen Tabellenhälfte
für das
Modul SINR sind 32 Aktivierungs-Bits mc1_1, mc1_2, ..., mc1_32 der
ersten Code-Komponente MC1 jedes MC-Rake-Fingers MC_RF_1, ..., MC_RF_32
dargestellt. In der unteren Hälfte
der in 3 dargestellten
Tabelle sind in derselben Spalte (ENA_SINR) die 32 Aktivierungs-Bits mc4_1,
mc4_2, ..., mc4_32 der vierten Code-Komponente MC4 jedes MC-Rake-Fingers
MC_RF_1, ..., MC_RF_32 angegeben. Die Aktiverungs-Bits mc1_1, mc1_2,...,
mc1_32 werden von dem DSP (nicht dargestellt) gesteuert. Das Aktivierungs-Bit
mc1_r (mc4_r) des MC-Rake-Fingers
MC_RF_r ist immer dann gesetzt (Wert 1), wenn der SINR-Messung dedizierte
Pilotsymbolen (gemeinsame Pilotsymbole) des MC-Rake-Fingers der
Nummer r zugrunde gelegt werden sollen. Ansonsten weist das Aktivierungs-Bit den
Wert 0 auf.
-
Jedem Aktivierungs-Bit mcy_r (y =
1, 4; r = 1,..., 32) sind folgende in der Tabelle in derselben Zeile
angegebenen Parameter zugeordnet:
-
- – Zellen-Nummer:
Da die SINR-Schätzung
jeweils bezüglich
einer (Mobilfunk-)Zelle durchgeführt
wird, muss für
jeden MC-Rake-Finger
MC_RF_r die Zellen-Nummer angegeben werden. Da Signale aus maximal
z.B. sechs Zellen in dem Empfänger
gleichzeitig empfangen und verarbeitet werden können, sind drei Bits z1_r,
z2_r, z3_r zur Codierung der Zellen-Nummer ausreichend.
- – Nur
ein dediziertes Pilotsymbol (1D): Die Anzahl der dedizierten
Pilotsymbole im Kanal DPCH ist variabel. Für den Fall, dass nur ein einziges
dediziertes Pilotsymbol übertragen
wird, muss in dem Modul SINR ein spezieller Berechnungsmodus angewendet werden.
In diesem Fall nimmt das in der Spalte 1D eingetragene
Bit d1, d2, ..., d32 z.B. den Wert 1 an.
- – STTD-Modus
(STTD): Im UMTS-Standard ist ein senderseitiger Zwei-Antennenmodus
in den Downlink-Kanälen
möglich.
Im STTD-Modus werden jeweils vier aufeinanderfolgende Bits b0, b1,
b2, b3 über
eine erste Antenne in der unveränderten
Reihenfolge (b0, b1, b2, b3) und über eine zweite Antenne in
der STTD-codierten Reihenfolge (–b2, b3, b0, –b1) ausgesandt,
siehe 3GPP TS 25.211 V4.4.0 (2002-03), Kapitel 5.3.1.1.1. Sofern
der STTD-Modus eingesetzt wird, sind die zugehörigen Bits s1, s2, ..., s32
gleich 1. Durch Auslesen dieser Fingerbezogenen Bits wird in dem
Modul SINR der geeignete Berechnungsmodus eingestellt.
- – Zeitschlitz-Format-Referenz
(SL-FO): Über
zwei Bits f1_r und f2_r können
vier verschiedene Zeitschlitz-Formate (SL-FO) des von der Code-Komponente
MC1 demodulierten Kanals DPCH referenziert werden. Wie im folgenden
noch näher
erläutert
wird, können
spezifische Angaben zu den referenzierten Zeitschlitz-Formaten aus
einer z.B. für
alle Module gemeinsamen Tabelle (d.h. einer Tabelle, deren Einträge nicht
Modulspezifisch sind) ausgelesen werden, auf welche alle Schnittstellen
IF_AFC, IF_CWE, IF_SINR, IF_MRC und IF_TPC Zugriff haben.
-
Welche Parameter von der Schnittstelle SINR
benötigt
werden, ist davon abhängig,
ob die SINR-Messung auf der Basis der dedizierten Pilotsymbole (aus
dem Kanal DPCH) oder der gemein samen Pilotsymbole (aus dem Kanal
CPICH) durchgeführt
werden soll. Soll die SINR-Schätzung
nur anhand der gemeinsamen Pilotsymbol (Kanal CPICH) durchgeführt werden,
sind lediglich Einträge
zu den Parametern Zellen-Nummer und STTD erforderlich, siehe die
untere Hälfte
der in 3 dargestellten
Tabelle.
-
Es wird deutlich, dass die in der
Modul-spezifischen Tabelle verwalteten Parameter allgemein nach
Auswahlparametern und Verarbeitungsparametern unterschieden werden
können:
Auswahlparameter ermöglichen
es der Schnittstelle, zu entscheiden, ob ein eintreffendes Symbol
für die
Prozessierung in dem Modul an dieses weitergeleitet werden soll
oder nicht. Verarbeitungsparameter steuern eine bestimmte Verarbeitung
oder Berechnungsweise des Moduls. Bei dem hier dargestellten Beispiel
sind die Parameter ENA_SINR (Aktivierungs-Bits mc1_1, ..., mc132
sowie mc4_1, ..., mc4_32) und die Parameter SL-FO Auswahlparameter
und die restlichen Parameter sind Verarbeitungsparameter.
-
Den Tabellen für die weiteren Module AFC, CWE,
SNR, MRC liegt die gleiche Aufbausystematik zugrunde. Sowohl die
Zeilenangaben als auch die in den Spalten angegebenen Parameter
sind jedoch Modul-spezifisch und können damit von der in 3 gezeigten Darstellung
abweichen.
-
Z.B. kann die Schätzung von Kanalgewichten (Modul
CWE) ebenfalls auf der Basis von dedizierten und gemeinsamen Pilotsymbolen
durchgeführt
werden, weshalb ebenfalls die Aktivierungs-Bits mcy_r, y = 1, 4
und r = 1, ..., 32, benötigt
werden. Die Spalteneinträge
umfassen hier neben der Zeitschlitz-Format-Referenzangabe SL-FO (2 Bit)
und einer Angabe über
den STTD-Modus (1 Bit) ferner auch eine Referenzangabe über das
verwendete Pilotsymbol-Muster (2 Bit) und eine Extrapolationsangabe
(1 Bit), die die Berechnungsweise des Moduls CWE in der Weise beeinflusst,
dass eine Extrapolation der Kanal- Gewichtskoeffizienten auf der Basis von
Ergebnissen in früheren
Zeitschlitzen ermöglicht wird.
-
Ein weiteres Beispiel: Da das Modul
MRC eine Kombination sämtlicher
demodulierten Kanäle vornimmt,
muss dessen Tabelle sämtliche
Aktivierungs-Bits mcy_r, y = 1, ..., 4 und r = 1, ..., 32, enthalten.
Modul-spezifische Parameter für
die Code-Komponenten
MC1, MC2, MC3 sind die Zellen-Nummer (3 Bit), der STTD-Modus (1
Bit), eine Angabe, zu welchem physikalischen Kanal (DPCH1, DPCH2, DSCH1,
DSCH2, sCCPCH) das demodulierte Symbol gehört (3 Bit), und eine (andere)
Zeitschlitz-Format-Referenzangabe
(3 Bit), die die möglichen
Zeitschlitz-Formate der demodulierten Kanäle referenziert.
-
Die Funktionsweise der in 2 dargestellten Schaltung
ist wie folgt.
-
Vorausgesetzt wird, dass der Rake-Demodulator
in bestimmter Weise konfiguriert ist, d.h. dass (1) die einzelnen
MC-Rake-Finger MC_RF_1,
..., MC_RF_32 mittels der Delay-Einstellung bestimmten Ausbreitungswegen
zugeordnet sind und dass (2) die Code-Komponenten MC1, MC2, MC3,
MC4 bestimmten Kanälen
zugeordnet sind, d.h. mit bestimmten vorgegebenen Spreiz- und Scramblingcodes
die erhaltenen Eingangschips demodulieren. Diese Konfigurierung
bzw. Programmierung wird von dem DSP vorgenommen und ist diesem
bekannt. Nun soll ein aufgabenspezifisches Hardware-Modul eine Berechnung
durchführen.
Exemplarisch wird wiederum das Hardware-Modul SINR betrachtet.
-
Die in 3 dargestellte
Tabelle für
das Hardware-Modul SINR wird in einem lokalen Speicherbereich (in 2 nicht dargestellt) der Schnittstelle
IF_SINR verwaltet. Dieser wird nun von dem DSP folgendermaßen beschrieben:
-
- – Durch
die Eintragung der Aktivierungs-Bits in die Spalte ENA_SINR bestimmt
der DSP, welche der MC-Rake-Finger MC_RF_r mit welchen Code-Komponenten
MCy (y = 1, 4) zur SINR-Messung beitragen sollen. Sollen Symbole,
die von der Code-Komponente MCy des MC-Rake-Fingers MC_RF_r ausgegebenen
werden, grundsätzlich
berücksichtigt werden,
wird mcy_r = 1 gesetzt. Sollen die von der Code-Komponente MCy des
MC-Rake-Fingers MC_RF_r ausgegebenen Symbole nicht berücksichtigt
werden, wird mcy_r = 0 eingetragen. Durch die Einträge in der
Spalte ENA_SINR wird auch festgelegt, ob nur gemeinsame, nur dedizierte
oder sowohl gemeinsame als auch dedizierte Pilotsymbole der SINR-Schätzung zugrunde
gelegt werden sollen.
- – Durch
die Eintragung der zugehörigen
Parameterwerte werden die für
die Berechnung benötigten
Angaben und das jeweils verwendete Zeitschlitz-Format mitgeteilt.
-
Für
jedes von dem Rake-Demodulator auf den Symbolbus SB ausgegebene
Symbol werden nun die folgenden beiden Bedingungen überprüft:
-
1. Bedingung:
-
Ist eine der vorgesehenen Code-Komponenten
(hier: MC1 oder MC4) des MC-Rake-Fingers MC_RF_r aktuell aktiv (Kriterium
1) und ist mc1_r = 1 oder mc4_r = 1 (Kriterium 2)?
-
Ist sowohl das erste als auch das
zweite Kriterium erfüllt,
dann liegt auf dem Symbolbus SB ein von der Code-Komponente MC1
oder MC4 des MC-Rake-Fingers MC_RF_r ausgegebenes Symbol vor (Kriterium
1) und ist für
die Verarbeitung in dem Modul SINR grundsätzlich vorgesehen (Kriterium
2). Die erste Bedingung ist dann erfüllt.
-
Wenn die 1. Bedingung erfüllt ist,
werden von der Schnittstelle IF_SINR die in der Modul-spezifischen
Tabelle der 3 eingetragenen
Komponenten-spezifischen Parameter ausgelesen, d.h. es wird ein
Speicherzugriff auf den internen Speicher vorgenommen. Dann wird
anhand der Auswahlparameter (hier: die Bits im Feld SL-FO) die z.
Bedingung überprüft:
-
2. Bedingung:
-
Ist das aktuelle Symbol für die Bearbeitung
in dem Modul SINR zugelassen?
-
Für
die SINR-Schätzung
auf der Basis des Kanals DPCH sind allein die dedizierten Pilotsymbole,
nicht jedoch die ebenfalls in diesem Kanal übertragenen (Nutz-)Datensymbole
zugelassen. Folglich wird hier überprüft, ob das
aktuelle Symbol ein dediziertes Pilotsymbol oder ein beliebiges
anderes Symbol ist.
-
4 zeigt
ein Schaltungsbeispiel für
die Schnittstelle IF_SINR. Ein Register R1 einer Vorauswahl-Logikschaltung
LOG_R1 dient zur Speicherung der Aktivierungs-Bits mc1_r bzw. mc4_r.
Das Register R2 ist zur Abspeicherung eines zugehörigen Parametersatzes
vorgesehen, braucht zunächst
aber nicht beschrieben zu werden. Ferner umfasst die Schaltung eine
Berechnungslogik LOG mit einem Zähler
CT, einem Komparator CP, einem Festwertspeicher ROM-TAB und einem
Schalter GATE. Mit ena werden in 4 Aktivierungssignale
bezeichnet.
-
Sofern ein fertiges Symbol vorliegt
(wird von dem Demodulator durch symb_ready mitgeteilt), überprüft die Logikschaltung
LOG_R1 anhand der Finger-Nummer r den Wert von mc1_r, d.h. ob das Symbol
für die
Verarbeitung in der Schnittstelle IF_SINR grundsätzlich vorgesehen ist (1. Bedingung).
Sofern dies der Fall ist, werden die Parameterwerte z1_r, z2_r,
z3_r, dr, sr, f1_r, f2_r aus der Tabelle in das Register R2 gelesen.
Außerdem
wird die Berechnungslogik LOG aktiviert.
-
Die Überprüfung der z. Bedingung erfolgt
in der Modulzugeordneten Schnittstelle IF_SINR mittels des Zählers CT
in Verbindung mit einer Auswertung der Zeitschlitz-Format-Referenz
(SL-FO) betreffend das (variable) Zeitschlitz-Format. Der Zähler CT
wird von dem Zählimpuls
main_cnt angestoßen,
zählt im 4-Chip-Takt
hoch und wird mit jedem neuen Zeitschlitzbeginn durch das Signal
slot_sync zurückgesetzt.
Die Auswertung der Zeitschlitz-Format-Referenz-Bits mittels Nachschlagens
in dem die möglichen
Formate enthaltenden Festwertspeicher ROM-TAB liefert die Intervallgrenzen anf
und end für das
Pilotfeld DED_PIL (d.h. das Feld, in welchem die dedizierten Pilotsymbole
im DPCH-Rahmen liegen). Ein DPCH-Rahmen ist in 4 durch die strickpunktiert umrandete
Datenstruktur stilisiert wiedergegeben. Wird im Komparator CP durch
einen Vergleich des Zählwertes
mit den Intervallgrenzen anf und end des Pilotfelds festgestellt,
dass sich das aktuelle Symbol im Pilotfeld befindet, wird der Schalter
GATE geöffnet
und dieses Symbol von dem Modul SINK gelesen. Ferner greift das
Hardware-Modul SINR dann auch auf die Verarbeitungs-Parameterwerte z1_r, z2_r,
z3_r, dr, sr zu. Die Verarbeitung im Modul SINK erfolgt dann mit
Modul-spezifischen und Komponentenspezifischen Verarbeitungsparametern.
Andernfalls wird das aktuelle Symbol verworfen.
-
Zusammengefasst werden also bei dem
hier erläuterten
Beispiel, bei welchem dedizierte Pilotsymbole stets von der Komponente
MC1 demoduliert und gemeinsame Pilotsymbole stets von der Komponente
MC4 demoduliert werden, die den aktuellen Werten des Fingers r und
der Komponente y = 1, 4 zugehörigen
Aktivierungs-Bits mc1_r und mc4_r überprüft. Sofern sich bei der Überprüfung herausstellt,
dass das Aktivierungs-Bit mc1_r den Wert 1 aufweist (1. Bedingung),
werden die Parameter in der durch das Aktivierungs-Bit mc1_r vorgegebenen
Tabellenzeile gelesen und wie oben beschrieben zur Überprüfung der
2. Bedingung und zur Steuerung des Moduls verwendet. Hinsichtlich
des Aktivierungs-Bits mc4_r braucht bei dem hier erläuterten Beispiel
lediglich die 1. Bedingung überprüft und die Verarbeitungsparameter
an das Modul weitergeleitet werden.
-
In analoger Weise werden die Modul-spezifischen
Tabellen der Modul-Schnittstellen IF_AFC, IF_CWE, IF_SINR, IF_TPC,
IF_MRC ständig
abgetastet und deren Einträge überprüft. Im Ergebnis
wird erreicht, dass jedes Hardware-Modul durch eine dezentrale Auswahllogik
genau die für
die Berechnungsaufgabe erforderlichen Symbole erhält.
-
5 zeigt
eine Variante der in 2 dargestellten
Architektur. Auch hier werden sämtliche
von den Rake-Fingern MC_RF_r ausgegebenen Symbole jeweils den Modul-zugeordneten
Schnittstellen IF_MRC, IF_CWE, IF_AFC, IF_SINR und IF_TPC zugeleitet.
Eine weitere Modul-zugeordnete Schnittstelle, IF_TFCI, wird von
Ergebnissen sowie von Kontrollinformation aus der ersten Stufe der
Einheit MRC1 gespeist. Ein Unterschied zu der in 2 dargestellten Anordnung besteht darin,
dass das Modul CWE in zwei einzelne Hardware-Module CCWE und DCWE
aufgespaltet ist, wobei das Modul CCWE für die Berechnung von Kanalgewichten
auf der Basis der gemeinsamen Pilotsymbole und das Modul DCWE für die Berechnung
von Kanalgewichten auf der Basis der dedizierten Pilotsymbole vorgesehen sind.
Analog hierzu ist die in 2 gemeinsame Schnittstelle
IF_CWE in zwei Modul-zugeordnete Schnittstellen IF_CCWE und IF_DCWE
aufgespaltet. Die Schnittstellen IF_CCWE und IF_DCWE sind den jeweiligen
Modulen CCWE bzw. DCWE vorgeordnet.
-
Wie in der 5 erkennbar, ist jeder Schnittstelle
ein lokaler Speicher SP1 (IF_MRC), SP2 (IF_CCWE), SP3 (IF_DCWE),
SP4 (IF_AFC), SP5 (IF_SINR), SP6 (IF_TPC) (und SP7 (IF_TFCI)) zugeordnet.
In den genannten Speichern sind Tabellen der in 3 dargestellten Form bestehend aus den Aktivierungs-Bits
(ENA_MRC, ENA_CCWE, ENA_DCWE, ENA_AFC, ENA_SINR (, ENA_TPC, ENA_TFCI&PILOT)) und den
diesen Aktivierungs-Bits zugeordneten Parametern (PAR_MRC, PAR_CCWE,
PAR_DCWE, PAR_AFC, PAR_SINR, PAR_TPC (, PAR_TFCI&PILOT)) für die Auswahl der "richtigen"
Symbole sowie der Auswahl der gewünschten Berechnungsvorschrift
abgelegt.
-
Die Steuerung der Modul-zugeordneten Schnittstellen
erfolgt über
eine Schaltung IF_CON, die mit einem Parameterspeicher IF_PAR in
Zugriffsverbindung steht. Der Steuerung IF_CON wird die Nummer r
des aktuellen MC-Rake-Finger MC_RF_r mitgeteilt, dessen Ausgabesymbole
gerade auf dem Symbolbus SB vorliegen.
-
Die Steuerung IF_CON steht über Steuerleitungen
SL1, SL2, SL3, SL4, SLS, SL6 mit den Schnittstellen IF_MRC, IF_CCWE,
IF_DCWE, IF_AFC, IF_SINR und IF_TPC in Verbindung.
-
Nach einer ersten Ausgestaltung werden
in dem Parameterspeicher IF_PAR lediglich die Informationen darüber verwaltet,
ob der MC-Rake-Finger MC_RF_r aktiv ist (1. Kriterium der 1. Bedingung).
In diesem Fall wird über
die Steuerleitungen SL1 bis SL6 für alle Schnittstellen der gleiche
Steuerwert ausgegeben, nämlich
z.B. der Wert 1, sofern der aktuelle MC-Rake-Finger MC_RF_r aktiv ist, und der Wert
0, sofern der aktuelle MC-Rake-Finger MC_RF_r nicht aktiv ist. Die
Schnittstellen lesen den ausgegebenen Steuerwert, wobei die Auswahl
der benötigten
Symbole (durch die Überprüfung des
2. Kriteriums der 1. Bedingung und der z. Bedingung) weiterhin dezentral
in jeder einzelnen Schnittstelle vorgenommen wird.
-
Nach einer zweiten Ausgestaltung
wird in dem Parameterspeicher IF_PAR Modul-spezifische Aktivierungs-Information
verwaltet. Hierfür
muss der Parameterspeicher IF_PAR die Tabellen-Einträge ENA_MRC,
ENA_CCWE, ENA_DCWE, ENA_AFC, ENA_SINR, ENA_TPC (, ENA_TFCI&PILOT) enthalten
(das Modul IF_TFCI wird hier von der Steuerung IF_CON über das
Modul MRC1 kontrolliert, deswegen müssen die Tabellen-Einträge ENA_TFCI&PILOT nicht zwingend
in IF_PAR enthalten sein). Die Steuerung IF_CON überprüft anhand der Nummer r des
aktuell aktiven MC-Rake-Fingers
MC_RF_r, ob bzw. für
welche Module MRC, CCWE, DCWE, AFC, SINR, TPC das aktuelle Symbol
zur Verfügung
stehen soll (1. Bedingung). Je nach Ergebnis der Überprüfung werden über die
Steuerleitungen SL1, SL2, ..., SL6 Schnittstellen-spezifische Aktivierungs-Bits ausgegeben,
das heißt
jede einzelne Schnittstelle IF_MRC, IF_CCWE, IF_DCWE, IF_AFC, IF_SINR, IF_TPC
wird entsprechend der Berechnungslogik LOG in 4 nur dann aktiviert, wenn gerade ein
von dem dieser Schnittstelle zugeordneten Hardware-Modul benötigtes Symbol
auf dem Symbolbus SB vorliegt. Bei Erhalt eines Aktivierungs-Bits (entspricht
den von LOG_R1 ausgegebenen Aktivierungs signalen ena in 4) findet die Überprüfung der
z. Bedingung für
jedes einzelne Modul getrennt in der jeweiligen Modul-zugeordneten
Schnittstelle IF_MRC, IF_CCWE; IF_DCWE, IF_AFC, IF_SINR, IF_TPC
statt. Durch die zweistufige Ausgestaltung des Abprüfvorgangs
ist gewährleistet,
dass lediglich die Steuerung IF_CON (entspricht den Vorauswahl-Logikschaltungen
LOG_R1 sämtlicher
Schnittstellen) ständig
aktiv sein muss. Erst wenn die 1. Bedingung erfüllt ist, werden die Hardware-Module MRC,
CCWE, DCWE, AFC, SINR, TPC mit ihren Modul-zugeordneten Schnittstellen
IF_MRC, IF_CCWE, IF_DCWE, IF_AFC, IF_SINR, IF_TPC aktiviert. Es wird
darauf hingewiesen, dass auch in diesem Fall sämtliche von den MC-Rake-Fingern gelieferten Symbole
an sämtlichen
Modul-zugeordneten Schnittstellen IF_MRC, IF_CCWE, IF_DCWE, IF_AFC, IF_SINR,
IF_TPC anliegen.
-
Nach einer dritten Ausgestaltung
werden über
die Steuerleitungen SL1 bis SL6 zusätzlich zu den Schnittstellenspezifischen
Aktivierungs-Bits (der zweiten Ausgestaltung) die Auswahl- und Verarbeitungsparameter
(für IF_SINR:
z1_r, z2_r, z3_r, dr, sr, f1_r, f2_r) übermittelt. Die Überprüfung der
erhaltenen Symbole anhand der übermittelten
Auswahlparameter wird weiterhin lokal in den Schnittstellen vorgenommen
(dies entspricht der Funktionalität der Berechnungslogik LOG
in 4) .
-
6 zeigt
ein weiteres Ausführungsbeispiel der
Erfindung, welches sich von dem in 5 dargestellten
Beispiel im wesentlichen dadurch unterscheidet, dass den einzelnen
Modulzugeordneten Schnittstellen IF_MRC, IF_CCWE, IF_DCWE, IF_AFC, IF_SINR,
IF_TPC über
Modul-spezifische Busse B1, B2, ..., B6 jeweils nur diejenigen Symbole
zugeleitet werden, die von dem jeweiligen Hardware-Modul MRC, CCWE,
DCWE, AFC, SINR, TPC benötigt
werden (das Modul IF_TFCI wird wie bereits erwähnt von Ergebnissen sowie von
Kontrollinformation aus der ersten Stufe der Einheit MRC1 gespeist).
Das sind diejenigen Symbole, für
die die 1. Bedingung erfüllt ist.
Zu diesem Zweck sind in dem Parameterspeicher IF_PAR die Tabellen
für sämtliche
Module gespeichert. Die Steuerung IF_CON stellt dann bezüglich jedes
Hardware-Moduls und jedes einlaufenden Symbols fest, ob dieses Symbol
dem betrachteten Hardware-Modul zugeleitet werden soll. Sofern z.B. ein
Symbol dem Hardware-Modul MRC zugeleitet werden soll, wird die entsprechende
Schnittstelle IF_MRC über
die Steuerleitung SL1 aktiviert und das Symbol wird über den
Bus B1 der Schnittstelle IF_MRC zugeleitet. Darüber hinaus werden der Schnittstelle
IF_MRC zu jedem übertragenen
Symbol über
die Steuerleitung SL1 auch jeweils die zugehörigen Symbol-bezogenen Parameter
(Auswahlparameter und Verarbeitungsparameter) mitgeteilt. In derselben
Weise werden über
die Busse B2, B3, B4, B5 und B6 den Schnittstellen IF_CCWE, IF_DCWE, IF_AFC,
IF_SINR und IF_TPC nur diejenigen Symbole zugeleitet, die von den
zugehörigen
Modulen benötigt
werden. Die Steuerleitungen SL1, ..., SL6 dienen hier also sowohl
zur Aktivierung der jeweiligen Schnittstellen IF_CCWE, IF_DCWE,
IF_AFC, IF_SINR und IF_TPC als auch zur Übertragung des für die Auswahl
(gemäß der 2.
Bedingung) und Verarbeitung des Symbols benötigten Symbol-spezifischen
Parametersatzes (für
IF_SINR: z1_r, z2_r, z3_r, dr, sr, f1_r, f2_r). Der in die Steuerung
IF_CON integrierte kombinierte Schalter und Multiplexer GATE1 übernimmt
die Vorauswahl (1. Bedingung) und Verteilung der einzelnen Symbole
auf die Busse B1, ..., B6.
-
Ferner sind gemäß 6 weitere Datenverbindungen DV1, DV2,
DV3 und DV4 zwischen der Steuerung IF_CON und den Modulzugeordneten Schnittstellen
IF_MRC, IF_AFC, IF_SINR und IF_TPC vorgesehen. Über diese Datenverbindungen DV1,
DV2, DV3, DV4 können
Symbol-unspezifische Parameter an die Module übertragen werden, die ebenfalls
einen bestimmten Berechnungs-Algorithmus für die nachgeschalteten Hardware-Module
festlegen. Es kann sich hierbei z.B. um Skalierungsinformation handeln.
Beim Modul AFC sind es beispielsweise Abstandswerte gemessen in
Vielfachen von CPICH-Symbolen, um die die Faktoren eines Produktes
aus CPICH-Symbolen auseinanderlie gen. In 5 wird unterstellt, dass diese Information
lokal in den Schnittstellen vorhanden ist.
-
Da bei diesem Ausführungsbeispiel
eine zentrale Vorauswahl der Symbole für jedes Modul getroffen wird
und daraufhin die ausgewählten
Symbole mit ihren Symbol-bezogenen Parametersätzen übermittelt werden, wird in
den Parameterspeichern PAR_MRC, PAR_CCWE, PAR_DCWE, PAR_AFC, PAR_SINR,
PAR_TPC (und PAR TFCI) lediglich der aktuell übertragene Parametersatz (z.B.
Modul SINR: Zellen-Nummer, 1D, STTD und SL-FO) zu dem aktuellen
Symbol zwischengespeichert bzw. globale, nicht Fingerspezifische
aber Modul-spezifische Parameter gespeichert.
-
Der Vorteil der in 6 dargestellten Architektur besteht darin,
dass die einzelnen Busse B1, B2, ..., B6 einen deutlich geringeren
Datenverkehr als der Symbolbus SB transportieren müssen und
dass der Stromverbrauch aufgrund der nur bei Bedarf aktivierten
Module MRC, CCWE, DCWE, AFC, SINR und TPC minimiert wird.