Software Defined Radio…

Software Defined Radio Challenges and Opportunities’Notes

2013/3/10  Nick Chan

Paper come from IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010. Software Defined Radio: Challenges and Opportunities

Abstract—Software Defined Radio (SDR) may provide flexible, upgradeable and longer lifetime radio equipment for the military and for civilian wireless communications infrastructure. SDR may also provide more flexible and possibly cheaper multistandard-terminals for end users. It is also important as a convenient base technology for the future context-sensitive, adaptive and learning radio units referred to as cognitive radios. SDR also poses many challenges, however, some of them causing SDR to evolve slower than otherwise anticipated. Transceiver development challenges include size, weight and power issues such as the required computing capacity, but also SW architectural challenges such as waveform application portability. SDR has demanding implications for regulators, security organizations and business developers.

 

The tutorial will start with SDR SW architecture. As a background to this discussion, Software Communications Architecture (SCA) is briefly reviewed. Then there is a review of the challenges and existing/ongoing work within application portability, application development, the underlying middleware platform and alternative architectures.

A fundamental challenge of SDR is to provide the necessary computational capacity to process the waveform applications, in particular the complex and high data rate waveforms and especially for units with strict power- and size limitations. The computational requirements and the available computing elements required to handle them will be reviewed.

Further the implications for security, regulations and for the radio manufacturer business structure will be discussed and the remaining challenges and/or future projections will be commented on. However, the security of SDR isn’t my interesting and requirement. I jump security part.

The most widely used software architecture for SDR is the Software Communications Architecture (SCA). SCA is published by the Joint Program Executive Office (JPEO) for JTRS, with SDR Forum having assisted the JPEO with the development of SCA. The SCA defines a protocol and an environment for the application components. SCA does this by defining a set of interfaces and services, referred to as the Core Framework (CF) , by specifying the information requirements and formats for the Extensible Markup Language (XML) descriptions for components and applications, termed the "Domain Profile", and by specifying underlying middleware and standards. By providing a standard for instantiation, management, connection of and communication between components, the SCA contributes to providing portability and reusability of components. SCA is a general architecture, targeted for but not limited to SDR systems. SCA has similarities with other distributed component architectures, e.g. the CORBA Component Model (CCM). A conceptual difference relative to CCM is the support for system components or ’devices’.

SW ARCHITECTURAL CHALLENGES

A.      Portability of SDR SCA-Based Applications

A fundamental challenge of SDR is to provide an ideal platform to application separation, such that waveform applications can be moved from one SDR platform to be rebuilt on another one without having to change or rewrite the application.

1.      The SCA compliance of an application is not sufficient to cover all aspects of portability. Significant pieces that are not standardized by the SCA itself are the APIs to the services and devices of the system platform.

2.      In order for portability to extend across domains, the APIs to the services and devices will need to be standardized across domains as well.

3.      Another related portability issue is the various alternatives for transport mechanisms for the communication with components deployed on DSPs and FPGAs.

4.      Lastly, portability obviously requires that the component code is interpreted correctly on the platform.

B.      Challenges related to SCA Application Development

A further enhancement of the efficiency of designing SCA-based applications, as well as a general avail-ability of MDD tools with fully automated conversion to code level for any given HW platform are important remaining challenges.

C.      CORBA Related Challenges

CORBA is demanded by SCA as a middleware platform. The use of CORBA, however, has known challenges in the form of implications on communication throughput, latency and latency variation, as well as an overhead of consumed computation and memory resources. Another issue is that CORBA has lost its popularity in some application domains, which naturally raises the question of whether an alternative middleware is also needed for SDR.

D.     SCA Challenges and Alternative Architectures

A further political argument against SCA is that it is also not an open standard as it is directly managed under the supervision of the JPEO. With these issues as a background, it is interesting to explore the alternatives.

This part introduces a SDR platform which I am interesting. I use Gnu Radio to develop a system and I am familiar with it. The GNU radio architecture is an open-source initiative, where the signal processing is carried out on GPP computers.GNU radio is adapted to the Universal Serial Radio Peripheral (USRP) which converts between base band and RF signals. Radio applications are formed as graphs where the vertices represent signal processing blocks and the edges are the data flow, and where the blocks have input and output ports. The signal processing blocks are written in C++ and the graph is connected using the Python programming language.

Concluding on the outlook for SDR architectures, it is expected that the SCA will remain a dominating architecture in the military segment, due to its momentum and the high importance of portability in this domain. In the commercial civilian segment, where there is less focus on portability and more on hardware cost and low power consumption, it is expected that a significant portion of designs will use dedicated and proprietary lighter-weight architectures. In a longer time perspective, with decreasing hardware cost and increasing performance, it is expected that open and standardized architectures such as the OMG one will gain wider acceptance in this sector.

CHALLENGES ANDOPPORTUNITIESRELATED TO COMPUTATIONAL REQUIREMENTS OFSDR

 

A. Computational Requirements

A fundamental challenge with SDR is how to achieve sufficient computational capacity, in particular for processing wide-band high bit rate waveforms, within acceptable size and weight factors, within acceptable unit costs, and with acceptable power consumption.

1.      This is particularly challenging for small handheld units, e.g. multi mode terminals. The power consumption must be considered.

2.      For base stations like cellular network infrastructure stations, and for vehicular mounted stations cost may still be challenging for complex high bit rate waveforms.

Conceptually, as an abstraction, we can consider SDR applications to consist of two main groups of components：

(1)Data Processing Components (DPCs)

(2) Event Driven, Administrative and Control Components (EDACCs).

With complex waveforms, the DPCs will be the components that require the most computing capacity, and the ones that drive the processing requirements of the SDR computing platform. Table II lists some computational complexity numbers for some key algorithms of the 802.11a waveform at 24 Mbps. The calculated complexity numbers are in the form of gigacycles per second referenced to an Alpha GPP. The complexity is seen to be overwhelming for such a single GPP, as the required cycle rate is far above achievable rates.

B. Processing Options

There is a large variety of available processing elements, each with their associated strong and weak points.

1) Static Processing Elements and Tailored Functional Arrays: In a non-SDR device, the computationally demanding and often highly parallel parts of an algorithm would typically be implemented as logical circuitry in an Application-Specific Integrated Circuit (ASIC).

2) Reconfigurable Processing Elements: The Field Programmable Gate Array (FPGA) is the reconfigurable alternative to the ASIC. At the expense of higher power consumption and circuit area than the corresponding ASIC solution, an FPGA can be field-programmed with the specific code needed for the specific waveform application.

3) Fast Reconfigurable Units:Configurable Computing Machines (CCM) offer shorter reconfiguration times than FPGAs, and for some types close-to real-time reconfiguration.

4) Real-Time Reconfigurable Units: Microprocessor systems are processing alternatives that provide full real-time programmability. Year after year, processors have shown remark-able performance increases. Whereas cycle clock increases have become more difficult due to technological barriers and also less desirably because of power consumption and power density concerns, the average number of instructions processed per clock cycle has increased by various means.

 Most multi-core processors may be classified as Single Instruction Multiple Data (SIMD), Multiple Instruction Multiple Data (MIMD), or as a combination of the two.

 SIMD units have a single instruction stream, i.e. they execute a single program and each processor is constrained to executing the same instruction. They operate on multiple data streams at a time, i.e. each processor may operate on a different set of data. They are very well suited for algorithms where there is high data parallelism, i.e. a number of identical operations that can or need to be performed at the same point in time, on multiple data sets.

MIMD units have multiple instruction streams, and operate on multiple data streams at a time. This is hence a more general and flexible architecture than SIMD, allowing separate programs to be executed on each core. This allows problems that exhibit some parallelism, but where the parallelism does not have a regular structure in the form mentioned for SIMD above, to be speeded up through parallel execution.

Graphical Processing Units (GPUs) may also be used for accelerating or running signal processing algorithms.

5) Processing Elements, Concluding Comments: With the wide variety of types of processing elements available, how do they compare and which ones should be preferred? The answer depends on the individual weighting of a number of factors, and hence no easy answer is available.

C. Requirements versus Capacity, the Way Ahead

the throughput download data rate in mobile cellular terminals increases at a higher exponential rate than the exponential rate of the DSP processing capacity in MIPS.

While the progress of processing element capacity continuously makes it easier to meet the capacity requirements of today’s existing waveforms, the rapid system evolution particularly in the civilian mobile communications sector indicates that providing adequate processing power at target power consumption will remain a challenge in the years to come, and there will be an increasing need for data processing elements that further exploit parallelism.