[Code of Federal Regulations] [Title 14, Volume 5] [Revised as of January 1, 2007] From the U.S. Government Printing Office via GPO Access [CITE: 14CFR1215.109] [Page 145-147] TITLE 14--AERONAUTICS AND SPACE CHAPTER V--NATIONAL AERONAUTICS AND 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 146]] 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 147]] (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]