an overview of mimo testbed technology - CiteSeerX

AN OVERVIEW OF MIMO TESTBED TECHNOLOGY Jos´e. A. Garc´ıa-Naya, M. Gonz´alez-L´opez, L. Castedo Departamento de Electr´onica y Sistemas, Universidade da Coru˜na Campus de Elvi˜na no 5. 15071 A Coru˜na, SPAIN email: {jagarcia, mgonzalezlopez, luis}@udc.es ABSTRACT Based on our experience in MIMO testbed design and implementation, we provide an up-to-date classification of the most relevant MIMO testbeds developed so far by the research community. First, we include an overview of the different tools enabling real test and measurement, making a clear distinction among testbeds, demonstrators and prototypes, and emphasising their key features. We also describe the structure of a typical MIMO testbed, detailing its hardware components and software modules. Baseband components, RF front-ends and software development tools are analysed, enabling us to point out the challenges that must be overcome in the future. Finally, several guidelines for the evolution of testbeds are proposed.

1. INTRODUCTION Since the pioneering work of Foschini and Telatar [1, 2], MIMO theory basis have been settled. Both academia and industry are showing an increasing interest on building real systems to verify the capacity gains promised by MIMO theory. While theory and simulations typically show the corresponding gains under ideal conditions, hardware systems are suitable in validating these gains in more realistic scenarios. Hardware implementations are split into three groups [3]. The first one is constituted by demonstrators, frequently designed focusing on standards or specifications. Demonstrators usually exhibit good technical characteristics for real-time implementations, but they are extremely expensive and have poor flexibility and modularity capabilities. The second group is formed by testbeds, that support real-time transmissions while the data is generated and post-processed off-line. They are flexible, modular and scalable solutions more suitable for research than demonstrators. Finally, the third set is constituted by the prototypes of a final product, usually suitable for the industry. Throughout this paper we will concentrate in testbeds, because they use open designs and are found in public research centres and academia. Various testbeds have been constructed for testing MIMO technologies and several classifications have been suggested, according to diverse selection criteria: taking care of the final purpose, for example, if they are focused on a concrete standard or specification, or they are designed according to general purpose [4]; with respect to the technology used: software-defined, DSP-based, DSP and FPGA-based, FPGA-based and, finally, ASIC-based [5]; or taking account of their flexibility, development time consumption, throughput or cost [5]. Finally, the educational possibilities of the hardware implementations are especially valuable in academia, because the availability of varied This work has been supported by a “Mar´ıa Barbeito” Ph. D. grant of Xunta de Galicia, and a research project of the Ministerio de Educaci´on y Ciencia of Spain (TEC2007-68020-C04-01).

multi-antenna hardware implementations enables many teaching opportunities. Although there are several testbed examples focused in different research areas and constructed using distinct technologies and equipments, there is a lack of up-to-date guides and tutorials that help in the construction of a new testbed from scratch. Indeed, there exist only very few contributions [4, 5, 6] and, except for [6], the information contained on them is already outdated. The objectives of this paper are to highlight the principal problems to be considered when a new testbed is built, to perform an analysis of the hardware technology available for constructing the main parts of a testbed, to introduce the software tools and methodologies that can be used and, finally, to present an up-to-date classification of the most relevant testbeds. We will focus on testbeds centered on MIMO technologies and that can be mainly constructed using hardware components available in the market. The analyses are based on both previous work and our experience in the testbed research field [7, 8, 9, 10]. The rest of the paper is structured as follows. Section 2 gives a global description of the fundamental testbed features. Section 3 details the technical features of the most relevant testbeds. Various guidelines about the testbeds future are described in Section 4 and, finally, Section 5 is devoted to the conclusions. 2. TESTBED FEATURES Testbeds are used to verify if a new signalling technique that has been proven useful in a simulation environment is also valid in realistic wireless scenarios. The testbed allows evaluating the hardware needs for the implementations, not only from the digital side (mainly, DSP and FPGA requirements), but for the behaviour required for the analog RF modules. Consequently, testing with testbeds allows knowing whether a proposed technique is feasible or not for hardware implementation. In this Section we detail the three main components that constitute a testbed: baseband modules, RF front-ends and software development tools targeted to testbed development. 2.1. Baseband components Testbed hardware is split into three groups according to its functionality. The first one is the host PC or the equipment that allocates the hardware testbed. The second group is constituted by digital hardware components and, finally, the third one is formed by the RF front-ends. The frontier between the digital and analog hardware is generally constituted by the D/A and A/D converters. Baseband components are the hardware elements necessary to deal with the low IF or baseband signals. Frequently, carrier elements are used to allocate the baseband components or even the RF front-ends. Current testbeds use carrier boards equipped with typical buses to access the testbed hardware, such as USB, PCI, cPCI, PCI express or similar. A manufacturer compliant with the PXI alliance [37] specifications produces carrier ele-

ments that are compatible with the most typical buses present in host equipments. Signal processing is performed by means of discrete-time signal processors such as DSPs or FPGAs. When available, testbeds typically use DSPs from Texas Instruments (C62xx, C64xx and C67xx are very common) and FPGAs from Xilinx or Altera (for example the Xilinx Virtex family). Important hardware components in a testbed are the storage buffers. They allow performing signal operations off-line while data is sent and acquired in real-time. If only the transmission is performed in real-time, both the available memory amount and the access speed constitute the main limitation for the experiments to be carried out with a testbed. D/A and A/D converters are needed to convert the signals from digital to analog and viceversa. Nowadays, testbeds use very powerful D/A and A/D converters with a resolution varying from 10 to 16 bits and speeds up to 500 Msamples/s or even higher. Many of the testbeds have dual D/A converters that can perform IQ modulation and, also, they incorporate interpolating filters for signal quality improvement. The interconnection among the just described elements is carried out using buses that must be capable of transmitting the data in real-time. Finally, external circuitry such as clock distribution and/or synchronisation is needed. Typically, local oscillators are jointly provided with the D/A and A/D converter components. However, when MIMO processing is required, it must be taken into account the need for external clock connectors, necessary to synchronise several converters. 2.2. RF front-ends RF front-ends constitute one of the major hindrances in the testbed building process. They are responsible of up converting low IF or baseband signals to RF. The most common RF bands are the unlicensed ISM located at 2.4 and 5.8 GHz. High linearity and flexibility in terms of supported carrier frequencies and bandwidth are desirable features for the RF front-ends. However, the most advanced front-ends available are only dual-band and have fixed bandwidth. Also, the majority of the front-ends are designed for SISO operation, making difficult to adapt them to a MIMO system. Once the front-end has been acquired, extensive test on it is needed. To this end, expensive measurement equipment is required. 2.3. Software development tools Methodologies that cover the entire development process from the source code suitable for simulations and executed off-line to the implementation that is executed in real-time (also called real-time implementation) in the testbed, and software tools according to these methodologies, are extremely scarce. The most popular methodology for testbed development is the rapid prototyping [3, 11, 12]. A typical approach used to develop real-time algorithms that run in a testbed consists of starting with a simulation implementation. Next, the simulation is migrated to the testbed. Finally, a real-time implementation is obtained. It is also convenient to split the real-time implementation into several steps: firstly, a fixed-point code is produced, next a DSP implementation is obtained and, afterwards, the software modules that do not meet the time requirements are migrated to an FPGA, making use of high level tools when possible. Those systems with a clear commercial projection are implemented in dedicated chips (ASIC), but this step is out of the objectives followed by researchers. Nowadays, excluding the Mathworks tool suite combined with some VHDL code generators, there is a lack of high level tools and development environments suitable to fit the previous steps. Currently, these tools are very immature, especially those dedicated to facilitate the real-time implementation

in FPGA. Thus, there are no useful development environments that cover the entire rapid prototyping process, increasing the gap between the complexity of wireless systems and the tools available for their implementation. Generally, testbed hardware manufactures provide basic tools for development. Sometimes these tools are customised by the manufacturer or new tools are attached, as for example the 3L Diamond real-time operating system. Unfortunately, one of the most common drawbacks in testbed software development is the poor quality of the provided documentation. 2.4. Testbed manufacturers Complete out-of-the box testbeds are available from Lyrtech [13] and Signalion [14]. Lyrtech offers a testbed formed by baseband modules integrated in a PC plus a Quad Dual-Band RF transceiver that allows building a dual-band MIMO 4 x 4 system at both 2.4 and 5 GHz bands. Lyrtech has available a complete portfolio with hardware specifically built for MIMO and smart antennas operation. On the other hand, Signalion provides several testbed types. For example, the HaLO [15] is specially suitable for the exploitation of the hardware-in-the-loop concept and with very good technical characteristics. It constitutes a 4 x 4 MIMO system with 20 MHz of bandwidth both in the 2.4 and 5 GHz ISM bands. Another testbed example from Signalion is SORBAS [16], specifically designed for rapid prototyping. It is also possible to construct a testbed selecting its elements from Commercial Off-The-Shelf (COTS) hardware components. This is the case of Sundance Multiprocessor [17], Hunt Engineering [18], Pentek [19] or ICS [20]. In all cases, the most scarce components are the RF front-ends. The other set of platforms is constituted by those exclusively focused on real-time processing. For example, Nallatech [21] offers several COTS specifically designed for FPGA operation. Finally, the last group contains testbeds suitable for non high performance requirements, constituting very good solutions for educational purposes or specific fields of interest. Examples of this group are [22] or the GNU Radio [23]. 3. TESTBED OVERVIEW Making a review of the developed testbeds is not easy due to their different nature and construction purposes. Various authors propose several classification criteria. For example, [5] introduces a classification from the user perspective, based on flexibility, development time, throughput and cost, also providing a table showing how these characteristics are verified in softwaredefined, DSP-based, ASIC-based or DSP+FPGA-based testbeds. Here we complete such classification by summarising the key technical features (see Table 1) present in current testbeds. Gathering technical information about testbeds is not difficult but it is very time-consuming because those kind of details are widely spread among papers, datasheets, brochures and websites. Without any doubt, the obtained technical summary will be very helpful for those researchers interested in MIMO testbed technology. The majority of the analysed testbeds are MIMO 4 × 4 except for UCLA (1 × 1), Rice (2 × 2), ITR (2 × 2), STARS (2 × 4) and MIMESIS (2 × 2). All have both off-line and realtime (DSP and/or FPGA) processing capabilities. The following testbeds do not have any DSP: SABA, UCLA, Montreal, Rice and ITR. The remaining platforms have one or more Texas Instruments DSPs, and C62xx, C64xx and C67xx are the most common DSP families used. Regarding FPGAs, Xilinx Virtex or even Spartan are the most used models except for ITR that uses an ALTERA model. Most of the testbeds take into account the advantages derived from having memory buffers accessible in real-time. This is the case of WG, TUWIEN, LRTS,

Table 1. Summary of technical features of current MIMO testbeds. WG [25] 4×4 VME PC/DSP 8 × C6203 –

TUWIEN [26] 4×4 PCI PC/DSP/FPGA 2 × C6416 2 × Virtex II

LRTS [27] 4×4 PCI PC/DSP/FPGA C6701 Virtex II

SABA [28] 4×4 cPCI FPGA – 6 × Virtex II

UCLA [29] 1×1 PCI PC –

Tx × Rx Carrier Baseband DSP

GEDOMIS [24] 4×4 VME PC/DSP/FPGA 4 × C6203 6 × Spartan II 2 × Virtex II – VIM / Global 16 bit, 320 MHz 12 bit, 80 MHz 40 MHz 40 MHz Montreal [30] 4×4 RAID PCI PC –

Yes VME 12 bit, 200 MS/s 12 bit, 65 MS/s Unknown – Rice [31] 2×2 PCI/USB FPGA –

Yes SHB 14 bit, 200 MS/s 14 bit, 100 MS/s 20 MHz – ITR [32] 2×2 PCI PC/FPGA –

Yes GPIO / PCI 105 MS/s 105/200 MS/s 40 MHz 40 MHz STARS [33] 2×4 PCI PC/DSP/FPGA 2 × C6416

Yes PCI 16 bit, 100 MHz 14 bit, 50 MHz – 25 MHz MIMESIS [35] 2×2 PCI PC/DSP/FGPA 2 × C6416

FPGA Buffers Bus DAC ADC BW 2.4 GHz BW 5 GHz

6 × Virtex II Yes PCI/FPDP 14 bit, 65 MS/s 12 bit, 65 MS/s 3.5 MHz –

– – PCI/USB – – 20 MHz –

Altera EP20K – PCI 12 bit, 80 MHz 12 bit, 80 MHz – 20 MHz

2 × Virtex II Yes SHB 16 bit, 400 MS/s 14 bit, 105 MS/s 20 MHz –

Yes Custom 14 bit, 100 MS/s 14 bit, 100 MS/s – – UCLA2 [34] 4×4 VME PC/DSP/FPGA 4 × C6701 4 × C6203 2 × Virtex II Yes PCI/VME 12 bit, 200 MHz 12 bit, 105 MHz 20 MHz –

Tx × Rx Carrier Baseband DSP FPGA Buffers Bus DAC ADC BW 2.4 GHz BW 5 GHz

SABA, UCLA, Montreal, STARS, UCLA2 and MIMESIS. Also, all testbeds use VME, PCI, cPCI and/or USB buses to interconnect the testbed hardware with the host PC. Many of them also use custom or proprietary high-speed buses to transfer data among the baseband modules. With respect to the D/A and A/D converters it is very common to have 12 or more bits of resolution and more than 50 Msamples/s. Generally, the baseband features of all analysed testbeds are very good, showing that baseband hardware is good enough to satisfy the processing requirements of today’s MIMO algorithms. The RF front-end is the most distinguishing property among testbeds. The majority of the testbeds have front-ends for the ISM unlicensed bands, specially the 2.4 and 5 GHz bands. A special case is constituted by those testbeds with a dual-band front-end as, for example, GEDOMIS and LRTS (using Lyrtech hardware). The ITR and UCLA testbeds only work in the 5 GHz band and the rest of the testbeds, except for SABA and Montreal, have front-ends in the 2.4 GHz band. SABA uses the 10.525 GHz band and, finally, Montreal employs the 1850–1950 MHz band. The maximum bandwidth allowed by the front-ends varies a lot among testbeds, from less than 5 MHz up to 40 MHz. The most common testbed hardware manufacturers are Pentek (GEDOMIS, WG and UCLA2), Sundance (TUWIEN, STARS and MIMESIS), Nallatech (SABA and Rice), ICS (TUWIEN and Montreal) and Lyrtech (LRTS). The most common development tools used in testbeds are the Mathworks tool suite, TI Code Composer, and Xilinx FPGA tools such as ISE or System Generator. Testbeds built from Sundance hardware (TUWIEN, STARS and MIMESIS) use in addition 3L Diamond.

2 × Virtex II Yes SHB 16 bit, 400 MS/s 14 bit, 105 MS/s 20 MHz 20 MHz

available in the market, new solutions have started to emerge as, for example, the MORFAN module [36] available for Sundance testbed implementations. This module integrates baseband D/A and A/D converters plus the RF front-end in the same hardware component. Just like the RF front-end offered by Lyrtech, MORFAN is based on Maxim MAX2829 chipset. However, the features available in the baseband modules, including the storage buffers, are perfectly adequate for a large variety of applications. Real-time processing is one of the most difficult to implement aspects in testbed technology. The shortage of development methodologies and tools difficults the migration from offline code to real-time implementation. A key aspect will be the introduction of design patterns that help to improve the translation from off-line to real-time code. The availability of integrated development environments that support these patterns will also be crucial for the success of this migration. Finally, the evolution of software engineering during last years should be taken into account as a model. Moreover, the existence of design patterns for off-line implementations that have been proven as valid to be migrated to real-time is the starting point of a new revolution in testbed technology. Also, some standardisation have just started in order to make compatible hardware components and software modules from different manufactures and developers. The PXI alliance [37] plus the SDR Forum [38] and initiatives such as the Software Communications Architecture (SCA) [39] constitute the starting point of a new generation of modular, flexible and standard radio interfaces suitable for research. 5. CONCLUSIONS

4. THE FUTURE OF THE TESTBEDS The lack of flexible and tunable RF front-ends is the major weakness of testbeds’ hardware. Although there are very few products

Testbeds are very useful tools to check if simulation tests are also valid in real scenarios. Also, they allow in depth studying of some physical aspects that are difficult to take into account in

simulations, such as the effect of the impairments caused by the hardware and the channel. In this paper, a detailed explanation about the constituting parts of a testbed is shown. Also, a distinction among demonstrators, prototypes and testbeds is provided and several previous work in this field is mentioned. Different testbed software tools are presented and the problem of the lack of methodologies and tools is introduced. In order to be helpful for those research teams without experience that are planning to build a new testbed from scratch, an up-to-date classification of the most relevant testbeds developed so far is presented.

[18] Hunt Engineering (U.K.) Ltd., www.hunteng.co.uk [19] Pentek, Inc., www.pentek.com [20] GE Fanuc, www.gefanucembedded.com [21] Nallatech Inc., www.nallatech.com [22] C. Y. Chiu, C. H. Cheng, Y. S. Wan, C. R. Rowell, R. D. Murch, “Design of a Flat Fading 4 x 4 MIMO Testbed for Antenna Characterization using a Modular Approach”, Proc. of WCNC, pp. 2913–2918, March 2007. [23] GNU Radio, www.gnu.org/software/gnuradio

6. REFERENCES [1] G. Foschini, M. Gans, “On limits of wireless communications in a fading environment when using multiple antennas”, Wireless Personal Comm., vol. 6, pp. 311–335, 1998. [2] I. E. Telatar, “Capacit01184117.y of multi-antenna Gaussian channels”, European Trans. on Telecommunications, vol. 10, no. 6, pp. 585–595, Nov.-Dec. 1999. [3] M. Rupp, C. Mehlf¨uhrer, S. Caban, “Testbeds and Rapid Prototyping in Wireless System Design”, EURASIP Newsletter, vol. 17, no. 3, pp. 32–50, Sept. 2006. [4] S. Caban, C. Mehlf¨uhrer, R. Langwieser, A. L. Scholtz and M. Rupp, “Vienna MIMO Testbed”, EURASIP Journal on Applied Signal Processing, vol. 2006, pp. 1–13, 2006. [5] R. Mysore Rao, W. Zhu, S. Lang et al, “Multi–Antenna Testbeds for Research and Education in Wireless Communications”, IEEE Communications Magazine, pp. 72–81, Dec. 2004. [6] M. Rupp, S. Caban, C. Mehlf¨uhrer, “Challenges in Building MIMO Testbeds”, European Signal Processing Conference, Pozna´n’, Poland, Sept. 2007. [7] D. Ram´ırez, I. Santamar´ıa, et al, “A flexible testbed for rapid prototyping of MIMO baseband modules”, ISWCS 2006, Valencia, Spain, Sept. 2006. [8] D. Ram´ırez, I. Santamar´ıa, J. P´erez, J. V´ıa, J. A. Garc´ıaNaya, et al, “A comparative study of STBC transmissions at 2.4 GHz over indoor channels using a 2 × 2 MIMO testbed”, Wireless Communications and Mobile Computing, published online, 2007. [9] J. A. Garc´ıa-Naya, H. J. P´erez-Iglesias, T. M. Fern´andezCaram´es, M. Gonz´alez-L´opez, L. Castedo, “A Distributed Multilayer Architecture Enabling End-User Access to MIMO Testbeds”, submitted to PIMRC 2008, 2008. [10] T. M. Fern´andez-Caram´es, J. A. Garc´ıa-Naya, M. Gonz´alez-L´opez, L. Castedo, “MIMO testbed middleware for transmission automation”, submitted to ELMAR 2008, 2008. [11] T. Kaiser, A. Wilzeck, M. Berentsen, M. Rupp, “Prototyping for MIMO Systems – An Overview”, Proc. of EUSIPCO 2004, Vienna, Sept. 2004. [12] M. Rupp, A. Burg, and E. Beck, “Rapid Prototyping for Wireless Designs: the Five-Ones Approach”, Signal Processing Europe, vol. 83, pp. 1427–1444, 2003. [13] Lyrtech, www.lyrtech.com [14] Signalion GmbH, www.signalion.com

[24] X. Nieto, L. M. Ventura, and A. Mollfulleda, “GEDOMIS: a Broadband Wireless MIMO-OFDM Testbed. Design and Implementation,” Proc. of TRIDENTCOM, Barcelona (Spain), March 2006. [25] J. Wallace, B. Jeffs, and M. Jensen, “A real-time multiple antenna element testbed for mimo algorithm development and assessment,” Antennas and Propagation Society International Symposium, IEEE, vol. 2, pp. 17161719, June 2004. [26] S. Caban, Christian Mehlf¨uhrer, R. Langwieser, A. L. Scholtz, and M. Rupp, “Vienna MIMO Testbed”, EURASIP Journal on Applied Signal Processing, vol. 2006, pp. 1–13, 2006. [27] S. Roy, L. B`elanger, The Design of an FPGA-Based MIMO Transceiver for Wi-Fi, “Xilinx DSP Magazine”, May 2006. [28] 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. [29] S. Lang, M. Rao, and B. Daneshrad, “Design and development of a 5.25 GHz Software Dened Wireless OFDM Communication Platform,” Communications Magazine, IEEE, vol. 42, no. 6, pp. 612, 2004. [30] R. Morawski, T. Le-Ngoc, O. Naeem, “ Wireless and wireline MIMO testbed”, Electrical and Computer Engineering, 2003. IEEE CCECE 2003. Canadian Conference on, vol. 3, pp. 1913–1916, May 2003. [31] P. Murphy, F. Lou, A. Sabharwal, J.P. Frantz, “An FPGA based rapid prototyping platform for MIMO systems”, Proc. of Asilomar, vol. 1, pp. 900–904, Nov. 2003. [32] A. G. Fabregas, M. Guillaud, G. Caire et al, “A MIMOOFDM Testbed for Wireless Local Area Networks”, Proc. of Asilomar, pp. 82–86, Nov. 2005. [33] A. Wilzeck, M. El-Hadidy, Q. Cai, M. Amelingmeyer, T. Kaiser, “MIMO Prototyping Testbed with off-the-shelf plugin RF Hardware”, IEEE Workshop on Smart Antennas 2006, Ulm, Germany March 2006. [34] W. Zhu, D. Browne, M. Fitz, “An Open Access Wideband Multi-Antenna Wireless Testbed with Remote Control Capability”, Proc. of TRIDENTCOM, pp. 72–81, Feb. 2005. [35] J. A. Garc´ıa-Naya, T. Fern´andez-Caram´es, H. P´erezIglesias, M. Gonz´alez-L´opez, L. Castedo, D. Ram´ırez, et. al, “Performance of STBC transmissions with real data”, Proceedings of 16th IST Mobile and Wireless Communications Summit, Budapest, Hungary, July 2007. [36] MimoOn MORFAN RF front-end, www.mimoon.de/pages/Products/MIMO Reference Designs

[15] Signalion HaLO, http://www.signalion.com/9-0-hardwarein-the-loop-platform.html

[37] PCI eXtensions for Instrumentation (PXI), www.pxisa.org

[16] Signalion SORBAS, sorbas-platform.html

[39] Software Communications http://sca.jpeojtrs.mil/

http://www.signalion.com/10-0-

[17] Sundance Multip. Tech., Ltd., www.sundance.com

[38] Software Defined Radio (SDR) Forum, www.sdrforum.org Architecture

(SCA),