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

OVERVIEW The six steps in the systems-level design process associated with the software radio are illustrated in Figure 6-1.. ANTENNA TRADEOFFS The first tradeoff defines the structure o

Software Radio Architecture: Object-Oriented Approaches 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)

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

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 tradeoff

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 may 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 segment 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-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

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 middleware 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 lowest 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 dede-velopment 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/ DAC, 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 antenna 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?

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?