Ground Communications

This article describes how the Antaris Cloud Platform (ACP) facilitates ground-based communications with satellites. The diagram below illustrates the conceptual architecture:

The Ground Segment encompasses everything operating on the earth in support of a satellite mission. This includes, for example, Ground Station hardware, ACP software, and supporting services such as Space Situational Awareness (SSA) providers.

Satellites communicate with the Ground Segment during scheduled Ground Contacts. Many distributed components may be coordinated during a Ground Contact in order to establish a connection, typically including active tracking of the satellite by ground station antennae. The satellite may also need to actively track the ground station.

Individual Ground Contacts typically fit one of three use cases:

  • TT&C (Telemetry, Tracking & Command): primary communications path used to control the satellite. These are typically lower bandwidth, bidirectional communications links using S-Band or UHF transceivers

  • Teledata: used to download payload data using high bandwidth communication paths like X-Band, Ka-Band, and Optical links

  • Beacon: critical health telemetry transmitted over highly resilient, low bandwidth links like UHF

ACP takes the ultimate responsibility to orchestrate Ground Contacts but can rely on external services to handle individual elements of the overall solution as needed. For example, ACP can build a tracking model for a satellite, or it can fetch a TLE from an external source like space-track.org. ACP can also control ground station infrastructure and coordinate SDR software/hardware, or delegate that responsibility to a third party GSaaS provider.

Contact Scheduling

ACP orchestrates the Ground Contact schedule for all satellites under management. The scheduling process generally works like so:

  1. Build a set of contact opportunities for a given satellite using recent orbital ephemeris and configured ground station access requirements

  2. Fetch prescheduled contacts from ground station providers, if available

  3. Optimize the ground contact schedule based on operator-defined policies, pending control tasks, and projected data downlink requirements

  4. Publish contact schedule back to ground station providers

  5. Upload contact schedule to satellite at next opportunity

Some ground stations may be fully under the control of ACP and used only by a single satellite. Many additional operational capabilities are available:

  • Support for multiple satellites within ACP, even shared across missions and tenants

  • Scheduling exceptions for satellites managed outside of ACP (i.e. facilitating external multi-tenant operation)

  • Externally controlled contact scheduling, delegating decision-making to a third party

ACP directly manages all of these complexities and gives users effective controls over when and how ground contacts are ultimately executed.

Contact Execution

Once a Ground Contact has been scheduled, ACP will wait until it is ready for execution then take the appropriate action.

For TT&C contacts, ACP will take the following approach:

  • Initiate all required data plane connections to the provider

  • Begin listening for telemetry through the data plane. Parse received messages and aggregate them into necessary telemetry dashboards

  • Enable the message console so users can send Telecommands directly to the connected satellite

  • Automatically process any pending control tasks, such as deploying an updated schedule and uploading files

For Teledata contacts, ACP orchestrates ground contact scheduling but delegates data plane responsibilities to the Ground Station Provider. Payload data is routed directly into storage services rather than ingested into ACP.

For Beacon contacts, the uplink capabilities of ACP are simply not enabled. The contact is executed in a “listen-only” mode. Any received telemetry is still ingested as would be done for a full TT&C contact.

Ground Station Providers

ACP uses the “Ground Station Provider” abstraction to define ground station capabilities and relevant access parameters. Each provider includes the following:

  • A set of physical ground station locations and the available communications capabilities

  • An API endpoint that can be used to manage Ground Contact scheduling for the configured Ground Stations

  • Service endpoints that host relevant data plane APIs

This abstraction is applied to both first- and third-party ground stations.

First Party Ground Station Integration

Users are able to directly integrate ACP with first party ground station software and hardware through a simple API-driven abstraction. This allows users to bring their own ground station infrastructure online in support of production satellite operations with minimal overhead. An SDK is available to assist in implementation of these APIs, and users are free to implement them directly in whatever software is most appropriate.

Ground contact schedules are managed through a simple JSON-based API, while the data plane is connected through a simple set of MQTT topics.

Supported Ground Station Services

Below is a description of the “Ground Station as a Service” (GSaaS) integrations available in ACP. Each of these requires a user to establish a commercial relationship with a third party, then ACP can integrate with the services offered by that third party.

ATLAS Space Operations

Users may configure a Ground Station Provider with access to the ATLAS Freedom API. This requires that the user already has a support agreement in place with ATLAS Space Operations.

This integration supports:

  • Ground contact scheduling, syncing in both directions between ACP and the Freedom API

  • Data plane access using the websocket endpoint offered by the Freedom API

Leaf Space

Users may configure a Ground Station Provider with access to the Leaf Space API and MQTT broker. This requires that the user already has a support agreement in place with Leaf Space.

This integration supports:

  • Ground contact scheduling, syncing in both directions between ACP and the Leaf Space API

  • Data plane access using the Leaf Space MQTT broker

Last updated