Hardware needs limit software radio

The ultimate goal of software radio design is to build a device flexible enough to run every possible waveform, without restrictions on operating frequency range, signal bandwidth, modulation scheme, data rate, networking requirements, etc., while adequately addressing collocation issues and radio channel impairments, and all of these must be achieved simply by changing its software.

Since 1995, when Joseph Mitola III first coined this term, extensive research and development efforts have been invested toward this goal, leaded by the JTRS JPO and the SDR Forum. As of today, these efforts led to significant progress in software communication architecture (SCA), but yielded little in other areas. As a result, many radio functions that are critical in implementing a successful, high performance radio design, cannot be considered as software implementable. Antennas, power amplifiers, oscillators, passive filters, power supplies, to name just a few of these functions, must still be implemented in hardware, yet these functions add up to a significant fraction of the radio system development and production costs, as well as to radio size and weight.

This paper presents major design and implementation issues and reaches the conclusion that even using intensive software processing, the attempt to design a real world software radio will result, contrary to common expectations, in a big, heavy, power hungry and very expensive device. Actually, it seems that radio hardware design engineering expertise is ever more relevant and challenging in the software radio world.

Physics or Mathematics?
First, let's define what is to be considered a physical operation and what a mathematical one. Energy transformation (occurring in any microphone, loudspeaker, etc.) is obviously a physical operation. Clock signal generation —creating periodic oscillations of an electrical signal —is also a physical operation, because it exploits electrical or electromechanical resonance phenomena.

Operations on data represented as input and output files (for example, numerical arrays), in which the output data is determined by an arbitrary user defined function of the input data, are obviously mathematical operations. Such operations are routinely carried out in today's electronic equipment by software using an embedded digital computing platform. Input files are created in the normal course of equipment operation or received from other devices. For example, most of the baseband signal processing in a contemporary radio system is mathematically performed by software. Complex networking algorithms are also routinely implemented in software.

Hardware Challenges of Ideal Software Radio
ADC and DAC
The common perception of the ideal software radio (ISWR) is that its receive path samples the analog input signal at the antenna connector, and converts it to a mathematically processable format by means of an analog to digital converter (ADC). The transmit path is expected to use a DAC to convert digital data to an analog transmit signal that is then applied to the antenna connector.

It is often suggested that only the technological limitations of the ADC and DAC components are barriers on the way to a successful ISWR implementation. Thus, sometime in the future, it is expected that the ongoing process of technologically improving ADC and DAC components will remove these limitations and a true software radio will be within reach.

But, to anyone familiar with ADC and DAC functions, this is a clear misconception. Actually, ADC and DAC components are complex analog devices performing linear conversion of input signals. Even today, suitable devices can be built using discrete parts. However, such implementations will be very costly in terms of materials, space, and power consumption. On the other hand, despite the rapid pace of progress in semiconductor technology (whether based on silicon or other materials), the integration of truly high power signal handling circuits on the same chip with low level processing devices does not seem to become practical in the foreseeable future.

Anyway, we will show below that an ISWR implementation based on A/D and D/A conversion suffers from inherent drawbacks.

The Transmit Path
Let's start with the transmission path, using the generic block diagram of an ISWR transmitter shown in Figure 1 for reference.

1. ISWR Transmitter

In the architecture of Figure 1, the output DAC performs pure physical, analog operations: it accepts a digital data stream, and accurately converts it to an analog signal of sufficient magnitude (power) for transmission by means of an antenna.

One problem with this architecture is that software processing must be carried out at a frequency at least twice the carrier frequency. For example, to implement an IEEE 802.11a compliant device, the required processing speed will exceed 11 Gsamples/second! Today, and in any foreseeable future, the digital processing of signals is carried out at baseband or at IF (intermediate frequency), and the processed signal is then upconverted to the higher RF frequency with the help of a frequency synthesizer. Even if hardware (including DACs) fast enough to allow purely digital implementation of the signal processing functions at the final RF frequency will be available in the far future, we will still have great difficulties in connecting the DAC directly to the antenna.

Obviously, in any practical implementation, the DAC backend must possess the characteristics of an RF power amplifier (PA). Namely, it is expected to provide the necessary performance (output power, harmonics and spurious levels, noise floor, etc.) over the whole frequency range of interest for the ISWR.

The PA fulfills a very important function: it converts the input DC power provided by a battery or other DC power source, into an accurate replica of the signal to be transmitted. Integrated circuits (IC) have on chip power transistors capable to provide a few tens of milliwatts: if higher power is required, external transistors are used. Anyway, additional functions are always needed in any practical implementation: these include smoothing (filtering out the unavoidable spectral artifacts that are a result of discrete signal representation), impedance matching, power combining, harmonics filtering, RF power control (ALC), DC power regulation, and other analog circuits. And almost all of these functions are either frequency dependent or bandwidth limited.

The inescapable conclusion is that our ideal transmitter DAC must be replaced by the more practical equivalent shown in Figure 2.

2. Practical Implementation of Ideal DAC Functionality Thus, we will have to design a software transmitter, without getting rid of any current aspect of analog transmitter hardware design. Unfortunately, now we must also solve new problems, especially with respect to the higher noise floor level, which is due to the poor spurious free dynamic range (SFDR) performance of high speed DACs.

The major RF power amplifier design challenge is heat dissipation (heat is due to losses inherent in the DC to RF power conversion process). Current PA efficiency ranges from 40 to 10 percents when linear amplification is required, even using different linearization techniques. The required linearity depends on the modulation scheme employed in a radio system. The OFDM scheme, regarded as a critical component of the JTRS wideband networking waveform (WNW), requires very high PA linearity, even when clipping and forward error correction (FEC) are used to optimize overall system performance.

The need for an appropriately dimensioned heatsink, capable of dissipating the power generated by internal losses within the radio system, greatly affects radio set size. As a general statement, radio set size depends to a great extent on its RF power output. This statement stems from the very basic fact that the whole physical envelope of a radio set is used to dissipate power (heat pipe technology just helps transport the heat to the envelope). The statement, which holds true for any radio, including a software radio, may easily prove a major limiting factor in multi channel radio[2].

The Receive Path
Many suggest that the real opportunity for software to contribute to a radio system's success is in the receive path, because most of the signal processing functions are performed in the receive path. Yet, some functions in the receive path are strictly physical and therefore are better implemented using passive (analog) devices. This approach is especially effective when considering power consumption in battery operated equipment. Our argument is based on the generic block diagram of an ISWR receiver, shown in Figure 3.

3. Software Receiver