Tài liệu Phần mềm xác định radio P10 doc

Part IV
Software Technology
Software – at air interface, applications, protocol and network levels – is at the heart of the
promise of software radio. At all levels the potential is vast and the implications are profound
– the need for effective design tools to give functional reliability will be key to successful
commercialization.
Software Defined Radio
Edited by Walter Tuttlebee
Copyright q 2002 John Wiley & Sons, Ltd
ISBNs: 0-470-84318-7 (Hardback); 0-470-84600-3 (Electronic)
10
Software Engineering for
Software Radios: Experiences at
MIT and Vanu, Inc
John Chapin
Vanu, Inc
A good software design is one of the most important aspects of a software radio. This chapter
describes the software and hardware design approaches used in two software radio projects
that focused on maximizing software portability, modularity, and adaptability.
The designs described in this chapter were developed in two projects that built a series of
software radios over a 6-year period. The SpectrumWare software radio project at the
Massachusetts Institute of Technology in the United States ran from 1995 to 1998. In 1998
most of the SpectrumWare team left MIT to start Vanu, Inc. Between 1998 and 2001 Vanu
built software radio implementations of a variety of commercial and government waveforms,
including the cellular telephone standards IS-91 AMPS, IS-136 TDMA, and GSM.
Although the systems developed by SpectrumWare and those developed at Vanu, Inc.
differ in many details, the two development efforts followed the same design approach. In
this chapter both systems are called Vanu systems.
Vanu systems have several characteristics that distinguish them from other software radios.
Most signal processing functions execute on general purpose processors rather than on digital
signal processors or field programmable gate arrays. Almost all signal processing code is

implemented in a high level language, C11, running on top of a standard portable operating
system interface (POSIX) operating system. The waveforms and signal processing infrastruc-
ture have ported almost unchanged across Intel Pentium, Intel StrongARM, Compaq Alpha,
and Motorola PowerPC processors. These characteristics make Vanu systems pure software
radios, as opposed to the software-defined radios of other projects. The importance of this
distinction will become clear in the explanation of the engineering advantages inherent in the
approach.
Software Defined Radio
Edited by Walter Tuttlebee
Copyright q 2002 John Wiley & Sons, Ltd
ISBNs: 0-470-84318-7 (Hardback); 0-470-84600-3 (Electronic)
10.1 Overview of Vanu Systems
In its current form, the Vanu system architecture consists of the layers and components shown
in Figure 10.1.
The lowest layer is the antenna. The antenna counts as a layer because modern radio
systems contain active antenna elements that must be controlled: for example, beam forming
arrays or MEMS-based tunable antennas.
The next layer, labeled RF-to-Digital, 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 slice of the radio spectrum. On the transmit side, it generates a radio signal
from a digitized representation. It performs no signal processing. In lower cost systems, the
RF to digital layer performs channel selection on receive and band synthesis on transmission,
while in high performance systems it exchanges a digitized representation of a whole RF band
with the motherboard, enabling multichannel operation.
The name of the next layer, Motherboard, is borrowed from the PC world because software
radios built to the Vanu architecture look much more like computers than like legacy radios.
Like a PC motherboard, this layer contains memory and processor components, and provides
I/O to a network, to the user, and timing support and similar functions
The Operating System layer sits on top of the motherboard. Use of an operating system is
critical to the design approach because it isolates the signal processing application from the

hardware and thereby significantly improves its portability. Vanu systems place no unusual
demands on the operating system. Any COTS operating system that supports high data rate
transfers between applications and the underlying hardware can be used. The current imple-
mentation runs on Linux but could be ported easily to any POSIX compliant OS.
The software radio system runs as an application process on top of the operating system. It is
split into control and signal processing components, which have different engineering require-
ments. The control component emphasizes portability and the ability to integrate with COTS
Software Defined Radio: Enabling Technologies292
Figure 10.1 Layered software radio architecture
implementations of network protocol stacks and other higher layer functionality. The signal
processing component emphasizes processing efficiency, modularity and code reuse.
The signal processing component consists of a middleware layer which performs data
movement and module integration, and a library of signal processing modules for functions
such as FM encoding, the Viterbi algorithm, or FIR filtering. The control component consists
of a runtime system that interprets state machines and processing descriptions, and a down-
loadable application which determines which waveform or communications standard the
system will implement.
The SpectrumWare project at MIT had a simpler architecture than the one shown here. The
most significant difference is the lack of a defined control component. The research proto-
types built at MIT did not integrate software signal processing into larger systems and hence
needed only simple control functionality. The SpectrumWare system design has been
described in a variety of publications [1–6].
10.1.1 Representative Implementations
To make the above abstract architecture more concrete, consider a few current implementa-
tions of the architecture.
10.1.1.1 Powered User Equipment
For user environments where power is available, a commercial off the shelf (COTS) mother-
board can be used. The current Vanu demo system is a standard PC with a 1 GHz Pentium III,
dual channel PC133 memory, A/D and D/A cards, and an external RF front end for frequency
conversion. This system has been used to demonstrate reception of legacy AM and FM

broadcasts, family band walkie-talkie, APCO 25 (a North American digital law enforcement
standard), 1G and 2G cellular standards, and NTSC television.
10.1.1.2 Handheld User Equipment
In 2001 Vanu completed a research prototype of a battery-powered handheld system [7] (see
Figure 10.2). The custom board has a 200 MHz StrongARM 1110, dual port RAM, and a field
programmable gate array (FPGA) that interfaces to a host PDA and to a separate RF to digital
board which provides channel selection. The system supports the IS-136 2G cellular standard
in addition to less complex legacy standards.
10.1.1.3 Infrastructure Equipment
Vanu’s proof of concept implementation of a cellular telephone base station consists of a
number of COTS 1U rackmount servers, each with two 1 GHz Pentium III processors,
connected by gigabit ethernet [8,9] (Figure 10.3). The RF to digital function is provided
by separate single processor PCs, with A/D, D/A, and RF front ends, which exchange wide-
band digitized streams with the signal processors over the ethernet. The control component
runs on a single processor and communicates to the signal processing components using
CORBA. The system uses standard cluster techniques to detect and recover from the failure
of any signal processing server.
Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 293
10.1.2 Difference from Other Software Radios
The same software runs on all the radically different hardware implementations of the Vanu
system architecture. Furthermore, in platforms other than the handheld, all hardware except
the transmit front end is acquired as COTS boards or boxes that are plugged together without
any hardware design work. These features make Vanu systems fundamentally different from
legacy radio architectures, where the software is intimately tied to the hardware and building
a new radio always starts as a hardware design problem.
Software Defined Radio: Enabling Technologies294
Figure 10.2 Handheld prototype (the production version, August 2002, fits into a standard IPAQ
sleeve).
Figure 10.3 GSM base station prototype.
Most software defined radio approaches stay within the legacy approach and use software

merely as a means to improve system flexibility. Vanu systems make a sharp break from the
legacy approach and gain significant engineering advantages as a result. The combination of
portable software and COTS commodity hardware significantly increases the speed of devel-
opment and the diversity of communications functions that can be supported for the same
manufacturer engineering investment. The Vanu approach will gain increasing advantages as
this investment shifts over time to focus ever more greatly on software.
10.2 The Importance of Software in Software Radio
Communication systems have traditionally been constrained by antenna, amplifier, and
analog circuit design. However, software design is likely to become a core problem in future
software radios, one which is just as important as the traditional hardware design problem.
To see why, observe the trajectory of other industries. In fields such as aircraft and medical
devices, an initial hardware only system grew into a system where software implemented
critical performance and safety features. Eventually, software became the factor limiting
system design and performance. For example, Lockheed Martin reported in 1995 that by
the early 1990s software had become the single largest engineering cost over the product
lifecycle of an aircraft. Software costs exploded due to the difficulty of maintaining high
reliability while adding sophisticated software functionality and due to the cost of software
maintenance and upgrades over the life of the product.
Radios resemble aircraft and medical devices in ways which suggest that they will follow a
similar software cost curve. Users require a high level of reliability from communication
devices. Each of the features that make software radios attractive adds complexity to the
software. Manufacturers will need to provide upgrades for fielded devices, since the offer of
future upgrades will provide a key competitive advantage in the initial device sales effort.
These factors work together to make the software for software radios very costly.
Software costs can become high even without the advanced features promised from future
software radios. For example, the Harris Falcon II family of military radios currently supports
25 communications standards in a small package through use of SDR techniques. In early
2001, the software base for the Falcon II family contained an amazing three million lines of
code [10]. This exceeds the size, and probably the development cost, of all except the most
sophisticated business software applications.

For these reasons, software complexity and cost will become key considerations in the
system design. It will turn out to be appropriate in some cases to add cost or complexity to the
hardware if this can provide significant benefits to the software. The most important software
cost reduction opportunity, one that affects the hardware design in fundamental ways, is to
make the software portable across platforms.
10.3 Software Portability
Software portability is the primary requirement that has driven both the hardware and soft-
ware architecture design of Vanu systems. Although portability by itself is not sufficient to
prevent software costs from overwhelming manufacturers, it is a necessary component of the
solution.
Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 295
The benefits of portability for reducing development costs are so well known that little
explanation is necessary. Portability enables the developer to amortize the cost of software
over several generations of a product, and over several different products such as mobile
devices and fixed stations which interoperate using common waveforms. As software costs
increase as a proportion of system cost, the cost savings due to portability will continue to
grow.
This section explains other benefits of portability and the aspects of Vanu system design
that provide it.
10.3.1 The Effects of Moore’s Law
Portable software will frequently perform better than software optimized for a particular
platform. This counterintuitive result is a consequence of Moore’s Law. Moore’s Law is
the observation that the number of transistors which can be integrated into a single chip
doubles every 18 months. The semiconductor industry has closely followed this trajectory
since the 1960s. Exponential growth in transistor count has led to corresponding exponential
growth in processor performance, which strongly affects the trade-offs in software develop-
ment
Consider the experience of the SpeakEasy software radio project.
1
In 1991 the United

States Department of Defense launched SpeakEasy with the goal of supporting ten military
waveforms on a single device. The developers chose the fastest available digital signal
processor in 1991, the Texas Instruments TMS320C40. The computational requirements of
the target waveforms far exceeded the capability of the C40, so the developers planned a
system with multiple processors and highly optimized the software to reduce the number
required. By the time the SpeakEasy Phase I effort finished in 1994, Texas Instruments had
introduced the TMS320C54xx, a processor family four times faster than the C40. However,
SpeakEasy could not take advantage of the new processors. The software was tied to the C40
processor and would have had to be completely rewritten. Therefore the SpeakEasy system as
demonstrated in August of 1994 missed out on a potential 4£ reduction in size, power,
weight, and parts cost of the signal processing engine.
In contrast, consider the Vanu implementation of the American mobile phone system
(AMPS) analog cellular telephone standard. When the SpectrumWare project started in
1995, the first software radio could not process even a single AMPS channel in real time.
The 1995 software ran on a PentiumPro 133-MHz processor. By 2001 the Vanu derivative of
that code supported seven AMPS channels in real time on a Pentium III 1-GHz processor.
Most of the R&D dollars required to achieve this performance improvement were invested by
Intel, not by Vanu.
This consequence of Moore’s Law means that portable software will frequently out-
perform nonportable software for complex systems where software is a significant portion
of the engineering effort. Over the lifecycle of a product family, which can easily stretch to
10 years or more, Moore’s Law provides such a huge advantage that code portability is a
fundamental requirement for good performance of such systems.
Software Defined Radio: Enabling Technologies296
1
For a history and description of SpeakEasy see Bonser, W. ‘US defence initiatives in software radio’,in
Tuttlebee, W. (Ed.), Software Defined Radio: Origins, Drivers and International Perspectives, John Wiley &
Sons, Chichester, 2002, Chapter 2.
Portability is not a requirement for every line of code in the system. It is usually advanta-
geous to apply nonportable optimizations to the most performance critical sections of the

code. In a typical complex system roughly 5% of the code base may be specialized for each
platform without harm to the overall portability benefits. However, the benefits of tuning
more of the software for a given hardware platform rapidly decrease.
10.3.2 Exploiting Moore’s Law
Portability is not sufficient by itself for an application to take advantage of Moore’sLaw
performance gains. Additionally, the processor must be the performance bottleneck. Other
COTS components have historically improved at much lower rates than processors. If an
application is memory- or I/O-limited, hardware performance improvement over time may
not be sufficient to overcome the software performance costs associated with portability.
Designing a software radio to be processor-limited is a significant engineering challenge.
Signal processing has a higher ratio of data throughput to computation than most other
applications. Processors and systems designed to cover a broad range of applications can
easily become memory or I/O limited when running a software radio.
Two attributes of the Vanu system design approach are particularly important in ensur-
ing that the systems are processor-limited. The first is to ruthlessly eliminate data copies
wherever they occur in the system. Signal data, whether input, output, or intermediate
result, is only written once and then reused as many times as needed from that location.
While this may sound straightforward, it turns out to require surprising care to achieve in
a modularized complex system, especially when an operating system is used to control
the I/O devices. The second design attribute is to choose the amount of data operated on
in each pass through the processing pipeline (the payload) so it is small enough to fitin
the cache. This minimizes the number of data cache fills and spills to main memory
beyond the required load of input data and writeback of final output. Since data cache
sizes vary significantly across processors, even among closely related processors from the
same manufacturer, the processing payload size cannot be chosen as part of the software
design. Vanu systems dynamically determine the payload size at runtime. This is a
change from traditional implementation techniques which specialize the code to the
payload size.
Following these design approaches enables software to take advantage of Moore’sLaw
performance improvements, and therefore creates a strong performance benefit from port-

ability.
10.3.3 Generic Data Path
Software portability requires the use of hardware that has a generic data path rather than a
data path specialized for a particular application. Generic data paths have already become
common in the most complex signal processing applications such as airborne radar [11]. The
importance of portability for software radios will lead to adoption of generic data paths in less
complex systems such as vehicular and portable radios.
A specialized data path is a hardware data path tuned for the problem being solved. A
digital radio receiver, for example, may provide digital down converters (FPGA or DSP),
baseband processors (DSP), and network protocol processors (GPP), connected in a specia-
Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 297
lized topology with interdevice links whose capacities reflect the expected communication
patterns among the devices.
A generic data path is a hardware data path whose design is not specialized to any
particular problem. Commonly, the data path is either a single processor node, with its
associated memory, or a pipeline or array of identical processor nodes.
The choice of generic over specialized data paths is driven by the need to write a single
abstract source program and then use a compiler to generate the code for a variety of plat-
forms. Compiler technology is not yet good enough to generate efficient code for a specia-
lized data path from an abstract source program. A software engineer faced with a specialized
data path must therefore create a corresponding specialized source program. When this is
done, assumptions about the number of components, trade-offs among component speeds,
and the specialized capabilities of each component permeate the source code in a way that is
difficult or impossible to change. Porting the source code to a new platform or to the next
generation of a given platform usually requires a significant rewrite.
Just as with the choice of portable versus optimized code, the requirement to avoid specia-
lizing the software to the data path is not absolute. For example, one of the analog-to-digital
converters currently used by Vanu provides digital down-converter functionality. Taking
advantage of the DDC requires modifying each waveform implementation when porting it
to that platform. As long as such modifications affect only a small region of the program, this

does not significantly reduce overall code portability.
A design approach that requires generic data paths may be seen as unrealistic. After all,
specialized data paths are common today because they usually reduce the final system parts
cost. This benefit will not disappear in the future. However, as software costs become an ever
higher proportion of lifecycle cost, the parts cost savings of a specialized data path will
become less and less significant for any except the highest volume applications. This will
lead to the emergence of a large class of systems for which a generic data path is the
appropriate and cost-effective solution.
10.3.4 Temporal Decoupling
Radio systems face stringent real time requirements. For example, the IS-95 standard for
CDMA cellular telephones requires the mobile unit to begin transmitting data within a 3-ms
window centered at the scheduled start time.
Current digital radio systems satisfy real time requirements through tight control over
software execution timing. This approach does not significantly reduce portability by itself.
However, it limits the software to platforms that provide highly predictable execution rates.
Also, it limits the algorithms used to those that perform roughly the same amount of compu-
tation for each data sample processed. Current designs assume that execution jitter is confined
to small effects such as cache misses or bus contention and therefore only a few samples of
buffering at input and output are required to tolerate it.
Vanu systems relax the requirement of execution predictability by significantly increasing
the buffering at system input and output. Relaxing the execution rate requirement enables the
software engineer to exploit a much wider range of platforms and algorithms. For example,
Vanu, Inc. has found significant cost and portability benefits from using Linux rather than a
dedicated real time operating system (RTOS) in many applications. Also, the total computa-
tional load can be reduced by sophisticated algorithms that run quickly in the common case
Software Defined Radio: Enabling Technologies298
but occasionally fall back to expensive processing in the uncommon case. An example is a
convolutional decoding algorithm, much faster than the widely used Viterbi algorithm but
with the same error correction performance.
The Vanu approach sufficiently decouples the processor’s execution from the wallclock

such that the rate of execution at any given point in time is unpredictable. Real time require-
ments will be satisfied as long as the processor is fast enough for the signal processing code to
average a processing rate faster than the I/O rate.
This design approach interacts with the hardware design and with application end to end
latency requirements.
10.3.4.1 Hardware Design
Temporal decoupling requires the hardware to provide sufficient buffering on input to tolerate
the periods when the processing code runs slower than real time, and sufficient buffering on
output to tolerate the periods when the code is catching up by running faster than real time.
Alternately, the operating system can provide the buffering if it empties and fills the hardware
queues at a smooth rate. The amount of buffering required increases both with the variance in
processing rate and with the closeness of the average processing rate to its lower bound at the
I/O rate.
The input and output devices must also provide mechanisms to enable the application to
meet strict timing requirements on actions such as transmissions and frequency hops. This
issue was not addressed in SpectrumWare. The Vanu solution is a cycle counter in the input
and output devices. The input device uses its cycle counter to timestamp samples upon A/D
conversion. The output device stalls transfer of samples to the D/A converter if a sample
reaches the head of the output buffer labeled with a cycle count that has not yet been reached.
Future frequency hopping versions of both devices will have a queue of pending hop requests
where each request is labeled with the cycle counter value at which it should take effect.
These mechanisms enable signal processing code which is decoupled from wallclock time to
cause events such as transmissions and hops to occur at precise delays relative to prior input
events.
10.3.4.2 End-to-End Latency Requirements
Buffering on input and output does not come for free. Each sample buffered between the input
and output causes an additional sample period’s worth of delay. This limits the ability of
applications with strict end to end latency requirements to run on some platforms. The latency
requirement limits the amount of buffering allowed, which in turn limits the allowed variance
in the signal processing rate. Each platform has some minimum variance it can achieve,

depending on its hardware and system software design. If the minimum variance is too high
and the latency requirement too low, the application cannot run on the platform.
Unlike in traditional digital radio designs, however, the Vanu design approach ensures as
wide a range of platform compatibility as possible for each application. Temporal decoupling
smoothes out the discontinuity between predictable real time systems and unpredictable
nonreal time systems. By adjusting I/O buffer sizes, a portable application can run in real
time on a variety of different platforms and achieve the minimum end to end latency
permitted by each.
Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 299
10.4 Commodity PC hardware
The SpectrumWare project started with the goal of using commodity personal computer
hardware as a signal processing engine. This hardware has excellent price/performance,
improves more rapidly along the Moore’s Law curve than other components, and supports
a wide range of powerful software development and testing tools. In certain applications use
of commodity PC or server hardware will lead to radio systems whose cost or time to market
is substantially better than other hardware choices.
However, use of commodity PC hardware is not fundamental to the software engineering
techniques of Vanu systems. For example, Vanu is currently investigating use of a next-
generation DSP for a low power platform. The benefits of portability and other attributes of
the software design remain strong whatever hardware platform is used.
One challenge in using commodity PC hardware for software radio is to stream sample data
at high bandwidth back and forth between I/O devices and user mode applications. Neither
standard hardware nor standard operating systems comfortably support the data rates used,
especially for wideband systems such as a third-generation cellular telephone. SpectrumWare
introduced techniques that substantially increase the bandwidth that can be achieved, through
cooperation between the application, operating system device driver, and I/O device. The
common idea underlying the techniques is to exploit the predictability of the data flow to
preallocate and reuse resources effectively [12].
Commodity PC hardware platforms also suffer from a mismatch between processor perfor-
mance and memory system performance. The processors are significantly faster than the

memory, so a design that keeps most memory accesses in the cache becomes even more
important than was described earlier. The signal processing middleware design described
next was partially motivated by the need for excellent cache performance.
10.5 Signal Processing Software
Use of a generic data path and temporal decoupling free a software radio from the traditional
constraints on signal processing software design. A radio designed this way can take advan-
tage of any engineering techniques that improve modularity, reusability, adaptability, or other
code attributes. This section describes the particular design choices made in the signal
processing software design of Vanu systems.
10.5.1 Data Pull
Data in a signal processing system flows through a chain of processing stages from input to
output. In most systems, control also flows from input to output. When a processing stage is
complete, it pushes data downstream, causing the next stage to begin work.
Vanu systems invert the traditional design. Each processing stage pulls data from the
previous stage as needed to do its work. When implemented as a program, the application
starts by invoking a procedure in the final output stage. This stage calls the immediately
upstream stage, requesting the needed data. That stage in turn makes a procedure call on its
upstream neighbors, and so on until an input stage provides input samples to be processed.
Vanu systems are called ‘data pull’ for this reason.
Software Defined Radio: Enabling Technologies300
A data pull implementation works well with temporal decoupling, for several reasons.
† No processing is done until it is needed. Decisions to modify the behavior of the proces-
sing chain take effect immediately, rather than being delayed until partially processed data
has drained through to the output. Therefore the radio can adapt much more quickly to
events such as changes in the power level of a received signal.
† No work is done when the output buffer is full. Therefore there is no concern about
overrunning the output buffer despite the decoupling of processing rate from real time.
† Processing can be skipped in cases where the output is not needed. Examples of this
include a cellular mobile unit scanning the input looking for a synchronization pulse,
and a television display that is showing one-quarter of the full transmitted picture. The

downstream stage pulls the particular samples it needs and instructs its upstream neighbor
to skip the others. The skip instruction ripples up through the system and causes input
samples to be dropped if they are not needed.
In traditional systems, each processing stage operates on just a few samples at a time. This
approach would have excessive performance overheads in a Vanu system. The function call
overhead between stages would exceed the useful processing work being done, and the
program would have poor cache locality for both instructions and data. Instead, in a Vanu
system the stages operate on blocks of samples called ‘payloads’, as described earlier. Stages
that naturally process individual samples are built to process payloads of arbitrary size, while
stages that naturally process frames of data support payloads containing arbitrary numbers of
frames.
The payload requested by the final output stage of a processing chain is called ‘the output
size’. Porting a data pull application to a new platform requires adjusting the output size of
each processing chain. The size of the data cache, relative cost of a function call, and other
hardware parameters interact to determine the output size that provides maximum perfor-
mance at minimum end to end latency.
Data pull fits a single processor signal processing engine extremely well. The processor is
always busy doing only useful work. On the other hand, data pull is less natural for a pipeline
of processors. If implemented in the most straightforward manner, only one processor in the
pipeline will be doing useful work at a time.
SpectrumWare did not consider processor pipelines. In the Vanu, Inc. version of the
system, each processor works ahead of requests coming from the downstream processor.
The results of the workahead are written to an output buffer which is stored in memory
accessible to the downstream processor. In this way its data pull requests can be immediately
satisfied with precomputed values, in the common case that the next request follows sequen-
tially from the previous one without change to the processing parameters.
10.5.2 Signal Processing Stages as Objects
Vanu systems implement the various stages of the signal processing pipeline as independent
objects, written in an object-oriented language, which are connected at runtime to form the
desired processing graph. This approach is so common in the specification and rapid proto-

typing of signal processing systems that it is almost boring. However, Vanu systems are
unusual because they use dynamically connected objects as the implementation strategy for
the actual signal processing engine.
Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 301
Use of objects in this way in the operational system makes it easy to achieve a high degree
of reconfigurability. For example, in the Vanu implementation of a GSM cellular base station,
chains of signal processing objects are dynamically created and deleted as new connections
are established. This provides a clean mechanism for ensuring that only the required proces-
sing is done on each connection, among the various types of processing which the GSM
standard supports. In power-limited systems, objects that embody algorithms with higher
performance and higher power consumption can be replaced by objects with lower perfor-
mance and lower power consumption whenever conditions permit. This means, for example,
that battery life can be extended when there is little noise in the channel.
The cost of using independent runtime objects to implement processing stages is that object
granularity becomes a compromise decision. As the amount of code in each object increases,
the software objects become less reusable. Each one incorporates more of the functionality of
a particular communications standard or waveform and hence applies to a smaller range of
standards. On the other hand, as the amount of code decreases, performance overheads
increase. Fine-grained objects do less useful computation for each invocation of the inter-
object data communication mechanism.
The Vanu projects have used an application-driven approach to choose the object granu-
larity. With each new communications standard or waveform implemented in the system,
preexisting objects were split or generalized as needed to provide maximum code reuse while
achieving system performance goals. The Vanu class library remains a work in progress. An
ideal library would provide objects sufficiently flexible and sufficiently fine grained that a
broad range of commercially and/or militarily interesting waveforms could be implemented
without needing to write new classes.
10.5.3 Stream Abstraction
Vanu systems represent the data connections between processing stages as object-oriented
streams. The stream abstraction is designed to match engineers’ intuitions about these

connections. Each stream appears as an infinite sequence of data values, all of the same
type. Some streams carry scalar values, like floating point numbers, representing a continuous
sequence. Others carry discrete chunks of data such as video frames. Each entry in a stream is
associated with a time stamp. In the current implementation, it has turned out to be faster and
simpler to compute the time stamp upon request rather than store one with each entry.
The stream abstraction simplifies the implementation of the objects that provide the signal
processing stages. Through careful design of the API between the code in each object and the
stream implementation, all code dealing with buffer allocation, the circular nature of finite
buffers, buffer underflow and overflow, initialization, and flushing is hidden from the proces-
sing module. Each signal processing object treats its input and output buffers as infinite
arrays, subject to a few usage rules. The key usage rule is that the code must maintain an
access pointer, monotonically increasing, indicating a point in an input buffer before which
the code will not read, and a point in an output buffer before which all data values are valid.
This provides the implementation of the stream abstraction the information it needs to
manage buffer space and to activate upstream and downstream processing objects at the
appropriate times.
Hiding buffer management in the stream abstraction has significant benefits. The code for
the processing objects becomes cleaner and its actual signal processing behavior is much
Software Defined Radio: Enabling Technologies302
easier to read and reason about. Buffer management code is centralized into one abstraction
where it can be thoroughly tested. When porting, it is possible to take advantage of platform
specific buffer management features, such as virtual memory on a general purpose processor
or circular addressing in a DSP, through modifying code in one small part of the system.
Buffer size is hidden from the signal processing code, enabling output size and payload to be
adjusted when the system is ported, or even dynamically adjusted when operational condi-
tions change. The approach makes it easy to support variable cost algorithms that do not
always consume the same amount of input each time they run.
Because of the modularity and separation of concerns provided by the stream abstraction,
implementing the physical layer of the AMPS cellular telephone standard on top of the
SpectrumWare infrastructure and preexisting input/output libraries required only 600 lines

of code. This code implements four signal processing objects: a channel selection filter, an
FM discriminator, a low pass filter that also performs decimation, and an audio band pass
filter.
10.5.4 Out of Band Communication
Signal processing objects occasionally send or receive control events. These control events
differ substantially from the data flows in sample streams. Control events occur at unpredict-
able times, carry argument data of a variety of types, and can be sent between modules that
are not connected in the data flow graph. For these reasons it is appropriate to provide a
mechanism other than the stream abstraction to implement control events.
To remain consistent with the dynamic approach used for the data streams, control connec-
tions are established at runtime between signal processing objects. Control connections are
implemented in the widely used publish/subscribe design pattern [13].
The publish/subscribe pattern has two variants: a synchronous variant where subscribers
receive invocations while the publish procedure call is in progress and an asynchronous
variant where invocations are delivered to subscribers at some point after the publish proce-
dure call has completed. SpectrumWare used the synchronous variant exclusively as it was
simpler to implement. Vanu introduced asynchronous events for the case where the publisher
and subscriber are located on different processors. This led to a situation that proved error
prone, with synchronous events in the local case and asynchronous events in the remote case.
Also, an event path in the implementation of GSM was discovered that requires asynchronous
events even in the local case. Therefore Vanu changed to a fully asynchronous event model.
10.6 Control Software
The control component is responsible for selecting the signal processing objects used for
signal processing, making the necessary interconnections, and setting all the processing
parameters. Additionally, the control component implements the protocol state machines,
changes the processing graph as required by changes in operational conditions, and interacts
with higher layer software or with the user.
10.6.1 Code Generation
At Vanu Inc., the effort to implement large systems such as cellular telephone base stations
Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 303

quickly demonstrated that automatic code generation is required for the control component.
The physical layer of an AMPS base station includes in excess of 1500 signal processing
object instantiations. Creating these one by one, then setting their parameters and connecting
their data and control flows appropriately, requires a large number of lines of control soft-
ware, or a large number of entries in a table if the system is table-driven. This code or table is
repetitive, difficult to read, and expensive to modify correctly. A better mechanism than hand
writing explicit code or tables is necessary for industrial strength systems.
The code generation system currently in use at Vanu includes several components:
† generation of signal processing object instantiations, parameter settings, and connections
from a more abstract description of the desired signal processing. The more abstract
description is written in a Vanu-developed language called the radio description language
(RDL) [14]
† generation of the most common RDL constructs from graphical representations of assem-
blies
† generation of state machine code from graphical statecharts
The code generation system provides an important form of portability to the control
component of Vanu software radios. The mechanism used to connect the control component
to the signal processing component is different in different systems. In a resource-constrained
handheld, JNI is used between the Java-based control component and the C11-based signal
processing component. In a distributed infrastructure system, CORBA connects the control to
the signal processing. Different connection mechanisms require substantial differences in the
control code. These differences are hidden from the software engineer by generating the
variants automatically from a more abstract description. The result is a significant reduction
in the amount of reprogramming required to port a waveform across platforms.
10.6.2 Radio Description Language
RDL is a compiled language for describing signal processing graphs. RDL offers two primary
constructs.
† Modules are the nodes in the processing graph. Each corresponds to a signal processing
function. Figure 10.4 shows an example module.
† Assemblies are graphs. An assembly contains modules or subassemblies, connected into a

particular topology. Figure 10.5 shows an example assembly, and Figure 10.6 shows the
topology it describes.
Additionally, the language contains the notion of streams that express the graph connec-
tions along which data flows, ports that are attachment points for streams on modules, and
channel types describing the messages that can flow along a stream.
Assemblies serve to simplify the expression of complex processing graphs that have
internal structure. An example assembly is the receive chain that monitors GSM control
channel traffic. In a base station which monitors multiple control channels simultaneously,
a control channel receive assembly is instantiated multiple times, with the center frequency
and other relevant parameters set differently in each one. This substantially reduces the
number of lines of code in the description of the graph.
A key design decision in RDL is that an assembly is treated just like a module by all code
Software Defined Radio: Enabling Technologies304
Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 305
Figure 10.4 RDL module
Figure 10.5 RDL assembly
outside that assembly. Assemblies have parameters, control and data ports just like modules
do, and can be instantiated, connected, and disconnected from each other as if they were
modules. More precisely, each assembly implements a module, just as a class implements an
interface in an object-oriented language like Java. All uses of the assembly refer solely to the
module, hiding the existence of the assembly. This approach improves modularity, since
assembly internals can be freely changed, and allows the runtime system to substitute a single
module implementation in place of the assembly if one is available with better performance.
The processing graph described by a collection of RDL modules and assemblies is one part
of a larger waveform application. Other parts of the application, such as protocol state
machines, need to interact with the processing graph. For example, a signal processing object
that monitors received signal strength must send a control event to the GSM application when
signal strength drops below some threshold, so the application can initiate handoff processing.
RDL reuses the channel construct for connections between signal processing objects and
higher layers. A module in a RDL waveform description may be declared a control module.

Control modules represent portions of the application rather than signal processing compo-
nents. When an application delivers a processing graph to the RDL runtime for execution, it
provides a reference to an object in its address space for each control module in the graph.
Control events sent to ports of that are delivered as procedure calls to the application object.
For the reverse path, there is an application programming interface (API) by which the
application can send control events out along the channels connected to the control module.
The current implementation of RDL uses Java class files as the download format for RDL,
and CORBA or JNI to connect the control to the signal processing component. RDL assem-
blies are compiled to a Java class, which the waveform developer subclasses and extends with
code to compute the parameters of the components based on the parameters of the assembly.
The waveform developer writes Java for the other application parts of the waveform and links
that code together with the Java produced from the RDL assemblies that describe the signal
processing part of the waveform. This produces a portable download image as a Java jar file
which can run on any platform from a handheld up to a cluster of servers. The RDL imple-
mentation is a work in progress and may change substantially as it is extended to support a
wider range of platforms and uses.
RDL descriptions of waveforms are compact. The RDL description of GSM layer 1 is built
from 36 different primitive modules and 28 different assemblies, totalling 3190 lines of RDL
code including comments. In one execution configuration, when a GSM mobile is camping on
Software Defined Radio: Enabling Technologies306
Figure 10.6 Data flows of RDL assembly in Figure 10.5
a control channel waiting for a call, the processing graph contains 20 signal processing
modules and seven control modules, connected by 25 data streams and 16 control streams.
For a more detailed description of RDL, see [14]. The text in this section is based on that
paper.
10.7 Performance
Performance of the SpectrumWare system was presented in [2,5]. Performance of the Vanu
signal processing subsystem can be roughly measured as megacycles per second of computa-
tion required to support a given waveform or communications standard in real time. For
example, if a given standard requires 100 megacycles per second of computation, then it will

use 50% of the available CPU performance on a 200 MHz processor. This is only a rough
measure because different processor architectures do different amounts of computation per
cycle
Table 10.1 shows the performance of several representative standards, measured on a
600 MHz Intel Pentium III processor.
IS-136 and 802.11b are half-duplex, and transmission requires less processing than receive,
so the number shown for RX is the maximum computational load required for signal proces-
sing to support the standard. The IS-91 and GSM measurements include simultaneous RX and
TX processing. Comparisons among these performance numbers should not be taken to
represent intrinsic differences in the computational complexity of the standards.
Note that TDMA standards such as IS-136 and GSM do not scale linearly in cost with the
number of time slots supported. When the GSM implementation is used in a base station, for
example, two full-duplex connections active within a single 200-kHz carrier consume a total
of 211 megacycles per second, while three connections active consume 348 megacycles per
second.
To give a sense of how the systems function internally, Table 10.2 lists all functions
consuming more than 2% of the execution time in the GSM implementation (measured by
gprof, running three active connections). These are individual functions, so in each case the
number shown is for the inner loop function of the named signal processing object.
This execution breakdown roughly parallels what would be expected based on the intrinsic
complexity of the various signal processing functions in the GSM standard.
Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 307
Table 10.1 Signal processing performance
Waveform Megacycles/s Op Comments
IS-91 41 RX 1 TX AMPS 1G cellular voice
IS-136 62 RX TDMA 2G cellular voice
GSM 96 RX 1 TX 2G cellular voice
802.11b 516 RX LAN data
10.8 Future Directions
Vanu Inc. continues active work on all aspects of the software for software radios. Research

efforts focus on tools and techniques for improving both the performance and portability of
Vanu systems beyond current levels. One major target is to exploit the vector execution units
of modern processors (SSE on Pentium, 3dNow! on Athlon, Altivec on PowerPC). At present
this code must be hand-specialized to each platform. Although written in C, it uses compiler
intrinsics that translate one for one to the idiosyncratic features of the hardware. A higher
level compiler that can automatically generate the hardware specific intrinsics from portable
code will significantly reduce the porting effort across platforms.
A longer term compiler effort is to automatically combine the algorithms from indepen-
dently written signal processing stages into single functions. This will nearly eliminate the
costs associated with fine-grained signal processing stages and thereby improve the reuse-
ability of signal processing code.
Highly flexible physical layers offer the potential to reduce power consumption and
improve throughput in ad hoc mobile networks. Vanu is investigating this opportunity in
collaboration with researchers at MIT [15].
Another research effort relates to the certification of software radios by the United States
FCC.
2
Current certification rules require each software and hardware combination to be tested
together. Under these rules, certification costs prevent manufacturers from rapidly deploying
new waveform software across a variety of platforms, even if the software is portable. Vanu,
Inc. is working on techniques to assure that transmissions remain in compliance as software is
ported across platforms. Certification of these techniques and their use in future systems will
help unlock the full economic benefits inherent in software radio technology.
As manufacturers move to 3G cellular systems, build multimode vehicular telematics
devices, or develop infrastructure systems that dynamically change functionality to maximize
revenue, the engineering costs of radio systems will shift ever more strongly into software.
This will continue to strengthen the case for focusing radio system design on reducing soft-
ware costs. The Vanu designs described in this chapter show the significant improvements in
portability, adaptability, and modularity that can be achieved in the software for software
radios.

Software Defined Radio: Enabling Technologies308
2
See Grable, M., ‘Regulation of software defined radio – United States’, in Tuttlebee, W. (Ed.), Software Defined
Radio: Origins, Drivers and International Perspectives, John Wiley & Sons, Chichester, 2002, Chapter 11.
Table 10.2 GSM implementation profile
Time (%) Signal processing object
35.7 Equalizer, normal training sequence
14.8 Convolutional decoder
8.4 Speech encoder
5.4 GMSK modulator
3.3 Distance vector computation for convolutional decoder
2.8 Equalizer, SCH training sequence
2.2 History accumulation for convolutional decoder
Acknowledgements
Work on Vanu systems at MIT and Vanu, Inc. has been supported by funding from the US
Defense Advanced Research Projects Agency, the National Science Foundation, the National
Institute of Justice, and the US Department of Defense Joint Tactical Radio Systems Office.
The technical work is a collaborative effort with too many contributors to list here, although
special recognition for the fundamental system concepts goes to Vanu Bose and Michael
Ismert. In the preparation of this manuscript, the author is grateful for the support and eternal
good humor of Walter Tuttlebee.
References
[1] Bose, V. and Shah, A., ‘Software radios for wireless networking’, Infocomm ‘98, San Francisco, CA, April,
1998.
[2] Bose, V., ‘The impact of software radio on wireless networking’, Mobile Computing and Communications
Review, Vol. 3, No. 1, January, 1999.
[3] Bose, V., Ismert, M., Welborn, M. and Guttag, J., ‘Virtual radios’, IEEE/JSAC, Special Issue on Software
Radios, April, 1999.
[4] Chiu, A., ‘Adaptive channels for wireless networks’, MIT M.Eng. thesis, May, 1999.
[5] Bose, V., ‘Design and implementation of software radios using general purpose processors’, MIT Ph.D. thesis,

June, 1999.
[6] Vasconcellos, B., ‘Parallel signal processing for everyone’, MIT M.Eng. thesis, February, 2000.
[7] Chapin, J. ‘Handheld all-software radios: prototyping e evaluation for JTRS Step 2B’, lt.
army.mil/docs/documents/step2b/Vanu.pdf
[8] Chapin, J., Chiu, A. and Hu, R., ‘PC clusters for signal processing: an early prototype’, IEEE Sensor Array and
Multichannel Signal Processing Workshop, Cambridge, MA, March, 2000.
[9] ‘Programmable, scalable wireless information infrastructure’, NSF Contract DMI-9960454 final report, http://
www.vanu.com/publications, July 11, 2000.
[10] Turner, M., ‘Software programmable radio: the Harris solution’, SMi Software Radio Conference, London,
April, 2001.
[11] Mercury Computers technology white papers,
[12] Ismert, M., ‘Making commodity PCs fit for signal processing’, USENIX ‘98, New Orleans, , LO, June, 1998.
[13] Gamma, E., Helm, R., Johnson, R. and Vlissides, J., Design Patterns, Addison-Wesley, Reading, MA, 1995.
[14] Chapin, J., Lum, V. and Muir, S., ‘Experiences implementing GSM in RDL (The Vanu Radio Description
Languagee)’, MILCOM, October, 2001.
[15] Bose, V., Hu, R. and Morris, R., ‘Dynamic physical layers for wireless networks using software radio’,
International Conference on Acoustics, Speech, and Signal Processing, Salt Lake City, UT, May, 2001.
Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 309