- The Need for Software Radios
- What Is a Software Radio?
- Characteristics and Benefits of a Software Radio
- Design Principles of a Software Radio
This chapter is from the book
This chapter is from the book
This chapter is from the book
Design Principles of a Software Radio
Radio design has always required a broad set of design skills. Although one might initially assume that software radios would require simply a higher level of digital signal processing programming skill than conventional radio design, this is not the case; a higher skill level is needed for almost all aspects of the radio design because of the dependency of the radio subsystems.
Software radios derive their benefits from their flexibility, complete and easy reconfig-urability, and scalability. It is important to ensure that these characteristics are present in the final product. A generic design procedure for software radios follows and demonstrates the interaction between the various subsystems of the radio design. Subsequent chapters in this book focus on the details of these design procedures.
Step 1: Systems engineering—Understanding the constraints and requirements of the communication link and the network protocol allows the allocation of sufficient resources to establish the service given the system's constraints and requirements. For instance, constraints on the range and transmit power constrain the modulation types and data rate that can be supported. For a well-defined standard, the systems engineering aspects, such as the routing protocol, are to a great extent predetermined. However, as additional flexibility is allowed in defining the network, systems engineering and optimization becomes a more complex task. In an ideal software radio with the ability to change a number of system parameters in real-time, optimizing an active communications session is a major challenge.
Step 2: RF chain planning—The ideal RF chain for the software radio should incorporate simultaneous flexibility in selection of power gain, bandwidth, center frequency, sensitivity, and dynamic range. Achieving strict flexibility is impractical and trade-offs must be made. If the communication system is constrained to selected commercial or military bands, this optimization problem is simplified. Nevertheless, with a software radio design, it is possible to compensate for some of the inadequacies of the RF components in the digital domain. Compensations for power amplifier distortion or power management of the RF circuitry, for example, can be accomplished in the digital domain.
Step 3: Analog to digital conversion and digital to analog conversion selection—Analog to digital conversion and digital to analog conversion for the ideal software radio is difficult to achieve, and in practice, the selection requires trading power consumption, dynamic range, and bandwidth (sample rate). Analog to digital conversion and digital to analog conversion selection is closely tied to the RF requirements for dynamic range and frequency translation. Channelization requirements also impact the selection of the analog to digital conversion and digital to analog conversion. Current conversion technology is very limited and is often the weak link in the overall system design. There are post-digitization techniques based on multirate digital signal processing that can be used to improve the flexibility of the digitization stage.
Step 4: Software architecture selection—The software architecture is an important consideration to ensure maintainability, expandability, compatibility, and scalability for the software radio. Ideally, the architecture should allow for hardware independence through the appropriate use of middleware, which serves as an interface between applications-oriented software and the hardware layer. The software needs to be aware of the capabilities of the hardware (both DSP and RF hardware) at both ends of the communications link to ensure compatibility and to make maximum use of the hardware resources. Furthermore, given that the software radio will operate in an existing data infrastructure, it must interface quickly and efficiently with this infrastructure. This means that the software radio needs to control issues such as attribute naming, error management, and addressing, regardless of the protocol used in the infrastructure. Partitioning the radio functions into objects can help with these issues as well as aid in portability and maintenance of the software. Example objects might include the blocks of the model software radio shown in Figure 1.1. Security is an important issue to ensure that software downloads are legitimate. Finally, given that higher-layer protocols such as TCP have constraints inherent to the way in which they manage a session, the software architecture should consider latency and timing for the whole protocol stack.
Step 5: Digital signal processing hardware architecture selection—The core digital signal processing hardware can be implemented through microprocessors, FP-GAs, and/or ASICs. Typically microprocessors offer maximum flexibility, highest power consumption, and lowest computational rate, while ASICs provide minimal flexibility, lowest power consumption, and highest computational rate. FPGAs, on the other hand, lie somewhere between an ASIC and a DSP in these characteristics. The selection of the core computing elements depends on the algorithms and their computational and throughput requirements. In practice, a software radio will use all three core computing elements, yet the dividing line between the implementation choices for a specific function depends on the particular application being supported.
Step 6: Radio validation—This step is perhaps the most difficult. It is essential to ensure not only that the communicating units operate correctly, but also that a glitch does not cause system-level failures. Interference caused by a software radio mobile unit to adjacent bands is an example of how a software radio could cause a system-level failure, and this is of great concern to government regulators. Given the many variable parameters for the software radio and the desire for an open and varied source of software modules, it is very difficult to ensure a fail-proof system. Testing and validation steps can be taken to help minimize risk. Structuring the software to link various modules with their limitations and deficiencies can help in testing compatibility of software modules.
As you can see from the cartoon in Figure 1.2, Dilbert is skeptical of the ideal software radio. This skepticism is understandable; software radios require a much higher level of systems-level engineering than today's products. To carry out this cooperative interdisciplinary design, engineers must understand the ramifications of their design on the overall system and be willing to have their subsystem control and be controlled by other subsystems, and they must be knowledgeable in a variety of technical disciplines.
)
Figure 1.2: Dilbert's View of Software Radios.1