Law

A distributed multilayer architecture enabling end-user access to MIMO testbeds

Description
We propose a distributed multilayer architecture that provides user access to a MIMO testbed at the convenient abstraction level for researchers. This novel architecture releases the user from the need of low-level programming, making the MIMO
Categories
Published
of 5
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  A Distributed Multilayer ArchitectureEnabling End-User Access to MIMO Testbeds Jos´e A. Garc´ıa-Naya, H´ector J. P´erez-Iglesias, Tiago M. Fern´andez-Caram´es, M. Gonz´alez-L´opez, Luis Castedo Departamento de Electr´onica y Sistemas, Universidade da Coru˜na Campus de Elvi˜na no 5. 15071 A Coru˜na, SPAIN email:  {  jagarcia, hperez, tmfernandez, mgonzalezlopez, luis } @udc.es  Abstract —We propose a distributed multilayer architecturethat provides user access to a MIMO testbed at the convenientabstraction level for researchers. This novel architecture releasesthe user from the need of low-level programming, making theMIMO testbed accessible through high level software (i.e. Matlabor similar). The layers of this architecture are highly decoupledamong them, allowing us to run each layer on a different PC.Also, each layer permits independent extension or customisationas needed, for example to implement new testbed features suchas a feedback channel or to deploy multiuser MIMO scenarios. I. I NTRODUCTION During the last years, MIMO signalling schemes haverevealed themselves as the most promising techniques toincrease transmission capacity [1], [2]. While theory andsimulations typically show the corresponding gains under idealconditions, testbeds are useful to validate these gains in realscenarios and in presence of implementation impairments. Dif-ferent general-purpose MIMO testbeds have been constructedfor testing space-time coding and signal processing techniques[3]–[7]. They all exhibit good technical features and highflexibility capabilities.However, testing MIMO signalling methods over a realsetup involves cumbersome low-level programming to accessthe hardware, making difficult to test new methods [8]. Forthis reason, it is desirable to incorporate an user interface tothe MIMO testbed, that allows researchers to focus exclusivelyon the development of new MIMO techniques, releasing themfrom the task of low-level programming. Our aim is to handleour MIMO testbed at the usual abstraction level employedby reasearchers. Separating signal processing implementationfrom hardware access control and configuration leads to amore efficient exploitation of the hardware testbed. Moreover,to facilitate the task of extensive experimental trials, it is alsodesirable to make the MIMO testbed remotely accessible fromthe user Personal Computer (PC).In this paper we describe how to meet all these goalsthrough a distributed multilayer architecture. Three layersconstitute the proposed architecture: a middleware that in-teracts with the testbed hardware, a signal processing layerthat converts discrete symbol sequences into IF signals atthe transmitter (and vice versa at the receiver), and an userlayer that presents the testbed to the user at a high abstractionlevel. To support a wide range of communication scenariosand user needs, the architecture is designed under the premise Tx PC (Middleware) Rx PC (Middleware) TxProc PC (Signal Processing Layer) RxProc PC (Signal Processing Layer)  Network Remote User PC (User layer + user application) Fig. 1. Platform diagram of minimising dependencies among its layers. This way, eachlayer can be extended or customised to satisfy different re-quirements almost without affecting the others. One of themain advantages of our approach is that each layer runs on adifferent PC and that the intercommunication among layers iscarried out through sockets over standard network links. Thisproperties allow the implementation of new testbed features,as for example a feedback channel or a multiuser MIMOscenario.The rest of the paper is structured as follows. Section IIgives a global description of the different system modules anda brief explanation of the synchronisation, configuration andcontrol mechanisms. Section III details the signal processingand the user layers. Section IV describes the middlewarelayer, from its low-level components, close to the hardware,up to its high-level ones. The testbed hardware componentsare shortly described in Section V. Section VI illustrates thesystem through a new user tool for Alamouti coded MIMOsystems. Finally, Section VII is devoted to the conclusions.II. D ESCRIPTION OF THE SYSTEM Fig. 1 shows the testbed hardware hosted by two ordinaryPCs, one for the transmitter (referred to as Tx PC) andother for the receiver (called Rx PC). Fig. 2 illustrates theblock diagram of the entire system. Three main parts can bedistinguished: the testbed hardware that allows us to transmit 978-1-4244-2644-7/08/$25.00 © 2008 IEEE    Sundance  S M T 3 1   Q   S undance  S MT3 Q SMT37   1 dual DAC 4 MB memory 2 x ADC FPGA Virtex II Middleware – TxDSPPCI BusPCI Bus Tx PC RxPCMiddleware – RxHost Middleware – RxDSP Middleware – TxHostSocket connection RxProcPCTxProc PC Signal Processing Layer – TxProc Signal Processing Layer – RxProc Remote User PC User ApplicationUser Layer Interface Access PointSocket connection Socket connectionSocket connection Socket connection SMT365   DSP@600 MHzFPGA Virtex-II16 MB memorySHB buses SMT365   DSP@600 MHz FPGA Virtex-II 16 MB memory SHB buses SMT35 1 GB FIFO memory for the SHB buses SMT349   MT37 SM T 3 49   IF   RF 1 dual DAC IF   RF 16 MHz BW 4 MB memory 16 MHz BW IF 70 MHz 2 x ADC IF 70 MHz RF 2.45 GHzFPGA Virtex II RF 2.45 GHz Fig. 2. Platform scheme function call discrete symbolsequences   User  Application User Layer TxProcMiddlewareTx Middleware Rx RxProc socket connection discrete symbol sequences socket connection IF signals RF transmission socket connection acquired IF signals socket connection acquired discrete symbol sequences function return acquired discrete symbolsequences Fig. 3. Frame transmission example. discrete-time signals over multiple antennas at 2.4 GHz;the multilayer software architecture that makes the hardwareaccessible to end researchers and; finally, the user applicationimplemented using the testbed capabilities and the architecturefacilities. The lowest software level (i.e. the middleware) isrequired to be installed in the same computers as the testbedhardware, but the other two layers can be installed in any otheravailable PCs. In order to minimise the time the Tx-Rx PCsare busy, the rest of the architecture layers are detached fromthem, allowing that different signal processing layer instancessimultaneously run in different PCs. Finally, the user layer isinstalled in the same computer as the final user programs (seeFig. 1).In order to shed more light on the system architecture,let us explain, step by step, the frame transmission exampleshown in Fig. 3. After the symbols to be transmitted havebeen generated at the user application, a function is calledpassing to it the corresponding symbol vectors (one vectorper transmitting antenna). These symbols are sent to the signalprocessing layer (TxProc) through the user layer, where theyare converted to IF signals that are subsequently sent to themiddleware. When both the Tx-Rx PCs are ready to completea transmission, the signals are passed to the testbed hardwareto be transmitted through the antennas. At the receiver side,the middleware stores the signals into the hardware buffersand then they are forwarded to the receiver signal processinglayer (RxProc). At this moment, the Tx-Rx PCs are ready toprocess another frame while the acquired signals are convertedto complex symbol vectors that will then be forwarded to theuser application through the user layer, completing the entireprocess.This example shows the advantages derived from the useof a multilayer architecture instead of a monolithic system:the hardware is better exploited and each layer can be cus-tomised or extended according to specific capabilities, withoutdeveloping a complete new monolithic system each time thespecifications change.III. U SER AND SIGNAL PROCESSING LAYERS After describing the complete system architecture in theprevious section, this and the following sections study in depth  the layers that compound the architecture designed for ourMIMO testbed. In this section the two highest level layersare explained, i.e. the user and the signal processing layers,leaving the description of the middleware for section IV.The user layer interacts with the researcher or final testbeduser by calling a simple function implemented in Matlabor in any software or development platform that supportssocket connections. Its main task consists in sending to thesignal processing layer the symbols to be transmitted plus thenecessary parameters, at the transmitter side. In the same way,the user layer receives the acquired symbols, being noticed if any software error occurs.The main target of the user layer is making the rest of the layers accessible to the final users taking into account thetype of development environment they use. For this reason,the user layer is jointly executed with the user application (seeFigs. 1 and 2). Thus, a different user layer implementation canbe made available satisfying the particular user developmentenvironment requirements (Simulink, C/C++, Java, etc.).The signal processing layer is network-connected with boththe user and the middleware layers (see Fig. 2). It providesremote access and makes them platform independent withrespect to the other layers. This fact allows that the sig-nal processing layer to be run in a PC cluster, allowingintensive computing to generate the data to be transmittedand to process the acquired frames. This layer consists of two different processes that carry out the signal processingoperations needed to link the user and middleware layers.The first process (TxProc) receives the symbol vectors fromthe user layer and performs the up sampling, pulse-shapefiltering, IQ modulation and frame assembling operations inorder to generate the IF signals that will be sent to themiddleware. Similarly, the second process (RxProc) waits forthe acquired signals from the middleware and performs thetime and frequency synchronisation operations followed by theIQ demodulation, filtering and downsampling. The resultingvectors are sent to the user layer. It is important to emphasisethat the signal processing layer is designed and implementedby clearly separating its two main tasks: interconnection withthe adjacent layers (user and middleware) and execution of signal processing tasks.The signal processing layer can also incorporate new fea-tures such as, for example, a feedback channel for precodedMIMO systems [9]. This feedback channel is implementedusing the network connection available between the transmitterand the receiver. After an acquired frame is sent to the RxProcprocess, the feedback data is sent to the TxProc processthrough the Tx and Rx PCs. For instance, the RxProc processsends the feedback data to the Rx PC. Next, the feedback datais sent to the Tx PC and, finally, from the Tx PC to the TxProcprocess, making the feedback data available at the transmitterside.A signal processing layer detached from the other archi-tecture layers is fundamental to deploy a multiuser MIMOscenario. After extending the current TxProc and RxProc im-plementations in order to support multiuser MIMO techniques,the TxProc processes run at the transmitting users and theRxProc processes are executed at the receiving users.The user and signal processing layers also allow the re-searcher to implement tasks currently located at the signalprocessing layer, such as timing and/or frequency synchroni-sation or filtering.IV. M IDDLEWARE LAYER The middleware layer fills the gap between the platformhardware and the signal processing layer, allowing discrete-time signals to be transferred through the PCI bus and makingpossible the synchronisation between the Tx PC and the RxPC using a TCP/IP network connection.The middleware architecture is split into two differentsublayers (see Fig. 2). The top sublayer is responsible of establishing the network connections between the transmitterand the receiver, and with the higher layer (the signal pro-cessing layer). The bottom sublayer corresponds to the testbedhardware configuration and control software. Fig. 2 shows themiddleware with its two sublayers plus the connections withthe adjacent layers.The middleware is constituted by four different processes.The first two (TxHost and RxHost) run, respectively, on theTx PC and the Rx PC. They are implemented in standard C++language and use sockets to establish the necessary network connections: one between the TxHost and RxHost processes(used to synchronise the transmitter and the receiver, so thereceiver knows when the signal acquisition process has tostart); another one, established between the TxHost processand the Tx signal processing layer; and, finally, another onebetween the RxHost process and the Rx signal processinglayer. The remaining two processes are the transmitter andthe receiver processes that run on their respective DigitalSignal Processors (DSPs) available in the testbed hardware.Thus, the transmitter DSP process (TxDSP) performs datatransfers through the PCI bus jointly with the TxHost processand configures and controls the hardware components at theTx PC. In the same way, the RxHost process and the DSPreceiver process (RxDSP) are responsible of transferring thedata through the PCI bus and, from the DSP side, controllingand configuring the testbed hardware components.The middleware serves the maximum number of requeststhat the hardware supports. It serves a request while the datafor the next frame is still being generated by any computerin the network and, when the first frame is passed to thesignal processing layer, the middleware is ready to accepta new frame. With this architecture scheme, the middlewaresimultaneously serves requests from other layers running indifferent PCs.In order to release the middleware implementation fromdealing with the lowest level hardware details, the Sun-dance SMT6025 software development kit and the SundanceSMT6300 operating system driver are used in the TxHostand the RxHost implementations, while the Texas InstrumentsCode Composer compiler, as well as the 3L Diamond, areemployed for the TxDSP and RxDSP implementations.  Fig. 4. Testbed picture showing the two Tx Pc and Rx PC. The middleware concept constitutes a great leap forward inMIMO testbed technology, allowing access to hardware usingordinary network connections, and allowing synchronisationbetween the transmitter and the receiver. It also permits to in-corporate a wired feedback channel implementation describedin the previous section. The middleware design supportsextensibility in many senses, for instance many transmitterand receivers that can be used through broadcast network connections. Also, although the DSP processes are hardware-dependent, the control logic between the transmitter and thereceiver, as well as with the higher layers, is valid for differenthardware platforms. Finally, since the hardware interfacesfrom the host side and the software related to DSPs aredeveloped as separated software modules, they can be replacedby implementations suitable for any other testbed.V. T ESTBED HARDWARE DESCRIPTION A first release of the testbed hardware was presented in[7], where the baseband modules were from Sundance andthe radiofrequency (RF) front-end modules were developedat the University of Cantabria. The testbed has been updatedand new RF front-end Sundance SMT349 modules have beenincluded. Also, minor module reorganisations have been done.For example, by using the previously described middlewarelayer, external synchronisation circuits are no longer neededto start the acquisition process.Fig. 4 shows a picture of the Testbed PCs. The hardwaretestbed is based on a PCI carrier board SMT310Q and abasic processing module: the SMT365 equipped with a XilinxVirtex-II FPGA and a Texas Instruments C6416 DSP at 600MHz. The processing module has two buses that can transfer32-bit words up to 400 MB/s, allowing the connection with theSMT370 module, that contains a dual AD9777 D/A converterand two AD6645 A/D converters. The SMT370 module alsohas a 2 MB per-channel memory that is used to load the framesto be transmitted. At the receiver side, the data acquired bythe A/D converters is stored in real time in a 1 GB FIFOmemory SMT351 module and, in an offline task, passed to themiddleware through the PCI bus. Finally, the testbed containstwo SMT349 RF front-end modules. They perform the up and Fig. 5. Graphical interface screen shot of the tool. down conversion operations from an IF of 70 MHz to a 2.45GHz carrier RF, with 16 MHz of maximum bandwith.VI. T HE SYSTEM AT WORK :  A NEW TOOL FOR  A LAMOUTICODED  MIMO  SYSTEMS In previous work [10], [11], we have proposed several novelblind MIMO channel estimation methods based on differentBlind Source Separation (BSS) algorithms. The proposedmethods are especially powerful when used in conjunctionwith orthogonal space-time block codes (OSTBC), such as theAlamouti coding scheme [12]. In addition, all these algorithmshave been tested in an indoor scenario using the MIMOtestbed described in the previous section. Cumbersome low-level programming was needed to perform the experimentaltrials. In contrast, thanks to the abstraction level of ourdistributed architecture, it has been very easy to implementan user tool for testing the algorithms on the MIMO testbed.The tool is implemented in Matlab and it is especially suitablefor the BSS techniques experimentation. It serves both as ademonstration of the testbed capabilities and as starting pointfor the development of a new tool suitable in another MIMOresearch area. Although the tool can be employed by its own,using randomly generated channels, it has been specificallydesigned to show how new software applications are developedby using our multilayer architecture. In order to provide betteruser experience with the tool it has been equipped with agraphical user interface. Fig. 5 shows a screen shot of thegraphical interface.The tool allows testing with discrete symbol sequences,baseband or passband IF signals that are transmitted usingthe testbed or through randomly generated channels. Severalparameters can be modified such as the number of bits tobe transmitted, or how they are generated; the modulationformat (PAM, PSK or QAM) and its number of levels; thenumber of samples for each symbol plus the pulse-shape touse. The user can also test the recently proposed blind channelestimation techniques [10], [11] plus the JADE and FastICAblind methods or classical least squares.  Fig. 6. Tool output showing the transmitted symbols (black) and signals(red), the received signals after the IQ demodulation (green) and after thematched filter (blue).Fig. 7. Received symbol constellation. For example, after a 4-QAM symbol sequence is codedusing the Alamouti OSTBC and transmitted over the testbed,the tool displayed Figs. 6 and 7. The first one shows thetransmitted symbol sequence and the resulting signals afterthe pulse-shape filter. The acquired signals are plotted afterthe IQ demodulation and the matched filter. The second figureshows the received symbol constellation. At the bottom of thefigure the obtained symbol error ratio (SER), the bit error rate(BER) and the signal-to-noise ratio (SNR) are displayed.VII. C ONCLUSIONS In this paper a new distributed multilayer architecture forMIMO testbed user access is proposed. The architecture fillsthe gap that currently exists between commercial hardwarecomponents and the most common abstraction level used byresearchers. The architecture overcomes the limitations of im-plementing new algorithms directly from the testbed. Insteadof using the low-level interfaces provided by manufacturers,the architecture supplies a high level interface access fortestbeds. It releases researchers from the necessity of knowingthe details of the testbed and hardware. For instance, they caneasily test new algorithms without developing a completelynew source code release specifically for the testbed, speedingup the implementation and test tasks.The key point to the multilayer architecture design is the useof ordinary network connections to link both software modulesand hardware components, being also useful for decoupling thesoftware layers. Several advantages are obtained as a conse-quence of the multilayer software architecture. For example,synchronisation between the transmitter and the receiver canbe dealt through a network connection instead of using exter-nal circuits. Also, multiuser scenarios and feedback channelscan be constructed extending the proposed architecture. Fi-nally, to complete the proposed multilayer architecture, a newtool has been implemented demonstrating the developmentfacilities provided by the architecture.A CKNOWLEDGEMENTS This work has been supported by an FPU Ph. D. grantof Ministerio de Educaci´on y Ciencia of Spain (TEC2004-06451-C05-01), a “Mar´ıa Barbeito” Ph. D. grant of Xunta deGalicia, and a research project of the Ministerio de Educaci´ony Ciencia of Spain (TEC2007-68020-C04-01).R EFERENCES[1] G. Foschini and M. Gans,  On limits of wireless communications in a fading environment when using multiple antennas , Wireless PersonalCommunications, vol. 6, pp. 311–335, 1998.[2] I. E. Telatar,  Capacity of multi-antenna Gaussian channels , EuropeanTrans. on Telecommunications, vol. 10, no. 6, pp. 585–595, Nov.-Dec.1999.[3] R.M. Rao, Wiejun Zhu, S. Lang, et. al,  Multi-Antenna Testbeds for  Research and Education in Wireless Communications , CommunicationsMagazine, IEEE, Volume 42, Issue 12, pp. 72–81, December 2004.[4] Ll. Ventura, X. Nieto, J. Gr`egoire, W. De Win, N. Lugil,  A broadband wireless MIMO-OFDM demonstrator, design and measurement results ,Proceedings of the 17th PIMRC, Helsinki, Finland, September 2006.[5] S. Caban, C. Mehlfuhrer, R. Langwieser, A. L. Scholtz, and M. Rupp, Vienna MIMO Testbed  , EURASIP Journal on Applied Signal Processing.vol. 2006, 2006.[6] D. Borkowski, L. Brhl, C. Degen, et al.,  Saba: A Testbed for a real-time MIMO system , EURASIP Journal on Applied Signal Processing,vol. 2006, 2006.[7] J. A. Garc´ıa-Naya, T. Fern´andez-Caram´es, H. P´erez-Iglesias, M.Gonz´alez-L´opez, L. Castedo, D. Ram´ırez, et. al,  Performance of STBC transmissions with real data , Proceedings of 16th IST Mobile andWireless Communications Summit, Budapest, Hungary, July 2007.[8] M. Rupp, S. Caban, C. Mehlf¨uhrer,  Challenges in Building MIMOTestbeds , European Signal Processing Conference, Pozna, Poland,September 2007.[9] Mai Vuk, A. Paulraj,  MIMO Wireless Linear Precoding , IEEE SignalProcessing Magazine, vol. 24, issue 5, pp. 86–105, Sept. 2007.[10] H. J. P´erez-Iglesias, A. Dapena, L. Castedo, and V. Zarzoso,  Blind channel identification for Alamouti’s coding system based on eigenvector decomposition , Proceedings of 13th European Wireless Conference, Paris,France, April 2007.[11] H. J. P´erez-Iglesias, J. A. Garc´ıa-Naya, and A. Dapena,  A blind channelestimation strategy for the 2x1 Alamouti system based on diagonalising4th-order cumulant matrices , Proceedings of 2008 IEEE InternationalConference on Acoustics, Speech, and Signal Processing, Las Vegas,Nevada, U.S.A., April 2008.[12] S. M. Alamouti,  A simple transmit diversity technique for wirelesscommunications , IEEE Journal Select. Areas Communications, vol. 16,pp. 1451–1458, October 1998.
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks