High Data Volume SMSes and TDRS Contact Usage
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 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, 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.
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 observations 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:
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
- 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
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.
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 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. Plot 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) 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.
Plot 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. Plot 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.
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.
