IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 12, NO.

4, FOURTH QUARTER 2010 531

Software De?ned Radio: Challenges and Opportunities
Tore Ulversoy, Member, IEEE
Abstract? Software De?ned Radio (SDR) may provide ?exible,
upgradeable and longer lifetime radio equipment for the military
and for civilian wireless communications infrastructure. SDR
may also provide more ?exible 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.
Index Terms?Software de?ned radio, radio communication equipment, software engin
eering.
I . IN T RO D U C T IO N
THE TERM fSoftware Radio f was coined by Joseph
Mitola III to signal the shift from HW design dominated
radio systems to systems where the major part of the functionality is de?ned in
software. He described the concept in
[1].
Software De?ned Radio (SDR) has no single, uni?ed,
globally recognized de?nition. Slightly different interpretations exist among th
e actors in the ?eld. Adding to this,
a variety of related terms has been proposed and is used
to variable degrees. These include Software Based Radio
[2], Recon?gurable Radio, Flexible Architecture Radio [3].
The main parameter in the various interpretations and the
related terms, is how ?exibly the radio waveform can be
changed through changing software (SW) and without modifying the SDR Platform (t
he combination of hardware and
operating environment where the waveform application is
running). Obviously the ideal however unrealizable goal is to
be able to communicate at any desirable frequency, bandwidth,
modulation and data rate by simply loading the appropriate
SW. Usually SDR is given a more practical interpretation,
implying simply that large parts of the waveform are de?ned
in SW, giving the ?exibility to change the waveform within
certain bounds as given by the actual system. The ?exibility
is commonly assumed to extend at least to multi-band and
multi-modulation. Examples of speci?c de?nitions are those
provided by the Software De?ned Radio Forum (SDR Forum)
Manuscript received 8 April 2008; revised 27 November 2008 and 12 March
2009. The work is ?nancially supported by FFI (the Norwegian Defence
Research Establishment).
T. Ulversoy is a Ph. D. candidate at the UniK - University Graduate Center,
University of Oslo, Norway. (e-mail: Tore.Ulversoy@f?.no).
Digital Object Identi?er 10.1109/SURV.2010.032910.00019
[4] and by the Federal Communications Commission (FCC)
[5].
The evolution towards SDR systems has been driven in
part by the evolution of the enabling technologies, ?rst and
foremost the DA and AD converters and the Digital Signal
Processors (DSPs), but also that of the General Purpose
Processors (GPPs) and the Field Programmable Gate Arrays
(FPGAs). A major driving force has also been the demand
for more ?exible and recon?gurable radio communication
solutions, in particular from the military sector. This demand
has resulted in several major governmental development programmes, e.g. in the U
S the SpeakEasy I, the SpeakEasy
II [6] and the ongoing Joint Tactical Radio System (JTRS)
[7]?[9] programme. Examples from Europe are the "Software
Radio Architecture" Plan d fEtude Amont (PEA) [10], [11]
in France, the Terminal Radio Software (TERSO) programme
[12] in Spain, the Finnish Software Radio Programme (FSRP)
[13], the Swedish Common Tactical Radio System (GTRS)
[14], [15] and the European Secured Software De?ned Radio
Referential (ESSOR) [16] programme. The latter is the result
of cooperation between several European countries under the
banner of the European Defence Agency (EDA).
There are many motivations for utilizing SDR solutions.
For the military sector, where communication systems need to
have a longer service life time than in the commercial sector,
SDR helps to protect investments by prolonging the useful service life of commun
ication systems. This is facilitated through
SDR allowing the possibility to change waveforms and/or load
new waveforms on already acquired SDR equipment. It also
allows SDR applications (waveforms) that are already invested
in to be ported to new and more capable SDR platforms. SDR
furthermore provides the ?exible asset suited for the changing
environments of coalition and Network Centric Operations
(NCO).
A major motivation within the commercial communications
arena, is the rapid evolvement of communications standards,
making SW upgrades of base stations a more attractive solution than the costly r
eplacement of base stations.
Common for both the military and the commercial sector,
is that SDR opens up a range of possibilities by making
existing types of radio applications easier to implement, and
by allowing new types of applications. In particular the
computing capacity and the ?exibility of the SDR may be
exploited to develop Cognitive Radios (CR), context-sensitive
and adaptive units that may also learn from their adaptations. As an example, th
e SDR unit may adapt to harsh
interference and noise conditions by instantly changing parts
of the waveform processing through loading different SW
1553-877X/10/$25.00 c 2010 IEEE532 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL.
12, NO. 4, FOURTH QUARTER 2010
Data Source FEC
Encoder
Interleaver Symbol
Mapper
and
Scrambler
Symbol to I/Q
and
Transmission
Filter
Fig. 1. An example application component structure, the TX baseband processing o
f a relatively simple Stanag 4285 waveform. The processed data is sent
in packets from the output port of one component to the input port of the next c
omponent.
modules, in order to still maintain adequate bit error rates.
The cognitive functionality may also be used for improved
spectrum utilization, e.g. through the coexistence of cognitive
systems with legacy systems.
SDR is also bene?cial for space applications as it provides
the ?exibility that will allow deployed satellite communication
equipment to be SW upgraded according to advances in
algorithms and communication standards. This will allow
communication functionality changes and multiple uses during
the lifetime of the satellite [17].
The exploitation of SDR technology in actual products has
evolved more slowly than what was anticipated some years
ago. As late as in 2002 [2] it was predicted that by 2006
the adoption of SDR in commercial mobile terminals would
have "widespread adoption and movement to SDR as baseline
design", something which certainly has not happened. Also the
US government JTRS programme has at various times since its
initialization in 1997 "experienced cost and schedule overruns
and performance shortfalls" [7]. However, lately there have
also been several positive signs and accomplishments within
SDR, which indicates that we are getting closer to a largerscale adoption of SDR
in commercial products. Examples
are Vanu Inc. fs fAnywave f base station approved by the
FCC [18], the ?rst fSCA approved with waivers f military
communications product Thales AN/PRC-148 JEM, and the
?rst fSCA approved with no waivers f Harris Falcon III(TM)
AN/PRC-152(C). Also an increasing number of SDR research
and prototyping platforms are being offered on the market,
along with SDR development tools.
This tutorial will review the fundamental challenges that
SDR imposes on the various actors within the ?eld, i.e. developers, security org
anizations, regulators, business managers,
and users. It will further review part of the important past and
ongoing work, when available, that has contributed to deal
with these challenges. During the discussion of each topic
there will be a summary of the remaining open items and/or
the projections.
The tutorial will start with SDR SW architecture. As
a background to this discussion, Software Communications
Architecture (SCA) is brie?y reviewed. Then there is a review
of the challenges and existing/ongoing work within application
portability, application development, the underlying middleware platform and alt
ernative 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.
SDR poses severe challenges also in analogue RF hardware
design and the conversion between the analogue and digital
domains, particularly in wideband implementations. In order
to limit the scope of this tutorial, and as these topics are not
unique to SDR alone, these topics have not been discussed
here. A recommended source of information on these topics
is the recent work by Kenington [3]. The aspects of AD
conversion are also excellently treated in [19] which occurs
in what is considered a landmark special issue on Software
Radio [20]. Additional recommended sources on SDR receiver
front-end technology are [17], [21]?[24].
I I . SDR A N D T H E SO F T WA R E CO M M U N I CAT IO N S
AR CH I T E C T U R E
The most widely used software architecture for SDR is
the Software Communications Architecture (SCA). SCA is
published by the Joint Program Executive Of?ce (JPEO) for
JTRS, with SDR Forum having assisted the JPEO with the
development of SCA. SCA is considered a fde facto f standard
for the military domain, and has been implemented within the
SDR industry, research organizations and at universities.
SCA together with available SCA-based tools allow designers to build component-b
ased SDR applications, as assemblies
of components and logical devices. The components are SW
processing modules with input and output ports, context
dependencies in the form of processing element dependencies, and with settable p
roperties. The logical devices are
abstractions for HW modules that in some way process the
information stream.
The component-based approach makes the reuse of parts
of applications easier as the components have clearly de?ned
inputs, outputs and context requirements, and are deployable
units. The component-based approach also promotes a separation of roles in the d
evelopment. Thus, a radio systems
engineer could assemble an SDR application based on preprogrammed components wit
hout having to be a SW specialist, whereas a signal processing implementation sp
ecialist
could concentrate on the processing code of a component.
The SCA is a distributed systems architecture, allowing the
various parts of applications to run on different processing
elements, i.e. each component is deployed on one of a set of
available processors. The communication between the components, and between comp
onents and devices, is based on using
the Common Object Request Broker Architecture (CORBA)
middleware. For communication with specialized processors,
e.g. DSPs or FPGAs, SCA advises the use of adapters between
CORBA and these units.
The SCA de?nes a protocol and an environment for the
application components. SCA does this by de?ning a set ofULVERSOY: SOFTWARE DEFI
NED RADIO: CHALLENGES AND OPPORTUNITIES 533
Application
Component
System
Component
A
P
I
A
P
I
FC FC AEP FS FS
CORBA CORBA
OS
Application
Component
A
P
I
System
Component
CORBA
FS FC AEP FS FC
Fig. 2. A visualization of the layers of the SCA. fFC f is an implementation
of the Framework Control Interfaces, and fFS f an implementation of the
Framework Services Interfaces. fAEP f is the Application Environment Pro?le,
that limits the applications access to the Operating System (OS).
interfaces and services, referred to as the Core Framework
(CF) [25], by specifying the information requirements and
formats for the Extensible Markup Language (XML) descriptions for components and
applications, termed the "Domain
Pro?le", and by specifying underlying middleware and standards. By providing a s
tandard for instantiation, management,
connection of and communication between components, the
SCA contributes to providing portability and reusability of
components.
The CF interfaces are grouped in four sets:
? The Base Application Interfaces provide management and
control interfaces for the application components, and
they are implemented by these application components.
? The Base Device Interfaces allow management and control of hardware devices th
rough their software interface,
and are implemented by the logical device components.
? The Framework Control Interfaces control the instantiation, management and rem
oval of software from the
system, and these interfaces are implemented by software
modules that form part of the system platform.
? The Framework Services Interfaces provide ?le functions,
and are implemented by software modules that form part
of the system platform.
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 fdevices f.
I I I . SW AR CH I T E C T U RA L CH A L L E N G E S
Since the SCA is the dominant SDR architecture, the
SCA-related challenges will be focused on ?rst. Then the
more general SW architectural challenges and alternatives to
SCA will be discussed. The remaining open issues will be
highlighted.
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. Such waveform portability is highly desirable,
particularly in the military sector, for example in order to
achieve interoperability in coalitions by exchanging waveforms.
SCA contributes to such application portability by providing
a standard for deployment and management of SCA-based
applications [25]. It also standardizes the interconnection
and intercommunication both between the components of the
application, and between components and system devices.
Using the SCA Application Environment Pro?le (AEP), SCA
also standardizes the minimum subset of operating system
capabilities that must be available for the applications, and
hence the limited subset that applications may use.
The SCA compliance of an application is not suf?cient to
cover all aspects of portability. Signi?cant pieces that are not
standardized by the SCA itself are the APIs to the services and
devices of the system platform (see Figure 2). Since these are
linked to the actual implementation of the system platform,
they are supposed to be standardized per system or domain,
as is clearly pointed out in the SCA 2.2.2 speci?cation [25].
Within JTRS, a number of such APIs have been developed
[8]. Although previously not publicly accessible from the SCA
website, 14 APIs were made available in April 2007 [26] and
as of February 2009, 18 were available. Presumably this is
not a complete set of APIs. Also for some APIs there may
be strategic reasons for not wanting to release them from a
particular domain, examples are the security-related APIs.
In order for portability to extend across domains, the APIs
to the services and devices will need to be standardized across
domains as well. With the JTRS APIs now being available,
these may be one option for such standardization, particularly
for military domains. There are also several other initiatives
in this area, including one from the Object Management
Group (OMG) Software Based Communications Domain Task
Force [27]. Another example is the ESSOR project, which
aims at giving "European industry the capability to develop
interoperable SDR" [16]. It remains to be seen if ESSOR
will develop standards to be used by a European military
domain only, or whether this initiative could also contribute
to providing inter-domain waveform portability.
An alternative and equivalent approach to that of standardizing APIs to system c
omponents is providing abstraction
layers between the platform and the application components.
An example is a proposal for a "Transceiver Facility Platform
Independent Model" [28].
Another related portability issue is the various alternatives
for transport mechanisms for the communication with components deployed on DSPs
and FPGAs. SCA 2.2.2 prescribes
adapters between CORBA and the DSP and FPGA components as the primary means of c
ommunication with these
elements. The JTRS has standardized a speci?c adapter referred to as the Modem H
ardware Abstraction layer (MHAL)
for this purpose [8], [26]. Other similar solutions exist, e.g.
Spectrum Signal Processing fs fQuicComm f [29]. In recent
years, Object Request Broker (ORB) implementations have
also been made available on DSPs and FPGAs, making
CORBA communication possible also to these components
[30]. The fact that various messaging protocols are currently
used implies, however, that communication with DSPs and
FPGAs will remain a portability issue until one standard or
another has become the de facto standard.
Furthermore there are some minor portability issues related
to differences in ORB implementations [31].
Lastly, portability obviously requires that the component
code is interpreted correctly on the platform. This again has534 IEEE COMMUNICAT
IONS SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010
TABLE I
A SU M M A RY O F PO RTA B I L I T Y IS S U E S F O R S CA - BA S E D AP P
L I C AT I ON S
Portability aspect: Standardized through SCA?
Environment and protocol for
the installation, instantiation,
control, connection and intercommunication of application
components
Yes. (But: SCA Security requirements not public)
De?ned allowed OperatingSystem access
Yes, through AEP
APIs to system units (devices) and
system services
No. (SCA states this is to be handled per domain.)
Communication (message transport) with specialized processors
(DSPs, FPGAs)
No. Multiple solutions available.
JTRS has standardized on MHAL.
ORB SCA speci?es CORBA. There are
however some minor differences
between ORB-implementations.
Programming language No, but this merely presumes
availability of compilers, libraries
etc.
Target processor compatibility of
the code
No. Different DSPs and FPGAs
may support different features.
two aspects, language compatibility issues and target processor
functionality compatibility. Since SCA is based on CORBA
which has support for several programming languages, using
different code languages will be possible as long as the
appropriate compilers and libraries are available. However,
different processing elements, in particular different types of
DSPs and FPGAs, support different functionalities and features. This either requ
ires several component implementations,
one for each family of processing elements, resulting in an
overhead of work-hours used. The other approach is to have
the component functionality de?ned in a high-level language,
which is compiled to create a correct code image for the actual
processing element to be used. Obviously such a compiler
may become very complicated. The resulting target code or
image may also become less optimal than a target code written
speci?cally for the target processor.
Further information on portability issues may be found
in recent publications, including API standardization [32],
lessons learned from porting a soldier radio waveform [33],
SCA aspects in heterogeneous environments [34] and the
trade-off between portability and energy ef?ciency of the
processing [35].
The portability issues with SCA-based applications are
summarized in Table I. As is evident from the table, important
challenges remain in this area.
B. Challenges related to SCA Application Development
For the traditional communications equipment design engineer, with a communicati
ons or radio engineering and less
of a SW distributed systems background, SCA may appear
challenging to learn and understand.
Even for embedded systems engineers without a CORBA
and Object Oriented Programming background, according to
[36] fit could take several months to fully understand SCA f.
SCA tools help abstract away some of the dif?culties in
SCA. Commercial tools are available from various sources,
e.g. Zeligsoft [37], PrismTech [38] and Communications Research Canada (CRC) [39
], and there is also a University Open
Source initiative, the Ossie Waveform Developer [40] from
VirginiaTech. While de?ning SCA components manually is
tedious work involving a lot of XML and CORBA details,
the tools allow the SDR designers to de?ne the components
through user-friendly tool interfaces. The tools also allow
applications to be formed by making connections between
the various components, and between the components and
the devices of the platform. Still, even with the tools being
of signi?cant help in the development process, concluding
for example from SCA-based development efforts within own
organization, detailed SCA knowledge is still needed and in a
starting phase a lot of time is spent on non-signal-processing
issues, particularly on a heterogeneous platform.
The tools typically generate the necessary XML and the
SCA infrastructure part of the components [41], while functional processing code
needs to be added by the designer,
either coded manually or using her/his favourite tools. A more
uni?ed higher-level design approach possibly could improve
productivity. An approach where the functional skeleton code
is imported into a Uni?ed Modelling Language (UML) to
allow higher abstraction level modelling of the functional behaviour, is describ
ed in [41]. It is envisioned that SDR-design
will increasingly be performed at higher abstraction levels,
eventually using fully integrated Model-Driven Development
(MDD) [42] tools with automatic transformation from model
level to any speci?c heterogeneous platform.
In summary, a further enhancement of the ef?ciency of
designing SCA-based applications, as well as a general availability 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.
Throughput is a factor of both CORBA and the underlying
transport used by CORBA. In [43] throughput of CORBA
one-way invocations has been measured using a TAO 1.2
ORB, TCP/IP and 100MBit/sec Ethernet, and compared to
using TCP/IP socket programming directly. The results show
that the CORBA throughput is highly dependent on message
size. With a message size of 64 bytes the CORBA TAO
throughput was only a few MBit/sec, whereas with TCP/IP
socket programming above 90 Mbit/sec. For message sizes
above 8K bytes the throughput came close to that of using
socket programming directly. These results show that avoiding
too small packet sizes in SCA-based applications is important
in order to keep the throughput optimized.
Where the throughput is limited mainly by the underlying
transport, other transport mechanisms than TCP/IP may be
used with CORBA. "CORBA over RapidIO" [44] and CORBA
over a PCI bus [45] are recently described examples.ULVERSOY: SOFTWARE DEFINED R
ADIO: CHALLENGES AND OPPORTUNITIES 535
Latency implies processing delays in the SDR, and tolerable
level is application and waveform dependent. As with throughput, latency is a fu
nction of both CORBA and the underlying
transport. Average latency tends to show a linear relation with
message size [44], [46], and with a signi?cant non-zero latency
for message size 0. As an example, latency with CORBA over
a RapidIO transport between GPPs [44] is measured at 114 Ês
for size 32 bytes and 180 Ês for 4096 bytes. Latency variation
may be reduced [47] by using Real-Time CORBA features.
Measurements of CORBA computation overhead for a GPPsystem with the Ossie CF [40
] and OmniORB have been
provided in [48]. Figure 3 shows an example of how the
computation overhead is increased when an application is split
into more and more components, and which in this case is
dominated by a CORBA-related overhead [48]. The application waveform was a Stana
g 4285 TX base band waveform
running at an increased symbol rate of 25600 symbols / sec,
with frames of 256 symbols being processed at a time.
The memory footprint may be signi?cant on a general fullfeature ORB [49] but sli
m implementations have been made
needing less than 100 kBytes of memory [44], [50].
In order to eliminate CORBA latency, throughput and
footprint implications, and in particular when the processing
is done on DSPs and FPGAs, data transfers are done on many
current SDR systems on speci?c high-speed connections with
low-level formatting [50], [51] instead of using CORBA. A
downside of this approach is that it makes portability more
dif?cult, unless the high-speed connections and formatting are
standardized. Adapters may be used for control and data from
CORBA-enabled processors.
While CORBA used to be limited to GPP processors only,
ORBs for specialized processing elements such as DSPs [50]
and FPGAs [30], [44], [50], [52] have been developed in
recent years. The ORB on an FPGA may be put in an
embedded microprocessor [52], or (as a CORBA subset)
directly implemented at native gate level [44], [50], where
the latter has a processing speed advantage. This theoretically
facilitates CORBA communication between all typical processing elements on an SD
R platform, which is excellent for
portability. The downside of the approach is the amount of
resources occupied by these ORBs on the processing elements,
and the latency and throughput implications. As for FPGA
ones, latency numbers published in [44] and statements in
[50] that an FPGA native level ORB may process a message
in fa few hundred nanoseconds f indicate that FPGA native
level ORBs can now be made very effective in terms of
performance, but further public domain results are needed on
this subject.
CORBA has its popularity in embedded and real-time
applications, but has become less popular in general businessoriented applicatio
ns. This naturally raises the question of
whether there are other likely candidates to take over from
CORBA also in SCA and SDR applications. In [53], CORBA
has been compared to two main competitors in the businessoriented domain, Enterp
rise Java Beans (EJB) and Web Services. CORBA was found to be the most mature an
d better
performing technology, 7 times faster than Web Services in a
speci?c single-client evaluation test, but also by far the most
complex one. Web Services was the worst performer but the
simplest one and the one that tackled Internet applications
best. Web Services is popular in this domain, which illustrates
that it is not because it is being outcompeted on performance
that CORBAs popularity has diminished, but rather due to
other technologies meeting a weighted set of requirements
for this type of application better. CORBA fs standing in this
domain is thus not directly transferrable to the SDR domain,
as the SDR domain has more focus on performance issues.
The Data Distribution Service (DDS) has been suggested
as an alternative middleware in an SCA context. DDS is an
OMG-managed standard for publish-subscribe communication
for real-time and embedded systems [54]. DDS belongs to
the group of Message-Oriented Middleware (MOM). MOM
provides a looser coupling between senders and receivers than
in CORBA, messages are sent to an intermediary layer from
which the message is received by the addressee [55].
In summary, there are exciting ongoing CORBA activities,
such as enabling ORBs to work with fast transports and new
ORBs for FPGAs. In the near term, it is anticipated that this
migration of CORBA onto specialized processors and faster
transports will continue, but that low-level non-CORBA data
connections will still be used where they are advantageous.
So far there is not a clear path for a middleware that is less
complex yet better performing, to potentially take over the
role of CORBA in SDR.
D. SCA Challenges and Alternative Architectures
Several technical- and complexity-related SCA challenges
have been reviewed in the previous subsections. 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.
A closely related alternative architecture speci?cation for
SDR, and derived from the SCA, is OMG fs "PIM and PSM for
Software Radio Components Speci?cation" [56]. Its current
Platform Speci?c Model (PSM) utilizes CORBA-interfaces
[56], but the division in a Platform Independent Model (PIM)
and a PSM makes it easier to substitute CORBA with some
other middleware, if more suitable middleware platforms were
to emerge in the future. OMG fs standards are open ones also
in the sense that all members have an equal vote on the ?nal
content of a standard. OMG fs speci?cation is used by the
WINTSEC project [57] in Europe. It has been put forward
as a promising candidate for future use in the commercial
domain [58].
Of particular interest for resource-constrained systems is
NASA fs fSpace Telecommunication Radio System f (STRS)
[59]?[61] architecture. Electronic devices used in space require radiation harde
ning [59], and processors are hence
slower than terrestrial equivalents, which places further requirements on reduce
d resource consumption on the application and runtime environment. STRS has many
characteristics
in common with SCA, such as the separation of waveform
applications from hardware, but there are also differences.
No particular communication mechanism is described, i.e.
CORBA is neither mandated nor precluded. Likewise, an
XML parser is not part of the STRS infrastructure, XML ?les536 IEEE COMMUNICATIO
NS SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010
Data
Source
FEC
Encoder
Interleaver
Symbol
Mapper &
Scrambler
Symbol to
I/Q & TX
Filter
Float to
fixed
converter
Float to
fixed
converter
Forwarder Forwarder Forwarder Forwarder
Data
Source
FEC
Encoder
Interleaver
Symbol
Mapper &
Scrambler
Symbol to
I/Q & TX
Filter
Data
Sink
Stanag
4285 TX
Data
Sink
Data
Sink
CPU: 5.5%
CPU: 11.2%
CPU: 16.6%
Fig. 3. Processor workload (user applications + system) in % when running a Stan
ag 4285 TX waveform, at an increased symbol rate of 25600 symbols
/sec, using the Ossie CF on a GPP, and with having the waveform application impl
emented as one SCA component (top), 6 components (middle) and 6
components with 4 additional (no-functionality) forwarding components (bottom).
With the useful signal processing being identical in all three cases, the
processor workload is seen to increase signi?cantly as the processing is split i
nto more components.
may be pre-processed prior to deployment [59]. STRS does not
have the notion of ports but rather optional source and sink
APIs [60]. The standard is a NASA managed one, but it is
in?uenced through collaboration with OMG and SDR Forum
[61]. An open-source implementation, "Open Space Radio"
[62], has been made available by Virginia Tech.
The GNU radio architecture [63] is an open-source initiative, where the signal p
rocessing 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 ?ow, 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.
A comparison between GNU radio and a OSSIE SCA-based
system has been recently published [64].
Since part of the features of MOM ?t well with SDR fs
needs, there could be a potential for MOM-based architectures as future alternat
ives for SDR, however this has to be
demonstrated.
With the evolution towards cognitive radios which requires
the radio to have reasoning capability and adaptivity there
will probably be a need for architectural features beyond
the present SCA. As an example, with cognitive radios it
is bene?cial to have convenient framework functions to be
able to swap a component from/to a running application in
close to real-time. Also, although the cognitive functionality
itself, e.g. adaptation of the waveform application to external
conditions, may be implemented as application components, it
may be bene?cial to partly support this functionality through
middleware. An example of a middleware-based approach to
system self-adaptation is provided in [65].
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 signi?cant 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.
IV. CH A L L E N G E S A N D OP P O RT U N I T I E S RE L AT E D TO
CO M P U TAT IO NA L RE QUI R E ME NT S O F SDR
A. Computational Requirements
A fundamental challenge with SDR is how to achieve
suf?cient 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.
This is particularly challenging for small handheld units,
e.g. multi mode terminals. The power consumption must be
below certain limits to keep the battery discharge time within
acceptable limits, and with the smallest handheld units it will
also be an issue of not causing the surface temperature of the
device to become unpleasantly high for the user.
For base stations like cellular network infrastructure stations, and for vehicul
ar mounted stations, the power, size and
weight factors are easier to accommodate, however performance versus these param
eters and cost may still be challenging for complex high bit rate waveforms.
SDR applications perform processing of the various stages
of receive and transmit signals, but they also perform protocol
handling, application control activities, user interaction and
more. Conceptually, as an abstraction, we can consider SDR
applications to consist of two main groups of components, (1)
Data Processing Components (DPCs) and (2) Event Driven,
Administrative and Control Components (EDACCs). DPCsULVERSOY: SOFTWARE DEFINED R
ADIO: CHALLENGES AND OPPORTUNITIES 537
TABLE II
CO M P U TAT I O NA L C O M P L E X I T Y F O R S O M E K E Y A L G O
R I T H M S O F 8 0 2 . 1 1A
802.11a signal processing operation at 24 Mbps
Gigacycles per second, Alpha
GPP
FFT 15.6
FIR (Rx) 6.08
Viterbi decoder 35.0
typically have deterministic behaviour, in the form of processing a package of d
ata according to its de?ned algorithm. DPCs
typically also have a high degree of inherent parallelism that
may be exploited, an example being a Finite Impulse Response
(FIR) ?lter where a number of additions and multiplications
may be carried out in parallel, and the deterministic behaviour
also allows low-level optimization of implementations, see, for
example [66]. EDACCs depend on events, on data content or
user interaction, or perform various administrative and control
tasks and are less predictable in their path of execution. Also
they typically have far less inherent parallelism.
The SDR components may to a large degree run in parallel,
e.g. a decimator component may run in parallel with a ?lter
component and a Fast Fourier Transform (FFT) component,
since they work on different stages of the processed data.
The Software Communications Architecture (SCA) facilitates
this type of parallel processing as it is a distributed systems
architecture, where processes may run on several processing
elements while exchanging processed data. A good exploitation of this parallelis
m depends on a well devised component
structure of the waveform application, along with optimized
deployment of the components on the available processing
elements.
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,
as provided in [67]. 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. For the
DPCs, processing elements that are able to exploit regular
structures, deterministic ?ows of instructions and internal
parallelism will be bene?cial from a performance point of
view. In the following some of the most important processing
alternatives will be reviewed. The alternatives will be listed
according to recon?guration time, starting with the least con-
?gurable options and proceeding to the real-time con?gurable,
as the ability of SDRs to be recon?gured or reloaded with new
waveform components or applications is one of its most essential properties. For
some SDR applications, it will be suf?cient
to be able to recon?gure the unit at a maintenance site, and
it will not be a problem if it takes a few minutes to load a
new application. For other applications, recon?guration will
need to happen while switching from one service, network or
waveform standard to another, e.g. while switching from GSM
to WiFi, and the recon?guration should then typically be done
in less than a few tenths of a second. For other applications,
e.g. a fully context-adaptive SDR, recon?guration will need to
be done in real-time without disturbing any operation of the
radio system.
1) Static Processing Elements and Tailored Functional Arrays: In a non-SDR devic
e, the computationally demanding
and often highly parallel parts of an algorithm would typically be implemented a
s logical circuitry in an ApplicationSpeci?c Integrated Circuit (ASIC). This is
often regarded as
the optimum solution for computation ef?ciency and power
consumption, and is typically regarded as a reference solution,
which the recon?gurable solutions may be compared against.
ASIC solutions may provide low unit costs for very high
production volumes, but with high development costs.
ASIC implementations are static and as such not usable
in an SDR. SDR approaches that focus on the advantages of
ASIC implementations, and on the fact that waveforms tend to
have common modules, have however been suggested. It has
been pointed out [68] that CMOS ASIC devices with more
total logic than alternative Field Programmable Gate Arrays
(FPGAs), have signi?cantly less quiescent power and dynamic
power consumption. Taking this into account, it is further
suggested [68] it is bene?cial for any design to evaluate the
waveforms and determine which functions are common across
waveforms, which then could be hosted in an ASIC to allow
a low power implementation.
Related suggestions are also discussed in [69], where
the processing platform is constructed of interconnected
application-domain tailored functional units.
Along the same line, some commercial signal processors are
having coprocessors speci?cally tailored for speci?c functions
[70].
The functional units may be parameterized to adapt to the
speci?c waveform application. By changing parameters and
switching functional units in and out, fast recon?guration
within the solution space provided by the functional units is
available.
It can be argued that such ASIC-hosted modules or tailored
functional units will have a negative impact on portability of
waveform applications, limiting portability to platforms that
have the necessary ASIC implementations or functional units.
Against this it can be argued that having alternative software
implementations of the same functionality for more general
processing elements, and by allowing the deployment manager
to make intelligent decisions on whether to utilize the ASIChosted modules, tail
ored functional units, or more general
processing elements, portability will still be achieved. Still,
for part of the SDR community, SDR platforms with ASIChosted processing modules
will not be considered true SDR
ones.
2) Recon?gurable Processing Elements: The Field Programmable Gate Array (FPGA) i
s the recon?gurable alternative to the ASIC. At the expense of higher power cons
umption
and circuit area than the corresponding ASIC solution, an
FPGA can be ?eld-programmed with the speci?c code needed
for the speci?c waveform application. Recon?guration times538 IEEE COMMUNICATION
S SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010
may become as low as fractions of a second or just some
milliseconds, and hence may allow recon?guration of the SDR
unit to connect to a network via a different waveform standard,
for example.
FPGAs have become computationally powerful circuits, and
come in many variants. An additional advantage of the FPGAs
is the rich availability of toolsets. Further, the amount of
designs done for FPGAs and the amount of know-how about
this type of designs in typical electronics development organizations, make desi
gns for FPGAs easily planned development
tasks with low or moderate risk. Also, compilers are being
promoted that make it possible to generate FPGA code directly
from Matlab or Simulink, or directly from c-code. This type
of compilers can be used for applications such as accelerating
bottleneck pieces of c-code running on a GPP or DSP, by
converting them to FPGA code. An example is Altera fs Nios
II C2H compiler which is described in [71].
3) Fast Recon?gurable Units: Con?gurable Computing
Machines (CCM) offer shorter recon?guration times than
FPGAs, and for some types close-to real-time recon?guration.
CCMs are fcustomizable FPGAs with a coarser granularity
in its fundamental composition that is better suited for signal processing or wi
reless applications f [72]. CCMs have
application-domain tailored processing units, connected via a
highly ?exible and fast recon?gurable fabric.
There is a huge variety of proposed CCMs, both academic
initiatives and commercial products. [72] and [3] provide
overviews of different CCMs.
CCMs may seem ideally suited for SDRs that need high
performance and fast recon?guration. A disadvantage, however, is the diversity i
n approaches, which makes efforts to
use them very much a unique effort for each type. This also
reduces the availability of SW tools for programming them.
4) Real-Time Recon?gurable Units: Microprocessor systems are processing alternat
ives that provide full real-time programmability. Year after year, processors ha
ve shown remarkable performance increases. Whereas cycle clock increases
have become more dif?cult 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. This is often
the result of having more features operating in parallel within
the processor. This has advanced into multiple-core processors, e.g. multi-core
GPPs, multi-core DSPs and Massively
Parallel Processor Arrays. Notably, the trend towards parallel
processing within microprocessor technology ?ts well with the
characteristics of DPC SDR components.
While GPPs are designed for good average performance
for a wide variety of program sources, DSPs have features
speci?cally targeted for digital signal processing, e.g. combined multiply-accum
ulate operations, and including features
to exploit parallelism [73]. There are DSPs that are optimized
for performance, and others that are optimized for low power
consumption, e.g. for battery-driven applications.
Most multi-core processors may be classi?ed 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.
An example of a unit that has several SIMD processing
elements is the Cell processor [74]. The peak processing
power is quoted at an impressive > 256 GFlops [75], however
the corresponding power consumption is not stated, in a
chart comparison with other processors [67] it is located at
approximately 50W. Although lower-power versions have been
released [76], [77], these presumably still have a somewhat
high power consumption when considering battery powered
applications.
Examples of units that have SIMD processing elements
and that are targeted for low-power consuming units, are
the NXP Embedded Vector Processor (EVP) [78], [79], the
Sandbridge SB3011 [80] and the Icera Livanto [81]. An
example university approach is the SODA architecture [67].
It is argued that a solution to the performance/power challenge of the fourth ge
neration communication standards, is an
increased number of cores, with each core including a very
wide SIMD processor, hence exploiting the parallelism of the
algorithms [82].
MIMD units have multiple instruction streams, and operate
on multiple data streams at a time. This is hence a more
general and ?exible 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 [83].
Recent GPUs for the gaming market are powerful computing
units with a number of parallel processors, e.g. the nVidia
8800 GTX has 128 ?oating point units running at 1.35GHz,
and an observed 330GFlop/sec [83]. As the processors are
targeted speci?cally at graphics related processing, they have
a higher user threshold for general purpose or signal related
processing than a GPP. However, due to the attractive prices
and high computational capacity of GPUs, they may become
attractive in low-budget-type PC-based SDR solutions, as
accelerators for processing-intensive blocks. GPUs may also
have importance for SDR as high-volume massively parallel
computation technology that may be speci?cally tailored to
SDR applications.
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.
In addition to the processing performance the factors of
recon?gurability time, power consumption, size, weight, cost,
suitability for the actual processing load and probably many
more factors need to be taken into account to make proper
choices.
Unfortunately there is no uni?ed scale by which the processing capacity of the d
ifferent types of processing elementsULVERSOY: SOFTWARE DEFINED RADIO: CHALLENGE
S AND OPPORTUNITIES 539
TABLE III
WAV E F O RM IM P L E M E N TAT I O N EX A M P L E S F O R DI FFE R E N T
PRO C E S S I NG
EL E M E N T S (R E F E R E N C E S, S E E T E X T)
Proc.
element
class
Source and
type
Implementation(s) and result(s)
Pub.
year
FPGAs
and
CPUs
2x XiLinx
XC2V4000,
6000, 8000
2x CPUs
(unspeci?ed)
430 MIPS
802.11a
W-CDMA
2004
SIMD
Sandbridge
Sandblaster
SB3011
WiMAX, 2.9Mbps: 80% utilization
802.11b 11Mbps: 55% utilization
W-CDMA 2.4Mbps: 87%
utilization
@0.5W
2007
SIMD NXP EVP
Estimated approx 45% utilization for HSDPA @ few
hundred milliwatts
2005
CCM
Stallion
(VirginiaTech)
A benchmark suite of WCDMA algorithms
Computations/sec: 7118
@0.7W
2004
32-bit
VLIW
DSP
TI C6201
A benchmark suite of
WCDMA algorithms
Computations/second: 10293
@1.94W
2004
can be judged. For the various processing elements there are
different ?gures of merit that are promoted, examples being
MIPS, MOPS, MMACS, MFLOPS and so on. An interesting
approach is described in [84] where various elements (ASIC,
FPGA, DSP, GPP) are evaluated and comparative charts
provided. A speci?c FFT is used as a benchmark algorithm
and Real-Time Bandwidth (RTBW) as a scale, de?ned as the
maximum equivalent analogue bandwidth that the unit is able
to process with the given algorithm, without losing any input
information. Still these types of comparisons are only valid for
the particular benchmark algorithm. Also they do not indicate
the capacity of the unit for running other algorithms in parallel,
e.g. in an FPGA case.
Guidance may also be obtained from commercially available benchmark analysis rep
orts from Berkeley Design Technology, Inc. (BDTI) [85].
In order to give an indication of what may be achieved
with the different types of elements, Table III provides some
examples of implementation results from various published
work [79], [80], [86], [87].
C. Requirements versus Capacity, the Way Ahead
With the continuous improvement of processing elements,
will having adequate processing power in handheld SDR
terminals soon be a non-issue? To make some projections,
and inspired by [88], the data rate evolution of mobile cellular
systems [89] has been plotted against the DSP performance
evolution of Texas Instruments (TI) DSPs [70], [90], see Figure 4. Estimates of
the single channel processing requirements
of 2G/3G mobile systems [2], and for a particular 4G case
(conditions in [91]) are also plotted.
Data Rate and MIPS Requirements for Mobile Cellular Systems vs DSP
MIPS Evolution
1
10
100
1000
10000
100000
1000000
10000000
1980 1985 1990 1995 2000 2005 2010 2015
Year
kpbs and MIPS
Data Rate (kbps)
TI DSP (MIPS)
Comp. req. (MIPS)
Exp. Trend DSP
2G
3G
4G
Fig. 4. Data rate in kbps of the download channel of mobile cellular
systems, and approximate MIPS requirements, plotted against the performance
evolution of TI DSPs.
For this example, 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. The required processing rate increases at an even higher
pace, this being due to the algorithmic complexity increasing
with the generations.
While the progress of processing element capacity continuously makes it easier t
o meet the capacity requirements
of today fs 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.
V. SE CU R I T Y RE L AT E D CH A L L E N G E S
The ?exibility bene?ts of SDR at the same time causes
challenges in the security area, both for developers and security certi?cation o
rganizations. In the following the most
important of these security related challenges will be reviewed
along with important research contributions in these areas, and
a summary of the remaining dif?culties.
A. Software Load and Protection against Unauthorized SW
A major security challenge is introduced through the possibility to load and ins
tall new SW on an SDR unit [92], possibly
also over-the-air [23], [92]?[94] or via a ?xed network [94]
connection, and the consequent threat of having unauthorized
and potentially malicious SW installed on the platform. This
problem domain is very similar to that of maintaining SW
installations on personal computers, and avoiding unintended
or malicious functions to be installed. With SDRs, the consequences of unauthori
zed code can be even more far-reaching,
from compromising threats to the user fs assets, e.g. his con?-
dential items, via threats to the communication ability of the
equipment, to threats to other users and networks, e.g. by the
SDR jamming other radio activity [95]. In the USA, SDRs are
required by the FCC to have the means to avoid unauthorized
SW [96], the speci?cs of these means are however left to the
manufacturer.540 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH
QUARTER 2010
If the SW is downloaded over the air, this also exposes
the system for someone illegally obtaining the SW (privacy
violation) or altering the SW while in transport (integrity
violation).
Several publications describe the preventing of unauthorized
code by using Digital Signatures [97]?[104]. The manufacturer
(or any other party authorizing the code) computes a oneway hash of the code mod
ule, then encrypts this hash code
using their private key of a private-public asymmetric key pair.
This encrypted hash is the digital signature which is added to
the code module before it is sent to the SDR platform. A
veri?cation application on the SDR platform then veri?es the
signature by decrypting the signature using the manufacturer fs
public key, and checks that the decrypted signature equals the
one-way hash of the code module. A Digital Certi?cate is a
way of assuring that a public key is actually from the correct
source. The Digital Certi?cate is digitally signed by a trusted
third-party. The trusted third-party is veri?ed through a chain
of trust to a root certi?cate on the platform.
A critical issue with the above approach is that root certi?-
cates must be distributed to all terminals through a secure
out-of-band channel. With a new platform this is easy as
root certi?cates may be factory installed or installed through
physically delivered SW, however the issue becomes important
when a certi?cate has expired when the terminal is in the ?eld.
A further issue is that of revocation of certi?cates. A certi?cate
can be revoked at any point in time, and in order for the
terminal to know if this is the case or not, it needs to check
against a revocation registry, for each and every download
operation. It is well known from general computing that this
pattern of action is not always obeyed.
Another published way of providing code authorization
relies on the sharing of a secret between the SDR platform
and the manufacturer. The manufacturer may then make a oneway hash of the SW cod
e and the shared secret and send this
hash to the SDR platform together with the SW code [102].
The SDR platform may then verify that the code is from the
manufacturer by doing the same one-way hash and compare.
A negative implication of this approach is that if the secret
is a unique key for each SDR platform, there will be a high
number of keys to administrate for the manufacturer. On the
other hand, if it is a single key with a wide distribution, this
makes it more susceptible to be compromised.
Trusted Computing (TC) functionality [95] is also an optional way to address thr
eats against an SDR platform and
against downloaded software. A trusted platform subsystem
has a ftrusted component f integrated into the platform, which
is immutable, i.e. the replacement or modi?cation is under the
control of the platform manufacturer. The trusted part may be
used for integrity measurements of a program, and for creating
certi?ed asymmetric key pairs for the software downloading
[95]. TC is further commented in section B.
A suggested further barrier against potentially malicious
code is the pre-running of the new SDR component in a
"sandbox" [99], [104], a sheltered environment where it can be
evaluated without posing threats to the actual system. Ordinary
personal computer protection means as virus protection [92],
[103] and memory surveillance [103] may be further barriers,
as may also radio emission monitoring [99]. The ef?ciency
of the sandbox pre-running may be debated, as there is no
guarantee that the malicious code will expose its behaviour in
this test.
The authorization schemes described above also provide
integrity protection of the code while in transit. Privacy protection, i.e. prot
ecting the code in transit from being disclosed
to a third party, may be achieved through encrypting [98],
[105], [106] the code and including the digital signature.
An SDR ideally should have exchangeable cryptographic
algorithms too. A motivation for exchangeability of cryptographic components is
that even if a current security evaluation does not reveal any weaknesses of som
e cryptographic
approach, cryptanalysis techniques developed later may render
it insecure [98], [103], [105]. The cryptographic components
are in [98], [103], [105] viewed as a matrix with columns
for hash algorithm, digital signature primitive, crypto cipher,
secret key and public key, and with rows for the entries for
alternative cryptographic components. It is assumed that there
is a minimum of two alternatives for each of the crypto
components, such that even if there is one that is compromised,
there is one that is secure that can be used in the downloading
process. Any weak cryptographic component, e.g. a crypto
algorithm, is downloaded using trusted crypto components
from the matrix, and in an automatic manner.
A solution utilizing Altera Stratix III FPGAs has been
described [107]. The FPGA con?guration bit stream is transferred to the FPGA in
Advanced Encryption Standard (AES)
encrypted form, with the FPGA containing a crypto key and a
decryption module that allows it to decrypt the con?guration
bitstream when it is loaded into the circuit. Once inside the
circuit, the con?guration ?le cannot be read back [107].
In summary, many research contributions have been made in
the area of software download, providing a menu of technological options that ca
n be used. Still, there is increased potential
for security threats to SDR systems versus non-recon?gurable
ones. With the anticipated creativity of attackers, the speci?c
solutions for the speci?c SDR systems, and ensuring these
resist potential threats, will remain a challenging area for both
developers and security organizations. Any allowed downloading of security compo
nents will be particularly challenging.
Also, the question of who will authorize the SW remains.
Should it be the hardware manufacturer, the SW company, a
third-party certi?er, a government institution, or all the above
mentioned. This remains an issue that needs to be further
matured.
B. Trusted and High-Assurance Systems
Many communication systems, in particular military ones,
have high-assurance security requirements. Demonstrating
such high-assurance security on a fully ?exible and general
computing platform is a very dif?cult task. This contrasts
that the fully ?exible platform, where all the functionality
is de?ned in SW applications only, is the ideal computing
platform for an SDR in terms of portability.
The high-assurance SDR system will have certain assets,
like crypto keys, the user fs plain text messages, his/her personal information an
d more, that need to be protected e.g. for
con?dentiality and integrity. Hence practical strong securityULVERSOY: SOFTWARE
DEFINED RADIO: CHALLENGES AND OPPORTUNITIES 541
Crypto
Security Control
Black side application Red side application
Red data
Black data
A
P
I
A
P
I
A
P
I
A
P
I
Control Control
Control
Fig. 5. An illustration of a red (plain-text) to black separation barrier, and
the data and control interfaces to the security related modules.
solutions typically employ combinations of hardware solutions
and software solutions [103]. Examples of modules that have
impact on the hardware structure are the protected storage for
crypto keys, the protected storage for the crypto-algorithm,
and the separation between black (encrypted) data and red
(plain-text) data (Figure 5). Such architectures are typically
custom and dedicated.
As mentioned, TC, standardized by the Trusted Computing Group [108], incorporate
s dedicated immutable hardware
elements. The immutable elements are in this case the Root
of Trust for Measurement (RTM), Root of Trust for Storage
(RTS) and the Root of Trust for Reporting (RTR) [109]. These
enable measurements of SW on the platform to be made so that
changes can be detected, con?dentiality-protection of data, and
allow an outside challenger to assess whether the platform is
trustworthy. TC also facilitates isolation between different SW
components on the platform.
While being developed originally for general computing
platforms and PCs, the bene?ts of TC on SDR platforms
have been pointed to [95], and there is also a TCG Mobile
Phone Work group in existence [108]. For SDR, TC can
provide authenticated download, ensure access to SW only
by the intended recipient, detection of malicious or accidental
modi?cation or removal, veri?cation of the state that the
platform boots into, and isolation of security-critical software
[95]. TC functionality does not ensure the integrity of securitycritical softwar
e while in storage, and does not prevent denialof-service attacks in the form of
deletion of the downloaded
SDR software [95]. While TC has many bene?cial properties
for use in SDR, it does not cover every relevant aspect of
security for SDR, and hence in itself is not suf?cient for a
high-assurance SDR system.
Modern military information and communication systems
often need to handle information at different security classi?cation levels simu
ltaneously. With conventional security
architectures, this requires multiple sets of security HW and
processors, which implies both high cost and high power
consumption. Examples [110] have also shown that with the
conventional security architectures it is demanding to certify
the SW security core to the highest assurance levels, as this
part of the SW and hence the certi?cation task often grows
too large to handle at the highest certi?cation levels.
The Multiple Independent Levels of Security (MILS) architecture offers solutions
to these issues. According to [111],
the earliest references to MILS are NSA internal papers by
Van?eet and others from 1996. At the basis of the architecture
Separation Kernel (SK)
Application
Restricted
Middleware PCS
Application
Secret
Middleware
Application
Confidential
Middleware
Fig. 6. The basic building blocks of the MILS architecture.
is a Separation Kernel (SK), as outlined by John Rushby in
1981 [112]. The SK allows several independent partitions,
e.g. partitions handling different security levels (Figure 6),
to run on the same microprocessor, through separating them
in space and time [110]. The SK provides data separation,
in ensuring that the different partitions operate on physically
separated memory areas. It also provides authorized communication channels betwe
en the partitions. Further it provides
for sanitization, i.e. the cleaning of shared resources (e.g.
registers) before a new partition can use them. Finally it
provides damage limitation, in that an error in one partition
is not able to affect the processes in the other partitions. The
SK schedules processing resources to each partition in such a
way that the partition will always be able to process its tasks,
independently of any behaviour in the other partitions. The
SK is the only piece of SW in the architecture that is allowed
to run in supervisor mode, all the partitions run in user mode,
which means under no circumstance can they alter the SK.
Since the SK only includes the limited functionality as
described above, it can be made fairly small, about 4K lines
of code has been quoted [113]. This makes it manageable
to certify the SK to the highest Evaluation Assurance Levels
(EAL) levels in the Common Criteria [114], EAL 6 and EAL
7. Green Hills Inc recently announced the completion of the
certi?cation of their Integrity-178B SK-based OS as the worlds
?rst certi?ed at EAL6+ [115]. It should be noted also that
real-time OSes using SK principles have been used for some
years already, probably with some more functionality than the
minimum-size SK, in the aviation industry, in other embedded
applications and in SDR applications.
The SK requires a certain amount of support from speci?c
HW [116], the most important function being the Memory
Management Unit (MMU), needed for physical memory separation. A remarkable advan
tage with the architecture is that
the speci?c HW support needed is already available in many
commercial microprocessors [116].
The individual partitions include application code and middleware. Middleware in
MILS has a wider interpretation than
the conventional one, it includes both traditional communi-542 IEEE COMMUNICATIO
NS SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010
cation oriented middleware such as CORBA, and may also
include more OS-related functions [110]. Some partitions
may be Single-Level-Secure (handles data at one security
level) while others may be Multi-Level Secure (for example a
module that downgrades information from one security level
to a lower one, through ?ltering or encryption) [116].
Application and middleware in a partition are to be security
evaluated at the appropriate level for that partition, and without
needing to take into account the other partitions in the system.
This separates the problem of evaluation and certi?cation, and
assures that no part of the system needs to be certi?ed at a
higher level than what is needed for the security level of the
information it is to handle.
Obviously the control of the information ?ow between the
partitions is an important part of the security in a MILS
system. The allowed information ?ow may be planned as a
directed graph [110], specifying which partitions are allowed
to exchange information in which direction. Within a single
processor the information ?ow is moderated by the SK.
In a distributed system with multiple processors involved,
the information ?ow moderation is facilitated through the
Partitioning Communication System [113] (PCS).
A vision for MILS, and one that potentially could significantly reduce the amoun
t of time spent on evaluations, is
that of a "compositional approach to assurance, evaluation and
certi?cation" [117], enabling security evaluation of a system
to be based on previous evaluations of the components that it
is composed of.
The disadvantages with the MILS architecture include the
higher memory consumption due to the partition allocated
memory areas, the less dynamic processing performance exploitation due to the ne
ed to guarantee processing resources
to all partitions, and the higher cost of context switches
due to the increased number of separate processes and due
to the sanitization operations needed. With the advances in
processors and memory devices, these disadvantages have
become less important over time.
MILS is a very promising security architecture for SDR,
offering a security-domain ?exibility that goes hand-in-hand
with the waveform application ?exibility desired for SDR.
MILS for SDR is still a work-in-progress, for example in terms
of certi?cations of components, and it will be very interesting
to follow the advances in this area.
In summary, it is challenging for an SDR system to obtain
the best possible compromise between high-assurance security
and having a computing platform that is as ?exible and
general as possible. The MILS architecture is very promising
in this context, and additionally offers cost-effective handling
of multiple security levels and a compositional approach
to certi?cation. The further availability of certi?ed MILS
components will strengthen its position.
C. Portability of Security Related Modules
As a way to achieve interoperability between secure radio
systems, for example in military coalition operations, portability of security S
W modules is a highly desired feature.
Code portability between platforms with conventional security architectures requ
ires that the APIs to the security
related devices and services are standardized. In many cases
each user domain (e.g. a nation) will be reluctant to disclose security features
and APIs, due to the fear that the
information may be useful for organizations that wish to
develop threats against the type of SDR platform. The issue
of whether security features should be disclosed or kept secret
("security by obscurity") is however a debated one. FCC
stated in a ?nal rule [118] that "manufacturers should not
intentionally make the distinctive elements that implement
that manufacturer fs particular security measures in a software
de?ned radio public...". SDR Forum in their response [119]
pointed to that "History repeatedly has shown that "security
through obscurity" often fails, typically because it precludes
a broad and rigorous review that would uncover its ?aws".
A possible way ahead is to design the security features and
the security APIs in such a way that making the security APIs
public does not increase the vulnerability of the platform.
Another potential solution is having dual security APIs, an
intra-domain API and another inter-domain API, where only
the inter-domain API is disclosed outside of its own domain.
With the current (2.2.2) [25] version of the SCA, neither the
security requirements nor the security APIs have been openly
published, making portability between different development
domains dif?cult. The ESSOR project aims at providing what
it terms a fcommon security basis to increase interoperability
between European forces as well as with the United States f
[16]. It remains to be seen though, if ESSOR will de?ne the
needed security parts for the whole of the European domain
or which part, and whether this will contribute in any way to
portability with US platforms.
MILS-type architectures are the most promising developments for providing drasti
c reductions in technical obstacles
for portability of security code. Since the MILS-speci?c
HW requirements are already present in many commercial
microprocessors, this enables different platforms to provide
compatible environments for MILS-type security code. It
should be noted though that in the case of implementationspeci?c additional bind
ings to non-standard devices this would
give similar concerns as discussed earlier.
In summary, the lack of interdomain security APIs and security feature documenta
tion is presently a major challenge and
obstacle for SDR application portability. Ongoing initiatives,
e.g. ESSOR, are likely to improve this situation by providing
complementing standards. MILS-type security architectures
have the potential of greatly reducing technical obstacles for
portability of security code, such that the dominant issue will
be that of trust between organizations and the willingness to
share crypto algorithms or having available coalition algorithms (such as the "S
uite B" initiative [120]) and security
related code. Thus MILS potentially forms an important part
of the solution for exchanging secure operational waveforms
between nations and thereby achieving multination interoperability in the battle
?eld.
VI . RE G U L ATO RY A N D CE RT I FI CAT IO N IS S U E S
In the following, certi?cation challenges with SDR equipment are reviewed. The r
emaining issues are pointed out.ULVERSOY: SOFTWARE DEFINED RADIO: CHALLENGES AND
OPPORTUNITIES 543
A. SDR Certi?cation
Traditionally, radio equipment has been approved with
the speci?c frequencies, bandwidths, modulations and with
speci?c, and ?xed, versions of functionality. This certi?cation
regime is challenged when the future application waveforms
of the equipment are not known at the time of shipment, and
it must be expected that a speci?c radio platform is updated
with new SW versions several times during its lifetime, or
even, in future systems, recon?gured dynamically according
to communications needs.
1) SDR Certi?cation in the USA: In the USA, signi?cant
steps have already been taken in changing certi?cation rules to
accommodate SDR equipment. The FCC in the USA adopted
rule changes on 13 September 2001 [96] that de?ned SDRs as
a new class of equipment. With the previous rules any changes
to output power, frequency or type of modulation implied that
a new application form and a new approval would be needed
and the equipment be re-labelled with a new identi?cation
number. With the changed rules, updates to the software that
affected the output power, frequency or type of modulation
could be handled in a more streamlined approval process
referred to as a "Class III permissive change", provided the
equipment originally had been approved as an SDR. An
important requirement introduced was that "manufacturers
must take steps to prevent unauthorized software changes".
The concept of electronic labelling of equipment was also
introduced.
The certi?cation rules were further updated on 10 March
2005 [5]. Under these rules, radio equipment that has SW
that affects the RF operating parameters, and where this SW
is designed to or expected to be modi?ed by a party other
than the manufacturer, is required to be certi?ed as an SDR.
One of the reasons for this change was a fear that third-party
SW modi?able radio equipment could otherwise be declared
non-SDR, and hence would not be required to have protection
against unauthorized software.
These updated rules also de?ne SDR radios as where
"the circumstances under which the transmitter operates in
accordance with Commission rules, can be altered by making
a change in software", which points to the conditional use
of spectrum, modulation or output power, as given in FCC
regulations.
Certi?cation is required to be carried out at FCC labs,
no self-certi?cation or certi?cation by Telecommunications
Certi?cation Bodies (TCBs) is allowed.
Further information on SDR certi?cation may be found in
[121]. A related standardization effort is IEEE 1900.3 [122].
2) SDR Certi?cation in Europe: In Europe, steps have
also been taken that allow faster certi?cation of recon?gured
radio equipment. Whereas previous processes demanded independent type approval p
rocesses in test houses, the Radio and Telecommunications Terminal Equipment Dir
ective
(R&TTE) that came into force in April 2000 in Europe allows
self-certi?cations for telecommunications equipment, yielding
faster update cycles when recon?guration of equipment is
needed [123]. Work on making speci?c adaptations to the
R&TTE directive to accommodate SDR products has been carried out by the TCAM Gro
up on SDR (TGS), where TCAM is
the Telecommunications Conformity Assessment and Market
Surveillance Committee of the European Union. A ?nal report
was presented from TGS in 2004. Based on this and further
discussion in TCAM, the European Commission has drawn
current preliminary conclusions [124]. Further conclusions
have been expected from TCAM, but as of November 2008,
none have been drawn up. It is expected that this process will
continue. It has been suggested that a speci?c harmonized
standard for SDR in Europe is to be developed [124].
The TGS report identi?es fresponsibility for the product f as
a key issue, such as when third-party SW is installed on the
equipment. The need for a more ?exible marking, e.g. digital,
is concluded. The need for safeguarding the equipment against
unauthorized SW is a discussion point, but currently, unlike in
the USA, the manufacturer is not responsible for unauthorized
code installation [124].
Further perspectives on regulatory aspects in Europe may
be found in [123]?[125].
3) Remaining Issues and Projected Evolution of SDR Regulatory Certi?cation: It i
s clear from the above that the
regulatory certi?cation aspects of SDR need to be further
matured, both in the USA and in Europe.
The FCC lab certi?cation approach in the USA is likely
to become an overwhelming task as the number of products
increase and with the product complexity and the amount of
functionality in an SDR. Even the Class III procedure for SW
updates is likely to saturate with future highly recon?gurable
equipment with a vast amount of possible SW combinations.
Self-certi?cation in the form of manufacturer Declaration
of Conformity, combined with process and organizational
certi?cation of the manufacturers to ensure their capability of
self-certi?cation, will both allow the tasks to be manageable
and give a shorter time to market.
In Europe, more ?nal conclusions on SDR certi?cation need
to be drawn and standards updated. The concept of a single
party being responsible for the equipment is likely to become
increasingly dif?cult and will need reconsideration.
In both the USA and in Europe, since future dynamic recon-
?gurable equipment is likely to have a very large number of
possible software application combinations, it is unlikely that
each and every possible combination of software components
can be tested on each and every platform type. An alternative
way is to establish trust by testing the components themselves.
A way of creating a further barrier against non-conformity
with applicable regulations is to include in each product a
mandatory regulation policy enforcement SW module that
de?nes the opportunity window of frequencies, modulations
and output power. Additionally, a policy monitor component
may be included, that monitors the spectrum from the SDR
in a periodic manner and issues alarms or closes down
transmission when a policy breach is detected (see Figure 7).
B. SCA Compliance and Domain Certi?cation
In market domains where the SCA speci?cation is used,
certi?cation of compliance to the SCA speci?cation is likely to
be a market demand, and important for application portability.
The same applies to other features that are particular to
the domain, for example domain APIs. It is a challenge to
establish such certi?cation also outside the JTRS.544 IEEE COMMUNICATIONS SURVEY
S & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010
Waveform
application
RF
Policy
enforcement
module
Policy
monitor
Data input
Policy input
Fig. 7. A way of creating a further barrier against non-conformance to
regulations: A policy enforcement module communicates to the waveform
application which regulatory policies apply at the present location and
time, e.g. which frequency range and radiated power is allowed to use. A
policy monitor periodically checks the actual generated waveform for nonconforma
nce, in which case it will instruct the Policy enforcement module to
shut down the transmitter.
JPEO states that it is the Certi?cation Authority for the
SCA, and that it will assign one or more test organizations as
the Test and Evaluation Authority [25]. An overview of the
model for certi?cation of JTRS products is provided in [126].
There is a need for architectural certi?cation authorities
also in other domains than the JTRS domain, and in other
parts of the world than the USA. For example, since it is
likely that there will be some differences between European
standards and the US one, Europe will need its own certi-
?cation facilities. Platform and waveform certi?cation needs
as de?ned in the WINTSEC project in Europe are discussed
in [57]. Referring to the view of the Finnish Software Radio Programme, a fEurope
an certi?cation network must be
operational about 2013-2014 f [127]. How this will happen
and which organizations will have the responsibility are open
issues.
VI I . OP P O RT U N I T I E S RE L AT E D TO BU S I N E S S MO D E L S
A N D MI L I TARY AND COMME R C IAL MA RK E T S
SDR provides new product and market opportunities, and
has the potential of changing the business models in the
radio communication industry. Here, these opportunities are
reviewed along with the present status in pursuing these in
the military and commercial domains, and with references to
recent publications on this subject. Lastly, projections for the
further development in this area are provided.
A. Opportunities in the Military Domain
1) SW Upgradeable and Recon?gurable Military Radio
Communications Equipment: SDR provides opportunities for
having military radio communications equipment which is SW
upgradeable and recon?gurable, possibly even ?eld recon?gurable and recon?gurabl
e in space deployment [128]. This
represents both bene?ts for users and a considerable market
opportunity for manufacturers.
Since the military domain is characterized by long-lifetime
acquisitions, while missions and technical requirements vary
at a faster scale, SW upgradability and recon?gurability is very
much in demand. Additionally, the possibility of contracting
the SW updates from third-party providers may provide more
competition and contribute to reduced lifetime-costs for the
military.
The military SDR domain in the USA is dominated by
the JTRS programme [7]?[9], [129]. JTRS has great focus
on standardization and portability, with the JPEO managing
the SCA. The ?rst production contracts for JTRS finterim f
products were awarded in June 2007 [130], these are variants
that meet some basic JTRS requirements [126] but not all
requirements as laid out in [126]. According to [131], lowrate production start
of fHandheld, Manpack and Small Form
Fit f and fGround Mobile f radios are scheduled for 2010 and
2011 respectively.
JTRS has evolved to also be a programme that delivers
tactical wireless networking [9] for the US military and thus
is an important part of the NCO transformation.
In recent reports [7], [132] the United States Government
Accountability Of?ce (GAO) raises its concern about JTRS,
pointing to the risks due to the technology challenges [7],
[132] and the cost of each unit being signi?cantly higher (up
to 10x) than the legacy units they replace [132].
In the military domain in Europe, as in the USA, there is
support for and focus on the SCA. The military domain is
dominated by several national [12], [13], [15] projects and
demonstration platform developments and cooperative [16],
[133], [134] projects. Sweden has received its ?rst vehicular
mount SCA-based GTRS units [14]. Apart from this it is
expected that major development efforts for volume products
will await the architectural outcomes of the ESSOR [134]
project.
A discussion on SDR processing in satellites is provided in
[128].
In summary, the opportunities provided by SDR in the
military domain are starting to be exploited in the form of
deployed SDR units. Some interim radio types meeting basic
JTRS requirements have been contracted and production and
deliveries have started. In Europe, several projects are ongoing. Still, taking
into consideration the challenges discussed
elsewhere in this paper and the concerns raised by GAO, the
pace where ?xed military radios are replaced by SCA-certi?ed
high-?exibility SDR ones is expected to be slow in the next
few years.
2) Waveform Library: SDR also provides a possibility for
building up libraries of waveform applications. In this way,
SDR platforms may be loaded with the speci?c applications
needed in the scenarios and operations they are to be deployed
in. Libraries can be national ones or coalitional ones. Library
waveforms represent market opportunities for SW companies,
as well as units that will be tradable between organizations.
JTRS is building up a repository of waveform applications
for porting onto the various platforms. In 2006 it was reported
that JTRS code had accumulated to 3.5 million lines with
Government Purpose Rights [8].
In Europe the political and business issues of building
up a waveform inventory are dif?cult, as manufacturers in
some cases are the owners of the waveforms and as there
are also many national interests. NATO fs Industry Advisory
Group (NIAG) has investigated "the dynamics and Business
Models behind Industrial Contribution of Waveform Standards
and how these may and could change with the advent of
SDR technology" [133]. NIAG has issued its report but it is
unfortunately not publicly available.ULVERSOY: SOFTWARE DEFINED RADIO: CHALLENGE
S AND OPPORTUNITIES 545
Availability of advanced communication waveforms for
exchange of video and data in coalitions is a critical issue,
which is hampered both by the above-mentioned political and
business issues and due to the JTRS ones being classi?ed
as "US ONLY" [131]. A way of getting round such political
and business issues for coalition waveforms is to develop new
waveforms through collaborative contributions from nations.
COALWNW is an example of such a multinational cooperative
effort [131].
Due to the reasons presented and discussed in Section III,
porting efforts are likely to be required for putting library
software onto a speci?c platform.
It is projected that the trend towards building up libraries
of waveform applications for national and coalitional use will
remain an active one, and that this will be a growing market
opportunity for third-party SW companies.
3) Military Cognitive Radio: SDR, as a base implementation technology, provides
opportunities for providing the
future military versions of Cognitive Radio (CR).
Cognitive radio in the military domain is a highly active
research ?eld, that generates considerable interest both as a
means for recon?guring waveforms according to sensed electromagnetic conditions,
and as a means to provide increased
spectrum utilization through dynamic use of spectrum [135].
It is also foreseen that as more and more radios in battle?eld
environments will have cognition, and as the cognitive abilities
are likely to be used for both offensive and defensive purposes,
cognitive abilities in military radio equipment will become
mandatory. CR will thus be another major driver for the
transition to SDR in the military domain.
The literature on CR and potential use of SDR for CR
purposes is overwhelming, a few recommended sources of
information are [135]?[140].
It is expected that the replacement of military radio systems with smarter CR on
es will represent a continued SDR
opportunity for many years forward.
B. Opportunities in the Commercial Domain
1) Multiprotocol Multiband Base Stations: SDR provides
an opportunity to switch from conventionally designed cellular
base stations to Software De?ned Multi-Protocol Multi-Band
(MPMB) base stations [58].
The recon?guration possibilities provided by SDR MPMBs
accommodate future cellular base station needs, for example:
? the possibility to dynamically add services
? the rapid introduction of new communications standards
[141]
? the trend that new communications standards are put into
service in a less mature state than previous standards,
implying an increased risk of post-deployment changes
needed [141]
? context-related recon?gurability and the accommodation
of the future cognitive terminals [125], [142]
SDR MPMBs also allow standardization of hardware platforms, which reduces the am
ount of capital tied up in hardware
inventory. Since the total lifetime cost of the system is more
important than the initial cost, the SDR solution may be
preferred even if the initial cost of the SDR platform is higher.
Also with base stations, increased power consumption over a
conventional design can be tolerated.
At present, cellular base stations are dominated by the
traditional non-SDR ones. The VANU [18] base stations, as
well as some recent announcements from Huawei [143] and
ZTE [144], are SDR examples.
Further background on SDR base station opportunities is
provided in [58], [142].
The share of SDR base stations compared to the overall
number is predicted to grow signi?cantly from 2010, to
become an approximate equal share of the overall number
of base stations in 2016 and continue rising [145].
2) Mobile Multi-standard Terminals: Mobile Multistandard Terminals (MMTs) repres
ent another large market
opportunity for SDR. As the number of standards needing
to be served [141] by the MMT grows, SDR will at some
point provide a cost advantage relative to a conventionally
designed MMT. Further it provides opportunities for future
mobile wireless users to change and personalize their units
by installing additional pieces of waveform software, and
upgrade their units as new standards emerge or as standards
are updated. More importantly, with the future recon?gurable
and cognitive radio networks it will be a necessity for the
units to be able to add waveform applications or components
dynamically.
MMTs are still almost exclusively using traditional nonSDR designs, utilizing wa
veform standard speci?c integrated
HW [58] even if the terminals serve a high number of
waveform standards (e.g. GSM, EDGE, W-CDMA, HSDPA,
Bluetooth, WiFi). A multi-mode mobile phone with fsoftwarede?ned modem f processing
up to 2.8 Mbps has been demoed
[146]. This is possibly an important milestone in the SDR
direction. Technical details about its SW ?exibility and powerconsumption are ho
wever unknown.
MMTs presently are also characterized by a relatively small
amount of dominant manufacturers having a high degree
of vertical integration and proprietary solutions, e.g. being
responsible both for the hardware platform and the waveform
software, and which have an interest in maintaining this
business model. There are, however, some signs of interfaces
being opened up and value chain restructuring. An obvious
observation is the trend of employing third-party operating
systems (e.g. the Symbian OS) allowing third-party user
applications to be loaded. This has an effect in making end
users accustomed to adding SW applications to their units.
So far, the user demand for ?eld upgrading waveform
application software on mobile handsets has been limited,
simply due to the fact that the handsets are frequently replaced
(the fhandset replacement f model [58], since the market is currently driven also b
y a lot of other factors than the waveform
standards, e.g. improved platform devices such as cameras
and displays. Several authors, however, predict a change to
the fhandset service upgrade f [58] and fpersonalization f [147]
model where a fnaked handset f [58] is uploaded to suit the
user fs needs.
The mainstream MMT evolution into SDR-based design is
dependent on several factors, the most important being power
consumption and cost, with the cost trade-off being highly
dependent on the number of waveform standards that the546 IEEE COMMUNICATIONS SU
RVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010
terminal is intended to serve. Due to these factors being more
signi?cant for MMTs than for base stations, the MMTs are
predicted to come after the base station development in the
transition to SDR design. However, since the MMT market
has high price pressure, this implies that as soon as the SDR
approach gives a cost advantage, and assuming acceptable
power consumption, there will be a very signi?cant drive in
this direction.
3) Cognitive Radio: The projected evolution into CR capable MPMBs and MMTs repre
sents a large future market
opportunity and driver for SDR technology.
CRs may both provide context-aware services for the user
[148] and improve spectrum utilization through dynamic spectrum access [135], [1
37], [149]. In order to continuously take
advantage of spectrum opportunities and adapt to the speci?c
context, CR requires platforms that have fast dynamic recon-
?guration abilities. Recommended sources of information on
CR and the application of SDR in CR systems are [136], [138].
While the ?rst commercial-domain CR standard is already
drafted [150], more advanced CRs are viewed as being further
into the future.
4) Other Commercial Domain Opportunities: Commercial
Satellite Communications has already been mentioned as a
segment that will bene?t from SDR, where SDR enables
remote upgrades and possibly multiple uses during the lifetime of a satellite [1
7]. Equipment to be located in remote
and poorly accessible locations on earth is another similar
opportunity.
The Femtocell or Home Base Station has been put forward
as another market segment with great opportunities for SDR
[58], [151]. The recon?gurability and ?exibility provided
by SDR support the multiple bands, multiple standards and
simultaneous fsnif?ng f functionality needed in the Femtocells
[151]. Other mentioned market opportunities include devices
for laptops, automobiles, home entertainment and the medical
and public safety segments [58].
VI I I . CO N C L U S I O N S
Although SDR technology has evolved more slowly than
anticipated some years ago, there are now many positive
signs, the clearest ones being in the form of SDR products
entering the market. Several major initiatives, at national and
cooperative levels between nations and the industry are paving
the way for SDR.
The increasing availability of SCA SW tools and development platforms is contrib
uting to reducing the learning threshold of the SCA and also increase the produc
tivity of SDR
development. Developments within Model Driven Design may
further increase this productivity.
The SCA eases portability by providing a standard for
deploying and managing applications. Even so the portability
of SCA-based applications between different platforms is not
straightforward. One major issue is the standardization of
the APIs between the application and the system devices
and services. Although a subset of the needed APIs have
been published on the JTRS website, parts of the APIs will
be dif?cult to standardize across domains, for example the
security-related APIs. Another major issue is the instruction
code compatibility between different processing elements,
which at present requires porting efforts in terms of rewriting
code to ?t the processing elements of the target platform. It
is expected in the long term that design in higher abstraction
languages will reduce this type of porting effort.
Alternatives to the SCA include OMG fs speci?cation,
NASA fs STRS architecture and the GNU Radio architecture. MOM-based architectures
have a potential of becoming
alternatives, but the maturity and the acceptance of these
speci?cations have to be demonstrated. For cognitive radio
systems, additions to the SCA, such as middleware that
supports adaptation, will be bene?cial. Such middleware will
increase productivity and standardize solutions when making
adaptive and cognitive systems.
It is expected that the SCA will remain the dominating
architecture in the military sector where waveform application
portability and reuse are major priorities, especially through
cooperative programmes. On the other hand, a signi?cant
portion of designs for the civilian commercial market, where
hardware cost is a major factor, are likely to utilize dedicated and proprietary
lighter-weight architectures. In a longer
(?10 years) perspective, and as hardware cost progressively
becomes a smaller part of the total system cost, standardized
open architectures are likely to become more popular also on
the civilian commercial market.
A fundamental challenge for SDR designs is that of providing suf?cient computati
onal performance for the signal
processing tasks and within the relevant size weight and
power requirements. This is particularly challenging for small
handheld units, and for ubiquitous units. Parallel computation
enhancements and the rapid evolvement of DSP and FPGA
performance help to provide this computational performance.
Processing units having multiple SIMD processing elements
appear to be very promising for low-power SDR units. Also,
as waveforms typically have many common functions, it
may be sensible to make parameterized, optimal low-powerconsumption dedicated ha
rdware blocks for these common
functions, and run alternative source code on a more general
processing element if they do not exist.
The recon?gurability of SDR systems has security challenges as a side effect. On
e such security challenge is that the
system must be protected from loading unauthorized and/or
malicious code. Also, the rigidity of conventional security
architectures in many ways contrast the desired ?exibility and
portability ideally required for SDR. The MILS architecture
provides for larger ?exibility and easier portability of security
related modules, while offering multiple security-levels without the need for mu
ltiple sets of HW.
SDR has forced regulators to rethink the certi?cation of
radio equipment. While traditional equipment has a ?xed
number of functional modes and a more or less ?xed design
that may be fully characterized, SDRs may be SW loaded
to function in a large variety of modes and hence may not
be tested in every possible mode at the time of the initial
certi?cation. Changes in certi?cation rules to deal with SDRs
have taken place, but it is likely that as more SDR products
approach the market, there will be a further evolvement of
these rules.
The multitude of waveform standards and their rapid
progress make it bene?cial and economical to be able toULVERSOY: SOFTWARE DEFINE
D RADIO: CHALLENGES AND OPPORTUNITIES 547
easily update wireless network infrastructure equipment, such
as cellular base stations. Also, base stations are less sensitive
to the power consumption of the SDR processing platforms
than the mobile devices. Thus SDR has promising potential
in commercial wireless network infrastructure equipment.
SDR has the potential to increase the productivity of radio
communication development and lower the lifecycle costs of
radio communication. This will partly come through a change
in the business models in the radio communication industry,
allowing a separation into SDR platform providers and thirdparty SW providers. T
his again will provide volume bene?ts
for the platforms and lower the threshold for companies
entering the market as SW providers, and hence provide
further competition in the SDR SW applications area.
SDR will have continued focus as a highly ?exible platform
to meet the demands from military organizations facing the
requirements from network centric and coalitional operations.
SDR will also have continued focus as a convenient platform
for future cognitive radio networks, enabling more information
capacity for a given amount of spectrum and have the ability
to adapt on-demand to waveform standards.
ACK N OW L E D G M E N T
The author would like to thank Christian Serra at Thales
Communications, Marc Adrat at FGAN (the Research Establishment for Applied Scien
ce), Jon Olavsson Neset and
Stewart Clark at NTNU (Norwegian University of Science
and Technology), Audun Josang at UniK (University Graduate
Center at Kjeller), Frank Eliassen at UiO (University of
Oslo) and Torleiv Maseng, Tor Gjertsen, Asgeir Nysater and
Synnove Eifring at FFI (the Norwegian Defence Research
Establishment) for their valuable input and advice. The author
would also like to thank the anonymous reviewers for their
helpful comments.
RE F E R E N C E S
[1] J. Mitola III, gSoftware radios - survey, critical evaluation and future
directions, h in Telesyst. Conf., 1992. NTC-92., National, May 1992, pp.
13/15?13/23.
[2] W. Tuttlebee, Software De?ned Radio: Enabling Technologies. Chichester: Wile
y, 2002.
[3] P. B. Kenington, RF and Baseband Techniques for Software De?ned
Radio. Boston: Artech House, 2005.
[4] Software De?ned Radio Forum. (2007, Oct) SDR Forum. [Online].
Available: http://www.sdrforum.org
[5] Federal Communications Commission, gIn the matter of facilitating
opportunities for ?exible, ef?cient, and reliable spectrum use employing cogniti
ve radio technologies, report and order, h Mar. 2005, FCC
05-57, ET Docket No. 03-108.
[6] P. G. Cook and W. Bonser, gArchitectural overview of the SPEAKeasy
system, h Sel. Areas Commun., IEEE J., vol. 17, no. 4, pp. 650?661,
1999.
[7] United States Government Accountability Of?ce, gRestructured JTRS
Program Reduces Risk, but Signi?cant Challenges Remain, h Sept.
2006.
[8] D. R. Stephens, B. Salisbury, and K. Richardson, gJTRS infrastructure
architecture and standards, h in Military Commun. Conf., 2006.MILCOM 2006, Oct. 20
06, pp. 1?5.
[9] R. North, N. Browne, and L. Schiavone, gJoint tactical radio system -
connecting the GIG to the tactical edge, h in Military Commun. Conf.,
2006.MILCOM 2006, Oct. 2006, pp. 1?6.
[10] G. Gailliard, E. Nicollet, M. Sarlotte, and F. Verdier, gTransaction
level modelling of SCA compliant software de?ned radio waveforms
and platforms PIM/PSM, h in Design, Automation Test Europe Conf.
Exhibition, 2007. f07, Apr. 2007, pp. 1?6.
[11] C. Serra, B. Sourdillat, and E. Nicollet, gSDR key factors - advanced
studies & results related to the implementations of the SCA, h in
2006 Software De?ned Radio Technical Conf. Product Exposition, Nov.
2006.
[12] H. S. Kenyon. (2007, Sept.) Spanish Research Platform Ready For Service. [O
nline].
Available: http://www.afcea.org/signal/articles/templates\\/SIGNAL\
_Article\_Template.asp?articleid=1383\&zoneid=47
[13] T. Tuukkanen, A. Pouttu, and P. Lepp?anen. (2007,
June) Finnish Software Radio Programme. [Online]. Available: http://www.mil.?/pa
aesikunta/materiaaliosasto/liitteet\\/?nnish\
_software\_radio\_programme.pdf
[14] Swedish Defence Materiel Organization. (2008, Apr.) A
New Generation Radio. [Online]. Available: http://www.fmv.se/
WmTemplates/news.aspx?id=4104
[15] A. Baddeley. (2006, May) Sweden Seeks Military Commun. Flexibility.
[Online]. Available: http://www.afcea.org/signal/articles/templates/\\
SIGNAL\_Article\_Template.asp?articleid=1129\&zoneid=7
[16] European Defence Agency, gBackground on Software De?ned Radio, h
Nov. 2007.
[17] F. Daneshgaran and M. Laddomada, gTransceiver front-end technology
for software radio implementation of wideband satellite communication
systems, h Wireless Personal Commun., vol. 24, no. 2, pp. 99?121, 2003.
[18] V. Inc. (2007) Vanu fs Software Radio... [Online]. Available:
http://www.vanu.com
[19] R. H. Walden, gAnalog-to-digital converter survey and analysis, h Sel.
Areas Commun., IEEE J., vol. 17, no. 4, pp. 539?550, Apr. 1999.
[20] J. Mitola, V. Bose, B. M. Leiner, T. Turletti, and D. Tennenhouse,
gSpecial issue on software radio, h Sel. Areas Commun., IEEE J.,
vol. 17, no. 4, Apr. 1999.
[21] A. A. Abidi, gThe path to the software-de?ned radio receiver, h SolidState Cir
cuits, IEEE J., vol. 42, no. 5, pp. 954?966, 2007.
[22] M. Laddomada, F. Daneshgaran, M. Mondin, and R. M. Hickling,
gA pc-based software receiver using a novel front-end technology, h
Commun. Mag., IEEE, vol. 39, no. 8, pp. 136?145, Aug. 2001.
[23] E. Buracchini, gThe software radio concept, h Commun. Mag., IEEE,
vol. 38, no. 9, pp. 138?143, Sept. 2000.
[24] M. Laddomada, gGeneralized comb decimation ?lters for sigma-delta
A/D converters: Analysis and design, h Circuits Systems I: Regular
Papers, IEEE Trans., vol. 54, no. 5, pp. 994?1005, May 2007.
[25] (JTRS), JTRS Standards Joint Program Executive Of?ce (JPEO) Joint
Tactical Radio System, gSoftware Communication architecture speci-
?cation, h May 2007.
[26] JTRS Standards Joint Program Executive Of?ce (JPEO) Joint
Tactical Radio System (JTRS). (2007, Sep) Software Commun.
Architecture SCA Document Downloads. [Online]. Available: http:
//sca.jpeojtrs.mil/downloads.asp?ID=2.2.2
[27] Object Management Group Inc. (2007, Sept.) The Software-Based
Communication (SBC) Domain Task Force (DTF). [Online]. Available:
http://sbc.omg.org
[28] E. Nicollet, gThe transceiver facility platform independent model
(PIM): De?nition, content and usage, h in 2006 Software De?ned Radio
Technical Conf. Product Exposition, Nov. 2006.
[29] Vecima Networks Inc. (2007) Spectrum Signal Processing. [Online].
Available: http://www.spectrumsignal.com
[30] F. Humcke, gMaking FPGAs g?rst class h SCA citizens, h in 2006
Software De?ned Radio Technical Conf. Product Exposition, Nov.
2006.
[31] C. McHale. (2007, Feb.) Corba explained simply. [Online]. Available:
http://www.ciaranmchale.com/
[32] C. Magsombol, C. Jimenez, and D. R. Stephens, gJoint tactical radio
system - application programming interfaces, h in Military Commun.
Conf., 2007.MILCOM 2007.IEEE, Oct. 2007, pp. 1?7.
[33] A. Blair, T. Brown, J. Cromwell, S. Kim, and R. Milne, gPorting
lessons learned from soldier radio waveform (SRW), h in Military
Commun. Conf., 2007.MILCOM 2007.IEEE, Oct. 2007, pp. 1?6.
[34] S. Bernier and J. P. Z. Zapata, gThe deployment of software components into
heterogeneous SCA platforms, h in SDR f08 Technical Conf.
Product Exposition, Oct. 2008.
[35] T. Kempf, E. M. Witte, V. Ramakrishnan, G. Ascheid, M. Adrat,
and M. Antweiler, gA practical view on SDR baseband processing
portability, h in SDR f08 Technical Conf. Product Exposition, Oct. 2008.
[36] Y. Zhang, S. Dyer, and N. Bulat, gStrategies and insights into SCAcompliant
waveform application development, h in Military Commun.
Conf., 2006.MILCOM 2006.IEEE, Oct. 2006, pp. 1?7.
[37] Zeligsoft Inc. (2007) Zeligsoft. [Online]. Available: http://www.
zeligsoft.com548 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH
QUARTER 2010
[38] PrismTech. (2007) PrismTech Productivity Tools and Middleware.
[Online]. Available: http://www.prismtech.com/
[39] Commun. Research Canada. (2008, Aug.) SCARI Software Suite.
[Online]. Available: http://www.crc.gc.ca/en/html/crc/home/research/
satcom/rars/sdr\\/products/scari\_suite/scari\_suite
[40] VirginiaTech. (2007, Dec.) OSSIE development site for softwarede?ned radio.
[Online]. Available: http://ossie.wireless.vt.edu/trac
[41] S.-P. Lee, M. Hermeling, and C.-M. Poh, gExperience report: Rapid
model-driven waveform development with UML, h in SDR f08 Technical
Conf. Product Exposition, Oct. 2008.
[42] B. Hailpern and P. Tarr, gModel-driven development: The good, the
bad, and the ugly, h IBM Systems J., vol. 45, no. 3, pp. 451?461, July
2006.
[43] Z. Jianfan, D. Levy, and A. Liu, gEvaluating overhead and predictability of
a real-time CORBA system, h in Proc. 37th Annual Hawaii
International Conf. Syst. Sciences - 2004, Jan. 2004, p. 8.
[44] F. Casalino, G. Middioni, and D. Paniscotti, gExperience report on the
use of CORBA as the sole middleware solution in SCA-based SDR
environments, h in SDR f08 Technical Conf. Product Exposition, Oct.
2008.
[45] J. Kim, S. Hyeon, and S. Choi, gDesign and implementation of
high-speed data transfer protocol in CORBA enviroment, h in SDR f08
Technical Conf. Product Exposition, Oct. 2008.
[46] A. S. Gokhale and D. C. Schmidt, gEvaluating CORBA latency and
scalability over high-speed ATM networks, h in Distributed Comput.
Syst., 1997., Proc. 17th International Conf. , 1997, pp. 401?410.
[47] J. Bertrand, J. W. Cruz, B. Majkrzak, and T. Rossano, gCORBA delays
in a software-de?ned radio, h IEEE Commun. Mag., vol. 40, no. 2, pp.
152?155, Feb. 2002.
[48] T. Ulversoy and J. O. Neset, gOn workload in an SCA-based system,
with varying component and data packet sizes, h in RTO-MP-IST-083
Military Commun. Special Focus Tactical Commun. Netw. Centric
Operations, Apr. 2008.
[49] P. J. Balister, C. Dietrich, and J. H. Reed, gMemory usage of a
software communication architecture waveform, h in 2007 Software
De?ned Radio Technical Conf. Product Exposition, Nov. 2007.
[50] D. Paniscotti and J. Bickle, gSDR signal processing distributivedevelopment
approaches, h in 2007 Software De?ned Radio Technical
Conf. Product Exposition, Nov. 2007.
[51] D. R. Stephens, C. Magsombol, and C. Jimenez, gDesign patterns of
the JTRS infrastructure, h in Military Commun. Conf., 2007.MILCOM
2007.IEEE, 2007, pp. 1?5.
[52] C. Lee, J. Kim, S. Hyeon, and S. Choi, gFPGA design to support
a Corba component, h in SDR f08 Technical Conf. Product Exposition,
Oct. 2008.
[53] D. Vassilopoulos, T. Pilioura, and A. Tsalgatidou, gDistributed technologies
CORBA, Enterprise JavaBeans, Web services: A comparative presentation, h in Paral
lel, Distributed, Netw.-Based Process.,
2006.PDP 2006.14th Euromicro International Conf. , Feb. 2006, p. 5.
[54] Object Management Group Inc. (2006, Oct) The Object Management
Group (OMG). [Online]. Available: http://www.omg.org
[55] Q. H. Mahmoud, Middleware for Communication. Chichester: Wiley,
2004.
[56] OMG. (2007, Mar.) Documents associated with PIM and PSM
for software radio components (SDRP), v 1.0. [Online]. Available:
http://www.omg.org/spec/SDRP/1.0/
[57] S. Nagel, V. Blaschke, J. Elsner, F. K. Jondral, and D. Symeonidis,
gCerti?cation of SDRs in new public and governmental security
systems, h in SDR f08 Technical Conf. Product Exposition, Oct. 2008.
[58] A. Kaul, gSoftware de?ned radio: The transition from defense to
commercial markets, h in 2007 Software De?ned Radio Technical Conf.
Product Exposition, Nov. 2007.
[59] T. Quinn and T. Kacpura, gStrategic adaptation of SCA for STRS, h
in 2006 Software De?ned Radio Technical Conf. Product Exposition,
Nov. 2006.
[60] T. J. Kacpura, L. M. Handler, J. C. Briones, and C. S. Hall, gUpdates
to the NASA space teleCommun. radio system (STRS) architecture, h
in 2007 Software De?ned Radio Technical Conf. Product Exposition,
Nov. 2007.
[61] J. C. Briones, L. M. Handler, C. S. Hall, R. C. Reinhart, and T. J.
Kacpura, gCase study: Using the OMG SWRadio pro?le and SDR
Forum input for NASA fs space teleCommun. radio system, h in SDR f08
Technical Conf. Product Exposition, Oct. 2008.
[62] S. B. Raghunandan, D. Kumaraswamy, L. Le, C. B. Dietrich, and J. H.
Reed, gOpen space radio: An open source implementation of STRS
1.01, h in SDR f08 Technical Conf. Product Exposition, Oct. 2008.
[63] Free Software Foundation Inc. (2007, Mar) GNU Radio - The GNU
Software Radio. [Online]. Available: http://www.gnu.org/software/
gnuradio/index.html
[64] G. Abgrall, F. L. Roy, J.-P. Delahaye, J.-P. Diguet, and G. Gogniat, gA
comparative study of two software de?ned radio platforms, h in SDR f08
Technical Conf. Product Exposition, Oct. 2008.
[65] E. Gjorven, F. Eliassen, K. Lund, V. S. W. Eide, and R. Staehli, gSelfadapti
ve systems: A middleware managed approach, h Self-Managed
Netw., Syst., Services, Proc., vol. 3996, pp. 15?27, 2006.
[66] A. P. Vinod and E. M. K. Lai, gLow power and high-speed implementation of FI
R ?lters for software de?ned radio receivers, h Wireless
Commun., IEEE Trans., vol. 5, no. 7, pp. 1669?1675, 2006.
[67] L. Yuan, L. Hyunseok, M. Woh, Y. Harel, S. Mahlke, T. Mudge,
C. Chakrabarti, and K. Flautner, gSODA: A low-power architecture
for software radio, h in Comput. Architecture, 2006.ISCA f06.33rd
International Symp., 2006, pp. 89?101.
[68] John L. Shanton III and H. Wang, gDesign considerations for size,
weight and power (SWAP) constrained radios, h in 2006 Software
De?ned Radio Technical Conf. Product Exposition, Nov. 2006.
[69] B. Jerker and V. Seppo, gConvergence of hardware and software in
platforms for radio technologies, h Commun. Mag., IEEE, vol. 44,
no. 11, pp. 52?57, 2006.
[70] Texas Instruments Incorporated. (2008, Oct) Texas Instruments.
[Online]. Available: http://www.ti.com
[71] D. Lau, J. Blackburn, and C. Jenkins, gUsing c-to-hardware acceleration in F
PGAs for waveform baseband processing, h in 2006 Software
De?ned Radio Technical Conf. Product Exposition, Nov. 2006.
[72] S. Srikanteswara, R. C. Palat, J. H. Reed, and P. Athanas, gAn overview
of con?gurable computing machines for software radio handsets, h
Commun. Mag., IEEE, vol. 41, no. 7, pp. 134?141, 2003.
[73] D. Efstathiou, L. Fridman, and Z. Zvonar, gRecent developments in
enabling technologies for software de?ned radio, h Commun. Mag.,
IEEE, vol. 37, no. 8, pp. 112?117, Aug. 1999.
[74] J. A. Kahle, M. N. Day, H. P. Hofstee, C. R. Johns, T. R. Maeurer, and
D. Shippy, gIntroduction to the Cell microprocessor, h IBM J. Research
Development, vol. 49, no. 4/5, pp. 589?604, Sept. 2005. [Online].
Available: http://www.research.ibm.com/journal/rd/494/kahle.pdf
[75] (2007, Oct.) The Cell project at IBM Research, The Cell Chip.
[Online]. Available: http://www.research.ibm.com/cell/cell\_chip.html
[76] J. Pille, C. Adams, T. Christensen, S. Cottier, S. Ehrenreich, T. Kono,
D. Nelson, O. Takahashi, S. Tokito, O. Torreiter, O. Wagner, and
D. Wendel, gImplementation of the CELL broadband engine in a
65nm SOI technology featuring dual-supply SRAM arrays supporting
6GHz at 1.3V, h in Solid-State Circuits Conf., 2007.ISSCC 2007. Digest
Technical Papers. IEEE International, 2007, pp. 322?606.
[77] O. Takahashi, C. Adams, D. Ault, E. Behnen, O. Chiang, S. R. Cottier,
P. Coulman, J. Culp, G. Gervais, M. S. Gray, Y. Itaka, C. J. Johnson,
F. Kono, L. Maurice, K. W. McCullen, L. Nguyen, Y. Nishino, H. Noro,
J. Pille, M. Riley, M. Shen, C. Takano, S. Tokito, T. Wagner, and
H. Yoshihara, gMigration of cell broadband engine from 65nm SOI
to 45nm SOI, h in Solid-State Circuits Conf., 2008.ISSCC 2008. Digest
Technical Papers. IEEE International, 2008, pp. 86?597.
[78] P. Westermann, G. Beier, H. it Harma, and L. Schwoerer, gPerformance
analysis of W-CDMA algorithms on a vector DSP, h in Circuits Syst.
Commun., 2008.ECCSC 2008.4th European Conf., 2008, pp. 307?311.
[79] K. van Berkel, F. Heinle, P. P. E. Meuwissen, K. Moerman, and
M. Weiss, gVector processing as an enabler for software-de?ned radio
in handheld devices, h EURASIP J. Applied Signal Process., vol. 2005,
no. 16, pp. 2613?2625, 2005.
[80] J. Glossner, D. Iancu, M. Moudgill, G. Nacer, S. Jinturkar, S. Stanley,
and M. Schulte, gThe Sandbridge SB3011 platform, h EURASIP J.
Embedded Syst., vol. 2007? 2007.
[81] ICERA. (2008) Livantoc chipsets. [Online]. Available: http:
//www.icerasemi.com/livanto-chipsets.php
[82] M. Woh, S. Seo, H. Lee, Y. Lin, S. Mahlke, T. Mudge, C. Chakrabarti,
and K. Flautner, Embedded Computer Systems: Architectures,
Modeling, and Simulation. Springer Berlin / Heidelberg, 2007, ch. The
Next Generation Challenge for Software De?ned Radio, pp. 343?354.
[Online]. Available: http://dx.doi.org/10.1007/978-3-540-73625-7\_36
[83] M. D. McCool, gSignal processing and general-purpose computing and
GPUs, h Signal Process. Mag., IEEE, vol. 24, no. 3, pp. 110?115, 2007.
[84] F. Stefani, A. Moschitta, D. Macii, and D. Petri, gFFT Benchmarking
for Digital Signal Processing Technologies, h University of Trento,
Department Inf. Commun. Technol., Technical Rep., Mar. 2004.
[85] BDTI. (2008) BDTI - Insight, Analysis, and Advice on Signal
Processing Technology. [Online]. Available: http://www.bdti.com/ULVERSOY: SOFTWA
RE DEFINED RADIO: CHALLENGES AND OPPORTUNITIES 549
[86] H. Harada, gSoftware de?ned radio prototype for W-CDMA and
IEEE802.11a wireless LAN, h in Veh. Technol. Conf., 2004.VTC2004-
Fall.2004 IEEE 60th, vol. 6, Sept. 2004, pp. 3919?3924.
[87] J. Neel, S. Srikanteswara, J. H. Reed, and P. M. Athanas, gA comparative stu
dy of the suitability of a custom computing machine and
a VLIW DSP for use in 3G applications, h in Signal Process. Syst.,
2004.SIPS 2004.IEEE Workshop, Oct. 2004, pp. 188?193.
[88] S. Rajagopal and J. R. Cavallaro. (2005, Jul) Communication
Processors. [Online]. Available: http://hdl.handle.net/1911/20241
[89] GSM Association. (2008) Gsm world. [Online]. Available: http:
//www.gsmworld.com
[90] K. Keutzer, gDigital Signal Processors: A TI Architectural History, h
2000. [Online]. Available: http://bwrc.eecs.berkeley.edu/classes/cs252/
Notes/Lec10a-DSP1.ppt
[91] M. Etel?aper?a and J.-P. Soininen, g4G Mobile Terminal Architectures, h
Technical Research Centre of Finland (VTT), Technical Rep., Sep
2007. [Online]. Available: rooster.oulu.?/materiaalit/4G\%20terminal\
%20architectures.pdf
[92] D. Babb, C. Bishop, and T. E. Dodgson, gSecurity issues for downloaded code
in mobile phones, h Electronics Commun. Eng. J., vol. 14,
no. 5, pp. 219?227, Oct. 2002.
[93] M. Cummings and S. Heath, gMode switching and software download
for software de?ned radio: the SDR Forum approach, h Commun. Mag.,
IEEE, vol. 37, no. 8, pp. 104?106, Aug. 1999.
[94] M. Laddomada, gRecon?guration issues of future mobile software
radio platforms, h Wireless Commun. Mobile Comput., vol. 2, no. 8,
pp. 815?826, Dec. 2002.
[95] E. Gallery and C. Mitchell, gTrusted computing technologies and
their use in the provision of high assurance SDR platforms, h in 2006
Software De?ned Radio Technical Conf. Product Exposition, Nov.
2006.
[96] Federal Commun. Commission, gIn the matter of Authorization and
Use of Software De?ned Radios, First Report and Order, h Sept. 2001,
FCC 01-264, ET Docket No. 00-47.
[97] R. Falk, F. Haettel, U. L Pucking, and E. Mohyeldin, gAuthorization of
SDR software using common security technology, h in 2005 Software
De?ned Radio Technical Conf. Product Exposition, Nov. 2005.
[98] L. B. Michael, M. J. Mihaljevic, S. Haruyama, and R. Kohno, gA
framework for secure download for software-de?ned radio, h Commun.
Mag., IEEE, vol. 40, no. 7, pp. 88?96, 2002.
[99] R. Falk, P. Bender, N. J. Drew, and J. Faroughi-Esfahani, gConformance and s
ecurity challenges for personal communication in the recon?gurable era, h in 3G Mo
bile Commun. Technol., 2003.3G 2003.4th
International Conf. (Conf.Publ.No.494), 2003, pp. 7?12.
[100] H. Shiba, K. Uehara, and K. Araki, gProposal and evaluation of security
schemes for software-de?ned radio, h in Personal, Indoor Mobile Radio
Commun., 2003.PIMRC 2003.14th IEEE Proc., vol. 1, 2003, pp. 114?
118.
[101] M. Kurdziel, J. Beane, and J. J. Fitton, gAn SCA security supplement
compliant radio architecture, h in Military Commun. Conf., 2005.MILCOM 2005.IEEE,
Oct. 2005, pp. 2244?2250.
[102] W. T. Scott, A. C. Houle, and A. Martin, gInformation assurance issues
for an SDR operating in a manet network, h in 2006 Software De?ned
Radio Technical Conf. Product Exposition, Nov. 2006.
[103] D. S. Dawoud, gA proposal for secure software download in SDR, h in
AFRICON, 2004.7th AFRICON Conf. Africa, Sept. 2004, pp. 77?82.
[104] R. Falk and M. Dillinger, gApproaches for secure SDR software
download, h in 2004 Software De?ned Radio Technical Conf. Product
Exposition, Nov. 2004.
[105] M. J. Mihaljevic and R. Kohno, gOn a framework for employment
of cryptographic components in software de?ned radio, h in Wireless
Personal Multimedia Commun., 2002. 5th International Symp., vol. 2,
Oct. 2002, pp. 835?839.
[106] C. Y. Yeun and T. Farnham, gSecure software download for programmable mobil
e user equipment, h in 3G Mobile Commun. Technol.,
2002.Third International Conf. (Conf.Publ.No.489), May 2002, pp.
505?510.
[107] C. Jenkins and C. Plante, gMilitary anti-tampering solutions using
programmable logic, h in 2006 Software De?ned Radio Technical Conf.
Product Exposition, Nov. 2006.
[108] TCG. (2007) Trusted Computing Group. [Online]. Available:
https://www.trustedcomputinggroup.org/home
[109] C. Mitchell, Trusted Computing, London: Institution of Electrical
Engineers, 2005.
[110] J. Alves-Foss, C. Taylor, and P. Oman, gA multi-layered approach
to security in high assurance systems, h in Proc. 37th Annual Hawaii
International Conf. Syst. Sciences (HICSS f04) - Track 9, 2004., vol. 9,
Jan. 2004.
[111] B. Randell and J. Rushby, gDistributed secure systems: Then and now, h
in 2007 Annual Computer Security Appl. Conf. (ACSAC 23), Dec. 2007.
[112] J. Rushby, gDesign and veri?cation of secure systems, h in Proc. Eighth
Symp. Operating Syst. Principles, Dec. 1981.
[113] C. Taylor, gMILS, multiple independent levels of security: A
high assurance architecture, h May 2006. [Online]. Available: http:
//cisr.nps.navy.mil/guests/taylor06.html
[114] (2007) Common Criteria portal, The of?cial website of the Common
Criteria Project. [Online]. Available: http://www.commoncriteriaportal.
org/
[115] Green Hills Software Inc. (2008, Nov) Green Hills Software
Announces World fs First EAL6+ Operating System Security
Certi?cation. [Online]. Available: http://www.ghs.com/news/20081117\
_integrity\_EAL6plus\_security.html
[116] J. Alves-Foss, P. W. Oman, C. Taylor, and W. S. Harrison, gThe MILS
architecture for high-assurance embedded systems, h International J.
Embedded Syst., vol. 2, no. 3/4, pp. 239?247, 2006.
[117] C. Boettcher, R. DeLong, J. Rushby, and W. Sifre, gThe MILS
component integration approach to secure information sharing, h in The
27th IEEE/AIAA Digital Avionics Syst. Conf. (DASC), Oct. 2008.
[118] Federal Commun. Commission, gCognitive Radio Technologies and
Software De?ned Radios, h June 2007, 47 CFR Part 2 [ET Docket No.
03-108; FCC 07-66].
[119] SDR Forum, gSDR Forum Response to FCC MOO, h June 2007.
[120] T. Moore, gDeveloping an interoperable coalition communication
strategy using suite B, h in Military Commun. Conf., 2007.MILCOM
2007.IEEE, Oct. 2007, pp. 1?4.
[121] J. Giacomoni and D. C. Sicker, gDif?culties in providing certi?cation
and assurance for software de?ned radios, h in New Frontiers Dynamic
Spectrum Access Netw., 2005.DySPAN 2005.2005 First IEEE International Symp., Nov
. 2005, pp. 526?538.
[122] IEEE Standards Association. (2007, Sep) IEEE Standards Coordinating
Committee 41 (Dynamic Spectrum Access Networks). [Online].
Available: http://www.scc41.org/
[123] P. Martigne, B. Deschamps, K. Moessner, G. de Brito, K. El-Khazen,
and D. Bourse, gRegulatory trends for recon?gurable end-to-end systems, h in IST Su
mmit 06, 2006.
[124] P. Bender, gRegulatory Aspects of Software De?ned Radio, h Feb 2007.
[Online]. Available: http://www.etsi.org/website/document/workshop/
softwarede?nedradio\\/sdrworkshop4-1paulbender.pdf
[125] D. Bourse, W. Koenig, M. Doubrava, J.-M. Temerson, K. Nolte, I. Gaspard, K
. Kalliojarvi, E. Buracchini, and D. Bateman, gFP7 EU project:
Technical, business, standardization and regulatory perspectives, h in
SDR f08 Technical Conf. Product Exposition, Oct. 2008.
[126] Joint Program Executive Of?ce Joint Tactical Radio System, gJPEO
JTRS Announces fBusiness Model f for Certifying JTRS Radios, h Jan.
2007.
[127] H. Rantanen, gSCA test, evaluation and certi?cation - the perspective
of the Finnish software radio programme, h Apr. 2008.
[128] T. A. Sturman, M. D. J. Bowyer, and N. R. Pet?eld, gSkynet 5: MILSATCOM usi
ng SDR, h in Military Commun. Conf., 2007.MILCOM
2007.IEEE, 2007, pp. 1?7.
[129] M. S. Hasan, M. LaMacchia, L. Muzzelo, R. Gunsaulis, L. R. Housewright, an
d J. Miller, gDesigning the joint tactical radio system (JTRS)
handheld, manpack, and small form ?t (HMS) radios for interoperable
networking and waveform applications, h in Military Commun. Conf.,
2007.MILCOM 2007.IEEE, 2007, pp. 1?6.
[130] Defence Update. (2007, June) Harris, Thales Compete MultiBillion JTRS Radi
o Procurement. [Online]. Available: http://www.
defense-update.com/newscast/0607/news/240607\_jtrs.htm
[131] K. Bailey, gJTRS and COALWNW Overview for MILCIS 2008, h Nov.
2008.
[132] United States Government Accountability Of?ce, gDepartment of Defense Needs
Framework for Balancing Investments in Tactical Radios, h
Aug 2008.
[133] C. Serra, gEvolution of SDR Standards - The SDR Forum Perspective, h
Nov. 2007, Key note at 2007 Software De?ned Radio Technical Conf.
Product Exposition (presentation slides).
[134] European Defence Agency and OCCAR, gEuropean Secure Software
De?ned Radio: Contract Launced, h Dec. 2008.
[135] I. F. Akyildiz, W.-Y. Lee, M. C. Vuran, and S. Mohanty, gNext
generation/dynamic spectrum access/cognitive radio wireless networks:
A survey, h Comput. Netw., vol. 50, no. 13, pp. 2127?2159, 2006.
[136] B. A. Fette, Cognitive Radio Technology. Amsterdam:
Newnes/Elsevier, 2006.
[137] S. Haykin, gCognitive Radio: Brain-Empowered Wireless Commun., h
Sel. Areas Commun., IEEE J., vol. 23, no. 2, pp. 201?220, 2005.550 IEEE COMMUNIC
ATIONS SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010
[138] F. K. Jondral, gSoftware-de?ned radio ? basics and evolution to
cognitive radio, h EURASIP J. Wireless Commun. Netw., vol. 2005,
no. 3, pp. 275?283, Apr. 2005.
[139] C. Tran, R. P. Lu, A. D. Ramirez, R. C. Adams, T. O. Jones, C. B.
Phillips, and S. Thai, gDynamic spectrum access: Architectures and
implications, h in Military Commun. Conf., 2008.MILCOM 2008.IEEE,
Nov. 2008, pp. 1?7.
[140] T. Yucek and H. Arslan, gA survey of spectrum sensing algorithms for
cognitive radio applications, h IEEE Commun. Surveys Tuts., vol. 11,
no. 1, Jan. 2009.
[141] A. Gatherer, gMarket and technology drivers for cellular infrastructure
modem development, h Wireless Personal Commun., vol. 38, no. 1, pp.
43?53, 2006.
[142] S. Jennis and P. Burns, gWhat does mainstream telecom need to
embrace ftrue SDR f? h in SDR f08 Technical Conf. Product Exposition,
Oct. 2008.
[143] Huawei. (2008, Sep) Huawei Industry First with 3G/2G Software
De?ned Radio (SDR) Single RAN Product Launch. [Online].
Available: http://www.huawei.com/news/view.do?id=5587\&cid=42
[144] ZTE. (2008, Feb) ZTE Launches First SDR Base Station at
GSMA Mobile World Congress Barcelona 2008. [Online]. Available:
http://wwwen.zte.com.cn
[145] A. Kaul, gSoftware de?ned radio - the transition from defense to
commercial markets, h Nov. 2007, Key note 2007 Software De?ned
Radio Technical Conf. Product Exposition (presentation slides).
[146] NXP Semiconductors. (2008, Oct) Samsung, NXP and T3G showcase
world fs ?rst TD-SCDMA HSDPA/GSM multi-mode mobile phone.
[Online]. Available: http://www.nxp.com
[147] J. Martin and F. Clermidy, gMobile digital baseband: From con?gurable to ev
olutive platforms, h in Mobile Wireless Commun. Summit,
2007.16th IST, 2007, pp. 1?5.
[148] J. Mitola III, gCognitive radio an integrated agent architecture for softwa
re de?ned radio, h Ph.D. dissertation, Royal Institute of Technology
(KTH), SE-164 40 Kista, Sweden, May 2000.
[149] I. F. Akyildiz, L. Won-Yeol, M. C. Vuran, and M. Shantidev, gA survey
on spectrum management in cognitive radio networks, h Commun. Mag.,
IEEE, vol. 46, no. 4, pp. 40?48, 2008.
[150] C. Cordeiro, K. Challapali, D. Birru, and S. Shankar, gIEEE 802.22: An
introduction to the ?rst wireless standard based on cognitive radios, h
J. Commun., vol. 1, no. 1, pp. 38?47, Apr. 2006.
[151] E. L. Org, R. J. Cyr, R. Cook, and D. Donovan, gSoftware de?ned
radio - programmable transceivers for femtocells, h in SDR f08 Technical
Conf. Product Exposition, Oct. 2008.
Tore Ulversoy graduated from the Norwegian Institute of Technology (NTH),
Trondheim, Norway, in 1986. He has several years of experience from
development of military radio communications equipment. He is currently a
Ph. D. candidate at the UniK - University Graduate Center, University of Oslo,
Norway. His research interests include Software De?ned Radio, Cognitive
Radio and Dynamic Spectrum Access.