# 4 Space/Ground Trades

The initial CSOC wireless network architecture is based on an existing
heterogeneous infrastructure, much of which cannot be easily shared
between disparate missions. Under CSOC the architecture will be unified
and standardized by modification of existing systems and addition of new
systems to reduce cost of operations while improving the level of
service to the NASA customers. The goal of unification is directed
toward achieving the functional structure shown in Figure 4-1. The keys
to the structure are in the standardization of the Data Distribution
Functions and in extensive use of autonomous operations. For this, CSOC
will utilize standard Internet Protocols (IP's) for data movement
throughout the system and direct activity toward achieving autonomous
operations. The IP's will also be extended to spacecraft through the
Space/Ground Networks to achieve interface, data, and control uniformity
throughout the system. CSOC's Data Distribution Functions and
Space/Ground Networks enable all users (Mission Operations, Science
Operations, Data Archive and Retrieval, High Security Users, and
Internet Users) to communicate with each other as well as their
space-borne hardware.

![](media/image1.emf){width="6.4944444444444445in"
height="5.354861111111111in"}

Figure 4-1 CSOC Unified Functional Structure

## 4.1 Space/Ground Trade Strategy 

## 

The crux of the high cost of operations in using the present systems is
implied in the top half of Figure 4.1-1, which shows that
spacecraft/user data/commands move through existing facilities, each of
which use teams of personnel to facilitate that movement. A main
strategy of CSOC is to transform those personnel intensive activities to
self-running robotic activities by:

-   Introducing autonomous operations on the ground and on the
    spacecraft,

-   Simplifying the movement of data and commands, and

-   Improving bandwidth,

The bottom of the figure shows the target concept of operations for
CSOC's strategy. In that part of the figure, the spacecraft and user
communicate directly between each other through autonomous ground
stations by use of wireless services rendered on-demand and IP compliant
networks.

![](media/image2.emf){width="0.9798611111111111in"
height="-1.0986111111111112in"}

Figure 4.1-1 CSOC Strategy - Migrate from human intensive to autonomous
operations.

Improving efficiency

This strategy for ground and spacecraft operations maximizes efficiency
with:

Very high bandwidth wireless networks that:

-   Include Ka-band RF to obtain 100-600 Mbps near earth transfers, 1
    Mbps Mars transfers.

-   Enable shorter transfer times, thus more transfers per asset.

Autonomous operation of those networks that:

-   Render service on-demand,

-   Need no scheduling of activities, and

-   Can be implemented with inexpensive ground stations that can be
    added as missions increase in number.

New spacecraft that:

-   Use small, high-rate Ka-band steerable dish and low-rate near-omni
    antennas,

-   Obtain service from the ground by requesting it using autonomous
    control of on-board RF to support the demand access protocols,

-   Incorporate a high-speed, IP compliant, autonomous on-board LAN,

-   Provide bus services for IP compliant on-board instruments and
    subsystems,

-   Perform autonomous navigation,

-   Perform autonomous fault detection and recovery, and

-   Utilize task assignments rather than commands to perform user
    requested mission operations.

Utilize IP Compliant Networks

An important piece in the CSOC strategy is to evolve the networks to
achieve the functionality and operational autonomy of the Internet
between the users, operations, the spacecraft, the on-board instruments,
and the on-board personnel.

This Internet Protocol (IP) model:

-   Transfers data on demand rather than on a schedule;

-   Includes reliable data movement protocols;

-   Supports secured data movement; and,

-   Handles very high data rates.

The methods whereby network protocols will be extended into space must
be resolved early in the CSOC program. It is possible to achieve
ground/space IP compatible connectivity with protocols modified (by
issuance of new RFC's) to handle the long light-time
transmission/reception delays and with data encapsulation and software
mechanisms to handle data recovery and maintain proper data order in the
event of data dropout. Alternatively, non-IP compliant (however IP-like)
protocols that have been devised from existing space/ground protocols
may be used. Data using these protocols would be repackaged at the
ground station so as to be IP compliant for routing along CSOC's
Intranets and the Internet. The set of protocols providing the most
efficiency for moving the data and the highest compliance to normal
network functionality will likely be the most desirable choice for
providing CSOC with reliable wireless connections.

Utilize Autonomous Operations

Autonomous operations are critical to the strategy for providing highly
efficient mission and network services between the user and the
spacecraft or on-board instrument. The CSOC networks, RF links,
spacecraft, and instruments will all become autonomous in a graduated
fashion.

-   Autonomous operations are first introduced in parallel to manned
    operations, tested and verified in that parallel mode, and then
    fully implemented by replacing the manned operations as full
    verification is achieved.

-   At first, autonomy will be largely ground implemented, as the
    present and near-future space hardware will not have quite the
    functionality needed to perform the autonomous operations in space.

-   As spacecraft and instruments become more capable, the autonomous
    functions will be converted to on-board software. Again, this is a
    graduated process where autonomous software is up-linked and enabled
    in parallel to functioning ground software.

-   As confidence is gained in the functionality of a flight module,
    full control of that particular function is handed over to the
    on-board software and the ground module is discontinued.

-   With the final implementation, we will have migrated most or all
    mission operations to the spacecraft resulting in the least
    expensive system possible for the operation of NASA's space
    missions.

![](media/image3.emf){width="1.1194444444444445in"
height="-1.1611111111111112in"}

Figure 4.1-2 General CSOC Command and Data Movement Structure

The general structure for achieving the autonomy and IP functionality on
the ground as well as on-board the spacecraft is shown in Figure 4.1-2.
The figure implies complete autonomy in the movement of data from the
instrument, along an on-board LAN, through the network module, and
through the spacecraft RF system to the ground. The data is captured by
the autonomous ground station's RF system and processed to remove the
artifacts of space communications by ground processing equipment. The
data are then passed via CSOC's Intranet to an IMOC (where operations
users have access) and from there via Internet to the user. Commands are
sent back up this chain to the spacecraft and instruments. On the
wireless portion of the data path, the protocols are augmented with data
recovery encoding techniques, such as Viterbi and Reed Solomon and the
data annotations derived from CCSDS standards. Each of the network
components operate with agility in a prioritized, on-demand fashion such
that long term network usage planning and scheduling is not necessary.

In the early consolidation phase of the CSOC contract, the TDRSS space
network (SN), along with NASA's ground network (GN), is firstly
automated at the ground stations and then later converted to demand
access under software control as spacecraft with demand capability are
launched. Also in the early phase, the DSN antennas are automated then
later converted to an autonomous, demand access-like system using the
Internet protocols with augmentations.

Missions of the future to the Moon and Mars require the extension of the
CSOC in-space network infrastructure to support the retrieving of data
from surface networks, atmospheric balloons, and manned bases.
Communications satellite constellations are needed around the Moon and
Mars to assure global telecommunications from point to point on the
surface and from surface to earth. These systems will also incorporate
demand access from surface to communications satellite, and thence back
to the surface or on to earth. Likewise demand access will be
implemented for communication from earth user to the Moon or Mars
constellation and down to the Moon or Mars surface.

The conversions of SN, GN, and the DSN serve as the final,
Internet-based CSOC architecture. Future enhancements (i.e.; use of
commercial GEO and LEO communication systems to pick-up NASA satellite
command and data handling; or, in-space replacements/augmentations to
the DSN) will be built on the autonomous IP-based structure that are
implemented during the CSOC.

## 4.2 Planned Trades

### 4.2.1 TDRSS.

The strategies for modification and utilization of the TDRSS are
directed toward reducing operations costs by:

• Early modification of the in-place TDRSS to obtain automated
scheduling and operation of the system.

• Later modifications to convert the system to a demand mode method of
operation on both the MA and SA subsystems.

• Encourage (with appropriate pricing strategies) customer use of the
highest bandwidth antennas to minimize time needed to service customers.

A computer, agent software, and support hardware is developed and
installed at White Sands Complex (WSC) that serves as a master router
for the TDRSS. The agent allows the near real-time scheduling of
requests from the user's ground location via IP connection to the TDRSS
at WSC. Prior to the use of IP compatible spacecraft, it is the intent
of the modifications to spoof the IP connection at the WSC agent
computer and make it appear to the ground user that the TDRSS and user
spacecraft is performing the TCP/IP and UDP/IP protocols. It is of
interest to mention here that a TDRS performs in a bent pipe fashion in
all modes; that is, it routes data between the spacecraft and ground and
performs no processing or decisions based on the user traffic.
Therefore, a TDRS cannot perform TCP/IP or traffic scheduling on-board.
It can only pass such protocols on through as ordinary data. The same is
true for the H, I, and J TDRS's. Later, after IP compatible spacecraft
are in-space, the TDRSS agent at WSC will pass the Internet protocols
between the ground user and the spacecraft, through each TDRS, so that
true IP conformance is realized.

TDRSS, under CSOC, uses two general modes of operation:

• Pre-scheduled service which supports SST, ISS, and legacy missions
(see Figures 4.2.1-1 \[left and bottom\] and 4.2.1-2 \[dark hatched time
periods\] which show scheduled SA service for SST and ISS); and,

• On-demand service which is implemented during the gaps between the
scheduled services (see Figures 4.2.1-1 \[right\] and 4.2.1-2 \[light
shaded time periods\] which show demand access and available TDRSS SA
time to satisfy demanded service requests).

The TDRSS is further modified to provide on-demand IP service between
the user's ground location and on-orbit spacecraft using:

• Low rate S-band MA service and

• High rate K-band Single Access (SA) service.

The technical strategy is to use the lower rate, wider field of view,
S-band, Multiple Access (MA) feature of the TDRSS to detect 'demands'
for either level of service. The wide field of view for MA enables a
user spacecraft to be heard by a TDRS such that it can 'demand' service
at any time by broadcasting in an general upward direction in the S-band
for as long as necessary to get the attention of a TDRS. Rendering of
demanded service is then scheduled by agent software at WSC that
monitors and routes the MA traffic for each TDRS. It is the agent's task
to determine the earliest possible moment when TDRSS can render service
as balanced against present activities and priority. It must then inform
the user spacecraft through the MA system as to when it can expect
service (the earliest time and from which TDRS the service will be
rendered), and then initiate the service at the correct time. The WSC
agent software can also initiate or pass-on (from the ground) a TCP/IP
message to the user spacecraft by broadcasting through a TDRS downward
with the MA antenna until the user spacecraft responds. If, for some
reason, the TDRSS doesn't know where the user's spacecraft is, the
entire constellation can send search signals until one of them gets a
response.

![](media/image4.emf){width="6.485416666666667in"
height="5.009722222222222in"}**Figure 4.2.1-1, The TDRSS shown providing
scheduled and demanded access.**

![](media/image5.emf){width="6.485416666666667in"
height="2.4368055555555554in"}

Figure 4.2.1-2, Demanded access fits between scheduled services.

The TDRSS provides customer spacecraft with on-demand IP service at any
of its available data rates using a very high rate Ku-band (all TDRS's)
or Ka-band (TDRS's H, I, and J only) communications system. The high
rate TDRSS data is accommodated with asynchronous transfer mode (ATM)
protocols. The ATM protocols guarantee bandwidth availability for
applications such as ISS or STS video and audio channels in parallel
with TCP/IP class internet traffic.

An interesting and powerful artifact of this new internet-based
constellation is that a trigger signal from one user spacecraft can be
nearly instantly routed around the earth, via the TDRSS through WSC, to
other spacecraft to enable very near real-time cooperative science
investigations. If an instrument on one user spacecraft (or even an
earth-bound facility) detects an important event, such as a gamma- or
x-ray burst, a trigger signal is sent via S-band to the nearest TDRS MA
antenna. The WSC ground agent then acts as a server/coordinator for this
activity by broadcasting the trigger to other user spacecraft through
each TDRS MA system and by sending IP broadcasts over the Internet to
subscribing user ground sites as well as subscribing spacecraft via
ground stations. Another software agent on a CSOC server then
coordinates the data gathering by receiving all initial data resulting
from the trigger. This agent performs triangulation calculations that
support extending the investigation (i.e.; determining where in the
heavens the trigger originated by analyzing the timing information
gathered from each of several spacecraft). The coordinating agent then
passes the results on to supporting spacecraft such as HST or AXAF,
which may want to slew over as fast as possible to see the beginning of
a nova.

### 4.2.2 Ground Stations.

**Modifications**

Existing ground network (GN) stations are modified early in the CSOC
program. These modifications are directed to automating GN operations at
the antenna sites and on the network. The first changes are directed
toward automatic scheduling of antenna activities and the interfacing of
legacy spacecraft data and commands to CSOC's Intranet and the public
Internet by embedding the information into IP conforming packets. Later
modifications are directed toward converting existing antennas to
stand-alone demand access operation. At first, service from the GN will
be requested by user-initiated web messages to automatic scheduling
programs at the CSOC control center. Later, antenna service will be
rendered on demand from the spacecraft or the user.

Front End Processors (FEP's) will be installed between the antenna's
transceiver and the IP network at all GN antenna sites. This will enable
conversion between legacy spacecraft command/data streams and the IP
compliant data needed for the networks. Thus, early in CSOC's existence,
all data will be moved on IP compliant networks. Later, as new IP
compliant spacecraft and instruments come on-line, most of the
functionality of the FEP's become unnecessary and the only
space-specialized equipment needed is the Viterbi and Reed Solomon types
of data error detection and correction hardware and software.

Conversion to Ka-band operation for most missions will occur later in
the CSOC program. At that time, existing ground stations may be
converted to operate in the Ka-band; however, it may be more cost
effective to convert the GN to the miniature ground systems described
below.

![](media/image6.emf){width="5.526388888888889in"
height="6.428472222222222in"}

Figure 4.2.2-1, a. Modification for Automation and IP Connection.\
b. Spacecraft Demands Service, GS Acknowledges.\
c. Spacecraft and GS move high rate data down and up.\
d. GS Modified for Autonomous Demand Access Operation.

A Strategy for Implementing an Inexpensive Miniature Autonomous Ground
Station (MAGS).

Future spacecraft will use Ka-band RF hardware for moving data and
commands. This frequency is chosen for its synergy with the goals of
CSOC.

• Ka-band enables very high rate data transfers. Most spacecraft don't
generate huge amounts of data, but they do tie up resources when their
data is moved. High rate transfers ensure short service times, thus, the
number of spacecraft that can be serviced is increased. Ground station
overflights are very short, so increased data rates enable many
spacecraft to dump all their data in one download.

• Ka-band equipment is very small and relatively low power. The Ka-band
hardware will provide for 'better, faster, cheaper' spacecraft data
handling without draining launch mass and on-board power resources.

• Once standard systems are designed, Ka-band equipment should become
quite cheap, both for the spacecraft and for the ground stations.

An inexpensive mission scenario that is being used now and is likely to
continue after CSOC begins, is to provide ground support for a mission
using a small antenna with the appropriate RF, dish steering, and
computer control equipment mounted to the roof of a college campus
building.

![](media/image7.emf){width="5.526388888888889in"
height="4.415277777777778in"}

Figure 4.2.2-2 a. MAGS Acknowledging a Request for Service.\
b. Ka-band High Rate down- and uplink.\
c. Equipment in the base of a MAGS.

While such a system is quite inexpensive, it is not very capable as it
can only communicate with the spacecraft when it flies over the ground
station, 5-10 minutes every other orbit.

A strategy for making this ground station scheme more useful is to use a
common-design Miniature Autonomous Ground Station (MAGS), see the
Figures in 4.2.2-2. A MAGS uses the more efficient (in size, mass, and
power) Ka-band equipment similar to that being used for direct digital
television. Ka-band enables the up- and downlink transfers to be very
high rate, at 50-300 Mbps or more. If done cheaply enough, many of these
MAGS can be dispersed among universities and other users around the
world. If they are all then connected to the Internet and shared by any
number of compatible spacecraft, a very powerful communications system
can be realized.

The autonomous, steerable dish MAGS is a single turn-key package that
provides everything needed to 'connect' the inexpensive spacecraft to
the internet at each fly-over. The package performs as a simple server
to the spacecraft, buffering up-linked task commands and downlinked data
in a high-density local storage so that the spacecraft/ground station
system can run itself for extended periods of time.

### 4.2.3 Strategies for Providing On-demand Access to an IP Compliant DSN.

The Deep Space Network (DSN) will be modified to provide a demand
access, IP compliant system for the deep space CSOC users. The
strategies include increasing data rates by modification of the DSN
antennas to Ka-band operation; and by using beacon mode signaling, as
now being developed by JPL, as the standard method of operating the DSN
for most solar system missions.

To implement this beacon mode of operation, several smaller, inexpensive
antennas will be assigned to regularly search the sky in the directions
of known missions to detect the various missions\' beacon signals (see
Figure 4.2.3-1).

![](media/image8.emf){width="6.4875in" height="2.2354166666666666in"}

Figure 4.2.3-1, DSN using beacon mode to achieve autonomous demand
access service.

A spacecraft may return:

• No signal;

• An 'I'm OK' signal with identification, time, and a small amount of
health data;

• An 'I need high speed data service' signal with identification, time,
and a count-down time to when the high rate data will start; and,

• An 'I have a problem' signal with identification, time, and pertinent
health data.

Upon receiving an 'I need high speed data service' signal, the DSN
autonomous agent software slew\'s a large Ka-band dish to the requesting
spacecraft and captures the data. After the high rate data is
downloaded, the large dish is immediately made available to service
another mission. In this fashion, the expensive large dish resources are
not required to continuously stare at spacecraft for long periods of
time while no real data is being downloaded, as has been the normal
method of operation in the past.

To avoid competition between spacecraft for DSN resources, spacecraft
are informed of time periods for when they can't send high rate data.
These periods of time are used for guaranteeing reception service for
another mission's critical sequences (such as one about to perform entry
and landing at a moon or planet); or for other missions that are
particularly far away and are power limited such that re-transmission
isn't practical. During the periods that are not blocked out, a mission
is free to send high rate data after having first sent an 'I need high
speed data service' preamble. In most cases, the data will be captured.
Occasionally, the DSN system may miss the reception and the data will
need to be re-transmitted.

When the smaller antennas are listening to various mission beacon
signals, they will also send a low rate return signal that carries small
amounts of command and timing synchronization data for the several
different spacecraft that may be in the antenna beam.

These signals returned from earth:

• Are used to inform a spacecraft of impending high rate up-link data to
follow;

• Provide a navigation marker for where Earth is with respect to the
spacecraft; and,

• Provide Earth-to-spacecraft distance information by echoing some
beacon signals back to the spacecraft.

The JPL TMOD people have studied the beacon mode of on-demand operation
for the DSN. The CSOC program will benefit from this work.

### 4.2.4 Strategies for Moving CSOC functions to the Spacecraft

CSOC is charged with using consolidations and the application of
innovative technology and automation to significantly reduce the cost of
NASA's operations. Very important aspects of this effort are to apply
Internet Protocols (IP's) and to migrate mission operations to software
and hardware directly on-board the spacecraft.

The CSOC strategy for encouraging the development of IP compliant
autonomous spacecraft is to assist in the definition of the requirements
and functionality of such spacecraft and to assist in coordination of
activities initiated by NASA and/or spacecraft and equipment vendors to
design such missions, spacecraft, and instruments. CSOC will provide an
impetus for changing spacecraft to the new designs through its pricing
structures. Those spacecraft that can take full advantage of access
on-demand and that utilize high levels of autonomy with minimum ground
operations support will be much cheaper to fly.

The customer spacecraft's interface to the CSOC network is a wireless
'connector' package consisting of a low rate, near omni-directional RF
module, a steerable, high rate, Ka-band RF module, hardware to handle
encapsulation and decapsulation, encryption and decryption, internet
protocols and on-spacecraft routing. The customer's spacecraft further
includes the hardware and software to provide all other functions needed
to operate within our architecture with full autonomy and independence
(GPS receiver and processor, attitude determination hardware and
software, etc.).

## 4.3 Candidate Trades

### 4.3.1 A Possible Strategy for Using Commercial LEO Communication Satellite Constellations 

Over the duration of CSOC, it might become feasible to communicate at
low rates through a commercial communication satellite system (see
Figure 4.3.1-1). Using an omni-directional RF system to communicate
through a commercial satellite constellation such as Iridium or
GlobalStar could accommodate normal low-rate (from 100 to 1,000,000 bps)
command and status signal traffic between an LEO spacecraft and the
ground. This connection could be used by the customer spacecraft to
receive task assignment commands from the user. It could also be used to
send down health and status data both on-demand and periodically, as
well as alarm data in an on-demand fashion from the spacecraft.

The airborne, balloon, launch vehicle, or sounding rockets segments of
NASA's mission could be nicely served by a commercial constellation or a
ground station network because each of these vehicles spends all or part
of their active mission time moving relatively slowly in the earth's
atmosphere beneath these constellations.

![](media/image9.emf){width="4.8875in" height="3.7069444444444444in"}

Figure 4.3.1-1, Commercial Constellation with a CSOC Plug-in. Also shows
possible coverage of a rocket launch.

### 4.3.2 Strategies for Providing Moon or Mars Communications Constellations.

JPL has undertaken a study of employing a communication satellite
constellation around Mars to support future robotic and manned missions
(see Figure 4.3.2-2). It is NASA's strategy to significantly increase
the number of missions to Mars in the next decade, particularly if the
cost of performing the missions becomes considerably less expensive. A
communications constellation, if it can be implemented cheaply, is an
ideal method of 'connecting' to Mars and all the landers, probes,
surface network stations (for weather, seismic measurements, etc.) and
later manned stations. It would enable surface to surface, surface to
near space, and surface to earth communications. Properly designed, it
can also bring the Internet and its powerful protocols as well as global
positioning technology to the Mars space, orbital, atmospheric, and
surface environments. The connection to earth would be near continuous
and at as high a rate as practical (1 Mbps or better), at least in the
Ka-band. The connection to earth is likely best done using continuous
coverage with connection being picked-up as each DSN site turns toward
Mars. Communication from the Mars surface to the constellation itself,
however, can occur by access on-demand. A similar constellation could be
placed around the moon to enable full communications coverage to the
back side.

![](media/image10.emf){width="6.414583333333334in"
height="3.1930555555555555in"}

Figure 4.3.2-1, JPL concept for Mars IP Communication Constellation.

CSOC will coordinate with and assist NASA and JPL in these strategies by
helping to define these communications systems as they will ultimately
interface with CSOC systems on earth.