submitted by thania kumar - semantic scholar · 2017-11-01 · challenges and opportunities”,...

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY

COCHIN – 682022

2011

Seminar Report

On

Software Defined Radio: Challenges and Opportunities

Submitted By

Thania Kumar

In partial fulfilment of the requirement for the award of

Degree of Master of Technology (M.Tech)

In

Computer and Information Science

Software Defined Radio

Department of Computer Science i CUSAT

DEPARTMENT OF COMPUTER SCIENCE

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY

COCHIN – 682022

Certificate

This is to certify that the Seminar report entitled “Software Defined Radio:

Challenges and Opportunities”, submitted by Thania Kumar , Semester II, in the partial fulfilment of

the requirement for the award of M.Tech. Degree in Computer and Information Science is a bonafide

record of the Seminar presented by her in the academic year 2011.

G Santhosh Kumar Dr. K Paulose Jacob

Seminar Guide Head of the Department


Department of Computer Science ii CUSAT

ACKNOWLEDGEMENT

I express our profound gratitude to the Head of Department Dr. K Paulose Jacob for allowing

me to proceed with the seminar and also for giving me full freedom to access the lab facilities.

My heartfelt thanks to my guide Mr.G Santhosh Kumar, Lecturer, Department of Computer

Science for taking time and helping me through my seminar. He has been a constant source of

encouragement without which the seminar might not have been completed on time. I am very grateful

for his guidance.

I am also thankful to, Dr. Sumam Mary Idicula for helping me with my seminar. Her ideas

and thoughts have been of great importance.


Department of Computer Science iii CUSAT

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 well-defined, 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.

. Keywords: SDR, SCA, Cognitive Radio, GNU Radio, Reconfigurable Radio,

Multiprotocol Multiband Base Stations, Mobile Multi-standard Terminals, CORBA.


Department of Computer Science 1 CUSAT

Contents

1. Introduction ............................................................................................................................... 2

2. Software Architecture ................................................................................................................ 3

2.1 Software Communication Architecture (SCA) .................................................................... 3

2.2 Middleware ........................................................................................................................ 5

2.2.1 CORBA ..................................................................................................................... 5

2.3 SCA compliant SDR design ............................................................................................... 6

2.3.1 Base Application Interface .......................................................................................... 7

2.3.2 Framework Control Interfaces .................................................................................... 9

2.3.3 Framework Services Interfaces ................................................................................... 9

3. Challenges ............................................................................................................................... 11

3.1 Software Communication Architecture (SCA) .................................................................. 11

3.1.1 Portability of SDR SCA Based Application .............................................................. 11

3.1.2 Challenges related to SCA Application Development ............................................... 12

3.1.3 CORBA Related Challenges ..................................................................................... 13

3.1.4 SCA Challenges and Alternative Architectures ......................................................... 13

3.2 Challenges related to computational requirements of SDR. ............................................... 14

3.2.1 Computational requirements ..................................................................................... 14

3.2.2 Processing Options ................................................................................................... 14

3.3 Security Related Challenges ............................................................................................. 15

3.3.1 Software Load and Protection against Unauthorized SW ........................................... 15

3.3.2 Portability of Security Related Modules .................................................................... 15

4. Opportunities ........................................................................................................................... 17

4.1 Opportunities in the Military Domain ............................................................................... 17

4.2 Opportunities in the Commercial Domain ......................................................................... 17

4.2.1 Multiprotocol Multiband Base Stations: .................................................................... 17

4.2.2 Mobile Multi-standard Terminals: Mobile Multi standard ......................................... 18

4.2.3 Cognitive Radio: The projected evolution into CR capable ....................................... 18

4.2.4 Other Commercial Domain Opportunities: Commercial ............................................ 18

5. Conclusion .............................................................................................................................. 20

6. References ............................................................................................................................... 21



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.

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, well-defined, 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.

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



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.

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

A 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 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, LifeCycle, TestableObject, PropertySet, PortSupplier, ResourceFactory 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, ApplicationFactory, DomainManager, Device, LoadableDevice, ExecutableDevice, AggragateDevice and DeviceManager.The Framework Services Interfaces provide the system services. These interfaces support both core and none-core applications. They include: File, FileSystem, FileManager and Timer. The CF uses a Domain Profile to describe the 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. Figure 1 shows the relationship between the AEP, the application and the OE.

Fig 1.Relationship between SCA 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

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.

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). Figure 2 shows this configuration.

Fig 2.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 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 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 ResourceFactory 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 3. Resource Interface UML Diagram.

Design has four distinct functional components that inherit the Resource interface. These components are DirectXResource, AudioResource, WaveformResource 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.



Fig4.SCA interfaces used in the design

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



3. Challenges

3.1 Software Communication Architecture (SCA) Since SCA is the dominant SDR architecture, the SCA-related challenges will be

focused on first. Then the more general SW architectural challenges and alternatives to SCA will be discussed.

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 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 . The portability issues with SCA-based applications are summarized in Table I.



Portability Aspect: Standardized through SCA?

Environment and protocol for installation , instantiation & control,connection of application components

Yes.(But SCA security requirements not public)

Defined allowed Operating system services Yes.through AEP APIs to system units and system services No.(SCA states this is to be handled per

domain.) Communication No.Multiple solutions available.JTRS has

standardized on MHAL ORB SCA specifies CORBA 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.

Table 1

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

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 adaptivity 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 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 performanceversus 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.

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’spublic 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.

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



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.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, Wi-Fi). A multi-mode 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.

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.



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



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

submitted by thania kumar - semantic scholar · 2017-11-01 · challenges and opportunities”,...

Documents