You can understand how MIMO works, at least in broad terms, with a simple thought experiment. Suppose you set up a transmitter with a single antenna and then move a receiver, also with a single antenna, far enough away for the reception to fade in and out once in a while. Such problems arise because the transmitted signal takes multiple routes to the receiver—some of it perhaps bouncing off a passing car, other parts reflecting off the steel beams of the building where the receiver is located. When the difference in length between two paths is half a wavelength (or three halves, or five halves, and so forth), the two waves will interfere destructively, clobbering the signal.
MIMO sidesteps that pitfall by multiplying the number of possible paths between transmitter and receiver. If the signal passed from one transmitting antenna to one receiving antenna fades, the signal from a different pair should still come in loud and clear, taking advantage of a phenomenon known to radio designers as transmit diversity.
Throw in some serious number crunching to process the digitized signals and you can achieve extraordinarily high data rates. Researchers at NTT DoCoMo, in Japan, which is developing such systems for 4G mobile communications, have managed 5 gigabits per second. And this wasn’t just in a controlled laboratory setting; they achieved this rate outdoors, albeit with the receiver moving no faster than a swift walking pace (doing the same while traveling down the highway would be much more difficult). Impressive results with MIMO and other advanced antenna systems are also coming out of Stanford’s Information Systems Laboratory, MIT’s Lincoln Laboratory, and the Center for TeleInfrastructure at Aalborg University, in Denmark.
Another tricky issue for the makers of SDR handsets is designing the transmitter’s power amplifier so that it can operate over a broad range of frequencies without mangling the signal. The challenge is not so great for FM transmission, but for communication schemes that require the amplitude of the wave to be manipulated, things can rapidly go awry.
Avoiding problems in such cases typically requires some kind of feedback mechanism. You can, for example, sample the output of the power amplifier and convert this RF signal to lower frequencies, which you can then compare with the signals used to modulate the amplifier. You can then compensate for any error you find by digitally adding the reverse distortion to the input signal. Among the leading manufacturers of such designs are RF Micro Devices, in Greensboro, N.C.; Acco Semiconductor, in Saint-Germain-en-Laye, France; and Axiom MicroDevices, in Irvine, Calif.
Another challenge for SDR designers is making much faster ADCs. To avoid “aliasing”—the effect that makes rapidly spinning wagon wheels in old Westerns look as though they’re turning slowly, or even backward—the ADC must sample the signal at a rate at least twice that of the highest-frequency component, and this may be quite high. The upcoming 4G technologies, for example, are expected to operate in the vicinity of 3.5 gigahertz, which means you’d need to take 7 billion samples per second—more than 10 times as fast as what today’s best ADCs of sufficient resolution can manage.
Many SDR researchers consider this to be among the toughest obstacles ahead—not only because they must up the sampling rate so much but also because they’ll simultaneously need to make significant improvements in the signal-to-noise ratio, power consumption, and physical size of this circuitry. Typically, you can better one of these parameters only by making trade-offs with the others. So achieving gains on all fronts at once is going to be extremely difficult.
There is, however, a strategy that might allow direct conversion of RF in the not-so-distant future: purposeful subsampling. The trick here is to arrange the sampling frequency of the ADC so that the inevitable aliasing that occurs works to your advantage. In one step, the operation both digitizes the RF signal and converts it to a lower frequency. This may seem a bit magical, but it’s not so hard to understand. Just imagine the RF signal as one of those rapidly spinning wagon wheels. Adjust the frame rate of the motion-picture camera appropriately and your captured version of this wheel will turn at whatever lower frequency you want [see “Aliasing Harnessed”].
Astute readers might notice that the difficulties we’ve outlined so far all involve hardware. Software-defined handsets will have some challenging software, too. It’ll manage the modulation, demodulation, encoding, decoding, encryption, and decryption, as well as the packing and unpacking of the data needed for the communications protocol employed—all computationally intensive tasks. What’s the best kind of microprocessor for such heavy lifting?
Most SDR designers struggling with that question instinctively fixate on the MIPS rate—how many million instructions per second the processor can execute. That’s because it must carry out a huge number of arithmetic operations—largely multiplications and additions—to massage the digitized signal. Specialized digital signal processors (DSPs) are usually the best chips for such things, but they may not be the only solution for SDR handsets. The reason is that these radios must do other kinds of signal processing, too.
In particular, SDR handsets need to detect and correct errors in the received digital bit stream, and the algorithms for that consist less of multiplications and additions than of “if-then-else” statements. Those branching operations are better done by a general-purpose processor, which would normally also be assigned the tasks of running the unit’s real-time operating system, keyboard, and display. So a software-defined handset will need to have such a chip around anyway.
A general-purpose processor will also be required to host the software interfaces that connect different applications with the underlying hardware. In the near term at least, that “middleware” is likely to conform to the rules laid out in the U.S. military’s Software Communications Architecture, an object-oriented computing framework that has become the de facto standard for software radios intended for combat use.
Designers of future SDR handsets will revel in the flexibility afforded by having the software control so much of the signal processing. And designers will no doubt want as much of the set’s hardware as possible to be reconfigurable—that is, they’ll want software to do not only signal processing but also be able to switch between different antennas and RF front ends. Such capability would allow you to turn a cellphone into a satellite-radio receiver, say, at the touch of a button.
While the technology for accomplishing this has been around for years, until now it’s been too bulky and power hungry to be used in handsets. But consumers are now on the verge of enjoying the fruits of this approach, implemented with modest amounts of power and in very small packages. In February 2008, BitWave Semiconductor, of Lowell, Mass., announced its BW 1102 Softransceiver RFIC, a chip intended to bring SDR to both cellphones and femtocells (small wireless base stations that can be set up in a home or business to improve cellular coverage indoors). The BW 1102 is a single complementary metal-oxide-semiconductor integrated circuit containing a transceiver that supports a variety of wireless protocols and can operate anywhere on the spectrum from 700 MHz to 3.8 GHz.
Suppose, however, that you are a radio designer and want more than BitWave’s chip can handle, such as the ability to receive FM broadcasts—and maybe even transmit on FM, too, so that you can play your favorite MP3 files on your car radio. How hard would it be to create the perfect IC for that? Hard indeed, it turns out, and that’s why BitWave still has essentially no competitors.
But let’s say you’re keen to try. You might start by estimating the allowable execution time for each of the radio’s intended functions and its power consumption, physical size, and other properties, including the frequency bands to be covered. Based on that assessment, you’d decide how to divide the overall system into hardware and software. Although this exercise isn’t trivial, tools for hardware-software codesign are available.