Page 1 of 1
Software radio architectures have traditionally taken a hardware-oriented approach, driven by the signal processing capabilities of the underlying processing platform. SDR systems have typically been designed around a combination of processing technologies such as DSPs, FPGAs and other specialized reconfigurable processing devices. The other aspects of the system architecture, such as the RF, analog-to-digital conversion and the system I/O, are then designed around the capabilities and limitations of the processing devices.
Unfortunately, the software architecture itself is often an afterthought, and consists of several different development and operating environments to accommodate the processing elements in the system. This approach results in a complex software development and operating environment, which significantly increases cost, development time, portability and software flexibility. As the underlying processing devices continue to improve, more of the system complexity gets moved into software, increasing the penalty associated with a poor software architecture.
A better approach is to focus on the software architecture first, using a distributed computing, open operating system, and an object-oriented methodology. In this way, COTS hardware can easily be introduced and spiraled via technology refresh. This software-driven SDR design approach has nicely evolved over the past decade. Its evolution can be traced by following the path from a university research project called SpectrumWare to the first commercial deployment of an SDR-based cellular network using industry-standard servers.
The SpectrumWare project applied a software-oriented wireless communications approach with distributed signal processing. The research direction of the SpectrumWare project was heavily influenced by two software radio efforts: the military SpeakEasy project and the commercial products of the Steinbrecher Corporation.
According to Upmal and Lackey in “SPEAKeasy, the Military Software Radio” IEEE Communications Magazine (NY: IEEE Press) 1995, the SpeakEasy project was started in 1991 and was the first large-scale software radio. SpeakEasy was motivated in large part by the communications interoperability problems that resulted from different branches of the military services having dissimilar (non-interoperable) radio systems. This lack of communications interoperability can be directly linked to casualties in several conflicts. SpeakEasy had a very aggressive goal of implementing ten different radio waveforms in software on a single platform. The designers chose the fastest DSP available at the time, the Texas Instruments TMS320C40 processor, which ran at 40 MHz. Since this was not enough processing power to implement all of the waveform processing, the system boards were designed to each support four ’C40s as well as some FPGAs.
In 1994, Phase I was successfully demonstrated; however it involved several hundred processors and filled the back of a truck. Moore’s Law provides a doubling in speed every eighteen months, and since it had taken three years to build the system and write all of the software, two doublings had taken place. This seemed to indicate that the number of processors could be reduced by a factor of four. However, SpeakEasy could not take advantage of these newer faster processors, and the reason was the software.
The software was tied to ’C40 assembly language, plus all of the specialized glue code to get four C40s to work together with the code for the particular chosen FGPA. The observation was that it had taken three years to write software for a platform that Moore’s Law made obsolete in eighteen months. Further-more, a software radio pushes most of the complexity of the radio into software, so the software development could easily become the largest, most expensive part of the system. These observations led to software portability being a key goal of the SpectrumWare project.
As long as Moore’s Law continues, software that is tied to a specific processor or platform will be obsolete before it even comes to market. Software portability has a second benefit: to allow waveforms to be quickly ported to processors for new applications. Examples might be low-power processors for handheld applications or high-powered servers for infrastructure applications.
More Hardware Limitations
Steinbrecher Corporation produced a commercial software-based TDMA base station in the early ’90s. One of the major technical challenges that they faced was obtaining A/D converters with sufficient spurious-free dynamic range to digitize wide bands of cellular spectrum and be able to resolve weak signals in the presence of strong signals on adjacent channels.
At the time, Steinbrecher paid a premium to hand pick the output of Analog Devices A/D converter line to obtain the converters that met the demanding cellular specifications. Steinbrecher also faced a number of market-related challenges, including closed proprietary network interfaces, market skepticism regarding software radio in general and the long sales cycles to carriers.
These factors indicated that the SpectrumWare project needed to take a 10-year outlook. Time would solve the A/D spurious-free dynamic range issue, and even once a system was working, there would be several years of testing, trial deployments and technology validation. The time frame for commercialization of the technology needed to coincide with the improvement in underlying technologies and market acceptance of the concepts.
SpectrumWare, a DARPA-sponsored MIT research project, was formed in 1994 to investigate the potential for building software radio systems that implemented as much as possible in software, while leveraging Moore’s Law and the price performance curves of industry standard servers. (D. L. Tennenhouse, V. G. Bose, “The SpectrumWare Approach to Wireless Signal Processing,” Wireless Networks, Volume 2, No. 1, 1996; and V. Bose, M. Ismert, M. Welborn, J. Guttag, “Virtual Radios,” IEEE/JSAC, Special Issue on Software Radios, April 1999.) The SpectrumWare research direction was heavily influenced by the lessons learned from early software radio research and development in both the commercial and military sectors. Since the formation of Vanu, Inc. in 1998 to commercialize this research, the feasibility and price/performance of software radio has seen tremendous gains due to advances in underlying technology such as A/D converters, multi-carrier power amplifiers, processors and operating systems.
The SpectrumWare architecture is illustrated in Figure 1. The architecture consists of a front-end that is responsible for RF up/down conversion and well as A/D and D/A conversion. The system I/O was handled by a PCI-bus DMA engine called the GuPPI (M. Ismert, “Making Commodity PCs Fit for Signal Processing,” USENIX ‘98, New Orleans, June 1998), and the processing was implemented on a standard PC running Linux. There were small extensions to the OS to implement a zero-copy I/O scheme to reduce the processor overhead required for data transfer. This architecture was designed to support a portable object-oriented software architecture, as well as leverage high-volume commercial components.
While this platform was not the most powerful SDR platform of its time, Moore’s Law and the 10-year time horizon combined to place the emphasis of the SpectrumWare project on software engineering. The ultimate product would run on hardware that was very different than the research and development systems, and as processors got faster, more of the complexity of the system effectiveness, time-to-market and reliability of the software radio systems would flow from the software engineering methodologies that were put in place in the early stages of the research.
SpectrumWare was unique in adopting a software-first design approach to software radio systems. Most efforts, like SpeakEasy, took the best processing technology of the day and built an architecture around those capabilities. By contrast, the SpectrumWare approach was to create a software radio architecture that would scale with technology and provide software portability into the future, and the hardware choices followed from the software architecture design decisions. Two key decisions that were made in support of software portability, reusability and development efficiency were to use a fully featured operating system and an object-oriented software design methodology. Both of these decisions were very different from the way signal processing systems were built at the time.
Traditionally, fully featured operating systems and object-oriented design lead to some implementation inefficiencies and system overhead. However, looking to the future, processors, memory and I/O subsystems would all get cheaper and faster, so these design tradeoffs would become more attractive with the passage of time. Furthermore, the benefit of software portability, the ability to take waveforms and quickly bring them up on newer, faster platforms would provide tremendous cost and time-to-market benefits in the future.
The first SpectrumWare system received AMPS cellular telephone calls. It digitized one of the 12.5 MHz cellular bands, and in software selected out a 30 kHz channel and performed all of the voice and data processing for the channel on a standard PC. It took all of the fastest CPU available at the time to process a single channel, and the result was viewed by some as the most expensive analog cell phone ever built. However, the system was designed to scale with Moore’s Law, and today a single HP ProLiant server can process 32 GSM traffic channels simultaneously, validating the scalability and portability of the architecture.
From Research Lab to Commercialization
In 1998, Vanu, Inc. was formed to commercialize the SpectrumWare research, and set out to examine commercial applications of the technology. Based on the lessons learned from the SpectrumWare experience, a new software infrastructure was designed (Figure 2). This architecture kept several features from SpectrumWare, such as the fully featured operating system, object-oriented design and software portability. One of the major changes was to separate the high-speed signal processing software from the code for control and configuration. This enhanced portability and software reuse, since the control code was implemented in an interpreted language.
In bringing this technology to the commercial infrastructure market, there were significant technical and market barriers that had to be overcome. In early discussions with wireless carriers—in particular BellSouth—it became apparent that there was interest in the potential of software radio, but there were some significant hurdles that had to be overcome in order to turn it into a viable product for the commercial infrastructure.
In particular, the scalability and reliability of the system needed to be addressed. It was clear that productization of the technology would require additional research, and Vanu, Inc. acquired an SBIR grant from the NSF to support this work. The challenge was to address the scalability and reliability without losing the advantages of software portability, and riding the price performance curves of industry standard equipment driven by Moore’s Law.
Scalability was addressed by extending existing distributed computation techniques to handle the high bandwidth, low latency and real-time constraints of software radio applications. In order to ride the IT price/performance curves, significant effort was made to realize a solution that consisted solely of COTS servers and networking equipment.
Achieving sufficient reliability while solely utilizing COTS equipment was considerably more challenging. A key observation simplified this task: Even in a Vanu Software Radio system that is running multiple standards simultaneously, such as GSM and CDMA, the hardware is generic. The same servers are used to process the different standards. So rather than build in redundancy per standard, the same result can be achieved by having redundant generic servers, with multiple instantiations of software on each backup machine. This approach allows less overall hardware to achieve the same level of reliability.
Furthermore, when coupled with scalability, customers are able make a cost/reliability tradeoff. The level of reliability is proportional to the number of backup servers added to the network, so it is fairly straightforward to provide a cost/reliability tradeoff for the customer by configuring the system with the appropriate number of backup servers.
Real World SDR Using “Pizza Box” Servers
The major marketing challenge was to convince network operators that a robust radio access network could
actually be built from industry standard servers and networking equipment, and that a new software base station, when properly implemented, can facilitate operational features such as hand-off management and power control. The only way to validate these capabilities was to deploy a live network trial. The company chosen for the trial was Mid-Tex cellular, a rural operator based in DeLeon Texas. The company was interested in the multi-mode capability of software radio infrastructure, something that would enable them to become roaming partners with both TDMA and GSM carriers.
The trial installation consisted of two base station transceivers (BTS) and a base station controller (BSC), with each running on an industry standard Hewlett Packard ProLiant DL380 server with dual Intel Xeon 2.8 GHz processors. All of the signal processing, protocol processing and BSC functionality was implemented as application level software running on top of the Linux operating system (Figure 3).
The system was implemented in C++, which allowed for implementation of the whole system, from high-performance signal processing code to network protocols to high-level control, in one language. Open-source tools and libraries were also used extensively.
After the initial installation of the equipment and tests to ensure that it was functioning properly, engineers spent three consecutive weeks at the Mid-Tex site to test and improve the system until it was ready for Mid-Tex to trial. This was the first field trial of the software GSM base station in a live outdoor environment. All prior testing was in a controlled lab environment. The tests were performed onsite using commercial, off-the-shelf GSM phones that supported GSM in the 850 MHz cellular band. Most of the tests consisted of drive tests with the phones. These tests were used to exercise handover, power control and timing advance, as well as to determine the coverage area.
Using off-the-shelf servers and the Linux operating system streamlined the development and deployment process. Capabilities such as log retrieval and remote software installation were built into these commodity components, meaning these did not have to be custom-developed. Additionally, as bugs were found in the system, fixes to the software could be downloaded remotely in Texas from the office in Massachusetts.
It has been almost ten years since the beginning of the SpectrumWare project. The feasibility of software radio has been greatly enhanced by advances in processors, A/D converters and the availability of RF chipsets. These advances have improved market acceptance of software radio. The military is aggressively pursuing software radio as evidenced by the JTRS program, and commercial carriers are starting to look at the potential for software radio technology in their networks.
The SpectrumWare approach anticipated rapid advances in the underlying technology and focused its design effort on a software architecture that supported portable and reusable code. The Vanu Software Radio base station has leveraged several generations of technology improvement that has resulted in improved performance and lower cost for customers, without a significant re-investment in software development. The commercial success of the Vanu Software Radio system is validation of the SpectrumWare approach of letting the software constraints drive the design of the software radio architecture.