At the heart of the JTRS project is the concept of a software definable radio or SDR. The SDR is a hardware form much like your laptop; consisting of a processor or processors with its supporting circuitry – like memory, codecs, encryption chip and the r.f. or radio frequency components.
Like a computer, it processes instruction sets to perform specific functions. The executable instruction sets are broadly referred to as waveforms, and a waveform is what gives the SDR its identity, so a common hardware architecture can emulate a variety of fixed radios. For example, by loading a SINCGAR waveform in a software defined radio, you are able to communicate seamlessly with dedicated SINCGAR radios on a network.
Creating interoperability is the set of rules defined in the Software Communications Architecture or SCA. All hardware and software designed for JTRS must be SCA compliant. SCA is also and open architecture, meaning there are no proprietary components. This approach is critically important to the military and commercial success of the project, because it opens the doors to waveform developers. A historical example of the open architecture approach was IBM’s opening up of the desktop computer. That decision, uncharacteristically IBM, is what made the PC ubiquitous .
There are currently over 20 waveforms in the JTRS Network Enterprise Domain (NED)inventory. NED is responsible for the management, development and enhancement of the waveform library.
One waveform that seems to be at the heart of the net-centric battlefield is the Wideband Networking Waveform or WNW. Radios running the WNW will have the ability to transmit voice, data, video and imagery by tacking up 4 r.f. channels or scaling back to 2 channels as needed.
So, our ideal JTRS radio will have the capacity to emulate (computer jargon for imitate) any force radio. On the network side it will also have the ability to transmit voice, data, imagery or video concurrently by tacking up multiple communications channels as routing or bandwidth requirements dictate.
What is particularly interesting to me is the network side of JTRS. From what I’ve seen, manufacturers are dealing with voice, data and video applications by tacking up multiple channels, which appears to me to be inefficient. Regardless of the frequency spectrum, the more channels you tack up the larger bite you take out of available bandwidth.
A better approach may be to operate two channels, one broader active channel and one narrow channel for alternate routing, backup or signaling. The active channel could employ statistical time division multiplexing – a technology where time slots are allocated to the input that most need it – wrapping the encrypted data packets in IPv6, for routing. IPv6 provides 2128 network addresses.
Another interesting aspect of JTRS is the frequency spectrum they operate in, for example Boeing’s Ground Mobile Radio or GMR which functions from 2 MHz to 2 GHz. The radio can operate within that envelope as needed. However, in order to support high bandwidth applications like video and imagery, JTRS will need to use the higher end of the frequency spectrum, which makes the technology line of sight. So, in difficult terrain it requires an intermediary like a UAS or satellite link to increase its operating range. That dependency may prove to be a problem, in both maritime and land application, should we find ourselves in a conflict where our space assets are denied.
JTRS holds great promise for both military and commercial applications. It will be expensive but the commercial potential is high enough that developers will be willing to commit resources to the project.
As always, pass along any questions that you have and I’ll try to answer those for you. I hope you enjoyed the JTRS series.
Note: In general, higher frequencies are more sensitive to propagation impairments, satisfy higher bandwidth requirements and require smaller antennas. Lower frequencies are less sensitive to propagation impairments, provide lower bandwidths and require larger antennas.