Agile satellite communication ground systems with Amazon EC2 F2 FPGA solutions

Satellite communication operators are increasingly seeking more flexibility at their ground stations. Existing physical infrastructure is typically locked to a specific vendor, with complex upgrade paths for the dedicated, standalone hardware modems.

Most modem vendors use Field-Programmable Gate Arrays (FPGAs) to efficiently implement encoding and modulation. Therefore, a solution is needed to use existing designs while delivering the desired agility.

The newly released Amazon Elastic Compute Cloud (Amazon EC2) F2 FPGA instance types meet the needs of the new wave of dynamic satcom applications. The density of the F2 digital signal processors (DSPs) and lookup tables (LUTs) enable large amounts of satellite bandwidth to be efficiently processed after digitization. Orchestration of multiple waveforms can be achieved with the Amazon FPGA Image (AFI) management tools provided in the Amazon EC2 FPGA development kit.

In this post, we provide technical guidance to help satellite operators build, deploy, and analyze satcom waveforms on Amazon Web Services (AWS). Details are provided about the orchestration of multiple waveforms, including an example of one AFI being swapped in for another. We analyze the FPGA utilization and metrics in Amazon CloudWatch and Amazon QuickSight, and validate network performance against system latency requirements. Finally, we recommend actions you can take to build an agile satcom strategy.

Background

Communication satellites relay and amplify radio frequency (RF) signals to allow communication between two or more locations on Earth. Satcom networks typically connect a large antenna at a teleport/hub to one or more smaller antennas in remote locations. They’re used in environments with no terrestrial connectivity, such as aircraft and vessels; in areas with unreliable terrestrial connectivity, such as after catastrophic events; and for live content distribution, such as media broadcasting.

Figure 1. Architectural diagram of a traditional satellite communications system.

There is very little agility in a traditional satcom ground segment. These hardware solutions are complex and inflexible, forcing customers to spend precious time and resources manually provisioning and installing ground segment components. Peak holiday air travel or major sporting events can more than double the satellite bandwidth demand, but satellite operators have limited ability to scale up. Proprietary hardware systems can rarely be repurposed for new missions.

Now, with agile satellite communications, operators can overcome these challenges. The benefits are reduced upfront hardware spend, increased flexibility, and simplified operations. The introduction of the Waveform Architecture for Virtualized Ecosystems (WAVE) consortium has further amplified demand for a fully interoperable satcom framework.

The RF components are replaced by a digitizer, software channelizer and combiner, and one or more software defined radios (SDR), as shown in Figure 2. The SDRs may be in an AWS Region or at AWS Outposts infrastructure for higher bandwidth, low-latency use cases.

Figure 2. Architectural diagram of a virtualized satellite communications system with SDR (de)modulation, (de)coding. The major components are an Amazon S3 bucket, Amazon SageMaker, AWS Lambda, Amazon EC2, Amazon EKS, AWS Direct Connect, and AWS Outposts.

Accelerated compute instances: F2 FPGA

In contrast to a purpose-built chip designed for a single function, FPGAs are more flexible with reprogrammable logic gates and the capability to perform many operations in parallel.

Typical waveform standards in satellite communications are DVB-S2X and DVB-RCS2. Satcom infrastructure providers often implement these waveforms in FPGAs because the underlying algorithms (such as low-density parity check or cyclic redundancy check) can achieve higher efficiency, measured in bits per Hertz, with DSPs.

The new F2 FPGA instances are well-suited to the category of virtualized satcom applications. Based on the AMD Virtex UltraScale+ VU47P FPGA, satellite operators can (de)modulate and (de)code multiple waveforms in the cloud. Key differentiators include:

• 9024 DSPs enabling processing of complex waveforms in a single FPGA
• 100 gigabits per second (Gbps) networking using Data Plane Development Kit (DPDK), a framework for high performance network traffic handling in user-space by limiting context switches
• Up to eight FPGAs on a single F2 instance type, with the result that operators can digitize and process large amounts of satellite RF bandwidth

Orchestration: Managing multiple satcom waveforms

Agile multi-waveform capabilities enable rapid reconfiguration in the field, which is advantageous for scenarios such as military personnel switching to a new protocol to make communications more secure. Orchestrating the clearing and loading of different waveform images becomes a critical requirement for the new, flexible ground segment.

AFIs provide the foundation for this switching, empowering satellite operators to deploy systems with multiple waveforms. After creating an FPGA design (also called custom logic, or CL), modem developers create an F2-based AFI. AFIs are reusable, shareable, and can be deployed in a scalable and secure way, such as in AWS Marketplace. Operators consume the AFIs and deploy them to an F2 instance type of choice.

Figure 3 shows a scenario with two waveforms from different vendors. Each supplier builds their design check point (DCP) using their chosen tooling, for example, hardware development kit logic or Vitis high level synthesis (HLS) for C/C++ based IP blocks that target FPGA fabric. An AFI would typically be built for each waveform with its own differentiated algorithms, then deployed into AWS Marketplace. The end user ingests each of the AFIs programmatically, by referring to their respective Amazon Global Firmware Image (AGFI) identifier. Management tools to load, clear, and describe AFIs are available in the F2 development kit.

Figure 3. Development flow with EC2 F2 FPGA.

This fulfills the need for serial loading of different waveforms. However, what if customers need multiple simultaneous waveforms to be active? This is where larger F2 instance types such as the f2.48xlarge (eight FPGAs), can be adopted. AFIs from different modem vendors are loaded on separate FPGA slots, enabling a full multi-tenant solution for satellite operators.

Observability: Key performance indicators

How do we measure the number of DSP and system logic cell resources used by each AFI? Do the load and clear waveform cycle times meet system requirements? These are some of the questions to answer from an observability perspective.

The Vitis development flow produces an HLS report with detailed performance and utilization estimates including a timing latency summary and DSP and LUT usage for each design checkpoint. A sample AWS Lambda function is provided in this post’s associated GitHub repository to parse these key performance indicators (KPIs). The metrics are then pushed to Amazon Simple Storage Service (Amazon S3) storage and viewed in Amazon QuickSight, a business intelligence (BI) tool. The Lambda function can be used as a reference for customers seeking to retrieve satcom KPIs, such as receive signal-to-noise ratio (SNR) and modulation coding rates (modcod), then deliver them to an Amazon S3 bucket.

Figure 4. QuickSight dashboard showing FPGA DSP and LUT usage for each AFI.

CPU and network utilization are equally important to validate that an appropriately sized F2 instance has been selected. These are collected by default for the F2 EC2 instance and are available in Amazon CloudWatch, as shown in Figure 5. Custom metrics can also be pushed to CloudWatch. For example, in the military scenario discussed earlier, AFI load and clear durations might be important to rapidly cycle waveforms. Clearing and then loading a new AFI typically takes less than 30 seconds, with reloads benefitting from a hardware caching mechanism.

Figure 5. CloudWatch metrics for CPU, network, and FPGA utilization.

Networking requirements and configuration

Agile satcom places substantial networking requirements on compute instances performing demodulation. Demodulating a satcom RF waveform and transforming it into digitized intermediate frequency (DigIF) streams produces approximately a 20:1 expansion in data rate. That is, 100 MHz of RF bandwidth equates to approximately 2 Gbps of DigIF data (the actual ratio varies depending on factors such as modulation scheme, and error correction type). This drives the need for high throughput processing and network bandwidth. To avoid hitting scaling limits, we need a way to move data in and out of the FPGA instances for processing satcom data with as little overhead as possible.

As mentioned earlier, FPGA instances support DPDK networking. The open source DPDK framework consists of libraries to accelerate packet processing workloads. Importantly for scaling digital satcom workloads, it runs in user space, bypassing kernel space to achieve the maximum network performance.

Figure 6 shows the network traffic flow for customer data, which enters the Amazon EC2 Enhanced Network Adapter (ENA), passes through the PCIe bus and into user space through the DPDK ENA driver, then to the DPDK application. From there, traffic is delivered to the FPGA through a DPDK Software Patch Panel (SPP), also running in user space. Return traffic takes the reverse path through the DPDK application to the ENA.

Figure 6:. Optimized traffic flow bypassing kernel interrupts for maximum throughput.

In testing, an F2 instance with a single FPGA running the custom logic streaming data engine (cl_sde) application in the shell, to the DPDK SPP in user space, achieved 9 GB/s of throughput with 8192-byte jumbo ethernet frames. When traffic is introduced from an external network source through the ENA, throughput will be in line with the instance-based limits of the ENA, providing the scale and performance agile satcom requires with DigIF workloads.

Figure 7. Network throughput test results using the DPDK testpmd application.

Recommendations

Adopting a new agile satcom strategy requires evaluation of the business and technical aspects, with the following actions recommended:

• Calculate the total cost of ownership for fixed, on-premises satellite modem infrastructure factoring in physical infrastructure footprint and operational overhead. Compare this to a cloud compute solution, in which instance types can be easily upgraded and scaled up or down.
• Understand the networking requirements presented by DigIF systems, making sure the chosen instance type and AWS Direct Connect link capacity can accommodate your traffic.
• Get started with F2 instances by visiting the AWS FPGA GitHub repository.

Summary

This walkthrough explores how to use the new EC2 F2 FPGA instances to deliver agile satcom workloads. Flexible solutions help satellite operators automate their ground systems, updating the satellite payload based on customer needs. Customers can scale the infrastructure based on demand instead of investing upfront.

Waveforms from multiple modem vendors can be integrated as AFIs, enabling a new level of flexibility as mission requirements change. Orchestration of waveforms is available within a single FPGA or across multiple FPGAs in larger instance types, with observability metrics available in familiar Amazon CloudWatch and BI tools, enabling new levels of visibility into system performance.

For more aerospace and satellite learning resources, visit the AWS for Aerospace and Satellite main page.