AGUAYO GONZALEZ LAYOUT
9/23/09
10:52 AM
Page 48
MILITARY COMMUNICATIONS
Open-Source SCA-Based Core Framework and Rapid Development Tools Enable Software-Defined Radio Education and Research Carlos R. Aguayo González, Carl B. Dietrich, Shereef Sayed, Haris I. Volos, Joseph D. Gaeddert, P. Max Robert, and Jeffrey H. Reed, Virginia Tech Frank E. Kragh, Naval Postgraduate School
ABSTRACT This article describes the Open Source SCA Implementation::Embedded project, an open source software development kit designed for rapid prototyping of software defined radios consistent with the Software Communications Architecture. The SCA is a product of the American military’s SDR acquisition program and has played a large role in SDR development in the military and in the wireless industry. OSSIE was designed for use in wireless communications curricula and research efforts, so it is easy to learn and illustrative of software engineering, programming, and communications engineering concepts important in industrial practice today. OSSIE includes a core framework (i.e., common services enumerated in the SCA). It also includes graphical user interface-oriented tools that are easily learned and free to download and use. The tools auto-generate SCA-specific component source code and supporting files, leaving the developer to provide signal processing functionality. In addition, visualization tools for debugging and a growing library of SDR software components are available. Discussed herein are examples of SDRs designed using OSSIE, including embedded applications. OSSIE enables easy transition from concepts to practice in SDR design for communications engineers who may not have a strong software background.
INTRODUCTION In recent years the communications industry has seen explosive growth in research and development of software defined radio (SDR) technology. Students, engineers, and software developers entering this field need tools for SDR development and for acquiring new skills when necessary. Such tools include not only integrated development environments and reusable software mod-
48
0163-6804/09/$25.00 © 2009 IEEE
ules, but also reference implementations of software architectures that embody best design practices. These tools can also have great educational impact by enabling a practical introduction to SDR software development. The Open Source SCA Implementation::Embedded (OSSIE) project [1] meets the need for a freely available, easyto-use toolset that embraces an industry standard approach to SDR development and is well suited to education, research, and rapid prototyping. This article provides an introduction to the software of the OSSIE project, its structure and applications, and related educational resources. We define SDR as any radio that is substantially defined in software and whose physical layer behavior can be significantly altered through changes to its software [2]. SDRs are important because they offer several advantages over traditional hardware radios including efficient and compact multimode functionality, global mobility, and ease of upgrades. SDR is an emerging technology, with increasing applicability as research and development drives down costs and increases capabilities. Government has led SDR development with the American military’s Joint Tactical Radio Systems (JTRS) program [3] and its predecessors. Industry has also found substantial use for SDR including, for example, multimode SDR base stations for mobile telephone systems such as Vanu, Inc.’s Anywave Base Station. Academia is improving SDR technology via research, using SDR as a flexible tool for radio experimentation, and teaching SDR design methodologies to a new generation of communications engineers. The OSSIE project is based on the widely used Software Communications Architecture (SCA), which has been developed as part of the JTRS program and is central to much ongoing research and development. The OSSIE project provides the software infrastructure mandated by the SCA, and easily mastered design tools
IEEE Communications Magazine • October 2009
Authorized licensed use limited to: Tabriz University. Downloaded on October 28, 2009 at 08:49 from IEEE Xplore. Restrictions apply.
AGUAYO GONZALEZ LAYOUT
9/21/09
1:15 PM
Page 49
that facilitate development of components and applications. These tools assist with radio application generation and visual debugging, including automatic code generation to facilitate conformance with the SCA. This reduces the need for manual programming and the likelihood of programming errors. The OSSIE project is a catalyst for education, research, and development in SDRs because it satisfies the need for an integral development solution that is easily available and relevant to current SDR design trends. The OSSIE project is open source, and freely available via Internet download including all the infrastructure software, the development tools, and the component library. Anyone can contribute software to this open source project. The software developed in the OSSIE project is intended to work on PCbased platforms as well as embedded platforms. As products of the university educational environment, tools and software artifacts in the OSSIE project have been designed to be easily learned. The OSSIE project has a strong user base and includes help assets such as user guides, an electronic mailing list, and a users’ chat line. This is all part of the objective of the OSSIE project, which is to enable education and design in SDR for a wide user base.
FRAMEWORK A BRIEF INTRODUCTION TO THE SCA The SCA is an open architecture developed by the U.S. Department of Defense to assist in the development of SDRs. It specifies the mechanisms to build, deploy, manage, and interconnect component-based applications in modular distributed platforms. The SCA is expected to greatly enhance the interoperability of communication systems, and reduce their deployment and development costs. The SCA was developed to achieve the following goals [4]: • Improve the portability of application software between different implementations of the SCA • Reduce development cost by leveraging commercial standards • Reduce development time by reusing design modules • Build on commercial frameworks and architectures The SCA provides an implementation-independent set of rules to design SDRs that achieve these goals. It has been developed following a component-based approach including best practices from components models and design patterns. These characteristics translate into easier, faster development of flexible, maintainable, and upgradeable applications. The SCA also defines a standard component model. This standardization enables third parties to provide generic tools for SCA development, reducing time to market as well as support and maintenance costs. Being implementation independent, the SCA describes the behavior expected from components, applications, and operational environments without mandating specific implementation details. The SCA was developed as a scalable architecture capable of supporting platforms with widely different capacities, from fixed communication hubs
to handheld devices. This scalability, along with standard waveform packaging and deployment, greatly improves portability of radio applications. A key element for achieving this portability is the definition of a standard operational environment (OE). Such standardization provides the consistency necessary to deploy and run waveforms across platforms with different hardware components, device drivers, or transport mechanisms. The OE is divided into three layers providing distinct levels of abstraction: the operating system (OS), the middleware, and the core framework (CF). The OSSIE project is developed for the Linux operating system. In the SCA context, any radio application is known as a waveform, which is defined as the set of transformations applied to information that is transmitted over the air and the corresponding set of transformations to convert received signals back to their information content [3]. The core framework defines a common mechanism to manage and control waveforms and their components. Therefore, components can come from different sources and still use the same mechanisms to be deployed, connected, and managed. A more detailed description of the architecture can be found in [5, 6].
The SCA is an open architecture developed by the US Department of Defense to assist in the development of SDRs. It is expected to greatly enhance the interoperability of communication systems and reduce their deployment and development costs.
THE ROLE OF THE COMMON OBJECT RESOURCE BROKER ARCHITECTURE IN THE SCA Distributed processing is a fundamental aspect of the SCA, where the Common Object Resource Broker Architecture (CORBA) is used as the message passing mechanism within the distributed processing environment. CORBA is widely used in the commercial world for different applications as it standardizes client/server operations in distributed processing platforms. CORBA makes possible the development of SCA waveforms independent of the actual deployment configuration on distributed modular platforms. CORBA provides a layer of abstraction between the application and platform-specific elements, such as OS and transport layers. This gives the SCA location transparency, enabling deployment modifications without affecting the application’s logic. Furthermore, the benefits of standardized interfaces and operations from CORBA can be extended not only to general-purpose processors (GPPs) but also to digital signal processors (DSPs) and field programmable gate arrays (FPGAs), promoting scalable solutions with a common integration interface. The OSSIE project uses omniORB, an open source CORBA implementation.
CORE FRAMEWORK A framework is a set of cooperating classes that make up a reusable design for a specific class of software [7]. The SCA defines, in the CF, a set of interfaces that govern the deployment and management of waveforms and their components. These interfaces define low-level architectural details, allowing developers to focus on application design. The SCA CF includes: • Base application interfaces, which provide a common mechanism for the control and configuration of software components • Base device interfaces, which allow interaction with physical hardware devices by providing a proxy to the rest of the framework
IEEE Communications Magazine • October 2009 Authorized licensed use limited to: Tabriz University. Downloaded on October 28, 2009 at 08:49 from IEEE Xplore. Restrictions apply.
49
AGUAYO GONZALEZ LAYOUT
9/21/09
Device Configuration Descriptor (DCD)
1:15 PM
DomainManager Configuration Descriptor (DMD)
Device Package Descriptor (DPD)
Includes 1...n Software Package Descriptor (SPD)
Includes 0...n Includes 0...n
Software Assembly Descriptor (SAD)
Includes 1
Inc lu 1.. des .n
Includes 0...n
Page 50
Properties Descriptor (PRF)
Includes 0...n Includes Software Component 0...n Descriptor (SCD)
Figure 1. Domain Profile XML file type relationships (adapted from [4, Fig. 332]). • Framework control interfaces, which allow consistent deployment, configuration, and management of waveforms and platforms • Framework services interfaces, which enable distributed file-related operations • Domain Profile The OSSIE project includes implementations of the framework control and services interfaces, as well as examples of representative devices, in its OSSIE CF. Our tools, explained in the next section, assist developers with base application interfaces and domain profile files.
THE SCA DOMAIN PROFILES All the information concerning applications and platforms within the SCA is included in a set of files called the Domain Profile. These files describe the interfaces, capacity models, properties, interdependencies, interconnections, and logical location of each and every component within the domain. These descriptions are provided in eXtensible Markup Language (XML). The OSSIE project uses the Xerces XML parser and is currently migrating to tinyXML. Figure 1 displays the relationships of the different profiles that make up the SCA Domain Profile. The top three elements of the Domain Profile are the root profiles that drive the SCA; the Device Configuration Descriptor (DCD), the DomainManager Configuration Descriptor (DMD), and the Software Assembly Descriptor (SAD). The root profiles reference the Software Package Descriptor (SPD). The SPD is an essential profile that describes the software features of one or more particular software components. In this way, an SPD describes the software requirements of a component, such as supported operating systems and supported hardware devices, in order to support multiple component implementations.
TOOLS: THE WAVEFORM WORKSHOP 1
The name ALF is not an acronym.
50
The OSSIE Waveform Workshop comprises a comprehensive set of freely available tools for rapid development, testing, and runtime configuration of SDR waveforms and components. Fig-
ure 2 illustrates the use of the tools that make up the Waveform Workshop. Virginia Tech developed the OSSIE Waveform Developer (OWD) and associated component editor to simplify waveform and component development. This software provides a graphical user interface (GUI) that allows the developer to design new software components and interconnect existing components to create waveform applications. OWD uses a template-based approach to code generation, and produces XML files needed for waveform applications and components. Component source code (now in either C++ or Python) is automatically generated that takes care of interactions with the SCA framework and CORBA. The developer adds signal processing functionality to the code. Developers at Science Applications International Corporation (SAIC) contributed ALF,1 a waveform application visualization and debugging tool. ALF allows a developer or user to launch waveforms on the target platforms, display them in block diagram form, and probe component ports using provided or user-developed plug-in tools such as a spectrum and constellation plotting tool. These tools were developed in Python, an object-oriented scripting language that is popular for rapid prototyping. ALF’s capabilities have been expanded to include more plug-in tools and the ability to rapidly launch software components as standalone applications. Furthermore, a connection tool was added that allows interconnections between multiple concurrently running applications. This allows ad hoc applications to be built from independently running components, and provides a higher-level approach to application management. The connection tool makes use of XML files to define producer and consumer applications and their methods of installation (e.g., install once or install and uninstall on demand). With support from the U.S. Army Communications-Electronics Research, Development, and Engineering Center (CERDEC), the existing tools were integrated into Eclipse. Eclipse is an open source integrated development environment that provides an improved user interface and many other features desirable to developers. These features include code editing and debugging, and support for collaborative development through interfaces with revision control systems. Revision control systems such as subversion and concurrent version system (CVS) store source code in a central repository and track developers’ edits to the code. Using the OSSIE Eclipse Feature (OEF), it is now possible to develop components and waveform applications, launch the domain manager and device managers, launch ALF, and, if desired, launch the legacy OWD, all from within the Eclipse GUI [8]. The OSSIE Waveform Dashboard, under development at this writing, leverages SCA functionality to provide an interactively customizable GUI that provides easy control of both existing and new waveforms. The GUI allows a user to install and run waveforms, configure component properties, and choose which properties to display and the type of control to be used for each displayed property. This allows the user to focus on the waveforms, components, and properties
IEEE Communications Magazine • October 2009 Authorized licensed use limited to: Tabriz University. Downloaded on October 28, 2009 at 08:49 from IEEE Xplore. Restrictions apply.
AGUAYO GONZALEZ LAYOUT
9/21/09
1:15 PM
Page 51
Figure 2. Waveform design flow using the OSSIE Waveform Workshop. Application software is developed using the Eclipse-based component and waveform development tools, tested using the ALF waveform visualization and debugging environment, configured, and run as a standalone application using the Waveform Dashboard. Work is in progress to simplify porting of components and waveforms to embedded hardware. that require his or her attention, speeding development and reducing programming errors.
COMPONENTS SCA applications are made up of collections of software components that run as separate processes and are interconnected using CORBA middleware. The components are deployed to executable devices and may be connected via standard interfaces with other devices (e.g., an RF front-end or sound card) as well as to other components.
Peripheral (USRP) device [9]. Table 1 provides a list of selected OSSIE components. Most of the components available have reconfigurable properties with specified default values. The property values of each component’s instance can be set to instance-specific defaults in waveforms developed using OEF, and can be set interactively at runtime using the Waveform Dashboard. The user is not limited to the components that OSSIE provides. Using the OEF, the user can easily modify existing components or develop his/her own components.
SIGNAL PROCESSING COMPONENTS
DEVICE INTERFACE CODE
The OSSIE project includes a library with the necessary signal processing components to establish a radio link. For the transmitter, components are available that perform forward error correction, modulation, and interpolation with pulse shaping. For the receiver, components are available that perform the functions of decimation, automatic gain control, carrier recovery, symbol synchronization, and demodulation. Furthermore, components are available for the configuration and control of an RF front-end (RFFE), such as the Universal Software Radio
The SCA defines interfaces that act as proxies to physical devices, such as GPPs and DSPs. The OSSIE project provides a reference implementation of these interfaces for CORBA-enabled processors in its GPP device implementation. The USRP is a popular hardware peripheral for reception and transmission of signals in the open source software radio community. Support for the USRP is provided in the OSSIE project using a software abstraction of the same name. Finally, another useful device provides access to the computer’s sound card.
IEEE Communications Magazine • October 2009 Authorized licensed use limited to: Tabriz University. Downloaded on October 28, 2009 at 08:49 from IEEE Xplore. Restrictions apply.
51
AGUAYO GONZALEZ LAYOUT
9/21/09
1:15 PM
Page 52
Component name
Function
AutomaticGainControl
Automatically adjusts the input signal level amplification
Conv_Enc/Conv_Dec
Convolutional encoder/decoder
CostasLoop
Performs carrier recovery for a BPSK signal
Decimator
Filters and decimates
DigitalModulator DigitalDemodulator
Modulates or demodulates bits or symbols, respectively; supports PSK and QAM
Interpolator
Interpolates and filters (pulse shaping)
MultirateSynchronizer
Carrier recovery and symbol synchronization
SymbolSyncPoly
Symbol synchronization
USRP_Commander
Configures and controls the USRP device
ZFE
Zero forcing equalizer, removes the effects of the channel
Table 1. Selected OSSIE components.
INTERFACES Interfaces are for communicating between components. For a uses port (an output port in the push model used by the SCA) to be connected to a provides (input) port, the interfaces used by the two ports must be compatible. The OSSIE project provides a set of standard interfaces that specify data formats to be used by standard ports for common tasks. In addition, the user is not limited by the supplied interfaces; if needed, new interfaces can be developed to support the needs of a new application. For example, a modified set of interfaces was developed to address the needs of the cognitively intrepid radio emergency network (CIREN) waveform application.
APPLICATIONS A wide variety of applications have been developed using the tools and artifacts of the OSSIE project. These applications include cognitive radio systems, a distributed receiver, and a proof-of-concept embedded radio. We highlight the ossie_demo waveform that is distributed with the OSSIE project, and CIREN, a waveform application that was designed to address a problem posed in the SDR Forum’s 2007 Smart Radio Challenge regarding dynamic spectrum access for first responders.
DEMONSTRATION WAVEFORM The ossie_demo waveform is a simple baseband simulation of a quadrature phase shift keying (QPSK) communications link. The waveform consists of three components. The TxDemo component is a transmitter that repeatedly sends a test vector of 1024 bits. The signal from TxDemo is then processed in the ChannelDemo component, which adds white Gaussian noise and imposes a phase shift on the signal. The RxDemo component demodulates the received signal and compares the
52
demodulated data with the known test vector to calculate a bit error rate. Using the Waveform Dashboard and the ALF plot tool, the user can interactively vary the standard deviation of the noise and the phase shift imposed by the ChannelDemo component while observing the signal constellation, as shown in Fig. 3. Thus, a student can easily observe the effect of channel parameters on both the signal constellation and bit error rate.
CIREN First response teams following major disasters such as earthquakes or floods require accurate and reliable radio links to provide voice and data communications between team members. Frequently, however, emergency teams cannot intercommunicate due to relying on fixed-frequency legacy radios. One solution proposed was CIREN, a novel system for deploying SDR handsets containing voice and multimedia data communication capabilities. The SDR handsets function as nodes in a frequency-agile mobile ad hoc network that exploits available spectrum while avoiding interference to and from legacy users. The radios utilized the flexibility of the SCA for development, debugging, and deployment. A full operational description of CIREN is not possible due to space limitations. Instead, we would like to focus our attention on describing how the development of complex waveforms can be leveraged by specific SCA features and the OSSIE project toolset. Debugging waveforms is a critical step necessary for application deployment. Physical layer synchronization can be one of the most challenging steps in the dependable reception of data in short-burst packet radio protocols, particularly in a multiple access spectrum environment exhibiting heterogeneous signals. The component model of the SCA allows for a modular design of applications, wrapping DSP algorithms in reconfigurable blocks. The components’ ports can be connected to software debugging tools, such as scatter plots, spectrum analyzers, or sampled data capture for offline analysis. This model has several advantages over conventional modular DSP designs: the validity of components can be monitored by making the connection at runtime without regenerating the binary executables (e.g., recompiling with traditional #ifdef DEBUG statements is not necessary). This is an extremely powerful advantage of the SCA: the target platform can be monitored and debugged through CORBA ports over the transport layer by another processor. This significantly relaxes the programming constraints of the developer and provides a method to ensure the executable operates as expected on the target platform. The development stages of CIREN relied heavily on the tools provided by the OSSIE project including OWD and ALF. CIREN itself was designed to be modular such that, when possible, each stage of its component development appended to its compliment (see the previous section for a list of selected components). This in particular includes packet encoders/decoders, digital modulators/demodulators, and interpolators/decimators. When connected together in a complementary fashion, nearly the entire transceiver chain could be simulated before connecting to the RF hardware.
IEEE Communications Magazine • October 2009 Authorized licensed use limited to: Tabriz University. Downloaded on October 28, 2009 at 08:49 from IEEE Xplore. Restrictions apply.
AGUAYO GONZALEZ LAYOUT
9/21/09
1:15 PM
Page 53
In order to achieve the SCA goals of reuse and technology insertion, it is necessary to develop software components that are correct, robust, maintainable, and reusable. These components need to be tested for architectural and operational compliance.
Figure 3. Interactive control and observation of the ossie_demo waveform using the Waveform Dashboard and the ALF waveform application visualization and debugging environment.
TESTING In order to achieve the SCA goals of reuse and technology insertion, it is necessary to develop software components that are correct, robust, maintainable, and reusable. These components need to be tested for architectural and operational compliance. Testing for architectural compliance is performed to verify that the interfaces required by the SCA are implemented correctly. If the components are developed using our tools (i.e., OWD) and no modifications are performed, the developer can be confident that the resulting artifacts are consistent with the interpretation of the specifications in the OSSIE project. Testing for operational compliance is performed in order to verify that the component performs its intended functionality correctly (e.g., a filter filters and a scrambler scrambles). This can be difficult and is completely component-dependent. There are some available tools that can be used to facilitate this process. Internally, the OSSIE team uses cxxTest [10] to define, implement, execute, and store test cases. It is important to keep and update these tests as the component evolves. We must remember that test vectors and test cases can be as important as the actual implementation of a software module, if not more. It is important to mention that the JTRS Test and Evaluation Laboratory (JTEL) has developed tools to help evaluate SCA compliance. For SCA version 2.2, JTEL developed the JTRS Test Application (JTAP) and Waveform Test Tool (WTT). The former tests core frameworks (e.g., OSSIE CF) to make sure they implement all the interfaces correctly, and the latter tests that applications can be deployed and managed with a compliant framework. For SCA version
2.2.2, the most recent version at this time, the functionality of WTT was merged into JTAP.
EMBEDDED PLATFORMS Fundamentally, an embedded processor can perform the same operations as a high-end processor, given unlimited memory and time. We know that in the real world these conditions are not possible. The OSSIE team is currently working on porting the CF to different embedded platforms. To this end, the operational environment must be tailored to operate with constrained resources. There are several aspects of the SCA operational environment that require special attention in embedded platforms: the OS, middleware, transport mechanisms, XML parsing, file systems, and component instantiation. The SCA requires the use of a POSIX-compliant OS and minimumCORBA to support the component model and the rest of the OE. For the OS, given the success of some embedded Linux distributions, it is more and more common to find open implementations for a large number of embedded platforms. There is also a variety of commercial operating systems available for almost any platform, although some may be expensive. If there is no available POSIXcompliant OS for the target platform, it is possible to emulate the functionality of the SCA Application Environment Profile (AEP) described in SCA 2.2.2 Appendix B for the applications by using native OS calls, while allowing the CF full access to the native OS. While this approach is not technically SCA-compliant, it can be argued that the critical functionality and the ability to deploy compliant waveforms is maintained. If a non-POSIX OS is used, it is necessary to consider the scheduling mechanisms followed by
IEEE Communications Magazine • October 2009 Authorized licensed use limited to: Tabriz University. Downloaded on October 28, 2009 at 08:49 from IEEE Xplore. Restrictions apply.
53
AGUAYO GONZALEZ LAYOUT
9/21/09
The SCA requires the parsing of XML files at runtime to obtain deployment and configuration information from the Domain Profile. For example, the ApplicationFactory interface must read a SAD file in order to know what components are included in a given waveform and the respective connections.
1:15 PM
Page 54
the OS. Some embedded OSs implement a preemptive scheduling mechanism where the active task with the highest priority is scheduled for execution, no matter how many other tasks are waiting, or for how long. This characteristic allows deterministic execution, crucial in real-time systems, but makes the developer completely responsible for task scheduling and priority assignment. In terms of middleware, there are several open source implementations that can be used with little or no modification on many platforms, although major porting efforts may be necessary sometimes. There are also commercial implementations for a growing number of platforms. These cost more, but the extra efficiency and support that come with them can be well worth the price. The SCA requires the parsing of XML files at runtime to obtain deployment and configuration information from the Domain Profile. For example, the ApplicationFactory interface must read a SAD file in order to know what components are included in a given waveform and the respective connections. Full XML parsing can be a complicated task for certain embedded processors, and there may not be many tools available to perform it. There are different processing elements that can enhance the capabilities of an embedded platform. For instance, DSPs are specialized microprocessors designed specifically for real-time digital signal processing. Initially, DSPs were relegated as secondary elements in the SCA, requiring a hardware abstraction layer (HAL) for connectivity. Ongoing improvements in development tools and middleware technology allow the full integration of DSPs into SCA systems. This allows developers to take advantage of the cost and power efficiency of DSPs, while still maintaining SCA compliance. The OSSIE team conducted a feasibility study for the integration of TI C64 DSPs into the SCA. At the time of development, there was no POSIX OS available for the C64 platform. The native DSP/BIOS operating system was used instead, which is a preemptive multithreaded real-time OS for TI DSPs. Because of this and the lack of a memory management unit, certain aspects of the CF needed to be modified. For example, all memory management was left to the developers, and certain OS calls, such as fork(), were not supported. As for middleware, e*ORB, a commercial implementation of minimum CORBA for TI DSPs developed by PrismTech, was used. XML parsing was implemented in a two-step approach, where an offline translation of the XML files into a simplified format is performed. The simplified format only keeps the most important information from the profile files and stores it in a simple text file. At the conclusion of the project, we were able to deploy a modified version of the OSSIE demo waveform into the C64 platform, corroborating the feasibility of fully integrating DSPs into an SCA solution. A more detailed explanation of this project can be found in [11].
OSSIE IN EDUCATION AND RESEARCH The OSSIE project supports the graduate electrical engineering curriculum and research at both
54
Virginia Tech (VT) and the Naval Postgraduate School (NPS). Each university offers a course in SDR design oriented toward communications engineering graduate students. Due to its complexity, SDR design techniques are best learned via a combination of lectures, reading, laboratory exercises, and design projects. Both universities rely on the OSSIE project to provide a fundamental design tool for laboratory exercises and design projects. The OSSIE project provides excellent design tools for the course because they are easy to learn, highly capable, and based on modern design methodologies, such as component-based and architecture-consistent design. Students in the course get familiarized with the OSSIE project by completing five selfexplanatory laboratory exercises. These exercises have also been used in tutorials at the annual VT Symposium on Wireless Communications and at the SDR Forum’s annual Technical Conference, and are available for free Internet download from the OSSIE site [1]. The first laboratory exercise introduces the student to the OSSIE project and the OEF. In this exercise the student uses provided software components to construct and run a simple waveform application. This exercise also introduces the student to the process of generating the XML code that defines the radio’s domain profile. In all the laboratories, examining the generated XML files is straightforward, which gives the students further insight into the core framework, the waveform application, and interactions between the two. In the second laboratory exercise the student uses provided software components to construct and run a simple QPSK transmitter. In this exercise the student learns how to tailor software components using component properties, a method to parameterize components, which simplifies programming and facilitates software component reuse, a key element in efficient software engineering. In the third exercise the student learns how to design and build new SCA-based software components using the component creation capability of OEF. The fourth exercise teaches the student how to interface their software, executing on a personal computer, with input and output hardware including the USRP. In the fifth laboratory exercise students use the OSSIE CF, the USRP, the computer’s sound card, and local AM radio stations to design, build, and test an SCA-based AM radio receiver. Additional laboratory exercises that address digital communications and distributed applications are under development. The OSSIE project is also used for course projects. In the past these have included a software defined FM receiver, a software defined oscilloscope, and a software defined spectrum analyzer. Several Master’s degree theses have been completed in SDR design using OSSIE’s CF and design tools. These include software defined designs for transceivers for IEEE-802.11a, IEEE802.16, and IS-95B signals, and synchronization of an IEEE 802.11g receiver. With the recent addition of drag-and-drop waveform construction and auto-generated customizable waveform GUIs, and planned support for cross-compilation of component code for embedded platforms, the tools developed for the OSSIE project allow students to rapidly inte-
IEEE Communications Magazine • October 2009 Authorized licensed use limited to: Tabriz University. Downloaded on October 28, 2009 at 08:49 from IEEE Xplore. Restrictions apply.
AGUAYO GONZALEZ LAYOUT
9/21/09
1:15 PM
Page 55
grate signal processing concepts and code into instructive and practical projects.
CONCLUSIONS The OSSIE project is an academic initiative that promotes research and education of future communication engineers in the field of SDR. It provides an implementation of the SCA, and includes a tool suite and a growing library of SDR software components to aid wireless engineers in the rapid prototyping of SDR applications. The software components may be reused or modified for additional applications. An example of this workflow has been the design and development of the CIREN waveform at Virginia Tech. The flexible nature of OSSIE allows developers to rapidly prototype DSP applications, target embedded platforms, and design and test cognitive radios. It is important to mention that there are other available SCA implementations, including SCARI from Communication Research Center Canada and dmTK from Harris Corporation. These implementations are fully compliant with the specifications, and their usage may require a license. OSSIE provides an open source alternative which includes educational materials that help users become familiarized with the main principles of the SCA. The OSSIE project allows and encourages developers to modify and improve its current implementation. The continued contributions from the OSSIE team and the general SDR community will continue expanding the project’s capabilities and yield exciting new applications for education and research.
ACKNOWLEDGMENTS The OSSIE project began as a volunteer effort by Dr. Robert and students at Virginia Tech. Continued work has been made possible by support from the National Science Foundation (under Grant no. 0520418), ETRI, the Joint Program Executive Office Joint Tactical Radio System, the Office of Naval Research, Science Applications International Corporation, Tektronix, Texas Instruments, and U.S. Army CERDEC, and by student work on independent study and research projects. The authors thank the many developers who have contributed to the project.
REFERENCES [1] “Open-Source SCA Implementation::Embedded (OSSIE);” http://ossie.wireless.vt.edu [2] J. H. Reed, Software Radio: A Modern Approach to Radio Engineering, Prentice Hall PTR, 2002. [3] Joint Tactical Radio System (JTRS); http://jpeojtrs.mil [4] Software Communications Architecture Specification, v. 2.2.2; http://sca.jpeojtrs.mil/ [5] C. R. Aguayo González, C. B. Dietrich, and J. H. Reed, “Understanding the Software Communications Architecture,” IEEE Commun. Mag., vol. 47, no. 9, Sept. 2009. [6] J. Bard and V. J. Kovarik, Jr., Software Defined Radio: The Software Communications Architecture, Wiley, 2007. [7] E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994. [8] J. Snyder, S. H. Edwards, and C. B. Dietrich, “An Eclipsebased IDE for OSSIE Waveforms and Components,” SDR Forum Tech. Conf. ‘08, Washington, DC, Oct. 2008. [9] Ettus Research LLC; http://www.ettus.com [10] CxxTest; http://cxxtest.tigris.org/ [11] C. R. Aguayo González, “Design and Implementation of an Efficient SCA Framework for Software-Defined Radios,” M.S. thesis, Virginia Tech, 2006.
BIOGRAPHIES CARLOS R. AGUAYO GONZALEZ (
[email protected]) is a Ph.D. candidate in electrical engineering at Virginia Tech. He received a B.S. from Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM) Campus Guadalajara, Mexico, in 2000 and an M.S. from Virginia Tech in 2006. He worked from 2000 to 2002 as a software engineer for Mixbaal, Guadalajara, Mexico, developing spread spectrum radios for last-mile applications. His current research interest is efficient implementations of SDR, including their validation, certification, and testing. CARL B. DIETRICH (
[email protected]) is a research assistant professor at Virginia Tech, where he did graduate studies after graduating from Texas A&M. He worked with the Defense Information Systems Agency, Arlington, Virginia, and Bell Northern Research, Richardson, Texas, and has conducted research on adaptive and diversity antennas and radio wave propagation. His current work is in SDR and includes leading projects related to the OSSIE open source effort. He currently chairs the SDR Forum Educational Work Group, is a member of ASEE and Eta Kappa Nu, and is a Professional Engineer in Virginia. FRANK E. KRAGH (
[email protected]) joined the Naval Postgraduate School as an assistant professor of electrical and computer engineering in 2003. He teaches digital communications, forward error correction coding, and SDR. His interests include cognitive signals intelligence systems, MIMO systems, SDR, co-channel interference mitigation, and satellite communications. He earned three degrees in electrical engineering: a B.S. from Caltech in 1986, an M.S. from the University of Central Florida in 1990, and a Ph.D. from the Naval Postgraduate School in 1997. He is active in the annual Asilomar Conference on Signals, Systems, and Computers; the annual MILCOM conference; and the SDR Forum.
The OSSIE project allows and encourages developers to modify and improve its current implementation. The continued contributions from the OSSIE team and the general SDR community will continue expanding the project’s capabilities and yield exciting new applications for education and research.
SHEREEF SAYED (
[email protected]) is a Master’s of Science student at Wireless@VT under Dr. Reed. He is one of the original developers of the OSSIE project, and continues to develop and maintain the current distribution alongside the OSSIE team. His research interests include coarsegrained configurable computing, models of computation, and embedded platform development and support. H ARIS I. V OLOS (
[email protected]) is a doctoral candidate in Virginia Tech’s Bradley Department of Electrical and Computer Engineering. He received an M.S. in electrical engineering from Virginia Tech as a scholar in the Cyprus America Scholarship Program (CASP), and a B.S. (summa cum laude) in electrical engineering from Old Dominion University. His research interests are artificial intelligence methods for multi-antenna systems, SDRs, and propagation measurements and analysis for ultra-wideband signals. He is a member of the Wireless@VT research group. JOSEPH D. GAEDDERT (
[email protected]) received his B.S. degree in electrical engineering from the University of Kentucky in 2002 and his M.S. at Virginia Polytechnic Institute and State University in 2005 on the topic of parametric estimation of fading channels and their role in adaptive radios. Currently he is a Ph.D. student pursuing a degree in cognitive and softwaredefined radios at Virginia Tech. His research interests concern the reduction of receiver complexity in reconfigurable radio platforms, and the parametric estimation of synchronizers in the context of filterbank multicarrier transmission schemes. P. MAX ROBERT (
[email protected]) earned his B.S. in electrical engineering from Case Western Reserve University in 1996, and his M.S. and Ph.D. in electrical engineering from Virginia Tech in 1998 and 2003. During his graduate work at Virginia Tech, he received the Bradley fellowship from the Bradley Department of Electrical and Computer Engineering at Virginia Tech, the America Online Wireless Home Networking Technologies fellowship, and the Paul E. Torgersen Graduate Research Excellence award. In 2003 he became an IC postdoctoral research fellow, with a research focus on SDR. During his fellowship, he started the OSSIE project. He is currently a consultant. JEFFREY H. REED [F] (
[email protected]) is the Willis G. Worcester Professor in the Bradley Department of Electrical and Computer Engineering and director of Wireless@Virginia Tech. His area of expertise is in software radios, cognitive radios, wireless networks, and communications signal processing. He is the author of Software Radio: A Modern Approach to Radio Design (Prentice-Hall, 2002) and An Introduction to Ultra Wideband Communication Systems (Prentice-Hall, 2005).
IEEE Communications Magazine • October 2009 Authorized licensed use limited to: Tabriz University. Downloaded on October 28, 2009 at 08:49 from IEEE Xplore. Restrictions apply.
55
