SOFTWARE-DEFINED RADIO, THE JTRS INITIATIVE, AND THEIR IMPLICATIONS FOR HF COMMUNICATIONS Eric Koski Harris Corporation RF Communications Division 1680 University Avenue Rochester, New York 14610 U.S.A.
[email protected] ABSTRACT The Software Defined Radio (SDR) concept is profoundly changing the technology, business, and user experience of wireless communications. Military SDR initiatives, chief among them the Joint Tactical Radio System (JTRS) initiative of the US Department of Defense, have played a leading role in defining the technological roadmap for practical application of the SDR concept. In this paper, we
1.
Provide an overview of the concept, motivations, and technological underpinnings of Software Defined Radio Provide an overview of the US JTRS program, examining its key technologies such as the Software Communications Architecture (SCA), the program strategy, progress to date, challenges, and future prospects Discuss the impacts of SDR and JTRS on vendors, purchasers, and users of military wireless communications systems Discuss specific impacts of SDR and JTRS on HF communications, and the progress toward and prospects for software defined HF-capable radio systems. INTRODUCTION
The subject matter of Software Defined Radio is vast and constantly evolving. The JTRS program is so complex as to defy succinct description. Both are very important subjects likely to have farreaching impacts on the lives and careers of those involved in using, purchasing, or developing military communications systems. The goal of this paper is to provide a useful broad introduction to the SDR concept and the JTRS program for readers with a need to understand these phenomena and the issues surrounding them without delving into the enormous amount of detailed technical information on SDR concepts and technical approaches, and on the architecture and key technologies of JTRS. We also provide in this paper a broad overview of the history of the JTRS program, examining it for signs as to where the program may be going and what its results and implications may be. Section 2 of the paper presents the concept of Software Defined Radio and examines a variety of technical approaches through which the ‘ideal software radio’ can be approached or approximated in a radio design to different degrees, describing some of the trade-offs and key technical issues faced in selecting a design approach. Section 3 provides an overview of the US JTRS program including its organization, goals, key activities (the JTRS procurement programs), and strategy. Section 4 briefly describes some key technologies of JTRS including the Software Communications Architecture; however, this is a very deep subject in itself, which cannot be done adequate justice in this paper. (Fortunately, many other information sources are available.) Section 5 provides overviews of the design, implementation, and validation processes through which JTRS products (waveforms, radio ‘platforms’, and complete radio systems) are developed and certified. Section 6 summarizes the history and status of the JTRS program, analyzing some of the cost and schedule problems experienced by the program and highlighting some areas in which the goals of the JTRS initiative are being more successfully realized. Section 7 considers the likely impacts of JTRS on US military
communications, the military communications industry, vendors, the commercial wireless marketplace, and non-US (specifically European) prospective developers and users of military SDR systems. Section 8 briefly examines the prospects for software-defined HF radio systems, either based on or independent of the JTRS program, and Section 9 draws a few conclusions. 2.
THE CONCEPT OF SOFTWARE DEFINED RADIO
2.1 RADIO ARCHITECTURE OVERVIEW Link / network protocols
Antenna subsystem
RF processing (up- and downconversion, filtering)
Baseband modulation / demodulation
INFOSEC (COMSEC, TRANSEC)
Source coding (Vocoders, etc.)
Network interfaces
User interfaces
Figure 1. Radio architecture functional overview
Figure 1 provides a coarse-grained functional block diagram of a modern wireless communications system node. An antenna subsystem provides the interface between the RF processing subsystem and the wireless medium, preferably in such a way as to minimize path loss across the communications link. RF processing subsystems up- and down-convert the communications signal between the baseband spectrum of the information payload it conveys and the RF band in which it is communicated over the wireless medium, at the same time filtering the signal so as to remove undesired signals (out-of-band interference) and artifacts resulting from the conversion processes themselves. Digital communications systems typically require additional modem subsystems responsible for modulating and demodulating digital data to and from a baseband analog signal representation, source coding subsystems required to convert analog program data (voice, images, video) to and from the digital representation in which they are communicated, an information security subsystem responsible for information security functions (COMSEC, TRANSEC, NETSEC, etc.), and subsystems implementing (where needed) the data link, network, transport, and other protocol layers of a modern digital communications network such as the worldwide Internet. Of the functional blocks shown in Figure 1, many would not have existed in a typical transceiver design of 40 years ago, which might have been used only for analog voice communications: AM, SSB, or FM. Source coding, data protocols, and INFOSEC were usually entirely absent, and baseband processing functions were very limited. The RF processing functions, on the other hand, have been an enduring component of radio designs (for obvious reasons), and continue to play a crucial role in determine the achievable performance, size, weight, and power consumption of radio designs, so it is useful to start by focusing on these functions and considering how they have been impacted by the infiltration of digital and software technology into radio designs. Due to time and space limitations, in this paper we will focus our attention primarily on the receiver architecture (following the practice of other authors) since the design challenges faced there are somewhat more difficult; many of the challenges faced in transmitter design have analogues in receiver design. 2.2 RF ARCHITECTURE EVOLUTION 2.2.1 Traditional RF Architectures Figure 2 provides a fairly representative depiction of a modern multiple-conversion receiver design [1][2]. In this design,
product detector audio output BPF
LNA
image filter
IF / image filter
1st LO
AGC
IF filter
2nd LO
AGC
LPF
BFO
Figure 2. Traditional RF receiver architecture
1. The input bandpass filter provides an initial coarse selection of the desired band, attenuating signals outside the radio’s operating range and avoiding overloading of the first mixer by out-ofband signals. 2. The Low Noise Amplifier (LNA) amplifies the filtered RF input signal to a level compatible with the downstream processing elements. Residual undesired components are also amplified. 3. The image filter is necessary to reduce the low-frequency out-of-band signal components that could otherwise be imaged into the desired band by the mixer. 4. The first mixer down-converts the filtered input signal to the first Intermediate Frequency (IF). Doing this permits selectivity to be achieved with filters at a fixed frequency. It also permits gain to be introduced in stages, reducing the Local Oscillator (LO) power requirements. 5. The IF / image filter provides a narrower bandpass selection of the desired band, and suppresses the frequency components that could be imaged into the desired band by the second mixer. 6. The filtered first IF signal is amplified, providing part of the receiver gain required for the needed level of receiver sensitivity. 7. The second mixer converts the first IF signal to a second IF frequency at which filtering can be effectively employed to fully achieve the desired receiver selectivity. (In a partially digital receiver design, this may also be a frequency at which analog-to-digital (A/D) conversion can be performed.) 8. The second IF filter is a sharp bandpass filter selecting the desired band as much as possible. 9. The second IF amplifier provides the major part of the receiver gain used to achieve the required receiver sensitivity, and places the signal at the desired level for input to the product detector, which down-converts the signal to its final audio frequency. The benefit of the multiple-conversion design is that it permits filtering and amplification to be done in stages. Doing the filtering in stages permits filters with relaxed performance requirements to be used in each stage. This makes this design especially desirable for modes with small channel spacing, where selectivity is especially important. Applying gain in multiple stages reduces the mixer LO power requirements and relaxes the requirements for isolation between the LO and the mixer signal input. The cost is potentially higher parts count and complexity, potentially higher power consumption (overall), and additional potential for spurious signals resulting from the multiple mixing stages. 2.2.2 Design challenges What are (some of) the fundamental challenges faced in the design of a radio’s RF subsystem? The key performance desiderata of RF receiver subsystem design are sensitivity, selectivity, dynamic range, and the resulting signal-to-noise ratio. The key constraints that must be balanced against them are cost, size, weight, and power consumption. Some of the critical design issues that must be managed in order to appropriately balance these objectives and constraints are [1][2]:
Control of signal levels. At each stage, it is desirable to keep the level of the incoming signal well above the noise floor – for optimal sensitivity, the higher the better, limited by the amount of gain that can be achieved at each stage without distortion. At the same time, higher signal levels require higher LO output levels, resulting in increased power consumption. Achieving the
appropriate gain distribution typically requires Automatic Gain Control (AGC), with different bands and waveforms having different requirements. Selectivity must be achieved through the use of filtering to exclude interfering out-of-band signals, in order to prevent high-level signals from causing saturation (clipping) or forcing the desired input signal to be attenuated to a level at or below the internal noise floor. Receive performance is further complicated by the numerous ways in which interfering signals can be created or multiplied by the receive subsystem itself. The local oscillator and signal inputs to each mixer must be carefully isolated to avoid creating spurious signals or DC bias. Each mixer translates in frequency not only the desired signal but interfering signals from other band regions, potentially introducing strong interfering signals into the frequency band of the desired signal; preventing this requires that each mixer be preceded by a high-quality image filter to exclude such signals as much as possible. Intermodulation, cross modulation, and reciprocal mixing all create increased noise levels or spurious signals, and must be minimized through careful component selection and circuit design. Dynamic range is achieved at the low end by keeping internal noise levels as low as possible, and by amplifying the desired signal to well above the noise floor as early as is practical. At the high end, dynamic range with respect to the desired signal is achieved through gain control preventing signal distortion. With respect to out-of-band signals, it is achieved through filtering eliminating these signals as early as is practical.
2.2.3 Forces driving evolution What recent forces of change have driven evolution of RF subsystem designs? What new challenges have resulted? Recent changes in communications technology and user requirements have placed the RF subsystem design approach exemplified by Figure 2 under increasing pressure for change:
Analog RF designs achieve high levels of performance in the face of these challenges only through ingenuity, careful design practices, carefully selected and matched components, and precisely controlled manufacturing. Changes in component availability and characteristics and in manufacturing processes can make specified levels of performance difficult to maintain over a product’s lifetime [1]. The required components and processes are often expensive and haven’t lent themselves to miniaturization or dramatic cost reduction through manufacturing economies to the extent that digital technology has. Advances in communications technology have resulted in an explosion of new waveform designs, protocols, and air interface standards, as well as changes in spectrum allocation and usage patterns, creating enormous pressure for increased flexibility and reconfigurability of radio products. The analog design approach of Figure 2 accommodates these requirements only to a limited extent and often at the cost of significant performance tradeoffs. Increasingly, users have requirements to communicate using multiple air interfaces in different bands. The alternative to the undesirable approach of carrying one radio per air interface is a ‘multiband’ radio supporting multiple standards and frequency bands, and easily switched among them. One can design a ‘multiband’ radio by combining multiple ‘RF chains’ – each optimized for a single band – into a single product. This has been done many times – indeed, is hard to avoid completely – but has obvious detrimental impacts on size, weight, cost, complexity, power consumption, and often performance. Military communicators have had to try to cope with the proliferation of military communications bands, waveform designs, and standards. Inter-service and multinational joint operations have created demanding interoperability requirements, forcing military communicators to contemplate taking multiple radios along on each mission. At the same time, civilian users are faced with diverse civil communications networks and standards, and the dilemma of which device to buy and to which network to subscribe. Standardization (GSM) has made such decisions easier in some areas, but evolving technology inevitably complicates the situation.
2.2.4 Applications of digital and software technology How have digital and software technology been applied toward meeting these challenges? In response to these challenges and other emerging requirements, the infiltration of digital and software technology into radio systems was already well underway even before the software radio ‘revolution’ was first declared [3]: 1. As radios came be used for data communications as well as for voice, modems and digital data interfaces became routine elements of radio systems, populating the baseband processing functional block of Figure 1. 2. With data communications came the possibility of eavesdropping and the need for information security. Digital logic and integrated circuit technology made digital encryption and transmission security (e.g., frequency hopping) techniques practically achievable. 3. Around 1980, microprocessors began playing significant roles in radio systems, focused at first on control, switching, and data handling. 4. In the early 1980s, digital signal processing became increasingly practical, and came to be the dominant approach to realizing baseband processing functions: modulation and demodulation. At the same time, Digital Signal Processors (DSPs) made digital source coding – specifically vocoders – possible. Digital voice communications techniques proliferated, driven initially by security requirements in many cases, but also increasingly by the ability to achieve increased voice quality and communications reliability at reduced cost by these means. 5. At first, A/D and D/A conversion was performed solely at baseband. Increases in the capability and performance of available A/D and D/A converters and in the processing power of DSPs made possible around 1990 the first ‘digital radios’ in which A/D and D/A conversion were performed at an IF frequency and the last frequency translation stage was performed entirely by digital logic. In the radio receiver, this resulted in the kind of architecture shown in Figure 3 [1][3]. These first digital radios were typically still limited to a single band, but often achieved a degree of flexibility by supporting different waveforms (DSP-based FSK or PSK baseband modems) and protocols in software.
ADC
BPF
LNA
image filter
IF / image filter
AGC
1st LO
IF filter
IF digital output
Digital IF
Modem, &c ...
AGC
2nd LO
Figure 3. Dual-conversion receiver with digital final IF
Where it could be inserted, digital technology often provided solutions to what had formerly been vexing design problems. In particular, digitizing the final IF signal and performing the final downconversion step digitally eliminated carrier offset and imaging issues arising from the analog product detection process [1], and was an efficient way of preparing the signal for DSP-based baseband processing. In other areas, digital and software-based control provided elegant solutions to challenges such as adaptive gain control, automatic antenna tuning, and pre-distortion of exciter signals to compensate for transmitter nonlinearity. Where it replaced analog circuitry, digital processing provided gains in performance, manufacturability, supportability, reliability, and often cost. These demonstrated benefits and the ever-increasing requirements for new functionality, versatility, and interoperability gave birth to the concept of a software defined radio, a radio whose operational capabilities are defined by the software installed in it.
2.3 SOFTWARE DEFINED RADIO RF ARCHITECTURE APPROACHES What might the RF subsystem of a software defined radio look like? The ultimate software radio would perform A/D and D/A conversion directly at the antenna, with at most a final amplification stage being realized in analog circuitry. This remains an unrealistic approach in most situations; however, the closer the analog/digital threshold can be pushed toward the antenna, the more completely the vision and benefits of software defined radio can be realized. In practice, a variety of architectural approaches have been used in software defined radio systems. The following sections provide a concise overview of common approaches, focusing on receiver architectures; analogous approaches are available and commonly used in the design of softwaredefined transmitters. 2.3.1 Tuned RF Receiver Figure 4 depicts one possible tuned receiver architecture. In this architecture, the incoming RF signal is bandpass filtered to remove some out-of-band signals; the filtered signal is amplified to raise it above the internal noise floor and to scale it appropriately for the A/D converter (ADC). A/D conversion occurs at a sample rate of at least twice the RF carrier frequency; further filtering and down-conversion to baseband are performed digitally.
ADC
BPF
LNA
digital output
Digital down-conversion
Baseband processing
...
AGC
Figure 4. Tuned RF receiver architecture
This architecture achieves almost the maximum fidelity to the software radio vision, and potentially achieves a very high degree of flexibility and programmability. However, these benefits carry with them significant costs and limitations. Sampling at more than twice the carrier frequency may be simply impossible to achieve, or may require extremely expensive and power-hungry conversion components. At the current state of conversion technology, there is a straightforward trade-off between sample rate and resolution: faster sampling comes at the price of reduced dynamic range. Improved ADC performance is becoming available only slowly and at the price of large R&D investments [3]. After conversion, the digital signal processing must also be performed at a high bandwidth, again resulting in increased cost and power consumption [1][4]. Achieving reasonable selectivity places very stringent demands on the initial bandpass filter, which must be tuneable if multiband capability is to be achieved. In practice, the initial filter is able only to select the general band of interest, with further selectivity requiring digital filtering after conversion; however, this allows interfering signals to enter the ADC, compromising dynamic range [1]. For all of these reasons, this architecture has seen little (if any) recent commercial application. However, due to the relatively low sample rates required, this has been proposed as a potentially viable emerging architecture for HF [5]. 2.3.2 Direct Conversion Architecture Figure 5 depicts a possible direct conversion architecture – so-called because a single mixing stage directly converts the RF signal to baseband. This design approach places much less stringent requirements on the ADC, while retaining simplicity and a low parts count. Use of only a single mixing stage permits reduced power consumption by comparison with multiple-conversion architectures.
ADC
BPF
LNA
image filter
AGC
LPF
Baseband digital output
Modem, &c ...
AGC
LO
Figure 5. Direct conversion architecture
Realizing high levels of performance can be difficult [1][4]. Isolation of the mixer inputs is extremely critical since self-mixing of the LO signal can result in a large DC bias, although suitable DSP-based bias compensation techniques are available. Phase stability of the local oscillator is extremely critical since phase noise will occur at baseband frequencies. In spite of its limitations, this architecture is considered promising for a variety of low-power and low-cost software radio applications, and is supported by chip sets from a variety of manufacturers [3]. 2.3.3 Single- or Dual-Conversion Heterodyne A further step away from the ‘ideal software radio’ approach brings us back to the family of heterodyne RF architectures. We have already seen a representative dual-conversion architecture in Figure 3. Figure 6 depicts one possible single-conversion architecture, differing from the direct conversion architecture in that the initial analog mixing translates the signal frequency to an IF rather than directly to baseband; the final conversion to baseband is performed digitally. ADC IF filter
BPF
LNA
AGC
IF digital output
LO
AGC
I
Digital IF
Modem, &c ...
90°
ADC Q IF filter
AGC
Figure 6. Single-conversion architecture with quadrature conversion
In this example, I&Q down-conversion and quadrature sampling are used to create the separate inphase and quadrature sample streams required for frequency- or phase-modulated baseband signals. Because of their performance advantages, single- and multiple-conversion heterodyne architectures are continuing to play a significant role in software defined radio in spite of the significant analog processing they retain at the RF front end. Even in these architectures, software (especially DSP) capabilities can play a significant role in enhancing system flexibility and performance [1]:
Software-based control and switching will play an indispensable role in any multiband architecture, controlling LO frequencies and selectively activating and switching band-specific RF processing elements, as well as controlling sampling rates and resolution for different air interface standards. Software control will play a key role in power management, especially where a multiband architecture requires multiple RF chains that must be selectively activated and powered off. Software-based adaptive gain control can play an important role in optimizing dynamic range. Software-based compensation algorithms can reduce or eliminate performance penalties resulting from various kinds of bias and distortion. One interesting example is the use of DSP-based predistortion techniques to compensate for power amplifier nonlinearity. DSP is the key enabling technology for the emerging area of smart antennas and space-time processing, which is yielding dramatic gains in performance in systems to which it can be applied [1].
As we’ve seen, the software radio designer has a variety of candidate architectures to consider, with different benefits and trade-offs. In many cases, the same system may use different architectures at different points in the system. For instance, in a cellular mobile radio system, a direct conversion architecture may be attractive for handsets because of its low parts count, size, and weight; higher transmit power levels at the cell site can be used to compensate for receivers’ sensitivity, selectivity, and dynamic range limitations. Meanwhile, at the cell site, receiver performance is at a premium due to low transmit power level from the handset (battery operation, inefficient antenna), while size, weight, and cost at the cell site can be less of an issue, making use of a multiple-conversion heterodyne architecture attractive. 2.4 KEY DESIGN CONSIDERATIONS 2.4.1 Analog-to-digital conversion As we have seen, one key objective of software defined radio designs is to perform the frequency translation and filtering processes of the RF subsystem using software or reconfigurable digital hardware as much as possible. A straightforward consequence of this objective is that software defined radio designs may place extremely stringent requirements on the A/D and D/A conversion components of the radio hardware. In the extreme case of the ‘pure’ tuned receiver architecture (with Nyquist sampling), the sample rate of the converter must be more than twice the maximum carrier frequency the radio is to support. For many systems, this requirement is simply not feasible to meet. Even where converters nominally supporting the required sample rate are available, there is a trade-off between sample rate and resolution: increased sample rate is achieved only at the price of lower resolution (fewer bits). To the extent that the designer hopes to achieve selectivity performance through digital filtering, the signal input to initial A/D conversion will necessarily contain both desired in-band and undesired out-of-band signals; the resolution of the A/D converter becomes a key factor limiting the radio’s dynamic range. The achievable combinations of sample rate and resolution have been increasing only slowly as technology is refined, and are ultimately limited by the Heisenberg Uncertainty Principle [3]. Combinations of sample rate and resolution near the technology threshold are achieved only at high cost and power consumption. Superconducting electronics have been proposed as a potential way of transcending these limitations [6], and may soon find use in applications such as SATCOM ground stations and cellular base stations, but the necessary cryogenic cooling has not to date been feasible in portable radio equipment. One possible answer to this challenge is provided by ‘bandpass sampling’ or ‘undersampling’ [7]. In this technique, it is possible to choose a sample rate of between two and four times the bandwidth of the signal of interest, sample at this rate, and recover the signal even where the sample rate is well below the Nyquist threshold determined from the carrier frequency; in effect, the same sampling process accomplishes both digitization and frequency translation. However, this technique has three important limitations: 1. The input signal must have been bandpass filtered prior to conversion. The stop-band attenuation of the bandpass filtering is extremely critical, since undesired out-of-band signals at different multiples of the sample rate can be aliased into the same sampled frequency band occupied by the desired signal. 2. The carrier frequency and bandwidth of the signal to be digitized constrain the sample rates that can be used for bandpass sampling. For this reason, achieving the desired multi-band capabilities may require different sample rates, potentially limiting the flexibility of the hardware design unless multiple A/D converters are used. It may be possible to determine a single sample rate serving multiple bands; however, there appears not to be any single solution providing continuous frequency coverage over the very wide ranges contemplated for military SDRs [8]. 3. Even where sampling at a rate well below the carrier frequency is possible, the RF input signal must not exceed the analog input bandwidth limit of the A/D converter; commercially available converters are typically limited in this way [8]. Even where frequency translation is performed prior to digitization, the high bandwidths of new wideband waveform designs can place stringent requirements on A/D conversion performance [9].
Representative semiconductor devices in widespread use achieve 14-bit resolution at approximately 80 to 110 million samples per second – sufficient for Nyquist sampling of HF frequencies up to 30 MHz – with input bandwidths permitting bandpass sampling through the VHF frequency range [5][10]. 2.4.2 Sample rate conversion and multirate signal processing Any software defined radio system will typically be required to process digitized signals at a variety of sample rates, and frequently to convert between sample rates, for a variety of reasons:
The desired sample rate for baseband processing is usually a function of the communications standard being supported; different standards usually have different optimal rates. The sample rate resulting from initial A/D conversion may be constrained by hardware characteristics and the need to support a variety of carrier frequency ranges and signal bandwidths. In particular, a sampling rate considerably higher than the theoretical minimum may be desirable in order to relax the required anti-alias filter specifications [1]. As a result, the initial sample rate will usually not be the most desirable sample rate at which to perform the bulk of a waveform’s receive signal processing. Other things being equal, it is desirable to perform signal processing functions at the lowest feasible sample rate, as this limits computational workloads and sample transfer bandwidths within the radio. In the receive direction, this usually makes it desirable to reduce the sample rate as early as possible.
These considerations make efficient sample rate conversion techniques such as Cascaded Integrator Comb (CIC) filters and polyphase filters a key enabling technology for software defined radio. Reed [1] provides a useful overview of these techniques and their applications. 2.4.3 Computing resources An obvious key challenge of software defined radio design is to achieve reconfigurability of the processing resources used for signal processing that might formerly have been accomplished using analog hardware. Any real-world radio design must meet stringent requirements in the areas of performance, flexibility, Size, Weight, and Power (SWAP) constraints, and cost. Performance requirements generally drive upward the needed level of processing capability, especially where they involve challenging signal bandwidths (very wide), data rates (very high), electromagnetic environments (disadvantaged), and network architectures (dynamic, ‘ad hoc’). The task of the radio engineer is to make selections of computing hardware components that meet a product’s performance requirements, provide the required degree of flexibility, and at the same time meet the product’s cost and SWAP constraints. Three families of computing hardware have been used predominantly to meet these computing requirements:
Application Specific Integrated Circuits (ASICs): custom integrated circuits containing specialized processing elements designed to serve the requirements of a particular system. The circuit provided by an ASIC is completely determined at design time, but can be designed to provide a degree of reconfigurability through the setting of configuration registers, etc.
Field Programmable Gate Arrays (FPGAs): standardized logic devices containing arrays of logic circuit elements with Static RAM (SRAM) cells used to interconnect them. The SRAM contents determine the functionality of the FPGA; the device is reconfigured by rewriting the SRAM cells.
Digital Signal Processing (DSP) microprocessors: microprocessors whose architectures and instruction sets have been specifically designed to optimize performance of commonly required signal processing functions.
(General-purpose processors, or GPPs, typically remain the technology of choice for many control functions and data handling such as data link, network, and transport protocols.) The choice of each of these technologies involves a different set of trade-offs among the various requirements and constraints affecting a software defined radio design. Table 1 (based on the discussion in [1]) provides a very simplified overview of the trade-offs for each digital signal processing technology. In all three categories, the offerings available to radio designers are constantly changing, affecting the families’
relative merits with respect to particular roles in a design. It is common for radio designs to contain elements from at least two of these families, and often all three. It can perhaps be stated that, as reconfigurability requirements have grown in importance with no relief in the area of required processing power, the role of FPGAs in radio designs has increased somewhat at the expense of ASICs. Another important trend is the blurring of the boundaries separating these component families, as (i) entire microprocessor architectures – including DSPs – become available as library cores embeddable within ASICs or FPGAs; (ii) devices considered to be DSPs increasingly contain FPGA elements; and (iii) general-purpose processors acquire an increasing level and range of DSP capabilities [1][12][13]. Table 1. Trade-offs resulting from digital processing technology choices ASIC
FPGA
DSP
Processing power
Flexibility
Design cost/ risk
Component cost
Power consumption, size, etc. Potentially lowest, in Lowest high volume
Highest: maximum parallelism, circuit design can optimize signal propagation and switching times More: parallelism readily achieved; FPGA layout constrains signal propagation and switching Lowest: parallelism limited by processor architecture
Lowest: reconfigurable only as provided for at design time More: Store multiple FPGA ‘programs’ and reprogram ‘onthe-fly’
Highest: custom manufacturing, long lead time
Less: catalog parts, circuit design cycle, HDL, simulation
Higher
More
Most
Least: software design cycle
Higher
Highest
2.5 SUMMARY In our tour of the RF subsystem design issues for software radio, we have observed that the designer can choose from among a variety of design approaches that replace analog with digital technology in the RF subsystem to varying degrees. Even when the architecture finally chosen appears not so different from the sort of multiple-conversion architecture one might have seen in a radio many years ago (albeit probably with the final down-conversion being done digitally), we have observed numerous areas in which software comes into play in controlling and enhancing the performance of the RF subsystem. Even when achieving multiband capabilities with the required levels of performance still requires that a radio contain multiple RF chains in some form, we see that software plays an indispensable role in making it possible for a radio to support multiple bands, bandwidths, modulation types, and standards. This becomes all the more evident when we broaden our focus to again consider the functional areas – baseband processing, INFOSEC, source coding, and data link and network protocols – in which a radio system’s capabilities may be implemented entirely in software. The view of a radio system to which we are led is one in which the hardware design establishes some fundamental constraints bounding the eventual capabilities of the system, but it is almost entirely the software that determines how a radio supports the capabilities of a particular system or standard. Once the hardware design is in place, the engineering activity through which a radio design is given the capability to communicate within a particular system or network becomes almost entirely a software development activity bringing with it a distinctive set of engineering issues and challenges, including:
Providing an execution environment in which new software applications supporting new waveforms, protocols, and standards can be installed and inserted after delivery of the radio hardware platform. Minimizing or eliminating dependencies between application software implementing a network’s waveforms, protocols, and standards, and the software/hardware platform on which it is executed, so that the application software can be ported among different platforms with minimal change, even where these platforms may have very different hardware architectures. As software development becomes the predominant non-recurring engineering activity in developing a new radio system, economic forces create overwhelming pressure for reuse of software from one platform or one system to another.
Meeting a new and more challenging set of security requirements – a problem made much more complex by the greater role of software and the fact that a radio may in its lifetime execute numerous software applications not even envisioned when the radio was initially delivered, and the possibility that these applications could be installed by the user or even downloaded over the air.
We turn next to considering the US military’s Joint Tactical Radio System (JTRS), which has pioneered one influential set of approaches for meeting these challenges. 3.
THE US JTRS INITIATIVE
3.1 JTRS PROGRAM OVERVIEW The Joint Tactical Radio System (JTRS) program of the United States Department of Defense is an ambitious multi-year program aimed at developing a new family of software programmable military radio systems based on a common architecture, and originally intended to replace the roughly 750,000 radios of 25 to 30 different radio types currently in the US military inventory with a smaller number of JTRS radios [14][15]. JTRS radios are envisioned to be highly modular, scaleable, upgradeable, network-capable, and interoperable with one another and with existing ‘legacy’ radio systems. Use of the common architecture is intended to facilitate ‘porting’ of waveforms from one radio type to another, to ensure that radios of different types are interoperable (because they use waveform software of common origin), and to facilitate reuse of common software from one radio type to another. The impetus for JTRS has come from two principal drivers: what could be called a ‘radio inventory rationalization’ thrust on one hand, and a ‘transformational networking’ thrust on the other. When it was originally conceived in the late 1990s, the primary goal of the JTRS program was to replace the US military’s diverse ‘legacy’ radio systems with a new generation of more capable and supportable radio systems. The US military is operationally and logistically handicapped by its having and using so many diverse radio types. Current radios are almost always limited to specific bands, waveforms, protocols, and so forth; many current radio types support only one standard air interface. Missions frequently require that units carry and use multiple radio types, especially as requirements for inter-service, multinational, and civil interoperability become increasingly prevalent. The explosive growth of new communication technologies and requirements collides with the fact that ‘legacy’ radio types typically have no cost-effective upgrade path due to hardware processing limitations and inflexible software architectures. Reflecting on this situation, the US military became convinced that future radio procurements must be pursued according to a strategy that reduces the number of required radio types, ensures interoperability, and provides an effective insertion approach for new technologies as they become available. The key enabling technology through which these goals were to be accomplished was that of software defined radio. JTRS radios would be highly capable multi-band, multi-mission, and multi-standard radios, because the capabilities used in a particular mission would be defined by software. Radios would be reconfigured for a different mission by simply installing different application software, in the way that one installs different application software (e.g., Microsoft Office™) in a personal computer. As it was being defined, however, the JTRS program was tasked with meeting an additional set of very ambitious requirements stemming from the seamless networking goals of the US military’s Joint Vision 2020 [16]. The new generation of JTRS radio systems was tasked with supporting a new family of waveforms intended to achieve a transformational impact on tactical communications, realizing the goals of network centric warfare through advanced Mobile Ad Hoc Networking (MANET) capabilities and seamless interconnection with the US military’s Global Information Grid (GIG) [17]. The new waveforms were to achieve high levels of throughput performance, scalability, and adaptability through the use of higher frequencies (up to 2.0 GHz or higher), higher bandwidths (up to 10 MHz or higher), and sophisticated Signal-in-Space designs (PSK and OFDM families with different signal constellations, bandwidths, numbers of carriers, etc.). Advances of this magnitude could be achieved only through incremental technology insertion; the software defined radio aspect of
JTRS was viewed as providing the necessary support for the evolutionary development and incremental deployment of these new networking capabilities. Fulfilling these objectives would inevitably require a large, complex, multi-service program with a substantial price tag. The JTRS radio types being procured would span a continuum from large multichannel shipboard, fixed site, and airborne radio systems to ‘Small Form Fit’ (SFF) radios for embedding into sensors and smart munitions. Radio types intended for use in different platforms (e.g., dismounted vs. vehicular, fixed-wing vs. rotary-wing aircraft) were organized into ‘clusters’ intended to exploit commonalities in requirements among similar platforms; each cluster procurement was managed by the military service most affected. Defined JTRS program funding (predominantly R&D cost) was $5.9 billion as of August 2003 [18]. Total procurement cost was estimated at $15.6 billion for JTRS Cluster 1 and $8.7 billion for JTRS Cluster 5 as of March 2005 [19]; these estimated costs grew still further over time [20]. Problems with cost and schedule performance eventually forced a reorganization of the program; we will consider some of the reasons for these problems and results of the reorganization later in the paper. As a result of the reorganization, the JTRS program reports directly to the Undersecretary of Defense for Acquisition, Technology, and Logistics within the Office of the Secretary of Defense, and is organized as shown in Figure 7 [21].
JPEO
Network Enterprise Domain
Airborne, Maritime, Fixed Site Domain
Ground Domain
Special Radios
NES
GMR
AMF
Waveforms
HMS
MIDS
JEM
Figure 7. JTRS program organization
JTRS program activities are organized as four domains managed from within the JTRS Joint Program Executive Office (JPEO) [22][23], led by the JTRS Program Executive Officer, Dennis Bauman. The Network Enterprise Domain (NED) has two principal areas of focus.
The Waveforms focus area manages the development of the new JTRS networking waveforms Wideband Networking Waveform (WNW), Soldier Radio Waveform (SRW), Mobile User Objective System (MUOS), and Joint Airborne Networking-Tactical Edge (JAN-TE), as well as JTRS versions of ‘legacy’ waveforms supported by current non-JTRS radio systems. The Network Enterprise Services (NES) focus area is developing network management and network service capabilities for JTRS, as well as gateway products supporting interworking of various JTRS networks. In addition, the NED provides a variety of program technical support services, including systems engineering, spectrum allocation, support of the Software Communications Architecture (SCA), security engineering, and hardware and software testing and certification, specifically in the area of SCA compliance. A key element of this domain is the JTRS Test and Evaluation Laboratory (JTEL) [24], which is responsible for testing and certifying compliance of JTRS waveforms and radio operating environments to the requirements of the SCA.
The Ground Domain manages procurement of JTRS radio systems that are, loosely speaking, intended for use in some kind of ground-based platform. It includes two major JTRS programs:
The Ground Mobile Radio (GMR) program, formerly known as “Cluster 1”, is developing a JTRS radio system form factor intended for Army and Marine Corps ground vehicular platforms and available in a four-channel configuration with frequency coverage spanning 2 MHz to 2 GHz. The Cluster 1 program (as it was then called) was awarded to a team led by Boeing in November 2002. The Handheld, Manpack, and Small Form Fit (HMS) program, formerly known as “Cluster 5”, is developing a radio family including two-channel handheld and two-channel manpack radios, as well as a variety of Small Form Fit radio types intended for embedding into sensors, munitions, and so forth. The radio types differ in frequency coverage with the manpack radio covering 2 MHz to 2 GHz and other form factors covering subsets of this range. The Cluster 5 program (as it was then known) was awarded to a team led by General Dynamics in July 2004.
The Airborne, Maritime, and Fixed Site Domain manages procurements of radios for (unsurprisingly) airborne, maritime, and fixed-site platforms, under two major programs:
The AMF (Airborne, Maritime, Fixed Site) program is developing two radio models: a small form factor radio for tactical, rotary-wing, and wide-body aircraft, and a larger form factor for shipboard and fixed site applications. This program resulted from the merging of what were formerly Clusters 3 and 4. The MIDS (Multifunctional Information Distribution System)-JTRS program was a relatively recent addition to the JTRS ‘program family’. This program is developing a four-channel SCAcompliant radio system as a plug-compatible replacement for the existing MIDS Low Volume Terminals. The MIDS JTRS is to maintain current Link16 and tactical air navigation (TACAN) interoperability in one channel, while providing an additional three programmable channels accommodating new waveforms in the range 2 MHz to 2 GHz [23].
The Special Radios domain manages procurement of the JTRS Enhanced MBITR (JEM), an SCAcompliant upgrade of the Multi Band Inter/intra Team Radio (MBITR) that is in widespread service with the US military, under a program formerly known as JTRS Cluster 2. This is considered an interim handheld solution to be ultimately superseded by handheld offerings from the HMS program [25]. The transformational communications capabilities of the JTRS system are intended to be achieved through the development of a new family of advanced networking waveforms, including:
The Wideband Networking Waveform WNW). WNW is a high-capacity networking waveform intended to provide the lower tactical Internet backbone. In JTRS Increment 1, it is planned to include two Signal-in-Space (SiS) designs: a scaleable Orthogonal Frequency Domain Multiplexing (OFDM) design using different bandwidths, constellations, and coding to provide data rates of from 55 kbps to up to 10 Mbps or more, in bandwidths of 150 kHz to 10 MHz [26]; and an Anti-Jam SiS design providing a similar range of data rates in still larger bandwidths. Two other contemplated SiS designs – an advanced narrowband waveform known as BEAM (Bandwidth Efficient Advanced Modulation) and an LPI waveform – have been deferred to a later increment [22]. WNW is designed to provide voice and IP-based data communications in a Mobile Ad Hoc Networking (MANET) architecture with High Assurance IP Encryption (HAIPE). Black core routing between WNW subnets will permit end-to-end encryption obviating the need to decrypt and re-encrypt payload data in intermediate nodes [17]. WNW was at one time envisioned as filling a very wide range of roles including those of the other networking waveforms described below; its intended role has been significantly narrowed over time as the distinctive challenges of these different roles have come to be better understood [27]. The Soldier Radio Waveform (SRW). SRW, a lineal descendant of the Soldier Level Integrated Communications Environment (SLICE) waveform developed by ITT [28], is intended to provide networking capabilities to platforms described as being “disadvantaged”, because they are not capable of supporting WNW effectively due to limitations of size, weight, power, etc.; hence, SRW is specifically designed to accommodate these kinds of constraints. The “disadvantaged” platforms to be served by SRW include some vehicles, dismounted soldiers, rotary-wing aircraft,
munitions, sensors, and unmanned air vehicles (UAVs) [23]. SRW networks will be “stub networks” with little if any internal routing. Gateways connecting SRW subnetworks to WNW or other WANs will be used to provide connectivity from the Global Information Grid (GIG) and the individual soldier or unmanned device [17]. Versions of the waveform with and without Type I COMSEC are planned. The Joint Airborne Network – Tactical Edge (JAN-TE) waveform. The JAN-TE waveform is intended to provide MANET capabilities to fast-moving, highly-maneuverable tactical aircraft, accommodating the special challenges posed by these platform characteristics and supporting applications requiring minimal communications latency. JAN-TE networks are also envisioned as “stub networks” providing wide-area connectivity via gateways [17][23]. The Mobile User Objective System (MUOS) waveform is a satellite communications (SATCOM) waveform providing beyond line-of-sight (BLOS) capabilities complementing the primarily lineof-sight capabilities of the other JTRS waveforms, at bandwidths capable of supporting applications such as streaming video [17][23].
Figure 8. JTRS Increment 1 reference architecture
Figure 8 [29] depicts the envisioned JTRS Increment 1 network architecture, showing the intended applications and relationships of the new JTRS waveforms. It also illustrates the intended transformational role of JTRS: to provide tactical ‘last mile’ connections through which deployed forces are provided access to the GIG. This GIG connectivity carries with it two key technical challenges for JTRS: 1. Network ‘impedance matching’: The design of the GIG itself generally assumes continuous or at least stable connectivity over a high-bandwidth, high-availability network composed predominantly of optical fiber links. These assumptions obviously cannot be sustained within the ‘disadvantaged’ and constantly changing tactical environment of JTRS. Applications requiring end-to-end connectivity over a mixture of GIG and JTRS subnetworks must take this diversity of network characteristics into account [17]. 2. GIG security: Connection of JTRS subnetworks to the GIG makes JTRS a potential avenue for information warfare attacks on the GIG itself. Recognition of the scope and gravity of these potential vulnerabilities has led to the application of very stringent security requirements to JTRS, some of them not even formulated until the program was already well underway [29][14]. Completing the roster of waveforms planned for JTRS Increment 1 are five legacy waveforms in wide use in current US military communications systems: SINCGARS, EPLRS, HF, LINK 16, and UHF
SATCOM (DAMA). Table 2 summarizes the radio form factors being developed by the various JTRS programs, and maps to them the full set of nine JTRS Increment 1 waveforms [17]. Table 2. Overview of JTRS form factors and waveforms [17] Domain
Program Form Factor
Ground
GMR
Airborne Maritime Fixed Site
Ground Vehicle (4 ch) HMS Manpack (2 ch) Handheld (2 ch) SFF A/H (IMS/UGS 1 or 2 ch) SFF B (LW 2 ch) SFF C (LW 1 ch) SFF D (UAV 1 ch) SFF I (LW 1 ch) SFF J (NLOS 2 ch) AMF AMF SA (2 ch) AMF M (4 ch) MIDS-J MIDS-J (4 ch)
WNW SRW SRW JAN-TE SINCGARS SINCGARS Link EPLRS MUOS HF UHF Type 1 Type 2 w/INC 16 SATCOM Secret SBU (ASIP) DAMA X X X X X X X X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X X X
X
X
X
X
X
X
X
X
X
X
X X
X
X
X
3.2 JTRS STRATEGY Key aspects and challenges of the JTRS program can be brought into focus by viewing it as an application of a software product line strategy [30][31][32]. Northrop defines the concept of a software product line as follows: A software product line is a set of software-intensive systems that share a common, managed feature set satisfying a particular market segment’s specific needs or mission and that are developed from a common set of core assets in a prescribed way. [31] (emphasis added). JTRS radios are software intensive (because they are software defined), having in common the set of features characterizing the domain of military communications: a collection of air interface (waveform) standards they must support, security requirements, the requirements of various military platforms, and so forth. The technology strategy of JTRS is in fact to develop and produce the member products of the JTRS product line from a set of reusable core assets, which include not only reusable software components (waveforms, platform components, middleware) but other engineering work products as well: requirements, framework architectures, test procedures and infrastructures, and even management processes. The success of a product line initiative is achieved by meeting a series of technical and management challenges. The reward for success is the ability to bring into being an extensive family of products meeting the needs of diverse users, much more cost-effectively that would be possible by developing each product independently. The technical challenges of product line development arise from the need to manage and facilitate product variation while preserving the integrity of the product line architecture (or architectures). Key elements of the technical strategy through which this is achieved include a strong focus on architecture definition, typically resulting in a framework architecture with well-defined interfaces. The interfaces play a key role by defining concretely the commonalities that different products must share (their conformance to the specified interfaces) and the degrees to which variation is permitted. To the extent that product variation continues after delivery (through run-time reconfiguration or installation of new
features), component-based technology becomes an important enabling technology. When software components – or even entire applications – are the core assets one hopes to reuse within different hardware architectures providing different complements of computing resources, distributed processing technologies such as CORBA become key enablers as well, as we will see when we consider the key technologies of JTRS in detail. Such techniques provide ways of managing the variation of the software itself; however, further challenges loom when one considers necessary variation of the other software work products such as requirements and testware. The management challenges of product line development arise from
The resources that must be invested in the product line framework architecture and infrastructure. A positive net return on investment is almost never realized until after multiple products have been delivered from the product line. Developing a cogent business case for the product line, and managing execution of product line development so as to realize the predicted return, are challenges of a different order from those faced in developing individual, self-contained products. The complex web of interactions and dependencies occurring within a product line initiative. Managers responsible for the development and delivery of individual products find their fates in the hands of producers not directly accountable to them, and having objectives overlapping with but not identical with theirs. Providing suitable objectives, direction, and accountability to those responsible for core assets such as the product line architecture is especially challenging: making them accountable to managers of specific products risks their failing to support the others, while having them accountable to no specific products risks having them produce ‘shelfware’ not used by any product.
Meeting these challenges requires
Correctly scoping the product line, so that it can derive sufficient economic leverage from the reuse of core assets without becoming too complex to be managed effectively. Protecting the integrity of the product line, including its framework architecture(s), so that they continue to acquire new capabilities and support the development from them of new and profitable products. A common way of failing at this is to permit a specific product to ‘clone and own’ [35] the core assets it uses; as a result, its own enhancements and extensions of the core assets do not become part of the asset base of the product line as a whole. Balancing the requirements, needs, and interests of individual product development activities with those of the product line as a whole. This task becomes especially intricate where meeting product schedule targets places conflicting demands on core asset developers to meet core asset release dates, prioritize some features rather than others, and so forth. Ensuring proper alignment of the objectives and incentives of the various participants in a product line initiative. It is hard to see how this can be accomplished without a strong management focus on the product line as a whole: i.e., a strong, centralized ‘program office’ for the product line, having the proper authority and perspective to weigh the interdependent and conflicting needs and objectives of different products.
As a research topic, software product lines have developed a growing technical literature and an active research community, with an annual conference [36] and a recent special issue of IEEE Software [37]. Within this community many success stories have been reported, in both military and commercial domains, in which a software product line initiative achieves remarkable economic results by basing a diverse set of products on a common architecture and asset base. What these successful initiatives share in almost all cases is the fact that they are executed within the boundaries of a single organization (usually, a single company). The unprecedented aspect of JTRS as an example of a product line initiative is the fact that it attempts to superimpose a single product line initiative on an entire large market segment spanning numerous large corporations and multiple large-scale purchasers and users of military communications equipment [30]. The result is that the JTRS product line’s process flows, lines of communication, and dependencies span numerous organization boundaries, increasing enormously the magnitude of the management challenges faced in making the product line initiative successful. We will see consequences of this unprecedented aspect of JTRS in some of the challenges the program has faced, and in some of the changes that have been required over its history.
4.
KEY TECHNOLOGIES OF JTRS
OE
Non-CORBA Modem Components RF
Applications Core Framework (CF) Commercial Off-the-Shelf (COTS)
Non-CORBA Security Components
Non-CORBA I/O Components
Physical API Modem Modem Components Adapter MAC API
Link, Network Components
Security Security Security Adapter Components Adapter
LLC/Network API
Security API
Core Framework IDL
CORBA ORB & Services (Middleware)
CF Services & Applications
Operating System Network Stacks & Serial Interface Services Board Support Package (Bus Layer) Black Hardware Bus
Link, Network Components
I/O I/O Adapter Components
LLC/Network API
I/O API
(“Logical Software Bus” via CORBA)
CORBA ORB & Services (Middleware)
CF Services & Applications
Operating System Network Stacks & Serial Interface Services Board Support Package (Bus Layer) Red Hardware Bus
Figure 9. JTRS SCA architecture
Figure 9 [44] depicts the JTRS framework architecture defined by the SCA. At the lowest layer, the SCA requires that compliant platforms must provide a POSIX-compliant operating system. It further specifies a JTRS Application Environment Profile (AEP), a subset of the POSIX real-time specification defining a limited set of OS services to be provided. Applications are restricted to using only the services defined by the AEP to help ensure their portability. On top of this, the JTRS SCA employs CORBA middleware to support a distributed component environment allowing individual software components to be deployed on available hardware at runtime in a location-transparent manner. (This is not the diagram used in the current version of the SCA, but it nonetheless provides a useful depiction of the role of the Core Framework in an SCA-compliant radio system.) The key enabling technology of the JTRS program is, of course, software defined radio technology. This paper has already explored the hardware design implications of software defined radio in Section 2, and the JTRS program certainly uses a variety of the design approaches described there. However, the distinctive technological thrust of the JTRS program is in the area of software architecture. The key software technology on which the JTRS program is based is its framework architecture, the Software Communications Architecture (SCA), presently released at version 2.2.2. The main document (“the SCA”) [38] specifies the standard framework components necessary to install, manage and deploy waveforms and other applications, as well as the required management interfaces for the applications themselves. Two companion documents were also included in prior releases of the SCA:
An SCA Application Programming Interface (API) Supplement [39] provided common ‘ground rules’ for defining platform and waveform component interfaces. Requirements here, when combined with a formal approval process, were intended to limit unnecessary API divergence with its potential to fragment the product line. However, in SCA v2.2.2, this document has been deprecated in favour of releases of the API definitions themselves [40]. As of this writing, fourteen individual API definitions have been released, providing standardized interface definitions for fundamental Device and Service types including IO, audio port, serial port, and Ethernet Devices and a Vocoder Service, as well as a Modem Hardware Abstraction Layer API [41].
The SCA Security Supplement [42] defined additional security requirements for US military JTRS radios. This document has been replaced by classified requirements defined by the US National Security Agency (NSA) [43].
The Core Framework provides the means to deploy and manage platform and application components on top of this infrastructure foundation. DeviceManager components launch Device components abstracting physical devices, as well as Service components providing platform services such as file systems or event logging. DomainManager and ApplicationFactory components work together to install and launch Applications, which are typically communications waveforms. Each installed application supplies a set of XML specifying the application’s required processing capabilities (processor types, required Devices and Services to use, memory requirements, etc.) and how the application component’s ports need to be connected to each other and to the platform Devices and Services. The ApplicationFactory uses this XML, together with XML specifying the characteristics of the platform Devices and Services, to dynamically deploy the Application’s components to physical resources (processors) providing the required capabilities. Once deployed, the components are interconnected, resulting in a complete deployed Application. In Figure 9, the top two rows of boxes depict the CORBA components of a possible waveform application after they have been launched and interconnected by the Core Framework, together with non-CORBA components interfaced to the CORBA ‘bus’ by means of ‘adapter’ components. The combination of the operating system, CORBA, the Core Framework, and the launched Devices and Services forms the “JTRS Operating Environment” (OE). It is this OE that forms the runtime environment for JTRS Applications. The net effect of the JTRS architecture is to unbind the component design from the physical hardware. This separation is crucial to ensuring the portability of communications waveforms across a product line spanning a continuum from single-channel handheld radios to large shipboard radio systems providing hundreds of channels. A large and growing collection of tutorial material on the SCA and its use is now available from a variety of sources, and will not be reproduced here; the reader is advised to consult useful resources such as [45] and [46]. 5.
JTRS SYSTEM DEVELOPMENT
The development activities of a product line initiative fall into two key categories: core asset development creating the asset base for the product line, and product development combining and extending the core assets into products suitable for delivery to customers and end-users. These two categories are equally applicable to the JTRS program, in which the final product is a JTRS radio set programmed with the waveform application software giving it the communications capabilities required for its current mission; and the two principal core assets are portable waveform software applications waiting to be ported to radio platforms, and radio platforms combining the radio hardware with a software operating environment, but not including the waveform software. The business model of the JTRS program defines development processes for the waveform and platform core assets, and for the final product; the following sections provide overviews of these development processes. Validation is a key element of each development process, not only to ensure that the end product meets mission requirements (including interoperability), but equally, to ensure that the waveforms and radio platforms conform to the standards constituting the JTRS framework architecture – centrally, the SCA – since failures to conform to the architecture could create obstacles to portability and reuse, ultimately damaging the integrity of the product line. 5.1 WAVEFORM APPLICATION DEVELOPMENT The key objective of waveform application development is to prepare a waveform implementation that, in virtue of its compliance with the SCA, and be cost-effectively ported to SCA-compliant radio platforms with high assurance that it will function correctly on each such platform and be interoperable with implementations of the same waveform on other platforms. Figure 10 provides an overview of the JTRS process for waveform development and validation.
Figure 10. JTRS waveform development and validation (simplified!)
1. The waveform developer starts by developing a portable, SCA-compliant implementation of the waveform application. Frequently, development of the SCA-compliant waveform will use a nonSCA-compliant ‘legacy’ implementation from some non-JTRS radio system as a point of departure. What makes the new implementation portable in a JTRS sense is that it makes only correct uses of Operating Environment facilities (e.g., uses only operating system calls included within the JTRS Application Environment Profile (AEP)) and JTRS APIs, and that it provides a compliant management interface through which it can be configured, started, stopped, and so forth. The ‘portable’ waveform implementation may have unavoidable dependencies on the availability of particular computing resources such as DSPs or FPGAs; these elements of the waveform implementation may have to be redone when the waveform is ported. 2. The ‘portable waveform’ by itself is of limited utility – and in particular, cannot be tested – until it has been hosted on a particular radio platform; waveform development is not complete until this has been done. The platform hosting process comprises implementing any hardware-dependent elements of the waveform, and implementing a Human-Machine Interface suitable for operation and control of the waveform on the target platform. 3. The ported waveform application is submitted to JTEL for testing. The hardware-independent portion is tested for SCA compliance using the JTEL Waveform Test Tool (WTT) in a simulated operating environment. The ported waveform also undergoes functional and performance testing in conjunction with the target radio platform. On successful completion of these testing activities, the waveform is certified to be SCA compliant, and typically is then incorporated into the JTRS Information Repository. 5.2 RADIO PLATFORM DEVELOPMENT The key objective of JTRS radio platform development is to ensure that JTRS radios provide operating environments to which waveforms can be cost-effectively ported, and within which they can operate so as to meet their functional, performance, and interoperability requirements. Figure 11 provides an overview of the JTRS development and validation processes for JTRS radio platforms.
Figure 11. JTRS platform (radio set) development and validation (simplified!)
1. The radio platform developer implements an SCA-compliant Operating Environment on the target hardware, including a POSIX-compliant operating system, CORBA middleware, an SCA Core Framework, platform-dependent Devices and Services, and possible a set of HMI services in some form. 2. After being installed in the target hardware, the Operating Environment is submitted to JTEL for SCA compliance testing. JTEL uses a test application, the JTRS Test Application (JTAP), to verify the Operating Environment’s compliance to SCA requirements. On successful completion of this testing, the radio is certified to be SCA-compliant. At this point, the radio platform is itself a core asset of the JTRS product line, but does not become a product in itself until it has waveforms ported to it and undergoes validation in conjunction with these waveforms. 3. The radio is submitted to the US DoD’s Joint Interoperability Test Center (JITC) for functional, performance, and interoperability testing in conjunction with a set of waveforms ported to the radio. JITC tests the radio’s performance in its execution of one or more particular waveforms; the evaluation criteria are drawn primarily from functional and performance specifications of the particular waveforms. On successful completion of the testing, the radio is certified by JITC and considered accepted for deployment and use by the US military. 5.3 WAVEFORM PORTING The objective of waveform porting is to cost-effectively retarget a portable waveform application from the JTRS Information Repository to a particular radio target platform other than the one for which the waveform was originally developed, and verify that the ported waveform meets its functional, performance, and interoperability requirements when executed on the target platform. Figure 12 provides a simplified overview of the waveform porting process. 1. Starting from a portable ‘library’ waveform implementation, the waveform port developer implements the changes and additions to the waveform implementation needed to permit it to be executed on the new target platform. It is specifically intended that the waveform port developer need not be the original developer of the waveform application; stringent acceptance criteria applied to portable waveform applications accepted into the JTRS Information Repository are
intended to ensure that all information required to support porting of the waveform is present. The goal is that one JTRS program can develop a waveform and submit it to the repository; then, sometime later, a different JTRS program ports the waveform to the radio platform(s) it is developing. A key prerequisite is that the original waveform implementation have been acquired with unlimited Government Purpose Rights – i.e., terms and conditions ensuring that the US government can use the waveform software for any government purpose without having to negotiate new license terms [29]. 2. The ported waveform application is submitted to JTEL for functional and performance testing, along with the target radio platform. On successful completion of the testing, the waveform application is certified and incorporated into the JTRS Information Repository.
Figure 12. JTRS waveform porting (simplified!)
6.
JTRS PROGRESS AND CHALLENGES
The JTRS program as a whole has experienced large cost and schedule overruns, while many key technical objectives still have yet to be realized. The two largest and most ambitious of the JTRS programs, GMR (formerly Cluster 1) and HMS (formerly Cluster 5), have experienced the most serious difficulties. After a recent program restructuring, total research and development cost for the GMR program was estimated at $1.55 billion, a 65% increase over the estimated cost as of June 2002 [47]. Over a similar period, the program’s Low-Rate Production Decision and Operational Test and Evaluation (OT&E) milestones have slipped by fully five years [48], with OT&E now planned for 2011. Concerns over the program’s cost and schedule performance led to the prime contractor’s being issued a ‘ShowCause’ letter (stop work order) on 25 April 2005, threatening cancellation of the program [14]. Work on the program was resumed on 19 July 2005 with Boeing still in the role of prime contractor. According to one report, resumption of the program was due less to confidence that program issues would be corrected than to threatened litigation by Boeing if the contract had been cancelled [14]. Other major DoD programs, including Future Combat Systems and the HMS (Cluster 5) program, depended on the Cluster 1 program for significant system components; further GMR schedule overruns could still threaten the success of these programs. A major technical issue for GMR has been the impact of WNW processing resource requirements on radio size, weight, and power (SWAP); inability to meet the radio weight limit for rotary-wing platforms led to transfer of these platform requirements from the GMR to the AMF program.
Figure 13. JTRS program schedule performance [48]
Total R&D cost for the HMS program was recently estimated at $673 million, an increase of 34.5% over the estimated cost as of May 2004 [47]. Over a similar period, the program’s low-rate and fullrate production decision milestones have each slipped by two years [48], with full-rate production now planned for 2011. Size, weight, and power have also been serious issues for HMS – not surprising since some Cluster 5 form factors were to have weights as small as one pound [14]. Cluster 5 was also significantly impacted by problems in Cluster 1, to such an extent that the first of two planned spiral deliveries within Cluster 5 was cancelled because required waveforms from Cluster 1 would not have been available in time [49]. Issues that may have contributed to JTRS program challenges include the following: 1. Unmanaged growth of scope and requirements. JTRS Program Executive Officer Bauman reports finding that the central objective of the program fundamentally changed sometime after its inception, from one of simply replacing the US military’s ‘legacy’ radio systems with a more efficient and supportable complement of equipment, to one of providing a new set of transformational network communications capabilities supporting Network Centric Warfare [50]. This change greatly increased the level of technical ambition of the program with no corresponding adjustment of cost or schedule. 2. Volatility of security requirements. The expanded networking requirements and envisioned connectivity to the GIG raised new security concerns not accounted for in the program’s initial technical approaches. When the NSA examined the new networking scenarios, it significantly changed the security requirements applied to Cluster 1 even after engineering development models of the radio hardware had been created [50]. 3. Lack of effective product line focus. With the individual military services having complete authority over the JTRS programs they managed, the JTRS product line as a whole lacked an effective champion and focal point [30]. In Bauman’s terms, the program lacked an effective joint enterprise management approach and an effective enterprise business model [33]. Coordination issues between programs required ad hoc negotiation to resolve them, and program dependencies often were not effectively managed. Effective procedures for managing program core assets (waveform applications, associated documentation, build environments, etc.) were not in place, creating obstacles to reuse of these assets between programs. 4. Reliance on immature technologies. The architectural issues resulting from the program’s adoption of software defined radio technology were addressed through a careful and largely effective risk mitigation effort. The framework architecture (the SCA) was developed by an industry consortium, independently reviewed, and validated through a series of prototype development activities (the Step 2a, 2b, 2c programs) to ensure that the program’s goals of waveform portability could be feasibly realized. It is not clear that any comparable mitigation effort was undertaken to address risks arising from the very ambitious networking requirements added to the program. Even as of the spring of 2005, the WNW had been demonstrated only in a network of four users, far short of the required 250. The full demonstration of WNW capabilities
is apparently not scheduled to occur until the GMR program’s System Integration Test in approximately 2010 [47]. Further problems with immature technologies have become apparent with respect to WNW range requirements (3 km demonstrated, 10 km required [14][49]) and size, weight, and power requirements throughput the GMR and HMS programs. Responding to Congressional concerns, in February 2005, the Defense Department established the JTRS Joint Program Executive Office (JPEO), led by Dennis Bauman, to provide a stronger centralized leadership focus for the program. In Defense Acquisition Board (DAB) reviews held in August and November 2005, the JPEO was assigned the task of reviewing the entire program and preparing recommendations for restructuring the program so as to bring cost and schedule performance under effective control. The key budgetary issue was that the actual R&D cost to fulfill the original program requirements was $6 billion, vs. allocated resources of roughly $2 billion – an amount considered simply excessive [50]. In response, the JPEO offered a set of three options for executing the program: 1. Drastically de-scope the program so as to remain as close as possible to the original R&D budget allocation. 2. Retain only the new networking capabilities of the program. While appearing to fulfill the transformational vision of the program, this option would have resulted in a very difficult transition to use of the new capabilities, because of the impossibility of replacing all fielded ‘legacy’ equipment with new JTRS equipment in a single stroke. 3. Retain the transformational networking objectives of the program in conjunction with a reduced number of ‘legacy’ waveforms; reduce the total number of JTRS form factors and the number of waveforms to be supported by each form factor in an initial increment. Defer other waveforms and form factors to potential future increments. The US DoD leadership chose to proceed with Option 3, providing $4 billion of funding for years 2006 through 2011 to complete JTRS Increment 1. The number of waveforms was reduced from 32 to nine, the number of form factors from 26 to 13, resulting in the program scope shown in Table 2 above. At the same time, the program was reorganized so that all of the JTRS programs now report to the single JPEO. This gives the JPEO the authority and perspective with which to effectively coordinate the various programs, manage their dependencies, and ensure the continued integrity of the JTRS product line. The reorganization appears to have addressed many of the issues responsible for the program’s cost and schedule difficulties. Execution of the GMR and HMS programs appears to be better managed, although a number of key technical issues remain [48]. It can be hoped that the AMF program, for which a system development contract is to be awarded in mid to late 2007, will benefit even more from the sound management structure and processes now evidently in place. However, it remains unclear that the damage done by past difficulties can be entirely repaired. Several potential challenges remain for the JTRS program: 1. Placing all of the JTRS programs under the JPEO, while it facilitates effective coordination of these programs and the implementation of an enterprise strategy for JTRS as a whole, may diminish the commitment of the military services to the success of JTRS by diminishing their perceived ownership of the programs supplying their radios. This becomes more of an issue to the extent that alternatives to JTRS become or remain available. 2. The extended delays in the availability of JTRS radios have damaged confidence in the program. Bauman has stated explicitly that one of his key tasks is to restore confidence in JTRS [51]. 3. While JTRS equipment has remained unavailable, urgent operational requirements in Iraq and Afghanistan have forced the US military to suspend the ‘waiver policy’ that had been in effect and procure large quantities of available non-JTRS radios, especially in handheld and manpack form factors. The JPEO deputy director, Howard Pace, has publicly estimated that $9 to $16 billion in non-JTRS radio systems were purchased since 1998, with the largest expenditures occurring in 2004 and 2005, and with no end in sight [51]. These radios are unlikely to be simply discarded
once JTRS equipment becomes available, and resources spent on them become unavailable for purchases of JTRS radios. It is perhaps for these reasons that the US military services’ projected purchases of JTRS equipment have fallen dramatically, by a total of 68 percent (from 458,000 radios to 148,000). In particular, Erwin [51] reports that planned purchases of the GMR four-channel vehicular radio have dropped from 108,000 to 5,700, of the two-channel HMS manpack from 104,000 to 16,900, and of the onechannel HMS handheld from 46,700 to none. The reduced procurement quantities will inevitably increase per-radio unit procurement costs, which may indeed create pressure for further reductions. If this trend continues, it is likely to mean that procurement and use of non-JTRS radio systems will continue indefinitely, after which the JTRS program can hardly be judged an unqualified success. However, this assessment – focused as it is on the two largest and most troubled JTRS programs – may paint too bleak a picture. Two avenues very different from the ones taken by these programs show signs of leading to success in realizing the JTRS vision. One promising avenue is to create a JTRS radio by enhancing or evolving an existing successful radio system. This avenue has been followed in somewhat different ways by two other JTRS programs, the JEM (JTRS Enhanced MBITR) program (formerly Cluster 2), and the MIDS JTRS program commenced after the initial group of ‘cluster’ procurements. The JEM program has developed a handheld JTRS radio in the form of an upgrade to the widely fielded AN/PRC-148 MultiBand Inter/Intra Team Radio (MBITR). The upgrade consists of two digital circuit cards together with a programmable encryption module. The first order for 1,200 JEM radios was received in November 2006 [52]; the radio is presently certified SCA-compliant (with waivers) by the JPEO [53]. The JEM approach also provides an upgrade path for the tens of thousands of MBITR radios already delivered. The MIDS JTRS program is migrating JTRS capabilities into the US Navy’s successful MIDS Low Volume Terminal (LVT) radio systems by adding an SCA-compliant operating environment and three additional 2 MHz to 2 GHz channels to the MIDS LVT radio’s single channel supporting the Link 16 and Tactical Air Navigation (TACAN) waveforms. The added channels will be capable of running the new JAN-TE networking waveform, as well as other SCA-compliant waveforms. Operational Test and Evaluation (OT&E) is scheduled to be completed in 2009 [34]. The program is reported to have completed a successful Critical Design Review (CDR) in June 2006, and to benefit from the relative maturity of its design and from design reuse from the GMR program [33]. It may come as a surprise that none of the radio systems described above is the first widely fielded JTRS radio system. That honor instead belongs to the Harris Falcon® III handheld radio, which was developed as a vendor-funded commercial product rather than under any JTRS ‘program of record’. By December 2006, 3,000 of the Falcon® III radios were already in service under procurements going back as far as September 2005 [53][54], with many seeing use in Iraq and Afghanistan. Many thousands more were delivered in the first half of 2007 [55]. The Falcon® III radio was certified SCA-compliant (with waivers) by the JPEO in December 2006. This commercially-developed JTRS radio is the most prominent test case for the JPEO’s avowed commitment to, in the words of JPEO Executive Officer Dennis Bauman, “removing JTRS market entry barriers and creating a competitive environment within the JTRS family” [54]. The US Defense Department is expected soon to solicit industry bids for up to 89,000 handheld radios to be delivered over the years between 2007 and 2012, the first year in which handheld radios from the HMS program will become available [55]. The Falcon® III and JEM radios are clearly leading competitors for this procurement, which will make them, in number of fielded systems, the dominant form of JTRS radio in real-world use. The US military clearly benefits from the opportunity it now has, as a result of the commercial development of the Falcon® III radio, to procure this large quantity of radios competitively. The success of these two avenues to producing JTRS radios – ‘incremental upgrade’ and commercial development – can be seen as confirming the soundness of the fundamental JTRS premise: that future US military radio systems can and should be software-defined radios with an open, standardized operating environment supporting waveform portability and technology insertion. Many of the difficulties of the JTRS initiative appear to have resulted from issues with the program’s management
structure and the extremely ambitious networking requirements added to the program after its genesis, rather than from any fundamental flaw in the program’s SDR strategy. 7.
JTRS IMPACTS
In spite of the mixed track record of the JTRS programs, it does appear that the JTRS initiative will have a deep and pervasive impact on future US military communications systems. The feasibility of the SCA in a wide variety of radio form factors has now been clearly demonstrated. The radio reconfigurability and software portability made possible by the SCA presently come at a price in initial development cost, SWAP attributes, and some aspects of performance, but military radio purchasers appear not to find this price excessive. The JTRS program apparently envisions that the economic benefits of waveform porting and other software reuse will, and indeed must, be realized through a controlled process of software distribution mediated by the program office, with reusable software being submitted to the JTRS Information Repository, validated in various ways prior to acceptance, and only thereafter being made available for use in other radio products. This appears to be a workable process for sharing of software within a family of development programs all managed by the JPEO. It is less clear how this model will work if – as now appears likely – a substantial fraction of fielded JTRS radios are commercially developed rather than being developed by a JTRS ‘program of record’. The conditions under which commercial vendors can obtain access to software from the Information Repository, and under which they might submit software to this repository, remain to be fully elaborated. Traditionally, vendors have invested in developing waveform software for the specific purpose of gaining competitive advantage for their radio products – almost always complete systems composed of both hardware and software. Software as a distinct product has little precedent in this market; how such software should be priced is not clearly understood. A ‘cost-plus’ pricing model for software delivered under unlimited Government Purpose Rights may not be very enticing for qualified vendors capable of delivering useful products (although it may be for others). The vision of Software Defined Radio is often illustrated by comparing radios to PCs: it is said that one will install waveforms into a radio in the way that one installs software applications into a PC. In particular, one can install the same Microsoft Office™ applications into one’s PC regardless of whether it was made by Dell, HP, Lenovo, or Acer. That one can do so is ensured by the standardization of key interfaces within the PC ‘operating environment’ – primarily due to the de facto proprietary standardization of the operating system and the other items (device drivers, etc.) that it carries with it. Pushing this analogy to its limit, one might speculate that the result of SDR technology could be that the military communications industry undergoes a structural transformation similar to that which occurred in the computing industry from about 1970 to 1995, as described by Andrew Grove [56] and analyzed by Carliss Baldwin [57]. Baldwin describes the computer industry as initially having a ‘vertical silo’ organization – with large vendors such as IBM, DEC, and HP typically providing end-to-end solutions – but then evolving into a ‘modular cluster’ organization with numerous vendors providing various horizontally stratified pieces of customer solutions but no single vendor commanding a dominant share of the market. For the participants, this transformation was extremely disruptive, with some key players (IBM) playing dramatically reduced roles, and others (NCR, DEC, Sperry) disappearing completely. What made this transformation possible was the increasing modularity of computer system designs exemplified by the modular design of the IBM System/360 product family, in which standards (the S/360 instruction set architecture and operating systems) played a key role. Ironically, the same architectural innovations that made the System/360 family successful created openings for other vendors to invade and transform the market. Could SDR technology – and more particularly, the SCA – be instruments of a similar transformation of the military communications industry? While some early JTRS champions were probably hoping for this sort of transformation, it seems unlikely to occur on anything like the same scale as in the computer industry, for at least two reasons: 1. Even after all the work that has gone into the SCA and related technologies, the degree of modularity of radio systems – i.e., the degree to which system components can be designed independently and interchanged – appears much less than in computer systems. The design of
radio systems requires a heavy focus on system engineering to manage dependencies and interactions among system components designed by a variety of engineering disciplines (RF, analog, digital, software, mechanical, electromagnetic); the advent of software defined radio does not appear to make this any less true [1]. The system-level know-how of incumbent vendors remains an important strategic asset, and barriers to market entry remain high. 2. The growth curve of the computer industry as a whole encouraged the making of risky investments in particular ‘modules’ or horizontal market segments; the potential return on these investments was understood to be very high. (Amdahl was able to make a lot of money!) Even with the concept of Network Centric Warfare becoming very influential, it is far from clear that the military communications market can be expected to grow to a similar degree. While the JTRS initiative may not radically transform the entire military communications industry, it has created opportunities for a new category of vendors offering various components of software defined radio solutions. Established hardware (Xilinx, Texas Instruments, Lyrtech), operating system (Green Hills, Wind River Systems, LynuxWorks), CORBA (Objective Interface Systems), and system (Spectrum Signal Processing, Mercury Computer Systems) vendors see SDR as an important potential market and have readied product offerings specifically targeted to SDR. (None of these lists is exhaustive!) Several vendors offer complete SCA Operating Environments and accompanying development tools, including:
The Communications Research Centre Canada (CRC): SCARI Core Framework and Development Tools [58] Harris: dmTK® Core Framework and Development Tools [59] PrismTech: Spectra™ Operating Environment and Development Tools [60] Zeligsoft: Component Enabler (CE™) SCA Development Tools [61]
(This list is also not exhaustive.) In some cases, the development tools employ sophisticated techniques such as Model Driven Development to substantially automate the processes of IDL and XML generation for SCA components and waveforms. Increasingly, integrated solutions are becoming available offering a reliable, seamless ‘tool-chain’ for SCA development; standard interfaces within the ‘chain’ permit elements (ORB, OS, Core Framework) to be substituted for one another so as to optimize features, footprint, and so forth. To the extent that these trends are successful, they may conceivably pave the way toward greater commercial acceptance of the SCA in non-military domains, where the effort, expense, and learning curve of SCA development have heretofore been serious obstacles. In other areas, issues remain not fully addressed that still retard the widespread adoption of the SCA. The ‘footprint’ of the SCA middleware remains an issue, impacting the performance, size, weight, and power consumption (SWAP) of radio platforms and forcing radio developers to incorporate custom work-arounds. In commercial telecommunications, the ‘footprint’ and related issues are likely to restrict early SCA penetration to base station and/or cell site transceivers where SWAP constraints play less of a role. Progress is clearly being made in this area, however. Commercial application of the SCA is affected by its interesting dual nature as both a military and a commercial standard. Configuration control of the SCA remains with the US military, but the SCA has also been adopted by the Object Management Group as the basis for its initiatives in the area of Software Defined Radio [62]. In determining its policy toward the commercial role of the SCA, the US military faces a difficult dilemma:
On the one hand, strong considerations favor encouraging commercial adoption and further development of the SCA. The military wants to be in the standards business only where there are compelling reasons for it; reliance on military standards divorced from the commercial world is expensive and threatens the ability of military technology to keep pace with commercial developments. On the other hand, surrendering control of the SCA to a commercial body such as OMG would threaten the military with losing control over the architectures of vital natural security assets (with typical operational lifetimes of 20 years), which is considered unacceptable.
How this dilemma will be resolved in the long run is not yet clear. After SCA version 2.2 became widely promulgated and was used as the basis for the first round of JTRS procurements, drafts of versions 3.0 and 3.1 were prepared with substantial added and changed material arising from within the OMG community. Alarmed at the implications of this rapid evolution of the SCA, the JPO declared a ‘strategic pause’ in SCA evolution [43]. Since then, versions 2.2.1 and 2.2.2 have been released, with changes occurring on a much smaller scale. As a result of the large commitment of resources to JTRS by the US military and the resulting availability of a nearly ‘ready-made’ SDR architecture for adoption, European nations have shown considerable interest in adopting the SCA as a basis for their own SDR procurements. Several nations (France, Finland, Italy, Sweden) have already developed their own SDR ‘demonstrator’ platforms and have ported waveforms to them. Germany has reportedly mandated that all of its military radio procurements must be SCA-compliant, starting in 2008 [43]. NATO has formed a Software Defined Radio Users Group having as its main focus the establishment of a multinational waveform library; waveforms in the library would presumably be SCA-compliant implementations [63]. A major European initiative known as “ESSOR”, for European Secure SOftware defined Radio (directly participating: Finland, France, Italy, Spain, and Sweden), has the objectives of developing the required standards to support production of SDRs in Europe while “setting up a common security basis to increase interoperability between European forces as well as with the United States” [64]. Funding for this effort is projected to be approximately € 100 Million. Having a truly common SCA shared between the US and Europe could have significant benefits: permitting multinational waveform sharing and facilitating multinational interoperability. However, a number of issues may complicate efforts to establish a common SCA. The US-developed JTRS API draft specifications were placed under export control (ITAR) restrictions in June 2005, raising the prospect that European nations would be forced to develop their own APIs incompatible with the US APIs, and making any US-European cooperation at the waveform level a remote prospect [43]. Prospects for cooperation may have improved with the recent public release of a collection of JTRS API specifications [65]; however, it remains to be seen what concrete basis for international cooperation will be established and how fully opportunities for cooperation will be exploited. 8.
SOFTWARE-DEFINED HF RADIO
For users, purchasers, and developers of HF radio systems, the question naturally arises: How will future HF radio systems be affected by SDR technology, and more specifically, by JTRS and the SCA? One more concrete way to ask this question is: What HF-capable radio systems will the JTRS programs produce? From Table 2 it is clear that, while other JTRS form factors may be HF-capable in principle, the only two form factors planned to be HF-capable in JTRS Increment 1 are the fourchannel vehicular GMR radio and the two-channel manpack HMS radio. Fielding in quantity of both radios is unlikely to occur before at least 2011, and the US military services have dramatically reduced the quantities of these radios they intend to procure. In the meantime, HF radios such as Harris’s AN/PRC-150 are being procured in large quantities [66]. When they are fielded, the GMR vehicular and HMS manpack radios will have the HF waveform capabilities provided by the JTRS HF SSB-ALE waveform, on which development work started as part of the Cluster 1 program. Initially, the waveform was being developed in the Ada programming language. This was considered unacceptable for Cluster 5 (HMS), resulting in a stop-work order for HF waveform development in early 2006. After some adjustments to waveform requirements, development work was resumed in October 2006. At present, development of only a “Spiral 1” set of capabilities is funded. These include the following [67]:
MIL-STD-188-110B modem capabilities: ‘legacy’ FSK and Serial Tone at rates of 75 to 9600 bps STANAG 4285 serial tone modem (considered obsolescent by NATO) MIL-STD-188-141B radio and ALE capabilities: o Main standard: radio specifications o Appendix A: Second-generation ALE (including Advanced Quick Call),
o Appendix B: Linking Protection (AL0-3) STANAG 5066 with Annex A/B/C/D Clear voice: analog Secure voice: LPC-10 and MELP
Notably missing are any form of frequency hopping and any of the advanced ‘third generation’ linking and data capabilities of STANAG 4538 that are now widely fielded and used in the Harris AN/PRC150 (US) and RF-5800H (export) radios. From this it appears that, even when the JTRS program fields HF-capable radios, their waveform capabilities will be significantly deficient relative to those of widely-used non-JTRS radio systems. This is not to say that any major obstacles stand in the way of implementing a highly capable HF waveform in an SCA-compliant form. If this is to happen soon, it may have to be accomplished outside the JTRS program. Interestingly, the relatively low frequency range of HF could lend itself to implementation in a very pure form of software radio with Nyquist sampling at RF and fully digital down-conversion [5]. This may provide an appealing approach for development of HF-only radios, but has less impact on multiband systems since their higher frequencies would require either bandpass sampling or some form of analog frequency conversion. The very simple RF architecture suitable for HF would not be applicable to most of the frequency range of a multiband radio aimed at providing frequency coverage up to 2 GHz or even 512 MHz. Even where the ‘digital frontier’ of an HF radio can be pushed all the way to RF, HF radio systems retain distinctive hardware requirements in the areas of filtering, power amplification, and the antenna subsystem (specifically antenna tuning), so that any HF-capable radio system is likely to require significant RF components specific to HF. 9.
CONCLUSIONS
In this paper, we first examined the manner in which digital and software technology have come to play an increasing role in radio systems, arriving finally at the concept of an ideal software radio in which the digital/analog frontier is adjacent to the radio’s RF interface. We observed that this ideal concept is not feasible for most systems with the components and techniques available today, but that the designer of a software defined radio system can choose from among a variety of candidate RF subsystem design approaches approximating the ideal concept to varying degrees. Each candidate approach has different benefits and liabilities; different candidates best serve the needs of different systems. However, even in a radio architecture retaining certain analog components in the RF subsystem, the role of software has become so pervasive that the development of a new radio system has become predominantly a software engineering task, and the goal of using software to define the functionality of a flexible hardware platform – making it a software defined radio, properly so-called – has become entirely feasible. Using software to define the functionality of a radio system raises a new set of engineering issues and challenges. In particular, it becomes extremely important to decouple the waveform application software that gives a radio the ability to support a particular communications standard from the hardware and software of the radio platform as far as possible, so as to make waveform applications portable from one platform to another even when platforms may differ significantly in their hardware architectures and in the complements of computing resources they provide. The US military’s JTRS initiative has pioneered one very influential set of responses to these challenges: a framework architecture known as the Software Communications Architecture. The paper provides an overview of the JTRS initiative – its objectives, organization, strategy, and key technologies – and then describes and analyzes the history and progress of the initiative and some major difficulties that have affected the two largest of the JTRS programs, the GMR and HMS programs. These problems appear to have been primarily due to the addition to the program of a highly ambitious set of transformational networking requirements and to lack of an effective management structure, and not to any fundamental flaw in the program’s Software Defined Radio strategy. A recent reorganization and re-scoping of the program appear to have stabilized the GMR and HMS programs; however, the success of these programs is still placed in doubt by the past loss of customer confidence in them, and by interim procurements of non-JTRS radio systems that have eroded the rationale for procurement of JTRS equipment in the originally planned quantities. The clear JTRS successes that have occurred were
achieved on programs in which an existing successful radio system was upgraded with JTRS capabilities (the JEM and MIDS JTRS programs) or in developing commercial JTRS products (the Harris Falcon® III radio) outside of any JTRS ‘program of record’. This commercial development of a JTRS radio has yielded important benefits for the US government, and is an approach the government should actively encourage and facilitate. The paper also considers the likely long-term impacts of JTRS on military communications, the military communications industry, prospective commercial SDR customers and developers, and the international marketplace. The fundamental SDR strategy of JTRS, based on the SCA, appears sound and is likely to become pervasive in US military communications systems. On the other hand, although it does appear intended to increase the modularity of military wireless communications systems in the manner described by Baldwin [57], JTRS appears unlikely to effect a sweeping transformation of the military communications industry similar to what befell the computing industry between 1970 and 1995. The JTRS program has created a growing market for providers of SCA Operating Environments and development toolkits; product offerings in this area are increasing in capability and integration and are facilitating the transition to SCA-based SDR technology. The SCA is also seeing increasing adoption as the basis for SDR research and development programs outside the United States, and in Europe in particular. Widespread international adoption of the SCA offers the promise of making possible cooperative waveform development and sharing of waveforms, with improved prospects for interoperability in situations where it matters: NATO and other multinational operations. International SDR cooperation based on the SCA will be more successful to the extent that participants are also able to share APIs, which play a key role in ensuring waveform portability. Apparently, current JPEO policy is to keep the JTRS APIs mostly open except in sensitive (securityrelated) areas. If this remains true, it should preserve opportunities for beneficial multinational cooperation. Finally, the paper considers the prospects for future software-defined HF radio systems. The direct impact of the JTRS program on HF communications appears delayed and diminished by the recent problems of the GMR and HMS programs; HF-capable radios from these programs will probably not be available before at least 2011, and may only be procured in modest numbers. Even when they appear, these radios will be executing the JTRS HF waveform, which, as it is currently defined, lacks important capabilities found in HF radios now in widespread use. Interestingly, HF radios lend themselves to an almost pure software-based implementation due to the relatively low carrier frequencies involved; however, Nyquist-sampling RF subsystem designs within reach for HF remain out of reach for higher-frequency bands. 10.
ACKNOWLEDGEMENTS
The author wishes to thank Chuck Linn for many helpful conversations during the preparation of this paper; Rich Buckley, Jim White, Mark Turner, Roy Breon, and William Batts for helpful comments on earlier drafts; Håkan Bergzén for being very patient; and his family for their love and understanding through too many lost weekends. REFERENCES [1] [2] [3] [4]
[5]
J. H. Reed, Software Radio: A Modern Approach to Radio Engineering. Upper Saddle River, NJ: Prentice Hall PTR, 2002. W.E. Sabin and E.O. Schoenike, Single Sideband Systems and Circuits, 2nd edition. New York: McGraw-Hill, Inc., 1995. J. Mitola, Software Radio Architecture: Object-Oriented Approaches to Wireless Systems Engineering. New York: John Wiley & Sons, Inc., 2000. P. Isomäki and N. Avessta, “An Overview of Software Defined Radio Technologies”, TUCS Technical Report No. 652, December 2004. (www.tucs.fi/publications/attachment.php?fname=TR652.pdf). M. Chamberlain, “A Software Defined HF Radio”, Proceedings of IEEE Military Communications Conference (MILCOM) 2005, IEEE, Atlantic City, NJ, October 2005.
[6]
[7] [8] [9] [10]
[11]
[12] [13] [14]
[15] [16] [17]
[18] [19] [20] [21] [22] [23] [24] [25]
[26] [27] [28]
J. Rosa, “Superconducting MicroElectronics (SME) Technology for Commercial Wireless Base Stations”, 2004 Software Defined Radio Technical Conference, November 2004, Phoenix, Arizona. (http://www.sdrforum.org/pages/sdr04/4.6%20Base%20Stations%20Koenig/4.63%20Rosa.pdf). R.G. Lyons, Understanding Digital Signal Processing, 2nd edition. Upper Saddle River, NJ: Prentice Hall PTR, 2004. C.-H. Tseng and S.-C. Chou, “Direct Downconversion of Multiband RF Signals Using Bandpass Sampling”, IEEE Transactions on Wireless Communications, Vol. 5, No. 1, January 2006. R. Bedi and L. Farrugia, “Mixed-Signal ASIC Design for Space Communications”, 12th NASA Symposium on VLSI Design, Coeur d’Alene, Idaho, USA, Oct. 4-5, 2005. D. Moore, “Practical Transmit/Receive System for Software Radio”, 2004 Software Defined Radio Technical Conference, November 2004, Phoenix, Arizona. (http://www.sdrforum.org/pages/sdr04/4.4%20Transmit-Receive%20Systems%202Kiaei/4.43%20Moore.pdf). A. Ivers and D. Smith, “A practical approach to the implementation of multiple radio configurations utilizing reconfigurable hardware and software building blocks”, Proceedings of IEEE Military Communications Conference (MILCOM) 1997, IEEE, Atlantic City, NJ, November 1997. I. Scouras, “Mixed-signal FPGA integrates soft ARM7 IP core”, ee Product Center, 14 March 2006. (http://www.eeproductcenter.com/pld-fpga/brief/showArticle.jhtml?articleID=181503479). “Synopsys' DesignWare Library Ships with Philips' CoolFlux DSP Core”, Embedded Star™, 13 May 2004. (http://www.embeddedstar.com/press/content/2004/5/embedded14518.html). A. Feickert, “The Joint Tactical Radio System (JTRS) and the Army’s Future Combat System (FCS): Issues for Congress.” Congressional Research Service, Washington, DC, November 2005. R. Brewin, “JTRS office says streamlined development could save billions”, Government Computer News (GCN), 17 April 2006. (www.gcn.com/online/vol1_no1/43839-1.html). United States Department of Defense, Joint Chiefs of Staff, Joint Vision 2020, 30 May 2000. (http://www.dtic.mil/jointvision/jvpub2.htm.) R. North et al, “Joint Tactical Radio System: Connecting the GIG to the Tactical Edge”, Proceedings of IEEE Military Communications Conference (MILCOM) 2006, IEEE, Washington, DC, October 2006. United States General Accounting Office report GAO-03-879R, “Challenges and Risks Associated with the Joint Tactical Radio System Program”, August 11, 2003. United States Government Accountability Office report GAO-05-301, “DEFENSE ACQUISITIONS: Assessments of Selected Major Weapon Programs”, March 2005. R. Brewin, “JTRS Costs Leap Higher”, Federal Computer Week, 10 May 2005. (http://www.fcw.com/article88828-05-10-05-Web). JPEO JTRS Organization Chart, http://enterprise.spawar.navy.mil/getfile.cfm?contentId=1902&type=R. L. Schiavone, “JTRS Overview for CCEB Spectrum Task Force” (presentation slides), 03 May 2006. (http://enterprise.spawar.navy.mil/getfile.cfm?contentId=1488&type=R). ARMY RDT&E BUDGET ITEM JUSTIFICATION (R2 Exhibit), February 2007. (www.dtic.mil/descriptivesum/Y2008/Army/0604280A.pdf). Information at https://jtel.spawar.navy.mil/main.asp. A. Baddeley, “JITR Takes the Stage”, Special Operations Technology, Online Edition, Volume: 2 Issue: 7, 21 October 2004. (http://www.special-operationstechnology.com/article.cfm?DocID=674). Rockwell Collins, “JTRS: Joint Tactical Radio System” (brochure), September 2005. (http://www.rockwellcollins.com/content/pdf/pdf_7500.pdf). V. Popik, briefing to SPAWAR/Industry Executive Network, 6 March 2006. (http://www.ndiasd.org/briefs/6-Mar%20SIEN%20Presentation%5B1%5D.pdf). A. Baddeley, “Handheld Comms”, Special Operations Technology, Online Edition, Volume: 5 Issue: 2, 15 March 2007. (http://www.special-operationstechnology.com/article.cfm?DocID=1954).
[29] S. Anderson and S. Davis, “The JTRS System Reloaded”, CHIPS - The Department of the Navy Information Technology Magazine, July-September 2006. (http://www.chips.navy.mil/archives/06_Jul/web_pages/JPEO_JTRS.htm). [30] E. Koski and C.Linn, “The JTRS Program: Software-Defined Radios as a Software Product Line”, Proceedings of the 10th International Software Product Line Conference, Software Engineering Institute, Baltimore, MD, 21-24 August 2006. [31] L. Northrop, “SEI’s Software Product Line Tenets”, IEEE Software, IEEE, Los Alamitos, CA, July/August 2002. [32] P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Boston: AddisonWesley, 2001. [33] “Radio Executive: Interview with Dennis M. Bauman”, Military Information Technology Online Edition, Volume: 10 Issue: 10, 20 December 2006. (http://www.military-informationtechnology.com/article.cfm?DocID=1876). [34] NAVY RDT&E BUDGET ITEM JUSTIFICATION (R2 Exhibit), February 2007. (http://www.dtic.mil/descriptivesum/Y2008/Navy/0604280N.pdf). [35] Software Engineering Institute (SEI), A Framework for Software Product Line Practice, Version 4.2. Carnegie Mellon University, 2007. (http://www.sei.cmu.edu/productlines/framework.html). [36] Software Product Lines Conference (SPLC). Information at http://www.sei.cmu.edu/productlines/sei_events.html. [37] IEEE Software, July/August 2002. [38] Joint Program Executive Office, Joint Tactical Radio Systems (JPEO JTRS), “Software Communications Architecture Specification”, JTRS-5000SCA V2.2.2, 15 May 2006. [39] Joint Program Executive Office, Joint Tactical Radio Systems (JPEO JTRS), “Application Programming Interface Supplement to the Software Communications Architecture Specification” JTRS-5000API V2.2.1 April 30, 2004. [40] Joint Program Executive Office, Joint Tactical Radio Systems (JPEO JTRS), “News Release: JPEO JTRS Approves New Release of the Software Communications Architecture”, 16 June 2006. (http://jtrs.spawar.navy.mil/sca/_downloads/SCA_v2.2.2_Press_Release_061606.pdf). [41] All available at http://jtrs.spawar.navy.mil/sca/downloads.asp. [42] Joint Program Executive Office, Joint Tactical Radio Systems (JPEO JTRS), “Security Supplement to the Software Communications Architecture Specification” JTRS-5000 SEC V2.2.1 April 30, 2004. [43] C. Serra, “JTRS, SCA & International SDR Standards: Impact on SCA WG Activities”. Presentation to SDR Forum, 12 September 2005. (www.sdrforum.org/pages/brussels_05_drop_box/JTRS_SCA_SDR_STD_Sept05_csv3.ppt). [44] Joint Program Executive Office, Joint Tactical Radio Systems (JPEO JTRS), “Software Communications Architecture Specification”, JTRS-5000SCA V2.2.1 April 30, 2004. [45] B. Salisbury, “SCA Overview” (presentation slides), JPEO JTRS, Unlimited Distribution, 3 October 2005. [46] N. Hayes, “Software Communications Architecture” (presentation slides). (http://www.omg.org/news/meetings/workshops/SBC_2005/SBC_2005_Proceedings/00T5_HayesV2.pdf). [47] United States Government Accountability Office report GAO-07-0406SP, “DEFENSE ACQUISITIONS: Assessments of Selected Weapon Programs”, March 2007. [48] United States Government Accountability Office report GAO-06-995, “DEFENSE ACQUISITIONS: Restructured JTRS Program Reduces Risk, but Significant Challenges Remain”, September 2006. [49] United States Government Accountability Office report GAO-05-669, “DEFENSE ACQUISITIONS: Resolving Development Risks in the Army's Networked Communications Capabilities Is Key to Fielding Future Force”, June 2005. [50] D. Bauman, “Introductory Remarks for Media Teleconference”, 3 May 2006. (http://enterprise.spawar.navy.mil/getfile.cfm?contentId=1579&type=R). [51] S. Erwin, “Trials and tribulations persist in Joint Tactical Radio”, National Defense Magazine, May 2007. (http://www.nationaldefensemagazine.org/issues/2007/May/Trialsandtrib.htm).
[52] Thales Communications, Inc. press release, “Thales’ AN/PRC-148 JEM Becomes the First Government Approved Joint Tactical Radio System Radio in Production”, 16 November 2006, https://secure.thalescomminc.com/newsroom_details.asp?ID=307. [53] Defense Industry Daily, “Thales PRC-148 JEM: The First Tactically Deployed JTRS Radio?”, 22 January 2007, (http://www.defenseindustrydaily.com/2007/01/thales-prc148-jem-the-firsttactically-deployed-jtrs-radio/index.php). [54] Harris Corporation press release, 11 December 2006, http://www.harris.com/view_pressrelease.asp?act=lookup&pr_id=2024. [55] S. Erwin, “Defense Department ‘Bundles’ Handheld Radio Procurements”, National Defense Magazine, May 2007. (http://www.nationaldefensemagazine.org/issues/2007/May/DefenseBundles.htm). [56] A. Grove, Only the Paranoid Survive. New York: Doubleday, 1996. [57] C. Baldwin, “Making Money from Design Architecture” (presentation slides), 27 February 2007. (www.people.hbs.edu/cbaldwin/DR2/BaldwinWhitneyPDSlides2007.pdf). [58] Information on the SCARI Development Suite is at the Communications Research Centre Canada web site, www.crc.ca. [59] dmTK Information at http://www.govcomm.harris.com/solutions/marketindex/product.asp?source=search&product_id =292. [60] PrismTech Spectra information at http://www.prismtechnologies.com/sectionitem.asp?id=305&sid=18&sid2=54. [61] Zeligsoft CE™ information at www.zeligsoft.com. [62] Object Management Group (OMG), PIM and PSM for Software Radio Components, 4 May 2004. (http://www.omg.org/docs/dtc/04-05-04.pdf). [63] R. Barfoot, “NATO Approaches to Software Defined Radio.” Conference presentation, Software Defined Radio 2006, IQPC, London, UK, December 2006. [64] European Defence Agency, “Background on Software Defined Radio”, Brussels, 13 November 2006. (http://www.eda.europa.eu/newsitem.aspx?id=51). [65] JTRS JPEO, “News Release: JPEO JTRS Releases Application Programming Interfaces”, 24 April 2007. (http://enterprise.spawar.navy.mil/getfile.cfm?contentId=1901&type=R). [66] Harris Corporation press release, “Harris Corporation Awarded Contract With a Potential Value of $422 Million For Falcon® II AN/PRC-150(C) High-Frequency Tactical Radios”, 3 May 2007, http://www.harris.com/view_pressrelease.asp?act=lookup&pr_id=2149. [67] E. Johnson, “Revision of US Military HF Radio Standards” (presentation slides), HF Industry Association, San Diego, CA, 1 February 2007. (http://www.hfindustry.com/Feb07/Feb2007_Presentations/Standards%20Revision%20Process.p pt).
