Where conventional satellites were earlier tailored to comply with single mission requirements, satellite developers are gradually adapting the vision of software-defined satellites which can be reprogrammed and reconfigured, to allow a satellite to take up new applications and expand its performance. Instead of viewing a satellite as a monolithic piece of hardware and software, designed to perform a specific mission, one can see the same satellite as a platform capable of running multiple different missions (defined as software applications) on the same hardware platform.
This transformation is driven by the ongoing New Space revolution which has planned up to 50,000 active satellites to be in orbit over the next 10 years. All these satellites have complex and variegated sets of orbits and waveforms that satellite communication (SATCOM) networks need to support. This drives the need for SATCOM operators to create flexible and adaptable networks capable of operating on a myriad of different waveforms, orbits, and constellations—while simultaneously maintaining service quality and profitability.
“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.
Digitization enabling Software-defined satellites and networks
A traditional satellite communications payload consisted of the digital data and networking traffic being handled by external systems while the modem, transceiver, and RF Front-end (RFFE) handled analog communication signals from the digital controllers and the antenna system. Much of a satellite modem has long been replaced by digital hardware that processes the modulation and demodulation of communications signals at baseband frequency.
Hence, more recent satellite communication systems use modems with Analog-to-digital Converters (ADCs) and Digital-to-analog Converters (DACs) that can operate to baseband frequencies, with the modulation, demodulation, and signal processing being handled in the digital plane by Application-Specific Integrated Circuits (ASICs), General Purpose Processors (GPPs) or Field-programmable Gate Arrays (FPGAs).
This led to the integration of digital hardware into the transmit and receive chain of satellite communications payload, but only to baseband frequencies. This left RFFE, Intermediate Frequency (IF), and baseband frequency (baseband) analog hardware remaining, even with the move from highly directional, discrete antenna to phased array antenna. This move merely required more RF, IF, and baseband hardware as well as digital controllers and amplitude/phase shifters in the RF section to handle the phase shifting for each antenna element or group.
Satellite communication systems have typically been in the upper microwave and millimeter-wave range due to throughput and spectrum allocation considerations. With such high RF frequencies, a single frequency conversion stage has largely been untenable, as the limitations of mixers and Local Oscillators (LOs) lead to substantial signal degradation at higher frequency conversion ratios. Therefore, multiple frequency conversion stages have traditionally been necessary, with each frequency conversion stage requiring filters, LO, mixer, and possibly a gain stage to overcome the signal loss associated with each component within the signal chain.
Recent advances in direct digital synthesis, direct digital sampling, and digital upconversion/downconversion have led to increasing digitization of the satellite communication signal chain. An enabling factor for this digitization are higher frequency ADCs and DACs that can reach upper microwave and millimeter-wave frequencies and more powerful ASICs, GPPS, DPSs, and FPGAs that can handle the signal processing and data conversion requirements of modern satellite communications protocols have become available.
This digitization may also include the channelization hardware, and that process can now be done in the digital realm, no longer requiring analog multiplexers or digital switches. Namely, the low noise amplifiers, power amplifiers, circulators/switches, antenna, limiters, front-end filters, pre-amplifiers, and interconnect remain the only analog hardware in this chain for the latest satellites. With digitized modem and transceiver functions, the limiting performance factors for communications is now placed on the ADCs and DACs synthesizing and sampling the RF signals, as well as the RFFE presenting the most pristine signals to and from the antenna.
To further accommodate greater communication system flexibility, RF bandwidth has also increased. This means that wider bandwidth RF components and devices are now needed to pair with the wide bandwidth digital communications hardware. Moreover, the new Digital Front-end (DFE) hardware presents its own new design challenges. For instance, the sample rate conversion (SRC) and channelization can have a significant impact on the waveform with certain modulations requiring specific sampling rates. Moreover, the DFE hardware also introduces its own distortions and noise, which must then be handled by the RF hardware to ensure high signal quality. These factors may result in additional filterings, such as antialiasing filters and channel selection filtering to reduce the burden of channelization on the digital hardware.
Digitized modem architecture with digital IF
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.
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 (RF front end) 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.
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. There are some important reality checkpoints. The digitized samples must be at a frequency and resolution that is sufficient to reliably perform the digital signal processing. For example, 40Msamples/second at 12-bits each
may be required to processing a 5 Mbps telemetry downlink with 10 MHz of bandwidth. So there’s high throughput and high network loading that most often requires the network connection carrying the Digital IF be dedicated.
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.
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.
Processing 60 Mbytes of sample data every second and doing the complex computations needed for a software modem is no small task. It’s one that would swamp most computer systems prior to a few years ago. But the multi-core processors in today’s high-performance, low-cost servers have changed all that.
Multi-core processors are advantageous for signal processing in several areas. First, there’s their sheer performance when doing floating-point arithmetic. Second, the multi-core processors include instruction primitives that speed up the sophisticated math even more. Third, processing tasks can be assigned to a core and that core dedicated to that task. This is important for tasks that require near real time execution and/or have high throughput requirements. Getting all of this power and functionality in a commercial, low-cost server has enabled the software-defined modem.
Innovations in data converter technology, DSP devices, system interconnects, processors, software, design tools, and packaging techniques have improved performance levels and reduced the size, weight, and power consumption of software radio systems. However, the rapid surge in software radio applications spawned ad hoc, proprietary interfaces between the elements in these systems.
Approved as an ANSI standard in 2007, VITA 49.0 represented the first official standard for VRT, but it only defined receiver functions using the VRT IF Data and Context packets. After demonstrating its usefulness by early adopters, system designers wanted to extend its scope to encompass even more elements of software radios. The original VITA 49.0 standard omits support for transmitters, control and status functions, and any signals other than digital IF. To address these shortcomings, VITA 49.2 was initiated with new packet classes represented in Figure 2.
Signal Data Packets
The original IF Data Packet is replaced with the Signal Data Packet, which not only supports digitized IF signals, but also baseband signals, broadband RF signals, and even spectral data. Signal Data Packets are backwards compatible with IF Data Packets, with new identifier bits to specify the data type.
To support bi-directional radio signals, Signal Data Packets can now be used for transmit data, supporting baseband, IF, and RF signals. Here, the time stamp dictates the transmit time, which is especially useful for generating precisely-timed radar pulses. Multi-static radar systems use one antenna for transmitting pulses and other remotely located antennas for capturing the reflected pulses. Through GPS synchronization, VRT can be used to coordinate transmit and receive signals at each site.
Spectral survey systems are in widespread use for detecting and recording signals of interest. Under VITA 49.2, Signal Data packets can carry digitized spectral information from scanning receivers, and deliver packets to analysts anywhere in the world. These packets maintain full context information regarding location, circumstances and conditions, as well as a precise time stamp.
VRT time stamps allow beamforming applications to compare absolute time and phase differences between signals received from multiple antennas to calculate distance, location, speed and heading of a transmitter. Likewise, a multi-element diversity receiver can exploit VRT time stamps to create delays and phase shifts in each antenna signal path to maximize receptivity in a particular direction.
Enhanced Context Packets
The original Context Packet is also significantly enhanced in VITA 49.2. Many more types of metadata are supported for new details and richer information about the signal data. Context Packets now allow a VRT resource to respond to the system with a complete set of its operational specifications including minimum and maximum limits of each programmable parameter. This may include frequency tuning range, bandwidth settings, range of programmable gain, antenna azimuth angle limits, and range of transmit power levels.
Context Packets now also provide additional characteristics such as:
- the settling time when switching tuning frequency, bandwidth, or gain
- the angle slew rate for a movable dish antenna
- frequency accuracy and stability
- time stamp and ephemeris accuracy
- operating temperature range
- tolerance limits for shock and vibration
- the effects of temperature drift and aging
In theory, a VITA 49.2 System Processor can connect to a new, unknown software radio resource and automatically discover everything it can do, how to control and monitor its operation, and how to successfully exchange receive and transmit signals. In practice, Context Packets will be most useful when developing new applications on existing platforms, and in reacting responsibly to new threats or circumstances during deployed operations.
Gaining Control with Command Packets
Another deficiency of VITA 49.0 was its lack of control of software radio resources. VITA 49.2 adds a new packet class called Command Packets, which allow the VRT System Processor to deliver operating parameters to each element using the same standardized fields and formats as the Context Packets. This provides a consistent control interface across a wide class of hardware, ranging from antenna positioning systems to transmit power amplifiers.
Command packets not only provide control, but also support status and acknowledgement functions so that the VRT processor can check the operational status of the receivers and transmitters to verify successful execution of the control commands.
This comprehensive and complimentary control/status protocol of VRT provides an essential function for cognitive radio, adaptive spectral management, electronic counter measures, and other critical applications.
Many previous generation modems combined FPGA firmware and software. These modems are configurable in that the modem’s processing can be configured for the waveform, data rates, data formats, and other parameters. But they are essentially a monolithic firmware/software implementation that has all of the features and functions in one hard-to-manage configuration. This necessitates a long regression test period with each new release.
True software-defined modems are implemented with separate software applications for each unique waveform. In other words, there’s an application-specific to a type or family of spacecraft. This has the advantage of allowing customers to only deploy the waveform applications they need and update them as needed. An App is started and stopped for each contact. These “smaller” Apps are independent and thus more reliable, more mature, and easier to manage. Plus, adding a new waveform-specific App does not invalidate any of the existing Apps.
Reduced Life Cycle Costs
True software-defined modems are dramatically reducing the upfront and on-going costs of the modems used for satellite telemetry, ranging, and commanding. Hosting the Apps on commercial servers has two cost benefits. First, the initial cost is much lower than the custom industrial computers used with point solution modems. Second, the software Apps can be easily migrated to new server platforms, eliminating the need to replace/repurchase the full modem. The up front costs are also lower because the vendor cost to produce and support the products are lower. They
may also be lower because the satellite operator only needs to purchase the waveform Apps specific to their satellites.
Increased Network Agility and Capability
Network and terminal agility are becoming more important due to the rapidly changing space layer. Agile networks and terminals will enable easier migration to waveforms and constellations, streamline network resource reconfiguration, and modernize deployment of new capabilities. In a digitized architecture, digital modems are decoupled from edge devices, supporting easy reconfiguration of the network. With a standardized digital IF interface, digital modems could replace and back up one another for redundancy through simple IP network configurations.
Additionally, digital IF streams could be duplicated, combined, and separated digitally to provide new capabilities like diversity gain, beam forming, and amplifier distortion correction. Finally, with a reliable digital IF transport, digital modems can communicate to distant edge devices adding additional network redundancy and even leverage cloud
References and Resources also include: