Building high-throughput satellite data downlink architectures with AWS Ground Station WideBand DigIF and Amphinicy Blink SDR

As the number and size of satellite constellations in orbit increase, satellite ground segment architectures must modernize to maintain agility, operational excellence, and economic viability. Virtualizing ground segment architectures can reduce dependency on mission-specific hardware components and drive forward this modernization. The Amazon Web Services (AWS) Cloud enables ground segment engineers to explore the possibilities of these architectures with services and features built specifically for this purpose.

This blog summarizes some of the benefits of cloud-based ground segment architectures, and demonstrates how users can build a proof-of-concept using AWS Ground Station’s capability to transport and deliver Wideband Digital Intermediate Frequency (DigIF) data, along with the software-defined radio Blink, built by the AWS Partner Amphinicy. The proof-of-concept enables the acquisition of X-band downlink data from a public broadcasting satellite, Suomi National Polar-orbiting Partnership (Suomi NPP). Users can deploy the proof-of-concept in their own AWS accounts, and use it as a baseline for the implementation of ground segment architectures to communicate with their own satellites.

The walkthrough explores and provides an example for the acquisition of satellite data (downlink), but the same architecture is valid for the transmission of telecommands (uplink).

Challenges of traditional ground segment architectures

Ground segment architectures have traditionally relied on specialized hardware components such as antennas, modems, and frontend processors (FEP). The following diagram illustrates a typical ground segment architecture.

Figure 1. Traditional ground segment architecture composed of antenna, modem, front end processor, and mission operations software backend.

During a satellite downlink, the antenna system receives a radio frequency signal from a satellite and sends it over to a modem. The modem demodulates the analog radio frequency signal into a digital stream, which passes to a frontend processor for frame synchronisation, error decoding, and pre-processing. Pre-processed data is finally delivered to downstream mission-specific software applications, such as mission control centres (MOCs) or payload data processors.

There are a few constraints imposed by the specialised hardware components of these architectures (modems and FEPs). Some of these constraints are:

• Limited ability to upgrade signal processing and output data formatting capabilities of the specialised hardware. Operators are constrained about leveraging new technologies in-orbit (for example, to downlink data more efficiently), or they are forced to upgrade the ground segment hardware.
• If any of the specialised hardware components break or malfunction, they need to be physically replaced. If the operator doesn’t maintain costly spares on-site, the process is likely to entail a downtime that can last several weeks until these parts are delivered and installed. The downtime negatively affects the quality of the service provided by the operator.

Possibilities of software-defined ground segment architectures

These challenges can be mitigated by reducing the dependency of ground segment architectures on specialized hardware components. The following diagram illustrates an architecture of this kind.

Figure 2. Software-defined ground segment architecture composed of antenna, hardware DAC/ADC, software-defined radio and front end processor, and mission operations software backend.

These architectures incorporate an analog-to-digital and digital-to-analog converter (ADC/DAC). The other fundamental difference is that both the modem and the FEP are now software functions that can be hosted on generic compute infrastructure, more widely available on premises or in the cloud.

During a satellite downlink, the ADC digitises or samples the analog radio frequency signal received from the antenna system to produce a digital radio frequency stream, or digIF data. A software-defined radio (SDR) demodulates and decodes the digIF data, and a software FEP completes frame synchronisation, error decoding, and pre-processing, in a similar fashion to their counterparts in specialised hardware in traditional architectures.

Customers can deploy SDR and FEP products on AWS’s compute services, along with their mission operation centre solutions, and benefit from hosting the whole end-to-end ground segment architectures in the cloud. This results in several advantages, some of which are:

• There is no need for large capital investments into infrastructure: the costs of all cloud-based resources are consumption based. For example, AWS Ground Station is billed by the minute, and Amazon Elastic Compute Cloud (Amazon EC2) is billed by the second.
• Cloud architectures, composed of components like ground stations, network resources, or virtual machines, can be defined and deployed using infrastructure as code (IaC) and following DevOps principles. High levels of automation increase business agility and reduce the chance for human error.
• Upgrading software components in cloud architectures can be as simple as pushing a code update. Customers can deploy new capabilities, such as new modulation and coding schemes, when they virtualize ground segment architectures by incorporating SDR and software FEP products. These upgrades are more agile than upgrading physical components, and therefore reduce significantly the time to results.
• Software-based architectures can rely on physically distributed components by leveraging AWS’s Availability Zones, making simpler to implement resilient designs that can recover seamlessly from issues affecting individual nodes.

AWS Ground Station

AWS Ground Station is a managed service that lets customers build ground segment architectures in the cloud to control their satellites, process satellite data, and scale satellite operations without having to worry about building or managing their own antenna infrastructure. AWS Ground Station combines a global footprint of physical ground stations, and the AWS global infrastructure to help ground segment builders address satellite data acquisition and data transport challenges.

Figure 3. Software-defined ground segment architecture composed of AWS Ground Station, software-defined radio and front end processor, and mission operations software backend.

Thanks to Wideband digIF data delivery, ground segment architects can select the SDR and software FEP solutions that best meet their satellite mission needs, and incorporate these solutions to ground segment architectures in the AWS Cloud. AWS Ground Station can capture, transport, and deliver up to 800 MHz (400 MHz per polarization) of digIF data between AWS Ground Station antenna sites, and customers’ virtual private clouds (VPCs). AWS Ground Station relieves users from the complexities of managing antenna systems and ADC/DACs in multiple locations around the world, and leverages AWS’s private, low-latency, high bandwidth global network for a reliable transport of the digIF data.

Amphinicy Blink

Amphinicy Blink is a new kind of satellite modem for Earth observation (EO) and space science. It is a multi-mission, pure software modem, taking in a digitized signal and outputting payload data as frames and packets. It is unique in that it runs at rates up to 4.5 Gb/s, supporting channels up to 1.3 GHz wide on a single server, in near real-time. It provides robust support for Digital Video Broadcasting-Satellite (DVB-S2/S2X) and Consultative Committee for Space Data Systems (CCSDS) protocols, verified with over 20 operational missions.

Software modems are the key to satellite ground station evolution by moving signal processing from high-maintenance, single-purpose modem hardware to software. Blink can run on bare metal machines such as standard servers or laptops, as well as virtual and cloud environments, and support multiple missions at once. When not running modem software for a specific contact, the same underlying server hardware can be used for other computing purposes. Plus, this simplifies upgrades, maintenance, and replacements in comparison to traditional hardware modems, thus optimising costs and utilisation of (ground) infrastructure.

Under the hood, Blink is a software framework for signal and frame processing, making it adaptable, with short lead times and offering a competitive cost. Its architecture makes it simple to deploy in a cloud environment for a dynamic, global, on-demand ground segment. The Blink Amazon machine image (AMI) available in the AWS Marketplace is a simple way to get started. Typical ground stations can benefit, too, as a server running Blink is deployed instead of a conventional satellite receiver, providing record-breaking throughput of up to 4.5 Gb/s, extensibility, and cost-effectiveness.

Figure 4. Usage of Amphinicy Blink in ground segment architectures in the cloud and at the edge.

Large agencies continuously push the envelope in satellite assembly, integration, testing, and validation, before and after launch. Blink comes with a modulator capable of generating signals using known data and simulating various channel effects. At the end of each reception, Blink produces a self-contained, advanced HTML data reception report. It covers everything from global reception summaries to per-anomaly packet header details, from individual signal readings (e.g., Eb/No, gain), constellation and waterfall, and frequency spectrum diagrams.

Ground segment operators supporting multiple missions can create a much simpler ground segment: no mission-specific hardware and a single management and control (M&C) interface for a wide variety of missions or multiple generations of mission spacecraft.

WideBand DigIF X-band downlink data delivery to Amazon EC2

The following diagram describes an end-to-end architecture for the acquisition and processing of satellite data from SNPP, combining AWS Ground Station’s capability to deliver wideband digIF and Amphinicy Blink Modem.

Figure 5. End-to-end architecture for the acquisition and processing of satellite data from SNPP, combining AWS Ground Station’s capability to deliver wideband digIF and Amphinicy Blink Modem.

1. Users schedule a contact with the satellite at an AWS Ground Station antenna region that is supported as a source of wideband digIF data. AWS Ground Station delivers the digIF stream into the AWS Region designated by the user as the data delivery region.
2. A few minutes before the contact, the AWS Ground Station emits a prepass event.
3. The prepass event triggers an AWS Lambda function.
4. The AWS Lambda function starts an Amazon Elastic Compute Cloud (Amazon EC2) instance. The instance hosts the AWS Ground Station Agent (GSA) and the Amphinicy Blink Modem. The instance has an elastic IP attached, which is used by AWS Ground Station as a delivery endpoint.
5. When the contact begins the AWS Ground Station starts to digitize the downlink spectrum defined by the user in the mission profile, and streams the resulting digIF data to the elastic IP attached to the Amazon EC2.
6. The data is received by the AWS Ground Station agent first. The AWS Ground Station agent supports reliable data delivery from AWS Ground Station using Forward Error Correction (FEC), andsecures data delivery from AWS Ground Station using a customer managed AWS Key Management Service (AWS KMS) key for encryption.
7. The AWS Ground Station agent forwards received data over the User Datagram Protocol (UDP) protocol to Blink Modem, which is hosted on the same machine to reduce chance for UDP packets drop between the AWS Ground Station agent and the Blink Modem. Blink Modem demodulates, decodes, and decapsulates the incoming data, and saves the output data in L0 format on disk. It can also be configured to send the output data to customer’s downstream endpoint over the Transmission Control Protocol (TCP) protocol or upload the output data to an Amazon Simple Storage Service (Amazon S3) bucket.
8. Users can connect to Amphinicy Blink WebUI during the contacts to review live plots of the spectrum and rich data processing metrics.
9. After the contact ends, AWS Ground Station emits a post-pass event, which triggers the AWS Lambda. The AWS Lambda assigns a special tag with value “COMPLETE” to the Amazon EC2 instance. A script on the Amazon EC2 instance monitors the tag value, and starts a shutdown procedure, gracefully stopping Blink SDR.
10. The shutdown script uploads Blink report to an Amazon S3 bucket and finally stops the instance. After that, the system is ready again for a new contact.

Note: Make sure there is no data loss on the entire link between the AWS Ground Station agent and the Amphinicy Blink Modem with the following:

• AWS Ground Station agent can only run on specific instance types. The instance also needs to have GPUs, as these are used by the Blink Modem for digital signal processing.
• The Amazon EC2 instance should be powerful enough to handle the signal processing in near real-time. This proof-of-concept uses metal. We advise customers to test different instance sizes to determine the optimal instance size for their bandwidth, demodulation, and decoding requirements.
• To make sure that the AWS Ground Station agent performs nominally, users need to ensure the AWS Ground Station agent runs on dedicated CPU cores; that hardware interrupt requests are routed away from the AWS Ground Station agent CPU cores; and to apply the optimisations described in the public documentation of the service.
  • NOTE: The specifics of the performance tuning depend on the instance size. The CloudFormation template provided for this proof-of-concept implements the performance tuning for metal.

To deploy the solution in your AWS account, request the onboarding of SNPP and follow these instructions in the GitHub repository. In addition to an AWS CloudFormation template, the repository provides the necessary automation scripts and Amphinicy Blink configuration files.

During a successful contact, you can see spectrograms of the signal along with the constellation diagram in Amphinicy Blink Web UI, similar to Figure 6:

Figure 6. Amphinicy Blink Web UI showing spectrograms of the signal along with the constellation diagram.

After completion of the contact, find the Blink contact report in HTML format in the Amazon S3 bucket s3://<bucket-name>/Blink/<yyyy-mm-dd>/ along with AWS Ground Station agent logs and Amphinicy Blink logs copied into s3://<bucket-name>/Logs/<yyyy-mm-dd>/<hh-mm-ss/

Find the processed satellite data (CADU) on the Amazon EC2 instance in the directory /var/blink/out/ACQ_<timestamp>/CADUs/ .

In this default configuration, Blink processes data up to Instrument Source Packet (ISP) level: Channel Access Data Unit (CADU)→ Virtual Channel Data Unit (VCDU)→ISP and stores data output at each level.

Conclusion

In this article we have described some of the benefits of cloud-based ground segment architectures, and implemented a proof-of-concept of a high-throughput satellite data downlink architecture with AWS Ground Station’s capability to transport and deliver Wideband Digital Intermediate Frequency (DigIF) data, along with the software-defined radio Blink, built by the AWS Partner Amphinicy.

Please reach out to us or to your AWS account team to discuss how you can build your mission’s ground segment in the AWS Cloud.