FFT spectrum screenshot of OFDM signal (packet length 20 bytes) showing single data frame with 48 sub-carriers (bins) when using n + . 

Context in source publication

Context 1

... which provide a frequency range between 2.4 GHz - 2.5 GHz and 4.9 GHz - 5.9 GHz which allow us the setup of IEEE 802.11n WLANs. Fig. 1 shows the platform setup for SISO communication. The setup consists of 2 personal computers and 1 USRP at the transmitter (Tx) and the receiver (Rx). Fig. 2 shows the overall system architecture of the proposed multi-antenna MIMO- OFDM setup, consisting of one transmitter and one receiver, both with two USRP boards attached. The figure illustrates the H-matrix of a 2 × 2 MIMO-OFDM setup. For the evaluation of non-certified radio systems, we used a shielded location to avoid any interference with public wireless networks. Our platform has Ubuntu Linux, version 11.04, running on two Pentium-4 PCs. The platform needs to be highly flexible, operating at different frequency bands including sub- 1 GHz, 2.4 GHz and higher. Here, we propose the use of software radio platforms. Further, the platform should also allow modifications to hardware and software on each of the lower ISO/OSI layers to apply MIMO-OFDM for different systems, e.g., PHY down-clocking operations and MAC frame aggregation. Therefore, we are looking up to open-source solutions, which can be easily tested and extended for our purposes. We tested two potential MIMO implementations, an implementation called 802 . 11 n + or simply n + [13], and a solution called Hydra [14]. Both implementations aim at providing building blocks for MIMO support. n + provides a basic MIMO framework for transmitting a pre-designed traffic pattern which is then decoded in off-line fashion using MATLAB TM . We found that this solution is hard to verify due to a proprietary MIMO implementation – light-weight RTS/CTS, no acknowledgements (ACKs). It also has an inefficient off-line procedure that requires the received signal to be transferred to the MATLAB TM user space, where the Fast Fourier Transform (FFT) operation is executed. Main drawback of n + is that no two-way communication is supported. In contrast Hydra claims to support IEEE 802.11n basic features and runs in on-line fashion, i.e., data files can decoded in real-time at the receiver. Hydra comes with a support for 2-way communication and offers more control over the communication protocol and enables the development of optional features, including framing and block ACKs. Hydra comes with a library that supports limited core functions of IEEE 802.11n operation. Hydra utilizes the USRP boards as RF front-ends for wireless setup. When comparing various USRP types, the USRP 2 supports only single internal RF daughter-boards. This would require two USRP 2 and an external clock to operate a 2 × 2 MIMO system. In contrast, the USRP 1 supports two internal RF boards, which we used in our WLAN platform using two SBX boards. We compare the building blocks in Table III. There is a significant software dependency on the USRP RF daughter-boards, as we have stated above. When using Hydra, the use of the XCVR 2450 daughter-board is required in order to execute wireless data communication in the 2.4 GHz band, which is Hydra’s default frequency-band. Software modifications IV. are P LATFORM needed to E operate VALUATION Hydra R on ESULTS different carrier frequencies, We conducted e.g., extensive f c = 923 field MHz trials when to using evaluate SBX the daughter- performance boards. of To two solve implementations, the problem of n + controlling and Hydra. the The SBX objective board is with to Hydra, evaluate we the studied selected the differences hardware and in the software hardware in archi- order to tecture verify of the both basic daughter-boards, MIMO-OFDM the operations XCVR 2450 and and to SBX. identify An performance intensive study boundaries gave us insight of our into proposed the hardware WLAN platform. architecture and how the communication channels and bit-sequences of both daughter-boards are defined [7]. For example, we found that the I/O-control is somewhat different which required significant changes on the serial USRP interface, which we then implemented as a new UHD (USRP Hardware Driver) software library to support SBX boards. We added the new Hydra library in order to support two synchronized SBX boards operating at f c = 923 MHz and without the use of any external clock synchronization. We found that GnuRadio, version 3.2.2, [8] is a valid compromise which supports Hydra, the modified UHD driver, and the SBX board. IV. P LATFORM E VALUATION R ESULTS We conducted extensive field trials to evaluate the performance of two implementations, n + and Hydra. The objective is to evaluate the selected hardware and software in order to verify the basic MIMO-OFDM operations and to identify performance boundaries of our proposed WLAN platform. First, we setup a WLAN platform using n to transmit MIMO-OFDM signals. We observed that the implementation by n + is somewhat limited, mainly due to the software design which does not include IEEEE 802.11 basic PHY and MAC operations. Fig. 3 shows a screenshot of a OFDM signal of a single data packet (packet length 20 bytes) when using n + . It shows 48 OFDM sub-carriers with an observed sending power at 0 dBm. Fig. 4 shows the transmission results of the OFDM signal while using the SISO platform configuration after off-line decoding with MATLAB TM . It shows the increased slope (real part) over the sub-carrier. The receiver correctly demodulates the transmitted OFDM signal. It is worth noting that a continuous data transmission with n + was not possible. Only one single data frame is transmitted, modulated as MIMO signal, which then has to be demodulated off-line using MATLAB TM . We added a new software library which would allow us to transmit a continuous data flow with n + . The results of transmitting multiple data packets with n + is shown in Fig. 4, indicating the measured inter-frame spacing time of 2 ms. We conclude that n + is not our favorite candidate simply due to the required off-line demodulation procedure. To identify Hydra’s performance boundaries, we measured the round trip time (RTT), packet error rate (PER), channel gain, and data rate for sub-1 GHz SISO and MIMO configuration. We limited our measurement campaign using MCS 0 to MCS 4 for SISO and from MCS 8 to MCS 12 for the MIMO setup, due to the significant increase in error rate for higher MCS rates which indicates significant performance limits of higher modulation rates for narrow-band data transmission at 1 MHz, which we observed in our setup. To verify the wireless link performance we tested the channel gain of 2 × 2 MIMO in a shielded location. The channel gain measurement results (graphs not shown due to paucity of space and for brevity) is given in Table IV, indicating a robust gain performance over the MIMO link (MCS 8) compared to SISO (MCS 0) at f c = 923 MHz. The observed PER of the received packet index was below 2%. We then confirmed that the performance is similar compared to results from the literature [15]. Next, we report on the delay and throughput performances of our platform. We used the Internet Control Message Protocol (ICMP) which gives the highest data rate due to less protocol overhead. In addition, we are interested in potential drawbacks and limitations when User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) are used. In particular, the TCP performance will indicate the lower boundaries of our platform, because any transmission limitations would lead to TCP retransmissions. Then, we report on the MIMO delay performance which is given in Fig. 5. The measurement indicates an increased delay at 461 ms (MCS 8) for 1400 byte packet length. Lowest delay values have been measured at 245 ms (MCS 10). Next, we show the throughput performance of our 2 × 2 MIMO-OFDM narrow-band WLAN platform in Fig. 6. In Fig. 6 it can be observed that the throughput increases for larger packet length (100, 200, 400, 800, 1400 byte) and reaches 91.31 Mbps for 1400 byte ICMP packet length (MCS 10). We observed that higher MCS rates lead to satu- rated throughput, due to the limited channel bandwidth. Next, we report on the sub-1 GHz data rates. In order to identify the upper boundaries, we added the results of IEEE 802.11n 2 × 2 MIMO ICMP throughput measurements taken at 2.4 GHz with chip-based Wi-Fi, at 1 MHz channel bandwidth by applying (5) and MCS rates from Table II. Fig. 7 summarizes the throughput measurement results. The highest throughput was measured at 91.31 kbps (MCS 10). Compared with the highest throughput for single antenna system (SISO), which we measured at 87.8 kbps (MCS 2) for ICMP, we conclude that MIMO indeed increases the performance (graphs not shown due to paucity of space and for brevity). In order to validate the sub-1 GHz WLAN throughput performance we compare the observed throughput with the theoretical throughput of IEEE 802.11n. Fig. 7 illustrates that the chip- based WLAN performance is 10 times higher compared to our proposed software-based WLAN platform, due to the real-time software decoding of captured WLAN signals that somewhat limits the performance. Finally, we report on the UDP and TCP transmission performance. Fig. 7 indicates the highest throughput for UDP measured at 64.7 kbps (MCS 10) and 50.2 kbps (MCS 10) for TCP. The reduction of UDP and TCP data rate is within a regime (30% for UDP, 45% for TCP) which is reasonable due to the increased protocol overhead and also due to the tunneling the captured datagram to the Linux network-stack in Hydra. The TCP performance gives us the insight that the MIMO-OFDM setup is reliable due to the data rate which is not significantly reduced compared to UDP (comparing ICMP, UDP, and TCP throughput performance at MCS 10 in Fig. 7). For operating in a shielded location with 1 m distance between the transmitters, the achieved performance gain is reasonable, which is somewhat limited in our selected experimental setup. V. C ONCLUSIONS In this article, we presented the ...