[Code of Federal Regulations]

[Title 14, Volume 5]

[Revised as of January 1, 2006]

From the U.S. Government Printing Office via GPO Access

[CITE: 14CFR1215.109]



[Page 143-145]

 

                     TITLE 14--AERONAUTICS AND SPACE

 

                          SPACE ADMINISTRATION

 

PART 1215_TRACKING AND DATA RELAY SATELLITE SYSTEM (TDRSS)--Table of 

Contents

 

  Subpart 1215.1_Use and Reimbursement Policy for Non-U.S. Government 

                                  Users

 

Sec. 1215.109  Scheduling user service.



    (a) User service shall be scheduled only by NASA. Scheduling refers 

to that activity occurring after the user has been accepted and placed 

in the TDRSS mission model as specified in Sec. 1215.108(b). See 

appendix C for a description of a typical user activity timeline.

    (b) Schedule conflict will be resolved in general by application of 

principles of priority to user service requirements. Services shall be 

provided either as normally scheduled service or



[[Page 144]]



as emergency/disruptive update service. Priorities will be different for 

emergency/disruptive updates than for normal services.

    (1) Normally scheduled service is service which is planned and 

ordered under normal operational conditions and is subject to schedule 

conflict resolution under normal service priorities. Priorities are 

established by the NASA Administrator or his/her designee. Requests for 

normally scheduled service must be received by the schedulers at the 

GSFC Network Control Center (NCC) no later than 45 minutes prior to 

requested support time.

    (2) Normal scheduling principles of priority are generally ordered 

as follows beginning with the highest priority:

    (i) Launch, reentry, landing of the STS Shuttle, or other NASA 

launches.

    (ii) NASA payloads/spacecraft.

    (iii) Other payloads/spacecraft of interest to the United States.

    (iv) Other payloads/spacecraft launched by a NASA launch vehicle.

    (v) Other payloads/spacecraft.

    (vi) Support of other launches.

    (3) Exceptions to these priorities may be determined on a case-by-

case basis with the NASA Administrator or his/her designee as the 

priorities stated in paragraph (b)(2) of this section are indicative of 

general rather than specific cases.

    (4) Emergency service conditions are those requiring rapid response 

to changing user service requirements. Emergency service may be 

instituted under the following conditions:

    (i) Circumstances which pose a threat to the security of the United 

States.

    (ii) Circumstances which threaten human life.

    (iii) Circumstances which threaten user mission loss.

    (iv) Other circumstances of such a nature which make it necessary to 

preempt normally scheduled services.

    (5) At times, emergency service requirements will override normal 

schedule priority. Under emergency service conditions, disruptions to 

schedule service will occur. As a consequence, users requiring emergency 

service shall be charged for emergency service at rate factors set forth 

in appendix B.

    (6) Disruptive updates are scheduled updates which, by virtue of 

priorities, cause previously scheduled user services to be rescheduled 

or deleted or are requested by the user less than 45 minutes prior to 

the scheduled support period.

    (i) Disruptive updates will be charged at the same rates as 

emergency service. User initiated schedule requests which are received 

less than 45 minutes prior to the requested schedule support time will 

be considered a disruptive update.

    (ii) User initiated schedule requests which are received more than 

45 minutes and less than 12 hours prior to the scheduled support period 

will be acted upon as a routine input provided other users are 

unaffected. If other users are affected, the scheduling input will be 

considered a disruptive update and the appropriate charge factor will be 

applied.

    (iii) The Network Control Center (NCC) at GSFC reserves the sole 

right to schedule, reschedule or cancel TDRSS service. Schedule changes 

brought about through no fault of the user are not charged the factor 

for a disruptive update.

    (7) While the priority listing remains the general guide for 

establishing support availability, the NASA schedulers will exercise 

judgment and endeavor to see that lower priority users are not excluded 

from a substantial portion of their contracted-for service due to the 

requirements of higher priority users.

    (8) When a user contracts for TDRSS service for an ``operational 

satellite'' which interfaces with a significant number of national and 

world-wide users on a regularly scheduled basis as opposed to a 

``research and development satellite,'' NASA will place special emphasis 

on the operational requirement when planning schedules. This should 

reduce the probability of losing perishable operational data such as 

meteorological, climate, or earth resources information.

    (c) General user service requirements, which will be used for 

preliminary planning and mission modeling, should include as a minimum, 

the following;

    (1) Date of service initiation.



[[Page 145]]



    (2) Expected date of service termination.

    (3) The type of TDRSS services desired [e.g., multiple access, 

tracking, etc.].

    (4) The frequency and duration of each service, including orbital 

position or time constraints on service delivery from a given spacecraft 

where appropriate.

    (5) Orbital or trajectory parameters and tracking data requirements.

    (6) Spacecraft events affecting tracking, telemetry or command 

requirements.

    (7) Signal parameters and data rates by type of service, type and 

location of antennas and other related information dealing with user 

tracking, command, and data systems.

    (8) Special test requirements, compatibility testing, data flows, 

simulations, etc.

    (9) Identification of type and quantity of user information 

necessary for control functions, location of user control facility, and 

identification of communications requirements.

    (10) Identification of ground communications requirements and 

interface points, including the level of support to be requested from 

NASCOM.

    (d) To provide for effective planning, general service requirements 

should be provided at least 3 years before initiation of service. With 

these data NASA will determine whether the requested services can be 

provided.

    (e) Detailed requirements for user services must be provided 18 

months before the initiation of service. These data will be the basis 

for the technical definition of the Interface Control Document (ICD). If 

requirements are received late, necessitating extraordinary NASA 

activities [e.g., overtime, special printing of documents], such 

activities will be considered to be mission unique and their cost 

charged the user.



[48 FR 9845, Mar. 9, 1983, as amended at 56 FR 28049, June 19, 1991]