Software Defined Radio Challenges and Opportunities’ Notes

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.