Kiến trúc phần mềm Radio P6 pptx

Softwar e Radio Arc hitecture: Object-Oriented Approac hes to Wireless Systems Engineering
Joseph Mitola III
Copyright
c
!2000 John Wiley & Sons, Inc.
ISBNs: 0-471-38492-5 (Hardback); 0-471-21664-X (Electronic)
6
Segment Design Tradeoffs
I. OVERVIEW
The six steps in the systems-level design process associated with the software
radio are illustrated in Figure 6-1. The tradeoffs proceed from front end to
back end. The choice of antennas (step 1 in the figure) determines the number
and bandwidth of RF channels (step 2). This, in turn, constrains the numbers
and bandwidths of ADCs (step 3). Some waveforms may require dedicated
ASICs (e.g., W-CDMA despreaders) in front of the ADCs. Additional parallel
IF processing and ADC paths may be necessary to support multiple-service
bands simultaneously. The ADCs provide high-speed streams for heteroge-
neous multiprocessing (step 4). Digital interconnect fans these streams out to
digital-filter ASICs. The resulting narrowband streams then interleave among
DSPs, medium-speed interconnect, and general-purpose processors yielding a
multithreaded, multitasking, multiprocessing operating environment. Software
objects must be organized into real-time objects (step 5). The effective hosting
of these objects onto this complex operating environment requires a refined set
of techniques unique to this text called
SDR performance management
(step 6).
These six tradeoff steps are introduced in this section and discussed in depth
in the subsequent chapters.
Figure 6-1
Six-step segment design-tradeoff process.
236

ANTENNA TRADEOFFS
237
Figure 6-2
Antenna tradeoffs.
II. ANTENNA TRADEOFFS
The first tradeoff defines the structure of the antenna segment and implicitly
the RF conversion segment. Maximum system performance requires resonant
narrowband antennas. As illustrated in Figure 6-2a, this approach typically re-
sults in multiple parallel antenna/RF conversion channels. In the specific case
illustrated in the figure, an advanced PDA needs to operate in first-generation
cellular (AMPS), and second- or third-generation digital cellular (PCS) bands.
In addition, for location-aware services, the PDA has a GPS receiver. Finally ,
in order to operate on the corporate RF LAN, it supports a LAN band. One
could fabricate such a PDA with parallel RF channels. The physical inte-
gration of the disparate RF devices presents challenges. Given a commodity
GPS chip and a Bluetooth-class RF LAN, however, the parts costs could be
low.
The broadband approach illustrated in Figure 6-2b simplifies the antenna
and RF design to only two parallel channels. Finally, Figure 6-2c illustrates
the spectral coverage of a single wideband antenna. Note that the antenna
response is not uniform across such a broad range. The broad spectral cov-
erage needed for SDR flexibility therefore can drive one toward many par-
allel overlapping narrowband channels. This can be an effective approach if
cost is not a major consideration. Alternatively, the design may employ fewer
channels with wider RF coverage per channel. Transmission efficiency and
matching voltage standing wave ratios (VSWR) are more challenging as band-
width increases. Below 100 MHz, multi-octave antennas and RF segments are
238
SEGMENT DESIGN TRADEOFFS
well-established products. As frequency increases, wavelengths approach the

physical dimensions of the RF devices, making it more difficult to exceed
an octave of RF coverage. Since antennas, RF conversion, and IF processing
through the first ADC can account for over 60% of the manufacturing cost
of an SDR node, reducing the number of RF channels is a significant design
tradeof f.
III. RF AND IF PROCESSING TRADEOFFS
The second tradeoff concerns RF and IF conversion. Multichannel transceivers
in TDD bands require an interference-suppression architecture that could in-
clude antenna isolation, programmable analog filters, and/or active cancella-
tion. The transmitter may require both linear operation (e.g., for W-CDMA and
QAM waveforms) and nonlinear operation (e.g., class-C amplifier for high-
power efficiency with FSK or PSK waveforms). Single-channel receivers may
resort to nonlinear distortion of the incoming waveform (e.g., for a narrow-
band direct-conversion architecture).
Multichannel receivers, on the other hand, must match the RF and IF con-
version parameters to the ADC, digital filtering, and signal recovery algo-
rithms of the back-end. The goal of this tradeoff is to balance the noise,
spurious components, intermodulation products, and artifacts as illustrated in
Figure 6- 3. The receiver may include multiple RF/IF conversion stages (e.g.,
a superheterodyne—“superhet”—receiver). Alternatively, a single stage may
convert the RF signal directly to baseband (the direct-conversion or “homo-
dyne” receiver) [241]. Since the direct-conversion receiver has fewer parts,
its manufacturing costs m ay be less than the superhet, which may have better
performance. The thermal noise floor will be determined by the total band-
width (e.g., in interference-limited bands below 400 MHz), or by the first LNA
(e.g., in cellular and microwave bands). The thermal noise will be processed
through the RF and IF conversion stages, resulting in noise shaping across the
passband. Spurious responses (“spurs”) and LO leakage can mask subscriber
signals if ineffectively filtered. LO leakage can be particularly problematic in
homodyne receivers [245]. A well-balanced architecture keeps the peak en-

ergy of all noise, spurs, and artifacts at about half of the least significant bit
(LSB) of the wideband ADC.
IV. ADC TRADEOFFS
The third tradeoff is the design of the ADC se gment. Maximum sampling
rate is obtained for a given clock technology in a quadrature-sampling ADC
architecture. Such ADCs can introduce nonlinearities due to mismatching be-
tween the in-phase (real) and quadrature (imaginary) conversion channels.
Real oversampling with digital quadrature provides a lower-complexity alter-
DIGITAL ARCHITECTURE TRADEOFFS
239
Figure 6-3
RF tradeoffs include staging, conversion frequencies, and filtering.
native. In addition, one must match the ADC architecture to the structure of
the service bands being supported. If two or three 25 MHz bands spaced
hundreds of MHz apart are to be supported, one may have more total dy-
namic range using multiple medium-bandwidth ADCs instead of one su-
perwideband (e.g., 500 MHz) ADC. Each medium-bandwidth ADCs access
band may be programmable by tuning the final LO. Such an approach there-
fore complicates the RF architecture, but reduces the interconnect band-
width and processing capacity of the next stage. The set of ADC architec-
ture alternatives is similar to the RF access alternatives illustrated in Figure
6-2.
V. DIGITAL ARCHITECTURE TRADEOFFS
The fourth tradeoff concerns the mix of parallelism and pipelining of the
digital signal processing hardware from ASICs and FPGAs to DSPs and
general-purpose processors. Figure 6-4 illustrates the processing flow among
wideband ADCs, DACs, and reconfigurable ASICs or FPGAs. High-speed
(gigabyte-per-second) digital interconnect is necessary to fan wideband ADC
streams out to digital filtering FPGAs or ASICs. Reconfigurable processors
and despreader ASICs may reduce or eliminate the need for wideband dig-

240
SEGMENT DESIGN TRADEOFFS
Figure 6-4
Digital architecture tradeoffs.
ital interconnect by either embedding the interconnect on-chip or producing
baseband streams directly.
Digital filtering of high-data-rate ADC streams yields much lower data rate
subscriber baseband channels. Medium bandwidth digital interconnect (hun-
dreds of megabytes per second) then provides flexible paths among DSPs
and general-purpose processors. The architecture of local and global mem-
ory among the processors also can be a significant contributor to algorithm
performance. Balancing these high-speed data flows and bandwidth reduction
steps against clusters of processing capacity and memory is a central con-
cern of the digital architecture tradeoffs. The selection of an appropriate ISA
is part of this step that determines the availability and maturity of software
tools.
VI. SOFTWARE ARCHITECTURE TRADEOFFS
The fifth tradeoff concerns the organization of the radio software into appro-
priately packaged data structures and real-time algorithms. Figure 6-5 sum-
marizes software design tradeoffs as a function of the level of abstraction of
the capability. At the highest level, interfaces among applications and services
need to be radio-aware so that the radio’s low data rates, high variability in
data transfer times, and occasional outages do not severely curtail user satis-
faction with the services. In the radio applications layer, object-oriented de-
sign techniques help group related data structures with appropriate algorithm
methods. This simplifies detailed design, development, testing, deployment,
and evolution of the software architecture. The terminology and approaches
of object-oriented design may be applied to all the functions of the radio.
This facilitates the realization of those functions in hardware, firmware, or
software, as a function of technology and project needs.

PERFORMANCE MANAGEMENT TRADEOFFS
241
Figure 6-5
Overview of software architecture tradeoffs.
Projects may be implemented using conventional software techniques. With
such approaches, the radio applications and infrastructure software elements
are intricately interwoven. Open-architecture approaches now favor the use of
the industry-standard CORBA [216] in radio infrastructure m iddleware. Such
middleware reduces the coupling between radio functions and distributed pro-
cessor hardware. This adds flexibility but requires processing capacity above
that which is needed for a closed architecture. Accurate characterization of the
processing requirements of modular collections of open-architecture software
can be challenging. At the lo west level of abstraction is the real-time interface
to the hardware platform. This includes not just the processors, but the many
computer-controlled features of the analog radio platform. Software design
tradeoffs, then, include both top-down application of open-architecture princi-
ples and bottom-up integration of existing hardware, firmware, and software
components.
VII. PERFORMANCE MANAGEMENT TRADEOFFS
The final major tradeoff concerns the management of processing demand of-
fered by the software against the resources provided by the hardware platform.
Accurate characterization of processing demand requires benchmarking. Ac-
curate prediction (e.g., at proposal time), can be accomplished using queuing
theory techniques that have been refined and reduced to the structured method
described in the corresponding chapter of this text. A sustained measurement
and instrumentation campaign to monitor performance implications of de-
velopment decisions reduces development risk. Performance prediction and
management steps add cost to a software radio development program. One
therefore must balance the cost of performance management against the bene-
fits of reduced development risk. This text shows how to manage performance

affordably.
242
SEGMENT DESIGN TRADEOFFS
VIII. END-TO-END TRADEOFFS
Other important tradeoffs include end-to-end tradeoffs. One of the most im-
portant in the software radio is the allocation of dynamic range among RF, IF,
ADC, DSP hardware (e.g., FPGAs and ASICs), and algorithms. Another is the
allocation of software objects to hardware components. After considering the
antenna segment, the RF, ADC/ D AC, DSP, software, and integration aspects
are considered in turn.
IX. EXERCISES
The following questions review the material in the first part of the text. They
also motivate the subsequent chapters.
1.
Review the disaster-recovery case study. List the RF bands that need to be
addressed. What antennas are needed? Search the web for COTS a ntenna
products. List antenna products that you would employ in a contemporary
design. Which of these antennas are programmable? Is there any flexibility
that could be software-defined? What about a next-generation product?
2.
Continuing with the case study, list the RF conversion components that are
needed in a conventional design. What is the modularity of these compo-
nents? What fraction of these components are integrated transceivers, and
what fraction are modular at some other level of granularity? Is the data
processing in devices physically separate from the RF access? Could the
baseband streams (e.g., voice and data) be switched in software on LANs
and workstations? How much work is it to determine the answer to this
question? Did you use a systematic method to address this question? Do
you know of one that you could have used?
3.

Also in the case study, from the bandwidths of the RF access bands derive
the bandwidths of the ADCs necessary to access these bands digitally. What
are the output bandwidths of these ADCs in MBps?
4.
Suppose narrowband channels (e.g., AM and FM push-to-talk) require 10
MFLOPS and second-generation standards like GSM require 30 MFLOPS
per channel. How much digital signal processing capacity is required for
the disaster-recovery application? How many vans are in your system?
If you do not know, assume there are five. Can the channel capacity be
partitioned among these vans? How many of what kinds of processors do
you need? You could multiply the number of channels times the processing
requirements per channel and then divide by the capacity of a processor.
You could also apply some factors for realism, such as multiplying the
number of processors by two so that each has 50% spare capacity. Does this
yield an adequate sizing of the processors? Are they dedicated or pooled?
EXERCISES
243
5.
What software is needed for the disaster-relief case study? Of this software,
which modules are in the front-end, which are in the back-end, and which
are distributed across the system? How many lines of code will be in the
system? How can you estimate this parameter?
6.
What are the end-to-end issues in this case study?