AT501645B1 - Kanalsimulations- sowie entwicklungsplattform und verwendung derselben - Google Patents

Description

2 AT 501 645 B1

Die Erfindung betrifft eine Kanalsimulations- sowie Entwicklungsplattform gemäß dem Oberbegriff des Anspruchs 1. Die Erfindung basiert dabei zum Teil auf der österreichischen Patentanmeldung A 904/2003 „Kanalsimulator“, welche in der vorliegenden Erfindung entscheidend verbessert wurde, um einerseits für Multikanal-(MIMO-) Funkübertragungssysteme, andererseits über die Kanalsimulation hinausgehend als komplette Entwicklungsplattform verwendbar zu sein. ΜΙΜΟ bedeutet Multiple Input Multiple Output.

Der durch Kolu, J; Jämsä, T; “A real-time Simulator for ΜΙΜΟ radio Channels.“ In: 5th International Symposium on Wireless Personal Multimedia Communications, 2002. 27.-30. Oktober 2002; Piscataway, NJ, USA, IEEE., Seiten 568-572 vol. 2, beschriebene Kanalsimulator sieht vor, dass er den Ausbreitungsvorgang der Funksendesignale (MIMO-Kanäle) nicht exakt nachstellt, sondern die Simulation bloß durch Filterung der Signale mit FIR-Filter, deren Eigenschaften je nach den gewählten Übertragungsszenarien gewählt wurden, durchführt. Es werden anhand des Kanalmodells, welches die Umgebungsszenarien beschreibt, die Übertragungsfunktionen (Impulsantworten) der Filter vorberechnet, und mit diesen Übertragungsfunktionen wird die Simulation durch den erwähnten Filtervorgang in Echtzeit ausgeführt (jedes FIR-Filter verarbeitete einen MIMO-Kanal). Die Simulation nach diesem Verfahren ist nicht sehr genau und kann nicht vollständig in Echtzeit durchgeführt werden, weit die Umgebungsszenarien nicht während der Simulation (in Echtzeit) geändert werden können, sondern die sich aus den Szenarien ergebenden Übertragungsfunktionen immer vor der eigentlichen Simulation berechnet werden müssen.

Das Kanalmodell dieser Druckschrift verwendet zwar auch geometrische Berechnungen, allerdings wird kein geometrisches Abbild der Umgebung erstellt, sondern lediglich die Richtungen der an der Antennen einfallenden Signale werden als Basis für die Berechnung der Übertragungsfunktionen herangezogen, welche Richtungen nach statistischen Verteilungen ermittelt werden. Auch wenn einige Parameter, z.B. Laufzeiten, Dämpfungswerte, verwendet werden, so fehlt die Berücksichtigung der Umgebungsgeometrie.

Ferner sind bei dem bekannten Verfahren bei dem tapped delay line filtering (FIR-Filter) die Verzögerungszeiten zwischen den einzelnen Filtertaps konstant und somit können die diesen entsprechenden Signallaufzeiten ebenfalls nur vordefinierte, konstante Werte annehmen. Das bedeutet, dass nur zu vorgegebenen Zeitpunkten Signalkomponenten an den Antennen eintref-fen können, was in der Realität nicht der Fall ist.

In der Publikation „Radio Propagation in Urban Cells Environment ..." werden die Ergebnisse einer Messkampagne beschrieben, in der die Ausbreitung in typischen städtischen Umgebungen gemessen wird und daraus eine spatial-temporale (räumlich-zeitliche) Beschreibung des Funkkanals abgeleitet wird. Die Messergebnisse werden anschließend mit den Simulationsergebnissen verglichen, welche durch eine Kanalsimulations-Software erhalten wurden, die ein bekanntes spatial-temporales Kanalmodell verwendet.

Diese Kanalsimulations-Software ist kein Kanalsimulator im Sinne eines Gerätes, sie verwirklicht lediglich eine softwaremäßige Funksimulation auf einem PC, sie verwendet keine spezielle echtzeitfähige Hardware, ist auf jedem leistungsfähigen PC-System ablaufbar und kann die Simulation nicht in Echtzeit durchführen. Sie besitzt keine Konvertierungsmittel zum Aufneh-men/Abgeben von Basisband- bzw. HF-Frontend-Signalen und ist auch nicht als Entwicklungsplattform einsetzbar. Derartige Tools sind weit verbreitet, sie sind aber vor allem wegen der fehlenden Echtzeitfähigkeit keinesfalls mit dem erfindungsgemäßen Kanalsimulator vergleichbar.

In der EP 1 447 927 A1 wird ein Verfahren beschrieben, welches die Simulation der Ausbreitung von Funksignalen vereinfacht. Es wird die mathematische Beschreibung des Kanals in eine einfachere Darstellungsweise transformiert, welche bei der Verwendung zur Kanalsimulation einen geringeren Rechenaufwand erfordert wie bekannte mathematische Beschreibungen 3 AT 501 645 B1 des Funkkanals. Bei diesem Verfahren werden die einzelnen, miteinander korrelierten Funksignale durch ein Set von Zufallsvariablen ersetzt, deren statistische Eigenschaften aus den Korrelationsbeziehungen der Funksignale und der Kanal-Korrelationsmatrix berechnet werden. Diese Zufallsvariablen sind miteinander unkorreliert und erlauben eine einfachere Berechnung des resultierenden Signals im Empfänger. In dieser Patentschrift wird auch ein Verfahren zur Kanalsimulation beschrieben, welches das erwähnte Verfahren zur Beschreibung des Kanals verwendet.

Dieses bekannte Kanalsimulations-Verfahren ist kein Kanalsimulator im Sinne eines Gerätes, es verwirklicht lediglich eine softwaremäßige Funksimulation (z.B. auf einem PC), es setzt keine spezielle echtzeitfähige Hardware voraus, ist auf jedem leistungsfähigen PC-System ablaufbar und kann die Simulation nicht in Echtzeit durchführen. Es verwendet keine Konvertierungsmittel zum Aufnehmen/Abgeben von Basisband- bzw. HF-Frontend-Signalen und ist auch nicht in einer Entwicklungsplattform ersetzbar. In dieser Publikation wird beschrieben, wie das Verfahren zur Simulation eines Funkkanals eingesetzt werden kann, und es ist nicht möglich, es zur Simulation von MIMO-Übertragungen einzusetzen.

Bei MIMO-Funkübertragungssystemen handelt es sich um Systeme, die neben zeitlichem und frequenzmäßigem zusätzlich räumliches Multiplexen verwenden, um die Kanalkapazität zu erhöhen. Es wird das Sendesignal in mehrere Pakete geschachtelt, die alle gesondert mit der gleichen Trägerfrequenz von den einzelnen Antennen eines Arrays ausgesendet werden (Abb. 1). Aufgrund des geringfügig unterschiedlichen Abstrahlortes ergeben sich für die einzelnen Signale unterschiedliche räumliche Ausbreitungsbedingungen. Mithilfe geeigneter Algorithmen können die einzelnen MIMO-Kanäle des Empfangssignals voneinander unterschieden werden und im Empfänger zu einem Signal integriert werden.

Um solche Systeme zu simulieren, benötigt man einen MIMO-tauglichen Echtzeit-Kanalsimulator, der mit den im Kennzeichen des Patentanspruches 1 angeführten Merkmalen charakterisiert ist. Bisher bekannte Ausführungen konnten MIMO-Simulationen nicht in Echtzeit durchführen. In Abbildung 2 erkennt man das Prinzip dieses Echtzeit-Kanalsimulators: Je ein Kanal wird durch die Übertragung von einer Sendeantenne zu einer Empfangsantenne gebildet. Jeder dieser Kanäle wird vorzugsweise durch eine Einheit des Kanalsimulators simuliert.

Der erfindungsgemäße Kanalsimulator stellt den Ausbreitungsvorgang möglichst wirklichkeitstreu nach, indem er ein möglichst realistisches statistisches Modell der tatsächlichen geometrischen Übertragungsszenarien erstellt, und mit diesem Modell mit den die Übertragung bestimmenden und beeinflussenden Objekten die Ausbreitung der Signale simuliert, wie sie in der Realität ablaufen würde. Es wird ein dem ray tracing ähnliches Verfahren angewendet und die Wege der einzelnen Signalkomponenten werden nachverfolgt. Es wird daher der reale Verlauf der einzelnen Signale und deren Komponenten in einer statistisch modellierten Umgebung in Echtzeit bestimmt, die tatsächliche Streuung an Streuobjekten, die tatsächlichen Signalpfade, Laufzeiten etc. Änderungen dieser Umgebung können jederzeit während des Simulationsablaufes vorgenommen werden und sind daher sofort wirksam.

Das erfindungsgemäße Kanalmodell ist ein geometrisch stochastisches Modell (GSCM, geo-metry based stochastical Channel model). Der Kanalsimulator ermittelt mit statistischen Methoden ein geometrisches Abbild der Umgebung und stellt geometrische Berechnungen von Weglängen, Laufzeitdifferenzen, Einfallswinkel etc. an.

Des weiteren wird durch den Aufbau des erfindungsgemäßen Kanalsimulators eine Signalverarbeitung des stochastischen Modells in Echtzeit ermöglicht, da die Berechnungen aufgeteilt und zu dem Ausgangssignal integriert werden.

Eine entscheidende Neuerung des erfindungsgemäßen Kanalsimulators besteht darin, dass er ΜΙΜΟ, ray tracing und Kanalmodelle (GSCM) erstmals für Echtzeit-Simulationen anwendet und 4 AT 501 645 B1 somit ganz neue Einsatzmöglichkeiten und höhere Aussagekraft von Funksimulationen erlaubt. Für Mehrkanal-Simulationen benötigt man ein MIMO-taugliches Kanalmodell. Es wurde daher das Kanalmodell aus der Patentanmeldung A 904/2003 „Kanalsimulator“ in vielen Punkten erweitert. Dazu zählt die Berücksichtigung von Mehrfachreflexionen (Double Scattering), die ein exakteres Nachstellen realer Ausbreitungsphänomene ermöglicht. Insbesondere für Mehrkanal-Übertragungen spielen Mehrfachreflexionen eine bedeutende Rolle, weil sie die realistische Simulation der Kanalkapazität dieser Übertragungen beträchtlich verbessert.

Neben dem Near Cluster der Mobilstation wurde das Kanalmodell um einen Near Cluster im Bereich der Basisstation erweitert. Dieser so genannte „Near Basestation Cluster“ ist vor allem für die Übertragung in Mikro Zellen notwendig.

Der Erfindungsgegenstand eignet sich nicht nur zur Simulation von MIMO-Funkübertragungen, sondern er kann als leistungsfähiges Entwicklungswerkzeug für die Entwicklung sowie für Tests von Software basierenden flexiblen Funkübertragungssystemen (SDR) eingesetzt werden. Dazu umfasst der Erfindungsgegenstand neben dem Kanalsimulationssystem auch über einen Receiver für Software Defined Radio. Durch das Zusammenwirken von Simulations- und Empfangssystem (das auch den Sender umfasst) wird eine Plattform geschaffen, die sich für die Implementierung von unterschiedlichen Software Defined Radio-Strukturen sowie von verschiedenen Algorithmen für jedes Strukturelement und somit auch für das Testen dieser Strukturen eignet.

Im folgenden wird die Erfindung anhand der Abbildungen näher erläutert. Abb. 1 zeigt Ausbreitungswege bei der MIMO-Übertragung. Abb. 2 zeigt das Prinzip der MIMO-Kanalsimulation. Abb. 3 zeigt ein Blockschaltbild eines Software Defined Radio (SDR). Abb. 4 zeigt die Struktur einer Entwicklungsplattform. Abb. 5 zeigt einen Ausbreitungsvorgang mit Berücksichtigung von Double Scattering. Abb. 6 zeigt ein Ablaufdiagramm der LS-Update. Abb. 7 zeigt die Zylinderform eines Clusters. Abb. 8 zeigt die Modulierung der Jakobian-Transformation. Abb. 9 zeigt den Dämpfungsverlauf eines Kantenmodells. Abb. 10 veranschaulicht das Double Scattering. Abb. 11 zeigt die Berechnung des Ricefaktors. Abb. 12 zeigt einen Fading-Verlauf. Abb. 13 zeigt das Ausfäden bei LOS-Visibility. Abb. 14 zeigt die Anordnung der Störer bei CDM-Uplink. Abb. 15 zeigt die Anordnung der Störer bei CDMA-Downlink. Abb. 16 zeigt die Anordnung eines Sinus-Störers. Abb. 17 die Korrektur des Delay. Abb. 18 zeigt die Ermittlung eines kürzesten Pfades. Abb. 19 zeigt die Korrektur eines Delay. Abb. 20 zeigt eine Backplane mit Stecker. Abb. 21 zeigt Anschlüsse eines LVDS-Kanals. Abb. 22 zeigt die Anschlüsse eines Multiplexers. Abb. 23 zeigt die Anschlüsse eines adressierbaren Latch. Abb. 24 zeigt die Anordnung einer Backplane und eines Backplaneerweiterungssystems. Abb. 25 zeigt eine Daisy-Chane. Abb. 26 zeigt eine Datenverteilung mit Schaltmatrix. Abb. 27 zeigt eine Rück-Schnitt- und Vorderansicht eines Racks. Abb. 28 zeigt eine Direktverbindung von zwei Leiterplatten. Abb. 29 zeigt eine Leiterplatte. Abb. 30 zeigt eine Leiterplatte. Abb. 31 zeigt durchgefräste Durchkontaktierungen. Abb. 32 zeigt eine MISO-8-1. Abb. 33 zeigt eine MIMO-8-Version A. Abb. 35 zeigt eine MIMO-8-Version B. Abb. 36 zeigt eine MIMO-3. Abb. 37 zeigt eine MIMO-3. Abb. 38 zeigt eine MIMO-5. Abb. 39 zeigt ein Empfangssystem für MIMO-X2. Abb. 40 zeigt ein Empfangssystem für MIMO-X4. Abb. 41 zeigt ein Empfangsystem für MIMO-X6. Abb. 42 zeigt ein Empfangssystem für MIMO-X8. Abb. 43 zeigt ein Empfangsystem für MIMO-X10. Abb. 44 zeigt eine Golden Coat Matrix. Abb. 45 zeigt eine Schaltung eines Douple-dual-RAM. Abb. 46 zeigt eine Standardvorgangsweise zur Imageerstellung. Abb. 47 zeigt eine Partitionierung eines Flash-Speichers. Abb. 48 zeigt einen verbesserten Prozess zur Imageerstellung. Abb. 49 zeigt den DSP-Board als Quantendetektionssystem. Abb. 50 zeigt ein allgemeines Blockschaltbild einer Anwendung eines erfindungsgemäßen Testsystems. Abb. 51 zeigt einen Kameralink. Abb. 52 zeigt ein RTS-DSP-Board als frame grabber bzw. als Signalsenke. Abb. 53 zeigt ein RSD-DSP-Board als Bildgenerator bzw. Singalquelle.

Ein Blockschaltbild eines SDR-Receivers ist in Abbildung 3 gezeigt. Der linke, nicht markierte 5 AT 501 645 B1

Bereich stellt das HF-Frontend dar, das die digitalen Basisbandsignale in den HF-Bereich mischt bzw. die HF-Signale in den Basisbandbereich. Zu diesem Bereich gehören auch der A/D-Wandler bzw. der D/A Wandler. Der rot markierte Teil übernimmt die Verarbeitung der digitalisierten Daten. Dazu gehören die Demodulation und die Decodierung der Daten. Dieser Teil wird zur Gänze vom RTS- DSP- Board implementiert. Der RF- und der IF-Abschnitt werden durch ein eigenes Analog- I/O- Board realisiert. Zu dessen Aufgaben zählen die IF-Mischung sowie die A/D-Wandlung.

Das Gesamtsystem besteht nun aus einer erweiterbaren Architektur 8 paralleler Simulationsboards, von denen jedes vorzugsweise die Simulation eines Kanals übernimmt, sowie aus ein bis zwei Empfängerboards, die jeweils 4 Antennensignale verarbeiten können. Eigene Analog- I/O-Boards für alle Rechenboards mit separaten Eingängen für Digital-, Analog-, RF- und IF- Signale gestalten die Plattform höchst flexibel und erlauben die Simulation von unterschiedlichsten ΜΙΜΟ- Konfigurationen. LVDS-Leitungen ermöglichen schnellstmögliche Datenübertragung der digitalen Basisbandsignale zwischen den Boards sowie zu den Ein/Ausgängen. In Abbildung 4 ist die Struktur der Entwicklungsplattform schematisch dargestellt, wobei hier zur Vereinfachung nur der Fall der Basisband-Übertragung herangezogen wurde und die Schnittstellen zu anderen Datenformaten nicht gezeigt werden. 2. Kanalmodellimplementierung

Gegenüber der Version des Kanalmodells aus der Patentanmeldung A 904/2003 „Kanalsimulator“ finden sich hier einige Erweiterungen, Veränderungen und Vereinfachungen, um dieses Kanalmodell einerseits in Echtzeit zu implementieren, und auch um eine bessere Modellierung der ΜΙΜΟ (Multiple Input Multiple Output) Kanaleigenschaften zu erreichen. Dazu zählt die Berücksichtigung von Mehrfachreflexionen (Double Scattering), die ein exakteres Nachstellen realer Ausbreitungsphänomene ermöglicht (s. Abbildung 5). Insbesondere bei Mehrkanal-Übertragungen spielen die Mehrfachreflexionen eine bedeutende Rolle, um die Kanalkapazität realistischer simulieren zu können.

Zusätzlich zum Near Cluster der Mobilstation wurde ein Near Cluster der Basisstation berücksichtigt. Dieser so genannte „Near Basestation Cluster“ ist vor allem bei Übertragungen in Mikro Zellen notwendig. Bei Mikro Zellen ist die Basisstation (BS) üblicherweise in Höhe der Dachkante montiert, nicht hoch über den Häuserdächern (wie bei Makro Zellen). Daher bilden die um die Basisstation liegenden Gebäude Scatterer, welche bei der Simulation durch den „Near Basestation Cluster“ beschrieben werden.

Bei dem Kanalsimulator der Patentanmeldung A 904/2003 „Kanalsimulator“ wird die Simulation mithilfe eines einfacheren zweidimensionalen Modells durchgeführt. In der vorliegenden Erfindung wird nun für das Platzieren der Scatterer und Antennen ein dreidimensionales Modell herangezogen. Diese dritte Dimension wird durch die Elevation, das ist der Winkel zwischen der z-Achse und der Ursprungsgeraden durch den gewünschten Punkt, beschrieben.

Die Struktur des Kanalmodells ändert sich auch insofern gegenüber der Patentanmeldung A 904/2003 „Kanalsimulator“, als einige Funktionen vom SS (Small Scale) Update in den LS (Large Scale) Update verschoben werden. Im SS Update werden größtenteils nur mehr lineare oder quadratische Interpolationen der im LS Update berechneten Werte durchgeführt. Dies erspart sehr viel Rechenzeit. Speziell die Weglängenberechnung, die in Patentanmeldung A 904/2003 „Kanalsimulator“ noch für jeden einzelnen Pfad im SS Update durchgeführt wurde, wird jetzt durch eine quadratische Interpolation ersetzt. Die Weglängenberechnung machte den größten Teil der Rechenleistung aus, weil hierfür die Auswertung von Wurzeln mit einer Genauigkeit von 64 Bit erforderlich war.

Wird nun diese Berechnung in den LS Update verschoben, so muss sie nicht mehr zu jedem TS (Timeslot) sondern lediglich zweimal alle 40 TS (LS Update Periode) durchgeführt werden (für 6 AT 501 645 B1 GSM). Dies bedeutet eine Reduzierung der erforderlichen Rechenleistung auf ein Zwanzigstel (ohne Berücksichtigung des zusätzlichen Aufwands, der durch die quadratische Interpolation entsteht). Für UMTS-Übertragungen gilt ähnliches, in diesem Fall kann man vermutlich eine Reduktion auf ein Siebtel erreichen. (Der geringere Wert ergibt sich durch kürzere Updateperioden infolge des bei UMTS-Systemen höheren erlaubten Geschwindigkeitswertes des Mobilteilnehmers.)

Aus diesem Grund sieht die neue Struktur des LS Update wie in Abbildung 6 aus. 2.1. Near Base Station Cluster

Wie schon erwähnt wurde, ist zur Eignung des Kanalmodells für ΜΙΜΟ Kapazitätssimulationen und Mikrozellen Szenarios ein Cluster rund um die Basisstation eingefügt worden. Dieser Cluster soll die Scatterer rund um die Antennen darstellen, die aufgrund der geringeren Basisstationshöhe wirksam werden. Diese Scatterer werden in weiterer Folge Near Basestation Scatterer (NBS) genannt. Die NBS werden ähnlich wie die FS (Far Scatterer) zu Beginn der Simulation ausgestreut und behalten während der ganzen Simulation ihre Position bei. Das bedeutet, dass die Weglängen zwischen den NBS und den Basisstationsantennen, sowie die Weglängen zwischen NBS und FS entweder schon von der GUI vorberechnet werden können oder in der Initialisierungsphase im Simulator ausgerechnet werden. Gleiches gilt auch für die Winkel zwischen den BS - Antennen und diesen Scatterern. 2.2. Elevation der Scatterer

Die Erweiterung des Kanalmodells sieht vor, die Koordinaten jedes Scatterers um eine unabhängige vertikale Komponente zu ergänzen. Diese wird durch den Elevationswinkel ausgedrückt und lässt die Verwendung von dreidimensionalen Antennenmodellen zu. Die Elevation ist darüber hinaus für ΜΙΜΟ Kapazitätssimulationen von Bedeutung.

Die Scatterer werden nun in einem Zylinder ausgestreut, nicht in einem Kreis, wie in der Patentanmeldung A 904/2003 „Kanalsimulator" (s. Abbildung 7). Die Höhe der Zylinder kann vom Benutzer über die GUI eingestellt werden oder bei der Initialisierung der Simulation ermittelt werden. Dazu wird der Zufallsprozess für den „Angular - Spread“ herangezogen und über Mittelwert und Standardabweichung die Höhe bestimmt. 2.3. Polarisation

Gegenüber der Patentanmeldung A 904/2003 „Kanalsimulator werden bei der vorliegenden Erfindung die Polarisationswerte der Signale für die Simulation berücksichtigt, wobei hierfür zwei Varianten vorgesehen sind. In der ersten Variante werden zufällige, aber konstante Polarisationswerte für alle Scatterer während der Initialisierung ermittelt, in der zweiten Variante werden bei jeder Generierung bzw. Platzierung eines Scatterers die Polarisationsparameter aktualisiert. Die Polarisationswerte werden den jeweiligen Scatterern (wie z.B. die Area - Werte, das sind die „Reflexionsfaktoren“ der Scatterer, die das Verhältnis aus reflektierter Welle zu einfallender Welle wiedergeben) zugeordnet. Diese zweite Variante hat jedoch den Nachteil, dass der Programmcode zu unterschiedlichen Laufzeiten führen kann, weil im LS Update nicht alle Polarisationsfaktoren neu ermittelt werden, sondern nur die der hinzugekommenen Scatterer.

Die folgende Berechnung der Polarisationsfaktoren gilt für alle Scatterer. Jedoch bleiben die Polarisationsfaktoren der Far Scatterer und der Near Basestation Scatterer konstant und somit müssen nur jene der Near Mobilestation Scatterer aktualisiert werden.

Die Dämpfungsfaktoren, wie Shadowfading, Scatterer Area..., beschreiben die Dämpfung bei Ausbreitungsvorgängen, die auf die Polarisationsebene W (Vertikal - Vertikal) beschränkt sind. 7 AT 501 645 B1

Um nun den Einfluss der Polarisation zu berücksichtigen, werden zusätzliche Faktoren für die anderen Polarisationsebenen im LS Update ermittelt, welche die Änderung der Polarisationsrichtungen durch die Streuung an den Scatterern wiedergeben. Diese zusätzlichen Faktoren berechnen sich nach den folgenden Gleichungen: XPD_VH = (XPD_VH_mean + XPD_ VH_spread*randn())*^2'n‘rand{) XPD_HV = (XPD_HV_mean + XPD_HV_spread*randn())*j'2‘TT‘rand0 POL_HH = (POL_HH_mean + POL_HH_spread*randn())*e>'2'n‘rand0 randn() ... Zufallsfunktion für normalverteilte Zufallsfolgen rand() ... Zufallsfunktion für gleichverteilte Zufallsfolgen XPD_VH ... Kreuzpolarisationsfaktor für die Polarisationsebene Vertikal - Horizontal XPD_HV... Kreuzpolarisationsfaktor für die Polarisationsebene Horizontal - Vertikal POL_HH ... Polarisationsfaktor für die Polarisationsebene Horizontal - Horizontal Für die Implementierung wurde folgende Vereinfachung gewählt. Die Polarisationsfaktoren werden im LS Update zusammen mit den Antennengewinnen zu einem Faktor kombiniert. Dies gilt für alle Pfade, mit Ausnahme jener, welche über Near Mobilestation Scatterer verlaufen. Diese Vereinfachung resultiert aus der Tatsache, dass die Antennenrichtung sich durch die Bewegung der MS innerhalb eines LS Updates nicht stark ändert und somit die Antennengewinne nahezu konstant bleiben. Für Pfade über Near Mobilestation Scatterern kann diese Vereinfachung nicht gewählt werden, weil die Antennengewinne wegen der geringen Distanz zwischen Antennen und Scatterern nicht konstant sind und im SS Update berechnet werden.

Im SS Update werden für die W-Polarisation die Dämpfungswerte ohne Berücksichtigung der Antennenfaktoren berechnet (siehe dazu auch Abschnitt 2.4). Diese Dämpfungswerte werden anschließend mit den Polarisationsfaktoren und den polarisierten Antennengewinnen zu den resultierenden Dämpfungsfaktoren kombiniert, die an den FPGA (Field Programmable Gate Ar-ray) weitergeleitet werden. Diese Kombination erfolgt entweder zur Gänze im LS-Update, wie eben ausgeführt, oder zum Teil im SS Update (für Pfade über Near Mobilestation Scatterer). 2.4. Berechnung der Antennengewinne

Wie schon zuvor angedeutet wurde, soll die Berechnung des Antennengewinns weitestgehend im LS Update durchgeführt werden. Dies kann jedoch nicht für die NMS (Near Mobile Station Scatterer) durchgeführt werden. Um eine entsprechende Genauigkeit zu erhalten, werden die Antennengewinne für die NMS im SS Update aus Tabellen ermittelt, wobei die Winkelberechnungen zum Teil linear oder quadratisch interpoliert werden. Dies verringert die erforderliche Rechenleistung gegenüber der rechenintensiven Arcustangens - Berechnung. Da die Basisstation fix ist, bleiben die Antennengewinne der Basisstationsantennen konstant, bis Scatterer durch neue ersetzt werden. Wegen der Berücksichtigung der Scattererpolarisation spielt die Polarisation der Antennen für die Berechnung der Antennengewinne eine bedeutende Rolle.

Es soll hier erwähnt werden, dass sich die Antennen Arrays nur um die Z Achse drehen können, jedoch nicht um die X und Y Achsen. Die Verdrehung des Arrays um die X und Y Achsen würde die Berechnung der Antennengewinne wesentlich komplexer machen, da sich damit auch die Polarisationsebenen der Antennen ändern würden.

Da das Kanalmodell auch die Elevation beinhaltest, müssen 3D-Antennenpattern zur Berechnung der Antennengewinne verwendet werden. 2.5. Scatterer Area Berechnung

Im Kanalmodell der Patentanmeldung A 904/2003 „Kanalsimulator" wurden im LS update die 8 AT 501 645 B1

Area-Dämpfungswerte berechnet und sofort mit den Area-Korrekturwerten kombiniert, damit nicht zu viele Multiplikationen im SS Update durchgeführt werden müssen. Dies ist jedoch im Fall des Double Scattering nicht mehr machbar, da die Werte getrennt notwendig sind. Siehe dazu auch Abschnitt 2.8, welcher das Double Scattering Prinzip näher erläutert.

Near Scatterer Area Berechnung

Die Near Scatterer Area Berechnung erfolgte im Kanalmodell der Patentanmeldung A 904/2003 „Kanalsimulator nach COST259. Die Scatterer wurden im Near Scatterer Cluster gleich verteilt, und wurden über die Jacobian Transformation gewichtet, um das von COST259 vorgegebene Power Delay Profile und Angular Power Spectrum zu erhalten.

Da für die Jacobian Transformation alle Scatterer auf ein Koordinatensystem mit x-Achse in Richtung LOS transformiert werden müssen, und darüber hinaus auch einige Wurzeln ausgewertet werden müssen, wird die Berechnung leider sehr aufwändig.

Einen Lösungsansatz für eine Vereinfachung der Jacobian Transformation stellt die Verringerung der Genauigkeit der Längenauflösung dar. In der oben angeführten Patentanmeldung werden Längen mit 32 Bit aufgelöst. Da jedoch das LS Update Intervall bei maximaler Geschwindigkeit 10λ beträgt, kann davon ausgegangen werden, dass keine volle Längenauflösung von hl1024 erforderlich ist. Falls sich die Mobilstation weniger als 10λ bewegt, kann ähnlich wie bei der Berechnung des Ricefaktor (siehe Abschnitt 2.9) eine lineare Interpolation der Area Werte durchgeführt werden. Dies soll eine Vereinfachung der Wurzelberechnungen ermöglichen, weil dazu eine geringere Auflösung als 64 Bit ausreicht.

Sobald Double Scattering (siehe Abschnitt 2.8) berücksichtigt wird, führt die Verwendung der Jacobian Transformation nicht auf die in COST 259 beschriebenen Power Delay Profiles und Angular Power Spektren, da die zusätzlichen Signale über die Double Scattering Pfade die Leistungsverteilung beeinflussen. Die Berücksichtigung dieses Einflusses erfordert höchst komplexe mathematische Methoden, die in einem Echtzeitsystem nicht implementiert werden können.

Aus diesem Grund gehen wir derzeit von der Forderung ab, vorgegebenen Power Delay Profiles und Angular Power Spektren zu erreichen, und verwenden weitere Vereinfachungen für die Jacobian Transformation.

Eine Alternative zur genauen Berechnung ist die Unterteilung des jeweiligen Scatterer-Clusters in Kreisringe, wobei alle Scatterer innerhalb eines Ringes gleiche Area Werte aufweisen (s. Abbildung 8). Alternativ dazu könnten die Werte innerhalb eines Kreisrings linear interpoliert werden. Eine weitere Alternative ist eine lineare oder quadratische Interpolation vom äußerstem zum innersten Kreisring.

Die Ermittlung der Area Werte eines Kreisrings erfolgt über die Jacobian Transformation. Es werden einige wenige Scatterer (so viele wie gewünschte Kreisringe) über den Radius verteilt und an diesen Positionen die Area Wertberechnung durchgeführt. Durch die Wahl von fiktiven Scatterern müssen die Scatterer nicht zwischen den Koordinatensystemen transferiert werden. Es müssen so je nach gewählter Anzahl von Ringen wesentlich weniger Scatterer als im gesamten Cluster berücksichtigt werden. Eine etwaige zusätzliche Aufteilung der Kreisringe in Sektoren könnte auch noch durchgeführt werden. Dies könnte eine bessere Annäherung an die Jacobian Transformation ermöglichen.

Far Scatterer Area Berechnung

In der Patentanmeldung A 904/2003 „Kanalsimulator" erfolgte die Berechnung der Far Scatterer Area über eine exponentielle Funktion in Abhängigkeit von der Distanz der Far Scatterer zum 9 AT 501 645 B1

Far Cluster Zentrum. In dieser neuen Version des Kanalmodells wird die Berechnung der FS-Area wiederum über die im Abschnitt Near Scatterer Area Berechnung beschriebenen Jacobian Transformation durchgeführt.

Die vorgeschlagenen Vereinfachungen für die Near Scatterer Area Berechnungen gelten auch bei den Far Scatterer Area Berechnungen. 2.6. Ein- und Ausfaden von Scatterern

Bei der Kanalsimulation laut Patentanmeldung A 904/2003 „Kanalsimulator“ wurden Scatterer, die nach einem LS Update aus dem Near Cluster rausfallen, sofort durch neue ersetzt. Dadurch kommt es zu Sprüngen in den Dämpfungswerten. Sind sehr viele Scatterer durch das Pulsieren (Delay Spread und Angular Spread) des Near Cluster ersetzt worden, so kann es im Dämpfungsverlauf zu sehr starken Verlaufsänderungen kommen. Diese stellen grundsätzlich bei Empfängersystemen ohne Gedächtnis über mehrere Timeslots kein Problem dar, weil immer nur das Signal eines Slots betrachtet wird. Allerdings entspricht der Signalverlauf nicht realen Verläufen und soll nun verbessert werden. Die Abbildung 9 zeigt den zeitlichen Verlauf der Dämpfung. Man erkennt, dass der Funktionsverlauf bei der Zeit von ca. 0.14075[s] bis 0.1414[s] (also Dauer eines GSM Timeslots) einen ganz anderen Verlauf als ursprünglich annimmt.

Aus diesem Grund sollte der Wechsel von einem Scatterer zu einem neuen nicht sprunghaft erfolgen, sondern in Form eines kontinuierlichen Ausfaden (Scatterer fällt aus dem Cluster) und Einfaden (neuer Scatterer kommt in den Cluster) erfolgen.

Dazu soll die Tatsache ausgenützt werden, dass nicht immer alle Far Cluster sichtbar sind. Bei der Kanalsimulation nach Patentanmeldung A 904/2003 „Kanalsimulator" wurden immer die Channel Engine-Pfade für die Far Scatterer reserviert, obwohl sie nicht ständig genützt wurden.

Darüber hinaus besitzen nur bestimmte Szenarien tatsächlich 3 Far Cluster, womit bei dem Kanalsimulator nach Patentanmeldung A 904/2003 „Kanalsimulator“ viel Rechenleistung nicht verwendet wurde. Diese nicht benützten Pfade (Rechenleistung) können nun (bei geringer Pfadzahl) zum parallelen Ein- und Ausfaden von Near Scatterern verwendet werden.

Sobald jedoch Double Scattering aktiviert ist, erhöht sich die Anzahl der Pfade im System und ein paralleles Ein- und Ausfaden kann nicht mehr realisiert werden. Aus diesem Grund sollen die Pfade sequentiell aus- und danach einfaden. Die Scatterer faden während eines SS Updates langsam aus und im nächsten SS Update langsam ein. Dadurch bleibt die Anzahl der Near Scatterer (Pfade) im FPGA immer konstant, was auch die Verarbeitung im FPGA gegenüber parallelem Faden vereinfacht. 2.7. Area Werte interpolieren

Wie schon im Abschnitt 2.5 angedeutet wurde, wird eine lineare Interpolation der Area Werte vorgenommen. Zusätzlich werden auch die FS- Area und die LOS- Area Korrektunwerte linear interpoliert. 2.8. Double Scattering

Zur Verbesserung des Kanalmodells nach COST259 wird bei der Simulation nach dem vorliegenden Anmeldungsgegenstand Double Scattering berücksichtigt. Signale werden nicht nur an einem Scatterer reflektiert, sondern z.T. auch an einem zweiten Scatterer (s. Abbildung 10).

Daher treten zusätzlich zu diesem Single Scattering- auch noch Double Scattering-Pfade auf. Diese sind vor allem für ΜΙΜΟ Algorithmen von Bedeutung, da noch mehr Informationen aus den Delays und der Richtung der Signale gewonnen werden können. 10 AT 501 645 B1

Die Abbildung 10 zeigt einen Single Scattering Pfad in rot, der durch eine bestimmte Einfallsrichtung und einem über die Länge definierten Delay gekennzeichnet ist. Weiters sind auch noch einige Double Scattering Pfade in blau dargestellt. Da alle DS Pfade über denselben zweiten Scatterer wie der Single Pfad eintreffen, aber unterschiedliche erste „Double Scatterer“ haben, kommen sie alle aus einer Richtung, haben jedoch unterschiedliche Delays und Dämpfungswerte.

Das Double Scattering wird grundsätzlich mit denselben Scatterern wie das Single Scattering durchgeführt. Es werden allerdings zum Beispiel nur die ersten 5 Scatterer (NMDSnr=5; NMDSnr... Near Mobile Double Scatterer Number) eines Near MS Clusters und die ersten 3 Scatterer (NBDSnr=3; NBDSnr... Near BS Double Scatterer Number) des Near BS Clusters für das Double Scattering verwendet, obwohl jeder der beiden Cluster zum Beispiel 10 Scatterer haben könnte. Dies soll eine „Explosion“ der Pfadanzahl aufgrund von Double Scattering verhindern. Wie die Single Scattering Pfade faden die DS Pfade zuerst langsam aus und anschließend langsam ein.

Berechnung der Dämpfungswerte für DS zwischen Near Mobile Scatterern

Die Berechnung der Dämpfung für die Single Scattering Pfade setzt sich nach folgender Formel zusammen. Zur einfacheren Darstellung wurden hier die Antennengewinne und die Polarisation nicht berücksichtigt.

att_NMS_ss{NMSnr) = NMS_area(NMSnr)*NMS_area_correcture*NMC_SF NMS_area(NMSnr) ...NMS- Area- Wert (Gewichtung der Scatterer) NS_area_correcture ...Korrekturfaktor aus Monte-Carlo-Simulation

Die Berechnung der Double Scattering Pfade errechnet sich wie folgt: att_NMS_ds{DSnr) = NMS_DS_weight*

NMS_area{DS'\nr)*NMS_area(DS2nr)*NMS_area_correcture*NMC_SF

Die Variable NMS_DS_weight soll eine Gewichtung des DS über NMS gegenüber dem Single Scattering ermöglichen. Diese Variable wird von der GUI (Graphical User Interface) initialisiert und bleibt für eine Realisierung konstant. Wird die Variable modifiziert, muss eine neue MC Simulation durchgeführt werden. Da beide Double Scatterer-Pfade die gleichen Korrekturwerte haben, kann die Wurzelberechnung über NS_area_correcture und NC_SF entfallen. Wie im folgenden Beispiel zu sehen ist, muss sie bei den Far Scatterern durchgeführt werden.

Berechnung der Dämpfungswerte für DS zwischen Near Mobile Scatterern und Far Scatterern

Die Berechnung der Dämpfung für die Double Scattering Pfade wird nach der folgenden Formel durchgeführt. att_NMS_FS_ds(DSnr) = NMS_FS_DS_weight* NMS_area(NMSnr)* VNMS_area_correcture*NMC_SF *

FS_area(FSnr)*MS_FC_visibility* FS_area_correcture *FC_SF

Die beiden Wurzeln werden bei der Berechnung im DSP zu einer zusammengefasst, um Rechenleistung zu sparen. Weiters muss die Wurzel nur einmal für alle DS Pfade zwischen NMS und FS berechnet werden, da sie nicht von den verwendeten Scatterern abhängt.

Berechnung der Dämpfungswerte für DS zwischen Near BS Scatterern 1 1 AT 501 645 B1

Die Berechnung der Single Scattering Pfade für die Near Base Station Scatterer wird nach der folgenden Formel durchgeführt. Dabei tritt ein zusätzlicher Gewichtungsfaktor im Vergleich zu der Berechnung für die Near MS Scatterer auf. \ ,.,οο NBS area correcture Λ

att NBS ss(NBSnr) = NBS area(NBSnr)* ——=——=-—— * NBC SF ~ ~ NBS _ NMS _ weight

Die Berechnung des Quotienten aus NS-Area-Korrekturwert durch den Gewichtungsfaktor wird bereits im LS-Update durchgeführt. Weiters wird die Division auf eine Multiplikation mit dem reziproken Wert von NBS_NMS_weight vereinfacht. att_NBS_ds(DSnr) - NBS_DS_weight* Λ/ßS area correcture

NBS area(DS1nr)*NßS_area(DS2nr)* wss_NM~S_«e&t * NBC-SF Ähnlich wie bei der Berechnung des DS zwischen den Near Mobile Scatterern kann auch hier die Wurzelberechnung wegfallen.

Berechnung der Dämpfungswerte für DS zwischen Near BS Scatterern und Near Mobile Scatterern

Die Berechnung erfolgt nach demselben Schema wie in den anderen Double Scattering Fällen. att_NBS_NMS_ds(DSnr) = NBS_NMS_DS_weight* NBS_area(DS'\ nr) *NMS_area{DS2nr) *

yjNBS_area_correcture*NBC_SF * y]NMS_area_correcture*NMC_SF

Berechnung der Dämpfungswerte für DS zwischen Near BS Scatterern und Far Scatterern

Die Berechnung der DS Pfade zwischen Near BS Scatterern und Far Scatterern erfolgt äquivalent zur Berechnung der Near MS Scatterer und Far Scatterer. Es gelten auch hier dieselben Vereinfachungsansätze. att_NBS_FS_ds{DSnr) = NBS_FS_DS_weight* NBS_area{NMSnr) * NBS area correcture _____ _

—...... — _—_* A/Dp OC NBS _ NMS _ weight ~ FS_area(FSnr)*MS_FC_visibility*y]FS_area_correcture*FC_SF 2.9. Rice Faktor Berechnung

Die Ricefaktor Berechnung erfolgt wie im Kanalmodell der Patentanmeldung A 904/2003 „Kanalsimulator“ nach den Vorgaben von COST259. Nur wird gegenüber COST259 nicht mit jedem SS Update ein neuer Ricefaktor ermittelt. Die ursprüngliche Implementierung führte bei sehr kleinen Geschwindigkeiten (bzw. Stillstand der Mobilstation) zu einer starken Änderung der LOS-Komponente. Dies wird nun verhindert, indem der Ricefaktor nur nach Wegänderungen von mindestens λ/2 (dieser Wert könnte möglicherweise auf die Korrelationslänge des Shadow-fading vergrößert werden (5-12m)) neu berechnet und dazwischen linear interpoliert wird.

Wenn sich die MS mit der maximalen Geschwindigkeit bewegt, wird mit jedem SS-Update ein neuer Ricefaktor berechnet. Bewegt sich die MS langsamer, so wird mit einer Häufigkeit, die sich nach dem Verhältnis von derzeitiger Geschwindigkeit zu maximaler Geschwindigkeit richtet, linear interpoliert. Dadurch wird erreicht, dass sich die LOS-Komponente bei Stillstand der MS nicht mehr ändert. 12 AT 501 645 B1

Die Berechnung erfolgt nach dem in Abbildung 11 gezeigten Ablaufdiagramm: 2.10. Shadowfading Berechnung

Zur Berechnung des Shadowfadings wird nach der Patentanmeldung A 904/2003 „Kanalsimulator" zwischen Tabellenwerten mit einer Schrittweite von 1m linear interpoliert (im SS Update). In dem vorliegenden Anmeldungsgegenstand werden als Alternative die Tabellenwerte im LS-Update errechnet und ein Interpolationsschritt für das Shadowfading durch Aufsummieren durchgeführt.

Der LS-Update wird bei maximaler Geschwindigkeit alle 10λ durchgeführt. Daher wird die Tabellenschrittweite auch auf 10λ erhöht. Da nun alle Weglängen in Vielfachen von Lambda (λ/1024) ausgedrückt werden, wird der Tabellenzugriff erleichtert. Der Update sollte bei maximaler Geschwindigkeit 10λ erreichen. Für diese Umstellung ist es jedoch notwendig, die Berechnung der Tabellen für diese Schrittweite umzustellen. Bei einer Frequenzänderung auf z.B 900 MHz ergibt sich eine sehr große Tabellenschrittweite. Um dies zu verhindern, könnte das Updateintervall von 10 auf 5 Lambda verändert werden. 2.11. Far Cluster Visibility Factor Berechnung

Wie in COST259 beschrieben ist, werden die Far Cluster Visibility Regions kreisförmig ausgeführt. Für die Berechnung, ob sich die MS in einer Visibility Region befindet, werden folgende Vereinfachungen durchgeführt: Für die Distanzberechnungen zwischen MS und Visibility Region Zentrum werden nicht die tatsächlichen Distanzen ausgerechnet, sondern quadratische Distanzen, wodurch Wurzelberechnungen eingespart werden. Einen weiteren Schritt zur Reduktion des Rechenaufwands stellt das Vorselektieren der möglichen Visibility Regions dar. Dabei werden anstelle der Kreise umschreibende Quadrate verwendet. Befindet sich die MS nun in einem dieser Quadrate, so werden nur für diese Quadrate die quadratischen Distanzen zwischen MS und Visibility Region Zentrum ermittelt. COST259 schlägt ein langsames Ein und Ausfaden des Clusters nach einer Kosinus - Funktion vor (Abbildung 12). In dem vorliegenden Anmeldungsgegenstand erstreckt sich der Bereich des kosinusförmigen Verlaufs vom 0,9 bis 1,1 fachen des Radius der Far Cluster Visibility Region. Innerhalb dieses Bereichs wird die Kosinus-Funktion aus einer Tabelle gelesen. Ist die Distanz größer, so wird die Visibility gleich null gesetzt, wodurch die Komponenten des FC gleich 0 werden. Ist die Distanz geringer als der 0.9 fache Radius, so wird die Visibility gleich 1 gesetzt.

Damit ergibt sich ein Bereich für die Kosinus Funktion von 20m bei einem Radius der FC Visibility Region von 100 m. Da die Update - Intervalle so ausgelegt sind, dass sich die MS bei maximaler Geschwindigkeit (500km/h) ca. 10λ weiterbewegt, ergeben sich bei maximaler Geschwindigkeit und einem λ von ca. 15cm (für UMTS) ca. 20m/1,5m=13,33 Werte für die Adressierung.

Das bedeutet im schlechtesten Fall hätte man bei dieser Konstellation 13 Werte aus dem LS-Update. Es wird daher im SS-Update noch linear interpoliert, um Unstetigkeiten bei LS-Updates zu vermeiden bzw. zu verringern. 2.12. LOS Visibility Faktor Berechnung

Die Berechnung des LOS Visibility Faktors erfolgt ähnlich wie in Abschnitt 2.11. Leider sind die LOS Visibility Areas wesentlich kleiner und weisen einen typischen Radius von lediglich 30m auf. Dadurch ergibt sich ein Bereich von nur 6m (1,1*30 - 0.9*30=6m) für die Kosinus Funktion 13 AT 501 645 B1 und damit nur mehr 4 LS Updates über die interpoliert werden muss. Falls keine Interpolation durchgeführt werden würde, könnte ein Sprung im Verlauf der Kosinus-Funktion von 0,4 von einem LS Update zum nächsten LS Update auftreten.

Wie die Abbildung 13 zeigt, ist die Änderung speziell an den Randstellen durch die lineare Interpolation etwas ungenau. Daher wird als zweite Option anstatt der linearen Interpolation eine quadratische Interpolation im SS Update vorgeschlagen. 2.13. Störsignale

Störsignale stellen je nach zu simulierenden System unterschiedliche Anforderungen dar. Für CDMA (Code Division Multiple Access) Uplink-Übertragung wirkt sich eine Anzahl von Mobilstationen, die auf derselben Frequenz arbeiten und unterschiedliche Spreading und Scrambling Codes verwenden, als Störung aus, wenn diese Anzahl in den Bereich der Zellauslastung ansteigt. Im Downlink-Fall stellen die Basisstationen in benachbarten Zellen die Störsignale dar.

Bei GSM oder einem ähnlichen System verwenden alle Mobilstationen unterschiedliche Time Slots (TDMA, Time Division Multiple Access). In diesem Fall nimmt man einfacherweise ein sinusförmiges Störsignal und eine fixe Position des Störers an.

Störsignale für CDMA Systeme im Uplink

Die folgenden Ausführungen beziehen sich auf ein UMTS-System, sind aber nicht auf dieses beschränkt. UMTS verwendet in Uplinkrichtung eine Powercontrol für jeden mobilen Teilnehmer, sodass von jedem Mobileterminal dieselbe Empfangsleistung an der Basisstation ankommt. In dem vorliegenden Anmeldungsgegenstand werden daher verschiedene Mobilstationen als Störer angenommen und diese mithilfe der Powercontrol auf einen gemeinsamen Pegel normiert. Die Signale dieser Mobilstationen können summiert und als ein Störsignal abgespeichert werden. Die „Stör“-Mobilstationen bewegen sich dabei auf kreisähnlichen oder elliptischen Bahnen, um Dopplereffekte der Störer simulieren zu können (Abbildung 14). Ein Limit stellt dabei nicht die Anzahl der Störer dar, sondern die Größe der Bahn und die Geschwindigkeit der Bewegung. Denn die Samples der gesamten Bewegungsbahn müssen im Speicher der DSP-Platine Platz finden.

Die Anzahl der Störer wird anhand der gewählten Spreadingcodes und somit der Auslastung der Zelle bzw. des Sektors der Zelle gewählt.

Eine Schwierigkeit, die sich mit einer besonderen Eigenschaft des Simulators ergibt ist die, dass für diverse Receivertests Synchronisierhilfen zur Verfügung gestellt werden. Diese sind so ausgelegt, dass die Zeitliche Verzögerung der Line of Sight Komponente abgezogen wurde. Bei Systemen mit „Timing Advance“ wie zB. UMTS im TDD Mode oder auch GSM, kann das System den Mobilstationen mitteilen, um wie viele Symbole sie ihre „innere Uhr verstellen sollen und früher mit dem Sendevorgang beginnen sollen, damit sie nicht die Timings ihrer Timeslots verletzen. Möchte man quasi ein System simulieren, bei dem alle MS also die zu untersuchende und die Stör MS eine Timing Advance aufweisen, so muss von jeder MS ihre jeweilige zeitliche Verzögerung der LOS Komponente (kürzester Pfad zwischen den Antennenarrays von der Basisstation und der Mobilstation) abgezogen werden. (Jede MS sollte synchron an der BS ankommen.)

Wird keine Synchronisierhilfe verwendet, so sind bei allen MS auch alle LOS Verzögerungen mit eingerechnet.

Störsignal für CDMA Systeme im Downlink

Bei Downlink-Übertragung werden einer Zelle weitere Basisstationen zugeordnet (Abbildung 14 AT 501 645 B1 15). Jede dieser „Stör“ Basisstationen erhält über ihre Zelle den mittleren Dämpfungsverlauf nach Cost Hata oder Walfish - Ikegami, ähnlich wie dies auch für die Mobilstation in ihrer „Heimat“ Zelle gilt. Jedoch werden für die „Stör“ Basisstationen in der ersten Version keine Streuer angenommen. Das Signal kommt nur aus Richtung der Basisstation, wobei die Signalstärke aus dem Dämpfungsverlauf von Cost Hata und Walfish - Ikegami ermittelt wird. Gefaltet wird dieser Dämpfungswert mit zuvor abgespeicherten modulierten Werten.

Die Basisstationen müssen im System nicht synchronisiert sein1). Das bedeutet für die Synchronisierhilfe des Simulators, dass auch die abgezogene LOS keinen Einfluss hat. Es muss also nicht darauf geachtet werden, ob die LOS Komponente zwischen BS und MS abgezogen wurde und die „Stör" BS diese berücksichtigt oder nicht.

Sinus Störsignal

Wie schon zuvor kurz angedeutet, wird in diesem Fall der Störer (Abb. 16) irgendwo im Koordinatensystem der Zelle platziert werden (natürlich auch außerhalb der Zelle selbst). Die Signalstärke des Störers wird über die Cost Hata und Walfish - Ikegami Pathloss Modelle sowie über den Sendepegel des Störers ermittelt. Für die Einstellungen des Pathloss Modells des Störers gelten dieselben Bedingungen wie für die Basisstation. Die Phase des Dämpfungssignals wird über die Distanzen der Störer zur MS Antenne ermittelt.

Das Störsignal wird im Basisband übereinen Betrag und eine Phase definiert. Die Phasenänderung je Samplewert wird auch noch mit übergeben und repräsentiert die Frequenz des Basisbandsignals. Es ergibt sich damit im Basisband ein Sinusstörsignal.

Die Berechnung erfolgt innerhalb des FPGA und kann Parallel zum Rechenwerk der Kanalmodell - Pfade durchgeführt werden. Es wird daher kein zusätzliches Board wie in den zuvor erwähnten Kapiteln über die Störer für CDMA Signale benötigt. 2.14. Synchronisierhilfen für Receiver

Bei der Verwendung des Systems als Entwicklungsplattform müssen bei der Simulation die Laufzeiten (Delays) aller Signalkomponenten berücksichtigt werden, damit der Empfänger eine Korrelation zwischen Sende- u. Empfangssignalen hersteilen kann. Dadurch ist keine Synchronisation im Empfänger notwendig, die dort sehr aufwändig zu realisieren wäre. Dies erfolgt im einfachsten Fall dadurch, dass die Laufzeit der LOS- Komponente als Maß herangezogen wird und das Empfangssignal um diese Laufzeit verschoben wird. Für eine genauere Berechnung wird anstelle der LOS die Laufzeit des kürzesten Pfades, der zwischen den Antennen auftritt, herangezogen.

In der folgenden Abbildung 17 ist veranschaulicht, wie das Delay des kürzesten Pfades zwischen den Antennen subtrahiert wird.

Bei dem Kanalsimulator nach Patentanmeldung A 904/2003 „Kanalsimulator wurde von jedem einzelnen Rechenboard das Empfangssignal jeweils nur einer Antenne zu Antenne Verbindung verarbeitet. Die Ermittlung des kürzesten Pfades stellt bei dieser Aufteilung der Rechenleistung auf die einzelnen Platinen ein Problem dar. Da die Boards untereinander nicht kommunizieren können, kann nicht ermittelt werden, welcher der TX zu RX- Pfade bei der aktuellen Position der MS der kürzeste ist.

Folgende Methoden sind zur Lösung dieses Problems geeignet. 1 s. „WCDMA for UMTS“, S 33 15 AT 501 645 B1 • Jede Platine erhält die Positionen aller Antennen, berechnet jedoch nur die LOS- Verbindungen für alle TX zu RX- Pfade (Abbildung 18). Die indirekten Verbindungen über Scatterer werden nur für den in dem jeweiligen DSP Board aktiven TX zu RX- Pfad gerechnet. • Jede Platine erhält die maximale Distanz von den einzelnen TX Antennen zum TX Zentrum sowie von den RX Antennen zum RX Zentrum. Im DSP wird dann die Distanz zwischen TX und RX Zentrum berechnet und danach werden die maximalen Distanzen abgezogen. Daraus ergibt sich dann das kürzest mögliche Delay. Dies hat jedoch den Nachteil, dass dieses berechnete Delay nicht immer dem tatsächlichen kürzesten Pfad entspricht und daher unter Umständen keine perfekte Synchronität erreicht werden kann.

Wie zuvor bei den CDMA Störern im Uplink Fall angedeutet wurde, kann das kürzeste Delay auch von jeder „Stör“- MS abgezogen und die Summe dieser Störer dann im RAM abgespeichert werden. Damit würden die Signale aller MS synchron an der BS eintreffen. Dies würde einem System mit Timing Advance entsprechen und ist in der unter Abbildung 19c) dargestellt.

Zusätzlich kann jedoch beim Erzeugen der abgespeicherten Daten auch das Delay aller Pfade erhalten bleiben und die „Stör“- Signale können einfach aufaddiert werden. Damit ergibt sich in weiterer Folge der Fall wie in Abbildung 19 unter a) dargestellt. Wird jedoch auch das im RAM abgelegte Signal um das Delay der Mobilstation verschoben, so ergibt sich der dargestellte Fall in der Abbildung 19 b). Für den Downlink- Fall sind diese Synchronisierungen der Störer bei UMTS nicht notwendig, da ja auch die einzelnen Basisstationen nicht synchron arbeiten. Die Synchronisierungshilfe der betrachteten Mobilstation ist jedoch schon von Interesse, da ja damit der Empfangsalgorithmus unabhängig vom Synchronisieralgorithmus getestet werden kann. 3. Datenaustausch über Backplane

Die für eine Simulation von Mehrkanalübertragungen erforderliche Rechenleistung wird bei dem Erfindungsgegenstand durch das Zusammenwirken mehrerer (oder einer Vielzahl von) Rechenboards erbracht. Vorzugsweise erfolgt die Aufteilung der Rechenleistung so, dass jedes Board genau einen ΜΙΜΟ- Kanal (eine Verbindung von einer Sendeantenne zu einer Empfangsantenne) berechnet. Um nun aus diesen einzelnen Kanälen das Gesamtsignal zu berechnen, müssen zwischen den Boards Teilergebnisse weitergereicht sowie Eingangssignale verteilt werden. Dazu ist eine sehr leistungsfähige Datenkommunikation zwischen den Boards erforderlich, die bei dem Erfindungsgegenstand über eine Backplane mit fix verdrahteten LVDS-Verbindungen geführt wird.

Die Hardware für das Backplanekonzept besteht aus einer Platine mit 2 oder mehreren Steckern, die mit den Signalverarbeitungsboards durch eine Steckverbindung oder über ein Kabel verbunden sind (siehe Abbildung 20). Eine bevorzugte Ausführung dieser Steckverbindung mittels einer neuartigen steckerlosen Technologie wird in Abschnitt 3.1 beschrieben.

Jede Signalverarbeitungsplatine führt zu diesem Stecker neben Datensignalen auch Steuersignale, wie z.B. serielle Steuersignale (RS232...), IIC- Bussignale und Synchronisationssignale. Weiters kann über diesen Stecker auch die Energieversorgung mit konstanten Spannungen und variablen Strömen bezogen werden.

Um die Zahl der erforderlichen Datenleitungen gering zu halten und dennoch sehr hohe Datenübertragungsraten zu erzielen, werden Datensignale nach dem LVDS- Channellink Vorschlag für 32 bit Signale verwendet. Dabei werden die Datensignale zu 6 Signalen serialisiert und mittels LVDS- Pegel (Low Voltage Differential Signaling) auf 6 Leitungspaaren übertragen. Dazu kommen noch 2 Paare LVDS- Taktsignale. Diese derart beschriebene Datenverbindung wird im Folgenden als LVDS- Kanal bezeichnet (siehe Abbildung 21). 16 AT 501 645 B1

Die Backplane hat auch die Aufgabe, jedes Board über eine fixe eindeutige Slotadresse und eine einstellbare Gehäuseadresse (zum Beispiel mit einem DIP- Switch) für die Datenrichtung Backplane -> Board zu adressieren. Um Leitungen auf dem Stecker zum Signalverarbeitungsboard zu sparen, kann diese Adressierung mit 3 Adressierungen, einer Datenleitung, einer Read-Leitung und einem Multiplexer aufgebaut werden (siehe Abbildung 22).

Mit dieser Adressierungsart, einem adressable Latch und einer zusätzlichem Write-Leitung können auch Signale vom Signalverarbeitungsboard über die Backplane geführt werden (siehe Abbildung 23).

Die Backplane hat auch die Aufgabe, Synchronisationssignale von einem Signalverarbeitungsboard (Master Board z.B. im Slot 0) zu den anderen Boards zu übertragen. Um Reflexionen an der Backplane zu verhindern werden GTLP- Treiber und GTLP Receiver verwendet. Diese Sync- Signale können auch über eine entsprechende Backplaneerweiterung zur Gerätehinter-seite weitergeführt werden, um auch die Synchronisation mit anderen Systemen zu ermöglichen (Abb. 24).

Eine Übertemperaturüberwachung kann ebenfalls auf der Backplane vorgesehen werden. Einfache Bimetallschalter sowohl für eine Wamschwelle als auch zum Abschalten des Gerätes sind vorgesehen. Es wird jedoch auch eine kompliziertere Temperaturmessung mit eigenen elektronischen Temperatursensoren vorgeschlagen.

Auf jedem Signalverarbeitungsboard sind 4 LVDS- Kanäle zur Backplane geführt, die sowohl als Eingang als auch als Ausgang betrieben werden können. 2 dieser 4 Kanäle werden über die Backplane zu einer Daisy- Chain verbunden, in der jedes Board seinen Eingang vom vorhergehenden Board bezieht und seinen Ausgang zum nächsten Board führt. Auf diese Weise können die Einzelergebnisse der jeweiligen MIMO-Kanäle aufaddiert werden und das Ergebnis zum nächsten Board weitergeleitet werden (siehe Abbildung 25). Der 1. Eingang des 1. Signalverarbeitungsboards und der letzte Ausgang des letzten Signalverarbeitungsboards werden über das Backplaneerweiterungssystem an die Gehäuserückwand geführt, um diese Daisy Chain auf mehrere Systeme erweitern zu können.

Durch ein einfaches Backplaneerweiterungssystem (siehe Abbildung 26) werden die 2 restlichen LVDS- Kanäle (Eingang und Ausgang) jedes Boards bis an die Gehäuserückwand geleitet. Mit Hilfe von Kabeln kann damit auf der Gehäuserückwand das Eingangssignal verteilt werden, um die gewünschten ΜΙΜΟ- Konfigurationen zu erhalten. Diese Verdrahtung kann entweder vom Kunden vorgenommen werden, oder fix vom Hersteller vorgegeben werden (s. Abschnitt 4, Fixverdrahtungen der Boards für unterschiedliche ΜΙΜΟ- Konfigurationen). In letzterem Fall werden die Signale intern vom FPGA geschalten und auf die gewünschte Weise miteinander verbunden.

Dieses Backplaneerweiterungssystem sieht auch die Verwendung einer großen programmierbaren Schaltmatrix für LVDS- Kanäle vor. Damit ist kein händisches Stecken für das Verteilen des Eingangssignals erforderlich. Die Schaltmatrix für LVDS- Kanäle kann durch einen großen FPGA realisiert werden (siehe Abbildung 27).

Zur besseren Übersicht kann man aus Abbildung 27 die Anordnung der einzelnen Platinen im Rack des Gesamtsystems sowie die Front- bzw. Rückansicht des Racks entnehmen. 3.1. Steckverbindung zwischen Backplane und SV-Boards

Um 2 Leiterplatten auf einer Länge L miteinander zu verbinden und dabei N elektrische Verbindungen zwischen den Leiterplatten zu erhalten, wurden bisher Steckverbinder verwendet. Zumindest auf einer Leiterplatte (meistens auf beiden Leiterplatten) waren solche Steckverbinder notwendig. Um eine hohe Zahl an elektrischen Verbindungen pro Längeneinheit zu erreichen, 1 7 AT 501 645 B1 wurden überwiegend mehrreihige Steckverbinder eingesetzt. Bei Verbindung der beiden Leiterplatten in einem Winkel von 90 Grad liegen daher die inneren Kontakte weiter entfernt vom Leiterplattenrand und es ergeben sich für diese Kontakte kürzere Leitungslängen im Vergleich zu den äußeren Kontakten. Dies stellt ein großes Problem für Verbindungen mittels LVDS-Technologie dar, denn diese Technologie setzt gleiche Leitungslängen voraus.

Aus diesem Grund wurde eine sehr fortschrittliche Technik für eine „steckerlose“ Verbindung zwischen 2 Leiterplatten entwickelt. Das neue Verbindungssystem sieht die mechanische und elektrische Verbindung von 2 zueinander um 90 Grad gedrehten Leiterplatten durch direktes ineinander Stecken der Leiterplatten vor (siehe Abbildung 28).

Die Leiterplatte 1 besitzt an ihrem Ende Fortsätze mit einer ähnlichen Form wie Stecker bei einem PCI - Stecksystem. Auf beiden Seiten jedes Fortsatzes befinden sich Leiterbahnen (siehe Abbildung 29).

Die Leiterplatte 2 hat längsgefräste Ausnehmungen (siehe Abbildung 30), welche die Fortsätze der Leiterplatte 1 aufnehmen.

Das Design und die Fertigung der Leiterplatte 1 erfolgt standardmäßig. Die Leiterbahnen sollen möglichst bis an den Rand geführt werden. Die Leiterbahnbreite kann z.B. 0.4 mm und der Leiterbahnabstand 0.6 mm betragen. Damit ergibt sich eine Dichte von 1 Leiterbahn / mm für jede Seite, also 2 Leiterbahnen / mm für die gesamte Steckverbindung.

Die schlitzförmigen Ausnehmungen der Leiterplatte 2 sollen eine Breite aufweisen, welche der Dicke der Leiterplatte 1 plus den Toleranzmaßen entspricht (bei Standardleiterplatten beträgt die Dicke 1.6mm, die Fräsung sollte daher 1.8 bis 2.0mm betragen). Die Ausnehmungen werden gefräst, nachdem an jeder Leiterbahn zwei Durchkontaktierungen gesetzt wurden, die zur Hälfte weggefräst werden, und die den elektrischen Kontakt zur Leiterplatte 1 hersteilen.

Die Leiterbahnen der Leiterplatte 2 müssen mit demselben Raster wie auf Leiterplatte 1 bis zu der Fräskante auf der Ober- und Unterseite (die Leiterbahnen auf der Ober- und Unterseite müssen gleiches elektrisches Potential haben) geführt werden. Genau auf den beiden Fräskanten muss jeweils eine Durchkontaktierung (verbindet Leiterbahn der Ober- und Unterseite) gesetzt werden. Der Bohrdurchmesser für die Durchkontaktierungen muss kleiner als die Leiterbahnbreite sein und die Pads der Durchkontaktierungen dürfen nicht wesentlich größer als die Leiterbahnbreite sein. Auf alle Fälle muss der Isolierabstand zwischen den Pads eingehalten werden. Für einen Leiterbahnabstand von 1.0mm und einer Leiterbahnbreite von 0.4mm könnte eine Durchkontaktierungsbohrung von 0.3mm und ein Paddurchmesser von 0.5 - 0.6mm vorgesehen werden.

Nach einer gewöhnlichen Leiterplattenfertigung werden die Schlitze gefräst. Dabei werden wie beschrieben alle Durchkontaktierungen zur Hälfte weggefräst (siehe Abbildung 31).

Nach dem mechanischen Zusammenstecken kann dann die Lötverbindung durch Schwalllöten erreicht werden (Schwallrichtung siehe Abbildung 28). 4. Fixverdrahtungen der Boards für unterschiedliche MIMO-Konfigurationen

Die unterschiedlichsten MIMO/MISO/SIMO-Konfigurationen können mit dem Erfindungsgegenstand realisiert werden. Um dem Kunden ein aufwändiges Verkabeln zu ersparen, sind die einzelnen Boards z.T. über eine fixe Verkabelung (Backplane) miteinander verbunden. Die einzelnen Ein- bzw. Ausgänge sind softwaregesteuert schaltbar, um sie für verschiedene Zwecke verwenden zu können, wodurch sich im Gesamten viele Nutzungsmöglichkeiten ergeben.

Im Prinzip sind folgende Lösungen möglich: 18 AT 501 645 B1 1) alle Verbindungen zwischen Boards werden vom Kunden mit Patchkabeln verdrahtet. Diese Lösung bedeutet aber für den Benutzer einen unzumutbaren Aufwand und wird daher nicht weiter betrachtet 2) alle Verbindungen zwischen Boards sind auf der Backplane in Form von zwei Daisy-Chains fix verdrahtet 3) Es existiert nur eine fix verdrahtete Daisy-Chain, die jedes Board mit seinem unmittelbaren Nachbarn verbindet. Dadurch bleiben auf jedem Board noch ein Sende- und ein Empfangskanal frei. Diese werden nun nach außen geführt und können mit Patchkabeln beliebig verdrahtet werden. 4.1. MIMO-Konfigurationen mit 2 fix verdrahteten Daisy-Chains

Pro Board stehen 3 LVDS Eingangskanäle und 3 LVDS Ausgangskanäle zur Verfügung, wobei jeder einzelne LVDS- Kanal fix ein Eingang oder ein Ausgang ist. Von diesen sind jeweils ein Eingang und ein Ausgang bequem an der Frontplatte zugänglich, die restlichen 2 Ein- und 2 Ausgänge sind über einen 96-poligen Stecker an die Backplane geführt. Je ein Ausgang an der Backplane ist mit einem Eingang des benachbarten Boards verbunden (obere Linkleiste), der zweite Ausgang an der Backplane ist mit einem Eingang des übernächsten Boards verbunden (untere Linkleiste, siehe Skizze).

Die einzelnen Kanäle werden je nach Größe/Konfiguration des ΜΙΜΟ Systems für verschiedene Zwecke verwendet, z.B. zum Weiterschleifen der Eingangsdaten oder zum Weiterreichen der Zwischenergebnisse. Dadurch, dass man sich hier nicht auf fixe Nutzungsarten jedes Kanals festlegt, erreicht man (bei gleicher, fixer Verdrahtung) wesentlich mehr Nutzungsmöglichkeiten.

Darüber hinaus werden diese Verdrahtungen vom ersten bzw. letzten Board des Racks nach außen geführt. Dadurch wird in vielen Fällen eine praktische Kaskadierung der Racks möglich, um größere Installationen zu bauen. Dies soll anhand einiger Bespiele gezeigt werden, wobei wir uns folgender Notation bedienen:

Notation: 0 LVDS-Output (Backplane intern) 0 LVDS-Input (Backplane intern)

Ungenutzter LVDS-Input (Backplane intern)

i—S LVDS-ln-/Output (Backplane extern) LVDS-ln-/Output (Frontplatte)

Rote/Orange Pfeile: Sendesignale

Blau/Grüne Pfeile: Resultate MISO n—*1:

Ein Rack mit simpler Verschaltung (siehe Abbildung 32). Es wird immer das vorige Teilergebnis vom linken Nachbarn geholt und das Berechnungsergebnis an den rechten Nachbarn und an den Frontausgang geliefert. Der letzte Frontausgang hat dann das Endergebnis. Nur für den Spezialfall, dass n ein Vielfaches von 8 ist, liegt auch am Erweiterungsstecker das Endergebnis an.

Beim Design der Software ist auf die Laufzeiten in den LVDS Links beim Weiterreichen der 19 AT 501 645 B1

Zwischenergebnisse zu achten. Das Senden eines Symbols benötigt stets exakt einen ganzen Symboltakt und die Addition einen weiteren Takt (auch wenn sie real viel schneller ist, ist es praktisch taktsynchron zu bleiben). Somit braucht die n-te Platine im System stets 2n+1 Zwischenbuffer (wahlweise für Input- oder Output - siehe unten) damit sicher die richtigen Samples zusammenaddiert werden. Jede Platine muss also um Ihre Position (innerhalb des Racks und die Position des Racks im Gesamtsystem) wissen (entweder per Software, die solche Entscheidungen treffen kann, oder durch je eine unterschiedliche Softwareversion pro Platine) um die Buffer richtig dimensionieren zu können. ΜΙΜΟ n->2: ΜΙΜΟ n—2 funktioniert sehr ähnlich wie MISO n—1. Während bei MISO n—1 die Basiseinheit eine einzelne Platine ist, wird hier stets ein Set aus 2 Platinen betrachtet (Abbildung 33). Die Verteilung des Eingangssignals innerhalb eines Sets findet über die obere Linkleiste statt. Die unteren Linkleisten bieten bequemes Weiterreichen der Zwischenergebnisse. (Logisch äquivalent zu zwei verschachtelt aufgebauten MISOs!)

Wie schon im MISO Fall, muss jede Platine um ihre relative Position in der Kette wissen um die Eingangs- oder Ausgangsbuffer der Channel - Engine angemessen dimensionieren zu können. Als zusätzliche Komplikation ist es hier erforderlich, dass der Platine bekannt ist, ob sie zum ersten oder zweiten Empfängerstrang gehört und entweder die Eingangsdaten von der Frontplatte bezieht und über die Backplane weiterreicht oder über die Backplane bezieht. Achtung: Durch das Weiterreichen per Backplane ergibt sich eine weitere (minimale: ca. Y* bis V* LVDS Takt) Verzögerung des Eingangssignals, das evt. als störend empfunden wird. ΜΙΜΟ 8—8

Offensichtlich benötigt man zur Realisierung eines ΜΙΜΟ 8—8 System 8x8 = 64 Platinen, die in 8 (64/8) Racks untergebracht werden (s. Abbildung 35). Nun gibt es grundsätzlich zwei Möglichkeiten die 8 Racks logisch anzuordnen: Entweder zwei Türme von je 4 Racks, oder einen Turm von 8 Racks übereinander. Andere Lösungen (etwa 4 Türme aus je nur 2 Racks oder 8 Einzelracks nebeneinander (oder gar Systeme mit mehreren Türmen unterschiedlicher Höhe), sind nicht geschickt aus dem bisher dargestellten Basisrack realisierbar und werden daher im Folgenden auch nicht behandelt.

Ansatz A: Zwei Türme mit je 4 Racks übereinander (s. Abbildung 34)

Ansatz B: 8 Racks übereinander (s. Abbildung 35 )

Vorteil: Für den Betrachter einfacher zu durchblickende Logik Nachteil: Mehr Verkabelungsaufwand 4.2. MIMO-Konfigurationen mit 1 Fixverdrahtung und einer Kabelverdrahtung

Der wesentliche Vorteil der Lösung mit nur einer Fixverdrahtung besteht darin, dass über die Daisy-Chain immer nur (Zwischen-) Resultate von einem Board zum nächsten gereicht werden, nie aber Modulatorsignale verteilt werden. Die Modulatorsignale werden dann über vom Benutzer anzubringende Kabel flexibel verteilt. Dies steht in deutlichem Unterschied zur Lösung mit zwei fix verdrahteten Daisy-Chains, bei denen, je nach MIMO-Grad mal die eine, und mal die andere Daisy-Chain für jede dieser Aufgaben herangezogen wurde. Durch die flexiblere Verdrahtung ist es also bereits bei der Programmierung des Kanalmodells bekannt, an welchem Eingang das Board Zwischenergebnisse erhält und wo Modulatorsignale empfangen werden, ohne dass dabei bereits der ΜΙΜΟ Grad bekannt sein müsste. Dies macht die Entwicklung der FPGA Logik wesentlich einfacher (Abb. 36 und 37).

Weiters sind nun auch ΜΙΜΟ Grade, die keine Zweierpotenz sind, über mehrere Racks ohne 20 AT 501 645 B1 Lücken zwischen den Boards der Racks füllbar. Durch die Verwendung mehrerer Racks ist es natürlich wieder erforderlich, auch die Daisy Chain durch ein Kabel weiterzuschleifen.

Der zentrale Vorteil der höheren Flexibilität bei der freien Verdrahtung anstelle der zweiten Daisy-Chain stellt gleichzeitig auch den größten Problempunkt dar. Es ist ein großer Verdrahtungsaufwand erforderlich, der leicht unübersichtlich werden kann (Abb. 38). 5. Empfängerstrukturen für die Entwicklungsplattform

Die zentrale Aufgabe eines digitalen Receivers besteht darin, das (digitale) Base-Band Signal zu dekodieren und die darin enthaltenen (Nutz-) Daten zurück zu gewinnen. Die Base-Band Daten jeder Empfangsantenne werden dabei als l/Q (Amplitude/Phase) Paare mit einer Wert-Auflösung von je 32 Bit geliefert. Die Abtastzeitpunkte werden dabei so gewählt, dass pro Bitzeit zwischen ein (kein Oversampling) und acht (8-fach Oversampling) Datenwerte gemessen werden.

Die folgenden Ausführungen beziehen sich auf eine reine Basisband-Übertragung. Für Übertragung im HF-Bereich müssen den einzelnen Basisband-Eingängen des Receivers jeweils seine HF-Karte vorgeschaltet werden.

Alle realisierbaren Empfängerstrukturen der Entwicklungsplattform basieren auf der Grundeinheit eines DSP-Boards. Je nach gewünschter MIMO-Konfiguration fallen unterschiedliche Datenmengen für den Receiver an. Daraus ergeben sich unterschiedliche Anforderungen an die Datenraten der Anschlüsse sowie an die Rechenleistung des Receivers. Um diesen Anforderungen zu entsprechen, werden mehrere DSP-Boards sowie Zusatzprints zu einem Receiversystem kombiniert. GSM arbeitet mit TDMA (Time Division Multiple Access) in Frequenzbändern von 200kHz Breite. Ein TDMA Frame dauert dabei 4,615 ms (» 216,67 Hz) und enthält 8 Time Slots (zu je 0,5766 ms). In jedem dieser Timeslots kann ein Normalburst gesendet werden, der aus 156,25 Bit besteht (« 3,69 ps/Bit * 270833,33 Bits/sec). Diese 156,25 Bit setzen sich zusammen aus 3 Head Bits + 57 Datenbits + 1 Killbit (Abstandhalter, immer 0) + 26 Bit Midamble (Fixes Muster zur Synchronisation und zur (näherungsweisen) Messung der Kanal-Impulsantwort) + 1 Killbit (Abstandhalter, immer 0) + 57 Datenbit + 3 Tail Bits + 8,25 Bit Sicherheitsabstand gegen Jitter, oder kurz gesagt aus 114 (2x57) Bit Nutzdaten, 34 (3+1+26+1+3) Bit Verwaltung und 8,25 Bit Sicherheitsabstand. UMTS arbeitet mit WCDMA (Wideband Code Division Multiple Access). Dabei sendet jeder Teilnehmer gleichzeitig auf der gleichen Wellenlänge in einem 5 MHz breiten Frequenzband. Die Trennung der einzelnen Teilnehmer beim Empfänger erfolgt auf Basis von zueinander orthogonalen Codes, wobei besonders darauf geachtet werden muss, dass bei der Vielzahl der Mobilstationen pro Basisstation und ihrer unterschiedlichen Entfernung von der Basisstation (= unterschiedliche Signallaufzeit) keine perfekte Synchronisation der Empfangssignale erreicht werden kann. UMTS organisiert seine Übertragung in Rahmen zu 10 ms, wobei jeder Rahmen 15 Zeitschlitzen (zu 0,667ms) geteilt ist, und jeder Rahmen 2560 Chips (zu 0,26ps » 3,84 MHz) enthält.

Ein RTS-Board erhält von der Frontplatte über 2 LVDS Anschlüsse Digital-Baseband Signale, die zum FPGA geführt werden. Diese beiden LVDS Anschlüsse sind über einen Zusatzprint mit dem DSP-Board verbunden. Die Digital-Baseband Signale sind jeweils auf UMTS mit 8-fach Oversampling ausgelegt (8x3,84MHz = 30,72MHz Samplerate (jeweils 32 Bit l/Q) - Zur Übertragung von 16 Nutzbits werden 3x7 Datenbits über eine Gruppe von 3 LVDS Paaren gesendet (womit also 5 (=3x7-16) Bit für Verwaltungszwecke zur freien Verfügung stehen).

Außerdem verfügt das RTS-Board durch einen 96 poligen Stecker über weitere LVDS Stecker, 21 AT 501 645 B1 mit denen sich bis zu 4 weitere Digital-Baseband Signale übertragen lassen. Eine Hilfsplatine nimmt 2 solche Digital-Baseband Signale an ihrer Frontplatte entgegen und leitet sie (ohne weitere Verarbeitung) an die Backplane weiter. Von dort gelangen die Daten dann in das RTS-Board. Gemeinsam mit seinen beiden eigenen Frontanschlüssen verfügt das Receiverboard damit über 4 Digital-Baseband-Eingänge (2 eigene + 2 über die Hilfsplatine).

Eine Erweiterung dieser Hilfsplatine auf 4 Digital- Baseband- Eingänge ist ohne weitere Probleme möglich, da ja an der Rückseite Platz für 4 LVDS Kanäle Platz ist. So lassen sich bequem xIMO Systeme mit bis zu 6 (2+4) Empfangsantennen realisieren. Will man darüber hinausgehen (etwa ΜΙΜΟ n->8) so empfiehlt es sich, für je 4 Empfangsantennen ein RTS-Board (mit einer 2-Eingangs-Hilfsplatine) bereit zu stellen. Dadurch gewinnt man unmittelbar bei den Eingängen lokale Rechenleistung, mit denen man die Daten bearbeiten (etwa filtern, komprimieren etc.) kann. Die beiden freien LVDS Ports an der Rückseite kann man nun nutzen, um Daten zwischen den RTS-Boards auszutauschen (Achtung: Es wird ein LVDS-Port pro Richtung benötigt. Diese Lösung ist also nicht auf mehr als 2 RTS-Boards (8 Empfangsantennen) skalierbar. Eine ΜΙΜΟ x-»10 Lösung ist mit 3 RTS-Boards (und 2 Hilfsplatinen) in einer 4+2+4 Eingangsbelegung machbar.). Auch wenn letztlich gewisse Schritte des Empfangsalgorithmus nicht über die RTS-Boards verteilbar sind, sondern unbedingt auf einem einzigen Board ausgeführt werden müssen, kann durch geschickte Vorverarbeitung die Menge der zu übertragenden Bits deutlich reduziert werden (Anmerkung: Dies ist auch dringend nötig. Ein UMTS Kanal lastet (bei 8-fach Oversampling) die Kapazität eines LVDS Kanals vollständig aus, wenn also die Information, die aus den Signalen von 4 Empfangsantennen über einen einzigen LVDS Kanal transportiert werden muss, ist eine geschickte Selektion der Daten unumgänglich.).

Im Folgenden sollen einige Empfängerkonfigurationen dargestellt werden. Dabei werden einerseits RTS Boards (breiter durch Huckepackplatine zur Weiterleitung der beiden LVDS Kanäle von der Frontplatte bis zum Stecker in der Platinenmitte) und andererseits Empfänger-Erweiterungsplatinen (2 LVDS Kanäle werden ohne jede aktive Logik von der Frontplatte an die Anschlüsse der Backplane durchgeleitet) verwendet. Die Aufgabe der Backplane (mit fixer Verkabelung) besteht nun (abgesehen von Spannungsversorgung und Taktweiterleitung) darin, dafür zu sorgen, dass alle LVDS Signale von einem FPGA empfangen werden können.

Aus Kostengründen ist es natürlich wünschenswert, wenn es nur eine einzige Art der RTS Boards und der Erweiterungsplatinen gibt, und dass alle Konfigurationen mit einer einzigen Backplane abgedeckt werden können. 5.1. Receiver für ΜΙΜΟ x-*2 Systeme

Im primitiven Fall, dass nur 1-2 Empfangsantennen ausgewertet werden müssen, genügen natürlich die beiden Basisbandanschlüsse eines einzigen RTS-Boards. Da dieses (einzige) Board mit keinem anderen Board Informationen austauschen muss, beschränkt sich die Aufgabe der Backplane auf die Bereitstellung der Versorgungsspannung und das Loop-Back der Clocksignale. Anmerkung: Die Wahl des Steckplatzes ist durch das Clock-Loopback vorgegeben. Wenn man diese Funktion anderwertig löst, ist die Wahl des Steckplatzes vollkommen frei (Abb. 39). 5.2. Receiver für ΜΙΜΟ x->4 Systeme Für ΜΙΜΟ x->4 Systeme reicht im Allgemeinen die Rechenleistung eines einzigen RTS-Boards. Daher können die beiden anderen Eingänge durch eine kostengünstige Erweiterungsplatine (Plug Extension) gestellt werden (Abb. 40). 5.3. Receiver für ΜΙΜΟ x—>6 Systeme

Am einfachsten lässt sich ein ΜΙΜΟ x->6 Empfangs-System mit 2 RTS-Boards aufbauen (s. 22 AT 501 645 B1

Abbildung 41). Dabei wird eines der RTS-Boards per Erweiterungsplatine noch um zwei weitere LVDS-Eingänge (insg. nun also 4) erweitert. Dieses RTS-Board muss nun 4 LVDS-Eingänge empfangen und den darin enthaltenen Datenstrom vorverarbeiten (z.B. komprimieren durch Redundanzelimination etc. - (Möglichkeiten der Datenkompression siehe unten). Parallel dazu wird das andere RTS-Board Daten über seine beiden LVDS-Kanäle empfangen und ebenfalls vorverarbeiten. Nun werden (jeweils eine Auswahl von wesentlichen) Daten auf eines der beiden Boards gespielt, dort jene Rechenschritte abgearbeitet, für die ein Totalüberblick über alle Daten erforderlich ist, und dann die gewonnenen Erkenntnisse wieder auf beide Boards verteilt.

Anmerkung: Bei dem RTS-Board, das mit der Erweiterungsplatine verbunden ist, sind bereits zwei der 4 rückseitigen LVDS-Kanäle durch das Erweiterungsboard belegt. Es bleiben also nur 2 Kanäle. Da jeder LVDS Kanal nur in eine Richtung verwendet werden kann, und zwischen den Boards bidirektionale Kommunikation stattfinden muss, bleibt nur ein LVDS-Kanal pro Richtung (Abb. 41). 5.4. Receiver für ΜΙΜΟ x->8 Systeme Für ΜΙΜΟ x—>8 Empfangssysteme sind zwei RTS-Boards mit je einem Erweiterungsboard erforderlich (s. Abbildung 42). Jedes Board muss zunächst .seine’ 4 LVDS Kanäle (zwei eigene und zwei von der Erweiterungsplatine) einiesen und vorverarbeiten. Die gewonnenen (komprimierten) Daten werden dann (in den essentiellen Teilen) auf einem Board zusammengefasst und auf diesem Board dann all jene Berechnungen ausgeführt, die wirklich die Daten aller Antennen benötigen (Abb. 42). 5.5. Receiver für ΜΙΜΟ x->10 Systeme

Eine Möglichkeit zur Verringerung der übertragenen Datenmenge besteht in der Verringerung der Anzahl der Bit pro l/Q Wert. Ursprünglich wird dieser Wert mit 32 Bit Auflösung gesampelt, doch ergeben sich dabei nie 32 signifikante Bits, vielmehr ist die große Bitzahl ist nur erforderlich um sowohl starke, direkte Signale empfangen zu können, als auch extrem gedämpfte Signale noch sinnvoll aufzulösen. Nachdem die Daten einer AGC (Automatic Gain Control) unterworfen wurden, sind die signifikanten Informationen sicher in den höchstwertigen 16 Bit enthalten und die unteren 16 Bit können ohne negative Folgen vernachlässigt werden. Es gibt sogar die Meinung, dass die wichtigen Informationen bereits in den ersten 8 Bit (evt. sogar nur 5-6 Bit) enthalten sind, und somit noch wesentlich mehr Bits entfernt werden können, ohne wichtige Informationen zu verlieren. Für viele Algorithmen mag es ausreichen, wenn eine Auswahl des empfangenen Signals (und nicht das gesamte Empfangssignal) zur Berechnung bereitsteht. So reicht es für den GSM-Receiver aus, wenn die Daten der Midamble zur Verfügung stehen (also nur 26 von 156 Chips eines Timeslots (d.h. nur 26/156 = 1/6 der gesamten Daten muss übertragen werden).

Durch die Reduktion der Bits/Sample und die geschickte Auswahl der übertragenen Daten (sowie notfalls durch Reduktion des Oversamplings) lassen sich die Datenströme sicher so komprimieren, dass sie über eine einzige LVDS Leitung übertragen werden können (Abb. 43).

Neben dem Handling der Eingangssignale und der eigentlichen Durchführung des Empfangsalgorithmus, muss das RTS-Board natürlich auch die Ergebnisse seiner Tätigkeit nach außen liefern. Verglichen mit den Eingangsdaten sind die Ergebnisse sehr kompakt. GSM liefert etwa 197.904 bit/sec (= 24.738 Byte/sec) (= 2x57 Datenbits/Normalburst x 1 Normalburst/Timeslot x 8 Timeslots/TDMA Frame x 217 Frames/sec) echte Nutzdaten (oder sogar weniger, wenn nicht alle Timeslots genutzt werden). Zu diesen Nutzdaten, die auch der im Realeinsatz befindliche Receiver berechnen muss, kommen noch Zusatzdaten die nur für die Entwicklung und Visualisierung der Algorithmen nötig sind (etwa AGC Faktoren, FIR-Faktoren der geschätzten Kanäle, Gewichtungsfaktoren für die Signalsummation etc.) wobei diese Werte aber stets für eine größere Gruppe von Bits gelten, und somit selbst keinen riesigen Datenstrom darstellen (selbst bei 23 AT 501 645 B1 sehr großzügiger Auslegung nur wenige 100 KByte/sec). UMTS liefert bereits deutlich mehr Daten. Bei reiner Sprachübertragung (128x12,2 KBit/sec) oder wenigen, schnellen Datenverbindungen (4x384 KBit/sec) sind insgesamt bis zu 1.5 MBit/sec (= 192 KByte/sec) sind möglich. Wie bei GSM kommen dazu noch die internen Daten aus dem Empfangsalgorithmus (wohl wieder max. wenige 100 KByte/sec).

Bei DECT liegt mit seinen (bei Vollauslastung aller 24 Kanäle) 1,152 MBit/sec (= 144 KByte/sec) in einer ähnlichen Größenordnung wie UMTS.

Der Coldfire pController verfügt über eine 100 MBit/sec Fast Ethernet Schnittstelle, über die (real gemessen) eine Datenübertragung per TCP/IP von rund 2,3 MByte/sec (oder 3,3 MBy-te/sec mit UDP) möglich ist (begrenzt durch die CPU-Leistung des Coldfire). Die wenigen 100 KByte/sec, die die Empfangsalgorithmen als Ergebnis liefern, lassen sich also bequem per Ethernet an den (Windows-) PC übertragen, auf dem das steuernde Programm und die Benutzeroberfläche läuft.

Alternativ wäre natürlich auch der Zugang über das JTAG Interface des DSP (mit bis zu 28.5 MHz) möglich. Diese Lösung hat allerdings mehrere Nachteile: Schnelle JTAG Interfaces sind sehr teuer, wohingegen Fast Ethernet mittlerweile zur Standardausstattung jedes PC gehört. Für den Einsatz mehrerer RTS- Boards sind ebenso viele JTAG Interfaces erforderlich, was die Kosten weiter nach oben treibt, während ein Fast Ethernet Switch für wenige Euro/Port verfügbar ist. Wenn das RTS- Board in ein Rack eingebaut ist, ist das JTAG Interface im Gehäuseinneren, versteckt, während der Fast Ethernet Stecker auf der Frontseite bequem erreichbar ist. (Anmerkung: Natürlich wäre es möglich, auch die JTAG Stecker über eine Huckepackplatine (anstatt oder zusätzlich zur LVDS Huckpackplatine) zur Frontplatte zu führen. 6. Automatisierte Codegenerierung und Einbinden des Systems in standardisierte Simulationstools

Die Entwicklung von komplexen Algorithmen, insbesondere für Echtzeit-Simulationen, erstreckt sich über einen mehrstufigen Prozess. Am Beginn der Produktentwicklung werden normalerweise Ideen in einem high-level Simulationstool wie Matlab/Simulink implementiert und auf dieser Ebene getestet. Anschließend werden die derart gewonnenen Algorithmen auf der Zielplattform implementiert und in Echtzeit getestet.

Zur Beschleunigung und Vereinfachung dieses Prozesses können Methoden der automatischen Codegenerierung, insbesondere Rapid Prototyping eingesetzt werden. Mithilfe dieser Technologie lassen sich neue algorithmische Ideen schnell auf eine Echtzeit-Plattform umsetzen, wodurch eine Vielzahl von Fehlerquellen, die durch manuelles Codieren entstehen, ausgemerzt werden. Signalverarbeitungs-Ansätze können daher einfach getestet und evaluiert werden.

Rapid Prototyping basiert auf dem „Golden Code“ Paradigma. D.h. es gibt einen zentralen Code, an dem verschiedene Teams arbeiten können, und der in einer abstrakten Sprache geschrieben ist. Dieser Code kann auf unterschiedliche Plattformen gemappt werden, somit können Änderungen zentral vorgenommen werden und es sind nicht mehrere Implementierungen eines Algorithmus in verschiedenen Sprachen notwendig.

Im Header des Golden Codes wird die Anzahl an Ein-/Ausgängen und deren Datenraten genau spezifiziert. Die Plattformen können entweder ein Simulationswerkzeug, das tatsächliche System, oder die sich auf die Erfindung beziehende Signalverarbeitungshardware sein. Mithilfe des Mapping-Tools kann der Golden Code nun auf die verschiedenen Plattformen gemappt werden (siehe Abbildung 44).

Der „Golden Code“ lässt sich auch in mehreren Codeblöcke verwalten, die wahlweise auf DSPs 24 AT 501 645 B1 oder FPGAs gemappt werden können. Mithilfe des Mapping Tools ist es möglich, diese Partitio-nierung (welcher Block auf welchen Baustein gemappt wird) automatisch durchzuführen.

Im Rahmen einer Diplomarbeit wurden bereits einige Tools für Rapid Prototyping entwickelt. Das Programm GenC zum Beispiel bildet in Generic C implementierte Algorithmen („Golden Code“) automatisch entweder in Simulink Blöcke oder auf die sich auf die Erfindung beziehende Signalverarbeitungshardware ab. Bei letzterem wird außerdem eine automatische Partitionie-rung von Blöcken auf den DSP bzw. den FPGA durchgeführt.

Um unter Simulink auf die Zielplattform zugreifen zu können, lässt sich bei dem der Patentanmeldung zugrunde liegenden Erfindungsgegenstand noch ein weiteres Automationsfeature realisieren, nämlich das Einbinden des Systems in standardisierte Simulationstools (wie z.B. Simulink). Dies bedeutet, dass das System „in the loop“ betrieben werden kann (Hardware in the Loop). Hithilfe von „Hardware in the Loop“ ist es möglich, spezifische Eigenschaften und Probleme der Zielplattform in einem frühen Stadium der Produktentwicklung mit einzubeziehen.

Es wurde eine Bibliothek entwickelt, welche die Kommunikation zwischen der sich auf die Erfindung beziehenden Signalverarbeitungshardware und dem Simulationstool Simulink realisiert. Mit dem Programm GenCaddOn können die von GenC erzeugten Dateien um Initialisierungs-, Sende-, und Empfangsroutinen erweitert werden, so dass aus dem Simulink - Modell einzelne Blöcke auf das Simulationsboard ausgelagert und vom PC aus auf dem Board ausgeführt werden können. Für die Simulation bedeutet dies, dass ein Block den Datenaustausch zwischen Hardware und PC steuert.

Im Gegensatz zu anderen Produkten dieser Art (z.B.: Xilinx System Generator, Mathworks Em-bedded Target, ...) stellt die vorliegende Erfindung den „Loop“ nicht über teure JTAG Interfaces her, sondern über ein Fast Ethernet. Die Hardware kann also bequem ans eigene Haus- oder Firmennetz angeschlossen werden. Das wird einerseits dadurch ermöglicht, dass die sich auf die Erfindung beziehende Signalverarbeitungshardware die Möglichkeit besitzt über Ethernet geflasht zu werden oder durch spezielle Simulink I/O Blocks, die die Verbindung von Simulink zu der Signalverarbeitungshardware über Fast Ethernet herstellt. 7. Implementierungsmerkmale des Erfindungsgegenstandes 7.1. Channel Engine

Die Channel Engine berechnet die Faltung der einzelnen Mehrwegsignale und ist in den wesentlichen Punkten entsprechend der Patentanmeldung A 904/2003 „Kanalsimulator“ ausgeführt. Die entscheidenden Verbesserungen gegenüber der erwähnten Anmeldung sind im folgenden Abschnitt angeführt.

Im GSCM Kanalmodell werden viele unterschiedlich lange Ausbreitungspfade berücksichtigt. Manche Pfade weisen eine gegenüber anderen Pfaden eine um Vieles höhere Länge auf, so-dass Intersymbolinterferenzen auftreten. Das bedeutet, dass die zeitliche Verzögerung dieser Pfade höher wie die Symboldauer ist und daher nicht das gleiche Symbol wie über den kürzeren Pfaden, sondern das vorangehende Symbol empfangen wird. Um die richtigen Signale zu falten, muss jetzt um einen Delay-Wert in die Vergangenheit zurückgegangen werden und das entsprechende Modulationssignal verwendet werden. Dazu wird ein HistoryRAM verwendet, das den zeitlichen Verlauf des Modulationssignals über eine bestimmte Dauer festhält. Da in dem speziellen Fall sehr viele unterschiedliche Lesezugriffe auf dieses HistoryRAM durchgeführt werden (die Adressen entsprechen den Delays der Pfade), aber Schreibzugriffe nur mit kontinuierlich steigender Adresse gemacht werden, wurde das HistoryRAM mit dem in Abschnitt 7.2 dargestellten Double Dual-Ported RAM implementiert.

Die Channel Engine erhält am Eingang entweder ein internes (vom DSP berechnetes) oder ein 25 AT 501 645 B1 externes Modulationssignal und resampelt dieses Signal mithilfe eines Multirate Interpolationsfilters, um die zeitliche Auflösung zu vergrößern, wobei zusätzlich der Differenzwert jedes Abtastwertes zum vorigen Abtastwert gebildet wird. Dieses upgesampelte Signal wird zusammen mit den Deltawerten im HistoryRAM abgespeichert. Um eine weitere Steigerung der zeitlichen Auflösung des Modulatorsignals zu erreichen, wird beim Auslesen aus dem HistoryRAM der Signalwert mithilfe vom DSP vorgegebener Abweichungswerte angenähert (sukzessive Approximation). So kann eine zeitliche Auflösung im Bereich von 1 ns erreicht werden.

7.2. Double Dual-Ported RAM

Wie im vorangegangenen Abschnitt ausgeführt, wird das HistoryRAM mit einem neuartigen Double Dual-Ported RAM realisiert. Diese Erfindung beschreibt einen Datenpuffer, der die von einer Datenquelle (Produzenten) laufend mit hoher Frequenz gelieferten Daten für mehrere Datenempfänger (Konsumenten) zugänglich macht. Dabei kann bei jedem Zugriff eines Konsumenten, innerhalb eines durch die Puffergröße definierten Intervalls, frei gewählt werden, um wie viele Datenpakete vom aktuellen Zeitpunkt gesehen zurück in die Vergangenheit der Zugriff erfolgen soll.

Es entspricht dem Stand der Technik, für diese Problemstellung ein Dual-Ported RAM zu verwenden, das ein RAM-Port für das Schreiben und ein RAM-Port zum Auslesen verwendet. Dabei können sich mehrere Konsumenten den Lese-Port im Zeitmultiplex-Verfahren teilen. Es ist jedoch sehr schwierig, die freie Zeit des Schreib-Ports für weitere Lesezugriffe zu verwenden, da der Umschaltvorgang zwischen Lese und Schreibzugriff sehr viel Zeit in Anspruch nimmt.

Diese Erfindung beschreibt eine Möglichkeit, durch geschickte Nutzung der internen RAM-Organisation des Puffers, sowie der Tatsache, dass die Schreibzugriffe streng geordnet erfolgen, wahlweise eines aus gewöhnlichem Single-Ported RAM gefertigten Puffer gleichzeitig zum Lesen und zum Schreiben zu nutzen oder beide Ports eines Dual-Ported RAM zum Lesen zu Nutzen und trotzdem noch Daten schreiben zu können.

Intern ist ein größerer RAM Bereich, der etwa in einem FPGA implementiert ist, aus mehreren kleinen BlockRAMs fixer Größe zusammengesetzt, von denen jedes über eigene Adress- und Datenleitungen verfügt. Erst eine darüber liegende Logik, die vom VHDL Compiler automatisch erstellt wird, baut daraus einen einzigen, homogen Speicher. Statt dieser standardmäßigen Logik kann nun die dieser Erfindung zugrunde liegende verbesserte Logik verwendet werden, wie sie in folgender Abbildung 45 beispielhaft dargestellt ist.

Die in Abbildung 45 verwendeten BlockRAMs sind Dual Ported. Der in Abbildung 45 oben dargestellte Port dient dabei nur dem Lesen, wobei sich mehrere, in der Abbildung exemplarisch zwei, Konsumenten diesen Port im Zeitmultiplex teilen, während der unten dargestellte Port dem gleichzeitigen Lesen durch mehrere, in der Abbildung exemplarisch zwei, Konsumenten und dem Schreiben durch den Produzenten dient. Verfügt man nur über Single Ported BlockRAMs, so fällt der obere Teil der Abbildung weg, und der nunmehr einzige Port dient dem gleichzeitigen Lesen und Schreiben.

Da der obere Teil der Schaltung dem allgemeinen Stand der Technik entspricht wird im Folgenden nur der untere Teil der Schaltung weiter beschrieben.

Um gleichzeitig Lesen und Schreiben zu können werden nach außen hin zwei Daten- und Adressbusse eingesetzt von denen einer ausschließlich zum Lesen dient und einer ausschließlich zum Schreiben eingesetzt wird. Die Umsetzung von diesen beiden globalen Bussystemen auf die lokalen Busse der einzelnen BlockRAMs findet durch jeweils einen Multiplexer für jedes BlockRAM statt. Dabei wird der Produzent mit einem eigenem BlockRAM verbunden in das er die aktuell anfallenden Werte einträgt (Nutzung der streng sequentiellen Natur des Datenein- 26 AT 501 645 B1 gangs), während die Busse aller anderen BlockRAMs mit den Lese-Bussen verbunden sind. Es lohnt sich festzuhalten, dass die Datenleitungen Daten stets nur in eine Richtung transportieren müssen, es ist also nicht erforderlich, teure, bidirektionale Multiplexer einzusetzen.

Die einzelnen BlockRAMs sind dabei nach dem Prinzip der zyklischen Kette angeordnet. Das vorderste Glied dieser Kette stellt das aktuelle Schreib-BlockRAM da, während sich dahinter, nach zunehmendem Alter sortiert, die Lese-BlockRAMs befinden. Wenn der Produzent .sein' BlockRAM vollgeschrieben hat, wird dieses vorne in die Kette der Lese-BlockRAMs eingereiht und nach dem Prinzip der zyklischen Kette das .älteste' Lese-BlockRAM als neues Schreib-BlockRAM zugewiesen.

Es soll festgehalten werden, dass diese Umprogrammierung des MUX und das Umschalten zwischen Lese- und Schreibbetrieb eines BlockRAMs nur dann erforderlich ist, wenn ein BlockRAM gerade voll geschrieben ist. Die erforderliche Adressumsetzung, die sich durch die Aufteilung des GesamtRAMs in Einzelblöcke ergibt, beschränkt sich auf simples Vernachlässigen von Bits, sofern die Anzahl der BlockRAMs eine Zweierpotenz ist. Andernfalls ist hier eine geringfügig aufwändigere Modulo-Addition erforderlich. Somit ist dargestellt, wie mit geringem Aufwand RAM Bausteine gleichzeitig sequentiell geschrieben und wahlfrei gelesen werden können. 7.3. LVDS-Protokoll und Synchronisierung

Um Daten zwischen den einzelnen Signalverarbeitungsboards austauschen zu können, wurden LVDS-Verbindungen auf Basis des 21-Bit Channellink Standards gewählt. Die Datensätze bestehen aus 64 Bit, wobei sie sich auf jeweils 32 Bit für Realteil (I) und Imaginärteil (Q) aufteilen. Um die Daten über den oben genannten Link zu übertragen, muss dieser Datensatz in 4 Teile zu je 16 Nutzdatenbits geteilt werden. Durch diese Aufteilung wird es notwendig, den einzelnen Datenpaketen Informationen beizupacken, um sie am Empfänger wieder zu einem kompletten Datensatz zusammensetzen zu können. Dies geschieht in den 5 Overheadbits.

So ist es z.B. aufgrund der hohen Übertragungsrate der LVDS Verbindung in manchen Anwendungsfällen notwendig, zusätzlich zu den gültigen Datenpaketen auch „Ruhelagepakete“ einzufügen. Jedes gültige, auszuwertende Datenpaket wird mit einem Validflag versehen, alle anderen können vom Empfänger ignoriert werden. (1 = gültig)

Protokollaufbau:

Dargestellt wird hier die Bitanordnung für einen 21-Bit Channellink. Jedes Datenpaket besteht aus 21 Bit. Davon sind 16 Bit Nutzdaten und 5 Bit Overhead. Der Overhead wird für jedes zu übertragende Datenpaket neu generiert.

Bit 0 bis 15: Nutzdatenbereich Bit 16: l/Q Flag

Bit 17: nicht benutzt

Bit 18: Low/High Select

Bit 19: Timeslotflag

Bit 20: Validflag

Nutzdatenbereich: zu übertragende Nutzdaten l/Q Flag: Dieses Flag wird dazu verwendet, um dem Datensatz eine Flag wird auf der Empfängerseite dazu verwendet, die empfangenen Pakete zuzuordnen (0 = I, 1 = Q)

Low/High Select: Dieses Bit zeigt an, ob das Paket die niederwertigen 16 Bit (Low-word) oder die höherwertigen 16 Bit (High-word) enthält (0 = low) 27 AT 501 645 B1

Timeslotflag: Dieses Flag wird dazu benutzt, um das erste Datenpaket(Symbol) eines

Frames zu markieren (1 = Beginn)

Validflag: kennzeichnet ein gültiges Datenpaket

In jedem Empfängerboard bzw. im FPGA dieses Boards sind 4 LVDS Schnittstellen (Receiver) implementiert. Ein LVDS Receiver erhält nun 64 Bit Datensätze (Symbole) von einem Sendeboard, welche die Empfangsdaten einer Empfangsantenne repräsentieren. Aufgrund unterschiedlicher LVDS-Leitungen sowie asynchronem Senden der Daten sind die einzelnen LVDS-Signale um bis zu 1 Symbollänge zueinander zeitlich versetzt.

Damit die Algorithmen der MIMO-Entwicklungsplattform korrekt ablaufen können, müssen die Daten der einzelnen LVDS - Receiver für jeden Timeslot synchronisiert werden. Dies erfolgt über das Timeslotflag und das Validflag des LVDS-Datenstrom.

Die Empfangsdaten jedes LVDS-Receivers werden in jeweils einem Register für die Synchronisierung zwischengespeichert, anschließend werden sie von der erfindungsgemäßen Steuerung in ein DPRAM geschrieben und stehen synchron zur Verarbeitung zur Verfügung. Zusätzlich steht noch das Register Path select zur Verfügung, in das für jeden Timeslot eingetragen wird, welche Sendeboards aktiv sind. Sobald ein Timeslotflag eines Sendeboards erkannt wird, wird das jeweilige Bit im 4-Bit Path-Select-Register gesetzt. Zusätzlich wird ein Zähler auf den Startwert gesetzt. Mit dem ersten (und jedem weiteren) ankommenden Validflag wird der Zählerwert um 1 verkleinert und ab diesem Zeitpunkt werden die Daten synchron von den 4 Registern in das DPRAM geschrieben.

Der Ausfall eines Sendeboards sowie das mehrmalige Senden durch ein Boards werden mit dem nächsten Timeslotflag erkannt. 7.4. uClinux on System Konfiguration

Bei der Arbeit mit dem Kanalsimulator, besonders in der Entwicklungsphase, muss das verwendete uClinux sehr oft umkonfiguriert und neu kompiliert werden. Das uClinux-lmage wird in einen Flash-Speicher in komprimierter Form gespeichert und wird beim Drücken der Reset-Taste des RTS-DSP - Boards vom ebenfalls im Flash-Speicher gespeicherten Bootloader in den SDRAM-Speicher dekomprimiert und anschließend gestartet. Es ergeben sich beim Verändern und auch Neuerstellen des Images folgende Arbeitsschritte, die leider einen großen Arbeitsaufwand mit sich ziehen: • Löschen der vorhergehenden Konfiguration, der Objektdateien, der exekutierbaren Dateien sowie des uClinux-lmages (*.bin und *.zip) -*· make clean • Veränderung der Konfiguration (Kernel, Dateisystem, Start-Skripten und User-Programme) —► make xconfig • Kompilieren des Images (beinhaltet das Kompilieren des Kernels, der einzelnen User-Programme und das Zusammenfügen der einzelnen binären Dateien) —> make dep, make • Download des Images auf das RTS-DSP Board mittels TFTP direkt ins SDRAM oder per BDM-Interface in den Flash-Speicher (hier ist es wieder vom Bootloader abhängig welche Art des downloads gewählt werden muß) -» BDM Linux Flasher oder dBug TFTP download • Reset des RTS-DSP - Boards oder go-Befehl im dBug Monitorprogramm

Das Löschen der vorhergehenden Konfiguration des uClinux-lmages am Entwicklungssystem erfolgt mit dem make clean Befehl. Dieser führt ein Skript aus welches alle relevanten Verzeichnisse besucht und in diesen die bei der letzten Konfiguration und dem Kompiliervorgang erstellten Objektdateien, exekutierbare Dateien und Overheaddateien löscht. Davon sind auch die Verzeichnisse des ROMFS und der Imagedateien betroffen. Falls Veränderungen an unüblichen Stellen im Sourcenverzeichnis durchgeführt wurden, müssen diese dementsprechend händisch nachbearbeitet oder gelöscht werden. 28 AT 501 645 B1

Mit dem make xconfig Befehl wird ein sehr benutzerfreundliches Tool zur Konfiguration des Kernels und der Benutzerprogramme also des ROMFS aufgerufen. Hier wird unter anderem auch der Prozessor und die Architektur ausgewählt und zum Teil konfiguriert. Kemelmodule wie beispielsweise Dateisysteme, Schnittstellen und Treiber werden auch an dieser Stelle konfiguriert. Nachteilig erweisen sich Konfigurationen und Veränderungen des Sourcecodes eines bestimmten Programms, diese müssen im jeweiligen speziellen Verzeichnis erfolgen. Hier gilt es auch keine Veränderungen zu machen, wenn nicht eine Sicherheit in Sachen Kompilierbar-keit und Richtigkeit gegeben ist.

Beim Kompilieren wird von jedem in der Konfiguration ausgewählten Modul das Sourceverzeichnis herangezogen und in diesem der jeweilige make-Befehl ausgeführt. Danach entstehen in diesem die exekutierbaren Dateien, wobei User-Programme im ROMFS ins bin-Verzeichnis kopiert werden und Kernelkomponenten als ganzes binäres Kernelimage vorhanden sind. Alle Sourcen (Kernelkomponenten und User-Programme) werden natürlich mit dem Compiler des Zielsystems (z.B. m68k) am Entwicklungssystem (z.B. Linux PC / i386) kompiliert. Danach wird aus dem am Entwicklungssystem liegenden ROMFS (meistens ein Verzeichnis mit allen am Zielsystem benötigten Dateien, Skripten und Verzeichnissen) ein binäres ROMFS-Image erstellt. Dieses ROMFS-Image wird anschließend mit dem Kernel-Image zusammengehängt und die daraus resultierende binäre Datei ins zip-Format konvertiert.

In der Entwicklungsphase des uClinux-lmages sollte das dBug-Monitorprogramm als Bootloader verwendet werden. Nach dem Reset muß zwar manuell der dn (Image per TFTP ins SDRAM downloaden) und go (Image ab SDRAM-Adresse 0x20000 starten) - Befehl eingegeben werden, aber der Zeitaufwand und die Fehleranfälligkeit sinken erheblich. Das Image ist danach auf dem Zielsystem vorhanden und es kann mit diesem gearbeitet werden, aber nach einem Reset nicht mehr vorhanden. Auch etliche Veränderungen der Skripten oder durchgeführte manuelle Starts von Programmen müssen nach einem erneuten Download gemacht werden. Um dies zu vermeiden kann der COLILO Bootloader installiert werden. Dieser dekomprimiert nach einem Reset das im Flash-Speicher programmierte uClinux-lmage in den SDRAM-Speicher und startet es anschließend automatisch. Dabei muss vorher das uClinux-lmage in den Flash-Speicher mittels BDM (Background Debug Mode) - Kabel programmiert werden. Bei dieser Methode ist zwar der wieder auftretende Download des Images vom Entwicklungssystem nicht notwendig (da das Image lokal auf dem Zielsystem vorliegt), die Problematik des flüchtigen Speichers und der verlorengehenden Änderungen der Skripten und Programme wird allerdings nicht gelöst. Die Methode mit COLILO ist für uClinux-lmageentwicklung eher unpraktisch, da auch jedes neue Image wie oben erwähnt mittels BDM-Kabel und lokaler Verbindung zum Zielsystem in den Flash-Speicher programmiert werden muss.

Um diese Problematik zu lösen, mussten Prozesse entwickelt werden, um dem User-Programm und uClinux-lmage Entwickler entgegen zu kommen.

Im Folgenden wird die Standardvorgangsweise bei der uClinux-lmage und User-Programm-Entwicklung dargestellt (Abb. 46).

Wie oben beschrieben wird für jede Änderung das Entwicklungssystem herangezogen und auf diesem die jeweiligen Änderungen vorgenommen und anschließend das uCLinux-lmage erstellt. Danach muss es auf das Zielsystem übertragen werden um es Testen zu können.

Entwickelter Prozess:

Um den eben beschriebenen Arbeitsablauf zu vereinfachen und somit den Entwicklungsvorgang zu beschleunigen, wurde ein neuartiger Prozess zur Erstellung des Image entwickelt. Bei diesem Prozess bestand die Anforderung, so viele Komponenten (Komprimierungstools, Flas-her und Generatoren) wie nur möglich vom Entwicklungssystem auf das Zielsystem zu verlegen, damit eine größere Unabhängigkeit des Zielsystems realisiert wird. Dies konnte nur durch 29 AT 501 645 B1 eine Kompilation auch der Entwicklungswerkzeuge für das Zielsystem erreicht werden. Im Folgenden werden die einzelnen Anforderungen an das Zielsystem, sowie benötigte Komponenten um eine benutzerfreundliche Kanalsimulation ermöglichen zu können, vorgestellt. Anforderungen an das Zielsystem: - Es soll eine umfangreiche und leistungsfähige uClinux-lmage Version installiert sein - Dieses Image soll nach einem Reset automatisch booten - Es sollen Initialisierungsskripte / Bootskripte veränderbar sein - Diese Skripte sollen auch nach einem erneuten Reset wieder vorhanden sein - Ein eventueller Image Update soll auch ohne BDM-Kabel erfolgen können

Voraussetzungen für eine automatische Konfiguration - Partitionierung des Flash-Speichers - Skriptanpassungstool (z.B. Texteditor am Zielsystem) - ROMFS Generator - In-System-Flasher

Um bestimmte Teile des Systems zu konfigurieren oder zu sichern, müssen diese auch vom System getrennt veränderbar sein. Wenn der gesamte Flash-Speicher betrachtet wird, dann besteht dieser aus nur einer einzigen Partition. In dieser Partition befindet sich der Bootloader an der Adresse 0x0, dieser ist mit dem Kernel-Image ab Adresse 0x40000 und dieser wiederum mit dem ROMFS verbunden (Adresse 0x40000 + Kernel-Image Länge). Um ein neues Image in den Flash-Speicher zu programmieren, müssen alle Komponenten als erstens am Entwicklungssystem zusammengehängt und zweitens als Ganzes programmiert werden. Um diesem Problem entgegenzuwirken wird der Flash-Speicher in mehrere Partitionen aufgeteilt (Abb. 47).

Die Bootloader Partition beinhaltet weiterhin den COLILO-Bootloader. Dieser dekomprimiert nach einem Reset der Kernel und ROMFS Image aus der zweiten Partition in den SDRAM -Speicher und startet dieses anschließend.

Die Kernel-Image und ROMFS Partition beinhaltet ein minimales am Entwicklungssystem erstelltes uClinux-lmage und auch Initialisierungs und Bootroutinen die das System mit minimaler Performance startet. Am Ende dieser Skripte wird die letzte Partition gemountet (User-Flash Partition) und in dieser vom User veränderbare Skripte aufgerufen.

Die User-Flash Partition ist die eigentliche Erneuerung am ganzen System. Diese beinhaltet die oben erwähnten Skripte (können auch Programme sein) welche jedoch im Flash direkt nicht verändert oder ausgeführt werden können. Diese werden vom Minimalsystem beim Booten gemountet (eingebunden) und in den SDRAM Speicher (RAMFS, ext2 Dateisystem, RW) kopiert, wo sie vom User verändert und ausgeführt werden können. Diese Änderungen, besonders die Initialisierungsskripte und Bootskripte, sind zwar im System vorhanden und können verwendet werden, würden aber nach einem Reset wieder verloren gehen. Dazu musste ein Prozess entwickelt werden um diese auch zu sichern.

Prozess zur Sicherung und In-System-Konfiguration

Die Idee dahinter bestand darin das genromfs-Tool (generiert aus einem Verzeichnis und den darin liegenden Dateien ein ROMFS-Image), welches zur ROMFS-Generierung am Entwicklungssystem verwendet wird, auf das Zielsystem zu portieren. Damit wird es möglich, aus Verzeichnissen am Zielsystem ein ROMFS zu generieren, um es auch in den Flash-Speicher zu programmieren und lesend einzubinden.

Die am Zielsystem und im RAMFS Verzeichnis veränderten und erstellten Dateien (können auch eine Kopie des vorhergehenden User-Flash Inhalts sein), werden mit dem genromfs-Tool 30 AT 501 645 B1 zu einem ROMFS-Image generiert. Dazu musste auch ein minimaler Texteditor für das Zielsystem portiert werden. Dieses ROMFS-Image wird anschließend auch am Zielsystem mit dem Flash-Speicher Programmierprogramm (flashw) in die User-Flash Partition programmiert (Abb. 48).

Dies ist eher eine Sicherung, da die Verwendung sowieso erst nach einem Reboot oder un-mounten (Verbindung lösen) und erneutem Mounten des ROMFS-Dateisystems (besteht im Flash-Speicher nach der Programmierung) erfolgen kann. Somit ist es beispielsweise für einen User-Programm Entwickler sehr komfortabel nur das entwickelte Programm vom Entwicklungssystem per FTP, NFS oder TFTP über das Netzwerk runter zu laden, anschließend zu testen und im Flash-Speicher zu sichern. Unterschiedliche Übergabeparameter und automatischer Start können auch in Skripten eingetragen werden und vom Zielsystem unabhängig verändert werden umkonfiguriert. Für die Verwendung im Kanalsimulator wird eigentlich nur mehr das Netzwerk verwendet, da über telnet eine Verbindung zum RTS-DSP-Board aufgebaut werden kann, die benötigte Veränderung (meistens Parameter der Kommunikationsprogramme) des gespiegelten Flash-Speichers gemacht werden kann und das Bootskript zum automatischen Aufruf nach dem Reset angepasst wird. Danach wird wiederum über telnet das ROMFS-Image generiert und in den Flash-Speicher programmiert. Grundsätzlich ist die Programmierung jeder Partition des Flash-Speichers möglich, wodurch auch ein Update des uClinux-lmages unabhängig vom Entwicklungssystem erfolgen kann. Dazu wird nur vom PC der Kanalsimulator GUI eine telnet Verbindung zum Zielsystem aufgebaut, ein Netzwerk-Verzeichnis (z.B. NFS-Server am PC), mit dem neuen uClinux-lmage, eingebunden und dieses Image, in die entsprechende Flash-Speicher Partition, vom Zielsystem programmiert. 8. Weitere Verwendungsmöglichkeiten der Entwicklungsplattform 8.1. Entwicklungsplattform als Channel Sounder

Neben der Verwendung als Entwicklungsplattform und als Kanalsimulator kann der, der Patentanmeldung zugrunde liegende, Erfindungsgegenstand auch als Channel Sounder eingesetzt werden. Dabei handelt es sich um ein Messgerät zur Bestimmung der Übertragungscharakteristik eines realen Funkkanals.

Zur Messung sendet eine Sendeantenne ein kurzes Signal mit bekannter Form (Amplitudenverlauf, Phasenlage) aus, das von einer Messantenne an einem anderen Ort empfangen wird. Das Empfangssignal wird digitalisiert und kann zur weiteren Analyse verwendet werden. Für diese Kanalmessungen eignet sich der Erfindungsgegenstand auf vorzügliche Weise. Die Generierung des Sendesignals, der Empfang, die A/D-Wandlung und die Speicherung der Empfangsdaten lassen sich mit der Erfindung realisieren. Zur Speicherung liest der FPGA die Daten ein und leitet sie zum Speicher des DSP weiter. Nach Beendigung des Messvorgangs können die Daten verarbeitet werden oder an einen PC zur Verarbeitung weitergeleitet werden.

Ein besonderer Vorzug ergibt sich, wenn man die Signale mehrerer gegeneinander versetzter Messantennen mit mehreren Boards parallel erfasst. Dadurch erhält man unter exakt identischen Randbedingungen ein räumliches und zeitliches Abbild der Signalverteilung. 8.2. Vorverarbeitung und Speicherung quantenkryptographischer Detektorsignale

Die Signalverarbeitungsboards des Erfindungsgegenstandes können eingesetzt werden, um Detektorsignale eines Quantenkryptographischen Systems auszuwerten, abzuspeichern und weiterzureichen. Die Detektoren, welche Quanten mit unterschiedlichen Polarisationen detektie-ren, weisen den Nachteil einer hohen Fehlerrate auf. Das bedeutet, sobald ein Detektor auslöst, 31 AT 501 645 B1 lösen die anderen nach kurzer Zeit auch aus.

Um zu erkennen ob der Detektor durch die Detektion eines Lichtquants oder durch einen Fehler ausgelöst wurde, muss in einer sehr feinen Auflösung erkannt werden welcher Detektor zu welchem Zeitpunkt ausgelöst hat und wie diese Auslöseflanken zu einander stehen. Aus diesem Grund benötigt man zur Auswertung eine äußerst schnelle Logik, wie sie durch den Erfindungsgegenstand realisiert wird.

Tritt ein Detektionsereignis auf, wird dieses mithilfe einer zeitlichen Fensterfunktion bewertet. Die zeitliche Lage des Fensters wird dem System über einen separaten konventionellen optischen Kanal (Synchronisationskanal) mitgeteilt. Falls die steigende Flanke des Signals innerhalb des Fensters liegt, wird das Signal als Aktivierung abgespeichert. Falls es außerhalb des zeitlichen Fensters liegt, wird als fehlerhafte Auslösung erkannt.

Um eine möglichst feine Einstellung für dieses Fenster zu erreichen, kann die Breite und das Delay dieses Fensters in Schritten von 1,25 ns eingestellt werden. Diese genaue Auflösung erreicht man, indem man die positive und die negative Flanke des Takts für die Fenstererzeugung verwendet. Zusätzlich wird auch noch das zeitgleiche Auftreten mehrerer Detektionsereignisse innerhalb eines Fensters überprüft, und das Ergebnis abgespeichert.

Ein weiterer wichtiger Parameter der Detektionslogik ist die Anzahl der einzelnen Detektionssignale innerhalb eines definierten Intervalls. Dazu verwendet man einen Zähler, der die Signalflanken der einzelnen Detektorsignale erkennt, zählt und nach Ablauf eines einstellbaren Zeitintervalls wieder auf Null gesetzt wird.

Sobald ein Ereignis auf einem Detektor auftritt, wird das Signal zum FPGA geführt und in weiterer Folge ausgewertet und gespeichert. Dazu wird es an den DSP weitergeleitet, der diese Aufgaben durchführt. Mittels der Schnittstelle zwischen DSP und CPU können die Informationen über einen Ethernet Link an eine GUI übertragen werden (Abb. 49). 8.3. Entwicklungsplattform als skalierbares Testsystem

Eine weitere, über den eigentlichen Zweck hinausgehende Verwendungsmöglichkeit für den der Patentanmeldung zugrunde liegende Erfindungsgegenstand liegt in dem Bereitstellen einer Vielzahl beliebig formbarer Testsignale an den LVDS-Buchsen. Dadurch wird ein universelles, skalierbares, modulares Testsystem verwirklicht, mit dem das Testen von Systemen möglich ist, welche eine große Zahl von Testsignalen mit unterschiedlichen Protokollen benötigen.

So könnten Testsignale generiert werden, welche im realen Betrieb nur selten auftreten, und so könnte z.B. ein „worsed case“-Szenario nachgestellt werden. Mithilfe der graphischen Bildschirmoberfläche und über die geräteinterne Synchronisation (CLK-START, LOCK und TRIG-Signale) könnten so synchronisierte Testsignale zur Verfügung gestellt werden.

Jedes Signalverarbeitungsboard besitzt insgesamt 78 verwendbare Testpins, welche direkt mit dem auf den Platinen vorhandenen FPGA verbunden sind. Mit diesem FPGA ist es nun einerseits möglich, beliebige Signalfolgen bzw. Protokolle zu generieren, andererseits können aufgrund der parallelen Verarbeitung im FPGA auch die Testsignale parallel ausgegeben werden.

Die Modularität des erfindungsgemäßen Testsystems kann durch das Zusammenschalten mehrerer Racks zu einem noch größeren synchronen Testsystem auf größere Einheiten als 1 Board erweitert werden.

Pro Rack sind maximal 8 synchronisierte I/O-Boards vorhanden, wodurch 624 Testsignale möglich sind. Bei der maximalen Rackanzahl von 8 können somit 4992 Testsignale generiert werden. 32 AT 501 645 B1

Zur Steuerung des Testsystems kann mit jedem Board über folgende zusätzliche Schnittstellen kommuniziert werden:

• 2UARTS • 1 x USB 1.1 • 1 x 100MBit FastEthernet Mögliche Testszenarien Gebäudeüberwachungssystem-Tester

In modernen Gebäuden befindet sich eine Vielzahl an Sensoren (z.B. für die Klimatisierung, Bewegungsmeldern, Rauchmelder...). In einem Katastrophenfall oder anderen außergewöhnlichen Ereignissen müssen sehr viele Signale gleichzeitig und richtig verarbeitet werden. Um neben einzelnen Sensoren auch das Zusammenspiel aller testen zu können, bietet sich der Einsatz dieses skalierbaren Testsystems an, mit dem „worst case“-Szenarien simuliert werden können.

Testsystem für Autoboardcomputer

Moderne Autos sind voll gepackt mit Elektronik und Überwachungssystemen.

Es gibt einerseits sicherheitskritische Signale, welche zum ESP-, ABS-, Brems-, Airbag- oder Motorsteuerungssystem gehören, andererseits Signale, welche von der Klimaanlage oder von der Audiosteuerung generiert werden.

Das hier dargestellte skalierbare Testsystem ist in der Lage, die Signale der Messwertaufnehmer zu ersetzen. Somit ist es einfach möglich, verschiedenste Szenarien und Betriebszustände, die während eines Fährbetriebs auftreten, zu simulieren.

Besonderheiten des erfindungsgemäßen Testsystems

Steuerung über Ethernet

Das Laden der I/O-Daten und das Steuern des Testsystems passiert über die FastEthernet-Interfaces jedes Boards. Die GUI steuert über diese Verbindungen das Testsystem.

Hohe I/O Anzahl

Bis zu 624 synchronisierte I/O-Signale pro Testsystem-Rack.

Maximal 4992 frei über die GUI konfigurierbare digitale Testsignale bei 8 Racks.

Viele Fast Ethernet und Serielle Verbindungen nach außen.

Erweiterung von asynchronen I/Os

Durch die zusätzlichen 2 x 76 I/O Signale zweier erweiterter Boards in einem Rack ist es möglich, diese I/O Signale dort zu verwenden, wo keine Synchronisation mit den restlichen 624 Signalen des Testsystems benötigt wird. Somit kann ein Rack bis auf maximal 776 Testsignale ausgebaut werden wobei 624 synchron arbeiten, 152 asynchron (Abb. 50). 8.4. Bildverarbeitung:

Das RTS-DSP Board kann auch zur Bildverarbeitung genutzt werden. Diese Eigenschaft ist durch die zwei an der Frontplatte ausgeführten 26-poligen Buchsen gegeben. Diese sind als 33 AT 501 645 B1 LVDS Anbindung an das Board als ein Camera Link konfigurierbar. Dadurch können entweder Kamera Module mit einem Camera Link Ausgang, bzw. das RTS-DSP-Board als Videogenerator verwendet werden. Im ersten Fall funktioniert das RTS-DSP-Board als ein Frame-Grabber und kann auch weitere Algorithmen zwecks Bildverarbeitung im FPGA und im DSP beinhalten. Relevante Informationen können dann per Ethernet an einen Computer oder auch weitere RTS-DSP-Boards weitergereicht werden. Im zweiten Fall können Generator Konfigurationsdaten an das RTS-DSP-Board per Ethernet von einem PC aus übertragen werden, auf dem Board dann die auszugebenden Signale im DSP oder FPGA berechnet werden und über den Camera Link entweder an weitere Boards oder externen Frame Grabber ausgegeben werden (Abb. 51, 52).

In Abbildung 53 ist erkennbar, dass eine sehr große Rechenleistung mittels der RTS-DSP-Boards zusammengeschaltet werden kann und die Information per Weiterschleifen über die doppelt ausgeführten Camera Links weitergereicht bzw. Ergebnisse ausgegeben werden können. Konfiguration und Evaluation kann natürlich über Fast Ethernet von einem zentralen PC oder eben unter den einzelnen Boards erfolgen. 8.5. Number Cruncher / Distributed Computing

Durch die geballte Rechenleistung der Hardware bietet es sich an, rechenintensive Aufgaben, insbesondere aus dem Feld der numerischen Simulation, auf diese Plattform auszulagern. Insbesondere lassen sich aus verschiedenen kommerziellen Programmpaketen zur numerischen Berechnung am PC (wie etwa Matlab/Simulink von The MathWorks) automatisch Programme in üblichen Programmiersprachen (wie etwa C) erstellen, mit geeigneten Compilern (für den Texas Instruments TMS320C6416 etwa Code Composer Studio) daraus ausführbare Programme erstellen.

Diese Programme können dann mit über ein geeignetes Übertragungsmedium (etwa Ethernet oder JTAG) auf das Board überspielt werden. Soweit das eingesetzte Protokoll nicht vollständig in Hardware unterstützt wird (wie etwa JTAG), sondern höhere Verarbeitungsschritte benötigt (etwa Ethernet) wird dazu ein vorab im Flash-Speicher des RTS-DSP Boards abgelegtes Boot-Programm verwendet, das diese höheren Protokollschichten abarbeitet. Es soll dabei insbesondere auf die Möglichkeit hingewiesen werden, dass dieses Programm neben der Abarbeitung des Protokolls zusätzliche Rechenoperationen bietet. Insbesondere ist es möglich das zuletzt generierte Paket aus der PC Umgebung mit der Möglichkeit der Protokollabarbeitung zu kombinieren und so wahlweise Rechenaufgaben zu erledigen oder das System für neue Rechenaufgaben vorzubereiten.

Alle oben genannten Schritte lassen sich dabei bequem durch Skripte steuern, so dass für den Benutzer der ausgelagerten Rechenleistung keine zusätzlichen Arbeiten anfallen, sondern die Aufgaben in der gewohnten PC Umgebung erstellt werden und die Resultate wieder auf in PC Umgebung präsentiert werden. Die Tatsache, dass zwischendurch nicht der PC, sondern das RTS-DSP Board gerechnet hat, ist für den Benutzer nur an der Geschwindigkeitssteigerung feststellbar.

Natürlich ist auch die Rechenleistung eines RTS-DSP Boards begrenzt. Es besteht daher auch die Option mehrere Boards gleichzeitig mit Rechenaufgaben zu beschicken. Sofern sich das Problem gut in parallele Teilprobleme zerlegen lässt besteht die Möglichkeit jedem Board ein oder mehrere solcher Teilprobleme zuzuweisen und dann alle Boards parallel rechnen zu lassen. Ist das Problem nicht so gut zerlegbar, bietet sich dennoch oft die Möglichkeit es in verschiedene Stufen zu gliedern, und nach dem Vorliegen der ersten Teilergebnisse der ersten Stufe bereits mit der Berechnung der zweiter (und in Folge weiterer) Stufe(n) zu beginnen, ehe die erste Stufe abgeschlossen ist. In beiden Fällen wird effizient Parallelverarbeitung betrieben und die Rechenleistung des Gesamtsystems gegenüber einem einzelnen RTS-DSP Board gesteigert.

Claims (36)

1. 34 AT 501 645 B1 Patentansprüche: 1. Kanalsimulations- sowie Entwicklungsplattform zur Simulation zumindest eines Übertragungskanals zwischen Sendesignale ausstrahlenden Sendern und Empfängern eines digitalen oder analogen Funkübertragungssystems, bzw. zur Verwendung als Entwicklungsplattform für die Entwicklung von Software-basierenden flexiblen Funkübertragungssystemen, im folgenden auch als Software Defined Radio bezeichnet, umfassend: Eingangseinheiten zum Empfang von Sendesignalen repräsentierenden Eingangssignalen, wobei die Eingangssignale ein oder mehrere digitale(s) oder analoge(s) Hochfrequenzsig-nal(e), digitale(s) oder analogen Basisband- oder Zwischenfrequenzbandsignal(e), Audio-und/oder Videosignal(e) umfassen, Konvertierungseinheiten zum Konvertieren der Eingangssignale vom Audio- / Video-Bereich in den analogen bzw. digitalen Basisband-Bereich bzw. in umgekehrter Richtung, weiters vom analogen in den digitalen Basisband-Bereich bzw. in umgekehrter Richtung, und weiters vom analogen bzw. digitalen Basisband- in den Hochfrequenz-Bereich bzw. in umgekehrter Richtung, Steuerungseinheiten zur Bereitstellung zumindest eines durch sich im Verlauf der Simulationsberechnungen ändernden Kanalparameter definierten geometrischen Kanalmodells zur Beschreibung von Signalformungseigenschaften des zumindest einen Übertragungskanals, Signalverarbeitungseinheiten, z.B. FPGA, DSP, zur Erzeugung zumindest eines Ausgangssignals durch Formung des Eingangssignals gemäß den Signalformungseigenschaften des Kanalmodells, welche Signalverarbeitungseinheiten zur mathematischen Abbildung des Kanalmodells als geometrisches Modell mit einer Vielzahl von Streuobjekten bzw. Scatterer und zur Formung des Ausgangssignals durch Echtzeit-Berechnung des Ausbreitungsverlaufs von Mehrwegkomponenten des Eingangssignals ausgebildet sind, welche Mehrwegkomponenten durch Streuung, Reflexion und Beugung des Eingangssignals an den Streuobjekten des geometrischen Modells hervorgerufen werden, Ausgabeeinheiten zur Ausgabe des zumindest einen Ausgangssignals, dadurch gekennzeichnet, - dass zur Simulation zumindest eines Übertragungskanals eines Multikanal-Funkübertragungssystems bzw. zur Entwicklung eines Multikanal- Software Defined Radio, das von den Signalverarbeitungseinheiten abgebildete geometrische Modell ein geometriebasierendes stochastisches Kanalmodell ist, - dass die Signalverarbeitungseinheit zur mathematischen Abbildung eines MIMO-tauglichen, geometrischen, stochastischen Kanalmodells ausgebildet sind, welches Kanalmodell eine Echtzeit-Berechnung des Ausbreitungsverlaufs mehrerer Kanäle eines Multikanal-Funkübertragungssystems sowie deren Mehrwegkomponenten zulässt, - dass mehrere Signalverarbeitungseinheiten bzw. Boards vorgesehen wird, unter denen die Berechnungen aufgeteilt sind, - dass jeweils eine Signalverarbeitungseinheit zur Simulation von vorzugsweise einem Kanal herangezogen wird und die Teilergebnisse aller Signalverarbeitungseinheiten addiert werden, - dass das Teilergebnis einer Signalverarbeitungseinheit in der jeweils benachbarten Signalverarbeitungseinheit zu dem dortigen Teilergebnis addiert wird, somit eine stufenweise Addition erfolgt und das Gesamtergebnis schließlich in der letzten Signalverarbeitungseinheit vorliegt, - dass die Verbindung zwischen den boards als eine von einem board zu einem benachbarten board geführte, fix verdrahtete daisy-chain LVDS-Leitung und über eine insbesondere über Steckverbindungen an der backplane, flexibel mit beliebigen anderen boards verbindbare LVDS-Leitung erfolgt und - dass die dritte LVDS-Leitung als A/O-Anschluss für das jeweilige board vorgesehen ist.
2. 2. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 1, dadurch gekennzeichnet, dass das von den Signalverarbeitungseinheiten abgebildete geometrische Modell zur Berücksichtigung von Mehrfachreflexionen (Double Scattering) ausgebildet ist. 35 AT 501 645 B1
3. 3. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 2, dadurch gekennzeichnet, dass das geometriebasierte stochastische Kanalmodell Streuobjekten in der Umgebung der Basisstation bzw. near base Station cluster berücksichtigt.
4. 4. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass das geometriebasierte stochastische Kanalmodell als dreidimensionales Modell ausgebildet ist, wobei die dritte Dimension durch die Elevation beschrieben wird, bei der es sich um den Winkel zwischen der z-Achse und der Ursprungsgeraden durch den gewünschten Punkt handelt.
5. 5. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 4, dadurch gekennzeichnet, dass die dritte räumliche Dimension lediglich beim Platzieren von Streuobjekten bzw. Scat-terer und Antennen berücksichtigt wird.
6. 6. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass Cluster, das sind Streuobjekte in Form von Gruppen, innerhalb derer sich Scatterer befinden, die Form eines Zylinders aufweisen.
7. 7. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 6, dadurch gekennzeichnet, dass die Höhe der Zylinders konstant und vom Benutzer einstellbar ist.
8. 8. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 6, dadurch gekennzeichnet, dass die Höhe der Zylinders mithilfe eines Zufallsprozesses für den angular spread der E-levation, das ist die Streuung der Winkelwerte, bestimmt wird.
9. 9. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche 2 bis 8, dadurch gekennzeichnet, dass das geometriebasierte stochastische Kanalmodell den Einfluss der Polarisation des Sendesignals sowie der Scatterer berücksichtigt.
10. 10. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 9, dadurch gekennzeichnet, dass den Scatterern konstante zufällige Polarisationswerte zugewiesen werden.
11. 11. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 9, dadurch gekennzeichnet, dass bei der Generierung von neuen Scatterern diesen neue zufällige Polarisationswerte zugewiesen werden.
12. 12. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 9, dadurch gekennzeichnet, dass zur Vereinfachung der Berechnung die Polarisationsfaktoren mit den Antennengewinnen zu einem Faktor kombiniert werden.
13. 13. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Antennengewinne für Near Mobile Scatterer im Small Scale Update aus Tabellen ermittelt werden, wobei die Winkelberechnungen zum Teil linear oder quadratisch interpoliert werden.
14. 14. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Dämpfungsfaktoren der einzelnen Ausbreitungspfade nach Formeln berechnet werden, welche sowohl Single Scattering Pfade als auch Double Scattering Pfade berücksichtigen, wobei eine Gewichtung des Double Scattering gegenüber dem Single Scattering vorgenommen wird und die Anzahl der Double Scattering Pfade auf einen Maximalwert begrenzt wird.
15. 15. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Berechnung von Weglängen durch eine quadratische Interpolation erfolgt. 36 AT 501 645 B1
16. 16. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass Scatterer-Clusters in Kreisringe unterteilt werden, wodurch eine Vereinfachung zur Durchführung der Jacobian Transformation getroffen wird, die zur Kompensation der durch die näherungsweise festgelegte Verteilung der Scatterer entstehende Ungenauigkeiten durchgeführt wird, wobei die Jacobian-Transformation den Zusammenhang zwischen der Position eines Scatterer und seiner Dämpfung beschreibt.
17. 17. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 16, dadurch gekennzeichnet, dass alle Scatterer innerhalb eines Ringes gleiche Area Werte aufweisen.
18. 18. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 16, dadurch gekennzeichnet, dass die Werte innerhalb eines Kreisrings linear interpoliert werden.
19. 19. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 16, dadurch gekennzeichnet, dass eine lineare Interpolation vom äußersten zum innersten Kreisring vorgenommen wird.
20. 20. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 16, dadurch gekennzeichnet, dass eine quadratische Interpolation vom äußersten zum innersten Kreisring vorgenommen wird.
21. 21. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Wechsel von einem Scatterer zu einem neuen nicht sprunghaft erfolgt, sondern in Form eines kontinuierlichen Ausfadens, wobei der Scatterer aus dem Cluster fällt, und Einfaden, wobei ein neuer Scatterer in den Cluster kommt, erfolgt.
22. 22. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 21, dadurch gekennzeichnet, dass die Pfade sequentiell aus- und danach einfaden.
23. 23. Kanalsimulations- sowie Entwicklungsplattform nach einem der Ansprüche 1 bis 22, dadurch gekennzeichnet, dass das Weiterreichen der Teilergebnisse sowie sonstiger Datenaustausch über eine Backplane erfolgt, welche über ein Stecksystem mit den einzelnen Boards verbunden ist.
24. 24. Kanalsimulations- sowie Entwicklungsplattform nach Anspruch 23, dadurch gekennzeichnet, dass das Stecksystem das direkte Ineinander-Stecken der Boards in die Backplane ermöglicht, so dass sich für alle gleichen Leitungen gleiche Längen ergeben.
25. 25. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche 1 bis 24, dadurch gekennzeichnet, dass der Datenaustausch mittels LVDS-Protokoll erfolgt.
26. 26. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Plattform zur Simulation unterschiedlicher MIMO-Konfigurationen ausgebildet ist, welche MIMO-Konfigurationen zum Beispiel die Anordnungen SIMO 1-8, ΜΙΜΟ 2-4, ΜΙΜΟ 4-2, MISO 8-1 umfassen.
27. 27. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Entwicklungsplattform einen Empfänger zum Empfang von GSM- bzw. UMTS-Signalen im digitalen Basisbandformat, bzw. über Konvertierungsmittel auch im HF-Band, aufweist, der mit zumindest einem gleichen Rechenboard realisiert wird, welches auch für die Kanalsimulation eingesetzt wird, wobei der Empfänger zum Empfang von Signalen unterschiedlicher MIMO-Konfigurationen ausgebildet ist. 3 7 AT501645B1
28. 28. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass sie das automatische Erzeugen von zielplattformgerechten bzw. auf standardisierten Simulationstools lauffähigen Programmen auf der Basis eines in höherer Sprache geschriebenen Codes unterstützt, z.B. durch automatisierte Codegenerierung bzw. Rapid Prototyping, sowie das Einbinden des Systems in standardisierte Simulationstools zum Umwandeln von Algorithmen dieser standardisierten Simulationstools in Algorithmen für das Zielsystem unterstützt, welche Algorithmen dann vom Simulationstool aus auf dem Zielsystem ausgeführt werden können.
29. 29. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass ein HistoryRAM vorgesehen ist, in dem die Eingangsdaten zwischengespeichert werden, so dass ein bestimmter in der Vergangenheit liegender Zeitschlitz innerhalb des Datenstroms auswählbar ist, wobei das HistoryRAM vorzugsweise als Ringspeicher mit Double Dual Ported RAMs ausgeführt ist, das sind Dual Ported RAMs, auf deren beiden Ports Lesezugriffe erfolgen und gleichzeitig Schreiben in einen Bereich des RAMs möglich ist.
30. 30. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche 25 bis 29, dadurch gekennzeichnet, dass die einzelnen LVDS-Eingangssignale zueinander synchronisiert werden, wobei die Synchronisation über einzelne Flags des LVDS-Datenstroms, z.B. Timeslotflag und Validflag, erfolgt.
31. 31. Kanalsimulations- sowie Entwicklungsplattform nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass bei der Verwendung des Erfindungsgegenstandes das Betriebssystem bereits am Zielsystem neu konfiguriert werden kann, z.B. mit In-System-Konfiguration, weil viele Komponenten der Entwicklungsumgebung auf das Zielsystem verlagert wurden, insbesondere das genromfs-Tool zur Generierung des ROMFS-Image, wodurch dieses ROMFS-Image im Zielsystem gesichert werden kann.
32. 32. Verwendung der Kanalsimulations- sowie Entwicklungsplattform nach einem der Ansprüche 1 bis 31 als Channel Sounder, das ist ein Messgerät zur Bestimmung der Übertragungscharakteristik eines realen Funkkanals.
33. 33. Verwendung der Kanalsimulations- sowie Entwicklungsplattform nach einem der Ansprüche 1 bis 31 zur Vorverarbeitung und Speicherung quantenkryptographischer Detektorsignale, wobei Zeitfenster mit einer sehr hohen Auflösung realisiert werden können.
34. 34. Verwendung der Kanalsimulations- sowie Entwicklungsplattform nach einem der Ansprüche 1 bis 31 als universelles Testsystem, welches eine beliebige Anzahl von beliebig geformten Testsignalen mit beliebiger zeitlicher Korrelation bereitstellt.
35. 35. Verwendung der Kanalsimulations- sowie Entwicklungsplattform nach einem der Ansprüche 1 bis 31 als Bildverarbeitungssystem, welches Camera Link Signale aufnimmt und auf den einzelnen Rechnerboards weiter verarbeitet, bzw. welches Videosignale auf der Basis von durch das externe Steuerungsmittel bereitgestellten Konfigurationsdaten generiert.
36. 36. Verwendung der Kanalsimulations- sowie Entwicklungsplattform nach einem der Ansprüche 1 bis 31 als Number Cruncher, das ist ein Hochleistungsrechner zur Durchführung rechenintensiver Aufgaben, insbesondere aus dem Feld der numerischen Simulation. Hiezu 33 Blatt Zeichnungen