29-12-2012, 06:02 PM
Seminar Report On Software Defined Radio: Challenges and Opportunities
1Seminar Report On Software.pdf (Size: 1.65 MB / Downloads: 103)
ABSTRACT
Today’s exceedingly rapid pace of technological advances makes communication
devices become obsolete shortly after they are produced. To keep up with this pace,
communications systems must be designed to maximize the transparent insertion of new
technologies at virtually every phase of their lifecycles. When these new technologies are
inserted, the upgraded devices should still be able to communicate with each other and with
legacy systems.
The term software defined radio was coined in 1990s to overcome these problems. A
software defined radio is a communications device whose functionality is defined in
software. In order to maintain interoperability, the radio systems must be built upon a welldefined,
standardized, open architecture. Defining architecture also enhances scalability and
provides plug-and-play behavior for the components of a radio. Software Defined Radio may
provide flexible, upgradeable and longer lifetime radio equipment for the military and for
civilian wireless communications infrastructure. SDR may also provide more flexible and
possibly cheaper multi standard-terminals for end users. It is also important as a convenient
base technology for cognitive radios. SDR also poses many challenges, however, some of
them causing SDR to evolve slower than otherwise anticipated.
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.
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 be defined. By building upon a common, welldefined,
open architecture, radio vendors could improve interoperability by providing the
ability to share waveform software between radios, and reduce development time through
software reuse. Such architecture would also facilitate scalability and technology insertion.
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 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.
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.
CORBA
CORBAis 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
under 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.
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
data they contain differs.
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 inherits the SCA CF application, which has the generic functions implemented.
The waveform specific behavior can be implemented by function overloading.
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.
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.
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 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.