So you are nearing the launch of your spacecraft and thinking about which ground system provider to use. There are many questions that should come to mind including:
- Should I integrate just one? Or do I need multiple ground systems to gain enough global coverage for my mission?
- Can my team integrate in time for launch?
- How can I be guaranteed the minutes I need with certainty? Do I have to deploy my own hardware?
- Is my spacecraft radio compatible with the modem at the site?
To expound on all the questions you should ask would require a multidisciplinary team of software, hardware, and RF experts.
Hopefully by the time you have selected your spacecraft radio frequency (RF) you’ve evaluated ground providers as well. But what else is there to consider when selecting a provider? All a ground provider does is give access to rack space and an RF Feed right?
Ground service providers offer a range of services from simple rack space to commodity hardware accessed by a VPN tunnel. However, it is worth evaluating the entirety of the chain with respect to the work your team will have to perform to integrate. If you are launching your first test spacecraft, and need 2 full time engineers to perform integration with ground providers, it can dramatically affect your costs. As a result, you have to ask yourself: what will I get in return from each ground service provider?
So let us take a look at the critical questions that you’ll need to answer
Antenna Time – Ground service providers are all going to allow access to an antenna feed, it’s just a question of where you tap into the RF Chain. As you proceed you’ll need answers to the following questions:
- Is the Radio Frequency directly into your own rack of equipment?
- Does Digital Intermediate Frequency that has to be processed in the cloud? Or can you gain efficiency by processing at the ground?
- Do you have to purchase additional baseband equipment and place it at the site, mandating your own Firewall and RF Switch as well?
All of these questions can dramatically affect the profit and loss of your company. You don’t need a reminder that modems are expensive. Unless you are one of the companies that can afford a dedicated antenna at each location you need, you must fully grasp the hidden costs of processing RF data.
Baseband – To process the RF signal you will need baseband equipment (Modem, Front End Processor, etc). Here you’ll need to consider:
- Do you have to purchase this yourself?
- Will you ship expensive staff and equipment to each antenna location, or rent hardware to test your spacecraft?
- Does the ground network provider assist you in testing?
- Do they provide a dedicated test network with which to integrate?
- Do they ship you baseband equipment to perform an end-to-end compatibility test?
These are more than logistical questions, they get to the total cost of running and maintaining hardware.
Network Operations – 24/7 Network operations is the norm across the industry. However, it’s important to understand if they collect metrics (data samples from the hardware) and have a system for providing feedback when an anomaly occurs. It’s not a question of if something will go wrong, but when. Your ground provider should know when a pass has gone badly before you do. If they don’t or can’t provide real time metrics then you aren’t getting full value.
Licensing – Ground Providers should have in-house staff to help with spacecraft licensing in any country they own an antenna. They need to advise you as to the regional rules when using their stations. And they need to submit licensing applications with the appropriate lead-time to ensure your mission is not blocked by bureaucracy.
Backhaul – The speed of the network connection to the ground site has a direct impact on latency. All providers must articulate the speed and upgradability of their internet service provider (ISP). They should be transparent about whether it is a shared or dedicated link as well. If your provider is making you pay for ISP costs, then make sure you understand the full price ahead of time. ISP prices vary widely from location to location, much less country to country. If you think fiber is expensive to your home you should see the prices in Barrow, Alaska.
One API – The clarity of the Application Programming Interface (API) for access matters. If a provider requires use of multiple APIs, then you may want to look elsewhere. A single API means less integration effort and risk. Before you sign a contract ask to see their documentation (ICD, User Guide) and plans for de-risking during onboarding. Ask how often they update their software. If it’s once every few months, it’s an indicator they aren’t an agile software company, but rather they write software as a side project. Updates should be weekly to achieve a stable system (bug fixes, added features).
Security – Every company will say they are secure, but if they cannot prove how they address these critical concerns look elsewhere:
- Ask what standards they follow? (NIST 180-171, NIST 800-53, etc)
- Is it self-audited or a third party? The gold standard is an audit or attestation through a Certified Third Party Assessment Organization (C3PAO).
- Are they penetration tested?
Orchestration – If you are deploying your own equipment to the ground site (see Baseband) then you will need to write software to control all of the components you deploy. This can range from loading the configurations for modems, front end processors, HPAs, and modifying firewalls. If you are interested in collecting metrics / data points at regular intervals during operations, you will also have to learn and understand the API of each hardware. All of this is effectively a full time job for a software engineer in conjunction with a system architect to align all system components in an orchestrated fashion. If you are not deploying your own hardware, but rather interfacing with the providers’, there are still many questions to ask.
- Are you interacting directly with the hardware?
- Do they have an API that abstracts away the work and provides you, no matter the hardware, a unified interface?
You may still be responsible for loading configurations, collecting metrics, and recording data. The critical benefit here is to only have code the solution once, no matter the data source.
Scheduling – Choosing the times to access an antenna (visibilities / passes) can be simple, in the case of a single spacecraft, or complicated with a larger constellation. Ensure you are able to address the following:
- Does your provider offer any tools to assist in making those choices?
At the very least, they should provide a means to select a minimum contact duration, in conjunction with a maximum. From a scheduling perspective this is one key way to increase quality of service. Rather than completely rejecting one customer, the scheduler can provide both customers with their minimum ask.
- Does your provider have an API to give your team better insight into time that is actually free from conflicts?
If you are running on a congested antenna, this is one way to quickly find a high quality contact.
- Lastly, is there ways to pick a time window you would like a pass in?
With this capability, you will have to code less “back-and-forth” if you aren’t paying dedicated premium pricing. Just input the number of passes you want in 12 hours and let the algorithm choose for you.
Data Collection & Delivery – If you are in charge of your own equipment, it’s your job to collect the data, stream it, back it up locally, and push it to the cloud as needed. Both at the site and in the cloud, you have to consider retention policies, security policies, disaster recovery, scaling, and price controls for the raw data (nevermind the processed data). Important considerations to address are:
- Is your provider already cloud-integrated and managing this for you? Or do you just get a stream of data and if you fail to connect, is it gone?
- Will it take one or two full time engineers to build, test, and maintain this portion alone?
You have to consider that you may be in charge of a much larger and more complex system architecture than you anticipated when deciding to build your spacecraft.
Analytics – Metrics covering all ground hardware can be used for analysis. They provide you insight in aggregate form, hence you’ll want to to know if:
- Your provider can deliver a stream for real-time analysis?
- Are the metrics streamed at sufficient frequency to be useful?
- Do they store the metrics for later analysis, including long-term trends and machine learning?
These metrics can be critical to early diagnosis if your anomaly is with the spacecraft or the ground system. Finally, if you have to build a system to both collect, store, and analyze ground hardware data you are performing tasks outside the scope of operating a spacecraft and add yet more cost to your company.
User Interface – Not all customers are focused on machine to machine integration. Rather they simply need manual interaction to “just get started” with a ground provider via a web based interface. Other customers who are fully integrated via an API may also want the capabilities exposed in a dashboard so they do not have to integrate into their own UI. Does your provider have a user interface that allows:
- Viewing visibilities?
- Requesting time on an antenna?
- Visualize unused / free time on the system so you have greater insight when booking essential tasks?
- Download receive data?
- Visualize metrics / data points across a pass execution?
- Display whether or not the pass was a success (from the ground system side)?
Considering the entirety of the value chain requires a multidisciplinary approach and a systems design understanding. We must move towards solutions that reduce the engineering burden on the spacecraft owners and operators. While launch costs have recently decreased, we need further disruptions in the ground segment to accelerate access to space data. As a pioneer in GSaaS (Ground Station as a Service) ATLAS Space Operations has been leveraging our expertise to build a system that addresses the entirety of the value chain.
Click here to view Brad’s original post on LinkedIn.