Unlocking the Software Defined Radios' Potential for Military Communications


By Donald R. Stephens, PhD, JTRS Standards Manager


The Joint Tactical Radio System (JTRS) has created open standards that unlock the potential of Software Defined Radios (SDRs). Without the ability of software and hardware from different software publishers and vendors to interoperate, radio development has reinvented the functionality of a previous radio. Similar to Internet open standards enabling scalable and global connectivity, JTRS standards are empowering similar transformation for military and government communications.


A frequently articulated question to the JTRS program is, "why are additional radio standards necessary when 3G and 4G commercial standards enable such great products such as the iPhone and Android?"

JTRS 2012 Radios

There are several differences between commercial and military communications as depicted in Figure 1.

Commercial standards such as Android or iOS are applicable for user interfaces, best described as a presentation layer. These standards facilitate applications, assuming the wireless carrier’s networking service provides the data transport. However, the presentation layer standards only enable graphics and high-level capabilities such as chat and Web interfaces. They do not enable the Sprint cell phone to operate in a different frequency band or to switch from 3G to Satcom.

While JTRS radios are exploiting Android user interfaces for the Warfighter, they also provide a rich set of waveform Application Program Interfaces (APIs). JTRS standards enable a military radio to reprogram itself for Satcom, line-of-sight, and data trunking, all with very different physical layers unsupported by any commercial products.

JTRS radios are designed to operate in regions of the world where different frequency operating restrictions are an issue. In other words, what is permissible in the United States is different from what is available in Europe or Asia. Commercial radios do not have the flexibility to operate in completely different frequency bands.

Commercial handsets are not designed to interoperate with other wireless networks – a cellular phone cannot communicate with P-25 public service radios. Depending upon the mission, military radios must have the capability to intercommunicate with public service workers and coalition forces. This requires flexibility and programmability not enabled by 3G and 4G standards.

JTRS 2012

 It is obvious that military and government radios require additional security beyond the services provided in commercial products. The strength and quality of the encryption algorithm is only the tip of the security iceberg as the military radio must be cyber hardened against sophisticated nation state threats and attacks.

Military radios are more constrained in frequency spectrum than their commercial counterparts – the precious military UHF satellite communications frequency band (serving all users) has less frequency space than the 3G commercial cellular channel. Mobile ad hoc networks (MANETs) were originally matured by the military, although commercial industry is showing some interest in the technology that does not require cell towers and other infrastructure.

Creating JTRS standards

The personal computer, cell phone, and Internet have all been successful in part because of open system specifications. An open system is a collection of interacting software, hardware, and human components available to the public and maintained through group consensus. Because of International Traffic in Arms Regulations (ITAR) and national security issues, it was impossible to allow international participation in the initial development of the JTRS standards. Instead, the JTRS program followed the patterns and processes of the IEEE, ETSI, OMG, and WINNF, but limited participation to DOD contractors and government agencies.

As illustrated in Figure 2, the process is typical of open standards organizations. The JTRS Interface Control Working Group (ICWG) is the standards body that proposes, develops, and votes upon the standards for the DOD. There is a perception that military standards take a long time to develop, but JTRS standards are developed in a smaller timeframe than corresponding 3G and 4G commercial standards. JTRS has processes and infrastructure that can administer changes throughout the JTRS community in less than a week. Participating organizations include JTRS Programs of Record, DOD radio vendors, and other government agencies.

 SCA and SCA next

The Software Communications Architecture (SCA) was first released in December of 1999, initiating a bow wave of software defined radios. A breakout of typical radio functionality is illustrated in Figure 3.JTRS 2012

 In this graphic, the radio hardware is separated between RF/Waveform processing and general processing. Over-the-air signal transmissions generally require a combination of Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and Digital Signal Processors (DSPs). General processing can be performed by traditional computer chips, although designers are conscious of the battery life for battery-powered devices.

The software of a radio is illustrated in Figure 3 with two different types of operating environments, although most radios today only have a single operating environment. As discussed previously, the Android/iOS environments are designed primarily as a presentation layer. The Android has an extensive set of APIs for displaying information and piping data between user applications. Access to telephony, or in the JTRS vocabulary, waveforms, is limited. It can initiate a phone call, send a text message, or access the Internet, but lacks the granularity for directly controlling the over-the-air signal.

In contrast, the Software Communications Architecture (SCA) and JTRS Standard APIs have a rich API set for the RF/Waveform processing. It was designed to provide plug-and-play infrastructure and the capability for dozens of waveforms to be deployed upon a single radio platform. The SCA has standardized control and installation interfaces, permitting rapid deployment of new waveforms or modifications necessary to mitigate an emerging threat or scenario. Although the waveforms and applications in the SCA environment have the capability of providing direct user interfaces, the APIs and services are less advanced than the Android for presentation layer applications.

Today’s radios use either an Android/iOS type or SCA environment, focusing on the flexibility valued by their users. A base station needs to support multiple waveforms and has limited user interface requirements. Tactical radios similarly need to support multiple waveforms and ease of waveform upgrades. The SCA is best suited for these applications. Commercial handsets for mobile telephony are increasingly using an

JTRS 2012

Android/iOS environment. It seems obvious that a bridge between the two operating environments would simultaneously provide rich presentation capability and waveform processing. That capability is already being exploited by the SCA Compliant JTRS Rifleman Radio using tethered devices.

A more detailed depiction of an SCA-hosted radio is illustrated in Figure 4. The primary feature of the SCA is to provide a standardized host environment for waveforms. Because the APIs are standardized, the waveform always sees a consistent interface, regardless of the specific radio platform.

In essence, this defines the functions and services that a waveform developer can utilize in the waveform. By defining a specific collection of functions and services, the SCA promotes waveform portability. A waveform developer is assured an SCA-compliant waveform can execute upon any SCA-compliant radio platform.

The SCA Next is a technical refresh of the software defined radio specification. Version 2.2, released in 2001, has received only two minor updates during the past ten years. Best compared to an operating system upgrade for radios, SCA Next provides new features and capabilities for radio set developers. It provides radio developers with great flexibility in architecting a system with validated standards.

Application Program Interfaces (APIs)

The primary emphasis in API standardization has been the waveform-to-set interfaces illustrated in Figure 5. Only interfaces between the waveform and the radio are standardized. Internal interfaces and transport

JTRS 2012

mechanisms of the radio are defined as necessary by the radio provider. The intent is to provide portability or reuse of the waveform between radio platforms and not necessarily reuse of the radio operating environment software.

In Figure 4, several API groups separate the waveform from the radio set. The SCA does not define the APIs between radio set hardware and services to the waveform. Instead, these are documented separately as JTRS APIs. These include services such as GPS, time, etc. An example list of JTRS APIs is provided in Figure 6.

The seamless automatic connection of components and depth of interfaces might mistakenly impress developers that SCA compliance has a significant learning curve and extra development steps. Over the past decade, an SCA ecosystem has developed with open- source and commercial products that are exploited by JTRS developers. These provide automatic code generation of SCA and JTRS APIs.

The JTRS Information Repository

The JTRS standards reduce the cost of software radio development through validated design patterns and interfaces. The SCA ecosystem further improves efficiencies and economy of scale for radios based upon the JTRS infrastructure. The advantage for the DOD is that waveforms are developed once and then ported to many different radio sets. Interoperability is assured because of a common software base. The JTRS Information Repository is a collection of JTRS waveforms such as WNW, SRW, MUOS, TTNT, in addition to many legacy waveforms.

The government has a minimum of government purpose rights for the waveform and radio set software managed in the Information Repository. This reduces barriers to entry for small, innovative, companies and competitively encourages industry to reuse Government software. The basic model is similar to the commercial open source model where developers check software in and others subsequently access the latest version.

Summary -- Enabling military and government communications

The open standards for software radios generated by JTRS unlock the potential of software-defined radios. The SCA defines the installation and control of waveforms ported to a radio, facilitating in-the-field software installations and emergency upgrades. The JTRS APIs protect the government’s ownership of

JTRS 2012

tactical radio waveforms and software by defining a common way for waveforms to interact with the JTRS radio architectures and hardware.

The JTRS standards’ validated architecture, design patterns, and APIs, accelerate the development of software development platforms. The SCA and JTRS ecosystem of commercial software tools further reduces the cost of porting and developing software.

The JTRS open standards are complimentary to the commercial Android/iOS APIs, which provide presentation layer features, but no waveform features. JTRS radios are exploiting the rich application availability and user interface capabilities of the commercial products, while retaining the necessary interoperability, security, and waveform capabilities necessary for military-grade radios.

JTRS 2012

The JTRS standards lay the foundation for an open competitive market in JTRS radio development. Government purpose rights on software within the JTRS Information Repository enable competition, prevent vendor lock-in, and reduce barriers to entry for small and agile software developers.




About this Report
