Internal Technical Memorandum ITM-2000-01
High Data Volume SMSes and TDRS Contact
Usage
A. Patterson, E. Wells and D. Jones
May 18, 2000
Concurrence: D. Taylor
ABSTRACT
The future installation of the Advanced Camera for Surveys (ACS) and the potential for operating
four instruments will significantly increase the volume of data to be transmitted from the Hubble
Space Telescope (HST) via the Tracking and Data Relay Satellite System (TDRS) to the ground. A
reasonable estimate is about 150 Gbits of data per calendar week. This report investigates the ability of the scheduling process to handle such a large data volume with current TDRS accessibility,
generic TDRS scheduling, and single High Gain Antenna (HGA) usage.
1. Introduction
The installation of the Advanced Camera for Surveys (ACS) will occur during Servicing Mission
SM3B which is currently expected to occur in June of 2001. When this instrument is operational
the volume of data produced per week by the anticipated science programs will be significantly
higher than previously encountered. It has been estimated (in ISR ACS-97-01, HST Reference
Mission for Cycle 9 and Ground System Requirements) that the highest average daily downlink
data volume will be 16.5 Gbits per day excluding overhead under the assumption that the ACS
images will not be compressed. Applying estimates of the overheads produces a weekly data volume requirement of 152 Gbits. The increased data volume will require a correspondingly
increased number of granted TDRS contacts to downlink the data.
In this report we examine how the needed number of contacts compares to the maximum possible.
We describe the current process for obtaining TDRS contacts, then our reasons for desiring generic
TDRS request operation. We consider single High Gain Antenna (HGA) operation and describe
our test procedure.
Finally we present the results of tests of the acquisition of TDRS contacts for high data volume
SMSes and discuss the limits this places on the data volume that we will be able to handle.
2. Theoretical Limits
The contacts between a TDRS satellite and HST need more than just line of sight visibility. They
also require the capability of orienting an HGA at the desired TDRS satellite. The time window
1
Internal Technical Memorandum ITM-2000-01
available for each HGA to TDRS contact has been trimmed by a few minutes to a current maximum value of 45 minutes, to allow for ephemeris slips between the time of the initial request and
final flight Mission Schedule (MS) and Command Load (CL) generation. The source of the
ephemeris slips is related to the high level of sunspot activity that leads to increased density of the
Earth’s upper atmosphere at the altitude of HST. This, in turn, leads to increased drag on HST
making the orbit more difficult to predict. Each 45 minute contact should allow the downlinking of
about 2.5 Gbits of data.
For any particular pointing of HST each HGA can point at approximately half the sky. The two
HGAs cover two separate hemispheres. Each TDRS satellite will spend 7 of its 14 daily views
from HST being visible to each HGA, ignoring the small effects of the orbital motion of HST and
the TDRS satellites. Generally when a TDRS satellite moves out of the visibility of HGA1 it
moves into the visibility for HGA2 and vice versa. The specific orientation of HST about its V1
axis is not determined inflexibly by the need to orient the solar arrays at the sun, but can be
adjusted within a small range for science and operational reasons. Particular orientations will modify the TDRS visibilities of the HGAs. In the best case, where no TDRS contacts are blocked due
to HST orientation, operations could downlink 17.5 Gbits of data per HGA per TDRS per day or
about 122.5 Gbits of data per HGA per TDRS per week. For the case where only a single antenna
accesses two TDRS satellites the theoretical maximum is 245 Gbits per week. For a single
antenna, the TDRS availability windows for TDRS East and TDRS West do not overlap. When
both HGAs are used there is some overlap of the TDRS visibility times of each HGA so the doubled limit of 490 Gbits per week has to be reduced somewhat to about 440 Gbits.
If HST has two HGAs available and two TDRS satellites, our anticipated data volume is well
under the ~440 Gbit limit. However, for the case of a single antenna a weekly volume of 150 Gbits
is about 60% of the theoretical 245 Gbit maximum.
3. Current Process for TDRS Contact Determination
The current process for getting the TDRS contacts necessary to handle the data downlink needs of
the Science Mission Schedule (SMS) has several steps, which are summarized below.
1. The Science Planning and Scheduling Team (SPST) produces an SMS with all science
on the timeline as it will be expected to execute on HST.
2. SPST generates requests for TDRS contacts using knowledge of the run of science data
recording through the week and visibilities of TDRS satellites from the HGAs on HST.
3. SPST submits the TDRS requests to Network Control Center (NCC).
4. NCC trims (or deletes) contacts.
5. SPST generates a final MS using the TDRS contacts granted by NCC.
6. SPST eliminates any Solid State Recorder (SSR) overflows or any high final volume on
the SSR by requesting additional downlinks.
7. SPST generates a final MS that avoids SSR overflows and has a low ending usage on the
SSR.
A feature of this process is that the initial request for TDRS services to the NCC uses both the
known data volume through the week and the planned pointing profile for HST. The flight SMS
generally will be the same as the initial SMS. Any differences between the initial and final SMSes
are infrequent and are caused by Target of Opportunity observations, and unanticipated science,
2
Internal Technical Memorandum ITM-2000-01
instrument or observatory issues. Therefore the differences between the granted TDRS contacts
and those initially requested will usually be due to the TDRS conflict resolution process at NCC.
There are many users of the TDRS system and NCC attempts to satisfy as many of the requests as
it can. Because some proportion of our requests are trimmed or denied we request somewhat more
contacts than we need for the science downlinks. This action is important because it increases the
likelihood that the size of the granted TDRS contacts that we use will be long. We prefer long
TDRS contacts because they are more efficient. For each TDRS contact about three minutes are
used up by overhead activities between HST and the ground station for control of the data dumps,
so longer contacts mean that a higher percentage of the time is used for transferring data. For a
given volume of data, using long contacts will minimize the total contact time and the number of
transmitter turn-ons.
4. Generic TDRS Requests
Generic TDRS operations separates the initial request for TDRS services from any knowledge of
the pointing profile or data volume of the flight SMS. The request for TDRS services may be made
before the timeline for the flight SMS is known. This is the main attraction of generic scheduling;
it allows flight SMS production to occur well after the request for TDRS services. By putting the
creation of the flight SMS much closer to its time of execution we can more easily accommodate
needs for urgent changes (whether science or engineering) because fewer SMSes would be in work
at any one time. Any generic TDRS request must produce sufficient contacts to handle the
unknown data volume of the flight SMS. This could be done by using for the request some value of
data volume than is higher than most if not all expected weekly data volumes by an additional
oversubscription factor. This higher level of request acknowledges that we not only have to
account for the trimming and denied services that NCC will impose but also the adjustment of the
contact placement and durations caused by the change in pointing profile. While the TDRS satellites will still be visible from HST the pointing and orientation of HST in the flight SMS will be
different from that in the generic TDRS request. For some flight pointings and orientations the initially requested TDRS satellite and HGA contact will no longer be possible. Additionally, some
contacts, now possible, would never have been requested because they were not possible with the
pointing profile used in the generic TDRS request.
Even with the extra oversubscription it is an assumption that, statistically, the denials of service by
NCC will be reasonably smoothly distributed. As the number of orbits per week (~100) is not very
great, the distribution of granted contacts could be distinctly non random. We require not only that
the number and durations of the granted TDRS contacts be sufficient to downlink the total data
volume written to the SSR for the calendar week, but that the distribution of contacts removes data
from the SSR sufficiently steadily such that there is no overflow of the storage capacity of the SSR.
The TDRS contact requirements of all NCC serviced spacecraft in low Earth orbit are not random
but are quasi-periodic, because they are related to the orbital visibilities between the individual
spacecraft and the TDRS satellites. It is expected that from time to time the TDRS visibilities of
the relatively small number of TDRS users will phase together. At these predictable times the
amount of TDRS contact time initially granted to each satellite user will be below average. Additional contact time will have to be negotiated with NCC. HST is in the fortunate situation of being
very high on the NCC priority list and should suffer less from the conflicts. The Space Shuttle has
higher priority than HST, so Shuttle flights do cause more disruption to our requested TDRS
contacts.
3
Internal Technical Memorandum ITM-2000-01
5. Transmitter Availability
When transmitter 2 failed, SPST began operating with a single transmitter (transmitter 1) and has
continued to do so even though transmitter 2 was replaced in SM3A. The output of transmitter 1 is
directed solely through High Gain Antenna 1 (HGA1). The two HGAs are on opposite sides of
HST and each HGA can see only about half the sky. For a successful contact through either HGA
there must be a TDRS satellite visible from the antenna and the line of sight must not be blocked
by structures on HST. There is a period of about 3 orbits each day when a single HGA generally
cannot contact either TRDS East or TDRS West, and during which high gain downlinks are not
possible. The original transmitter 2 is being inspected, so that the failure can be understood, the
probability of future transmitter failures estimated and refurbishment for future re-installation considered. For the immediate future only a single transmitter will be in routine operation at any one
time. This is a precaution against the failure of another transmitter. Therefore we must carefully
consider the case of single transmitter and HGA usage.
6. Science Data Storage Capacity
A single SSR on HST is currently used to store both science and engineering data. The full storage
area is partitioned so that science data may be stored in a large section. The current setting for the
science data storage is 8.63 Gbits and that for the Engineering data is 2.65 Gbits. Using the highest
average data rate per day from ISR ACS-97-01 we could expect to fill the science section of the
SSR in less than 9 hours or about 5 orbits if the science recording activity were uniformly
distributed.
A second similarly sized SSR was installed on HST in SM3A. If the two SSRs were set to use the
first for science and the second for engineering data, the gain in science storage capacity would
only be a factor of 30% which is quite small. The second SSR would then certainly be under utilized by the engineering data requirements. If the two SSRs were kept logically separate but each
permitted to handle both science and engineering data, the weekly operations effort would be complicated by the management of the storage usage. While this management could eventually be
accomplished by software after a period of software development, at least initially it would need to
be handled by a more manual process. A better way, from the viewpoint of science data handling,
would be to configure the two SSRs as one logical contiguous unit, so that the operational system
would be unaware of any distinction between the two physical units. The changes to allow this
would be in the Flight Software and the rest of the ground system would be unchanged, except for
a modification to a single total volume parameter.
The advantage of having twice the storage capacity for science data will be strongly suggested by
the tests results presented below.
7. Test Program
We used the currently available operational software to test the ability of the system to handle
SMSes with large data volumes under several circumstances. First we constructed a high data volume SMS for the data readouts by mimicing the set of instruments to be in use after SM3B. The
data volume we chose was 150 Gbits for the week, to correspond to the highest average expected
in the ISR ACS-97-01 report. This value included all instruments, assumed no compression for the
ACS images and applies to general usage. Higher data volumes may occur for some special obser-
4
Internal Technical Memorandum ITM-2000-01
vations or campaigns. We ensured that the distribution of data volume with time was not uniform
but had some variation, because that is the situation SPST encounters operationally. We tested the
response of the software system to the high data volume distribution, with a variety of flight SMS
pointing distributions and different TDRS availabilities.
As a basis for the pointing profiles in the tests we used the set of eight flight calendars from week
99256 to week 99305.
The TDRS availabilities were created by following the current process either with or without a
modification for Generic TDRS scheduling. We included the effects of oversubscription of contacts, trimming and denial of contacts by NCC and the usage of one or both HGAs. For the NCC
denial and trimming of contacts we modified an initially generated contact list in a statistical fashion that mimiced the NCC action in both the percentage and distribution of contacts trimmed or
denied.
The effect of the engineering data dumps was ignored in the tests. It was assumed that engineering
overflow problems could be managed in high science data volume situations just as they are now,
by switching dump designations between science and engineering and manually limiting the engineering dump times. It may be that some small amount of variation in the results is due to the
unmodified (therefore non-optimized) usages of some TDRS contacts for engineering rather than
science.
7.1 Test Procedure
The starting information available for each week included:
1. High data volume SMS (data readouts only)
2. Flight SMS with no data readouts (has pointing profile)
3. Fixed pointing SMS with no readouts (for Generic TDRS requests)
4. Flight basefiles
5. Standard parameters for trimming and denying TDRS contacts
The sequence of actions followed in conducting the test were:
1. Generate Initial TDRS request
• Select oversubscribed data volume SMS (180 Gbits or 210 Gbits)
• Select pointing profile SMS (Flight or Generic)
• Select number of transmitters to consider
• Run Initial mode MS and CL software
• Convert TDRS request to standard granted TDRS format (using DST program)
2. Modify TDRS request, matching NCC trimming and denial actions
• Trim and deny contacts randomly to match typical actions of NCC
• Produce output in standard granted TDRS format
3. Run Final mode MS and CL program
• Use high data volume SMS (150 Gbits)
• Use flight SMS pointing profile
• Use same number of transmitters as Initial request
• Use created granted TDRS file for contact resolution
5
Internal Technical Memorandum ITM-2000-01
4. Adjust TDRS file to accommodate SSR overflows
• Where SSR overflows occur, add extra I29 services on available H04 uplinks
• Create updated granted TDRS file
5. Rerun Final Mode MS and CL program
• Use high data volume SMS (150 Gbits)
• Use flight SMS pointing profile
• Use same number of transmitters as Initial request
• Use updated granted TDRS file for contact resolution
6. Rerun Final Mode MS and CL program as in step 5
• Use lower trigger level for TDRS contact usage
7.2 Results
The most important data to come from the many output files produced by the MS CL generation
process is the amount of data that is successfully dumped. We assumed that any (small) amount
left on the SSR would in practice be downlinked later, so we added this to the value reported for
the downlink volume during the week to produce an adjusted downlinked volume.
The precise value of the data volume recorded in all of the tests was 152.28 Gbits. Table 1 below
presents the average and lowest adjusted downlinked volumes for Generic and non-Generic (i.e.,
current process) requests, using 1 or 2 transmitters and a requested data volume of either 210 Gbits
or 180 Gbits. These data volumes include the effects of using the additional I29 services on top of
existing H04s and of lowering the threshold for triggering downlinks in SSR volume management.
In other words this is the most that the present system can provide from the granted TDRS contact
times before entirely new services are requested. We used only the higher data volume request in
the non-Generic tests.
Table 1: Final Adjusted Downlinked Data volume for the test SMSes
Number of
HGAs
Data volume
in TDRS
request
Generic
request
Generic
request
Non-Generic
request
Non-Generic
request
(Transmitters)
(Gbits)
Average
Lowest
Average
Lowest
1
180
125.55
117.78
-
-
1
210
127.03
120.01
140.94
126.82
2
180
147.57
139.25
-
-
2
210
150.39
147.97
151.6
149.35
8. Discussion
The discussions and recommendations below refer to obtaining additional TDRS contacts by
negotiation with NCC. This is an action that SPST has used infrequently. The additional contacts
could be unused TDRS time but that will be almost entirely in small pieces which will be inefficient and therefore of limited effect in solving a large overflow problem. We may also take a lower
6
Internal Technical Memorandum ITM-2000-01
priority user’s granted contact which may be undesirable for other reasons if used frequently.
Extending existing contacts will produce very little extra contact time, though it would be efficient
in not requiring any more transmitter turn-ons and requiring no additional contact management
overhead.
An expected gradual increase in the number of TDRS users and each users’ needs will increase the
conflicts that NCC will encounter and we must expect an increase in the number of trimmed and
denied contacts. All the tests have been made assuming the same proportion and distribution of
trimmed and denied TDRS contacts that we experience now. The advent of flexible TDRS scheduling is expected to increase the amount of granted TDRS time. Also newer higher capacity TDRS
satellites will eventually be available. Experience will show how significant these changes will be.
8.1 Non-Generic case using 2 transmitters
This is the best case operationally where we make the request for TDRS contacts based on the
flight pointing profile and use both transmitters (HGAs). The lowest result was 149.35 Gbits. We
did encounter some small level of overflows of the SSR, which occurred for only 2 of the 8 test
weeks. In practice we should expect that such a small level of overflow would be resolved by negotiating additional contacts with the NCC in real time.
8.2 Non-Generic case using 1 transmitter
The successfully dumped data volume is significantly below the desired data volume of 152 Gbits.
This is a direct result of the restrictions imposed by single HGA (and single transmitter) usage.
The data overflowing the SSR and therefore lost to subsequent downlinking, is that being written
during the time that the HGA does not in general have usable TDRS contacts. For single transmitter situations this occurs in a period of about three consecutive orbits at the same UT time each
day. A high level of science recording activity will cause overflows each day at the end of and
immediately following this daily 3 orbit window lacking in contacts. While we did not run tests
with a larger data storage capacity it is obvious that additional storage would delay overflow occurrences, and provide more of a bridge to cover the shortage of contacts.
The range of successfully dumped data volumes on the test weeks shows the sensitivity to the
pointing profile and the consequent contact availability between TDRS and the single HGA. 1
shows the distribution of dumped data volumes for each of the test weeks. The lowest volume
(126.82 Gbits) is significantly lower than the rest of the group; the others range from 139.33 to
146.64 Gbits. This suggests that we should be able to handle about 139 Gbits of data per week
about 85% of the time before needing to request additional contact time from NCC. We have not
tested the limits on the additional contacts that NCC may provide. We expect that a substantial part
of the test case shortage of 12 Gbits, if not all of it, will be obtainable with additional contacts from
NCC.
8.3 .Generic case using 2 transmitters
The amount of data successfully downlinked is less than for the non-Generic request using 2 transmitters. Both the average (150.39) and lowest (147.97) downlinked volume produced by the 210
Gbit request are only slightly lower than the test volume of 152 Gbits. This suggests that the oversubscription inherent in the 210 Gbits request is enough to handle both the high data volume and
the generic nature of the TDRS request. For the 180 Gbit request the results (147.57 and 139.25)
7
Internal Technical Memorandum ITM-2000-01
are considerably below the test data volume and 8 Gbits different from one another. The difference
in results for the 180 Gbit and 210 Gbit requests shows how sensitive the volume downlinked is to
the oversubscription level.
2 shows the generally lower level of the downlinked volume and its increased variability for the
180 Gbit request compared to the 210 Gbit request. As we noted for the non-Generic case with 2
transmitters, the small level of overflow seen with the 210 Gbit request should be relatively easily
resolved by real time negotiation with the NCC. For the 180 Gbit request, some if not all of the
required capacity will be obtainable with additional contacts from NCC.
8.4 Generic case using 1 transmitter
The worst results occur for the Generic request case where only one transmitter is available. 3
shows the downlinked volume for each of the test weeks, showing a spread of 18 Gbits with a low
downlink value of 120 Gbits for the 210 Gbit request and ~118 Gbits for the 180 Gbit request. This
gain of ~2 Gbits is small compared to the 32 plus Gbits needed to reach 152 Gbits. It appears that
the controlling factor is the general lack of downlink opportunities in a 3 orbit window every day.
The values of dumped data volume for the 210 Gbit requests are individually very close to those
for the 180 Gbit request for each individual week, while the variation from week to week is much
greater.
9. Recommendations
9.1 Non-Generic Scheduling using 2 transmitters
Using a data volume request of 210 Gbits and the standard process should produce most contacts.
We do expect that a few additional contacts will be easily negotiable with NCC.
9.2 Non-Generic Scheduling using 1 transmitter
If only one SSR is available and we use a high oversubscription request at 210 Gbits per week,
then it would be appropriate to limit the data volume on the calendar to some value between 140
Gbits and 127 Gbits. If we were prepared to suffer a loss of data due to overflows about 15% of the
time then the high value would be appropriate. It is uncertain how many additional contacts would
be available from NCC and the total gain they would provide. If there is no tolerance for data overflows then the low value must be selected.
These values of total weekly data volume could be attained by limiting the science on the SMS,
using data compression for some ACS data or a combination of both.
Putting the second SSR in operation would allow the data volume limit to be raised. Using the
SSRs separately will produce a small gain that will raise the limit values near to the desired volume of 152 Gbits. The most gain will be treatment of the two SSRs as a single logical unit, which
will more than double the capacity for science. This method of using the two SSRs would guarantee that non-generic scheduling using 1 transmitter would be able to handle the desired volume of
152 Gbits per week. It could also allow the oversubscription request level to be reduced, which
would be of definite interest if full cost accounting were ever implemented for TDRS requests.
8
Internal Technical Memorandum ITM-2000-01
9.3 Generic case using 2 transmitters
Using a data volume request of 210 Gbits and the Generic request process should produce most of
the contacts needed. As in the non-Generic case above, any small number of additional contacts
should be easily negotiable with NCC. The high oversubscription for the TDRS contact requests
and the general full day coverage in TDRS contacts provided by 2 transmitter use do provide the
ability to reach the 152 Gbit per week data volume level.
Should full cost accounting for TDRS contact requests ever make a high level of requests undesirable, then we would have to consider limiting the data volume for science and implementing 2
SSR usage. The increased storage volume would not gain any extra contact time for downlinks but
would smooth over the variations in contact availability from orbit to orbit. Using the two SSRs
separately would allow a small drop in the TDRS request level. Using the two SSRs as one logical
unit would allow the request level to drop from 210 Gbits noticeably toward the science volume
value of 152 Gbits, so that would be the preferred choice.
9.4 Generic case using 1 transmitter
If only one SSR were available, then the appropriate limit on science data volume for the SMS is
120 Gbits. The Generic TDRS request should be no less than 210 Gbits per week.
A total weekly data volume of 120 Gbits could be attained by limiting the science on the SMS,
using data compression for some ACS data or a combination of both. This limit would translate to
about 13 Gbits per day without overhead.
Putting the second SSR into operation will allow these limits to be raised. The additional storage
capacity would carry more science data across the general 3 orbit hole in TDRS coverage. This is
the simplest solution to raising the expected data throughput toward the anticipated 152 Gbit
weekly value. Clearly, the generic TDRS request, single transmitter operating mode demands the
maximum increase in storage capacity be obtained if we are not to limit the science data volume.
As described earlier, we can reach this by configuring the two SSRs as one logical unit.
1
9
Internal Technical Memorandum ITM-2000-01
Plot 1: Data Volume for 1 transmitter and 210
Gbit request
150
145
135
130
125
120
Calendar Week
10
5
99
30
8
99
29
91
99
2
4
99
28
77
99
2
27
0
99
26
3
99
56
115
99
2
Data Volume (Gbits)
140
Internal Technical Memorandum ITM-2000-01
2
Plot 2: Data Volume for 2
transmitter Generic requests
155
145
140
135
Calendar Week
180 Gbit request
11
210 Gbit request
99305
99298
99291
99284
99277
99270
99263
130
99256
Data Volume (Gbits)
150
Internal Technical Memorandum ITM-2000-01
3
Plot 3: Data Volume for 1
transmitter and Generic requests
140
135
125
120
115
110
Calendar Week
180 Gbit request
12
210 Gbit request
99305
99298
99291
99284
99277
99270
99263
105
99256
Data Volume (Gbits)
130