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

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.. These f

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

Edited by Walter Tuttlebee Copyright q 2002 John Wiley & Sons, Ltd ISBNs: 0-470-84318-7 (Hardback); 0-470-84600-3 (Electronic)

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

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

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

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

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

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

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’s Law 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 fit in 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’s Law 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-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 speciaspecia-lized 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

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