Kiến trúc phần mềm Radio P12 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) 12 Software Com po nent Characteristics This chapter addresses the structure and function of low-level software compo- nents. These include algorithms, modules (e.g., Ada packages, C++ objects), and APIs. The perspective is bottom-up, with the emphasis on computational complexity. Low-level algorithms may be simple at first, but complexity can increase over time. The increases in complexity can occur with research ad- vances. Measures taken to compensate for a performance problem in one area (e.g., noisy voice channel) can increase complexity of an algorithm (e.g., dithering the digital LO to spread homodyne artifacts over the voice band, improving voice SNR). Sometimes algorithms have to be restructured to in- tegrate new advances. This chapter introduces low-level algorithms and com- plexity, core aspects of software component tradeoffs. It also describes APIs useful in implementing the layers defined above. I. HARDWARE-SOFTWARE INTERFACES The SDR engineer must ensure that services are robust. That is, services should be available in spite of the challenges of maintaining isochronism in a d is- tributed multiprocessing environment. External effects of radio propagation, noise and interference, impede the delivery of such services. The SDR ac- cesses multiple bands and modes simultaneously. The advanced implementa- tions manage spectrum use on behalf of the user—band and mode selection, power levels, error-control coding, and waveform choice. In some cases, the services include bridging across modes so that dissimilar legacy systems can intercommunicate. In other cases, users may need special applications encap- sulated a s scripts o r Jav a-applet like structures, which m ay be defined via (secure) over-the-air downloads. As listed in Figure 12-1, these services demand that radio applications in- clude shared resources and interleaved “multithreaded” information flows. In addition, the radio applications must keep track of the state of each such in- formation flow. Infrastructure software includes specialized interrupt-service- routines (ISRs). This software needs efficient use of memory including pro- gramming direct memory access (DMA) hardware. Managed access to shared resources includes the use of semaphores. In addition, parallel execution of in- structions occurs on multiple levels. One may assign independent information 384 HARDWARE-SOFTWARE INTERF ACES 385 Figure 12-1 Hardware-software interaction viewed by level of abstraction. streams to distinct boards, chips, or pipelines. The result is a multithreaded software system with multiprocessing. Handsets usually hav e the simplest software environments, limited to only two or three bands and independent information streams at a time. But even such simple SDRs require algorithms to generate air interface waveforms of specified spectral purity. They include digital carrier tracking, demodulation, and protocol stacks. And they must deliver the required QoS in spite of radio channel impairments on a given band and mode. Finally, they must do this within the constraints of the RF and digital processing platform. This chap- ter therefore begins by considering hardware-software interactions in SDR algorithms. It goes on to characterize SDR algorithms and APIs. A. DSP Extensions Consider first the software interactions with the hardware platform(s) (e.g., Figure 12-2). One DSP may be allocated to a modem algorithm per RF car- rier . General-purpose (GP) black processors may b e dedicated to link-level processing software, while GP red processors support the higher levels of the protocol stack and the user interface. The DSP platforms have extended hard- ware instruction sets, real-time operating system kernels, run-time libraries, 386 SOFTWARE COMPONENT CHARACTERISTICS Figure 12-2 Illustrative SDR hardware platform. and other software tools that reduce software development time. Instruction timing will have a first-order impact on one’s ability to deliver robust per- formance in the isochronous streams. Timing described in DSP manuals may underemphasize the overhead associated with setting up pipelines (e.g., for digital filtering). Performance m ay degrade due to cache misses and other factors related to context switching such as termination, handoff from one task to another, and resources used by applications-level dispatching code. Digital signal processors therefore define much of their value-added in terms of significantly faster execution of computationally intensive algorithms such as filtering, demodulation, and sin( )/cos( ) arithmetic processing. These are facilitated by extensions to instruction sets, which include the following: " Instruction set extensions – Register, direct, indirect, immediate addressing – Bit-reversed addressing – Circular (modulo- N ) addressing – Hardware push/pop, semaphore – Repeat- N (no loop overhead) – Multiply-accumulate (load, multiply, add, increment, iterate) – Parallel multiply-add " Data forma t extensions – Fix, float, double- and triple-precision integer Address modes such as register, indirect, and immediate allow one to accom- plish software tasks entirely within the register set. This avoids the increased latency of memory access (“register” types). DSPs perform very efficient t able- HARDWARE-SOFTWARE INTERF ACES 387 Figure 12-3 Illustrative multiply-accumulate algorithm structure. lookup operations (“indirect” types); and include operands in the same fetch as the instruction, again avoiding memory accesses (“immediate data” types). Bit-reversed addressing allows one to extract the results of the ubiquitous fast Fourier transform (FFT) from an in-place array without suffering the multiple-instruction overhead of calculating the address of the next sample. Instead, one simply reads the in-place FFT in bit-reversed address order to shuffle the results to normal time or frequency domain order. Isochronous tasks include many double-buffer operations in which words or blocks are written into a shared buffer by one task while they are read from the same buffer by another task. If there are N words in the shared buffer, hardware modulo N addressing resets the buffer pointer to zero in hardware whenever it reaches N . This avoids the overhead of checking this condition in software and thus speeds up short loops by factors of 2 or more. In addition, the DO loop has a hardware equivalent, repeat N , in which loop indexing and testing occurs in hardware in parallel to the execution of the substantive instructions in the loop, again significantly speeding up loops. Multiply-accumulate instructions are critical to digital filters that typically have an algorithmic structure similar to that illustrated in Figure 12-3. DSP hardware speeds up the bandpass filters (BPF in Figure 12-3), which individ- ually include multiply-accumulate steps. It also speeds up the overall demod- ulator algorithm by efficient execution of weighted multiply-accumulate steps implicit in the summing junctions of the figure. In addition, DSP chips gener- ally have sin/cos lookup tables or sin/cos approximation algorithms. Hardware lookup tables (CORDIC) speed up the generation of reference waveforms such as the sin and cos ( Wo + 85) of the algorithm in the figure. Finally, DSPs generally offer data format extensions such as 32-, 48-, and 64-bit integer, fixed and floating point arithmetic formats. Certain algorithm structures that arise naturally in SDRs require such formats. DSPs with fewer bits of precision are smaller and require less power. They therefore demand less average battery drain in critical handset applications than their larger- precision cousins. A clock that is counted down from a fast crystal may require double- or triple-precision integer arithmetic. Periods of long data transmis- sion may require this arithmetic, such as on a microwave radio link which is expected to operate for months before being reset. Multiple-data fetch instruc- 388 SOFTWARE COMPONENT CHARACTERISTICS Figure 12-4 Illustrative real-time DSP task. tions fill filtering registers or floating point pipelines quickly. These instruc- tion extensions avoid much software overhead at the expense of increased complexity of the processor core. Intel’s M ulti-Media Extensions (MMX) for the Pentium processors extend the standard Intel architecture by including multiple-data fetch and other in- structions to enhance multimedia operations needed in today’s desktop sys- tems. These extensions have begun to blur the line between general-purpose Complex Instruction Set Computers (CISC) and DSP chips. For the moment, DSP chips provide greater parallelism and ISA extensions to reduce the total number of processors by a factor of two to ten compared to MMX Intel chips for most SDR applications. This is not to say that general-purpose processors cannot be used for software radio research. For example, MIT has used the DEC Alpha chip for their virtual radio [178]. DSP teams apply skill in the use of DSP chips to enhance QoS, or to reduce the hardware footprint. Details are available in texts on programming DSPs [364, 365]. Those details are not necessary for the architecture-level analysis. B. Execution Timing Execution timing techniques ensure that the timing constraints imposed by isochronism are met. Figure 12-4 illustrates the lo w-level software structures associated with a typical real-time DSP task. When the informal term real-time is used in an SDR context, one generally means that the software must be exe- cuted within some timing window. This window is defined by the average data rate of a continuous information stream and the maximum size of the buffer that introduces tolerable delay through the processor. For example, a 64 kbps voice channel delivers 8000 8-bit samples to a DSP per second (125 ¹ sec betw een samples). Listeners can tolerate up to about 100 ms of end-to-end delay before beginning to perceive a time delay; end-to-end delays of 250– 500 ms become uncomfortable. Since there may be many processing steps in HARDWARE-SOFTWARE INTERF ACES 389 Figure 12-5 Illustrative timing diagram. an end-to-end path, a given DSP task may be allocated 10 ms of time delay. This means that the processor may accumulate 8000 # (10 ms = 1000 ms) = 80 samples in the input buffer. One may allocate two buffers with DMA programming that immediately switches buffers when one is full (“Ping-Pong” or “double buffering”). The DSP supports a continuous input stream while accumulating 80 # 125 ¹ sec of time (i.e., 10 ms) for software processing. As the buffer size increases, the software overhead associated with initializing the processing, setting up and controlling the processing loops, etc. is distributed over more samples, increasing efficiency and hence throughput. Figure 12-5 illustrates this process for a 150 kHz ADC with overhead that reduces the time available between ten sample blocks to 63.5 usec (the “block” w indow). The ADC analog input is called the video signal. Although samples are taken continuously, they are transferred to the DSP only when ten have been accumulated in a (double) buffer in the ADC board. This results in the ADC burst that becomes available periodically as shown in the timing diagram of the figure. Since the DMA transfer may not be as fast as the ADC burst, but may begin before all ADC samples are ready, there is overlap of the DMA transfer with the ADC burst. The software—all of it including interrupt service routines—then has processing time which is the difference between the DMA window and the block window. The DMA ties up memory so that processing effectively cannot be accomplished during the DMA burst. Some DSPs segment memory so that there is hardware parallelism that reduces this encroachment of the DMA onto the software tasks. The input interrupt service routine (ISR) recognizes the DMA complete, switches the pointer between buffers, sets a flag to wake up the associated processing software, and terminates. The ISR should run to complete with a 390 SOFTWARE COMPONENT CHARACTERISTICS minimum of instructions, limited to pointer manipulation and error checking, so th at the hardware interrupt stacks will not exceed their capacity. A few interrupts may be stacked in hardware, but since many ISRs turn off the inter- rupts so that they will not be interrupted, there may be only a few hardware levels of interrupt available. In very busy systems, lost interrupts can cause system crashes that are not easy to diagnose. So generally, one tries to drive the probability of lost interrupts to as close to zero as possible by strictly lim- iting the ISRs. They may be coded for recursive calls and double buffering. Circular buffering requires semaphores and tolerates less timing error than double buffers. The ISR-complete condition signals the applications to process the ten- sample buffers, which in this example, filters the data and sends it to a host processor (e.g., a laptop computer) for real-time display. While users may be relatively forgiving of display update delays, the loss of buffers of data might be more evident in speech applications. This can happen due to slightly exceeding the allocated execution window so that a buffer-full interrupt cannot be serviced. The timing diagram shows the timing budgets. One may test the filter software by running it on a dedicated processor in a loop, which calls it, for example, 10 million times. One measures the elapsed time and divides by 10 million for an estimated execution time. If the time estimated from this kind of measurement is not greater than 50% of the available processing window, then there is little doubt that the DSP will process the samples on time and robustly. As the estimated execution time approaches 80 to 90% of the allocated window, there is greater and greater chance that unanticipated events will cause the process to fail to complete on time. Operating system servicing of keyboard interrupts is one example. In order to obtain robust performance, the design m ust take into account the limited resources and unknown arrival times of external events. One cannot predict when one of 100 users will make a telephone call or use the radio. C. Aggregate Software Performance The SDR engineer estimates the computational complexity of software objects in order to ensure that the software personalities and hardware platform(s) are compatible. Software demand should be allocated to hardware in such a way as to keep the estimated demand for processing resources to less than 50% of processing capacity as a general rule of thumb. This concept is introduced in this chapter and addressed in detail in the sequel. Since SDRs are by definition capable of multiband, multimode behavior, multiple software personalities cor- respond to multiple waveforms and associated protocols of the air interface(s). Each personality is partitioned into software objects. A simple, illustrativ e set of objects comprising one software personality is illustrated in Figure 12-6. Each object has an associated processing demand. Simple rules-of-thumb provide top-down estimates of processing demand as shown in the figure. HARDWARE-SOFTWARE INTERF ACES 391 Figure 12-6 Aggregate software includes all processing regardless of hosting. Generally, IF processing, the digital filtering required to select a subscriber channel from a wideband IF ADC stream, needs resources that are directly proportional to the IF sample rate, f s . A proportionality constant of 100 multi- plies per sample represents the stages of filtering needed to filter a 12.5 MHz IF (30 M samples/sec) to typical cellular subscriber bandwidths of 25 (ana- log cellular) to 200 kHz (GSM-like). 1.2 MHz CDMA channels require less IF processing but more processing to despread the selected subscriber chan- nel. Once the subscriber channel has been isolated, 40 multiplies per sample times the baseband bandwidth times 2.5 for somewhat oversampled Nyquist criteria yields 100 # Wc multiplies needed by the baseband object for demod- ulation, link processing, and other modem functions. Information security (INFOSEC) processing requires typically fixed point or bit manipulation instructions (MIPS) which are proportional to the baseband data rate times an INFOSEC complexity factor. This factor reflects additional processing for recoding, stream ciphering, etc., which must be accomplished within the INFOSEC module. Black control (on the encrypted side of the radio) and red control (on the unencrypted side) each require additional processing that is directly proportional to the baseband data rate times a fraction of the INFOSEC complexity. Control is generally a passthrough function that con- sumes fewer resources than subscriber streams. Finally, internetworking con- sumes integer-processing resources which are directly proportional to the user data rate. The factors of 100 can be combined to yield the simple equation shown in Figure 12-6. This is a first-look, rough order of magnitude estimate of the processing demands of a single subscriber. The software objects should be supportable in the target distributed pro- cessing environment, a simple example of which is illustrated in Figure 12-7. In this case, the IF processing, baseband, and black control processes are all hosted in a front-end processor (FEP). The FEP includes ASICs (e.g., digital filter chip(s)), FPGAs (e.g., for timing and high-speed data control), and DSP chip(s) for baseband processing and control. The critical measure of performance on the FEP is the number of multi- plies supported per second. The INFOSEC processor provides MIPS, but as shown in Figure 12-7, its main contribution may be bus operations (e.g., for delivery of TRANSEC commands to the front end). In addition, INFOSEC 392 SOFTWARE COMPONENT CHARACTERISTICS Figure 12-7 Target distributed environments provide processing capacity. typically manipulates bits one at a time. The appropriate characterization of the INFOSEC processor may be bit operations per second. Bus and bit op- erations will not necessarily fall out of the initial rough order of magnitude estimates, so they will have to be refined using techniques discussed in the chapter on performance management. In addition, some processes such as in- ternetworking may have other measures of processing capacity and demand such as millions of packets processed per second. Timing and analysis of resource demands and capacity are needed up front. One does not have a good software design until processing demands have been estimated and resources allocated. One does not have a viable unit-level test program unless the estimates have been replaced with measurements. Finally , these estimates and measurements must be maintained throughout the integra- tion process to support optimization, and resource reallocation. In addition, the adjustment of operating system priorities and memory allocation—system tuning—is part of performance management. This is an integral element of software design for SDR. Without such start-to-finish discipline, one runs the risk of building a fragile system which cracks under the slightest load vari- ations and which is incredibly hard to debug as marginal timing conditions impact eac h other to cr eate intermittent bugs. P erformance management is developed in this text in stages. The balance of this chapter describes the soft- ware components. A subsequent chapter explains how to estimate resource requirements imposed by software and how to project capacity supplied by hardware so that one may accurately estimate costs, risks, development time, and performance specifications for SDRs. II. FRONT-END PROCESSING SOFTWARE Front-end processing software includes antenna control, diversity selection, and related functions. The SPEAKeasy II applications programmer interface (API) lists the messages in Table 12-1 within RF control. These functions are employed in the phases designated in the table. On power-up, the software requests built-in test (BIT). When the BIT state machines run to complete, the hardware platform has been successfully initialized. The response from the BIT request is the resulting hardware configuration. The front-end control FRONT-END PROCESSING SOFTWARE 393 TABL E 12-1 Front-End Processing Functions No. Name Phase 1ACK All 2Buffer Complete All 3Buffer Notify All 4Forward Message All 5 NACK All 6BITRequest Power up 7Define Remote Child Power up 8Define Remote Parent Power up 9 A llocate Resources Instantiation 10 Connection Test Instantiation 11 Define Remote Child Instantiation 12 End Download Instantiation 13 File Download Complete Instantiation 14 File Download Start Instantiation 15 Initiate Download Instantiation 16 New Agent Instantiation 17 Standard Data Msg Instantiation 18 Antenna Select Params & Mode 19 DeAllocate Resources Params & Mode 20 Define Child Params & Mode 21 RF Direction Params & Mode 22 RX Calibration Params & Mode 23 Software Vers ion Request Params & Mode 24 Hop Strobe Operation 25 Initiate TX Calibration Operation 26 Receive Mode Operation 27 RF Frequency Operation 28 Set Gain Operation 29 Standard Data Msg Operation 30 T/R Transmit Operation 31 Transmit Mode O peration 32 Destroy Agent Teardown 33 PA Power Teardown 34 Reset to Boot Teardown c !1999 IEEE, reprinted from [30] with permission. software then creates parents and children which are placeholders for instances of the software entities that control the antenna, transmitter, receiver, and other front-end functions. SDR hop set generation, for example, may be distributed to a microcontroller that controls a fast tuning synthesizer. The hop set param- eters would be created by the INFOSEC function, but the details of creating the hops from these parameters might be delegated to the front end (as is the case in Table 12-1). [...]... in spectrum use leading to a dynamic choice of operating frequency Some radios facilitate this choice with built-in spectrum displays, again putting the user in the decision loop Others, like TETRA, pick a clear channel for the user Cellular radio systems also manage physical (FDMA) and virtual channels (e.g., TDMA or CDMA) as radio resources Generally, they have an a-priori set of frequencies per... provide high-capacity interconnect Prior to the advent of gigabit fiber, these radios comprised the bulk of the trunking capacity of developed nations, including the United States Once the investment has been made in fiber optics, the return on investment is significantly better than microwave radio, however As a result, microwave radio is now found primarily in developing economies This technology employed... for dynamic use of the RF spectrum are listed in Table 12-2 The simplest way to dynamically manage the RF spectrum is by manual channel selection Many large groups of radio users including general aviation, citizens’ band (CB), and amateur radio operators employ this approach as the primary mechanism for spectrum management The user interface for spectrum management typically consists of the voice channel... mode assignment without the burden of man-in-the-loop choices For example, a dynamic channel handoff scheme implemented in the radio could automatically transmit, say, 30 ms bursts of coded data on candidate channels to determine the received SNR on both sides of the link The radios could autonomously move a pair of users from one channel to the next without user intervention Such schemes are almost... weakest subscribers Using such techniques, SDRs have the potential to deliver better end-to-end quality with longer reach and greater reliability than analog radios A first implementation of an SDR may not perform as well as the equivalent analog radio because inadequate attention is paid to the way in which RF/IF monitor algorithms define the effective system sensitivity Algorithm refinement may include... Amateur radio operators faced with a similarly anarchistic spectrum management schema, but operating from a fixed site, may use a PC to display the RF spectrum, facilitating choice of channel with a display of energy in the candidate channels Such an enhanced user interface allows two subscribers to pick a channel that appears clear from both receiving sites Military users with AM/FM single-channel radios... modulus (blind) equalization to reduce intersymbol interference (ISI) that is induced by multipath fading in typical microwave radio deployments This equalizer technology is computationally intensive, but its enhancement to BER makes it advantageous As a result, many other radio modes (e.g., GSM) employ constant modulus equalizers to enhance BER The synchronous multiplex hierarchy is illustrated in... the SDR, employing reserve processing resources in a way that shifts resources to subscriber services as they are needed Potential dynamic reassignment of processing resources is a key theme of software radio design strategy Massively parallel hardware platforms may allocate resources in a fixed scheme, wasting large fractions of available processing power It is possible to reduce hardware costs at the... both sustain 412 SOFTWARE COMPONENT CHARACTERISTICS Figure 12-16 Data stream synchronization throughput Thus, physical layer access drives the processing requirements of the DSP suite D Synchronization Radio links employ both asynchronous and synchronous modes of frame synchronization as illustrated in Figure 12-16 Asynchronous framing is employed in TDMA systems as illustrated in the figure Each subscriber... advanced techniques B Spectrum Monitoring SDRs with wide IF bandwidths must accommodate different noise levels across the band by using noise-riding squelch algorithms For example, aeronautical mobile radios operating in VHF and UHF will experience a noise background defined by thermal noise in remote areas such as the arctic and central regions of the Atlantic, Pacific, and Indian oceans But as the . Figure 12-1, these services demand that radio applications in- clude shared resources and interleaved “multithreaded” information flows. In addition, the radio applications must keep track of the. that general-purpose processors cannot be used for software radio research. For example, MIT has used the DEC Alpha chip for their virtual radio [178]. DSP teams apply skill in the use of DSP chips. spectrum is by manual channel selection. Many large groups of radio users including general aviation, citi- zens’ band (CB), and amateur radio operators employ this approach as the primary mechanism