(Co-authored by Ahmed Ouameur)

GNU Radio is a flexible environment for developing software-defined radio (SDR) applications. GNU Radio can fully utilize the CPU power of a high-end computer to process data coming from or going to an external radio peripheral. This enables real-time SDR applications where the processing is all done in a computer.

It’s important that the physical link be able to keep up with the data flow required for the final application. Unpredictable physical-link throughput can badly affect the real-time performance of the SDR. When designing a system for a specific radio application, it’s important to consider the following two key items:

  • real-time data transfer where the radio head provides accurate symbols, slot and framing timing counters, real time interrupts and signaling, and FIFO storage status
  • real-time data transfer where the physical link (gigabit Ethernet, PCIe or SRIO, to name a few examples) will not impose limitations on the throughput, including control and status signaling overhead

In this post, we’ll focus on the second item; that is, the throughput of the computer-to-radio-head physical link (referred to in Figure 1 below as physical link for brevity). Correctly determining the bandwidth that’s required to support real-time data streaming to and from a radio head is very important. This is even more true when designing a MIMO application, since the throughput increases linearly with the number of RF front ends in the case where all the data must be transferred to and from the computer. In a typical MIMO application, the user will communicate with the hardware peripheral for a number of purposes, such as configuring the carrier and RF front-ends (local oscillator frequency, sampling frequency, gains, filters, and so on), as well as streaming data from and to the radio hardware.

 

Hardware configuration

 

The following figure below shows a MIMO SDR setup for a 2×2 MIMO application. We’ll refer to the carrier board and radios 1 and 2 as the radio head.

MIMO SDR setup for 2x2 MIMO applications

Both radio cards are connected to an FPGA carrier board through a high-pin-count FPGA mezzanine card (HPC FMC) connector. The FPGA carrier board is used to configure the radios, do signal preprocessing on the raw data signals, and provide a physical link interface for remote operations. In an SDR application, the computer needs to run signal processing algorithms on the preprocessing samples. GNU Radio is a powerful environment for developing such application, and it accelerates implementation time since many processing blocks are already available from its open-source community. In a real implementation, the data used in GNU Radio needs to come from the hard peripherals, and once processed needs to be sent back to it. For this reason, peripheral plug-in blocks should be used in GNU Radio. These blocks allow seamless implementation of all the physical link protocols. In order to have high throughput in GNU Radio, the physical link protocol must be designed carefully.

 

Physical Link

 

The physical link between the radio head and the computer carries RF samples which, briefly speaking, would make it appropriate in terms of sample interconnection standards. Organizations such as OBSAI

[1], CPRI [2] and VITA WG [3] have proposed sample interconnection standards that enable GNU radio development while ensuring computer and frond end interconnection operability. Interconnection standards can be compared against each other in terms of throughput, latency, computer support of the corresponding protocol, and low-cost availability. One interesting interconnection standard is USB 2.0, which is used in the Universal Softarware Radio Peripheral (USRP) [4] associated with the GNU Radio open source SDR project [5]. USB2 is cheap (low-cost availability), making it a baseline for gigabit Ethernet comparison. Another physical link is based on SRIO standards. This allows the use of doorbell interrupts to signal any real-time event or data FIFO status.

When it comes to gigabit Ethernet, there are numerous advantages: it’s both widely availabile and inexpensive; it runs efficiently in a wide range of system designs; it can take advantage of built in support in all operating systems; and there are plenty of good diagnostic tools available for it. VANU’s implementation of RF over Ethernet [6] is a good example of using gigabit Ethernet for sample interconnection while overcoming issues like latency, jitter, link and packet processing overhead, and packet loss that are related to this asynchronous interconnection standard.

 

Gigabit Ethernet: A Basic View

 

When streaming data, the throughput is important and it should not be wasted. The available bandwidth should prioritize the actual data over the headers transmitted with it.

The figure below illustrates an Ethernet packet designed for MIMO applications:

Ethernet packet designed for MIMO applications

To maximize the effective throughput of the physical link, the application should transmit only useful information in the header. In this packet, a basic Ethernet header is sent to identify the source and the destination of the packet. The mode tells the packet decoder whether the message content is a control command or radio data. In the case of a data message, the parameter section contains the channel ID of the radio, the packet data size, and a packet identifier used to detect packet loss. In this case, all headers can fit in 32 bytes.

The header has a fixed size while the data size can vary. To maximize the effective throughput, the data length should be far greater than the header size. If the data section contains 128 bytes, only 80% of the physical link capacity will be used for transmitting the RF data. For this reason, MIMO application should use Ethernet hardware that can handle jumbo frames. With these larger packets, the data can reach sizes of up to 8192 bytes. This represents an effective throughput of 99.6%.

Ethernet packets contain bursts of data, as opposed to radio peripherals that require a continuous data flow. To convert the data flow data from one form to the other, the application should implement first-in first-out (FIFO) memory in the carrier board to act as buffers.

Transmission (TX) channels receive data continuously from RF front-ends and send data bursts to the host computer. The buffer is filled with radio samples and once the packet data size is reached, the carrier board sends an Ethernet packet. It’s important that the host computer can keep up with the size and the rate of the packets sent by the carrier board.

Meanwhile, reception (RX) channels receive data bursts and send data continuously to RF front-ends. These buffers should never be empty since this causes discontinuities in the radio signal. Furthermore, if data bursts arrive too quickly, the buffer can overflow and data will be lost. This also produces discontinuities. Flow control on the reception side should be implemented to avoid this problem.

To implement flow control, specific messages need to be sent to the transmitting device in order to indicate the RX buffer status. When the buffer is almost full, a message is sent to tell the transmitting device to stop sending new packets so that the RX buffer doesn’t overflow. Once the buffer has room for new packets, a message is sent to tell the transmitting device to start sending packets again.

The timing for this section is critical and the right buffer size must be used. The buffer size should be large enough to contain many packets at the same time. Since jumbo frame packets are a good solution for throughput optimization, the buffer size needs to be huge. The full-buffer threshold needs to be a few packets less than the real FIFO size so that the buffer can still accept newly sent packets. The flow control messages are not instantaneous, so the FIFO must take this into account. On the other hand, the flow control message that tells the transmitter to start sending data again should be sent before the buffer is empty to prevent discontinuities in the data flow.

For example, 128 KB FIFO could have a full threshold at 96 KB and deactivate the full flag at 32 KB. This allows four packets to be sent between the time the flow control message is sent and the transmitting device stops transmitting, and the same number of packets before the buffer is empty. This means that two flow control messages are sent in the time 64 KB of data are transmitted. These messages use the same physical link bandwidth as the data flow and their impact should be analyzed. Each flow control message is 5 bytes long. Since jumbo frames are used and the FIFO is big enough, the impact is very low (< 0.02%) and can be ignored.

 

MIMO Applications

 

The maximum sampling rate of a MIMO 2×2 application can be calculated as follows. The gigabit Ethernet link theoretically allows 1 Gbps in both directions (full-duplex link). Since our effective throughput is 99.6% because of the efficient header size, this brings the useful physical link bandwidth down to 996 Mbps.

Both radios can operate on 12-bit samples, I and Q components being interleaved, at a maximum sampling frequency of

sampling rate that allows development of SDR application like MIMO 2x2 LTE with 20 MHz equation

This sampling rate allows development of SDR applications like MIMO 2×2 LTE with 20 MHz bandwidth that requires a sampling rate of 30.72 MHz [7].

To easily handle data that doesn’t occupy an integer number of bytes, the application can use the next larger integer number of bytes. In this case 12-bit samples are stored in 16 bits. This reduces the effective bandwidth and will lower the calculated maximal sampling frequency to 31.125 MHz. This new frequency is theoretically the maximal sampling frequency, and designing LTE applications with 20 MHz is way too risky since the Ethernet is not guaranteed to run at its maximum throughput.

To use the all the available bits and not lose 75% of the effective bandwidth uselessly, the application should implement a sample packer and unpacker in GNU Radio and in the carrier board. Another way to maintain the throughput is to use a faster physical link like PCI express, so that bit packing is no longer required.

 

Conclusion

 

When designing SDR applications, the bandwidth of the physical link between the processing unit and the hardware is critical. The bandwidth information of the physical link is not enough to be sure that it is suited for your application. The effective bandwidth including the communication overhead should be taken into account. For this reason, message headers should be kept small compared to the data.

References

  1. http://www.obsai.org
  2. http://www.cpri.info
  3. http://www.digitalif.org
  4. http://home.ettus.com/usrp/usrp_guide.html
  5. http://www.gnu.org/software/gnuradio
  6. Britton, Gerald, Byron Kubert, and John Chapin. 2005. “RF Over Ethernet for Wireless Infrastructure.” SDR05, SDR Forum Technical Conference.
  7. Telesystem Innovations Inc. 2010. “LTE in a Nutshell: The Physical Layer.” White paper. http://www.tsiwireless.com/docs/whitepapers/LTE%20in%20a%20Nutshell%20-%20Physical%20Layer.pdf