Architecture

Software architecture across all systems

Waveform implementations have two parts that face significantly different portability challenges. The control part configures and controls the system, and implements higher level functions such as protocol state machines and network routing. The signal processing part implements the high speed transforms between user data and a sampled representation of a RF waveform. The software architecture, shown in Figure 1, illustrates how Vanu Software Radio builds these two parts upon a common operating system.

The Operating System layer is critical to the design approach because it isolates the signal processing application from the hardware and thereby significantly improves its portability. Vanu, Inc. systems place no unusual demands on the operating system. Any POSIX compliant operating system that supports high data rate transfers between applications and the underlying hardware can be used. The current implementation runs on Linux and on the real-time operating system QNX.

The signal processing component consists of the Sprockit™ middleware layer which performs data movement and module integration, and a library of signal processing modules for functions such as FM modulation, Viterbi encoding, or FIR filtering.

The control component is a portable, well-modularized C and C++ application. Where possible, software components are automatically generated from higher level descriptions such as state charts, which reduces design time and increases assurance.

Hardware architecture across all systems

The hardware architecture, pictured in Figure 2, groups the hardware components into three blocks representing the antenna, RF-to-digital and processing subsystems. No hardware component in the architecture is specialized to any particular waveform. While the architecture places no limitation on the achievable waveforms, any given implementation of the architecture can only support some waveforms. Each implementation will support a limited range of RF frequencies, bandwidths, and amount of computational power. For example, in order for a platform to be software upgradeable from 2G to 3G cellular standards, the implementation must be able to receive a 5 MHz wide band in the appropriate frequency ranges and have enough computational power to perform the 3G processing.

The rightmost block in Figure 2 represents the antenna subsystem. The interfaces to the antenna block are RF transmit and receive analog lines and a digital control interface. With these interfaces, the architecture can accommodate traditional passive antennas (for which the digital interface has no function) as well as advanced systems such as electrically controllable antenna arrays. Note that the architecture does not specify a particular type of digital connection (e.g. RS-232) as this is a detail of the implementation.

The next block to the left in Figure 1, labeled RF front end, is the only layer of the system that contains radio-specific analog components. On the receive side, its sole function is to generate a digitized representation of a downconverted slice of the radio spectrum. On the transmit side, it generates an upconverted radio signal from a digitized representation. This block does not perform waveform specific processing such as demodulation or equalization.

The third block, Radio Processor, is like a PC motherboard and can be implemented using a standard PC if desired. This block contains memory and processor components, and provides I/O to a network, to the user, timing support, and similar functions. A particularly important feature of the architecture is that radio samples flow into and out of main memory rather than directly to the processor. This frees the processor from the sample-by-sample real-time computation requirements characteristic of traditional signal processing designs, enabling a significant degree of software design flexibility and reduced development costs.