Seminar Report 2021-22 Software Defined Radio

CHAPTER 1

INTRODUCTION

The term software defined radio refers to reconfigurable or reprogrammable

radios that can show different functionality with the same hardware. Because the
functionality is defined in software, a new technology can easily be implemented in a
software radio with a software upgrade. Today’s continuously changing technology
brings the need to build “future proof” radios. If the functions that were formerly
carried out by hardware can be performed by software, new functionality can be
deployed on a radio by updating the software running on it. Increasing traffic rates,
but decreasing amounts of spectrum requires even more sophisticated signal
processing algorithms be deployed on radios. The increase of variable- QoS, multi-
component traffic, requires complex management of resources allocated in the
operation of a user connection. There is a need to deploy a multiplicity of standards
within a single device.

Fig.1.1 SDR Structure

In a software defined radio, multiple waveforms can be implemented in

software, using the same hardware. One software defined radio can communicate with
many different radios, with only a change in software parameters. This means
interoperability among different military units, emergency units, and coalition armies.
New technologies can be adapted quickly, easily, and for a much lower cost. To build
radios that are able to support operations in a wide variety of domains without losing
the ability to communicate with each other, an open, standardized architecture must

Dept. of Electronics Engg. 1 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

be defined. By building upon a common, well defined, open architecture, radio

vendors could improve interoperability by providing the ability to share waveform
software between radios, and reduce development time through ssoftware reuse. Such
architecture would also facilitate scalability and technology insertion.

Fig.1.2 SDR Chip

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 communication systems. This is facilitated through SDR allowing the
possibility to change waveforms and/or load new waveforms on already acquired
SDR equipment.

Fig.1.3 Block Diagram

Dept. of Electronics Engg. 2 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

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
flexible asset suited for the changing environments of coalition and Network Centric
Operations (NCO).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.SDR poses severe challenges also in analogue RF hardware design
and the conversion between the analogue and digital domains, particularly in
wideband implementations.

Dept. of Electronics Engg. 3 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

CHAPTER 2

SOFTWARE ARCHITECTURE

The foundation of any digital system is the architecture. The term architecture
can refer to software, hardware or a combination of two. Software architecture is a
level of abstraction at which a system is typically described as a collection of
components and their interactions. Components perform the primary computations of
the system. Interactions between components include high level communication
abstractions such as message passing and event broadcast.

Software architecture includes components, connectors and configurations,

where components define the locus of computation, connectors define the interactions
between components and configurations define the topology of the components and
connectors. The software architecture of a program or computing system as the
structure or structures of the system, which comprise software components, the
externally visible properties of those components, and the relationships among them.
The structure should represent an abstract view of the system without implying any
implementation details. A software architecture also defines various static and
dynamic relationships between those components.

Software architecture should represent a high-level view of the system

revealing the structure, but it should hide all implementation. Specifically, it should
reveal attributes such as responsibilities of the constituents of the architecture,
distribution and deployment. It should also realize use case scenarios with appropriate
models and present both a logical or conceptual view and a deployment view of the
software.

Software architecture has different goals for different groups. For the systems
engineer, software architecture brings consistency, requirements tractability and trade-
off and completeness analysis whereas for the developer, it provides sufficient detail
for design and interoperability with legacy systems. It establishes a reference for
assembling components and guides the developer for software modification. The

Dept. of Electronics Engg. 4 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

software architecture provides consistency with use case scenarios, reliability and
interoperability analysis and project scheduling for the end user.

2.1 SOFTWARE COMMUNICATION ARCHITECTURE (SCA)

When the JTRS JPO was established to acquire a family of affordable, high
capacity, tactical radio systems that can provide interoperable wireless mobile
network services, the need for an open architecture emerged. By building upon a
common open architecture, JTRS can improve interoperability by providing the
ability to share waveform software between radios and reduce development and
deployment costs. In view of its potential applicability across a wide range of
communications domains, JTRS JPO named this architecture the Software
Communications Architecture

The SCA defines an Operating Environment (OE) that will be used by JTRS
radios. It also specifies the services and interfaces that the applications use from the
environment. The interfaces are defined by using the CORBA IDL, and graphical
representations are made by using UML. The OE consists of a Core Framework (CF),
a CORBA middleware and a POSIX-based Operating System (OS). The OS running
the SCA must provide services and interfaces that are defined as mandatory in the
Application Environment Profile (AEP) of the SCA. The CF describes the interfaces,
their purposes and their operations. It provides an abstraction of the underlying
software and hardware layers for software application developers. An SCA
compatible system must implement these interfaces. The interfaces are grouped as
Base Application Interfaces, Framework Control Interfaces and Framework

Services Interfaces the Base Application Interfaces are used by the application
layer. They provide the basic building blocks of an application. The interfaces in this
group are: Port, Life Cycle, Testable Object, Property Set, Port Supplier, Resource
Factory and Resource. The Framework Control Interfaces provide the control of the
system. The application layer can reach the OS through these control interfaces. The
interfaces in this group are: Application, Application Factory, Domain Manager,
Device, Loadable Device, Executable Device, Aggragate Device and Device
Manager. The Framework Services Interfaces provide the system services. These
interfaces support both core and none-core applications. They include: File, File
System, File Manager and Timer. The CF uses a Domain Profile to describe the

Dept. of Electronics Engg. 5 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

components in the system. The Domain Profile is a set of XML files that describe the
identity, capabilities, properties, inter-dependencies, and location of the hardware
devices and software components that make up the system. The software component
characteristics are contained in the Software Package Descriptor (SPD), Software
Component Descriptor (SCD) and Software Assembly Descriptor (SAD).

The hardware device characteristics are stored in the Device Package

Descriptor (DPD) and Device Configuration Descriptor (DCD). The Properties
Descriptor contains information about the properties of a hardware device or software
component. The Profile Descriptor contains an absolute file name for a Device
Configuration Descriptor, a Software Package Descriptor or a Software Assembly
Descriptor. Finally, the Domain Manager Configuration Descriptor (DMD) contains
the configuration information for the Domain Manager. Although the SCA uses the
CORBA middleware for its software bus, the application layer can reach the OS by
other means. CORBA adapters can be used to wrap the legacy software components.

2.2 MIDDLEWARE

Middleware is a layer of software between the applications and the underlying

network. This layer provides services like identification, authentication, naming,
trading, security and directories. The middleware also aims to provide hardware and
location transparency to software entities. It functions as a conversion and translation
layer. It is a consolidator and integrator. With the help of middleware, software
applications running on different platforms can communicate transparently.

2.2.1 CORBA

CORBA is used as the underlying middleware. CORBA has been chosen as

the middleware layer of the Software Communications Architecture, because of the
wide commercial availability of CORBA products and its industry acceptance.
Distributed processing is a fundamental aspect of the JTRS system architecture.
CORBA is used to provide a cross-platform middleware service that simplifies
standardized client/server operations in this distributed environment by hiding the
actual communication mechanisms Sunder an Object Request Broker software bus
.CORBA is the Object Management Group’s open architecture that provides the
infrastructure for computer applications to work together over a network.

Dept. of Electronics Engg. 6 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

A CORBA-based application written in almost any language and running on

almost any platform can interoperate with another CORBA-based application written
in a different language and running on a different platform. CORBA is mostly used in
large enterprise systems because of its ability to integrate machines from different
vendors easily. It is also used frequently in servers that need to handle large number
of clients at high hit rates securely, and reliably. CORBA applications are composed
of objects that encapsulate data and functionality. These objects are small individual
units of running software that usually represent something in real life. Objects are the
instances of a type, and a typical application will have many instances of a type.
These instances all have the same functionality, but the Sdata they contain differs.

A good example is an e-commerce site that assigns a shopping cart object to

every customer. All the carts will have the functionality to add and remove items, but
the items in the cart will be different for each customer. Each object in a CORBA
application is defined as an interface, using OMG’s IDL. The interface is the syntax
part of the contract that the server object offers to the clients that invoke it. Any client
that wants to invoke an operation on the object must use this IDL interface to specify
the operation it wants to perform, and to marshal the arguments that it sends. When
the invocation reaches the target object, the same interface definition is used there to
unmarshal the arguments so that the object can perform the requested operation with
them. The interface definition is then used to marshal the results for their trip back,
and to unmarshal them when they reach their destination.

The transparency and interoperability provided by CORBA is enabled by IDL.

IDL separates the interface from the implementation. There is a very strict interface
definition for every CORBA object. This interface is advertised throughout the
system. In contrast, the implementation of the objects is opaque. The object’s running
code and its data is hidden from the rest of the system with a boundary that the clients
cannot pass. Clients can only reach the objects through their advertised interfaces. An
IDL compiler compiles the given IDL into client stubs and object skeletons. The stubs
and skeletons act as proxies for clients and servers, and they run on top of Object
Request Brokers (ORB). Fig. 2.1 shows this configuration.

Dept. of Electronics Engg. 7 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

Fig 2.1 Stubs and skeltons in CORBA

When the ORB that runs the client discovers that the actual object
implementation is on a remote ORB, it routes the invocation out over the network to
the remote object’s ORB. As the ORBs might be implemented by different vendors,
and CORBA promises vendor independent interoperability, the architecture specifies
a common protocol called Internet Inter-ORB Protocol (IIOP).This protocol specifies
a representation to specify the target object, operation, all parameters (input and
output) of every type that may be used, and how all of this is represented over the
wire. CORBA provides the mechanism through which different software defined
radio vendors can develop compatible software and hardware interfaces. Any
component on a radio can be replaced or upgraded, and the download process can be
made transparent to the user.

2.3 SCA COMPLIANT SDR DESIGN

SCA is designed to be an open, standardized architecture providing

interoperability, technology insertion, quick upgrade capability, software reuse and
scalability. A software engineer should keep these key issues in mind, while designing
the software structure of an SCA compliant software radio. CORBA is the
interoperability backbone of the SCA specification. The design makes efficient use of
CORBA in every possible situation, and does not use any ORB-dependent features to
be completely compatible with all CORBA compliant ORBs. No assumptions are
made about the locations of the software components, except for the object factories.
Software reuse is another very important aspect of our design. Each new waveform on
the radio system is deployed as a new application. The specific waveform application

Dept. of Electronics Engg. 8 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

inherits the SCA CF application, which has the generic functions implemented. The
waveform specific behavior can be implemented by function overloading. All
waveforms can use the CF services like the File System, which is another factor
increasing reusability.

Scalability is provided by software component assemblies. A waveform

application creates a CF Resource for each functional unit, connects these resources to
each other using CF Ports, and deploys these resources on CF Devices. New
functionality can be added easily to an existing system by creating a new Resource,
and connecting it to the necessary resources. When a new hardware device is installed
on a system, a new logical CF Device is created as a software proxy for this hardware
device, and the Device is registered to a CF Device Manager.

2.3.1 Base Application Interface

The CF Base Application Interfaces are the basic building blocks for an SCA
compatible radio system. These interfaces are Port, LifeCycle, TestableObject,
PropertySet, PortSupplier, Resource and ResourceFactory. These interfaces are used
by the application layer and the Framework Control Interfaces to assemble an
application. They are implemented by the application developers. The components of
an SCA compatible application connect to each other through ports. The Port
interface provides the connect and disconnect operations needed to assemble and
disassemble components. Application specific ports inherit the Port interface. These
component dependent, application specific ports define the direction and control of
the data flow and fan-in fan-out specifications by implementing additional operations.
Components that provide ports inherit the PortSupplier interface which defines the
getPort operation.

This operation is used to obtain a specific consumer or producer port. The

components that need to be initialized or released after instantiation inherit the
LifeCycle interface. This interface provides a generic method to set a component to a
known initial state, and to tear it down. The TestableObject interface defines a Built-
In-Test behavior for components that inherit it. The runTest method defined by this
interface, provides a black box test with test parameters provided by the user.
Components implementing the PropertySet give access to their properties and
attributes. The configure operation of the PropertySet allows runtime configuration of

Dept. of Electronics Engg. 9 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

a component, whereas the query operation returns its attributes and properties. The
software components in an SCA compatible system implement the Resource
interface. The Resource interface provides the operations to control and configure a
component by inheriting the PortSupplier, TestableObject, PropertySet and LifeCycle
interfaces, and by providing start and stop operations. Applications are created by
connecting a number of Resources to each other through Ports.

A Resource can be created or released by a ResourceFactory. The Resource-

Factory is designed after the Factory Design Patterns. Factories are used to define an
interface for creating an object, but let subclasses decide which class to instantiate.
Factory Method lets a class defer instantiation to subclasses. Different kinds of
functionality can be implemented by different components that inherit the Resource
interface. When an application tries to assemble these components to build up the
system, it may not predict the subclass of Resource to instantiate. In other words,
although an application knows when a new resource should be created, it may not
know which subclass to create. The Resource Factory solves this problem by
providing a generic operation to create Resources. The factory method also provides a
client-server isolation in a CORBA implementation. The factory keeps a list of the
object instances it created, keeping an object reference on the server side, until a
release request is received. This helps the book-keeping of the client and server side
reference counts.

Fig.2.2 Resource Interface UML Diagram

Dept. of Electronics Engg. 10 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

Design has four distinct functional components that inherit the Resource
interface. These components are DirectXResource, AudioResource, Waveform
Resource and ModemResource. They communicate through ports. The Resources
perform their functions by loading pre-compiled binaries on the Devices they are
deployed on, and executing these binaries. Their functionalities are two-way, so the
same Resource can be used for both reception and transmission. The DirectXResource
handles the D/A and A/D conversion with the help of a sound card. This resource
must be deployed on a device that has a compatible sound card. Once started,
DirectXResource converts the analog voice signal from a microphone to a sequence
of integers, and vice versa.

2.3.2 Framework Control Interfaces

The CF Framework Control Interfaces provide the interfaces to assembly and

control the radio system. These interfaces are Application, ApplicationFactory,
DomainManager, Device, LoadableDevice, ExecutableDevice, AggregateDevice and
DeviceManager. The Framework Control Interfaces can be grouped as Domain
Management Interfaces and Device Management Interfaces. Domain Management
Interfaces consist of DomainManager, Application and ApplicationFactory. These
interfaces provide the services to control, register and unregister applications and
devices. These interfaces are coupled together and they must be implemented
together. The Device Management Interfaces consist of Device,LoadableDevice,
ExecutableDevice, AggregateDevice and DeviceManager. The device interfaces are
used to create logical devices within the domain that act as software proxies for the
hardware devices. The DeviceManager creates and controls these logical devices.

2.3.3 Framework Services Interfaces

The Framework Services Interfaces provide the system services. These

interfaces are File, FileSystem, FileManager and Timer. These interfaces support both
core and non-core applications. The File interface provides the operations to read and
write files in an SCA compliant radio domain. The SCA specification defines a file
conceptually as a sequence of octets with a file pointer describing where the next read
or write will occur. Remote access to physical file systems are provided by the

Dept. of Electronics Engg. 11 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

FileSystem interface. The FileSystem also acts as an object factory for Files by
defining create and open operations. The FileSystem interface makes the underlying
physical file system transparent to the user. Different file systems like FAT32, NTFS,
and Unix File System can be used with the same interface. When combined with the
location transparency feature of CORBA, the user does not even know where the
physical file actually resides in the system. The FileManager provides yet another
level of abstraction so that multiple, distributed FileSystems may be accessed through
a FileManager.

The FileManager inherits the FileSystem interface and extends it by providing

mount and unmount behavior. If no additional FileSystems are mounted, the
FileManager can be treated as a FileSystem. If additional FileSystems are added to the
system and mounted to the FileManager, the user can transfer Files between them as
if they are different directories. The different physical file systems are transparent to
the user. All the file accesses in our radio are provided by the FileSystem. A file
resident on the physical file system is not existent in the SCA domain unless it is
opened or created by the FileSystem.

Dept. of Electronics Engg. 12 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

CHAPTER 3

CHALLENGES

3.1 SOFTWARE COMMUNICATION ARCHITECTURE (SCA)

Since SCA is the dominant SDR architecture, the SCA-related challenges will be
focused on first.

3.1.1 Portability of SDR SCA Based Application

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 on 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. 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 Profile (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 sufficient to cover all aspects of
portability. Significant pieces that are not standardized by the SCA itself are the APIs
to the services and devices of the system platform. Within JTRS, a number of such
APIs have been developed. 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. It remains to be seen if ESSOR will develop standards to be used by a

Dept. of Electronics Engg. 13 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

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 components is providing abstraction layers
between the platform and the application components. Another related portability
issue is the various alternatives for transport mechanisms for the communication with
components deployed on DSPs and FPGAs. The JTRS has standardized a specific
adapter referred to as the Modem Hardware Abstraction layer (MHAL) for this
purpose .

Table 3.1 The portability issues with SCA-based applications

Portability Aspect Standardized through SCA

Environment and protocol for

Yes.(But SCA security requirements
installation, instantiation & control,
not public)
connection of application components

Defined allowed Operating system

Yes. through AEP
services

APIs to system units and system No.(SCA states this is to be handled

services per domain.)

No. Multiple solutions available.

Communication
JTRS has standardized on MHAL

ORB SCA specifies CORBA

No. But this merely presumes

Programming language
availability of compilers, libraries etc.

Target processor compatibility of the No. Different DSPs and FPGAs may
code support different features

3.1.2 Challenges related to SCA Application Development

For the traditional communications equipment design engineer, with a

communications or radio engineering and less of a SW distributed systems
background, SCA may appear challenging to learn and understand. While defining

Dept. of Electronics Engg. 14 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

SCA components manually is tedious work involving a lot of XML and CORBA
details, the tools allow the SDR designers to define 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 significant 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 while functional processing code needs to be added by the
designer, either coded manually or using her/his favorite tools. A more unified higher-
level design approach possibly could improve productivity. It is envisioned that SDR-
design will increasingly be performed at higher abstraction levels, eventually using
fully integrated Model-Driven Development (MDD) tools with automatic
transformation from model level to any specific heterogeneous platform. In summary,
a further enhancement of the efficiency 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.

When confidential data have to be removed, we must be sure that once

deleted, the data can no longer be restored. A full secure data lifecycle implies that
data is not only stored securely, but deleted in a secure manner as well. However,
typical file deletion (encrypted or not) only removes a file name from its directory or
folder.

3.1.3 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 Latency implies

Dept. of Electronics Engg. 15 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

processing delays in the SDR, and tolerable level is application and waveform
dependent. As with throughput, latency is a function of both CORBA and the
underlying transport. Average latency tends to show a linear relation with message
size and with significant non-zero latency for message size 0. Latency variation may
be reduced by using Real-Time CORBA features.

While CORBA used to be limited to GPP processors only, ORBs for

specialized processing elements such as DSPs and FPGAs have been developed in
recent years. The ORB on an FPGA may be put in an embedded microprocessor or (as
a CORBA subset) directly implemented at native gate level where the latter has a
processing speed advantage. This theoretically facilitates CORBA communication
between all typical processing elements on an SDR 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

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.

3.1.4 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 specification for SDR, and derived from the
SCA, is OMG’s PIM and PSM for Software Radio Components Specification Its
current Platform Specific Model (PSM) utilizes CORBA-interfaces, 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’s standards are open ones also in the sense that all
members have an equal vote on the final content of a standard.

Dept. of Electronics Engg. 16 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

An open-source implementation, "Open Space Radio" has been made

available by Virginia Tech. The GNU radio architecture is an open-source initiative,
where the signal processing is carried out on GPP computers. GNU radio is adapted to
the Universal Serial Radio Peripheral (USRP) which converts between base band and
RF signals. Radio applications are formed as graphs where the vertices represent
signal processing blocks and the edges are the data flow, and where the blocks have
input and output ports. With the evolution towards cognitive radios which requires the
radio to have reasoning capability and adaptively there will probably be a need for
architectural features beyond the present SCA. As an example, with cognitive radios it
is beneficial 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 beneficial to partly support
this functionality through middleware.

In the commercial civilian segment, where there is less focus on portability

and more on hardware cost and low power consumption, it is expected that a
significant portion of designs will use dedicated and proprietary lighter-weight
architectures. In a longer time perspective, with decreasing hardware cost and
increasing performance, it is expected that open and standardized architectures such
as the OMG one will gain.

3.2 CHALLENGES RELATED TO COMPUTATIONAL REQUIREMENTS

OF SDR

3.2.1 Computational requirements

A fundamental challenge with SDR is how to achieve sufficient computational

capacity, in particular for processing wide-band high bit rate waveforms, within
acceptable size and weight factors, within acceptable unit costs, and with acceptable
power consumption. 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

Dept. of Electronics Engg. 17 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

become unpleasantly high for the user. For base stations like cellular network
infrastructure stations, and for vehicular mounted stations, the power, size and weight
factors are easier to accommodate, however performance versus these parameters 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.

The SDR components may to a large degree run in parallel, e.g. a decimator
component may run in parallel with a filter 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 system Architecture, where processes may run on
several processing elements while exchanging processed data. A good exploitation of
this parallelism depends on a well devised component structure of the waveform
application, along with optimized deployment of the components on the available
processing elements.

3.2.2 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 flows of instructions and internal parallelism
will be beneficial from a performance point of view. For some SDR applications, it
will be sufficient to be able to reconfigure 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, reconfiguration 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 reconfiguration should then typically be done in less than a few tenths of a
second. For other applications, e.g. a fully context-adaptive SDR, reconfiguration will
need to be done in real-time without disturbing any operation of the radio system.

3.3 SECURITY RELATED CHALLENGES

The flexibility benefits of SDR at the same time causes challenges in the
security area, both for developers and security certification organizations.

Dept. of Electronics Engg. 18 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

3.3.1 Software Load and Protection against Unauthorized SW

A major security challenge is introduced through the possibility to load and

install new SW on an SDR unit possibly also over-the-air or via a fixed network
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 unauthorized
code can be even more far-reaching, from compromising threats to the user’s assets,
e.g. his confidential 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.

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. The manufacturer (or any other party authorizing the
code) computes a one-way hash of the code module, 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 verification application on the SDR platform then verifies the signature
by decrypting the signature using the manufacturer’s public key, and checks that the
decrypted signature equals the one-way hash of the code module. A Digital Certificate
is a way of assuring that a public key is actually from the correct source. The Digital
Certificate is digitally signed by a trusted third-party.

The trusted third-party is verified through a chain of trust to a root certificate

on the platform. A critical issue with the above approach is that root certificates must
be distributed to all terminals through a secure out-of-band channel. With a new
platform this is easy as root certificates may be factory installed or installed through
physically delivered SW; however the issue becomes important when a certificate has
expired when the terminal is in the field. A further issue is that of revocation of
certificates. A certificate 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.

Dept. of Electronics Engg. 19 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

3.3.2 Portability of Security Related Modules

As a way to achieve interoperability between secure radio systems, for

example in military coalition operations, portability of security SW modules is a
highly desired feature. Code portability between platforms with conventional security
architectures requires 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.

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 version of the SCA, neither the security requirements nor the
security APIs have been openly published, making portability between different
development domains difficult. The ESSOR project aims at providing what it terms a
common security basis to increase interoperability between European forces as well
as with the United States. It remains to be seen though, if ESSOR will define 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 drastic reductions in
technical obstacles for portability of security code. Since the MILS-specific 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 implementation specific additional
bindings to non-standard devices this would give similar concerns as discussed
earlier.

In summary, the lack of inter domain security APIs and security feature
documentation is presently a major challenge and obstacle for SDR application
portability. Ongoing initiatives, E.g. ESSOR, are likely to improve this situation by

Dept. of Electronics Engg. 20 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

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 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 battlefield.

Dept. of Electronics Engg. 21 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

CHAPTER 4

OPPORTUNITIES

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.

4.1 OPPORTUNITIES IN THE MILITARY DOMAIN

SDR provides opportunities for having military radio communications

equipment which is SW upgradeable and reconfigurable, possibly even field
reconfigurable and reconfigurable in space deployment. This represents both benefits
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 reconfigurability 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. JTRS has great focus on standardization and portability, with
the JPEO managing the SCA. JTRS has evolved to also be a programme that delivers
tactical wireless networking for the US military and thus is an important part of the
NCO transformation. 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.

4.2 OPPORTUNITIES IN THE COMMERCIAL DOMAIN

4.2.1 Multiprotocol Multiband Base Stations

SDR provides an opportunity to switch from conventionally designed cellular

base stations to Software Defined Multi-Protocol Multi-Band (MPMB) base stations.

Dept. of Electronics Engg. 22 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

The reconfiguration 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
 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.
 Context-related reconfigurability and the accommodation of the future
cognitive terminals.

SDR MPMBs also allow standardization of hardware platforms, which

reduces the amount 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 base stations, as well as some recent announcements from Huawei and ZTE,
are SDR examples.

4.2.2 Mobile Multi-standard Terminals: Mobile Multi standard

Terminals (MMTs) represent another large market opportunity for SDR. As

the number of standards needing to be served 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
reconfigurable 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 non- SDR designs,
utilizing waveform standard specific integrated HW even if the terminals serve a high
number of waveform standards (e.g. GSM, EDGE, W-CDMA, HSDPA, Bluetooth,

Dept. of Electronics Engg. 23 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

Wi-Fi). A multimode mobile phone with ’software defined modem’ processing up to

2.8 Mbps has been demoed. This is possibly an important milestone in the SDR
direction. Technical details about its SW flexibility and power consumption are
however 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 field upgrading waveform application software on
mobile handsets has been limited, simply due to the fact that the handsets are
frequently replaced the handset replacement’ model since the market is currently
driven also by a lot of other factors than the waveform standards, e.g. improved
platform devices such as cameras and displays.

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 the
terminal is intended to serve. Due to these factors being more significant 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
significant drive in this direction.

4.2.3 Cognitive Radio: The projected evolution into CR capable

MPMBs and MMTs represent a large future market opportunity and driver for
SDR technology. CRs may both provide context-aware services for the user and
improve spectrum utilization through dynamic spectrum access. In order to
continuously take advantage of spectrum opportunities and adapt to the specific
context, CR requires platforms that have fast dynamic reconfiguration abilities.

Dept. of Electronics Engg. 24 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

4.2.4 Other Commercial Domain Opportunities

Commercial Satellite Communications has already been mentioned as a

segment that will benefit from SDR, where SDR enables remote upgrades and
possibly multiple uses during the lifetime of a satellite. 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 .The reconfigurability and flexibility provided by
SDR support the multiple bands, multiple standards and simultaneous ’sniffing’
functionality needed in the Femtocells. Other mentioned market opportunities include
devices for laptops, automobiles, home entertainment and the medical and public
safety segments.

Dept. of Electronics Engg. 25 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

CHAPTER 5

CONCLUSION

Even though 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 contributing to
reducing the learning threshold of the SCA and also increase the productivity 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. 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.

A fundamental challenge for SDR designs is that of providing sufficient

computational 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. The reconfigurability of SDR systems
has security challenges as a side effect.

One 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 flexibility and portability ideally
required for SDR. The multitude of waveform standards and their rapid progress
make it beneficial and economical to be able to 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

Dept. of Electronics Engg. 26 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined 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
third-party SW providers. This again will provide volume benefits 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 flexible 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.

Dept. of Electronics Engg. 27 S.R.G.P.T.C Thriprayar

Seminar Report 2021-22 Software Defined Radio

REFERENCES

1. Tore Ulversøy,“ Software Defined Radio: Challenges and Opportunities”

IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 12, NO. 4,
FOURTH QUARTER , 2010
2. Sabri Murat Bicer,” A Software Communications Architecture Compliant”
June 2002 Software Defined Radio Implementation
3. IEEE Journals on Selected areas in communication system, “Cognitive Radio:
Brain Empowered wireless communication” VOL. 23, NO. 2, FEBRUARY
2005.
4. B. K. Jondral, “Software-defined radio – basics and evolution to cognitive
radio,” EURASIP J. Wireless Commun. Netw., vol. 2005,no. 3, pp. 275–283,
Apr. 2005.
5. Ralf E. Schuh, Peter Eneroth and Peter Karlsson,” Multi-Standard Mobile
Terminals”Feb 2005
6. John Bard,Vincent J. Kovarik Jr.”Software Defined Radio-Software
Communication Architecture” Wiley Publication

Dept. of Electronics Engg. 28 S.R.G.P.T.C Thriprayar