Professional Documents
Culture Documents
Software Defined Radio is an emerging technology that has been an active re-
search topic for over a decade. The terms software defined radio and software
radio are used to describe radios whose implementation is largely software-based.
These radios are reconfigurable through software updates. There are also wider
definitions of the concept.
Various military software defined radio programs were the pathfinders that
proved the viability of the concept. Latests of these projects have produced radios
that are already replacing legacy systems.
The software radio technology is rapidly advancing, at least on most fronts.
There is an ongoing standardisation process of framework architectures that en-
able portability of e.g. waveform processing software across radios for various
domains.
Software defined radios are beginning to find also commercial potential. When
the software defined radio becomes mainstream, the full potential of adaptability
may create possibilities for new kind of services. From the users’ point of view,
seamless operation across networks, without caring about the underlying technol-
ogy, would be a very desirable feature.
Keywords: Software Defined Radio (SDR), Radio Frequency (RF) front end,
Analog-to-Digital Converter (ADC), Digital Signal Processor (DSP), Software
Communications Architecture (SCA), SWRadio, programmable, reconfigurable
TUCS Laboratory
Communication Systems Laboratory
Contents
1 Introduction 1
2 Implementation Aspects 3
2.1 Radio Frequency Front End . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Superheterodyne Architecture . . . . . . . . . . . . . . . 4
2.1.2 Direct Conversion Architecture . . . . . . . . . . . . . . 5
2.1.3 Tuned RF Receiver . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 Other Architectures . . . . . . . . . . . . . . . . . . . . . 6
2.2 A/D and D/A Conversion . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Noise and Distortions in Converters . . . . . . . . . . . . 8
2.2.2 Sampling Methods . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 Converter Structures . . . . . . . . . . . . . . . . . . . . 11
2.3 Digital Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Selection of the Processing Hardware . . . . . . . . . . . 12
2.3.2 Multirate Processing . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Digital Generation of Signals . . . . . . . . . . . . . . . . 13
2.3.4 Bandpass Waveform Processing . . . . . . . . . . . . . . 14
2.3.5 Baseband Waveform Processing . . . . . . . . . . . . . . 14
2.3.6 Bit-stream Processing . . . . . . . . . . . . . . . . . . . 15
2.4 Reconfiguration and Resource Management . . . . . . . . . . . . 15
2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Standards 17
3.1 Air Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1 Model Driven Architecture (MDA) . . . . . . . . . . . . 21
3.3.2 Common Object Request Broker Architecture (CORBA) . 21
3.3.3 Interface Definition Language (IDL) . . . . . . . . . . . . 22
3.3.4 Unified Modeling Language (UML) . . . . . . . . . . . . 23
3.3.5 Extensible Markup Language (XML) . . . . . . . . . . . 23
3.4 Software Communications Architecture (SCA) . . . . . . . . . . 24
3.4.1 Application Layer . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Waveform Development . . . . . . . . . . . . . . . . . . 26
3.4.3 SCA Reference Implementation (SCARI) . . . . . . . . . 27
3.5 SWRadio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1 SWRadio Platform . . . . . . . . . . . . . . . . . . . . . 28
3.5.2 SWRadio Architecture . . . . . . . . . . . . . . . . . . . 28
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Software Defined Radio Projects 30
4.1 SPEAKeasy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1 SPEAKeasy Phase I . . . . . . . . . . . . . . . . . . . . 30
4.1.2 SPEAKeasy Phase II . . . . . . . . . . . . . . . . . . . . 32
4.2 Joint Tactical Radio System (JTRS) . . . . . . . . . . . . . . . . 33
4.2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.3 Wireless Information Transfer System (WITS) . . . . . . 35
4.2.4 SDR-3000 . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Other SDR Projects . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1 Joint Combat Information Terminal (JCIT) . . . . . . . . 36
4.3.2 CHARIOT . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.3 SpectrumWare . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.4 European Perspective: ACTS and IST Projects . . . . . . 38
4.3.5 GNU Radio . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5 Conclusions 42
Abbreviations 44
1 Introduction
Software defined radio is an emerging technology that is profoundly changing
the radio system engineering. A software defined radio consists of functional
blocks similar to other digital communication systems. However, the software
defined radio concept lays new demands on the architecture in order to be able to
provide multi-band, multi-mode operation and reconfigurability, which are needed
for supporting a configurable set of air interface standards.
This report is organised as follows: Chapter 2 discusses the implementation
aspects of software defined radios. The multi-band, multi-mode operation intro-
duces stringent requirements on the system architecture. To achieve the required
flexibility, the boundary of digital processing should be moved as close as possi-
ble to the antenna and application specific integrated circuits should be replaced
with programmable processing elements. The exact point where the conversion
between digital and analog waveforms is done depends on the architecture.
The requirement of supporting multiple frequency bands complicates the de-
sign of the RF front end and the A/D and D/A converters. The RF front end should
be adjustable or directly suitable for different center frequencies, bandwidths and
other waveform requirements set by the different standards. The choice of the RF
front end architecture depends also on the availability of the A/D and D/A con-
verters. In software defined radios, one of the typical places for the conversions
is between the stages of channel modulation at an intermediate frequency. The
need for reconfigurability restricts the choice of the digital processing platform,
which may be a combination of FPGAs, DSPs and general purpose processors or
a completely new type of computing environment.
Chapter 3 discusses standards related to software defined radios. Standards
are of an enormous importance considering quality, efficiency, compatibility etc.
Currently, wireless communication industry and end users have to deal with the
problems arising from the constant evolution of air interface standards and varia-
tions across the world. Software defined radios can be seen as a solution to many
of the problems.
There are several standards bodies relevant to software radios: ANSI, ARIB,
ETSI, IEEE, ISO, ITU, OMG, PCI, TIA, VSO etc. There are standards, for exam-
ple, for interconnects, analog hardware, buses and backplanes, internetworking
and object oriented architectures. The expanding amount of air interface stan-
dards resulted in need to develop multi-mode radios, both for military and for
commercial applications.
Two framework architectures, the SCA and the SWRadio, have been devel-
oped. The SCA is the de facto standard for military and commercial software
defined radio development and the SWRadio is the result of an ongoing project
for building an open international industry standard using the SCA as a basis.
Chapter 4 reviews the historical perspective of software defined radio archi-
tectures and the current state of the art, by presenting a few of the most influential
projects. In addition, a few other projects related either to research of software de-
1
fined radio technology or to development of deployable radio sets are presented.
An interesting question is, what the architectures used in these projects have in
common, and whether there is an architecture that has proven to be optimal.
The conclusions summarise this overview of software defined radios in Chap-
ter 5.
2
2 Implementation Aspects
A software defined radio (SDR) consists of, for the most part, the same basic
functional blocks as any digital communication system [19]. Software defined
radio lays new demands on many of these blocks in order to provide multiple band,
multiple service operation and reconfigurability needed for supporting various air
interface standards. To achieve the required flexibility, the boundary of digital
processing should be moved as close as possible to the antenna, and application
specific integrated circuits, which are used for baseband signal processing, should
be replaced with programmable implementations [8].
Functions of a typical digital communication system can be divided into bit-
stream processing, baseband waveform processing and bandpass processing. The
transmitter of a digital radio can be further divided into an information source, a
source encoder, an encryptor, a channel encoder, a modulator, a digital-to-analog
converter (DAC) and a radio frequency (RF) front end block. Correspondingly,
the receiver consists of an RF front end, an analog-to-digital converter (ADC), a
synchronisation block, a demodulator, a detector, a channel decoder, a decryptor,
a source decoder and an information sink [1, 2]. The exact point where the conver-
sion between digital and analog waveforms is done depends on the architecture.
The converters have been deliberately left out from Figure 2.1. In conventional
radio architectures, the conversion is done at the baseband, whereas in software
defined radios, one of the typical places for the conversion is between the stages
of channel modulation, at an intermediate frequency.
The multi-band, multi-mode operation of an SDR introduces stringent require-
ments on the underlying system architecture. The requirement of supporting mul-
tiple frequency bands affects the design of the RF front end and the A/D and D/A
converters [2]. The RF front end should be adjustable or directly suitable for dif-
ferent center frequencies and bandwidths required by the different standards that
the SDR supports. The front end architectures differ also in suitability consider-
ing the waveform requirements of different operating modes. The RF front end
architectures are discussed in section 2.1. The choice of the RF front end archi-
tecture depends also on the availability of suitable ADCs and DACs. These data
converters are discussed in Section 2.2. The need for reconfigurability and repro-
grammability restrict the choice of the digital processing platform. For instance,
the platform may be a combination of field programmable gate arrays (FPGAs),
digital signal processors (DSPs) and general purpose processors (GPPs). The as-
pects related to digital processing are discussed in Section 2.3. The reconfigura-
bility and the need for resource management are discussed in Section 2.4. The
chapter is summarised in Section 2.5.
3
Information Source Encryptor Channel Modulator RF front end
source encoder encoder
RF
Information Source Decryptor Channel Detector Demodulator front
sink decoder decoder end
mentation still needs an RF front end, and the design of a reconfigurable RF part
remains a very complicated issue [4, 2, 7]. The receiver section is more com-
plex than the transmitter and the ADC is the most critical part limiting the choice
of the RF front end architecture [2]. The main functions of the radio frequency
front end are down and up conversion, channel selection, interference rejection
and amplification.
The transmitter side of the RF front end takes the signal from digital-to-analog
converter, converts the signal to the transmission radio frequency, amplifies the
signal to a desired level, limits the bandwidth of the signal by filtering in order to
avoid interference and feeds the signal to the antenna [3].
The receiver side converts the signal from the antenna to a lower center fre-
quency such that the new frequency range is compatible with the ADC, filters
out noise and undesired channels and amplifies the signal to the level suitable for
the ADC. The common part of every receiver architecture apart from fully digital
ones is that the antenna feeds signal trough an RF bandpass filter to a low noise
amplifier (LNA). Automatic gain control (AGC) keeps the signal level compati-
ble with the ADC. Design objectives include achieving a suitable dynamic range
and minimising additive noise while minimising the power consumption. Usually
there has to be a trade-off between power consumption and the dynamic range.
The following subsections present different receiver architectures, i.e. su-
perheterodyne, direct conversion, tuned RF and pure digital receivers. Actual
transceivers have also a transmitter section, which is also based on the single or
the dual conversion architecture. Many of the design challenges concerning the
transmitter are similar to those of the receiver, particularly the power consumption
[2].
4
BPF LNA BPF BPF AGC LPF AGC ADC
IF LO1 IF LO2
The direct conversion receiver (DCR) needs significantly lower number of parts
and it is conceptually attractive because of the simplicity. Despite its problems,
the DCR concept has gained again attraction as a result of its suitability for use
with multiple standards [7]. In the DCR, the received signal is directly down con-
verted to baseband. The down converted signal is then prefiltered by a variable
frequency anti-aliasing filter and, after analog-to-digital conversion, desired chan-
nels are chosen by software filters. Figure 2.3 illustrates the structure of the analog
part of a direct conversion receiver that uses quadrature sampling.
Direct conversion receivers have been so far suitable only for modulation
methods that do not have significant part of signal energy near DC. There are
5
LPF AGC ADC
o
90
BPF LNA
also problems associated with the fact that the local oscillator of a DCR is at the
signal band, including possible unauthorised emissions and internal interference.
One of the problems is that phase noise falls within the baseband. Thus, the DCR
architecture needs an extremely stable local oscillator. Some of the problems can
be compensated with digital post processing.
Apart from the possibility to switch between some specific bands and modes,
direct conversion receivers do not offer prominent flexibility. There are some air
interface standards that are very difficult to support by a direct conversion receiver.
On the other hand, the concept has been proven to be commercially usable, for at
least some purposes, by an existing GSM receiver. Some sources suggest that the
DCR is the most promising RF front end architecture for software defined radio
[7].
6
BPF LNA AGC ADC
radios. Such a solution puts an ADC at the antenna and does everything else,
including down conversion and filtering, using digital signal processing [4, 2, 3].
The architecture needs A/D conversion and digital processing at very high band-
widths, which results in a high power consumption. Furthermore, the incoming
signal cannot be equalised and as a consequence, error rates are higher. Pure
digital RF processing has yet to see any commercially viable applications.
7
The analog front end of an ADC has a direct influence on the dynamic range.
The non-linearities of the front end cause intermodulation. The spurious free dy-
namic range (SFDR) denotes the difference between the minimum detectable in-
put (noise floor) and the point where the third order distortion becomes stronger
than that [2]. Different air interface types and standards have different demands
on the dynamic range. A large SFDR is needed to allow recovery of small scale
signals when strong interferers are present.
Different types of receiver architectures need different sampling methods [3].
A superheterodyne receiver or a direct conversion receiver may have an I/Q base-
band signal as the analog output, for which quadrature baseband sampling is
needed. Another possibility is an intermediate frequency analog output, for which
a suitable sampling strategy is for example IF band-pass sampling by using a
sigma-delta ADC. Direct sampling is a suitable method for low IF analog signals.
Although the ADC performance is often the limiting factor in the SDR con-
cept and usually more widely discussed in this context, the transmit path is also
a design problem of comparable complexity [3]. The requirements for DACs in-
clude high linearity, sufficient filtering and isolation of the clock from the output,
in order to avoid distortion and out-of-band emissions.
The following subsection discusses distortions in converters and related con-
siderations from the point of view of different air interfaces. The subsequent sub-
sections present different sampling methods and converter structures, taking into
account issues related to the suitability for SDRs.
8
the air interface standard used, which has to be taken into account in SDR design.
Avoiding clipping due to overload may effectively use the entire most significant
bit. Therefore, the usable dynamic range may be one or two bits lower than the
resolution of ADC [4].
Offset and gain errors are linear transfer characteristic errors. Non-linearities
can be described with two measures: integral non-linearity denotes the maximum
deviation of the transfer characteristic from the ideal straight line and differential
non-linearity denotes the variation of the distances of quantisation levels from the
desired step size.
Thermal noise is an unavoidable property of resistive components. Software
defined radios work with multiple bandwidths, which results in varying noise
floor. Concerning wideband signals, thermal noise may considerably reduce the
dynamic range.
The uncertainty in spacing between sampling instances is called aperture jitter.
This causes uncertainty in the phase, deteriorates the noise floor performance and
increases intersymbol interference. Glitches are transient differences from the
correct output voltage in DACs. Aperture jitter and glitches are the most important
timing problems of ADCs and DACs.
The effective number of bits (ENOB) of a converter can be calculated from
the signal-to-noise-and-distortion (SINAD) ratio [2].
SIN AD − 1.763dB
EN OB =
6.02
and the SNR of a system in which other effects are negligible compared to aperture
jitter is given by [2]
SN R = −10log10 (2π 2 f 2 ∆a 2 )
where f is the frequency of input signal and ∆a 2 is the variance of the aperture
jitter. By using these equations, an upper limit of the effective number of bits at
different frequencies can be calculated. The limit is shown for one value of the
aperture jitter in Figure 2.5. Thermal noise may also be the dominant limiting
factor, whereas conversion ambiguity may become dominant at high frequencies.
The performance of currently available ADCs lies usually below the line show in
the figure. There are more detailed graphs in [4] and [2].
Dithering is a method that is used to increase spurious free dynamic range [3].
SFDR is essential from the point of view of narrow band air interfaces. Dither
is pseudo random noise that is added to the input of ADC. The main goal is to
maximise the SFDR, while minimising the effect adverse on SNR. Small-scale
dithering is used to decorrelate quantisation noise, which leads to reduction of the
harmonics caused by correlated noise. Dithering may also reduce errors caused by
differential non-linearities. There are two large-scale dithering techniques that are
used to mitigate effects of non-linearities: out-of-band dithering and subtractive
dithering [2]. In out-of-band dithering, noise is added outside the frequency band
9
20
18
16
Effective number of bits
14
12
10
8
6 7 8 9
10 10 10 10
Sampling rate
Figure 2.5: The effect of 0.5 ps aperture jitter on the performance of ADC
10
RF bands of radio systems have band-pass characteristics instead of low-pass
characteristics. Bandpass sampling, or sub-sampling, also utilises the Nyquist’s
theorem, i.e. the sampling rate has to be at least twice the bandwidth of the input
signal. In this method, images are viewed as frequency translated versions of the
desired spectrum instead of only harmful by-products. It is necessary that infor-
mation in any Nyquist zone will not interfere with information in other Nyquist
zones. By using this approach, down conversion is also provided by the sampling
process.
11
+ 1−bit
LNA LPF +
filter & decimator
−
−
n−bit output
DAC
hardware has to be reprogrammable and there has to be some control software for
handling the reconfiguration.
The following subsections discuss the selection of the processing platform,
techniques related to digital waveform processing and finally the bit-stream sec-
tion of the SDR.
The need for reconfigurability necessitates the use of programmable digital pro-
cessing hardware. The reconfiguration may be done at several levels. There may
be parameterised components that are fixed ASICs, and in the other end, the hard-
ware itself may be totally reconfigurable, e.g. FPGAs. There has to be done a
compromise between programmability, reconfiguration time, processing power,
power consumption, cost, etc.
The most optimised hardware implementation can be done using ASICs but it
is very inconvenient to have a dedicated chip for every operating mode. Digital
signal processors excel in programmability but they can not handle everything, at
least with a tolerable power consumption [9]. FPGAs are often used to do the
most intensive computations. Their reconfiguration time is significantly longer
than the time needed for reprogramming of DSPs and general purpose processors.
It might be desirable that a software defined radio could switch between differ-
ent operating modes based on channel conditions or other changes in environment.
Customised FPGAs, called configurable computing machines (CCMs), provide
real-time paging of algorithms [9]. They use coarser granularity than traditional
FPGAs. This kind of architectures can be used as stand alone processors or as
co-processors. Low power requirement still remains a problem. There are also
other new approaches at research stage, including application specific instruction
set processors and field programmable functional arrays, which consist of config-
urable sections specialised for certain tasks. These and a few other approaches are
presented in [9]. In [17], there is proposed a FPGA-macro-based SDR architec-
ture.
12
The total amount of processing capacity sets another limit for implementable
systems. In [4], there are presented a few simple equations for calculating the
needed processing capacity. An illustrative calculation shows that a GSM receiver
requires the capacity of over 40 millions of operations per second (in standardised
MOPS) when the IF processing is excluded. Vanu Inc. has also published a table
containing the number of operations needed by a few air interfaces implemented
in their line of SDR products. For instance, a GSM transceiver needs 96 Mcycles
per second on a Pentium III platform, whereas a 802.11b WLAN receiver requires
512 Mcycles per second [31].
13
Direct digital synthesis produces purely digitally signals that are discrete in
time. In comparison to analog methods, the benefits include high accuracy, im-
munity to noise, ability to generate arbitrary waveforms, low switching time and
the physical size of circuits.
There are a number of approaches for generating digital signals. One of the
basic methods is to store a sampled waveform in a look-up table (LUT). The sam-
pled values are then sent to the output periodically. Sinusoidal signals can be
generated this way. There are three sources of error in direct digital synthesis:
amplitude error due to the limited number of bits used in quantisation, phase trun-
cation due to a limited number of bits used to address the locations of the table,
and the resolution of the DAC. The phase truncation is a significant source of error
and many methods have been developed to cure problem.
There are many approaches to reduce the size of LUT or to avoid spurious
signals caused by phase truncation. Interpolation reduces the required size signif-
icantly. There are also sine wave generators that do not need a LUT for generating
a wave of a fixed frequency. These include the CORDIC algorithm and IIR oscil-
lators.
14
Analog modulation methods may also be emulated using digital waveform
processing with very reasonable computational requirements.
15
Communication profiles are needed for the management of reconfiguration.
Profiles have to be defined for users, terminals, services and networks [6]. There
has to be also means for monitoring and identification of available air interfaces
and for the management radio resources. One of the challenges of future wireless
systems is finding means for more flexible, dynamic and efficient allocation of
spectrum. Technical and regulatory work is needed for setting rules for more
optimal spectrum management.
2.5 Summary
The implementation of software defined radios is a wide and challenging issue.
The starting point in this chapter was the general structure of digital communi-
cation systems. The requirements set by the need for multi-mode operation and
reconfigurability have effects on implementation of various parts of a radio node,
ranging from the selection of processing hardware to the RF front end. There
are a few critical points, such as the analog-to-digital conversion and the power
consumption of many of the components, that limit the choice of physical layer
architecture and, in the end, the achievable performance. The sections of this
chapter discussed these implementation aspects.
SDR has often been seen as a design problem mostly related to the low-level
implementation of a radio node capable of operating in multiple modes. Many
other issues, such as the management of resources and the handling of reconfig-
uration, suggest that there are also other significant aspects. The next chapter
introduces various standards related to SDRs and the current efforts related to the
standardisation process of frameworks for SDR development.
16
3 Standards
Standards are of an enormous importance considering quality, reliability, effi-
ciency and compatibility. Information technology industry is not an exception:
standards are essential from the point of view of e.g. compatibility, portability of
software components and the development process of products in general.
Currently, wireless communication industry and end users have to deal with
the problems arising from the constant evolution of air interface standards and
different standards in different countries, incompatibilities between wireless net-
works, and existence of legacy devices. SDRs can be seen as a solution to many
of these problems. On the other hand, SDRs have to conform to an exceptionally
large number of standards due to the multi-mode operation.
There are several standards bodies relevant to SDRs [4]: ANSI, TIA and IEEE
are responsible for interconnect standards, e.g. serial lines and LANs. These
organisations and ETSI define standards for analog hardware, e.g. antennas, RF
connectors and cables. Bus and backplane standards bodies include VSO and PCI.
Organisation responsible for internetworking standards, e.g. TCP/IP and ATM,
include ITU, ISO, ETSI, ARIB, IEEE, TIA and ANSI. OMG and Open Group
define standards for object oriented software.
Section 3.1 discusses the role of air interface standards as a reason for the need
to develop multi-mode radios, from the point of view of military and commercial
applications. Section 3.2 presents various types of hardware standards related
to SDRs. Section 3.3 discusses middleware technologies, which are currently
on the central focus of the most significant SDR projects. Sections 3.4 and 3.5
present two framework architectures for SDRs, i.e. the SCA and the SWRadio.
The SCA is the de facto standard for military and commercial SDR development
and the SWRadio is the result of an ongoing project for building an international
commercial standard based on the SCA. The chapter is summarised in Section
3.6.
17
the SPEAKeasy are listed for instance in [21]. The JCIT and multiple JTRS im-
plementations are examples of military SDRs currently in field use. For the JCIT,
the provided modulation formats can be found from [4] and the operating modes
and supported radio system standards are listed in [36]. In Table 1, there is the list
of the currently approved JTRS waveforms.
18
competing digital cellular radio standards. The adoption of the third generation
mobile phone standards may somewhat change the situation.
Commercially used air interfaces supported by future reconfigurable radios
may include mobile cellular standards, audio and video broadcasts, satellite com-
munications, local area networks, wireless local loops etc. Table 2 shows exam-
ples of these wireless systems [34]. The commercial demand for SDRs may rise
from the needs of users for roaming seamlessly across networks and getting ac-
cess to services anywhere without paying attention to the underlying technology,
which is queried by the services [34, 35].
3.2 Hardware
Even though one of the main goals of the SDR concept is to perform as many
radio functions as possible in the programmable digital domain, i.e. in software,
hardware standards still play a considerable role from the point of view of modu-
larity. Ideally, different vendors should be able to design hardware modules using
standard interfaces.
For physically connecting separate hardware elements of the radio system, a
number of standardised buses can be used, for example VME, PCI, cPCI, PC-104,
IEEE-1394 and Ethernet [4, 11]. For instance, the SPEAKeasy Phase I used the
VME bus, while the Phase 2 used the PCI bus. A radio peripheral designed for the
GNU Software Radio [37] uses USB2 for connecting to the PC that performs most
of the digital processing. Many of the buses have various physically different or
even non-standard connectors, for instance for different form factors. Thus, sig-
nalling within the buses and the possible external connectivity are separate issues.
The VME is also a chassis standard. The standardised mechanical specifica-
tions become important when commercial of-the-shelf (COTS) components are
used. Use of COTS components has become preferable also for military radios, in
order to reduce acquisition, operation and support costs and to gain upgradeabil-
ity [11]. A radio node may have serial and network interfaces. Possible physical
interfaces include for example RS-232, RS-422, RS-423, RS-485, Ethernet and
802.x [11]. At least base stations and military radios may also need different an-
tennas or other RF components for supporting a wide range of frequency bands
19
and operating modes. There are standards for the required connectors, waveg-
uides, cables etc.
Of course, the handsets of wireless cellular systems have demands different
from base stations or physically large military radios. At least currently, there
are no practical possibilities to add daughterboards or any other functional units,
apart from memory cards, after manufacturing. Therefore, the hardware standards
may seem less important in this context. Yet, the handsets have often an external
connector for data transfer, and the SDRs requiring reconfigurability may lay new
needs for standardisation. Certainly, there are also a lot of other standards related
to e.g. electronic circuit and board design, but they are usually unspecific to SDRs.
For the processing needs of SDRs, there are not yet even de facto standards
and in the most significant SDR projects, such as [11], there is a hardware ab-
straction layer for maximising independence from the underlying hardware. The
following section presents an object oriented method for the management and in-
terconnection hardware elements in heterogeneous processing environments. Ac-
tually, there is still a lack of high level tools for describing the systems and then
automatically generating code, especially concerning the partitioning of the pro-
cessing tasks into parts suitable for the heterogeneous processing environments of
SDRs, which include software and reconfigurable hardware [8]. There may be a
need for standardised procedures for also this kind of tasks.
3.3 Middleware
In the context of computer networks, the term middleware is used to denote the
core set of functions that enable easy use of communication services and dis-
tributed application services [33]. In other words, it provides means for manage-
ment of applications or services, the mapping of names to objects that provide
them, connection control, etc. In mobile communications, the middleware may
have functions for link monitoring and notifications to user or components of
significant events. The middleware is also one of the parts that is essential for
seamless use of services when multiple wireless standards are used.
Object oriented concepts can be used for partitioning of both software and
hardware. This practice provides the broadest reusability and portability. It is es-
pecially advantageous for software defined radios since reconfigurability makes
object oriented techniques and independence of the actual platform used essen-
tially necessary.
The JTRS military radio development program chose OMG’s object manage-
ment technologies for its framework for SDRs, called Software Communications
Architecture (SCA). The JTRS is discussed in the next chapter and the SCA is
treated in more detail at the end of this chapter.
The Object Management Group (OMG) is an open membership, non-profit
consortium that produces and maintains specifications for interoperable applica-
tions [10]. There are hundreds of members in the OMG, including most of the
large companies in computer industry. The next subsections introduce several
20
Client Object implementation
Request
OMG’s specifications, by using the definitions from OMG [10, 18] and the SCA
Developer’s Guide [12]. CORBA is the OMG’s middleware that is used in the
SCA, and the other specifications are needed for utilising the middleware for de-
velopment of systems with this architecture. The OMG’s own specification for
SDR development, i.e. the SWRadio, uses OMG’s Model Driven Architecture.
21
Client Object implementation Client Object implementation
IIOP
protocol
Object Request Broker 1 Object Request Broker 2
22
into language-specific type definitions and APIs (Application Program Interfaces).
These type definitions and APIs are used by the developer to provide application
functionality and to interact with the ORB.
The translation algorithms for various implementation languages are specified
by CORBA and are known as language mappings. CORBA defines a number
of language mappings including those for C++, Ada, and Java (along with many
others). An IDL compiler produces source files that must be combined with appli-
cation code to produce client and server executables. Details, such as the names
and numbers of generated source files, vary from ORB to ORB. However, the
concepts are the same for all ORBs and implementation languages. The outcome
of the development process is a client executable and a server executable.
23
Figure 3.3: Structure of the software architecture of the SCA [11]
24
Figure 3.4: Hardware Class Structure of the SCA [11]
tivity (HAL-C) for non-CORBA compliant hardware [22]. Especially high bit-rate
waveforms need specialised hardware.
The SCA has been designed also to meet commercial requirements, in addition
to military needs, and it is expected to become a standard. Standardisation is the
key to acceptance of a technology and therefore the JTRS program is cooperating
with the SDR Forum [15] and the OMG [10]. The SDR Forum is a non-profit
organisation that is dedicated to promoting the development and deployment of
technologies related to SDRs. It has been involved in the development of the SCA,
in order to ensure conformance with commercial requirements, such as avoiding
the overhead caused by military requirements. The SDR Forum is not a standardi-
sation organisation. Therefore, the SCA has been passed to a formal specification
body, i.e. the OMG. Standards organisations maintain liaison relationships with
the OMG.
On the commercial side, one drawback of the architecture is the lack of proper
CORBA support on some of the most common FPGAs and DSPs [25]. However,
there are projects addressing also this issue [26].
25
Applications consist of Resources and use Devices. Devices are types of Re-
sources that are used as software proxies for actual hardware devices. ModemDe-
vice, LinkResource, SecurityDevice, I/ODevice and NetworkResource are inter-
face extensions of the CF. They implement APIs for waveform and networking
applications. They conform to the functional entities of the SCA Software Refer-
ence Model that is based on the PMCS model.
3. Determine what services are needed beyond the API Service Groups
10. Generate language-appropriate template files for servant and user software
26
3.4.3 SCA Reference Implementation (SCARI)
3.5 SWRadio
The SWRadio is a specification of radio infrastructure facilities. The SWRadio
promotes portability of waveforms across SDRs [18]. The SCA has been used as
a basis for OMG’s work on the SWRadio. The SWRadio specification uses the
OMG’s Model Driven Architecture.
The specification supports an approach where the SWRadio platform provides
a standardised extensible set of software services that abstracts hardware and sup-
ports applications, such as waveforms and management applications. In the spec-
ification, there is defined a set of platform-independent interfaces. Applications
can be developed and ported onto various implementations. This approach pro-
vides a possibility for an open market where waveforms can be produced inde-
pendently of platforms and their providers.
There is a physical partitioning of the SWRadio specification into three main
chapters: UML profile for SWRadio, and PIM and PSM for the CORBA IDL.
A language for modelling SWRadio elements is defined in the UML profile for
SWRadio by extending the UML language with radio domain specific definitions.
A behavioral model of an SWRadio system, standardised APIs and example com-
ponent definitions that realise the interfaces are provided by the PIM. The PIM
specification is independent from the underlying middleware technology. For
modelling a software radio system defined in the PIM, UML and its extensions
provided by the UML profile for SWRadio are used. The SWRadio specification
also provides a mechanism for transforming the elements of the PIM model into
the platform specific model for the CORBA IDL.
27
Figure 3.5: SWRadio Layers [18]
There are three types of applications supported by the SWRadio Platform: Wave-
form applications that are the main focus, management applications and other
applications, such as network and end user applications.
28
(ISO IS 7498) of the International Standard Organization, which defines that the
communications functions should be structured into a stack of seven layers.
The use of reconfigurable components through standard interfaces and well
defined modules is encouraged by the approach. The specification uses extended
OSI model which allows Management and QoS interfaces to communicate with
any layer. The focus the SWRadio architecture is only on physical and link layers.
3.6 Summary
In general, multiple aspects, such as compatibility, reliability, portability and ease
of development, call for standardisation. In the context of radio systems, the mul-
titude of air interface standards has resulted in need for interoperable, reconfig-
urable systems. Different applications and systems need different air interface
modes and therefore reconfigurability is the only feasible solution to support a
great number of standards with a single radio set. There are also other emerg-
ing motives for reconfigurability, e.g. context aware services. For the hardware
required by these reconfigurable radio systems, there are standards, which were
discussed in this chapter.
A detailed architecture defined for the processing platform of SDRs would
lead to portability problems. Therefore, the focus has been on defining a com-
mon middleware that provides abstraction of the software and hardware platforms
and thus endorses portability and modularity. The SCA and the SWRadio are
open SDR framework architectures that make extensive use of object oriented
techniques, i.e. the middleware. They are the key elements leading to SDR stan-
dardisation.
The next chapter focuses on the research projects related to the SDRs. Early
projects have proven the viability of the SDR concept and there are projects in
progress, which aim to bring the SDR concept into mainstream radio architectures
by using the industry standard components discussed in this chapter.
29
4 Software Defined Radio Projects
This chapter reviews the historical perspective of the evolution of the SDR archi-
tectures and the current state of the art SDRs by presenting a few of the most in-
fluential SDR projects. Section 4.1 presents the SPEAKeasy program that proved
the potential of the SDR concept for military radios. Section 4.2 discusses the
ongoing JTRS program, which will replace the hardware intensive military radios
with the more flexible, interoperable SDRs [22]. The program is also developing
an open architecture framework for SDRs, i.e. the SCA. Section 4.3 presents a
few other projects that are either associated to research on SDR related topics or
to the development of SDR sets. Section 4.4 summarises the chapter.
4.1 SPEAKeasy
The SPEAKeasy was a US Department of Defence program whose aim was, in
cooperation with industry, to prove the concept of multi-band, multi-mode soft-
ware programmable radio operating from 2 MHz to 2 GHz [20]. It was intended
to be able to operate with multiple military radios by employing waveforms that
can be selected from memory, or downloaded from external storage or over-the-
air (OTA) [19]. The SPEAKeasy was designed as a totally open architecture that
can provide secure connections, interoperability and programmability. The bene-
fits of the architecture include seamless connection of various radios and bridging
between different systems. Military applications include tactical radio systems
as well as voice and data communications to aircraft and onto battlefield. Civil-
ian applications also exist: emergency communications, law enforcement radio
communications and public safety.
The SPEAKeasy program evolved from the earlier technologies of the Air
Force, i.e. Tactical Anti Jam Programmable Signal Processor (TAJPSP) initi-
ated in 1989 and the Integrated Communications, Navigation, Identification and
Avionics (ICNIA) system, which was one of the first systems to use a digital pro-
grammable modem, from the late 1970’s [20].
30
Figure 4.1: SPEAKeasy Phase I Architecture [21]
31
methods are (16, 7) and (31, 15) Reed-Solomon and convolutional codes of K=7,
R=1/2 and T=133 or 171 [19].
The Phase 1 system was first demonstrated in August 1994 to operate with
HAVE QUICK, HF modem, automatic link establishment and SINCARS [19].
Simultaneous frequency hopping transmission on HAVE QUICK and SINCARS
as well as bridging networks that use these waveforms were also demonstrated.
Programmability was also shown by modifying a waveform on two units. At
JWID-95 interoperability demonstration the system was demonstrated on-the-air
[20]. The Phase-1 modem and software performed well but lack of ease of use
remained a disadvantage.
32
Figure 4.2: SPEAKeasy Phase II Architecture [21]
the Phase1 architecture, which was based on functional flows lacking true mod-
ularity [2]. The modules communicated over the bus by using a layered protocol
[20] asynchronously without a centralised operating system [2]. The implementa-
tion units used the PCI bus. The bus formed the lowest layer of the protocol stack,
i.e. the physical layer. There were three software layers: link layer, communica-
tions layer and application layer [20]. The communications layer used the lower
layers for message passing, whereas the communication layer itself detected the
installed resources, established the links as well as performed the queueing and
buffering of the data. The application contained the waveform software that used
the APIs of the lower layer.
The Phase 2 was planned to be a four year project with model-year develop-
ment versions. Enhanced model-year-1 units were field demonstrated at Army’s
TX-XX-AWE experiment in 1997. They managed to accomplish bridging air-
craft HAVE QUICK UHF to Army SINCGARS VHF radios and hand-held LMR
[20]. The waveform for LMR compatibility was developed in less than 14 days
and it was downloaded to the SPEAKeasy units during the demonstration from a
laboratory far away.
The model-year-1 proved to be so successful that it went into production and
the Phase 2 had no chance to continue with further research. Therefore, a part
of the goals remain unaccomplished. The model-year-1 units did not include the
support for the full RF range, wideband waveforms, data gateways and network-
ing [20]. The production units were limited to 20 - 400 MHz and only a few
waveforms were implemented. The speed of the cryptographic processor lim-
ited simultaneous connections because there was no opportunity to implement
the AIM. The INFOSEC module should be able to support multiple simultaneous
COMSEC and TRANSEC functions and handle the context switching at different
rates. That remained a problem [20].
33
Spectrum Signal Processing Inc. and the NRL Software Radio [28], which is an
outgrowth of the JCIT. There is a group of specified domains, e.g. the hand-held
domain and fixed maritime domain, that have different needs. However, the JTRS
architecture ensures interoperability across radios designed for different domains.
The JTRS program is a process consisting of three steps that aim to define,
standardise and implement an architecture for software defined radios. The result
of step 1 was the definition of the base architecture. Step 2 refined the baseline
architecture to the SCA, which will be the basis for future military radios [2]. The
SCA has also been used as a starting point for standardisation process of commer-
cial SDRs, as described in the previous chapter. The next subsection describes the
first two phases, whereas the last two subsections discuss two already deployed
product families.
4.2.1 Background
34
4.2.2 Architecture
The JTRS program has focused on the common infrastructure software, i.e. the
middleware, instead of a detailed architecture. The were two reasons for this
decision: Firstly, in the SPEAKeasy radios, the infrastructure code comprised one
third of the whole software. Secondly, industry pointed out that portability of
components requires interfaces between radio entities and the platform [25]. The
architecture had to be clearly defined yet flexible, in order to provide extendibility
to new waveforms and hardware by rapid insertion of technology. Thus, the SCA
is the core of the JTRS architecture.
Modular design of both software and hardware allows easy upgrades and re-
placement of components. Legacy waveforms and new waveforms, like the Wide-
band Networking Waveform, are implemented in software [22]. The waveform
software is supposed to be common for all implementations in order to ensure in-
teroperability. The latest document of operational requirements includes 33 wave-
forms that each JTRS implementation should support [23]. The capabilities of the
JTRS are evolutionary in the sense that they can be increased along with techno-
logical advancements or when funding allows it.
35
available RF units, which use direct down-conversion, do not support high data
rates, but for the present military applications, the WITS is very suitable and the
capabilities can be expanded [2].
4.2.4 SDR-3000
36
4.3.2 CHARIOT
37
time reconfiguration concept, the leading packet of a stream is used to reconfigure
the unit at the head of the stream. This leads to fast distributed reconfiguration
since the streams control the flow independently [2].
4.3.3 SpectrumWare
The SpectrumWare project at MIT utilised the constantly advancing performance
of general purpose processors. An advantage of this processing platform is that
the radio subsystem and the applications use the same hardware and operating
system, which simplifies programming [2]. The development environment, i.e.
a UNIX OS, is widely known and mature. The core of the system consists of
the radio algorithms implemented on a workstation. The I/O between an external
wideband tuner and the workstation was a problem that had to solved.
In typical non-real-time operating system, user-space applications cannot per-
form even near real-time processing using I/O devices. There are many factors
that make the data transfer delays unpredictable. The SpectrumWare system uses
a modified UNIX OS and DMA-transfers pass data to buffers in kernel-space [2].
The buffers are mapped to user-space by using a virtual memory approach. The
variable delays and low capacity of the standard PCI bus resulted in need to design
a dedicated I/O solution, i.e. the General Purpose PCI I/O (GuPPI). The GuPPI
buffers data between a daughtercard and the workstation, thus relaxing the timing
issues. The transfers are performed using blocks of data.
The Signal Processing Environment for Continuous Real-Time Applications
(SPECtRA) was implemented to allow rapid development of reusable real-time
radio software [2]. The SPECtRA consists of a library of signal processing mod-
ules, a set of interface modules and a scripting language for defining SDRs. It
supports several adaptation methods based on environment and user needs. One
of the innovations was to pull data in the processing flow instead of pushing. This
makes multi-rate processing easier and decreases redundant processing.
An experimental system, which implemented a GSM base-station, was built.
In 1998, the project team left to start Vanu Inc. [3]. Vanu has build various
software implementations of waveforms, e.g. cellular standards. The signal pro-
cessing software is mostly written in a high level language.
SDRs were recently recognised by the FCC as a new category of radios. The
Vanu Software Radio GSM Base Station by Vanu Inc. was the first SDR device
to fulfil the FCC’s certification process [30]. This is a positive sign for the future
of the SDR concept since regulatory issues have been seen as one of the key
challenges [4].
38
Figure 4.3: ACTS Projects [33]
projects. There are areas where the coverage has been minimal within the ACTS
programme, i.e. the network and spectrum issues and business models.
Currently the work continues in the scope of the IST (Information Society
Technologies) programme within the EU’s Sixth Framework Programme (2002-
2006). The TRUST project adopted a user-centric perspective by examining the
user requirements in order to identify what is needed to support reconfigurable
radios. The SCOUT project is continuing the research initiated in TRUST on
reconfigurable terminal and network architectures. The research areas of SCOUT
include a number of technical, regulatory and business issues [35].
39
Figure 4.4: Universal Software Radio Peripheral [37]
tions between them. At the moment, the only fully supported operating system
is GNU/Linux but there is ongoing work at least on Windows and Mac OSX.
The currently available Gnu Radio Software supports only FM radio and HDTV
receiving. The FM radio requires a bandwidth of about 200 kHz which is usu-
ally out of the range of PC sound cards. The HDTV support necessitates a better
ADC. With relatively little work, the support could include for example NTSC
television, AM, SSB, Telemetry and HAM packet radio.
4.4 Summary
The SPEAKeasy program was a successful feasibility demonstration of the soft-
ware reconfigurable radio for military purposes. It also encompassed many im-
portant concepts for SDRs, such as the open and modular architecture as well as
the use of reconfigurable hardware. The program has had a number of successors.
The JTRS program focuses on portability of waveforms across radio plat-
forms, interoperability among radios, reuse of common software, use of cost ef-
fective commercial components and scalability. To achieve these goals, the JTRS
program has developed the SCA, which was discussed in the previous chapter.
There are several existing implementations of the SCA, e.g. the SCARI, and com-
plete JTRS compliant radio systems, such as the NRL Software Radio, the WITS
and the SDR-3000.
There are also several other SDR projects. A few of them were presented
in this chapter. The JCIT is another military software radio developed by the
40
NRL. Two significant academic projects were presented: the CHARIOT is Vir-
ginia Tech’s SDR and the SpectrumWare was developed in MIT until the project
evolved to founding of the Vanu Inc. and a commercial product line. In Europe,
many SDR related projects have been conducted within ACTS and IST technol-
ogy programmes. The open source community has also launched an SDR project,
i.e. the GNU Radio.
Different radios for various application domains serve different purposes [2].
There has to be done trade-offs that depend on the domain. For example, hand-
held devices are limited by size and power consumption, whereas fixed station ra-
dios may e.g. relax RF front end requirements by employing multiple RF modules
or use high power DSPs. Therefore, none of the architectures proves to be better
than all the others. For instance, the WITS performs well in the main military
domains, while the CHARIOT’s approach is suitable for the low-power hand-held
radios, which need high bit-rates. Nevertheless, at a high level, the architectures
are usually very similar to reference models, such as the PMCS model.
41
5 Conclusions
The software defined radio is a far reaching topic, since it is an all encompassing
solution, for which only imagination limits the capabilities that can be planned.
Thus, in the scope of a short report, only a part of related items can be treated.
A relatively traditional view was chosen, omitting potential future trends like the
Cognitive Radio.
Chapter 2 discussed the implementation issues mainly focusing on the physi-
cal layer. The implementation of software defined radios is a wide and challenging
issue. The starting point of the chapter was the general structure of digital com-
munication systems. The requirements set by the need for multi-band, multi-mode
operation and reconfigurability have implications on implementations of various
parts of a software defined radio set, ranging from the selection of processing
hardware to the RF front end.
There are a few critical points: considering the physical implementation, the
analog-to-digital conversion and the power consumption of many of the compo-
nents are among the most important issues, which limit the choice of physical
layer architecture and eventually the achievable performance
Software defined radio has often been seen as a design problem, mostly related
to the low-layer air interface implementation of a radio node, capable of operat-
ing in multiple frequency bands and multiple modes. There are a lot of other
significant tasks, such as the resource management and the handling of reconfig-
uration, which suggest that the scope of the concept is wider. There was also a
short discussion of these topics in Chapter 2.
Chapter 3 introduced various standards related to software defined radios and
the current efforts related to the standardisation process of frameworks for efficient
development process.
In general, multiple aspects, including compatibility, portability and rapid de-
velopment cycles, lay demand for standardisation. Considering radio systems, the
great number of air interface standards has resulted in the need for reconfigurable
systems capable of operating together with a wide variety of legacy systems. Dif-
ferent services and communication environments need different modes, thus mak-
ing the reconfigurability the only feasible solution for integrating a wide range of
applications in a single radio set. There are also other emerging techniques that
need reconfigurability, such as context aware services that dynamically optimise
the air interface.
The framework architectures include the SCA and the SWRadio. They incor-
porate industry standard object oriented techniques into the processing environ-
ment of software defined radios. A detailed architecture defined for the process-
ing platform would lead to weak portability of software modules. Therefore, the
focus has been on defining a common middleware that provides modular abstrac-
tion of the software and hardware platforms. The SCA and the SWRadio are open
architectures that extensively use the middleware. They are an essential path to
standardisation.
42
Chapter 4 focused on the research projects related to the software defined ra-
dios. Early projects have proven the viability of the concept and there are projects
in progress aiming to bring software defined radios into mainstream radio archi-
tectures by using the industry standard components that were discussed in the
chapter.
The SPEAKeasy program was a successful feasibility demonstration of the
software reconfigurable radio for military purposes. It has had a number of suc-
cessors. The JTRS program focuses on the portability of waveforms across ra-
dio platforms, interoperability among radios, reuse of common software, use of
cost effective commercial components and scalability. To achieve these goals that
are common to many projects, the JTRS program has developed the SCA, which
was discussed in Chapter 3. The SDR Forum, which is a non-profit organisation
promoting software defined radio technologies, has also contributed to the SCA.
There are several existing instantiations of the JTRS architecture, including the
WITS and the SDR-3000.
A number of other significant projects were also presented in Chapter 4. These
were the JCIT military radio, and two academic projects: Virginia Tech’s CHAR-
IOT and MIT’s SpectrumWare. One of the main contributions of CHARIOT was
a new kind of a reconfigurable processor, i.e. the configurable computing ma-
chine called STALLION. SpectrumWare has evolved to a company called Vanu
Inc. that has a line of software radio products, which use conventional general pur-
pose computer processors instead of more specialised hardware. In Europe, many
projects related to software defined radio have been organised within EU’s tech-
nology programmes. The open source community has also had a project called
the GNU Radio.
A few critical issues were identified. The wideband A/D conversion and power
consumption may be problematic in part of the application domains. The com-
plexity of the management of networks, capable of supporting dynamically re-
configurable services, may at least slow down the adoption of some of the ideas.
However, the adopted systems have proven the viability of the concept of software
defined radio. None of the architectures is optimal for all applications. Instead,
different approaches serve different purposes. The problem has been addressed:
the frameworks, i.e. SCA and SWRadio, attempt to promote the portability and
reuse of software across different architectures. The FCC approval of Vanu Soft-
ware Radio was a positive sign considering the future possibilities of software
reconfigurable radios.
43
Abbreviations
44
FEC Forward Error Control
FFT Fast Fourier Transfer
FM Frequency Modulation
FPGA Field Programmable Gate Array
FSK Frequency Shift Keying
GPP General Purpose Processor
GSM Global System for Mobile Communications
GuPPI General Purpose PCI I/O
HAL-C Hardware Abstraction Layer Connectivity
HF High Frequency
ICNIA Integrated Communications, Navigation, Identification
and Avionics
IDL Interface Definition Language
IEEE Institute of Electrical and Electronics Engineering
IF Intermediate Frequency
INFOSEC Information Security
IOR Interoperable Object Reference
ISO International Standard Organization
IST Information Society Technologies
ITU International Telecommunication Union
JCIT Joint Combat Information Terminal
JPO Joint Program Office
JTRS Joint Tactical Radio System
KP Key Processor
KPP Key Performance Parameter
LAN Local Area Network
LMR Land Mobile Radio
LNA Low Noise Amplifier
LRU Line Replaceable Unit
LSB Least Sensitive Bit
LSB-SC Lower Sideband - Suppressed Carrier
LUT Look-Up Table
MAC Medium Access Control
MDA Model Driven Architecture
MPSK M-ary Phase Shift Keying
MOPS Millions of Operations Per Second
MRSC Modular Software Defined Radio Consortium
MWS multimedia wireless systems
OE Operating Environment
OMG Object Management Group
OQPSK Offset Quadrature Phase Shift Keying
ORB Object Request Broker
OSI Open System Interconnection
OTA Over-the-Air
45
PAN Personal Area Network
PCI Peripheral Component Interconnect
PMCS Programmable Modular Communications System
PIM Platform-Independent Model
PSK Phase Shift Keying
PSM Platform-Specific Model
QAM Quadrature Amplitude Modulation
QDPSK Quadrature Differential Phase Shift Keying
QoS Quality of Service
RISC Reduced Instruction Set Computer
RF Radio Frequency
RLC Radio Link Control
SCA Software Communications Architecture
SCARI SCA Reference Implementation
SDR Software Defined Radio
SFDR Spurious Free Dynamic Range
SINAD Signal-to-Noise-and-Distortion
SINCGARS Single Channel Ground to Air Radio System
SNR Signal-to-Noise Ratio
SPECtRA Signal Processing Environment for Continuous Real-Time
Applications
SRI Soft Radio Interface
TAJPSP Tactical Anti Jam Programmable Signal Processor
TIA Telecommunication Industry Association
TRANSEC Transmission Security
UHF Ultra High Frequency
UML Unified Modeling Language
UMTS Universal Mobile Telecommunications System
USB Universal Serial Bus
USB-SC Upper Sideband - Suppressed Carrier
USRP Universal Software Radio Peripheral
VHF Very High Frequency
VME Versa Module Europa
VSO VITA Standards Organization
WFA Work Force Administration
WITS Wireless Information Transfer System
WNW Wideband Networking Waveform
xMDS Multichannel Multipoint Distribution System
XML Extensible Markup Language
46
References
[1] R. E. Ziemer, R. L. Petterson, Introduction to Digital Communication, 2nd
edition, Prentice Hall, 2000
[2] J. H. Reed, Software Radio: A modern Approach to Radio Engineering,
Prentice Hall, 2002
[3] Walter Tuttlebee, Software Defined Radio: Enabling Technologies, Wiley,
2002
[4] J. Mitola III, Software Radio Architecture, Wiley, 2000
[5] J. Mitola, “The Software Radio Architecture”, IEEE Communications Mag-
azine, May 1995
[6] M. Dillinger, K. Madani, N. Alonistioti, Software Defined Radio: Architec-
tures, Systems and Functions, Wiley, 2003
[7] H. Tsurumi, Y. Suzuki, ”Broadband RF Stage Architecture for Software-
Defined Radio in Handheld Applications”, IEEE Communications Maga-
zine, February 1999
[8] Z. Salcic, C. F. Mecklenbrauker, “Software Radio - Architectural Require-
ments, Research and Development Challenges”, The 8th International Con-
ference on Communication Systems, Volume 2, November 2002
[9] S. Srikanteswara, R. C. Palat, J. H. Reed, P. Athanas, “An Overview of Con-
figurable Computing Machines for Software Radio Handsets”, IEEE Com-
munications Magazine, July 2003
[10] Object Management Group, http://www.omg.org
[11] Software Communications Architecture Specification V3.0, JTRS JPO, Au-
gust 2004
[12] SCA Developer’s Guide Rev 1.1, Raytheon Company, 2002
[13] JTRS ORD Waveform Extract, Version a, April 2003
[14] Communications Research Centre, “SCARI”, http://www.crc.ca/en/html/
rmsc/home/sdr/projects/scari
[15] Software Defined Radio Forum, www.sdrforum.org
[16] SDR Forum, “Modular Multifunctional Information Transfer System
(MMITS) Task Group”, http://www.sdrforum.org/MTGS/formins.html
[17] P. Ting, B. H. Wang, C. S. Tao et al, An Adaptive Hardware Platform for
SDR, SDR Forum Contribution, 2001
47
[18] PIM and PSM for Software Radio Components, Final Adopted Specification,
OMG, May 2004
[19] R. L. Lackey, D. W. Upmal, “Speakeasy: The Military Software Radio”,
IEEE Communications Magazine, May 1995
[20] P. G. Cook, W. Bonser, “Architectural Overview of the SPEAKeasy System”,
IEEE Communications Magazine, April 1999
[21] W. Bonser, SPEAKeasy Military Software Defined Radio, International Sym-
posium on Advanced Radio Technologies, 1998
[22] JTRS JPO, “Joint Tactical Radio System”, http://jtrs.army.mil/sections/
technicalinformation/fset_technical_sca.html
[23] P. A. Eyermann, M. A. Powell “Maturing the Software Communications
Architecture for JTRS”, Proceedings of the IEEE Military Communications
Conference, vol 1, 2001
[24] B. Tarver, E. Christensen, A. Miller et al, “Digital Modular Radio (DMR) as
a Maritime/Fixed Joint Tactical Radio System (JTRS)”, Proceedings of the
IEEE Military Communications Conference, vol 1, 2001
[25] J. Mitola III, “SDR Architecture Refinement for JTRS”, Proceedings of the
Military Communications Conference, vol 1, 2000
[26] L. Pucker, G. Holt, “Extending the SCA Core Framework Inside the Modem
Architecture of a Software Defined Radio”, IEEE Radio Communications,
March 2004
[27] Spectrum Signal Processing, “SDR-3000 cPCI Software Defined Ra-
dio Tranceiver Platform” http://www.spectrumsignal.com/products/
sdr/sdr_3000.asp
[28] Telenetics, Inc., “Software Radio”, http://www.telenetics-inc.com/
SW%20Radio.html
[29] Mobile and Portable Radio Research Group / Virginia Tech, “Virginia Tech’s
GloMo Effort”, http://www.mprg.org/research/glomo-archive/index.shtml
[30] Vanu, Inc., “The Software in Software Radio”, www.vanu.com
[31] J. Chapin, Overview of Vanu Software Radio, Vanu, Inc, 2002
[32] W. H. Tuttlebee, “Software Radio Technology: A European Perspective”,
IEEE Communications Magazine, February 1999
[33] D. Ikonomou, J. M. Pereira, J. da Silva,“EU funded R&D on Re-configurable
Radio Systems and Networks: The story so far”, Infowin Thematic Issue -
Mobile Communications, ACTS, 2000
48
[34] Information Society Technologies, “IST - Strategic Objectives - Mobile and
Wireless”, http://www.cordis.lu/ist/so/mobile-wireless/home.html
[37] Free Software Foundation, “GNU Radio, The GNU Software Radio”,
http://www.gnu.org/software/gnuradio
49
Lemminkäisenkatu 14 A, 20520 Turku, Finland | www.tucs.fi
University of Turku
• Department of Information Technology
• Department of Mathematical Sciences
ISBN 952-12-1486-4
ISSN 1239-1891