Publications

Issue Archive

Architecture of the Air Force Satellite Control Network

Sunday, 01 April 2012

Page 3 of 3

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.

Question of the Week

This week's Question: A recent study created by the Arizona-based Paragon Space Development Corporation says its life support system could help humans survive on Mars. The proposed Environmental Control and Life Support System, the company says,...