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

Part IV Software Technology Software – at air interface, applications, protocol and network levels – is at the heart of the promise of software radio. At all levels the potential is vast and the implications are profound – the need for effective design tools to give functional reliability will be key to successful commercialization. Software Defined Radio Edited by Walter Tuttlebee Copyright q 2002 John Wiley & Sons, Ltd ISBNs: 0-470-84318-7 (Hardback); 0-470-84600-3 (Electronic) 10 Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc John Chapin Vanu, Inc A good software design is one of the most important aspects of a software radio. This chapter describes the software and hardware design approaches used in two software radio projects that focused on maximizing software portability, modularity, and adaptability. The designs described in this chapter were developed in two projects that built a series of software radios over a 6-year period. The SpectrumWare software radio project at the Massachusetts Institute of Technology in the United States ran from 1995 to 1998. In 1998 most of the SpectrumWare team left MIT to start Vanu, Inc. Between 1998 and 2001 Vanu built software radio implementations of a variety of commercial and government waveforms, including the cellular telephone standards IS-91 AMPS, IS-136 TDMA, and GSM. Although the systems developed by SpectrumWare and those developed at Vanu, Inc. differ in many details, the two development efforts followed the same design approach. In this chapter both systems are called Vanu systems. Vanu systems have several characteristics that distinguish them from other software radios. Most signal processing functions execute on general purpose processors rather than on digital signal processors or field programmable gate arrays. Almost all signal processing code is implemented in a high level language, C11, running on top of a standard portable operating system interface (POSIX) operating system. The waveforms and signal processing infrastruc- ture have ported almost unchanged across Intel Pentium, Intel StrongARM, Compaq Alpha, and Motorola PowerPC processors. These characteristics make Vanu systems pure software radios, as opposed to the software-defined radios of other projects. The importance of this distinction will become clear in the explanation of the engineering advantages inherent in the approach. Software Defined Radio Edited by Walter Tuttlebee Copyright q 2002 John Wiley & Sons, Ltd ISBNs: 0-470-84318-7 (Hardback); 0-470-84600-3 (Electronic) 10.1 Overview of Vanu Systems In its current form, the Vanu system architecture consists of the layers and components shown in Figure 10.1. The lowest layer is the antenna. The antenna counts as a layer because modern radio systems contain active antenna elements that must be controlled: for example, beam forming arrays or MEMS-based tunable antennas. The next layer, labeled RF-to-Digital, is the only layer of the system that contains radio specific analog components. On the receive side, its sole function is to generate a digitized representation of a slice of the radio spectrum. On the transmit side, it generates a radio signal from a digitized representation. It performs no signal processing. In lower cost systems, the RF to digital layer performs channel selection on receive and band synthesis on transmission, while in high performance systems it exchanges a digitized representation of a whole RF band with the motherboard, enabling multichannel operation. The name of the next layer, Motherboard, is borrowed from the PC world because software radios built to the Vanu architecture look much more like computers than like legacy radios. Like a PC motherboard, this layer contains memory and processor components, and provides I/O to a network, to the user, and timing support and similar functions The Operating System layer sits on top of the motherboard. Use of an operating system is critical to the design approach because it isolates the signal processing application from the hardware and thereby significantly improves its portability. Vanu systems place no unusual demands on the operating system. Any COTS operating system that supports high data rate transfers between applications and the underlying hardware can be used. The current imple- mentation runs on Linux but could be ported easily to any POSIX compliant OS. The software radio system runs as an application process on top of the operating system. It is split into control and signal processing components, which have different engineering require- ments. The control component emphasizes portability and the ability to integrate with COTS Software Defined Radio: Enabling Technologies292 Figure 10.1 Layered software radio architecture implementations of network protocol stacks and other higher layer functionality. The signal processing component emphasizes processing efficiency, modularity and code reuse. The signal processing component consists of a middleware layer which performs data movement and module integration, and a library of signal processing modules for functions such as FM encoding, the Viterbi algorithm, or FIR filtering. The control component consists of a runtime system that interprets state machines and processing descriptions, and a down- loadable application which determines which waveform or communications standard the system will implement. The SpectrumWare project at MIT had a simpler architecture than the one shown here. The most significant difference is the lack of a defined control component. The research proto- types built at MIT did not integrate software signal processing into larger systems and hence needed only simple control functionality. The SpectrumWare system design has been described in a variety of publications [1–6]. 10.1.1 Representative Implementations To make the above abstract architecture more concrete, consider a few current implementa- tions of the architecture. 10.1.1.1 Powered User Equipment For user environments where power is available, a commercial off the shelf (COTS) mother- board can be used. The current Vanu demo system is a standard PC with a 1 GHz Pentium III, dual channel PC133 memory, A/D and D/A cards, and an external RF front end for frequency conversion. This system has been used to demonstrate reception of legacy AM and FM broadcasts, family band walkie-talkie, APCO 25 (a North American digital law enforcement standard), 1G and 2G cellular standards, and NTSC television. 10.1.1.2 Handheld User Equipment In 2001 Vanu completed a research prototype of a battery-powered handheld system [7] (see Figure 10.2). The custom board has a 200 MHz StrongARM 1110, dual port RAM, and a field programmable gate array (FPGA) that interfaces to a host PDA and to a separate RF to digital board which provides channel selection. The system supports the IS-136 2G cellular standard in addition to less complex legacy standards. 10.1.1.3 Infrastructure Equipment Vanu’s proof of concept implementation of a cellular telephone base station consists of a number of COTS 1U rackmount servers, each with two 1 GHz Pentium III processors, connected by gigabit ethernet [8,9] (Figure 10.3). The RF to digital function is provided by separate single processor PCs, with A/D, D/A, and RF front ends, which exchange wide- band digitized streams with the signal processors over the ethernet. The control component runs on a single processor and communicates to the signal processing components using CORBA. The system uses standard cluster techniques to detect and recover from the failure of any signal processing server. Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 293 10.1.2 Difference from Other Software Radios The same software runs on all the radically different hardware implementations of the Vanu system architecture. Furthermore, in platforms other than the handheld, all hardware except the transmit front end is acquired as COTS boards or boxes that are plugged together without any hardware design work. These features make Vanu systems fundamentally different from legacy radio architectures, where the software is intimately tied to the hardware and building a new radio always starts as a hardware design problem. Software Defined Radio: Enabling Technologies294 Figure 10.2 Handheld prototype (the production version, August 2002, fits into a standard IPAQ sleeve). Figure 10.3 GSM base station prototype. Most software defined radio approaches stay within the legacy approach and use software merely as a means to improve system flexibility. Vanu systems make a sharp break from the legacy approach and gain significant engineering advantages as a result. The combination of portable software and COTS commodity hardware significantly increases the speed of devel- opment and the diversity of communications functions that can be supported for the same manufacturer engineering investment. The Vanu approach will gain increasing advantages as this investment shifts over time to focus ever more greatly on software. 10.2 The Importance of Software in Software Radio Communication systems have traditionally been constrained by antenna, amplifier, and analog circuit design. However, software design is likely to become a core problem in future software radios, one which is just as important as the traditional hardware design problem. To see why, observe the trajectory of other industries. In fields such as aircraft and medical devices, an initial hardware only system grew into a system where software implemented critical performance and safety features. Eventually, software became the factor limiting system design and performance. For example, Lockheed Martin reported in 1995 that by the early 1990s software had become the single largest engineering cost over the product lifecycle of an aircraft. Software costs exploded due to the difficulty of maintaining high reliability while adding sophisticated software functionality and due to the cost of software maintenance and upgrades over the life of the product. Radios resemble aircraft and medical devices in ways which suggest that they will follow a similar software cost curve. Users require a high level of reliability from communication devices. Each of the features that make software radios attractive adds complexity to the software. Manufacturers will need to provide upgrades for fielded devices, since the offer of future upgrades will provide a key competitive advantage in the initial device sales effort. These factors work together to make the software for software radios very costly. Software costs can become high even without the advanced features promised from future software radios. For example, the Harris Falcon II family of military radios currently supports 25 communications standards in a small package through use of SDR techniques. In early 2001, the software base for the Falcon II family contained an amazing three million lines of code [10]. This exceeds the size, and probably the development cost, of all except the most sophisticated business software applications. For these reasons, software complexity and cost will become key considerations in the system design. It will turn out to be appropriate in some cases to add cost or complexity to the hardware if this can provide significant benefits to the software. The most important software cost reduction opportunity, one that affects the hardware design in fundamental ways, is to make the software portable across platforms. 10.3 Software Portability Software portability is the primary requirement that has driven both the hardware and soft- ware architecture design of Vanu systems. Although portability by itself is not sufficient to prevent software costs from overwhelming manufacturers, it is a necessary component of the solution. Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 295 The benefits of portability for reducing development costs are so well known that little explanation is necessary. Portability enables the developer to amortize the cost of software over several generations of a product, and over several different products such as mobile devices and fixed stations which interoperate using common waveforms. As software costs increase as a proportion of system cost, the cost savings due to portability will continue to grow. This section explains other benefits of portability and the aspects of Vanu system design that provide it. 10.3.1 The Effects of Moore’s Law Portable software will frequently perform better than software optimized for a particular platform. This counterintuitive result is a consequence of Moore’s Law. Moore’s Law is the observation that the number of transistors which can be integrated into a single chip doubles every 18 months. The semiconductor industry has closely followed this trajectory since the 1960s. Exponential growth in transistor count has led to corresponding exponential growth in processor performance, which strongly affects the trade-offs in software develop- ment Consider the experience of the SpeakEasy software radio project. 1 In 1991 the United States Department of Defense launched SpeakEasy with the goal of supporting ten military waveforms on a single device. The developers chose the fastest available digital signal processor in 1991, the Texas Instruments TMS320C40. The computational requirements of the target waveforms far exceeded the capability of the C40, so the developers planned a system with multiple processors and highly optimized the software to reduce the number required. By the time the SpeakEasy Phase I effort finished in 1994, Texas Instruments had introduced the TMS320C54xx, a processor family four times faster than the C40. However, SpeakEasy could not take advantage of the new processors. The software was tied to the C40 processor and would have had to be completely rewritten. Therefore the SpeakEasy system as demonstrated in August of 1994 missed out on a potential 4£ reduction in size, power, weight, and parts cost of the signal processing engine. In contrast, consider the Vanu implementation of the American mobile phone system (AMPS) analog cellular telephone standard. When the SpectrumWare project started in 1995, the first software radio could not process even a single AMPS channel in real time. The 1995 software ran on a PentiumPro 133-MHz processor. By 2001 the Vanu derivative of that code supported seven AMPS channels in real time on a Pentium III 1-GHz processor. Most of the R&D dollars required to achieve this performance improvement were invested by Intel, not by Vanu. This consequence of Moore’s Law means that portable software will frequently out- perform nonportable software for complex systems where software is a significant portion of the engineering effort. Over the lifecycle of a product family, which can easily stretch to 10 years or more, Moore’s Law provides such a huge advantage that code portability is a fundamental requirement for good performance of such systems. Software Defined Radio: Enabling Technologies296 1 For a history and description of SpeakEasy see Bonser, W. ‘US defence initiatives in software radio’,in Tuttlebee, W. (Ed.), Software Defined Radio: Origins, Drivers and International Perspectives, John Wiley & Sons, Chichester, 2002, Chapter 2. Portability is not a requirement for every line of code in the system. It is usually advanta- geous to apply nonportable optimizations to the most performance critical sections of the code. In a typical complex system roughly 5% of the code base may be specialized for each platform without harm to the overall portability benefits. However, the benefits of tuning more of the software for a given hardware platform rapidly decrease. 10.3.2 Exploiting Moore’s Law Portability is not sufficient by itself for an application to take advantage of Moore’sLaw performance gains. Additionally, the processor must be the performance bottleneck. Other COTS components have historically improved at much lower rates than processors. If an application is memory- or I/O-limited, hardware performance improvement over time may not be sufficient to overcome the software performance costs associated with portability. Designing a software radio to be processor-limited is a significant engineering challenge. Signal processing has a higher ratio of data throughput to computation than most other applications. Processors and systems designed to cover a broad range of applications can easily become memory or I/O limited when running a software radio. Two attributes of the Vanu system design approach are particularly important in ensur- ing that the systems are processor-limited. The first is to ruthlessly eliminate data copies wherever they occur in the system. Signal data, whether input, output, or intermediate result, is only written once and then reused as many times as needed from that location. While this may sound straightforward, it turns out to require surprising care to achieve in a modularized complex system, especially when an operating system is used to control the I/O devices. The second design attribute is to choose the amount of data operated on in each pass through the processing pipeline (the payload) so it is small enough to fitin the cache. This minimizes the number of data cache fills and spills to main memory beyond the required load of input data and writeback of final output. Since data cache sizes vary significantly across processors, even among closely related processors from the same manufacturer, the processing payload size cannot be chosen as part of the software design. Vanu systems dynamically determine the payload size at runtime. This is a change from traditional implementation techniques which specialize the code to the payload size. Following these design approaches enables software to take advantage of Moore’sLaw performance improvements, and therefore creates a strong performance benefit from port- ability. 10.3.3 Generic Data Path Software portability requires the use of hardware that has a generic data path rather than a data path specialized for a particular application. Generic data paths have already become common in the most complex signal processing applications such as airborne radar [11]. The importance of portability for software radios will lead to adoption of generic data paths in less complex systems such as vehicular and portable radios. A specialized data path is a hardware data path tuned for the problem being solved. A digital radio receiver, for example, may provide digital down converters (FPGA or DSP), baseband processors (DSP), and network protocol processors (GPP), connected in a specia- Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 297 lized topology with interdevice links whose capacities reflect the expected communication patterns among the devices. A generic data path is a hardware data path whose design is not specialized to any particular problem. Commonly, the data path is either a single processor node, with its associated memory, or a pipeline or array of identical processor nodes. The choice of generic over specialized data paths is driven by the need to write a single abstract source program and then use a compiler to generate the code for a variety of plat- forms. Compiler technology is not yet good enough to generate efficient code for a specia- lized data path from an abstract source program. A software engineer faced with a specialized data path must therefore create a corresponding specialized source program. When this is done, assumptions about the number of components, trade-offs among component speeds, and the specialized capabilities of each component permeate the source code in a way that is difficult or impossible to change. Porting the source code to a new platform or to the next generation of a given platform usually requires a significant rewrite. Just as with the choice of portable versus optimized code, the requirement to avoid specia- lizing the software to the data path is not absolute. For example, one of the analog-to-digital converters currently used by Vanu provides digital down-converter functionality. Taking advantage of the DDC requires modifying each waveform implementation when porting it to that platform. As long as such modifications affect only a small region of the program, this does not significantly reduce overall code portability. A design approach that requires generic data paths may be seen as unrealistic. After all, specialized data paths are common today because they usually reduce the final system parts cost. This benefit will not disappear in the future. However, as software costs become an ever higher proportion of lifecycle cost, the parts cost savings of a specialized data path will become less and less significant for any except the highest volume applications. This will lead to the emergence of a large class of systems for which a generic data path is the appropriate and cost-effective solution. 10.3.4 Temporal Decoupling Radio systems face stringent real time requirements. For example, the IS-95 standard for CDMA cellular telephones requires the mobile unit to begin transmitting data within a 3-ms window centered at the scheduled start time. Current digital radio systems satisfy real time requirements through tight control over software execution timing. This approach does not significantly reduce portability by itself. However, it limits the software to platforms that provide highly predictable execution rates. Also, it limits the algorithms used to those that perform roughly the same amount of compu- tation for each data sample processed. Current designs assume that execution jitter is confined to small effects such as cache misses or bus contention and therefore only a few samples of buffering at input and output are required to tolerate it. Vanu systems relax the requirement of execution predictability by significantly increasing the buffering at system input and output. Relaxing the execution rate requirement enables the software engineer to exploit a much wider range of platforms and algorithms. For example, Vanu, Inc. has found significant cost and portability benefits from using Linux rather than a dedicated real time operating system (RTOS) in many applications. Also, the total computa- tional load can be reduced by sophisticated algorithms that run quickly in the common case Software Defined Radio: Enabling Technologies298 but occasionally fall back to expensive processing in the uncommon case. An example is a convolutional decoding algorithm, much faster than the widely used Viterbi algorithm but with the same error correction performance. The Vanu approach sufficiently decouples the processor’s execution from the wallclock such that the rate of execution at any given point in time is unpredictable. Real time require- ments will be satisfied as long as the processor is fast enough for the signal processing code to average a processing rate faster than the I/O rate. This design approach interacts with the hardware design and with application end to end latency requirements. 10.3.4.1 Hardware Design Temporal decoupling requires the hardware to provide sufficient buffering on input to tolerate the periods when the processing code runs slower than real time, and sufficient buffering on output to tolerate the periods when the code is catching up by running faster than real time. Alternately, the operating system can provide the buffering if it empties and fills the hardware queues at a smooth rate. The amount of buffering required increases both with the variance in processing rate and with the closeness of the average processing rate to its lower bound at the I/O rate. The input and output devices must also provide mechanisms to enable the application to meet strict timing requirements on actions such as transmissions and frequency hops. This issue was not addressed in SpectrumWare. The Vanu solution is a cycle counter in the input and output devices. The input device uses its cycle counter to timestamp samples upon A/D conversion. The output device stalls transfer of samples to the D/A converter if a sample reaches the head of the output buffer labeled with a cycle count that has not yet been reached. Future frequency hopping versions of both devices will have a queue of pending hop requests where each request is labeled with the cycle counter value at which it should take effect. These mechanisms enable signal processing code which is decoupled from wallclock time to cause events such as transmissions and hops to occur at precise delays relative to prior input events. 10.3.4.2 End-to-End Latency Requirements Buffering on input and output does not come for free. Each sample buffered between the input and output causes an additional sample period’s worth of delay. This limits the ability of applications with strict end to end latency requirements to run on some platforms. The latency requirement limits the amount of buffering allowed, which in turn limits the allowed variance in the signal processing rate. Each platform has some minimum variance it can achieve, depending on its hardware and system software design. If the minimum variance is too high and the latency requirement too low, the application cannot run on the platform. Unlike in traditional digital radio designs, however, the Vanu design approach ensures as wide a range of platform compatibility as possible for each application. Temporal decoupling smoothes out the discontinuity between predictable real time systems and unpredictable nonreal time systems. By adjusting I/O buffer sizes, a portable application can run in real time on a variety of different platforms and achieve the minimum end to end latency permitted by each. Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 299 [...]... adaptability, and modularity that can be achieved in the software for software radios 2 See Grable, M., ‘Regulation of software defined radio – United States’, in Tuttlebee, W (Ed.), Software Defined Radio: Origins, Drivers and International Perspectives, John Wiley & Sons, Chichester, 2002, Chapter 11 Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc 309 Acknowledgements Work on Vanu... impact of software radio on wireless networking’, Mobile Computing and Communications Review, Vol 3, No 1, January, 1999 [3] Bose, V., Ismert, M., Welborn, M and Guttag, J., ‘Virtual radios’, IEEE/JSAC, Special Issue on Software Radios, April, 1999 [4] Chiu, A., ‘Adaptive channels for wireless networks’, MIT M.Eng thesis, May, 1999 [5] Bose, V., ‘Design and implementation of software radios using general... economic benefits inherent in software radio technology As manufacturers move to 3G cellular systems, build multimode vehicular telematics devices, or develop infrastructure systems that dynamically change functionality to maximize revenue, the engineering costs of radio systems will shift ever more strongly into software This will continue to strengthen the case for focusing radio system design on reducing... Ph.D thesis, June, 1999 [6] Vasconcellos, B., ‘Parallel signal processing for everyone’, MIT M.Eng thesis, February, 2000 [7] Chapin, J ‘Handheld all-software radios: prototyping e evaluation for JTRS Step 2B’, http://www.jtrs.saalt army.mil/docs/documents/step2b/Vanu.pdf [8] Chapin, J., Chiu, A and Hu, R., ‘PC clusters for signal processing: an early prototype’, IEEE Sensor Array and Multichannel Signal... partially motivated by the need for excellent cache performance 10.5 Signal Processing Software Use of a generic data path and temporal decoupling free a software radio from the traditional constraints on signal processing software design A radio designed this way can take advantage of any engineering techniques that improve modularity, reusability, adaptability, or other code attributes This section... Engineering for Software Radios: Experiences at MIT and Vanu, Inc 301 A data pull implementation works well with temporal decoupling, for several reasons † No processing is done until it is needed Decisions to modify the behavior of the processing chain take effect immediately, rather than being delayed until partially processed data has drained through to the output Therefore the radio can adapt much... Joint Tactical Radio Systems Office The technical work is a collaborative effort with too many contributors to list here, although special recognition for the fundamental system concepts goes to Vanu Bose and Michael Ismert In the preparation of this manuscript, the author is grateful for the support and eternal good humor of Walter Tuttlebee References [1] Bose, V and Shah, A., ‘Software radios for wireless... is written in a Vanu-developed language called the radio description language (RDL) [14] † generation of the most common RDL constructs from graphical representations of assemblies † generation of state machine code from graphical statecharts The code generation system provides an important form of portability to the control component of Vanu software radios The mechanism used to connect the control... description of the graph A key design decision in RDL is that an assembly is treated just like a module by all code Software Engineering for Software Radios: Experiences at MIT and Vanu, Inc Figure 10.4 Figure 10.5 RDL module RDL assembly 305 Software Defined Radio: Enabling Technologies 306 Figure 10.6 Data flows of RDL assembly in Figure 10.5 outside that assembly Assemblies have parameters, control and... ‘Programmable, scalable wireless information infrastructure’, NSF Contract DMI-9960454 final report, http:// www.vanu.com/publications, July 11, 2000 [10] Turner, M., ‘Software programmable radio: the Harris solution’, SMi Software Radio Conference, London, April, 2001 [11] Mercury Computers technology white papers, http://www.mc.com [12] Ismert, M., ‘Making commodity PCs fit for signal processing’, USENIX ‘98, . the software for software radios. Software Defined Radio: Enabling Technologies308 2 See Grable, M., ‘Regulation of software defined radio – United States’,. Chapin, J. ‘Handheld all-software radios: prototyping e evaluation for JTRS Step 2B’, http://www.jtrs.saalt. army.mil/docs/documents/step2b/Vanu.pdf [8] Chapin,