Historically, the evolution of the modem technology has been exclusively focused on purpose-built solutions with a Printed Circuit Board (PCB), CPU, FPGAs, discrete components, and/or an Application Specific Integrated Circuit (ASIC); and combined with implementation code targeted for the custom hardware environment to deliver a limited set of capabilities and a single or limited set of waveforms.
This digitization has given rise to digitized modem architecture comprising digital modem and the RF front end also called edge devices, which are connected using the digital IF interface, which is an IP-based transport protocol used to communicate digital samples and their contexts across a data network. This has led to lower cost of managing SATCOM networks’ important in maintaining profitability and longevity.
IF is short for Intermediate Frequency. Rather than having an RF or 70 MHz analog signal as the intermediate frequency, Digital IF provides a digitized sample representation of that same signal. The digitized samples can then be processed entirely in software. In addition, transport of the digitized samples can be over a much longer distance than a traditional RF or baseband analog signal. A Digital IF interface can flow via Ethernet, whether that be a local area network or
possibly even a wide area network. Digital IF allows the majority of that hardware and FPGA firmware processing to be replaced with software.
With Digital IF, there’s still hardware that performs the analog signal to digital sample conversion for received links and the digital sample to analog signal conversion for transmitted links. The Signal Converter has RF or IF signals on one side and Ethernet interfaces on the other.
When comparing capital expenditures, instead of expensive analog transmission lines and distribution equipment, digital IF transmissions are based Commercial-Off-the-Shelf (COTS) IP routers and switches, which, generally, have lower capital and operation costs. Additionally, network reconfiguration or migration doesn’t require operators to disconnect transmission cabling for equipment replacement. These network operations can be entirely managed by reassigning digital IF IP addresses or simply plugging in a new digital modem into a router.
The major disadvantages of using analog L-band IF were cable power loss and distortion from L-band switching systems, which degrade the SNR. In digitized architectures, L-band switching equipment is replaced with more efficient IP switched systems. Additionally, since the edge device is not fixed to the modem, edge devices can be placed much closer to the antennas, minimizing L-band IF cable length, transmission power loss, and maximizing SNR. Increasing Signal-to-Noise Ratio (SNR) improves signal quality and SATCOM network throughput.
With a true software modem, the Signal Converter is “waveform agnostic.“ Waveform agnostic means that it requires no knowledge of the type of modulation and demodulation. To it, all signals are the same. Any waveform-specific processing is performed in the software that’s across the network. Signal converters that are waveform agnostic can be deployed in any satellite ground system, supporting the waveforms of current and future unknown satellites.
“Software-designed” is defined as any traditionally implemented hardware components replaced by software to configure a function dynamically and programmatically. This definition follows the same approach as other “software-defined” entities, such as “software-defined radio” transceivers that can be reconfigured for a variety of RF tasks or “software-defined networking” appliances that can support a wide range of telecommunications applications.
The Army currently procures and utilizes satellite modems from multiple vendors each having a proprietary waveform and hardware platform utilized in a point-to-point, full mesh or hybrid (hub assist) manner while at-the-halt, at- the-quick-halt or on-the move. These satellite modems are capable of Multi-Frequency Time-Division Multiple Access (MF-TDMA), Frequency Division Multiple Access (FDMA) with a variety of Phase Shift Key (PSK) modulation. All modems use a form of error correction code from legacy block and convolution codes to highly efficient linear error correct code like Low Density Parity-Check (LDPC) codes or concatenated codes such as Turbo Product Code (TPC).
All modems must meet bulk encryption satisfying the requirements of the Federal Information Processing Standard 140-2. The Project Management Office is interested in a way to streamline the tactical Army’s satellite modem product line into a smaller logistical footprint in ways to streamline satellite modem operations with less hardware, use of virtualization, or a combination of both while still preserving the ability to operate in a dynamic tactical battlefield environment while using its current and future compliment of satellite antennae that range from sub one meter to greater than 9 meter.
Future Advanced SATCOM Technologies (FAST) was a four- year research and development program sponsored by US Army Communications Electronics Research & Development
Engineering Center (CERDEC) in FY12. Its aim was to develop a suite of technology demonstrating the implementation of an all digital SATCOM terminal with the associated digital subsystems and corresponding application.
It also became apparent that the architecture’s core subsystems can be functionally equivalent, but not interoperate when designed by different vendors. To potentially circumvent this problem, FAST initiated another effort to develop an Open Standard Digital-IF Interface (OSDI) for SATCOM Systems. This development focused on fostering open market competition while not limiting creative “black box” designs, non-proprietary technology, and designs that achieves compatibility-interoperability-interchangeability.
The FAST architecture also incorporates compatibility with the modular open standard Government Reference Architecture, most notably the segmentation of data, signal, and control functions into distinct processing planes.
The primary benefit of the FAST digital IF SATCOM terminal architecture is the ability to consolidate IF/baseband processing in low-cost digital hardware that, with the widespread adoption of software-defined platforms and programmable logic, can be dynamically loaded to meet evolving mission requirements. Secondary benefits may include new capabilities like reduction in the analog IF equipment suite, improvement in transmit noise spectral density, dynamic channel topology management, all-digital spectral monitoring, enhanced physical and logical separation of security enclaves, and advanced DSP capabilities, such as adaptive compensation, linearization, interference cancellation, and multi-aperture beam-forming.
While the ADC/DAC are among the most critical components in any digital communications link,
their functional purpose is to act as a transducer that “optimally” changes the processing domain rather than change the actual content of the signal. For a single signal, the most efficient ADC/DAC location is generally at baseband (a zeroIF/ZIF modem) or at a nonzero low IF (e.g. 70 MHz, 140 MHz, 700 MHz) that enables sufficient oversampling of the analog signal to optimally process in the digital domain; the fundamental constraint on this sampling process is that of the
Nyquist sampling criterion, dependent primarily on the instantaneous bandwidth of the actual communications signal.
The scalability of this functional architecture to simultaneous processing of multiple signals, and the associated impacts of the ADC/DAC location within the architecture are the core drivers of the present model for digital IF SATCOM. The digital IF architecture must be capable of supporting point-topoint SCPC links, all varieties of communications links (SCPC, FDMA, TDMA, CDMA, MF-TDMA), distributed apertures, and also new desired capabilities for switching signal streams between distant terminals.
The architecture is composed of assemblies notionally located at an electronics building (EB), a pedestal, and the aperture/hub assembly. Functionally, the digital IF FAST architecture may be decomposed into an RF section (red) and the core digital IF processing components (gray).
The RF section includes block frequency translation to the L-band IF (1-2 GHz) in the block up-/down-converters (BUC/BDC), amplification in the high-power amplifiers (HPA), noise figure optimized wideband reception in the low noise amplifier (LNA), and potentially multiband feed
assemblies integrated into a single aperture.
The architecture offers insight to the potential for multiple RF bands, each interfacing to a unique digital IF digital conversion subsystem (DCS), although only one aperture is detailed out for simplicity. Additional RF functions within the hub/pedestal include the scanning/tracking receivers, mechanical/environmental regulation subsystems, and local test equipment (performance monitoring and test subsystem, PMTS) supporting real-time measurement of gain, flatness, and spectral characteristics.
The digital IF terminal processing section interfaces to the L-band IF signal, digitizes the wideband signal in the DCS, and transports the digitized wideband signals over Ethernet, using a
VITA-49-compliant sample encapsulation to the wideband signal processor (WSP). The signal plane interface between the DCS and WSP conveys signals in digital quadrature format, limited in bandwidth only by the GbE transport mechanism.
Routing of the different digital IF sample streams is supported with VLAN tagging to logically separate streams. The DCS, Ethernet switching, and WSP take the place of the fine-tune
converters and L-band switching subsystem (LSS) in an analog IF architecture. Once signals are received, the WSP acts primarily as the system channelizer and gain control manager. The WSP also converts the filtered/rate-adjusted signals to quadrature baseband, reducing the signal sample rate to the banks of digital modems (DMs). “Rate adjustment” within the WSP involves increasing or reducing the sample rate of each sample stream in binary steps to a fixed set of sample rates; note that the actual signal bandwidth can be any value, with the sample rate chosen as the next “level” up to meet appropriate sampling criterion.
The VITA-49-encapsulated sample streams provided between the WSP and DM contain the carrierspecific baseband quadrature samples processed by the DM for signal transmission/reception. The DM is effectively a pure digital baseband processor, strictly producing/receiving samples at baseband. The FAST terminal infrastructure incorporates a frequency and timing synchronization subsystem (FTSS) that manages synchronization to the individual subsystems.
The user data plane elements are broken into two distinct elements, integrating and distributing the user data as received to/from the external global information grid (GIG) interface: (1) the dataplane Gateway serves the function of user data plane information routing, multilevel security (MLS) adjudication (if required), and any inherent data rate adaptation/buffering functions; and (2 the terrestrial interface module is envisioned as the terminal Gateway to the GIG and/or any other external data and control interfaces of the terminal. Due to the extensive number of user data interface types, only a limited definition of the user data plane is contained within the FAST architecture.
The final elements in the FAST architecture are a series of ‘applications’ that will support terminal automation, PMTS functionality, and other real-time processing
This effort resulted in a standard known as the TIA 5041 OSDI and provided a modular architectural framework defining the signal processing elements and the subsystem communication interfaces to create a class of digital intermediate frequency (IF), or “all digital,” strategic fixed SATCOM terminals.
The TIA interface control document (ICD) defines the subsystem communications interfaces and message content for a class of digital intermediate frequency (IF), or “all digital,” strategic or large fixed satellite communications (SATCOM) terminals. The intent of this document is to act as an Open Standard Digital-IF Interface (OSDI) allowing lower cost subsystem development by a variety of vendors, taking full advantage of the migration to digital IF SATCOM architectures, with ensured interoperations via compliance to a set of defined open interfaces.
While the hardware is instrumental to the virtualization effort, another piece of the architecture that is tantamount to the hardware is the coding environment. The OpenCL coding environment allows one to utilize high-level software with directives and extensions to move sections of the code that are better suited to be supported by the hardware assisted processing while saving less compute-intensive processing for the CPU. While OpenCL offers a high-level coding environment, the compiler technology is such that one still must be savvy on hardware to fully appreciate and utilize the hardware assisted processing.
The OpenCL is the framework for developing applications that are hardware agnostic (platform or hardware independent). In fact, OpenCL was defined to be able to execute across heterogeneous-computing platforms that consist of CPUs, GPUs, DSPs and FPGA based acceleration cards. OpenCL includes an Application Programming Interface (API) for controlling the platform and abstracting the underlying hardware. The OpenCL specification is currently at version 2.2.
The OpenCL framework can be utilized to implement the digital processing of any telecommunication waveform as an application running on a COTS HPC server with hardware
acceleration. To achieve practical data rates of today’s telecommunication needs, portions of the program that are too CPU intensive would need to be off-loaded to a FPGA-based acceleration card. The OpenCL program can be partitioned into the main host program running on the CPU, called the “host code,” while portions of the programs to be hardware accelerated become the optimized “kernel code.” The OpenCL API is used by the host to setup kernel tasks and transfer data between the host and the hardware acceleration device(s).
The OpenCL framework provides some key advantages over other implementation approaches. Being a programming language, a waveform implementation can be easily ported from one computing platform to another. Although an OpenCL program is abstracted enough to offer this level of portability, it can also accommodate performance comparable to custom “purpose-built” hardware. Also, the abstraction offered by OpenCL makes it ideal for maintaining code and
enhances design re-use. The OpenCL specification is occasionally expanded and revised to support new capabilities and features of CPUs and devices as they become available.
For example, the OpenCL specification was updated to support direct memory access between an OpenCL acceleration device and the CPU for more efficient data transfers. This eliminated the latency and overhead of copying data in and out of the OpenCL computing device for processing, which enhanced performance. Currently, efforts are underway to integrate FPGA technology directly within the CPU core. Thus, the technological trend is for tighter integration and coupling of the FPGA technology with the general processor.
Michael Beeler, et al describe the application of satellite, tactical radio, or terrestrial radio waveform virtualization on commercial-off-the-shelf (COTS) High-Performance Computing
(HPC) platforms using a high-level software programming language and an open computing framework to provide hardware abstraction.
The HPC server utilizes the combination of a CPU with an integrated hardware acceleration device, e.g. Field Programmable Gate Array (FPGA). The introduction of the open and heterogenous computing framework known as Open Computing Language (OpenCL) provides the mechanism to utilize high-level C with OpenCL extensions as the programming language with the
ability to provide advanced task scheduling of tasks based on the need for CPU (general data processing) versus FPGA (computeintensive) processing.
The OpenCL code is partitioned based on the Host (CPU) and Kernel (FPGA) code. The two different compilers used to compile the host code and the optimized kernel code. One uses the host functions for items requiring much less compute-intensive functions such as routing, encapsulation/framing, management, etc. Conversely, one uses the Kernel code for logic intensive operations such as BCH encoder/decoder, Low-Density Parity Check (LDPC), symbol mapper/demapper, shaping filter, etc. The combined Host and Kernel code provide a logical partition of the various operations based on a directive from the software engineer developing the virtualized waveform. Using the Host Channels, one uses optimal operations within the HPC to
support real-time and continuous data processing.
To demonstrate the feasibility and capability of this proposed solution, the DVB-S2 waveform has been implemented in OpenCL and executed on a COTS server HPC.
References and resources also include: