2008

Architecture of the Air Force Satellite Control Network

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, visit http://info.hotims.com/40432-541.