For the PDF version of this article, click here.

Today's wireless industry is rapidly expanding with multiple standards and devices. New wireless technologies are being introduced at a progressively increasing pace. Consumers have come to expect mobile phones with multifunctionality; they want to talk, receive e-mail and download videos from a single, portable device. The impact of globalization has created the need for these devices to reliably function and communicate from Japan to England to the United States. All the while, designers and manufacturers must find a way to flexibly and cost-effectively develop the technology.

It is clear that the face of the wireless industry is changing and becoming more complex. Software-defined radio (SDR), a communications device whose operation from the physical layer through higher-level protocol layers is principally defined in software, provides a framework to enable this change. It supports multiband-multimode radios, global roaming, runtime reconfigurability and over-the-air-programming, alleviating issues arising with the deployment of new communications standards. SDR provides the flexibility of changing a radio's operational ability simply by changing the software code in the device's processing hardware. SDR has additional benefits such as improving spectrum utilization to further increase the technology's value.

SDR has promoted advances by the U.S. Department of Defense's Joint Tactical Radio System (JTRS)^[1], Defense Advanced Research Projects Agency's (DARPA) neXt Generation (XG) Communications program^[2], and the Federal Communications Commission's (FCC) Cognitive Radio Technology Proceedings^[3]. Now, SDR is making moves into the consumer market, streamlining design cycles and introducing a gamut of new applications. However, SDR developers face a special challenge when testing and validating their designs, and require robust, flexible testing tools that are as robust and flexible as the technology itself. This article explores these challenges and provides test solutions for the issues posed.

SDR achieves the goal of supporting all different standards and technologies by providing a common radio architecture. Championed by the JTRS program, the Software Communications Architecture (SCA)^[1] has been adopted as the standard software radio architecture for military communications systems. The SCA is an open architecture framework that ensures portability, reusability and scalability of software and hardware components as well as interoperability of products developed under its guidelines. The SCA will ultimately impact the commercial radio communications sector because commercial architectures will include most of the functionality already considered in the SCA. The problems and challenges that SCA implementations are now overcoming are similar to those that commercial implementations will encounter later. Already the SCA has extended into the commercial world and forms the basis of the SDR Forum's Software Radio Architecture (SRA)^[4].

However, the flexibility that allows SDR to support disparate technologies and standards sets unseen challenges in SDR design validation and final product verification. The difficulty of testing SDR arises in the huge number of different modules that interact together. The resulting number of component combinations makes it difficult to verify the correct performance of every single individual set without having a flexible test setup. In order to achieve efficient design and rapid product development, it is necessary to provide developers with flexible testing tools.

As SDR applications begin to achieve the runtime reconfigurability and over-the-air programming that is foreseen, more and more modules will be expected to interact within the context of a single waveform. Current implementations of SDR are flexible enough that simply changing the contents of a configuration file can change an application waveform. The large number of different software modules that can be combined to interact at any given point in time sets a test and validation challenge for designers and manufacturers.

After system-level simulation is completed and the software module functionality has been validated, it is time for deployment on real hardware. There are many sources of errors that can affect the correct performance of a particular device. Particularly, hardware flaws, software bugs and design miscalculations can appear and need to be caught during the multiple stages of the SDR development cycle. More realistic testing leads to more reliable operation of SDR.

Instruments, especially those geared for wireless applications, can be part of the toolsets required for designing and testing future software radios. Integrating test equipment into the SCA provides the ability to create an abstraction for the different components in the system, allowing the components to interact regardless of their fundamental implementations; expand the application's self-test scope and ensure a more reliable diagnostic of the overall system; and provide a seamless transition from a simulation environment to deployment. The following examples outline two of these methods.

Arbitrary waveform generators (AWG) bring testing capabilities one step closer to a real over-the-air operational environment by providing a source of analog and digital signals as well as noise and modulation for SDR receiver testing. The digital output of the AWG can be used to stimulate digital circuitry or simulate the performance of an ADC. Further benefits are obtained when the AWG is integrated into the application waveform of an SDR device. This integration enables the core framework to control the AWG in the same manner that it controls any other software component or device. This way, an AWG can be included in the application waveform by only modifying an extensible markup language (XML) file.

Consequently, a specialized application can be developed to test any given set of components. When a new set of components is combined to comprise a certain application, a modified version of the same waveform that includes test modules can be used to test and validate the performance of the original modules. In addition, code used by previous test beds can be reused almost seamlessly by copying the core functionality of the legacy code into the new test module.

To integrate an AWG into an application waveform developed under SCA guidelines, it is necessary to instantiate a proxy component that will work as an adapter between the AWG, the core framework and the waveform components. This adapter, or wrapper, inherits from the “loadable device” class as specified in the SCA. This inheritance enables the adapter to allocate and de-allocate certain capacities, and gives it the interface to load and unload predefined waveforms into the generator's waveform memory. These capacities, configured at instantiation time, represent physical characteristics of the AWG, and are described in an extensible markup language (XML) file.

The wrapper needs its own IDL interface in order to interact with other components. This interface provides an entry point to handle middleware calls. The wrapper waits and responds to any calls made by the application.

Once the wrapper is instantiated and initialized, the application waveform allocates the requested capacities, loads the required waveform, implements the necessary inter-component connections, and starts all the components, including the AWG. The waveform file to load into the waveform memory can be created using the AWG's built-in tools for waveform editing or even using other specialized tools, such as MATLAB. In order to integrate the AWG into an existing waveform, it is necessary to modify the application's software assembly descriptor (SAD) file to include the wrapper as a component and describe the necessary connections. As shown in Figure 3, the AWG can be connected in different stages of the receiver path to better isolate a specific module or modules for testing.

When the application waveform is created, it performs the initialization and configuration of the equipment as well as all testing functions required to verify the correct performance of the application. The application itself is responsible for performing tests on the intended component or set of components. The application provides the test data, transfers it into the AWG, which then sends the data to the components being tested. The application monitors the tested components and verifies their correct behavior. In the event of a failure, the application can trigger an alarm and log a record. Logged information along with the knowledge of a fault source allows for more accurate debugging.

With the FCC's regulations of spectrum use, validation of SDR waveforms becomes a crucial part of the development cycle. As with any digital radio there are many possible sources of operational errors, such as spurious components derived from non-linearities at the power amplifier, clipping of the signal at the digital to analog converter (DAC), phase truncation and periodic jitter. In the case of SDR, the problem gets magnified as each different set of software components that comprise an application waveform has to be validated. As SDR applications start implementing more waveforms and standards, which may also occupy different frequency bands, the validation process becomes more complicated and demands higher flexibility from the test equipment. Given the expected trends in SDR development, the scenario only becomes more demanding as technology progresses. The implementation of different technologies that rely on cognitive radio features, such as the XG program^[2], requires strict and adaptive validation given that non-conformance to the regulations can cause serious performance issues for the involved systems.

Real-time spectrum analyzers (RTSA) are ideal for testing and validating radio transmitters. With RF signals using complex modulation and signal changes, keeping pace with the time-varying nature of signals is crucial. Due to the architectural limitations of the triggering and memory bufffering systems of traditional spectrum analyzers and vector signal analyzers, these tools have a low confidence and high uncertainty capturing time-variant events. Similar to the AWG, RTSAs require adapter components and an IDL interface.

Even though there are no software load capacities generally defined in test equipment, the adapter itself can read a configuration file and then “load” this configuration into an instrument. This loadable behavior allows for a simplified procedure to configure the RTSA to be integrated into an SCA framework. The content and format of the configuration files are application-dependent. In order to support legacy test code, the content of the configuration file can be the configuration scripts used by the previous test bed. By using this loadable approach, every time an application waveform is instantiated, the corresponding configuration file can be loaded, setting the RTSA in the correct acquisition mode, center frequency, frequency span and whatever other attributes may be relevant. As with any other SCA device, the wrapper for the RTSA is required to have a set of operational capacities to allocate and de-allocate during runtime. For the case of the RTSA, the allocation capacities could be as simple as a single property that indicates if the analyzer is available for use or if it has been engaged for operation with another waveform.

SDR design presents unseen test challenges and requires a flexible approach to integration and subsystem and system validation. By leveraging the inherent features of the SCA, an integrated approach to test methods facilitates a seamless design to deployment process. Creating software wrappers around test equipment and into the defining waveform of an SDR application facilitates and accelerates this process for SDR communication devices.

With the proliferation of SDR devices in the commercial market, traditional equipment used for designing and testing wireless technologies will soon be obsolete. SDR is leapfrogging the wireless industry and requires new design methodologies. RF and wireless test equipment must provide solutions for the SDR field by integrating analysis, measurement and probe equipment into the SCA framework.

1. JTRS Program, http://jtrs.army.mil/.

2. XG Program, http://www.darpa.mil/ato/programs/XG/.

3. FCC Cognitive Radio Technologies Proceeding (CRTP), http://www.fcc.gov/oet/cognitiveradio/.

4. SDR Forum, http://www.sdrforum.org/.

Darren McCarthy is a market development manager for RF test at Tektronix. He has worked extensively in various test and measurement positions for the last 17 years including R&D engineer, R&D management, product planning, and business development. During his career, McCarthy has also represented the United States on several IEC technical committees for international EMC standards. He holds a BSEE from Northwestern University in Evanston, IL.