Architecture of the Air Force Satellite Control Network

The Air Force Satellite Control Network (AFSCN) is a worldwide network of ground stations that supports a variety of users from NASA to the National Reconnaissance Office (NRO). The network performs tracking, telemetry, and commanding (TT&C) for these users. Users, located at Satellite Operations Centers (SOCs), must compete for time on the AFSCN (see Figure 1).

Figure 1. As can be seen from this Operational Concept Diagram, the AFSCN supports a wide variety of users. Each one of these users requires telemetry, tracking, and commanding (TT&C) support from the AFSCN.

One value that determines the success of an uplink or downlink is the signal to noise ratio (SNR). SNR is the power of the transmitted signal over the noise power. Both uplink and downlink require minimum SNR to be considered successful. If the minimum SNR is not met, the data cannot be extracted from the signal.

Currently, the users do not know what the SNR performance will be over a given contact because there is currently no SNR prediction capability in the AFSCN. The spacecraft operators, or users, schedule time on the AFSCN with no regard to the estimated SNR. This presents an issue. With no way to estimate or predict the performance of an upcoming support, the users cannot accurately request time on the network because they do not have a quantitative representation of the estimated performance of the contact. If the users had an estimate of how the link would perform, they would be better prepared to schedule contacts more efficiently.

SNR is largely dependent on the signal power from the transmitter. With the ability to predict the SNR of a downlink, the users would be able to optimize the power level to the amount required to achieve the desired SNR. This is a huge advantage as power consumption is an important factor in spacecraft operations.

Figure 2. Given a ground station, STK will determine its availability to a particular spacecraft. The availability of these orbits to the Colorado Tracking Station (top), and Diego Garcia Tracking Station (bottom) were modeled.

There are apparent advantages to predicting link performance. So why doesn’t the AFSCN have this capability? During the design phase of spacecraft programs, a worst-case link budget is used. In other words, the spacecraft is designed to obtain the needed SNR in worst-case scenarios. Therefore, varying SNR is not normally considered an important issue because the needed performance can be obtained in most conditions. As a result, there is no SNR predictive capability within the AFSCN.

Having SNR prediction capability would allow the spacecraft operators to more accurately predict the amount of time needed for a support and potentially result in power savings for the spacecraft. Guiding the research are the following questions: How can link performance be predicted? Where in the current AFSCN architecture would performance prediction be applied? Lastly, how would the AFSCN and its users benefit from link prediction capability?

An AFSCN LP was created that integrates several physics-based models of antennae patterns, thermal noise, and signal gains. SNR is largely dependent on the signal power from the transmitter.

SNR normally refers to the carrier power over the noise power spectral density. This value is important because it is needed to determine the Bit Error rate (BER) of the subcarriers. The subcarriers are what contain the data needed by the users. Certain types of data require that the BER not be above a certain threshold. Therefore, the SNR is important because it is directly linked to BER. By knowing the predicted BER or SNR of their respective links, the users then know, within a margin of error, what the performance of that link will be and when/how long they should schedule their AFSCN support and/or how much power to expend.

Each user requires telemetry, tracking, and commanding (TT&C) support from the AFSCN. The users are composed primarily of SOCs and external users supporting communication services, navigation, surveillance, reconnaissance, environmental/wea ther, research and development, and launch. Users must interface with the Network operations center (NOC) to request support from the AFSCN. The NOC is responsible for de-conflicting requests and disseminating the Network Tasking Order (NTO) to all of the users and Remote Tracking Stations (RTS), or ground stations. The NTO tells the network when each spacecraft will be supported at each RTS.

It is a common occurrence in the AFSCN that the users request more time than needed and the support is cut short. This results in wasted time on the network that could be used for another support.

Link Prediction

There are link prediction products currently available. These products utilize the same functionality required by the AFSCN, but are not tailored specifically to it. The Dynamic Link Analysis (DLA) tool is a MATLAB-based tool that was designed to predict link performance during launches on the Eastern and Western Launch ranges operated by the Air Force. DLA GUI allows a user to select the space vehicle and earth station desired. This tool then predicts the performance of the link based on known parameters. These selections then translate into a predicted SNR. Most link analysis is static, which means it assumes constant performance throughout the contact based on worstcase performance.

Noise Temperature

The noise temperature is all of the power added to the carrier from environmental and manmade sources. This added noise makes it difficult for the receiver to distinguish between the noise and the desired signal. Noise comes from natural sources like the Earth and Sun. It is also radiated from the receiving equipment, which imparts additional gain but also additional noise.

The system noise temperature for downlink will vary over time for all spacecraft contacts. This will yield different system performance at each interval of the contact. This fluctuation in noise temperature will be less pronounced for geostationary or geosynchronous orbits because they remain more or less stationary with respect to the spacecraft. However, the noise temperature will vary greatly for low earth orbiting (LEO) orbits because of the system noise temperature’s dependence on elevation.

Link Geometry

To determine the link geometry, Analytical Graphics’ STK space systems modeling application generates geometric arrays for each link. The three parameters used to predict the performance of each link are: elevation angle, degrees off boresight, and range. The ground stations are selected from the online database provided by STK, and generic spacecraft orbits were defined using STK’s orbit modeler. STK automatically generates time-based arrays of any orbital location parameter given a ground station location, spacecraft location and orbit, and support start and end times.

This orbital information is then exported from STK and imported into MATLAB and available to use in the AFSCN link prediction (LP). Rep - resentative low earth, medium earth, and high earth orbits were modeled using STK. Given a ground station, STK will determine its availability to a particular spacecraft. The availability of these orbits to Colorado Tracking Station (CTS) and Diego Garcia Tracking Station (DGS) were modeled (see Figure 2).

The AFSCN LP was designed from the bottom-up, meaning its place in the architecture of the AFSCN was not previously determined before creating the AFSCN LP. The functionality of performance prediction was established and then adopted for use within the AFSCN. The current design of the AFSCN LP requires spacecraft ephemeris (i.e., location) updates from NORAD because that is what STK requires. During a contact, a user’s spacecraft location information is updated with current tracking information obtained during the contact from the RTS. The users use this tracking data to update the known location of their spacecraft.

The AFSCN LP software would be loaded onto a CPU at a workstation located in the orbital analyst section of the SOC/External users’ facility. The spacecraft ephemeris information would then be loaded into the AFSCN LP in preferably an automated fashion. The AFSCN LP would need to be updated to allow the user to determine which RTS would be best suited for their needs. Some RTSs are more capable than others and would provide a better SNR.

Also, hardware and software updates to the RTSs may result in increased/ decreased performance. On the spacecraft side of the link, the AFSCN LP makes certain assumptions about the spacecraft such as the antenna type, transmission power, signal loss models, etc. However, in practice those assumptions are not always valid and all spacecraft configurations must be accounted for. Continuous updates will be needed to that take into account new spacecraft launches and changes in performance of existing spacecraft.

Considering the updates required on the RTS and spacecraft sides of the link, there needs to be a mechanism to update the tool to adjust for these changes. These updates could be released as a software patch periodically.

Network Architecture

AFSCN currently utilizes a closed network. The communications segment is self-contained and is not connected to any other network. Any updates to the operational software of the RTSs must be accomplished in one of two ways. A CD can be shipped to each RTS and then installed on the system. Or the software update can be uploaded to an online database connected to the Web and then accessed via a Web-enabled terminal at the RTS. The software can then be downloaded to a CD and installed on the system. This method could be utilized by the users to update the AFSCN LP.

This AFSCN LP architecture is intentionally simple because the AFSCN is already a complex system-of-systems (SoS); any added complexity would not be welcomed. This approach would allow the least amount of disruption and added complexity to the AFSCN possible. The users would be encouraged, not required, to utilize the AFSCN LP.

The AFSCN LP was created to demonstrate the utility of performance prediction and its potential use in the AFSCN. Here, simulations are run assuming representative spacecraft configurations and orbits. The AFSCN LP software is currently only written to predict the performance of AFSCN links that utilize RBC RTSs.

Conclusions

The research conducted is significant because time across the AFSCN is limited and a performance prediction capability could allow the more effective and efficient scheduling of more supports. Also, if this tool were to prove useful in saving power on spacecraft and was a robust part of the AFSCN architecture, users would be able to use the extra power to better meet their mission needs, or extend mission endurance.

The AFSCN and its users could greatly benefit from having the capability to predict link performance. By predicting the BER over an AFSCN support, the user would have the option to schedule less time on the network or adjust the spacecraft’s power level to the optimal setting, saving power. The proposed architecture would impart minimal impact on current AFSCN operations while allowing for increased efficiency, in time on the network and power on spacecraft.

This article was written by Eric W. Nelson, Air Force Institute of Technology, Wright- Patterson Air Force Base, OH. For more information, Click Here